Stop using the 'TRUE' define. This ultimately gets defined by
acpi/actypes.h that gets included here via a convoluted chain of
other headers. drm_crtc.h is part of that chain, and I'm trying
to eliminate all unnecessary includes from it to avoid pointless
rebuilds.
v2: Split out from the bigger patch
Cc: Zack Rusin <zackr@vmware.com>
Cc: VMware Graphics Reviewers <linux-graphics-maintainer@vmware.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220630195114.17407-2-ville.syrjala@linux.intel.com
Reviewed-by: Zack Rusin <zackr@vmware.com<mailto:zackr@vmware.com>>
The next call to sii8620_burst_get_tx_buf will result in off-by-one
When ctx->burst.tx_count + size == ARRAY_SIZE(ctx->burst.tx_buf). The same
thing happens in sii8620_burst_get_rx_buf.
This patch also change tx_count and tx_buf to rx_count and rx_buf in
sii8620_burst_get_rx_buf. It is unreasonable to check tx_buf's size and
use rx_buf.
Fixes: e19e9c692f ("drm/bridge/sii8620: add support for burst eMSC transmissions")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220518065856.18936-1-hbh25y@gmail.com
Until now, when running at the maximum resolution of 1280x720 at 32bpp
on the JZ4770 SoC the output was garbled, the X/Y position of the
top-left corner of the framebuffer warping to a random position with
the whole image being offset accordingly, every time a new frame was
being submitted.
This problem can be eliminated by using a bigger burst size for the DMA.
Set in each soc_info structure the maximum burst size supported by the
corresponding SoC, and use it in the driver.
Set the new value using regmap_update_bits() instead of
regmap_set_bits(), since we do want to override the old value of the
burst size. (Note that regmap_set_bits() wasn't really valid before for
the same reason, but it never seemed to be a problem).
Cc: <stable@vger.kernel.org>
Fixes: 90b86fcc47 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs")
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20220702230727.66704-1-paul@crapouillou.net
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Christophe Branchereau <cbranchereau@gmail.com>
Add binding for the Emerging Display Technology ETML0700Y5DHA panel.
It is a 7" WSVGA (1024x600) TFT LCD panel with:
- LVDS data interface,
- backlight and
- capacitive touch.
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220530122407.918874-1-m.felsch@pengutronix.de
LQ101R1SX03 is compatible with LQ101R1SX01 from software perspective,
document it. The LQ101R1SX03 is a newer revision of LQ101R1SX01, it has
minor differences in hardware pins in comparison to the older version.
The newer version of the panel can be found on Android tablets, like
ASUS TF701T.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Anton Bambura <jenneron@protonmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220529180548.9942-2-clamor95@gmail.com
It's possible for users to try to duplicate the CRTC state even when the
state doesn't exist. drm_atomic_helper_crtc_duplicate_state() (and other
users of __drm_atomic_helper_crtc_duplicate_state()) already guard this
with a WARN_ON() instead of crashing, so let's do that here too.
Fixes: 4e257d9eee ("drm/rockchip: get rid of rockchip_drm_crtc_mode_config")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220617172623.1.I62db228170b1559ada60b8d3e1637e1688424926@changeid
The various Freescale i.MX8 display bridges are only present on
Freescale i.MX8 SoCs. Hence add a dependency on ARCH_MXC, to prevent
asking the user about these drivers when configuring a kernel without
i.MX SoC support.
Fixes: e60c435484 ("drm/bridge: imx: Add LDB support for i.MX8qm")
Fixes: 3818715f62 ("drm/bridge: imx: Add LDB support for i.MX8qxp")
Fixes: 96988a526c ("drm/bridge: imx: Add i.MX8qxp pixel link to DPI support")
Fixes: 1ec17c26bc ("drm/bridge: imx: Add i.MX8qm/qxp display pixel link support")
Fixes: 93e163a9e0 ("drm/bridge: imx: Add i.MX8qm/qxp pixel combiner support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/42c542b53a1c8027b23a045045fbb7b34479913d.1656072500.git.geert+renesas@glider.be
HDMI 2.1 section 10.3.6 defines an HDMI Forum EDID Extension Override
Data Block, which may contain a different extension count than the base
block claims. Add support for reading more EDID data if available. The
extra blocks aren't parsed yet, though.
Hard-coding the EEODB parsing instead of using the iterators we have is
a bit of a bummer, but we have to be able to do this on a partially
allocated EDID while reading it.
v2:
- Check for CEA Data Block Collection size (Ville)
- Amend commit message and comment about hard-coded parsing
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/57b57a355d62eb91ad1e3cf555978576f2bd9fdd.1656494768.git.jani.nikula@intel.com
Unfortunately, there are still plenty of interfaces around that require
a struct edid pointer, and it's impossible to change them all at
once. Add an accessor to the raw EDID data to help the transition.
While there are no such cases now, be defensive against raw EDID
extension count indicating bigger EDID than is actually allocated.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fb55d0b580d556bf2b8e58070239657ac9cb4b2f.1656494768.git.jani.nikula@intel.com
Add a new function drm_edid_connector_update() to replace the
combination of calls drm_connector_update_edid_property() and
drm_add_edid_modes(). Usually they are called in the drivers in this
order, however the former needs information from the latter.
Since the new drm_edid_read*() functions no longer call the connector
updates directly, and the read and update are separated, we'll need this
new function for the connector update.
This is all in drm_edid.c simply to keep struct drm_edid opaque.
v2:
- Share code with drm_connector_update_edid_property() (Ville)
- Add comment about override EDID handling
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/75aa3dbc8c9aa26ebbcdeacd98a466ef8d8827f4.1656494768.git.jani.nikula@intel.com
Add functions drm_edid_override_set() and drm_edid_override_reset() to
support "edid_override" connector debugfs, and to hide the details about
it in drm_edid.c. No functional changes at this time.
Also note in the connector.override_edid flag kernel-doc that this is
only supposed to be modified by the code doing debugfs EDID override
handling. Currently, it is still being modified by amdgpu in
create_eml_sink() and handle_edid_mgmt() for reasons unknown. This was
added in commit 4562236b3b ("drm/amd/dc: Add dc display driver (v2)")
and later moved to amdgpu_dm.c in commit e7b07ceef2 ("drm/amd/display:
Merge amdgpu_dm_types and amdgpu_dm").
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8f6b4001630cafac5f44aa5913429ac9979743d2.1656494768.git.jani.nikula@intel.com
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: da8e393e23 ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220629200101.498138-1-trix@redhat.com
Like was done for read, provide the equivalent for write. Even if
current users are not in the hot path, this should future-proof it.
v2:
- Remove default from _Generic() - callers wanting to write more
than u64 should use iosys_map_memcpy_to()
- Add WRITE_ONCE() cases dereferencing the pointer when using system
memory
v3:
- Fix precedence issue when casting inside WRITE_ONCE(). By not using ()
around vaddr__ the offset was not part of the cast, but rather added
to it, producing a wrong address
- Remove compiletime_assert() as WRITE_ONCE() already contains it
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Reviewed-by: Christian König <christian.koenig@amd.com> # v1
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220628191016.3899428-2-lucas.demarchi@intel.com
Instead of always falling back to memcpy_fromio() for any size, prefer
using read{b,w,l}(). When reading struct members it's common to read
individual integer variables individually. Going through memcpy_fromio()
for each of them poses a high penalty.
Employ a similar trick as __seqprop() by using _Generic() to generate
only the specific call based on a type-compatible variable.
For a pariticular i915 workload producing GPU context switches,
__get_engine_usage_record() is particularly hot since the engine usage
is read from device local memory with dgfx, possibly multiple times
since it's racy. Test execution time for this test shows a ~12.5%
improvement with DG2:
Before:
nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07;
median = 9.52548e+06; var = 526149;
After:
nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06;
median = 8.33955e+06; var = 333113;
Other things attempted that didn't prove very useful:
1) Change the _Generic() on x86 to just dereference the memory address
2) Change __get_engine_usage_record() to do just 1 read per loop,
comparing with the previous value read
3) Change __get_engine_usage_record() to access the fields directly as it
was before the conversion to iosys-map
(3) did gave a small improvement (~3%), but doesn't seem to scale well
to other similar cases in the driver.
Additional test by Chris Wilson using gem_create from igt with some
changes to track object creation time. This happens to accidentally
stress this code path:
Pre iosys_map conversion of engine busyness:
lmem0: Creating 262144 4KiB objects took 59274.2ms
Unpatched:
lmem0: Creating 262144 4KiB objects took 108830.2ms
With readl (this patch):
lmem0: Creating 262144 4KiB objects took 61348.6ms
s/readl/READ_ONCE/
lmem0: Creating 262144 4KiB objects took 61333.2ms
So we do take a little bit more time than before the conversion, but
that is due to other factors: bringing the READ_ONCE back would be as
good as just doing this conversion.
v2:
- Remove default from _Generic() - callers wanting to read more
than u64 should use iosys_map_memcpy_from()
- Add READ_ONCE() cases dereferencing the pointer when using system
memory
v3:
- Fix precedence issue when casting inside READ_ONCE(). By not using ()
around vaddr__ the offset was not part of the cast, but rather added
to it, producing a wrong address
- Remove compiletime_assert() as READ_ONCE() already contains it
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com> # v1
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220628191016.3899428-1-lucas.demarchi@intel.com
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
Add a separate driver which is really a fork of MXSFB driver with the
i.MX8MP LCDIF variant handling filled in.
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Tested-by: Martyn Welch <martyn.welch@collabora.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Robby Cai <robby.cai@nxp.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-2-marex@denx.de
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3
and is completely different from the LCDIFv3 found in i.MX23 in that it
has a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space. However,
except for the complete bit reshuffling, this is still LCDIF and it still
works like one.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Robby Cai <robby.cai@nxp.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: devicetree@vger.kernel.org
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-1-marex@denx.de
The DSI lane count can be accessed via the dsi device pointer,
make use of that. No functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220624181902.151959-1-marex@denx.de
there is an unexpected word 'for' in the comments that need to be dropped
file - ./drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c
line - 3
* Test cases for for the DRM DP MST helpers
changed to:
* Test cases for the DRM DP MST helpers
Signed-off-by: Jiang Jian <jiangjian@cdjrlc.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220623100632.27056-1-jiangjian@cdjrlc.com
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: 8323989140 ("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-34-maxime@cerno.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
For interlaced modes the timings were not being correctly
programmed into the HDMI block, so correct them.
Fixes: 8323989140 ("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-33-maxime@cerno.tech
Signed-off-by: Maxime 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: ba8c0faebb ("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.tech
Signed-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: 682e62c454 ("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.tech
Signed-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.tech
Signed-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.tech
Signed-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.tech
Signed-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.tech
Signed-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 bb7d785688
("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.tech
Signed-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: c86b412143 ("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.tech
Signed-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: 14e193b956 ("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.tech
Signed-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: 8323989140 ("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.tech
Signed-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: bb7d785688 ("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.tech
Signed-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: 21317b3fba ("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.tech
Signed-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: 8323989140 ("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.tech
Signed-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.tech
Signed-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: 033bfe7538 ("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.tech
Signed-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: 4078f57571 ("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.tech
Signed-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: 4078f57571 ("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.tech
Signed-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: a86773d120 ("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.tech
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
