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: ba8c0fae ("drm/vc4: hdmi: Enable 10/12 bpc output")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-32-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

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: 682e62c4 ("drm/vc4: Fix support for interlaced modes on HDMI.")
Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

Our HDMI controllers supports Stereo output so let's enable it.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-30-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The MISC_CONTROL register allows configuration of pixel repetition
for pixel doubling in the HDMI block instead of PixelValve.
It was already defined for vc5, so add it for vc4.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-29-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The block can detect what the incoming image timings are for
debug purposes. Add them to the list of registers understood
by the driver to allow easy dumping of the values.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-28-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

This bit ensures data island packets are never generated when disallowed
by HDCP. As no Pi boards support HDCP this is providing an unnecessary
restriction
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-27-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

This path actually occurs when audio is started during a hdmi mode set.
As the data will be written by vc4_hdmi_set_infoframes when packet RAM
is enabled again, don't treat as an error
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-26-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The current HDMI driver, in vc4_hdmi_audio_can_stream() checks whether
the display output is enabled.

This has been there in one form or the other since the introduction of
the audio support in the VC4 HDMI driver in commit bb7d7856
("drm/vc4: Add HDMI audio support"), but no justification for this check
is in the commit message, or in the discussions around the patches.

One can only assume this was done to prevent a user from playing audio
on the ALSA soundcard when the monitor doesn't support it.

However, this is causing some issues. Indeed, Kodi, for example, was
hitting some errors if it was streaming audio during a modeset. With the
theory above, it does make sense, but the display and audio threads are
typically completely different processes with no opportunity to
synchronise which makes it hard to workaround.

Removing that check also doesn't seem to cause any trouble, so let's
just remove it.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-25-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

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: c86b4121 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

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: 14e193b9 ("drm/vc4: hdmi: Warn if we access the controller while disabled")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-23-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

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: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

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: bb7d7856 ("drm/vc4: Add HDMI audio support")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

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: 21317b3f ("drm/vc4: Set up the AVI and SPD infoframes.")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-20-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The vc5 HDMI registers hadn't been added into the debugfs
register sets, therefore weren't dumped on request.
Add them in.

Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-19-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The dmas property is used to hold the dmaengine channel used for audio
output.

Older device trees were missing that property, so if it's not there we
disable the audio output entirely.

However, some overlays have set an empty value to that property, mostly
to workaround the fact that overlays cannot remove a property. Let's add
a test for that case and if it's empty, let's disable it as well.

Cc: <stable@vger.kernel.org>
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

vc4_dsi_encoder_disable is partially an open coded version of
drm_bridge_chain_disable, but it missed a termination condition
in the loop for ->disable which meant that no post_disable
calls were made.

Add in the termination clause.

Fixes: 033bfe75 ("drm/vc4: dsi: Fix bridge chain handling")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-17-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

DSI0 seemingly had very little or no testing as a load of
the register mappings were incorrect/missing, so host
transfers always timed out due to enabling/checking incorrect
bits in the interrupt enable and status registers.

Fixes: 4078f575 ("drm/vc4: Add DSI driver")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-16-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

vc4_dsi was registering both dsi0 and dsi1 as VC4_ENCODER_TYPE_DSI1
which seemed to work OK for a single DSI display, but fails
if there are two DSI displays connected.

Update to register the correct type.

Fixes: 4078f575 ("drm/vc4: Add DSI driver")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-15-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

For slightly unknown reasons, dsi0 takes a different pixel format
to dsi1, and that has to be set in the pixel valve.

Amend the setup accordingly.

Fixes: a86773d1 ("drm/vc4: Add support for feeding DSI encoders from the pixel valve.")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-14-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The divider calculations tried to find the divider just faster than the
clock requested. However if it required a divider of 7 then the for loop
aborted without handling the "error" case, and could end up with a clock
lower than requested.

The integer divider from parent PLL to DSI clock is also capable of
going up to /255, not just /7 that the driver was trying.  This allows
for slower link frequencies on the DSI bus where the resolution permits.

Correct the loop so that we always have a clock greater than requested,
and covering the whole range of dividers.

Fixes: 86c1b9ef ("drm/vc4: Adjust modes in DSI to work around the integer PLL divider.")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-13-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

On Pi0-3 the driver allocates a buffer and requests a DMA channel
because the ARM can't write to DSI1's registers directly.

However, we never release that buffer or channel. Let's add a
device-managed action to release each.

Fixes: 4078f575 ("drm/vc4: Add DSI driver")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-12-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

In a couple of error/incomplete configuration cases, the
DPI_FORMAT bits wouldn't get set.

