Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 28 4月, 2020 3 次提交
    • L
      drm/dp_mst: Kill the second sideband tx slot, save the world · d308a881
      由 Lyude Paul 提交于 
      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: NLyude Paul <lyude@redhat.com>
Fixes: ad7f8a1f ("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: NSean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20200424181308.770749-1-lyude@redhat.com
      d308a881
    • Z
      drm/rockchip: Remove unneeded semicolon · 611e22b1
      由 Zheng Bin 提交于 
      Fixes coccicheck warning:

drivers/gpu/drm/rockchip/cdn-dp-reg.c:604:2-3: Unneeded semicolon
drivers/gpu/drm/rockchip/cdn-dp-reg.c:622:2-3: Unneeded semicolon
drivers/gpu/drm/rockchip/cdn-dp-reg.c:703:2-3: Unneeded semicolon
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NZheng Bin <zhengbin13@huawei.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200424074410.1070-1-zhengbin13@huawei.com
      611e22b1
    • E
      drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static · 7c49abb4
      由 Enric Balletbo i Serra 提交于 
      This fixes the following warning detected when running make with W=1

    drivers/gpu/drm/rockchip//cdn-dp-core.c:1112:5: warning: no previous
    prototype for ‘cdn_dp_suspend’ [-Wmissing-prototypes]

    drivers/gpu/drm/rockchip//cdn-dp-core.c:1126:5: warning: no previous
    prototype for ‘cdn_dp_resume’ [-Wmissing-prototypes]
Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20200426161653.7710-1-enric.balletbo@collabora.com
      7c49abb4
  3. 27 4月, 2020 1 次提交
  5. 26 4月, 2020 1 次提交
  7. 25 4月, 2020 9 次提交
  9. 24 4月, 2020 13 次提交
  11. 21 4月, 2020 3 次提交
  13. 20 4月, 2020 1 次提交
    • T
      drm/ast: Allocate initial CRTC state of the correct size · f0adbc38
      由 Thomas Zimmermann 提交于 
      The ast driver inherits from DRM's CRTC state, but still uses the atomic
helper for struct drm_crtc_funcs.reset, drm_atomic_helper_crtc_reset().

The helper only allocates enough memory for the core CRTC state. That
results in an out-ouf-bounds access when duplicating the initial CRTC
state. Simplified backtrace shown below:

[   21.469321] ==================================================================
[   21.469434] BUG: KASAN: slab-out-of-bounds in ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[   21.469445] Read of size 8 at addr ffff888036c1c5f8 by task systemd-udevd/382
[   21.469451]
[   21.469464] CPU: 2 PID: 382 Comm: systemd-udevd Tainted: G            E     5.5.0-rc6-1-default+ #214
[   21.469473] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN FIRE X2270 M2, BIOS 2.05    07/01/2010
[   21.469480] Call Trace:
[   21.469501]  dump_stack+0xb8/0x110
[   21.469528]  print_address_description.constprop.0+0x1b/0x1e0
[   21.469557]  ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[   21.469581]  ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[   21.469597]  __kasan_report.cold+0x1a/0x35
[   21.469640]  ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[   21.469665]  kasan_report+0xe/0x20
[   21.469693]  ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[   21.469733]  drm_atomic_get_crtc_state+0xbf/0x1c0
[   21.469768]  __drm_atomic_helper_set_config+0x81/0x5a0
[   21.469803]  ? drm_atomic_plane_check+0x690/0x690
[   21.469843]  ? drm_client_rotation+0xae/0x240
[   21.469876]  drm_client_modeset_commit_atomic+0x230/0x390
[   21.469888]  ? __mutex_lock+0x8f0/0xbe0
[   21.469929]  ? drm_client_firmware_config.isra.0+0xa60/0xa60
[   21.469948]  ? drm_client_modeset_commit_force+0x28/0x230
[   21.470031]  ? memset+0x20/0x40
[   21.470078]  drm_client_modeset_commit_force+0x90/0x230
[   21.470110]  drm_fb_helper_restore_fbdev_mode_unlocked+0x5f/0xc0
[   21.470132]  drm_fb_helper_set_par+0x59/0x70
[   21.470155]  fbcon_init+0x61d/0xad0
[   21.470185]  ? drm_fb_helper_restore_fbdev_mode_unlocked+0xc0/0xc0
[   21.470232]  visual_init+0x187/0x240
[   21.470266]  do_bind_con_driver+0x2e3/0x460
[   21.470321]  do_take_over_console+0x20a/0x290
[   21.470371]  do_fbcon_takeover+0x85/0x100
[   21.470402]  register_framebuffer+0x2fd/0x490
[   21.470425]  ? kzalloc.constprop.0+0x10/0x10
[   21.470503]  __drm_fb_helper_initial_config_and_unlock+0xf2/0x140
[   21.470533]  drm_fbdev_client_hotplug+0x162/0x250
[   21.470563]  drm_fbdev_generic_setup+0xd2/0x155
[   21.470602]  ast_driver_load+0x688/0x850 [ast]
<...>
[   21.472625] ==================================================================

Allocating enough memory for struct ast_crtc_state in a custom ast CRTC
reset handler fixes the problem.

v2:
	* implement according to drm_atomic_helper_crtc_reset()
	* update state with __drm_atomic_helper_crtc_reset()
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Fixes: 83be6a3c ("drm/ast: Introduce struct ast_crtc_state")
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200130094012.32140-1-tzimmermann@suse.de
      f0adbc38
  15. 17 4月, 2020 1 次提交
  17. 16 4月, 2020 1 次提交
  19. 15 4月, 2020 1 次提交
  21. 14 4月, 2020 2 次提交
  23. 13 4月, 2020 1 次提交
  25. 10 4月, 2020 3 次提交