dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH] drm/ingenic: Fix pixclock rate for 24-bit serial panels
by Paul Cercueil 17 May '21

17 May '21

When using a 24-bit panel on a 8-bit serial bus, the pixel clock requested by the panel has to be multiplied by 3, since the subpixels are shifted sequentially. The code (in ingenic_drm_encoder_atomic_check) already computed crtc_state->adjusted_mode->crtc_clock accordingly, but clk_set_rate() used crtc_state->adjusted_mode->clock instead. Fixes: 28ab7d35b6e0 ("drm/ingenic: Properly compute timings when using a 3x8-bit panel") Cc: stable(a)vger.kernel.org # v5.10 Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> --- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c index d60e1eefc9d1..cba68bf52ec5 100644 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c @@ -342,7 +342,7 @@ static void ingenic_drm_crtc_atomic_flush(struct drm_crtc *crtc, if (priv->update_clk_rate) { mutex_lock(&priv->clk_mutex); clk_set_rate(priv->pix_clk, - crtc_state->adjusted_mode.clock * 1000); + crtc_state->adjusted_mode.crtc_clock * 1000); priv->update_clk_rate = false; mutex_unlock(&priv->clk_mutex); } -- 2.30.2

4 7

BUG: unable to handle kernel paging request in vga16fb_imageblit (2)
by syzbot 17 May '21

17 May '21

Hello, syzbot found the following crash on: HEAD commit: 262f7a6b Merge tag 'for-5.7-rc3-tag' of git://git.kernel.o.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12786888100000 kernel config: https://syzkaller.appspot.com/x/.config?x=5b075813ec8b93cd dashboard link: https://syzkaller.appspot.com/bug?extid=1f29e126cf461c4de3b3 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1f29e126cf461c4de3b3(a)syzkaller.appspotmail.com BUG: unable to handle page fault for address: ffff8880ffca0e80 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD d401067 P4D d401067 PUD 0 Oops: 0002 [#1] PREEMPT SMP KASAN CPU: 0 PID: 710 Comm: syz-executor.5 Not tainted 5.7.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline] RIP: 0010:vga_imageblit_expand drivers/video/fbdev/vga16fb.c:1168 [inline] RIP: 0010:vga16fb_imageblit+0xa5b/0x2210 drivers/video/fbdev/vga16fb.c:1260 Code: 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 09 84 d2 74 05 e8 ee 59 ed fd 41 8b 47 14 48 8b 74 24 08 <88> 06 0f ae e8 8a 06 b8 05 00 00 00 ba ce 03 00 00 ee 48 c7 c2 18 RSP: 0000:ffffc90002ea71f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000007 RCX: ffffc90014391000 RDX: 0000000000000000 RSI: ffff8880ffca0e80 RDI: ffffc90002ea739c RBP: ffffc90002ea738c R08: ffff8880922ac200 R09: 0000000000000000 R10: ffffffff8a895007 R11: fffffbfff1512a00 R12: 0000000000000000 R13: ffff888218de5140 R14: 0000000000000001 R15: ffffc90002ea7388 FS: 00007fbeeb282700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8880ffca0e80 CR3: 000000008e9c5000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline] bit_putcs+0x910/0xe10 drivers/video/fbdev/core/bitblit.c:188 fbcon_putcs+0x345/0x3f0 drivers/video/fbdev/core/fbcon.c:1362 con_flush drivers/tty/vt/vt.c:2569 [inline] do_con_write.part.0+0x7d1/0x1dc0 drivers/tty/vt/vt.c:2772 do_con_write drivers/tty/vt/vt.c:2588 [inline] con_write+0x41/0xe0 drivers/tty/vt/vt.c:3154 process_output_block drivers/tty/n_tty.c:595 [inline] n_tty_write+0x3f0/0xf90 drivers/tty/n_tty.c:2333 do_tty_write drivers/tty/tty_io.c:962 [inline] tty_write+0x495/0x800 drivers/tty/tty_io.c:1046 __vfs_write+0x76/0x100 fs/read_write.c:495 __kernel_write+0x11c/0x3a0 fs/read_write.c:516 write_pipe_buf+0x153/0x1e0 fs/splice.c:809 splice_from_pipe_feed fs/splice.c:512 [inline] __splice_from_pipe+0x3e6/0x7b0 fs/splice.c:636 splice_from_pipe+0xd9/0x140 fs/splice.c:671 default_file_splice_write+0x37/0x90 fs/splice.c:821 do_splice_from fs/splice.c:863 [inline] direct_splice_actor+0x115/0x160 fs/splice.c:1037 splice_direct_to_actor+0x38c/0x980 fs/splice.c:992 do_splice_direct+0x1b4/0x280 fs/splice.c:1080 do_sendfile+0x555/0xc50 fs/read_write.c:1521 __do_sys_sendfile64 fs/read_write.c:1582 [inline] __se_sys_sendfile64 fs/read_write.c:1568 [inline] __x64_sys_sendfile64+0x1cc/0x210 fs/read_write.c:1568 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45c829 Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007fbeeb281c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000028 RAX: ffffffffffffffda RBX: 00000000004fc0c0 RCX: 000000000045c829 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000003 RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000 R10: 0800000080004103 R11: 0000000000000246 R12: 00000000ffffffff R13: 00000000000008d6 R14: 00000000004cb7a1 R15: 00007fbeeb2826d4 Modules linked in: CR2: ffff8880ffca0e80 ---[ end trace 5bb103c4fc7bf525 ]--- RIP: 0010:writeb arch/x86/include/asm/io.h:65 [inline] RIP: 0010:vga_imageblit_expand drivers/video/fbdev/vga16fb.c:1168 [inline] RIP: 0010:vga16fb_imageblit+0xa5b/0x2210 drivers/video/fbdev/vga16fb.c:1260 Code: 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 09 84 d2 74 05 e8 ee 59 ed fd 41 8b 47 14 48 8b 74 24 08 <88> 06 0f ae e8 8a 06 b8 05 00 00 00 ba ce 03 00 00 ee 48 c7 c2 18 RSP: 0000:ffffc90002ea71f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000007 RCX: ffffc90014391000 RDX: 0000000000000000 RSI: ffff8880ffca0e80 RDI: ffffc90002ea739c RBP: ffffc90002ea738c R08: ffff8880922ac200 R09: 0000000000000000 R10: ffffffff8a895007 R11: fffffbfff1512a00 R12: 0000000000000000 R13: ffff888218de5140 R14: 0000000000000001 R15: ffffc90002ea7388 FS: 00007fbeeb282700(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8880ffca0e80 CR3: 000000008e9c5000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

5 20

[PATCH v3] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops
by Kai-Heng Feng 17 May '21

17 May '21

On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX to discrete GFX after S3. This is not desirable, because userspace will treat connected display as a new one, losing display settings. The expected behavior is to let discrete GFX drives all external displays. The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX. The method is inside the another _DSM, so add the _DSM and call it accordingly. I also tested some MUX-less and iGPU only laptops with that _DSM, no regression was found. v3: - Remove BXT from names. - Change the parameter type. - Fold the function into intel_modeset_init_hw(). v2: - Forward declare struct pci_dev. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113 References: https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh… Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/gpu/drm/i915/display/intel_acpi.c | 18 ++++++++++++++++++ drivers/gpu/drm/i915/display/intel_acpi.h | 3 +++ drivers/gpu/drm/i915/display/intel_display.c | 2 ++ 3 files changed, 23 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c b/drivers/gpu/drm/i915/display/intel_acpi.c index 833d0c1be4f1..d008d3976261 100644 --- a/drivers/gpu/drm/i915/display/intel_acpi.c +++ b/drivers/gpu/drm/i915/display/intel_acpi.c @@ -13,12 +13,17 @@ #include "intel_display_types.h" #define INTEL_DSM_REVISION_ID 1 /* For Calpella anyway... */ +#define INTEL_DSM_FN_PLATFORM_MUX_ENABLE 0 /* No args */ #define INTEL_DSM_FN_PLATFORM_MUX_INFO 1 /* No args */ static const guid_t intel_dsm_guid = GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f, 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c); +static const guid_t intel_dsm_guid2 = + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260, + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14); + static char *intel_dsm_port_name(u8 id) { switch (id) { @@ -176,6 +181,19 @@ void intel_unregister_dsm_handler(void) { } +void intel_dsm_enable_mux(struct drm_i915_private *i915) +{ + struct pci_dev *pdev = i915->drm.pdev; + acpi_handle dhandle; + + dhandle = ACPI_HANDLE(&pdev->dev); + if (!dhandle) + return; + + acpi_evaluate_dsm(dhandle, &intel_dsm_guid2, INTEL_DSM_REVISION_ID, + INTEL_DSM_FN_PLATFORM_MUX_ENABLE, NULL); +} + /* * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All Devices * Attached to the Display Adapter). diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h b/drivers/gpu/drm/i915/display/intel_acpi.h index e8b068661d22..def013cf6308 100644 --- a/drivers/gpu/drm/i915/display/intel_acpi.h +++ b/drivers/gpu/drm/i915/display/intel_acpi.h @@ -11,11 +11,14 @@ struct drm_i915_private; #ifdef CONFIG_ACPI void intel_register_dsm_handler(void); void intel_unregister_dsm_handler(void); +void intel_dsm_enable_mux(struct drm_i915_private *i915); void intel_acpi_device_id_update(struct drm_i915_private *i915); #else static inline void intel_register_dsm_handler(void) { return; } static inline void intel_unregister_dsm_handler(void) { return; } static inline +void intel_dsm_enable_mux(struct drm_i915_private *i915) { return; } +static inline void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; } #endif /* CONFIG_ACPI */ diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index a10e26380ef3..d79dae370b20 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -11472,6 +11472,8 @@ void intel_modeset_init_hw(struct drm_i915_private *i915) { struct intel_cdclk_state *cdclk_state; + intel_dsm_enable_mux(i915); + if (!HAS_DISPLAY(i915)) return; -- 2.30.2