Enforce our RGB888 default in all these cases.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-11-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

DRM provides flags for inverting pixel clock and output enable
signals, but these were not mapped to the relevant registers.

Add those mappings.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-10-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The hardware can combine H&V syncs onto the output enable line
as composite syncs, so add the relevant configuration to do that.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-9-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

This allows easy analysis of display lists when debugging.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-8-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

Move from only supporting the default of pre-multiplied
alpha to supporting user specified blend mode using the
standardised property.
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-7-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The current plane margin calculation code clips the right and bottom
edges of the range based using the left and top margins.

This is obviously wrong, so let's fix it.

Fixes: 666e7358 ("drm/vc4: Take margin setup into account when updating planes")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-6-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

There is little harm in ignoring fractional coordinates
(they just get truncated).

Without this:
modetest -M vc4 -F tiles,gradient -s 32:1920x1080-60 -P89@74:1920x1080*.1.1@XR24

is rejected. We have the same issue in Kodi when trying to
use zoom options on video.

Note: even if all coordinates are fully integer. e.g.
src:[0,0,1920,1080] dest:[-10,-10,1940,1100]

it will still get rejected as drm_atomic_helper_check_plane_state
uses drm_rect_clip_scaled which transforms this to fractional src coords

Fixes: 21af94cf ("drm/vc4: Add support for scaling of display planes.")
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-5-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The core clock computation takes into account both the load due to the
input (ie, planes) and its output (ie, encoders).

However, while the input load needs to consider all the planes, and thus
sum all of their associated loads, the output happens mostly in
parallel.

Therefore, we need to consider only the maximum of all the output loads,
and not the sum like we were doing. This resulted in a clock rate way
too high which could be discarded for being too high by the clock
framework.

Since recent changes, the clock framework will even downright reject it,
leading to a core clock being too low for its current needs.

Fixes: 16e10105 ("drm/vc4: Increase the core clock based on HVS load")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-4-maxime@cerno.tech

We currently ignore the clk_set_min_rate return code assuming it would
succeed. However, it can fail if we ask for a rate higher than the
current maximum for example.

Since we can't fail in atomic_commit, at least warn on failure.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-3-maxime@cerno.tech

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: <stable@vger.kernel.org>
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-2-maxime@cerno.techSigned-off-by: Maxime Ripard <maxime@cerno.tech>

The driver expects the pitch of the Intel CCS CC color planes to be
64 bytes aligned, adjust the modifier descriptions accordingly.

Cc: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com

Replace apprpriately with appropriately.

Fixes: 1e4d84c6 ("drm/doc: Polish plane composition property docs")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Simon Ser <contact@emersion.fr>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Simon Ser <contact@emersion.fr>
Reviewed-by: Simon Ser <contact@emersion.fr>
Link: https://patchwork.freedesktop.org/patch/msgid/20220628003407.77765-1-marex@denx.de

The latest hardware version (0x40100) supports a hardware threshold
register (aka FUTR) to trigger a fifo underrun interrupt.
A software threshold has been implemented for other hardware versions.
The threshold is set to 128 by default.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603134654.594373-1-yannick.fertre@foss.st.com

Support of vertical & horizontal mirroring features thanks to
the plane rotation property.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603134547.593790-1-yannick.fertre@foss.st.com

Zpos property is immutable for all hardware versions except the last
version (0x40100) which support the blending order feature
(dynamic z-order).
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603134459.593379-1-yannick.fertre@foss.st.com

Fix issues reported by checkpatch.pl:
- Braces {} should be used on all arms
- Blank lines
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603134334.592805-1-yannick.fertre@foss.st.com

Remove error message about scaling & replace it by a debug
message to avoid too much error.
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Acked-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603134250.592408-1-yannick.fertre@foss.st.com

All plans must be disabled before the CRTC shutdown helping
the crtc to restart from a clean situation (without unwanted
planes already enable).
Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com>
Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220603134151.591997-1-yannick.fertre@foss.st.com

Explain how to run the KUnit tests present in the DRM subsystem and
clarify why the UML-only options were not added to the configuration
file present in drivers/gpu/drm/.kunitconfig [1] [2].

[1] https://lore.kernel.org/dri-devel/CABVgOSn8i=LO5p7830h2XU1Jgg0KrN0qTnxkOMhf1oTgxjaKKw@mail.gmail.com/
[2] https://lore.kernel.org/dri-devel/CAGS_qxqpiCim_sy1LDK7PLwVgWf-LKW+uNFTGM=T7ydk-dYcEw@mail.gmail.com/Reviewed-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: David Gow <davidgow@google.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220620160640.3790-4-jose.exposito89@gmail.com