summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-03drm/panel: simple: Add support for HannStar HSD101PWW2 panelSvyatoslav Ryhel1-0/+28
Add definition of the HannStar HSD101PWW2 Rev0-A00/A01 LCD SuperIPS+ HD panel. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220529180548.9942-4-clamor95@gmail.com
2022-07-03dt-bindings: display: simple: Add HannStar HSD101PWW2Svyatoslav Ryhel1-0/+2
Add HannStar HSD101PWW2 10.1" WXGA (1280x800) TFT-LCD LVDS panel to the list of compatibles. Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220529180548.9942-3-clamor95@gmail.com
2022-07-03dt-bindings: sharp,lq101r1sx01: Add compatible for LQ101R1SX03Anton Bambura1-1/+6
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
2022-07-02drm/rockchip: Fix an error handling path rockchip_dp_probe()Christophe JAILLET1-1/+9
Should component_add() fail, we should call analogix_dp_remove() in the error handling path, as already done in the remove function. Fixes: 152cce0006ab ("drm/bridge: analogix_dp: Split bind() into probe() and real bind()") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/b719d9061bb97eb85145fbd3c5e63f4549f2e13e.1655572071.git.christophe.jaillet@wanadoo.fr
2022-07-02drm/rockchip: vop: Don't crash for invalid duplicate_state()Brian Norris1-0/+3
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: 4e257d9eee23 ("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
2022-07-01drm/bridge: imx: i.MX8 bridge drivers should depend on ARCH_MXCGeert Uytterhoeven1-0/+4
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: e60c4354840b2fe8 ("drm/bridge: imx: Add LDB support for i.MX8qm") Fixes: 3818715f62b42b5c ("drm/bridge: imx: Add LDB support for i.MX8qxp") Fixes: 96988a526c97cfbe ("drm/bridge: imx: Add i.MX8qxp pixel link to DPI support") Fixes: 1ec17c26bc06289d ("drm/bridge: imx: Add i.MX8qm/qxp display pixel link support") Fixes: 93e163a9e0392aca ("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
2022-06-30drm: Remove unnecessary junk from drm_crtc.hVille Syrjälä1-8/+0
drm_crtc.h is including several entirely unnecessary headers, and also contains unused forward declarations. Remove it all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220613200317.11305-6-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2022-06-30drm/edid: take HF-EEODB extension count into accountJani Nikula1-0/+13
Take the HF-EEODB extension count override into account. 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/c31b5796feb05c3ebac067600be2e88e098d7592.1656494768.git.jani.nikula@intel.com
2022-06-30drm/edid: add HF-EEODB support to EDID read and allocationJani Nikula1-3/+86
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
2022-06-30drm/edid: do invalid block filtering in-placeJani Nikula1-20/+23
Rewrite edid_filter_invalid_blocks() to filter invalid blocks in-place. The main motivation is to not rely on passed in information on invalid block count or the allocation size, which will be helpful in follow-up work on HF-EEODB. 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/a6ad5e4e7b91338c0d19d7be189af31094e65555.1656494768.git.jani.nikula@intel.com
2022-06-30drm/edid: add drm_edid_raw() to access the raw EDID dataJani Nikula2-0/+27
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
2022-06-30drm/probe-helper: add drm_connector_helper_get_modes()Jani Nikula2-0/+35
Add a helper function to be used as the "default" .get_modes() hook. This also works as an example of what the driver .get_modes() hooks are supposed to do regarding the new drm_edid_read*() and drm_edid_connector_update() calls. 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/d985449ed4b95971490ab7c09d2d59b58a892769.1656494768.git.jani.nikula@intel.com
2022-06-30drm/edid: add drm_edid_connector_update()Jani Nikula2-24/+81
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
2022-06-30drm/edid: abstract debugfs override EDID set/resetJani Nikula4-17/+38
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 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") and later moved to amdgpu_dm.c in commit e7b07ceef2a6 ("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
2022-06-30drm/edid: clean up connector update error handling and debug loggingJani Nikula1-13/+28
Bail out on all errors, debug log all errors, and convert to drm device based debug logging. 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/de4270b3d2e61fe42b9248490376594d472d19aa.1656494768.git.jani.nikula@intel.com
2022-06-30drm/edid: convert drm_connector_update_edid_property() to struct drm_edidJani Nikula1-46/+35
Make drm_connector_update_edid_property() a thin wrapper around a struct drm_edid based version of the same. This lets us remove the legacy drm_update_tile_info() and drm_add_display_info() functions altogether. 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/4bfe87ae392554ffb41d725353c4265ae56700bb.1656494768.git.jani.nikula@intel.com
2022-06-30drm/edid: move drm_connector_update_edid_property() to drm_edid.cJani Nikula3-82/+81
The function needs access to drm_edid.c internals more than drm_connector.c. We can make drm_reset_display_info(), drm_add_display_info() and drm_update_tile_info() static. There will be more benefits with follow-up struct drm_edid refactoring. 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/cbabce6ffb41fdc903533f21d946e8cae0667be5.1656494768.git.jani.nikula@intel.com
2022-06-30drm/vc4: change vc4_dma_range_matches from a global to staticTom Rix1-1/+1
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 <trix@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220629200101.498138-1-trix@redhat.com
2022-06-30iosys-map: Add per-word writeLucas De Marchi1-9/+29
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
2022-06-30iosys-map: Add per-word readLucas De Marchi1-9/+33
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
2022-06-29drm: lcdif: Add support for i.MX8MP LCDIF variantMarek Vasut7-1/+1144
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
2022-06-29dt-bindings: lcdif: Add compatible for i.MX8MPMarek Vasut1-0/+1
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
2022-06-29drm/bridge: tc358767: Do not cache dsi_lanes twiceMarek Vasut1-4/+2
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
2022-06-29drm/display/selftests: drop extra word 'for' in comments for MST selftestsJiang Jian1-1/+1
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
2022-06-28drm/vc4: hdmi: Move pixel doubling from Pixelvalve to HDMI blockDave Stevenson2-7/+31
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 <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-34-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Correct HDMI timing registers for interlaced modesDave Stevenson1-4/+4
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 <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-33-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Force modeset when bpc or format changesDom Cobley1-1/+11
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: ba8c0faebbb0 ("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>
2022-06-28drm/vc4: hdmi: Fix timings for interlaced modesMateusz Kwiatkowski2-9/+10
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 <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Report that 3d/stereo is allowedDom Cobley1-0/+1
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.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Add MISC_CONTROL register for vc4Dave Stevenson1-0/+1
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>
2022-06-28drm/vc4: hdmi: Add HDMI format detection registers to register listDave Stevenson1-0/+30
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>
2022-06-28drm/vc4: hdmi: Remove VC4_HDMI_SCHEDULER_CONTROL_VERT_ALWAYS_KEEPOUTDom Cobley1-3/+0
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>
2022-06-28drm/vc4: hdmi: Skip writes to disabled packet RAMDom Cobley2-1/+12
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>
2022-06-28drm/vc4: hdmi: Stop checking for enabled output in audioDom Cobley2-33/+3
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 bb7d78568814 ("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>
2022-06-28drm/vc4: hdmi: Move HDMI reset to pm_resumeDave Stevenson1-19/+22
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 <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Switch to pm_runtime_status_suspendedDave Stevenson1-2/+2
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 <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-23-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Reset HDMI MISC_CONTROL registerDave Stevenson2-0/+11
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 <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Avoid full hdmi audio fifo writesDom Cobley1-4/+4
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 <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Clear unused infoframe packet RAM registersDom Cobley1-1/+10
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 <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-20-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumpsDave Stevenson2-0/+47
The vc5 HDMI registers hadn't been added into the debugfs register sets, therefore weren't dumped on request. Add them in. Fixes: 8323989140f3 ("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>
2022-06-28drm/vc4: hdmi: Disable audio if dmas property is present but emptyPhil Elwell1-3/+3
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>
2022-06-28drm/vc4: dsi: Add correct stop condition to vc4_dsi_encoder_disable iterationDave Stevenson1-0/+3
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: 033bfe7538a1 ("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>
2022-06-28drm/vc4: dsi: Fix dsi0 interrupt supportDave Stevenson1-26/+85
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: 4078f5757144 ("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>
2022-06-28drm/vc4: dsi: Register dsi0 as the correct vc4 encoder typeDave Stevenson1-1/+2
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: 4078f5757144 ("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>
2022-06-28drm/vc4: dsi: Correct pixel order for DSI0Dave Stevenson1-1/+2
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: a86773d120d7 ("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>
2022-06-28drm/vc4: dsi: Correct DSI divider calculationsDave Stevenson1-4/+2
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: 86c1b9eff3f2 ("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.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Release workaround buffer and DMADave Stevenson1-1/+28
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: 4078f5757144 ("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.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dpi: Ensure a default format is selectedDave Stevenson1-3/+5
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.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dpi: Add option for inverting pixel clock and output enableDave Stevenson1-28/+38
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.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dpi: Add support for composite syncs to vc4_dpiDave Stevenson1-9/+16
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.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 22:23:12 +0300