Skip to content
  1. Jun 13, 2019
  3. Jun 12, 2019
    • Sean Paul's avatar
      drm: Tweak drm_encoder_helper_funcs.enable kerneldoc · 09cc5609
      Sean Paul authored 
      

I copied the kerneldoc for encoder_funcs.atomic_enable from encoder_funcs.enable
in a recent patch [1]. Sam rightly pointed out in the review that "for symmetry
with" text is awkward [2]. So here's a patch to fix up the source of the awkward
language.

[1] https://patchwork.freedesktop.org/patch/msgid/20190611160844.257498-2-sean@poorly.run
[2] https://patchwork.freedesktop.org/patch/msgid/20190611185352.GA16305@ravnborg.org

Suggested-by: default avatarSam Ravnborg <sam@ravnborg.org>
Reviewed-by: default avatarSam Ravnborg <sam@ravnborg.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190612150038.194843-1-sean@poorly.run
      09cc5609
    • Chris Wilson's avatar
      dma-fence/reservation: Markup rcu protected access for DEBUG_MUTEXES · 5740671e
      Chris Wilson authored 
      

Mark the access to reservation_object.fence as being protected to
silence sparse.

Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190612132830.31221-1-chris@chris-wilson.co.uk
      5740671e
    • Wolfram Sang's avatar
      gpu: drm: bridge: sii9234: simplify getting the adapter of a client · c412187d
      Wolfram Sang authored 
      

We have a dedicated pointer for that, so use it. Much easier to read and
less computation involved.

Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190608105619.593-3-wsa+renesas@sang-engineering.com
      c412187d
    • Thomas Zimmermann's avatar
      drm: Reverse lock order in pan_display_legacy() · 1ff30dd8
      Thomas Zimmermann authored 
      Acquiring drm_client_dev.modeset_mutex after the locks in drm_fb_helper.dev
creates a deadlock with drm_setup_crtcs() as shown below:

  [    4.959319] fbcon: radeondrmfb (fb0) is primary device
  [    4.993952] Console: switching to colour frame buffer device 240x67
  [    4.994040]
  [    4.994041] ======================================================
  [    4.994041] WARNING: possible circular locking dependency detected
  [    4.994042] 5.2.0-rc4-1-default+ #39 Tainted: G            E
  [    4.994043] ------------------------------------------------------
  [    4.994043] systemd-udevd/369 is trying to acquire lock:
  [    4.994044] 00000000fb622acb (&client->modeset_mutex){+.+.}, at: drm_fb_helper_pan_display+0x103/0x1f0 [drm_kms_helper]
  [    4.994055]
  [    4.994055] but task is already holding lock:
  [    4.994055] 0000000028767ae4 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_lock+0x42/0xf0 [drm]
  [    4.994072]
  [    4.994072] which lock already depends on the new lock.
  [    4.994072]
  [    4.994072]
  [    4.994072] the existing dependency chain (in reverse order) is:
  [    4.994073]
  [    4.994073] -> #3 (crtc_ww_class_mutex){+.+.}:
  [    4.994076]        lock_acquire+0x9e/0x170
  [    4.994079]        __ww_mutex_lock.constprop.18+0x97/0xf40
  [    4.994080]        ww_mutex_lock+0x30/0x90
  [    4.994091]        drm_modeset_lock+0x42/0xf0 [drm]
  [    4.994102]        drm_modeset_lock_all_ctx+0x1f/0xe0 [drm]
  [    4.994113]        drm_modeset_lock_all+0x5e/0x1a0 [drm]
  [    4.994163]        intel_modeset_init+0x60b/0xda0 [i915]
  ..
  [    4.994253]
  [    4.994253] -> #2 (crtc_ww_class_acquire){+.+.}:
  [    4.994255]        lock_acquire+0x9e/0x170
  [    4.994270]        drm_modeset_acquire_init+0xcc/0x100 [drm]
  [    4.994280]        drm_modeset_lock_all+0x44/0x1a0 [drm]
  [    4.994320]        intel_modeset_init+0x60b/0xda0 [i915]
  ..
  [    4.994403]
  [    4.994403] -> #1 (&dev->mode_config.mutex){+.+.}:
  [    4.994405]        lock_acquire+0x9e/0x170
  [    4.994408]        __mutex_lock+0x62/0x8c0
  [    4.994413]        drm_setup_crtcs+0x17c/0xc50 [drm_kms_helper]
  [    4.994418]        __drm_fb_helper_initial_config_and_unlock+0x34/0x530 [drm_kms_helper]
  [    4.994450]        radeon_fbdev_init+0x110/0x130 [radeon]
  ..
  [    4.994535]
  [    4.994535] -> #0 (&client->modeset_mutex){+.+.}:
  [    4.994537]        __lock_acquire+0xa85/0xe90
  [    4.994538]        lock_acquire+0x9e/0x170
  [    4.994540]        __mutex_lock+0x62/0x8c0
  [    4.994545]        drm_fb_helper_pan_display+0x103/0x1f0 [drm_kms_helper]
  [    4.994547]        fb_pan_display+0x92/0x120
  [    4.994549]        bit_update_start+0x1a/0x40
  [    4.994550]        fbcon_switch+0x392/0x580
  [    4.994552]        redraw_screen+0x12c/0x220
  [    4.994553]        do_bind_con_driver.cold.30+0xe1/0x10d
  [    4.994554]        do_take_over_console+0x113/0x190
  [    4.994555]        do_fbcon_takeover+0x58/0xb0
  [    4.994557]        notifier_call_chain+0x47/0x70
  [    4.994558]        blocking_notifier_call_chain+0x44/0x60
  [    4.994559]        register_framebuffer+0x231/0x310
  [    4.994564]        __drm_fb_helper_initial_config_and_unlock+0x2fd/0x530 [drm_kms_helper]
  [    4.994590]        radeon_fbdev_init+0x110/0x130 [radeon]
  ..

