summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4
AgeCommit message (Collapse)AuthorFilesLines
2024-12-14drm/vc4: hvs: Set AXI panic modes for the HVSDave Stevenson1-0/+11
[ Upstream commit 014eccc9da7bfc76a3107fceea37dd60f1d63630 ] The HVS can change AXI request mode based on how full the COB FIFOs are. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. With HVS channel 2 now being used for live video, change the panic mode for all channels to be explicitly set by the driver, and the same for all channels. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-7-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14drm/vc4: hdmi: Avoid log spam for audio start failureDom Cobley1-1/+1
[ Upstream commit b4e5646178e86665f5caef2894578600f597098a ] We regularly get dmesg error reports of: [ 18.184066] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19 [ 18.184098] MAI: soc_pcm_open() failed (-19) These are generated for any disconnected hdmi interface when pulseaudio attempts to open the associated ALSA device (numerous times). Each open generates a kernel error message, generating general log spam. The error messages all come from _soc_pcm_ret in sound/soc/soc-pcm.c#L39 which suggests returning ENOTSUPP, rather that ENODEV will be quiet. And indeed it is. Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-5-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14drm/vc4: hvs: Correct logic on stopping an HVS channelDave Stevenson1-5/+3
[ Upstream commit 7ab6512e7942889c0962588355cb92424a690be6 ] When factoring out __vc4_hvs_stop_channel, the logic got inverted from if (condition) // stop channel to if (condition) goto out //stop channel out: and also changed the exact register writes used to stop the channel. Correct the logic so that the channel is actually stopped, and revert to the original register writes. Fixes: 6d01a106b4c8 ("drm/vc4: crtc: Move HVS init and close to a function") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-32-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs functionDave Stevenson2-2/+5
[ Upstream commit d285bb622ebdfaa84f51df3a1abccb87036157ea ] The debugfs function to dump dlists aborted at 256 bytes, when actually the dlist memory is generally significantly larger but varies based on SoC. We already have the correct limit in __vc4_hvs_alloc, so store it for use in the debugfs dlist function. Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-19-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14drm/vc4: hvs: Fix dlist debug not resetting the next entry pointerDave Stevenson1-1/+2
[ Upstream commit 6d5f76e0544b04ec5bdd2a09c19d90aeeb2cd479 ] The debug function to display the dlists didn't reset next_entry_start when starting each display, so resulting in not stopping the list at the correct place. Fixes: c6dac00340fc ("drm/vc4: hvs: Add debugfs node that dumps the current display lists") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-18-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14drm/vc4: hdmi: Avoid hang with debug registers when suspendedDom Cobley1-0/+4
[ Upstream commit 223ee2567a55e4f80315c768d2969e6a3b9fb23d ] Trying to read /sys/kernel/debug/dri/1/hdmi1_regs when the hdmi is disconnected results in a fatal system hang. This is due to the pm suspend code disabling the dvp clock. That is just a gate of the 108MHz clock in DVP_HT_RPI_MISC_CONFIG, which results in accesses hanging AXI bus. Protect against this. Fixes: 25eb441d55d4 ("drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumps") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-17-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-12-14drm/vc4: hvs: Don't write gamma luts on 2711Dave Stevenson1-0/+3
[ Upstream commit 52efe364d1968ee3e3ed45eb44eb924b63635315 ] The gamma block has changed in 2711, therefore writing the lut in vc4_hvs_lut_load is incorrect. Whilst the gamma property isn't created for 2711, it is called from vc4_hvs_init_channel, so abort if attempted. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-15-dave.stevenson@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-10-17drm/vc4: Stop the active perfmon before being destroyedMaíra Canal1-1/+6
commit 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 upstream. Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Cc: stable@vger.kernel.org # v4.17+ Cc: Boris Brezillon <bbrezillon@kernel.org> Cc: Juan A. Suarez Romero <jasuarez@igalia.com> Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Juan A. Suarez <jasuarez@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcanal@igalia.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-10-17drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_getStefan Wahren1-1/+7
[ Upstream commit f1a54e860b1bc8d824925b5a77f510913880e8d6 ] The commit 0f5251339eda ("drm/vc4: hdmi: Make sure the controller is powered in detect") introduced the necessary power management handling to avoid register access while controller is powered down. Unfortunately it just print a warning if pm_runtime_resume_and_get() fails and proceed anyway. This could happen during suspend to idle. So we must assume it is unsafe to access the HDMI register. So bail out properly. Fixes: 0f5251339eda ("drm/vc4: hdmi: Make sure the controller is powered in detect") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Maíra Canal <mcanal@igalia.com> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240821214052.6800-3-wahrenst@gmx.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-06-12drm: vc4: Fix possible null pointer dereferenceAleksandr Mishin1-0/+2
[ Upstream commit c534b63bede6cb987c2946ed4d0b0013a52c5ba7 ] In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240409075622.11783-1-amishin@t-argos.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-13drm/vc4: don't check if plane->state->fb == state->fbMaíra Canal1-4/+1
[ Upstream commit 5ee0d47dcf33efd8950b347dcf4d20bab12a3fa9 ] Currently, when using non-blocking commits, we can see the following kernel warning: [ 110.908514] ------------[ cut here ]------------ [ 110.908529] refcount_t: underflow; use-after-free. [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0 [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32 [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0 [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0 [ 110.909170] sp : ffffffc00913b9c0 [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60 [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480 [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78 [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000 [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004 [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003 [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00 [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572 [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000 [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001 [ 110.909434] Call trace: [ 110.909441] refcount_dec_not_one+0xb8/0xc0 [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4] [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4] [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper] [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4] [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper] [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper] [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm] [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm] [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm] [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm] [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4 [ 110.914873] invoke_syscall+0x4c/0x114 [ 110.914897] el0_svc_common+0xd0/0x118 [ 110.914917] do_el0_svc+0x38/0xd0 [ 110.914936] el0_svc+0x30/0x8c [ 110.914958] el0t_64_sync_handler+0x84/0xf0 [ 110.914979] el0t_64_sync+0x18c/0x190 [ 110.914996] ---[ end trace 0000000000000000 ]--- This happens because, although `prepare_fb` and `cleanup_fb` are perfectly balanced, we cannot guarantee consistency in the check plane->state->fb == state->fb. This means that sometimes we can increase the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The opposite can also be true. In fact, the struct drm_plane .state shouldn't be accessed directly but instead, the `drm_atomic_get_new_plane_state()` helper function should be used. So, we could stick to this check, but using `drm_atomic_get_new_plane_state()`. But actually, this check is not really needed. We can increase and decrease the refcount symmetrically without problems. This is going to make the code more simple and consistent. Signed-off-by: Maíra Canal <mcanal@igalia.com> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240105175908.242000-1-mcanal@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-04-03drm/vc4: hdmi: do not return negative values from .get_modes()Jani Nikula1-1/+1
[ Upstream commit abf493988e380f25242c1023275c68bd3579c9ce ] The .get_modes() hooks aren't supposed to return negative error codes. Return 0 for no modes, whatever the reason. Cc: Maxime Ripard <mripard@kernel.org> Cc: stable@vger.kernel.org Acked-by: Maxime Ripard <mripard@kernel.org> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/dcda6d4003e2c6192987916b35c7304732800e08.1709913674.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-08-30drm/aperture: Remove primary argumentDaniel Vetter1-1/+1
[ Upstream commit 62aeaeaa1b267c5149abee6b45967a5df3feed58 ] Only really pci devices have a business setting this - it's for figuring out whether the legacy vga stuff should be nuked too. And with the preceding two patches those are all using the pci version of this. Which means for all other callers primary == false and we can remove it now. v2: - Reorder to avoid compile fail (Thomas) - Include gma500, which retained it's called to the non-pci version. v4: - fix Daniel's S-o-b address v5: - add back an S-o-b tag with Daniel's Intel address Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Deepak Rawat <drawat.floss@gmail.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: Emma Anholt <emma@anholt.net> Cc: Helge Deller <deller@gmx.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: linux-hyperv@vger.kernel.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-tegra@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230406132109.32050-4-tzimmermann@suse.de Stable-dep-of: 5ae3716cfdcd ("video/aperture: Only remove sysfb on the default vga pci device") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: hdmi: Correct interlaced timings againDave Stevenson1-2/+3
[ Upstream commit 771d6539f27bd55f43d8a95d53a7eeaaffa2681c ] The back porch timings were correct, only the sync offset was wrong. Correct timing is now reported for 1080i and 576i, but the h offset is incorrect for 480i for non-obvious reasons. Fixes: fb10dc451c0f ("drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-14-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: hvs: Fix colour order for xRGB1555 on HVS5Dave Stevenson1-0/+2
[ Upstream commit 902973dc1a049c0d7bf0c222b8f2b3876f01b4a2 ] Same as the xRGB8888 formats, HVS5 has managed to swap the colour channels for the xRGB1555 formats as well. Add the relevant config for pixel_order_hvs5. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-6-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: hvs: Correct interrupt masking bit assignment for HVS5Dave Stevenson2-18/+44
[ Upstream commit 87551ec650bb87d35f1b29bba6a2430896e08da0 ] HVS5 has moved the interrupt enable bits around within the DISPCTRL register, therefore the configuration has to be updated to account for this. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-4-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: hvs: SCALER_DISPBKGND_AUTOHS is only valid on HVS4Dave Stevenson2-4/+7
[ Upstream commit 982ee94486863a41c6af9f2ab3f6681f72bc5c48 ] The bit used for SCALER_DISPBKGND_AUTOHS in SCALER_DISPBKGNDX has been repurposed on HVS5 to configure whether a display can win back-to-back arbitration wins for the COB. This is not desirable, therefore only select this bit on HVS4, and explicitly clear it on HVS5. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-3-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: hvs: Set AXI panic modesDave Stevenson2-0/+17
[ Upstream commit df993fced230daa8452892406f3180c93ebf7e7b ] The HVS can change AXI request mode based on how full the COB FIFOs are. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. With HVS channel 2 now being used for live video, change the panic mode for all channels to be explicitly set by the driver, and the same for all channels. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-hvs-crtc-misc-v1-2-1f8e0770798b@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: drop all currently held locks if deadlock happensMaíra Canal1-1/+10
[ Upstream commit 479d4f0be4237ba33bc9432787aeb62c90e30f95 ] If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock happened in the locking context. This situation should be addressed by dropping all currently held locks and block until the contended lock becomes available. Currently, vc4 is not dealing with the deadlock properly, producing the following output when PROVE_LOCKING is enabled: [ 825.612809] ------------[ cut here ]------------ [ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.613458] Modules linked in: 8021q mrp garp stp llc raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211 btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6 [ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3 [ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper] [ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] [ 825.614829] sp : ffff800008313bf0 [ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000 [ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758 [ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001 [ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3 [ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000 [ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002 [ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800 [ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054 [ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10 [ 825.615219] Call trace: [ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] [ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper] [ 825.616233] process_one_work+0x2b4/0x618 [ 825.616264] worker_thread+0x24c/0x464 [ 825.616288] kthread+0xec/0x110 [ 825.616310] ret_from_fork+0x10/0x20 [ 825.616335] irq event stamp: 7634 [ 825.616349] hardirqs last enabled at (7633): [<ffffcd777831ee90>] _raw_spin_unlock_irq+0x3c/0x78 [ 825.616384] hardirqs last disabled at (7634): [<ffffcd7778315a78>] __schedule+0x134/0x9f0 [ 825.616411] softirqs last enabled at (7630): [<ffffcd7707aacea0>] local_bh_enable+0x4/0x30 [ipv6] [ 825.617019] softirqs last disabled at (7618): [<ffffcd7707aace70>] local_bh_disable+0x4/0x30 [ipv6] [ 825.617586] ---[ end trace 0000000000000000 ]--- Therefore, deal with the deadlock as suggested by [1], using the function drm_modeset_backoff(). [1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reported-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Maíra Canal <mcanal@igalia.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221229194638.178712-1-mcanal@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-03-10drm/vc4: dpi: Fix format mapping for RGB565Dave Stevenson1-1/+1
[ Upstream commit 0870d86eac8a9abd89a0be1b719d5dc5bac936f0 ] The mapping is incorrect for RGB565_1X16 as it should be DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3. Fixes: 08302c35b59d ("drm/vc4: Add DPI driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-7-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-22drm/vc4: Fix YUV plane handling when planes are in different buffersDave Stevenson1-2/+4
commit 6b77b16de75a6efc0870b1fa467209387cbee8f3 upstream. YUV images can either be presented as one allocation with offsets for the different planes, or multiple allocations with 0 offsets. The driver only ever calls drm_fb_[dma|cma]_get_gem_obj with plane index 0, therefore any application using the second approach was incorrectly rendered. Correctly determine the address for each plane, removing the assumption that the base address is the same for each. Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127155708.454704-1-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-22drm/vc4: crtc: Increase setup cost in core clock calculation to handle ↵Dom Cobley1-1/+1
extreme reduced blanking commit 247a631f9c0ffb37ed0786a94cb4c5f2b6fc7ab1 upstream. The formula that determines the core clock requirement based on pixel clock and blanking has been determined experimentally to minimise the clock while supporting all modes we've seen. A new reduced blanking mode (4kp60 at 533MHz rather than the standard 594MHz) has been seen that doesn't produce a high enough clock and results in "flip_done timed out" error. Increase the setup cost in the formula to make this work. The result is a reduced blanking mode increases by up to 7MHz while leaving the standard timing mode untouched Link: https://github.com/raspberrypi/linux/issues/4446 Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230127145558.446123-1-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-02-09drm/vc4: hdmi: make CEC adapter name uniqueHans Verkuil1-1/+2
[ Upstream commit 51128c3f2a7c98055ea1d27e34910dc10977f618 ] The bcm2711 has two HDMI outputs, each with their own CEC adapter. The CEC adapter name has to be unique, but it is currently hardcoded to "vc4" for both outputs. Change this to use the card_name from the variant information in order to make the adapter name unique. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/dcf1db75-d9cc-62cc-fa12-baf1b2b3bf31@xs4all.nl Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01drm/vc4: bo: Fix unused variable warningMaxime Ripard1-1/+0
[ Upstream commit 83a7f8e4899fb4cd77c787a3373f3e82b49a080f ] Commit 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog") removed the only use of the ret variable, but didn't remove the variable itself leading to a unused variable warning. Remove that variable. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 07a2975c65f2 ("drm/vc4: bo: Fix drmm_mutex_init memory hog") Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230113154637.1704116-1-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-02-01drm/vc4: bo: Fix drmm_mutex_init memory hogMaxime Ripard1-3/+2
[ Upstream commit 07a2975c65f2be2e22591d795a9c39b00f95fd11 ] Commit 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") converted, among other functions, vc4_create_object() to use drmm_mutex_init(). However, that function is used to allocate a BO, and therefore the mutex needs to be freed much sooner than when the DRM device is removed from the system. For each buffer allocation we thus end up allocating a small structure as part of the DRM-managed mechanism that is never freed, eventually leading us to no longer having any free memory anymore. Let's switch back to mutex_init/mutex_destroy to deal with it properly. Fixes: 374146cad469 ("drm/vc4: Switch to drmm_mutex_init") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230112091243.490799-1-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-11-10drm/vc4: kms: Fix IS_ERR() vs NULL check for vc4_kmsGaosheng Cui1-4/+4
The drm_atomic_get_new_private_obj_state() function returns NULL on error path, drm_atomic_get_old_private_obj_state() function returns NULL on error path, too, they does not return error pointers. By the way, vc4_hvs_get_new/old_global_state() should return ERR_PTR(-EINVAL), otherwise there will be null-ptr-defer issue, such as follows: In function vc4_atomic_commit_tail(): |-- old_hvs_state = vc4_hvs_get_old_global_state(state); <-- return NULL |-- if (WARN_ON(IS_ERR(old_hvs_state))) <-- no return |-- unsigned long state_rate = max(old_hvs_state->core_clock_rate, new_hvs_state->core_clock_rate); <-- null-ptr-defer Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221110094445.2930509-6-cuigaosheng1@huawei.com
2022-11-07drm/vc4: Fix missing platform_unregister_drivers() call in vc4_drm_register()Yuan Can1-1/+6
A problem about modprobe vc4 failed is triggered with the following log given: [ 420.327987] Error: Driver 'vc4_hvs' is already registered, aborting... [ 420.333904] failed to register platform driver vc4_hvs_driver [vc4]: -16 modprobe: ERROR: could not insert 'vc4': Device or resource busy The reason is that vc4_drm_register() returns platform_driver_register() directly without checking its return value, if platform_driver_register() fails, it returns without unregistering all the vc4 drivers, resulting the vc4 can never be installed later. A simple call graph is shown as below: vc4_drm_register() platform_register_drivers() # all vc4 drivers are registered platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without unregister drivers Fixing this problem by checking the return value of platform_driver_register() and do platform_unregister_drivers() if error happened. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Yuan Can <yuancan@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221103014705.109322-1-yuancan@huawei.com
2022-11-03drm/vc4: hdmi: Fix HSM clock too low on Pi4maxime@cerno.tech2-4/+18
Commit ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") reintroduced the call to clk_set_min_rate in an attempt to fix the boot without a monitor connected on the RaspberryPi3. However, that introduced a regression breaking the display output entirely (black screen but no vblank timeout) on the Pi4. This is due to the fact that we now have in a typical modeset at boot, in vc4_hdmi_encoder_pre_crtc_configure(), we have a first call to clk_set_min_rate() asking for the minimum rate of the HSM clock for our given resolution, and then a call to pm_runtime_resume_and_get(). We will thus execute vc4_hdmi_runtime_resume() which, since the commit mentioned above, will call clk_set_min_rate() a second time with the absolute minimum rate we want to enforce on the HSM clock. We're thus effectively erasing the minimum mandated by the mode we're trying to set. The fact that only the Pi4 is affected is due to the fact that it uses a different clock driver that tries to minimize the HSM clock at all time. It will thus lower the HSM clock rate to 120MHz on the second clk_set_min_rate() call. The Pi3 doesn't use the same driver and will not change the frequency on the second clk_set_min_rate() call since it's still within the new boundaries and it doesn't have the code to minimize the clock rate as needed. So even though the boundaries are still off, the clock rate is still the right one for our given mode, so everything works. There is a lot of moving parts, so I couldn't find any obvious solution: - Reverting the original is not an option, as that would break the Pi3 again. - We can't move the clk_set_min_rate() call in _pre_crtc_configure() since because, on the Pi3, the HSM clock has the CLK_SET_RATE_GATE flag which prevents the clock rate from being changed after it's been enabled. Our calls to clk_set_min_rate() can change it, so they need to be done before clk_prepare_enable(). - We can't remove the call to clk_prepare_enable() from the runtime_resume hook to put it into _pre_crtc_configure() either, since we need that clock to be enabled to access the registers, and we can't count on the fact that the display will be active in all situations (doing any CEC operation, or listing the modes while inactive are valid for example()). - We can't drop the call to clk_set_min_rate() in _pre_crtc_configure() since we would need to still enforce the minimum rate for a given resolution, and runtime_resume doesn't have access to the current mode, if there's any. - We can't copy the TMDS character rate into vc4_hdmi and reuse it since, because it's part of the KMS atomic state, it needs to be protected by a mutex. Unfortunately, some functions (CEC operations, mostly) can be reentrant (through the CEC framework) and still need a pm_runtime_get. However, we can work around this issue by leveraging the fact that the clk_set_min_rate() calls set boundaries for its given struct clk, and that each different clk_get() call will return a different instance of struct clk. The clock framework will then aggregate the boundaries for each struct clk instances linked to a given clock, plus its hardware boundaries, and will use that. We can thus get an extra HSM clock user for runtime_pm use only, and use our different clock instances depending on the context: runtime_pm will use its own to set the absolute minimum clock setup so that we never lock the CPU waiting for a register access, and the modeset part will set its requirement for the current resolution. And we let the CCF do the coordination. It's not an ideal solution, but it's fairly unintrusive and doesn't really change any part of the logic so it looks like a rather safe fix. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2136234 Fixes: ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") Reported-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20221021131339.2203291-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-03drm/vc4: hdmi: Fix outdated function name in commentmaxime@cerno.tech1-3/+2
A comment introduced by commit 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") mentions a drm_atomic_helper_connector_hdmi_reset_link() function that was part of the earlier versions but got moved internally and is now named vc4_hdmi_reset_link(). Let's fix the function name. Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221024093634.118190-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-11-03drm/vc4: hdmi: Take our lock to reset the linkmaxime@cerno.tech1-4/+17
We access some fields protected by our internal mutex in vc4_hdmi_reset_link() (saved_adjusted_mode, output_bpc, output_format) and are calling functions that need to have that lock taken (vc4_hdmi_supports_scrambling()). However, the current code doesn't lock that mutex. Let's make sure it does. Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221024093634.118190-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-10-20Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann22-853/+1513
Backmerging to get v6.1-rc1. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2022-10-13drm/vc4: hdmi: Check the HSM rate at runtime_resumeMaxime Ripard1-0/+20
If our HSM clock has not been properly initialized, any register access will silently lock up the system. Let's check that this can't happen by adding a check for the rate before any register access, and error out otherwise. Link: https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak2et@pengutronix.de/ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-2-cd22e962296c@cerno.tech
2022-10-13drm/vc4: hdmi: Enforce the minimum rate at runtime_resumeMaxime Ripard1-0/+9
This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock rate initialization"), with the code slightly moved around. It turns out that we can't downright remove that code from the driver, since the Pi0-3 and Pi4 are in different cases, and it only works for the Pi4. Indeed, the commit mentioned above was relying on the RaspberryPi firmware clocks driver to initialize the rate if it wasn't done by the firmware. However, the Pi0-3 are using the clk-bcm2835 clock driver that wasn't doing this initialization. We therefore end up with the clock not being assigned a rate, and the CPU stalling when trying to access a register. We can't move that initialization in the clk-bcm2835 driver, since the HSM clock we depend on is actually part of the HDMI power domain, so any rate setup is only valid when the power domain is enabled. Thus, we reinstated the minimum rate setup at runtime_suspend, which should address both issues. Link: https://lore.kernel.org/dri-devel/20220922145448.w3xfywkn5ecak2et@pengutronix.de/ Fixes: fd5894fa2413 ("drm/vc4: hdmi: Remove clock rate initialization") Reported-by: Marc Kleine-Budde <mkl@pengutronix.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-1-cd22e962296c@cerno.tech
2022-10-13drm/vc4: Add module dependency on hdmi-codecMaxime Ripard1-0/+1
The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver will register a device matching the HDMI codec driver, and then register an ASoC card using that codec. However, if vc4 is compiled as a module, chances are that the hdmi-codec driver will be too. In such a case, the module loader will have a very narrow window to load the module between the device registration and the card registration. If it fails to load the module in time, the card registration will fail with EPROBE_DEFER, and we'll abort the audio initialisation, unregistering the HDMI codec device in the process. The next time the bind callback will be run, it's likely that we end up missing that window again, effectively preventing vc4 to probe entirely. In order to prevent this, we can create a soft dependency of the vc4 driver on the HDMI codec one so that we're sure the HDMI codec will be loaded before the VC4 module is, and thus we'll never end up in the previous situation. Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220902144111.3424560-1-maxime@cerno.tech
2022-09-14Merge drm/drm-next into drm-misc-nextMaxime Ripard1-0/+1
We need 6.0-rc1 to merge the backlight rework PR. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-09-13drm/vc4: hdmi: Reset link on hotplugMaxime Ripard1-3/+101
During a hotplug cycle (such as a TV going out of suspend, or when the cable is disconnected and reconnected), the expectation is that the same state used before the disconnection is reused until the next commit. However, the HDMI scrambling requires that some flags are set in the monitor, and those flags are very likely to be reset when the cable has been disconnected. This will thus result in a blank display, even if the display pipeline configuration hasn't been modified or is in the exact same state. The solution we've had so far is to enable the scrambling-related bits again on reconnection, but the HDMI 2.0 specification (Section 6.1.3.1 - Scrambling Control) requires that the scrambling enable bit is set before sending any scrambled video signal. Using that solution thus breaks that expectation. The solution used by i915 is to do a full modeset on the connector so that we disable the video signal, enable the scrambling bit, and enable the video signal again. As such, we took that code and plugged it into vc4. It probably could have been turned into an helper, but it proved to be difficult for several reasons: * i915 has fairly different structures than simpler KMS drivers such as vc4, so doing some code that works with both proved to be difficult; * Other simpler drivers could reuse some of it (tegra, dw-hdmi), but it would still require to move some parameters currently stored in private structure that are needed to compute whether the scrambling is needed or not, and then inform the driver that it needs to be enabled. Some of those parameters are already in core structures (drm_display_mode, drm_display_info, bpc), but the output format isnt't. Adding it is fairly challenging since unlike the TMDS char rate or mode, there's no consensus on what format to pick in drivers, so it's not possible to write some generic code that can depend on it. For these reasons, we chose to duplicate the code for now, until someone else really needs it as well, in which case we will be able to convert it into a generic helper. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-8-maxime@cerno.tech
2022-09-13drm/vc4: hdmi: Move vc4_hdmi_supports_scrambling() aroundMaxime Ripard1-17/+17
We'll need it earlier in the driver, so let's move it next to the other scrambling-related helpers. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-7-maxime@cerno.tech
2022-09-13drm/vc4: hdmi: Switch to detect_ctxMaxime Ripard1-3/+4
We'll need the locking context in future patch, so let's convert .detect to .detect_ctx. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-6-maxime@cerno.tech
2022-09-13drm/vc4: hdmi: Simplify the hotplug handlingMaxime Ripard1-22/+41
Our detect callback has a bunch of operations to perform depending on the current and last status of the connector, such a setting the CEC physical address or enabling the scrambling again. This is currently dealt with a bunch of if / else statetements that make it fairly difficult to read and extend. Let's move all that logic to a function of its own. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-5-maxime@cerno.tech
2022-09-13drm/vc4: hdmi: Remove mutex in detectMaxime Ripard2-64/+34
We recently introduced a new mutex to protect concurrent execution of ALSA and KMS hooks, and the concurrent access to some of vc4_hdmi fields. However, using it in the detect hook was creating a reentrency issue with CEC code. Indeed, calling cec_s_phys_addr_from_edid from detect might call the CEC adap_enable hook with the lock held, eventually resulting in a deadlock. Since we didn't really need to protect anything at the moment in the CEC code, the decision was made to ignore the mutex in those CEC hooks, working around the issue. However, we can have the same thing happening if we end up triggering a mode set from the detect callback, for example using drm_atomic_helper_connector_hdmi_reset_link(). Since we don't really need to protect anything in detect either, let's just drop the lock in detect, and add it again in CEC. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-4-maxime@cerno.tech
2022-09-13drm/vc4: hdmi: Remove unused argument in vc4_hdmi_supports_scramblingMaxime Ripard1-3/+2
Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it never uses it. Let's remove it. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-3-maxime@cerno.tech
2022-09-13drm/vc4: hdmi: Constify drm_display_modeMaxime Ripard2-9/+9
We don't modify the drm_display_mode pointer we have in the driver in most places, so let's make them const. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220829134731.213478-2-maxime@cerno.tech
2022-09-11Merge tag 'drm-misc-next-2022-09-09' of ↵Dave Airlie5-98/+101
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.1-rc1: [airlied - fix sun4i_tv build] UAPI Changes: - Hide unregistered connectors from GETCONNECTOR ioctl. - drm/virtio no longer advertises LINEAR modifier, as it doesn't work. - Cross-subsystem Changes: - Fix GPF in udmabuf failure path. Core Changes: - Rework TTM placement to use intersect/compatible functions. - Drop legacy DP-MST support. - More DP-MST related fixes, and move all state into atomic. - Make DRM_MIPI_DBI select DRM_KMS_HELPER. - Add audio_infoframe packing for DP. - Add logging when some atomic check functions fail. - Assorted documentation updates and fixes. Driver Changes: - Assorted cleanups and fixes in msm, lcdif, nouveau, virtio, panel/ilitek, bridge/icn6211, tve200, gma500, bridge/*, panfrost, via, bochs, qxl, sun4i. - Add add AUO B133UAN02.1, IVO M133NW4J-R3, Innolux N120ACA-EA1 eDP panels. - Improve DP-MST modeset state handling in amdgpu, nouveau, i915. - Drop DP-MST from radeon driver, it was broken and only user of legacy DP-MST. - Handle unplugging better in vc4. - Simplify drm cmdparser tests. - Add DP support to ti-sn65dsi86. - Add MT8195 DP support to mediatek. - Support RGB565, XRGB64, and ARGB64 formats in vkms. - Convert sun4i tv support to atomic. - Refactor vc4/vec TV Modesetting, and fix timings. - Use atomic helpers instead of simple display helpers in ssd130x. Maintainer changes: - Add Douglas Anderson as reviewer for panel-edp. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a489485b-3ebc-c734-0f80-aed963d89efe@linux.intel.com
2022-09-07drm/vc4: vec: Fix timings for VEC modesMateusz Kwiatkowski1-2/+2
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-28-459522d653a7@cerno.tech
2022-09-07drm/vc4: vec: Remove redundant atomic_mode_setMateusz Kwiatkowski1-14/+4
Let's remove the superfluous tv_mode field, which was redundant with the mode field in struct drm_tv_connector_state. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-27-459522d653a7@cerno.tech
2022-09-07drm/vc4: vec: Refactor VEC TV mode settingMateusz Kwiatkowski1-65/+23
Change the mode_set function pointer logic to declarative config0, config1 and custom_freq fields, to make TV mode setting logic more concise and uniform. Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> [Maxime: Fixed != 0 check, added tv_mode variable] Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-26-459522d653a7@cerno.tech
2022-09-07drm/vc4: vec: Convert to atomic helpersMaxime Ripard1-4/+6
The VC4 VEC driver still uses legacy enable and disable hook implementation. Let's convert to the atomic variants. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-25-459522d653a7@cerno.tech
2022-09-07drm/vc4: vec: Remove empty mode_fixupMaxime Ripard1-9/+0
The mode_fixup hooks are deprecated, and the behaviour we implement is the default one anyway. Let's remove it. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-24-459522d653a7@cerno.tech
2022-09-06Merge tag 'drm-misc-next-2022-08-20-1' of ↵Daniel Vetter22-690/+1260
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.1: UAPI Changes: Cross-subsystem Changes: - DMA-buf: documentation updates. - Assorted small fixes to vga16fb - Fix fbdev drivers to use the aperture helpers. - Make removal of conflicting drivers work correctly without fbdev enabled. Core Changes: - bridge, scheduler, dp-mst: Assorted small fixes. - Add more format helpers to fourcc, and use it to replace the cpp usage. - Add DRM_FORMAT_Cxx, DRM_FORMAT_Rxx (single channel), and DRM_FORMAT_Dxx ("darkness", inverted single channel) - Add packed AYUV8888 and XYUV8888 formats. - Assorted documentation updates. - Rename ttm_bo_init to ttm_bo_init_validate. - Allow TTM bo's to exist without backing store. - Convert drm selftests to kunit. - Add managed init functions for (panel) bridge, crtc, encoder and connector. - Fix endianness handling in various format conversion helpers. - Make tests pass on big-endian platforms, and add test for rgb888 -> rgb565 - Move DRM_PLANE_HELPER_NO_SCALING to atomic helpers and rename, so drm_plane_helper is no longer needed in most drivers. - Use idr_init_base instead of idr_init. - Rename FB and GEM CMA helpers to DMA helpers. - Rework XRGB8888 related conversion helpers, and add drm_fb_blit() that takes a iosys_map. Make drm_fb_memcpy take an iosys_map too. - Move edid luminance calculation to core, and use it in i915. Driver Changes: - bridge/{adv7511,ti-sn65dsi86,parade-ps8640}, panel/{simple,nt35510,tc358767}, nouveau, sun4i, mipi-dsi, mgag200, bochs, arm, komeda, vmwgfx, pl111: Assorted small fixes and doc updates. - vc4: Rework hdmi power up, and depend on PM. - panel/simple: Add Samsung LTL101AL01. - ingenic: Add JZ4760(B) support, avoid a modeset when sharpness property is unchanged, and use the new PM ops. - Revert some amdgpu commits that cause garbaged graphics when starting X, and reapply them with the real problem fixed. - Completely rework vc4 init to use managed helpers. - Rename via_drv to via_dri1, and move all stuff there only used by the dri1 implementation in preperation for atomic modeset. - Use regmap bulk write in ssd130x. - Power sequence and clock updates to it6505. - Split panel-sitrox-st7701 init sequence and rework mode programming code. - virtio: Improve error and edge conditions handling, and convert to use managed helpers. - Add Samsung LTL101AL01, B120XAN01.0, R140NWF5 RH, DMT028VGHMCMI-1A T, panels. - Add generic fbdev support to komeda. - Split mgag200 modeset handling to make it more model-specific. - Convert simpledrm to use atomic helpers. - Improve udl suspend/disconnect handling. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f0c71766-61e8-19b7-763a-5fbcdefc633d@linux.intel.com
2022-08-25drm/vc4: hvs: protect drm_print_regset32()Danilo Krummrich1-2/+2
In vc4_hvs_dump_state() potentially freed resources are protected from being accessed with drm_dev_enter()/drm_dev_exit(). Also include drm_print_regset32() in the protected section, since drm_print_regset32() does access memory that is typically mapped via devm_* calls. Fixes: 969cfae1f01d ("drm/vc4: hvs: Protect device resources after removal") Signed-off-by: Danilo Krummrich <dakr@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220824161327.330627-5-dakr@redhat.com
generated by cgit v1.2.3 (git 2.39.0) at 2026-04-23 17:42:55 +0300