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

drm/vc4: change vc4_dma_range_matches from a global to static

2022-08-17T12:42:36Z

commit 63569d90863ff26c8b10c8971d1271c17a45224b upstream. sparse reports drivers/gpu/drm/vc4/vc4_drv.c:270:27: warning: symbol 'vc4_dma_range_matches' was not declared. Should it be static? vc4_dma_range_matches is only used in vc4_drv.c, so it's storage class specifier should be static. Fixes: da8e393e23ef ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component") Signed-off-by: Tom Rix Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220629200101.498138-1-trix@redhat.com Signed-off-by: Greg Kroah-Hartman

drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component

2022-08-17T12:42:21Z

[ Upstream commit da8e393e23efb60eba8959856c7df88f9859f6eb ] vc4_drv isn't necessarily under the /soc node in DT as it is a virtual device, but it is the one that does the allocations. The DMA addresses are consumed by primarily the HVS or V3D, and those require VideoCore cache alias address mapping, and so will be under /soc. During probe find the a suitable device node for HVS or V3D, and adopt the DMA configuration of that node. Cc: Signed-off-by: Dave Stevenson Link: https://lore.kernel.org/r/20220613144800.326124-2-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

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

2022-08-17T12:40:57Z

[ 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-17T12:40:56Z

[ 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: Fix timings for interlaced modes

2022-08-17T12:40:56Z

[ 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-17T12:40:56Z

[ 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-17T12:40:56Z

[ 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-17T12:40:56Z

[ 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

drm/vc4: hdmi: Avoid full hdmi audio fifo writes

2022-08-17T12:40:56Z

[ Upstream commit 1c594eeccf92368177c2e22f1d3ee4933dfb8567 ] We are getting occasional VC4_HD_MAI_CTL_ERRORF in HDMI_MAI_CTL which seem to correspond with audio dropouts. Reduce the threshold where we deassert DREQ to avoid the fifo overfilling Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Dom Cobley Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

drm/vc4: hdmi: Clear unused infoframe packet RAM registers

2022-08-17T12:40:56Z

[ Upstream commit b6079d1578dc4b4b8050d613a5449a63def7d1dd ] Using a hdmi analyser the bytes in packet ram registers beyond the length were visible in the infoframes and it flagged the checksum as invalid. Zeroing unused words of packet RAM avoids this Fixes: 21317b3fba54 ("drm/vc4: Set up the AVI and SPD infoframes.") Signed-off-by: Dom Cobley Link: https://lore.kernel.org/r/20220613144800.326124-20-maxime@cerno.tech Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin