- 06 Jul, 2022 5 commits
-
-
Marek Vasut authored
The DE inversion is implemented in LCDIFv3 driver and is no longer needed in the LDB bridge which does not invert the DE signal. Drop the inversion. Fixes: 463db5c2 ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Hsin-Yi Wang authored
Move hpd polling check into wait_hpd_asserted() callback. For the cases that aux transfer function wasn't used, do hpd polling check after pm runtime resume, which will power on the bridge. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
Hsin-Yi Wang authored
Move devm_of_dp_aux_populate_ep_devices() after pm runtime and i2c setup to avoid NULL pointer crash. edp-panel probe (generic_edp_panel_probe) calls pm_runtime_get_sync() to read EDID. At this time, bridge should have pm runtime enabled and i2c clients ready. Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel") Signed-off-by:
-
Hsin-Yi Wang authored
There's no need to check for IRQ or disable it in suspend. Use pm_runtime_force_suspend(resume) to make sure anx7625 is powered off correctly. Make the system suspend/resume and pm runtime suspend/resume more consistent. Signed-off-by:
-
Hsin-Yi Wang authored
Simplify the resource management. Signed-off-by:
-
- 05 Jul, 2022 4 commits
-
-
Ville Syrjälä authored
drm_crtc.h has no need for linux/i2c.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/i2c.h. Quite a few placs do currently depend on linux/i2c.h without actually including it directly. All of those need to be fixed up. v2: imx and mcde need linux/io.h for readl()/etc. 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-5-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
drm_crtc.h has no need for linux/media-bus-format.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/media-bus-format.h. Quite a few placs do currently depend on linux/media-bus-format.h without actually including it directly. All of those need to be fixed up. v2: Deal with ingenic as well v3: Fix up mxsfb and remaining parts of imx Acked-by:
-
Ville Syrjälä authored
drm_crtc.h has no need for linux/fb.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/fb.h. Quite a few placs do currently depend on linux/fb.h or other headers pulled in by it without actually including any of it directly. All of those need to be fixed up. v2: Split the vmwgfx change out Acked-by:
-
Ville Syrjälä authored
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:
-
- 04 Jul, 2022 2 commits
-
-
Hangyu Hua authored
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: e19e9c69 ("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:
-
Paul Cercueil authored
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: 90b86fcc ("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.netAcked-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
- 03 Jul, 2022 5 commits
-
-
Marco Felsch authored
Add support for the 1024x600 LVDS panel. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Marco Felsch authored
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:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Svyatoslav Ryhel authored
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:
-
Svyatoslav Ryhel authored
Add HannStar HSD101PWW2 10.1" WXGA (1280x800) TFT-LCD LVDS panel to the list of compatibles. Acked-by:
-
Anton Bambura authored
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:
Anton Bambura <jenneron@protonmail.com> Signed-off-by:
-
- 02 Jul, 2022 2 commits
-
-
Christophe JAILLET authored
Should component_add() fail, we should call analogix_dp_remove() in the error handling path, as already done in the remove function. Fixes: 152cce00 ("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
-
Brian Norris authored
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: 4e257d9e ("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:
-
- 01 Jul, 2022 1 commit
-
-
Geert Uytterhoeven authored
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: e60c4354 ("drm/bridge: imx: Add LDB support for i.MX8qm") Fixes: 3818715f ("drm/bridge: imx: Add LDB support for i.MX8qxp") Fixes: 96988a52 ("drm/bridge: imx: Add i.MX8qxp pixel link to DPI support") Fixes: 1ec17c26 ("drm/bridge: imx: Add i.MX8qm/qxp display pixel link support") Fixes: 93e163a9 ("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:
-
- 30 Jun, 2022 14 commits
-
-
Ville Syrjälä authored
drm_crtc.h is including several entirely unnecessary headers, and also contains unused forward declarations. Remove it all. Signed-off-by:
-
Jani Nikula authored
Take the HF-EEODB extension count override into account. Signed-off-by:
-
Jani Nikula authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 4562236b ("drm/amd/dc: Add dc display driver (v2)") and later moved to amdgpu_dm.c in commit e7b07cee ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm"). Signed-off-by:
-
Jani Nikula authored
Bail out on all errors, debug log all errors, and convert to drm device based debug logging. Signed-off-by:
-
Jani Nikula authored
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 authored
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:
-
Tom Rix authored
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: da8e393e ("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
-
Lucas De Marchi authored
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
-
Lucas De Marchi authored
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:
-
- 28 Jun, 2022 7 commits
-
-
Marek Vasut authored
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:
Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-2-marex@denx.de
-
Marek Vasut authored
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:
-
Marek Vasut authored
The DSI lane count can be accessed via the dsi device pointer, make use of that. No functional change. Signed-off-by:
-
Jiang Jian authored
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:
-
Dave Stevenson authored
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:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-34-maxime@cerno.techSigned-off-by:
-
Dave Stevenson authored
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:
-
Dom Cobley authored
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:
-
