- 19 Apr, 2022 9 commits
-
-
Sandor Yu authored
PHY reset register(MC_PHYRSTZ) active high reset control for PHY GEN2, and active low reset control for PHY GEN1. Rename function dw_hdmi_phy_reset to dw_hdmi_phy_gen2_reset. Add dw_hdmi_phy_gen1_reset function for PHY GEN1. Signed-off-by:
Sandor Yu <Sandor.yu@nxp.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/e0b3be2d63fe3e95246fb8b8b0dcd57415b29e04.1649989179.git.Sandor.yu@nxp.com
-
Sandor Yu authored
HDMI1.4b specification section 6.5.3: Source shall only send GCPs with non-zero CD to sinks that indicate support for Deep Color. DW HDMI GCP default enabled, but only transmit CD and do not handle AVMUTE, PP norDefault_Phase (yet). Disable Auto GCP when 24-bit color for sinks that not support Deep Color. Signed-off-by:
-
Sandor Yu authored
i.MX8MPlus (v2.13a) has verified need the workaround to clear the overflow with one iteration. Only i.MX6Q(v1.30a) need the workaround with 4 iterations, the others versions later than v1.3a have been identified as needing the workaround with a single iteration. Default enable the workaround with one iteration for all versions later than v1.30a. Signed-off-by:
-
Marek Szyprowski authored
If panel_bridge_attach() happens after DRM device registration, the created connector will not be registered by the DRM core anymore. Fix this by registering it explicitly in such case. This fixes the following issue observed on Samsung Exynos4210-based Trats board with a DSI panel (the panel driver is registered after the Exynos DRM component device is bound): $ ./modetest -c -Mexynos could not get connector 56: No such file or directory Segmentation fault While touching this, move the connector reset() call also under the DRM device registered check, because otherwise it is not really needed. Fixes: 934aef88 ("drm: bridge: panel: Reset the connector state pointer") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
-
Biju Das authored
Connector detection using poll method won't work in case of bridge attached to the encoder with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, as the code defaults to HPD. Enable DRM_BRIDGE_OP_HPD based on HPD interrupt availability, so that it will fall back to polling, if HPD is not available. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
-
Marek Vasut authored
Add driver for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly capable at converting formats, but sadly it is also highly undocumented. This driver is written without any documentation from Lontium and based only on shreds of information available in various obscure example codes, hence long runs of unknown register patches and lengthy delays in various places. Whichever register meaning could be divined from its behavior has at least a comment around it. Currently the only mode tested is Single-link DSI to Single-link LVDS. Dual-link LVDS might work as well, the register programming is in place, but is untested. Reviewed-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: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Signed-off-by:
-
Marek Vasut authored
Add bindings for Lontium LT9211 Single/Dual-Link DSI/LVDS or Single DPI to Single-link/Dual-Link DSI/LVDS or Single DPI bridge. This chip is highly capable at converting formats, but sadly it is also highly undocumented. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Hsin-Yi Wang authored
Speaker may share I2S with DP and .get_eld callback will be called when speaker is playing. When HDMI wans't connected, the connector will be null. Instead of return an error, fill in empty ELD. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
Devarsh Thakkar authored
Soft reset the display subsystem controller on startup and wait for the reset to complete. This helps the scenario where display was already in use by some other core before the linux was booted. Signed-off-by:
Devarsh Thakkar <devarsht@ti.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
- 18 Apr, 2022 3 commits
-
-
Paul Cercueil authored
drm/drm-next has a build fix for the NewVision NV3052C panel (drivers/gpu/drm/panel/panel-newvision-nv3052c.c), which needs to be merged back to drm-misc-next, as it was failing to build there. Signed-off-by:Paul Cercueil <paul@crapouillou.net>
-
Tom Rix authored
Smatch reports this issue gf108.c:147:1: warning: symbol 'gf108_gr_fwif' was not declared. Should it be static? gf108_gr_fwif is only used in gf108.c. Single file variables should not be global so change gf108_gr_fwif's storage-class specifier to static. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Tom Rix authored
Smatch reports this issue base917c.c:26:1: warning: symbol 'base917c_format' was not declared. Should it be static? base917c_format is only used in base917.c. Single file variables should not be global so change base917c_format's storage-class specifier to static. Signed-off-by:
-
- 14 Apr, 2022 17 commits
-
-
Helge Deller authored
This reverts commit d6cd978f. It has been solved differently already. Signed-off-by:
Helge Deller <deller@gmx.de> Acked-by:
Paul Menzel <pmenzel@molgen.mpg.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220210065824.368355-1-zhouzhouyi@gmail.com
-
Zhouyi Zhou authored
In function do_remove_conflicting_framebuffers, if device is NULL, there will be null pointer reference. The patch add a check to the if expression. Signed-off-by:
Zhouyi Zhou <zhouzhouyi@gmail.com> Acked-by:
-
Yang Guang authored
Use sysfs_emit instead of scnprintf or sprintf. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Yang Guang <yang.guang5@zte.com.cn> Signed-off-by:
-
Imre Deak authored
Factor out from drm_dp_dpcd_read() a function to probe a DPCD address with a 1-byte read access. This will be needed by the next patch doing a read from an LTTPR address, which must happen without the preceding wake-up read in drm_dp_dpcd_read(). While at it add tracing for the 1 byte read even if the read was successful. v2: Add a probe function instead of exporting drm_dp_dpcd_access(). (Jani) v3: Add tracing for the 1-byte read even if the read was successful. (Khaled) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411132539.984647-1-imre.deak@intel.com
-
Jani Nikula authored
Add some helpers to figure out the EDID extension block count, block count, size, pointers to blocks. Unfortunately, we'll need to cast away the const in a few places where we actually need to access the data. v3: fix (!edid_extension_block_count(edid) == 0) (kernel test robot) v2: fix s/j/i/ introduced in a rebase Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/dc7b0850293d837439fb3914c8a9d81e39018b4b.1649685475.git.jani.nikula@intel.com
-
Jani Nikula authored
This will be useful in the future. Use fail label for fail exit. Signed-off-by:
-
Jani Nikula authored
We don't need override as a variable for anything. Signed-off-by:
-
Jani Nikula authored
Use the EDID block read helper also for extension block reads, making edid_block_read() the only place with the read retry logic. Note: We observe that drm_do_get_edid() does not use invalid extension blocks to flag the EDID as corrupt. Signed-off-by:
-
Jani Nikula authored
Convert drm_do_get_edit() from the base block read helper to the generic block read helper. There's quite a bit going on here, as the corrupt and null EDID information is moved back to the caller. As we see, they were not all that clear to begin with, and this change underlines that. Signed-off-by:
-
Jani Nikula authored
We have an abstraction for the EDID base block read, yet duplicating the retries and error handling for extension block reads. Introduce a more generic EDID block read helper. Switch to the helper piecemeal, starting with drm_edid_get_panel_id(), which doesn't need or have access to the connector anyway. The subtle change is switching from drm_edid_block_valid() to edid_block_check(). We also status print once, not for every attempt. Signed-off-by:
-
Jani Nikula authored
Make the callback a bit easier on the eye. Signed-off-by:
-
Jani Nikula authored
Avoid casting here and there, and make it const. Signed-off-by:
-
Jani Nikula authored
Unify debug log dumping. There's duplication in the error paths for EDID block validity checks, but this should be neglible. Signed-off-by:
-
Jani Nikula authored
Split out a function to log EDID block status. The printouts get changed slightly. Unfortunately, not all users will have struct drm_device available, so we convert to pr_* debug logging instead of drm device based logging. v2: Complain more loudly about unknown status codes (Ville) Signed-off-by:
-
Jani Nikula authored
We have the check function, have it also detect blocks that are all zero instead of leaving that to callers. Signed-off-by:
-
Jani Nikula authored
As edid_is_zero() is only ever used on EDID blocks, convert it to edid_block_is_zero() with implicit block size. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2022-04-13-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull for v5.19: Features and functionality: - Add support for new Tile 4 format on DG2 (Stan) - Add support for new CCS clear color compression on DG2 (Mika, Juha-Pekka) - Add support for new render and media compression formats on DG2 (Matt) - Support multiple eDP and LVDS native mode refresh rates (Ville) - Support static DRRS (Ville) - ATS-M platform info (Matt) - RPL-S PCI IDs (Tejas) - Extend DP HDR support to HSW+ (Uma) - Bump ADL-P DMC version to v2.16 (Madhumitha) - Let users disable PSR2 while enabling PSR1 (José) Refactoring and cleanups: - Massive DRRS and panel fixed mode refactoring and cleanups (Ville) - Power well refactoring and cleanup (Imre) - Clean up and refactor crtc readout and compute config (Ville) - Use kernel string helpers (Lucas) - Refactor gmbus pin lookups and allocation (Jani) - PCH display cleanups (Ville) - DPLL and DPLL manager refactoring (Ville) - Include and header refactoring (Jani, Tvrtko) - DMC abstractions (Jani) - Non-x86 build refactoring (Casey) - VBT parsing refactoring (Ville) - Bigjoiner refactoring (Ville) - Optimize plane, pfit, scaler, etc. programming using unlocked writes (Ville) - Split several register writes in commit to noarm+arm pairs (Ville) - Clean up SAGV handling (Ville) - Clean up bandwidth and ddb allocation (Ville) - FBC cleanups (Ville) Fixes: - Fix native HDMI and DP HDMI DFP clock limits on deep color/4:2:0 (Ville) - Fix DMC firmware platform check (Lucas) - Fix cursor coordinates on bigjoiner secondary (Ville) - Fix MSO vs. bigjoiner timing confusion (Ville) - Fix ADL-P eDP voltage swing (José) - Fix VRR capability property update (Manasi) - Log DG2 SNPS PHY calibration errors (Matt, Lucas) - Fix PCODE request status checks (Stan) - Fix uncore unclaimed access warnings (Lucas) - Fix VBT new max TMDS clock parsing (Shawn) - Fix ADL-P non-existent underrun recovery (Swathi Dhanavanthri) - Fix ADL-N stepping info (Tejas) - Fix DPT mapping flags to contiguous (Stan) - Fix DG2 max display bandwidth (Vinod) - Fix DP low voltage SKU checks (Ankit) - Fix RPL-S VT-d translation enable via quirk (Tejas) - Fixes to PSR2 (José) - Fix PIPE_MBUS_DBOX_CTL programming (José) - Fix LTTPR capability read/check on DP 1.2 (Imre) - Fix ADL-P register corruption after DDI clock enabling (Imre) - Fix ADL-P MBUS DBOX BW and B credits (Caz) Merges: - Backmerge drm-next (Rodrigo, Jani) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/874k2xgewe.fsf@intel.com
-
- 13 Apr, 2022 11 commits
-
-
Daniel Vetter authored
I messed up the delayed takover path in the locking conversion in 6e7da3af ("fbcon: Move console_lock for register/unlink/unregister"). If CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is enabled, fbcon take-over doesn't take place when calling fbcon_fb_registered(). Instead, is deferred using a workqueue and its fbcon_register_existing_fbs() function calls to fbcon_fb_registered() again for each registered fbcon fb. This leads to the console_lock tried to be held twice, causing a deadlock. Fix it by re-extracting the lockless function and using it in the delayed takeover path, where we need to hold the lock already to iterate over the list of already registered fb. Well the current code still is broken in there (since the list is protected by a registration_lock, which we can't take here because it nests the other way round with console_lock), but in the future this will be a list protected by console_lock when this is all sorted out. While reviewing the broken commit I realized that I've left some outdated comments about the locking behind. Fix those too. v2: Improve commit message (Javier) Reported-by:
Nathan Chancellor <nathan@kernel.org> Tested-by:
Javier Martinez Canillas <javierm@redhat.com> Cc: Nathan Chancellor <nathan@kernel.org> Fixes: 6e7da3af ("fbcon: Move console_lock for register/unlink/unregister") Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Du Cheng <ducheng2@gmail.com> Cc: Claudio Suarez <cssk@net-c.es> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Matthew Wilcox <willy@infradead.org> Cc: Zheyu Ma <zheyuma97@gmail.com> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Helge Deller <deller@gmx.de> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220413082128.348186-1-daniel.vetter@ffwll.ch
-
Marek Vasut authored
This driver currently rewrites bus_flags based solely on the value of DT property 'data-mirror' and ignores bus_flags which might have been set in DT panel-timing node. Specificaly, the 'de-active' DT property sets DRM_BUS_FLAG_DE_ bus_flags. Since of_get_drm_panel_display_mode() conveniently parses the bus_flags out of DT panel-timing property, just ORR them with bus_flags inferred from 'data-mirror' DT property and use the result as panel bus_flags. This fixes handling of panels with 'panel-timing { de-active = <1>; };'. Reviewed-by:Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by:
-
Marek Vasut authored
The mode parsing is currently implemented in three steps: of_get_display_timing() - DT panel-timing to struct display_timing videomode_from_timing() - struct display_timing to struct videomode drm_display_mode_from_videomode() - struct videomode to struct drm_display_mode Replace all that with simple of_get_drm_panel_display_mode() call, which already populates struct drm_display_mode and then duplicate that mode in panel_lvds_get_modes() each time, since the mode does not change. Nice bonus is the bus_flags parsed by of_get_drm_panel_display_mode() out of panel-timing DT node, which is used in subsequent patch to fix handling of 'de-active' DT property. Tested-by:
-
Marek Vasut authored
To make debugging easier, convert driver to regmap. Implement read and write regmap tables for known registers, keep all known register readable and mark those which are obviously read-only as not writeable. Use common I2C regmap for the I2C configuration, implement custom regmap bus for DSI configuration. The later is mandatory as this chip requires one extra byte set to read access length between register address and data. Signed-off-by:
Mark Brown <broonie@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220403171004.368464-1-marex@denx.de
-
Ville Syrjälä authored
Remove the pointless detour via __intel_fbc_post_update() during frontbuffer flush. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
Let's make sure FBC is always disabled when we start to take over the hardware state. I suspect this should never really happen, since the only time when we really should be taking over with the display already active is when the previous state was progammed by the BIOS, which likely shouldn't use FBC. This could be driver init, or S4 resume when the boot kernel doesn't load i915. But I suppose no harm in keeping this code around for exra safety since it's quite trivial. Signed-off-by:
-
Ville Syrjälä authored
By the time intel_fbc_global_disable() gets called during driver teardown we should have already disabled all the crtcs, so no way FBC should be enabled at this point. And I have no idea what the other user (i915_restore_display()) is even trying to achieve. So let's just throw intel_fbc_global_disable() into the bin. Signed-off-by:
-
Ville Syrjälä authored
Now that fbc no longer nukes while a flip is pending we can remove the last uncore.lock from the i9xx plane code. Signed-off-by:
-
Ville Syrjälä authored
Don't issue a nuke from frontbuffer flush while a flip is pending. This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke from racing with the DSPADDR/DSPSURF write being performed by the flip/plane update. The flip itself will already cause the nuke so a double nuke is redundant. Signed-off-by:
-
Ville Syrjälä authored
If the frontbuffer bits say this fbc instance isn't affected just skip the whole thing. Signed-off-by:
-
Ville Syrjälä authored
Not sure what the point of this fbc->possible_frontbuffer_bits is. And especially don't see why it's returning all the bits when fbc is not even enabled. So let's just get rid of this and only say we are interested in the plane's frontbuffer bits when fbc is actually enabled. Signed-off-by:
-
