aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-05drm/i915: Unify VBT version number commentsVille Syrjälä1-96/+110
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220715202044.11153-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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 <contact@emersion.fr> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220829151451.152114-2-contact@emersion.fr
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 <contact@emersion.fr> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220829151451.152114-1-contact@emersion.fr
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 <contact@emersion.fr> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220801133754.461037-1-contact@emersion.fr
2022-09-05drm/i915/ttm: Abort suspend on i915_ttm_backup failureNirmoy Das1-1/+6
On system suspend when system memory is low then i915_gem_obj_copy_ttm() could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough, suspend shouldn't continue if i915_ttm_backup() throws an error. v2: Keep the fdo issue till we have a igt test(Matt). v3: Use %pe(Andrzej) References: https://gitlab.freedesktop.org/drm/intel/-/issues/6529 Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Suggested-by: Chris P Wilson <chris.p.wilson@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901172217.18392-1-nirmoy.das@intel.com
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/20220901113011.12080-1-stanislav.lisovskiy@intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
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 <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-11-rex-bc.chen@mediatek.com
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 <rex-bc.chen@mediatek.com> Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com> Signed-off-by: Jitao Shi <jitao.shi@mediatek.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-10-rex-bc.chen@mediatek.com
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 <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-9-rex-bc.chen@mediatek.com
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 <rex-bc.chen@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-8-rex-bc.chen@mediatek.com
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 <rex-bc.chen@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-7-rex-bc.chen@mediatek.com
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 <rex-bc.chen@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-6-rex-bc.chen@mediatek.com
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 <rex-bc.chen@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-5-rex-bc.chen@mediatek.com
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 <jitao.shi@mediatek.com> Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-4-rex-bc.chen@mediatek.com
2022-09-03Revert "drm/i915/display: Re-add check for low voltage sku for max dp source rate"Ville Syrjälä1-29/+3
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 <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-2-ville.syrjala@linux.intel.com Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-03ACPI: video: Add Nvidia WMI EC brightness control detection (v3)Hans de Goede2-0/+4
On some new laptop designs a new Nvidia specific WMI interface is present which gives info about panel brightness control and may allow controlling the brightness through this interface when the embedded controller is used for brightness control. When this WMI interface is present and indicates that the EC is used, then this interface should be used for brightness control. Changes in v2: - Use the new shared nvidia-wmi-ec-backlight.h header for the WMI firmware API definitions - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this. Changes in v3: - Use WMI_BRIGHTNESS_GUID define Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Daniel Dadap <ddadap@nvidia.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-09-03drm/radeon: Register ACPI video backlight when skipping radeon backlight registrationHans de Goede1-1/+10
Typically the acpi_video driver will initialize before radeon, which used to cause /sys/class/backlight/acpi_video0 to get registered and then radeon would register its own radeon_bl# device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when radeon skips registering its own backlight device because of e.g. the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the radeon drm_device gets registered with userspace. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-09-03drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registrationHans de Goede2-2/+9
Typically the acpi_video driver will initialize before amdgpu, which used to cause /sys/class/backlight/acpi_video0 to get registered and then amdgpu would register its own amdgpu_bl# device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when amdgpu skips registering its own backlight device because of either the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the amdgpu drm_device gets registered with userspace. Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-09-03drm/nouveau: Register ACPI video backlight when nv_backlight registration fails (v2)Hans de Goede3-0/+14
Typically the acpi_video driver will initialize before nouveau, which used to cause /sys/class/backlight/acpi_video0 to get registered and then nouveau would register its own nv_backlight device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when native backlight device registration has failed / was skipped to ensure that there is a backlight device available before the drm_device gets registered with userspace. Changes in v2: - Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved symbol errors on non X86 Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-09-03drm/i915: Call acpi_video_register_backlight() (v3)Hans de Goede3-1/+31
On machins without an i915 opregion the acpi_video driver immediately probes the ACPI video bus and used to also immediately register acpi_video# backlight devices when supported. Once the drm/kms driver then loaded later and possibly registered a native backlight device then the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices (when acpi_video_get_backlight_type()==native). This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() after the i915 calls acpi_video_register() (after setting up the i915 opregion) so that the acpi_video backlight devices get registered on systems where the i915 native backlight device is not registered. Changes in v2: -Only call acpi_video_register_backlight() when a panel is detected Changes in v3: -Add a new intel_acpi_video_register() helper which checks if a panel is present and then calls acpi_video_register_backlight() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
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: stable@vger.kernel.org Cc: Jason A. Donenfeld <Jason@zx2c4.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6205 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220902070319.15395-1-ville.syrjala@linux.intel.com Tested-by: Aaron Ma <aaron.ma@canonical.com> Tested-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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 <macromorgan@hotmail.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220902153906.31000-3-macroalpha82@gmail.com
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 <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220831082653.20449-4-tomi.valkeinen@ideasonboard.com
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 <laurent.pinchart+renesas@ideasonboard.com> Reworked to set bridge type based on the next bridge/connector. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com> -- 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 <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220831082653.20449-3-tomi.valkeinen@ideasonboard.com
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 <tomi.valkeinen+renesas@ideasonboard.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220831082653.20449-2-tomi.valkeinen@ideasonboard.com
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-09-02drm/edid: Handle EDID 1.4 range descriptor h/vfreq offsetsVille Syrjälä2-8/+20
EDID 1.4 introduced some extra flags in the range descriptor to support min/max h/vfreq >= 255. Consult them to correctly parse the vfreq limits. Note that some combinations of the flags are documented as "reserved" (as are some other values in the descriptor) but explicitly checking for those doesn't seem particularly worthwile since we end up with bogus results whether we decode them or not. v2: Increase the storage to u16 to make it work (Jani) Note the "reserved" values situation (Jani) v3: Document the EDID version number in the defines Drop some bogus (u8) casts Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6519 References: https://gitlab.freedesktop.org/drm/intel/-/issues/6484 Reviewed-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/20220826213501.31490-2-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
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 <lyude@redhat.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901161933.1004778-1-imre.deak@intel.com
2022-09-02drm/nouveau: Don't register backlight when another backlight should be used (v2)Hans de Goede3-0/+13
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved symbol errors on non X86 Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2022-09-02Merge tag 'drm-intel-fixes-2022-09-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixesDave Airlie3-8/+19
- Fix for a null pointer dereference (Lukasz) - HDMI related quirk for ECS Liva Q2 with GLK graphics (Diego) - Skip wm/ddb readout for disabled pipes (Ville) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YxC3GmSOpDiZTdIJ@intel.com
2022-09-02Merge tag 'drm-msm-fixes-2022-08-27' of https://gitlab.freedesktop.org/drm/msm into drm-fixesDave Airlie7-4/+17
Fixes for v6.0 - Fix for inconsistent indenting in function msm_dsi_dphy_timing_calc_v3. This fixes a smatch warning reported by kbot - Fix to make eDP the first connector in the connected list. This was mainly done to address a screen corruption issue we were seeing on sc7280 boards which have eDP as the primary display. The corruption itself is from usermode but we decided to fix it this way because things work correct with the primary display as the first one for usermode - Fix to populate intf_cfg correctly before calling reset_intf_cfg(). Without this, the display pipeline is not torn down correctly for writeback - Specify the correct number of DSI regulators for SDM660. It should have been 1 but 2 was mentioned - Specify the correct number of DSI regulators for MSM8996. It should have been 3 but 2 was mentioned - Fix for removing DP_RECOVERED_CLOCK_OUT_EN bit for tps4 link training for DP. This was causing link training failures and hence no display for a specific DP to HDMI cable on chromebooks - Fix probe-deferral crash in gpu devfreq - Fix gpu debugfs deadlock Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGtuY=jd44itwTkLXVqhnoKgY0BswPTrxDTxCiPG3WbmLA@mail.gmail.com
2022-09-02Merge tag 'amd-drm-fixes-6.0-2022-08-31' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixesDave Airlie23-96/+234
amd-drm-fixes-6.0-2022-08-31: amdgpu: - FRU error message fix - MES 11 updates - DCN 3.2.x fixes - DCN 3.1.4 fixes - Fix possible use after free in CS IOCTL - SMU 13.0.x fixes - Fix iolink reporting on devices with direct connections to CPU - GFX10 tap delay firmware fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220831212312.5921-1-alexander.deucher@amd.com
2022-09-01drm/amd/display: fix indentation in commit_planes_for_stream()Hamza Mahfooz1-3/+4
Address the following warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] 3508 | if (update_type != UPDATE_TYPE_FAST) | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 3510 | if (update_type != UPDATE_TYPE_FAST) | ^~ Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amd/display: remove a duplicated declarationAsher Song1-1/+1
There are duplicated declarations of i, remove one of those. Signed-off-by: Asher Song <Asher.Song@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu/vcn: Add MMSCH v4_0 support for sriovJane Jian1-0/+140
These structures are basically ported from MMSCH v3_0, besides, added RB and RB4 enablement flag to support unified queue Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jane Jian <Jane.Jian@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu/vcn: Add sriov VCN v4_0 unified queue supportJane Jian3-15/+300
Enable unified queue support for sriov, abandon all previous multi-queue settings Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jane Jian <Jane.Jian@amd.com> Reviewed-by: Ruijing Dong <ruijing.dong@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu/vcn: Add vcn/vcn1 in white list to load its firmware under sriovJane Jian1-1/+3
Previously since vcn0/vcn1 are not enabled, loading firmware is skipped. Now add firmware loading back since vcn0/vcn1 has already been enabled on sriov Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jane Jian <Jane.Jian@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu/vcn: Disable CG/PG for SRIOVJane Jian1-0/+5
For sriov, CG and MG are controlled from hypervisor side, no need to manage them again in ip init Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jane Jian <Jane.Jian@amd.com> Reviewed-by: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amd: Skip smu_v13 register irq on SRIOV VFYifan Zha1-0/+9
[Why] VF do not need to handle SMU IRQ state. L1 Policy will block VF access THM_THERMAL_INT_CTRL and MP1_SMN_IH_SW_INT/CNTL. [How] Skip smu_v13 init register_irq_handler under SRIOV VF. And add irq_src check in enable/disable thermal alert to avoid thermal alert enable/disable fail. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/admgpu: Skip CG/PG on SOC21 under SRIOV VFYifan Zha1-0/+4
[Why] There is no CG(Clock Gating)/PG(Power Gating) requirement on SRIOV VF. For multi VF, VF should not enable any CG/PG features. For one VF, PF will program CG/PG related registers. [How] Do not set any cg/pg flag bit at early init under sriov. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu: Use RLCG to program GRBM_GFX_CNTL during full access timeYifan Zha1-1/+1
[Why] KIQ register init requires GRBM_GFX_CNTL to select KIQ. [How] As RLCG accessing registers will save the data of GRBM_GFX_CNTL and restore it. Use RLCG indirect accessing register method to select grbm instead of mmio directly access. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu: Skip program SDMA0_SEM_WAIT_FAIL_TIMER_CNTL under SRIOV VFYifan Zha1-1/+2
[Why] As SDMA0_SEM_WAIT_FAIL_TIMER_CNTL is a PF-only register, L1 would block this register for VF access. [How] VF do not program it. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu: Skip the VRAM base offset on SRIOVYifan Zha1-1/+4
[Why] As VF cannot read MMMC_VM_FB_OFFSET with L1 Policy(read 0xffffffff). It leads to driver get the incorrect vram base offset. [How] Since SR-IOV is dGPU only, skip reading this register and set the fb_offest to 0. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Signed-off-by: Horace Chen <horace.chen@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu: skip "Issue additional private vm invalidation to MMHUB" on SRIOVYifan Zha1-1/+2
[Why] vm_l2_bank_select_reserved_cid2 is a PF_only register that cannot be programmed by VF. This feature is only support HDP using GPUVM page tables to access FB memory which should be disabled on SRIOV. [How] Disable the feature on VF. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Signed-off-by: Horace Chen <horace.chen@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu: Skip the program of MMMC_VM_AGP_* in SRIOV on MMHUB v3_0_0Yifan Zha1-5/+5
[Why] VF should not program these registers, the value were defined in the host. [How] Skip writing them in SRIOV environment and program them on host side. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Signed-off-by: Horace Chen <horace.chen@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-09-01drm/amdgpu: Use PSP program IH_RB_CNTL registers under SRIOVYifan Zha1-3/+23
[Why] With L1 Policy applied, IH_RB_CNTL/RING cannot be accessed by VF. [How] Use PSP program IH_RB_CNTL in VF. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Signed-off-by: Horace Chen <horace.chen@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.