Re: [Intel-gfx] [PATCH] drm/debugfs: Fix framebuffer debugfs file init
On 14 November 2017 at 09:12, Noralf Trønnes wrote: > The introduction of: drm/framebuffer: Add framebuffer debugfs file > broke vgem. That patch assumed that all drivers had initialized the > dev->mode_config.fb_lock mutex which happens in drm_mode_config_init(). > vgem doesn't need to call drm_mode_config_init(). > > Fix this by only creating the framebuffer debugfs file for modesetting > drivers. > > Fixes: 45d58b40292b ("drm/framebuffer: Add framebuffer debugfs file") > Suggested-by: Chris Wilson > Signed-off-by: Noralf Trønnes Reviewed-by: Dave Airlie Can someone pushed this to drm-misc, I think it's blocking the intel CI ppl. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tilcdc: uninitialized variable in tilcdc_get_overlay()
The code seems to assume that of_fdt_unflatten_tree() sets "overlay" to NULL on error but actually it could be uninitialized. Fixes: 4e7221580223 ("drm/tilcdc: Add DRM_TILCDC_SLAVE_COMPAT for ti,tilcdc,slave binding support") Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c index d2b9e5f04724..a8a70b36f0ff 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c @@ -144,7 +144,7 @@ static struct device_node * __init tilcdc_get_overlay(struct kfree_table *kft) const int size = __dtb_tilcdc_slave_compat_end - __dtb_tilcdc_slave_compat_begin; static void *overlay_data; - struct device_node *overlay; + struct device_node *overlay = NULL; if (!size) { pr_warn("%s: No overlay data\n", __func__); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] OMAPFB: prevent buffer underflow in omapfb_parse_vram_param()
We cap the upper bound of "fbnum" but we also need to check for negatives or make the type unsigned. Signed-off-by: Dan Carpenter diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c index 1d7c012f09db..e08e5664e330 100644 --- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c +++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c @@ -1477,7 +1477,7 @@ static int omapfb_alloc_fbmem_display(struct fb_info *fbi, unsigned long size, static int omapfb_parse_vram_param(const char *param, int max_entries, unsigned long *sizes, unsigned long *paddrs) { - int fbnum; + unsigned int fbnum; unsigned long size; unsigned long paddr = 0; char *p, *start; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] exynos-drm-next
On 26 October 2017 at 11:37, Inki Dae wrote: > Hi Dave, > >Improving Exynos DRM HDMI and Mixer drivers and also adding >HDMI audio support. > >Please kindly let me know if there is any problem. > >Ps. we are reviewing IPP v2 driver[1] which controls post processor devices >such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to request >git pull one more time after review. Hi Inki, I dropped the ball a bit here, I do think the second pull with IPP is probably a bit late, I think I'd like more assurance that the UAPI for IPP is to be used in some upstream shipping project (forks of mpv not withstanding, unless this fork ships in some distro or product). I unfortunately forgot to pull this one, I've rectified that and it is now in drm-next. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline
On 11/14/2017 02:33 AM, Eric Anholt wrote: Lothar Waßmann writes: Hi, On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote: Lothar Waßmann writes: Hi, drivers/gpu/drm/bridge/lvds-encoder.c driver is currently dysfunctional due to: |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6 |Author: Eric Anholt |Date: Fri Jun 2 13:25:14 2017 -0700 | |drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge. Also, there is no in-kernel user of this driver, so that it obviously doesn't get tested in any way. There is only one dts file (r8a7779-marzen.dts) that instantiates this driver, but it has an incomplete OF graph. The missing link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in the kernel source. Should the driver be removed or moved to staging, until it is properly fixed? I can't see any behavior change about the DT handling in that commit, and I didn't intend for there to be any. Could you help me understand what went wrong? With the offending commit applied, the lvds-encoder driver is being attached to the device associated with the lcd-panel driver's of_node (panel-simple in my case) rather than the lvds-encoder's of_node. Anyone have any thoughts on best handling this? Slip another bridge in attached to this of_node that chains to panel-bridge's bridge, or just have a panel-bridge entrypoint for what node to register the bridge on? I think slipping in another bridge seems to make more sense. When we converted to panel-bridge, we didn't create a bridge entity for the lvds-encoder itself, we just created the panel-bridge's bridge, which anyway is more a glue-layer for drm_panel than a real bridge entity. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP
Hi Liviu, On Monday, 13 November 2017 13:53:14 EET Liviu Dudau wrote: > On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote: > > When the DU sources its frames from a VSP, it performs no memory access > > and thus has no requirements on imported dma-buf memory types. In > > particular the DU could import a physically non-contiguous buffer that > > would later be mapped contiguously through the VSP IOMMU. > > > > This use case isn't supported at the moment as the GEM CMA helpers will > > reject any non-contiguous buffer, and the DU isn't connected to an IOMMU > > that can make the buffer contiguous for DMA. Fix this by implementing a > > custom .gem_prime_import_sg_table() operation that accepts all imported > > dma-buf regardless of the number of scatterlist entries. > > This patch raises the question of why use CMA at all if you can accept > any kind of buffers. Both the DU and VSP require DMA contiguous memory. On R-Car Gen2 the DU performs DMA, and thus uses the GEM CMA helpers. On Gen3 it delegates DMA to the external VSP composer, and still uses the GEM CMA helpers to ensure that memory will be DMA contiguous for the VSP. The problem arises when physically non-contiguous dma-buf buffers are imported, they can be mapped contiguously to the VSP (assuming an IOMMU is present) but not to the DU (as there's no IOMMU). The situation is particularly messy due to the fact that I have one VSP instance per CRTC, each connected to its own IOMMU channel. The driver thus doesn't know when allocating GEM objects to which struct device they need to be mapped. The DRM helpers don't support delayed mapping of memory. I'd like to know whether that's something I should fix properly (which would likely involve major reworking of the helpers) or hack around it in the DU driver. > > Signed-off-by: Laurent Pinchart > > > > --- > > > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 ++ > > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 7 +++ > > 3 files changed, 47 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 48c166f925a3..d999231f98c7 > > 100644 > > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > > @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = { > > .gem_prime_import = drm_gem_prime_import, > > .gem_prime_export = drm_gem_prime_export, > > .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, > > - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, > > + .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table, > > .gem_prime_vmap = drm_gem_cma_prime_vmap, > > .gem_prime_vunmap = drm_gem_cma_prime_vunmap, > > .gem_prime_mmap = drm_gem_cma_prime_mmap, > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 566d1a948c8f..2dd0c2ba047d > > 100644 > > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c [snip] > > +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct > > drm_device *dev, > > + struct dma_buf_attachment *attach, > > + struct sg_table *sgt) > > +{ > > + struct rcar_du_device *rcdu = dev->dev_private; > > + struct drm_gem_cma_object *cma_obj; > > + struct drm_gem_object *gem_obj; > > + int ret; > > + > > + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) > > + return drm_gem_cma_prime_import_sg_table(dev, attach, sgt); > > + > > + /* Create a CMA GEM buffer. */ > > + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL); > > + if (!cma_obj) > > + return ERR_PTR(-ENOMEM); > > + gem_obj = &cma_obj->base; > > + > > + ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size); > > + if (ret) > > + goto error; > > + > > + ret = drm_gem_create_mmap_offset(gem_obj); > > + if (ret) { > > + drm_gem_object_release(gem_obj); > > + goto error; > > + } > > + > > + cma_obj->paddr = 0; > > This is going to break drm_gem_cma_describe() if you are using it As far as I can tell drm_gem_cma_describe() will just print paddr = 0, it won't crash. > plus the rcar_du_plane_setup_scanout() unless I'm missing something besides > familiarity with the RCAR driver code :) rcar_du_plane_setup_scanout() is only called when !rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE) (that is on Gen3 hardware, or on Gen2 when I artificially disable all DMA from the DU and use external composers to emulate Gen3 behaviour for testing purpose), in which case this function calls drm_gem_cma_prime_import_sg_table(). > This function looks very similar to what I tried to do for mali-dp to > allow the import of contiguous DMA buffers that have more than 1 sgt > entries. In the end I gav
Re: [PATCH 2/2] drm/ttm: optimize ttm_mem_evict_first v4
On 2017年11月13日 17:54, Christian König wrote: Deleted BOs with the same reservation object can be reaped even if they can't be reserved. v2: rebase and we still need to remove/add the BO from/to the LRU. v3: fix remove/add one more time, cleanup the logic a bit v4: we should still check if the eviction is valuable Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 54 +++- 1 file changed, 33 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 691646c0f8d3..7b1525d39ea8 100644 --- a/drivers/gpu/drm/ttm/ttm_bo.c +++ b/drivers/gpu/drm/ttm/ttm_bo.c @@ -738,47 +738,57 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object *bo, EXPORT_SYMBOL(ttm_bo_eviction_valuable); static int ttm_mem_evict_first(struct ttm_bo_device *bdev, - uint32_t mem_type, - const struct ttm_place *place, - bool interruptible, - bool no_wait_gpu) + struct reservation_object *resv, + uint32_t mem_type, + const struct ttm_place *place, + bool interruptible, + bool no_wait_gpu) { struct ttm_bo_global *glob = bdev->glob; struct ttm_mem_type_manager *man = &bdev->man[mem_type]; - struct ttm_buffer_object *bo; - int ret = -EBUSY; + struct ttm_buffer_object *bo = NULL; + bool locked = false; unsigned i; + int ret; spin_lock(&glob->lru_lock); for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) { list_for_each_entry(bo, &man->lru[i], lru) { - ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY; - if (ret) - continue; + if (bo->resv == resv) { + if (list_empty(&bo->ddestroy)) + continue; Do you have further patches for enabling eviction and swapout for allocation? Regards, David Zhou + + } else { + locked = reservation_object_trylock(bo->resv); + if (!locked) + continue; + } if (place && !bdev->driver->eviction_valuable(bo, place)) { - reservation_object_unlock(bo->resv); - ret = -EBUSY; + if (locked) + reservation_object_unlock(bo->resv); continue; } - break; } - if (!ret) + if (&bo->lru != &man->lru[i]) break; + else + bo = NULL; } - if (ret) { + if (!bo) { spin_unlock(&glob->lru_lock); - return ret; + return -EBUSY; } kref_get(&bo->list_kref); if (!list_empty(&bo->ddestroy)) { - ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true); + ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, + locked); kref_put(&bo->list_kref, ttm_bo_release_list); return ret; } @@ -786,10 +796,11 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev, ttm_bo_del_from_lru(bo); spin_unlock(&glob->lru_lock); - BUG_ON(ret != 0); - ret = ttm_bo_evict(bo, interruptible, no_wait_gpu); - ttm_bo_unreserve(bo); + if (locked) + ttm_bo_unreserve(bo); + else + ttm_bo_add_to_lru(bo); kref_put(&bo->list_kref, ttm_bo_release_list); return ret; @@ -853,7 +864,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo, return ret; if (mem->mm_node) break; - ret = ttm_mem_evict_first(bdev, mem_type, place, + ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place, interruptible, no_wait_gpu); if (unlikely(ret != 0)) return ret; @@ -1356,7 +1367,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev, for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) { while (!list_empty(&man->lru[i])) { spin_unlock(&glob->lru_lock); - ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, false); + ret = ttm_mem_evict_first(bdev, NULL, mem_type, NULL, +
[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 1/16] drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:9: error: implicit declaration of function 'ttm_populate_and_map_pages'; did you mean 'vmem
tree: git://people.freedesktop.org/~agd5f/linux.git upstream-4.14-drm-next-amd-dc-staging-chrome head: 4448b9a68413462529d018050cd246bc33957bd6 commit: a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 [1/16] FORKLIFT: amd: copy amd folder as is from dave airlie tree config: arm64-allyesconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 # save the attached .config to linux build tree make.cross ARCH=arm64 Note: the radeon-alex/upstream-4.14-drm-next-amd-dc-staging-chrome HEAD 4448b9a68413462529d018050cd246bc33957bd6 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 'amdgpu_ttm_tt_populate': >> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:9: error: implicit declaration >> of function 'ttm_populate_and_map_pages'; did you mean >> 'vmemmap_populate_basepages'? [-Werror=implicit-function-declaration] return ttm_populate_and_map_pages(adev->dev, >t->ttm); ^~ vmemmap_populate_basepages drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 'amdgpu_ttm_tt_unpopulate': >> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:995:2: error: implicit declaration >> of function 'ttm_unmap_and_unpopulate_pages'; did you mean >> 'ttm_dma_unpopulate'? [-Werror=implicit-function-declaration] ttm_unmap_and_unpopulate_pages(adev->dev, >t->ttm); ^~ ttm_dma_unpopulate cc1: some warnings being treated as errors -- drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_object_open': >> drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: error: >> 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function); >> did you mean 'AMDGPU_GEM_CREATE_VRAM_CLEARED'? if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID && ^ AMDGPU_GEM_CREATE_VRAM_CLEARED drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_create_ioctl': drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:215:9: error: 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function); did you mean 'AMDGPU_GEM_CREATE_VRAM_CLEARED'? AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) ^ AMDGPU_GEM_CREATE_VRAM_CLEARED drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_op_ioctl': drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:718:21: error: 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function); did you mean 'AMDGPU_GEM_CREATE_VRAM_CLEARED'? if (robj->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID) ^ AMDGPU_GEM_CREATE_VRAM_CLEARED -- drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_fence_to_handle_ioctl': drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1348:47: error: dereferencing pointer to incomplete type 'union drm_amdgpu_fence_to_handle' fence = amdgpu_cs_get_fence(adev, filp, &info->in.fence); ^~ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: error: 'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ' undeclared (first use in this function); did you mean 'AMDGPU_FENCE_FLAG_INT'? case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ: ^~ AMDGPU_FENCE_FLAG_INT drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: note: each undeclared identifier is reported only once for each function it appears in >> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1354:7: error: implicit declaration >> of function 'drm_syncobj_create'; did you mean 'drm_syncobj_free'? >> [-Werror=implicit-function-declaration] r = drm_syncobj_create(&syncobj, 0, fence); ^~ drm_syncobj_free >> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1358:7: error: implicit declaration >> of function 'drm_syncobj_get_handle'; did you mean 'drm_syncobj_get'? >> [-Werror=implicit-function-declaration] r = drm_syncobj_get_handle(filp, syncobj, &info->out.handle); ^~ drm_syncobj_get drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1362:7: error: 'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD' undeclared (first use in this function); did you mean 'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ'? case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD: ^ AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ >> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1367:7: error: imp
[Bug 103726] GPU crashes freezing the system and weird rendering issues on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=103726 Bug ID: 103726 Summary: GPU crashes freezing the system and weird rendering issues on CAYMAN Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: v10la...@myway.de QA Contact: dri-devel@lists.freedesktop.org I'm not really sure how to describe this bug. It is so random, sometimes I'm not sure if exists as nothing happens in weeks, then it happenes all 10 minutes. I'm hunting this bug for so long, can't tell if a year or two or even more. Some (if not all?) games are triggering weird behavior on a Radeon HD 6950. What happens is the screen changing to green with some check pattern (sorry for having no picture but screenshoting is impossible and I never had a camera at hand). Before the driver was able to do a GPU reset (now you get how old this bug is) it was staying there but with modern kernels the drivers seems to try a reset (monitor flickering for a moment) after some time and then all I get is a black screen (not no-signal, a black image) at that time the only way to recover the PC is by pressing the reset button. Now since a few days I'm playing Dead Island and it seems to be a good trigger for the bug ("good" means the game seems to trigger it in between a few seconds and 6 hours of gameplay. Make sure to have a lot of freetime if you try to recreate) so I decided to try to hunt it again. For that I started the game with R600_DEBUG=nosb,nohyperz and played for around 3 hours before I got bored. Then I switched back to the desktop and noticed that everything got broken: Flickering and/or invisible windows, hanging menue, the complete desktop hanging and so on (I tried to take a video but it's corrupted: [ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: moov atom not found) ). When the desktio corruted there's nothing in the logs except kernel: radeon_dp_aux_transfer_native: 32 callbacks suppressed but that should be harmless, shouldn't it? When the green screen comes there#s also nothing in the logs, but that's most likely because the system froze before it could flush it to disc as the logs are incomlete im that case. This bug might or might not be the same as https://bugs.freedesktop.org/show_bug.cgi?id=92555 - I really can't tell but if it's the same: Could it be a regresion introduced by splitting r600 and radeonsi? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vc4: Account for interrupts in flight
Stefan Schake writes: > Synchronously disable the IRQ to make the following cancel_work_sync > invocation effective. > > An interrupt in flight could enqueue further overflow mem work. As we > free the binner BO immediately following vc4_irq_uninstall this caused > a NULL pointer dereference in the work callback vc4_overflow_mem_work. > > Link: https://github.com/anholt/linux/issues/114 > Signed-off-by: Stefan Schake > Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.") Reviewed and applied this one. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101978] [bisected] war thunder performance reduced by ~28%
https://bugs.freedesktop.org/show_bug.cgi?id=101978 --- Comment #7 from higu...@gmx.net --- >Also, there are amdgpu kernel driver changes lined up for 4.14 that might help. Updates to 4.14 and i fail to see any improvement, sclk is still low, performance is still very low for what this card is capable. Or is there any new setting that i have to enable/change to get a possible improvement -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 1/16] drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:2: error: implicit declaration of function 'ttm_populate_and_map_pages'
tree: git://people.freedesktop.org/~agd5f/linux.git upstream-4.14-drm-next-amd-dc-staging-chrome head: 4448b9a68413462529d018050cd246bc33957bd6 commit: a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 [1/16] FORKLIFT: amd: copy amd folder as is from dave airlie tree config: x86_64-randconfig-g0-11140757 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout a9aa2210cd8aadeea91c845a0a05510d2a91ffa6 # save the attached .config to linux build tree make ARCH=x86_64 Note: the radeon-alex/upstream-4.14-drm-next-amd-dc-staging-chrome HEAD 4448b9a68413462529d018050cd246bc33957bd6 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 'amdgpu_ttm_tt_populate': >> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:967:2: error: implicit declaration >> of function 'ttm_populate_and_map_pages' >> [-Werror=implicit-function-declaration] return ttm_populate_and_map_pages(adev->dev, >t->ttm); ^ drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function 'amdgpu_ttm_tt_unpopulate': >> drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:995:2: error: implicit declaration >> of function 'ttm_unmap_and_unpopulate_pages' >> [-Werror=implicit-function-declaration] ttm_unmap_and_unpopulate_pages(adev->dev, >t->ttm); ^ cc1: some warnings being treated as errors -- drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_object_open': >> drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: error: >> 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function) if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID && ^ drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:123:19: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_create_ioctl': drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:215:9: error: 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function) AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)) ^ drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c: In function 'amdgpu_gem_op_ioctl': drivers/gpu//drm/amd/amdgpu/amdgpu_gem.c:718:21: error: 'AMDGPU_GEM_CREATE_VM_ALWAYS_VALID' undeclared (first use in this function) if (robj->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID) ^ -- drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_fence_to_handle_ioctl': drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1348:47: error: dereferencing pointer to incomplete type fence = amdgpu_cs_get_fence(adev, filp, &info->in.fence); ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1352:14: error: dereferencing pointer to incomplete type switch (info->in.what) { ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: error: 'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ' undeclared (first use in this function) case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ: ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1353:7: note: each undeclared identifier is reported only once for each function it appears in >> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1354:3: error: implicit declaration >> of function 'drm_syncobj_create' [-Werror=implicit-function-declaration] r = drm_syncobj_create(&syncobj, 0, fence); ^ >> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1358:3: error: implicit declaration >> of function 'drm_syncobj_get_handle' [-Werror=implicit-function-declaration] r = drm_syncobj_get_handle(filp, syncobj, &info->out.handle); ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1358:50: error: dereferencing pointer to incomplete type r = drm_syncobj_get_handle(filp, syncobj, &info->out.handle); ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1362:7: error: 'AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD' undeclared (first use in this function) case AMDGPU_FENCE_TO_HANDLE_GET_SYNCOBJ_FD: ^ >> drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1367:3: error: implicit declaration >> of function 'drm_syncobj_get_fd' [-Werror=implicit-function-declaration] r = drm_syncobj_get_fd(syncobj, (int*)&info->out.handle); ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1367:46: error: dereferencing pointer to incomplete type r = drm_syncobj_get_fd(syncobj, (int*)&info->out.handle); ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1371:7: error: 'AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD' undeclared (first use in this function) case AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD: ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1386:7: error: dereferencing pointer to incomplete type info->out.handle = fd; ^ drivers/gpu//drm/amd/amdgpu/amdgpu_cs.c:1392:1: warning: control reaches end of non-void funct
[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=99801 Matthew Treinish changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #20 from Matthew Treinish --- Ok, I built a kernel from Alex's amd-staging-drm-next tree https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next the head of the tree was: eee12cc2150b932ee52ccf89de611a7ba030eb90 drm/amdgpu/virt: remove redundant variable pf2vf_ver and I confirmed that dc is loaded by checking for: [ 10.330032] [drm] Display Core initialized! in dmesg. But the problem still persists. Although instead of 4 segments in each corner like before, there are only 2 now. I've attached the dmesg output (grepped for drm) and I can provide any additional debug information needed. Just let me know and I'll gladly do what I can to help. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=99801 Matthew Treinish changed: What|Removed |Added Attachment #129571|0 |1 is obsolete|| Attachment #129575|0 |1 is obsolete|| --- Comment #19 from Matthew Treinish --- Created attachment 135442 --> https://bugs.freedesktop.org/attachment.cgi?id=135442&action=edit dmesg output (grepped for 'drm') from kernel running eee12cc2150b -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: Ensure interrupts are disabled
Stefan Schake writes: > The overflow mem work callback vc4_overflow_mem_work reenables its > associated interrupt upon completion. To ensure all interrupts are disabled > when we return from vc4_irq_uninstall, we need to disable it again if > cancel_work_sync indicated pending work. Is there a reason we need the interrupts disabled at the V3D level while we have the IRQ disabled at the irqchip level? Once we re-enable at the irqchip, we immediately V3D_WRITE(V3D_INTENA, V3D_DRIVER_IRQS) anyway. 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/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
2017년 11월 13일 23:28에 Marek Szyprowski 이(가) 쓴 글: > Hi Inki, > > On 2017-11-13 02:24, Inki Dae wrote: >> Hi Marek, >> >> 2017년 11월 10일 16:35에 Marek Szyprowski 이(가) 쓴 글: >>> Dear Inki, >>> >>> On 2017-11-10 04:04, Inki Dae wrote: 2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글: > When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver > are contiguous, because of the underlying dma_alloc_attrs() function > provides only such buffers. In such case it makes no sense to keep What if user disabled CMA support? In this case, it guarantees also to allocate physically contiguous memory? I think it depends on CMA support so wouldn't be true. >>> dma_alloc_attrs() always guarantees the contiguity of the allocated memory >>> in DMA address space. When NOIOMMU is available, this mean that the >>> allocated >>> buffer is contiguous in the physical memory. When CMA is disabled, >>> dma_alloc_attrs() uses alloc_pages() allocator. The drawback of >>> alloc_pages() >>> is that it easily fails if physical memory is fragmented and it cannot >>> allocate memory larger than MAX_ORDER (4MiB in case of ARM32bit). >> You are right. Without IOMMU suppot alloc_pages always tryies to allocate >> contiguous memory, >> order = get_order(size); >> page = alloc_pages(..., order); >> if (!page) >> return NULL; >> ... > > Right > Real problem I think is that user don't know whether the gem buffer allocated with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer. So user can request a page flip with NONCONTIG buffer to kernel which doesn't support IOMMU. And another is that user may want to use NONCONTIG buffer for another purpose, not scanout. So if we enforce on using CONTIG buffer on kernel without IOMMU support, then it wouldn't be really what user intended. >>> When IOMMU support is disabled, ANY buffer allocated with dma_alloc_attrs() >>> will be contiguous, so I see no point propagating incorrect flag for it. >>> >>> The only way to create a NONCONTIG buffer with IOMMU disabled is to import >>> it from other driver and this path is already handled correctly. >>> My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate a buffer with a different allocation type - CONTIG or NONCONTIG - according to IOMMU support. And any page flip request with NONCONTIG buffer to kernel without IOMMU support should fail and it has to return a error with a proper error message. >>> I don't think that we need it. With the proposed patch the same userspace >>> will >>> work fine in both cases IOMMU enabled and disabled, even if it allocate GEM >>> with NONCONTIG flag. We can assume that CONTIG is a special case of >>> NONCONTIG >>> then. >> The problem is really not whether user space will work fine or not but is >> that this may be not what user space wanted. >> I.e., user space expects the allocated buffer is NONCONTIG buffer because >> user space requested NONCONTIG buffer but kernel internally, this is changed >> to CONTIG buffer. > > What's the problem when kernel allocated contiguous buffer but user > requested non-contiguous? Contiguous is a subclass of non-contiguous > in general. There is no driver nor scenario which will not work because > of such change (any code for handing n-segments should be fine with only > 1 segment). In some conditions, by luck, kernel might allocate > a contiguous buffer even with IOMMU enabled. When we know that the > buffer is contiguous, then flag it as such. I'd like to say what I experienced before here. I'd ever modified in-house kernel with similar issue that with IOMMU sometimes page fault happended. So tempararily I always made gem allocation request from user space to allocate CONTIG buffer and it worked well without page fault. Several days ago, a Platform guy reported one issue that gem allocation request failed even through it has free memory enough. The issus was as you guess fragementation issue and I talked to him memory fragmentation happended. However, that guy didn't understand why memory fragementation happended because he definitely requested NONCONTIG buffer allocation. Thus, if I provided a some hit - gem allocation way is changed to CONTIG due to some reason - to user space then he could understand the fragmentation issue without contacting me. This patch could fix the X Server issue but the X Server never know that the allocated buffer is contiguous because you changed the allocation type witout user's knowledge. Thanks, Inki Dae > >> So you could provide some information - maybe warning message?? - to user >> space the buffer type is changed to CONTIG buffer due to NO IOMMU support. > > I don't think this needs a warning. I just think that when we know that > the allocated buffer IS contiguous there is no point flagging it as > non-contiguous and fail a few calls later although the driver allocated
[Bug 103700] Displayport link status failed on resume from suspend on eDP on RX580 with Asus GL702ZC
https://bugs.freedesktop.org/show_bug.cgi?id=103700 --- Comment #2 from dwagner --- This bug could be the same as https://bugs.freedesktop.org/show_bug.cgi?id=103277 - but since I have only one display connected to the GPU - which stays off after resume (and then the system crashes so no other way to look at dmesg output) - I had no chance to see error messages like the ones you reported. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/debugfs: Fix framebuffer debugfs file init
The introduction of: drm/framebuffer: Add framebuffer debugfs file broke vgem. That patch assumed that all drivers had initialized the dev->mode_config.fb_lock mutex which happens in drm_mode_config_init(). vgem doesn't need to call drm_mode_config_init(). Fix this by only creating the framebuffer debugfs file for modesetting drivers. Fixes: 45d58b40292b ("drm/framebuffer: Add framebuffer debugfs file") Suggested-by: Chris Wilson Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_debugfs.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index 550f29de6c1f..b2482818fee8 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c @@ -158,10 +158,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id, } } - ret = drm_framebuffer_debugfs_init(minor); - if (ret) { - DRM_ERROR("Failed to create framebuffer debugfs file\n"); - return ret; + if (drm_core_check_feature(dev, DRIVER_MODESET)) { + ret = drm_framebuffer_debugfs_init(minor); + if (ret) { + DRM_ERROR("Failed to create framebuffer debugfs file\n"); + return ret; + } } if (dev->driver->debugfs_init) { -- 2.14.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tilcdc: Remove obsolete "ti, tilcdc, slave" dts binding support
On Mon, Nov 13, 2017 at 6:42 AM, Jyri Sarha wrote: > This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the > obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based > binding - that is widely used in other drm driver too - has been > supported since Linux v4.2. Maintaining the the backwards dts > conversion code in 0the DRM_TILCDC_SLAVE_COMPAT has become a nuisance > for the device/of development so the we decided to drop it after Linux > v4.14, the 2017 LTS. > > Signed-off-by: Jyri Sarha > --- > drivers/gpu/drm/tilcdc/Kconfig | 11 - > drivers/gpu/drm/tilcdc/Makefile| 3 - > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 269 > - > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 --- > drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h | 25 --- > 5 files changed, 380 deletions(-) > delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c > delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts > delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103630] [regression] Hacker Evolution(1,2,3) crash on startup
https://bugs.freedesktop.org/show_bug.cgi?id=103630 --- Comment #3 from cosiek...@o2.pl --- Computer Information: Manufacturer: Unknown Model: Unknown Form Factor: Desktop No Touch Input Detected Processor Information: CPU Vendor: GenuineIntel CPU Brand: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz CPU Family: 0x6 CPU Model: 0xf CPU Stepping: 0x6 CPU Type: 0x0 Speed: 1667 Mhz 2 logical processors 2 physical processors HyperThreading: Unsupported FCMOV: Supported SSE2: Supported SSE3: Supported SSSE3: Supported SSE4a: Unsupported SSE41: Unsupported SSE42: Unsupported AES: Unsupported AVX: Unsupported CMPXCHG16B: Supported LAHF/SAHF: Supported PrefetchW: Unsupported Operating System Version: "Manjaro Linux" (64 bit) Kernel Name: Linux Kernel Version: 4.9.61-3-MANJARO X Server Vendor: The X.Org Foundation X Server Release: 11905000 X Window Manager: Xfwm4 Steam Runtime Version: Video Card: Driver: X.Org R300 Project ATI RC410 Driver Version: 2.1 Mesa 17.2.4 OpenGL Version: 2.1 Desktop Color Depth: 24 bits per pixel Monitor Refresh Rate: 59 Hz VendorID: 0x1002 DeviceID: 0x5a62 Revision Not Detected Number of Monitors: 1 Number of Logical Video Cards: 1 Primary Display Resolution: 1280 x 800 Desktop Resolution: 1280 x 800 Primary Display Size: 13,03" x 8,15" (15,35" diag) 33,1cm x 20,7cm (39,0cm diag) Primary VRAM Not Detected Sound card: Audio device: Realtek ALC861-VD Memory: RAM: 1877 Mb Miscellaneous: UI Language: English LANG: pl_PL.utf8 Total Hard Disk Space Available: 54060 Mb Largest Free Hard Disk Block: 41979 Mb VR Headset: None detected Recent Failure Reports: -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file
Den 13.11.2017 23.17, skrev Chris Wilson: Quoting Noralf Trønnes (2017-11-13 22:12:06) Den 13.11.2017 22.33, skrev Chris Wilson: Quoting Noralf Trønnes (2017-11-13 19:54:43) Den 11.11.2017 19.55, skrev Chris Wilson: Quoting Noralf Trønnes (2017-11-07 19:13:40) Add debugfs file that dumps info about the framebuffers and its planes. Also dump info about any connected gem object(s). This isn't too hot for non-modesetting drm drivers. Just to be clear; this is currently on fire in i915's CI. As framebuffer-info is installed for vgem and vgem hasn't initialised any of the data structs being inspected... Ok, so I have broken vgem :-( drm_framebuffer_info() takes dev->mode_config.fb_lock which hasn't been initialized because vgem doesn't call drm_mode_config_init(). drm_mode_config_init() in addition to initializing various thing also calls drm_mode_create_standard_properties(). Can we call drm_mode_config_init() in vgem or is this a no-go because of the properties? Do you see a solution to this? My quick fix idea was a drm_core_check_feature(dev, DRIVER_MODESET) around the drm_framebuffer_debugfs_init(). Ah, yes, thank you! That sounds like a good idea. I will create a patch. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 4/16] drivers/gpu//drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of 'ttm_populate_and_map_pages'
tree: git://people.freedesktop.org/~agd5f/linux.git upstream-4.14-drm-next-amd-dc-staging-chrome head: 4448b9a68413462529d018050cd246bc33957bd6 commit: ed285b98008b667978d7faf348a22000b8a1c6b9 [4/16] drm/ttm: Add helper functions to populate/map in one call (v2) config: i386-randconfig-s0-201746 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout ed285b98008b667978d7faf348a22000b8a1c6b9 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> drivers/gpu//drm/ttm/ttm_page_alloc.c:923:5: error: redefinition of >> 'ttm_populate_and_map_pages' int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ In file included from drivers/gpu//drm/ttm/ttm_page_alloc.c:49:0: include/drm/ttm/ttm_page_alloc.h:120:19: note: previous definition of 'ttm_populate_and_map_pages' was here static inline int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ >> drivers/gpu//drm/ttm/ttm_page_alloc.c:950:6: error: redefinition of >> 'ttm_unmap_and_unpopulate_pages' void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ In file included from drivers/gpu//drm/ttm/ttm_page_alloc.c:49:0: include/drm/ttm/ttm_page_alloc.h:125:20: note: previous definition of 'ttm_unmap_and_unpopulate_pages' was here static inline void ttm_unmap_and_unpopulate_pages(struct device *dev, struct ttm_dma_tt *tt) ^~ vim +/ttm_populate_and_map_pages +923 drivers/gpu//drm/ttm/ttm_page_alloc.c 922 > 923 int ttm_populate_and_map_pages(struct device *dev, struct ttm_dma_tt > *tt) 924 { 925 unsigned i; 926 int r; 927 928 r = ttm_pool_populate(&tt->ttm); 929 if (r) 930 return r; 931 932 for (i = 0; i < tt->ttm.num_pages; i++) { 933 tt->dma_address[i] = dma_map_page(dev, tt->ttm.pages[i], 9340, PAGE_SIZE, 935DMA_BIDIRECTIONAL); 936 if (dma_mapping_error(dev, tt->dma_address[i])) { 937 while (i--) { 938 dma_unmap_page(dev, tt->dma_address[i], 939 PAGE_SIZE, DMA_BIDIRECTIONAL); 940 tt->dma_address[i] = 0; 941 } 942 ttm_pool_unpopulate(&tt->ttm); 943 return -EFAULT; 944 } 945 } 946 return 0; 947 } 948 EXPORT_SYMBOL(ttm_populate_and_map_pages); 949 > 950 void ttm_unmap_and_unpopulate_pages(struct device *dev, struct > ttm_dma_tt *tt) 951 { 952 unsigned i; 953 954 for (i = 0; i < tt->ttm.num_pages; i++) { 955 if (tt->dma_address[i]) { 956 dma_unmap_page(dev, tt->dma_address[i], 957 PAGE_SIZE, DMA_BIDIRECTIONAL); 958 } 959 } 960 ttm_pool_unpopulate(&tt->ttm); 961 } 962 EXPORT_SYMBOL(ttm_unmap_and_unpopulate_pages); 963 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file
Quoting Noralf Trønnes (2017-11-13 22:12:06) > > Den 13.11.2017 22.33, skrev Chris Wilson: > > Quoting Noralf Trønnes (2017-11-13 19:54:43) > >> Den 11.11.2017 19.55, skrev Chris Wilson: > >>> Quoting Noralf Trønnes (2017-11-07 19:13:40) > Add debugfs file that dumps info about the framebuffers and its planes. > Also dump info about any connected gem object(s). > >>> This isn't too hot for non-modesetting drm drivers. > > Just to be clear; this is currently on fire in i915's CI. As > > framebuffer-info is installed for vgem and vgem hasn't initialised any > > of the data structs being inspected... > > Ok, so I have broken vgem :-( > > drm_framebuffer_info() takes dev->mode_config.fb_lock which hasn't been > initialized because vgem doesn't call drm_mode_config_init(). > drm_mode_config_init() in addition to initializing various thing also > calls drm_mode_create_standard_properties(). > > Can we call drm_mode_config_init() in vgem or is this a no-go because of > the properties? Do you see a solution to this? My quick fix idea was a drm_core_check_feature(dev, DRIVER_MODESET) around the drm_framebuffer_debugfs_init(). -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file
Den 13.11.2017 22.33, skrev Chris Wilson: Quoting Noralf Trønnes (2017-11-13 19:54:43) Den 11.11.2017 19.55, skrev Chris Wilson: Quoting Noralf Trønnes (2017-11-07 19:13:40) Add debugfs file that dumps info about the framebuffers and its planes. Also dump info about any connected gem object(s). This isn't too hot for non-modesetting drm drivers. Just to be clear; this is currently on fire in i915's CI. As framebuffer-info is installed for vgem and vgem hasn't initialised any of the data structs being inspected... Ok, so I have broken vgem :-( drm_framebuffer_info() takes dev->mode_config.fb_lock which hasn't been initialized because vgem doesn't call drm_mode_config_init(). drm_mode_config_init() in addition to initializing various thing also calls drm_mode_create_standard_properties(). Can we call drm_mode_config_init() in vgem or is this a no-go because of the properties? Do you see a solution to this? Sorry about the fallout. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:upstream-4.14-drm-next-amd-dc-staging-chrome 3/16] drivers/staging//vboxvideo/vbox_mode.c:380:10: error: too few arguments to function 'drm_encoder_find'
tree: git://people.freedesktop.org/~agd5f/linux.git upstream-4.14-drm-next-amd-dc-staging-chrome head: 4448b9a68413462529d018050cd246bc33957bd6 commit: 74667d0b87be12956d9266ae54757db7adf6d1e6 [3/16] drm: Pass struct drm_file * to __drm_mode_object_find [v2] config: i386-randconfig-s0-201746 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout 74667d0b87be12956d9266ae54757db7adf6d1e6 # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): drivers/staging//vboxvideo/vbox_mode.c: In function 'vbox_best_single_encoder': >> drivers/staging//vboxvideo/vbox_mode.c:380:43: warning: passing argument 2 >> of 'drm_encoder_find' makes pointer from integer without a cast >> [-Wint-conversion] return drm_encoder_find(connector->dev, enc_id); ^~ In file included from include/drm/drm_modeset_helper_vtables.h:33:0, from include/drm/drm_crtc_helper.h:43, from drivers/staging//vboxvideo/vbox_mode.c:35: include/drm/drm_encoder.h:216:35: note: expected 'struct drm_file *' but argument is of type 'int' static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev, ^~~~ >> drivers/staging//vboxvideo/vbox_mode.c:380:10: error: too few arguments to >> function 'drm_encoder_find' return drm_encoder_find(connector->dev, enc_id); ^~~~ In file included from include/drm/drm_modeset_helper_vtables.h:33:0, from include/drm/drm_crtc_helper.h:43, from drivers/staging//vboxvideo/vbox_mode.c:35: include/drm/drm_encoder.h:216:35: note: declared here static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev, ^~~~ vim +/drm_encoder_find +380 drivers/staging//vboxvideo/vbox_mode.c dd55d44f4 Hans de Goede 2017-07-06 372 dd55d44f4 Hans de Goede 2017-07-06 373 static struct drm_encoder *vbox_best_single_encoder(struct drm_connector dd55d44f4 Hans de Goede 2017-07-06 374 *connector) dd55d44f4 Hans de Goede 2017-07-06 375 { dd55d44f4 Hans de Goede 2017-07-06 376 int enc_id = connector->encoder_ids[0]; dd55d44f4 Hans de Goede 2017-07-06 377 dd55d44f4 Hans de Goede 2017-07-06 378 /* pick the encoder ids */ dd55d44f4 Hans de Goede 2017-07-06 379 if (enc_id) dd55d44f4 Hans de Goede 2017-07-06 @380 return drm_encoder_find(connector->dev, enc_id); dd55d44f4 Hans de Goede 2017-07-06 381 dd55d44f4 Hans de Goede 2017-07-06 382 return NULL; dd55d44f4 Hans de Goede 2017-07-06 383 } dd55d44f4 Hans de Goede 2017-07-06 384 :: The code at line 380 was first introduced by commit :: dd55d44f408419278c00887bfcb2261d0caae350 staging: vboxvideo: Add vboxvideo to drivers/staging :: TO: Hans de Goede :: CC: Greg Kroah-Hartman --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file
Quoting Noralf Trønnes (2017-11-13 19:54:43) > > Den 11.11.2017 19.55, skrev Chris Wilson: > > Quoting Noralf Trønnes (2017-11-07 19:13:40) > >> Add debugfs file that dumps info about the framebuffers and its planes. > >> Also dump info about any connected gem object(s). > > This isn't too hot for non-modesetting drm drivers. Just to be clear; this is currently on fire in i915's CI. As framebuffer-info is installed for vgem and vgem hasn't initialised any of the data structs being inspected... -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=101739 --- Comment #2 from jan@gmx.de --- I also have this problem. Is there a way to force/override Z_ORDER to LATE_Z, at best per application, so that I can try whether this has any effect? If not: what other way is there to test it? I am willing to e.g. patch, compile and test some code if somebody tells me what to do, no promise when I'll find the time for that though. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values
On Mon, Nov 13, 2017 at 09:56:19PM +0100, Thierry Reding wrote: > On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote: > > On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > kerneldoc for drm_plane_create_zpos_property() says that the DRM core > > > will automatically calculate the normalized zpos values, but it won't > > > currently do so. Modify the atomic helpers to behave as documented. > > > > NAK > > > > See commit 38d868e41c4b ("drm: Don't force all planes to be added to > > the state due to zpos") > > Thanks, that's interesting background. It's a little unfortunate that > I'll have to go and add a custom ->atomic_check() just because of this. IIRC I did propose having two variants in the helper, but Daniel didn't like that. Of course that might not scale too well if more variants would become necessary, so I do understand the desire to avoid many helper variants. > This is something in general that's been bugging me. How are we supposed > to keep all of the custom ->atomic_check() implementations in sync with > the atomic helpers? It looks to me like most drivers will at some point > copy the atomic helper to their driver and then make driver-specific > changes to them. But then when one of the helpers gets updated, the same > changes are usually not propagated to the drivers that originally copied > from the helpers. > > One way I've seen used (and have used myself) occasionally is for the > driver-specific implementations to "subclass" the helpers by calling the > helper first and then calling the driver-specific bits. That helps a lot > but will obviously not work if ordering is important. > > Any ideas on how we can improve that? Other than periodically checking > the git log for the helpers and updating drivers? I suppose if one were > to closely follow the mailing list one might notice early on, and maybe > speak up and have the changes applied to the drivers in the same patch > as the helpers. But I don't think that's going to work for every driver. Yeah, I guess keeping a close eye on or periodically checking for changes is the best one can do. Of course people shouldn't be breaking other drivers with their changes to the helper. So if something gets added there that's really needed in the open coded implementations as well, the patch author should at least attempt to make those changes and make sure all relevant driver maintainers are aware part of the process. That won't magically land you new features though, unless the people implementing those are feeling extra generous. And I guess nothing beats regular and thorough testing if you're concerned about other people breaking your stuff. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline
Lothar Waßmann writes: > Hi, > > On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote: >> Lothar Waßmann writes: >> >> > Hi, >> > >> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently >> > dysfunctional due to: >> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6 >> > |Author: Eric Anholt >> > |Date: Fri Jun 2 13:25:14 2017 -0700 >> > | >> > |drm/bridge: Refactor out the panel wrapper from the lvds-encoder >> > bridge. >> > >> > Also, there is no in-kernel user of this driver, so that it obviously >> > doesn't get tested in any way. There is only one dts file >> > (r8a7779-marzen.dts) >> > that instantiates this driver, but it has an incomplete OF graph. The >> > missing >> > link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or >> > r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in >> > the kernel source. >> > >> > Should the driver be removed or moved to staging, until it is properly >> > fixed? >> >> I can't see any behavior change about the DT handling in that commit, >> and I didn't intend for there to be any. Could you help me understand >> what went wrong? >> > With the offending commit applied, the lvds-encoder driver is being > attached to the device associated with the lcd-panel driver's of_node > (panel-simple in my case) rather than the lvds-encoder's of_node. Anyone have any thoughts on best handling this? Slip another bridge in attached to this of_node that chains to panel-bridge's bridge, or just have a panel-bridge entrypoint for what node to register the bridge on? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=102800 --- Comment #12 from Alex Deucher --- Can you verify that the Linux pci subsystem is properly calling the ACPI _PR3 method on your platform? The workaround just uses the legacy AMD ACPI interface. It appears pci is not calling _PR3 properly for some reason on your platform. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values
On Mon, Nov 13, 2017 at 04:14:05PM +0200, Ville Syrjälä wrote: > On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote: > > From: Thierry Reding > > > > kerneldoc for drm_plane_create_zpos_property() says that the DRM core > > will automatically calculate the normalized zpos values, but it won't > > currently do so. Modify the atomic helpers to behave as documented. > > NAK > > See commit 38d868e41c4b ("drm: Don't force all planes to be added to > the state due to zpos") Thanks, that's interesting background. It's a little unfortunate that I'll have to go and add a custom ->atomic_check() just because of this. This is something in general that's been bugging me. How are we supposed to keep all of the custom ->atomic_check() implementations in sync with the atomic helpers? It looks to me like most drivers will at some point copy the atomic helper to their driver and then make driver-specific changes to them. But then when one of the helpers gets updated, the same changes are usually not propagated to the drivers that originally copied from the helpers. One way I've seen used (and have used myself) occasionally is for the driver-specific implementations to "subclass" the helpers by calling the helper first and then calling the driver-specific bits. That helps a lot but will obviously not work if ordering is important. Any ideas on how we can improve that? Other than periodically checking the git log for the helpers and updating drivers? I suppose if one were to closely follow the mailing list one might notice early on, and maybe speak up and have the changes applied to the drivers in the same patch as the helpers. But I don't think that's going to work for every driver. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197851] Resume from suspend sometimes results in black screen on Radeon R5
https://bugzilla.kernel.org/show_bug.cgi?id=197851 --- Comment #2 from Tyler McLean (sonarsoundapplicati...@gmail.com) --- Created attachment 260643 --> https://bugzilla.kernel.org/attachment.cgi?id=260643&action=edit Output from dmesg on a clean restart Attached the dmesg output. Can't get Xorg though as I'm running a Wayland environment -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102800] DRI_PRIME regression- radeon: Failed to allocate virtual address for buffer
https://bugs.freedesktop.org/show_bug.cgi?id=102800 --- Comment #11 from higu...@gmx.net --- just tested kernel 4.14.0 (without the above patch) and it still fails i will apply the patch again, as a workaround -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 2749/2876] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: eee12cc2150b932ee52ccf89de611a7ba030eb90 commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [2749/2876] ASoC: AMD: enable ACP3x drivers build config: blackfin-allyesconfig (attached as .config) compiler: bfin-uclinux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 0bd599b1f523598c05f13a4a562884e82a378c2c # save the attached .config to linux build tree make.cross ARCH=blackfin All errors (new ones prefixed by >>): sound/soc/amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe': >> sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of >> function 'pci_enable_msi' [-Werror=implicit-function-declaration] ret = pci_enable_msi(pci); ^~ >> sound/soc/amd/raven/pci-acp3x.c:122:2: error: implicit declaration of >> function 'pci_disable_msi' [-Werror=implicit-function-declaration] pci_disable_msi(pci); ^~~ sound/soc/amd/raven/pci-acp3x.c: At top level: sound/soc/amd/raven/pci-acp3x.c:159:1: warning: data definition has no type or storage class module_pci_driver(acp3x_driver); ^ >> sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in >> declaration of 'module_pci_driver' [-Werror=implicit-int] sound/soc/amd/raven/pci-acp3x.c:159:1: warning: parameter names (without types) in function declaration sound/soc/amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but not used [-Wunused-variable] static struct pci_driver acp3x_driver = { ^~~~ cc1: some warnings being treated as errors vim +/pci_enable_msi +58 sound/soc/amd/raven/pci-acp3x.c 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 29 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 30 static int snd_acp3x_probe(struct pci_dev *pci, 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 31 const struct pci_device_id *pci_id) 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 32 { 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 33 int ret; 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 34 u32 addr, val; 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 35 struct acp3x_dev_data *adata; 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 36 struct platform_device_info pdevinfo; 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 37 unsigned int irqflags; 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 38 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 39 if (pci_enable_device(pci)) { 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 40 dev_err(&pci->dev, "pci_enable_device failed\n"); 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 41 return -ENODEV; 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 42 } 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 43 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 44 ret = pci_request_regions(pci, "AMD ACP3x audio"); 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 45 if (ret < 0) { 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 46 dev_err(&pci->dev, "pci_request_regions failed\n"); 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 47 goto disable_pci; 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 48 } 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 49 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 50 adata = devm_kzalloc(&pci->dev, sizeof(struct acp3x_dev_data), 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 51 GFP_KERNEL); 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 52 if (adata == NULL) { 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 53 ret = -ENOMEM; 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 54 goto release_regions; 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 55 } 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 56 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 57 /* check for msi interrupt support */ 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 @58 ret = pci_enable_msi(pci); 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 59 if (ret) 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 60 /* msi is not enabled */ 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 61 irqflags = IRQF_SHARED; 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 62 else 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 63 /* msi is enabled */ 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 64 irqflags = 0; 2519e90f Maruthi Srinivas Bayyavarapu 2017-03-29 65 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 66 addr = pci_resource_start(pci, 0); 4eafb0d4 Maruthi Srinivas Bayyavarapu 2017-03-27 67 adata->acp3x_base = ioremap(add
Re: [PATCH v5 04/12] drm/framebuffer: Add framebuffer debugfs file
Den 11.11.2017 19.55, skrev Chris Wilson: Quoting Noralf Trønnes (2017-11-07 19:13:40) Add debugfs file that dumps info about the framebuffers and its planes. Also dump info about any connected gem object(s). This isn't too hot for non-modesetting drm drivers. And isn't this growing a midlayer? Calling to the drivers instead of the drivers controlling and calling helpers for the common stuff. I really can't say, but Daniel asked me to do it like this: https://lists.freedesktop.org/archives/dri-devel/2017-October/155245.html Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the devicetree tree with the drm tree
On 11/13/17 20:43, Frank Rowand wrote: > Hi Jyri, > > On 11/13/17 07:40, Jyri Sarha wrote: >> On 11/13/17 07:58, Stephen Rothwell wrote: >>> Hi all, >>> >>> On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote: Today's linux-next merge of the devicetree tree got a conflict in: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c between commit: 44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting") from the drm tree and commit: f948d6d8b792bb ("of: overlay: avoid race condition between applying multiple overlays") from the devicetree tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c index 482299a6f3b0,54025af534d4.. --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc return NULL; } - ret = of_resolve_phandles(overlay); - if (ret) { - pr_err("%s: Failed to resolve phandles: %d\n", __func__, ret); - return NULL; - } - of_node_set_flag(overlay, OF_DETACHED); -- return overlay; } >>> Just a reminder that this conflict still exists. >>> >> After some consideration, I think we can drop the dts backward >> compatibility code from drm/tilcdc. It seems that it is causing a lot of >> trouble and I do not even know if anybody uses it anymore. Here is a >> patch for dropping it: >> >> https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html >> >> I did not plan to merge it before v4.16, but if this is a bigger problem >> I can push is right now for v4.15. >> >> Best regards, >> Jyri >> > The dropping patch is much appreciated. > > It would make life easier for me if the patch gets into v4.15-rc. Dave, Daniel? Would you take this late addition to v4.15 still, if I would send a pull request now? The patch is pretty much orthogonal to the rest of drm as it is only dealing with device tree stuff. Best regards, Jyri -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 6/6] drivers/gpu/drm/i915/intel_device_info.c:345: undefined reference to `__udivdi3'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: dab91783338bd3dd42638f89b5f7e34c57773207 commit: dab91783338bd3dd42638f89b5f7e34c57773207 [6/6] drm/i915: expose command stream timestamp frequency to userspace config: i386-randconfig-s0-201746 (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout dab91783338bd3dd42638f89b5f7e34c57773207 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/intel_device_info.o: In function `read_reference_ts_freq': >> drivers/gpu/drm/i915/intel_device_info.c:345: undefined reference to >> `__udivdi3' vim +345 drivers/gpu/drm/i915/intel_device_info.c 331 332 static u64 read_reference_ts_freq(struct drm_i915_private *dev_priv) 333 { 334 u32 ts_override = I915_READ(GEN9_TIMESTAMP_OVERRIDE); 335 u64 base_freq, frac_freq; 336 337 base_freq = ((ts_override & GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_MASK) >> 338 GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DIVIDER_SHIFT) + 1; 339 base_freq *= 100; 340 341 frac_freq = ((ts_override & 342 GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK) >> 343 GEN9_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT); 344 if (frac_freq != 0) > 345 frac_freq = 100 / (frac_freq + 1); 346 347 return base_freq + frac_freq; 348 } 349 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave, Here's the previous PR plus the rockchip fix that snuck in. drm-misc-fixes-2017-11-13: Driver Changes: - qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd) - rockchip: Convert psr spinlock to mutex (Emil) Cc: Emil Renner Berthing Cc: Gerd Hoffmann Cheers, Sean The following changes since commit 33d930e59a98fa10a0db9f56c7fa2f21a4aef9b9: Linux 4.14-rc5 (2017-10-15 21:01:12 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2017-11-13 for you to fetch changes up to 44419ce7d77e03692ed8fe799688d8dc43f9266e: drm/rockchip: analogix_dp: Use mutex rather than spinlock (2017-11-13 10:29:23 +0800) Driver Changes: - qxl: Use a shadow bo as primary and blit to it to fix flicker (Gerd) - rockchip: Convert psr spinlock to mutex (Emil) Cc: Emil Renner Berthing Cc: Gerd Hoffmann Emil Renner Berthing (1): drm/rockchip: analogix_dp: Use mutex rather than spinlock Gerd Hoffmann (2): drm/qxl: replace QXL_INFO with DRM_DEBUG_DRIVER qxl: alloc & use shadow for dumb buffers drivers/gpu/drm/qxl/qxl_cmd.c | 22 ++- drivers/gpu/drm/qxl/qxl_display.c | 49 +++-- drivers/gpu/drm/qxl/qxl_drv.h | 28 ++ drivers/gpu/drm/qxl/qxl_dumb.c | 1 + drivers/gpu/drm/qxl/qxl_fb.c| 13 +++ drivers/gpu/drm/qxl/qxl_release.c | 5 +-- drivers/gpu/drm/qxl/qxl_ttm.c | 4 +- drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 +++ 8 files changed, 77 insertions(+), 59 deletions(-) -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver
On Mon, Nov 13, 2017 at 9:40 AM, Chen, Horace wrote: > Reivewed-by: Horace Chen Applied. thanks! Alex > > -Original Message- > From: Liu, Monk > Sent: Monday, November 13, 2017 11:43 AM > To: Chen, Horace ; Colin King > ; Deucher, Alexander ; > Koenig, Christian ; David Airlie > ; Yu, Xiangliang ; > amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver > Importance: High > > + Horace > > -Original Message- > From: Colin King [mailto:colin.k...@canonical.com] > Sent: 2017年11月11日 19:51 > To: Deucher, Alexander ; Koenig, Christian > ; David Airlie ; Liu, Monk > ; Yu, Xiangliang ; > amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org > Subject: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver > > From: Colin Ian King > > Variable pf2vf_ver is assigned but never read, it is redundant and hence can > be removed. > > Cleans up clang warning: > drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:310:3: warning: Value stored to > 'pf2vf_ver' is never read > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c > index 6738df836a70..b1cc179512fa 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c > @@ -296,7 +296,6 @@ int amdgpu_virt_fw_reserve_get_checksum(void *obj, > > void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev) { > - uint32_t pf2vf_ver = 0; > uint32_t pf2vf_size = 0; > uint32_t checksum = 0; > uint32_t checkval; > @@ -309,7 +308,6 @@ void amdgpu_virt_init_data_exchange(struct amdgpu_device > *adev) > adev->virt.fw_reserve.p_pf2vf = > (struct amdgim_pf2vf_info_header *)( > adev->fw_vram_usage.va + AMDGIM_DATAEXCHANGE_OFFSET); > - pf2vf_ver = adev->virt.fw_reserve.p_pf2vf->version; > AMDGPU_FW_VRAM_PF2VF_READ(adev, header.size, &pf2vf_size); > AMDGPU_FW_VRAM_PF2VF_READ(adev, checksum, &checksum); > > -- > 2.14.1 > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes
On Mon, Nov 13, 2017 at 06:30:47PM +, Jose Abreu wrote: > > > On 13-11-2017 17:04, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > If the user mode would specify an aspect ratio other than 4:3 or 16:9 > > we now silently ignore it. Maybe a better apporoach is to return an > > error? Let's try that. > > > > Also we must be careful that we don't try to send illegal picture > > aspect in the infoframe as it's only capable of signalling none, > > 4:3, and 16:9. Currently we're sending these bogus infoframes > > whenever the cea mode specifies some other aspect ratio. > > > > > > Yes, this is a bug. Following my input from the previous patch I > think you should also check for HDMI_PICTURE_ASPECT_RESERVED or RESERVED > 16_9 > user a helper to check that. I'm also wondering if this should go > to stable since the vics with aspect ratio > 16:9 were > introduced. We are indeed corrupting the AVI infoframe. Possibly. Just need to be careful we don't end up making a bigger mess in stable. I has some concerns about the ordering of these patches, but I guess that was between this patch and the next patch that starts to reject the illegal aspect ratios in the infoframe code. So just backporting this one alone (or both patches) should be fine. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling
On Mon, Nov 13, 2017 at 06:13:37PM +, Jose Abreu wrote: > Hi Ville, > > On 13-11-2017 17:04, Ville Syrjala wrote: > > > > + if (to_match->picture_aspect_ratio) > > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; > > + > > > > Maybe "if (to_match->picture_aspect_ratio != > HDMI_PICTURE_ASPECT_NONE && to_match->picture_aspect_ratio != > HDMI_PICTURE_ASPECT_RESERVED)"? > > Or some kind of helper to validate the aspect ratio from userspace? We can't currently get an aspect ratio from userspace. Well we had it but I reverted it due to regressions. When we add it back it will obviously need to be validated, just like any other information we get from userspace. Hmm. Except we don't even validate the current mode flags/type at all. Fail. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] video/hdmi: Reject illegal picture aspect ratios
On 13-11-2017 17:04, Ville Syrjala wrote: > From: Ville Syrjälä > > AVI infoframe can only carry none, 4:3, or 16:9 picture aspect > ratios. Return an error if the user asked for something different. > > Cc: Shashank Sharma > Cc: "Lin, Jia" > Cc: Akashdeep Sharma > Cc: Jim Bride > Cc: Jose Abreu > Cc: Daniel Vetter > Cc: Emil Velikov > Cc: Thierry Reding > Cc: Hans Verkuil > Cc: linux-me...@vger.kernel.org > Signed-off-by: Ville Syrjälä Reviewed-by: Jose Abreu Best Regards, Jose Miguel Abreu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes
On 13-11-2017 17:04, Ville Syrjala wrote: > From: Ville Syrjälä > > If the user mode would specify an aspect ratio other than 4:3 or 16:9 > we now silently ignore it. Maybe a better apporoach is to return an > error? Let's try that. > > Also we must be careful that we don't try to send illegal picture > aspect in the infoframe as it's only capable of signalling none, > 4:3, and 16:9. Currently we're sending these bogus infoframes > whenever the cea mode specifies some other aspect ratio. > > Yes, this is a bug. Following my input from the previous patch I think you should also check for HDMI_PICTURE_ASPECT_RESERVED or user a helper to check that. I'm also wondering if this should go to stable since the vics with aspect ratio > 16:9 were introduced. We are indeed corrupting the AVI infoframe. Best Regards, Jose Miguel Abreu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 6/6] intel_device_info.c:undefined reference to `__udivdi3'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: dab91783338bd3dd42638f89b5f7e34c57773207 commit: dab91783338bd3dd42638f89b5f7e34c57773207 [6/6] drm/i915: expose command stream timestamp frequency to userspace config: i386-defconfig (attached as .config) compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026 reproduce: git checkout dab91783338bd3dd42638f89b5f7e34c57773207 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/gpu/drm/i915/intel_device_info.o: In function `read_reference_ts_freq': >> intel_device_info.c:(.text+0x4b): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling
Hi Ville, On 13-11-2017 17:04, Ville Syrjala wrote: > > + if (to_match->picture_aspect_ratio) > + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; > + > Maybe "if (to_match->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE && to_match->picture_aspect_ratio != HDMI_PICTURE_ASPECT_RESERVED)"? Or some kind of helper to validate the aspect ratio from userspace? Best Regards, Jose Miguel Abreu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Regression in Linux next-20171113 with fbdev timer conversion
On Monday, November 13, 2017 09:07:14 AM Tony Lindgren wrote: > Hi, Hi Tony, > Looks like next-20171113 now has a NULL pointe dereference with commit > 6c78935777d1 ("video: fbdev: Convert timers to use timer_setup()"). > > See the error below, any ideas? Should be fixed by: https://marc.info/?l=linux-fbdev&m=151056635200583&w=2 > Regards, > > Tony > > 8< -- > Unable to handle kernel NULL pointer dereference at virtual address 0214 > pgd = edfe4000 > [0214] *pgd= > Internal error: Oops: 5 [#1] SMP ARM > ... > CPU: 1 PID: 920 Comm: openrc-run.sh Not tainted 4.14.0-next-20171113+ #1911 > Hardware name: Generic OMAP4 (Flattened Device Tree) > task: ed922000 task.stack: edc2 > PC is at _test_and_set_bit+0x20/0x48 > LR is at queue_work_on+0x28/0x74 > pc : []lr : []psr: 6193 > sp : edc21e38 ip : fp : c0d09168 > r10: edb686bc r9 : 0001 r8 : c0544e4c > r7 : ee80f000 r6 : 0002 r5 : 0214 r4 : 2113 > r3 : 0001 r2 : 0001 r1 : 0214 r0 : > Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none > Control: 10c5387d Table: adfe404a DAC: 0051 > Process openrc-run.sh (pid: 920, stack limit = 0xedc20218) > Stack: (0xedc21e38 to 0xedc22000) > 1e20: edb686bc edb686bc > 1e40: c0dc8588 0100 c0544e4c c0544e6c c0dc7239 c01cc78c 0001 > 1e60: c01cc6d0 0001 c1505b74 c124c5f8 > 1e80: c0adfb54 c0544e4c edb686bc c0544e4c ef6b3700 edc2 edc21ed8 > 1ea0: c0dc8588 c0d09168 edb686bc c01ccbbc 8fee 0001 edc21ed8 c0d05d00 > 1ec0: ef6b3700 c0d0957c 0100 c0dc8128 0282 c01ccd94 c0d4675c > 1ee0: 6113 c0dc7132 c0d09168 c019f718 e000 c0d03084 edc2 > 1f00: 0001 c0dc7132 c0d09168 c0101714 c0d8821c c0dc720a 0002 000a > 1f20: 8fee 0040 0001 0002 e000 c0d0957c > 1f40: 0001 ee80d400 fa240100 c0d09854 c013fa6c c0c79160 c01adf54 > 1f60: fa24010c 03eb 03ff edc21fb0 c0d88738 fa240100 c0101574 > 1f80: 0006 fa241100 edc2 b6f2e9bc 2010 10c5387d 10c5387d > 1fa0: 005169a0 00517240 005169a0 c088d6b4 005280ea 005280eb 005f > 1fc0: 005280e4 004f9511 00517830 005169a0 00517240 005169a0 > 1fe0: 0001 bed595c0 bed595e0 b6f2e9bc 2010 > [] (_test_and_set_bit) from [] (queue_work_on+0x28/0x74) > [] (queue_work_on) from [] > (cursor_timer_handler+0x20/0x44) > [] (cursor_timer_handler) from [] > (call_timer_fn+0xbc/0x408) > [] (call_timer_fn) from [] (expire_timers+0xe4/0x220) > [] (expire_timers) from [] (run_timer_softirq+0x9c/0x1a4) > [] (run_timer_softirq) from [] (__do_softirq+0x13c/0x5b8) > [] (__do_softirq) from [] (irq_exit+0x14c/0x1a8) > [] (irq_exit) from [] (__handle_domain_irq+0x6c/0xe0) > [] (__handle_domain_irq) from [] > (gic_handle_irq+0x58/0xb8) > [] (gic_handle_irq) from [] (__irq_usr+0x54/0x80) > Exception stack(0xedc21fb0 to 0xedc21ff8) > 1fa0: 005280ea 005280eb 005f > 1fc0: 005280e4 004f9511 00517830 005169a0 00517240 005169a0 > 1fe0: 0001 bed595c0 bed595e0 b6f2e9bc 2010 > Code: e1a002a0 e0811100 e1a03312 ee070fba (e1912f9f) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Initialize ops->info early
On Monday, November 13, 2017 10:45:46 AM Thierry Reding wrote: > From: Thierry Reding > > During console takeover, which happens for all DRM/KMS setups using the > fbdev helpers, fbcon_startup() is called before fbcon_init() and as a > result con2fb_acquire_newinfo() will not be called (info->fbcon_par was > set to non-NULL in fbcon_startup()) to assign ops->info. > > This causes the cursor_timer_handler() to unreference a NULL pointer. > > Avoid this by unconditionally assigning ops->info during fbcon_startup() > so that it will be available early, but keep the additional assignment > in con2fb_acquire_newinfo() to support console remapping at runtime. > > Cc: Kees Cook > Signed-off-by: Thierry Reding Patch queued for 4.15, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/10] video/hdmi: Pass buffer size to infoframe unpack functions
From: Ville Syrjälä To make sure the infoframe unpack functions don't end up examining stack garbage or oopsing, let's pass in the size of the buffer. Cc: Thierry Reding Cc: Hans Verkuil Cc: linux-me...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/media/i2c/adv7511.c | 2 +- drivers/media/i2c/adv7604.c | 2 +- drivers/media/i2c/adv7842.c | 2 +- drivers/media/i2c/tc358743.c | 2 +- drivers/video/hdmi.c | 51 include/linux/hdmi.h | 2 +- 6 files changed, 42 insertions(+), 19 deletions(-) diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c index 2817bafc67bf..dec09c18ea34 100644 --- a/drivers/media/i2c/adv7511.c +++ b/drivers/media/i2c/adv7511.c @@ -562,7 +562,7 @@ static void log_infoframe(struct v4l2_subdev *sd, const struct adv7511_cfg_read_ buffer[3] = 0; buffer[3] = hdmi_infoframe_checksum(buffer, len + 4); - if (hdmi_infoframe_unpack(&frame, buffer) < 0) { + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) { v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__, cri->desc); return; } diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index f289b8aca1da..8500438af0d3 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2429,7 +2429,7 @@ static int adv76xx_read_infoframe(struct v4l2_subdev *sd, int index, buffer[i + 3] = infoframe_read(sd, adv76xx_cri[index].payload_addr + i); - if (hdmi_infoframe_unpack(frame, buffer) < 0) { + if (hdmi_infoframe_unpack(frame, buffer, sizeof(buffer)) < 0) { v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__, adv76xx_cri[index].desc); return -ENOENT; diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index 65f34e7e146f..fd5d5e84dcbf 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -2576,7 +2576,7 @@ static void log_infoframe(struct v4l2_subdev *sd, struct adv7842_cfg_read_infofr for (i = 0; i < len; i++) buffer[i + 3] = infoframe_read(sd, cri->payload_addr + i); - if (hdmi_infoframe_unpack(&frame, buffer) < 0) { + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) { v4l2_err(sd, "%s: unpack of %s infoframe failed\n", __func__, cri->desc); return; } diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c index e6f5c363ccab..f6a5ebffd9c6 100644 --- a/drivers/media/i2c/tc358743.c +++ b/drivers/media/i2c/tc358743.c @@ -453,7 +453,7 @@ static void print_avi_infoframe(struct v4l2_subdev *sd) i2c_rd(sd, PK_AVI_0HEAD, buffer, HDMI_INFOFRAME_SIZE(AVI)); - if (hdmi_infoframe_unpack(&frame, buffer) < 0) { + if (hdmi_infoframe_unpack(&frame, buffer, sizeof(buffer)) < 0) { v4l2_err(sd, "%s: unpack of AVI infoframe failed\n", __func__); return; } diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 65b915ea4936..b5d491014b0b 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -1005,8 +1005,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log); /** * hdmi_avi_infoframe_unpack() - unpack binary buffer to a HDMI AVI infoframe - * @buffer: source buffer * @frame: HDMI AVI infoframe + * @buffer: source buffer + * @size: size of buffer * * Unpacks the information contained in binary @buffer into a structured * @frame of the HDMI Auxiliary Video (AVI) information frame. @@ -1016,11 +1017,14 @@ EXPORT_SYMBOL(hdmi_infoframe_log); * Returns 0 on success or a negative error code on failure. */ static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame, -const void *buffer) +const void *buffer, size_t size) { const u8 *ptr = buffer; int ret; + if (size < HDMI_INFOFRAME_SIZE(AVI)) + return -EINVAL; + if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI || ptr[1] != 2 || ptr[2] != HDMI_AVI_INFOFRAME_SIZE) @@ -1068,8 +1072,9 @@ static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame, /** * hdmi_spd_infoframe_unpack() - unpack binary buffer to a HDMI SPD infoframe - * @buffer: source buffer * @frame: HDMI SPD infoframe + * @buffer: source buffer + * @size: size of buffer * * Unpacks the information contained in binary @buffer into a structured * @frame of the HDMI Source Product Description (SPD) information frame. @@ -1079,11 +1084,14 @@ static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame, * Returns 0 on success or a negative error code on failure. */ static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame, -const void *buffer) +
[PATCH 08/10] video/hdmi: Reject illegal picture aspect ratios
From: Ville Syrjälä AVI infoframe can only carry none, 4:3, or 16:9 picture aspect ratios. Return an error if the user asked for something different. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma Cc: Jim Bride Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Cc: Thierry Reding Cc: Hans Verkuil Cc: linux-me...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/video/hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 111a0ab6280a..38716eb50408 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe *frame, void *buffer, if (size < length) return -ENOSPC; + if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9) + return -EINVAL; + memset(buffer, 0, size); ptr[0] = frame->type; -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes
From: Ville Syrjälä If the user mode would specify an aspect ratio other than 4:3 or 16:9 we now silently ignore it. Maybe a better apporoach is to return an error? Let's try that. Also we must be careful that we don't try to send illegal picture aspect in the infoframe as it's only capable of signalling none, 4:3, and 16:9. Currently we're sending these bogus infoframes whenever the cea mode specifies some other aspect ratio. Cc: Shashank Sharma Cc: Sean Paul Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 00aa98f3e55d..bafb3ee4ea97 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4786,6 +4786,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, const struct drm_display_mode *mode, bool is_hdmi2_sink) { + enum hdmi_picture_aspect picture_aspect; int err; if (!frame || !mode) @@ -4828,13 +4829,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct hdmi_avi_infoframe *frame, * Populate picture aspect ratio from either * user input (if specified) or from the CEA mode list. */ - if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 || - mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9) - frame->picture_aspect = mode->picture_aspect_ratio; - else if (frame->video_code > 0) - frame->picture_aspect = drm_get_cea_aspect_ratio( - frame->video_code); + picture_aspect = mode->picture_aspect_ratio; + if (picture_aspect == HDMI_PICTURE_ASPECT_NONE) + picture_aspect = drm_get_cea_aspect_ratio(frame->video_code); + /* +* The infoframe can't convey anything but none, 4:3 +* and 16:9, so if the user has asked for anything else +* we can only satisfy it by specifying the right VIC. +*/ + if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) { + if (picture_aspect != + drm_get_cea_aspect_ratio(frame->video_code)) + return -EINVAL; + picture_aspect = HDMI_PICTURE_ASPECT_NONE; + } + + frame->picture_aspect = picture_aspect; frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE; frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN; -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/10] drm/edid: Fix cea mode aspect ratio handling
From: Ville Syrjälä commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer") cause us to not send out any VICs in the AVI infoframes. That commit was since reverted, but if and when we add aspect ratio handing back we need to be more careful. Let's handle this by considering the aspect ratio as a requirement for cea mode matching only if the passed in mode actually has a non-zero aspect ratio field. This will keep userspace that doesn't provide an aspect ratio working as before by matching it to the first otherwise equal cea mode. And once userspace starts to provide the aspect ratio it will be considerd a hard requirement for the match. Also change the hdmi mode matching to use drm_mode_match() for consistency, but we don't match on aspect ratio there since the spec doesn't list a specific aspect ratio for those modes. Cc: Shashank Sharma Cc: "Lin, Jia" Cc: Akashdeep Sharma Cc: Jim Bride Cc: Jose Abreu Cc: Daniel Vetter Cc: Emil Velikov Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 7220b8f9a7e8..00aa98f3e55d 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -2903,11 +2903,15 @@ cea_mode_alternate_timings(u8 vic, struct drm_display_mode *mode) static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) return 0; + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; + for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) { struct drm_display_mode cea_mode = edid_cea_modes[vic]; unsigned int clock1, clock2; @@ -2921,7 +2925,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_m continue; do { - if (drm_mode_equal_no_clocks_no_stereo(to_match, &cea_mode)) + if (drm_mode_match(to_match, &cea_mode, match_flags)) return vic; } while (cea_mode_alternate_timings(vic, &cea_mode)); } @@ -2938,11 +2942,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode *to_m */ u8 drm_match_cea_mode(const struct drm_display_mode *to_match) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) return 0; + if (to_match->picture_aspect_ratio) + match_flags |= DRM_MODE_MATCH_ASPECT_RATIO; + for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) { struct drm_display_mode cea_mode = edid_cea_modes[vic]; unsigned int clock1, clock2; @@ -2956,7 +2964,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode *to_match) continue; do { - if (drm_mode_equal_no_clocks_no_stereo(to_match, &cea_mode)) + if (drm_mode_match(to_match, &cea_mode, match_flags)) return vic; } while (cea_mode_alternate_timings(vic, &cea_mode)); } @@ -3003,6 +3011,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode *hdmi_mode) static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_match, unsigned int clock_tolerance) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) @@ -3020,7 +3029,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_ abs(to_match->clock - clock2) > clock_tolerance) continue; - if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)) + if (drm_mode_match(to_match, hdmi_mode, match_flags)) return vic; } @@ -3037,6 +3046,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_ */ static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match) { + unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | DRM_MODE_MATCH_FLAGS; u8 vic; if (!to_match->clock) @@ -3052,7 +3062,7 @@ static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match) if ((KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock1) || KHZ2PICOS(to_match->clock) == KHZ2PICOS(clock2)) && - drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)) + drm_mode_match(to_match, hdmi_mode, match_flags))
[PATCH 09/10] video/hdmi: Constify 'buffer' to the unpack functions
From: Ville Syrjälä The unpack functions just read from the passed in buffer, so make it const. Cc: Thierry Reding Cc: Hans Verkuil Cc: linux-me...@vger.kernel.org Signed-off-by: Ville Syrjälä --- drivers/video/hdmi.c | 23 --- include/linux/hdmi.h | 3 ++- 2 files changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 38716eb50408..65b915ea4936 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -31,7 +31,7 @@ #define hdmi_log(fmt, ...) dev_printk(level, dev, fmt, ##__VA_ARGS__) -static u8 hdmi_infoframe_checksum(u8 *ptr, size_t size) +static u8 hdmi_infoframe_checksum(const u8 *ptr, size_t size) { u8 csum = 0; size_t i; @@ -1016,9 +1016,9 @@ EXPORT_SYMBOL(hdmi_infoframe_log); * Returns 0 on success or a negative error code on failure. */ static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame, -void *buffer) +const void *buffer) { - u8 *ptr = buffer; + const u8 *ptr = buffer; int ret; if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI || @@ -1079,9 +1079,9 @@ static int hdmi_avi_infoframe_unpack(struct hdmi_avi_infoframe *frame, * Returns 0 on success or a negative error code on failure. */ static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame, -void *buffer) +const void *buffer) { - u8 *ptr = buffer; + const u8 *ptr = buffer; int ret; if (ptr[0] != HDMI_INFOFRAME_TYPE_SPD || @@ -1117,9 +1117,9 @@ static int hdmi_spd_infoframe_unpack(struct hdmi_spd_infoframe *frame, * Returns 0 on success or a negative error code on failure. */ static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame, - void *buffer) + const void *buffer) { - u8 *ptr = buffer; + const u8 *ptr = buffer; int ret; if (ptr[0] != HDMI_INFOFRAME_TYPE_AUDIO || @@ -1163,9 +1163,9 @@ static int hdmi_audio_infoframe_unpack(struct hdmi_audio_infoframe *frame, */ static int hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame, -void *buffer) +const void *buffer) { - u8 *ptr = buffer; + const u8 *ptr = buffer; size_t length; int ret; u8 hdmi_video_format; @@ -1234,10 +1234,11 @@ hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame, * * Returns 0 on success or a negative error code on failure. */ -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer) +int hdmi_infoframe_unpack(union hdmi_infoframe *frame, + const void *buffer) { int ret; - u8 *ptr = buffer; + const u8 *ptr = buffer; switch (ptr[0]) { case HDMI_INFOFRAME_TYPE_AVI: diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h index d271ff23984f..d3816170c062 100644 --- a/include/linux/hdmi.h +++ b/include/linux/hdmi.h @@ -332,7 +332,8 @@ union hdmi_infoframe { ssize_t hdmi_infoframe_pack(union hdmi_infoframe *frame, void *buffer, size_t size); -int hdmi_infoframe_unpack(union hdmi_infoframe *frame, void *buffer); +int hdmi_infoframe_unpack(union hdmi_infoframe *frame, + const void *buffer); void hdmi_infoframe_log(const char *level, struct device *dev, union hdmi_infoframe *frame); -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/10] drm/edid: Allow HDMI infoframe without VIC or S3D
From: Ville Syrjälä Appedix F of HDMI 2.0 says that some HDMI sink may fail to switch from 3D to 2D mode in a timely fashion if the source simply stops sending the HDMI infoframe. The suggested workaround is to keep sending the infoframe even when strictly not necessary (ie. no VIC and no S3D). HDMI 1.4 does allow for this behaviour, stating that sending the infoframe is optional in this case. The infoframe was first specified in HDMI 1.4, so in theory sinks predating that may not appreciate us sending an uknown infoframe their way. To avoid regressions let's try to determine if the sink supports the infoframe or not. Unfortunately there's no direct way to do that, so instead we'll just check if we managed to parse any HDMI 1.4 4k or stereo modes from the EDID, and if so we assume the sink will accept the infoframe. Also if the EDID contains the HDMI 2.0 HDMI Forum VSDB we can assume the sink is prepared to receive the infoframe. v2: Fix the getting has_hdmi_infoframe from display_info Always fail constructing the infoframe if the display possibly can't handle it Cc: Shashank Sharma Cc: Andrzej Hajda Cc: Laurent Pinchart Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/bridge/sil-sii8620.c | 3 ++- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +++- drivers/gpu/drm/drm_edid.c| 34 +-- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_hdmi.c | 14 +++-- drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 ++- drivers/gpu/drm/nouveau/nv50_display.c| 3 ++- drivers/gpu/drm/rockchip/inno_hdmi.c | 1 + drivers/gpu/drm/sti/sti_hdmi.c| 4 +++- drivers/gpu/drm/zte/zx_hdmi.c | 1 + include/drm/drm_connector.h | 5 + include/drm/drm_edid.h| 1 + 12 files changed, 57 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c b/drivers/gpu/drm/bridge/sil-sii8620.c index b7eb704d0a8a..4417276ba02e 100644 --- a/drivers/gpu/drm/bridge/sil-sii8620.c +++ b/drivers/gpu/drm/bridge/sil-sii8620.c @@ -2220,8 +2220,9 @@ static bool sii8620_mode_fixup(struct drm_bridge *bridge, union hdmi_infoframe frm; u8 mhl_vic[] = { 0, 95, 94, 93, 98 }; + /* FIXME: We need the connector here */ drm_hdmi_vendor_infoframe_from_display_mode( - &frm.vendor.hdmi, adjusted_mode); + &frm.vendor.hdmi, NULL, adjusted_mode); vic = frm.vendor.hdmi.vic; if (vic >= ARRAY_SIZE(mhl_vic)) vic = 0; diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index a64ce7112288..b172139502d6 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1437,7 +1437,9 @@ static void hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi, u8 buffer[10]; ssize_t err; - err = drm_hdmi_vendor_infoframe_from_display_mode(&frame, mode); + err = drm_hdmi_vendor_infoframe_from_display_mode(&frame, + &hdmi->connector, + mode); if (err < 0) /* * Going into that statement does not means vendor infoframe diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 749d07a01772..9ada0ccf50df 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3393,6 +3393,7 @@ static int do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len, const u8 *video_db, u8 video_len) { + struct drm_display_info *info = &connector->display_info; int modes = 0, offset = 0, i, multi_present = 0, multi_len; u8 vic_len, hdmi_3d_len = 0; u16 mask; @@ -3520,6 +3521,8 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len, } out: + if (modes > 0) + info->has_hdmi_infoframe = true; return modes; } @@ -4243,6 +4246,8 @@ static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector, struct drm_display_info *display = &connector->display_info; struct drm_hdmi_info *hdmi = &display->hdmi; + display->has_hdmi_infoframe = true; + if (hf_vsdb[6] & 0x80) { hdmi->scdc.supported = true; if (hf_vsdb[6] & 0x40) @@ -4416,6 +4421,7 @@ static void drm_add_display_info(struct drm_connector *connector, info->cea_rev = 0; info->max_tmds_clock = 0; info->dvi_dual = false; + info->has_hdmi_infoframe = false; if (edid->revision < 3) return; @@ -4903,6 +4909,7 @@ s3d_structure_from_display_mode(const struct drm_display_mode *mod
[PATCH 03/10] drm/modes: Introduce drm_mode_match()
From: Ville Syrjälä Make mode matching less confusing by allowing the caller to specify which parts of the modes should match via some flags. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_modes.c | 134 ++-- include/drm/drm_modes.h | 9 +++ 2 files changed, 112 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 4a3f68a33844..8128dbb098be 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct drm_device *dev, } EXPORT_SYMBOL(drm_mode_duplicate); +static bool drm_mode_match_timings(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return mode1->hdisplay == mode2->hdisplay && + mode1->hsync_start == mode2->hsync_start && + mode1->hsync_end == mode2->hsync_end && + mode1->htotal == mode2->htotal && + mode1->hskew == mode2->hskew && + mode1->vdisplay == mode2->vdisplay && + mode1->vsync_start == mode2->vsync_start && + mode1->vsync_end == mode2->vsync_end && + mode1->vtotal == mode2->vtotal && + mode1->vscan == mode2->vscan; +} + +static bool drm_mode_match_clock(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + /* +* do clock check convert to PICOS +* so fb modes get matched the same +*/ + if (mode1->clock && mode2->clock) + return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock); + else + return mode1->clock == mode2->clock; +} + +static bool drm_mode_match_flags(const struct drm_display_mode *mode1, +const struct drm_display_mode *mode2) +{ + return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) == + (mode2->flags & ~DRM_MODE_FLAG_3D_MASK); +} + +static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return (mode1->flags & DRM_MODE_FLAG_3D_MASK) == + (mode2->flags & DRM_MODE_FLAG_3D_MASK); +} + +static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio; +} + /** - * drm_mode_equal - test modes for equality + * drm_mode_match - test modes for (partial) equality * @mode1: first mode * @mode2: second mode + * @match_flags: which parts need to match (DRM_MODE_MATCH_*) * * Check to see if @mode1 and @mode2 are equivalent. * * Returns: - * True if the modes are equal, false otherwise. + * True if the modes are (partially) equal, false otherwise. */ -bool drm_mode_equal(const struct drm_display_mode *mode1, const struct drm_display_mode *mode2) +bool drm_mode_match(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2, + unsigned int match_flags) { if (!mode1 && !mode2) return true; @@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode *mode1, const struct drm_displ if (!mode1 || !mode2) return false; - /* do clock check convert to PICOS so fb modes get matched -* the same */ - if (mode1->clock && mode2->clock) { - if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock)) - return false; - } else if (mode1->clock != mode2->clock) + if (match_flags & DRM_MODE_MATCH_TIMINGS && + !drm_mode_match_timings(mode1, mode2)) + return false; + + if (match_flags & DRM_MODE_MATCH_CLOCK && + !drm_mode_match_clock(mode1, mode2)) + return false; + + if (match_flags & DRM_MODE_MATCH_FLAGS && + !drm_mode_match_flags(mode1, mode2)) + return false; + + if (match_flags & DRM_MODE_MATCH_3D_FLAGS && + !drm_mode_match_3d_flags(mode1, mode2)) return false; - return drm_mode_equal_no_clocks(mode1, mode2); + if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO && + !drm_mode_match_aspect_ratio(mode1, mode2)) + return false; + + return true; +} +EXPORT_SYMBOL(drm_mode_match); + +/** + * drm_mode_equal - test modes for equality + * @mode1: first mode + * @mode2: second mode + * + * Check to see if @mode1 and @mode2 are equivalent. + * + * Returns: + * True if the modes are equal, false otherwise. + */ +bool drm_mode_equal(const struct drm_display_mode *mode1, + const struct drm_display_mode *mode2) +{ + return drm_mode_match(mode1, mode2, + DRM_MODE_MATCH_TIMINGS |
[PATCH 05/10] drm/edid: Fix up edid_cea_modes[] formatting
From: Ville Syrjälä Fix up a bunch of bad indentation and insconsistent comments in edid_cea_modes[]. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 84 +++--- 1 file changed, 42 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index b575c4b5a313..7220b8f9a7e8 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -685,43 +685,43 @@ static const struct drm_display_mode edid_cea_modes[] = { { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2008, 2052, 2200, 0, 1080, 1084, 1094, 1125, 0, DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC | - DRM_MODE_FLAG_INTERLACE), + DRM_MODE_FLAG_INTERLACE), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 6 - 720(1440)x480i@60Hz */ { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739, 801, 858, 0, 480, 488, 494, 525, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), + DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, }, /* 7 - 720(1440)x480i@60Hz */ { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739, 801, 858, 0, 480, 488, 494, 525, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), + DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 8 - 720(1440)x240@60Hz */ { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739, 801, 858, 0, 240, 244, 247, 262, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_DBLCLK), + DRM_MODE_FLAG_DBLCLK), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, }, /* 9 - 720(1440)x240@60Hz */ { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739, 801, 858, 0, 240, 244, 247, 262, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_DBLCLK), + DRM_MODE_FLAG_DBLCLK), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 10 - 2880x480i@60Hz */ { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956, 3204, 3432, 0, 480, 488, 494, 525, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_INTERLACE), + DRM_MODE_FLAG_INTERLACE), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, }, /* 11 - 2880x480i@60Hz */ { DRM_MODE("2880x480i", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956, 3204, 3432, 0, 480, 488, 494, 525, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_INTERLACE), + DRM_MODE_FLAG_INTERLACE), .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 12 - 2880x240@60Hz */ { DRM_MODE("2880x240", DRM_MODE_TYPE_DRIVER, 54000, 2880, 2956, @@ -767,43 +767,43 @@ static const struct drm_display_mode edid_cea_modes[] = { { DRM_MODE("1920x1080i", DRM_MODE_TYPE_DRIVER, 74250, 1920, 2448, 2492, 2640, 0, 1080, 1084, 1094, 1125, 0, DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC | - DRM_MODE_FLAG_INTERLACE), + DRM_MODE_FLAG_INTERLACE), .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 21 - 720(1440)x576i@50Hz */ { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732, 795, 864, 0, 576, 580, 586, 625, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), + DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, }, /* 22 - 720(1440)x576i@50Hz */ { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732, 795, 864, 0, 576, 580, 586, 625, 0, DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC | - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), + DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK), .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, }, /* 23 - 720(1440)x288@50Hz */ { DRM_MODE("720x288", DRM_MODE_TYPE_DRIVER, 13500, 720, 732, 795, 864, 0, 288, 290, 293, 31
[PATCH 01/10] video/hdmi: Allow "empty" HDMI infoframes
From: Ville Syrjälä HDMI 2.0 Appendix F suggest that we should keep sending the infoframe when switching from 3D to 2D mode, even if the infoframe isn't strictly necessary (ie. not needed to transmit the VIC or stereo information). This is a workaround against some sinks that fail to realize that they should switch from 3D to 2D mode when the source stop transmitting the infoframe. v2: Handle unpack() as well Pull the length calculation into a helper Cc: Shashank Sharma Cc: Andrzej Hajda Cc: Thierry Reding Cc: Hans Verkuil Cc: linux-me...@vger.kernel.org Reviewed-by: Andrzej Hajda #v1 Signed-off-by: Ville Syrjälä --- drivers/video/hdmi.c | 51 +++ 1 file changed, 31 insertions(+), 20 deletions(-) diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c index 1cf907ecded4..111a0ab6280a 100644 --- a/drivers/video/hdmi.c +++ b/drivers/video/hdmi.c @@ -321,6 +321,17 @@ int hdmi_vendor_infoframe_init(struct hdmi_vendor_infoframe *frame) } EXPORT_SYMBOL(hdmi_vendor_infoframe_init); +static int hdmi_vendor_infoframe_length(const struct hdmi_vendor_infoframe *frame) +{ + /* for side by side (half) we also need to provide 3D_Ext_Data */ + if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) + return 6; + else if (frame->vic != 0 || frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) + return 5; + else + return 4; +} + /** * hdmi_vendor_infoframe_pack() - write a HDMI vendor infoframe to binary buffer * @frame: HDMI infoframe @@ -341,19 +352,11 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame, u8 *ptr = buffer; size_t length; - /* empty info frame */ - if (frame->vic == 0 && frame->s3d_struct == HDMI_3D_STRUCTURE_INVALID) - return -EINVAL; - /* only one of those can be supplied */ if (frame->vic != 0 && frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) return -EINVAL; - /* for side by side (half) we also need to provide 3D_Ext_Data */ - if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) - frame->length = 6; - else - frame->length = 5; + frame->length = hdmi_vendor_infoframe_length(frame); length = HDMI_INFOFRAME_HEADER_SIZE + frame->length; @@ -372,14 +375,16 @@ ssize_t hdmi_vendor_infoframe_pack(struct hdmi_vendor_infoframe *frame, ptr[5] = 0x0c; ptr[6] = 0x00; - if (frame->vic) { - ptr[7] = 0x1 << 5; /* video format */ - ptr[8] = frame->vic; - } else { + if (frame->s3d_struct != HDMI_3D_STRUCTURE_INVALID) { ptr[7] = 0x2 << 5; /* video format */ ptr[8] = (frame->s3d_struct & 0xf) << 4; if (frame->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) ptr[9] = (frame->s3d_ext_data & 0xf) << 4; + } else if (frame->vic) { + ptr[7] = 0x1 << 5; /* video format */ + ptr[8] = frame->vic; + } else { + ptr[7] = 0x0 << 5; /* video format */ } hdmi_infoframe_set_checksum(buffer, length); @@ -1165,7 +1170,7 @@ hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame, if (ptr[0] != HDMI_INFOFRAME_TYPE_VENDOR || ptr[1] != 1 || - (ptr[2] != 5 && ptr[2] != 6)) + (ptr[2] != 4 && ptr[2] != 5 && ptr[2] != 6)) return -EINVAL; length = ptr[2]; @@ -1193,16 +1198,22 @@ hdmi_vendor_any_infoframe_unpack(union hdmi_vendor_any_infoframe *frame, hvf->length = length; - if (hdmi_video_format == 0x1) { - hvf->vic = ptr[4]; - } else if (hdmi_video_format == 0x2) { + if (hdmi_video_format == 0x2) { + if (length != 5 && length != 6) + return -EINVAL; hvf->s3d_struct = ptr[4] >> 4; if (hvf->s3d_struct >= HDMI_3D_STRUCTURE_SIDE_BY_SIDE_HALF) { - if (length == 6) - hvf->s3d_ext_data = ptr[5] >> 4; - else + if (length != 6) return -EINVAL; + hvf->s3d_ext_data = ptr[5] >> 4; } + } else if (hdmi_video_format == 0x1) { + if (length != 5) + return -EINVAL; + hvf->vic = ptr[4]; + } else { + if (length != 4) + return -EINVAL; } return 0; -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
From: Ville Syrjälä Use drm_mode_equal_no_clocks_no_stereo() in drm_match_hdmi_mode_clock_tolerance() for consistency as we also use it in drm_match_hdmi_mode() and the cea mode matching functions. This doesn't actually change anything since the input mode comes from detailed timings and we match it against edid_4k_modes[] which. So none of those modes can have stereo flags set. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 9ada0ccf50df..b575c4b5a313 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -3020,7 +3020,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode *to_ abs(to_match->clock - clock2) > clock_tolerance) continue; - if (drm_mode_equal_no_clocks(to_match, hdmi_mode)) + if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode)) return vic; } -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/10] drm/edid: Infoframe cleanups and fixes
From: Ville Syrjälä This series tries to fix some issues with HDMI infoframes. In particular we can currently send a bogus picture aspect ratio in the infoframe. I included stuff to to make the infoframe unpakc more robust, evne though we don't (yet) use it in drm. Additionally I included my earlier "empty" HDMI infoframe support. I have further work piled up on top which allows us to precompuet the infoframes during the atomic check phase. But the series would have become rather big, so I wanted to post these fixes and cleanups first. Entire series (with the infoframe precompute) is available here: git://github.com/vsyrjala/linux.git infoframe_precompute Cc: Akashdeep Sharma Cc: Andrzej Hajda Cc: Daniel Vetter Cc: Emil Velikov Cc: Hans Verkuil Cc: Jim Bride Cc: Jose Abreu Cc: Laurent Pinchart Cc: "Lin, Jia" Cc: linux-me...@vger.kernel.org Cc: Sean Paul Cc: Shashank Sharma Cc: Thierry Reding Ville Syrjälä (10): video/hdmi: Allow "empty" HDMI infoframes drm/edid: Allow HDMI infoframe without VIC or S3D drm/modes: Introduce drm_mode_match() drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy drm/edid: Fix up edid_cea_modes[] formatting drm/edid: Fix cea mode aspect ratio handling drm/edid: Don't send bogus aspect ratios in AVI infoframes video/hdmi: Reject illegal picture aspect ratios video/hdmi: Constify 'buffer' to the unpack functions video/hdmi: Pass buffer size to infoframe unpack functions drivers/gpu/drm/bridge/sil-sii8620.c | 3 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4 +- drivers/gpu/drm/drm_edid.c| 159 +++--- drivers/gpu/drm/drm_modes.c | 134 +++-- drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +- drivers/gpu/drm/i915/intel_hdmi.c | 14 +-- drivers/gpu/drm/mediatek/mtk_hdmi.c | 3 +- drivers/gpu/drm/nouveau/nv50_display.c| 3 +- drivers/gpu/drm/rockchip/inno_hdmi.c | 1 + drivers/gpu/drm/sti/sti_hdmi.c| 4 +- drivers/gpu/drm/zte/zx_hdmi.c | 1 + drivers/media/i2c/adv7511.c | 2 +- drivers/media/i2c/adv7604.c | 2 +- drivers/media/i2c/adv7842.c | 2 +- drivers/media/i2c/tc358743.c | 2 +- drivers/video/hdmi.c | 118 ++ include/drm/drm_connector.h | 5 + include/drm/drm_edid.h| 1 + include/drm/drm_modes.h | 9 ++ include/linux/hdmi.h | 3 +- 20 files changed, 326 insertions(+), 146 deletions(-) -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v2] amdgpu: Add memory over allocation test.
Allocates 1 TB of memory. Test is disabled by default since it's triggers OOM killer. v2: FIx the test to only alloc the BO and assert if return value not equal to -ENOMEM and remove test disable on start. Signed-off-by: Andrey Grodzovsky --- tests/amdgpu/bo_tests.c | 24 1 file changed, 24 insertions(+) diff --git a/tests/amdgpu/bo_tests.c b/tests/amdgpu/bo_tests.c index 4545196..53e76c1 100644 --- a/tests/amdgpu/bo_tests.c +++ b/tests/amdgpu/bo_tests.c @@ -47,6 +47,7 @@ static void amdgpu_bo_export_import(void); static void amdgpu_bo_metadata(void); static void amdgpu_bo_map_unmap(void); static void amdgpu_memory_alloc(void); +static void amdgpu_mem_fail_alloc(void); CU_TestInfo bo_tests[] = { { "Export/Import", amdgpu_bo_export_import }, @@ -55,6 +56,7 @@ CU_TestInfo bo_tests[] = { #endif { "CPU map/unmap", amdgpu_bo_map_unmap }, { "Memory alloc Test", amdgpu_memory_alloc }, + { "Memory fail alloc Test", amdgpu_mem_fail_alloc }, CU_TEST_INFO_NULL, }; @@ -244,3 +246,25 @@ static void amdgpu_memory_alloc(void) r = gpu_mem_free(bo, va_handle, bo_mc, 4096); CU_ASSERT_EQUAL(r, 0); } + +static void amdgpu_mem_fail_alloc(void) +{ + amdgpu_bo_handle bo; + int r; + struct amdgpu_bo_alloc_request req = {0}; + amdgpu_bo_handle buf_handle; + + /* Test impossible mem allocation, 1TB */ + req.alloc_size = 0xE8D4A51000; + req.phys_alignment = 4096; + req.preferred_heap = AMDGPU_GEM_DOMAIN_VRAM; + req.flags = AMDGPU_GEM_CREATE_NO_CPU_ACCESS; + + r = amdgpu_bo_alloc(device_handle, &req, &buf_handle); + CU_ASSERT_EQUAL(r, -ENOMEM); + + if (!r) { + r = amdgpu_bo_free(bo); + CU_ASSERT_EQUAL(r, 0); + } +} -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors
On Mon, Nov 13, 2017 at 2:35 AM, Dmitry V. Levin wrote: > Consistently use types provided by via > to fix the following linux/kfd_ioctl.h userspace compilation errors: > > /usr/include/linux/kfd_ioctl.h:236:2: error: unknown type name 'uint64_t' > uint64_t va_addr; /* to KFD */ > /usr/include/linux/kfd_ioctl.h:237:2: error: unknown type name 'uint32_t' > uint32_t gpu_id; /* to KFD */ > /usr/include/linux/kfd_ioctl.h:238:2: error: unknown type name 'uint32_t' > uint32_t pad; > /usr/include/linux/kfd_ioctl.h:243:2: error: unknown type name 'uint64_t' > uint64_t tile_config_ptr; > /usr/include/linux/kfd_ioctl.h:245:2: error: unknown type name 'uint64_t' > uint64_t macro_tile_config_ptr; > /usr/include/linux/kfd_ioctl.h:249:2: error: unknown type name 'uint32_t' > uint32_t num_tile_configs; > /usr/include/linux/kfd_ioctl.h:253:2: error: unknown type name 'uint32_t' > uint32_t num_macro_tile_configs; > /usr/include/linux/kfd_ioctl.h:255:2: error: unknown type name 'uint32_t' > uint32_t gpu_id; /* to KFD */ > /usr/include/linux/kfd_ioctl.h:256:2: error: unknown type name 'uint32_t' > uint32_t gb_addr_config; /* from KFD */ > /usr/include/linux/kfd_ioctl.h:257:2: error: unknown type name 'uint32_t' > uint32_t num_banks; /* from KFD */ > /usr/include/linux/kfd_ioctl.h:258:2: error: unknown type name 'uint32_t' > uint32_t num_ranks; /* from KFD */ > > Fixes: 6a1c9510694fe ("drm/amdkfd: Adding new IOCTL for scratch memory v2") > Fixes: 5d71dbc3a5886 ("drm/amdkfd: Implement image tiling mode support v2") > Signed-off-by: Dmitry V. Levin > --- > include/uapi/linux/kfd_ioctl.h | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > diff --git a/include/uapi/linux/kfd_ioctl.h b/include/uapi/linux/kfd_ioctl.h > index 26283fefdf5f..f7015aa12347 100644 > --- a/include/uapi/linux/kfd_ioctl.h > +++ b/include/uapi/linux/kfd_ioctl.h > @@ -233,29 +233,29 @@ struct kfd_ioctl_wait_events_args { > }; > > struct kfd_ioctl_set_scratch_backing_va_args { > - uint64_t va_addr; /* to KFD */ > - uint32_t gpu_id;/* to KFD */ > - uint32_t pad; > + __u64 va_addr; /* to KFD */ > + __u32 gpu_id; /* to KFD */ > + __u32 pad; > }; > > struct kfd_ioctl_get_tile_config_args { > /* to KFD: pointer to tile array */ > - uint64_t tile_config_ptr; > + __u64 tile_config_ptr; > /* to KFD: pointer to macro tile array */ > - uint64_t macro_tile_config_ptr; > + __u64 macro_tile_config_ptr; > /* to KFD: array size allocated by user mode > * from KFD: array size filled by kernel > */ > - uint32_t num_tile_configs; > + __u32 num_tile_configs; > /* to KFD: array size allocated by user mode > * from KFD: array size filled by kernel > */ > - uint32_t num_macro_tile_configs; > + __u32 num_macro_tile_configs; > > - uint32_t gpu_id;/* to KFD */ > - uint32_t gb_addr_config;/* from KFD */ > - uint32_t num_banks; /* from KFD */ > - uint32_t num_ranks; /* from KFD */ > + __u32 gpu_id; /* to KFD */ > + __u32 gb_addr_config; /* from KFD */ > + __u32 num_banks;/* from KFD */ > + __u32 num_ranks;/* from KFD */ > /* struct size can be extended later if needed > * without breaking ABI compatibility > */ > -- > ldv Thanks! Applied to -fixes Oded ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix amdkfd use-after-free GP fault
On Sat, Nov 11, 2017 at 8:16 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix GP fault caused by dev_info() reference to a struct device* > after the device has been freed (use after free). > kfd_chardev_exit() frees the device so 'kfd_device' should not > be used after calling kfd_chardev_exit(). > > To reproduce, just load the module and then unload it. > Note that %RAX contains repeated 0x6b, which is use-after-free > poisoning. > > [ 946.645809] calling kfd_module_init+0x0/0x1000 [amdkfd] @ 5785 > [ 946.646025] CRAT table not found > [ 946.646027] Finished initializing topology ret=0 > [ 946.646050] kfd kfd: Initialized module > [ 946.646058] initcall kfd_module_init+0x0/0x1000 [amdkfd] returned 0 after > 233 usecs > [ 947.650189] general protection fault: [#1] PREEMPT SMP > [ 947.650192] Modules linked in: amdkfd(-) amd_iommu_v2 dw_hdmi cec rc_core > mxm_wmi ttm dln2 gpio_max730x tps65218 lp3943 mcb crc4 fpga_mgr fpga_bridge > fmc fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common > xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 > nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT > iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_broadcast > nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack > libcrc32c ip6table_filter ip6_tables x_tables coretemp hwmon intel_rapl > x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm irqbypass > crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc > aesni_intel uvcvideo videobuf2_vmalloc aes_x86_64 videobuf2_memops > hid_generic videobuf2_v4l2 > [ 947.650224] crypto_simd snd_hda_codec_hdmi videobuf2_core usbmouse > videodev snd_hda_codec_realtek glue_helper usbhid media hid > snd_hda_codec_generic snd_hda_intel arc4 snd_hda_codec cryptd iwldvm > sdhci_pci snd_hda_core sdhci mmc_core mac80211 snd_hwdep iTCO_wdt snd_pcm > iTCO_vendor_support xhci_pci intel_cstate xhci_hcd i915 snd_seq > snd_seq_device ehci_pci snd_timer toshiba_acpi ehci_hcd snd usbcore iwlwifi > sparse_keymap e1000e cfg80211 input_leds ptp wmi sr_mod intel_uncore mei_me > lpc_ich led_class cdrom usb_common pps_core mei joydev intel_rapl_perf > mousedev evdev industrialio toshiba_bluetooth shpchp mac_hid rfkill soundcore > serio_raw pcspkr toshiba_haps battery video thermal ac button sg autofs4 > [last unloaded: radeon] > [ 947.650259] CPU: 3 PID: 5791 Comm: rmmod Not tainted 4.14.0-rc8 #4 > [ 947.650260] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version > 4.10 01/08/2013 > [ 947.650262] task: 97144a3f2840 task.stack: a51e409c4000 > [ 947.650266] RIP: 0010:__dev_printk+0x29/0x90 > [ 947.650267] RSP: 0018:a51e409c7e48 EFLAGS: 00010202 > [ 947.650269] RAX: 6b6b6b6b6b6b6b6b RBX: 97a579c3 RCX: > 000100140013 > [ 947.650270] RDX: a51e409c7e78 RSI: 97139e360558 RDI: > 97a579c3 > [ 947.650271] RBP: a51e409c7e68 R08: 6b6b6b6b6b6b6b6b R09: > a51e409c7e78 > [ 947.650272] R10: 9714465c44b8 R11: 9714465c55e8 R12: > 7fff874111f7 > [ 947.650273] R13: 0800 R14: 006231c0 R15: > 00623010 > [ 947.650275] FS: 7fe8a109d700() GS:97144fac() > knlGS: > [ 947.650276] CS: 0010 DS: ES: CR0: 80050033 > [ 947.650277] CR2: 0062cc88 CR3: 00013fd43005 CR4: > 000606e0 > [ 947.650279] Call Trace: > [ 947.650283] ? kobject_cleanup+0x75/0x170 > [ 947.650284] _dev_info+0x57/0x60 > [ 947.650288] ? kfree+0xf5/0x140 > [ 947.650295] kfd_module_exit+0x37/0x39 [amdkfd] > [ 947.650299] SyS_delete_module+0x14d/0x260 > [ 947.650302] ? exit_to_usermode_loop+0x60/0x87 > [ 947.650305] entry_SYSCALL_64_fastpath+0x1e/0xa9 > [ 947.650307] RIP: 0033:0x7fe8a0beff97 > [ 947.650308] RSP: 002b:7fff8740ffc8 EFLAGS: 0202 ORIG_RAX: > 00b0 > [ 947.650310] RAX: ffda RBX: 0003 RCX: > 7fe8a0beff97 > [ 947.650311] RDX: 7fe8a0c56920 RSI: 0800 RDI: > 00623228 > [ 947.650312] RBP: 006231c0 R08: 7fe8a0ea3f20 R09: > 7fff8740ef41 > [ 947.650313] R10: 2ef31b7d R11: 0202 R12: > 7fff8740efc0 > [ 947.650314] R13: R14: 006231c0 R15: > 00623010 > [ 947.650316] Code: 00 00 55 49 89 d1 48 89 e5 53 48 89 fb 48 83 ec 18 48 85 > f6 74 5f 4c 8b 46 50 4d 85 c0 74 2b 48 8b 86 88 00 00 00 48 85 c0 74 25 <48> > 8b 08 0f be 7b 01 48 c7 c2 96 0a aa 97 31 c0 83 ef 30 e8 7f > [ 947.650339] RIP: __dev_printk+0x29/0x90 RSP: a51e409c7e48 > [ 947.650388] ---[ end trace c41965e147ae98ae ]--- > > Signed-off-by: Randy Dunlap > Cc: Oded Gabbay > Cc: dri-devel@lists.freedesktop.org > --- > drivers/gpu/drm/amd/amdkfd/kfd_module.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- lnx-414-rc8.orig/drivers/gpu/drm/amd/amdkfd/kfd_module.c > ++
Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.
On 11/13/2017 10:27 AM, Christian König wrote: Am 13.11.2017 um 15:57 schrieb Andrey Grodzovsky: On 11/13/2017 07:39 AM, Christian König wrote: Am 13.11.2017 um 12:32 schrieb Michel Dänzer: On 12/11/17 10:35 AM, Christian König wrote: A few comments on the code: +/* Validate bo size is bit bigger then the request domain */ +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device *adev, + unsigned long size, u32 domain) Drop the inline keyword and the second _bo_ in the name here. +{ +struct ttm_mem_type_manager *man = NULL; + +if (domain & AMDGPU_GEM_DOMAIN_VRAM) { +man = &adev->mman.bdev.man[TTM_PL_VRAM]; + +if (man && size < (man->size << PAGE_SHIFT)) Drop the extra check that man is not NULL. We get the pointer to an array element, that can't be NULL. +return true; Mhm, domain is a bitmask of allowed domains. So we should check all valid domains if the size fit, not just the first one. Assuming VRAM <-> system migration of BOs larger than the GTT domain works, I'd say we should only require that the BO can fit in any of the allowed domains. Otherwise it must also always fit in GTT. Good point, and yes VRAM <-> system migration of BOs larger than the GTT domain works now. I can agree on that VRAM should probably be optional, otherwise we can't allocate anything large when the driver uses only very low amounts of stolen VRAM on APUs. But I think when userspace requests VRAM and GTT at the same time we still should be able to fall back to GTT. Attached V2 patch, I still don't understand why I experience the SIGSEV in the tester when the check fails and the IOCTLs will return ENOMEM Reviewed-by: Christian König for this one, but please use git send-email to send out patches. I will update the libdrm test to correctly handle mem failure, it segfaults at the moment. Sounds like it just tries to use the BO for VM or CPU mapping while the underlying function has failed (or we have another bug somewhere). Yes, the segfault is because I am using gpu_mem_alloc which continues executing after amdgpu_bo_alloc failed, the segfault is in amdgpu_bo_va_op. Please commit the kernel patch and leave me a note so that I can push the libdrm patches. Areyou gonna push patches 1-3 from the original series and then I need to resend patch 4 to fix the segfault ? BTW: Do you have the link where you request an account at hand? I want to ping the admins once more. https://bugs.freedesktop.org/show_bug.cgi?id=103566 Thanks, Andrey Regards, Christian. Thanks, Andey Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup
Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed. Note that the nodes returned from the two calls to of_parse_phandle() are also leaking, but fixing that is a bit more involved as pointers to node fields are being stored for later use. Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support") Cc: stable # 3.10 Cc: Guennadi Liakhovetski Signed-off-by: Johan Hovold --- drivers/video/backlight/as3711_bl.c | 35 +-- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/drivers/video/backlight/as3711_bl.c b/drivers/video/backlight/as3711_bl.c index 734a9158946b..21ce56053c88 100644 --- a/drivers/video/backlight/as3711_bl.c +++ b/drivers/video/backlight/as3711_bl.c @@ -262,15 +262,16 @@ static int as3711_bl_register(struct platform_device *pdev, static int as3711_backlight_parse_dt(struct device *dev) { struct as3711_bl_pdata *pdata = dev_get_platdata(dev); - struct device_node *bl = - of_find_node_by_name(dev->parent->of_node, "backlight"), *fb; + struct device_node *bl, *fb; int ret; + bl = of_get_child_by_name(dev->parent->of_node, "backlight"); if (!bl) { dev_dbg(dev, "backlight node not found\n"); return -ENODEV; } + /* FIXME: need to drop reference to returned node */ fb = of_parse_phandle(bl, "su1-dev", 0); if (fb) { pdata->su1_fb = fb->full_name; @@ -279,9 +280,10 @@ static int as3711_backlight_parse_dt(struct device *dev) if (pdata->su1_max_uA <= 0) ret = -EINVAL; if (ret < 0) - return ret; + goto err_put_bl; } + /* FIXME: need to drop reference to returned node */ fb = of_parse_phandle(bl, "su2-dev", 0); if (fb) { int count = 0; @@ -292,7 +294,7 @@ static int as3711_backlight_parse_dt(struct device *dev) if (pdata->su2_max_uA <= 0) ret = -EINVAL; if (ret < 0) - return ret; + goto err_put_bl; if (of_find_property(bl, "su2-feedback-voltage", NULL)) { pdata->su2_feedback = AS3711_SU2_VOLTAGE; @@ -314,8 +316,10 @@ static int as3711_backlight_parse_dt(struct device *dev) pdata->su2_feedback = AS3711_SU2_CURR_AUTO; count++; } - if (count != 1) - return -EINVAL; + if (count != 1) { + ret = -EINVAL; + goto err_put_bl; + } count = 0; if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) { @@ -334,8 +338,10 @@ static int as3711_backlight_parse_dt(struct device *dev) pdata->su2_fbprot = AS3711_SU2_GPIO4; count++; } - if (count != 1) - return -EINVAL; + if (count != 1) { + ret = -EINVAL; + goto err_put_bl; + } count = 0; if (of_find_property(bl, "su2-auto-curr1", NULL)) { @@ -355,11 +361,20 @@ static int as3711_backlight_parse_dt(struct device *dev) * At least one su2-auto-curr* must be specified iff * AS3711_SU2_CURR_AUTO is used */ - if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) - return -EINVAL; + if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) { + ret = -EINVAL; + goto err_put_bl; + } } + of_node_put(bl); + return 0; + +err_put_bl: + of_node_put(bl); + + return ret; } static int as3711_backlight_probe(struct platform_device *pdev) -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] backlight: tps65217_bl: fix device-tree node lookup
Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. This would only cause trouble if the child node is missing while there is an unrelated node named "backlight" elsewhere in the tree. Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver") Cc: stable # 3.7 Cc: Matthias Kaehlcke Signed-off-by: Johan Hovold --- drivers/video/backlight/tps65217_bl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/tps65217_bl.c b/drivers/video/backlight/tps65217_bl.c index 380917c86276..762e3feed097 100644 --- a/drivers/video/backlight/tps65217_bl.c +++ b/drivers/video/backlight/tps65217_bl.c @@ -184,11 +184,11 @@ static struct tps65217_bl_pdata * tps65217_bl_parse_dt(struct platform_device *pdev) { struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent); - struct device_node *node = of_node_get(tps->dev->of_node); + struct device_node *node; struct tps65217_bl_pdata *pdata, *err; u32 val; - node = of_find_node_by_name(node, "backlight"); + node = of_get_child_by_name(tps->dev->of_node, "backlight"); if (!node) return ERR_PTR(-ENODEV); -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: atmel_lcdfb: fix display-timings lookup
Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent display node was also prematurely freed. Note that the display and timings node references are never put after a successful dt-initialisation so the nodes would leak on later probe deferrals and on driver unbind. Fixes: b985172b328a ("video: atmel_lcdfb: add device tree suport") Cc: stable # 3.13 Cc: Jean-Christophe PLAGNIOL-VILLARD Signed-off-by: Johan Hovold --- drivers/video/fbdev/atmel_lcdfb.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c index e06358da4b99..3dee267d7c75 100644 --- a/drivers/video/fbdev/atmel_lcdfb.c +++ b/drivers/video/fbdev/atmel_lcdfb.c @@ -1119,7 +1119,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo) goto put_display_node; } - timings_np = of_find_node_by_name(display_np, "display-timings"); + timings_np = of_get_child_by_name(display_np, "display-timings"); if (!timings_np) { dev_err(dev, "failed to find display-timings node\n"); ret = -ENODEV; @@ -1140,6 +1140,12 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info *sinfo) fb_add_videomode(&fb_vm, &info->modelist); } + /* +* FIXME: Make sure we are not referencing any fields in display_np +* and timings_np and drop our references to them before returning to +* avoid leaking the nodes on probe deferral and driver unbind. +*/ + return 0; put_timings_node: -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] backlight: max8925_bl: fix device-tree node lookup
Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed, while the child backlight node was leaked. Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight") Cc: stable # 3.9 Cc: Qing Xu Cc: Haojian Zhuang Signed-off-by: Johan Hovold --- drivers/video/backlight/max8925_bl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/max8925_bl.c b/drivers/video/backlight/max8925_bl.c index 7b738d60ecc2..f3aa6088f1d9 100644 --- a/drivers/video/backlight/max8925_bl.c +++ b/drivers/video/backlight/max8925_bl.c @@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(struct platform_device *pdev) if (!pdata) return; - np = of_find_node_by_name(nproot, "backlight"); + np = of_get_child_by_name(nproot, "backlight"); if (!np) { dev_err(&pdev->dev, "failed to find backlight node\n"); return; @@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(struct platform_device *pdev) if (!of_property_read_u32(np, "maxim,max8925-dual-string", &val)) pdata->dual_string = val; + of_node_put(np); + pdev->dev.platform_data = pdata; } -- 2.15.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] drm/tegra: Implement dynamic channel allocation model
On 07.11.2017 15:29, Mikko Perttunen wrote: > On 05.11.2017 19:43, Dmitry Osipenko wrote: >> On 05.11.2017 14:01, Mikko Perttunen wrote: >>> In the traditional channel allocation model, a single hardware channel >>> was allocated for each client. This is simple from an implementation >>> perspective but prevents use of hardware scheduling. >>> >>> This patch implements a channel allocation model where when a user >>> submits a job for a context, a hardware channel is allocated for >>> that context. The same channel is kept for as long as there are >>> incomplete jobs for that context. This way we can use hardware >>> scheduling and channel isolation between userspace processes, but >>> also prevent idling contexts from taking up hardware resources. >>> >> >> The dynamic channels resources (pushbuf) allocation is very expensive, >> neglecting all benefits that this model should bring at least in non-IOMMU >> case. >> We could have statically preallocated channels resources or defer resources >> freeing. > > This is true. I'll try to figure out a nice way to keep the pushbuf > allocations. One variant could be to have all channels resources statically preallocated in a non-IOMMU case because CMA is expensive. Then you should measure the allocations impact in a case of IOMMU allocations and if it is significant, maybe implement Host1x PM autosuspend, releasing all channels when Host1x become idle. I think the above should be efficient and easy to implement. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: linux-next: manual merge of the devicetree tree with the drm tree
On 11/13/17 07:58, Stephen Rothwell wrote: > Hi all, > > On Mon, 30 Oct 2017 20:37:56 + Mark Brown wrote: >> >> Today's linux-next merge of the devicetree tree got a conflict in: >> >> drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c >> >> between commit: >> >> 44cd3939c111b7 ("drm/tilcdc: Remove redundant OF_DETACHED flag setting") >> >> from the drm tree and commit: >> >> f948d6d8b792bb ("of: overlay: avoid race condition between applying >> multiple overlays") >> >> from the devicetree tree. >> >> I fixed it up (see below) and can carry the fix as necessary. This >> is now fixed as far as linux-next is concerned, but any non trivial >> conflicts should be mentioned to your upstream maintainer when your tree >> is submitted for merging. You may also want to consider cooperating >> with the maintainer of the conflicting tree to minimise any particularly >> complex conflicts. >> >> diff --cc drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c >> index 482299a6f3b0,54025af534d4.. >> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c >> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c >> @@@ -163,12 -162,8 +162,6 @@@ static struct device_node * __init tilc >> return NULL; >> } >> >> -ret = of_resolve_phandles(overlay); >> -if (ret) { >> -pr_err("%s: Failed to resolve phandles: %d\n", __func__, ret); >> -return NULL; >> -} >> - of_node_set_flag(overlay, OF_DETACHED); >> -- >> return overlay; >> } >> > > Just a reminder that this conflict still exists. > After some consideration, I think we can drop the dts backward compatibility code from drm/tilcdc. It seems that it is causing a lot of trouble and I do not even know if anybody uses it anymore. Here is a patch for dropping it: https://lists.freedesktop.org/archives/dri-devel/2017-November/157394.html I did not plan to merge it before v4.16, but if this is a bigger problem I can push is right now for v4.15. Best regards, Jyri -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103697] [regression] shared memory size 64k -> 32k?
https://bugs.freedesktop.org/show_bug.cgi?id=103697 --- Comment #2 from O Heid --- I checked back with AMD and they say that there is hardware support for 64kB shared memory. This actually gets exposed in OpenCL and ROCm/HC. The 2016 AMD GCN3 manual wrongly states it is only 32kB, but the AMD Vega ISA reference guide has the correct 64kB LDS size. So it seems the restriction is due to the mesa software stack, not due to hardware. Could you please raise the bar back to 64kB? I wouldn't ask if it wouldn't hit me with with a 2x performance penalty... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.
Am 13.11.2017 um 15:57 schrieb Andrey Grodzovsky: On 11/13/2017 07:39 AM, Christian König wrote: Am 13.11.2017 um 12:32 schrieb Michel Dänzer: On 12/11/17 10:35 AM, Christian König wrote: A few comments on the code: +/* Validate bo size is bit bigger then the request domain */ +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device *adev, + unsigned long size, u32 domain) Drop the inline keyword and the second _bo_ in the name here. +{ + struct ttm_mem_type_manager *man = NULL; + + if (domain & AMDGPU_GEM_DOMAIN_VRAM) { + man = &adev->mman.bdev.man[TTM_PL_VRAM]; + + if (man && size < (man->size << PAGE_SHIFT)) Drop the extra check that man is not NULL. We get the pointer to an array element, that can't be NULL. + return true; Mhm, domain is a bitmask of allowed domains. So we should check all valid domains if the size fit, not just the first one. Assuming VRAM <-> system migration of BOs larger than the GTT domain works, I'd say we should only require that the BO can fit in any of the allowed domains. Otherwise it must also always fit in GTT. Good point, and yes VRAM <-> system migration of BOs larger than the GTT domain works now. I can agree on that VRAM should probably be optional, otherwise we can't allocate anything large when the driver uses only very low amounts of stolen VRAM on APUs. But I think when userspace requests VRAM and GTT at the same time we still should be able to fall back to GTT. Attached V2 patch, I still don't understand why I experience the SIGSEV in the tester when the check fails and the IOCTLs will return ENOMEM Reviewed-by: Christian König for this one, but please use git send-email to send out patches. I will update the libdrm test to correctly handle mem failure, it segfaults at the moment. Sounds like it just tries to use the BO for VM or CPU mapping while the underlying function has failed (or we have another bug somewhere). Please commit the kernel patch and leave me a note so that I can push the libdrm patches. BTW: Do you have the link where you request an account at hand? I want to ping the admins once more. Regards, Christian. Thanks, Andey Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vblank: Fix vblank timestamp debugs
On Mon, Nov 13, 2017 at 4:02 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > We're currently calling ktime_to_timespec64() on stack garbage > hence the debug output for vblank timestamps also contains garbage. > Let's assing something to the ktime_t first before we go converting > it to a timespec. > > While at it micro-optimize the ktime_to_timespec64() calls away > when vblank debugging isn't enabled. > > Fixes: 67680d3c0464 ("drm: vblank: use ktime_t instead of timeval") Acked-by: Arnd Bergmann Sorry about the mess and thanks for cleaning up behind me. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197851] Resume from suspend sometimes results in black screen on Radeon R5
https://bugzilla.kernel.org/show_bug.cgi?id=197851 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vblank: Fix vblank timestamp debugs
From: Ville Syrjälä We're currently calling ktime_to_timespec64() on stack garbage hence the debug output for vblank timestamps also contains garbage. Let's assing something to the ktime_t first before we go converting it to a timespec. While at it micro-optimize the ktime_to_timespec64() calls away when vblank debugging isn't enabled. Fixes: 67680d3c0464 ("drm: vblank: use ktime_t instead of timeval") Cc: Arnd Bergmann Cc: Keith Packard Cc: Sean Paul Cc: Dave Airlie Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_vblank.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 09c1c4ff93ca..2c68909637b5 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -664,14 +664,16 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, delta_ns = div_s64(100LL * (vpos * mode->crtc_htotal + hpos), mode->crtc_clock); - /* save this only for debugging purposes */ - ts_etime = ktime_to_timespec64(etime); - ts_vblank_time = ktime_to_timespec64(*vblank_time); /* Subtract time delta from raw timestamp to get final * vblank_time timestamp for end of vblank. */ - etime = ktime_sub_ns(etime, delta_ns); - *vblank_time = etime; + *vblank_time = ktime_sub_ns(etime, delta_ns); + + if ((drm_debug & DRM_UT_VBL) == 0) + return true; + + ts_etime = ktime_to_timespec64(etime); + ts_vblank_time = ktime_to_timespec64(*vblank_time); DRM_DEBUG_VBL("crtc %u : v p(%d,%d)@ %lld.%06ld -> %lld.%06ld [e %d us, %d rep]\n", pipe, hpos, vpos, -- 2.13.6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 197841] lg 25um58-P monitor wrong refresh rate with rx 460
https://bugzilla.kernel.org/show_bug.cgi?id=197841 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.
On 11/13/2017 07:39 AM, Christian König wrote: Am 13.11.2017 um 12:32 schrieb Michel Dänzer: On 12/11/17 10:35 AM, Christian König wrote: A few comments on the code: +/* Validate bo size is bit bigger then the request domain */ +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device *adev, + unsigned long size, u32 domain) Drop the inline keyword and the second _bo_ in the name here. +{ +struct ttm_mem_type_manager *man = NULL; + +if (domain & AMDGPU_GEM_DOMAIN_VRAM) { +man = &adev->mman.bdev.man[TTM_PL_VRAM]; + +if (man && size < (man->size << PAGE_SHIFT)) Drop the extra check that man is not NULL. We get the pointer to an array element, that can't be NULL. +return true; Mhm, domain is a bitmask of allowed domains. So we should check all valid domains if the size fit, not just the first one. Assuming VRAM <-> system migration of BOs larger than the GTT domain works, I'd say we should only require that the BO can fit in any of the allowed domains. Otherwise it must also always fit in GTT. Good point, and yes VRAM <-> system migration of BOs larger than the GTT domain works now. I can agree on that VRAM should probably be optional, otherwise we can't allocate anything large when the driver uses only very low amounts of stolen VRAM on APUs. But I think when userspace requests VRAM and GTT at the same time we still should be able to fall back to GTT. Attached V2 patch, I still don't understand why I experience the SIGSEV in the tester when the check fails and the IOCTLs will return ENOMEM I will update the libdrm test to correctly handle mem failure, it segfaults at the moment. Thanks, Andey Regards, Christian. >From 37369b3a58027dedf7e9dc65fd9bc0f9e86d0d80 Mon Sep 17 00:00:00 2001 From: Andrey Grodzovsky Date: Fri, 10 Nov 2017 18:35:56 -0500 Subject: drm/amdgpu: Implement BO size validation V2 Validates BO size against each requested domain's total memory. v2: Make GTT size check a MUST to allow fall back to GTT. Rmove redundant NULL check. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 41 ++ 1 file changed, 41 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c index a937c49..5acf20c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -281,6 +281,44 @@ void amdgpu_bo_free_kernel(struct amdgpu_bo **bo, u64 *gpu_addr, *cpu_addr = NULL; } +/* Validate bo size is bit bigger then the request domain */ +static bool amdgpu_bo_validate_size(struct amdgpu_device *adev, + unsigned long size, u32 domain) +{ + struct ttm_mem_type_manager *man = NULL; + + /* + * If GTT is part of requested domains the check must succeed to + * allow fall back to GTT + */ + if (domain & AMDGPU_GEM_DOMAIN_GTT) { + man = &adev->mman.bdev.man[TTM_PL_TT]; + + if (size < (man->size << PAGE_SHIFT)) + return true; + else + goto fail; + } + + if (domain & AMDGPU_GEM_DOMAIN_VRAM) { + man = &adev->mman.bdev.man[TTM_PL_VRAM]; + + if (size < (man->size << PAGE_SHIFT)) + return true; + else + goto fail; + } + + + /* TODO add more domains checks, such as AMDGPU_GEM_DOMAIN_CPU */ + return true; + +fail: + DRM_ERROR("BO size %lu > total memory in domain: %llu\n", size, + man->size << PAGE_SHIFT); + return false; +} + static int amdgpu_bo_do_create(struct amdgpu_device *adev, unsigned long size, int byte_align, bool kernel, u32 domain, u64 flags, @@ -299,6 +337,9 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev, page_align = roundup(byte_align, PAGE_SIZE) >> PAGE_SHIFT; size = ALIGN(size, PAGE_SIZE); + if (!amdgpu_bo_validate_size(adev, size, domain)) + return -ENOMEM; + if (kernel) { type = ttm_bo_type_kernel; } else if (sg) { -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver
Reivewed-by: Horace Chen -Original Message- From: Liu, Monk Sent: Monday, November 13, 2017 11:43 AM To: Chen, Horace ; Colin King ; Deucher, Alexander ; Koenig, Christian ; David Airlie ; Yu, Xiangliang ; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver Importance: High + Horace -Original Message- From: Colin King [mailto:colin.k...@canonical.com] Sent: 2017年11月11日 19:51 To: Deucher, Alexander ; Koenig, Christian ; David Airlie ; Liu, Monk ; Yu, Xiangliang ; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: [PATCH] drm/amdgpu/virt: remove redundant variable pf2vf_ver From: Colin Ian King Variable pf2vf_ver is assigned but never read, it is redundant and hence can be removed. Cleans up clang warning: drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:310:3: warning: Value stored to 'pf2vf_ver' is never read Signed-off-by: Colin Ian King --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c index 6738df836a70..b1cc179512fa 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c @@ -296,7 +296,6 @@ int amdgpu_virt_fw_reserve_get_checksum(void *obj, void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev) { - uint32_t pf2vf_ver = 0; uint32_t pf2vf_size = 0; uint32_t checksum = 0; uint32_t checkval; @@ -309,7 +308,6 @@ void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev) adev->virt.fw_reserve.p_pf2vf = (struct amdgim_pf2vf_info_header *)( adev->fw_vram_usage.va + AMDGIM_DATAEXCHANGE_OFFSET); - pf2vf_ver = adev->virt.fw_reserve.p_pf2vf->version; AMDGPU_FW_VRAM_PF2VF_READ(adev, header.size, &pf2vf_size); AMDGPU_FW_VRAM_PF2VF_READ(adev, checksum, &checksum); -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
Hi Inki, On 2017-11-13 02:24, Inki Dae wrote: Hi Marek, 2017년 11월 10일 16:35에 Marek Szyprowski 이(가) 쓴 글: Dear Inki, On 2017-11-10 04:04, Inki Dae wrote: 2017년 11월 01일 01:28에 Marek Szyprowski 이(가) 쓴 글: When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver are contiguous, because of the underlying dma_alloc_attrs() function provides only such buffers. In such case it makes no sense to keep What if user disabled CMA support? In this case, it guarantees also to allocate physically contiguous memory? I think it depends on CMA support so wouldn't be true. dma_alloc_attrs() always guarantees the contiguity of the allocated memory in DMA address space. When NOIOMMU is available, this mean that the allocated buffer is contiguous in the physical memory. When CMA is disabled, dma_alloc_attrs() uses alloc_pages() allocator. The drawback of alloc_pages() is that it easily fails if physical memory is fragmented and it cannot allocate memory larger than MAX_ORDER (4MiB in case of ARM32bit). You are right. Without IOMMU suppot alloc_pages always tryies to allocate contiguous memory, order = get_order(size); page = alloc_pages(..., order); if (!page) return NULL; ... Right Real problem I think is that user don't know whether the gem buffer allocated with CONTIG or NONCONTIG flag can be used as a SCANOUT buffer. So user can request a page flip with NONCONTIG buffer to kernel which doesn't support IOMMU. And another is that user may want to use NONCONTIG buffer for another purpose, not scanout. So if we enforce on using CONTIG buffer on kernel without IOMMU support, then it wouldn't be really what user intended. When IOMMU support is disabled, ANY buffer allocated with dma_alloc_attrs() will be contiguous, so I see no point propagating incorrect flag for it. The only way to create a NONCONTIG buffer with IOMMU disabled is to import it from other driver and this path is already handled correctly. My idea is to provide a new flag - i.e., EXYNOS_BO_SCANOUT - which can allocate a buffer with a different allocation type - CONTIG or NONCONTIG - according to IOMMU support. And any page flip request with NONCONTIG buffer to kernel without IOMMU support should fail and it has to return a error with a proper error message. I don't think that we need it. With the proposed patch the same userspace will work fine in both cases IOMMU enabled and disabled, even if it allocate GEM with NONCONTIG flag. We can assume that CONTIG is a special case of NONCONTIG then. The problem is really not whether user space will work fine or not but is that this may be not what user space wanted. I.e., user space expects the allocated buffer is NONCONTIG buffer because user space requested NONCONTIG buffer but kernel internally, this is changed to CONTIG buffer. What's the problem when kernel allocated contiguous buffer but user requested non-contiguous? Contiguous is a subclass of non-contiguous in general. There is no driver nor scenario which will not work because of such change (any code for handing n-segments should be fine with only 1 segment). In some conditions, by luck, kernel might allocate a contiguous buffer even with IOMMU enabled. When we know that the buffer is contiguous, then flag it as such. So you could provide some information - maybe warning message?? - to user space the buffer type is changed to CONTIG buffer due to NO IOMMU support. I don't think this needs a warning. I just think that when we know that the allocated buffer IS contiguous there is no point flagging it as non-contiguous and fail a few calls later although the driver allocated the contiguous buffer in fact. That's all. Regarding the buffer type Exynos DRM has, I'm not sure that providing CONTIG and NONCONTIG buffer types to user space is reasonable because I think such buffer types - physically contiguous or non contiguous - should be transparent to user space. And I looked into other ARM DRM drivers - omap and msm provides SCANOUT buffer type, tegra and rockchip have no such buffer types (contiguous or non-contiguous). This is also a thing I felt while working on kernel in collaborating with Platform guys - we made user spaces to care about the memory allocation way. I wonder why you say SCANOUT type is incorrect flag. I'm not against adding SCANOUT flag. It is a good idea in general, especially if the driver can simply select which set of flags will be best for such use case on the given hardware (IOMMU is practically always used on newer Exynos SoCs, IOMMU has enough TLB cache and handling of non-contiguous buffers is cheap there). I would only separate it from fixing the current code. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup
On 13/11/17 10:20, Johan Hovold wrote: Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed. Note that the nodes returned from the two calls to of_parse_phandle() are also leaking, but fixing that is a bit more involved as pointers to node fields are being stored for later use. Is using a devm_kstrdup() to remember the full_name sufficient so get each of the FIXMEs cleaned up as well? Daniel. Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support") Cc: stable # 3.10 Cc: Guennadi Liakhovetski Signed-off-by: Johan Hovold --- drivers/video/backlight/as3711_bl.c | 35 +-- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/drivers/video/backlight/as3711_bl.c b/drivers/video/backlight/as3711_bl.c index 734a9158946b..21ce56053c88 100644 --- a/drivers/video/backlight/as3711_bl.c +++ b/drivers/video/backlight/as3711_bl.c @@ -262,15 +262,16 @@ static int as3711_bl_register(struct platform_device *pdev, static int as3711_backlight_parse_dt(struct device *dev) { struct as3711_bl_pdata *pdata = dev_get_platdata(dev); - struct device_node *bl = - of_find_node_by_name(dev->parent->of_node, "backlight"), *fb; + struct device_node *bl, *fb; int ret; + bl = of_get_child_by_name(dev->parent->of_node, "backlight"); if (!bl) { dev_dbg(dev, "backlight node not found\n"); return -ENODEV; } + /* FIXME: need to drop reference to returned node */ fb = of_parse_phandle(bl, "su1-dev", 0); if (fb) { pdata->su1_fb = fb->full_name; @@ -279,9 +280,10 @@ static int as3711_backlight_parse_dt(struct device *dev) if (pdata->su1_max_uA <= 0) ret = -EINVAL; if (ret < 0) - return ret; + goto err_put_bl; } + /* FIXME: need to drop reference to returned node */ fb = of_parse_phandle(bl, "su2-dev", 0); if (fb) { int count = 0; @@ -292,7 +294,7 @@ static int as3711_backlight_parse_dt(struct device *dev) if (pdata->su2_max_uA <= 0) ret = -EINVAL; if (ret < 0) - return ret; + goto err_put_bl; if (of_find_property(bl, "su2-feedback-voltage", NULL)) { pdata->su2_feedback = AS3711_SU2_VOLTAGE; @@ -314,8 +316,10 @@ static int as3711_backlight_parse_dt(struct device *dev) pdata->su2_feedback = AS3711_SU2_CURR_AUTO; count++; } - if (count != 1) - return -EINVAL; + if (count != 1) { + ret = -EINVAL; + goto err_put_bl; + } count = 0; if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) { @@ -334,8 +338,10 @@ static int as3711_backlight_parse_dt(struct device *dev) pdata->su2_fbprot = AS3711_SU2_GPIO4; count++; } - if (count != 1) - return -EINVAL; + if (count != 1) { + ret = -EINVAL; + goto err_put_bl; + } count = 0; if (of_find_property(bl, "su2-auto-curr1", NULL)) { @@ -355,11 +361,20 @@ static int as3711_backlight_parse_dt(struct device *dev) * At least one su2-auto-curr* must be specified iff * AS3711_SU2_CURR_AUTO is used */ - if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) - return -EINVAL; + if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) { + ret = -EINVAL; + goto err_put_bl; + } } + of_node_put(bl); + return 0; + +err_put_bl: + of_node_put(bl); + + return ret; } static int as3711_backlight_probe(struct platform_device *pdev) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic-helper: Calculate normalized zpos values
On Mon, Nov 13, 2017 at 02:48:20PM +0100, Thierry Reding wrote: > From: Thierry Reding > > kerneldoc for drm_plane_create_zpos_property() says that the DRM core > will automatically calculate the normalized zpos values, but it won't > currently do so. Modify the atomic helpers to behave as documented. NAK See commit 38d868e41c4b ("drm: Don't force all planes to be added to the state due to zpos") > > Signed-off-by: Thierry Reding > --- > drivers/gpu/drm/drm_atomic_helper.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 71d712f1b56a..6c3ceb3a5dc0 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -791,6 +791,10 @@ int drm_atomic_helper_check(struct drm_device *dev, > if (ret) > return ret; > > + ret = drm_atomic_normalize_zpos(dev, state); > + if (ret) > + return ret; > + > ret = drm_atomic_helper_check_planes(dev, state); > if (ret) > return ret; > -- > 2.14.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] backlight: max8925_bl: fix device-tree node lookup
On 13/11/17 10:20, Johan Hovold wrote: Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed, while the child backlight node was leaked. Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight") Cc: stable # 3.9 Cc: Qing Xu Cc: Haojian Zhuang Signed-off-by: Johan Hovold Acked-by: Daniel Thompson --- drivers/video/backlight/max8925_bl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/video/backlight/max8925_bl.c b/drivers/video/backlight/max8925_bl.c index 7b738d60ecc2..f3aa6088f1d9 100644 --- a/drivers/video/backlight/max8925_bl.c +++ b/drivers/video/backlight/max8925_bl.c @@ -116,7 +116,7 @@ static void max8925_backlight_dt_init(struct platform_device *pdev) if (!pdata) return; - np = of_find_node_by_name(nproot, "backlight"); + np = of_get_child_by_name(nproot, "backlight"); if (!np) { dev_err(&pdev->dev, "failed to find backlight node\n"); return; @@ -125,6 +125,8 @@ static void max8925_backlight_dt_init(struct platform_device *pdev) if (!of_property_read_u32(np, "maxim,max8925-dual-string", &val)) pdata->dual_string = val; + of_node_put(np); + pdev->dev.platform_data = pdata; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] backlight: tps65217_bl: fix device-tree node lookup
On 13/11/17 10:20, Johan Hovold wrote: Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. This would only cause trouble if the child node is missing while there is an unrelated node named "backlight" elsewhere in the tree. Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver") Cc: stable # 3.7 Cc: Matthias Kaehlcke Signed-off-by: Johan Hovold Acked-by: Daniel Thompson --- drivers/video/backlight/tps65217_bl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/backlight/tps65217_bl.c b/drivers/video/backlight/tps65217_bl.c index 380917c86276..762e3feed097 100644 --- a/drivers/video/backlight/tps65217_bl.c +++ b/drivers/video/backlight/tps65217_bl.c @@ -184,11 +184,11 @@ static struct tps65217_bl_pdata * tps65217_bl_parse_dt(struct platform_device *pdev) { struct tps65217 *tps = dev_get_drvdata(pdev->dev.parent); - struct device_node *node = of_node_get(tps->dev->of_node); + struct device_node *node; struct tps65217_bl_pdata *pdata, *err; u32 val; - node = of_find_node_by_name(node, "backlight"); + node = of_get_child_by_name(tps->dev->of_node, "backlight"); if (!node) return ERR_PTR(-ENODEV); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 0/2] R-Car DU: Support importing non-contiguous dma-buf with VSP
Hi Laurent, On 13/11/17 10:32, Laurent Pinchart wrote: > Hello everybody, > > This patch series fixes two issues related to dma-buf import for the Renesas > R-Car DU when the imported buffer is either not physically contiguous or > located in high memory. > > Both cases require the use of an IOMMU to remap the buffers contiguously and > in 32-bit DMA space. On Gen2 platforms this is transparent and works already, > but on Gen3 platforms the situation is more complex. > > The Gen3 DU doesn't perform DMA access directly but instead goes through a VSP > IP core that acts as an external composer. When importing a dma-buf buffer the > GEM PRIME helper drm_gem_prime_import() maps the buffer to the DU device, and > the DU driver later remaps it to the VSP device. The driver unfortunately > can't use the drm_gem_prime_import_dev() helper to map th buffer to the VSP > device directly, as at import time we don't know yet to which VSP device the > buffer will need to be mapped (there is one VSP composer per CRTC). Mapping > the buffer to the VSP can thus only be done when pinning the framebuffer, as > we know at that time which plane and CRTC it will be used with. > > This works currently (with the caveat that an unneeded mapping to the DU is > created), but fails when the imported buffer is not physically contiguous or > is located in high memory. In the first case the GEM CMA helper > drm_gem_cma_prime_import_sg_table() will reject the buffer as it hasn't been > mapped contiguously in the DU DMA address space (because the DU has no IOMMU), > and in the second case the DMA mapping API will try to allocate a bounce > buffer and fail due to bounce buffer memory exhaustion. > > The first patch in this series fixes the second issue by setting the DMA > coherent mask of the DU device to the full 40 bits address space. All memory > will thus be accepted without trying to allocate a bounce buffer. > > The second patch in this series fixes the first issue by using an internal > copy of the drm_gem_cma_prime_import_sg_table() function that doesn't ensure > that the buffer is contiguous in memory. This is what caused me to post this > series as an RFC, as I'm not very happy with duplication of helper code in the > driver that could lead to breakages when the GEM CMA helpers are modified. If > this approach is accepted, I would prefer implementing the code in the GEM CMA > helpers. > > Another point that bothers me is that buffers can now be imported > unconditionally on Gen3 platforms, but atomic commits will fail if the buffer > can't be remapped through the VSP (for instance if no IOMMU is available). > Given the hardware architecture and the DRM/KMS API I don't really see a way > around this. > > Testing this series isn't easy as it requires getting hold of exported > dma-bufs located in high memory or not physically contiguous. I have used the > V4L2 vivid driver as an exporter for that purpose, with a few hacks that can > be found at > > git://linuxtv.org/pinchartl/media.git drm/du/devel/iommu > Ok - testing from this branch with "drm: rcar-du: Allow importing non-contiguous dma-buf with VSP" applied on top (it appeared to be missing) > On the userspace side I have used the v4l2-drm-example test application > available at > > git://git.infradead.org/users/kmpark/public-apps > > and run with > > dmabuf-sharing -M rcar-du -i /dev/video0 -S 640,480 -f YUYV -F YUYV \ > -s 640,480@0,0 -t 640,480@0,0 -o 70:68:640x480 -b 4 -e v4l2 > > (the -o argument needs to be modified based on the connector and CRTC ID). I've build dmabuf-sharing from kmpark/public-apps/v4l2-drm-example, but it doesn't appear to have a "-e v4l2" option (not listed in the -h, and complains with "ERROR(dmabuf-sharing.c:560) : failed to parse arguments") Have you also modified this application to run your tests? If it's easier, I can look at the screen while you run the test under your control as well. > Up to patch "[DEBUG] v4l: videobuf2-dma-contig: Print allocated buffer > address" buffer sharing should work. Patch "[HACK] vivid: Allocate buffers > from high memory" then breaks buffer import, and the issue is fixed by patch > "drm: rcar-du: Set the DMA coherent mask for the DU device". Patch "[HACK] > vivid: Use vmalloc allocator" breaks buffer import again, and is fixed by > "drm: rcar-du: Allow importing non-contiguous dma-buf with VSP". > > Kieran, I have tested this remotely on your Salvator-X H3 ES1.1 and haven't > noticed any problem, but couldn't check the output on the screen. Would you be > able to rerun the test locally for me ? Please note that the IPMMU is known to > have issues on H3 ES1.1, so you might need to test the code on H3 ES2.0 > instead. > > Laurent Pinchart (2): > drm: rcar-du: Set the DMA coherent mask for the DU device > drm: rcar-du: Allow importing non-contiguous dma-buf with VSP > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 13 +++- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 3
[PATCH] drm/atomic-helper: Calculate normalized zpos values
From: Thierry Reding kerneldoc for drm_plane_create_zpos_property() says that the DRM core will automatically calculate the normalized zpos values, but it won't currently do so. Modify the atomic helpers to behave as documented. Signed-off-by: Thierry Reding --- drivers/gpu/drm/drm_atomic_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 71d712f1b56a..6c3ceb3a5dc0 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -791,6 +791,10 @@ int drm_atomic_helper_check(struct drm_device *dev, if (ret) return ret; + ret = drm_atomic_normalize_zpos(dev, state); + if (ret) + return ret; + ret = drm_atomic_helper_check_planes(dev, state); if (ret) return ret; -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)
https://bugs.freedesktop.org/show_bug.cgi?id=102358 Thomas Hellström changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #38 from Thomas Hellström --- Fix has now been pushed to mesa master. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.
Am 13.11.2017 um 12:32 schrieb Michel Dänzer: On 12/11/17 10:35 AM, Christian König wrote: A few comments on the code: +/* Validate bo size is bit bigger then the request domain */ +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device *adev, + unsigned long size, u32 domain) Drop the inline keyword and the second _bo_ in the name here. +{ + struct ttm_mem_type_manager *man = NULL; + + if (domain & AMDGPU_GEM_DOMAIN_VRAM) { + man = &adev->mman.bdev.man[TTM_PL_VRAM]; + + if (man && size < (man->size << PAGE_SHIFT)) Drop the extra check that man is not NULL. We get the pointer to an array element, that can't be NULL. + return true; Mhm, domain is a bitmask of allowed domains. So we should check all valid domains if the size fit, not just the first one. Assuming VRAM <-> system migration of BOs larger than the GTT domain works, I'd say we should only require that the BO can fit in any of the allowed domains. Otherwise it must also always fit in GTT. Good point, and yes VRAM <-> system migration of BOs larger than the GTT domain works now. I can agree on that VRAM should probably be optional, otherwise we can't allocate anything large when the driver uses only very low amounts of stolen VRAM on APUs. But I think when userspace requests VRAM and GTT at the same time we still should be able to fall back to GTT. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.9 80/87] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
4.9-stable review patch. If anyone has any objections, please let me know. -- From: John Stultz commit 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c upstream. Thus this patch changes the EDID probing logic so that we re-use the __adv7511_power_on/off() calls instead of duplciating logic. This does change behavior slightly as it adds the HPD signal pulse to the EDID probe path, but Archit has had a patch to add HPD signal pulse to the EDID probe path before, so this should address the cases where that helped. Another difference is that regcache_mark_dirty() is also called in the power off path once EDID is probed. Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart Signed-off-by: John Stultz Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-6-git-send-email-john.stu...@linaro.org Signed-off-by: Nhan Nguyen Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -573,24 +573,13 @@ static int adv7511_get_modes(struct adv7 unsigned int count; /* Reading the EDID only works if the device is powered */ - if (!adv7511->powered) { - regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, - ADV7511_POWER_POWER_DOWN, 0); - if (adv7511->i2c_main->irq) { - regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0), -ADV7511_INT0_EDID_READY); - regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1), -ADV7511_INT1_DDC_ERROR); - } - adv7511->current_edid_segment = -1; - } + if (!adv7511->powered) + __adv7511_power_on(adv7511); edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511); if (!adv7511->powered) - regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, - ADV7511_POWER_POWER_DOWN, - ADV7511_POWER_POWER_DOWN); + __adv7511_power_off(adv7511); kfree(adv7511->edid); adv7511->edid = edid; ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.9 81/87] drm/bridge: adv7511: Re-write the i2c address before EDID probing
4.9-stable review patch. If anyone has any objections, please let me know. -- From: John Stultz commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream. I've found that by just turning the chip on and off via the POWER_DOWN register, I end up getting i2c_transfer errors on HiKey. Investigating further, it turns out that some of the register state in hardware is getting lost, as the device registers are reset when the chip is powered down. Thus this patch simply re-writes the i2c address to the ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set before we try to read the EDID data. Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Reviewed-by: Laurent Pinchart Tested-by: Laurent Pinchart Signed-off-by: John Stultz Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-email-john.stu...@linaro.org Signed-off-by: Nhan Nguyen Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -573,9 +573,17 @@ static int adv7511_get_modes(struct adv7 unsigned int count; /* Reading the EDID only works if the device is powered */ - if (!adv7511->powered) + if (!adv7511->powered) { + unsigned int edid_i2c_addr = + (adv7511->i2c_main->addr << 1) + 4; + __adv7511_power_on(adv7511); + /* Reset the EDID_I2C_ADDR register as it might be cleared */ + regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, +edid_i2c_addr); + } + edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511); if (!adv7511->powered) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.9 79/87] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally
4.9-stable review patch. If anyone has any objections, please let me know. -- From: John Stultz commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream. In chasing down issues with EDID probing, I found some duplicated but incomplete logic used to power the chip on and off. This patch refactors the adv7511_power_on/off functions, so they can be used for internal needs. Cc: David Airlie Cc: Archit Taneja Cc: Wolfram Sang Cc: Lars-Peter Clausen Cc: Laurent Pinchart Cc: dri-devel@lists.freedesktop.org Signed-off-by: John Stultz Signed-off-by: Archit Taneja Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-email-john.stu...@linaro.org Signed-off-by: Nhan Nguyen Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -325,7 +325,7 @@ static void adv7511_set_link_config(stru adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB; } -static void adv7511_power_on(struct adv7511 *adv7511) +static void __adv7511_power_on(struct adv7511 *adv7511) { adv7511->current_edid_segment = -1; @@ -354,6 +354,11 @@ static void adv7511_power_on(struct adv7 regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2, ADV7511_REG_POWER2_HPD_SRC_MASK, ADV7511_REG_POWER2_HPD_SRC_NONE); +} + +static void adv7511_power_on(struct adv7511 *adv7511) +{ + __adv7511_power_on(adv7511); /* * Most of the registers are reset during power down or when HPD is low. @@ -362,21 +367,23 @@ static void adv7511_power_on(struct adv7 if (adv7511->type == ADV7533) adv7533_dsi_power_on(adv7511); - adv7511->powered = true; } -static void adv7511_power_off(struct adv7511 *adv7511) +static void __adv7511_power_off(struct adv7511 *adv7511) { /* TODO: setup additional power down modes */ regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, ADV7511_POWER_POWER_DOWN, ADV7511_POWER_POWER_DOWN); regcache_mark_dirty(adv7511->regmap); +} +static void adv7511_power_off(struct adv7511 *adv7511) +{ + __adv7511_power_off(adv7511); if (adv7511->type == ADV7533) adv7533_dsi_power_off(adv7511); - adv7511->powered = false; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tilcdc: Remove obsolete "ti, tilcdc, slave" dts binding support
This patch removes DRM_TILCDC_SLAVE_COMPAT option for supporting the obsolete "ti,tilcdc,slave" device tree binding. The new of_graph based binding - that is widely used in other drm driver too - has been supported since Linux v4.2. Maintaining the the backwards dts conversion code in 0the DRM_TILCDC_SLAVE_COMPAT has become a nuisance for the device/of development so the we decided to drop it after Linux v4.14, the 2017 LTS. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/tilcdc/Kconfig | 11 - drivers/gpu/drm/tilcdc/Makefile| 3 - drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c | 269 - drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts | 72 --- drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h | 25 --- 5 files changed, 380 deletions(-) delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.dts delete mode 100644 drivers/gpu/drm/tilcdc/tilcdc_slave_compat.h diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig index 28fed7e..81ac824 100644 --- a/drivers/gpu/drm/tilcdc/Kconfig +++ b/drivers/gpu/drm/tilcdc/Kconfig @@ -12,14 +12,3 @@ config DRM_TILCDC controller, for example AM33xx in beagle-bone, DA8xx, or OMAP-L1xx. This driver replaces the FB_DA8XX fbdev driver. -config DRM_TILCDC_SLAVE_COMPAT - bool "Support device tree blobs using TI LCDC Slave binding" - depends on DRM_TILCDC - default y - select OF_RESOLVE - select OF_OVERLAY - help - Choose this option if you need a kernel that is compatible - with device tree blobs using the obsolete "ti,tilcdc,slave" - binding. If you find "ti,tilcdc,slave"-string from your DTB, - you probably need this. Otherwise you do not. diff --git a/drivers/gpu/drm/tilcdc/Makefile b/drivers/gpu/drm/tilcdc/Makefile index 55ebd51..efc2c4f 100644 --- a/drivers/gpu/drm/tilcdc/Makefile +++ b/drivers/gpu/drm/tilcdc/Makefile @@ -2,9 +2,6 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS))) ccflags-y += -Werror endif -obj-$(CONFIG_DRM_TILCDC_SLAVE_COMPAT) += tilcdc_slave_compat.o \ -tilcdc_slave_compat.dtb.o - tilcdc-y := \ tilcdc_plane.o \ tilcdc_crtc.o \ diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c b/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c deleted file mode 100644 index 482299a..000 --- a/drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c +++ /dev/null @@ -1,269 +0,0 @@ -/* - * Copyright (C) 2015 Texas Instruments - * Author: Jyri Sarha - * - * This program is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 as published by - * the Free Software Foundation. - * - */ - -/* - * To support the old "ti,tilcdc,slave" binding the binding has to be - * transformed to the new external encoder binding. - */ - -#include -#include -#include -#include -#include -#include - -#include "tilcdc_slave_compat.h" - -struct kfree_table { - int total; - int num; - void **table; -}; - -static int __init kfree_table_init(struct kfree_table *kft) -{ - kft->total = 32; - kft->num = 0; - kft->table = kmalloc(kft->total * sizeof(*kft->table), -GFP_KERNEL); - if (!kft->table) - return -ENOMEM; - - return 0; -} - -static int __init kfree_table_add(struct kfree_table *kft, void *p) -{ - if (kft->num == kft->total) { - void **old = kft->table; - - kft->total *= 2; - kft->table = krealloc(old, kft->total * sizeof(*kft->table), - GFP_KERNEL); - if (!kft->table) { - kft->table = old; - kfree(p); - return -ENOMEM; - } - } - kft->table[kft->num++] = p; - return 0; -} - -static void __init kfree_table_free(struct kfree_table *kft) -{ - int i; - - for (i = 0; i < kft->num; i++) - kfree(kft->table[i]); - - kfree(kft->table); -} - -static -struct property * __init tilcdc_prop_dup(const struct property *prop, -struct kfree_table *kft) -{ - struct property *nprop; - - nprop = kzalloc(sizeof(*nprop), GFP_KERNEL); - if (!nprop || kfree_table_add(kft, nprop)) - return NULL; - - nprop->name = kstrdup(prop->name, GFP_KERNEL); - if (!nprop->name || kfree_table_add(kft, nprop->name)) - return NULL; - - nprop->value = kmemdup(prop->value, prop->length, GFP_KERNEL); - if (!nprop->value || kfree_table_add(kft, nprop->value)) - return NULL; - - nprop->length = prop->length; - - return nprop; -} - -static void __init tilcdc_copy_props(struct device_node *from, -
Re: [PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP
On Mon, Nov 13, 2017 at 12:32:28PM +0200, Laurent Pinchart wrote: > When the DU sources its frames from a VSP, it performs no memory access > and thus has no requirements on imported dma-buf memory types. In > particular the DU could import a physically non-contiguous buffer that > would later be mapped contiguously through the VSP IOMMU. > > This use case isn't supported at the moment as the GEM CMA helpers will > reject any non-contiguous buffer, and the DU isn't connected to an IOMMU > that can make the buffer contiguous for DMA. Fix this by implementing a > custom .gem_prime_import_sg_table() operation that accepts all imported > dma-buf regardless of the number of scatterlist entries. This patch raises the question of why use CMA at all if you can accept any kind of buffers. > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 > +++ > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 7 +++ > 3 files changed, 47 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > index 48c166f925a3..d999231f98c7 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = { > .gem_prime_import = drm_gem_prime_import, > .gem_prime_export = drm_gem_prime_export, > .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, > - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, > + .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table, > .gem_prime_vmap = drm_gem_cma_prime_vmap, > .gem_prime_vunmap = drm_gem_cma_prime_vunmap, > .gem_prime_mmap = drm_gem_cma_prime_mmap, > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > index 566d1a948c8f..2dd0c2ba047d 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -20,6 +20,7 @@ > #include > #include > > +#include > #include > #include > > @@ -148,6 +149,44 @@ const struct rcar_du_format_info > *rcar_du_format_info(u32 fourcc) > * Frame buffer > */ > > +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device > *dev, > + struct dma_buf_attachment *attach, > + struct sg_table *sgt) > +{ > + struct rcar_du_device *rcdu = dev->dev_private; > + struct drm_gem_cma_object *cma_obj; > + struct drm_gem_object *gem_obj; > + int ret; > + > + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) > + return drm_gem_cma_prime_import_sg_table(dev, attach, sgt); > + > + /* Create a CMA GEM buffer. */ > + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL); > + if (!cma_obj) > + return ERR_PTR(-ENOMEM); > + gem_obj = &cma_obj->base; > + > + ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size); > + if (ret) > + goto error; > + > + ret = drm_gem_create_mmap_offset(gem_obj); > + if (ret) { > + drm_gem_object_release(gem_obj); > + goto error; > + } > + > + cma_obj->paddr = 0; This is going to break drm_gem_cma_describe() if you are using it plus the rcar_du_plane_setup_scanout() unless I'm missing something besides familiarity with the RCAR driver code :) This function looks very similar to what I tried to do for mali-dp to allow the import of contiguous DMA buffers that have more than 1 sgt entries. In the end I gave up as I kept finding issues and went for the drm_gem_cma_prime_import_sg_table() changes. Maybe you need to do a similar change in the function to bypass some requirements if the driver signals that it can accept relaxed requirements? Best regards, Liviu > + cma_obj->sgt = sgt; > + > + return gem_obj; > + > +error: > + kfree(cma_obj); > + return ERR_PTR(ret); > +} > + > int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev, > struct drm_mode_create_dumb *args) > { > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h > b/drivers/gpu/drm/rcar-du/rcar_du_kms.h > index 07951d5fe38b..10b2bb0f0df9 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h > @@ -16,10 +16,13 @@ > > #include > > +struct dma_buf_attachment; > struct drm_file; > struct drm_device; > +struct drm_gem_object; > struct drm_mode_create_dumb; > struct rcar_du_device; > +struct sg_table; > > struct rcar_du_format_info { > u32 fourcc; > @@ -36,4 +39,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu); > int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev, > struct drm_mode_create_dumb *args); > > +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(st
[Bug 103443] [CI] igt@kms_setmode@[clone-exclusive-crtc | invalid-clone-exclusive-crtc] - warn - no modes for connector 76
https://bugs.freedesktop.org/show_bug.cgi?id=103443 --- Comment #3 from Marta Löfstedt --- here also: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3331/shard-glkb2/i...@testdisplay.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103443] [CI] igt@kms_setmode@[clone-exclusive-crtc | invalid-clone-exclusive-crtc] - warn - no modes for connector 76
https://bugs.freedesktop.org/show_bug.cgi?id=103443 --- Comment #2 from Marta Löfstedt --- Here is another test that produce WARN only where there a no modes available https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_3335/shard-glkb2/igt@kms_sysfs_edid_timing.html -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 1/2] drm: rcar-du: Set the DMA coherent mask for the DU device
On Mon, Nov 13, 2017 at 12:32:27PM +0200, Laurent Pinchart wrote: > The DU DMA address space is limited to 32 bits, so the DMA coherent mask > should be set accordingly. The DMA mapping implementation will > transparently map high memory buffers to 32-bit addresses through an > IOMMU when present (or through bounce buffers otherwise, which isn't a > supported use case as performances would be terrible). > > However, when sourcing frames from a VSP, the situation is more > complicated. The DU delegates all memory accesses to the VSP and doesn't > perform any DMA access by itself. Due to how the GEM CMA helpers are > structured buffers are still mapped to the DU device. They are later > mapped to the VSP as well to perform DMA access, through the IOMMU > connected to the VSP. > > Setting the DMA coherent mask to 32 bits for the DU when using a VSP can > cause issues when importing a dma_buf. If the buffer is located above > the 32-bit address space, the DMA mapping implementation will try to map > it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer > will be allocated, which in the best case will waste memory and in the > worst case will just fail. > > To work around this issue, set the DMA coherent mask to the full 40-bit > address space for the DU. All dma-buf instances will be imported without > any restriction, and will be mapped to the VSP when preparing the > associated framebuffer. This does indeed look like a work around, but I can't see anything wrong with it. Reviewed-by: Liviu Dudau > > Signed-off-by: Laurent Pinchart > --- > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > index 6e02c762a557..48c166f925a3 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c > @@ -370,6 +370,7 @@ static int rcar_du_probe(struct platform_device *pdev) > struct rcar_du_device *rcdu; > struct drm_device *ddev; > struct resource *mem; > + unsigned int mask; > int ret; > > /* Allocate and initialize the R-Car device structure. */ > @@ -388,6 +389,16 @@ static int rcar_du_probe(struct platform_device *pdev) > if (IS_ERR(rcdu->mmio)) > return PTR_ERR(rcdu->mmio); > > + /* > + * Set the DMA coherent mask to reflect the DU 32-bit DMA address space > + * limitations. When sourcing frames from a VSP the DU doesn't perform > + * any memory access so set the mask to 40 bits to accept all buffers. > + */ > + mask = rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE) ? 40 : 32; > + ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(mask)); > + if (ret) > + return ret; > + > /* DRM/KMS objects */ > ddev = drm_dev_alloc(&rcar_du_driver, &pdev->dev); > if (IS_ERR(ddev)) > -- > Regards, > > Laurent Pinchart > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.
On 12/11/17 10:35 AM, Christian König wrote: > A few comments on the code: > >> +/* Validate bo size is bit bigger then the request domain */ >> +static inline bool amdgpu_bo_validate_bo_size(struct amdgpu_device >> *adev, >> + unsigned long size, u32 domain) > Drop the inline keyword and the second _bo_ in the name here. > >> +{ >> + struct ttm_mem_type_manager *man = NULL; >> + >> + if (domain & AMDGPU_GEM_DOMAIN_VRAM) { >> + man = &adev->mman.bdev.man[TTM_PL_VRAM]; >> + >> + if (man && size < (man->size << PAGE_SHIFT)) > > Drop the extra check that man is not NULL. We get the pointer to an > array element, that can't be NULL. > >> + return true; > Mhm, domain is a bitmask of allowed domains. > > So we should check all valid domains if the size fit, not just the first > one. Assuming VRAM <-> system migration of BOs larger than the GTT domain works, I'd say we should only require that the BO can fit in any of the allowed domains. Otherwise it must also always fit in GTT. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: add clut mode support
Hi Peter, On 11/12/2017 01:31 PM, Peter Rosin wrote: > On 2017-11-10 17:12, Philippe CORNU wrote: >> Hi Peter, >> >> On 11/07/2017 05:34 PM, Peter Rosin wrote: >>> On 2017-11-07 16:53, Philippe CORNU wrote: + Peter Hi Peter, CLUT support on STM32 has been removed thanks to your clean up patch >>> >>> Support is a bit strong for what I thought was a dead function, or >>> are you saying that it used to work before my series? Really sorry >>> if that is the case! >> >> As I wrote in the previous related thread >> (https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html), >> STM32 chipsets supports 8-bit CLUT mode but this driver version does not >> support it "yet"... >> >> So, no worry regarding your clean up, I gave you an "acked-by" for that : ) > > Ok, good. Thanks for clearing that up! > >>> >>> Anyway, the function I removed seemed to indicate that the hardware >>> could handle a separate clut for each layer, but your new version >>> does not. Why is that? >> >> Yes I confirm the clut support is available for each layer... but I >> thought the gamma_lut was only at the crtc level, not at layer level... >> Maybe I am wrong. >> Moreover, small test applications I used play only with clut at crtc >> level... >> >> Anyway, could you please help me to "find" a per-layer clut >> implementation because when I read "crtc->state->gamma_lut->data" it >> looks like gamma_lut is per crtc, not per plane...? or maybe I have to >> add extra properties for that... > > I wasn't clear enough. Yes, there is to my knowledge only one clut, > not one per plane. What I noticed was that the function I removed > seemed to touch clut registers for multiple layers, but your new > function appears to only touch registers for one layer. So, I > wondered if the "one and only" clut needed to be copied to the > registers for the other layers, or if the old dead code was simply > confused. Clearer? > The old code was a generic helper function (ie. for all layers) but used only for the 1st layer. So, we could say that "old dead code was simply confused" :-) When I put back the clut support in this patch, I decided to update only the 1st layer (because there is no API for handling it on other layers). I also decided to not re-use the former generic helper function as the update loop is pretty small. This patch offers the clut mode feature for fbdev (only one plane in fbdev) and for drm (single plane for many use cases, 2nd plane being used mostly for video...) If tomorrow the API offers clut support per plane, the update loop will be moved to the plane update function, means the generic helper function will not be require anymore too. Many thanks Philippe :) > Cheers. > Peter > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 1/2] drm: rcar-du: Set the DMA coherent mask for the DU device
The DU DMA address space is limited to 32 bits, so the DMA coherent mask should be set accordingly. The DMA mapping implementation will transparently map high memory buffers to 32-bit addresses through an IOMMU when present (or through bounce buffers otherwise, which isn't a supported use case as performances would be terrible). However, when sourcing frames from a VSP, the situation is more complicated. The DU delegates all memory accesses to the VSP and doesn't perform any DMA access by itself. Due to how the GEM CMA helpers are structured buffers are still mapped to the DU device. They are later mapped to the VSP as well to perform DMA access, through the IOMMU connected to the VSP. Setting the DMA coherent mask to 32 bits for the DU when using a VSP can cause issues when importing a dma_buf. If the buffer is located above the 32-bit address space, the DMA mapping implementation will try to map it to the DU's DMA address space. As the DU has no IOMMU a bounce buffer will be allocated, which in the best case will waste memory and in the worst case will just fail. To work around this issue, set the DMA coherent mask to the full 40-bit address space for the DU. All dma-buf instances will be imported without any restriction, and will be mapped to the VSP when preparing the associated framebuffer. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 6e02c762a557..48c166f925a3 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -370,6 +370,7 @@ static int rcar_du_probe(struct platform_device *pdev) struct rcar_du_device *rcdu; struct drm_device *ddev; struct resource *mem; + unsigned int mask; int ret; /* Allocate and initialize the R-Car device structure. */ @@ -388,6 +389,16 @@ static int rcar_du_probe(struct platform_device *pdev) if (IS_ERR(rcdu->mmio)) return PTR_ERR(rcdu->mmio); + /* +* Set the DMA coherent mask to reflect the DU 32-bit DMA address space +* limitations. When sourcing frames from a VSP the DU doesn't perform +* any memory access so set the mask to 40 bits to accept all buffers. +*/ + mask = rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE) ? 40 : 32; + ret = dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(mask)); + if (ret) + return ret; + /* DRM/KMS objects */ ddev = drm_dev_alloc(&rcar_du_driver, &pdev->dev); if (IS_ERR(ddev)) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 0/2] R-Car DU: Support importing non-contiguous dma-buf with VSP
Hello everybody, This patch series fixes two issues related to dma-buf import for the Renesas R-Car DU when the imported buffer is either not physically contiguous or located in high memory. Both cases require the use of an IOMMU to remap the buffers contiguously and in 32-bit DMA space. On Gen2 platforms this is transparent and works already, but on Gen3 platforms the situation is more complex. The Gen3 DU doesn't perform DMA access directly but instead goes through a VSP IP core that acts as an external composer. When importing a dma-buf buffer the GEM PRIME helper drm_gem_prime_import() maps the buffer to the DU device, and the DU driver later remaps it to the VSP device. The driver unfortunately can't use the drm_gem_prime_import_dev() helper to map th buffer to the VSP device directly, as at import time we don't know yet to which VSP device the buffer will need to be mapped (there is one VSP composer per CRTC). Mapping the buffer to the VSP can thus only be done when pinning the framebuffer, as we know at that time which plane and CRTC it will be used with. This works currently (with the caveat that an unneeded mapping to the DU is created), but fails when the imported buffer is not physically contiguous or is located in high memory. In the first case the GEM CMA helper drm_gem_cma_prime_import_sg_table() will reject the buffer as it hasn't been mapped contiguously in the DU DMA address space (because the DU has no IOMMU), and in the second case the DMA mapping API will try to allocate a bounce buffer and fail due to bounce buffer memory exhaustion. The first patch in this series fixes the second issue by setting the DMA coherent mask of the DU device to the full 40 bits address space. All memory will thus be accepted without trying to allocate a bounce buffer. The second patch in this series fixes the first issue by using an internal copy of the drm_gem_cma_prime_import_sg_table() function that doesn't ensure that the buffer is contiguous in memory. This is what caused me to post this series as an RFC, as I'm not very happy with duplication of helper code in the driver that could lead to breakages when the GEM CMA helpers are modified. If this approach is accepted, I would prefer implementing the code in the GEM CMA helpers. Another point that bothers me is that buffers can now be imported unconditionally on Gen3 platforms, but atomic commits will fail if the buffer can't be remapped through the VSP (for instance if no IOMMU is available). Given the hardware architecture and the DRM/KMS API I don't really see a way around this. Testing this series isn't easy as it requires getting hold of exported dma-bufs located in high memory or not physically contiguous. I have used the V4L2 vivid driver as an exporter for that purpose, with a few hacks that can be found at git://linuxtv.org/pinchartl/media.git drm/du/devel/iommu On the userspace side I have used the v4l2-drm-example test application available at git://git.infradead.org/users/kmpark/public-apps and run with dmabuf-sharing -M rcar-du -i /dev/video0 -S 640,480 -f YUYV -F YUYV \ -s 640,480@0,0 -t 640,480@0,0 -o 70:68:640x480 -b 4 -e v4l2 (the -o argument needs to be modified based on the connector and CRTC ID). Up to patch "[DEBUG] v4l: videobuf2-dma-contig: Print allocated buffer address" buffer sharing should work. Patch "[HACK] vivid: Allocate buffers from high memory" then breaks buffer import, and the issue is fixed by patch "drm: rcar-du: Set the DMA coherent mask for the DU device". Patch "[HACK] vivid: Use vmalloc allocator" breaks buffer import again, and is fixed by "drm: rcar-du: Allow importing non-contiguous dma-buf with VSP". Kieran, I have tested this remotely on your Salvator-X H3 ES1.1 and haven't noticed any problem, but couldn't check the output on the screen. Would you be able to rerun the test locally for me ? Please note that the IPMMU is known to have issues on H3 ES1.1, so you might need to test the code on H3 ES2.0 instead. Laurent Pinchart (2): drm: rcar-du: Set the DMA coherent mask for the DU device drm: rcar-du: Allow importing non-contiguous dma-buf with VSP drivers/gpu/drm/rcar-du/rcar_du_drv.c | 13 +++- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 +++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 7 +++ 3 files changed, 58 insertions(+), 1 deletion(-) -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH/RFC 2/2] drm: rcar-du: Allow importing non-contiguous dma-buf with VSP
When the DU sources its frames from a VSP, it performs no memory access and thus has no requirements on imported dma-buf memory types. In particular the DU could import a physically non-contiguous buffer that would later be mapped contiguously through the VSP IOMMU. This use case isn't supported at the moment as the GEM CMA helpers will reject any non-contiguous buffer, and the DU isn't connected to an IOMMU that can make the buffer contiguous for DMA. Fix this by implementing a custom .gem_prime_import_sg_table() operation that accepts all imported dma-buf regardless of the number of scatterlist entries. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 39 +++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 7 +++ 3 files changed, 47 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c b/drivers/gpu/drm/rcar-du/rcar_du_drv.c index 48c166f925a3..d999231f98c7 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c @@ -289,7 +289,7 @@ static struct drm_driver rcar_du_driver = { .gem_prime_import = drm_gem_prime_import, .gem_prime_export = drm_gem_prime_export, .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table, - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table, + .gem_prime_import_sg_table = rcar_du_gem_prime_import_sg_table, .gem_prime_vmap = drm_gem_cma_prime_vmap, .gem_prime_vunmap = drm_gem_cma_prime_vunmap, .gem_prime_mmap = drm_gem_cma_prime_mmap, diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 566d1a948c8f..2dd0c2ba047d 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -20,6 +20,7 @@ #include #include +#include #include #include @@ -148,6 +149,44 @@ const struct rcar_du_format_info *rcar_du_format_info(u32 fourcc) * Frame buffer */ +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device *dev, + struct dma_buf_attachment *attach, + struct sg_table *sgt) +{ + struct rcar_du_device *rcdu = dev->dev_private; + struct drm_gem_cma_object *cma_obj; + struct drm_gem_object *gem_obj; + int ret; + + if (!rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) + return drm_gem_cma_prime_import_sg_table(dev, attach, sgt); + + /* Create a CMA GEM buffer. */ + cma_obj = kzalloc(sizeof(*cma_obj), GFP_KERNEL); + if (!cma_obj) + return ERR_PTR(-ENOMEM); + gem_obj = &cma_obj->base; + + ret = drm_gem_object_init(dev, gem_obj, attach->dmabuf->size); + if (ret) + goto error; + + ret = drm_gem_create_mmap_offset(gem_obj); + if (ret) { + drm_gem_object_release(gem_obj); + goto error; + } + + cma_obj->paddr = 0; + cma_obj->sgt = sgt; + + return gem_obj; + +error: + kfree(cma_obj); + return ERR_PTR(ret); +} + int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev, struct drm_mode_create_dumb *args) { diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.h b/drivers/gpu/drm/rcar-du/rcar_du_kms.h index 07951d5fe38b..10b2bb0f0df9 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.h +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.h @@ -16,10 +16,13 @@ #include +struct dma_buf_attachment; struct drm_file; struct drm_device; +struct drm_gem_object; struct drm_mode_create_dumb; struct rcar_du_device; +struct sg_table; struct rcar_du_format_info { u32 fourcc; @@ -36,4 +39,8 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu); int rcar_du_dumb_create(struct drm_file *file, struct drm_device *dev, struct drm_mode_create_dumb *args); +struct drm_gem_object *rcar_du_gem_prime_import_sg_table(struct drm_device *dev, + struct dma_buf_attachment *attach, + struct sg_table *sgt); + #endif /* __RCAR_DU_KMS_H__ */ -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties
Hi Uma, On 10 November 2017 at 08:37, Shankar, Uma wrote: >>This is missing documentation on how plane colour management interacts with >>CRTC colour management. Is it a step before CRTC colour management is >>applied, or does it bypass CRTC colour management, or ... ? >> > > We can have color correction at 2 places in the Display hardware pipeline > 1. At plane level (before blending) > 2. At pipe level (after blending) > > Both can be used and function independently of each other. Typical use case > can be: > > 2 Layers planes/overlays with different color space and formats. These can be > converted to one > common color space using the plane level color correction, then blended > together. If needed > pipe color correction can be applied on the blended output (based on use case > and scenarios) This is roughly what I'd expected, but I don't believe the same to be true of all hardware, and it would certainly need to be documented. Thanks for the explanation! Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers
For personal reasons, Mark Yao will leave rockchip, can not continue maintain drm/rockchip, Sandy Huang will take over the drm/rockchip. Cc: Sandy Huang Cc: Heiko Stuebner Signed-off-by: Mark Yao --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 0d77f22..31bf080 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4627,7 +4627,7 @@ F: Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt F: Documentation/devicetree/bindings/display/renesas,du.txt DRM DRIVERS FOR ROCKCHIP -M: Mark Yao +M: Sandy Huang L: dri-devel@lists.freedesktop.org S: Maintained F: drivers/gpu/drm/rockchip/ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel