aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-09-05drm/i915/hpd: suspend MST at the end of intel_modeset_driver_removeAndrzej Hajda1-7/+7
i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst. Since dp_mst is suspended after irq handler uninstall, a cleaner approach is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk use-after-free. It should fix following WARNINGS: [283.405824] cpu_latency_qos_update_request called for unknown object [283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 cpu_latency_qos_update_request+0x2d/0x100 [283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1 [283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [283.405916] Workqueue: i915-dp i915_digport_work_func [i915] [283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100 ... [283.406040] Call Trace: [283.406041] <TASK> [283.406044] intel_dp_aux_xfer+0x60e/0x8e0 [i915] [283.406131] ? finish_swait+0x80/0x80 [283.406139] intel_dp_aux_transfer+0xc5/0x2b0 [i915] [283.406218] drm_dp_dpcd_access+0x79/0x130 [drm_display_helper] [283.406227] drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper] [283.406233] intel_dp_hpd_pulse+0x134/0x570 [i915] [283.406308] ? __down_killable+0x70/0x140 [283.406313] i915_digport_work_func+0xba/0x150 [i915] Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558 Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Arun R Murthy <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-05drm/i915: Parse DP/eDP max lane count from VBTVille Syrjälä3-1/+29
Limit the DP lane count based on the new VBT DP/eDP max lane count field. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Rename some VBT bitsVille Syrjälä1-2/+2
The allow vs. block display switch bits are named rather inconsistently. Fix it up. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Define all possible VBT device handlesVille Syrjälä1-0/+9
We already have LFP1 and LFP2 device handles define. Just add all the rest as well. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Define more VBT driver features block bitsVille Syrjälä1-4/+10
Define some additional bits in the driver features VBT block. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Document the sets of bits in the driver features blockVille Syrjälä1-0/+7
Add a few comment documenting the sets of bits in the driver features block. Might make it a bit easier to check against the spec. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Define VBT max HDMI FRL rate bitsVille Syrjälä1-2/+4
The VBT gained some bits to inidicate the max FRL rate for HDMI 2.1, define them. These just outright replaced the slave_port bits for ganged eDP. Apparently that feature was never actually used so someone decided that reusing the bits is fine. Although the actual ganged eDP enable bit was still left defined elsewhere for some reason. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Add the VBT LTTPR transparent vs. non-transparent bitsVille Syrjälä1-1/+2
VBT gained a bit to indicate whether LTTPRs should use transparent or non-transparent mode. Dunno if we should actually look at this... Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Define VBT eDP/DP max lane count bitsVille Syrjälä1-1/+1
Since version 244 the VBT can llimt the eDP/DP max lane count. Add the bits. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Properly define the DP redriver VBT bitsVille Syrjälä1-5/+11
Split the DP redriver bytes into bitfields. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Add some more VBT version number commentsVille Syrjälä1-38/+38
Document the VBT version dependency of several other fields. v2: s/165/155/ for custom_vbt_version (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-05drm/i915: Unify VBT version number commentsVille Syrjälä1-97/+111
Use a more standard form for the VT version number comments. One slight oddball case is the dp_max_link_rate that had two version numbers (216/230) and a platform name (GLK). The story goes that the field was introduced in the spec in version 216, along with a note that it's used on CNL+. Later in version 230 the definition of the bit was changed in bacakwards incompatible ways and the CNL note disappeard. For us the original CNL+ note in the header got changed to to GLK+ when all CNL support was dropped from the codebase. We do still need (and have) handling for both the 216+ and the 230+ defintions (parse_bdb_216_dp_max_link_rate() vs. parse_bdb_230_dp_max_link_rate()). Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2022-09-05drm/atomic-helper: log EINVAL cause in drm_atomic_helper_async_check()Simon Ser1-6/+26
This can help figure out why the kernel returns EINVAL from user-space. v2: add missing newlines Signed-off-by: Simon Ser <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-05drm/atomic-helper: print message on driver connector check failureSimon Ser1-2/+10
Sometimes drivers are missing logs when they return EINVAL. Printing the failure here in common code can help understand where EINVAL is coming from. All other atomic_check() calls in this file already have similar logging. v2: add missing newlines Signed-off-by: Simon Ser <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-05drm: hide unregistered connectors from GETCONNECTOR IOCTLSimon Ser1-0/+3
When registering a connector, the kernel sends a hotplug uevent in drm_connector_register(). When unregistering a connector, drivers are expected to send a uevent as well. However, user-space has no way to figure out that the connector isn't registered anymore: it'll still be reported in GETCONNECTOR IOCTLs. The documentation for DRM_CONNECTOR_UNREGISTERED states: > The connector […] has since been unregistered and removed from > userspace, or the connector was unregistered before it had a chance > to be exposed to userspace Signed-off-by: Simon Ser <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-05drm/i915: Start using REG_BIT* macros with CDCLK registersStanislav Lisovskiy1-10/+10
Lets start to use REG_BIT* macros, when working with CDCLK registers, such as CDCLK_CTL, instead of (x << 0) like expressions. Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Stanislav Lisovskiy <[email protected]>
2022-09-04drm/mediatek: dp: Audio support for MT8195Guillaume Ranquet2-1/+532
This patch adds audio support to the DP driver for MT8195 with up to 8 channels. Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: dp: Add hpd debounceJitao Shi1-1/+24
From the DP spec 1.4a chapter 3.3, upstream devices should implement HPD signal de-bouncing on an external connection. A period of 100ms should be used to detect an HPD connect event. To cover these cases, HPD de-bounce should be implemented only after HPD low has been detected for at least 100ms. Therefore, 1. If HPD is low (which means plugging out) for longer than 100ms: we need to do de-bouncing (which means we need to wait for 100ms). 2. If HPD low is for less than 100ms: we don't need to care about the de-bouncing. In this patch, we start a 100ms timer and use a need_debounce boolean to implement the feature. Two cases when HPD is high: 1. If the timer is expired (>100ms): - need_debounce is true. - When HPD high (plugging event comes), need_debounce will be true and then we need to do de-bouncing (wait for 100ms). 2. If the timer is not expired (<100ms): - need_debounce is false. - When HPD high (plugging event comes), need_debounce will be false and no need to do de-bouncing. HPD_______ __________________ | |<- 100ms -> |____________| <- 100ms -> Without HPD de-bouncing, USB-C to HDMI Adapaters will not be detected. The change has been successfully tested with the following devices: - Dell Adapter - USB-C to HDMI - Acer 1in1 HDMI dongle - Ugreen 1in1 HDMI dongle - innowatt HDMI + USB3 hub - Acer 2in1 HDMI dongle - Apple 3in1 HDMI dongle (A2119) - J5Create 3in1 HDMI dongle (JAC379) Tested-by: Rex-BC Chen <[email protected]> Reviewed-by: Rex-BC Chen <[email protected]> Signed-off-by: Jitao Shi <[email protected]> Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: CK Hu <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: dp: Add MT8195 External DisplayPort supportGuillaume Ranquet1-0/+139
Add External DisplayPort support to the MT8195 eDP driver. Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: CK Hu <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: dp: Determine device of next_bridgeBo-Chen Chen1-1/+4
It's not necessary to have a next_bridge for DP device, so we add this patch to judge this. Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: CK Hu <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: dp: Add multiple calibration data formats supportBo-Chen Chen1-3/+6
The calibration data formats of eDP and DP are different. We add "const struct mtk_dp_efuse_fmt *efuse_fmt" to the device data to define them. Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: CK Hu <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: dp: Add multiple smc commands supportBo-Chen Chen1-2/+4
The smc commands of eDP and DP are different. We add smc_cmd to the device data to define them. Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: CK Hu <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: dp: Add multiple bridge types supportBo-Chen Chen1-2/+14
The bridge types of eDP and DP are different. We add device data to this driver and add bridge_type to the device data to define them. Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: CK Hu <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04drm/mediatek: Add MT8195 Embedded DisplayPort driverMarkus Schneider-Pargmann4-0/+2315
This patch adds a embedded displayport driver for the MediaTek mt8195 SoC. It supports the MT8195, the embedded DisplayPort units. It offers DisplayPort 1.4 with up to 4 lanes. The driver creates a child device for the phy. The child device will never exist without the parent being active. As they are sharing a register range, the parent passes a regmap pointer to the child so that both can work with the same register range. The phy driver sets device data that is read by the parent to get the phy device that can be used to control the phy properties. This driver is based on an initial version by Jitao shi <[email protected]> Signed-off-by: Markus Schneider-Pargmann <[email protected]> Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: CK Hu <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04video/hdmi: Add audio_infoframe packing for DPMarkus Schneider-Pargmann3-20/+71
Similar to HDMI, DP uses audio infoframes as well which are structured very similar to the HDMI ones. This patch adds a helper function to pack the HDMI audio infoframe for DP, called hdmi_audio_infoframe_pack_for_dp(). hdmi_audio_infoframe_pack_only() is split into two parts. One of them packs the payload only and can be used for HDMI and DP. Also constify the frame parameter in hdmi_audio_infoframe_check() as it is passed to hdmi_audio_infoframe_check_only() which expects a const. Signed-off-by: Markus Schneider-Pargmann <[email protected]> Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-04dt-bindings: mediatek,dp: Add Display Port bindingMarkus Schneider-Pargmann1-0/+116
This controller is present on several mediatek hardware. Currently mt8195 and mt8395 have this controller without a functional difference, so only one compatible field is added. The controller can have two forms, as a normal display port and as an embedded display port. Signed-off-by: Markus Schneider-Pargmann <[email protected]> Signed-off-by: Guillaume Ranquet <[email protected]> Signed-off-by: Bo-Chen Chen <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-03Revert "drm/i915/display: Re-add check for low voltage sku for max dp source ↵Ville Syrjälä1-29/+3
rate" This reverts commit d5929835080a60f9119d024fa42f315913942f76. With the Parade PS8461E MUX workaround (WaEdpLinkRateDataReload) implemented we can get finally rid of the is_low_voltage_sku() check that incorrectly prevents many machines from using the 8.1Gpbs link rate. Cc: Jason A. Donenfeld <[email protected]> Cc: Ankit Nautiyal <[email protected]> Cc: Jani Nikula <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5272 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6323 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Aaron Ma <[email protected]> Tested-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Jani Nikula <[email protected]>
2022-09-03drm/i915: Implement WaEdpLinkRateDataReloadVille Syrjälä1-0/+22
A lot of modern laptops use the Parade PS8461E MUX for eDP switching. The MUX can operate in jitter cleaning mode or redriver mode, the first one resulting in higher link quality. The jitter cleaning mode needs to know the link rate used and the MUX achieves this by snooping the LINK_BW_SET, LINK_RATE_SELECT and SUPPORTED_LINK_RATES DPCD accesses. When the MUX is powered down (seems this can happen whenever the display is turned off) it loses track of the snooped link rates so when we do the LINK_RATE_SELECT write it no longer knowns which link rate we're selecting, and thus it falls back to the lower quality redriver mode. This results in unstable high link rates (eg. usually 8.1Gbps link rate no longer works correctly). In order to avoid all that let's re-snoop SUPPORTED_LINK_RATES from the sink at the start of every link training. Unfortunately we don't have a way to detect the presence of the MUX. It looks like the set of laptops equipped with this MUX is fairly large and contains devices from multiple manufacturers. It may also still be growing with new models. So a quirk doesn't seem like a very easily maintainable option, thus we shall attempt to do this unconditionally on all machines that use LINK_RATE_SELECT. Hopefully this extra DPCD read doesn't cause issues for any unaffected machine. If that turns out to be the case we'll need to convert this into a quirk in the future. Cc: [email protected] Cc: Jason A. Donenfeld <[email protected]> Cc: Ankit Nautiyal <[email protected]> Cc: Jani Nikula <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Tested-by: Aaron Ma <[email protected]> Tested-by: Jason A. Donenfeld <[email protected]> Reviewed-by: Jani Nikula <[email protected]>
2022-09-02drm/bridge: chrontel-ch7033: Add byteswap order settingChris Morgan1-2/+13
Add the option to set the byteswap order in the devicetree. For the official HDMI DIP for the NTC CHIP the byteswap order needs to be RGB, however the driver sets it as BGR. With this patch the driver will remain at BGR unless manually specified via devicetree. Signed-off-by: Chris Morgan <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-02dt-bindings: Add byteswap order to chrontel ch7033Chris Morgan1-0/+13
Update dt-binding documentation to add support for setting byteswap of chrontel ch7033. New property name of chrontel,byteswap added to set the byteswap order. This property is optional. Signed-off-by: Chris Morgan <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-02drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DPLaurent Pinchart1-0/+28
Implement the bridge connector-related .get_edid() and .detect() operations for full DP mode, and report the related bridge capabilities and type. Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Kieran Bingham <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-02drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) modeLaurent Pinchart1-3/+18
Despite the SN65DSI86 being an eDP bridge, on some systems its output is routed to a DisplayPort connector. Enable DisplayPort mode when the next component in the display pipeline is detected as a DisplayPort connector, and disable eDP features in that case. Signed-off-by: Laurent Pinchart <[email protected]> Reworked to set bridge type based on the next bridge/connector. Signed-off-by: Kieran Bingham <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> -- Changes since v1/RFC: - Rebased on top of "drm/bridge: ti-sn65dsi86: switch to devm_drm_of_get_bridge" - eDP/DP mode determined from the next bridge connector type. Changes since v2: - Remove setting of Standard DP Scrambler Seed. (It's read-only). - Prevent setting DP_EDP_CONFIGURATION_SET in ti_sn_bridge_atomic_enable() - Use Doug's suggested text for disabling ASSR on DP mode. Changes since v3: - Remove ASSR_CONTROL definition Changes since v4: - Refactor code to configure the DP/eDP scrambler in one place. Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-02drm/bridge: ti-sn65dsi86: Reject modes with too large blankingTomi Valkeinen1-0/+23
The front and back porch registers are 8 bits, and pulse width registers are 15 bits, so reject any modes with larger periods. Signed-off-by: Tomi Valkeinen <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-02drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointersVille Syrjälä1-28/+18
The current scheme for generating the LFP data table pointers (when the block including them is missing from the VBT) expects the 0xffff sequence to only appear in the fp_timing terminator entries. However some VBTs also have extra 0xffff sequences elsewhere in the LFP data. When looking for the terminators we may end up finding those extra sequeneces insted, which means we deduce the wrong size for the fp_timing table. The code then notices the inconsistent looking values and gives up on the generated data table pointers, preventing us from parsing the LFP data table entirely. Let's give up on the "search for the terminators" approach and instead just hardcode the expected size for the fp_timing table. We have enough sanity checks in place to make sure we shouldn't end up parsing total garbage even if that size should change in the future (although that seems unlikely as the fp_timing and dvo_timing tables have been declared obsolete as of VBT version 229). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-02drm/i915/bios: Validate fp_timing terminator presenceVille Syrjälä1-28/+32
Validate the LFP data block a bit hardwer by making sure the fp_timing terminators (0xffff) are where we expect them to be. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-09-02drm/i915/dp_mst: Fix mst_mgr lookup during atomic checkImre Deak1-5/+3
If an MST connector was disabled in the old state during a commit, the connector's best_encoder will be NULL, so we can't look up mst_mgr via it. Do the lookup instead via intel_connector->mst_port which always points to the primary encoder. This fixes the following: [ 58.922866] BUG: kernel NULL pointer dereference, address: 0000000000000170 [ 58.922867] #PF: supervisor read access in kernel mode [ 58.922868] #PF: error_code(0x0000) - not-present page [ 58.922869] PGD 0 P4D 0 [ 58.922870] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 58.922872] CPU: 0 PID: 133 Comm: kworker/0:2 Tainted: G U 6.0.0-rc3-imre+ #560 [ 58.922874] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.3135.A00.2203251419 03/25/2022 [ 58.922874] Workqueue: events output_poll_execute [drm_kms_helper] [ 58.922879] RIP: 0010:intel_dp_mst_atomic_check+0xbb/0x1c0 [i915] [ 58.922955] Code: 5b 7b f6 ff 84 c0 75 41 48 8b 44 24 18 65 48 2b 04 25 28 00 00 00 0f 85 ff 00 00 00 48 8b 45 10 48 8b 93 10 07 00 00 4c 89 e7 <48> 8b b0 70 01 00 00 48 83 c4 20 5b 5d 48 81 c6 f0 0c 00 00 41 5c [ 58.922956] RSP: 0018:ffffc90000633a88 EFLAGS: 00010246 [ 58.922957] RAX: 0000000000000000 RBX: ffff888117d19000 RCX: ffff888101893308 [ 58.922958] RDX: ffff888122981000 RSI: ffffffff82309ecc RDI: ffff888114da6800 [ 58.922959] RBP: ffff8881094bab48 R08: 0000000081917436 R09: 0000000068191743 [ 58.922960] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888114da6800 [ 58.922960] R13: ffff8881143f8000 R14: 0000000000000000 R15: ffff888119bf2000 [ 58.922961] FS: 0000000000000000(0000) GS:ffff888496200000(0000) knlGS:0000000000000000 [ 58.922962] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 58.922962] CR2: 0000000000000170 CR3: 0000000005612004 CR4: 0000000000770ef0 [ 58.922963] PKRU: 55555554 [ 58.922963] Call Trace: [ 58.922964] <TASK> [ 58.922966] drm_atomic_helper_check_modeset+0x3f8/0xc70 [drm_kms_helper] [ 58.922972] intel_atomic_check+0xb1/0x3180 [i915] [ 58.923059] ? find_held_lock+0x2b/0x80 [ 58.923064] drm_atomic_check_only+0x5d3/0xa60 [drm] [ 58.923082] drm_atomic_commit+0x56/0xc0 [drm] [ 58.923097] ? drm_plane_get_damage_clips.cold+0x1c/0x1c [drm] [ 58.923114] drm_client_modeset_commit_atomic+0x235/0x280 [drm] [ 58.923132] drm_client_modeset_commit_locked+0x5b/0x190 [drm] [ 58.923148] drm_client_modeset_commit+0x24/0x50 [drm] [ 58.923164] drm_fb_helper_set_par+0xae/0xe0 [drm_kms_helper] [ 58.923171] drm_fb_helper_hotplug_event+0xd5/0xf0 [drm_kms_helper] [ 58.923178] output_poll_execute+0xac/0x200 [drm_kms_helper] [ 58.923187] process_one_work+0x268/0x580 [ 58.923190] ? process_one_work+0x580/0x580 [ 58.923191] worker_thread+0x52/0x3b0 [ 58.923193] ? process_one_work+0x580/0x580 [ 58.923195] kthread+0xf0/0x120 [ 58.923196] ? kthread_complete_and_exit+0x20/0x20 [ 58.923198] ret_from_fork+0x1f/0x30 [ 58.923202] </TASK> Fixes: ffac9721939d ("drm/display/dp_mst: Don't open code modeset checks for releasing time slots") Cc: Lyude Paul <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-01drm/cmdline-parser: Use assert when neededMichał Winiarski1-40/+40
Expecting to observe a specific value, when the function responsible for setting the value has failed will lead to extra noise in test output. Use assert when the situation calls for it. Also - very small tidying up around the changed areas (whitespace). v2: Leave out the locals (drm_connector is huge) (lkp) Signed-off-by: Michał Winiarski <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-01drm/cmdline-parser: Merge negative testsMichał Winiarski1-190/+103
Negative tests can be expressed as a single parameterized test case, which highlights that we're following the same test logic (passing invalid cmdline and expecting drm_mode_parse_command_line_for_connector to fail), which improves readability. v2: s/negative/invalid to be consistent with other testcases in DRM Signed-off-by: Michał Winiarski <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-01gpu/drm/bridge/cadence: avoid flush_scheduled_work() usageTetsuo Handa1-1/+2
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a macro") says, flush_scheduled_work() is dangerous and will be forbidden. We are on the way for removing all flush_scheduled_work() callers from the kernel, and this patch is for removing flush_scheduled_work() call from cadence driver. Since cdns-mhdp8546 driver uses 4 works mhdp->modeset_retry_work mhdp->hpd_work mhdp->hdcp.check_work mhdp->hdcp.prop_work I assume that flush_scheduled_work() in cdns_mhdp_remove() needs to wait for only these 4 works. Since mhdp->modeset_retry_work already uses cancel_work_sync(), I assume that flush_scheduled_work() needs to wait for only 3 works. But I came to wonder whether mhdp->hdcp.check_work should be flushed or cancelled. While flush_scheduled_work() waits for completion of works which were already queued to system_wq, mhdp->hdcp.check_work is a delayed work. That is, this work won't be queued to system_wq unless timeout expires. Current code will wait for mhdp->hdcp.check_work only if timeout already expired. If timeout is not expired yet, flush_scheduled_work() will fail to cancel mhdp->hdcp.check_work, and cdns_mhdp_hdcp_check_work() which is triggered by mhdp->hdcp.check_work will schedule hdcp->check_work, which is too late for flush_scheduled_work() to wait for completion of cdns_mhdp_hdcp_prop_work(). But since I couldn't get comments on how do we want to handle this race window [1], this patch chose "do nothing" for mhdp->hdcp.check_work and mhdp->hdcp.prop_work. That is, I assume that flush_scheduled_work() in cdns_mhdp_remove() needs to wait for only mhdp->hpd_work work. Link: https://lkml.kernel.org/r/[email protected] [1] Signed-off-by: Tetsuo Handa <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-01drm/i915/display: Fix warning callstack for imbalance wakerefMitul Golani1-4/+8
While executing i915_selftest, wakeref imbalance warning is seen with i915_selftest failure. Currently when Driver is suspended, while doing unregister it is taking wakeref without resuming the device. This patch is resuming the device, if driver is already suspended and doing unregister process. Signed-off-by: Mitul Golani <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Imre Deak <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-09-01drm/panfrost: Update io-pgtable APIRobin Murphy1-17/+27
Convert to io-pgtable's bulk {map,unmap}_pages() APIs, to help the old single-page interfaces eventually go away. Unmapping heap BOs still wants to be done a page at a time, but everything else can get the full benefit of the more efficient interface. Signed-off-by: Robin Murphy <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Steven Price <[email protected]> Signed-off-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/daef7f8c134d989c55636a5790d8c0fcaca1bae3.1661205687.git.robin.murphy@arm.com
2022-08-31drm/i915: Allow more varied alternate fixed modes for panelsVille Syrjälä1-19/+6
On some systems the panel reports alternate modes with different blanking periods. If the EDID reports them and VBT doesn't tell us otherwise then I can't really see why they should be rejected. So allow their use for the purposes of static DRRS. For seamless DRRS we still require a much more exact match of course. But that logic only kicks in when selecting the downclock mode (or in the future when determining whether we can do a seamless refresh rate change due to a user modeset). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6374 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-08-31drm/i915/bios: Copy the whole MIPI sequence blockVille Syrjälä1-0/+7
Turns out the MIPI sequence block version number and new block size fields are considered part of the block header and are not included in the reported new block size field itself. Bump up the block size appropriately so that we'll copy over the last five bytes of the block as well. For this particular machine those last five bytes included parts of the GPIO op for the backlight on sequence, causing the backlight no longer to turn back on: Sequence 6 - MIPI_SEQ_BACKLIGHT_ON Delay: 20000 us - GPIO index 0, number 0, set 0 (0x00) + GPIO index 1, number 70, set 1 (0x01) Cc: [email protected] Fixes: e163cfb4c96d ("drm/i915/bios: Make copies of VBT data blocks") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6652 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula <[email protected]>
2022-08-31drm/i915/bios: Dump PNPID and panel nameVille Syrjälä1-0/+23
Dump the panel PNPID and name from the VBT. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/fence: replace BUG_ON() with BUILD_BUG_ON()Jani Nikula2-3/+5
Avoid BUG_ON(). Since __i915_sw_fence_init() is always called via a wrapper macro, we can replace it with a compile time BUILD_BUG_ON(). Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/perf: replace BUG_ON() with WARN_ON()Jani Nikula1-1/+2
Avoid BUG_ON(). Replace with WARN_ON() and early return. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/pch: replace BUG_ON() with drm_WARN_ON()Jani Nikula1-1/+1
Avoid BUG_ON(). Replace with drm_WARN_ON(). Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/dpll: replace BUG_ON() with drm_WARN_ON()Jani Nikula1-2/+4
Avoid BUG_ON(). Actually check the dpll count and bail out loudly with drm_WARN_ON() from the loop before overflowing i915->dpll.shared_dplls[]. v2: Rebase Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/crt: remove BUG_ON()Jani Nikula1-2/+0
Avoid BUG_ON(). We don't have such checks on output type anywhere else either, so just remove. Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-08-31drm/i915/gmbus: mass dev_priv -> i915 renameJani Nikula1-134/+134
Now that gmbus no longer uses macros that assume dev_priv is implicitly available, mass rename dev_priv to i915 in gmbus code. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/fcf16a65f7975379a887ed57c623b25de7b344c8.1661855191.git.jani.nikula@intel.com
Powered by cgit, Gruvboxed by Blaster4385.