dri-devel July 2020

dri-devel@lists.freedesktop.org

336 participants
772 discussions

[PATCH v3 0/9] support cmdq helper function on mt6779 platform
by Dennis YC Hsieh 21 Sep '20

21 Sep '20

This patch support more gce helper function on mt6779 platform. depends on patch: support gce on mt6779 platform and depends on following applied patches soc: mediatek: cmdq: add set event function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add assign function Change since v2: - Keep behavior in drm crtc driver and separate bug fix code into another patch. Change since v1: - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). Dennis YC Hsieh (9): soc: mediatek: cmdq: add address shift in jump soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api drm/mediatek: reduce clear event drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +- drivers/soc/mediatek/mtk-cmdq-helper.c | 113 ++++++++++++++++++++++- include/linux/mailbox/mtk-cmdq-mailbox.h | 6 +- include/linux/soc/mediatek/mtk-cmdq.h | 93 ++++++++++++++++++- 4 files changed, 206 insertions(+), 8 deletions(-) -- 2.18.0

6 24

[RESEND] [PATCH v6 0/8] do not store GPU address in TTM
by Nirmoy Das 21 Sep '20

21 Sep '20

With this patch series I am trying to remove GPU address dependency in TTM and moving GPU address calculation to individual drm drivers. This cleanup will simplify introduction of drm_mem_region/domain work started by Brian Welty[1]. It would be nice if someone test this for nouveau. Rest of the drivers are already tested. v2: * set bo->offset = 0 for drm/nouveau if bo->mem.mm_node == NULL v3: * catch return value of drm_gem_vram_offset() in drm/bochs * introduce drm_gem_vram_pg_offset() in vram helper * improve nbo->offset calculation for nouveau v4: * minor coding style fixes in amdgpu and radeon * remove unnecessary kerneldoc for internal function v5: * rebase on top of drm-misc-next * fix return value of drm_gem_vram_pg_offset() * add a comment in drm_gem_vram_pg_offset() to clearify why we return 0. v6: * rebase to drm-misc-next * removed acked for vmwgfx as there was a small conflict Nirmoy Das (8): drm/amdgpu: move ttm bo->offset to amdgpu_bo drm/radeon: don't use ttm bo->offset drm/vmwgfx: don't use ttm bo->offset drm/nouveau: don't use ttm bo->offset v3 drm/qxl: don't use ttm bo->offset drm/vram-helper: don't use ttm bo->offset v4 drm/bochs: use drm_gem_vram_offset to get bo offset v2 drm/ttm: do not keep GPU dependent addresses drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 23 ++++++++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 30 ++++++++++++++++----- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 4 +-- drivers/gpu/drm/bochs/bochs_kms.c | 7 ++++- drivers/gpu/drm/drm_gem_vram_helper.c | 11 +++++++- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 ++- drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 ++--- drivers/gpu/drm/nouveau/dispnv50/base507c.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/core507d.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/ovly507e.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/wndwc37e.c | 2 +- drivers/gpu/drm/nouveau/nouveau_abi16.c | 8 +++--- drivers/gpu/drm/nouveau/nouveau_bo.c | 8 ++++++ drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +++ drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +- drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 10 +++---- drivers/gpu/drm/qxl/qxl_drv.h | 6 ++--- drivers/gpu/drm/qxl/qxl_kms.c | 5 ++-- drivers/gpu/drm/qxl/qxl_object.h | 5 ---- drivers/gpu/drm/qxl/qxl_ttm.c | 9 ------- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_object.h | 16 ++++++++++- drivers/gpu/drm/radeon/radeon_ttm.c | 4 +-- drivers/gpu/drm/ttm/ttm_bo.c | 7 ----- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 -- include/drm/ttm/ttm_bo_api.h | 2 -- include/drm/ttm/ttm_bo_driver.h | 1 - 36 files changed, 125 insertions(+), 78 deletions(-) -- 2.27.0

5 24

