IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
[ Upstream commit 2f3a1273862cb82cca227630cc7f04ce0c94b6bb ]
Looks like that we're accidentally dropping a pretty important return code
here. For some reason, we just return -EINVAL if we fail to get the MST
topology state. This is wrong: error codes are important and should never
be squashed without being handled, which here seems to have the potential
to cause a deadlock.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs")
Cc: <stable@vger.kernel.org> # v5.6+
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2ac6cdd581f48c8f68747156fde5868486a44985 ]
drm_dp_dpcd_read returns the number of bytes read. The previous code
would print garbage on DPCD error, and would exit with on error on
success.
Signed-off-by: Simon Ser <contact@emersion.fr>
Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/473500/
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6e03b13cc7d9427c2c77feed1549191015615202 upstream.
drm_dp_mst_get_edid call kmemdup to create mst_edid. So mst_edid need to be
freed after use.
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20220516032042.13166-1-hbh25y@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 92bd92c44d0d9be5dcbcda315b4be4b909ed9740 upstream.
Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing +
selftests") added some debug code for sideband message tracing. But
it seems to have unintentionally changed the behavior on sideband message
failure. It catches and returns failure only if DRM_UT_DP is enabled.
Otherwise it ignores the error code and returns success. So on an MST
unplug, the caller is unaware that the clear payload message failed and
ends up waiting for 4 seconds for the response. Fixes the issue by
returning the proper error code.
Changes in V2:
-- Revise commit text as review comment
-- add Fixes text
Changes in V3:
-- remove "unlikely" optimization
Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests")
Cc: <stable@vger.kernel.org> # v5.5+
Signed-off-by: Rajkumar Subbiah <rsubbia@codeaurora.org>
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1625585434-9562-1-git-send-email-khsieh@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream.
Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by
ports in stale topology") added to calls to drm_dbg_kms() but it
missed the first parameter, the drm device breaking the build.
Fixes: 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology")
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: stable@vger.kernel.org
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210616194415.36926-1-jose.souza@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3769e4c0af5b82c8ea21d037013cb9564dfaa51f upstream.
[Why]
After unplug/hotplug hub from the system, userspace might start to
clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi()
to release stale VCPI of those ports which are not relating to current
topology, we have chane to wrongly clear active payload table entry for
current topology.
E.g.
We have allocated VCPI 1 in current payload table and we call
drm_dp_mst_deallocate_vcpi() to clean VCPI 1 in stale topology. In
drm_dp_mst_deallocate_vcpi(), it will call drm_dp_mst_put_payload_id()
tp put VCPI 1 and which means ID 1 is available again. Thereafter, if we
want to allocate a new payload stream, it will find ID 1 is available by
drm_dp_mst_assign_payload_id(). However, ID 1 is being used
[How]
Check target sink is relating to current topology or not before doing
any payload table update.
Searching upward to find the target sink's relevant root branch device.
If the found root branch device is not the same root of current
topology, don't update payload table.
Changes since v1:
* Change debug macro to use drm_dbg_kms() instead
* Amend the commit message to add Cc tag.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-3-Wayne.Lin@amd.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream.
[Why]
When we receive CSN message to notify one port is disconnected, we will
implicitly set its corresponding num_slots to 0. Later on, we will
eventually call drm_dp_update_payload_part1() to arrange down streams.
In drm_dp_update_payload_part1(), we iterate over all proposed_vcpis[]
to do the update. Not specific to a target sink only. For example, if we
light up 2 monitors, Monitor_A and Monitor_B, and then we unplug
Monitor_B. Later on, when we call drm_dp_update_payload_part1() to try
to update payload for Monitor_A, we'll also implicitly clean payload for
Monitor_B at the same time. And finally, when we try to call
drm_dp_update_payload_part1() to clean payload for Monitor_B, we will do
nothing at this time since payload for Monitor_B has been cleaned up
previously.
For StarTech 1to3 DP hub, it seems like if we didn't update DPCD payload
ID table then polling for "ACT Handled"(BIT_1 of DPCD 002C0h) will fail
and this polling will last for 3 seconds.
Therefore, guess the best way is we don't set the proposed_vcpi[]
diretly. Let user of these herlper functions to set the proposed_vcpi
directly.
[How]
1. Revert commit 7617e9621bf2 ("drm/dp_mst: clear time slots for ports
invalid")
2. Tackle the issue in previous commit by skipping those trasient
proposed VCPIs. These stale VCPIs shoulde be explicitly cleared by
user later on.
Changes since v1:
* Change debug macro to use drm_dbg_kms() instead
* Amend the commit message to add Fixed & Cc tags
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Fixes: 7617e9621bf2 ("drm/dp_mst: clear time slots for ports invalid")
Cc: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.5+
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210616035501.3776-2-Wayne.Lin@amd.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d919d3d6cdb31d0f9fe06c880f683a24f2838813 upstream.
[Why & How]
According to DP spec, CLEAR_PAYLOAD_ID_TABLE is a path broadcast request
message and current implementation is incorrect. Fix it.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224101521.6713-3-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 419e91ea3143bf26991442465ac64d9461e98d96 upstream.
[Why & How]
According to DP spec, broadcast message LCT equals to 1 and LCR equals
to 6. Current implementation is incorrect. Fix it.
In addition, revise a bit the hdr->rad handling to include broadcast
case.
Signed-off-by: Wayne Lin <Wayne.Lin@amd.com>
Cc: stable@vger.kernel.org
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224101521.6713-2-Wayne.Lin@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4b8878eefa0a3b65e2e016db49014ea66fb9fd45 ]
Caching EDIDs for physical ports prevents updating the EDID if a port
gets reconnected via a Connection Status Notification message, fix this.
Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
Cc: Wayne Lin <Wayne.Lin@amd.com>
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/20210201120145.350258-2-imre.deak@intel.com
(cherry picked from commit 468091531c2e5c49f55d8c6f1d036ce997d24e13)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 873e5bb9fbd99e4a26c448b5c7af942a6d7aa60d upstream.
Reporting a port as connected if nothing is attached to them leads to
any i2c transactions on this port trying to use an uninitialized i2c
adapter, fix this.
Let's account for this case even if branch devices have no good reason
to report a port as plugged with their peer device type set to 'none'.
Fixes: db1a07956968 ("drm/dp_mst: Handle SST-only branch device case")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2987
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1963
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v5.5+
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reported-by: Thiago Macieira <gitlab@gitlab.freedesktop.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210201120145.350258-1-imre.deak@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 83404d581471775f37f85e5261ec0d09407d8bed upstream.
This function will be needed by the next patch where the driver
calculates the BW based on driver specific parameters, so export it.
At the same time sanitize the function params, passing the more natural
link rate instead of the encoding of the same rate.
v2:
- Fix function documentation. (Lyude)
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: <stable@vger.kernel.org>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210125173636.1733812-1-imre.deak@intel.com
(cherry picked from commit a321fc2b4e60fc1b39517d26c8104351636a6062)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- dev: More devm_drm convertions and removal of drm_dev_init
Driver Changes:
- i915: selftests improvements
- panfrost: support for Amlogic SoC
- vc4: one fix
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX2jGxQAKCRDj7w1vZxhR
xR3DAQCiZOnaxVcY49iG4343Z1aHHaIEShbnB0bDdaWstn7kiQD/UXBXUoOSFoFQ
FkTsW31JsdXNnWP5e6/eJd2Lb6waVAA=
=VlsU
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2020-09-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.10:
UAPI Changes:
Cross-subsystem Changes:
- virtio: Merged a PR for patches that will affect drm/virtio
Core Changes:
- dev: More devm_drm convertions and removal of drm_dev_init
- atomic: Split out drm_atomic_helper_calc_timestamping_constants of
drm_atomic_helper_update_legacy_modeset_state
- ttm: More rework
Driver Changes:
- i915: selftests improvements
- panfrost: support for Amlogic SoC
- vc4: one fix
- tree-wide: conversions to devm_drm_dev_alloc,
- ast: simplifications of the atomic modesetting code
- panfrost: multiple fixes
- vc4: multiple fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200921152956.2gxnsdgxmwhvjyut@gilmour.lan
UAPI Changes:
None
Cross-subsystem Changes:
* Moves a bunch of miscellaneous DP code from the i915 driver into a set
of shared DRM DP helpers
Core Changes:
* New DRM DP helpers (see above)
Driver Changes:
* Implements usage of the aforementioned DP helpers in the nouveau
driver, along with some other various HPD related cleanup for nouveau
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/11e59ebdea7ee4f46803a21fe9b21443d2b9c401.camel@redhat.com
For DP MST outputs, the i2c device currently only supports transfers
that can be implemented using remote i2c reads. Such transfers must
consist of zero or more write transactions followed by one read
transaction. DDC/CI commands require standalone write transactions and
hence aren't supported.
Since each remote i2c write is handled as a separate transfer, remote
i2c writes can support transfers consisting of write transactions, where
all but the last have I2C_M_STOP set. According to the DDC/CI 1.1
standard, DDC/CI commands only require a single write or read
transaction in a transfer, so this is sufficient.
For i2c transfers meeting the above criteria, generate and send a remote
i2c write message for each transaction. Add the trivial remote i2c write
reply parsing support so remote i2c write acks bubble up correctly.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/37
Signed-off-by: Sam McNally <sammc@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200727160225.1.I4e95a534de051551cd143e6cb83d4c5a9b0ad1cd@changeid
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
v5:
* Drop !!()
* Move drm_dp_has_mst() out of header
* Change name from drm_dp_has_mst() to drm_dp_read_mst_cap()
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-10-lyude@redhat.com
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl9C2tseHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGgXoH/AuyLuMWwukVjVAx
b2N2Ri0qFVyZWLky+uPqc4NkqJCbD/Rt2Kq8odLnJOrs2bXKpP5KrMl4sVqwSRr4
CSkHkpo4oglmIxe5ptoWmWjrvHm/KNDZd2PY8cehii5eXG+aS7g3rIYjSFlXzP+1
yndJ00H7CDOxHd/DngqfD+Sr7j76EM1iZE9316JR7TEu5o38I4Ipu6+3L3uFZVlf
M90SmymY6hM7AJAyuOrd79ffXQry9KvWMUYyRkYyDK8y9taOSzfdfpppk8q5cVB1
l4pcPNBiveRM3Yet7UAMb8FSz8OG0rPkkCsq8ALNU/UO91IDY832OUyLxXUpWlf6
ZWRP2HA=
=596f
-----END PGP SIGNATURE-----
Merge tag 'v5.9-rc2' into drm-misc-fixes
Backmerge requested by Tomi for a fix to omap inconsistent
locking state issue, and because we need at least v5.9-rc2 now.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[Why]
In certain cases the crtc can be NULL and returning -EINVAL causes
atomic check to fail when it shouln't. This leads to valid
configurations failing because atomic check fails.
[How]
Don't early return if crtc is null
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
[added stable cc]
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 8ec046716ca8 ("drm/dp_mst: Add helper to trigger modeset on affected DSC MST CRTCs")
Cc: <stable@vger.kernel.org> # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200814170140.24917-1-Bhawanpreet.Lakha@amd.com
drm_dp_mst_allocate_vcpi() invokes
drm_dp_mst_topology_get_port_validated(), which increases the refcount
of the "port".
These reference counting issues take place in two exception handling
paths separately. Either when “slots” is less than 0 or when
drm_dp_init_vcpi() returns a negative value, the function forgets to
reduce the refcnt increased drm_dp_mst_topology_get_port_validated(),
which results in a refcount leak.
Fix these issues by pulling up the error handling when "slots" is less
than 0, and calling drm_dp_mst_topology_put_port() before termination
when drm_dp_init_vcpi() returns a negative value.
Fixes: 1e797f556c61 ("drm/dp: Split drm_dp_mst_allocate_vcpi")
Cc: <stable@vger.kernel.org> # v4.12+
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200719154545.GA41231@xin-virtual-machine
UAPI Changes:
- Add DRM_MODE_TYPE_USERDEF for video modes specified in cmdline.
Cross-subsystem Changes:
- Assorted devicetree binding updates.
- Add might_sleep() to dma_fence_wait().
- Fix fbdev's get_user_pages_fast() handling, and use pin_user_pages.
- Small cleanup with IS_BUILTIN in video/fbdev drivers.
- Fix video/hdmi coding style for infoframe size.
Core Changes:
- Silence vblank output during init.
- Fix DP-MST corruption during send msg timeout.
- Clear leak in drm_gem_objecs_lookup().
- Make newlines work with force connector attribute.
- Fix module refcounting error in drm_encoder_slave, and use new i2c api.
- Header fix for drm_managed.c
- More struct_mutex removal for !legacy drivers:
- Remove gem_free_object()
- Removal of drm_gem_object_put_unlocked().
- Show current->comm alongside pid in debug printfs.
- Add drm_client_modeset_check() + drm_client_framebuffer_flush().
- Replace drm_fb_swab16 with drm_fb_swap that also supports 32-bits.
- Remove mode->vrefresh, and compactify drm_display_mode.
- Use drm_* macros for logging and warnings.
- Add WARN when drm_gem_get_pages is used on a private obj.
- Handle importing and imported dmabuf better in shmem helpers.
- Small fix for drm/mm hole size comparison, and remove invalid entry optimization.
- Add a drm/mm selftest.
- Set DSI connector type for DSI panels.
- Assorted small fixes and documentation updates.
- Fix DDI I2C device registration for MST ports, and flushing on destroy.
- Fix master_set return type, used by vmwgfx.
- Make the drm_set/drop_master ioctl symmetrical.
Driver Changes:
Allow iommu in the sun4i driver and use it for sun8i.
- Simplify backlight lookup for omap, amba-clcd and tilcdc.
- Hold reg_lock for rockchip.
- Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice.
- Small assorted fixes to tilcdc, vc4, i915, omap, fbdev/sm712fb, fbdev/pxafb, console/newport_con, msm, virtio, udl, malidp, hdlcd, bridge/ti-sn65dsi86, panfrost.
- Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers.
- Add support for KOE Allow iommu in the sun4i driver and use it for sun8i.
- Simplify backlight lookup for omap, amba-clcd and tilcdc.
- Hold reg_lock for rockchip.
- Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice.
- Small assorted fixes to tilcdc, vc4 (multiple), i915.
- Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers.
- Add support for KOE TX26D202VM0BWA panel.
- Use GEM CMA functions in arc, arm, atmel-hlcdc, fsi-dcu, hisilicon, imx, ingenic, komeda, malidp, mcde, meson, msxfb, rcar-du, shmobile, stm, sti, tilcdc, tve200, zte.
- Remove gem_print_info.
- Improve gem_create_object_helper so udl can use shmem helpers.
- Convert vc4 dt bindings to schemas, and add clock properties.
- Device initialization cleanups for mgag200.
- Add a workaround to fix DP-MST short pulses handling on broken hardware in i915.
- Allow build test compiling arm drivers.
- Use managed pci functions in mgag200 and ast.
- Use dev_groups in malidp.
- Add per pixel alpha support for PX30 VOP in rockchip.
- Silence deferred probe logs in panfrost.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl7s11IACgkQ/lWMcqZw
E8OYnQ/+K4ZGpU11t4IzXCyJYis2ZPYs/FlJ2BWXH89YhOckN1e1tq7uDBzUE8qK
Hlz0gvH5C0WXR/PWqNglPXW7INwc0LtC8PSmvS4vvrZQBaJ2bvf19y7dROqJbR0E
xTUje95eq+10H9TysCRTf1osIUuZIoR0gRna22pb+nplKVBkqsQPyPT21AWq4fN0
H/LQfKNfAAHtKwvfsMsuG2U+ZTyTYo7Xi6UP413WAqDmzhewnCm5plifM29m5LhB
9BmKk0/1pL3KzZuCQvcZw4kYUjXYsgoOqD4hkMAOLsjyf6Ad5zbPB5YTxNK0C+NU
N04aHWvkRVl62A6rehgXdS5GJ3M4ORPDpIV9zQCVxMZV/886JLTGA1Wb+b3+umdk
t5M40kzgYQTDqdSwFoCDCd1tFpEjnLbE7E+eM89AyzTPOxZowrVS0No1dJA3+ST/
g7JOdDu2Zg7VAar6zByow0pMppikZro9H1mpSnk+WHbYNF3dFmW3QHKRuxoRt+Ee
l5G52LylwH3ZMPebGH9XB4cWtAUAHOsioe3CS/PKzGeUWNlUK29AqDCCBQmUdbcT
HNm5/Yygdg3rRjkDBuUI0I/pifxMYvm+28eNfNGjwq5To9ABXPNONQCEBH6rke+S
d1Z2nMmiVDf2MqhpkJppTKtHdMz13IGyZykXB7CdGnAu6k5s59c=
=ZmKI
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2020-06-19' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v5.9:
UAPI Changes:
- Add DRM_MODE_TYPE_USERDEF for video modes specified in cmdline.
Cross-subsystem Changes:
- Assorted devicetree binding updates.
- Add might_sleep() to dma_fence_wait().
- Fix fbdev's get_user_pages_fast() handling, and use pin_user_pages.
- Small cleanup with IS_BUILTIN in video/fbdev drivers.
- Fix video/hdmi coding style for infoframe size.
Core Changes:
- Silence vblank output during init.
- Fix DP-MST corruption during send msg timeout.
- Clear leak in drm_gem_objecs_lookup().
- Make newlines work with force connector attribute.
- Fix module refcounting error in drm_encoder_slave, and use new i2c api.
- Header fix for drm_managed.c
- More struct_mutex removal for !legacy drivers:
- Remove gem_free_object()
- Removal of drm_gem_object_put_unlocked().
- Show current->comm alongside pid in debug printfs.
- Add drm_client_modeset_check() + drm_client_framebuffer_flush().
- Replace drm_fb_swab16 with drm_fb_swap that also supports 32-bits.
- Remove mode->vrefresh, and compactify drm_display_mode.
- Use drm_* macros for logging and warnings.
- Add WARN when drm_gem_get_pages is used on a private obj.
- Handle importing and imported dmabuf better in shmem helpers.
- Small fix for drm/mm hole size comparison, and remove invalid entry optimization.
- Add a drm/mm selftest.
- Set DSI connector type for DSI panels.
- Assorted small fixes and documentation updates.
- Fix DDI I2C device registration for MST ports, and flushing on destroy.
- Fix master_set return type, used by vmwgfx.
- Make the drm_set/drop_master ioctl symmetrical.
Driver Changes:
Allow iommu in the sun4i driver and use it for sun8i.
- Simplify backlight lookup for omap, amba-clcd and tilcdc.
- Hold reg_lock for rockchip.
- Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice.
- Small assorted fixes to tilcdc, vc4, i915, omap, fbdev/sm712fb, fbdev/pxafb, console/newport_con, msm, virtio, udl, malidp, hdlcd, bridge/ti-sn65dsi86, panfrost.
- Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers.
- Add support for KOE Allow iommu in the sun4i driver and use it for sun8i.
- Simplify backlight lookup for omap, amba-clcd and tilcdc.
- Hold reg_lock for rockchip.
- Add support for bridge gpio and lane reordering + polarity to ti-sn65dsi86, and fix clock choice.
- Small assorted fixes to tilcdc, vc4 (multiple), i915.
- Remove hw cursor support for mgag200, and use simple kms helper + shmem helpers.
- Add support for KOE TX26D202VM0BWA panel.
- Use GEM CMA functions in arc, arm, atmel-hlcdc, fsi-dcu, hisilicon, imx, ingenic, komeda, malidp, mcde, meson, msxfb, rcar-du, shmobile, stm, sti, tilcdc, tve200, zte.
- Remove gem_print_info.
- Improve gem_create_object_helper so udl can use shmem helpers.
- Convert vc4 dt bindings to schemas, and add clock properties.
- Device initialization cleanups for mgag200.
- Add a workaround to fix DP-MST short pulses handling on broken hardware in i915.
- Allow build test compiling arm drivers.
- Use managed pci functions in mgag200 and ast.
- Use dev_groups in malidp.
- Add per pixel alpha support for PX30 VOP in rockchip.
- Silence deferred probe logs in panfrost.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/001cd9a6-405d-4e29-43d8-354f53ae4e8b@linux.intel.com
Atm, a pending delayed destroy work during module removal will be
canceled, leaving behind MST ports, mstbs. Fix this by using a dedicated
workqueue which will be drained of requeued items as well when
destroying it.
v2:
- Check if wq is NULL before calling destroy_workqueue().
Cc: Lyude Paul <lyude@redhat.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200610134704.25270-1-imre.deak@intel.com
During the initial MST probing an MST port's I2C device will be
registered using the kdev of the DRM device as a parent. Later after MST
Connection Status Notifications this I2C device will be re-registered
with the kdev of the port's connector. This will also move
inconsistently the I2C device's sysfs entry from the DRM device's sysfs
dir to the connector's dir.
Fix the above by keeping the DRM kdev as the parent of the I2C device.
Ideally the connector's kdev would be used as a parent, similarly to
non-MST connectors, however that needs some more refactoring to ensure
the connector's kdev is already available early enough. So keep the
existing (initial) behavior for now.
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200607212522.16935-2-imre.deak@intel.com
Some TypeC -> native DP adapters, at least the Club 3D CAC-1557 adapter,
incorrectly filter out HPD short pulses with a duration less than
~540 usec, leading to MST probe failures.
According to the DP Standard 2.0 section 5.1.4:
- DP sinks should generate short pulses in the 500 usec -> 1 msec range
- DP sources should detect short pulses in the 250 usec -> 2 msec range
According to the DP Alt Mode on TypeC Standard section 3.9.2, adapters
should detect and forward short pulses according to how sources should
detect them as specified in the DP Standard (250 usec -> 2 msec).
Based on the above filtering out short pulses with a duration less than
540 usec is incorrect.
To make such adapters work add support for a driver polling on MST
inerrupt flags, and wire this up in the i915 driver. The sink can clear
an interrupt it raised after 110 msec if the source doesn't respond, so
use a 50 msec poll period to avoid missing an interrupt. Polling of the
MST interrupt flags is explicitly allowed by the DP Standard.
This fixes MST probe failures I saw using this adapter and a DELL U2515H
monitor.
v2:
- Fix the wait event timeout for the no-poll case.
v3 (Ville):
- Fix the short pulse duration limits in the commit log prescribed by the
DP Standard.
- Add code comment explaining why/how polling is used.
- Factor out a helper to schedule the port's hpd irq handler and move it
to the rest of hotplug handlers.
- Document the new MST callback.
- s/update_hpd_irq_state/poll_hpd_irq/
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200604184500.23730-2-imre.deak@intel.com
drivers/gpu/drm/drm_dp_mst_topology.c:2898:6: warning: symbol 'drm_dp_send_clear_payload_id_table' was not declared. Should it be static?
drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer
drivers/gpu/drm/drm_dp_mst_topology.c:5451:37: warning: missing braces around initializer
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200516212330.13633-4-chris@chris-wilson.co.uk
While we support using both tx slots for sideband transmissions, it
appears that DisplayPort devices in the field didn't end up doing a very
good job of supporting it. From section 5.2.1 of the DP 2.0
specification:
There are MST Sink/Branch devices in the field that do not handle
interleaved message transactions.
To facilitate message transaction handling by downstream devices, an
MST Source device shall generate message transactions in an atomic
manner (i.e., the MST Source device shall not concurrently interleave
multiple message transactions). Therefore, an MST Source device shall
clear the Message_Sequence_No value in the Sideband_MSG_Header to 0.
This might come as a bit of a surprise since the vast majority of hubs
will support using both tx slots even if they don't support interleaved
message transactions, and we've also been using both tx slots since MST
was introduced into the kernel.
However, there is one device we've had trouble getting working
consistently with MST for so long that we actually assumed it was just
broken: the infamous Dell P2415Qb. Previously this monitor would appear
to work sometimes, but in most situations would end up timing out
LINK_ADDRESS messages almost at random until you power cycled the whole
display. After reading section 5.2.1 in the DP 2.0 spec, some closer
investigation into this infamous display revealed it was only ever
timing out on sideband messages in the second TX slot.
Sure enough, avoiding the second TX slot has suddenly made this monitor
function perfectly for the first time in five years. And since they
explicitly mention this in the specification, I doubt this is the only
monitor out there with this issue. This might even explain explain the
seemingly harmless garbage sideband responses we would occasionally see
with MST hubs!
So - rewrite our sideband TX handlers to only support one TX slot. In
order to simplify our sideband handling now that we don't support
transmitting to multiple MSTBs at once, we also move all state tracking
for down replies from mstbs to the topology manager.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Cc: Sean Paul <sean@poorly.run>
Cc: "Lin, Wayne" <Wayne.Lin@amd.com>
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200424181308.770749-1-lyude@redhat.com
Older compilers either want two extra pairs of curly braces around the
initializer for local variable desc, or they want a single pair of curly
braces with nothing inside. Because current Linux-kernel practice favors
the latter, this commit makes it so.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
drm_dp_mst_wait_tx_reply() returns > 1 if time elapsed in
wait_event_timeout() before check_txmsg_state(mgr, txmsg) evaluated to
true. However, we make the mistake of returning this time from
drm_dp_send_dpcd_write() on success instead of returning the number of
bytes written - causing spontaneous failures during link probing:
[drm:drm_dp_send_link_address [drm_kms_helper]] *ERROR* GUID check on
10:01 failed: 3975
Yikes! So, fix this by returning the number of bytes written on success
instead.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings")
Cc: Benjamin Gaignard <benjamin.gaignard@st.com>
Cc: Sean Paul <sean@poorly.run>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200424190722.775284-1-lyude@redhat.com
This reverts commit 6bb0942e8f46863a745489cce27efe5be2a3885e.
Unfortunately it would appear that the rumors we've heard of sideband
message interleaving not being very well supported are true. On the
Lenovo ThinkPad Thunderbolt 3 dock that I have, interleaved messages
appear to just get dropped:
[drm:drm_dp_mst_wait_tx_reply [drm_kms_helper]] timedout msg send
00000000571ddfd0 2 1
[dp_mst] txmsg cur_offset=2 cur_len=2 seqno=1 state=SENT path_msg=1 dst=00
[dp_mst] type=ENUM_PATH_RESOURCES contents:
[dp_mst] port=2
DP descriptor for this hub:
OUI 90-cc-24 dev-ID SYNA3 HW-rev 1.0 SW-rev 3.12 quirks 0x0008
It would seem like as well that this is a somewhat well known issue in
the field. From section 5.4.2 of the DisplayPort 2.0 specification:
There are MST Sink/Branch devices in the field that do not handle
interleaved message transactions.
To facilitate message transaction handling by downstream devices, an
MST Source device shall generate message transactions in an atomic
manner (i.e., the MST Source device shall not concurrently interleave
multiple message transactions). Therefore, an MST Source device shall
clear the Message_Sequence_No value in the Sideband_MSG_Header to 0.
MST Source devices that support field policy updates by way of
software should update the policy to forego the generation of
interleaved message transactions.
This is a bit disappointing, as features like HDCP require that we send
a sideband request every ~2 seconds for each active stream. However,
there isn't really anything in the specification that allows us to
accurately probe for interleaved messages.
If it ends up being that we -really- need this in the future, we might
be able to whitelist hubs where interleaving is known to work-or maybe
try some sort of heuristics. But for now, let's just play it safe and
not use it.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: 6bb0942e8f46 ("drm/dp_mst: Remove single tx msg restriction.")
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423164225.680178-1-lyude@redhat.com
Reviewed-by: Sean Paul <sean@poorly.run>
Zero Port's PBN together with VCPI slots when releasing
allocated VCPI slots. That way when disabling the connector
it will not cause issues in drm_dp_mst_atomic_check verifying
branch bw limit.
Signed-off-by: Mikita Lipski <mikita.lipski@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: cd82d82cbc04 ("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
Cc: <stable@vger.kernel.org> # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200407160717.27976-1-mikita.lipski@amd.com
Although it's not unexpected for drm_dp_check_act_status() to fail due
to DPCD read failures (as the hub may have just been unplugged
suddenly), timeouts are a bit more worrying as they either mean we need
a longer timeout value, or we aren't setting up payload allocations
properly. So, let's start printing errors on timeouts.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-5-lyude@redhat.com
Currently we only poll for an ACT up to 30 times, with a busy-wait delay
of 100µs between each attempt - giving us a timeout of 2900µs. While
this might seem sensible, it would appear that in certain scenarios it
can take dramatically longer then that for us to receive an ACT. On one
of the EVGA MST hubs that I have available, I observed said hub
sometimes taking longer then a second before signalling the ACT. These
delays mostly seem to occur when previous sideband messages we've sent
are NAKd by the hub, however it wouldn't be particularly surprising if
it's possible to reproduce times like this simply by introducing branch
devices with large LCTs since payload allocations have to take effect on
every downstream device up to the payload's target.
So, instead of just retrying 30 times we poll for the ACT for up to 3ms,
and additionally use usleep_range() to avoid a very long and rude
busy-wait. Note that the previous retry count of 30 appears to have been
arbitrarily chosen, as I can't find any mention of a recommended timeout
or retry count for ACTs in the DisplayPort 2.0 specification. This also
goes for the range we were previously using for udelay(), although I
suspect that was just copied from the recommended delay for link
training on SST devices.
Changes since v1:
* Use readx_poll_timeout() instead of open-coding timeout loop - Sean
Paul
Changes since v2:
* Increase poll interval to 200us - Sean Paul
* Print status in hex when we timeout waiting for ACT - Sean Paul
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Cc: Sean Paul <sean@poorly.run>
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.com
Just add a bit more line wrapping, get rid of some extraneous
whitespace, remove an unneeded goto label, and move around some variable
declarations. No functional changes here.
Signed-off-by: Lyude Paul <lyude@redhat.com>
[this isn't a fix, but it's needed for the fix that comes after this]
Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
Cc: Sean Paul <sean@poorly.run>
Cc: <stable@vger.kernel.org> # v3.17+
Reviewed-by: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-3-lyude@redhat.com
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port, there's no use in keeping this function around as all it
does is validate the port pointer before checking the audio status.
Note - drm_dp_mst_port->has_audio is technically protected by
drm_device->mode_config.connection_mutex, since it's only ever updated
from drm_dp_mst_get_edid(). Additionally, we change the declaration for
port in struct intel_connector to be properly typed, so we can directly
access it.
Changes since v1:
* Change type of intel_connector->port in a separate patch - Sean Paul
Cc: "Lee, Shawn C" <shawn.c.lee@intel.com>
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200406200646.1263435-2-lyude@redhat.com
It looks like that when we introduced the ability to handle multiple
down requests at once, we accidentally started dropping NAK replies -
causing sideband messages which got NAK'd to seemingly timeout and cause
all sorts of weirdness.
So, fix this by making sure we don't return from
drm_dp_mst_handle_down_rep() early, but instead treat NAKs like any
other message.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies")
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Wayne Lin <waynelin@amd.com>
Cc: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200403200325.885628-1-lyude@redhat.com
Reviewed-by: Sean Paul <sean@poorly.run>
While we don't need this function to store an mstb anywhere for UP
requests since we process them asynchronously, we do need to make sure
that we don't try to write to **mstb for UP requests otherwise we'll
cause a NULL pointer deref:
RIP: 0010:drm_dp_get_one_sb_msg+0x4b/0x460 [drm_kms_helper]
Call Trace:
? vprintk_emit+0x16a/0x230
? drm_dp_mst_hpd_irq+0x133/0x1010 [drm_kms_helper]
drm_dp_mst_hpd_irq+0x133/0x1010 [drm_kms_helper]
? __drm_dbg+0x87/0x90 [drm]
? intel_dp_hpd_pulse+0x24b/0x400 [i915]
intel_dp_hpd_pulse+0x24b/0x400 [i915]
i915_digport_work_func+0xd6/0x160 [i915]
process_one_work+0x1a9/0x370
worker_thread+0x4d/0x3a0
kthread+0xf9/0x130
? process_one_work+0x370/0x370
? kthread_park+0x90/0x90
ret_from_fork+0x35/0x40
So, fix this.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Fixes: fbc821c4a506 ("drm/mst: Support simultaneous down replies")
Cc: Wayne Lin <Wayne.Lin@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Wayne Lin <waynelin@amd.com>
Cc: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200406193352.1245985-1-lyude@redhat.com
Reviewed-by: Sean Paul <sean@poorly.run>
Now that we've removed the last user of this callback, get rid of it and
drm_dp_destroy_connector().
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200331205740.135525-5-lyude@redhat.com
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAl6BIG4eHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGlHUH/RCFve2sfHRPjRW+
xR5SaLVAw6XKvtKBq7yvKmHEwqNJnL79IHyqqtSrtfFr2FfaH/KvYiCbbAezvSrM
np0udGu7STKGd21CWuyEZJudyhXkOwMRNiFiCXWp7rs35oh8T0TpJxMzo2Nc1nLk
JFQPqAP6OSvq4IkWEywKQI+Au3Z1IBf83xVjZ1s+MKPQHYD49x2hc4cQntL5/cnm
a3DoR2iBkYiGZCZ9dDqAqJTnMQIiCbACdZXgGjNRUpdyA/dtAjsMl11NPYHm8TA2
3AHBupAK50WBZGad6xv2qKQyScsmoJG2mv92QjlOFz0Tpiu6rLnDlLYREDVB6YH6
qbLDsc8=
=XEIU
-----END PGP SIGNATURE-----
Merge v5.6 into drm-next
msm needed rc6, so I just went and merged release
(msm has been in drm-next outside of this tree)
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that we can support multiple simultaneous replies, remove the
restrictions placed on sending new tx msgs.
This patch essentially just reverts commit
5a64967a2f3b ("drm/dp_mst: Have DP_Tx send one msg at a time")
now that the problem is solved in a different way.
Cc: Wayne Lin <Wayne.Lin@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Wayne Lin <waynelin@amd.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200213211523.156998-4-sean@poorly.run
