Skip to content

L
linux
Switch branch/tag
  1. 20 May, 2023 2 commits
    • Douglas Anderson's avatar
      drm/msm/dsi: More properly handle errors in regards to dsi_mgr_bridge_power_on() · d8dd416c
      Douglas Anderson authored 
      In commit 7d8e9a90 ("drm/msm/dsi: move DSI host powerup to modeset
time") the error handling with regards to dsi_mgr_bridge_power_on()
got a bit worse. Specifically if we failed to power the bridge on then
nothing would really notice. The modeset function couldn't return an
error and thus we'd blindly go forward and try to do the pre-enable.

In commit ec7981e6 ("drm/msm/dsi: don't powerup at modeset time
for parade-ps8640") we added a special case to move the powerup back
to pre-enable time for ps8640. When we did that, we didn't try to
recover the old/better error handling just for ps8640.

In the patch ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset") we've now moved the powering up back to exclusively being
during pre-enable. That means we can add the better error handling
back in, so let's do it. To do so we'll add a new function
dsi_mgr_bridge_power_off() that's matches how errors were handled
prior to commit 7d8e9a90 ("drm/msm/dsi: move DSI host powerup to
modeset time").

NOTE: Now that we have dsi_mgr_bridge_power_off(), it feels as if we
should be calling it in dsi_mgr_bridge_post_disable(). That would make
some sense, but doing so would change the current behavior and thus
should be a separate patch. Specifically:
* dsi_mgr_bridge_post_disable() always calls dsi_mgr_phy_disable()
  even in the slave-DSI case of bonded DSI. We'd need to add special
  handling for this if it's truly needed.
* dsi_mgr_bridge_post_disable() calls msm_dsi_phy_pll_save_state()
  midway through the poweroff.
* dsi_mgr_bridge_post_disable() has a different order of some of the
  poweroffs / IRQ disables.
For now we'll leave dsi_mgr_bridge_post_disable() alone.
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarAbhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/521059/
Link: https://lore.kernel.org/r/20230131141756.RFT.v2.3.I3c87b53c4ab61a7d5e05f601a4eb44c7e3809a01@changeidSigned-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      d8dd416c
    • Douglas Anderson's avatar
      drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset · 9e15123e
      Douglas Anderson authored 
      In commit 7d8e9a90 ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.

That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()

Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is
commit 4fb912e5 ("drm/bridge: Introduce pre_enable_prev_first to
alter bridge init order"). As documented by that series, if a bridge
doesn't set "pre_enable_prev_first" then we should use the old ordering.

Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.

One last note is that even without reverting commit 7d8e9a90
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().

Cc: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Abhinav Kumar <quic_abhinavk@quicinc.com>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarAbhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Patchwork: https://patchwork.freedesktop.org/patch/521058/
Link: https://lore.kernel.org/r/20230131141756.RFT.v2.2.I4cfeab9d0e07e98ead23dd0736ab4461e6c69002@changeidSigned-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      9e15123e
  3. 17 May, 2023 2 commits
  5. 11 May, 2023 2 commits
  7. 28 Apr, 2023 1 commit
  9. 26 Apr, 2023 12 commits
  11. 24 Apr, 2023 2 commits
    • Rob Clark's avatar
      drm/msm: Fix vmap madv warning · 16eb51ab
      Rob Clark authored 
      Commit d6ae7d1c ("drm/msm/gem: Simplify vmap vs LRU tracking")
introduced a splat in the pin_pages_locked() path for buffers that
had been MADV_DONTNEED.

   ------------[ cut here ]------------
   msm_obj->madv != 0
   WARNING: CPU: 1 PID: 144 at drivers/gpu/drm/msm/msm_gem.c:230 msm_gem_pin_pages_locked+0x9c/0xd4
   Modules linked in: lzo_rle cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core venus_dec venus_enc videobuf2_dma_contig cdc_ether usbnet mii uvcvideo videobuf2_vmalloc hci_uart btqca qcom_spmi_adc5 uvc qcom_spmi_temp_alarm qcom_vadc_common cros_ec_sensorhub videobuf2_memops cros_ec_typec sx9324 sx_common typec joydev bluetooth industrialio_triggered_buffer ecdh_generic kfifo_buf ecc venus_core qcom_stats v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath11k_ahb ath11k mac80211 cfg80211 fuse zram zsmalloc
   CPU: 1 PID: 144 Comm: ring0 Tainted: G        W          6.3.0-rc2-debug+ #622
   Hardware name: Google Villager (rev1+) with LTE (DT)
   pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : msm_gem_pin_pages_locked+0x9c/0xd4
   lr : msm_gem_pin_pages_locked+0x9c/0xd4
   sp : ffffffc009ffbab0
   x29: ffffffc009ffbab0 x28: ffffffee8da75008 x27: ffffff80a10274d0
   x26: ffffff8087fe3bf8 x25: ffffff8087fe3c08 x24: 0000000000000001
   x23: ffffff80891d5800 x22: ffffff809d0de480 x21: ffffff8081e5a080
   x20: 0000000000000002 x19: ffffff80a3564c00 x18: 0000000000000000
   x17: 0000000000000000 x16: 0000000000000000 x15: 00000000000a9620
   x14: 0000000000000000 x13: 2d2d2d2d2d2d2d2d x12: 2d2d2d2d5d206572
   x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : ffffffee8c705dfc
   x8 : ffffffee8da75000 x7 : ffffffee8d34e6d0 x6 : 0000000000000000
   x5 : 00000000000affa8 x4 : 000000000000000d x3 : ffffffee8da75008
   x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8088048040
   Call trace:
    msm_gem_pin_pages_locked+0x9c/0xd4
    get_vaddr+0xb0/0x150
    msm_gem_get_vaddr_active+0x1c/0x28
    snapshot_buf+0x90/0x10c
    msm_rd_dump_submit+0x30c/0x380
    msm_gpu_submit+0x88/0x174
    msm_job_run+0x68/0x118
    drm_sched_main+0x2b8/0x3a0
    kthread+0xf0/0x100
    ret_from_fork+0x10/0x20
   irq event stamp: 3358
   hardirqs last  enabled at (3357): [<ffffffee8c7051f4>] __up_console_sem+0x7c/0x80
   hardirqs last disabled at (3358): [<ffffffee8d3480b0>] el1_dbg+0x24/0x80
   softirqs last  enabled at (3330): [<ffffffee8c610420>] __do_softirq+0x21c/0x4bc
   softirqs last disabled at (3325): [<ffffffee8c616708>] ____do_softirq+0x18/0x24
   ---[ end trace 0000000000000000 ]---

But, as with msm_gem_get_vaddr_active(), this is a special case
because we know that the buffer won't be purged evicted until it's
fence is signaled.  We just forgot to propagate the logic get_vaddr()
to pin_pages_locked().

Fixes: d6ae7d1c ("drm/msm/gem: Simplify vmap vs LRU tracking")
Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
Patchwork: https://patchwork.freedesktop.org/patch/532616/
Link: https://lore.kernel.org/r/20230417225504.494934-1-robdclark@gmail.com
      16eb51ab
    • Rob Clark's avatar
      drm/msm/atomic: Don't try async if crtc not active · ce902336
      Rob Clark authored 
      For a similar reason as commit f2c7ca89 ("drm/atomic-helper: Don't
set deadline for modesets"), we need the crtc to be already active in
order to compute a target vblank time for an async commit.  Otherwise
we get this splat reminding us that we are doing it wrong:

   ------------[ cut here ]------------
   msm_dpu ae01000.mdp: drm_WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev))
   WARNING: CPU: 7 PID: 1923 at drivers/gpu/drm/drm_vblank.c:728 drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370
   Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun vhost_vsock vhost vhost_iotlb vmw_vsock_virtio_transport_common vsock uinput rfcomm algif_hash algif_skcipher af_alg veth venus_dec venus_enc cros_ec_typec typec qcom_spmi_temp_alarm qcom_spmi_adc_tm5 qcom_spmi_adc5 xt_cgroup qcom_vadc_common qcom_stats hci_uart btqca xt_MASQUERADE venus_core 8021q coresight_tmc coresight_funnel coresight_etm4x coresight_replicator snd_soc_lpass_sc7180 coresight snd_soc_sc7180 ip6table_nat fuse ath10k_snoc ath10k_core ath mac80211 iio_trig_sysfs bluetooth cfg80211 cros_ec_sensors cros_ec_sensors_core ecdh_generic industrialio_triggered_buffer ecc kfifo_buf cros_ec_sensorhub r8153_ecm cdc_ether usbnet r8152 mii lzo_rle lzo_compress zram hid_vivaldi hid_google_hammer hid_vivaldi_common joydev
   CPU: 7 PID: 1923 Comm: DrmThread Not tainted 5.15.107-18853-g3be267609a0b-dirty #16 a1ffc1a66e79c21c3536d8c9a42e819236e39714
   Hardware name: Google Wormdingler rev1+ BOE panel board (DT)
   pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
   pc : drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370
   lr : drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x144/0x370
   sp : ffffffc012e2b800
   x29: ffffffc012e2b840 x28: ffffff8083676094 x27: ffffffc012e2bb28
   x26: ffffff8084539800 x25: 0000000000000000 x24: ffffff8083676000
   x23: ffffffd3c8cdc5a0 x22: ffffff80845b9d00 x21: ffffffc012e2b8b4
   x20: ffffffc012e2b910 x19: 0000000000000001 x18: 0000000000000000
   x17: 0000000000000000 x16: 0000000000000010 x15: ffffffd3c8451a88
   x14: 0000000000000003 x13: 0000000000000004 x12: 0000000000000001
   x11: c0000000ffffdfff x10: ffffffd3c973ef58 x9 : 8ea3526b3cc95900
   x8 : 8ea3526b3cc95900 x7 : 0000000000000000 x6 : 000000000000003a
   x5 : ffffffd3c99676cd x4 : 0000000000000000 x3 : ffffffc012e2b4b8
   x2 : ffffffc012e2b4c0 x1 : 00000000ffffdfff x0 : 0000000000000000
   Call trace:
    drm_crtc_vblank_helper_get_vblank_timestamp_internal+0x148/0x370
    drm_crtc_vblank_helper_get_vblank_timestamp+0x20/0x30
    drm_crtc_get_last_vbltimestamp+0x68/0xb0
    drm_crtc_next_vblank_start+0x5c/0xa8
    msm_atomic_commit_tail+0x264/0x664
    commit_tail+0xac/0x160
    drm_atomic_helper_commit+0x160/0x168
    drm_atomic_commit+0xfc/0x128
    drm_atomic_helper_disable_plane+0x8c/0x110
    __setplane_atomic+0x10c/0x138
    drm_mode_cursor_common+0x3a8/0x410
    drm_mode_cursor_ioctl+0x48/0x70
    drm_ioctl_kernel+0xe0/0x158
    drm_ioctl+0x25c/0x4d8
    __arm64_sys_ioctl+0x98/0xd0
    invoke_syscall+0x4c/0x100
    el0_svc_common+0x98/0x104
    do_el0_svc+0x30/0x90
    el0_svc+0x20/0x50
    el0t_64_sync_handler+0x78/0x108
    el0t_64_sync+0x1a4/0x1a8
   ---[ end trace a0f587e1ab9589e8 ]---

Fixes: 52ff0d30 ("drm/msm/atomic: Switch to vblank_start helper")
Signed-off-by: default avatarRob Clark <robdclark@chromium.org>
Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: default avatarAbhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/532727/
Link: https://lore.kernel.org/r/20230418164158.549873-1-robdclark@gmail.com
      ce902336
  13. 07 Apr, 2023 19 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7