dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH 0/4] drm/i915: Fix older platforms
by Ville Syrjala 04 Oct '21

04 Oct '21

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Fix a div-by-zero on gen2, and make the L-shaped memory detection actually work on cl/ctg. Atm the SWIZZLE_UNKNOWN stuff just trips some GEM_BUG_ONs. This doesn't fix those but since I populate all my memory channels symmetrically I get to avoid the GEM_BUG_ONs by correctly detecting that I don't have an L-shaped memory configuration. Ville Syrjälä (4): drm/i915: Avoid div-by-zero on gen2 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again drm/i915: Give C0DRB3/C1DRB3 a _BW suffix drm/i915: Rewrite CL/CTG L-shaped memory detection drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 19 ++++++++++--------- drivers/gpu/drm/i915/i915_debugfs.c | 16 ++++++++++++---- drivers/gpu/drm/i915/i915_reg.h | 8 ++++++-- 4 files changed, 29 insertions(+), 16 deletions(-) -- 2.26.3

3 11

[RFC 0/6] CPU + GPU synchronised priority scheduling
by Tvrtko Ursulin 04 Oct '21

04 Oct '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> This is a somewhat early sketch of one of my ideas intended for early feedback from the core scheduler experts. First and last two patches in the series are the most interesting ones for people outside of i915. (Note I did not copy everyone on all patches but just the cover letter for context and the rest should be available from the mailing list.) General idea is that current processing landscape seems to be more and more composed of pipelines where computations are done on multiple hardware devices. Furthermore some of the non-CPU devices, like in this case many GPUs supported by the i915 driver, actually support priority based scheduling which is currently rather inaccesible to the user (in terms of being able to control it from the outside). >From these two statements a question arises on how to allow for a simple, effective and consolidated user experience. In other words why user would not be able to do something like: $ nice ffmmpeg ...transcode my videos... $ my-favourite-game And have the nice hint apply to GPU parts of the transcode pipeline as well? Another reason why I started thinking about this is that I noticed Chrome browser for instance uses nice to de-prioritise background tabs. So again, having that decision propagate to the GPU rendering pipeline sounds like a big plus to the overall user experience. This RFC implements this idea with the hairy part being the notifier chain I added to enable dynamic adjustments. It is a global notifier which raises a few questions so I am very curious what experts will think here. Please see the opens in the first patch for more on this. And also the last two patches are the ones which implement a hash table in i915 so it can associate the notifier call- back with the correct GPU rendering contexts. On a more positive note the thing seems to even work as is. For instance I roughly simulated the above scenario by running a GPU hog at three nice levels and a GfxBench TRex in parallel (as a game proxy). This is what I got: GPU hog nice | TRex fps ------------------------------ 0 | 34.8 10 | 38.0 -10 | 30.8 So it is visible the feature can improve the user experience. Question is just if people are happy with this method of implementing it. Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Tvrtko Ursulin (6): sched: Add nice value change notifier drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track all user contexts per client drm/i915: Keep track of registered clients indexed by task struct drm/i915: Connect task and GPU scheduling priorities drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 20 +++ .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + .../drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/i915_drm_client.c | 129 ++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 71 ++++++++++ drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_request.h | 5 + drivers/gpu/drm/i915/i915_scheduler.c | 3 +- drivers/gpu/drm/i915/i915_scheduler.h | 14 ++ drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++ include/linux/sched.h | 5 + kernel/sched/core.c | 37 ++++- 16 files changed, 330 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h -- 2.30.2

2 13

[PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
by Fernando Ramos 04 Oct '21

04 Oct '21

Hi all, One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this patch series is about. You will find two types of changes here: - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has already been done in previous commits such as b7ea04d2) - Replacing "drm_modeset_lock_all()" with "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has already been done in previous commits such as 57037094) Most of the changes are straight forward, except for a few cases in the "amd" and "i915" drivers where some extra dancing was needed to overcome the limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used once inside the same function (the reason being that the macro expansion includes *labels*, and you can not have two labels named the same inside one function) Notice that, even after this patch series, some places remain where "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present, all inside drm core (which makes sense), except for two (in "amd" and "i915") which cannot be replaced due to the way they are being used. Changes in v2: - Fix commit message typo - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible - Split drm/i915 patch into two simpler ones - Remove drm_modeset_(un)lock_all() - Fix build problems in non-x86 platforms Fernando Ramos (17): drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() part 2 drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm: cleanup: remove drm_modeset_(un)lock_all() doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Documentation/gpu/todo.rst | 17 ---- Documentation/locking/ww-mutex-design.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 +++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +++++----- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 25 ++--- drivers/gpu/drm/drm_client_modeset.c | 14 ++- drivers/gpu/drm/drm_crtc_helper.c | 18 ++-- drivers/gpu/drm/drm_fb_helper.c | 10 +- drivers/gpu/drm/drm_framebuffer.c | 6 +- drivers/gpu/drm/drm_modeset_lock.c | 94 +------------------ drivers/gpu/drm/gma500/psb_device.c | 18 ++-- drivers/gpu/drm/i915/display/intel_audio.c | 16 ++-- drivers/gpu/drm/i915/display/intel_display.c | 23 ++--- .../drm/i915/display/intel_display_debugfs.c | 46 +++++---- drivers/gpu/drm/i915/display/intel_overlay.c | 46 ++++----- drivers/gpu/drm/i915/display/intel_pipe_crc.c | 7 +- drivers/gpu/drm/i915/i915_drv.c | 13 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 +- .../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 12 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++- drivers/gpu/drm/omapdrm/omap_fb.c | 9 +- drivers/gpu/drm/radeon/radeon_device.c | 21 +++-- drivers/gpu/drm/radeon/radeon_dp_mst.c | 10 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 +- drivers/gpu/drm/tegra/dsi.c | 6 +- drivers/gpu/drm/tegra/hdmi.c | 6 +- drivers/gpu/drm/tegra/sor.c | 11 ++- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 ++- include/drm/drm_modeset_lock.h | 2 - 30 files changed, 265 insertions(+), 292 deletions(-) base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.33.0

4 28

[PATCH v2 0/5] mxsfb/nwl/panels: media bus format fixes
by Guido Günther 04 Oct '21

04 Oct '21

commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if present") added bus format probing to mxsfb this exposed several issues in the display stack as used on the Librem 5: The nwl bridge and the panels didn't bother to set any media bus formats and in that case mxsfb would not pick a reasonable default. This series aims to fix this. This series includes the patch from https://lore.kernel.org/dri-devel/YVLYh%2FSgBritG%2FRJ@qwark.sigxcpu.org/ with a `dev_warn` added. The patches are against 5.15-rc3. I've marked a single patch with a 'fixes' which is enough to unbreak the display stack in 5.15. All patches of this series can be applied independently. Changes from v1: - Review comment by Marek Vasut https://lore.kernel.org/dri-devel/67e6056a-6157-795d-908d-d65cc803c03d@denx… Improve warning message - Move mxsfb patches to the end of the queue and the actual nwl fix to the front. Guido Günther (5): drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts drm/panel: mantix: Add media bus format drm/panel: st7703: Add media bus format drm: mxsfb: Print failed bus format in hex drm: mxsfb: Set proper default bus format when using a bridge drivers/gpu/drm/bridge/nwl-dsi.c | 35 +++++++++++++++++++ drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 ++++- .../gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +++++ drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +++++ 4 files changed, 59 insertions(+), 1 deletion(-) -- 2.33.0

2 9

[BUG 5.15-rc3] kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245!
by Steven Rostedt 04 Oct '21

04 Oct '21

