HDMI support for modes that require the scrambler (4k @ 60Hz, most importantly) #4302

Signed-off-by: Maxime Ripard <[email protected]>

The current code does a binary OR on the possible_crtcs variable of the TXP encoder, while we want to set it to that value instead. Cc: <[email protected]> # v5.9+ Fixes: 39fcb28 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

The vc4_set_crtc_possible_masks is meant to run over all the encoders and then set their possible_crtcs mask to their associated pixelvalve. However, since the commit 39fcb28 ("drm/vc4: txp: Turn the TXP into a CRTC of its own"), the TXP has been turned to a CRTC and encoder of its own, and while it does indeed register an encoder, it no longer has an associated pixelvalve. The code will thus run over the TXP encoder and set a bogus possible_crtcs mask, overriding the one set in the TXP bind function. In order to fix this, let's skip any virtual encoder. Cc: <[email protected]> # v5.9+ Fixes: 39fcb28 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

Due to a FIFO that cannot be flushed between the pixelvalve and the HDMI controllers on BCM2711, we need to carefully disable both at boot time if they were left enabled by the firmware. However, at the time we're running that code, the struct drm_connector encoder pointer isn't set yet, and thus we cannot retrieve the encoder associated to our CRTC. We can however make use of the fact that we have a less flexible setup than what DRM allows where we have a 1:1 relationship between our CRTCs and encoders (and connectors), and thus store the crtc associated to our encoder at boot time. We cannot do that at the time the encoders are probed though, since the CRTCs won't be probed yet and thus we don't know at that time which CRTC index we're going to get, so let's do this in two passes: we can first bind all the components and then once they all are bound, we can iterate over all the encoders to find their associated CRTC and set the pointer. This is similar to what we're doing to set the possible_crtcs field. Fixes: 875a4d5 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard <[email protected]>

Since we fixed the hooks to disable the encoder at boot, we now have an unbalanced clk_disable call at boot since we never enabled them in the first place. Let's mimic the state of the hardware and enable the clocks at boot if the controller is enabled to get the use-count right. Cc: <[email protected]> # v5.10+ Fixes: 09c4381 ("drm/vc4: hdmi: Implement finer-grained hooks") Signed-off-by: Maxime Ripard <[email protected]>

We'll need to have the HVS binding before the HDMI controllers so that we can check whether the firmware allows to run in 4kp60. Reorder a bit the component list, and document the current constraints we're aware of. Acked-by: Dave Stevenson <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

The BVB clock rate computation doesn't take into account a mode clock of 594MHz that we're going to need to support 4k60. Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

In order to reach the frequencies needed to output at 594MHz, the firmware needs to be configured with the appropriate parameters in the config.txt file (enable_hdmi_4kp60 and force_turbo). Let's detect it at bind time, warn the user if we can't, and filter out the relevant modes. Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

The HDMI controller on the BCM2711 includes a scrambler in order to reach the HDMI 2.0 modes that require it. Let's add the support for it. Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

Now that we have the infrastructure in place, we can raise the maximum pixel rate we can reach for HDMI0 on the BCM2711. HDMI1 is left untouched since its pixelvalve has a smaller FIFO and would need a clock faster than what we can provide to support the same modes. Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Dave Stevenson <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

HDMI support for modes that require the scrambler (4k @ 60Hz, most importantly) #4302

HDMI support for modes that require the scrambler (4k @ 60Hz, most importantly) #4302

Commits on Apr 21, 2021