[PATCH] dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv
by Daniel Vetter 17 Sep '20

17 Sep '20

GPU drivers need this in their shrinkers, to be able to throw out mmap'ed buffers. Note that we also need dma_resv_lock in shrinkers, but that loop is resolved by trylocking in shrinkers. So full hierarchy is now (ignore some of the other branches we already have primed): mmap_read_lock -> dma_resv -> shrinkers -> i_mmap_lock_write I hope that's not inconsistent with anything mm or fs does, adding relevant people. Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: Dave Chinner <david(a)fromorbit.com> Cc: Qian Cai <cai(a)lca.pw> Cc: linux-xfs(a)vger.kernel.org Cc: linux-fsdevel(a)vger.kernel.org Cc: Thomas Hellström (Intel) <thomas_os(a)shipmail.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: linux-mm(a)kvack.org Cc: linux-rdma(a)vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/dma-buf/dma-resv.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c index 0e6675ec1d11..9678162a4ac5 100644 --- a/drivers/dma-buf/dma-resv.c +++ b/drivers/dma-buf/dma-resv.c @@ -104,12 +104,14 @@ static int __init dma_resv_lockdep(void) struct mm_struct *mm = mm_alloc(); struct ww_acquire_ctx ctx; struct dma_resv obj; + struct address_space mapping; int ret; if (!mm) return -ENOMEM; dma_resv_init(&obj); + address_space_init_once(&mapping); mmap_read_lock(mm); ww_acquire_init(&ctx, &reservation_ww_class); @@ -117,6 +119,9 @@ static int __init dma_resv_lockdep(void) if (ret == -EDEADLK) dma_resv_lock_slow(&obj, &ctx); fs_reclaim_acquire(GFP_KERNEL); + /* for unmap_mapping_range on trylocked buffer objects in shrinkers */ + i_mmap_lock_write(&mapping); + i_mmap_unlock_write(&mapping); #ifdef CONFIG_MMU_NOTIFIER lock_map_acquire(&__mmu_notifier_invalidate_range_start_map); __dma_fence_might_wait(); -- 2.27.0

4 5

[PATCH -next] gpu: host1x: Convert to DEFINE_SHOW_ATTRIBUTE
by Qinglang Miao 17 Sep '20

17 Sep '20

From: Yongqiang Liu <liuyongqiang13(a)huawei.com> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Yongqiang Liu <liuyongqiang13(a)huawei.com> --- drivers/gpu/host1x/debug.c | 28 ++++------------------------ 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c index 545fc0afb..1688e98c4 100644 --- a/drivers/gpu/host1x/debug.c +++ b/drivers/gpu/host1x/debug.c @@ -110,7 +110,7 @@ static void show_all(struct host1x *m, struct output *o, bool show_fifo) } } -static int host1x_debug_show_all(struct seq_file *s, void *unused) +static int host1x_debug_all_show(struct seq_file *s, void *unused) { struct output o = { .fn = write_to_seqfile, @@ -122,6 +122,8 @@ static int host1x_debug_show_all(struct seq_file *s, void *unused) return 0; } +DEFINE_SHOW_ATTRIBUTE(host1x_debug_all); + static int host1x_debug_show(struct seq_file *s, void *unused) { struct output o = { @@ -134,29 +136,7 @@ static int host1x_debug_show(struct seq_file *s, void *unused) return 0; } -static int host1x_debug_open_all(struct inode *inode, struct file *file) -{ - return single_open(file, host1x_debug_show_all, inode->i_private); -} - -static const struct file_operations host1x_debug_all_fops = { - .open = host1x_debug_open_all, - .read_iter = seq_read_iter, - .llseek = seq_lseek, - .release = single_release, -}; - -static int host1x_debug_open(struct inode *inode, struct file *file) -{ - return single_open(file, host1x_debug_show, inode->i_private); -} - -static const struct file_operations host1x_debug_fops = { - .open = host1x_debug_open, - .read_iter = seq_read_iter, - .llseek = seq_lseek, - .release = single_release, -}; +DEFINE_SHOW_ATTRIBUTE(host1x_debug); static void host1x_debugfs_init(struct host1x *host1x) { -- 2.17.1

3 4

[PATCH -next] drm/komeda: Convert to DEFINE_SHOW_ATTRIBUTE
by Qinglang Miao 17 Sep '20

17 Sep '20

From: Liu Shixin <liushixin2(a)huawei.com> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. Signed-off-by: Liu Shixin <liushixin2(a)huawei.com> --- drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c index 0246b2e94..4a10e6b9e 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c @@ -41,18 +41,7 @@ static int komeda_register_show(struct seq_file *sf, void *x) return 0; } -static int komeda_register_open(struct inode *inode, struct file *filp) -{ - return single_open(filp, komeda_register_show, inode->i_private); -} - -static const struct file_operations komeda_register_fops = { - .owner = THIS_MODULE, - .open = komeda_register_open, - .read_iter = seq_read_iter, - .llseek = seq_lseek, - .release = single_release, -}; +DEFINE_SHOW_ATTRIBUTE(komeda_register); #ifdef CONFIG_DEBUG_FS static void komeda_debugfs_init(struct komeda_dev *mdev) -- 2.17.1

4 6

Re: Regression in 5.4 kernel on 32-bit Radeon IBM T40
by Christian König 16 Sep '20

16 Sep '20

Hi Christoph, Am 09.01.20 um 15:14 schrieb Christoph Hellwig: > Hi Woody, > > sorry for the late reply, I've been off to a vacation over the holidays. > > On Sat, Dec 14, 2019 at 10:17:15PM -0500, Woody Suwalski wrote: >> Regression in 5.4 kernel on 32-bit Radeon IBM T40 >> triggered by >> commit 33b3ad3788aba846fc8b9a065fe2685a0b64f713 >> Author: Christoph Hellwig <hch(a)lst.de> >> Date: Thu Aug 15 09:27:00 2019 +0200 >> >> Howdy, >> The above patch has triggered a display problem on IBM Thinkpad T40, where >> the screen is covered with a lots of random short black horizontal lines, >> or distorted letters in X terms. >> >> The culprit seems to be that the dma_get_required_mask() is returning a >> value 0x3fffffff >> which is smaller than dma_get_mask()0xffffffff.That results in >> dma_addressing_limited()==0 in ttm_bo_device(), and using 40-bits dma >> instead of 32-bits. > Which is the intended behavior assuming your system has 1GB of memory. > Does it? Assuming the system doesn't have the 1GB split up somehow crazy over the address space that should indeed work as intended. > >> If I hardcode "1" as the last parameter to ttm_bo_device_init() in place of >> a call to dma_addressing_limited(),the problem goes away. > I'll need some help from the drm / radeon / TTM maintainers if there are > any other side effects from not passing the need_dma32 paramters. > Obviously if the device doesn't have more than 32-bits worth of dram and > no DMA offset we can't feed unaddressable memory to the device. > Unfortunately I have a very hard time following the implementation of > the TTM pool if it does anything else in this case. The only other thing which comes to mind is using huge pages. Can you try a kernel with CONFIG_TRANSPARENT_HUGEPAGE disabled? Thanks, Christian.

5 5

[PATCH 1/3] drm: Restore driver.preclose() for all to use
by Chris Wilson 16 Sep '20

16 Sep '20

An unfortunate sequence of events, but it turns out there is a valid usecase for being able to free/decouple the driver objects before they are freed by the DRM core. In particular, if we have a pointer into a drm core object from inside a driver object, that pointer needs to be nerfed *before* it is freed so that concurrent access (e.g. debugfs) does not following the dangling pointer. The legacy marker was adding in the code movement from drp_fops.c to drm_file.c References: 9acdac68bcdc ("drm: rename drm_fops.c to drm_file.c") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Gustavo Padovan <gustavo.padovan(a)collabora.com> Cc: CQ Tang <cq.tang(a)intel.com> Cc: <stable(a)vger.kernel.org> # v4.12+ --- drivers/gpu/drm/drm_file.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c index 0ac4566ae3f4..7b4258d6f7cc 100644 --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -258,8 +258,7 @@ void drm_file_free(struct drm_file *file) (long)old_encode_dev(file->minor->kdev->devt), atomic_read(&dev->open_count)); - if (drm_core_check_feature(dev, DRIVER_LEGACY) && - dev->driver->preclose) + if (dev->driver->preclose) dev->driver->preclose(dev, file); if (drm_core_check_feature(dev, DRIVER_LEGACY)) -- 2.20.1

5 13

Re: backend-drm and scanning really large resolutions
by Pekka Paalanen 12 Sep '20

12 Sep '20

Adding Rob back in CC, I don't know if he is subscribed to wayland-devel@. You forgot to CC dri-devel@ too. On Tue, 11 Feb 2020 17:18:52 -0500 Xiaowen Wu <wxiaowen(a)codeaurora.org> wrote: > Hi Rob, > > If the vendor driver doesn't have the hwpipe sub-object and kms plane is > one-to-one mapped to hwpipe (sspp), > do you think if below approach is acceptable if we still want to > virtualize the kms plane to support 4K/8K scanout? > > 1. At kms atomic check before calling drm_atomic_helper_check, depending > on scanout width of plane A in state, add idle planes B (C,D,...) > into the same atomic state, backup and then modify > src_x/src_w/crtc_x/crtc_w of plane A and the affected planes B (C,D,...) > to meet scanout > width limits, and set crtc/fb of the affected planes B (C,D,...) same as > plane A. > > 2. At plane's state duplicate function, check if plane's > src_x/src_w/crtc_x/crtc_w are updated at step 1), if so revert the > change to > plane A's backup value to allow plane A's scanout to update again. These > value will again be updated in step 1) so nothing really changes > if plane A continues updating. > > 3. If plane A's scanout is updated or detached from crtc, detach > affected planes B (C,D,...) in the same atomic state in step 1) and then > run step 1) again. > > 4. If user want to commit plane B (C,D,...), the commit/test will fail > if planes are already used as sister plane of plane A. This failure is > same > as insufficient hwpipe from plane B (C,D,...). > > With above change, any downstream driver can support virtualized plane. > Also as the above approach is generic and not h/w specific, we can make > it a helper function and it's up to vendor to choose if they want to use > or not, if they don't have logic like drm/msm/disp/mdp5/mdp5_plane in > their downstream driver. > > Conceptional above changes didn't borrow hwpipe resources from other > plane but borrow planes themselves directly, however from user point of > view > they should not feel any difference. > > What do you think? > > BR, > Xiaowen Wu > > > On Tue Jan 21, 2020 at 4:12 PM Rob Clark <robdclark at gmail.com> wrote: > > On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <matt.hoosier at > > gmail.com> wrote: > >> > >> Hi all, > >> > >> I'm confronting a situation where the hardware with which I work is > >> capable of driving connectors at 4K or 8K, but doing so requires > >> bonding the scanning of multiple planes together. > >> > >> The scenario is that you'd have a big primary framebuffer whose size > >> is too large for an individual hardware scanning pipeline on the > >> display controller to traverse within its maximum allowed clock rate. > >> > >> The hardware supplier's approach is to assign multiple planes, which > >> in the KMS driver map to hardware scanning pipelines, to each be > >> responsible for scanning a smaller section of the framebuffer. The > >> planes are all assigned to the same CRTC, and in concert with each > >> other they cover the whole area of the framebuffer and CRTC. > >> > >> This sounds a little bit wild to me. I hadn't been aware it's even > >> legal to have more than one plane treated a the source of scanout for > >> a single framebuffer. Maybe that distinction isn't really relevant > >> nowadays with universal plane support. > >> > > > > fwiw, have a look at drm/msm/disp/mdp5/mdp5_plane, which will allocate > > one or two hwpipe's from the devices global atomic state, depending on > > scanout width.. the hwpipe (sspp) is the physical resource behind a > > plane, so essentially the kms planes are virtualized. At some point > > if you have too many wide layers, the atomic test step will fail due > > to insufficient hwpipe's. But this sort of scenario is the reason for > > the test step. > > > > BR, > > -R > > > >> I'm wondering if anybody here knows whether this a legit approach for > >> a compositor's DRM backend to take? > >> > _______________________________________________ > wayland-devel mailing list > wayland-devel(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel

3 2

[PATCH v9 0/5] Add support for iMX8MQ Display Controller Subsystem
by Laurentiu Palcu 10 Sep '20

10 Sep '20

From: Laurentiu Palcu <laurentiu.palcu(a)nxp.com> Hi, This patchset adds initial DCSS support for iMX8MQ chip. Initial support includes only graphics plane support (no video planes), no HDR10 capabilities, no graphics decompression (only linear, tiled and super-tiled buffers allowed). Support for the rest of the features will be added incrementally, in subsequent patches. The patchset was tested with both HDP driver (in the downstream tree) and the upstream MIPI-DSI driver (with a couple of patches on top, to make it work correctly with DCSS). Thanks, Laurentiu Changes in v9: * Fixed a compilation issue found by Guido in his setup: 'select VIDEOMODE_HELPERS' was missing from Kconfig; * Use imx8mq-clock.h in the bindings file so one can understand what those clock values mean; * no other changes done. Couldn't address the hang Guido reported as it's not happening in my setup. However, in my tree, there are some extra NWL and ADV patches applied on top of upstream ones... Also, removing them and testing only with upstream, even if there's no image out, does not produce a hang... :/ Changes in v8: * Removed 'select RESET_CONTROLLER" from Kconfig as Philipp pointed out. SRC is not used in DCSS driver; * Nothing else changed; Changes in v7: * Added a patch to initialize the connector using the drm_bridge_connector API as Sam suggested. Tested it using NWL_DSI and ADV7535 with Guido's patch [1] applied and one fix for ADV [2]. Also, some extra patches for ADV and NWL were needed, from our downstream tree, which will be upstreamed soon by their author; * Rest of the patches are untouched; [1] https://lists.freedesktop.org/archives/dri-devel/2020-July/273025.html [2] https://lists.freedesktop.org/archives/dri-devel/2020-July/273132.html Changes in v6: * Addressed Rob's comment and added "additionalProperties: false" at the end of the bindings' properties. However, this change surfaced an issue with the assigned-clock* properties not being documented in the properties section. Added the descriptions and the bindings patch will need another review; * Added an entry for DCSS driver in the MAINTAINERS file; * Removed the component framework patch altogether; Changes in v5: * Rebased to latest; * Took out component framework support and made it a separate patch so that people can still test with HDP driver, which makes use of it. But the idea is to get rid of it once HDP driver's next versions will remove component framework as well; * Slight improvement to modesetting: avoid cutting off the pixel clock if the new mode and the old one are equal. Also, in this case, is not necessary to wait for DTG to shut off. This would allow to switch from 8b RGB to 12b YUV422, for example, with no interruptions (at least from DCSS point of view); * Do not fire off CTXLD when going to suspend, unless it still has entries that need to be committed to DCSS; * Addressed Rob's comments on bindings; Changes in v4: * Addressed Lucas and Philipp's comments: * Added DRM_KMS_CMA_HELPER dependency in Kconfig; * Removed usage of devm_ functions since I'm already doing all the clean-up in the submodules_deinit(); * Moved the drm_crtc_arm_vblank_event() in dcss_crtc_atomic_flush(); * Removed en_completion variable from dcss_crtc since this was introduced mainly to avoid vblank timeout warnings which were fixed by arming the vblank event in flush() instead of begin(); * Removed clks_on and irq_enabled flags since all the calls to enabling/disabling clocks and interrupts were balanced; * Removed the custom atomic_commit callback and used the DRM core helper and, in the process, got rid of a workqueue that wasn't necessary anymore; * Fixed some minor DT binding issues flagged by Philipp; * Some other minor changes suggested by Lucas; * Removed YUV formats from the supported formats as these cannot work without the HDR10 module CSCs and LUTs. Will add them back when I will add support for video planes; Changes in v3: * rebased to latest linux-next and made it compile as drmP.h was removed; * removed the patch adding the VIDEO2_PLL clock. It's already applied; * removed an unnecessary 50ms sleep in the dcss_dtg_sync_set(); * fixed a a spurious hang reported by Lukas Hartmann and encountered by me several times; * mask DPR and DTG interrupts by default, as they may come enabled from U-boot; Changes in v2: * Removed '0x' in node's unit-address both in DT and yaml; * Made the address region size lowercase, to be consistent; * Removed some left-over references to P010; * Added a Kconfig dependency of DRM && ARCH_MXC. This will also silence compilation issues reported by kbuild for other architectures; Laurentiu Palcu (5): drm/imx: compile imx directory by default drm/imx: Add initial support for DCSS on iMX8MQ drm/imx/dcss: use drm_bridge_connector API MAINTAINERS: Add entry for i.MX 8MQ DCSS driver dt-bindings: display: imx: add bindings for DCSS .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 108 +++ MAINTAINERS | 8 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/imx/Kconfig | 2 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/dcss/Kconfig | 9 + drivers/gpu/drm/imx/dcss/Makefile | 6 + drivers/gpu/drm/imx/dcss/dcss-blkctl.c | 70 ++ drivers/gpu/drm/imx/dcss/dcss-crtc.c | 219 +++++ drivers/gpu/drm/imx/dcss/dcss-ctxld.c | 424 +++++++++ drivers/gpu/drm/imx/dcss/dcss-dev.c | 325 +++++++ drivers/gpu/drm/imx/dcss/dcss-dev.h | 177 ++++ drivers/gpu/drm/imx/dcss/dcss-dpr.c | 562 ++++++++++++ drivers/gpu/drm/imx/dcss/dcss-drv.c | 138 +++ drivers/gpu/drm/imx/dcss/dcss-dtg.c | 409 +++++++++ drivers/gpu/drm/imx/dcss/dcss-kms.c | 198 +++++ drivers/gpu/drm/imx/dcss/dcss-kms.h | 44 + drivers/gpu/drm/imx/dcss/dcss-plane.c | 405 +++++++++ drivers/gpu/drm/imx/dcss/dcss-scaler.c | 826 ++++++++++++++++++ drivers/gpu/drm/imx/dcss/dcss-ss.c | 180 ++++ 20 files changed, 4112 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml create mode 100644 drivers/gpu/drm/imx/dcss/Kconfig create mode 100644 drivers/gpu/drm/imx/dcss/Makefile create mode 100644 drivers/gpu/drm/imx/dcss/dcss-blkctl.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-crtc.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ctxld.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dev.h create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dpr.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-drv.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-dtg.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-kms.h create mode 100644 drivers/gpu/drm/imx/dcss/dcss-plane.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-scaler.c create mode 100644 drivers/gpu/drm/imx/dcss/dcss-ss.c -- 2.23.0

6 20

Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780
by Paul Boddie 10 Sep '20

10 Sep '20

Hello, On and off over the past few months, I have been looking at getting the Synopsys DesignWare HDMI peripheral used in the Ingenic JZ4780 SoC working with a recent kernel. Unfortunately, what probably should be a straightforward task is proving more difficult than it seems, and I have been advised to ask for advice on this list. == Background == Previously, in the vendor kernels released by Imagination Technologies for the MIPS Creator CI20, there were specialised HDMI drivers for the JZ4780: * One (based on Linux 3.0.8) which seems to use a Synopsys hardware abstraction layer. * Another (based on Linux 3.18) where the driver incorporates code used to support Freescale products and cooperates with a "CRTC" driver that has since been replaced by the ingenic-drm.c driver. Since the Freescale-related code now seems to reside as a kind of generic driver in drivers/gpu/drm/bridge/synopsys [1], with some other drivers specialising this generic support, I thought that it might be straightforward to specialise the code similarly for the JZ4780. Unfortunately, I have not managed to achieve this so far, and I imagine that I must have overlooked something. == Summary of Work == What I have done so far is to add a new file to... drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c (See [2] for the full file.) This specialises the generic dw-hdmi.c driver and is heavily based on the existing driver in... drivers/gpu/drm/imx/dw_hdmi-imx.c However, the probe and remove functions are defined in a similar way to... drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c It would appear, looking at the vendor kernel code, that the configuration of the peripheral in the JZ4780 is most similar to that done in the i.MX products, with various configuration operations that are done in their own particular way in the vendor kernel code now being done in a more generic way in the bridge driver code. So, I have a certain amount of confidence that the PLL and current control tables are reasonable. == Observations == When powering up the system with the driver built into the kernel, the driver is able to obtain mode information over DDC using the Synopsys peripheral's own I2C support (which is more reliable than using the JZ4780's I2C peripherals), and a viable list of modes is obtained. However, the debugfs state information in /sys/kernel/debug/dri/0/state is largely unpopulated: plane[31]: plane-0 crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.000000x0.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range crtc[32]: crtc-0 enable=0 active=0 self_refresh_active=0 planes_changed=0 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=0 connector_mask=0 encoder_mask=0 mode: "": 0 0 0 0 0 0 0 0 0 0 0x0 0x0 connector[34]: HDMI-A-1 crtc=(null) self_refresh_aware=0 At the moment, I and others who have tried to test this code have seen that the peripheral is not enabled (as confirmed by inspecting the appropriate entry under /sys/devices/platform). It appears that one obstacle is that the "bus format" is not set for the connector. Here, I noticed (and was reminded again recently) that in the bridge driver, there is no call to drm_display_info_set_bus_formats unlike in other bridge drivers. If such a call is added with a plausible bus format, the peripheral will be enabled, but the signal is not correct (monitors report things like "Input not supported"). It also occurs to me that other aspects of the signal may need to be defined. However, the debugfs state information will be populated with plausible values and seems to indicate that initialisation has taken place. == Conclusions == Without direct modifications to dw-hdmi.c, it seems like the initialisation of the appropriate data structures is not being completed. Without the call to drm_display_info_set_bus_formats in dw_hdmi_bridge_attach, the encoder does not get set on the connector, and the chain of components is not fully traversed for initialisation. One part of this situation is the dw_hdmi_setup function in the bridge driver. Here, there is the following code: /* TOFIX: Get input format from plat data or fallback to RGB888 */ if (hdmi->plat_data->input_bus_format) hdmi->hdmi_data.enc_in_bus_format = hdmi->plat_data->input_bus_format; else hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_RGB888_1X24; /* TOFIX: Get input encoding from plat data or fallback to none */ if (hdmi->plat_data->input_bus_encoding) hdmi->hdmi_data.enc_in_encoding = hdmi->plat_data->input_bus_encoding; else hdmi->hdmi_data.enc_in_encoding = V4L2_YCBCR_ENC_DEFAULT; What I seek guidance on is whether the unfixed nature of this code is having an impact and what I should be doing to make this driver initialise correctly. Given that there is no obvious documentation for the Synopsys peripheral, I feel that it will be a long journey figuring this out by myself. Thanks for any advice that anyone might have! Paul [1] https://lists.freedesktop.org/archives/dri-devel/2017-March/134666.html [2] http://git.goldelico.com/?p=letux-kernel.git;a=blob_plain;f=drivers/gpu/drm…

5 25

← Newer
1
...
8
9
10
11
12
13
14
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2020