When I tried to test patches applied to v5.15-rc3, I hit this bug (and hence can not test my code), on 32 bit x86. ------------[ cut here ]------------ kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! invalid opcode: 0000 [#1] SMP PTI CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc1-test+ #456 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 EIP: __i915_sw_fence_init+0x15/0x38 Code: 2b 3d 58 98 88 c1 74 05 e8 60 d9 58 00 8d 65 f4 5b 5e 5f 5d c3 3e 8d 74 26 00 55 89 e5 56 89 d6 53 85 d2 74 05 f6 c2 03 74 02 <0f> 0b 89 ca 8b 4d 08 89 c3 e8 48 94 ab ff 89 73 34 c7 43 38 01 00 EAX: c2508260 EBX: c2508000 ECX: c143de1e EDX: c09dfadd ESI: c09dfadd EDI: c45e7200 EBP: c26c9c68 ESP: c26c9c60 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010202 CR0: 80050033 CR2: 00000000 CR3: 019e2000 CR4: 001506f0 Call Trace: intel_context_init+0x112/0x145 intel_context_create+0x29/0x37 intel_ring_submission_setup+0x3cb/0x5a8 ? kfree+0x135/0x1c6 ? wa_init_finish+0x32/0x59 ? wa_init_finish+0x4f/0x59 ? intel_engine_init_ctx_wa+0x39a/0x3b3 intel_engines_init+0x2dd/0x4d0 ? gen6_bsd_submit_request+0x97/0x97 intel_gt_init+0x122/0x20d i915_gem_init+0x80/0xef i915_driver_probe+0x880/0xa90 ? i915_pci_remove+0x27/0x27 i915_pci_probe+0xdd/0xf6 ? __pm_runtime_resume+0x63/0x6b ? i915_pci_remove+0x27/0x27 pci_device_probe+0xbc/0x11e really_probe+0x13e/0x328 __driver_probe_device+0x140/0x176 driver_probe_device+0x1f/0x71 __driver_attach+0xf6/0x109 ? __device_attach_driver+0xbd/0xbd bus_for_each_dev+0x5b/0x88 driver_attach+0x19/0x1b ? __device_attach_driver+0xbd/0xbd bus_add_driver+0xf2/0x199 driver_register+0x8c/0xbe __pci_register_driver+0x5b/0x60 i915_register_pci_driver+0x19/0x1b i915_init+0x15/0x67 ? radeon_module_init+0x6a/0x6a do_one_initcall+0xce/0x21c ? rcu_read_lock_sched_held+0x35/0x6d ? trace_initcall_level+0x5f/0x99 kernel_init_freeable+0x1fb/0x247 ? rest_init+0x129/0x129 kernel_init+0x17/0xfd ret_from_fork+0x1c/0x28 Modules linked in: ---[ end trace 791dc89810d853da ]--- EIP: __i915_sw_fence_init+0x15/0x38 Code: 2b 3d 58 98 88 c1 74 05 e8 60 d9 58 00 8d 65 f4 5b 5e 5f 5d c3 3e 8d 74 26 00 55 89 e5 56 89 d6 53 85 d2 74 05 f6 c2 03 74 02 <0f> 0b 89 ca 8b 4d 08 89 c3 e8 48 94 ab ff 89 73 34 c7 43 38 01 00 EAX: c2508260 EBX: c2508000 ECX: c143de1e EDX: c09dfadd ESI: c09dfadd EDI: c45e7200 EBP: c26c9c68 ESP: c26c9c60 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010202 CR0: 80050033 CR2: 00000000 CR3: 019e2000 CR4: 001506f0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Kernel Offset: disabled ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Attached is the dmesg and the config. I bisected it down to this commit: 3ffe82d701a4 ("drm/i915/xehp: handle new steering options") -- Steve

4 5

[PATCH 1/3] drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()
by Dan Carpenter 04 Oct '21

04 Oct '21

Return an error code if msm_dsi_manager_validate_current_config(). Don't return success. Fixes: 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- drivers/gpu/drm/msm/dsi/dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c index 614dc7f26f2c..75ae3008b68f 100644 --- a/drivers/gpu/drm/msm/dsi/dsi.c +++ b/drivers/gpu/drm/msm/dsi/dsi.c @@ -215,8 +215,10 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev, goto fail; } - if (!msm_dsi_manager_validate_current_config(msm_dsi->id)) + if (!msm_dsi_manager_validate_current_config(msm_dsi->id)) { + ret = -EINVAL; goto fail; + } msm_dsi->encoder = encoder; -- 2.20.1

2 7

[PATCH 00/10] drm/gma500: Refactor GEM code
by Thomas Zimmermann 04 Oct '21

04 Oct '21

Bring GEM code up to current standards and untangle the connection to GTT helpers. The allocation and pinning helpers for struct gtt_range are located in the GTT code, but actually part of the GEM implementation. The patchset moves them to GEM code and refactors much of the implementation. Most of the GTT code is then independend from the struct gtt_range, while the GEM code does not contain GTT management. In addition to internal refiactoring, patches 2 to 4 update the rest of the driver to use the GEM interfaces for object allocation and release. Finally, rename struct gtt_range to struct psb_gem_object to designate it as a 'real' GEM object. Future work: with the GEM and GTT code separated, future patchsets can implement on-demand release of GTT entries, or remove the perma-mapping of stolen memory. Dma-buf support might also be added. Tested on Atom N2800 hardware. Thomas Zimmermann (10): drm/gma500: Move helpers for struct gtt_range from gtt.c to gem.c drm/gma500: Use to_gtt_range() everywhere drm/gma500: Reimplement psb_gem_create() drm/gma500: Allocate GTT ranges in stolen memory with psb_gem_create() drm/gma500: Rename psb_gtt_{pin,unpin}() to psb_gem_{pin,unpin}() drm/gma500: Inline psb_gtt_attach_pages() and psb_gtt_detach_pages() drm/gma500: Inline psb_gtt_{alloc,free}_range() into rsp callers drm/gma500: Set page-caching flags in GEM pin/unpin drm/gma500: Rewrite GTT page insert/remove without struct gtt_range drm/gma500: Rename struct gtt_range to struct psb_gem_object drivers/gpu/drm/gma500/framebuffer.c | 52 +--- drivers/gpu/drm/gma500/gem.c | 227 +++++++++++---- drivers/gpu/drm/gma500/gem.h | 28 +- drivers/gpu/drm/gma500/gma_display.c | 51 ++-- drivers/gpu/drm/gma500/gtt.c | 320 ++++----------------- drivers/gpu/drm/gma500/gtt.h | 29 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 3 +- drivers/gpu/drm/gma500/psb_intel_display.c | 17 +- drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +- 9 files changed, 310 insertions(+), 419 deletions(-) -- 2.33.0

2 24

[PATCH v5 00/16] Add MediaTek SoC DRM (vdosys1) support for mt8195
by Nancy.Lin 04 Oct '21

04 Oct '21

The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. Add DRM and these modules support by the patches below: Changes in v5: - add mmsys reset controller reference. Changes in v4: - use merge common driver for merge1~4. - refine ovl_adaptor rdma driver. - use ovl_adaptor ddp_comp function instead of ethdr. - modify for reviewer's comment in v3. Changes in v3: - modify for reviewer's comment in v2. - add vdosys1 2 pixels align limit. - add mixer odd offset support. Changes in v2: - Merge PSEUDO_OVL and ETHDR into one DRM component. - Add mmsys config API for vdosys1 hardware setting. - Add mmsys reset control using linux reset framework. Signed-off-by: Nancy.Lin <nancy.lin(a)mediatek.com> This series are based on the following patch: [1] arm64: dts: Add Mediatek SoC MT8195 and evaluation board dts and Makefile https://patchwork.kernel.org/project/linux-mediatek/patch/20210601075350.31… [2] arm64: dts: mt8195: add IOMMU and smi nodes https://patchwork.kernel.org/project/linux-mediatek/patch/20210615173233.26… [3] [01/24] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU https://patchwork.kernel.org/project/linux-mediatek/patch/20210630023504.18… [4] Add gce support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/list/?series=537069 [5] Add MediaTek SoC DRM (vdosys0) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/list/?series=537225 [6] [v8,1/2] dt-bindings: reset: mt8195: add toprgu reset-controller header file https://patchwork.kernel.org/project/linux-mediatek/patch/20210806023606.16… [7] [v3,2/7] dt-bindings: mediatek: Add #reset-cells to mmsys system controller https://patchwork.kernel.org/project/linux-mediatek/patch/20210825122613.v3… [8] [v3,6/7] soc: mediatek: mmsys: Add reset controller support https://patchwork.kernel.org/project/linux-mediatek/patch/20210825122613.v3… Nancy.Lin (16): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: mediatek: add vdosys1 MERGE property for mt8195 dt-bindings: mediatek: add ethdr definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit arm64: dts: mt8195: add display node for vdosys1 soc: mediatek: add mtk-mmsys support for mt8195 vdosys1 soc: mediatek: add mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: add cmdq support of mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1 soc: mediatek: add mtk-mutex support for mt8195 vdosys1 drm/mediatek: add display MDP RDMA support for MT8195 drm/mediatek: add display merge api support for MT8195 drm/mediatek: add ETHDR support for MT8195 drm/mediatek: add ovl_adaptor support for MT8195 drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support drm/mediatek: add mediatek-drm of vdosys1 support for MT8195 .../display/mediatek/mediatek,ethdr.yaml | 144 ++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 77 ++++ .../display/mediatek/mediatek,merge.yaml | 3 + arch/arm64/boot/dts/mediatek/mt8195.dtsi | 221 +++++++++ drivers/gpu/drm/mediatek/Makefile | 5 +- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 29 ++ drivers/gpu/drm/mediatek/mtk_disp_merge.c | 78 +++- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 408 +++++++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 25 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 377 +++++++++++++--- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 9 +- drivers/gpu/drm/mediatek/mtk_ethdr.c | 424 ++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 ++ drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 301 +++++++++++++ drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 37 ++ drivers/soc/mediatek/mt8195-mmsys.h | 199 ++++++++ drivers/soc/mediatek/mtk-mmsys.c | 76 +++- drivers/soc/mediatek/mtk-mmsys.h | 11 + drivers/soc/mediatek/mtk-mutex.c | 270 ++++++----- include/dt-bindings/reset/mt8195-resets.h | 12 + include/linux/soc/mediatek/mtk-mmsys.h | 22 + 24 files changed, 2574 insertions(+), 198 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h -- 2.18.0

4 33

[PATCH] drm: rcar-du: Don't create encoder for unconnected LVDS outputs
by Laurent Pinchart 03 Oct '21

03 Oct '21

On R-Car D3 and E3, the LVDS encoders provide the pixel clock to the DU, even when LVDS outputs are not used. For this reason, the rcar-lvds driver probes successfully on those platforms even if no further bridge or panel is connected to the LVDS output, in order to provide the rcar_lvds_clk_enable() and rcar_lvds_clk_disable() functions to the DU driver. If an LVDS output isn't connected, trying to create a DRM connector for the output will fail. Fix this by skipping connector creation in that case, and also skip creation of the DRM encoder as there's no point in an encoder without a connector. Fixes: e9e056949c92 ("drm: rcar-du: lvds: Convert to DRM panel bridge helper") Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> --- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 16 ++++++++++++---- drivers/gpu/drm/rcar-du/rcar_lvds.c | 11 +++++++++++ drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 +++++ 3 files changed, 28 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c index 0daa8bba50f5..4bf4e25d7f01 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c @@ -86,12 +86,20 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu, } /* - * Create and initialize the encoder. On Gen3 skip the LVDS1 output if + * Create and initialize the encoder. On Gen3, skip the LVDS1 output if * the LVDS1 encoder is used as a companion for LVDS0 in dual-link - * mode. + * mode, or any LVDS output if it isn't connected. The latter may happen + * on D3 or E3 as the LVDS encoders are needed to provide the pixel + * clock to the DU, even when the LVDS outputs are not used. */ - if (rcdu->info->gen >= 3 && output == RCAR_DU_OUTPUT_LVDS1) { - if (rcar_lvds_dual_link(bridge)) + if (rcdu->info->gen >= 3) { + if (output == RCAR_DU_OUTPUT_LVDS1 && + rcar_lvds_dual_link(bridge)) + return -ENOLINK; + + if ((output == RCAR_DU_OUTPUT_LVDS0 || + output == RCAR_DU_OUTPUT_LVDS1) && + !rcar_lvds_is_connected(bridge)) return -ENOLINK; } diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index d061b8de748f..b672c5bd72ee 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -576,6 +576,9 @@ static int rcar_lvds_attach(struct drm_bridge *bridge, { struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge); + if (!lvds->next_bridge) + return 0; + return drm_bridge_attach(bridge->encoder, lvds->next_bridge, bridge, flags); } @@ -598,6 +601,14 @@ bool rcar_lvds_dual_link(struct drm_bridge *bridge) } EXPORT_SYMBOL_GPL(rcar_lvds_dual_link); +bool rcar_lvds_is_connected(struct drm_bridge *bridge) +{ + struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge); + + return lvds->next_bridge != NULL; +} +EXPORT_SYMBOL_GPL(rcar_lvds_is_connected); + /* ----------------------------------------------------------------------------- * Probe & Remove */ diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.h b/drivers/gpu/drm/rcar-du/rcar_lvds.h index 222ec0e60785..eb7c6ef03b00 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.h +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.h @@ -16,6 +16,7 @@ struct drm_bridge; int rcar_lvds_clk_enable(struct drm_bridge *bridge, unsigned long freq); void rcar_lvds_clk_disable(struct drm_bridge *bridge); bool rcar_lvds_dual_link(struct drm_bridge *bridge); +bool rcar_lvds_is_connected(struct drm_bridge *bridge); #else static inline int rcar_lvds_clk_enable(struct drm_bridge *bridge, unsigned long freq) @@ -27,6 +28,10 @@ static inline bool rcar_lvds_dual_link(struct drm_bridge *bridge) { return false; } +static inline bool rcar_lvds_is_connected(struct drm_bridge *bridge) +{ + return false; +} #endif /* CONFIG_DRM_RCAR_LVDS */ #endif /* __RCAR_LVDS_H__ */ -- Regards, Laurent Pinchart

4 5

[GIT FIXES FOR v5.15] R-Car DU fix
by Laurent Pinchart 03 Oct '21

03 Oct '21

Hi Dave and Daniel, The following changes since commit 78ea81417944fe03f48648eddeb8e8a8e513c4ad: Merge tag 'exynos-drm-fixes-for-v5.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2021-10-01 18:14:39 +0200) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-fixes-20211003 for you to fetch changes up to 734d0b3b6afd44510b4752ea730685f89e107767: drm: rcar-du: Don't create encoder for unconnected LVDS outputs (2021-10-03 16:05:36 +0300) ---------------------------------------------------------------- - R-Car DU fix for LVDS outputs on D3 and E3 SoCs ---------------------------------------------------------------- Laurent Pinchart (1): drm: rcar-du: Don't create encoder for unconnected LVDS outputs drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 16 ++++++++++++---- drivers/gpu/drm/rcar-du/rcar_lvds.c | 11 +++++++++++ drivers/gpu/drm/rcar-du/rcar_lvds.h | 5 +++++ 3 files changed, 28 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart

1 0

← Newer
1
...
74
75
76
77
78
79
80
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021