This problem was introduced in

  d81294af	drm/fb-helper: Remove drm_fb_helper_crtc

Reversing the lock ordering in pan_display_legacy() fixes the issue.

Fixes: d81294af

 ("drm/fb-helper: Remove drm_fb_helper_crtc")
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: default avatarThomas Zimmermann <tzimmermann@suse.de>
Suggested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190611115716.7052-1-tzimmermann@suse.de
      1ff30dd8
    • Yannick Fertré's avatar
      drm/stm: dsi: add power on/off phy ops · ee7668bc
      Yannick Fertré authored 
      

These new physical operations are helpful to power_on/off the dsi
wrapper. If the dsi wrapper is powered in video mode, the display
controller (ltdc) register access will hang when DSI fifos are full.

Signed-off-by: default avatarYannick Fertré <yannick.fertre@st.com>
Acked-by: default avatarPhilippe Cornu <philippe.cornu@st.com>
Tested-by: default avatarPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1558952499-15418-3-git-send-email-yannick.fertre@st.com
      ee7668bc
    • Yannick Fertré's avatar
      drm/bridge/synopsys: dsi: add power on/off optional phy ops · a3e69b86
      Yannick Fertré authored 
      

Add power on & off optional physical operation functions, helpful to
program specific registers of the DSI physical part.

Signed-off-by: default avatarYannick Fertré <yannick.fertre@st.com>
Reviewed-by: default avatarPhilippe Cornu <philippe.cornu@st.com>
Tested-by: default avatarPhilippe Cornu <philippe.cornu@st.com>
Reviewed-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: default avatarAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1558952499-15418-2-git-send-email-yannick.fertre@st.com
      a3e69b86
    • Douglas Anderson's avatar
      drm/rockchip: dw_hdmi: Handle suspend/resume · 27c9130b
      Douglas Anderson authored 
      

On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:

1. You lose the ability to detect an HDMI device being plugged in.

2. If you're using the i2c bus built in to dw_hdmi then it stops
working.

Let's call the core dw-hdmi's suspend/resume functions to restore
things.

NOTE: in downstream Chrome OS (based on kernel 3.14) we used the
"late/early" versions of suspend/resume because we found that the VOP
was sometimes resuming before dw_hdmi and then calling into us before
we were fully resumed.  For now I have gone back to the normal
suspend/resume because I can't reproduce the problems.

Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604204207.168085-2-dianders@chromium.org
      27c9130b
    • Douglas Anderson's avatar
      drm: bridge: dw-hdmi: Add hook for resume · 99d02ed5
      Douglas Anderson authored 
      

On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:

1. You lose the ability to detect an HDMI device being plugged in.

2. If you're using the i2c bus built in to dw_hdmi then it stops
working.

Let's add a hook to the core dw-hdmi driver so that we can call it in
dw_hdmi-rockchip in the next commit.

NOTE: the exact set of steps I've done here in resume come from
looking at the normal dw_hdmi init sequence in upstream Linux plus the
sequence that we did in downstream Chrome OS 3.14.  Testing show that
it seems to work, but if an extra step is needed or something here is
not needed we could improve it.

As part of this change we'll refactor the hardware init bits of
dw-hdmi to happen all in one function and all at the same time.  Since
we need to init the interrupt mutes before we request the IRQ, this
means moving the hardware init earlier in the function, but there
should be no problems with that.  Also as part of this we now
unconditionally init the "i2c" parts of dw-hdmi, but again that ought
to be fine.

Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604204207.168085-1-dianders@chromium.org
      99d02ed5
    • Daniel Vetter's avatar
      drm/fb: document dirty helper better · ecf79e7c
      Daniel Vetter authored 
      

Apparently little known fact that there's no need to hand-roll your own
anymore. Cc'ing a bunch of driver people who might want to know this
too.

v2: s/none/known/ (Chris Wilson)

Cc: Rob Clark <robdclark@gmail.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: David Lechner <david@lechnology.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: default avatarNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190611112859.16375-1-daniel.vetter@ffwll.ch
      ecf79e7c
  5. Jun 11, 2019