kernel.git/drivers/gpu/drm/vc4, branch linux-5.19.y

drm/vc4: vec: Fix timings for VEC modes

2022-10-24T07:58:18Z

[ Upstream commit 30d7565be96b3946c18a1ce3fd538f7946839092 ] 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 Acked-by: Noralf Trønnes Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-28-459522d653a7@cerno.tech Signed-off-by: Sasha Levin

drm/vc4: hdmi: Depends on CONFIG_PM

2022-09-05T08:31:26Z

commit 72e2329e7c9bbe15e7a813670497ec9c6f919af3 upstream. We already depend on runtime PM to get the power domains and clocks for most of the devices supported by the vc4 driver, so let's just select it to make sure it's there. Link: https://lore.kernel.org/r/20220629123510.1915022-38-maxime@cerno.tech Acked-by: Thomas Zimmermann Tested-by: Stefan Wahren Signed-off-by: Maxime Ripard (cherry picked from commit f1bc386b319e93e56453ae27e9e83817bb1f6f95) Signed-off-by: Maxime Ripard Cc: "Sudip Mukherjee (Codethink)" Signed-off-by: Greg Kroah-Hartman

drm/vc4: hdmi: Rework power up

2022-09-05T08:31:26Z

commit 258e483a4d5e97a6a8caa74381ddc1f395ac1c71 upstream. The current code tries to handle the case where CONFIG_PM isn't selected by first calling our runtime_resume implementation and then properly report the power state to the runtime_pm core. This allows to have a functionning device even if pm_runtime_get_* functions are nops. However, the device power state if CONFIG_PM is enabled is RPM_SUSPENDED, and thus our vc4_hdmi_write() and vc4_hdmi_read() calls in the runtime_pm hooks will now report a warning since the device might not be properly powered. Even more so, we need CONFIG_PM enabled since the previous RaspberryPi have a power domain that needs to be powered up for the HDMI controller to be usable. The previous patch has created a dependency on CONFIG_PM, now we can just assume it's there and only call pm_runtime_resume_and_get() to make sure our device is powered in bind. Link: https://lore.kernel.org/r/20220629123510.1915022-39-maxime@cerno.tech Acked-by: Thomas Zimmermann Tested-by: Stefan Wahren Signed-off-by: Maxime Ripard (cherry picked from commit 53565c28e6af2cef6bbf438c34250135e3564459) Signed-off-by: Maxime Ripard Cc: "Sudip Mukherjee (Codethink)" Signed-off-by: Greg Kroah-Hartman

drm/vc4: hdmi: Move pixel doubling from Pixelvalve to HDMI block

2022-08-17T13:14:38Z

[ Upstream commit 3650062e4281ab28a6f8c9d59606d0a6266be736 ] With the change to 2 pixels/clock, the pixel doubling in the PV results in doubling each pair of pixels, ie ABABCDCD instead of AABBCCDD. Move the pixel doubling to the HDMI block, however this means that DBLCLK modes now fall foul of requiring even values for all the horizontal timing parameters. As both 480i and 576i fail this, attempt to fix up DBLCLK modes that have odd timings values. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson Link: https://lore.kernel.org/r/20220613144800.326124-34-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes

2022-08-17T13:14:38Z

[ Upstream commit fb10dc451c0f15e3c19798a2f41d357f3f7576f5 ] For interlaced modes the timings were not being correctly programmed into the HDMI block, so correct them. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson Link: https://lore.kernel.org/r/20220613144800.326124-33-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Force modeset when bpc or format changes

2022-08-17T13:14:38Z

[ Upstream commit c94cd0620a922156c9ff9af9c3301b174b287677 ] Whenever the maximum BPC is changed, vc4_hdmi_encoder_compute_config() might pick up a different BPC or format depending on the display capabilities. That change will have a number of side effects, including the clock rates and whether the scrambling is enabled. However, only drm_crtc_state.connectors_changed will be set to true, since that properly only affects the connector. This means that while drm_atomic_crtc_needs_modeset() will return true, and thus drm_atomic_helper_commit_modeset_enables() will call our encoder atomic_enable() hook, mode_changed will be false. So crtc_set_mode() will not call our encoder .atomic_mode_set() hook. We use this hook in vc4 to set the vc4_hdmi_connector_state.output_bpc (and output_format), and will then reuse the value in .atomic_enable() to select whether or not scrambling should be enabled. However, since our clock rate is pre-computed during .atomic_check(), we end up with the clocks properly configured, but the scrambling disabled, leading to a blank screen. Let's set mode_changed to true in our HDMI driver to force the update of output_bpc, and thus prevent the issue entirely. Fixes: ba8c0faebbb0 ("drm/vc4: hdmi: Enable 10/12 bpc output") Signed-off-by: Dom Cobley Link: https://lore.kernel.org/r/20220613144800.326124-32-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Fix timings for interlaced modes

2022-08-17T13:14:38Z

[ Upstream commit 0ee5a40152b15f200ed3a0d51e8aa782ea979c6a ] Increase the number of post-sync blanking lines on odd fields instead of decreasing it on even fields. This makes the total number of lines properly match the modelines. Additionally fix the value of PV_VCONTROL_ODD_DELAY, which did not take pixels_per_clock into account, causing some displays to invert the fields when driven by bcm2711. Fixes: 682e62c45406 ("drm/vc4: Fix support for interlaced modes on HDMI.") Signed-off-by: Mateusz Kwiatkowski Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Move HDMI reset to pm_resume

2022-08-17T13:14:38Z

[ Upstream commit 467e30171b5b483922b1c24c573fa50787207cb6 ] The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain attached to the HDMI block, handled in Linux through runtime_pm. That power domain is shared with the VEC block, so even if we put our runtime_pm reference in the HDMI driver it would keep being on. If the VEC is disabled though, the power domain would be disabled and we would lose any initialization done in our bind implementation. That initialization involves calling the reset function and initializing the CEC registers. Let's move the initialization to our runtime_resume implementation so that we initialize everything properly if we ever need to. Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Signed-off-by: Dave Stevenson Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Switch to pm_runtime_status_suspended

2022-08-17T13:14:37Z

[ Upstream commit fcef97e70094a33ded73b3eb9bef06698c6e9c12 ] If the controller isn't clocked or its domain powered up, the register accesses will either stall the CPU or return garbage, respectively. Thus, we had a warning in our register access function to complain when that kind of risky accesses were performed. In order to check the runtime_pm power state, we were using pm_runtime_active(), but it turns out that it will become active only once the runtime_resume hook has been executed. This prevents us from doing any WARN-free register access in our runtime_resume() implementation, while this is valid. Let's switch to pm_runtime_status_suspended() instead. Fixes: 14e193b95604 ("drm/vc4: hdmi: Warn if we access the controller while disabled") Signed-off-by: Dave Stevenson Link: https://lore.kernel.org/r/20220613144800.326124-23-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Reset HDMI MISC_CONTROL register

2022-08-17T13:14:37Z

[ Upstream commit 35dc00c12a72700a9c4592afee7d136ecb280cbd ] The HDMI block can repeat pixels for double clocked modes, and the firmware is now configuring the block to do this as the PV is doing it incorrectly when at 2pixels/clock. If the kernel doesn't reset it then we end up with strange modes. Reset MISC_CONTROL. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin