Igor Torrente [Mon, 5 Sep 2022 19:08:09 +0000 (16:08 -0300)]
drm: vkms: Supports to the case where primary plane doesn't match the CRTC
We will remove the current assumption that the primary plane has the
same size and position as CRTC and that the primary plane is the
bottom-most in zpos order, or is even enabled. At least as far
as the blending machinery is concerned.
For that we will add CRTC dimension information to `vkms_crtc_state`
and add a opaque black backgound color.
Because now we need to fill the background, we had a loss in
performance with this change. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|:--------------------------------------------:|
| Implementation | Previous | This commit |
|:---------------:|:---------:|:--------------:|
| frametime range | 5~18 ms | 10~22 ms |
| Average | 8.47 ms | 12.32 ms |
V6: Improve the commit description (Pekka Paalanen).
Update some comments (Pekka Paalanen).
Remove some fields from `vkms_crtc_state` and move where
some variables are set (Pekka Paalanen).
Igor Torrente [Mon, 5 Sep 2022 19:08:08 +0000 (16:08 -0300)]
drm: vkms: Refactor the plane composer to accept new formats
Currently the blend function only accepts XRGB_8888 and ARGB_8888
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
The pixels blend is done using the new internal format. And new handlers
are being added to convert a specific format to/from this internal format.
So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.
This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).
These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.
Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|:------------------------------------------:|
| Implementation | Current | This commit |
|:---------------:|:---------:|:------------:|
| frametime range | 9~22 ms | 5~17 ms |
| Average | 11.4 ms | 7.8 ms |
V2: Improves the performance drastically, by performing the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen).
Several security/robustness improvents(Pekka Paalanen).
Removes check_planes_x_bounds function and allows partial
partly off-screen(Pekka Paalanen).
V6: Fix a mismatch of some variable sizes (Pekka Paalanen).
Several minor improvements (Pekka Paalanen).
Igor Torrente [Mon, 5 Sep 2022 19:08:07 +0000 (16:08 -0300)]
drm: vkms: Add fb information to `vkms_writeback_job`
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_frame_info`
struct.
Also adds two new function pointers (`line_to_frame_func` and
`frame_to_line_func`) are defined to handle format conversion
from/to internal format.
A new internal format(`struct pixel_argb_u16`) is introduced to deal with
all possible inputs. It consists of 16 bits fields that represent each of
the channels.
These things will allow us, in the future, to have different compositing
and wb format types.
V2: Change the code to get the drm_framebuffer reference and not copy its
contents (Thomas Zimmermann).
V3: Drop the refcount in the wb code (Thomas Zimmermann).
V5: Add {wb,plane}_format_transform_func to vkms_writeback_job
and vkms_plane_state (Pekka Paalanen)
V6: Improvements to some struct/struct members names (Pekka Paalanen).
Splits this patch in two (Pekka Paalanen).
V7: Replace line_to_frame_func and frame_to_line_func typedefs
with the function signature and void* (Melissa Wen).
Igor Torrente [Mon, 5 Sep 2022 19:08:05 +0000 (16:08 -0300)]
drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation
Add a helper function to validate the connector configuration received in
the encoder atomic_check by the drivers.
So the drivers don't need to do these common validations themselves.
V2: Move the format verification to a new helper at the drm_atomic_helper.c
(Thomas Zimmermann).
V3: Format check improvements (Leandro Ribeiro).
Minor improvements(Thomas Zimmermann).
V5: Fix some grammar issues in the commit message (André Almeida).
Igor Torrente [Mon, 5 Sep 2022 19:08:04 +0000 (16:08 -0300)]
drm: vkms: Rename `vkms_composer` to `vkms_frame_info`
Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.
Composer is the code that do the compositing of the planes.
This struct contains information on the frame used in the output
composition. Thus, vkms_frame_info is a better name to represent
this.
V5: Fix a commit message typo(Melissa Wen).
V6: Fix wrong iosys_map_is_null verification at compose_plane
(Melissa Wen).
Simon Ser [Mon, 1 Aug 2022 13:38:02 +0000 (13:38 +0000)]
drm: hide unregistered connectors from GETCONNECTOR IOCTL
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
Jitao Shi [Thu, 1 Sep 2022 04:41:48 +0000 (12:41 +0800)]
drm/mediatek: dp: Add hpd debounce
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.
drm/mediatek: dp: Add MT8195 External DisplayPort support
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
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
drm/mediatek: dp: Add multiple calibration data formats support
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
drm/mediatek: dp: Add multiple smc commands support
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
drm/mediatek: dp: Add multiple bridge types support
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
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
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 <msp@baylibre.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> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220901044149.16782-3-rex-bc.chen@mediatek.com
dt-bindings: mediatek,dp: Add Display Port binding
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 <msp@baylibre.com> Signed-off-by: Guillaume Ranquet <granquet@baylibre.com> Signed-off-by: Bo-Chen Chen <rex-bc.chen@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> 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-2-rex-bc.chen@mediatek.com
Chris Morgan [Fri, 2 Sep 2022 15:39:06 +0000 (10:39 -0500)]
drm/bridge: chrontel-ch7033: Add byteswap order setting
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.
Laurent Pinchart [Wed, 31 Aug 2022 08:26:52 +0000 (11:26 +0300)]
drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
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.
Imre Deak [Thu, 1 Sep 2022 16:19:33 +0000 (19:19 +0300)]
drm/i915/dp_mst: Fix mst_mgr lookup during atomic check
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.
Michał Winiarski [Wed, 17 Aug 2022 21:12:36 +0000 (23:12 +0200)]
drm/cmdline-parser: Use assert when needed
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)
Michał Winiarski [Wed, 17 Aug 2022 21:12:35 +0000 (23:12 +0200)]
drm/cmdline-parser: Merge negative tests
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
Like commit 972041152ace123e ("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.
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.
Robin Murphy [Mon, 22 Aug 2022 22:01:27 +0000 (23:01 +0100)]
drm/panfrost: Update io-pgtable API
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.
Douglas Anderson [Mon, 22 Aug 2022 17:53:59 +0000 (10:53 -0700)]
MAINTAINERS: Add myself as a reviewer for panel-edp.c
panel-edp changes go through the drm-misc tree (as per the "DRM PANEL
DRIVERS" entry in MAINTAINERS), but ever since splitting panel-edp out
of panel-simple I've been trying to keep a close eye on it. Make that
official by listing me as a reviewer.
Pin-yen Lin [Tue, 30 Aug 2022 04:57:56 +0000 (12:57 +0800)]
drm/bridge: it6505: Fix the order of DP_SET_POWER commands
Send DP_SET_POWER_D3 command to the downstream before stopping DP, so the
suspend process will not be interrupted by the HPD interrupt. Also modify
the order in .atomic_enable callback to make the callbacks symmetric.
The two bridges (stdp2690, stdp4028) do not probe at the same time, so
the driver does not call ge_b850v3_resgiter() when probing, causing the
driver to try to remove the object that has not been initialized.
Fix this by checking whether both the bridges are probed.
Jani Nikula [Mon, 15 Aug 2022 08:58:34 +0000 (11:58 +0300)]
drm/dp: add drm_dp_phy_name() for getting DP PHY name
Add a helper for getting the DP PHY name. In the interest of caller
simplicity and to avoid allocations and passing in of buffers, duplicate
the const strings to return. It's a minor penalty to pay for simplicity
in all the call sites.
Hsin-Yi Wang [Mon, 15 Aug 2022 09:39:07 +0000 (17:39 +0800)]
drm/bridge: ps8640: Add double reset T4 and T5 to power-on sequence
The double reset power-on sequence is a workaround for the hardware
flaw in some chip that SPI Clock output glitch and cause internal MPU
unable to read firmware correctly. The sequence is suggested in ps8640
application note.
Lucas Stach [Fri, 26 Aug 2022 18:57:33 +0000 (20:57 +0200)]
drm: bridge: dw_hdmi: only trigger hotplug event on link change
There are two events that signal a real change of the link state: HPD going
high means the sink is newly connected or wants the source to re-read the
EDID, RX sense going low is a indication that the link has been disconnected.
Ignore the other two events that also trigger interrupts, but don't need
immediate attention: HPD going low does not necessarily mean the link has
been lost and should not trigger a immediate read of the status. RX sense
going high also does not require a detect cycle, as HPD going high is the
right point in time to read the EDID.
Marek Vasut [Mon, 1 Aug 2022 12:54:19 +0000 (14:54 +0200)]
drm/bridge: lvds-codec: Fix error checking of drm_of_lvds_get_data_mapping()
The drm_of_lvds_get_data_mapping() returns either negative value on
error or MEDIA_BUS_FMT_* otherwise. The check for 'ret' would also
catch the positive case of MEDIA_BUS_FMT_* and lead to probe failure
every time 'data-mapping' DT property is specified.
Fixes: 90054c85dbfec ("drm: of: Add drm_of_lvds_get_data_mapping") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sam Ravnborg <sam@ravnborg.org>
To: dri-devel@lists.freedesktop.org Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220801125419.167562-1-marex@denx.de
Marek Vasut [Sun, 24 Jul 2022 22:43:17 +0000 (00:43 +0200)]
drm/bridge: tc358767: Handle bridge past DPI output
Currently the driver only handles panel directly connected to the DPI output.
Handle the case where a bridge is connected past DPI output of this bridge.
This could be e.g. DPI to LVDS encoder chip.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220724224317.288727-1-marex@denx.de
Patrik Jakobsson [Fri, 10 Jun 2022 13:09:25 +0000 (15:09 +0200)]
drm/gma500: Fix SDVO command debug printing
At some point the DRM printers started adding a newline after each
print. This caused SDVO command debug printing to look weird. Fix this
by using snprintf to print into a buffer which can be printed as a whole
by DRM_DEBUG_KMS(). Code is heavily inspired by i915.
Linus Walleij [Thu, 5 May 2022 21:50:19 +0000 (23:50 +0200)]
drm/tve200: Fix smatch warning
The "ret" variable is ambiguously returning something that
could be zero in the tve200_modeset_init() function, assign
it an explicit error return code to make this unambiguous.
Marek Vasut [Mon, 1 Aug 2022 13:17:47 +0000 (15:17 +0200)]
drm: bridge: icn6211: Add support for external REFCLK
The ICN6211 is capable of deriving its internal PLL clock from either
MIPI DSI HS clock, external REFCLK clock, or even internal oscillator.
Currently supported is only the first option. Add support for external
REFCLK clock input in addition to that.
There is little difference between these options, except that in case
of MIPI DSI HS clock input, the HS clock are pre-divided by a fixed /4
divider before being fed to the PLL input, while in case of external
REFCLK, the RECLK clock are fed directly into the PLL input.
Per exceptionally poor documentation, the REFCLK must be in range of
10..154 MHz.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220801131747.183041-2-marex@denx.de
Marek Vasut [Mon, 1 Aug 2022 13:17:46 +0000 (15:17 +0200)]
dt-bindings: display: bridge: icn6211: Add support for external REFCLK
The ICN6211 is capable of deriving its internal PLL clock from either
MIPI DSI HS clock, external REFCLK clock, or even internal oscillator.
Currently supported is only the first option. Document support for
external REFCLK clock input in addition to that.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Rob Herring <robh@kernel.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: dri-devel@lists.freedesktop.org Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220801131747.183041-1-marex@denx.de
Marek Vasut [Mon, 1 Aug 2022 13:15:55 +0000 (15:15 +0200)]
drm: bridge: icn6211: Add and use hs_rate and lp_rate
Fill in hs_rate and lp_rate to struct mipi_dsi_device for this bridge and
adjust DSI input frequency calculations such that they expect the DSI host
to configure HS clock according to hs_rate.
This is an optimization for the DSI burst mode case. In case the DSI device
supports DSI burst mode, it is recommended to operate the DSI interface at
the highest possible HS clock frequency which the DSI device supports. This
permits the DSI host to send as short as possible bursts of data on the DSI
link and keep the DSI data lanes in LP mode otherwise, which reduces power
consumption.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220801131555.182969-1-marex@denx.de
Randy Dunlap [Tue, 23 Aug 2022 00:42:43 +0000 (17:42 -0700)]
drm: fix drm_mipi_dbi build errors
drm_mipi_dbi needs lots of DRM_KMS_HELPER support, so select
that Kconfig symbol like it is done is most other uses, and
the way that it was before MIPS_DBI was moved from tinydrm
to its core location.
Fixes these build errors:
ld: drivers/gpu/drm/drm_mipi_dbi.o: in function `mipi_dbi_buf_copy':
drivers/gpu/drm/drm_mipi_dbi.c:205: undefined reference to `drm_gem_fb_get_obj'
ld: drivers/gpu/drm/drm_mipi_dbi.c:211: undefined reference to `drm_gem_fb_begin_cpu_access'
ld: drivers/gpu/drm/drm_mipi_dbi.c:215: undefined reference to `drm_gem_fb_vmap'
ld: drivers/gpu/drm/drm_mipi_dbi.c:222: undefined reference to `drm_fb_swab'
ld: drivers/gpu/drm/drm_mipi_dbi.c:224: undefined reference to `drm_fb_memcpy'
ld: drivers/gpu/drm/drm_mipi_dbi.c:227: undefined reference to `drm_fb_xrgb8888_to_rgb565'
ld: drivers/gpu/drm/drm_mipi_dbi.c:235: undefined reference to `drm_gem_fb_vunmap'
ld: drivers/gpu/drm/drm_mipi_dbi.c:237: undefined reference to `drm_gem_fb_end_cpu_access'
ld: drivers/gpu/drm/drm_mipi_dbi.o: in function `mipi_dbi_dev_init_with_formats':
ld: drivers/gpu/drm/drm_mipi_dbi.o:/X64/../drivers/gpu/drm/drm_mipi_dbi.c:469: undefined reference to `drm_gem_fb_create_with_dirty'
Fixes: 28a6325c981c ("drm/tinydrm: Move mipi-dbi") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Dillon Min <dillon.minfei@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220823004243.11596-1-rdunlap@infradead.org
Randy Dunlap [Tue, 23 Aug 2022 00:42:27 +0000 (17:42 -0700)]
drm/panel: use 'select' for Ili9341 panel driver helpers
Use 'select' instead of 'depends on' for DRM helpers for the
Ilitek ILI9341 panel driver.
This is what is done in the vast majority of other cases and
this makes it possible to fix a build error with drm_mipi_dbi.
Fixes: 1cd67b63abaf ("drm/panel: Add ilitek ili9341 panel driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Dillon Min <dillon.minfei@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220823004227.10820-1-rdunlap@infradead.org
Vivek Kasireddy [Thu, 25 Aug 2022 06:35:22 +0000 (23:35 -0700)]
udmabuf: Set ubuf->sg = NULL if the creation of sg table fails
When userspace tries to map the dmabuf and if for some reason
(e.g. OOM) the creation of the sg table fails, ubuf->sg needs to be
set to NULL. Otherwise, when the userspace subsequently closes the
dmabuf fd, we'd try to erroneously free the invalid sg table from
release_udmabuf resulting in the following crash reported by syzbot:
Danilo Krummrich [Wed, 24 Aug 2022 16:13:24 +0000 (18:13 +0200)]
drm/vc4: hdmi: unlock mutex when device is unplugged
In vc4_hdmi_encoder_{pre,post}_crtc_enable() commit 8250f13eb1d0
("drm/vc4: hdmi: Protect device resources after removal") missed to
unlock the mutex before returning due to drm_dev_enter() indicating the
device being unplugged.
Lyude Paul [Wed, 17 Aug 2022 19:38:46 +0000 (15:38 -0400)]
drm/display/dp_mst: Move all payload info into the atomic state
Now that we've finally gotten rid of the non-atomic MST users leftover in
the kernel, we can finally get rid of all of the legacy payload code we
have and move as much as possible into the MST atomic state structs. The
main purpose of this is to make the MST code a lot less confusing to work
on, as there's a lot of duplicated logic that doesn't really need to be
here. As well, this should make introducing features like fallback link
retraining and DSC support far easier.
Since the old payload code was pretty gnarly and there's a Lot of changes
here, I expect this might be a bit difficult to review. So to make things
as easy as possible for reviewers, I'll sum up how both the old and new
code worked here (it took me a while to figure this out too!).
The old MST code basically worked by maintaining two different payload
tables - proposed_vcpis, and payloads. proposed_vcpis would hold the
modified payload we wanted to push to the topology, while payloads held the
payload table that was currently programmed in hardware. Modifications to
proposed_vcpis would be handled through drm_dp_allocate_vcpi(),
drm_dp_mst_deallocate_vcpi(), and drm_dp_mst_reset_vcpi_slots(). Then, they
would be pushed via drm_dp_mst_update_payload_step1() and
drm_dp_mst_update_payload_step2().
Furthermore, it's important to note how adding and removing VC payloads
actually worked with drm_dp_mst_update_payload_step1(). When a VC payload
is removed from the VC table, all VC payloads which come after the removed
VC payload's slots must have their time slots shifted towards the start of
the table. The old code handles this by looping through the entire payload
table and recomputing the start slot for every payload in the topology from
scratch. While very much overkill, this ends up doing the right thing
because we always order the VCPIs for payloads from first to last starting
timeslot.
It's important to also note that drm_dp_mst_update_payload_step2() isn't
actually limited to updating a single payload - the driver can use it to
queue up multiple payload changes so that as many of them can be sent as
possible before waiting for the ACT. This is -technically- not against
spec, but as Wayne Lin has pointed out it's not consistently implemented
correctly in hubs - so it might as well be.
drm_dp_mst_update_payload_step2() is pretty self explanatory and basically
the same between the old and new code, save for the fact we don't have a
second step for deleting payloads anymore -and thus rename it to
drm_dp_mst_add_payload_step2().
The new payload code stores all of the current payload info within the MST
atomic state and computes as much of the state as possible ahead of time.
This has the one exception of the starting timeslots for payloads, which
can't be determined at atomic check time since the starting time slots will
vary depending on what order CRTCs are enabled in the atomic state - which
varies from driver to driver. These are still stored in the atomic MST
state, but are only copied from the old MST state during atomic commit
time. Likewise, this is when new start slots are determined.
Adding/removing payloads now works much more closely to how things are
described in the spec. When we delete a payload, we loop through the
current list of payloads and update the start slots for any payloads whose
time slots came after the payload we just deleted. Determining the starting
time slots for new payloads being added is done by simply keeping track of
where the end of the VC table is in
drm_dp_mst_topology_mgr->next_start_slot. Additionally, it's worth noting
that we no longer have a single update_payload() function. Instead, we now
have drm_dp_mst_add_payload_step1|2() and drm_dp_mst_remove_payload(). As
such, it's now left it up to the driver to figure out when to add or remove
payloads. The driver already knows when it's disabling/enabling CRTCs, so
it also already knows when payloads should be added or removed.
Changes since v1:
* Refactor around all of the completely dead code changes that are
happening in amdgpu for some reason when they really shouldn't even be
there in the first place… :\
* Remove mention of sending one ACT per series of payload updates. As Wayne
Lin pointed out, there are apparently hubs on the market that don't work
correctly with this scheme and require a separate ACT per payload update.
* Fix accidental drop of mst_mgr.lock - Wayne Lin
* Remove mentions of allowing multiple ACT updates per payload change,
mention that this is a result of vendors not consistently supporting this
part of the spec and requiring a unique ACT for each payload change.
* Get rid of reference to drm_dp_mst_port in DC - turns out I just got
myself confused by DC and we don't actually need this.
Changes since v2:
* Get rid of fix for not sending payload deallocations if ddps=0 and just
go back to wayne's fix
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-18-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:45 +0000 (15:38 -0400)]
drm/radeon: Drop legacy MST support
Right now, radeon is technically the only non-atomic driver still making
use of the MST helpers - and thus the final user of all of the legacy MST
helpers. Originally I was going to look into seeing if we could move legacy
MST into the radeon driver itself, however:
* SI and CIK both can use amdgpu, which still supports MST
* It currently doesn't work according to my own testing. I'm sure with some
troubleshooting we could likely fix it, but that brings me to point #2:
* It was never actually enabled by default, and is still marked as
experimental in the module parameter description
* If people were using it, someone probably would have probably seen a bug
report about how it is currently not functional by now. That certainly
doesn't appear to be the case, since before getting access to my own
hardware I had to go out of my way to try finding someone to help test
whether this legacy MST code even works - even amongst AMD employees.
* Getting rid of this code and only having atomic versions of the MST
helpers to maintain is likely going to be a lot easier in the long run,
and will make it a lot easier for others contributing to this code to
follow along with what's happening.
FWIW - if anyone still wants this code to be in the tree and has a good
idea of how to support this without needing to maintain the legacy MST
helpers (trying to move them would probably be acceptable), I'm happy to
suggestions. But my hope is that we can just drop this code and forget
about it. I've already run this idea by Harry Wentland and Alex Deucher a
few times as well.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-17-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:44 +0000 (15:38 -0400)]
drm/display/dp_mst: Maintain time slot allocations when deleting payloads
Currently, we set drm_dp_atomic_payload->time_slots to 0 in order to
indicate that we're about to delete a payload in the current atomic state.
Since we're going to be dropping all of the legacy code for handling the
payload table however, we need to be able to ensure that we still keep
track of the current time slot allocations for each payload so we can reuse
this info when asking the root MST hub to delete payloads. We'll also be
using it to recalculate the start slots of each VC.
So, let's keep track of the intent of a payload in drm_dp_atomic_payload by
adding ->delete, which we set whenever we're planning on deleting a payload
during the current atomic commit.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-16-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:43 +0000 (15:38 -0400)]
drm/display/dp_mst: Drop all ports from topology on CSNs before queueing link address work
We want to start cutting down on all of the places that we use port
validation, so that ports may be removed from the topology as quickly as
possible to minimize the number of errors we run into as a result of being
out of sync with the current topology status. This isn't a very typical
scenario and I don't think I've ever even run into it - but since the next
commit is going to make some changes to payload updates depending on their
hotplug status I think it's a probably good idea to take precautions.
Let's do this with CSNs by moving some code around so that we only queue
link address probing work at the end of handling all CSNs - allowing us to
make sure we drop as many topology references as we can beforehand.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-15-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:42 +0000 (15:38 -0400)]
drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions
There's another kind of situation where we could potentially race with
nonblocking modesets and MST, especially if we were to only use the locking
provided by atomic modesetting:
* Display 1 begins as enabled on DP-1 in SST mode
* Display 1 switches to MST mode, exposes one sink in MST mode
* Userspace does non-blocking modeset to disable the SST display
* Userspace does non-blocking modeset to enable the MST display with a
different CRTC, but the SST display hasn't been fully taken down yet
* Execution order between the last two commits isn't guaranteed since they
share no drm resources
We can fix this however, by ensuring that we always pull in the atomic
topology state whenever a connector capable of driving an MST display
performs its atomic check - and then tracking CRTC commits happening on the
SST connector in the MST topology state. So, let's add some simple helpers
for doing that and hook them up in various drivers.
v2:
* Use intel_dp_mst_source_support() to check for MST support in i915, fixes
CI failures
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-14-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:41 +0000 (15:38 -0400)]
drm/nouveau/kms: Pull mst state in for all modesets
Since we're going to be relying on atomic locking for payloads now (and the
MST mgr needs to track CRTCs), pull in the topology state for all modesets
in nv50_msto_atomic_check().
Lyude Paul [Wed, 17 Aug 2022 19:38:40 +0000 (15:38 -0400)]
drm/nouveau/kms: Cache DP encoders in nouveau_connector
Post-NV50, the only kind of encoder you'll find for DP connectors on Nvidia
GPUs are SORs (serial output resources). Because SORs have fixed
associations with their connectors, we can correctly assume that any DP
connector on a nvidia GPU will have exactly one SOR encoder routed to it
for DisplayPort.
Since we're going to need to be able to retrieve this fixed SOR DP encoder
much more often as a result of hooking up MST helpers for tracking
SST<->MST transitions in atomic states, let's simply cache this encoder in
nouveau_connector for any DP connectors on the system to avoid looking it
up each time. This isn't safe for NV50 since PIORs then come into play,
however there's no code pre-NV50 that would need to look this up anyhow -
so it's not really an issue.
Lyude Paul [Wed, 17 Aug 2022 19:38:39 +0000 (15:38 -0400)]
drm/display/dp_mst: Fix modeset tracking in drm_dp_atomic_release_vcpi_slots()
Currently with the MST helpers we avoid releasing payloads _and_ avoid
pulling in the MST state if there aren't any actual payload changes. While
we want to keep the first step, we need to now make sure that we're always
pulling in the MST state on all modesets that can modify payloads - even if
the resulting payloads in the atomic state are identical to the previous
ones.
This is mainly to make it so that if a CRTC is still assigned to a
connector but is set to DPMS off, the CRTC still holds it's payload
allocation in the atomic state and still appropriately pulls in the MST
state for commit tracking. Otherwise, we'll occasionally forget to update
MST payloads from changes caused by non-atomic DPMS changes. Doing this
also allows us to track bandwidth limitations in a state correctly even
between DPMS changes, so that there's no chance of a simple ->active change
being rejected by the atomic check.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-11-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:38 +0000 (15:38 -0400)]
drm/display/dp_mst: Don't open code modeset checks for releasing time slots
I'm not sure why, but at the time I originally wrote the find/release time
slot helpers I thought we should avoid keeping modeset tracking out of the
MST helpers. In retrospect though there's no actual good reason to do
this, and the logic has ended up being identical across all the drivers
using the helpers. Also, it needs to be fixed anyway so we don't break
things when going atomic-only with MST.
So, let's just move this code into drm_dp_atomic_release_time_slots() and
stop open coding it.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-10-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:37 +0000 (15:38 -0400)]
drm/display/dp_mst: Add nonblocking helpers for DP MST
As Daniel Vetter pointed out, if we only use the atomic modesetting locks
with MST it's technically possible for a driver with non-blocking modesets
to race when it comes to MST displays - as we make the mistake of not doing
our own CRTC commit tracking in the topology_state object.
This could potentially cause problems if something like this happens:
* User starts non-blocking commit to disable CRTC-1 on MST topology 1
* User starts non-blocking commit to enable CRTC-2 on MST topology 1
There's no guarantee here that the commit for disabling CRTC-2 will only
occur after CRTC-1 has finished, since neither commit shares a CRTC - only
the private modesetting object for MST. Keep in mind this likely isn't a
problem for blocking modesets, only non-blocking.
So, begin fixing this by keeping track of which CRTCs on a topology have
changed by keeping track of which CRTCs we release or allocate timeslots
on. As well, add some helpers for:
* Setting up the drm_crtc_commit structs in the ->commit_setup hook
* Waiting for any CRTC dependencies from the previous topology state
v2:
* Use drm_dp_mst_atomic_setup_commit() directly - Jani
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-9-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:36 +0000 (15:38 -0400)]
drm/display/dp_mst: Add helper for finding payloads in atomic MST state
We already open-code this quite often, and will be iterating through
payloads even more once we've moved all of the payload tracking into the
atomic state. So, let's add a helper for doing this.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-8-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:35 +0000 (15:38 -0400)]
drm/display/dp_mst: Add some missing kdocs for atomic MST structs
Since we're about to start adding some stuff here, we may as well fill in
any missing documentation that we forgot to write.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-7-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:34 +0000 (15:38 -0400)]
drm/display/dp_mst: Fix confusing docs for drm_dp_atomic_release_time_slots()
For some reason we mention returning 0 if "slots have been added back to
drm_dp_mst_topology_state->avail_slots". This is totally misleading,
avail_slots is simply for figuring out the total number of slots available
in total on the topology and has no relation to the current payload
allocations.
So, let's get rid of that comment.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-6-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:33 +0000 (15:38 -0400)]
drm/display/dp_mst: Call them time slots, not VCPI slots
VCPI is only sort of the correct term here, originally the majority of this
code simply referred to timeslots vaguely as "slots" - and since I started
working on it and adding atomic functionality, the name "VCPI slots" has
been used to represent time slots.
Now that we actually have consistent access to the DisplayPort spec thanks
to VESA, I now know this isn't actually the proper term - as the
specification refers to these as time slots.
Since we're trying to make this code as easy to figure out as possible,
let's take this opportunity to correct this nomenclature and call them by
their proper name - timeslots. Likewise, we rename various functions
appropriately, along with replacing references in the kernel documentation
and various debugging messages.
It's important to note that this patch series leaves the legacy MST code
untouched for the most part, which is fine since we'll be removing it soon
anyhow. There should be no functional changes in this series.
v2:
* Add note that Wayne Lin from AMD suggested regarding slots being between
the source DP Tx and the immediate downstream DP Rx
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-5-lyude@redhat.com
In retrospect, the name I chose for this originally is confusing, as
there's a lot more info in here then just the VCPI. This really should be
called a payload. Let's make it more obvious that this is meant to be
related to the atomic state and is about payloads by renaming it to
drm_dp_mst_atomic_payload. Also, rename various variables throughout the
code that use atomic payloads.
Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-4-lyude@redhat.com
Lyude Paul [Wed, 17 Aug 2022 19:38:31 +0000 (15:38 -0400)]
drm/amdgpu/dm/mst: Rename get_payload_table()
This function isn't too confusing if you see the comment around the
call-site for it, but if you don't then it's not at all obvious this is
meant to copy DRM's payload table over to DC's internal state structs.
Seeing this function before finding that comment definitely threw me into a
loop a few times.
So, let's rename this to make it's purpose more obvious regardless of where
in the code you are.
Just to make this more clear to outside contributors that these are
DC-specific structs, as this also threw me into a loop a number of times
before I figured out the purpose of this.
We are adding two new callbacks to ttm resource manager
function to handle intersection and compatibility of
placement and resources.
v2: move the amdgpu and ttm_range_manager changes to
separate patches (Christian)
v3: rename "intersect" to "intersects" (Matthew)
v4: move !place check to the !res if and return false
in ttm_resource_compatible() function (Christian)
v5: move bits of code from patch number 6 to avoid
temporary driver breakup (Christian)
drm/msm: Make .remove and .shutdown HW shutdown consistent
Drivers' .remove and .shutdown callbacks are executed on different code
paths. The former is called when a device is removed from the bus, while
the latter is called at system shutdown time to quiesce the device.
This means that some overlap exists between the two, because both have to
take care of properly shutting down the hardware. But currently the logic
used in these two callbacks isn't consistent in msm drivers, which could
lead to kernel panic.
For example, on .remove the component is deleted and its .unbind callback
leads to the hardware being shutdown but only if the DRM device has been
marked as registered.
That check doesn't exist in the .shutdown logic and this can lead to the
driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't
been properly initialized.
A situation like this can happen if drivers for expected sub-devices fail
to probe, since the .bind callback will never be executed. If that is the
case, drm_atomic_helper_shutdown() will attempt to take mutexes that are
only initialized if drm_mode_config_init() is called during a device bind.
This bug was attempted to be fixed in commit 80970dd01d8d ("drm/msm: fix
shutdown hook in case GPU components failed to bind"), but unfortunately
it still happens in some cases as the one mentioned above, i.e:
drmm_universal_plane_alloc() already registers drm_plane_cleanup() as
managed release action via drmm_add_action_or_reset(). Hence,
drm_plane_cleanup() should not be set as drm_plane_funcs.destroy hook.
Lyude Paul [Tue, 16 Aug 2022 18:04:36 +0000 (14:04 -0400)]
drm/nouveau/kms/nv140-: Disable interlacing
As it turns out: while Nvidia does actually have interlacing knobs on their
GPU still pretty much no current GPUs since Volta actually support it.
Trying interlacing on these GPUs will result in NVDisplay being quite
unhappy like so:
nouveau 0000:1f:00.0: disp: chid 0 stat 00004802 reason 4 [INVALID_ARG] mthd 2008 data 00000001 code 00080000
nouveau 0000:1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0200 data 00000001 code 00000001
So let's fix this by following the same behavior Nvidia's driver does and
disable interlacing entirely.
drm/amdgpu_dm: Rely on split out luminance calculation function
Luminance range calculation was split out into drm_edid.c and is now
part of edid parsing. Rely on values calculated during edid parsing and
use these for caps->aux_max_input_signal and caps->aux_min_input_signal.
v2: Use values calculated during edid parsing
Cc: Roman Li <roman.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220719095700.14923-3-jouni.hogander@intel.com
drm: New function to get luminance range based on static hdr metadata
Split luminance min/max calculation using static hdr metadata from
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:update_connector_ext_caps
into drm/drm_edid.c and use it during edid parsing. Calculated range is
stored into connector->display_info->luminance_range.
Add new data structure (drm_luminance_range_inf) to store luminance range
calculated using data from EDID's static hdr metadata block. Add this new
struct as a part of drm_display_info struct.
v3: Squashed adding drm_luminance_range_info patch here
v2: Calculate range during edid parsing
Cc: Roman Li <roman.li@amd.com> Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220719095700.14923-2-jouni.hogander@intel.com
Liang He [Mon, 11 Jul 2022 13:15:50 +0000 (21:15 +0800)]
drm:pl111: Add of_node_put() when breaking out of for_each_available_child_of_node()
The reference 'child' in the iteration of for_each_available_child_of_node()
is only escaped out into a local variable which is only used to check
its value. So we still need to the of_node_put() when breaking of the
for_each_available_child_of_node() which will automatically increase
and decrease the refcount.
Lucas Stach [Wed, 6 Jul 2022 13:28:12 +0000 (15:28 +0200)]
drm/bridge: tc358767: disable main link PHYs on main link disable
Disable the main link PHYs and put them into reset when the main link
is disabled. When the PHYs stay enabled while the rest of the DP link
circuits are disabled there is some noise on the data lanes, which some
displays try to lock onto, waking them up from their low power state.
Lucas Stach [Wed, 6 Jul 2022 13:28:11 +0000 (15:28 +0200)]
drm/bridge: tc358767: increase CLRSIPO count
The current CLRSIPO count is marginal and does not work with high
DSI clock rates. Increase it a bit to allow the DSI link to work at
up to 1Gbps lane speed.
There is no need to enforce a specific sync signal polarity on the
DPI interface, as we can simply tell the TC358767 which polarities
it should expect on the input interface.
Takashi Iwai [Thu, 4 Aug 2022 07:58:26 +0000 (09:58 +0200)]
drm/udl: Replace BUG_ON() with WARN_ON()
BUG_ON() is a tasteless choice as a sanity check for a driver like UDL
that isn't really a core code. Replace with WARN_ON() and proper
error handling instead.
Takashi Iwai [Thu, 4 Aug 2022 07:58:25 +0000 (09:58 +0200)]
drm/udl: Kill pending URBs at suspend and disconnect
At both suspend and disconnect, we should rather cancel the pending
URBs immediately. For the suspend case, the display will be turned
off, so it makes no sense to process the rendering. And for the
disconnect case, the device may be no longer accessible, hence we
shouldn't do any submission.
Takashi Iwai [Thu, 4 Aug 2022 07:58:24 +0000 (09:58 +0200)]
drm/udl: Sync pending URBs at suspend / disconnect
We need to wait for finishing to process the all URBs after disabling
the pipe; otherwise pending URBs may stray at suspend/resume, leading
to a possible memory corruption in a worst case.
Takashi Iwai [Thu, 4 Aug 2022 07:58:23 +0000 (09:58 +0200)]
drm/udl: Replace semaphore with a simple wait queue
UDL driver uses a semaphore for controlling the emptiness of FIFO in a
slightly funky way. This patch replaces it with a wait queue and
controls the emptiness with the standard wait_event*() macro instead,
which is a more straightforward implementation.
While we are at it, drop the dead code for delayed semaphore down,
too.
projects / kernel.git / log