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: NJavier Martinez Canillas <javierm@redhat.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-2-cd22e962296c@cerno.tech

This is a revert of commit fd5894fa ("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: fd5894fa ("drm/vc4: hdmi: Remove clock rate initialization")
Reported-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220929-rpi-pi3-unplugged-fixes-v1-1-cd22e962296c@cerno.tech

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-8-maxime@cerno.tech

We'll need it earlier in the driver, so let's move it next to the other
scrambling-related helpers.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-7-maxime@cerno.tech

We'll need the locking context in future patch, so let's convert .detect
to .detect_ctx.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-6-maxime@cerno.tech

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-5-maxime@cerno.tech

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-4-maxime@cerno.tech

Even though vc4_hdmi_supports_scrambling takes a mode as an argument, it
never uses it. Let's remove it.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-3-maxime@cerno.tech

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220829134731.213478-2-maxime@cerno.tech

In vc4_hdmi_encoder_{pre,post}_crtc_enable() commit cd00ed51
("drm/vc4: hdmi: Protect device resources after removal") missed to
unlock the mutex before returning due to drm_dev_enter() indicating the
device being unplugged.

Fixes: cd00ed51 ("drm/vc4: hdmi: Protect device resources after removal")
Signed-off-by: NDanilo Krummrich <dakr@redhat.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220824161327.330627-2-dakr@redhat.com

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.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
(cherry picked from commit 53565c28)
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>

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.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
(cherry picked from commit f1bc386b)
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>

This driver includes the deprecated OF GPIO header <linux/of_gpio.h>
yet fail to use symbols from it, so drop the include.

Cc: Emma Anholt <emma@anholt.net>
Cc: Maxime Ripard <mripard@kernel.org>
Signed-off-by: NMaíra Canal <mairacanal@riseup.net>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220812205746.609107-6-mairacanal@riseup.net

mutex_init is supposed to be balanced by a call to mutex_destroy that we
were never doing in the vc4 driver.

Since a DRM-managed mutex_init variant has been introduced, let's just
switch to it.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-66-maxime@cerno.tech

The vc4 has a custom API to allow components to register a debugfs file
before the DRM driver has been registered and the debugfs_init hook has
been called.

However, the .late_register hook allows to have the debugfs file creation
deferred after that time already.

Let's remove our custom code to only register later our debugfs entries as
part of either debugfs_init or after it.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-65-maxime@cerno.tech

devm_pm_runtime_enable() simplifies the driver a bit since it will call
pm_runtime_disable() automatically through a device-managed action.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-49-maxime@cerno.tech

Whenever the device and driver are unbound, the main device and all the
subdevices will be removed by calling their unbind() method.

However, the DRM device itself will only be freed when the last user will
have closed it.

It means that there is a time window where the device and its resources
aren't there anymore, but the userspace can still call into our driver.

Fortunately, the DRM framework provides the drm_dev_enter() and
drm_dev_exit() functions to make sure our underlying device is still there
for the section protected by those calls. Let's add them to the HDMI driver.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-48-maxime@cerno.tech

The HDMI driver unbind hook doesn't have any ALSA-related code anymore, so
let's move the ALSA sanity checks and comments we have to some other part
of the driver dedicated to ALSA.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-47-maxime@cerno.tech

Commit 776efe80 ("drm/vc4: hdmi: Drop devm interrupt handler for
hotplug interrupts") dropped the device-managed interrupt registration
because it was creating bugs and races whenever an interrupt was coming in
while the device was removed.

However, our latest patches to the HDMI controller driver fix this as well,
so we can use device-managed interrupt handlers again.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-46-maxime@cerno.tech

The current code to build the registers set later exposed in debugfs for
the HDMI controller relies on traditional allocations, that are later
free'd as part of the driver unbind hook.

Since krealloc doesn't have a DRM-managed equivalent, let's add an action
to free the buffer later on.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-45-maxime@cerno.tech

The reference to the DDC controller device needs to be put back when we're
done with it. Let's use a device-managed action to simplify the driver.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-44-maxime@cerno.tech

The current code to unregister our CEC device needs to be undone manually
when we remove the HDMI driver.

Since the CEC framework will allocate its main structure, and will defer
its deallocation to when the last user will have closed it, we don't really
need to take any particular measure to prevent any use-after-free and can
thus use any managed action.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-43-maxime@cerno.tech

The current code to unregister our ALSA device needs to be undone manually
when we remove the HDMI driver.

Since ALSA doesn't seem to support any mechanism to defer freeing something
until the last user of the ALSA device is gone, we can either use a
device-managed or a DRM-managed action.

The consistent way would be to use a DRM-managed one, just like pretty much
any framework-facing structure should be doing. However, ALSA does a lot of
allocation and registration using device-managed calls. Thus, if we're
going that way, by the time the DRM-managed action would run all of those
allocation would have been freed and we would end up with a use-after-free.

Thus, let's do a device-managed action. It's been tested with KASAN enabled
and doesn't seem to trigger any issue, so it's as good as anything.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-42-maxime@cerno.tech

The current code will call drm_connector_unregister() and
drm_connector_cleanup() when the device is unbound. However, by then, there
might still be some references held to that connector, including by the
userspace that might still have the DRM device open.

Let's switch to a DRM-managed initialization to clean up after ourselves
only once the DRM device has been last closed.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-41-maxime@cerno.tech

The current code will call drm_encoder_cleanup() when the device is
unbound. However, by then, there might still be some references held to
that encoder, including by the userspace that might still have the DRM
device open.

Let's switch to a DRM-managed initialization to clean up after ourselves
only once the DRM device has been last closed.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-40-maxime@cerno.tech

drm_connector_unregister() is only to be used for connectors that have been
registered through drm_connector_register() after drm_dev_register() has
been called. This is our case here so let's remove the call.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-39-maxime@cerno.tech

Our internal structure that stores the DRM entities structure is allocated
through a device-managed kzalloc.

This means that this will eventually be freed whenever the device is
removed. In our case, the most likely source of removal is that the main
device is going to be unbound, and component_unbind_all() is being run.

However, it occurs while the DRM device is still registered, which will
create dangling pointers, eventually resulting in use-after-free.

Switch to a DRM-managed allocation to keep our structure until the DRM
driver doesn't need it anymore.
Acked-by: NThomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220711173939.1132294-38-maxime@cerno.tech

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.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>

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.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de>
Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NMaxime Ripard <maxime@cerno.tech>

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

For interlaced modes the timings were not being correctly
programmed into the HDMI block, so correct them.

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

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: NDom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-32-maxime@cerno.techSigned-off-by: NMaxime 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: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>

Our HDMI controllers supports Stereo output so let's enable it.
Signed-off-by: NDom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-30-maxime@cerno.techSigned-off-by: NMaxime 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: NDom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-27-maxime@cerno.techSigned-off-by: NMaxime 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: NDom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-26-maxime@cerno.techSigned-off-by: NMaxime 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: NDom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-25-maxime@cerno.techSigned-off-by: NMaxime 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: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@cerno.techSigned-off-by: NMaxime 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: NDave Stevenson <dave.stevenson@raspberrypi.com>
Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.techSigned-off-by: NMaxime 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: NDom Cobley <popcornmix@gmail.com>
Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>