summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-09-20dma-buf/dma-fence: Use a successful read_trylock() annotation for ↵Thomas Hellström
dma_fence_begin_signalling() Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230428125233.228353-1-thomas.hellstrom@linux.intel.com
2024-09-19drm/rockchip: Load crtc devices in preferred orderJonas Karlman
On RK3399 the VOPL is loaded before VOPB and get registered as crtc-0. However, on RK3288 and PX30 VOPB is gets registered as crtc-0 instead of VOPL. With VOPL registered as crtc-0 the kernel kms client is not able to enable 4K display modes for console use on RK3399. Load VOPB before VOPL to help kernel kms client make use of 4K display modes for console use on RK3399. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-8-jonas@kwiboo.se
2024-09-19drm/rockchip: dw_hdmi: Enable 4K@60Hz mode on RK3399 and RK356xJonas Karlman
Use a maximum TMDS clock rate limit of 594MHz to enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3399 and RK3568. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Quartz64 Model B Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-7-jonas@kwiboo.se
2024-09-19drm/rockchip: dw_hdmi: Use auto-generated tablesDouglas Anderson
The previous tables for mpll_cfg and curr_ctrl were created using the 20-pages of example settings provided by the PHY vendor. Those example settings weren't particularly dense, so there were places where we were guessing what the settings would be for 10-bit and 12-bit (not that we use those anyway). It was also always a lot of extra work every time we wanted to add a new clock rate since we had to cross-reference several tables. In <https://crrev.com/c/285855> I've gone through the work to figure out how to generate this table automatically. Let's now use the automatically generated table and then we'll never need to look at it again. We only support 8-bit mode right now and only support a small number of clock rates and I've verified that the only 8-bit rate that was affected was 148.5. That mode appears to have been wrong in the old table. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-6-jonas@kwiboo.se
2024-09-19drm/rockchip: dw_hdmi: Set cur_ctr to 0 alwaysDouglas Anderson
Jitter was improved by lowering the MPLL bandwidth to account for high frequency noise in the rk3288 PLL. In each case MPLL bandwidth was lowered only enough to get us a comfortable margin. We believe that lowering the bandwidth like this is safe given sufficient testing. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-5-jonas@kwiboo.se
2024-09-19drm/rockchip: dw_hdmi: Add phy_config for 594Mhz pixel clockNickey Yang
Add phy_config for 594Mhz pixel clock used for HDMI2.0 display modes. Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-4-jonas@kwiboo.se
2024-09-19drm/rockchip: dw_hdmi: Adjust cklvl & txlvl for RF/EMIYakir Yang
Dut to the high HDMI signal voltage driver, Mickey have meet a serious RF/EMI problem, so we decided to reduce HDMI signal voltage to a proper value. The default params for phy is cklvl = 20 & txlvl = 13 (RF/EMI failed) ck: lvl = 13, term=100, vlo = 2.71, vhi=3.14, vswing = 0.43 tx: lvl = 20, term=100, vlo = 2.81, vhi=3.16, vswing = 0.35 1. We decided to reduce voltage value to lower, but VSwing still keep high, RF/EMI have been improved but still failed. ck: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50 tx: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50 2. We try to keep voltage value and vswing both lower, then RF/EMI test all passed ;) ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40 tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40 When we back to run HDMI different test and single-end test, we see different test passed, but signle-end test failed. The oscilloscope show that simgle-end clock's VL value is 1.78v (which remind LowLimit should not lower then 2.6v). 3. That's to say there are some different between PHY document and measure value. And according to experiment 2 results, we need to higher clock voltage and lower data voltage, then we can keep RF/EMI satisfied and single-end & differen test passed. ck: lvl = 9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47 tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39 Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-3-jonas@kwiboo.se
2024-09-19drm/rockchip: dw_hdmi: Filter modes based on hdmiphy_clkJonas Karlman
RK3228 and RK3328 clock rate is being validated against a mpll config table intended for a Synopsys phy, and not the used inno-hdmi-phy. Instead get a reference to the hdmiphy clk and validate rates against it to enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228 and RK3328. For Synopsis phy the max_tmds_clock validation is sufficient. Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64 Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-2-jonas@kwiboo.se
2024-09-19drm/rockchip: Fix a typoAndrew Kreimer
Fix a typo in comments. Reported-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Andrew Kreimer <algonell@gmail.com> Acked-by: Andy Yan<andyshrk@163.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240915123943.105118-1-algonell@gmail.com
2024-09-18drm/ast: Warn about unsupported TX chipsThomas Zimmermann
A number of TX chips are listed in VGACRD1, but not supported by the ast driver. Whether any existing product uses such a chip is unknown. Warn if the driver encounters any. We can then add support as necessary. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Suggested-by: Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916082920.56234-4-tzimmermann@suse.de
2024-09-18drm/ast: Use TX-chip register constantsThomas Zimmermann
Replace magic values with named constants when reading the TX chip from VGACRD1. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916082920.56234-3-tzimmermann@suse.de
2024-09-18drm/ast: Rename register constants for TX-chip typesThomas Zimmermann
The type of the TX chip is provided in VGACRD1. Rename the constants accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240916082920.56234-2-tzimmermann@suse.de
2024-09-16drm/panic: Fix uninitialized spinlock acquisition with CONFIG_DRM_PANIC=nLyude Paul
It turns out that if you happen to have a kernel config where CONFIG_DRM_PANIC is disabled and spinlock debugging is enabled, along with KMS being enabled - we'll end up trying to acquire an uninitialized spin_lock with drm_panic_lock() when we try to do a commit: rvkms rvkms.0: [drm:drm_atomic_commit] committing 0000000068d2ade1 INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 4 PID: 1347 Comm: modprobe Not tainted 6.10.0-rc1Lyude-Test+ #272 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20240524-3.fc40 05/24/2024 Call Trace: <TASK> dump_stack_lvl+0x77/0xa0 assign_lock_key+0x114/0x120 register_lock_class+0xa8/0x2c0 __lock_acquire+0x7d/0x2bd0 ? __vmap_pages_range_noflush+0x3a8/0x550 ? drm_atomic_helper_swap_state+0x2ad/0x3a0 lock_acquire+0xec/0x290 ? drm_atomic_helper_swap_state+0x2ad/0x3a0 ? lock_release+0xee/0x310 _raw_spin_lock_irqsave+0x4e/0x70 ? drm_atomic_helper_swap_state+0x2ad/0x3a0 drm_atomic_helper_swap_state+0x2ad/0x3a0 drm_atomic_helper_commit+0xb1/0x270 drm_atomic_commit+0xaf/0xe0 ? __pfx___drm_printfn_info+0x10/0x10 drm_client_modeset_commit_atomic+0x1a1/0x250 drm_client_modeset_commit_locked+0x4b/0x180 drm_client_modeset_commit+0x27/0x50 __drm_fb_helper_restore_fbdev_mode_unlocked+0x76/0x90 drm_fb_helper_set_par+0x38/0x40 fbcon_init+0x3c4/0x690 visual_init+0xc0/0x120 do_bind_con_driver+0x409/0x4c0 do_take_over_console+0x233/0x280 do_fb_registered+0x11f/0x210 fbcon_fb_registered+0x2c/0x60 register_framebuffer+0x248/0x2a0 __drm_fb_helper_initial_config_and_unlock+0x58a/0x720 drm_fbdev_generic_client_hotplug+0x6e/0xb0 drm_client_register+0x76/0xc0 _RNvXs_CsHeezP08sTT_5rvkmsNtB4_5RvkmsNtNtCs1cdwasc6FUb_6kernel8platform6Driver5probe+0xed2/0x1060 [rvkms] ? _RNvMs_NtCs1cdwasc6FUb_6kernel8platformINtB4_7AdapterNtCsHeezP08sTT_5rvkms5RvkmsE14probe_callbackBQ_+0x2b/0x70 [rvkms] ? acpi_dev_pm_attach+0x25/0x110 ? platform_probe+0x6a/0xa0 ? really_probe+0x10b/0x400 ? __driver_probe_device+0x7c/0x140 ? driver_probe_device+0x22/0x1b0 ? __device_attach_driver+0x13a/0x1c0 ? __pfx___device_attach_driver+0x10/0x10 ? bus_for_each_drv+0x114/0x170 ? __device_attach+0xd6/0x1b0 ? bus_probe_device+0x9e/0x120 ? device_add+0x288/0x4b0 ? platform_device_add+0x75/0x230 ? platform_device_register_full+0x141/0x180 ? rust_helper_platform_device_register_simple+0x85/0xb0 ? _RNvMs2_NtCs1cdwasc6FUb_6kernel8platformNtB5_6Device13create_simple+0x1d/0x60 ? _RNvXs0_CsHeezP08sTT_5rvkmsNtB5_5RvkmsNtCs1cdwasc6FUb_6kernel6Module4init+0x11e/0x160 [rvkms] ? 0xffffffffc083f000 ? init_module+0x20/0x1000 [rvkms] ? kernfs_xattr_get+0x3e/0x80 ? do_one_initcall+0x148/0x3f0 ? __lock_acquire+0x5ef/0x2bd0 ? __lock_acquire+0x5ef/0x2bd0 ? __lock_acquire+0x5ef/0x2bd0 ? put_cpu_partial+0x51/0x1d0 ? lock_acquire+0xec/0x290 ? put_cpu_partial+0x51/0x1d0 ? lock_release+0xee/0x310 ? put_cpu_partial+0x51/0x1d0 ? fs_reclaim_acquire+0x69/0xf0 ? lock_acquire+0xec/0x290 ? fs_reclaim_acquire+0x69/0xf0 ? kfree+0x22f/0x340 ? lock_release+0xee/0x310 ? kmalloc_trace_noprof+0x48/0x340 ? do_init_module+0x22/0x240 ? kmalloc_trace_noprof+0x155/0x340 ? do_init_module+0x60/0x240 ? __se_sys_finit_module+0x2e0/0x3f0 ? do_syscall_64+0xa4/0x180 ? syscall_exit_to_user_mode+0x108/0x140 ? do_syscall_64+0xb0/0x180 ? vma_end_read+0xd0/0xe0 ? do_user_addr_fault+0x309/0x640 ? clear_bhb_loop+0x45/0xa0 ? clear_bhb_loop+0x45/0xa0 ? clear_bhb_loop+0x45/0xa0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Fix this by stubbing these macros out when this config option isn't enabled, along with fixing the unused variable warning that introduces. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: e2a1cda3e0c7 ("drm/panic: Add drm panic locking") Cc: <stable@vger.kernel.org> # v6.10+ Link: https://patchwork.freedesktop.org/patch/msgid/20240916230103.611490-1-lyude@redhat.com
2024-09-16drm/v3d: Appease lockdep while updating GPU statsTvrtko Ursulin
Lockdep thinks our seqcount_t usage is unsafe because the update path can be both from irq and worker context: [ ] ================================ [ ] WARNING: inconsistent lock state [ ] 6.10.3-v8-16k-numa #159 Tainted: G WC [ ] -------------------------------- [ ] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [ ] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes: [ ] ffff80003d7c08d0 (&v3d_priv->stats[i].lock){?.+.}-{0:0}, at: v3d_irq+0xc8/0x660 [v3d] [ ] {HARDIRQ-ON-W} state was registered at: [ ] lock_acquire+0x1f8/0x328 [ ] v3d_job_start_stats.isra.0+0xd8/0x218 [v3d] [ ] v3d_bin_job_run+0x23c/0x388 [v3d] [ ] drm_sched_run_job_work+0x520/0x6d0 [gpu_sched] [ ] process_one_work+0x62c/0xb48 [ ] worker_thread+0x468/0x5b0 [ ] kthread+0x1c4/0x1e0 [ ] ret_from_fork+0x10/0x20 [ ] irq event stamp: 337094 [ ] hardirqs last enabled at (337093): [<ffffc0008144ce7c>] default_idle_call+0x11c/0x140 [ ] hardirqs last disabled at (337094): [<ffffc0008144a354>] el1_interrupt+0x24/0x58 [ ] softirqs last enabled at (337082): [<ffffc00080061d90>] handle_softirqs+0x4e0/0x538 [ ] softirqs last disabled at (337073): [<ffffc00080010364>] __do_softirq+0x1c/0x28 [ ] other info that might help us debug this: [ ] Possible unsafe locking scenario: [ ] CPU0 [ ] ---- [ ] lock(&v3d_priv->stats[i].lock); [ ] <Interrupt> [ ] lock(&v3d_priv->stats[i].lock); [ ] *** DEADLOCK *** [ ] no locks held by swapper/0/0. [ ] stack backtrace: [ ] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G WC 6.10.3-v8-16k-numa #159 [ ] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [ ] Call trace: [ ] dump_backtrace+0x170/0x1b8 [ ] show_stack+0x20/0x38 [ ] dump_stack_lvl+0xb4/0xd0 [ ] dump_stack+0x18/0x28 [ ] print_usage_bug+0x3cc/0x3f0 [ ] mark_lock+0x4d0/0x968 [ ] __lock_acquire+0x784/0x18c8 [ ] lock_acquire+0x1f8/0x328 [ ] v3d_job_update_stats+0xec/0x2e0 [v3d] [ ] v3d_irq+0xc8/0x660 [v3d] [ ] __handle_irq_event_percpu+0x1f8/0x488 [ ] handle_irq_event+0x88/0x128 [ ] handle_fasteoi_irq+0x298/0x408 [ ] generic_handle_domain_irq+0x50/0x78 But it is a false positive because all the queue-stats pairs have their own lock and jobs are also one at a time. Nevertheless we can appease lockdep by disabling local interrupts to make it see lock usage is consistent. Cc: Maíra Canal <mcanal@igalia.com> Fixes: 6abe93b621ab ("drm/v3d: Fix race-condition between sysfs/fdinfo and interrupt handler") Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240813102505.80512-2-tursulin@igalia.com
2024-09-16drm/panel: raydium-rm69380: transition to mipi_dsi wrapped functionsTejas Vipin
Changes the raydium-rm69380 panel to use multi style functions for improved error handling. Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Tejas Vipin <tejasvipin76@gmail.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240914034341.897197-1-tejasvipin76@gmail.com
2024-09-16drm/omap: Fix locking in omap_gem_new_dmabuf()Tomi Valkeinen
omap_gem_new_dmabuf() creates the new gem object, and then takes and holds the omap_obj->lock for the rest of the function. This has two issues: - omap_gem_free_object(), which is called in the error paths, also takes the same lock, leading to deadlock - Even if the above wouldn't happen, in the error cases omap_gem_new_dmabuf() still unlocks omap_obj->lock, even after the omap_obj has already been freed. Furthermore, I don't think there's any reason to take the lock at all, as the object was just created and not yet shared with anyone else. To fix all this, drop taking the lock. Fixes: 3cbd0c587b12 ("drm/omap: gem: Replace struct_mutex usage with omap_obj private lock") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/511b99d7-aade-4f92-bd3e-63163a13d617@stanley.mountain/ Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-3-15d31aea0831@ideasonboard.com
2024-09-16drm/omap: Hide sparse warningsTomi Valkeinen
sparse reports: drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:122:16: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:122:16: expected void const volatile [noderef] __iomem *addr drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:122:16: got unsigned int [usertype] *wa_dma_data drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:130:9: warning: incorrect type in argument 2 (different address spaces) drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:130:9: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:130:9: got unsigned int [usertype] *wa_dma_data drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:414:9: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:414:9: expected void const volatile [noderef] __iomem *addr drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:414:9: got unsigned int * These come from pieces of code which do essentially: p = dma_alloc_coherent() dma_transfer_to_p() readl(p) writel(x, p) dma_transfer_from_p() I think we would do just fine without readl() and writel(), accessing the memory without any extras, but ensuring that the necessary barriers are in place. But this code is for a legacy platform, has been working for ages, and it's doing work-arounds for hardware issues, and those hardware issues are very difficult to trigger... So I would just rather leave the code be as it is now. However, the warnings are not nice. Hide the warnings by a (__iomem void *) typecast. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407311737.VsJ0Sr1w-lkp@intel.com/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-2-15d31aea0831@ideasonboard.com
2024-09-16drm/omap: Fix possible NULL dereferenceTomi Valkeinen
smatch reports: drivers/gpu/drm/omapdrm/dss/base.c:176 omapdss_device_disconnect() error: we previously assumed 'src' could be null (see line 169) This code is mostly from a time when omapdrm had its own display device model. I can't honestly remember the details, and I don't think it's worth digging in deeply into that for a legacy driver. However, it looks like we only call omapdss_device_disconnect() and omapdss_device_connect() with NULL as the src parameter. We can thus drop the src parameter from both functions, and fix the smatch warning. I don't think omapdss_device_disconnect() ever gets NULL for the dst parameter (if it did, we'd crash soon after returning from the function), but I have kept the !dst check, just in case, but I added a WARN_ON() there. Also, if the dst parameter can be NULL, we can't always get the struct dss_device pointer from dst->dss (which is only used for a debug print). To make sure we can't hit that issue, do it similarly to the omapdss_device_connect() function: add 'struct dss_device *dss' as the first parameter, so that we always have it regardless of the dst. Fixes: 79107f274b2f ("drm/omap: Add support for drm_bridge") Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240806-omapdrm-misc-fixes-v1-1-15d31aea0831@ideasonboard.com
2024-09-13accel/qaic: Change to use DEFINE_SHOW_ATTRIBUTE macroLonglong Xia
Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code. No functional change. Signed-off-by: Longlong Xia <xialonglong@kylinos.cn> Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240819095816.447096-1-xialonglong@kylinos.cn
2024-09-13drm/ast: Avoid upcasting to struct ast_deviceThomas Zimmermann
Several functions receive an instance of struct drm_device only to upcast it to struct ast_device. Improve type safety by passing the AST device directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-11-tzimmermann@suse.de
2024-09-13drm/ast: Respect return value from CRTC initThomas Zimmermann
Return an error if CRTC initialization fails. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-10-tzimmermann@suse.de
2024-09-13drm/ast: vga: Inline ast_vga_connector_init()Thomas Zimmermann
Inline ast_vga_connector_init() into its only caller. The helper currently only does half of the connector-init work and is trivial enough to be inlined. While at it, remove the error message from the call to ast_ddc_create(). The function already warns on errors. Also set the local variables for encoder and connector as late as possible, so that the compiler warns if we use them before having initialized the instance. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-9-tzimmermann@suse.de
2024-09-13drm/ast: sil164: Inline ast_sil164_connector_init()Thomas Zimmermann
Inline ast_sil164_connector_init() into its only caller. The helper currently only does half of the connector-init work and is trivial enough to be inlined. While at it, remove the error message from the call to ast_ddc_create(). The function already warns on errors. Also set the local variables for encoder and connector as late as possible, so that the compiler warns if we use them before having initialized the instance. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-8-tzimmermann@suse.de
2024-09-13drm/ast: dp501: Avoid upcasting to struct ast_deviceThomas Zimmermann
Several functions receive an instance of struct drm_device only to upcast it to struct ast_device. Improve type safety by passing the AST device directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-7-tzimmermann@suse.de
2024-09-13drm/ast: dp501: Inline ast_dp501_connector_init()Thomas Zimmermann
Inline ast_dp501_connector_init() into its only caller. The helper currently only does half of the connector-init work and is trivial enough to be inlined. Also set the local variables for encoder and connector as late as possible, so that the compiler warns if we use them before having initialized the instance. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-6-tzimmermann@suse.de
2024-09-13drm/ast: astdp: Replace ast_dp_set_on_off()Thomas Zimmermann
Replace ast_dp_set_on_off() with ast_dp_set_enable(). The helper's new name reflects the performed operation. If enabling fails, the new helper prints a warning. The code that waits for the programmed effect to take place is now located in __ast_dp_wait_enable(). Also align the register constants with the rest of the code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-5-tzimmermann@suse.de
2024-09-13drm/ast: astdp: Replace power_on helpersThomas Zimmermann
Replace the helper for controlling power on the physical connector, ast_dp_power_on_off(), with ast_dp_set_phy_sleep(). The new name reflects the effect of the operation. Simplify the implementation. The call now controls sleeping, hence semantics are inversed. Each 'on' becomes an 'off' operation and vice versa. Do the same for ast_dp_power_is_on() and also align naming of the register constant with the rest of the code. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-4-tzimmermann@suse.de
2024-09-13drm/ast: astdp: Avoid upcasting to struct ast_deviceThomas Zimmermann
Several functions receive an instance of struct drm_device only to upcast it to struct ast_device. Improve type safety by passing the AST device directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-3-tzimmermann@suse.de
2024-09-13drm/ast: astdp: Inline ast_astdp_connector_init()Thomas Zimmermann
Inline ast_astdp_connector_init() into its only caller. The helper currently only does half of the connector-init work and is trivial enough to be inlined. Also set the local variables for encoder and connector as late as possible, so that the compiler warns if we use them before having initialized the instance. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240911115347.899148-2-tzimmermann@suse.de
2024-09-13drm/imagination: annotate pvr_fw_version_packed() with __maybe_unusedJani Nikula
Building with clang and W=1 leads to warning about unused pvr_fw_version_packed(). Fix by annotating it with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Reviewed-by: Matt Coster <matt.coster@imgtec.com> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://patchwork.freedesktop.org/patch/msgid/190e4eefef6c5e62052a01af0084c69361e216ef.1725962479.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-13drm/kmb: annotate set_test_mode_src_osc_freq_target_{low, hi}_bits() with ↵Jani Nikula
__maybe_unused Building with clang and and W=1 leads to warning about unused set_test_mode_src_osc_freq_target_low_bits() and set_test_mode_src_osc_freq_target_hi_bits(). Fix by annotating them with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Acked-by: Anitha Chrisanthus <anitha.chrisanthus@intel.com> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://patchwork.freedesktop.org/patch/msgid/29a83771edd9b85032095ed3ecc1e91a77229b90.1725962479.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-13drm/panel: sony-acx565akm: Use %*ph to print small bufferAndy Shevchenko
Use %*ph format to print small buffer as hex string. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240911200125.2886384-1-andriy.shevchenko@linux.intel.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240911200125.2886384-1-andriy.shevchenko@linux.intel.com
2024-09-13drm: panel: nt36523: use devm_mipi_dsi_* function to register and attach dsiJianhua Lu
Switch to devm_mipi_dsi_* function, we don't need to detach and unregister dsi manually any more. Signed-off-by: Jianhua Lu <lujianhua000@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240904142907.367786-1-lujianhua000@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904142907.367786-1-lujianhua000@gmail.com
2024-09-13drm/panel: khadas-ts050: make ts050[v2]_panel_data staticMin-Hua Chen
make ts050_panel_data and ts050v2_panel_data static because they are only used in drivers/gpu/drm/panel/panel-khadas-ts050.c, and fix the following sparse warnings: drivers/gpu/drm/panel/panel-khadas-ts050.c:620:32: sparse: warning: symbol 'ts050_panel_data' was not declared. Should it be static? drivers/gpu/drm/panel/panel-khadas-ts050.c:625:32: sparse: warning: symbol 'ts050v2_panel_data' was not declared. Should it be static? No functional changes intended. Signed-off-by: Min-Hua Chen <minhuadotchen@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240908133533.112894-1-minhuadotchen@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240908133533.112894-1-minhuadotchen@gmail.com
2024-09-13drm/bridge: imx8mp-hdmi-tx: allow 0.5% margin with selected clockDominique Martinet
This allows the hdmi driver to pick e.g. 64.8MHz instead of 65Mhz when we cannot output the exact frequency, enabling the imx8mp HDMI output to support more modes Tested-by: Adam Ford <aford173@gmail.com> #imx8mp-beacon Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240907-hdmi-tolerance-v2-1-b9d7abd89f5c@codewreck.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240907-hdmi-tolerance-v2-1-b9d7abd89f5c@codewreck.org
2024-09-13drm/bridge: imx8qxp-ldb: Switch to RUNTIME_PM_OPS()Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative. The combined usage of pm_ptr() and RUNTIME_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626230704.708234-6-festevam@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626230704.708234-6-festevam@gmail.com
2024-09-13drm/bridge: dw-hdmi-cec: Switch to SYSTEM_SLEEP_PM_OPS()Fabio Estevam
Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS() alternative. The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626230704.708234-5-festevam@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626230704.708234-5-festevam@gmail.com
2024-09-13drm/bridge: samsung-dsim: Switch to RUNTIME_PM_OPS()Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative. The combined usage of pm_ptr() and RUNTIME_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626230704.708234-4-festevam@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626230704.708234-4-festevam@gmail.com
2024-09-13drm/bridge: imx8qxp-pixel-combiner: Switch to RUNTIME_PM_OPS()Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative. The combined usage of pm_ptr() and RUNTIME_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626230704.708234-3-festevam@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626230704.708234-3-festevam@gmail.com
2024-09-13drm/bridge: imx8qm-ldb: Switch to RUNTIME_PM_OPS()Fabio Estevam
Replace SET_RUNTIME_PM_OPS with its modern RUNTIME_PM_OPS() alternative. The combined usage of pm_ptr() and RUNTIME_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626230704.708234-2-festevam@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626230704.708234-2-festevam@gmail.com
2024-09-13drm/bridge: imx8mp-hdmi-tx: Switch to SYSTEM_SLEEP_PM_OPS()Fabio Estevam
Replace SET_SYSTEM_SLEEP_PM_OPS with its modern SYSTEM_SLEEP_PM_OPS() alternative. The combined usage of pm_ptr() and SYSTEM_SLEEP_PM_OPS() allows the compiler to evaluate if the runtime suspend/resume() functions are used at build time or are simply dead code. This allows removing the __maybe_unused notation from the runtime suspend/resume() functions. Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20240626230704.708234-1-festevam@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240626230704.708234-1-festevam@gmail.com
2024-09-13drm/bridge: tc358767: Support write-only registersAlexander Stein
Most registers are read-writable, but some are only RO or even WO. regmap does not support using readable_reg and wr_table when outputting in debugfs, so switch to writeable_reg. First check for RO or WO registers and fallback tc_readable_reg() for the leftover RW registers. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Link: https://lore.kernel.org/r/20240904120546.1845856-4-alexander.stein@ew.tq-group.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904120546.1845856-4-alexander.stein@ew.tq-group.com
2024-09-13drm/bridge: tc358767: Only print GPIO debug output if they actually occurAlexander Stein
Currently the output the following output is printed upon each interrupt: tc358767 1-000f: GPIO0: This spams the kernel log while debugging an IRQ storm from the bridge. Only print the debug output if the GPIO hotplug event actually happened. Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Link: https://lore.kernel.org/r/20240904120546.1845856-3-alexander.stein@ew.tq-group.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904120546.1845856-3-alexander.stein@ew.tq-group.com
2024-09-13drm/bridge: tc358767: Use dev_err_probeAlexander Stein
The function calls preceding these returns can return -EPROBE_DEFER. So use dev_err_probe to add some information to /sys/kernel/debug/devices_deferred Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20240904120546.1845856-2-alexander.stein@ew.tq-group.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904120546.1845856-2-alexander.stein@ew.tq-group.com
2024-09-13drm/bochs: use devm_ioremap_wc() to map framebufferYan Zhao
Opt for devm_ioremap_wc() over devm_ioremap() when mapping the framebuffer. Using devm_ioremap() results in the VA being mapped with PAT=UC-, which considerably slows down drm_fb_memcpy(). In contrast, devm_ioremap_wc() maps the VA with PAT set to WC, leading to better performance on platforms where access to UC memory is much slower than WC memory. Here's the performance data measured in a guest on the physical machine "Sapphire Rapids XCC". With host KVM honors guest PAT memory types, the effective memory type for this framebuffer range is - WC when devm_ioremap_wc() is used - UC- when devm_ioremap() is used. The data presented is an average from 10 execution runs. Cycles: Avg cycles of executed bochs_primary_plane_helper_atomic_update() from VM boot to GDM show up Cnt: Avg cnt of executed bochs_primary_plane_helper_atomic_update() from VM boot to GDM show up T: Avg time of each bochs_primary_plane_helper_atomic_update(). ------------------------------------------------- | | devm_ioremap() | devm_ioremap_wc() | |------------|----------------|-------------------| | Cycles | 211.545M | 0.157M | |------------|----------------|-------------------| | Cnt | 142 | 1917 | |------------|----------------|-------------------| | T | 0.1748s | 0.0004s | ------------------------------------------------- Note: Following the rebase to [3], the previously reported GDM failure on the VGA device [1] can no longer be reproduced, thanks to the memory management improvements made in [2]. Despite this, I have proceeded to submit this patch because of the noticeable performance improvements it provides. Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com> Closes: https://lore.kernel.org/all/87jzfutmfc.fsf@redhat.com/#t Cc: Sean Christopherson <seanjc@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Kevin Tian <kevin.tian@intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Yan Zhao <yan.y.zhao@intel.com> Link: https://lore.kernel.org/all/87jzfutmfc.fsf@redhat.com/#t [1] Link: https://patchwork.freedesktop.org/series/138086 [2] Link: https://gitlab.freedesktop.org/drm/misc/kernel/-/tree/drm-misc-next [3] Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Vitaly Kuznetsov <vkuznets@redhat.com> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240909131643.28915-1-yan.y.zhao@intel.com
2024-09-12drm/panthor: Display FW version informationSteven Price
The version number output when loading the firmware is actually the interface version not the version of the firmware itself. Update the message to make this clearer. However, the firmware binary has a git SHA embedded into it which can be used to identify which firmware binary is being loaded. So output this as a drm_info() so that it's obvious from a dmesg log which firmware binary is being used. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240906094025.638173-1-steven.price@arm.com
2024-09-11drm/bridge: ti-sn65dsi86: annotate ti_sn_pwm_pin_{request, release} with ↵Jani Nikula
__maybe_unused Building with clang, W=1, CONFIG_PM=n and CONFIG_OF_GPIO=n leads to warning about unused ti_sn_pwm_pin_request() and ti_sn_pwm_pin_release(). Fix by annotating them with __maybe_unused. See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static inline functions for W=1 build"). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/136ecd978aedd7df39d1b1c37b70596027ff0a3e.1725962479.git.jani.nikula@intel.com
2024-09-11drm/panel: himax-hx83112a: transition to mipi_dsi wrapped functionsTejas Vipin
Changes the himax-hx83112a panel to use multi style functions for improved error handling. Signed-off-by: Tejas Vipin <tejasvipin76@gmail.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240904141521.554451-1-tejasvipin76@gmail.com
2024-09-11drm/tests: Add test for drm_framebuffer_free()Carlos Eduardo Gallo Filho
Add a single KUnit test case for the drm_framebuffer_free function. Signed-off-by: Carlos Eduardo Gallo Filho <gcarlos@disroot.org> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240911001559.28284-10-gcarlos@disroot.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2024-09-11drm/tests: Add test for drm_framebuffer_init()Carlos Eduardo Gallo Filho
Add three KUnit test cases for the drm_framebuffer_init function: 1. Test if expected values are being set after drm_framebuffer_init() call. 2. Try to init a framebuffer without setting its format. 3. Try calling drm_framebuffer_init() with mismatch of the drm_device passed at the first argument and the one pointed by fb->dev. Signed-off-by: Carlos Eduardo Gallo Filho <gcarlos@disroot.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240911001559.28284-9-gcarlos@disroot.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-30 13:46:35 +0000