[PATCH 1/2] drm/ttm: drop special pipeline accel cleanup function.
From: Dave Airlie
The two accel cleanup paths were mostly the same once refactored.
Just pass a bool to say if the evictions are to be pipelined.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 89 +
include/drm/ttm/ttm_bo_driver.h | 17 +
5 files changed, 37 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index a57aaf666340..1ea58ce7c559 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -499,10 +499,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
}
/* Always block for VM page tables before committing the new location */
- if (bo->type == ttm_bo_type_kernel)
- r = ttm_bo_move_accel_cleanup(bo, fence, true, new_mem);
- else
- r = ttm_bo_pipeline_move(bo, fence, evict, new_mem);
+ r = ttm_bo_move_accel_cleanup(bo, fence, true, bo->type !=
ttm_bo_type_kernel, new_mem);
dma_fence_put(fence);
return r;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 56f974c28eb5..2ee75646ad6f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -824,7 +824,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict, bool intr,
if (ret == 0) {
ret = ttm_bo_move_accel_cleanup(bo,
>base,
- evict,
+ evict, false,
new_reg);
nouveau_fence_unref();
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 99d9ca1087b7..36150b7f31a9 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -200,7 +200,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
if (IS_ERR(fence))
return PTR_ERR(fence);
- r = ttm_bo_move_accel_cleanup(bo, >base, evict, new_mem);
+ r = ttm_bo_move_accel_cleanup(bo, >base, evict, false, new_mem);
radeon_fence_unref();
return r;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 502d334786d2..777f843cdb98 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -581,81 +581,56 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object
*bo,
return 0;
}
-int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
- struct dma_fence *fence,
- bool evict,
- struct ttm_resource *new_mem)
+static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo,
+ struct dma_fence *fence)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
- int ret;
+ struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
- dma_resv_add_excl_fence(bo->base.resv, fence);
- if (evict)
- ret = ttm_bo_wait_free_node(bo, man->use_tt);
- else
- ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
- if (ret)
- return ret;
+ /**
+* BO doesn't have a TTM we need to bind/unbind. Just remember
+* this eviction and free up the allocation
+*/
+ spin_lock(>move_lock);
+ if (!from->move || dma_fence_is_later(fence, from->move)) {
+ dma_fence_put(from->move);
+ from->move = dma_fence_get(fence);
+ }
+ spin_unlock(>move_lock);
- ttm_bo_assign_mem(bo, new_mem);
+ ttm_bo_free_old_node(bo);
- return 0;
+ dma_fence_put(bo->moving);
+ bo->moving = dma_fence_get(fence);
}
-EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
-int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
-struct dma_fence *fence, bool evict,
-struct ttm_resource *new_mem)
+int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
+ struct dma_fence *fence,
+ bool evict,
+ bool pipeline,
+ struct ttm_resource *new_mem)
{
struct ttm_bo_device *bdev = bo->bdev;
-
struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
- struct ttm_resource_manager *to =
[PATCH 2/2] drm/ttm: drop evicted from ttm_bo.
From: Dave Airlie
This was unused.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 4
include/drm/ttm/ttm_bo_api.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 279a0e44a5ed..7562b0844c75 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -298,8 +298,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
moved:
- bo->evicted = false;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
@@ -638,9 +636,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
if (ret != -ERESTARTSYS)
pr_err("Buffer eviction failed\n");
ttm_resource_free(bo, _mem);
- goto out;
}
- bo->evicted = true;
out:
return ret;
}
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 36ff64e2736c..03b4761a3ea3 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -141,7 +141,6 @@ struct ttm_buffer_object {
struct ttm_resource mem;
struct file *persistent_swap_storage;
struct ttm_tt *ttm;
- bool evicted;
bool deleted;
/**
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] ttm follow-on cleanups
These two also just fell out and seemed like good cleanups. (based on previous series) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/7] drm/ttm: move unbind into the tt destroy.
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
This moves unbind into the driver side on destroy paths.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 1 +
drivers/gpu/drm/radeon/radeon_ttm.c| 2 ++
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
6 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dbe3f90a0cf6..2028b9e4c25c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1267,6 +1267,7 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
{
struct amdgpu_ttm_tt *gtt = (void *)ttm;
+ amdgpu_ttm_backend_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
if (gtt->usertask)
put_task_struct(gtt->usertask);
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index b239381498c3..4a020a3da3dd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1372,6 +1372,7 @@ nouveau_ttm_tt_destroy(struct ttm_bo_device *bdev,
#if IS_ENABLED(CONFIG_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
if (drm->agp.bridge) {
+ ttm_agp_unbind(ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 0dfaa6fb536e..806d9ec310f5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -20,6 +20,7 @@ nouveau_sgdma_destroy(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
if (ttm) {
+ nouveau_sgdma_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_dma_tt_fini(>ttm);
kfree(nvbe);
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 76e24c6058ff..03e5ae4e3bf6 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -576,6 +576,7 @@ static void radeon_ttm_backend_destroy(struct ttm_bo_device
*bdev, struct ttm_tt
{
struct radeon_ttm_tt *gtt = (void *)ttm;
+ radeon_ttm_backend_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_dma_tt_fini(>ttm);
@@ -757,6 +758,7 @@ static void radeon_ttm_tt_destroy(struct ttm_bo_device
*bdev,
struct radeon_device *rdev = radeon_get_rdev(bdev);
if (rdev->flags & RADEON_IS_AGP) {
+ ttm_agp_unbind(ttm);
ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 649a7d0a0766..2c527cd20dfa 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1620,7 +1620,6 @@ void ttm_bo_tt_destroy(struct ttm_buffer_object *bo)
if (bo->ttm == NULL)
return;
- ttm_bo_tt_unbind(bo);
ttm_tt_destroy(bo->bdev, bo->ttm);
bo->ttm = NULL;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index d46426164577..7454f797d37b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -636,6 +636,7 @@ static void vmw_ttm_destroy(struct ttm_bo_device *bdev,
struct ttm_tt *ttm)
struct vmw_ttm_tt *vmw_be =
container_of(ttm, struct vmw_ttm_tt, dma_ttm.ttm);
+ vmw_ttm_unbind(bdev, ttm);
ttm_tt_destroy_common(bdev, ttm);
vmw_ttm_unmap_dma(vmw_be);
if (vmw_be->dev_priv->map_mode == vmw_dma_alloc_coherent)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/ttm: drop special pipeline accel cleanup function.
Am 17.09.20 um 08:41 schrieb Dave Airlie:
From: Dave Airlie
The two accel cleanup paths were mostly the same once refactored.
Just pass a bool to say if the evictions are to be pipelined.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 89 +
include/drm/ttm/ttm_bo_driver.h | 17 +
5 files changed, 37 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index a57aaf666340..1ea58ce7c559 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -499,10 +499,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
}
/* Always block for VM page tables before committing the new location */
- if (bo->type == ttm_bo_type_kernel)
- r = ttm_bo_move_accel_cleanup(bo, fence, true, new_mem);
- else
- r = ttm_bo_pipeline_move(bo, fence, evict, new_mem);
+ r = ttm_bo_move_accel_cleanup(bo, fence, true, bo->type !=
ttm_bo_type_kernel, new_mem);
You are now passing evict as always true here. I would keep the if instead.
Apart from that looks good to me,
Christian.
dma_fence_put(fence);
return r;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 56f974c28eb5..2ee75646ad6f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -824,7 +824,7 @@ nouveau_bo_move_m2mf(struct ttm_buffer_object *bo, int
evict, bool intr,
if (ret == 0) {
ret = ttm_bo_move_accel_cleanup(bo,
>base,
- evict,
+ evict, false,
new_reg);
nouveau_fence_unref();
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 99d9ca1087b7..36150b7f31a9 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -200,7 +200,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
if (IS_ERR(fence))
return PTR_ERR(fence);
- r = ttm_bo_move_accel_cleanup(bo, >base, evict, new_mem);
+ r = ttm_bo_move_accel_cleanup(bo, >base, evict, false, new_mem);
radeon_fence_unref();
return r;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 502d334786d2..777f843cdb98 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -581,81 +581,56 @@ static int ttm_bo_move_to_ghost(struct ttm_buffer_object
*bo,
return 0;
}
-int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
- struct dma_fence *fence,
- bool evict,
- struct ttm_resource *new_mem)
+static void ttm_bo_move_pipeline_evict(struct ttm_buffer_object *bo,
+ struct dma_fence *fence)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
- int ret;
+ struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
- dma_resv_add_excl_fence(bo->base.resv, fence);
- if (evict)
- ret = ttm_bo_wait_free_node(bo, man->use_tt);
- else
- ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
- if (ret)
- return ret;
+ /**
+* BO doesn't have a TTM we need to bind/unbind. Just remember
+* this eviction and free up the allocation
+*/
+ spin_lock(>move_lock);
+ if (!from->move || dma_fence_is_later(fence, from->move)) {
+ dma_fence_put(from->move);
+ from->move = dma_fence_get(fence);
+ }
+ spin_unlock(>move_lock);
- ttm_bo_assign_mem(bo, new_mem);
+ ttm_bo_free_old_node(bo);
- return 0;
+ dma_fence_put(bo->moving);
+ bo->moving = dma_fence_get(fence);
}
-EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
-int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
-struct dma_fence *fence, bool evict,
-struct ttm_resource *new_mem)
+int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
+ struct dma_fence *fence,
+ bool evict,
+ bool pipeline,
+ struct ttm_resource *new_mem)
{
struct
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On 08/09/2020 10:46, Daniel Vetter wrote: > On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote: >> Hi, >> >> On 07/09/2020 20:03, Daniel Vetter wrote: >>> On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: On 07/09/2020 10:44, Daniel Vetter wrote: > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver >>> 1.21a), with a custom >>> glue managing the IP resets, clock and data input similar to the >>> DW-HDMI Glue on other >>> Amlogic SoCs. >>> >>> This adds support for the Glue managing the transceiver, mimicing the >>> init flow provided >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the >>> digital D-PHY and the >>> Analog PHY in the proper way. >>> >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 >>> clock, which pixel clock >>> is derived and feeds the ENCL encoder and the VIU pixel reader. >>> >>> An optional "MEAS" clock can be enabled to measure the delay between >>> each vsync feeding the >>> DW-MIPI-DSI transceiver. >>> >>> Signed-off-by: Neil Armstrong >> >> More dw-hdmi drivers which aren't bridges but components, and the thing >> is >> still midlayer-y as heck :-/ > > *dw-dsi, but really they both work the same way and should both be fixed > ... They are bridges but since they have platform-dependent code due to theirs's generic IP nature, they need to be intanciated by components to sync with the platform code. >>> >>> Yeah that's how it currently works, but there's not much reason why it >>> needs to work like that. That platform glue code can also be put behind >>> the drm_bridge abstraction, and we could use the normal dt based bridge >>> lookup like for everything else. >>> >>> Afaiui the only reason dw-* bridge drivers work like that is because for >>> historical reasons we only had component.c at first, and none of the more >>> fancy dynamic bridge lookup. So would be really good to switch this all >>> over to a proper bridge abstraction, and not leak everything around. >> >> Does it mean we should avoit using components, right ? > > Yup, at least when there's an established specific mechanism to handle > cross-driver interactions/EPROBE_DEFER. > > So if you want a drm_panel or drm_bridge or a clock or i2c or anything > else standardized like that, no component.c please. That's just for the > driver-specific glue when you have entirely IP-specific way of building up > a driver from components, which will never be reused outside of that > overall driver. > > Hence why dw-* using components is rather uncool. > >>> I've typed up what I think should be the way forward a few times already, >>> but thus far not even the todo.rst entry materialized: >>> >>> https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ >>> >>> If everyone is always about "not in my patch series" it'll never happen. >> >> Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to implement >> vendor specific features, like : >> - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with >> platform specific values >> - platform specific mode validation >> - hpd setup => could use laurent's work here with no_connector, but how do >> we handle rxsense ??? >> - dsi timings/lane mbps ? these are platform phy specific >> >> For amlogic, I can split the "component" code handling venc/vclk into a >> primary bridge and add a >> secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, >> would that be a good start ? > > I think what we should do here: > > - type up todo.rst with the overall structure we want to aim for, i.e. > where is the code, who sets up what, how are the bridges bound into the > overall driver. OK, sure, this can be a good start, but first I would like all the other bridge maintainers & reviewers to agree on the the wanted structure. > > - demidlayer dw-* enough so that the callbacks are gone, and it becomes > more a toolbox/library for building a dw-* driver. Maybe we're there > already. This is not really wanted, otherwise we would duplicate a large amount of code over all the platform glues, is this really wanted ? Today, they already are a toolbox, with different levels of callback neded depending on how deep the integration is. > > - All new drivers then need to use the toolbox and have everything behind > a drm_bridge driver in drm/bridge/, with just default binding exposed to > drivers, no EXPORT_SYMBOL at all. Also no exported symbols used, this > should all be directly linked into the dw-*.ko imo and treated as > internals. In theory this is cool, in practice, this is impossible for meson_dw_hdmi, the first reason is how the
Re: [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory
Hi Christian and Thomas Am 16.09.20 um 15:37 schrieb Thomas Hellström (Intel): > > On 9/16/20 2:59 PM, Christian König wrote: >> Am 16.09.20 um 14:24 schrieb Daniel Vetter: >>> On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote: Hi Am 16.09.20 um 11:37 schrieb Daniel Vetter: > On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote: >> Dma-buf provides vmap() and vunmap() for retrieving and releasing >> mappings >> of dma-buf memory in kernel address space. The functions operate >> with plain >> addresses and the assumption is that the memory can be accessed >> with load >> and store operations. This is not the case on some architectures >> (e.g., >> sparc64) where I/O memory can only be accessed with dedicated >> instructions. >> >> This patchset introduces struct dma_buf_map, which contains the >> address of >> a buffer and a flag that tells whether system- or I/O-memory >> instructions >> are required. >> >> Some background: updating the DRM framebuffer console on sparc64 >> makes the >> kernel panic. This is because the framebuffer memory cannot be >> accessed with >> system-memory instructions. We currently employ a workaround in >> DRM to >> address this specific problem. [1] >> >> To resolve the problem, we'd like to address it at the most common >> point, >> which is the dma-buf framework. The dma-buf mapping ideally knows >> if I/O >> instructions are required and exports this information to it's >> users. The >> new structure struct dma_buf_map stores the buffer address and a >> flag that >> signals I/O memory. Affected users of the buffer (e.g., drivers, >> frameworks) >> can then access the memory accordingly. >> >> This patchset only introduces struct dma_buf_map, and updates >> struct dma_buf >> and it's interfaces. Further patches can update dma-buf users. For >> example, >> there's a prototype patchset for DRM that fixes the framebuffer >> problem. [2] >> >> Further work: TTM, one of DRM's memory managers, already exports an >> is_iomem flag of its own. It could later be switched over to >> exporting struct >> dma_buf_map, thus simplifying some code. Several DRM drivers >> expect their >> fbdev console to operate on I/O memory. These could possibly be >> switched over >> to the generic fbdev emulation, as soon as the generic code uses >> struct >> dma_buf_map. >> >> [1] >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2Fdata=02%7C01%7Cchristian.koenig%40amd.com%7C04e3cc3e03ae40f1fa0f08d85a3b6a68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637358558524732385sdata=wTmFuB95GhKUU%2F2Q91V0%2BtzAu4%2BEe3VBUcriBy3jx2g%3Dreserved=0 >> >> [2] >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200806085239.4606-1-tzimmermann%40suse.de%2Fdata=02%7C01%7Cchristian.koenig%40amd.com%7C04e3cc3e03ae40f1fa0f08d85a3b6a68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637358558524732385sdata=L4rBHmegO63b%2FiTQdTyH158KNxAZwSuJCQOaFszo5L0%3Dreserved=0 >> > lgtm, imo ready to convert the follow-up patches over to this. But > I think > would be good to get at least some ack from the ttm side for the > overall > plan. Yup, it would be nice if TTM could had out these types automatically. Then all TTM-based drivers would automatically support it. > Also, I think we should put all the various helpers (writel/readl, > memset, > memcpy, whatever else) into the dma-buf-map.h helper, so that most > code > using this can just treat it as an abstract pointer type and never > look > underneath it. We have some framebuffer helpers that rely on pointer arithmetic, so we'd need that too. No big deal wrt code, but I was worried about the overhead. If a loop goes over framebuffer memory, there's an if/else branch for each access to the memory buffer. >>> If we make all the helpers static inline, then the compiler should be >>> able >>> to see that dma_buf_map.is_iomem is always the same, and produced really >>> optimized code for it by pulling that check out from all the loops. >>> >>> So should only result in somewhat verbose code of having to call >>> dma_buf_map pointer arthimetic helpers, but not in bad generated code. >>> Still worth double-checking I think, since e.g. on x86 the generated >>> code >>> should be the same for both cases (but maybe the compiler doesn't see >>> through the inline asm to realize that, so we might end up with 2 >>> copies). >> >> Can we have that even independent of DMA-buf? We have essentially the >> same problem in TTM and the code around that is a complete mess if you >> ask me. >> >>
[v2 PATCH] dt-bindings: display: mediatek: convert the dpi bindings to yaml
Convert display/mediatek/mediatek,dpi.txt to display/mediatek/mediatek,dpi.yaml
and remove the old text bindings.
Signed-off-by: Jitao Shi
---
.../bindings/display/mediatek/mediatek,dpi.txt | 42 --
.../bindings/display/mediatek/mediatek,dpi.yaml| 97 ++
2 files changed, 97 insertions(+), 42 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
create mode 100644
Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
deleted file mode 100644
index 77def4456706..
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
+++ /dev/null
@@ -1,42 +0,0 @@
-Mediatek DPI Device
-===
-
-The Mediatek DPI function block is a sink of the display subsystem and
-provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
-output bus.
-
-Required properties:
-- compatible: "mediatek,-dpi"
- the supported chips are mt2701 , mt8173 and mt8183.
-- reg: Physical base address and length of the controller's registers
-- interrupts: The interrupt signal from the function block.
-- clocks: device clocks
- See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: must contain "pixel", "engine", and "pll"
-- port: Output port node with endpoint definitions as described in
- Documentation/devicetree/bindings/graph.txt. This port should be connected
- to the input port of an attached HDMI or LVDS encoder chip.
-
-Optional properties:
-- pinctrl-names: Contain "default" and "sleep".
-
-Example:
-
-dpi0: dpi@1401d000 {
- compatible = "mediatek,mt8173-dpi";
- reg = <0 0x1401d000 0 0x1000>;
- interrupts = ;
- clocks = < CLK_MM_DPI_PIXEL>,
-< CLK_MM_DPI_ENGINE>,
-< CLK_APMIXED_TVDPLL>;
- clock-names = "pixel", "engine", "pll";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <_pin_func>;
- pinctrl-1 = <_pin_idle>;
-
- port {
- dpi0_out: endpoint {
- remote-endpoint = <_in>;
- };
- };
-};
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
new file mode 100644
index ..4de08bc46fb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -0,0 +1,97 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: mediatek DPI Controller Device Tree Bindings
+
+maintainers:
+ - CK Hu
+ - Jitao shi
+
+description: |
+ The Mediatek DPI function block is a sink of the display subsystem and
+ provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel
+ output bus.
+
+properties:
+ compatible:
+enum:
+ - mediatek,mt2701-dpi
+ - mediatek,mt8173-dpi
+ - mediatek,mt8183-dpi
+
+ reg:
+maxItems: 1
+
+ interrupts:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Pixel Clock
+ - description: Engine Clock
+ - description: DPI PLL
+
+ clock-names:
+items:
+ - const: pixel
+ - const: engine
+ - const: pll
+
+ pinctrl-0: true
+ pinctrl-1: true
+
+ pinctrl-names:
+items:
+ - const: default
+ - const: sleep
+
+ port:
+type: object
+description:
+ Output port node with endpoint definitions as described in
+ Documentation/devicetree/bindings/graph.txt. This port should be
connected
+ to the input port of an attached HDMI or LVDS encoder chip.
+
+properties:
+ endpoint:
+type: object
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+#include
+#include
+dpi0: dpi@1401d000 {
+compatible = "mediatek,mt8173-dpi";
+reg = <0x1401d000 0x1000>;
+interrupts = ;
+clocks = < CLK_MM_DPI_PIXEL>,
+ < CLK_MM_DPI_ENGINE>,
+ < CLK_APMIXED_TVDPLL>;
+clock-names = "pixel", "engine", "pll";
+pinctrl-names = "default", "sleep";
+pinctrl-0 = <_pin_func>;
+pinctrl-1 = <_pin_idle>;
+
+port {
+dpi0_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+
+...
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/7] drm/ttm/drivers: call the bind function directly.
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
Now the bind functions have all the protection explicitly the
drivers can just call them directly, and the api can be unexported
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 5 -
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +-
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 2028b9e4c25c..a57aaf666340 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -63,6 +63,10 @@
#define AMDGPU_TTM_VRAM_MAX_DW_READ (size_t)128
+static int amdgpu_ttm_backend_bind(struct ttm_bo_device *bdev,
+ struct ttm_tt *ttm,
+ struct ttm_resource *bo_mem);
+
static int amdgpu_ttm_init_on_chip(struct amdgpu_device *adev,
unsigned int type,
uint64_t size)
@@ -552,7 +556,7 @@ static int amdgpu_move_vram_ram(struct ttm_buffer_object
*bo, bool evict,
goto out_cleanup;
/* Bind the memory to the GTT space */
- r = ttm_bo_tt_bind(bo, _mem);
+ r = amdgpu_ttm_backend_bind(bo->bdev, bo->ttm, _mem);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 4a020a3da3dd..56f974c28eb5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -44,6 +44,9 @@
#include
#include
+static int nouveau_ttm_tt_bind(struct ttm_bo_device *bdev, struct ttm_tt *ttm,
+ struct ttm_resource *reg);
+
/*
* NV10-NV40 tiling helpers
*/
@@ -927,7 +930,7 @@ nouveau_bo_move_flipd(struct ttm_buffer_object *bo, bool
evict, bool intr,
if (ret)
goto out;
- ret = ttm_bo_tt_bind(bo, _reg);
+ ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, _reg);
if (ret)
goto out;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c
index 03e5ae4e3bf6..99d9ca1087b7 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -56,6 +56,10 @@
static int radeon_ttm_debugfs_init(struct radeon_device *rdev);
static void radeon_ttm_debugfs_fini(struct radeon_device *rdev);
+static int radeon_ttm_tt_bind(struct ttm_bo_device *bdev,
+ struct ttm_tt *ttm,
+ struct ttm_resource *bo_mem);
+
struct radeon_device *radeon_get_rdev(struct ttm_bo_device *bdev)
{
struct radeon_mman *mman;
@@ -238,7 +242,7 @@ static int radeon_move_vram_ram(struct ttm_buffer_object
*bo,
goto out_cleanup;
}
- r = ttm_bo_tt_bind(bo, _mem);
+ r = radeon_ttm_tt_bind(bo->bdev, bo->ttm, _mem);
if (unlikely(r)) {
goto out_cleanup;
}
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2c527cd20dfa..279a0e44a5ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1628,7 +1628,6 @@ int ttm_bo_tt_bind(struct ttm_buffer_object *bo, struct
ttm_resource *mem)
{
return bo->bdev->driver->ttm_tt_bind(bo->bdev, bo->ttm, mem);
}
-EXPORT_SYMBOL(ttm_bo_tt_bind);
void ttm_bo_tt_unbind(struct ttm_buffer_object *bo)
{
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/ttm: add a simple assign mem to bo wrapper
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
This pattern is called in a few places, just clean it up.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 18 ++
include/drm/ttm/ttm_bo_driver.h | 10 --
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 919489f6a5a3..5a8d77ef504f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -87,9 +87,7 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
return ret;
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
-
+ ttm_bo_assign_mem(bo, new_mem);
return 0;
}
EXPORT_SYMBOL(ttm_bo_move_ttm);
@@ -299,8 +297,8 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
mb();
out2:
old_copy = *old_mem;
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+
+ ttm_bo_assign_mem(bo, new_mem);
if (!man->use_tt)
ttm_bo_tt_destroy(bo);
@@ -535,7 +533,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
- struct ttm_resource *old_mem = >mem;
int ret;
struct ttm_buffer_object *ghost_obj;
@@ -582,8 +579,7 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
ttm_bo_put(ghost_obj);
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+ ttm_bo_assign_mem(bo, new_mem);
return 0;
}
@@ -594,9 +590,8 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
struct ttm_resource *new_mem)
{
struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_resource *old_mem = >mem;
- struct ttm_resource_manager *from = ttm_manager_type(bdev, old_mem->mem_type);
+ struct ttm_resource_manager *from = ttm_manager_type(bdev,
bo->mem.mem_type);
struct ttm_resource_manager *to = ttm_manager_type(bdev,
new_mem->mem_type);
int ret;
@@ -673,8 +668,7 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
ttm_bo_free_old_node(bo);
}
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+ ttm_bo_assign_mem(bo, new_mem);
return 0;
}
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 7846dfa507f7..25cc932d63f1 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -539,6 +539,13 @@ static inline void ttm_bo_move_to_lru_tail_unlocked(struct
ttm_buffer_object *bo
spin_unlock(_bo_glob.lru_lock);
}
+static inline void ttm_bo_assign_mem(struct ttm_buffer_object *bo,
+struct ttm_resource *new_mem)
+{
+ bo->mem = *new_mem;
+ new_mem->mm_node = NULL;
+}
+
/**
* ttm_bo_move_null = assign memory for a buffer object.
* @bo: The bo to assign the memory to
@@ -552,8 +559,7 @@ static inline void ttm_bo_move_null(struct
ttm_buffer_object *bo,
struct ttm_resource *old_mem = >mem;
WARN_ON(old_mem->mm_node != NULL);
- *old_mem = *new_mem;
- new_mem->mm_node = NULL;
+ ttm_bo_assign_mem(bo, new_mem);
}
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1] powerplay:hwmgr - modify the return value
modify the return value is -EINVAL
Fixes: f83a9991648bb("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Fixes: 2cac05dee6e30("drm/amd/powerplay: add the hw manager for vega12 (v4)")
Cc: Eric Huang
Cc: Evan Quan
Signed-off-by: Xiaoliang Pang
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index c378a000c934..7eada3098ffc 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -4659,7 +4659,7 @@ static int
vega10_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
if ((data->water_marks_bitmap & WaterMarksExist) &&
!(data->water_marks_bitmap & WaterMarksLoaded)) {
result = smum_smc_table_manager(hwmgr, (uint8_t *)wm_table,
WMTABLE, false);
- PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
EINVAL);
+ PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
-EINVAL);
data->water_marks_bitmap |= WaterMarksLoaded;
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index a678a67f1c0d..04da52cea824 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -2390,7 +2390,7 @@ static int
vega12_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
!(data->water_marks_bitmap & WaterMarksLoaded)) {
result = smum_smc_table_manager(hwmgr,
(uint8_t *)wm_table,
TABLE_WATERMARKS, false);
- PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
EINVAL);
+ PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
-EINVAL);
data->water_marks_bitmap |= WaterMarksLoaded;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/aspeed: Add sysfs for output settings
On Wed, 16 Sep 2020, at 18:04, Joel Stanley wrote:
> These settings are used by an ASPEED BMC to determine when the host is
> trying to drive the display over PCIe (vga_pw) and to switch the
> output between PCIe and the internal graphics device (dac_mux).
>
> The valid values for the dac mux are:
>
> 00: VGA mode (default, aka PCIe)
> 01: Graphics CRT (aka BMC internal graphics, this driver)
> 10: Pass through mode from video input port A
> 11: Pass through mode from video input port B
>
> Values for the read-only vga password register are:
>
> 1: Host driving the display
> 0: Host not driving the display
>
> Signed-off-by: Joel Stanley
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 71 +
> 1 file changed, 71 insertions(+)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> index 903f4f304647..9e06a3683f8a 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -205,6 +205,69 @@ static const struct of_device_id
> aspeed_gfx_match[] = {
> { }
> };
>
> +#define ASPEED_SCU_VGA0 0x50
> +#define ASPEED_SCU_MISC_CTRL 0x2c
> +
> +static ssize_t dac_mux_store(struct device *dev, struct
> device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct aspeed_gfx *priv = dev_get_drvdata(dev);
> + u32 val;
> + int rc;
> +
> + rc = kstrtou32(buf, 0, );
> + if (rc)
> + return rc;
> +
> + if (val < 0 || val > 3)
val is unsigned so can't be less than zero.
Otherwise,
Reviewed-by: Andrew Jeffery
> + return -EINVAL;
> +
> + rc = regmap_update_bits(priv->scu, ASPEED_SCU_MISC_CTRL, 0x3, val
> << 16);
> + if (rc < 0)
> + return 0;
> +
> + return count;
> +}
> +
> +static ssize_t dac_mux_show(struct device *dev, struct
> device_attribute *attr, char *buf)
> +{
> + struct aspeed_gfx *priv = dev_get_drvdata(dev);
> + u32 reg;
> + int rc;
> +
> + rc = regmap_read(priv->scu, ASPEED_SCU_MISC_CTRL, );
> + if (rc)
> + return rc;
> +
> + return sprintf(buf, "%u\n", (reg >> 16) & 0x3);
> +}
> +static DEVICE_ATTR_RW(dac_mux);
> +
> +static ssize_t
> +vga_pw_show(struct device *dev, struct device_attribute *attr, char
> *buf)
> +{
> + struct aspeed_gfx *priv = dev_get_drvdata(dev);
> + u32 reg;
> + int rc;
> +
> + rc = regmap_read(priv->scu, ASPEED_SCU_VGA0, );
> + if (rc)
> + return rc;
> +
> + return sprintf(buf, "%u\n", reg & 1);
> +}
> +static DEVICE_ATTR_RO(vga_pw);
> +
> +static struct attribute *aspeed_sysfs_entries[] = {
> + _attr_vga_pw.attr,
> + _attr_dac_mux.attr,
> + NULL,
> +};
> +
> +static struct attribute_group aspeed_sysfs_attr_group = {
> + .attrs = aspeed_sysfs_entries,
> +};
> +
> static int aspeed_gfx_probe(struct platform_device *pdev)
> {
> struct aspeed_gfx *priv;
> @@ -219,6 +282,12 @@ static int aspeed_gfx_probe(struct platform_device
> *pdev)
> if (ret)
> return ret;
>
> + dev_set_drvdata(>dev, priv);
> +
> + ret = sysfs_create_group(>dev.kobj, _sysfs_attr_group);
> + if (ret)
> + return ret;
> +
> ret = drm_dev_register(>drm, 0);
> if (ret)
> goto err_unload;
> @@ -227,6 +296,7 @@ static int aspeed_gfx_probe(struct platform_device *pdev)
> return 0;
>
> err_unload:
> + sysfs_remove_group(>dev.kobj, _sysfs_attr_group);
> aspeed_gfx_unload(>drm);
>
> return ret;
> @@ -236,6 +306,7 @@ static int aspeed_gfx_remove(struct platform_device *pdev)
> {
> struct drm_device *drm = platform_get_drvdata(pdev);
>
> + sysfs_remove_group(>dev.kobj, _sysfs_attr_group);
> drm_dev_unregister(drm);
> aspeed_gfx_unload(drm);
>
> --
> 2.28.0
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [oss-drivers] [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is break;
>
> Found using:
>
> $ grep-2.5.4 -rP --include=*.[ch] -n
> "fallthrough;(\s*(case\s+\w+|default)\s*:\s*){1,7}break;" *
>
> Miscellanea:
>
> o Move or coalesce a couple label blocks above a default: block.
>
> Signed-off-by: Joe Perches
...
> diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> index 252fe06f58aa..1d5b87079104 100644
> --- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> +++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c
> @@ -345,7 +345,7 @@ static int matching_bar(struct nfp_bar *bar, u32 tgt, u32
> act, u32 tok,
> baract = NFP_CPP_ACTION_RW;
> if (act == 0)
> act = NFP_CPP_ACTION_RW;
> - fallthrough;
> + break;
> case NFP_PCIE_BAR_PCIE2CPP_MapType_FIXED:
> break;
> default:
This is a cascading fall-through handling all map types.
I don't think this change improves readability.
...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
On Mon, Sep 14, 2020 at 07:14:11PM +0900, Hoegeun Kwon wrote: > Hi Maxime, > > On 9/8/20 9:00 PM, Maxime Ripard wrote: > > Hi Hoegeun, > > > > On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote: > >> On 9/3/20 5:00 PM, Maxime Ripard wrote: > >>> Hi everyone, > >>> > >>> Here's a (pretty long) series to introduce support in the VC4 DRM driver > >>> for the display pipeline found in the BCM2711 (and thus the RaspberryPi > >>> 4). > >>> > >>> The main differences are that there's two HDMI controllers and that > >>> there's > >>> more pixelvalve now. Those pixelvalve come with a mux in the HVS that > >>> still > >>> have only 3 FIFOs. Both of those differences are breaking a bunch of > >>> expectations in the driver, so we first need a good bunch of cleanup and > >>> reworks to introduce support for the new controllers. > >>> > >>> Similarly, the HDMI controller has all its registers shuffled and split in > >>> multiple controllers now, so we need a bunch of changes to support this as > >>> well. > >>> > >>> Only the HDMI support is enabled for now (even though the DPI and DSI > >>> outputs have been tested too). > >>> > >>> Let me know if you have any comments > >>> Maxime > >>> > >>> Cc: bcm-kernel-feedback-l...@broadcom.com > >>> Cc: devicet...@vger.kernel.org > >>> Cc: Kamal Dasu > >>> Cc: Philipp Zabel > >>> Cc: Rob Herring > >>> Cc: Stephen Boyd > >>> > >>> Changes from v4: > >>> - Rebased on top of next-20200828 > >>> - Collected the various tags > >>> - Fixed some issues with 4k support and dual output (thanks Hoegeun!) > >> Thanks for your v5 patchset. > >> > >> I tested all patches based on the next-20200812. > > Thanks again for testing all the patches > > > >> Everything else is fine, but the dual hdmi modetest doesn't work well in my > >> environment... > >> > >> In my environment, dsi is not connected, I have seen your answer[1]. > > Can you share a bit more your setup? What monitors are being connected > > to each HDMI port? Do you hotplug any? > Yes, Monitors are being connected to each HDMI ports. (did not use hotplug) > > When booting, both HDMI-0 and 1 are recognized and the kernel log is output. > But after run modetest on HDMI-0(works) and modetest on HDMI-1(works), > crtc timed out occurs on HDMI-0 and does not work. > > When HDMI-0 is not working we do a modetest on HDMI-0, it will work agin > after about 40 sec. > > Below is the log for modetest. > > > root:~> modetest -Mvc4 -s 32:1280x720 - HDMI-0 works > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > failed to set gamma: Invalid argument > > root:~> modetest -Mvc4 -s 32:1280x720 - HDMI-0 works > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > failed to set gamma: Invalid argument > > root:~> modetest -Mvc4 -s 38:1280x720 - HDMI-1 works > setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69 > failed to set gamma: Invalid argument > > - Crtc timed out occurs on HDMI-0 and > does not work. > > [ 71.134283] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:64:crtc-3] flip_done timed out > [ 81.374296] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:64:crtc-3] flip_done timed out > [ 91.618380] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CONNECTOR:32:HDMI-A-1] flip_done timed out > [ 101.854274] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [PLANE:60:plane-3] flip_done timed out > > [ 112.094271] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:64:crtc-3] flip_done timed out > [ 122.590311] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:64:crtc-3] flip_done timed out > > root:~> modetest -Mvc4 -s 32:1280x720 > [ 132.830309] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CONNECTOR:32:HDMI-A-1] flip_done timed out > [ 143.070307] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [PLANE:60:plane-3] flip_done timed out > [ 153.310303] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:64:crtc-3] flip_done timed out > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64 > [ 163.550340] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:64:crtc-3] flip_done timed out > [ 173.790277] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CONNECTOR:32:HDMI-A-1] flip_done timed out > [ 184.030286] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [PLANE:60:plane-3] flip_done timed out > failed to set gamma: Invalid argument - HDMI-0 works Thanks :) I was able to reproduce it just by also letting X boot. I'm on a good path to fix it and found a workaround. I'll send you the patch in the upcoming days :) Thanks again, Maxime signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fix spelling error in comments
Change the comment typo: "manger" -> "manager". Signed-off-by: Wang Qing --- include/drm/drm_mm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h index a01bc6f..9b4292f --- a/include/drm/drm_mm.h +++ b/include/drm/drm_mm.h @@ -338,7 +338,7 @@ static inline u64 drm_mm_hole_node_end(const struct drm_mm_node *hole_node) /** * drm_mm_nodes - list of nodes under the drm_mm range manager - * @mm: the struct drm_mm range manger + * @mm: the struct drm_mm range manager * * As the drm_mm range manager hides its node_list deep with its * structure, extracting it looks painful and repetitive. This is -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Mon, Sep 14, 2020 at 11:55:24PM +0200, Thomas Gleixner wrote:
> But just look at any check which uses preemptible(), especially those
> which check !preemptible():
hmm.
+++ b/include/linux/preempt.h
@@ -180,7 +180,9 @@ do { \
#define preempt_enable_no_resched() sched_preempt_enable_no_resched()
+#ifndef MODULE
#define preemptible() (preempt_count() == 0 && !irqs_disabled())
+#endif
#ifdef CONFIG_PREEMPTION
#define preempt_enable() \
$ git grep -w preemptible drivers
(slightly trimmed by hand to remove, eg, comments)
drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
drivers/firmware/arm_sdei.c:WARN_ON_ONCE(preemptible());
drivers/firmware/arm_sdei.c:WARN_ON(preemptible());
drivers/firmware/efi/efi-pstore.c:preemptible(),
record->size, record->psi->buf);
drivers/irqchip/irq-gic-v4.c: WARN_ON(preemptible());
drivers/irqchip/irq-gic-v4.c: WARN_ON(preemptible());
drivers/scsi/hisi_sas/hisi_sas_main.c: if (!preemptible())
drivers/xen/time.c: BUG_ON(preemptible());
That only looks like two drivers that need more than WARNectomies.
Although maybe rcu_read_load_sched_held() or rcu_read_lock_any_held()
might get called from a module ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm: panfrost: Coherency support
> So I get a performance regression with the dma-coherent approach, even if it's > clearly the cleaner. That's bizarre -- this should really be the faster of the two. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 13/17] gpu: host1x: Reset max value when freeing a syncpoint
05.09.2020 13:34, Mikko Perttunen пишет:
> With job recovery becoming optional, syncpoints may have a mismatch
> between their value and max value when freed. As such, when freeing,
> set the max value to the current value of the syncpoint so that it
> is in a sane state for the next user.
>
> Signed-off-by: Mikko Perttunen
> ---
> drivers/gpu/host1x/syncpt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
> index 2fad8b2a55cc..82ecb4ac387e 100644
> --- a/drivers/gpu/host1x/syncpt.c
> +++ b/drivers/gpu/host1x/syncpt.c
> @@ -385,6 +385,7 @@ static void syncpt_release(struct kref *ref)
> {
> struct host1x_syncpt *sp = container_of(ref, struct host1x_syncpt, ref);
>
> + atomic_set(>max_val, host1x_syncpt_read_min(sp));
> sp->locked = false;
>
> mutex_lock(>host->syncpt_mutex);
>
Please note that the sync point state actually needs to be completely
reset at the sync point request-time because both downstream fastboot
and upstream u-boot [1] are needlessly enabling display VBLANK interrupt
that continuously increments sync point #26 during of kernel boot until
display controller is reset.
[1] https://github.com/u-boot/u-boot/blob/master/drivers/video/tegra.c#L155
Hence once sync point #26 is requested, it will have a dirty state. So
far this doesn't have any visible effect because sync points aren't used
much.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 13/17] gpu: host1x: Reset max value when freeing a syncpoint
16.09.2020 23:43, Mikko Perttunen пишет: ... >> Please note that the sync point state actually needs to be completely >> reset at the sync point request-time because both downstream fastboot >> and upstream u-boot [1] are needlessly enabling display VBLANK interrupt >> that continuously increments sync point #26 during of kernel boot until >> display controller is reset. >> >> [1] >> https://github.com/u-boot/u-boot/blob/master/drivers/video/tegra.c#L155 >> >> Hence once sync point #26 is requested, it will have a dirty state. So >> far this doesn't have any visible effect because sync points aren't used >> much. >> > > Maybe we can instead reserve syncpoints that might be used by the boot > chain, and only allow allocating them once the display driver has acked > that the syncpoint will no longer be incremented? That way if the > display driver is disabled for some reason we'll still be fine. sounds good > Looking at the downstream driver, it (still, on new chips..) reserves > the following syncpoints: > > - 10 (AVP) > - 22 (3D) > - 26 (VBLANK0) > - 27 (VBLANK1) > > and says that this applies to T20, T30, T114 and T148. > > I suppose if you haven't observed this happening to other syncpoints > than 26, then reserving 26 would probably be enough. I only saw SP 26 being used by the DC, but perhaps that may vary from device to device and SP 27 could actually be used in a wild as well. I think the AVP SP should only relate to the AVP-firmware that upstream doesn't support, so we can ignore its reservation. I've no idea what may use the 3D SP. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/tidss: use devm_platform_ioremap_resource_byname
Use the devm_platform_ioremap_resource_byname() helper instead of
calling platform_get_resource_byname() and devm_ioremap_resource()
separately.
Signed-off-by: Wang Xiaojun
---
drivers/gpu/drm/tidss/tidss_dispc.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index c3ece2c9d1c8..78f94a51a811 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -2605,16 +2605,9 @@ void dispc_remove(struct tidss_device *tidss)
static int dispc_iomap_resource(struct platform_device *pdev, const char *name,
void __iomem **base)
{
- struct resource *res;
void __iomem *b;
- res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name);
- if (!res) {
- dev_err(>dev, "cannot get mem resource '%s'\n", name);
- return -EINVAL;
- }
-
- b = devm_ioremap_resource(>dev, res);
+ b = devm_platform_ioremap_resource_byname(pdev, name);
if (IS_ERR(b)) {
dev_err(>dev, "cannot ioremap resource '%s'\n", name);
return PTR_ERR(b);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/21] Convert all remaining drivers to GEM object functions
Hi Am 15.09.20 um 17:25 schrieb Christian König: > Added my rb to the amdgpu and radeon patches. > > Should we pick those up through the amd branches or do you want to push > everything to drm-misc-next? > > I think the later since this should result in much merge clash. Yes, preferable, I'd merge it all through drm-misc. Best regards Thomas > > Christian. > > Am 15.09.20 um 16:59 schrieb Thomas Zimmermann: >> The GEM and PRIME related callbacks in struct drm_driver are >> deprecated in >> favor of GEM object functions in struct drm_gem_object_funcs. This >> patchset >> converts the remaining drivers to object functions and removes most of >> the >> obsolete interfaces. >> >> Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object >> functions, >> one by one. Each patch moves existing callbacks from struct drm_driver >> to an >> instance of struct drm_gem_object_funcs, and sets these funcs when the >> GEM >> object is initialized. The expection is .gem_prime_mmap. There are >> different >> ways of how drivers implement the callback, and moving it to GEM object >> functions requires a closer review for each. >> >> Patch #17 fixes virtgpu to use GEM object functions where possible. The >> driver recently introduced a function for one of the deprecated >> callbacks. >> >> Patch #20 converts xlnx to CMA helper macros. There's no apparent reason >> why the driver does the GEM setup on it's own. Using CMA helper macros >> adds GEM object functions implicitly. >> >> With most of the GEM and PRIME moved to GEM object functions, related >> code >> in struct drm_driver and in the DRM core/helpers is being removed by >> patch >> #21. >> >> Further testing is welcome. I tested the drivers for which I have HW >> available. These are gma500, i915, nouveau, radeon and vc4. The console, >> Weston and Xorg apparently work with the patches applied. >> >> v2: >> * moved code in amdgpu and radeon >> * made several functions static in various drivers >> * updated TODO-list item >> * fix virtgpu >> >> Thomas Zimmermann (21): >> drm/amdgpu: Introduce GEM object functions >> drm/armada: Introduce GEM object functions >> drm/etnaviv: Introduce GEM object functions >> drm/exynos: Introduce GEM object functions >> drm/gma500: Introduce GEM object functions >> drm/i915: Introduce GEM object functions >> drm/mediatek: Introduce GEM object functions >> drm/msm: Introduce GEM object funcs >> drm/nouveau: Introduce GEM object functions >> drm/omapdrm: Introduce GEM object functions >> drm/pl111: Introduce GEM object functions >> drm/radeon: Introduce GEM object functions >> drm/rockchip: Convert to drm_gem_object_funcs >> drm/tegra: Introduce GEM object functions >> drm/vc4: Introduce GEM object functions >> drm/vgem: Introduce GEM object functions >> drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs >> drm/vkms: Introduce GEM object functions >> drm/xen: Introduce GEM object functions >> drm/xlnx: Initialize DRM driver instance with CMA helper macro >> drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver >> >> Documentation/gpu/todo.rst | 7 +- >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 -- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 23 +++-- >> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 5 -- >> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 + >> drivers/gpu/drm/armada/armada_drv.c | 3 - >> drivers/gpu/drm/armada/armada_gem.c | 12 ++- >> drivers/gpu/drm/armada/armada_gem.h | 2 - >> drivers/gpu/drm/drm_gem.c | 35 ++-- >> drivers/gpu/drm/drm_gem_cma_helper.c | 6 +- >> drivers/gpu/drm/drm_prime.c | 17 ++-- >> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 --- >> drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - >> drivers/gpu/drm/etnaviv/etnaviv_gem.c | 19 - >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 --- >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 15 >> drivers/gpu/drm/gma500/framebuffer.c | 2 + >> drivers/gpu/drm/gma500/gem.c | 18 +++- >> drivers/gpu/drm/gma500/gem.h | 3 + >> drivers/gpu/drm/gma500/psb_drv.c | 9 -- >> drivers/gpu/drm/gma500/psb_drv.h | 2 - >> drivers/gpu/drm/i915/gem/i915_gem_object.c | 21 - >> drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 - >> drivers/gpu/drm/i915/i915_drv.c | 4 - >> .../gpu/drm/i915/selftests/mock_gem_device.c | 3 - >> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 5 -- >> drivers/gpu/drm/mediatek/mtk_drm_gem.c | 11 +++ >> drivers/gpu/drm/msm/msm_drv.c | 13 --- >> drivers/gpu/drm/msm/msm_drv.h | 1 - >> drivers/gpu/drm/msm/msm_gem.c | 19 - >> drivers/gpu/drm/nouveau/nouveau_drm.c
Re: [PATCH 0/3] dma-buf: Flag vmap'ed memory as system or I/O memory
Am 17.09.20 um 09:16 schrieb Thomas Zimmermann: Hi Christian and Thomas Am 16.09.20 um 15:37 schrieb Thomas Hellström (Intel): On 9/16/20 2:59 PM, Christian König wrote: Am 16.09.20 um 14:24 schrieb Daniel Vetter: On Wed, Sep 16, 2020 at 12:48:20PM +0200, Thomas Zimmermann wrote: Hi Am 16.09.20 um 11:37 schrieb Daniel Vetter: On Mon, Sep 14, 2020 at 01:25:18PM +0200, Thomas Zimmermann wrote: Dma-buf provides vmap() and vunmap() for retrieving and releasing mappings of dma-buf memory in kernel address space. The functions operate with plain addresses and the assumption is that the memory can be accessed with load and store operations. This is not the case on some architectures (e.g., sparc64) where I/O memory can only be accessed with dedicated instructions. This patchset introduces struct dma_buf_map, which contains the address of a buffer and a flag that tells whether system- or I/O-memory instructions are required. Some background: updating the DRM framebuffer console on sparc64 makes the kernel panic. This is because the framebuffer memory cannot be accessed with system-memory instructions. We currently employ a workaround in DRM to address this specific problem. [1] To resolve the problem, we'd like to address it at the most common point, which is the dma-buf framework. The dma-buf mapping ideally knows if I/O instructions are required and exports this information to it's users. The new structure struct dma_buf_map stores the buffer address and a flag that signals I/O memory. Affected users of the buffer (e.g., drivers, frameworks) can then access the memory accordingly. This patchset only introduces struct dma_buf_map, and updates struct dma_buf and it's interfaces. Further patches can update dma-buf users. For example, there's a prototype patchset for DRM that fixes the framebuffer problem. [2] Further work: TTM, one of DRM's memory managers, already exports an is_iomem flag of its own. It could later be switched over to exporting struct dma_buf_map, thus simplifying some code. Several DRM drivers expect their fbdev console to operate on I/O memory. These could possibly be switched over to the generic fbdev emulation, as soon as the generic code uses struct dma_buf_map. [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200725191012.GA434957%40ravnborg.org%2Fdata=02%7C01%7Cchristian.koenig%40amd.com%7C04e3cc3e03ae40f1fa0f08d85a3b6a68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637358558524732385sdata=wTmFuB95GhKUU%2F2Q91V0%2BtzAu4%2BEe3VBUcriBy3jx2g%3Dreserved=0 [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2F20200806085239.4606-1-tzimmermann%40suse.de%2Fdata=02%7C01%7Cchristian.koenig%40amd.com%7C04e3cc3e03ae40f1fa0f08d85a3b6a68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637358558524732385sdata=L4rBHmegO63b%2FiTQdTyH158KNxAZwSuJCQOaFszo5L0%3Dreserved=0 lgtm, imo ready to convert the follow-up patches over to this. But I think would be good to get at least some ack from the ttm side for the overall plan. Yup, it would be nice if TTM could had out these types automatically. Then all TTM-based drivers would automatically support it. Also, I think we should put all the various helpers (writel/readl, memset, memcpy, whatever else) into the dma-buf-map.h helper, so that most code using this can just treat it as an abstract pointer type and never look underneath it. We have some framebuffer helpers that rely on pointer arithmetic, so we'd need that too. No big deal wrt code, but I was worried about the overhead. If a loop goes over framebuffer memory, there's an if/else branch for each access to the memory buffer. If we make all the helpers static inline, then the compiler should be able to see that dma_buf_map.is_iomem is always the same, and produced really optimized code for it by pulling that check out from all the loops. So should only result in somewhat verbose code of having to call dma_buf_map pointer arthimetic helpers, but not in bad generated code. Still worth double-checking I think, since e.g. on x86 the generated code should be the same for both cases (but maybe the compiler doesn't see through the inline asm to realize that, so we might end up with 2 copies). Can we have that even independent of DMA-buf? We have essentially the same problem in TTM and the code around that is a complete mess if you ask me. Christian. I think this patchset looks good. Changing ttm_bo_kmap() over to returning a struct dma-buf-map would probably work just fine. If we then can have a set of helpers to operate on it, that's great. /Thomas Can I count this as an A-b by one of you? For the the general approach, certainly yes. Regards, Christian. Best regards Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___
Re: [PATCH 2/2] drm/ttm: drop evicted from ttm_bo.
Am 17.09.20 um 08:41 schrieb Dave Airlie:
From: Dave Airlie
This was unused.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4
include/drm/ttm/ttm_bo_api.h | 1 -
2 files changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 279a0e44a5ed..7562b0844c75 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -298,8 +298,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
}
moved:
- bo->evicted = false;
-
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
return 0;
@@ -638,9 +636,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
if (ret != -ERESTARTSYS)
pr_err("Buffer eviction failed\n");
ttm_resource_free(bo, _mem);
- goto out;
}
- bo->evicted = true;
out:
return ret;
}
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 36ff64e2736c..03b4761a3ea3 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -141,7 +141,6 @@ struct ttm_buffer_object {
struct ttm_resource mem;
struct file *persistent_swap_storage;
struct ttm_tt *ttm;
- bool evicted;
bool deleted;
/**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] powerplay:hwmgr - modify the return value
Am 17.09.20 um 05:46 schrieb Xiaoliang Pang:
modify the return value is -EINVAL
Maybe better write something like "The correct return value should be
-EINVAL." With that done feel free to add my acked-by.
Christian.
Fixes: f83a9991648bb("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Fixes: 2cac05dee6e30("drm/amd/powerplay: add the hw manager for vega12 (v4)")
Cc: Eric Huang
Cc: Evan Quan
Signed-off-by: Xiaoliang Pang
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index c378a000c934..7eada3098ffc 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -4659,7 +4659,7 @@ static int
vega10_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
if ((data->water_marks_bitmap & WaterMarksExist) &&
!(data->water_marks_bitmap & WaterMarksLoaded)) {
result = smum_smc_table_manager(hwmgr, (uint8_t *)wm_table,
WMTABLE, false);
- PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
EINVAL);
+ PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
-EINVAL);
data->water_marks_bitmap |= WaterMarksLoaded;
}
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
index a678a67f1c0d..04da52cea824 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c
@@ -2390,7 +2390,7 @@ static int
vega12_display_configuration_changed_task(struct pp_hwmgr *hwmgr)
!(data->water_marks_bitmap & WaterMarksLoaded)) {
result = smum_smc_table_manager(hwmgr,
(uint8_t *)wm_table,
TABLE_WATERMARKS, false);
- PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
EINVAL);
+ PP_ASSERT_WITH_CODE(result, "Failed to update WMTABLE!", return
-EINVAL);
data->water_marks_bitmap |= WaterMarksLoaded;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
Am 17.09.20 um 08:23 schrieb Daniel Vetter: On Wed, Sep 16, 2020 at 5:31 PM Christian König wrote: Am 16.09.20 um 17:24 schrieb Daniel Vetter: On Wed, Sep 16, 2020 at 4:14 PM Christian König wrote: Am 16.09.20 um 16:07 schrieb Jason Gunthorpe: On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: But within the driver, we generally need thousands of these, and that tends to bring fd exhaustion problems with it. That's why all the private buffer objects which aren't shared with other process or other drivers are handles only valid for a specific fd instance of the drm chardev (each open gets their own namespace), and only for ioctls done on that chardev. And for mmap we assign fake (but unique across all open fd on it) offsets within the overall chardev. Hence all the pgoff mangling and re-mangling. Are they still unique struct files? Just without a fdno? Yes, exactly. Not entirely, since dma-buf happened after drm chardev, so for that historical reason the underlying struct file is shared, since it's the drm chardev. But since that's per-device we don't have a problem in practice with different vm_ops, since those are also per-device. But yeah we could fish out some entirely hidden per-object struct file if that's required for some mm internal reasons. Hui? Ok that is just the handling in i915, isn't it? As far as I know we create an unique struct file for each DMA-buf. Yes dma-buf, but that gets forwarded to the original drm chardev which originally exported the buffer. It's only there where the forwarding chain stops. The other thing is that iirc we have a singleton anon_inode behind all the dma-buf, so they'd share all the same address_space and so would all alias for unmap_mapping_range (I think at least). Amdgpu works by using the address_space of the drm chardev into the struct file of DMA-buf instead. I think that this is cleaner, but only by a little bit :) Anyway I'm a bit concerned that we have so many different approaches for the same problem. Christian. -Daniel Regards, Christian. -Daniel Hence why we'd like to be able to forward aliasing mappings and adjust the file and pgoff, while hopefully everything keeps working. I thought this would work, but Christian noticed it doesn't really. It seems reasonable to me that the dma buf should be the owner of the VMA, otherwise like you say, there is a big mess attaching the custom vma ops and what not to the proper dma buf. I don't see anything obviously against this in mmap_region() - why did Chritian notice it doesn't really work? To clarify I think this might work. I just had the same "Is that legal?", "What about security?", etc.. questions you raised as well. It seems like a source of trouble so I thought better ask somebody more familiar with that. Christian. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cchristian.koenig%40amd.com%7Cf725d2eb6a5a49bd533f08d85ad23308%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637359206142262941sdata=qcLsl9R1gP%2FGY39ctsQkIzI99Bn%2F840YS17F4xudrAE%3Dreserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] drm/ttm: protect against reentrant bind in the drivers
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
This moves the generic tracking into the drivers and protects
against reentrancy in the drivers. It fixes up radeon and agp
to be able to query the bound status as that is required.
Signed-off-by: Dave Airlie
If would prefer splitting it up with one patch per driver, but of hand
that looks like it should work.
Patch is Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 5 +++-
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 8 +-
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 31 ++
drivers/gpu/drm/ttm/ttm_agp_backend.c | 14 ++
drivers/gpu/drm/ttm/ttm_bo.c | 20 ++
drivers/gpu/drm/ttm/ttm_bo_util.c | 5
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 22 ---
include/drm/ttm/ttm_bo_api.h | 1 -
include/drm/ttm/ttm_bo_driver.h| 14 --
include/drm/ttm/ttm_tt.h | 1 +
13 files changed, 91 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e86f8f6371c4..2851cf30091a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -813,6 +813,7 @@ struct amdgpu_ttm_tt {
uint64_tuserptr;
struct task_struct *usertask;
uint32_tuserflags;
+ boolbound;
#if IS_ENABLED(CONFIG_DRM_AMDGPU_USERPTR)
struct hmm_range*range;
#endif
@@ -1110,6 +,12 @@ static int amdgpu_ttm_backend_bind(struct ttm_bo_device
*bdev,
uint64_t flags;
int r = 0;
+ if (!bo_mem)
+ return -EINVAL;
+
+ if (gtt->bound)
+ return 0;
+
if (gtt->userptr) {
r = amdgpu_ttm_tt_pin_userptr(bdev, ttm);
if (r) {
@@ -1143,6 +1150,7 @@ static int amdgpu_ttm_backend_bind(struct ttm_bo_device
*bdev,
if (r)
DRM_ERROR("failed to bind %lu pages at 0x%08llX\n",
ttm->num_pages, gtt->offset);
+ gtt->bound = true;
return r;
}
@@ -1236,6 +1244,9 @@ static void amdgpu_ttm_backend_unbind(struct ttm_bo_device *bdev,
struct amdgpu_ttm_tt *gtt = (void *)ttm;
int r;
+ if (!gtt->bound)
+ return;
+
/* if the pages have userptr pinning then clear that first */
if (gtt->userptr)
amdgpu_ttm_tt_unpin_userptr(bdev, ttm);
@@ -1248,6 +1259,7 @@ static void amdgpu_ttm_backend_unbind(struct
ttm_bo_device *bdev,
if (r)
DRM_ERROR("failed to unbind %lu pages at 0x%08llX\n",
gtt->ttm.ttm.num_pages, gtt->offset);
+ gtt->bound = false;
}
static void amdgpu_ttm_backend_destroy(struct ttm_bo_device *bdev,
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index aea201d9c513..616d8844ba97 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -718,7 +718,10 @@ nouveau_ttm_tt_bind(struct ttm_bo_device *bdev, struct
ttm_tt *ttm,
{
#if IS_ENABLED(CONFIG_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
-
+#endif
+ if (!reg)
+ return -EINVAL;
+#if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge)
return ttm_agp_bind(ttm, reg);
#endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 05e542254e1f..21fb92770ea2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -33,6 +33,9 @@ nouveau_sgdma_bind(struct ttm_bo_device *bdev, struct ttm_tt
*ttm, struct ttm_re
struct nouveau_mem *mem = nouveau_mem(reg);
int ret;
+ if (nvbe->mem)
+ return 0;
+
ret = nouveau_mem_host(reg, >ttm);
if (ret)
return ret;
@@ -53,7 +56,10 @@ void
nouveau_sgdma_unbind(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
{
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
- nouveau_mem_fini(nvbe->mem);
+ if (nvbe->mem) {
+ nouveau_mem_fini(nvbe->mem);
+ nvbe->mem = NULL;
+ }
}
struct ttm_tt *
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index df6f0b49836b..a6d8de01194a 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2820,6 +2820,7 @@ extern int radeon_ttm_tt_set_userptr(struct radeon_device
*rdev,
uint32_t flags);
extern bool radeon_ttm_tt_has_userptr(struct radeon_device *rdev, struct
ttm_tt *ttm);
extern bool
Re: [PATCH 2/7] drm/ttm: flip tt destroy ordering.
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
Call the driver first and have it call the common code cleanup.
This is useful later to fix unbind.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 +
drivers/gpu/drm/drm_gem_vram_helper.c | 1 +
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c| 1 +
drivers/gpu/drm/qxl/qxl_ttm.c | 1 +
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +++
drivers/gpu/drm/ttm/ttm_tt.c | 7 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 1 +
include/drm/ttm/ttm_tt.h | 7 +++
9 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 2851cf30091a..dbe3f90a0cf6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1267,6 +1267,7 @@ static void amdgpu_ttm_backend_destroy(struct
ttm_bo_device *bdev,
{
struct amdgpu_ttm_tt *gtt = (void *)ttm;
+ ttm_tt_destroy_common(bdev, ttm);
if (gtt->usertask)
put_task_struct(gtt->usertask);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index f96321509d7e..50cad0e4a92e 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -922,6 +922,7 @@ static const struct drm_gem_object_funcs
drm_gem_vram_object_funcs = {
static void bo_driver_ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *tt)
{
+ ttm_tt_destroy_common(bdev, tt);
ttm_tt_fini(tt);
kfree(tt);
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 616d8844ba97..b239381498c3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1372,6 +1372,7 @@ nouveau_ttm_tt_destroy(struct ttm_bo_device *bdev,
#if IS_ENABLED(CONFIG_AGP)
struct nouveau_drm *drm = nouveau_bdev(bdev);
if (drm->agp.bridge) {
+ ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 21fb92770ea2..0dfaa6fb536e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -20,6 +20,7 @@ nouveau_sgdma_destroy(struct ttm_bo_device *bdev, struct
ttm_tt *ttm)
struct nouveau_sgdma_be *nvbe = (struct nouveau_sgdma_be *)ttm;
if (ttm) {
+ ttm_tt_destroy_common(bdev, ttm);
ttm_dma_tt_fini(>ttm);
kfree(nvbe);
}
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index bf3b091d0e2a..fd691fff8394 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -130,6 +130,7 @@ static void qxl_ttm_backend_destroy(struct ttm_bo_device
*bdev,
{
struct qxl_ttm_tt *gtt = (void *)ttm;
+ ttm_tt_destroy_common(bdev, ttm);
ttm_tt_fini(>ttm);
kfree(gtt);
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index fc8bbca28b34..76e24c6058ff 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -576,6 +576,8 @@ static void radeon_ttm_backend_destroy(struct ttm_bo_device
*bdev, struct ttm_tt
{
struct radeon_ttm_tt *gtt = (void *)ttm;
+ ttm_tt_destroy_common(bdev, ttm);
+
ttm_dma_tt_fini(>ttm);
kfree(gtt);
}
@@ -755,6 +757,7 @@ static void radeon_ttm_tt_destroy(struct ttm_bo_device
*bdev,
struct radeon_device *rdev = radeon_get_rdev(bdev);
if (rdev->flags & RADEON_IS_AGP) {
+ ttm_tt_destroy_common(bdev, ttm);
ttm_agp_destroy(ttm);
return;
}
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index a4f0296effac..f43fa69a1e65 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -207,7 +207,7 @@ int ttm_tt_set_placement_caching(struct ttm_tt *ttm,
uint32_t placement)
}
EXPORT_SYMBOL(ttm_tt_set_placement_caching);
-void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
+void ttm_tt_destroy_common(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
{
ttm_tt_unpopulate(bdev, ttm);
@@ -216,6 +216,11 @@ void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
fput(ttm->swap_storage);
ttm->swap_storage = NULL;
+}
+EXPORT_SYMBOL(ttm_tt_destroy_common);
+
+void ttm_tt_destroy(struct ttm_bo_device *bdev, struct ttm_tt *ttm)
+{
bdev->driver->ttm_tt_destroy(bdev, ttm);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index 01146b27c9a1..d46426164577 100644
---
Re: [PATCH 7/7] drm/ttm: make common function for wait/free node path.
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
The pipeline and accel cleansups has similiar paths here.
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 38 ---
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 3c16e303d2e2..502d334786d2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -526,6 +526,20 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+static int ttm_bo_wait_free_node(struct ttm_buffer_object *bo,
+bool dst_use_tt)
+{
+ int ret;
+ ret = ttm_bo_wait(bo, false, false);
+ if (ret)
+ return ret;
+
+ if (!dst_use_tt)
+ ttm_bo_tt_destroy(bo);
+ ttm_bo_free_old_node(bo);
+ return 0;
+}
+
static int ttm_bo_move_to_ghost(struct ttm_buffer_object *bo,
struct dma_fence *fence,
bool dst_use_tt)
@@ -577,19 +591,12 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object
*bo,
int ret;
dma_resv_add_excl_fence(bo->base.resv, fence);
- if (evict) {
- ret = ttm_bo_wait(bo, false, false);
- if (ret)
- return ret;
-
- if (!man->use_tt)
- ttm_bo_tt_destroy(bo);
- ttm_bo_free_old_node(bo);
- } else {
+ if (evict)
+ ret = ttm_bo_wait_free_node(bo, man->use_tt);
+ else
ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
- if (ret)
- return ret;
- }
+ if (ret)
+ return ret;
ttm_bo_assign_mem(bo, new_mem);
@@ -639,14 +646,9 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
*
* Should never happen in pratice.
*/
-
- ret = ttm_bo_wait(bo, false, false);
+ ret = ttm_bo_wait_free_node(bo, to->use_tt);
if (ret)
return ret;
-
- if (!to->use_tt)
- ttm_bo_tt_destroy(bo);
- ttm_bo_free_old_node(bo);
}
ttm_bo_assign_mem(bo, new_mem);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] drm/ttm: move ghost object creation to a common function
Am 17.09.20 um 06:30 schrieb Dave Airlie:
From: Dave Airlie
Both accel cleanup and pipeline move had the same code, make
a single function for it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 105 --
1 file changed, 43 insertions(+), 62 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 5a8d77ef504f..3c16e303d2e2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -526,6 +526,47 @@ void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map)
}
EXPORT_SYMBOL(ttm_bo_kunmap);
+static int ttm_bo_move_to_ghost(struct ttm_buffer_object *bo,
+ struct dma_fence *fence,
+ bool dst_use_tt)
+{
+ struct ttm_buffer_object *ghost_obj;
+ int ret;
+
+ /**
+* This should help pipeline ordinary buffer moves.
+*
+* Hang old buffer memory on a new buffer object,
+* and leave it to be released when the GPU
+* operation has completed.
+*/
+
+ dma_fence_put(bo->moving);
+ bo->moving = dma_fence_get(fence);
+
+ ret = ttm_buffer_object_transfer(bo, _obj);
+ if (ret)
+ return ret;
+
+ dma_resv_add_excl_fence(_obj->base._resv, fence);
+
+ /**
+* If we're not moving to fixed memory, the TTM object
+* needs to stay alive. Otherwhise hang it on the ghost
+* bo to be unbound and destroyed.
+*/
+
+ if (dst_use_tt) {
+ ghost_obj->ttm = NULL;
+ } else {
+ bo->ttm = NULL;
+ }
The {} can be dropped here, apart from that the patch is Reviewed-by:
Christian König
+
+ dma_resv_unlock(_obj->base._resv);
+ ttm_bo_put(ghost_obj);
+ return 0;
+}
+
int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
struct dma_fence *fence,
bool evict,
@@ -534,7 +575,6 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_resource_manager *man = ttm_manager_type(bdev,
new_mem->mem_type);
int ret;
- struct ttm_buffer_object *ghost_obj;
dma_resv_add_excl_fence(bo->base.resv, fence);
if (evict) {
@@ -546,37 +586,9 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
ttm_bo_tt_destroy(bo);
ttm_bo_free_old_node(bo);
} else {
- /**
-* This should help pipeline ordinary buffer moves.
-*
-* Hang old buffer memory on a new buffer object,
-* and leave it to be released when the GPU
-* operation has completed.
-*/
-
- dma_fence_put(bo->moving);
- bo->moving = dma_fence_get(fence);
-
- ret = ttm_buffer_object_transfer(bo, _obj);
+ ret = ttm_bo_move_to_ghost(bo, fence, man->use_tt);
if (ret)
return ret;
-
- dma_resv_add_excl_fence(_obj->base._resv, fence);
-
- /**
-* If we're not moving to fixed memory, the TTM object
-* needs to stay alive. Otherwhise hang it on the ghost
-* bo to be unbound and destroyed.
-*/
-
- if (man->use_tt) {
- ghost_obj->ttm = NULL;
- } else {
- bo->ttm = NULL;
- }
-
- dma_resv_unlock(_obj->base._resv);
- ttm_bo_put(ghost_obj);
}
ttm_bo_assign_mem(bo, new_mem);
@@ -599,40 +611,9 @@ int ttm_bo_pipeline_move(struct ttm_buffer_object *bo,
dma_resv_add_excl_fence(bo->base.resv, fence);
if (!evict) {
- struct ttm_buffer_object *ghost_obj;
-
- /**
-* This should help pipeline ordinary buffer moves.
-*
-* Hang old buffer memory on a new buffer object,
-* and leave it to be released when the GPU
-* operation has completed.
-*/
-
- dma_fence_put(bo->moving);
- bo->moving = dma_fence_get(fence);
-
- ret = ttm_buffer_object_transfer(bo, _obj);
+ ret = ttm_bo_move_to_ghost(bo, fence, to->use_tt);
if (ret)
return ret;
-
- dma_resv_add_excl_fence(_obj->base._resv, fence);
-
- /**
-* If we're not moving to fixed memory, the TTM object
-* needs to stay alive. Otherwhise hang it on the ghost
-* bo to be unbound and destroyed.
-*/
-
- if (to->use_tt) {
- ghost_obj->ttm = NULL;
- } else {
- bo->ttm = NULL;
-
Re: [PATCH] drm/ttm: some cleanups
Reviewed-by: Dave Airlie
On Wed, 16 Sep 2020 at 00:31, Christian König
wrote:
>
> Unexport ttm_check_under_lowerlimit.
> Make ttm_bo_acc_size static and unexport it.
> Remove ttm_get_kernel_zone_memory_size.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
> drivers/gpu/drm/ttm/ttm_memory.c | 7 ---
> include/drm/ttm/ttm_bo_api.h | 12
> include/drm/ttm/ttm_memory.h | 1 -
> 4 files changed, 3 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index ee2632128d3c..ffbdc20d8e8d 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1254,9 +1254,9 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
> }
> EXPORT_SYMBOL(ttm_bo_init);
>
> -size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> - unsigned long bo_size,
> - unsigned struct_size)
> +static size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> + unsigned long bo_size,
> + unsigned struct_size)
> {
> unsigned npages = (PAGE_ALIGN(bo_size)) >> PAGE_SHIFT;
> size_t size = 0;
> @@ -1266,7 +1266,6 @@ size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> size += ttm_round_pot(sizeof(struct ttm_tt));
> return size;
> }
> -EXPORT_SYMBOL(ttm_bo_acc_size);
>
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>unsigned long bo_size,
> diff --git a/drivers/gpu/drm/ttm/ttm_memory.c
> b/drivers/gpu/drm/ttm/ttm_memory.c
> index acd63b70d814..987aa32c4808 100644
> --- a/drivers/gpu/drm/ttm/ttm_memory.c
> +++ b/drivers/gpu/drm/ttm/ttm_memory.c
> @@ -554,7 +554,6 @@ ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
>
> return false;
> }
> -EXPORT_SYMBOL(ttm_check_under_lowerlimit);
>
> static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
> struct ttm_mem_zone *single_zone,
> @@ -682,9 +681,3 @@ size_t ttm_round_pot(size_t size)
> return 0;
> }
> EXPORT_SYMBOL(ttm_round_pot);
> -
> -uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob)
> -{
> - return glob->zone_kernel->max_mem;
> -}
> -EXPORT_SYMBOL(ttm_get_kernel_zone_memory_size);
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 36ff64e2736c..fd8d29f5f370 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -352,18 +352,6 @@ void ttm_bo_unlock_delayed_workqueue(struct
> ttm_bo_device *bdev, int resched);
> bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo,
> const struct ttm_place *place);
>
> -/**
> - * ttm_bo_acc_size
> - *
> - * @bdev: Pointer to a ttm_bo_device struct.
> - * @bo_size: size of the buffer object in byte.
> - * @struct_size: size of the structure holding buffer object datas
> - *
> - * Returns size to account for a buffer object
> - */
> -size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
> - unsigned long bo_size,
> - unsigned struct_size);
> size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
>unsigned long bo_size,
>unsigned struct_size);
> diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
> index c78ea99c42cf..2d468d7c94e6 100644
> --- a/include/drm/ttm/ttm_memory.h
> +++ b/include/drm/ttm/ttm_memory.h
> @@ -91,7 +91,6 @@ extern int ttm_mem_global_alloc_page(struct ttm_mem_global
> *glob,
> extern void ttm_mem_global_free_page(struct ttm_mem_global *glob,
> struct page *page, uint64_t size);
> extern size_t ttm_round_pot(size_t size);
> -extern uint64_t ttm_get_kernel_zone_memory_size(struct ttm_mem_global *glob);
> extern bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
> uint64_t num_pages, struct ttm_operation_ctx *ctx);
> #endif
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Wed, Sep 16, 2020 at 5:31 PM Christian König wrote: > > Am 16.09.20 um 17:24 schrieb Daniel Vetter: > > On Wed, Sep 16, 2020 at 4:14 PM Christian König > > wrote: > >> Am 16.09.20 um 16:07 schrieb Jason Gunthorpe: > >>> On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: > >>> > But within the driver, we generally need thousands of these, and that > tends to bring fd exhaustion problems with it. That's why all the private > buffer objects which aren't shared with other process or other drivers > are > handles only valid for a specific fd instance of the drm chardev (each > open gets their own namespace), and only for ioctls done on that chardev. > And for mmap we assign fake (but unique across all open fd on it) offsets > within the overall chardev. Hence all the pgoff mangling and re-mangling. > >>> Are they still unique struct files? Just without a fdno? > >> Yes, exactly. > > Not entirely, since dma-buf happened after drm chardev, so for that > > historical reason the underlying struct file is shared, since it's the > > drm chardev. But since that's per-device we don't have a problem in > > practice with different vm_ops, since those are also per-device. But > > yeah we could fish out some entirely hidden per-object struct file if > > that's required for some mm internal reasons. > > Hui? Ok that is just the handling in i915, isn't it? > > As far as I know we create an unique struct file for each DMA-buf. Yes dma-buf, but that gets forwarded to the original drm chardev which originally exported the buffer. It's only there where the forwarding chain stops. The other thing is that iirc we have a singleton anon_inode behind all the dma-buf, so they'd share all the same address_space and so would all alias for unmap_mapping_range (I think at least). -Daniel > > Regards, > Christian. > > > > -Daniel > > > Hence why we'd like to be able to forward aliasing mappings and adjust > the > file and pgoff, while hopefully everything keeps working. I thought this > would work, but Christian noticed it doesn't really. > >>> It seems reasonable to me that the dma buf should be the owner of the > >>> VMA, otherwise like you say, there is a big mess attaching the custom > >>> vma ops and what not to the proper dma buf. > >>> > >>> I don't see anything obviously against this in mmap_region() - why did > >>> Chritian notice it doesn't really work? > >> To clarify I think this might work. > >> > >> I just had the same "Is that legal?", "What about security?", etc.. > >> questions you raised as well. > >> > >> It seems like a source of trouble so I thought better ask somebody more > >> familiar with that. > >> > >> Christian. > >> > >>> Jason > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [patch 00/13] preempt: Make preempt count unconditional
On Wed, 16 Sep 2020 at 21:32, Linus Torvalds wrote: > > But something like a driver list walking thing should not be doing > different things behind peoples back depending on whether they hold > spinlocks or not. It should either just work regardless, or there > should be a flag (or special interface) for the "you're being called > in a crtitical region". > > Because dynamically changing behavior really is very confusing. > By the same reasoning, I don't think a generic crypto library should be playing tricks with preemption en/disabling under the hood when iterating over some data that is all directly accessible via the linear map on the platforms that most people care about. And using kmap_atomic() unconditionally achieves exactly that. As I argued before, the fact that kmap_atomic() can be called from an atomic context, and the fact that its implementation on HIGHMEM platforms requires preemption to be disabled until the next kunmap() are two different things, and I don't agree with your assertion that the name kmap_atomic() implies the latter semantics. If we can avoid disabling preemption on HIGHMEM, as Thomas suggests, we surely don't need it on !HIGHMEM either, and given that kmap_atomic() is preferred today anyway, we can just merge the two implementations. Are there any existing debug features that could help us spot [ab]use of things like raw per-CPU data within kmap_atomic regions? Re your point about deprecating HIGHMEM: some work is underway on ARM to implement a 3.75/3.75 GB kernel/user split on recent LPAE capable hardware (which shouldn't suffer from the performance issues that plagued the 4/4 split on i686), and so hopefully, there is a path forward for ARM that does not rely on HIGHMEM as it does today. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 13/17] gpu: host1x: Reset max value when freeing a syncpoint
On 9/17/20 12:37 AM, Dmitry Osipenko wrote: 16.09.2020 23:43, Mikko Perttunen пишет: ... Please note that the sync point state actually needs to be completely reset at the sync point request-time because both downstream fastboot and upstream u-boot [1] are needlessly enabling display VBLANK interrupt that continuously increments sync point #26 during of kernel boot until display controller is reset. [1] https://github.com/u-boot/u-boot/blob/master/drivers/video/tegra.c#L155 Hence once sync point #26 is requested, it will have a dirty state. So far this doesn't have any visible effect because sync points aren't used much. Maybe we can instead reserve syncpoints that might be used by the boot chain, and only allow allocating them once the display driver has acked that the syncpoint will no longer be incremented? That way if the display driver is disabled for some reason we'll still be fine. sounds good Looking at the downstream driver, it (still, on new chips..) reserves the following syncpoints: - 10 (AVP) - 22 (3D) - 26 (VBLANK0) - 27 (VBLANK1) and says that this applies to T20, T30, T114 and T148. I suppose if you haven't observed this happening to other syncpoints than 26, then reserving 26 would probably be enough. I only saw SP 26 being used by the DC, but perhaps that may vary from device to device and SP 27 could actually be used in a wild as well. I think the AVP SP should only relate to the AVP-firmware that upstream doesn't support, so we can ignore its reservation. I've no idea what may use the 3D SP. My guess is that some very old code used fixed syncpoint numbers so these were added to the reservation list. Let's reserve 26 and 27, that should be simple enough since both would be "released" by the display driver. Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 01/21] drm/amdgpu: Introduce GEM object functions
Hi
Am 15.09.20 um 17:05 schrieb Christian König:
> Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
>> GEM object functions deprecate several similar callback interfaces in
>> struct drm_driver. This patch replaces the per-driver callbacks with
>> per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
>> which is non-trivial to convert.
>>
>> v2:
>> * move object-function instance to amdgpu_gem.c (Christian)
>> * set callbacks in amdgpu_gem_object_create() (Christian)
>>
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 6 --
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 23 +-
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 5 -
>> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
>> 4 files changed, 19 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 6edde2b9e402..840ca8f9c1e1 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = {
>> .lastclose = amdgpu_driver_lastclose_kms,
>> .irq_handler = amdgpu_irq_handler,
>> .ioctls = amdgpu_ioctls_kms,
>> - .gem_free_object_unlocked = amdgpu_gem_object_free,
>> - .gem_open_object = amdgpu_gem_object_open,
>> - .gem_close_object = amdgpu_gem_object_close,
>> .dumb_create = amdgpu_mode_dumb_create,
>> .dumb_map_offset = amdgpu_mode_dumb_mmap,
>> .fops = _driver_kms_fops,
>> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
>> - .gem_prime_export = amdgpu_gem_prime_export,
>> .gem_prime_import = amdgpu_gem_prime_import,
>> - .gem_prime_vmap = amdgpu_gem_prime_vmap,
>> - .gem_prime_vunmap = amdgpu_gem_prime_vunmap,
>> .gem_prime_mmap = amdgpu_gem_prime_mmap,
>> .name = DRIVER_NAME,
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> index aa7f230c71bf..aeecd5dc3ce4 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
>> @@ -36,9 +36,12 @@
>> #include "amdgpu.h"
>> #include "amdgpu_display.h"
>> +#include "amdgpu_dma_buf.h"
>> #include "amdgpu_xgmi.h"
>> -void amdgpu_gem_object_free(struct drm_gem_object *gobj)
>> +static const struct drm_gem_object_funcs amdgpu_gem_object_funcs;
>> +
>> +static void amdgpu_gem_object_free(struct drm_gem_object *gobj)
>> {
>> struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj);
>> @@ -87,6 +90,7 @@ int amdgpu_gem_object_create(struct amdgpu_device
>> *adev, unsigned long size,
>> return r;
>> }
>> *obj = >tbo.base;
>> + (*obj)->funcs = _gem_object_funcs;
>> return 0;
>> }
>> @@ -119,8 +123,8 @@ void amdgpu_gem_force_release(struct amdgpu_device
>> *adev)
>> * Call from drm_gem_handle_create which appear in both new and open
>> ioctl
>> * case.
>> */
>> -int amdgpu_gem_object_open(struct drm_gem_object *obj,
>> - struct drm_file *file_priv)
>> +static int amdgpu_gem_object_open(struct drm_gem_object *obj,
>> + struct drm_file *file_priv)
>> {
>> struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
>> struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
>> @@ -152,8 +156,8 @@ int amdgpu_gem_object_open(struct drm_gem_object
>> *obj,
>> return 0;
>> }
>> -void amdgpu_gem_object_close(struct drm_gem_object *obj,
>> - struct drm_file *file_priv)
>> +static void amdgpu_gem_object_close(struct drm_gem_object *obj,
>> + struct drm_file *file_priv)
>> {
>> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
>> struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
>> @@ -211,6 +215,15 @@ void amdgpu_gem_object_close(struct
>> drm_gem_object *obj,
>> ttm_eu_backoff_reservation(, );
>> }
>> +static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = {
>> + .free = amdgpu_gem_object_free,
>> + .open = amdgpu_gem_object_open,
>> + .close = amdgpu_gem_object_close,
>> + .export = amdgpu_gem_prime_export,
>> + .vmap = amdgpu_gem_prime_vmap,
>> + .vunmap = amdgpu_gem_prime_vunmap,
>> +};
>> +
>> /*
>> * GEM ioctls.
>> */
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> index e0f025dd1b14..637bf51dbf06 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h
>> @@ -33,11 +33,6 @@
>> #define AMDGPU_GEM_DOMAIN_MAX 0x3
>> #define gem_to_amdgpu_bo(gobj) container_of((gobj), struct
>> amdgpu_bo, tbo.base)
>> -void amdgpu_gem_object_free(struct drm_gem_object *obj);
>> -int amdgpu_gem_object_open(struct drm_gem_object *obj,
>> - struct drm_file *file_priv);
>> -void
Re: [patch 00/13] preempt: Make preempt count unconditional
On Thu, Sep 17, 2020 at 12:39 AM Paul E. McKenney wrote: > > On Wed, Sep 16, 2020 at 11:43:02PM +0200, Daniel Vetter wrote: > > On Wed, Sep 16, 2020 at 10:58 PM Paul E. McKenney > > wrote: > > > > > > On Wed, Sep 16, 2020 at 10:29:06PM +0200, Daniel Vetter wrote: > > > > On Wed, Sep 16, 2020 at 5:29 PM Paul E. McKenney > > > > wrote: > > > > > > > > > > On Wed, Sep 16, 2020 at 09:37:17AM +0200, Daniel Vetter wrote: > > > > > > On Tue, Sep 15, 2020 at 7:35 PM Linus Torvalds > > > > > > wrote: > > > > > > > > > > > > > > On Tue, Sep 15, 2020 at 1:39 AM Thomas Gleixner > > > > > > > wrote: > > > > > > > > > > > > > > > > OTOH, having a working 'preemptible()' or maybe better named > > > > > > > > 'can_schedule()' check makes tons of sense to make decisions > > > > > > > > about > > > > > > > > allocation modes or other things. > > > > > > > > > > > > > > No. I think that those kinds of decisions about actual behavior > > > > > > > are > > > > > > > always simply fundamentally wrong. > > > > > > > > > > > > > > Note that this is very different from having warnings about > > > > > > > invalid > > > > > > > use. THAT is correct. It may not warn in all configurations, but > > > > > > > that > > > > > > > doesn't matter: what matters is that it warns in common enough > > > > > > > configurations that developers will catch it. > > > > > > > > > > > > > > So having a warning in "might_sleep()" that doesn't always > > > > > > > trigger, > > > > > > > because you have a limited configuration that can't even detect > > > > > > > the > > > > > > > situation, that's fine and dandy and intentional. > > > > > > > > > > > > > > But having code like > > > > > > > > > > > > > >if (can_schedule()) > > > > > > >.. do something different .. > > > > > > > > > > > > > > is fundamentally complete and utter garbage. > > > > > > > > > > > > > > It's one thing if you test for "am I in hardware interrupt > > > > > > > context". > > > > > > > Those tests aren't great either, but at least they make sense. > > > > > > > > > > > > > > But a driver - or some library routine - making a difference > > > > > > > based on > > > > > > > some nebulous "can I schedule" is fundamentally and basically > > > > > > > WRONG. > > > > > > > > > > > > > > If some code changes behavior, it needs to be explicit to the > > > > > > > *caller* > > > > > > > of that code. > > > > > > > > > > > > > > So this is why GFP_ATOMIC is fine, but "if (!can_schedule()) > > > > > > > do_something_atomic()" is pure shite. > > > > > > > > > > > > > > And I am not IN THE LEAST interested in trying to help people > > > > > > > doing > > > > > > > pure shite. We need to fix them. Like the crypto code is getting > > > > > > > fixed. > > > > > > > > > > > > Just figured I'll throw my +1 in from reading too many (gpu) > > > > > > drivers. > > > > > > Code that tries to cleverly adjust its behaviour depending upon the > > > > > > context it's running in is harder to understand and blows up in more > > > > > > interesting ways. We still have drm_can_sleep() and it's mostly just > > > > > > used for debug code, and I've largely ended up just deleting > > > > > > everything that used it because when you're driver is blowing up the > > > > > > last thing you want is to realize your debug code and output can't > > > > > > be > > > > > > relied upon. Or worse, that the only Oops you have is the one in the > > > > > > debug code, because the real one scrolled away - the original idea > > > > > > behind drm_can_sleep was to make all the modeset code work > > > > > > automagically both in normal ioctl/kworker context and in the panic > > > > > > handlers or kgdb callbacks. Wishful thinking at best. > > > > > > > > > > > > Also at least for me that extends to everything, e.g. I much prefer > > > > > > explicit spin_lock and spin_lock_irq vs magic spin_lock_irqsave for > > > > > > locks shared with interrupt handlers, since the former two gives me > > > > > > clear information from which contexts such function can be called. > > > > > > Other end is the memalloc_no*_save/restore functions, where I > > > > > > recently > > > > > > made a real big fool of myself because I didn't realize how much > > > > > > that > > > > > > impacts everything that's run within - suddenly "GFP_KERNEL for > > > > > > small > > > > > > stuff never fails" is wrong everywhere. > > > > > > > > > > > > It's all great for debugging and sanity checks (and we run with all > > > > > > that stuff enabled in our CI), but really semantic changes depending > > > > > > upon magic context checks freak my out :-) > > > > > > > > > > All fair, but some of us need to write code that must handle being > > > > > invoked from a wide variety of contexts. Now perhaps you like the > > > > > idea of > > > > > call_rcu() for schedulable contexts, call_rcu_nosched() when > > > > > preemption > > > > > is disabled, call_rcu_irqs_are_disabled() when interrupts are > > > > > disabled, > > > >
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 9:11 AM Christian König wrote: > > Am 17.09.20 um 08:23 schrieb Daniel Vetter: > > On Wed, Sep 16, 2020 at 5:31 PM Christian König > > wrote: > >> Am 16.09.20 um 17:24 schrieb Daniel Vetter: > >>> On Wed, Sep 16, 2020 at 4:14 PM Christian König > >>> wrote: > Am 16.09.20 um 16:07 schrieb Jason Gunthorpe: > > On Wed, Sep 16, 2020 at 11:53:59AM +0200, Daniel Vetter wrote: > > > >> But within the driver, we generally need thousands of these, and that > >> tends to bring fd exhaustion problems with it. That's why all the > >> private > >> buffer objects which aren't shared with other process or other drivers > >> are > >> handles only valid for a specific fd instance of the drm chardev (each > >> open gets their own namespace), and only for ioctls done on that > >> chardev. > >> And for mmap we assign fake (but unique across all open fd on it) > >> offsets > >> within the overall chardev. Hence all the pgoff mangling and > >> re-mangling. > > Are they still unique struct files? Just without a fdno? > Yes, exactly. > >>> Not entirely, since dma-buf happened after drm chardev, so for that > >>> historical reason the underlying struct file is shared, since it's the > >>> drm chardev. But since that's per-device we don't have a problem in > >>> practice with different vm_ops, since those are also per-device. But > >>> yeah we could fish out some entirely hidden per-object struct file if > >>> that's required for some mm internal reasons. > >> Hui? Ok that is just the handling in i915, isn't it? > >> > >> As far as I know we create an unique struct file for each DMA-buf. > > Yes dma-buf, but that gets forwarded to the original drm chardev which > > originally exported the buffer. It's only there where the forwarding > > chain stops. The other thing is that iirc we have a singleton > > anon_inode behind all the dma-buf, so they'd share all the same > > address_space and so would all alias for unmap_mapping_range (I think > > at least). > > Amdgpu works by using the address_space of the drm chardev into the > struct file of DMA-buf instead. > > I think that this is cleaner, but only by a little bit :) Yeah, but it doesn't work when forwarding from the drm chardev to the dma-buf on the importer side, since you'd need a ton of different address spaces. And you still rely on the core code picking up your pgoff mangling, which feels about as risky to me as the vma file pointer wrangling - if it's not consistently applied the reverse map is toast and unmap_mapping_range doesn't work correctly for our needs. > Anyway I'm a bit concerned that we have so many different approaches for > the same problem. Yeah, I think if we can standardize this then that would be really good. -Daniel > > Christian. > > > -Daniel > > > >> Regards, > >> Christian. > >> > >> > >>> -Daniel > >>> > >> Hence why we'd like to be able to forward aliasing mappings and adjust > >> the > >> file and pgoff, while hopefully everything keeps working. I thought > >> this > >> would work, but Christian noticed it doesn't really. > > It seems reasonable to me that the dma buf should be the owner of the > > VMA, otherwise like you say, there is a big mess attaching the custom > > vma ops and what not to the proper dma buf. > > > > I don't see anything obviously against this in mmap_region() - why did > > Chritian notice it doesn't really work? > To clarify I think this might work. > > I just had the same "Is that legal?", "What about security?", etc.. > questions you raised as well. > > It seems like a source of trouble so I thought better ask somebody more > familiar with that. > > Christian. > > > Jason > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cchristian.koenig%40amd.com%7Cf725d2eb6a5a49bd533f08d85ad23308%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637359206142262941sdata=qcLsl9R1gP%2FGY39ctsQkIzI99Bn%2F840YS17F4xudrAE%3Dreserved=0 > >>> > > > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] drm/panfrost: add Amlogic integration quirks
series r-b, nice! On Wed, Sep 16, 2020 at 05:01:44PM +0200, Neil Armstrong wrote: > The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, > G12A/SM1 & G12B > SoCs needs a quirk in the PWR registers at the GPU reset time. > > This serie adds the necessary quirks for the Amlogic integrated GPUs only. > > Changes since v1 at [1]: > - removed the BROKEN_SH quirk after [2] was sent by robin > - rebased on top of [3] by steven and moved the vendor quirk in the proper > quirk function > - added PWR_KEY unlock definition, and cleaned definition > > [1] https://lkml.kernel.org/r/20200908151853.4837-1-narmstr...@baylibre.com > [2] https://lkml.kernel.org/r/cover.1600213517.git.robin.mur...@arm.com > [3] https://lkml.kernel.org/r/20200909122957.51667-1-steven.pr...@arm.com > > Neil Armstrong (3): > drm/panfrost: add support for vendor quirk > drm/panfrost: add amlogic reset quirk callback > drm/panfrost: add Amlogic GPU integration quirks > > drivers/gpu/drm/panfrost/panfrost_device.h | 3 +++ > drivers/gpu/drm/panfrost/panfrost_drv.c| 11 +++ > drivers/gpu/drm/panfrost/panfrost_gpu.c| 15 +++ > drivers/gpu/drm/panfrost/panfrost_gpu.h| 2 ++ > drivers/gpu/drm/panfrost/panfrost_regs.h | 4 > 5 files changed, 35 insertions(+) > > -- > 2.22.0 > signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix incorrect TT->SYSTEM move handling
Am 16.09.20 um 21:27 schrieb Dave Airlie:
On Thu, 17 Sep 2020 at 00:24, Christian König
wrote:
When we move from the SYSTEM domain to the TT domain
we still need to potentially change the caching state.
This is most likely the source of a bunch of problems with
AGP and USWC together with hibernation and swap.
I'm going to need more commentary, because I've been staring at this
code a lot in the past few days and I'm although I dislike this path,
I'm not sure what this brings.
The current code flow to me is for SYSTEM->TT domain
ttm_tt_create
ttm_tt_set_placement_caching (new placement)
ttm_tt_bind (can cause populate)
move_notify
replace pointers
evicted = false
return
The new flow looks like
ttm_tt_create
ttm_tt_set_placement_caching (new placement)
ttm_tt_bind (can cause populate)
move_notify
(via ttm_bo_move_ttm)
ttm_tt_set_placement_caching (new placement)
ttm_tt_bind
replace pointers
(back to main code)
evicted = false
return
Is the second set placement caching doing something different here? or
is there something that happens in move notify that we need to set
things afterwards?
Oh, I was blind. Haven't seen the call to ttm_tt_set_placement_caching()
directly before this one.
So forget this one, need to keep searching why hibernation doesn't work :(
Christian.
Dave.
Signed-off-by: Christian König
CC: sta...@vger.kernel.org
---
drivers/gpu/drm/ttm/ttm_bo.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index ffbdc20d8e8d..5f7efc90970e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -264,13 +264,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
if (ret)
goto out_err;
}
-
- if (bo->mem.mem_type == TTM_PL_SYSTEM) {
- if (bdev->driver->move_notify)
- bdev->driver->move_notify(bo, evict, mem);
- bo->mem = *mem;
- goto moved;
- }
}
if (bdev->driver->move_notify)
@@ -293,7 +286,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
goto out_err;
}
-moved:
bo->evicted = false;
ctx->bytes_moved += bo->num_pages << PAGE_SHIFT;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave & Daniel - Due to the separate feature pull we haven't picked up gem fixes until now. Here's the first batch; there's potentially a few more to come [1]. I also just received a gvt fixes pull that didn't make it this week, so there are still more fixes coming. BR, Jani. [1] http://lore.kernel.org/r/87k0wuw1g3@intel.com drm-intel-fixes-2020-09-17: drm/i915 fixes for v5.9-rc6: - Avoid exposing a partially constructed context - Use RCU instead of mutex for context termination list iteration - Avoid data race reported by KCSAN - Filter wake_flags passed to default_wake_function The following changes since commit 856deb866d16e29bd65952e0289066f6078af773: Linux 5.9-rc5 (2020-09-13 16:06:00 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-09-17 for you to fetch changes up to 20612303a0b45de748d31331407e84300c38e497: drm/i915: Filter wake_flags passed to default_wake_function (2020-09-16 11:10:05 +0300) drm/i915 fixes for v5.9-rc6: - Avoid exposing a partially constructed context - Use RCU instead of mutex for context termination list iteration - Avoid data race reported by KCSAN - Filter wake_flags passed to default_wake_function Chris Wilson (4): drm/i915/gem: Delay tracking the GEM context until it is registered drm/i915/gem: Reduce context termination list iteration guard to RCU drm/i915: Be wary of data races when reading the active execlists drm/i915: Filter wake_flags passed to default_wake_function drivers/gpu/drm/i915/gem/i915_gem_context.c | 48 ++--- drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ++--- drivers/gpu/drm/i915/i915_request.c | 25 +-- drivers/gpu/drm/i915/i915_sw_fence.c| 10 -- 4 files changed, 71 insertions(+), 27 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> The Lyude fde7266fb2f6 change is actually based on Chromium change
> (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> Galaxy Chromebook. So currently we have 2 examples that use LSB
> interpretation and 1 that use MSB.
"If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
is cleared to 0, only the 8 MSB of the brightness control value can be
controlled.
(See Note below.)
Assigned bits are allocated to the MSB of the enabled register
combination."
I think that's pretty clear the assigned bits are supposed to be
msb aligned.
>
>
> On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
> >
> > Apologies for being too vague. To be as precise I can be, here is the
> > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > your other question, the code I tested against is indeed including the
> > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > message): our current top-of-tree for our 5.4 branch includes the
> > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > is exactly the change which breaks my Pixelbook model: prior to the
> > change, the max_brightness was hard-coded to 0x and the math
> > worked out that it didn't matter that the hardware cared about the MSB
> > despite the driver code caring about the LSB.
> >
> > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > need a quirk at least for some laptop. Reading through the copy of the
> > datasheet I have, it wasn't clear to me which was the correct
> > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > kernel code (caring about LSB) being the correct interpretation. I
> > believe we have other chromebooks which do rely on LSB functionality,
> > so unless we can find more examples of laptops wanting MSB it
> > currently looks like Pixelbook is the outlier.
> >
> > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > wrote:
> > >
> > > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > > We have observed that Google Pixelbook's backlight hardware is
> > > > interpretting these backlight bits from the most-significant side of the
> > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > assumes the peripheral cares about the least-significant bits.
> > > >
> > > > Testing was done from within Chrome OS's build environment when the
> > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > Pixelbook); for the record:
> > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > ./update_kernel.sh --remote=$IP
> > > >
> > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > > that the registers were being set according to what the actual hardware
> > > > expects; I also observe that the backlight is noticeably brighter with
> > > > this patch.
> > >
> > > It's unclear to me what kernel version this is against, and what you've
> > > actually tested.
> > >
> > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > DPCD aux max backlight calculations")?
> > >
> > > I just want to make sure you've tested with all the relevant fixes
> > > before adding quirks.
> > >
> > > BR,
> > > Jani.
> > >
> > > >
> > > > Signed-off-by: Kevin Chowski
> > > > ---
> > > >
> > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > 3 files changed, 48 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > index acbd7eb66cbe3..99c98f217356d 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > > > intel_connector *connector)
> > > > if (intel_dp->edp_dpcd[2] &
> > > > DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > > level = (read_val[0] << 8 | read_val[1]);
> > > >
> > > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > > + if (!drm_dp_dpcd_readb(_dp->aux,
> > > > DP_EDP_PWMGEN_BIT_COUNT,
> > > > + _val[0])) {
> > > > + DRM_DEBUG_KMS("Failed to read DPCD register
> > > > 0x%x\n",
> > > > + DP_EDP_PWMGEN_BIT_COUNT);
> > > > + return 0;
> > > > + }
> > > > + // Only bits 4:0 are used, 7:5 are
Re: [trivial PATCH] treewide: Convert switch/case fallthrough; to break;
On 9/9/2020 1:55 PM, Keith Busch wrote:
> On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
>> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
>> index eea0f453cfb6..8aac5bc60f4c 100644
>> --- a/crypto/tcrypt.c
>> +++ b/crypto/tcrypt.c
>> @@ -2464,7 +2464,7 @@ static int do_test(const char *alg, u32 type, u32
>> mask, int m, u32 num_mb)
>> test_hash_speed("streebog512", sec,
>> generic_hash_speed_template);
>> if (mode > 300 && mode < 400) break;
>> -fallthrough;
>> +break;
>> case 399:
>> break;
>
> Just imho, this change makes the preceding 'if' look even more
> pointless. Maybe the fallthrough was a deliberate choice? Not that my
> opinion matters here as I don't know this module, but it looked a bit
> odd to me.
>
Yea this does look very odd..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, Sep 17, 2020 at 09:25:35PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
>
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
>
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.
I guess there's some email issues happening, but just to clarify:
When the spec says MSB in caps here it clearly means
"most significant-bit(s)" since otherwise "8 MSB" would not make
any sense in the context of a 2 byte value.
Granted the spec is crap here since "Table 1-1: Acronyms and
Initialism" does claim "MSB" should be byte(s) and "msb" bit(s).
Also I can't imagine anyone would allocate the bits starting
from the lsb when the whole thing is clearly supposed to be a
16bit big endian integer. So with >8 assigned bits you'd end
up with crazy stuff like this:
[ 7 ... 0 ][7 ... 0]
[ 8 MSB ][][N LSB]
so you couldn't even treat the value as a regular big endian
thing. Instead, if you squint a bit, it now looks like a funky
little endian value. So we're deep into some mixed endian land
where nothing makes sense anymore.
Anyways I think the code should simply do this to match the spec:
u16 value = brightness << (16 - num_assigned_bits);
val[0] = value >> 8;
val[1] = value & 0xff;
>
> >
> >
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
> > >
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0x and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > >
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > >
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > wrote:
> > > >
> > > > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > >
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > ./update_kernel.sh --remote=$IP
> > > > >
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to
> > > > > verify
> > > > > that the registers were being set according to what the actual
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > >
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > >
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > >
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > >
> > > > > Signed-off-by: Kevin Chowski
> > > > > ---
> > > > >
> > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > +++
> > > > >
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 2020-09-17 at 21:25 +0300, Ville Syrjälä wrote:
> On Thu, Sep 17, 2020 at 11:14:43AM -0700, Puthikorn Voravootivat wrote:
> > The Lyude fde7266fb2f6 change is actually based on Chromium change
> > (https://crrev.com/c/1650325) that fixes the brightness for Samsung
> > Galaxy Chromebook. So currently we have 2 examples that use LSB
> > interpretation and 1 that use MSB.
>
> "If field 4:0 of the EDP_PWMGEN_BIT_COUNT register represents a value
> of greater than 8 and the BACKLIGHT_BRIGHTNESS_BYTE_COUNT bit
> is cleared to 0, only the 8 MSB of the brightness control value can be
> controlled.
> (See Note below.)
> Assigned bits are allocated to the MSB of the enabled register
> combination."
>
> I think that's pretty clear the assigned bits are supposed to be
> msb aligned.
Are we sure that isn't just referring to the DP_EDP_BACKLIGHT_BRIGHTNESS_MSB
register, as opposed to alignment of the whole value in that register? My
understanding of this was just that if there wasn't a pwmgen bit count
specified, that the backlight level would just be written to
DP_EDP_BACKLIGHT_BRIGHTNESS_MSB and DP_EDP_BACKLIGHT_BRIGHTNESS_LSB would be
ignored.
Hopefully I'm not misunderstanding Ville, but I don't think so since the current
code we have already follows the understanding I just gave:
vals[0] = level;
/* Write the MSB and/or LSB */
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT) {
vals[0] = (level & 0xFF00) >> 8;
vals[1] = (level & 0xFF);
}
(vals[0] == MSB)
>
> >
> > On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
> > > Apologies for being too vague. To be as precise I can be, here is the
> > > specific code delta I tested: https://crrev.com/c/2406616 . To answer
> > > your other question, the code I tested against is indeed including the
> > > fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> > > message): our current top-of-tree for our 5.4 branch includes the
> > > intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> > > is exactly the change which breaks my Pixelbook model: prior to the
> > > change, the max_brightness was hard-coded to 0x and the math
> > > worked out that it didn't matter that the hardware cared about the MSB
> > > despite the driver code caring about the LSB.
> > >
> > > To answer Ville's question: the fde7266fb2f6 change which fixes one
> > > laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> > > dug up) and breaks another (Pixelbook); so unfortunately I believe we
> > > need a quirk at least for some laptop. Reading through the copy of the
> > > datasheet I have, it wasn't clear to me which was the correct
> > > interpretation. I'm cc'ing puthik@, who was leaning toward the current
> > > kernel code (caring about LSB) being the correct interpretation. I
> > > believe we have other chromebooks which do rely on LSB functionality,
> > > so unless we can find more examples of laptops wanting MSB it
> > > currently looks like Pixelbook is the outlier.
> > >
> > > On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> > > wrote:
> > > > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > > > We have observed that Google Pixelbook's backlight hardware is
> > > > > interpretting these backlight bits from the most-significant side of
> > > > > the
> > > > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > > > assumes the peripheral cares about the least-significant bits.
> > > > >
> > > > > Testing was done from within Chrome OS's build environment when the
> > > > > patch is backported to 5.4 (the version we are newly targeting for the
> > > > > Pixelbook); for the record:
> > > > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > > > ./update_kernel.sh --remote=$IP
> > > > >
> > > > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to
> > > > > verify
> > > > > that the registers were being set according to what the actual
> > > > > hardware
> > > > > expects; I also observe that the backlight is noticeably brighter with
> > > > > this patch.
> > > >
> > > > It's unclear to me what kernel version this is against, and what you've
> > > > actually tested.
> > > >
> > > > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > > > DPCD aux max backlight calculations")?
> > > >
> > > > I just want to make sure you've tested with all the relevant fixes
> > > > before adding quirks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > > > Signed-off-by: Kevin Chowski
> > > > > ---
> > > > >
> > > > > .../drm/i915/display/intel_dp_aux_backlight.c | 34
> > > > > +++
> > > > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > > 3 files changed, 48 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > > >
Re: drm/ast something ate high-res modes (5.3->5.6 regression)
Hi, Yes, I can build custom kernels and test but I won't have time for that before the end of September so I'll do it only then. And thanks a lot :-). -- i. On Thu, 17 Sep 2020, Thomas Zimmermann wrote: > Hi > > Am 08.07.20 um 12:05 schrieb Ilpo Järvinen: > > Hi, > > > > After upgrading kernel from 5.3 series to 5.6.16 something seems to > > prevent me from achieving high resolutions with the ast driver. > > Are you able to build and run a test kernel? > > I'm seriously considering moving ast to the SHMEM memory manager, which > would restore the higher resolutions. > > If you're able to test, you need the git tree drm-tip/drm-tip and the > attached patch. > > Alternatively, I've pushed all to > > https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/ast-shmem > > You'd have to checkout the tree and switch to the ast-shmem branch. > > Please report back if that solves the issue for you. > > Best regards > Thomas > > > > > With 5.6.16: > > > > $ xrandr > > Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048 > > VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y > > axis) 519mm x 324mm > >1600x1200 60.00* > >1680x1050 59.95 > >1280x1024 75.0260.02 > >1440x900 59.89 > >1280x800 59.81 > >1024x768 75.0360.00 > >800x600 75.0060.32 > >640x480 75.0059.94 > >1920x1200_60.0 59.95 > > > > If I try to change to that manually added high-res mode, I get: > > xrandr: Configure crtc 0 failed > > > > With 5.3 series I've this: > > > > Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048 > > VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y > > axis) 519mm x 324mm > >1920x1200 59.95*+ > >1600x1200 60.00 > >1680x1050 59.95 > >1280x1024 75.0260.02 > >1440x900 59.89 > >1280x800 59.81 > >1024x768 75.0360.00 > >800x600 75.0060.32 > >640x480 75.0059.94 > >1920x1200_60.0 59.95 > > > > As I've had issues in getting EDID reliably from the monitor, I provide it > > on kernel command-line (the one dumped from the monitor I use). In > > addition, I've another workaround for past issues related to EDID which > > always adds that 1920x1200_60.0 mode but now I cannot use even it to > > enter a high-res mode. > > > > If you need some additional info or want me to test a patch, just let me > > know (but some delay is expected in testing patches). Thanks. > > > > > >___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
On Thu, 2020-09-17 at 11:31 -0600, Kevin Chowski wrote:
> Thanks very much for the quick reply, Lyude!
>
> I'm happy to make the requested changes, but I wanted to clarify before
> falling down the wrong hole: are you suggesting that I move
> the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
> the drm_dp_helper.c file?
You don't have to do that yet (although I wouldn't object either way), I was
just mostly implying using drm_dp_has_quirk()
> On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul wrote:
> > Just an FYI, my plan for some of this eDP backlight code is to move as much
> > of
> >
> > it into helpers as possible since we need to implement the same interface in
> >
> > nouveau. We probably can figure out some other solution for handling this
> > quirk
> >
> > if this isn't possible, but could we maybe use the panel's OUI here and add
> > a
> >
> > quirk to drm_dp_helper.c instead?
> >
> >
> >
> > On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> >
> > > We have observed that Google Pixelbook's backlight hardware is
> >
> > > interpretting these backlight bits from the most-significant side of the
> >
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> >
> > > assumes the peripheral cares about the least-significant bits.
> >
> > >
> >
> > > Testing was done from within Chrome OS's build environment when the
> >
> > > patch is backported to 5.4 (the version we are newly targeting for the
> >
> > > Pixelbook); for the record:
> >
> > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> >
> > > ./update_kernel.sh --remote=$IP
> >
> > >
> >
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> >
> > > that the registers were being set according to what the actual hardware
> >
> > > expects; I also observe that the backlight is noticeably brighter with
> >
> > > this patch.
> >
> > >
> >
> > > Signed-off-by: Kevin Chowski
> >
> > > ---
> >
> > >
> >
> > > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> >
> > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> >
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> >
> > > 3 files changed, 48 insertions(+)
> >
> > >
> >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > index acbd7eb66cbe3..99c98f217356d 100644
> >
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> >
> > > intel_connector *connector)
> >
> > > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> >
> > > level = (read_val[0] << 8 | read_val[1]);
> >
> > >
> >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> >
> > > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> >
> > > + _val[0])) {
> >
> > > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> >
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> >
> > > + return 0;
> >
> > > + }
> >
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> >
> > > + read_val[0] = read_val[0] & 0x1F;
> >
> > > + if (read_val[0] > 16) {
> >
> > > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> >
> > > expected at most 16\n",
> >
> > > + read_val[0]);
> >
> > > + return 0;
> >
> > > + }
> >
> > > + level >>= 16 - read_val[0];
> >
> > > + }
> >
> > > +
> >
> > > return level;
> >
> > > }
> >
> > >
> >
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> >
> > > drm_connector_state *conn_state, u32 lev
> >
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> >
> > > u8 vals[2] = { 0x0 };
> >
> > >
> >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> >
> > > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> >
> > > + [0])) {
> >
> > > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> >
> > > Failed to read DPCD register 0x%x\n",
> >
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> >
> > > + return;
> >
> > > + }
> >
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> >
> > > + vals[0] = vals[0] & 0x1F;
> >
> > > + if (vals[0] > 16) {
> >
> > > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> >
> > > Invalid DP_EDP_PWNGEN_BIT_COUNT
Re: [PATCH] fbcon: Remove the superfluous break
On 9/17/20 08:15, Jing Xiangfeng wrote:
> Remove the superfuous break, as there is a 'return' before it.
>
> Signed-off-by: Jing Xiangfeng
Reviewed-by: Gustavo A. R. Silva
Also, the following Fixes tag should be included in the changelog text:
Fixes: bad07ff74c32 ("fbcon: smart blitter usage for scrolling")
Thanks
--
Gustavo
> ---
> drivers/video/fbdev/core/fbcon.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 0b49b0f44edf..623359aadd1e 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1727,7 +1727,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> vc->vc_video_erase_char,
> vc->vc_size_row * count);
> return true;
> - break;
>
> case SCROLL_WRAP_MOVE:
> if (b - t - count > 3 * vc->vc_rows >> 2) {
> @@ -1818,7 +1817,6 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned
> int t, unsigned int b,
> vc->vc_video_erase_char,
> vc->vc_size_row * count);
> return true;
> - break;
>
> case SCROLL_WRAP_MOVE:
> if (b - t - count > 3 * vc->vc_rows >> 2) {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2] dt-bindings: dp-connector: add binding for DisplayPort connector
On Thu, Sep 17, 2020 at 03:39:38PM +0300, Tomi Valkeinen wrote: > On 17/09/2020 14:22, Ville Syrjälä wrote: > > On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: > >> Add binding for DisplayPort connector. A few notes: > >> > >> * Similar to hdmi-connector, it has hpd-gpios as an optional property, > >> as the HPD could also be handled by, e.g., the DP bridge. > >> > >> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it > >> is not strictly required: standard DP cables do not even have the pin > >> connected. > >> > >> * Connector type. Full size and mini connectors are identical except for > >> the connector size and form, so I believe there is no functional need > >> for this property. But similar to 'label' property, it might be used > >> to present information about the connector to the userspace. > >> > >> * No eDP. There's really no "eDP connector", as it's always a custom > >> made connection between the DP and the DP panel. So possibly there is > >> no need for edp-connector binding, but even if there is, I don't want > >> to guess what it could look like, and could it be part of the > >> dp-connector binding. > >> > >> * No DP++. I'm not familiar with DP++, but I think it's all handled by > >> the DP bridge, and does not need any new properties to the dp-connector. > > > > You might need an i2c bus for this. It's up to the source device > > to either hook up just AUX CH, or both AUX CH and DDC to a DP++ > > connector. If just AUX CH is wired up you are limited to using > > only type2 DP dual mode adapters, whereas if you also have DDC > > the crappier type1 adapters will also work. > > Ok, thanks for the clarifications on this. > > > I guess it's possible some bridges might handle all that for you. > > But eg. on i915 we always set up both AUX CH and DDC, and some > > extra circuitry on the board will isolate one or the other > > depending on what kind of dongle/cable gets plugged in > > (identified via the CONFIG pins). > > Is that automatic on i915? I could imagine a gpio-controlled mux doing the > isolation, and then we > need some driver controlling the gpio. Yeah, we don't even get the state of that pin in the driver. We just blindly probe both DDC and AUX CH. Due to the isolation only one goes through, the other other just times out. > > I could add the ddc bus the same way as on hdmi-connector.yaml, but perhaps > it's better to leave > that for someone with a DP++ board. Afaics, there should be no problems > adding this later. Another option might be to declare both dp and hdmi connectors for the same physical connector. That's the approach we use for drm_connectors in i915. But dunno if that's a good idea for dt. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
(resending as plain-text, my last mail was rejected by lots of
addresses for some reason)
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify
before falling down the wrong hole: are you suggesting that I move the
intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to the
drm_dp_helper.c file?
On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul wrote:
>
> Just an FYI, my plan for some of this eDP backlight code is to move as much of
> it into helpers as possible since we need to implement the same interface in
> nouveau. We probably can figure out some other solution for handling this
> quirk
> if this isn't possible, but could we maybe use the panel's OUI here and add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski
> > ---
> >
> > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + _val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> > return level;
> > }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + [0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + vals[0] = vals[0] & 0x1F;
> > + if (vals[0] > 16) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > + vals[0]);
> > + return;
> > + }
> > + level <<= (16 - vals[0]) & 0x;
> > + }
> > +
> > vals[0] = level;
> >
> > /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
> >
[PATCH] i915: Introduce quirk for shifting eDP brightness.
We have observed that Google Pixelbook's backlight hardware is
interpretting these backlight bits from the most-significant side of the
16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
assumes the peripheral cares about the least-significant bits.
Testing was done from within Chrome OS's build environment when the
patch is backported to 5.4 (the version we are newly targeting for the
Pixelbook); for the record:
$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
./update_kernel.sh --remote=$IP
I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
that the registers were being set according to what the actual hardware
expects; I also observe that the backlight is noticeably brighter with
this patch.
Signed-off-by: Kevin Chowski
---
.../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index acbd7eb66cbe3..99c98f217356d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector
*connector)
if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
level = (read_val[0] << 8 | read_val[1]);
+ if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+ if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+ _val[0])) {
+ DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+ DP_EDP_PWMGEN_BIT_COUNT);
+ return 0;
+ }
+ // Only bits 4:0 are used, 7:5 are reserved.
+ read_val[0] = read_val[0] & 0x1F;
+ if (read_val[0] > 16) {
+ DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
expected at most 16\n",
+ read_val[0]);
+ return 0;
+ }
+ level >>= 16 - read_val[0];
+ }
+
return level;
}
@@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
drm_connector_state *conn_state, u32 lev
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 vals[2] = { 0x0 };
+ if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
+ if (!drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+ [0])) {
+ DRM_DEBUG_KMS("Failed to write aux backlight level:
Failed to read DPCD register 0x%x\n",
+ DP_EDP_PWMGEN_BIT_COUNT);
+ return;
+ }
+ // Only bits 4:0 are used, 7:5 are reserved.
+ vals[0] = vals[0] & 0x1F;
+ if (vals[0] > 16) {
+ DRM_DEBUG_KMS("Failed to write aux backlight level:
Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
+ vals[0]);
+ return;
+ }
+ level <<= (16 - vals[0]) & 0x;
+ }
+
vals[0] = level;
/* Write the MSB and/or LSB */
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 46beb155d835f..63b27d49b2864 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
drm_i915_private *i915)
drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
}
+/*
+ * Some eDP backlight hardware uses the most-significant bits of the brightness
+ * register, so brightness values must be shifted first.
+ */
+static void quirk_shift_edp_backlight_brightness(struct drm_i915_private *i915)
+{
+ i915->quirks |= QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS;
+ DRM_INFO("Applying shift eDP backlight brightness quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -156,6 +166,9 @@ static struct intel_quirk intel_quirks[] = {
/* ASRock ITX*/
{ 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
{ 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time },
+
+ /* Google Pixelbook */
+ { 0x591E, 0x8086, 0x2212, quirk_shift_edp_backlight_brightness },
};
void intel_init_quirks(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4f7f6518945b..cc93bede4fab8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -525,6 +525,7 @@
[PATCH] dma-fence: add get_signaled_timestamp to fence ops
Add an optional fence ops to allow drivers to be able to set the
timestamp for a fence. Some drivers have hardware capability to get
the precise timestamp of certain events based on which the fences
are triggered. This allows it to set accurate timestamp factoring
out any software and IRQ latencies. The get_signaled_timestamp ops,
if defined by the driver would be used during fence signaling to set
the timestamp, before setting the flag DMA_FENCE_FLAG_TIMESTAMP_BIT.
If the callback is not defined, ktime_get is used to set the fence
timestamp.
Signed-off-by: Veera Sundaram Sankaran
---
drivers/dma-buf/dma-fence.c | 6 +-
include/linux/dma-fence.h | 13 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 43624b4..95c6ab0 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -4,6 +4,7 @@
*
* Copyright (C) 2012 Canonical Ltd
* Copyright (C) 2012 Texas Instruments
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
*
* Authors:
* Rob Clark
@@ -340,7 +341,10 @@ int dma_fence_signal_locked(struct dma_fence *fence)
/* Stash the cb_list before replacing it with the timestamp */
list_replace(>cb_list, _list);
- fence->timestamp = ktime_get();
+ if (fence->ops->get_signaled_timestamp)
+ fence->timestamp = fence->ops->get_signaled_timestamp(fence);
+ else
+ fence->timestamp = ktime_get();
set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, >flags);
trace_dma_fence_signaled(fence);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 09e23ad..ce73aba 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -4,6 +4,7 @@
*
* Copyright (C) 2012 Canonical Ltd
* Copyright (C) 2012 Texas Instruments
+ * Copyright (c) 2020 The Linux Foundation. All rights reserved.
*
* Authors:
* Rob Clark
@@ -261,6 +262,18 @@ struct dma_fence_ops {
*/
void (*timeline_value_str)(struct dma_fence *fence,
char *str, int size);
+
+ /**
+* @get_signaled_timestamp:
+*
+* Allows the driver to fill in precise timestamp for a fence.
+* This ops would be used during fence signalling to set the timestamp,
+* before setting the flag DMA_FENCE_FLAG_TIMESTAMP_BIT.
+*
+* This callback is optional. If this callback is not present,
+* ktime_get is used to fill in the timestamp.
+*/
+ ktime_t (*get_signaled_timestamp)(struct dma_fence *fence);
};
void dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 06:06:14PM +0200, Christian König wrote: > > > If it is already taking a page fault I'm not sure the extra function > > > call indirection is going to be a big deal. Having a uniform VMA > > > sounds saner than every driver custom rolling something. > > > > > > When I unwound a similar mess in RDMA all the custom VMA stuff in the > > > drivers turned out to be generally buggy, at least. > > > > > > Is vma->vm_file->private_data universally a dma_buf pointer at least? > > Nope. I think if you want this without some large scale rewrite of a > > lot of code we'd need a vmops->get_dmabuf or similar. Not pretty, but > > would get the job done. > > Yeah, agree that sounds like the simplest approach. I don't think that will fly, it is clearly only papering over a mess inside DRM/dma buf :\ Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 04:54:44PM +0200, Christian König wrote: > Am 17.09.20 um 16:35 schrieb Jason Gunthorpe: > > On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: > > > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: > > > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: > > > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: > > > > > > > > > > > > > Yeah, but it doesn't work when forwarding from the drm chardev to > > > > > > > the > > > > > > > dma-buf on the importer side, since you'd need a ton of different > > > > > > > address spaces. And you still rely on the core code picking up > > > > > > > your > > > > > > > pgoff mangling, which feels about as risky to me as the vma file > > > > > > > pointer wrangling - if it's not consistently applied the reverse > > > > > > > map > > > > > > > is toast and unmap_mapping_range doesn't work correctly for our > > > > > > > needs. > > > > > > I would think the pgoff has to be translated at the same time the > > > > > > vm->vm_file is changed? > > > > > > > > > > > > The owner of the dma_buf should have one virtual address space and > > > > > > FD, > > > > > > all its dma bufs should be linked to it, and all pgoffs translated > > > > > > to > > > > > > that space. > > > > > Yeah, that is exactly like amdgpu is doing it. > > > > > > > > > > Going to document that somehow when I'm done with TTM cleanups. > > > > BTW, while people are looking at this, is there a way to go from a VMA > > > > to a dma_buf that owns it? > > > Only a driver specific one. > > Sounds OK > > > > > For TTM drivers vma->vm_private_data points to the buffer object. Not sure > > > about the drivers using GEM only. > > Why are drivers in control of the vma? I would think dma_buf should be > > the vma owner. IIRC module lifetime correctness essentially hings on > > the module owner of the struct file > > Because the page fault handling is completely driver specific. > > We could install some DMA-buf vmops, but that would just be another layer of > redirection. If it is already taking a page fault I'm not sure the extra function call indirection is going to be a big deal. Having a uniform VMA sounds saner than every driver custom rolling something. When I unwound a similar mess in RDMA all the custom VMA stuff in the drivers turned out to be generally buggy, at least. Is vma->vm_file->private_data universally a dma_buf pointer at least? > > So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the > > memory it represents > > Ah, yes we are already doing this in amdgpu as well. But only for DMA-bufs > or more generally buffers which are mmaped by this driver instance. So there is no general dma_buf service? That is a real bummer Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 5.9-rc6
Hi Linus, A bunch of small fixes, some of the i915 ones have been out for a while and got better commit msg explaining some better reasoning behind them. (hopefully this trend continues). Otherwise there a few AMD related ones mostly small, one radeon PLL regression fix and a bunch of small mediatek fixes. I'm going to be offline for a couple of days in a few hours time, so if anything is wrong let Daniel know as well. Dave. drm-fixes-2020-09-18: drm fixes for 5.9-rc6 amdgpu: - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes amdkfd: - Fix a GPU reset crash - Fix a memory leak radeon: - Revert a PLL fix that broke other boards i915: - Avoid exposing a partially constructed context - Use RCU instead of mutex for context termination list iteration - Avoid data race reported by KCSAN - Filter wake_flags passed to default_wake_function mediatek: - Fix scrolling of panel - Remove duplicated include - Use CPU when fail to get cmdq event - Add missing put_device() call The following changes since commit 856deb866d16e29bd65952e0289066f6078af773: Linux 5.9-rc5 (2020-09-13 16:06:00 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-09-18 for you to fetch changes up to 1f08fde70075784d28d1687d0e75871e81cc1173: Merge tag 'mediatek-drm-fixes-5.9' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes (2020-09-18 08:52:06 +1000) drm fixes for 5.9-rc6 amdgpu: - Sienna Cichlid fixes - Navy Flounder fixes - DC fixes amdkfd: - Fix a GPU reset crash - Fix a memory leak radeon: - Revert a PLL fix that broke other boards i915: - Avoid exposing a partially constructed context - Use RCU instead of mutex for context termination list iteration - Avoid data race reported by KCSAN - Filter wake_flags passed to default_wake_function mediatek: - Fix scrolling of panel - Remove duplicated include - Use CPU when fail to get cmdq event - Add missing put_device() call Andrey Grodzovsky (1): drm/amdgpu: Include sienna_cichlid in USBC PD FW support. Bhawanpreet Lakha (2): drm/amd/display: Don't use DRM_ERROR() for DTM add topology drm/amd/display: Don't log hdcp module warnings in dmesg Chris Wilson (4): drm/i915/gem: Delay tracking the GEM context until it is registered drm/i915/gem: Reduce context termination list iteration guard to RCU drm/i915: Be wary of data races when reading the active execlists drm/i915: Filter wake_flags passed to default_wake_function Christian König (1): drm/radeon: revert "Prefer lower feedback dividers" Chun-Kuang Hu (1): drm/mediatek: Use CPU when fail to get cmdq event Dave Airlie (3): Merge tag 'amd-drm-fixes-5.9-2020-09-17' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Merge tag 'drm-intel-fixes-2020-09-17' of ssh://git.freedesktop.org/git/drm/drm-intel into drm-fixes Merge tag 'mediatek-drm-fixes-5.9' of https://git.kernel.org/.../chunkuang.hu/linux into drm-fixes Dennis Li (2): drm/kfd: fix a system crash issue during GPU recovery drm/amdkfd: fix a memory leak issue Jiansong Chen (2): drm/amd/pm: support runtime pptable update for sienna_cichlid etc. drm/amdgpu: declare ta firmware for navy_flounder Jitao Shi (1): drm/mediatek: dsi: Fix scrolling of panel with small hfp or hbp Jun Lei (1): drm/amd/display: update nv1x stutter latencies Michel Dänzer (1): drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is Wang Hai (1): drm/mediatek: Remove duplicated include Yu Kuai (4): drm/mediatek: Add missing put_device() call in mtk_ddp_comp_init() drm/mediatek: Add exception handing in mtk_drm_probe() if component init fail drm/mediatek: Add missing put_device() call in mtk_drm_kms_init() drm/mediatek: Add missing put_device() call in mtk_hdmi_dt_parse_pdata() drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c| 2 +- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 2 +- .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 4 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +-- .../gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 4 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_log.h| 2 +- .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c| 2 +- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 12 -- drivers/gpu/drm/i915/gem/i915_gem_context.c| 48 ++ drivers/gpu/drm/i915/gt/intel_lrc.c| 15 +-- drivers/gpu/drm/i915/i915_request.c| 25 ++- drivers/gpu/drm/i915/i915_sw_fence.c | 10 +++-- drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 20 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
On Thu, Sep 17, 2020 at 02:24:29PM +0200, Christian König wrote: > Am 17.09.20 um 14:18 schrieb Jason Gunthorpe: > > On Thu, Sep 17, 2020 at 02:03:48PM +0200, Christian König wrote: > > > Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: > > > > On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: > > > > > > > > > Yeah, but it doesn't work when forwarding from the drm chardev to the > > > > > dma-buf on the importer side, since you'd need a ton of different > > > > > address spaces. And you still rely on the core code picking up your > > > > > pgoff mangling, which feels about as risky to me as the vma file > > > > > pointer wrangling - if it's not consistently applied the reverse map > > > > > is toast and unmap_mapping_range doesn't work correctly for our needs. > > > > I would think the pgoff has to be translated at the same time the > > > > vm->vm_file is changed? > > > > > > > > The owner of the dma_buf should have one virtual address space and FD, > > > > all its dma bufs should be linked to it, and all pgoffs translated to > > > > that space. > > > Yeah, that is exactly like amdgpu is doing it. > > > > > > Going to document that somehow when I'm done with TTM cleanups. > > BTW, while people are looking at this, is there a way to go from a VMA > > to a dma_buf that owns it? > > Only a driver specific one. Sounds OK > For TTM drivers vma->vm_private_data points to the buffer object. Not sure > about the drivers using GEM only. Why are drivers in control of the vma? I would think dma_buf should be the vma owner. IIRC module lifetime correctness essentially hings on the module owner of the struct file > Why are you asking? I'm thinking about using find_vma on something that is not get_user_pages()'able to go to the underlying object, in this case dma buf. So, user VA -> find_vma -> dma_buf object -> dma_buf operations on the memory it represents Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
The Lyude fde7266fb2f6 change is actually based on Chromium change
(https://crrev.com/c/1650325) that fixes the brightness for Samsung
Galaxy Chromebook. So currently we have 2 examples that use LSB
interpretation and 1 that use MSB.
On Thu, Sep 17, 2020 at 10:55 AM Kevin Chowski wrote:
>
> Apologies for being too vague. To be as precise I can be, here is the
> specific code delta I tested: https://crrev.com/c/2406616 . To answer
> your other question, the code I tested against is indeed including the
> fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
> message): our current top-of-tree for our 5.4 branch includes the
> intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
> is exactly the change which breaks my Pixelbook model: prior to the
> change, the max_brightness was hard-coded to 0x and the math
> worked out that it didn't matter that the hardware cared about the MSB
> despite the driver code caring about the LSB.
>
> To answer Ville's question: the fde7266fb2f6 change which fixes one
> laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
> dug up) and breaks another (Pixelbook); so unfortunately I believe we
> need a quirk at least for some laptop. Reading through the copy of the
> datasheet I have, it wasn't clear to me which was the correct
> interpretation. I'm cc'ing puthik@, who was leaning toward the current
> kernel code (caring about LSB) being the correct interpretation. I
> believe we have other chromebooks which do rely on LSB functionality,
> so unless we can find more examples of laptops wanting MSB it
> currently looks like Pixelbook is the outlier.
>
> On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
> wrote:
> >
> > On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > > We have observed that Google Pixelbook's backlight hardware is
> > > interpretting these backlight bits from the most-significant side of the
> > > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > > assumes the peripheral cares about the least-significant bits.
> > >
> > > Testing was done from within Chrome OS's build environment when the
> > > patch is backported to 5.4 (the version we are newly targeting for the
> > > Pixelbook); for the record:
> > >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > > ./update_kernel.sh --remote=$IP
> > >
> > > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > > that the registers were being set according to what the actual hardware
> > > expects; I also observe that the backlight is noticeably brighter with
> > > this patch.
> >
> > It's unclear to me what kernel version this is against, and what you've
> > actually tested.
> >
> > Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> > DPCD aux max backlight calculations")?
> >
> > I just want to make sure you've tested with all the relevant fixes
> > before adding quirks.
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Kevin Chowski
> > > ---
> > >
> > > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > 3 files changed, 48 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > index acbd7eb66cbe3..99c98f217356d 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > > intel_connector *connector)
> > > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > > level = (read_val[0] << 8 | read_val[1]);
> > >
> > > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > > + if (!drm_dp_dpcd_readb(_dp->aux,
> > > DP_EDP_PWMGEN_BIT_COUNT,
> > > + _val[0])) {
> > > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > > + DP_EDP_PWMGEN_BIT_COUNT);
> > > + return 0;
> > > + }
> > > + // Only bits 4:0 are used, 7:5 are reserved.
> > > + read_val[0] = read_val[0] & 0x1F;
> > > + if (read_val[0] > 16) {
> > > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT
> > > 0x%X, expected at most 16\n",
> > > + read_val[0]);
> > > + return 0;
> > > + }
> > > + level >>= 16 - read_val[0];
> > > + }
> > > +
> > > return level;
> > > }
> > >
> > > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > > drm_connector_state *conn_state, u32 lev
> > > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > > u8 vals[2] = {
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
Thanks very much for the quick reply, Lyude!
I'm happy to make the requested changes, but I wanted to clarify before
falling down the wrong hole: are you suggesting that I move
the intel_dp_aux_set_backlight/intel_dp_aux_get_backlight routines to
the drm_dp_helper.c file?
On Thu, Sep 17, 2020 at 11:13 AM Lyude Paul wrote:
> Just an FYI, my plan for some of this eDP backlight code is to move as
> much of
> it into helpers as possible since we need to implement the same interface
> in
> nouveau. We probably can figure out some other solution for handling this
> quirk
> if this isn't possible, but could we maybe use the panel's OUI here and
> add a
> quirk to drm_dp_helper.c instead?
>
> On Thu, 2020-09-17 at 11:09 -0600, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
> >
> > Signed-off-by: Kevin Chowski
> > ---
> >
> > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_PWMGEN_BIT_COUNT,
> > + _val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register
> 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT
> 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> > return level;
> > }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_PWMGEN_BIT_COUNT,
> > + [0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + vals[0] = vals[0] & 0x1F;
> > + if (vals[0] > 16) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X, expected at most 16\n",
> > + vals[0]);
> > + return;
> > + }
> > + level <<= (16 - vals[0]) & 0x;
> > + }
> > +
> > vals[0] = level;
> >
> > /* Write the MSB and/or LSB */
> > diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> > b/drivers/gpu/drm/i915/display/intel_quirks.c
> > index 46beb155d835f..63b27d49b2864 100644
> > --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> > +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> > @@ -53,6 +53,16 @@ static void quirk_increase_ddi_disabled_time(struct
> > drm_i915_private *i915)
> > drm_info(>drm, "Applying Increase DDI Disabled quirk\n");
> > }
> >
> > +/*
> > + * Some eDP
Re: [PATCH] i915: Introduce quirk for shifting eDP brightness.
Apologies for being too vague. To be as precise I can be, here is the
specific code delta I tested: https://crrev.com/c/2406616 . To answer
your other question, the code I tested against is indeed including the
fde7266fb2f6 (despite ostensibly being called 5.4 in my commit
message): our current top-of-tree for our 5.4 branch includes the
intel_dp_aux_calc_max_backlight logic. Further, I'll note that change
is exactly the change which breaks my Pixelbook model: prior to the
change, the max_brightness was hard-coded to 0x and the math
worked out that it didn't matter that the hardware cared about the MSB
despite the driver code caring about the LSB.
To answer Ville's question: the fde7266fb2f6 change which fixes one
laptop (I believe Thinkpad X1 extreme Gen 2, from some bug reports I
dug up) and breaks another (Pixelbook); so unfortunately I believe we
need a quirk at least for some laptop. Reading through the copy of the
datasheet I have, it wasn't clear to me which was the correct
interpretation. I'm cc'ing puthik@, who was leaning toward the current
kernel code (caring about LSB) being the correct interpretation. I
believe we have other chromebooks which do rely on LSB functionality,
so unless we can find more examples of laptops wanting MSB it
currently looks like Pixelbook is the outlier.
On Thu, Sep 17, 2020 at 11:28 AM Jani Nikula
wrote:
>
> On Thu, 17 Sep 2020, Kevin Chowski wrote:
> > We have observed that Google Pixelbook's backlight hardware is
> > interpretting these backlight bits from the most-significant side of the
> > 16 bit word (if DP_EDP_PWMGEN_BIT_COUNT < 16), whereas the driver code
> > assumes the peripheral cares about the least-significant bits.
> >
> > Testing was done from within Chrome OS's build environment when the
> > patch is backported to 5.4 (the version we are newly targeting for the
> > Pixelbook); for the record:
> >$ emerge-eve-kernelnext sys-kernel/chromeos-kernel-5_4 && \
> > ./update_kernel.sh --remote=$IP
> >
> > I used `/sys/kernel/debug/dri/0/eDP-1/i915_dpcd` on my laptop to verify
> > that the registers were being set according to what the actual hardware
> > expects; I also observe that the backlight is noticeably brighter with
> > this patch.
>
> It's unclear to me what kernel version this is against, and what you've
> actually tested.
>
> Have you tried v5.7 kernel with Lyude's fde7266fb2f6 ("drm/i915: Fix eDP
> DPCD aux max backlight calculations")?
>
> I just want to make sure you've tested with all the relevant fixes
> before adding quirks.
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Kevin Chowski
> > ---
> >
> > .../drm/i915/display/intel_dp_aux_backlight.c | 34 +++
> > drivers/gpu/drm/i915/display/intel_quirks.c | 13 +++
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > 3 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > index acbd7eb66cbe3..99c98f217356d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> > @@ -91,6 +91,23 @@ static u32 intel_dp_aux_get_backlight(struct
> > intel_connector *connector)
> > if (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT)
> > level = (read_val[0] << 8 | read_val[1]);
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + _val[0])) {
> > + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return 0;
> > + }
> > + // Only bits 4:0 are used, 7:5 are reserved.
> > + read_val[0] = read_val[0] & 0x1F;
> > + if (read_val[0] > 16) {
> > + DRM_DEBUG_KMS("Invalid DP_EDP_PWNGEN_BIT_COUNT 0x%X,
> > expected at most 16\n",
> > + read_val[0]);
> > + return 0;
> > + }
> > + level >>= 16 - read_val[0];
> > + }
> > +
> > return level;
> > }
> >
> > @@ -106,6 +123,23 @@ intel_dp_aux_set_backlight(const struct
> > drm_connector_state *conn_state, u32 lev
> > struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> > u8 vals[2] = { 0x0 };
> >
> > + if (i915->quirks & QUIRK_SHIFT_EDP_BACKLIGHT_BRIGHTNESS) {
> > + if (!drm_dp_dpcd_readb(_dp->aux,
> > DP_EDP_PWMGEN_BIT_COUNT,
> > + [0])) {
> > + DRM_DEBUG_KMS("Failed to write aux backlight level:
> > Failed to read DPCD register 0x%x\n",
> > + DP_EDP_PWMGEN_BIT_COUNT);
> > + return;
> > + }
> > + // Only
[PATCH v4 09/19] drm/virtio: implement blob resources: probe for host visible region
From: Gerd Hoffmann
The availability of the host visible region means host 3D
allocations can be directly mapped in the guest.
Signed-off-by: Gerd Hoffmann
Co-developed-by: Gurchetan Singh
Signed-off-by: Gurchetan Singh
Acked-by: Tomeu Vizoso
---
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 5 +
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_kms.c | 20 ++--
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
index 6b9b8376613f0..a2cdd267914ac 100644
--- a/drivers/gpu/drm/virtio/virtgpu_debugfs.c
+++ b/drivers/gpu/drm/virtio/virtgpu_debugfs.c
@@ -52,6 +52,11 @@ static int virtio_gpu_features(struct seq_file *m, void
*data)
virtio_add_bool(m, "blob resources", vgdev->has_resource_blob);
virtio_add_int(m, "cap sets", vgdev->num_capsets);
virtio_add_int(m, "scanouts", vgdev->num_scanouts);
+ if (vgdev->host_visible_region.len) {
+ seq_printf(m, "%-16s : 0x%lx +0x%lx\n", "host visible region",
+ (unsigned long)vgdev->host_visible_region.addr,
+ (unsigned long)vgdev->host_visible_region.len);
+ }
return 0;
}
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index b53478a6a3c08..391637f0b362d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -209,6 +209,8 @@ struct virtio_gpu_device {
bool has_indirect;
bool has_resource_assign_uuid;
bool has_resource_blob;
+ bool has_host_visible;
+ struct virtio_shm_region host_visible_region;
struct work_struct config_changed_work;
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
index 0678e56100dae..e17d3f5a0b54e 100644
--- a/drivers/gpu/drm/virtio/virtgpu_kms.c
+++ b/drivers/gpu/drm/virtio/virtgpu_kms.c
@@ -155,11 +155,27 @@ int virtio_gpu_init(struct drm_device *dev)
if (virtio_has_feature(vgdev->vdev, VIRTIO_GPU_F_RESOURCE_BLOB)) {
vgdev->has_resource_blob = true;
}
+ if (virtio_get_shm_region(vgdev->vdev, >host_visible_region,
+ VIRTIO_GPU_SHM_ID_HOST_VISIBLE)) {
+ if (!devm_request_mem_region(>vdev->dev,
+vgdev->host_visible_region.addr,
+vgdev->host_visible_region.len,
+dev_name(>vdev->dev))) {
+ DRM_ERROR("Could not reserve host visible region\n");
+ goto err_vqs;
+ }
+
+ DRM_INFO("Host memory window: 0x%lx +0x%lx\n",
+(unsigned long)vgdev->host_visible_region.addr,
+(unsigned long)vgdev->host_visible_region.len);
+ vgdev->has_host_visible = true;
+ }
- DRM_INFO("features: %cvirgl %cedid %cresource_blob\n",
+ DRM_INFO("features: %cvirgl %cedid %cresource_blob %chost_visible\n",
vgdev->has_virgl_3d? '+' : '-',
vgdev->has_edid? '+' : '-',
-vgdev->has_resource_blob ? '+' : '-');
+vgdev->has_resource_blob ? '+' : '-',
+vgdev->has_host_visible ? '+' : '-');
ret = virtio_find_vqs(vgdev->vdev, 2, vqs, callbacks, names, NULL);
if (ret) {
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/19] drm/virtio: implement blob resources: probe for host visible region
On Thu, Sep 17, 2020 at 2:40 AM Gerd Hoffmann wrote:
> Hi,
>
> > + if (!devm_request_mem_region(>vdev->dev,
> > +
> vgdev->host_visible_region.addr,
> > +
> vgdev->host_visible_region.len,
> > + dev_name(>vdev->dev)))
> {
> > + DRM_ERROR("Could not reserve host visible
> region\n");
> > + goto err_vqs;
> > + }
>
> > + if (vgdev->has_host_visible) {
> > + devm_release_mem_region(>vdev->dev,
> > + vgdev->host_visible_region.addr,
> > + vgdev->host_visible_region.len);
> > + }
>
> Hmm. isn't it the point of the managed apis that the release happens
> automatically? I think you don't need the devm_release_mem_region
> call (it doesn't break things though).
>
Ack, good catch. Fixed.
>
> take care,
> Gerd
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/19] drm/virtio: implement blob resources: implement vram object
Hi,
> + if (resp_type == VIRTIO_GPU_RESP_OK_MAP_INFO) {
> + vram->map_info = resp->map_info;
> + vram->map_state = STATE_OK;
> + } else {
> + vram->map_state = STATE_ERR;
> + }
Ah, found it, here. ok.
take care,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/dp: add a number of DP 2.0 DPCD definitions
Prepare for future with DP 2.0 DPCD definitions, with a couple of related drive-by cleanups. No functional changes. Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 52 - 1 file changed, 45 insertions(+), 7 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 3d9900e7d57c..6144a4c54e4f 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -123,6 +123,7 @@ #define DP_MAX_DOWNSPREAD 0x003 # define DP_MAX_DOWNSPREAD_0_5 (1 << 0) +# define DP_STREAM_REGENERATION_STATUS_CAP (1 << 1) /* 2.0 */ # define DP_NO_AUX_HANDSHAKE_LINK_TRAINING (1 << 6) # define DP_TPS4_SUPPORTED (1 << 7) @@ -140,6 +141,7 @@ #define DP_MAIN_LINK_CHANNEL_CODING 0x006 # define DP_CAP_ANSI_8B10B (1 << 0) +# define DP_CAP_ANSI_128B132B (1 << 1) /* 2.0 */ #define DP_DOWN_STREAM_PORT_COUNT 0x007 # define DP_PORT_COUNT_MASK0x0f @@ -183,8 +185,14 @@ #define DP_FAUX_CAP0x020 /* 1.2 */ # define DP_FAUX_CAP_1 (1 << 0) +#define DP_SINK_VIDEO_FALLBACK_FORMATS 0x020 /* 2.0 */ +# define DP_FALLBACK_1024x768_60HZ_24BPP(1 << 0) +# define DP_FALLBACK_1280x720_60HZ_24BPP(1 << 1) +# define DP_FALLBACK_1920x1080_60HZ_24BPP (1 << 2) + #define DP_MSTM_CAP0x021 /* 1.2 */ # define DP_MST_CAP(1 << 0) +# define DP_SINGLE_STREAM_SIDEBAND_MSG (1 << 1) /* 2.0 */ #define DP_NUMBER_OF_AUDIO_ENDPOINTS 0x022 /* 1.2 */ @@ -415,6 +423,9 @@ # define DP_LINK_BW_2_70x0a # define DP_LINK_BW_5_40x14/* 1.2 */ # define DP_LINK_BW_8_10x1e/* 1.4 */ +# define DP_LINK_BW_10 0x01/* 2.0 128b/132b Link Layer */ +# define DP_LINK_BW_13_50x04/* 2.0 128b/132b Link Layer */ +# define DP_LINK_BW_20 0x02/* 2.0 128b/132b Link Layer */ #define DP_LANE_COUNT_SET 0x101 # define DP_LANE_COUNT_MASK0x0f @@ -466,12 +477,15 @@ # define DP_TRAIN_PRE_EMPHASIS_SHIFT 3 # define DP_TRAIN_MAX_PRE_EMPHASIS_REACHED (1 << 5) +# define DP_TX_FFE_PRESET_VALUE_MASK(0xf << 0) /* 2.0 128b/132b Link Layer */ + #define DP_DOWNSPREAD_CTRL 0x107 # define DP_SPREAD_AMP_0_5 (1 << 4) # define DP_MSA_TIMING_PAR_IGNORE_EN (1 << 7) /* eDP */ #define DP_MAIN_LINK_CHANNEL_CODING_SET0x108 # define DP_SET_ANSI_8B10B (1 << 0) +# define DP_SET_ANSI_128B132B (1 << 1) #define DP_I2C_SPEED_CONTROL_STATUS0x109 /* DPI */ /* bitmask as for DP_I2C_SPEED_CAP */ @@ -490,8 +504,19 @@ # define DP_LINK_QUAL_PATTERN_ERROR_RATE2 # define DP_LINK_QUAL_PATTERN_PRBS73 # define DP_LINK_QUAL_PATTERN_80BIT_CUSTOM 4 -# define DP_LINK_QUAL_PATTERN_HBR2_EYE 5 -# define DP_LINK_QUAL_PATTERN_MASK 7 +# define DP_LINK_QUAL_PATTERN_CP2520_PAT_1 5 +# define DP_LINK_QUAL_PATTERN_CP2520_PAT_2 6 +# define DP_LINK_QUAL_PATTERN_CP2520_PAT_3 7 +/* DP 2.0 UHBR10, UHBR13.5, UHBR20 */ +# define DP_LINK_QUAL_PATTERN_128B132B_TPS1 0x08 +# define DP_LINK_QUAL_PATTERN_128B132B_TPS2 0x10 +# define DP_LINK_QUAL_PATTERN_PRSBS90x18 +# define DP_LINK_QUAL_PATTERN_PRSBS11 0x20 +# define DP_LINK_QUAL_PATTERN_PRSBS15 0x28 +# define DP_LINK_QUAL_PATTERN_PRSBS23 0x30 +# define DP_LINK_QUAL_PATTERN_PRSBS31 0x38 +# define DP_LINK_QUAL_PATTERN_CUSTOM0x40 +# define DP_LINK_QUAL_PATTERN_SQUARE0x48 #define DP_TRAINING_LANE0_1_SET2 0x10f #define DP_TRAINING_LANE2_3_SET2 0x110 @@ -594,9 +619,9 @@ #define DP_LINK_STATUS_UPDATED (1 << 7) #define DP_SINK_STATUS 0x205 - -#define DP_RECEIVE_PORT_0_STATUS (1 << 0) -#define DP_RECEIVE_PORT_1_STATUS (1 << 1) +# define DP_RECEIVE_PORT_0_STATUS (1 << 0) +# define DP_RECEIVE_PORT_1_STATUS (1 << 1) +# define DP_STREAM_REGENERATION_STATUS (1 << 2) /* 2.0 */ #define DP_ADJUST_REQUEST_LANE0_1 0x206 #define DP_ADJUST_REQUEST_LANE2_3 0x207 @@ -609,6 +634,12 @@ # define DP_ADJUST_PRE_EMPHASIS_LANE1_MASK 0xc0 # define DP_ADJUST_PRE_EMPHASIS_LANE1_SHIFT 6 +/* DP 2.0 128b/132b Link Layer */ +# define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 0) +# define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 0 +# define DP_ADJUST_TX_FFE_PRESET_LANE0_MASK (0xf << 4) +# define DP_ADJUST_TX_FFE_PRESET_LANE0_SHIFT 4 + #define DP_ADJUST_REQUEST_POST_CURSOR2 0x20c # define DP_ADJUST_POST_CURSOR2_LANE0_MASK 0x03 # define DP_ADJUST_POST_CURSOR2_LANE0_SHIFT 0 @@ -926,9 +957,8 @@ #define DP_LANE_ALIGN_STATUS_UPDATED_ESI 0x200e /* status same as 0x204 */ #define
Re: [PATCH 0/3] drm: panfrost: Coherency support
On 9/17/20 12:38 PM, Steven Price wrote: On 16/09/2020 18:46, Rob Herring wrote: On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig wrote: So I get a performance regression with the dma-coherent approach, even if it's clearly the cleaner. That's bizarre -- this should really be the faster of the two. Coherency may not be free. CortexA9 had something like 4x slower memcpy if SMP was enabled as an example. I don't know if there's anything going on like that specifically here. If there's never any CPU accesses mixed in with kmscube, then there would be no benefit to coherency. The DDK blob has the ability to mark only certain areas of memory as coherent for performance reasons. For simple things like kmscube I would expect that it's basically write-only from the CPU and almost all memory the GPU touches isn't touched by the CPU. I.e. coherency isn't helping and the coherency traffic is probably expensive. Whether the complexity is worth it for "real" content I don't know - it may just be silly benchmarks that benefit. Or maybe it's only a problem for applications that do silly things? I don't think kmscube was ever optimized for performance. Regards, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/dp: add subheadings to DPCD address definitions
Add the subheadings from the DP spec. No functional changes. Signed-off-by: Jani Nikula --- include/drm/drm_dp_helper.h | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 5c45195ced32..3d9900e7d57c 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -104,8 +104,9 @@ #define DP_AUX_I2C_REPLY_DEFER (0x2 << 2) #define DP_AUX_I2C_REPLY_MASK (0x3 << 2) -/* AUX CH addresses */ -/* DPCD */ +/* DPCD Field Address Mapping */ + +/* Receiver Capability */ #define DP_DPCD_REV 0x000 # define DP_DPCD_REV_10 0x10 # define DP_DPCD_REV_11 0x11 @@ -407,7 +408,7 @@ #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1 0x0a1 #define DP_DSC_BRANCH_MAX_LINE_WIDTH0x0a2 -/* link configuration */ +/* Link Configuration */ #defineDP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE0x00/* eDP 1.4 */ # define DP_LINK_BW_1_62 0x06 @@ -561,6 +562,7 @@ #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 #define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 +/* Link/Sink Device Status */ #define DP_SINK_COUNT 0x200 /* prior to 1.2 bit 7 was reserved mbz */ # define DP_GET_SINK_COUNT(x) x) & 0x80) >> 1) | ((x) & 0x3f)) @@ -760,20 +762,27 @@ #define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1 /* 1.2 MST */ /* up to ID_SLOT_63 at 0x2ff */ +/* Source Device-specific */ #define DP_SOURCE_OUI 0x300 + +/* Sink Device-specific */ #define DP_SINK_OUI0x400 + +/* Branch Device-specific */ #define DP_BRANCH_OUI 0x500 #define DP_BRANCH_ID0x503 #define DP_BRANCH_REVISION_START0x509 #define DP_BRANCH_HW_REV0x509 #define DP_BRANCH_SW_REV0x50A +/* Link/Sink Device Power Control */ #define DP_SET_POWER0x600 # define DP_SET_POWER_D00x1 # define DP_SET_POWER_D30x2 # define DP_SET_POWER_MASK 0x3 # define DP_SET_POWER_D3_AUX_ON 0x5 +/* eDP-specific */ #define DP_EDP_DPCD_REV0x700/* eDP 1.2 */ # define DP_EDP_11 0x00 # define DP_EDP_12 0x01 @@ -857,11 +866,13 @@ #define DP_EDP_REGIONAL_BACKLIGHT_BASE 0x740/* eDP 1.4 */ #define DP_EDP_REGIONAL_BACKLIGHT_00x741/* eDP 1.4 */ +/* Sideband MSG Buffers */ #define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ #define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ #define DP_SIDEBAND_MSG_UP_REQ_BASE0x1600 /* 1.2 MST */ +/* DPRX Event Status Indicator */ #define DP_SINK_COUNT_ESI 0x2002 /* 1.2 */ /* 0-5 sink count */ # define DP_SINK_COUNT_CP_READY (1 << 6) @@ -915,6 +926,7 @@ #define DP_LANE_ALIGN_STATUS_UPDATED_ESI 0x200e /* status same as 0x204 */ #define DP_SINK_STATUS_ESI 0x200f /* status same as 0x205 */ +/* Extended Receiver Capability */ #define DP_DP13_DPCD_REV0x2200 #define DP_DP13_MAX_LINK_RATE 0x2201 @@ -928,6 +940,7 @@ # define DP_VSC_EXT_CEA_SDP_SUPPORTED (1 << 6) /* DP 1.4 */ # define DP_VSC_EXT_CEA_SDP_CHAINING_SUPPORTED (1 << 7) /* DP 1.4 */ +/* Protocol Converter Extension */ /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ #define DP_CEC_TUNNELING_CAPABILITY0x3000 # define DP_CEC_TUNNELING_CAPABLE (1 << 0) @@ -984,6 +997,7 @@ #define DP_CEC_TX_MESSAGE_BUFFER 0x3020 #define DP_CEC_MESSAGE_BUFFER_LENGTH 0x10 +/* HDCP 1.3 and HDCP 2.2 */ #define DP_AUX_HDCP_BKSV 0x68000 #define DP_AUX_HDCP_RI_PRIME 0x68005 #define DP_AUX_HDCP_AKSV 0x68007 @@ -1029,7 +1043,7 @@ #define DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET 0x69494 #define DP_HDCP_2_2_REG_DBG_OFFSET 0x69518 -/* Link Training (LT)-tunable PHY Repeaters */ +/* LTTPR: Link Training (LT)-tunable PHY Repeaters */ #define DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV 0xf /* 1.3 */ #define DP_MAX_LINK_RATE_PHY_REPEATER 0xf0001 /* 1.4a */ #define DP_PHY_REPEATER_CNT0xf0002 /* 1.3 */ -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 18/21] drm/vkms: Introduce GEM object functions
Hi Thomas,
On 09/15, Thomas Zimmermann wrote:
> GEM object functions deprecate several similar callback interfaces in
> struct drm_driver. This patch replaces the per-driver callbacks with
> per-instance callbacks in vkms.
>
> Signed-off-by: Thomas Zimmermann
Thanks! Looks fine.
Reviewed-by: Melissa Wen
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 8
> drivers/gpu/drm/vkms/vkms_gem.c | 13 +
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index cb0b6230c22c..726801ab44d4 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -51,12 +51,6 @@ static const struct file_operations vkms_driver_fops = {
> .release= drm_release,
> };
>
> -static const struct vm_operations_struct vkms_gem_vm_ops = {
> - .fault = vkms_gem_fault,
> - .open = drm_gem_vm_open,
> - .close = drm_gem_vm_close,
> -};
> -
> static void vkms_release(struct drm_device *dev)
> {
> struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
> @@ -98,8 +92,6 @@ static struct drm_driver vkms_driver = {
> .release= vkms_release,
> .fops = _driver_fops,
> .dumb_create= vkms_dumb_create,
> - .gem_vm_ops = _gem_vm_ops,
> - .gem_free_object_unlocked = vkms_gem_free_object,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_import_sg_table = vkms_prime_import_sg_table,
>
> diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
> index a017fc59905e..19a0e260a4df 100644
> --- a/drivers/gpu/drm/vkms/vkms_gem.c
> +++ b/drivers/gpu/drm/vkms/vkms_gem.c
> @@ -7,6 +7,17 @@
>
> #include "vkms_drv.h"
>
> +static const struct vm_operations_struct vkms_gem_vm_ops = {
> + .fault = vkms_gem_fault,
> + .open = drm_gem_vm_open,
> + .close = drm_gem_vm_close,
> +};
> +
> +static const struct drm_gem_object_funcs vkms_gem_object_funcs = {
> + .free = vkms_gem_free_object,
> + .vm_ops = _gem_vm_ops,
> +};
> +
> static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
>u64 size)
> {
> @@ -17,6 +28,8 @@ static struct vkms_gem_object *__vkms_gem_create(struct
> drm_device *dev,
> if (!obj)
> return ERR_PTR(-ENOMEM);
>
> + obj->gem.funcs = _gem_object_funcs;
> +
> size = roundup(size, PAGE_SIZE);
> ret = drm_gem_object_init(dev, >gem, size);
> if (ret) {
> --
> 2.28.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] Changing vma->vm_file in dma_buf_mmap()
Am 17.09.20 um 13:31 schrieb Jason Gunthorpe: On Thu, Sep 17, 2020 at 10:09:12AM +0200, Daniel Vetter wrote: Yeah, but it doesn't work when forwarding from the drm chardev to the dma-buf on the importer side, since you'd need a ton of different address spaces. And you still rely on the core code picking up your pgoff mangling, which feels about as risky to me as the vma file pointer wrangling - if it's not consistently applied the reverse map is toast and unmap_mapping_range doesn't work correctly for our needs. I would think the pgoff has to be translated at the same time the vm->vm_file is changed? The owner of the dma_buf should have one virtual address space and FD, all its dma bufs should be linked to it, and all pgoffs translated to that space. Yeah, that is exactly like amdgpu is doing it. Going to document that somehow when I'm done with TTM cleanups. Christian. Jason ___ Linaro-mm-sig mailing list linaro-mm-...@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-mm-sig ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: remove superflous extern attribute from funcs
Extern is the default attribute for functions anyway.
Signed-off-by: Christian König
---
include/drm/ttm/ttm_execbuf_util.h | 19 ---
include/drm/ttm/ttm_memory.h | 25 -
2 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/include/drm/ttm/ttm_execbuf_util.h
b/include/drm/ttm/ttm_execbuf_util.h
index 5a19843bb80d..a99d7fdf2964 100644
--- a/include/drm/ttm/ttm_execbuf_util.h
+++ b/include/drm/ttm/ttm_execbuf_util.h
@@ -58,9 +58,8 @@ struct ttm_validate_buffer {
* Undoes all buffer validation reservations for bos pointed to by
* the list entries.
*/
-
-extern void ttm_eu_backoff_reservation(struct ww_acquire_ctx *ticket,
- struct list_head *list);
+void ttm_eu_backoff_reservation(struct ww_acquire_ctx *ticket,
+ struct list_head *list);
/**
* function ttm_eu_reserve_buffers
@@ -96,10 +95,9 @@ extern void ttm_eu_backoff_reservation(struct ww_acquire_ctx
*ticket,
* ttm_eu_fence_buffer_objects() when command submission is complete or
* has failed.
*/
-
-extern int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
- struct list_head *list, bool intr,
- struct list_head *dups);
+int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
+ struct list_head *list, bool intr,
+ struct list_head *dups);
/**
* function ttm_eu_fence_buffer_objects.
@@ -113,9 +111,8 @@ extern int ttm_eu_reserve_buffers(struct ww_acquire_ctx
*ticket,
* It also unreserves all buffers, putting them on lru lists.
*
*/
-
-extern void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx *ticket,
- struct list_head *list,
- struct dma_fence *fence);
+void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx *ticket,
+struct list_head *list,
+struct dma_fence *fence);
#endif
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index 2d468d7c94e6..c1f167881e33 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -79,18 +79,17 @@ extern struct ttm_mem_global {
#endif
} ttm_mem_glob;
-extern int ttm_mem_global_init(struct ttm_mem_global *glob);
-extern void ttm_mem_global_release(struct ttm_mem_global *glob);
-extern int ttm_mem_global_alloc(struct ttm_mem_global *glob, uint64_t memory,
+int ttm_mem_global_init(struct ttm_mem_global *glob);
+void ttm_mem_global_release(struct ttm_mem_global *glob);
+int ttm_mem_global_alloc(struct ttm_mem_global *glob, uint64_t memory,
+struct ttm_operation_ctx *ctx);
+void ttm_mem_global_free(struct ttm_mem_global *glob, uint64_t amount);
+int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
+ struct page *page, uint64_t size,
+ struct ttm_operation_ctx *ctx);
+void ttm_mem_global_free_page(struct ttm_mem_global *glob,
+ struct page *page, uint64_t size);
+size_t ttm_round_pot(size_t size);
+bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob, uint64_t
num_pages,
struct ttm_operation_ctx *ctx);
-extern void ttm_mem_global_free(struct ttm_mem_global *glob,
- uint64_t amount);
-extern int ttm_mem_global_alloc_page(struct ttm_mem_global *glob,
-struct page *page, uint64_t size,
-struct ttm_operation_ctx *ctx);
-extern void ttm_mem_global_free_page(struct ttm_mem_global *glob,
-struct page *page, uint64_t size);
-extern size_t ttm_round_pot(size_t size);
-extern bool ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
- uint64_t num_pages, struct ttm_operation_ctx *ctx);
#endif
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Why is nouveau using a separate swap storage?
Hi guys, just another TTM feature which is only used by nouveau. We have this bo->bo.persistent_swap_storage pointer which is only set by nouveau to the GEM filp and used when a BO is swapped to a shmem file. As far as I can see this doesn't make any sense at all? What is the background here. Thanks, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] Enlarge tracepoints in the display component
On Wed, Sep 16, 2020 at 11:27:27AM -0400, Kazlauskas, Nicholas wrote: > On 2020-09-16 5:12 a.m., Daniel Vetter wrote: > > On Fri, Sep 11, 2020 at 10:59:23AM -0400, Rodrigo Siqueira wrote: > > > Debug issues related to display can be a challenge due to the complexity > > > around this topic and different source of information might help in this > > > process. We already have support for tracepoints inside the display > > > component, i.e., we have the basic functionalities available and we just > > > need to expand it in order to make it more valuable for debugging. For > > > this reason, this patchset reworks part of the current tracepoint > > > options and add different sets of tracing inside amdgpu_dm, display > > > core, and DCN10. The first patch of this series just rework part of the > > > current tracepoints and the last set of patches introduces new > > > tracepoints. > > > > > > This first patchset version is functional. Please, let me know what I > > > can improve in the current version but also let me know what kind of > > > tracepoint I can add for the next version. > > > > > > Finally, I want to highlight that this work is based on a set of patches > > > originally made by Nicholas Kazlauskas. > > > > > > Change in V2: > > > - I added another patch for capturing the clock state for different > > > display > > >architecture. > > > > Hm I'm not super sure tracepoints for state dumping are the right thing > > here. We kinda have the atomic state dumping code with all the various > > callbacks, and you can extend that pretty easily. Gives you full state > > dump in debugfs, plus a few function to dump into dmesg. > > > > Maybe what we need is a function to dump this also into printk tracepoint > > (otoh with Sean Paul's tracepoint work we'd get that through the dmesg > > stuff already), and then you could do it there? > > > > Upside is that for customers they'd get a much more consistent way to > > debug display issues across different drivers. > > > > For low-level hw debug what we do is give the hw guys an mmio trace, and > > they replay it on the fancy boxes :-) So for that I think this here is > > again too high level, but maybe what you have is a bit different. > > -Daniel > > We have raw register traces, but what I find most useful is to be able to > see are the incoming DRM IOCTLs, objects and properties per commit. > > Many of the bugs we see in display code is in the conversion from DRM -> DM > -> DC state. The current HW state is kind of useless in most cases, but the > sequence helps track down intermittent problems and understand state > transitions. > > Tracepoints provide everything I really need to be able to track down these > problems without falling back to a full debugger. The existing DRM prints > (even at high logging levels) aren't enough to understand what's going on in > most cases in our driver so funneling those into tracepoints to improve perf > doesn't really help that much. > > I think this kind of idea was rejected for DRM core last year with Sean's > patch series but if we can't get them into core then I'd like to get them > into our driver at least. These are a cleaned up version of Sean's work + my > work that I end up applying locally whenever I debug something. Nah, Sean's series wasn't rejected. It's simply stuck waiting for review. So if your goal is to get better dumping going on, I think combining this with Sean's work (and getting that reviewed), plus then tapping into the atomic state dumping code. Then you know what was requested, plus what your atomic_check code computed should be the hw state, and you can compare that with the register dumps you already grab. Feels at least like a more complete and flexible solution than ad-hoc tracepoints for debuggin in each driver. The idea behind Sean's work is also that we'd have a blackbox recorder for any drm issues which distros in the field could use. So driver doing their own debug output doesn't sound super great. I think Siqueira already chatted a bit with Sean. -Daniel > > Regards, > Nicholas Kazlauskas > > > > > > > > > Rodrigo Siqueira (4): > > >drm/amd/display: Rework registers tracepoint > > >drm/amd/display: Add tracepoint for amdgpu_dm > > >drm/amd/display: Add pipe_state tracepoint > > >drm/amd/display: Add tracepoint for capturing clocks state > > > > > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 + > > > .../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 712 +- > > > .../dc/clk_mgr/dce112/dce112_clk_mgr.c| 5 + > > > .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c| 4 + > > > .../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 4 + > > > .../amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 4 + > > > .../display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 4 + > > > drivers/gpu/drm/amd/display/dc/core/dc.c | 11 + > > > .../gpu/drm/amd/display/dc/dce/dce_clk_mgr.c | 5 + > > >
Re: [PATCH v3 02/19] drm/virtio: blob prep: make CPU responses more generic
On Wed, Sep 16, 2020 at 05:08:21PM -0700, Gurchetan Singh wrote: > RESOURCE_MAP_BLOB / RESOURCE_UNMAP_BLOB can use this. > -#define UUID_INITIALIZING 0 > -#define UUID_INITIALIZED 1 > -#define UUID_INITIALIZATION_FAILED 2 > +#define STATE_INITIALIZING 0 > +#define STATE_OK 1 > +#define STATE_ERR 2 --verbose please. I fail to see the point and browsing the following patches doesn't make things more clear ... take care, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/21] drm/tegra: Introduce GEM object functions
On Tue, Sep 15, 2020 at 04:59:51PM +0200, Thomas Zimmermann wrote: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in tegra. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/tegra/drm.c | 4 > drivers/gpu/drm/tegra/gem.c | 8 > 2 files changed, 8 insertions(+), 4 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4
Hi Thomas,
Am 17.09.20 um 12:51 schrieb Thomas Zimmermann:
Hi
Am 24.06.20 um 20:26 schrieb Nirmoy Das:
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset.
Signed-off-by: Nirmoy Das
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 0023ce1d2cf7..ad096600d89f 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -281,6 +281,15 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
*gbo)
}
EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
+static u64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
+{
+ /* Keep TTM behavior for now, remove when drivers are audited */
+ if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
At this line I got
Sounds like ast forgot to pin the cursor to VRAM.
If you look at ast_cursor_page_flip(), you see:
off = drm_gem_vram_offset(gbo);
if (drm_WARN_ON_ONCE(dev, off < 0))
return; /* Bug: we didn't pin the cursor HW BO to VRAM. */
The drm_WARN_ON_ONCE() just never triggered before because it checks for
the wrong condition (off < 0).
Regards,
Christian.
[ 146.133821] [ cut here ]
[ 146.133872] WARNING: CPU: 6 PID: 7 at
drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x59/0x60
[drm_vram_helper]
[ 146.133880] Modules linked in: fuse(E) af_packet(E) ebtable_filter(E)
ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E)
ip_tables(E) x_tables(E) bpfilter(E) rfkill(E) dmi_sysfs(E) msr(E)
intel_powerclamp(E) coretemp(E) kv)
[ 146.134051] scsi_dh_emc(E) scsi_dh_alua(E)
[ 146.134074] CPU: 6 PID: 7 Comm: kworker/u48:0 Tainted: GE
5.9.0-rc4-1-default+ #492
[ 146.134083] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN
FIRE X2270 M2, BIOS 2.0507/01/2010
[ 146.134099] Workqueue: events_unbound commit_work
[ 146.134116] RIP: 0010:drm_gem_vram_offset+0x59/0x60 [drm_vram_helper]
[ 146.134128] Code: 02 00 00 00 74 24 48 8d bb 80 02 00 00 e8 ef 27 17
d7 48 8b 83 80 02 00 00 5b 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5b
c3 <0f> 0b 31 c0 5b c3 90 66 66 66 66 90 41 56 41 55 49 89 d5 41 54 49
[ 146.134137] RSP: 0018:c9107c38 EFLAGS: 00010246
[ 146.134149] RAX: RBX: 88855000 RCX:
c032323b
[ 146.134158] RDX: dc00 RSI: 88810e236300 RDI:
88855278
[ 146.134168] RBP: 88810909 R08: c0323225 R09:
0002
[ 146.134177] R10: ed1020675020 R11: 0001 R12:
888109091050
[ 146.134187] R13: 88810e236300 R14: 88810909 R15:
[ 146.134197] FS: () GS:88811600()
knlGS:
[ 146.134206] CS: 0010 DS: ES: CR0: 80050033
[ 146.134215] CR2: 7f60547d9100 CR3: 29216002 CR4:
000206e0
[ 146.134223] Call Trace:
[ 146.134245] ast_cursor_page_flip+0x3e/0x150 [ast]
[ 146.134272] ast_cursor_plane_helper_atomic_update+0x8a/0xc0 [ast]
[ 146.134300] drm_atomic_helper_commit_planes+0x197/0x4c0
[ 146.134341] drm_atomic_helper_commit_tail_rpm+0x51/0x90
[ 146.134357] commit_tail+0x103/0x1c0
[ 146.134390] process_one_work+0x56a/0xa60
[ 146.134431] ? __lock_acquired+0x1ca/0x3d0
[ 146.134447] ? pwq_dec_nr_in_flight+0x110/0x110
[ 146.134460] ? __lock_contended+0x4a0/0x4a0
[ 146.134491] ? worker_thread+0x150/0x620
[ 146.134521] worker_thread+0x8b/0x620
[ 146.134539] ? _raw_spin_unlock_irqrestore+0x41/0x50
[ 146.134583] ? process_one_work+0xa60/0xa60
[ 146.134597] kthread+0x1e4/0x210
[ 146.134612] ? kthread_create_worker_on_cpu+0xb0/0xb0
[ 146.134637] ret_from_fork+0x22/0x30
[ 146.134698] irq event stamp: 74111
[ 146.134711] hardirqs last enabled at (74117): []
console_unlock+0x539/0x670
[ 146.134723] hardirqs last disabled at (74122): []
console_unlock+0x52f/0x670
[ 146.134737] softirqs last enabled at (73354): []
wb_workfn+0x3f5/0x430
[ 146.134749] softirqs last disabled at (73350): []
wb_wakeup_delayed+0x40/0xa0
[ 146.134758] ---[ end trace 74dd5fac6a3a2c0c ]---
Happens with ast when doing
weston-launch
+ return 0;
+
+ return gbo->bo.mem.start;
+}
+
/**
* drm_gem_vram_offset() - \
Returns a GEM VRAM object's offset in video memory
@@ -297,7 +306,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
{
if (WARN_ON_ONCE(!gbo->pin_count))
return (s64)-ENODEV;
- return gbo->bo.offset;
+ return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
}
EXPORT_SYMBOL(drm_gem_vram_offset);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix spelling error in comments
On Thu, Sep 17, 2020 at 10:04:32AM +0800, Wang Qing wrote: > Change the comment typo: "manger" -> "manager". > > Signed-off-by: Wang Qing Pushed to drm-misc-next, thanks for your patch. -Daniel > --- > include/drm/drm_mm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h > index a01bc6f..9b4292f > --- a/include/drm/drm_mm.h > +++ b/include/drm/drm_mm.h > @@ -338,7 +338,7 @@ static inline u64 drm_mm_hole_node_end(const struct > drm_mm_node *hole_node) > > /** > * drm_mm_nodes - list of nodes under the drm_mm range manager > - * @mm: the struct drm_mm range manger > + * @mm: the struct drm_mm range manager > * > * As the drm_mm range manager hides its node_list deep with its > * structure, extracting it looks painful and repetitive. This is > -- > 2.7.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v10 0/4] Support DRM bridges on NVIDIA Tegra
On Fri, Aug 14, 2020 at 01:06:52AM +0300, Dmitry Osipenko wrote: > Hello, > > This series adds initial support for the DRM bridges to NVIDIA Tegra DRM > driver. This is required by newer device-trees where we model the LVDS > encoder bridge properly. In particular this series is needed in order to > light up display panels of recently merged Acer A500 and Nexus 7 devices. > > Changelog: > > v10: - No changes. Patches missed v5.9 kernel, re-sending for v5.10. >@Thierry, please pick up this series into linux-next or let me >know what needs to be changed, thanks in advance! > > v9: - Dropped the of-graph/drm-of patches from this series because they > are now factored out into a standalone series [1]. > > [1] https://patchwork.ozlabs.org/project/linux-tegra/list/?series=186813 > > - The "drm/panel-simple: Add missing connector type for some panels" > patch of v8 was already applied. > > v8: - The new of_graph_get_local_port() helper is replaced with the > of_graph_presents(), which simply checks the graph presence in a > given DT node. Thank to Laurent Pinchart for the suggestion! > > - The of_graph_get_local_port() is still there, but now it isn't a public > function anymore. In the review to v7 Laurent Pinchart suggested that > the function's doc-comments and name could be improved and I implemented > these suggestions in v8. > > - A day ago I discovered that devm_drm_panel_bridge_add() requires > panel to have connector type to be properly set, otherwise function > rejects panels with the incomplete description. So, I checked what > LVDS panels are used on Tegra and fixed the missing connector types > in this new patch: > > drm/panel-simple: Add missing connector type for some panels > > v7: - Removed the obscure unused structs (which GCC doesn't detect, but CLANG > does) in the patch "Wrap directly-connected panel into DRM bridge", > which was reported by kernel test robot for v6. > > v6: - Added r-b and acks from Rob Herring and Sam Ravnborg. > > - Rebased on a recent linux-next, patches now apply without fuzz. > > v5: - Added new patches that make drm_of_find_panel_or_bridge() more usable > if graph isn't defined in a device-tree: > > of_graph: add of_graph_get_local_port() > drm/of: Make drm_of_find_panel_or_bridge() to check graph's presence > > - Updated "Support DRM bridges" patch to use drm_of_find_panel_or_bridge() > directly and added WARN_ON(output->panel || output->bridge) > sanity-check. > > - Added new "Wrap directly-connected panel into DRM bridge" patch, as > was suggested by Laurent Pinchart. > > v4: - Following review comments that were made by Laurent Pinchart to the v3, > we now create and use the "bridge connector". > > v3: - Following recommendation from Sam Ravnborg, the new bridge attachment > model is now being used, i.e. we ask bridge to *not* create a connector > using the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag. > > - The bridge is now created only for the RGB (LVDS) output, and only > when necessary. For now we don't need bridges for HDMI or DSI outputs. > > - I noticed that we're leaking OF node in the panel's error code path, > this is fixed now by the new patch "Don't leak OF node on error". > > v2: - Added the new "rgb: Don't register connector if bridge is used" > patch, which hides the unused connector provided by the Tegra DRM > driver when bridge is used, since bridge provides its own connector > to us. > > > Dmitry Osipenko (4): > drm/tegra: output: Don't leak OF node on error > drm/tegra: output: Support DRM bridges > drm/tegra: output: rgb: Support LVDS encoder bridge > drm/tegra: output: rgb: Wrap directly-connected panel into DRM bridge > > drivers/gpu/drm/tegra/drm.h| 2 + > drivers/gpu/drm/tegra/output.c | 21 +-- > drivers/gpu/drm/tegra/rgb.c| 102 + > 3 files changed, 72 insertions(+), 53 deletions(-) Applied to drm/tegra/for-next, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4
Hi
Am 24.06.20 um 20:26 schrieb Nirmoy Das:
> Calculate GEM VRAM bo's offset within vram-helper without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 0023ce1d2cf7..ad096600d89f 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -281,6 +281,15 @@ u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object
> *gbo)
> }
> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
>
> +static u64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
> +{
> + /* Keep TTM behavior for now, remove when drivers are audited */
> + if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
At this line I got
[ 146.133821] [ cut here ]
[ 146.133872] WARNING: CPU: 6 PID: 7 at
drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x59/0x60
[drm_vram_helper]
[ 146.133880] Modules linked in: fuse(E) af_packet(E) ebtable_filter(E)
ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E)
ip_tables(E) x_tables(E) bpfilter(E) rfkill(E) dmi_sysfs(E) msr(E)
intel_powerclamp(E) coretemp(E) kv)
[ 146.134051] scsi_dh_emc(E) scsi_dh_alua(E)
[ 146.134074] CPU: 6 PID: 7 Comm: kworker/u48:0 Tainted: GE
5.9.0-rc4-1-default+ #492
[ 146.134083] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN
FIRE X2270 M2, BIOS 2.0507/01/2010
[ 146.134099] Workqueue: events_unbound commit_work
[ 146.134116] RIP: 0010:drm_gem_vram_offset+0x59/0x60 [drm_vram_helper]
[ 146.134128] Code: 02 00 00 00 74 24 48 8d bb 80 02 00 00 e8 ef 27 17
d7 48 8b 83 80 02 00 00 5b 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5b
c3 <0f> 0b 31 c0 5b c3 90 66 66 66 66 90 41 56 41 55 49 89 d5 41 54 49
[ 146.134137] RSP: 0018:c9107c38 EFLAGS: 00010246
[ 146.134149] RAX: RBX: 88855000 RCX:
c032323b
[ 146.134158] RDX: dc00 RSI: 88810e236300 RDI:
88855278
[ 146.134168] RBP: 88810909 R08: c0323225 R09:
0002
[ 146.134177] R10: ed1020675020 R11: 0001 R12:
888109091050
[ 146.134187] R13: 88810e236300 R14: 88810909 R15:
[ 146.134197] FS: () GS:88811600()
knlGS:
[ 146.134206] CS: 0010 DS: ES: CR0: 80050033
[ 146.134215] CR2: 7f60547d9100 CR3: 29216002 CR4:
000206e0
[ 146.134223] Call Trace:
[ 146.134245] ast_cursor_page_flip+0x3e/0x150 [ast]
[ 146.134272] ast_cursor_plane_helper_atomic_update+0x8a/0xc0 [ast]
[ 146.134300] drm_atomic_helper_commit_planes+0x197/0x4c0
[ 146.134341] drm_atomic_helper_commit_tail_rpm+0x51/0x90
[ 146.134357] commit_tail+0x103/0x1c0
[ 146.134390] process_one_work+0x56a/0xa60
[ 146.134431] ? __lock_acquired+0x1ca/0x3d0
[ 146.134447] ? pwq_dec_nr_in_flight+0x110/0x110
[ 146.134460] ? __lock_contended+0x4a0/0x4a0
[ 146.134491] ? worker_thread+0x150/0x620
[ 146.134521] worker_thread+0x8b/0x620
[ 146.134539] ? _raw_spin_unlock_irqrestore+0x41/0x50
[ 146.134583] ? process_one_work+0xa60/0xa60
[ 146.134597] kthread+0x1e4/0x210
[ 146.134612] ? kthread_create_worker_on_cpu+0xb0/0xb0
[ 146.134637] ret_from_fork+0x22/0x30
[ 146.134698] irq event stamp: 74111
[ 146.134711] hardirqs last enabled at (74117): []
console_unlock+0x539/0x670
[ 146.134723] hardirqs last disabled at (74122): []
console_unlock+0x52f/0x670
[ 146.134737] softirqs last enabled at (73354): []
wb_workfn+0x3f5/0x430
[ 146.134749] softirqs last disabled at (73350): []
wb_wakeup_delayed+0x40/0xa0
[ 146.134758] ---[ end trace 74dd5fac6a3a2c0c ]---
Happens with ast when doing
weston-launch
> + return 0;
> +
> + return gbo->bo.mem.start;
> +}
> +
> /**
> * drm_gem_vram_offset() - \
> Returns a GEM VRAM object's offset in video memory
> @@ -297,7 +306,7 @@ s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo)
> {
> if (WARN_ON_ONCE(!gbo->pin_count))
> return (s64)-ENODEV;
> - return gbo->bo.offset;
> + return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
> }
> EXPORT_SYMBOL(drm_gem_vram_offset);
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Why is nouveau using a separate swap storage?
On Thu, 17 Sep 2020 at 20:06, Christian König wrote: > > Hi guys, > > just another TTM feature which is only used by nouveau. > > We have this bo->bo.persistent_swap_storage pointer which is only set by > nouveau to the GEM filp and used when a BO is swapped to a shmem file. > > As far as I can see this doesn't make any sense at all? What is the > background here. No specific reason I can remember, likely cargo-cult from very very early versions of TTM/GEM stuff. Ben. > > Thanks, > Christian. > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/ast something ate high-res modes (5.3->5.6 regression)
Hi
Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> Hi,
>
> After upgrading kernel from 5.3 series to 5.6.16 something seems to
> prevent me from achieving high resolutions with the ast driver.
Are you able to build and run a test kernel?
I'm seriously considering moving ast to the SHMEM memory manager, which
would restore the higher resolutions.
If you're able to test, you need the git tree drm-tip/drm-tip and the
attached patch.
Alternatively, I've pushed all to
https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/ast-shmem
You'd have to checkout the tree and switch to the ast-shmem branch.
Please report back if that solves the issue for you.
Best regards
Thomas
>
> With 5.6.16:
>
> $ xrandr
> Screen 0: minimum 320 x 200, current 1600 x 1200, maximum 1920 x 2048
> VGA-1 connected primary 1600x1200+0+0 (normal left inverted right x axis y
> axis) 519mm x 324mm
>1600x1200 60.00*
>1680x1050 59.95
>1280x1024 75.0260.02
>1440x900 59.89
>1280x800 59.81
>1024x768 75.0360.00
>800x600 75.0060.32
>640x480 75.0059.94
>1920x1200_60.0 59.95
>
> If I try to change to that manually added high-res mode, I get:
> xrandr: Configure crtc 0 failed
>
> With 5.3 series I've this:
>
> Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 2048
> VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y
> axis) 519mm x 324mm
>1920x1200 59.95*+
>1600x1200 60.00
>1680x1050 59.95
>1280x1024 75.0260.02
>1440x900 59.89
>1280x800 59.81
>1024x768 75.0360.00
>800x600 75.0060.32
>640x480 75.0059.94
>1920x1200_60.0 59.95
>
> As I've had issues in getting EDID reliably from the monitor, I provide it
> on kernel command-line (the one dumped from the monitor I use). In
> addition, I've another workaround for past issues related to EDID which
> always adds that 1920x1200_60.0 mode but now I cannot use even it to
> enter a high-res mode.
>
> If you need some additional info or want me to test a patch, just let me
> know (but some delay is expected in testing patches). Thanks.
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
From ea15b5d52a4538e40da9605d71ed52baa1c1cdd7 Mon Sep 17 00:00:00 2001
From: Thomas Zimmermann
Date: Thu, 9 Jul 2020 14:06:43 +0200
Subject: [PATCH] drm/ast: Convert ast to SHMEM
---
drivers/gpu/drm/ast/Kconfig | 4 +-
drivers/gpu/drm/ast/ast_cursor.c | 95
drivers/gpu/drm/ast/ast_drv.c| 5 +-
drivers/gpu/drm/ast/ast_drv.h| 8 ++-
drivers/gpu/drm/ast/ast_main.c | 1 -
drivers/gpu/drm/ast/ast_mm.c | 32 +++
drivers/gpu/drm/ast/ast_mode.c | 75 +++--
7 files changed, 112 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/ast/Kconfig b/drivers/gpu/drm/ast/Kconfig
index fbcf2f45cef5..d367a90cd3de 100644
--- a/drivers/gpu/drm/ast/Kconfig
+++ b/drivers/gpu/drm/ast/Kconfig
@@ -2,10 +2,8 @@
config DRM_AST
tristate "AST server chips"
depends on DRM && PCI && MMU
+ select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
- select DRM_VRAM_HELPER
- select DRM_TTM
- select DRM_TTM_HELPER
help
Say yes for experimental AST GPU driver. Do not enable
this driver without having a working -modesetting,
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index e0f4613918ad..ad4b02967d32 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -27,79 +27,39 @@
* Authors: Dave Airlie
*/
-#include
+#include
#include
#include "ast_drv.h"
-static void ast_cursor_fini(struct ast_private *ast)
-{
- size_t i;
- struct drm_gem_vram_object *gbo;
-
- for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
- gbo = ast->cursor.gbo[i];
- drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
- drm_gem_vram_unpin(gbo);
- drm_gem_vram_put(gbo);
- }
-}
-
-static void ast_cursor_release(struct drm_device *dev, void *ptr)
-{
- struct ast_private *ast = to_ast_private(dev);
-
- ast_cursor_fini(ast);
-}
-
/*
* Allocate cursor BOs and pins them at the end of VRAM.
*/
int ast_cursor_init(struct ast_private *ast)
{
- struct drm_device *dev = >base;
size_t size, i;
- struct drm_gem_vram_object *gbo;
void __iomem *vaddr;
- int ret;
+ u64 offset;
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
+ vaddr = ast->vram + ast->vram_fb_available;
+ offset = ast->vram_base + ast->vram_fb_available;
+
for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
- gbo = drm_gem_vram_create(dev, size, 0);
- if (IS_ERR(gbo)) {
- ret = PTR_ERR(gbo);
- goto err_drm_gem_vram_put;
- }
- ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
-
Re: [PATCH 0/3] drm: panfrost: Coherency support
On 17/09/2020 11:51, Tomeu Vizoso wrote: On 9/17/20 12:38 PM, Steven Price wrote: On 16/09/2020 18:46, Rob Herring wrote: On Wed, Sep 16, 2020 at 11:04 AM Alyssa Rosenzweig wrote: So I get a performance regression with the dma-coherent approach, even if it's clearly the cleaner. That's bizarre -- this should really be the faster of the two. Coherency may not be free. CortexA9 had something like 4x slower memcpy if SMP was enabled as an example. I don't know if there's anything going on like that specifically here. If there's never any CPU accesses mixed in with kmscube, then there would be no benefit to coherency. The DDK blob has the ability to mark only certain areas of memory as coherent for performance reasons. For simple things like kmscube I would expect that it's basically write-only from the CPU and almost all memory the GPU touches isn't touched by the CPU. I.e. coherency isn't helping and the coherency traffic is probably expensive. Whether the complexity is worth it for "real" content I don't know - it may just be silly benchmarks that benefit. Or maybe it's only a problem for applications that do silly things? I don't think kmscube was ever optimized for performance. Well doing silly things is almost the definition of a benchmark ;) A lot of the mobile graphics benchmarks suffer from not being very intelligent in how they render (e.g. many have meshes that are far too detailed so the triangles are smaller than the pixels). Of course there are also applications that get things wrong too. Steve ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/meson: add support for MIPI-DSI transceiver
On Thu, Sep 17, 2020 at 09:14:33AM +0200, Neil Armstrong wrote: > On 08/09/2020 10:46, Daniel Vetter wrote: > > On Tue, Sep 08, 2020 at 10:06:03AM +0200, Neil Armstrong wrote: > >> Hi, > >> > >> On 07/09/2020 20:03, Daniel Vetter wrote: > >>> On Mon, Sep 07, 2020 at 11:03:29AM +0200, Neil Armstrong wrote: > On 07/09/2020 10:44, Daniel Vetter wrote: > > On Mon, Sep 07, 2020 at 10:43:51AM +0200, Daniel Vetter wrote: > >> On Mon, Sep 07, 2020 at 10:18:25AM +0200, Neil Armstrong wrote: > >>> The Amlogic AXg SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver > >>> 1.21a), with a custom > >>> glue managing the IP resets, clock and data input similar to the > >>> DW-HDMI Glue on other > >>> Amlogic SoCs. > >>> > >>> This adds support for the Glue managing the transceiver, mimicing the > >>> init flow provided > >>> by Amlogic to setup the ENCl encoder, the glue, the transceiver, the > >>> digital D-PHY and the > >>> Analog PHY in the proper way. > >>> > >>> The DW-MIPI-DSI transceiver + D-PHY are directly clocked by the VCLK2 > >>> clock, which pixel clock > >>> is derived and feeds the ENCL encoder and the VIU pixel reader. > >>> > >>> An optional "MEAS" clock can be enabled to measure the delay between > >>> each vsync feeding the > >>> DW-MIPI-DSI transceiver. > >>> > >>> Signed-off-by: Neil Armstrong > >> > >> More dw-hdmi drivers which aren't bridges but components, and the > >> thing is > >> still midlayer-y as heck :-/ > > > > *dw-dsi, but really they both work the same way and should both be fixed > > ... > > They are bridges but since they have platform-dependent code due to > theirs's generic IP > nature, they need to be intanciated by components to sync with the > platform code. > >>> > >>> Yeah that's how it currently works, but there's not much reason why it > >>> needs to work like that. That platform glue code can also be put behind > >>> the drm_bridge abstraction, and we could use the normal dt based bridge > >>> lookup like for everything else. > >>> > >>> Afaiui the only reason dw-* bridge drivers work like that is because for > >>> historical reasons we only had component.c at first, and none of the more > >>> fancy dynamic bridge lookup. So would be really good to switch this all > >>> over to a proper bridge abstraction, and not leak everything around. > >> > >> Does it mean we should avoit using components, right ? > > > > Yup, at least when there's an established specific mechanism to handle > > cross-driver interactions/EPROBE_DEFER. > > > > So if you want a drm_panel or drm_bridge or a clock or i2c or anything > > else standardized like that, no component.c please. That's just for the > > driver-specific glue when you have entirely IP-specific way of building up > > a driver from components, which will never be reused outside of that > > overall driver. > > > > Hence why dw-* using components is rather uncool. > > > >>> I've typed up what I think should be the way forward a few times already, > >>> but thus far not even the todo.rst entry materialized: > >>> > >>> https://lore.kernel.org/dri-devel/20200430135841.GE10381@phenom.ffwll.local/ > >>> > >>> If everyone is always about "not in my patch series" it'll never happen. > >> > >> Today, the dw-mipi-dsi and dw-mipi-hdmi has mandatory callbacks to > >> implement > >> vendor specific features, like : > >> - hdmi/dsi phy handling when mixed into the glue/custom/synopsys but with > >> platform specific values > >> - platform specific mode validation > >> - hpd setup => could use laurent's work here with no_connector, but how do > >> we handle rxsense ??? > >> - dsi timings/lane mbps ? these are platform phy specific > >> > >> For amlogic, I can split the "component" code handling venc/vclk into a > >> primary bridge and add a > >> secondary driver only handling the glue around dw-mipi-dsi/dw-mipi-hdmi, > >> would that be a good start ? > > > > I think what we should do here: > > > > - type up todo.rst with the overall structure we want to aim for, i.e. > > where is the code, who sets up what, how are the bridges bound into the > > overall driver. > > OK, sure, this can be a good start, but first I would like all the other > bridge > maintainers & reviewers to agree on the the wanted structure. > > > > > - demidlayer dw-* enough so that the callbacks are gone, and it becomes > > more a toolbox/library for building a dw-* driver. Maybe we're there > > already. > > This is not really wanted, otherwise we would duplicate a large amount of code > over all the platform glues, is this really wanted ? > > Today, they already are a toolbox, with different levels of callback neded > depending on how deep the integration is. Yeah I guess getting rid of all of them doesn't make that much sense. > > - All new drivers then need to use the toolbox and have everything
[PATCH AUTOSEL 5.4 182/330] drm/msm/a5xx: Always set an OPP supported hardware value
From: Jordan Crouse
[ Upstream commit 0478b4fc5f37f4d494245fe7bcce3f531cf380e9 ]
If the opp table specifies opp-supported-hw as a property but the driver
has not set a supported hardware value the OPP subsystem will reject
all the table entries.
Set a "default" value that will match the default table entries but not
conflict with any possible real bin values. Also fix a small memory leak
and free the buffer allocated by nvmem_cell_read().
Signed-off-by: Jordan Crouse
Reviewed-by: Eric Anholt
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 7829247de60e0..de0ea1d09a54f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1407,18 +1407,31 @@ static const struct adreno_gpu_funcs funcs = {
static void check_speed_bin(struct device *dev)
{
struct nvmem_cell *cell;
- u32 bin, val;
+ u32 val;
+
+ /*
+* If the OPP table specifies a opp-supported-hw property then we have
+* to set something with dev_pm_opp_set_supported_hw() or the table
+* doesn't get populated so pick an arbitrary value that should
+* ensure the default frequencies are selected but not conflict with any
+* actual bins
+*/
+ val = 0x80;
cell = nvmem_cell_get(dev, "speed_bin");
- /* If a nvmem cell isn't defined, nothing to do */
- if (IS_ERR(cell))
- return;
+ if (!IS_ERR(cell)) {
+ void *buf = nvmem_cell_read(cell, NULL);
+
+ if (!IS_ERR(buf)) {
+ u8 bin = *((u8 *) buf);
- bin = *((u32 *) nvmem_cell_read(cell, NULL));
- nvmem_cell_put(cell);
+ val = (1 << bin);
+ kfree(buf);
+ }
- val = (1 << bin);
+ nvmem_cell_put(cell);
+ }
dev_pm_opp_set_supported_hw(dev, , 1);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 216/330] PCI: Use ioremap(), not phys_to_virt() for platform ROM
From: Mikel Rychliski
[ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ]
On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the radeon module on a x86_32 kernel
can result in the following:
BUG: unable to handle page fault for address: 3e8ed03c
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
*pde =
Oops: [#1] PREEMPT SMP
CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2
Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS
MP11.88Z.005C.B08.0707021221 07/02/07
EIP: radeon_get_bios+0x5ed/0xe50 [radeon]
Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08 8b
55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 01
aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06
EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001
ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206
CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0
Call Trace:
r520_init+0x26/0x240 [radeon]
radeon_device_init+0x533/0xa50 [radeon]
radeon_driver_load_kms+0x80/0x220 [radeon]
drm_dev_register+0xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_read_platform_bios() previously directly accessed an __iomem
pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
pci_platform_rom() now has no remaining callers, so remove it.
Link: https://lore.kernel.org/r/20200319021623.5426-1-mi...@mikelr.com
Signed-off-by: Mikel Rychliski
Signed-off-by: Bjorn Helgaas
Acked-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 31 +++
.../drm/nouveau/nvkm/subdev/bios/shadowpci.c | 17 --
drivers/gpu/drm/radeon/radeon_bios.c | 30 +++---
drivers/pci/rom.c | 17 --
include/linux/pci.h | 1 -
5 files changed, 52 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index 50dff69a0f6e3..b1172d93c99c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -192,30 +192,35 @@ static bool amdgpu_read_bios_from_rom(struct
amdgpu_device *adev)
static bool amdgpu_read_platform_bios(struct amdgpu_device *adev)
{
- uint8_t __iomem *bios;
- size_t size;
+ phys_addr_t rom = adev->pdev->rom;
+ size_t romlen = adev->pdev->romlen;
+ void __iomem *bios;
adev->bios = NULL;
- bios = pci_platform_rom(adev->pdev, );
- if (!bios) {
+ if (!rom || romlen == 0)
return false;
- }
- adev->bios = kzalloc(size, GFP_KERNEL);
- if (adev->bios == NULL)
+ adev->bios = kzalloc(romlen, GFP_KERNEL);
+ if (!adev->bios)
return false;
- memcpy_fromio(adev->bios, bios, size);
+ bios = ioremap(rom, romlen);
+ if (!bios)
+ goto free_bios;
- if (!check_atom_bios(adev->bios, size)) {
- kfree(adev->bios);
- return false;
- }
+ memcpy_fromio(adev->bios, bios, romlen);
+ iounmap(bios);
- adev->bios_size = size;
+ if (!check_atom_bios(adev->bios, romlen))
+ goto free_bios;
+
+ adev->bios_size = romlen;
return true;
+free_bios:
+ kfree(adev->bios);
+ return false;
}
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da09dc5f8..8d9812a51ef63 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -101,9 +101,13 @@ platform_init(struct nvkm_bios *bios, const char *name)
else
return ERR_PTR(-ENODEV);
+ if (!pdev->rom || pdev->romlen == 0)
+ return ERR_PTR(-ENODEV);
+
if ((priv = kmalloc(sizeof(*priv), GFP_KERNEL))) {
+ priv->size = pdev->romlen;
if (ret = -ENODEV,
- (priv->rom = pci_platform_rom(pdev, >size)))
+ (priv->rom = ioremap(pdev->rom, pdev->romlen)))
return priv;
kfree(priv);
}
@@ -111,11 +115,20 @@ platform_init(struct nvkm_bios *bios, const char *name)
return
[PATCH AUTOSEL 5.4 265/330] drm/amd/powerplay: try to do a graceful shutdown on SW CTF
From: Evan Quan
[ Upstream commit 9495220577416632675959caf122e968469ffd16 ]
Normally this(SW CTF) should not happen. And by doing graceful
shutdown we can prevent further damage.
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 21 +++
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 7 +++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
index d09690fca4520..414added3d02c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c
@@ -22,6 +22,7 @@
*/
#include
+#include
#include "hwmgr.h"
#include "pp_debug.h"
@@ -593,12 +594,18 @@ int phm_irq_process(struct amdgpu_device *adev,
uint32_t src_id = entry->src_id;
if (client_id == AMDGPU_IRQ_CLIENTID_LEGACY) {
- if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH)
+ if (src_id == VISLANDS30_IV_SRCID_CG_TSS_THERMAL_LOW_TO_HIGH) {
pr_warn("GPU over temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
- else if (src_id ==
VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
+ /*
+* SW CTF just occurred.
+* Try to do a graceful shutdown to prevent further
damage.
+*/
+ dev_emerg(adev->dev, "System is going to shutdown due
to SW CTF!\n");
+ orderly_poweroff(true);
+ } else if (src_id ==
VISLANDS30_IV_SRCID_CG_TSS_THERMAL_HIGH_TO_LOW)
pr_warn("GPU under temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
@@ -609,12 +616,18 @@ int phm_irq_process(struct amdgpu_device *adev,
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
} else if (client_id == SOC15_IH_CLIENTID_THM) {
- if (src_id == 0)
+ if (src_id == 0) {
pr_warn("GPU over temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
- else
+ /*
+* SW CTF just occurred.
+* Try to do a graceful shutdown to prevent further
damage.
+*/
+ dev_emerg(adev->dev, "System is going to shutdown due
to SW CTF!\n");
+ orderly_poweroff(true);
+ } else
pr_warn("GPU under temperature range detected on PCIe
%d:%d.%d!\n",
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
index c4d8c52c6b9ca..6c4405622c9bb 100644
--- a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
+++ b/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "pp_debug.h"
#include "amdgpu.h"
@@ -1538,6 +1539,12 @@ static int smu_v11_0_irq_process(struct amdgpu_device
*adev,
PCI_BUS_NUM(adev->pdev->devfn),
PCI_SLOT(adev->pdev->devfn),
PCI_FUNC(adev->pdev->devfn));
+ /*
+* SW CTF just occurred.
+* Try to do a graceful shutdown to prevent further
damage.
+*/
+ dev_emerg(adev->dev, "System is going to shutdown due
to SW CTF!\n");
+ orderly_poweroff(true);
break;
case THM_11_0__SRCID__THM_DIG_THERM_H2L:
pr_warn("GPU under temperature range detected on PCIe
%d:%d.%d!\n",
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH AUTOSEL 5.4 001/330] drm/v3d: don't leak bin job if v3d_job_init fails.
On Thu, Sep 17, 2020 at 7:01 PM Sasha Levin wrote:
>
> From: Iago Toral Quiroga
>
> [ Upstream commit 0d352a3a8a1f26168d09f7073e61bb4b328e3bb9 ]
>
> If the initialization of the job fails we need to kfree() it
> before returning.
>
> Signed-off-by: Iago Toral Quiroga
> Signed-off-by: Eric Anholt
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190916071125.5255-1-ito...@igalia.com
> Fixes: a783a09ee76d ("drm/v3d: Refactor job management.")
> Reviewed-by: Eric Anholt
> Signed-off-by: Sasha Levin
You're double freeing with this patch, the bug is already solved.
> ---
> drivers/gpu/drm/v3d/v3d_gem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index 19c092d75266b..6316bf3646af5 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -565,6 +565,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
> ret = v3d_job_init(v3d, file_priv, >base,
>v3d_job_free, args->in_sync_bcl);
> if (ret) {
> + kfree(bin);
> v3d_job_put(>base);
> kfree(bin);
> return ret;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 232/330] drm/amdgpu/sriov add amdgpu_amdkfd_pre_reset in gpu reset
From: Jack Zhang [ Upstream commit 04bef61e5da18c2b301c629a209ccdba4d4c6fbb ] kfd_pre_reset will free mem_objs allocated by kfd_gtt_sa_allocate Without this change, sriov tdr code path will never free those allocated memories and get memory leak. v2:add a bugfix for kiq ring test fail Signed-off-by: Jack Zhang Reviewed-by: Monk Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c | 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 3 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++ 3 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c index d10f483f5e273..ce30d4e8bf25f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c @@ -644,6 +644,9 @@ static int kgd_hqd_destroy(struct kgd_dev *kgd, void *mqd, uint32_t temp; struct v10_compute_mqd *m = get_mqd(mqd); + if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset) + return 0; + #if 0 unsigned long flags; int retry; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c index e262f2ac07a35..92754cfb98086 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c @@ -540,6 +540,9 @@ int kgd_gfx_v9_hqd_destroy(struct kgd_dev *kgd, void *mqd, uint32_t temp; struct v9_mqd *m = get_mqd(mqd); + if (amdgpu_sriov_vf(adev) && adev->in_gpu_reset) + return 0; + if (adev->in_gpu_reset) return -EIO; diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 5e1dce4241547..4105fbf571674 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3466,6 +3466,8 @@ static int amdgpu_device_reset_sriov(struct amdgpu_device *adev, if (r) return r; + amdgpu_amdkfd_pre_reset(adev); + /* Resume IP prior to SMC */ r = amdgpu_device_ip_reinit_early_sriov(adev); if (r) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 223/330] drm/amdgpu/vcn2.0: stall DPG when WPTR/RPTR reset
From: James Zhu [ Upstream commit ef563ff403404ef2f234abe79bdd9f04ab6481c9 ] Add vcn dpg harware synchronization to fix race condition issue between vcn driver and hardware. Signed-off-by: James Zhu Reviewed-by: Leo Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c index 36ad0c0e8efbc..cd2cbe760e883 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c @@ -1026,6 +1026,10 @@ static int vcn_v2_0_start_dpg_mode(struct amdgpu_device *adev, bool indirect) tmp = REG_SET_FIELD(tmp, UVD_RBC_RB_CNTL, RB_RPTR_WR_EN, 1); WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_CNTL, tmp); + /* Stall DPG before WPTR/RPTR reset */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK, + ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); /* set the write pointer delay */ WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_WPTR_CNTL, 0); @@ -1048,6 +1052,9 @@ static int vcn_v2_0_start_dpg_mode(struct amdgpu_device *adev, bool indirect) WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_WPTR, lower_32_bits(ring->wptr)); + /* Unstall DPG */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + 0, ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); return 0; } @@ -1357,8 +1364,13 @@ static int vcn_v2_0_pause_dpg_mode(struct amdgpu_device *adev, UVD_DPG_PAUSE__NJ_PAUSE_DPG_ACK_MASK, UVD_DPG_PAUSE__NJ_PAUSE_DPG_ACK_MASK, ret_code); + /* Stall DPG before WPTR/RPTR reset */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK, + ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); /* Restore */ ring = >vcn.inst->ring_enc[0]; + ring->wptr = 0; WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_LO, ring->gpu_addr); WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_HI, upper_32_bits(ring->gpu_addr)); WREG32_SOC15(UVD, 0, mmUVD_RB_SIZE, ring->ring_size / 4); @@ -1366,6 +1378,7 @@ static int vcn_v2_0_pause_dpg_mode(struct amdgpu_device *adev, WREG32_SOC15(UVD, 0, mmUVD_RB_WPTR, lower_32_bits(ring->wptr)); ring = >vcn.inst->ring_enc[1]; + ring->wptr = 0; WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_LO2, ring->gpu_addr); WREG32_SOC15(UVD, 0, mmUVD_RB_BASE_HI2, upper_32_bits(ring->gpu_addr)); WREG32_SOC15(UVD, 0, mmUVD_RB_SIZE2, ring->ring_size / 4); @@ -1374,6 +1387,9 @@ static int vcn_v2_0_pause_dpg_mode(struct amdgpu_device *adev, WREG32_SOC15(UVD, 0, mmUVD_RBC_RB_WPTR, RREG32_SOC15(UVD, 0, mmUVD_SCRATCH2) & 0x7FFF); + /* Unstall DPG */ + WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_POWER_STATUS), + 0, ~UVD_POWER_STATUS__STALL_DPG_POWER_UP_MASK); SOC15_WAIT_ON_RREG(UVD, 0, mmUVD_POWER_STATUS, UVD_PGFSM_CONFIG__UVDM_UVDU_PWR_ON, -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 132/206] PCI: Use ioremap(), not phys_to_virt() for platform ROM
From: Mikel Rychliski
[ Upstream commit 72e0ef0e5f067fd991f702f0b2635d911d0cf208 ]
On some EFI systems, the video BIOS is provided by the EFI firmware. The
boot stub code stores the physical address of the ROM image in pdev->rom.
Currently we attempt to access this pointer using phys_to_virt(), which
doesn't work with CONFIG_HIGHMEM.
On these systems, attempting to load the radeon module on a x86_32 kernel
can result in the following:
BUG: unable to handle page fault for address: 3e8ed03c
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
*pde =
Oops: [#1] PREEMPT SMP
CPU: 0 PID: 317 Comm: systemd-udevd Not tainted 5.6.0-rc3-next-20200228 #2
Hardware name: Apple Computer, Inc. MacPro1,1/Mac-F4208DC8, BIOS
MP11.88Z.005C.B08.0707021221 07/02/07
EIP: radeon_get_bios+0x5ed/0xe50 [radeon]
Code: 00 00 84 c0 0f 85 12 fd ff ff c7 87 64 01 00 00 00 00 00 00 8b 47 08 8b
55 b0 e8 1e 83 e1 d6 85 c0 74 1a 8b 55 c0 85 d2 74 13 <80> 38 55 75 0e 80 78 01
aa 0f 84 a4 03 00 00 8d 74 26 00 68 dc 06
EAX: 3e8ed03c EBX: ECX: 3e8ed03c EDX: 0001
ESI: 0004 EDI: eec04000 EBP: eef3fc60 ESP: eef3fbe0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010206
CR0: 80050033 CR2: 3e8ed03c CR3: 2ec77000 CR4: 06d0
Call Trace:
r520_init+0x26/0x240 [radeon]
radeon_device_init+0x533/0xa50 [radeon]
radeon_driver_load_kms+0x80/0x220 [radeon]
drm_dev_register+0xa7/0x180 [drm]
radeon_pci_probe+0x10f/0x1a0 [radeon]
pci_device_probe+0xd4/0x140
Fix the issue by updating all drivers which can access a platform provided
ROM. Instead of calling the helper function pci_platform_rom() which uses
phys_to_virt(), call ioremap() directly on the pdev->rom.
radeon_read_platform_bios() previously directly accessed an __iomem
pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
pci_platform_rom() now has no remaining callers, so remove it.
Link: https://lore.kernel.org/r/20200319021623.5426-1-mi...@mikelr.com
Signed-off-by: Mikel Rychliski
Signed-off-by: Bjorn Helgaas
Acked-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 31 +++
.../drm/nouveau/nvkm/subdev/bios/shadowpci.c | 17 --
drivers/gpu/drm/radeon/radeon_bios.c | 30 +++---
drivers/pci/rom.c | 17 --
include/linux/pci.h | 1 -
5 files changed, 52 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
index a5df80d50d447..6cf3dd5edffda 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
@@ -191,30 +191,35 @@ static bool amdgpu_read_bios_from_rom(struct
amdgpu_device *adev)
static bool amdgpu_read_platform_bios(struct amdgpu_device *adev)
{
- uint8_t __iomem *bios;
- size_t size;
+ phys_addr_t rom = adev->pdev->rom;
+ size_t romlen = adev->pdev->romlen;
+ void __iomem *bios;
adev->bios = NULL;
- bios = pci_platform_rom(adev->pdev, );
- if (!bios) {
+ if (!rom || romlen == 0)
return false;
- }
- adev->bios = kzalloc(size, GFP_KERNEL);
- if (adev->bios == NULL)
+ adev->bios = kzalloc(romlen, GFP_KERNEL);
+ if (!adev->bios)
return false;
- memcpy_fromio(adev->bios, bios, size);
+ bios = ioremap(rom, romlen);
+ if (!bios)
+ goto free_bios;
- if (!check_atom_bios(adev->bios, size)) {
- kfree(adev->bios);
- return false;
- }
+ memcpy_fromio(adev->bios, bios, romlen);
+ iounmap(bios);
- adev->bios_size = size;
+ if (!check_atom_bios(adev->bios, romlen))
+ goto free_bios;
+
+ adev->bios_size = romlen;
return true;
+free_bios:
+ kfree(adev->bios);
+ return false;
}
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
index 9b91da09dc5f8..8d9812a51ef63 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowpci.c
@@ -101,9 +101,13 @@ platform_init(struct nvkm_bios *bios, const char *name)
else
return ERR_PTR(-ENODEV);
+ if (!pdev->rom || pdev->romlen == 0)
+ return ERR_PTR(-ENODEV);
+
if ((priv = kmalloc(sizeof(*priv), GFP_KERNEL))) {
+ priv->size = pdev->romlen;
if (ret = -ENODEV,
- (priv->rom = pci_platform_rom(pdev, >size)))
+ (priv->rom = ioremap(pdev->rom, pdev->romlen)))
return priv;
kfree(priv);
}
@@ -111,11 +115,20 @@ platform_init(struct nvkm_bios *bios, const char *name)
return
[PATCH AUTOSEL 4.19 116/206] drm/msm/a5xx: Always set an OPP supported hardware value
From: Jordan Crouse
[ Upstream commit 0478b4fc5f37f4d494245fe7bcce3f531cf380e9 ]
If the opp table specifies opp-supported-hw as a property but the driver
has not set a supported hardware value the OPP subsystem will reject
all the table entries.
Set a "default" value that will match the default table entries but not
conflict with any possible real bin values. Also fix a small memory leak
and free the buffer allocated by nvmem_cell_read().
Signed-off-by: Jordan Crouse
Reviewed-by: Eric Anholt
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index ba6f3c14495c0..dd298abc5f393 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1474,18 +1474,31 @@ static const struct adreno_gpu_funcs funcs = {
static void check_speed_bin(struct device *dev)
{
struct nvmem_cell *cell;
- u32 bin, val;
+ u32 val;
+
+ /*
+* If the OPP table specifies a opp-supported-hw property then we have
+* to set something with dev_pm_opp_set_supported_hw() or the table
+* doesn't get populated so pick an arbitrary value that should
+* ensure the default frequencies are selected but not conflict with any
+* actual bins
+*/
+ val = 0x80;
cell = nvmem_cell_get(dev, "speed_bin");
- /* If a nvmem cell isn't defined, nothing to do */
- if (IS_ERR(cell))
- return;
+ if (!IS_ERR(cell)) {
+ void *buf = nvmem_cell_read(cell, NULL);
+
+ if (!IS_ERR(buf)) {
+ u8 bin = *((u8 *) buf);
- bin = *((u32 *) nvmem_cell_read(cell, NULL));
- nvmem_cell_put(cell);
+ val = (1 << bin);
+ kfree(buf);
+ }
- val = (1 << bin);
+ nvmem_cell_put(cell);
+ }
dev_pm_opp_set_supported_hw(dev, , 1);
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 100/206] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index e9934de1b9cf8..0222bb7ea49b4 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -742,8 +742,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 115/206] drm/msm: fix leaks if initialization fails
From: Pavel Machek
[ Upstream commit 66be340f827554cb1c8a1ed7dea97920b4085af2 ]
We should free resources in unlikely case of allocation failure.
Signed-off-by: Pavel Machek
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7f45486b6650b..3ba3ae9749bec 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -495,8 +495,10 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
GFP_KERNEL);
- if (!dev->dma_parms)
- return -ENOMEM;
+ if (!dev->dma_parms) {
+ ret = -ENOMEM;
+ goto err_msm_uninit;
+ }
}
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 47/90] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index 1b50e6c13fb3f..5fbf99d600587 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -748,8 +748,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 03/64] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 7d47b3d5cc0d0..54d554d720004 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 38/90] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c index 136d30484d023..46111e9ee9a25 100644 --- a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c +++ b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c @@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -219,6 +219,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.9 03/90] gma/gma500: fix a memory disclosure bug due to uninitialized bytes
From: Kangjie Lu
[ Upstream commit 57a25a5f754ce27da2cfa6f413cfd366f878db76 ]
`best_clock` is an object that may be sent out. Object `clock`
contains uninitialized bytes that are copied to `best_clock`,
which leads to memory disclosure and information leak.
Signed-off-by: Kangjie Lu
Signed-off-by: Daniel Vetter
Link:
https://patchwork.freedesktop.org/patch/msgid/20191018042953.31099-1-k...@umn.edu
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 17db4b4749d5a..2e8479744ca4a 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -415,6 +415,8 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t
*limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
+ memset(, 0, sizeof(clock));
+
switch (refclk) {
case 27000:
if (target < 20) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.4 27/64] drm/omap: fix possible object reference leak
From: Wen Yang [ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ] The call to of_find_matching_node returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang Reviewed-by: Laurent Pinchart Reviewed-by: Mukesh Ojha Cc: Tomi Valkeinen Cc: David Airlie Cc: Daniel Vetter Cc: Sebastian Reichel Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Markus Elfring Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yan...@zte.com.cn Signed-off-by: Sasha Levin --- drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c index 8b6f6d5fdd68b..43186fa8a13c9 100644 --- a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c +++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c @@ -194,7 +194,7 @@ static int __init omapdss_boot_init(void) dss = of_find_matching_node(NULL, omapdss_of_match); if (dss == NULL || !of_device_is_available(dss)) - return 0; + goto put_node; omapdss_walk_device(dss, true); @@ -221,6 +221,8 @@ static int __init omapdss_boot_init(void) kfree(n); } +put_node: + of_node_put(dss); return 0; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 181/330] drm/msm: fix leaks if initialization fails
From: Pavel Machek
[ Upstream commit 66be340f827554cb1c8a1ed7dea97920b4085af2 ]
We should free resources in unlikely case of allocation failure.
Signed-off-by: Pavel Machek
Signed-off-by: Rob Clark
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/msm/msm_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 4558d66761b3c..108632a1f2438 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -444,8 +444,10 @@ static int msm_drm_init(struct device *dev, struct
drm_driver *drv)
if (!dev->dma_parms) {
dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
GFP_KERNEL);
- if (!dev->dma_parms)
- return -ENOMEM;
+ if (!dev->dma_parms) {
+ ret = -ENOMEM;
+ goto err_msm_uninit;
+ }
}
dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 160/330] drm/amd/display: Stop if retimer is not available
From: Rodrigo Siqueira [ Upstream commit a0e40018dcc3f59a10ca21d58f8ea8ceb1b035ac ] Raven provides retimer feature support that requires i2c interaction in order to make it work well, all settings required for this configuration are loaded from the Atom bios which include the i2c address. If the retimer feature is not available, we should abort the attempt to set this feature, otherwise, it makes the following line return I2C_CHANNEL_OPERATION_NO_RESPONSE: i2c_success = i2c_write(pipe_ctx, slave_address, buffer, sizeof(buffer)); ... if (!i2c_success) ASSERT(i2c_success); This ends up causing problems with hotplugging HDMI displays on Raven, and causes retimer settings to warn like so: WARNING: CPU: 1 PID: 429 at drivers/gpu/drm/amd/amdgpu/../dal/dc/core/dc_link.c:1998 write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Modules linked in: edac_mce_amd ccp kvm irqbypass binfmt_misc crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel amdgpu(+) snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel snd_seq amd_iommu_v2 gpu_sched aes_x86_64 crypto_simd cryptd glue_helper snd_seq_device ttm drm_kms_helper snd_timer eeepc_wmi wmi_bmof asus_wmi sparse_keymap drm mxm_wmi snd k10temp fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore joydev input_leds mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 igb i2c_algo_bit hid_generic usbhid i2c_piix4 dca ahci hid libahci video wmi gpio_amdpt gpio_generic CPU: 1 PID: 429 Comm: systemd-udevd Tainted: GW 5.2.0-rc1sept162019+ #1 Hardware name: System manufacturer System Product Name/ROG STRIX B450-F GAMING, BIOS 2605 08/06/2019 RIP: 0010:write_i2c_retimer_setting+0xc2/0x3c0 [amdgpu] Code: ff 0f b6 4d ce 44 0f b6 45 cf 44 0f b6 c8 45 89 cf 44 89 e2 48 c7 c6 f0 34 bc c0 bf 04 00 00 00 e8 63 b0 90 ff 45 84 ff 75 02 <0f> 0b 42 0f b6 04 73 8d 50 f6 80 fa 02 77 8c 3c 0a 0f 85 c8 00 00 RSP: 0018:a99d02726fd0 EFLAGS: 00010246 RAX: RBX: a99d02727035 RCX: 0006 RDX: RSI: 0002 RDI: 976acc857440 RBP: a99d02727018 R08: 0002 R09: 0002a600 R10: e90610193680 R11: 05e3 R12: 005d R13: 976ac4b201b8 R14: 0001 R15: FS: 7f14f99e1680() GS:976acc84() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fdf212843b8 CR3: 000408906000 CR4: 003406e0 Call Trace: core_link_enable_stream+0x626/0x680 [amdgpu] dce110_apply_ctx_to_hw+0x414/0x4e0 [amdgpu] dc_commit_state+0x331/0x5e0 [amdgpu] ? drm_calc_timestamping_constants+0xf9/0x150 [drm] amdgpu_dm_atomic_commit_tail+0x395/0x1e00 [amdgpu] ? dm_plane_helper_prepare_fb+0x20c/0x280 [amdgpu] commit_tail+0x42/0x70 [drm_kms_helper] drm_atomic_helper_commit+0x10c/0x120 [drm_kms_helper] amdgpu_dm_atomic_commit+0x95/0xa0 [amdgpu] drm_atomic_commit+0x4a/0x50 [drm] restore_fbdev_mode_atomic+0x1c0/0x1e0 [drm_kms_helper] restore_fbdev_mode+0x4c/0x160 [drm_kms_helper] ? _cond_resched+0x19/0x40 drm_fb_helper_restore_fbdev_mode_unlocked+0x4e/0xa0 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] fbcon_init+0x471/0x630 visual_init+0xd5/0x130 do_bind_con_driver+0x20a/0x430 do_take_over_console+0x7d/0x1b0 do_fbcon_takeover+0x5c/0xb0 fbcon_event_notify+0x6cd/0x8a0 notifier_call_chain+0x4c/0x70 blocking_notifier_call_chain+0x43/0x60 fb_notifier_call_chain+0x1b/0x20 register_framebuffer+0x254/0x360 __drm_fb_helper_initial_config_and_unlock+0x2c5/0x510 [drm_kms_helper] drm_fb_helper_initial_config+0x35/0x40 [drm_kms_helper] amdgpu_fbdev_init+0xcd/0x100 [amdgpu] amdgpu_device_init+0x1156/0x1930 [amdgpu] amdgpu_driver_load_kms+0x8d/0x2e0 [amdgpu] drm_dev_register+0x12b/0x1c0 [drm] amdgpu_pci_probe+0xd3/0x160 [amdgpu] local_pci_probe+0x47/0xa0 pci_device_probe+0x142/0x1b0 really_probe+0xf5/0x3d0 driver_probe_device+0x11b/0x130 device_driver_attach+0x58/0x60 __driver_attach+0xa3/0x140 ? device_driver_attach+0x60/0x60 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x74/0xb0 ? kmem_cache_alloc_trace+0x1a3/0x1c0 driver_attach+0x1e/0x20 bus_add_driver+0x147/0x220 ? 0xc0cb9000 driver_register+0x60/0x100 ? 0xc0cb9000 __pci_register_driver+0x5a/0x60 amdgpu_init+0x74/0x83 [amdgpu] do_one_initcall+0x4a/0x1fa ? _cond_resched+0x19/0x40 ? kmem_cache_alloc_trace+0x3f/0x1c0 ? __vunmap+0x1cc/0x200 do_init_module+0x5f/0x227 load_module+0x2330/0x2b40 __do_sys_finit_module+0xfc/0x120 ? __do_sys_finit_module+0xfc/0x120 __x64_sys_finit_module+0x1a/0x20 do_syscall_64+0x5a/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f14f9500839 Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f
[PATCH AUTOSEL 5.4 154/330] drm/amd/display: fix image corruption with ODM 2:1 DSC 2 slice
From: Wenjing Liu
[ Upstream commit df8e34ac27e8a0d8dce364628226c5619693c3fd ]
[why]
When combining two or more pipes in DSC mode, there will always be more
than 1 slice per line. In this case, as per DSC rules, the sink device
is expecting that the ICH is reset at the end of each slice line (i.e.
ICH_RESET_AT_END_OF_LINE must be configured based on the number of
slices at the output of ODM). It is recommended that software set
ICH_RESET_AT_END_OF_LINE = 0xF for each DSC in the ODM combine. However
the current code only set ICH_RESET_AT_END_OF_LINE = 0xF when number of
slice per DSC engine is greater than 1 instead of number of slice per
output after ODM combine.
[how]
Add is_odm in dsc config. Set ICH_RESET_AT_END_OF_LINE = 0xF if either
is_odm or number of slice per DSC engine is greater than 1.
Signed-off-by: Wenjing Liu
Reviewed-by: Nikola Cornij
Acked-by: Rodrigo Siqueira
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c| 2 ++
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c | 2 +-
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 1 +
drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h | 1 +
4 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
index 5d6cbaebebc03..5641a9477d291 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_hwss.c
@@ -400,6 +400,7 @@ void dp_set_dsc_on_stream(struct pipe_ctx *pipe_ctx, bool
enable)
dsc_cfg.pic_height = stream->timing.v_addressable +
stream->timing.v_border_top + stream->timing.v_border_bottom;
dsc_cfg.pixel_encoding = stream->timing.pixel_encoding;
dsc_cfg.color_depth = stream->timing.display_color_depth;
+ dsc_cfg.is_odm = pipe_ctx->next_odm_pipe ? true : false;
dsc_cfg.dc_dsc_cfg = stream->timing.dsc_cfg;
ASSERT(dsc_cfg.dc_dsc_cfg.num_slices_h % opp_cnt == 0);
dsc_cfg.dc_dsc_cfg.num_slices_h /= opp_cnt;
@@ -504,6 +505,7 @@ bool dp_set_dsc_pps_sdp(struct pipe_ctx *pipe_ctx, bool
enable)
dsc_cfg.pic_height = stream->timing.v_addressable +
stream->timing.v_border_top + stream->timing.v_border_bottom;
dsc_cfg.pixel_encoding = stream->timing.pixel_encoding;
dsc_cfg.color_depth = stream->timing.display_color_depth;
+ dsc_cfg.is_odm = pipe_ctx->next_odm_pipe ? true : false;
dsc_cfg.dc_dsc_cfg = stream->timing.dsc_cfg;
DC_LOG_DSC(" ");
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
index 01040501d40e3..5c45c39662fbb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.c
@@ -351,6 +351,7 @@ static bool dsc_prepare_config(const struct dsc_config
*dsc_cfg, struct dsc_reg_
dsc_reg_vals->pps.block_pred_enable =
dsc_cfg->dc_dsc_cfg.block_pred_enable;
dsc_reg_vals->pps.line_buf_depth = dsc_cfg->dc_dsc_cfg.linebuf_depth;
dsc_reg_vals->alternate_ich_encoding_en =
dsc_reg_vals->pps.dsc_version_minor == 1 ? 0 : 1;
+ dsc_reg_vals->ich_reset_at_eol = (dsc_cfg->is_odm ||
dsc_reg_vals->num_slices_h > 1) ? 0xF : 0;
// TODO: in addition to validating slice height (pic height must be
divisible by slice height),
// see what happens when the same condition doesn't apply for
slice_width/pic_width.
@@ -513,7 +514,6 @@ static void dsc_update_from_dsc_parameters(struct
dsc_reg_values *reg_vals, cons
reg_vals->pps.rc_buf_thresh[i] = reg_vals->pps.rc_buf_thresh[i]
>> 6;
reg_vals->rc_buffer_model_size = dsc_params->rc_buffer_model_size;
- reg_vals->ich_reset_at_eol = reg_vals->num_slices_h == 1 ? 0 : 0xf;
}
static void dsc_write_to_registers(struct display_stream_compressor *dsc,
const struct dsc_reg_values *reg_vals)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
index 05b98eadc2899..bfa01137f8e09 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
@@ -2275,6 +2275,7 @@ static bool dcn20_validate_dsc(struct dc *dc, struct
dc_state *new_ctx)
+ stream->timing.v_border_bottom;
dsc_cfg.pixel_encoding = stream->timing.pixel_encoding;
dsc_cfg.color_depth = stream->timing.display_color_depth;
+ dsc_cfg.is_odm = pipe_ctx->next_odm_pipe ? true : false;
dsc_cfg.dc_dsc_cfg = stream->timing.dsc_cfg;
dsc_cfg.dc_dsc_cfg.num_slices_h /= opp_cnt;
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h
b/drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h
index
[PATCH AUTOSEL 5.4 144/330] drm/omap: dss: Cleanup DSS ports on initialisation failure
From: Laurent Pinchart
[ Upstream commit 2a0a3ae17d36fa86dcf7c8e8d7b7f056ebd6c064 ]
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
Signed-off-by: Tomi Valkeinen
Link:
https://patchwork.freedesktop.org/patch/msgid/20200226112514.12455-22-laurent.pinch...@ideasonboard.com
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/omapdrm/dss/dss.c | 43 +++
1 file changed, 26 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 4bdd63b571002..ac93dae2a9c84 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1151,46 +1151,38 @@ static const struct dss_features dra7xx_dss_feats = {
.has_lcd_clk_src= true,
};
-static int dss_init_ports(struct dss_device *dss)
+static void __dss_uninit_ports(struct dss_device *dss, unsigned int num_ports)
{
struct platform_device *pdev = dss->pdev;
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
unsigned int i;
- int r;
- for (i = 0; i < dss->feat->num_ports; i++) {
+ for (i = 0; i < num_ports; i++) {
port = of_graph_get_port_by_id(parent, i);
if (!port)
continue;
switch (dss->feat->ports[i]) {
case OMAP_DISPLAY_TYPE_DPI:
- r = dpi_init_port(dss, pdev, port, dss->feat->model);
- if (r)
- return r;
+ dpi_uninit_port(port);
break;
-
case OMAP_DISPLAY_TYPE_SDI:
- r = sdi_init_port(dss, pdev, port);
- if (r)
- return r;
+ sdi_uninit_port(port);
break;
-
default:
break;
}
}
-
- return 0;
}
-static void dss_uninit_ports(struct dss_device *dss)
+static int dss_init_ports(struct dss_device *dss)
{
struct platform_device *pdev = dss->pdev;
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
- int i;
+ unsigned int i;
+ int r;
for (i = 0; i < dss->feat->num_ports; i++) {
port = of_graph_get_port_by_id(parent, i);
@@ -1199,15 +1191,32 @@ static void dss_uninit_ports(struct dss_device *dss)
switch (dss->feat->ports[i]) {
case OMAP_DISPLAY_TYPE_DPI:
- dpi_uninit_port(port);
+ r = dpi_init_port(dss, pdev, port, dss->feat->model);
+ if (r)
+ goto error;
break;
+
case OMAP_DISPLAY_TYPE_SDI:
- sdi_uninit_port(port);
+ r = sdi_init_port(dss, pdev, port);
+ if (r)
+ goto error;
break;
+
default:
break;
}
}
+
+ return 0;
+
+error:
+ __dss_uninit_ports(dss, i);
+ return r;
+}
+
+static void dss_uninit_ports(struct dss_device *dss)
+{
+ __dss_uninit_ports(dss, dss->feat->num_ports);
}
static int dss_video_pll_probe(struct dss_device *dss)
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 143/330] drm/amd/display: dal_ddc_i2c_payloads_create can fail causing panic
From: Aric Cyr
[ Upstream commit 6a6c4a4d459ecacc9013c45dcbf2bc9747fdbdbd ]
[Why]
Since the i2c payload allocation can fail need to check return codes
[How]
Clean up i2c payload allocations and check for errors
Signed-off-by: Aric Cyr
Reviewed-by: Joshua Aberback
Acked-by: Rodrigo Siqueira
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/core/dc_link_ddc.c | 52 +--
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 51991bf26a93c..4c90d68db2307 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -126,22 +126,16 @@ struct aux_payloads {
struct vector payloads;
};
-static struct i2c_payloads *dal_ddc_i2c_payloads_create(struct dc_context
*ctx, uint32_t count)
+static bool dal_ddc_i2c_payloads_create(
+ struct dc_context *ctx,
+ struct i2c_payloads *payloads,
+ uint32_t count)
{
- struct i2c_payloads *payloads;
-
- payloads = kzalloc(sizeof(struct i2c_payloads), GFP_KERNEL);
-
- if (!payloads)
- return NULL;
-
if (dal_vector_construct(
>payloads, ctx, count, sizeof(struct i2c_payload)))
- return payloads;
-
- kfree(payloads);
- return NULL;
+ return true;
+ return false;
}
static struct i2c_payload *dal_ddc_i2c_payloads_get(struct i2c_payloads *p)
@@ -154,14 +148,12 @@ static uint32_t dal_ddc_i2c_payloads_get_count(struct
i2c_payloads *p)
return p->payloads.count;
}
-static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads **p)
+static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads *p)
{
- if (!p || !*p)
+ if (!p)
return;
- dal_vector_destruct(&(*p)->payloads);
- kfree(*p);
- *p = NULL;
+ dal_vector_destruct(>payloads);
}
#define DDC_MIN(a, b) (((a) < (b)) ? (a) : (b))
@@ -521,9 +513,13 @@ bool dal_ddc_service_query_ddc_data(
uint32_t payloads_num = write_payloads + read_payloads;
+
if (write_size > EDID_SEGMENT_SIZE || read_size > EDID_SEGMENT_SIZE)
return false;
+ if (!payloads_num)
+ return false;
+
/*TODO: len of payload data for i2c and aux is uint8,
* but we want to read 256 over i2c*/
if (dal_ddc_service_is_in_aux_transaction_mode(ddc)) {
@@ -556,23 +552,25 @@ bool dal_ddc_service_query_ddc_data(
ret = dc_link_aux_transfer_with_retries(ddc, _payload);
} else {
- struct i2c_payloads *payloads =
- dal_ddc_i2c_payloads_create(ddc->ctx, payloads_num);
+ struct i2c_command command = {0};
+ struct i2c_payloads payloads;
+
+ if (!dal_ddc_i2c_payloads_create(ddc->ctx, ,
payloads_num))
+ return false;
- struct i2c_command command = {
- .payloads = dal_ddc_i2c_payloads_get(payloads),
- .number_of_payloads = 0,
- .engine = DDC_I2C_COMMAND_ENGINE,
- .speed = ddc->ctx->dc->caps.i2c_speed_in_khz };
+ command.payloads = dal_ddc_i2c_payloads_get();
+ command.number_of_payloads = 0;
+ command.engine = DDC_I2C_COMMAND_ENGINE;
+ command.speed = ddc->ctx->dc->caps.i2c_speed_in_khz;
dal_ddc_i2c_payloads_add(
- payloads, address, write_size, write_buf, true);
+ , address, write_size, write_buf, true);
dal_ddc_i2c_payloads_add(
- payloads, address, read_size, read_buf, false);
+ , address, read_size, read_buf, false);
command.number_of_payloads =
- dal_ddc_i2c_payloads_get_count(payloads);
+ dal_ddc_i2c_payloads_get_count();
ret = dm_helpers_submit_i2c(
ddc->ctx,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 5.4 158/330] drm/amdgpu: increase atombios cmd timeout
From: John Clements
[ Upstream commit 1b3460a8b19688ad3033b75237d40fa580a5a953 ]
mitigates race condition on BACO reset between GPU bootcode and driver reload
Reviewed-by: Hawking Zhang
Signed-off-by: John Clements
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c
b/drivers/gpu/drm/amd/amdgpu/atom.c
index dd30f4e61a8cd..cae426c7c0863 100644
--- a/drivers/gpu/drm/amd/amdgpu/atom.c
+++ b/drivers/gpu/drm/amd/amdgpu/atom.c
@@ -744,8 +744,8 @@ static void atom_op_jump(atom_exec_context *ctx, int *ptr,
int arg)
cjiffies = jiffies;
if (time_after(cjiffies, ctx->last_jump_jiffies)) {
cjiffies -= ctx->last_jump_jiffies;
- if ((jiffies_to_msecs(cjiffies) > 5000)) {
- DRM_ERROR("atombios stuck in loop for
more than 5secs aborting\n");
+ if ((jiffies_to_msecs(cjiffies) > 1)) {
+ DRM_ERROR("atombios stuck in loop for
more than 10secs aborting\n");
ctx->abort = true;
}
} else {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH AUTOSEL 4.19 090/206] drm/amd/display: dal_ddc_i2c_payloads_create can fail causing panic
From: Aric Cyr
[ Upstream commit 6a6c4a4d459ecacc9013c45dcbf2bc9747fdbdbd ]
[Why]
Since the i2c payload allocation can fail need to check return codes
[How]
Clean up i2c payload allocations and check for errors
Signed-off-by: Aric Cyr
Reviewed-by: Joshua Aberback
Acked-by: Rodrigo Siqueira
Acked-by: Harry Wentland
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
.../gpu/drm/amd/display/dc/core/dc_link_ddc.c | 52 +--
1 file changed, 25 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
index 46c9cb47a96e5..145af3bb2dfcb 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c
@@ -127,22 +127,16 @@ struct aux_payloads {
struct vector payloads;
};
-static struct i2c_payloads *dal_ddc_i2c_payloads_create(struct dc_context
*ctx, uint32_t count)
+static bool dal_ddc_i2c_payloads_create(
+ struct dc_context *ctx,
+ struct i2c_payloads *payloads,
+ uint32_t count)
{
- struct i2c_payloads *payloads;
-
- payloads = kzalloc(sizeof(struct i2c_payloads), GFP_KERNEL);
-
- if (!payloads)
- return NULL;
-
if (dal_vector_construct(
>payloads, ctx, count, sizeof(struct i2c_payload)))
- return payloads;
-
- kfree(payloads);
- return NULL;
+ return true;
+ return false;
}
static struct i2c_payload *dal_ddc_i2c_payloads_get(struct i2c_payloads *p)
@@ -155,14 +149,12 @@ static uint32_t dal_ddc_i2c_payloads_get_count(struct
i2c_payloads *p)
return p->payloads.count;
}
-static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads **p)
+static void dal_ddc_i2c_payloads_destroy(struct i2c_payloads *p)
{
- if (!p || !*p)
+ if (!p)
return;
- dal_vector_destruct(&(*p)->payloads);
- kfree(*p);
- *p = NULL;
+ dal_vector_destruct(>payloads);
}
static struct aux_payloads *dal_ddc_aux_payloads_create(struct dc_context
*ctx, uint32_t count)
@@ -580,9 +572,13 @@ bool dal_ddc_service_query_ddc_data(
uint32_t payloads_num = write_payloads + read_payloads;
+
if (write_size > EDID_SEGMENT_SIZE || read_size > EDID_SEGMENT_SIZE)
return false;
+ if (!payloads_num)
+ return false;
+
/*TODO: len of payload data for i2c and aux is uint8,
* but we want to read 256 over i2c*/
if (dal_ddc_service_is_in_aux_transaction_mode(ddc)) {
@@ -613,23 +609,25 @@ bool dal_ddc_service_query_ddc_data(
dal_ddc_aux_payloads_destroy();
} else {
- struct i2c_payloads *payloads =
- dal_ddc_i2c_payloads_create(ddc->ctx, payloads_num);
+ struct i2c_command command = {0};
+ struct i2c_payloads payloads;
- struct i2c_command command = {
- .payloads = dal_ddc_i2c_payloads_get(payloads),
- .number_of_payloads = 0,
- .engine = DDC_I2C_COMMAND_ENGINE,
- .speed = ddc->ctx->dc->caps.i2c_speed_in_khz };
+ if (!dal_ddc_i2c_payloads_create(ddc->ctx, ,
payloads_num))
+ return false;
+
+ command.payloads = dal_ddc_i2c_payloads_get();
+ command.number_of_payloads = 0;
+ command.engine = DDC_I2C_COMMAND_ENGINE;
+ command.speed = ddc->ctx->dc->caps.i2c_speed_in_khz;
dal_ddc_i2c_payloads_add(
- payloads, address, write_size, write_buf, true);
+ , address, write_size, write_buf, true);
dal_ddc_i2c_payloads_add(
- payloads, address, read_size, read_buf, false);
+ , address, read_size, read_buf, false);
command.number_of_payloads =
- dal_ddc_i2c_payloads_get_count(payloads);
+ dal_ddc_i2c_payloads_get_count();
ret = dm_helpers_submit_i2c(
ddc->ctx,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