3 4

[PATCH v13 0/4] drm/panfrost: Add support for mt8183 GPU
by Nicolas Boichat 17 May '21

17 May '21

Hi! This is just a rebase of the v11, untested (but it seems like Neil Armstrong recently tested it), with small changes in binding and dts. v11 cover follows: Follow-up on the v5 [1], things have gotten significantly better in the last year, thanks to the efforts on Bifrost support by the Collabora team (and probably others I'm not aware of). I've been testing this series on a MT8183/kukui device, with a chromeos-5.10 kernel [2], and got basic Chromium OS UI up with mesa 20.3.2 (lots of artifacts though). devfreq is currently not supported, as we'll need: - Clock core support for switching the GPU core clock (see 2/4). - Platform-specific handling of the 2-regulator (see 3/4). Since the latter is easy to detect, patch 3/4 just disables devfreq if the more than one regulator is specified in the compatible matching table. [1] https://patchwork.kernel.org/project/linux-mediatek/cover/20200306041345.25… [2] https://crrev.com/c/2608070 Changes in v13: - devfreq: Fix conflict resolution mistake when rebasing, didn't even compile. Oops. Changes in v12: - binding: Fix min/maxItems logic (Rob Herring) - Add gpu node to mt8183-pumpkin.dts as well (Neil Armstrong). Changes in v11: - binding: power-domain-names not power-domainS-names - mt8183*.dts: remove incorrect supply-names Changes in v10: - Fix the binding to make sure sram-supply property can be provided. Changes in v9: - Explain why devfreq needs to be disabled for GPUs with >1 regulators. Changes in v8: - Use DRM_DEV_INFO instead of ERROR Changes in v7: - Fix GPU ID in commit message - Fix GPU ID in commit message Changes in v6: - Rebased, actually tested with recent mesa driver. - Add gpu regulators to kukui dtsi as well. - Power domains are now attached to spm, not scpsys - Drop R-B. - devfreq: New change - Context conflicts, reflow the code. - Use ARRAY_SIZE for power domains too. Changes in v5: - Rename "2d" power domain to "core2" - Rename "2d" power domain to "core2" (keep R-B again). - Change power domain name from 2d to core2. Changes in v4: - Add power-domain-names description (kept Alyssa's reviewed-by as the change is minor) - Add power-domain-names to describe the 3 domains. (kept Alyssa's reviewed-by as the change is minor) - Add power domain names. Changes in v3: - Match mt8183-mali instead of bifrost, as we require special handling for the 2 regulators and 3 power domains. Changes in v2: - Use sram instead of mali_sram as SRAM supply name. - Rename mali@ to gpu@. Nicolas Boichat (4): dt-bindings: gpu: mali-bifrost: Add Mediatek MT8183 arm64: dts: mt8183: Add node for the Mali GPU drm/panfrost: devfreq: Disable devfreq when num_supplies > 1 drm/panfrost: Add mt8183-mali compatible string .../bindings/gpu/arm,mali-bifrost.yaml | 30 ++++- arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 5 + .../arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 5 + .../boot/dts/mediatek/mt8183-pumpkin.dts | 5 + arch/arm64/boot/dts/mediatek/mt8183.dtsi | 105 ++++++++++++++++++ drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++ drivers/gpu/drm/panfrost/panfrost_drv.c | 10 ++ 7 files changed, 168 insertions(+), 1 deletion(-) -- 2.31.1.368.gbe11c130af-goog

6 11

[PATCH v1 0/3] drm/msm/dpu: rework irq handling
by Dmitry Baryshkov 16 May '21

16 May '21

Simplify IRQ handling. dpu_irq_map is a huge table consisting of all possible IRQ entries (including a plenty of 'reserved' = not existing IRQs). It is always used to lookup the interrupt index (in the table) and then to use this index to lookup related interrupt register and mask. For the long period of time these indices had 1:1 correspondence to register/mask pairs. SC7280 introduced 'additional' IRQs removing this correpondence. Replace all IRQ lookup with stable irq indices, which correponds directly to the register/bit pair. The dpu_irq_map table is used only for the lookup of the irq index. Changes since RFC: - rebase on top of msm/msm-next to include SC7280 changes.

2 8

[PATCH v2 0/7] Qualcomm DRM DPU fixes
by AngeloGioacchino Del Regno 15 May '21

15 May '21

This patch series brings some fixes to the Qualcomm DPU driver, aim is to get it prepared for "legacy" SoCs (like MSM8998, SDM630/660) and to finally get command-mode displays working on this driver. The series was tested against MSM8998 (the commit that introduces it to the hw-catalog is not included in this series, as it needs to be cleaned up a little more) and specifically on: - Sony Xperia XZ Premium (MSM8998), 4K dual-dsi LCD display, command-mode - F(x)Tec Pro1 (MSM8998), single-dsi OLED display, video-mode ... And it obviously worked just perfect! Changes in v2: - Dropped patches "drm/msm/dpu: Add a function to retrieve the current CTL status" and "drm/msm/dpu: Fix timeout issues on command mode panels" as the second patch was wrong. - Fixed patch apply issues on latest linux-next and 5.11-rcX AngeloGioacchino Del Regno (7): drm/msm/dpu: Fix VBIF_XINL_QOS_LVL_REMAP_000 register offset drm/msm/dpu: Move DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks drm/msm/dpu: Add prog_fetch_lines_worst_case to INTF_BLK macro drm/msm/dpu: Allow specifying features and sblk in DSPP_BLK macro drm/msm/dpu: Disable autorefresh in command mode drm/msm/dpu: Correctly configure vsync tearcheck for command mode drm/msm/dpu: Remove unused call in wait_for_commit_done .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 90 +++++++++++++++---- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 49 +++++----- .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 26 ++++++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 9 +- 5 files changed, 147 insertions(+), 41 deletions(-) -- 2.29.2

2 8

[PATCH v3] drm/bridge/sii8620: fix dependency on extcon
by Robert Foss 15 May '21

15 May '21

The DRM_SIL_SII8620 kconfig has a weak `imply` dependency on EXTCON, which causes issues when sii8620 is built as a builtin and EXTCON is built as a module. The symptoms are 'undefined reference' errors caused by the symbols in EXTCON not being available to the sii8620 driver. Fixes: 688838442147 ("drm/bridge/sii8620: use micro-USB cable detection logic to detect MHL") Signed-off-by: Robert Foss <robert.foss(a)linaro.org> Reported-by: kernel test robot <lkp(a)intel.com> --- LKP reported issue: https://lore.kernel.org/lkml/202104040604.SSTe2Cxf-lkp@intel.com/ Changes since v1: - Fix typo on comment Changes since v2: - Randy: Changed from `depends` to `select` drivers/gpu/drm/bridge/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 22a467abd3e9..70402da5cc70 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -169,7 +169,7 @@ config DRM_SIL_SII8620 tristate "Silicon Image SII8620 HDMI/MHL bridge" depends on OF select DRM_KMS_HELPER - imply EXTCON + select EXTCON depends on RC_CORE || !RC_CORE help Silicon Image SII8620 HDMI/MHL bridge chip driver. -- 2.31.0.30.g398dba342d.dirty

2 6

[PATCH v2] drm: rcar-du: fix linker undefined references
by Randy Dunlap 15 May '21

15 May '21

When DRM_RCAR_DU=y and DRM_RCAR_LVDS=m, there are several build errors as reported by 'kernel test robot'. These can be corrected by changing source code occurrences of IS_ENABLED(...) to IS_REACHABLE(...). In looking at this, the same problem (build errors) happens when DRM_RCAR_DU=y and DRM_RCAR_CMM=m, so again change an IS_ENABLED() to IS_REACHABLE() for this case as well. These changes fix the following 8 build/link errors: aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x1be8): undefined reference to `rcar_lvds_clk_enable' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x2438): undefined reference to `rcar_lvds_clk_disable' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_drv.o: in function `rcar_du_init': rcar_du_drv.c:(.init.text+0x14): undefined reference to `rcar_du_of_init' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_encoder.o: in function `rcar_du_encoder_init': rcar_du_encoder.c:(.text+0x1d4): undefined reference to `rcar_lvds_dual_link' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_cmm_setup': rcar_du_crtc.c:(.text+0x380): undefined reference to `rcar_cmm_setup' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x1c08): undefined reference to `rcar_cmm_enable' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x231c): undefined reference to `rcar_cmm_disable' aarch64-linux-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init': rcar_du_kms.c:(.text+0xd08): undefined reference to `rcar_cmm_init' All RCAR kconfig combinations now build for me. Fixes: e08e934d6c28 ("drm: rcar-du: Add support for CMM") Fixes: 02f2b30032c1 ("drm: rcar-du: lvds: Add API to enable/disable clock output") Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Reported-by: kernel test robot <lkp(a)intel.com> Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-renesas-soc(a)vger.kernel.org Cc: Jacopo Mondi <jacopo+renesas(a)jmondi.org> --- v2: also send to LKML; don't change Kconfig "imply" to "select" since not all platforms with DU have CMM and/or LVDS support. Use IS_REACHABLE() instead. drivers/gpu/drm/rcar-du/rcar_cmm.h | 4 ++-- drivers/gpu/drm/rcar-du/rcar_du_of.h | 2 +- drivers/gpu/drm/rcar-du/rcar_lvds.h | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) --- linux-next-20210420.orig/drivers/gpu/drm/rcar-du/rcar_lvds.h +++ linux-next-20210420/drivers/gpu/drm/rcar-du/rcar_lvds.h @@ -12,7 +12,7 @@ struct drm_bridge; -#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS) +#if IS_REACHABLE(CONFIG_DRM_RCAR_LVDS) 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); --- linux-next-20210420.orig/drivers/gpu/drm/rcar-du/rcar_du_of.h +++ linux-next-20210420/drivers/gpu/drm/rcar-du/rcar_du_of.h @@ -11,7 +11,7 @@ struct of_device_id; -#if IS_ENABLED(CONFIG_DRM_RCAR_LVDS) +#if IS_REACHABLE(CONFIG_DRM_RCAR_LVDS) void __init rcar_du_of_init(const struct of_device_id *of_ids); #else static inline void rcar_du_of_init(const struct of_device_id *of_ids) { } --- linux-next-20210420.orig/drivers/gpu/drm/rcar-du/rcar_cmm.h +++ linux-next-20210420/drivers/gpu/drm/rcar-du/rcar_cmm.h @@ -25,7 +25,7 @@ struct rcar_cmm_config { } lut; }; -#if IS_ENABLED(CONFIG_DRM_RCAR_CMM) +#if IS_REACHABLE(CONFIG_DRM_RCAR_CMM) int rcar_cmm_init(struct platform_device *pdev); int rcar_cmm_enable(struct platform_device *pdev); @@ -53,6 +53,6 @@ static inline int rcar_cmm_setup(struct { return 0; } -#endif /* IS_ENABLED(CONFIG_DRM_RCAR_CMM) */ +#endif /* IS_REACHABLE(CONFIG_DRM_RCAR_CMM) */ #endif /* __RCAR_CMM_H__ */

1 1

[PATCH v3] drm: rcar: unbreak the R-Car menu items
by Randy Dunlap 15 May '21

15 May '21

DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig symbols do not depend on DRM_RCAR_DU, the menu presentation is broken for the following R-Car Kconfig symbols. Use an if/endif block to make all of these symbols depend on DRM_RCAR_DU (and remove the separate "depends on DRM_RCAR_DU"). This makes the kconfig menu presentation much cleaner. Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> Cc: dri-devel(a)lists.freedesktop.org Cc: linux-renesas-soc(a)vger.kernel.org Cc: Koji Matsuoka <koji.matsuoka.xm(a)renesas.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> --- v2: use an if/endif block for the dependencies (thanks, Geert) v3: still applicable -- update/rebase Applies after today's earlier patch to fix undefined reference build errors for R-Car (probably won't matter). I did this patch one year ago and then forgot about it somehow. Rediscovered & updated it today. drivers/gpu/drm/rcar-du/Kconfig | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- linux-next-20210423.orig/drivers/gpu/drm/rcar-du/Kconfig +++ linux-next-20210423/drivers/gpu/drm/rcar-du/Kconfig @@ -14,10 +14,11 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. +if DRM_RCAR_DU + config DRM_RCAR_CMM tristate "R-Car DU Color Management Module (CMM) Support" depends on DRM && OF - depends on DRM_RCAR_DU help Enable support for R-Car Color Management Module (CMM). @@ -41,7 +42,6 @@ config DRM_RCAR_LVDS config DRM_RCAR_VSP bool "R-Car DU VSP Compositor Support" if ARM default y if ARM64 - depends on DRM_RCAR_DU depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m) help Enable support to expose the R-Car VSP Compositor as KMS planes. @@ -49,4 +49,5 @@ config DRM_RCAR_VSP config DRM_RCAR_WRITEBACK bool default y if ARM64 - depends on DRM_RCAR_DU + +endif # DRM_RCAR_DU

1 1

[PATCH] drm/msm/dsi: save PLL registers across first PHY reset
by benl-kernelpatches＠squareup.com 15 May '21

15 May '21

From: Benjamin Li <benl(a)squareup.com> Take advantage of previously-added support for persisting PLL registers across DSI PHY disable/enable cycles (see 328e1a6 'drm/msm/dsi: Save/Restore PLL status across PHY reset') to support persisting across the very first DSI PHY enable at boot. The bootloader may have left the PLL registers in a non-default state. For example, for dsi_pll_28nm.c on 8x16/8x39, the byte clock mux's power-on reset configuration is to bypass DIV1, but depending on bandwidth requirements[1] the bootloader may have set the DIV1 path. When the byte clock mux is registered with the generic clock framework at probe time, the framework reads & caches the value of the mux bit field (the initial clock parent). After PHY enable, when clk_set_rate is called on the byte clock, the framework assumes there is no need to reparent, and doesn't re-write the mux bit field. But PHY enable resets PLL registers, so the mux bit field actually silently reverted to the DIV1 bypass path. This causes the byte clock to be off by a factor of e.g. 2 for our tested WXGA panel. The above issue manifests as the display not working and a constant stream of FIFO/LP0 contention errors. [1] The specific requirement for triggering the DIV1 path (and thus this issue) on 28nm is a panel with pixel clock <116.7MHz (one-third the minimum VCO setting). FHD/1080p (~145MHz) is fine, WXGA/1280x800 (~75MHz) is not. Signed-off-by: Benjamin Li <benl(a)squareup.com> --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c index 009f5b843dd1..139b4a5aaf86 100644 --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -621,6 +621,22 @@ static int dsi_phy_driver_probe(struct platform_device *pdev) phy->pll = NULL; } + /* + * As explained in msm_dsi_phy_enable, resetting the DSI PHY (as done + * in dsi_mgr_phy_enable) silently changes its PLL registers to power-on + * defaults, but the generic clock framework manages and caches several + * of the PLL registers. It initializes these caches at registration + * time via register read. + * + * As a result, we need to save DSI PLL registers once at probe in order + * for the first call to msm_dsi_phy_enable to successfully bring PLL + * registers back in line with what the generic clock framework expects. + * + * Subsequent PLL restores during msm_dsi_phy_enable will always be + * paired with PLL saves in msm_dsi_phy_disable. + */ + msm_dsi_pll_save_state(phy->pll); + dsi_phy_disable_resource(phy); platform_set_drvdata(pdev, phy); -- 2.17.1

3 5

← Newer
1
...
12
13
14
15
16
17
18
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021