linux.git/drivers/gpu/drm/msm, branch v5.16-rc4

drm: msm: fix building without CONFIG_COMMON_CLK

2021-11-26T16:58:57+00:00

When CONFIG_COMMON_CLOCK is disabled, the 8996 specific
phy code is left out, which results in a link failure:

ld: drivers/gpu/drm/msm/hdmi/hdmi_phy.o:(.rodata+0x3f0): undefined reference to `msm_hdmi_phy_8996_cfg'

This was only exposed after it became possible to build
test the driver without the clock interfaces.

Make COMMON_CLK a hard dependency for compile testing,
and simplify it a little based on that.

Fixes: b3ed524f84f5 ("drm/msm: allow compile_test on !ARM")
Reported-by: Randy Dunlap 
Suggested-by: Geert Uytterhoeven 
Signed-off-by: Arnd Bergmann 
Reviewed-by: Dmitry Baryshkov 
Link: https://lore.kernel.org/r/20211013144308.2248978-1-arnd@kernel.org
Signed-off-by: Rob Clark

drm/msm: Do hw_init() before capturing GPU state

2021-11-22T18:45:55+00:00

In particular, we need to ensure all the necessary blocks are switched
to 64b mode (a5xx+) otherwise the high bits of the address of the BO to
snapshot state into will be ignored, resulting in:

  *** gpu fault: ttbr0=0000000000000000 iova=0000000000012000 dir=READ type=TRANSLATION source=CP (0,0,0,0)
  platform 506a000.gmu: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set BOOT_SLUMBER: 0x0

Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20211108180122.487859-1-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/dp: Avoid unpowered AUX xfers that caused crashes

2021-11-22T18:16:05+00:00

If you happened to try to access `/dev/drm_dp_aux` devices provided by
the MSM DP AUX driver too early at bootup you could go boom. Let's
avoid that by only allowing AUX transfers when the controller is
powered up.

Specifically the crash that was seen (on Chrome OS 5.4 tree with
relevant backports):
Kernel panic - not syncing: Asynchronous SError Interrupt
CPU: 0 PID: 3131 Comm: fwupd Not tainted 5.4.144-16620-g28af11b73efb #1
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
Call trace:
dump_backtrace+0x0/0x14c
show_stack+0x20/0x2c
dump_stack+0xac/0x124
panic+0x150/0x390
nmi_panic+0x80/0x94
arm64_serror_panic+0x78/0x84
do_serror+0x0/0x118
do_serror+0xa4/0x118
el1_error+0xbc/0x160
dp_catalog_aux_write_data+0x1c/0x3c
dp_aux_cmd_fifo_tx+0xf0/0x1b0
dp_aux_transfer+0x1b0/0x2bc
drm_dp_dpcd_access+0x8c/0x11c
drm_dp_dpcd_read+0x64/0x10c
auxdev_read_iter+0xd4/0x1c4

I did a little bit of tracing and found that:
* We register the AUX device very early at bootup.
* Power isn't actually turned on for my system until
hpd_event_thread() -> dp_display_host_init() -> dp_power_init()
* You can see that dp_power_init() calls dp_aux_init() which is where
we start allowing AUX channel requests to go through.

In general this patch is a bit of a bandaid but at least it gets us
out of the current state where userspace acting at the wrong time can
fully crash the system.
* I think the more proper fix (which requires quite a bit more
changes) is to power stuff on while an AUX transfer is
happening. This is like the solution we did for ti-sn65dsi86. This
might be required for us to move to populating the panel via the
DP-AUX bus.
* Another fix considered was to dynamically register / unregister. I
tried that at but it got
ugly. Currently there's a bug where the pm_runtime() state isn't
tracked properly and that causes us to just keep registering more
and more.

Signed-off-by: Douglas Anderson
Reviewed-by: Kuogee Hsieh
Reviewed-by: Abhinav Kumar
Link: https://lore.kernel.org/r/20211109100403.1.I4e23470d681f7efe37e2e7f1a6466e15e9bb1d72@changeid
Signed-off-by: Rob Clark

drm/msm/dsi: set default num_data_lanes

2021-11-22T18:16:04+00:00

If "data_lanes" property of the dsi output endpoint is missing in
the DT, num_data_lanes would be 0 by default, which could cause
dsi_host_attach() to fail if dsi->lanes is set to a non-zero value
by the bridge driver.

According to the binding document of msm dsi controller, the
input/output endpoint of the controller is expected to have 4 lanes.
So let's set num_data_lanes to 4 by default.

Signed-off-by: Philip Chen 
Reviewed-by: Douglas Anderson 
Reviewed-by: Stephen Boyd 
Link: https://lore.kernel.org/r/20211030100812.1.I6cd9af36b723fed277d34539d3b2ba4ca233ad2d@changeid
Signed-off-by: Rob Clark

drm/msm/gpu: Fix check for devices without devfreq

2021-11-21T20:56:51+00:00

Looks like 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before
clamping freq") was badly rebased on top of efb8a170a367 ("drm/msm:
Fix devfreq NULL pointer dereference on a3xx") and ended up with
the NULL check in the wrong place.

Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20211120200103.1051459-2-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/gpu: Fix idle_work time

2021-11-21T20:56:30+00:00

This was supposed to be a relative timer, not absolute.

Fixes: 658f4c829688 ("drm/msm/devfreq: Add 1ms delay before clamping freq")
Signed-off-by: Rob Clark 
Reviewed-by: Douglas Anderson 
Link: https://lore.kernel.org/r/20211120200103.1051459-1-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm/a6xx: Fix uinitialized use of gpu_scid

2021-11-21T20:55:26+00:00

Avoid a possible uninitialized use of gpu_scid variable to fix the
below smatch warning:
	drivers/gpu/drm/msm/adreno/a6xx_gpu.c:1480 a6xx_llc_activate()
	error: uninitialized symbol 'gpu_scid'.

Reported-by: Dan Carpenter 
Signed-off-by: Akhil P Oommen 
Link: https://lore.kernel.org/r/20211118154903.3.Ie4ac321feb10168af569d9c2b4cf6828bed8122c@changeid
Signed-off-by: Rob Clark

drm/msm: Fix null ptr access msm_ioctl_gem_submit()

2021-11-21T20:54:22+00:00

Fix the below null pointer dereference in msm_ioctl_gem_submit():

 26545.260705:   Call trace:
 26545.263223:    kref_put+0x1c/0x60
 26545.266452:    msm_ioctl_gem_submit+0x254/0x744
 26545.270937:    drm_ioctl_kernel+0xa8/0x124
 26545.274976:    drm_ioctl+0x21c/0x33c
 26545.278478:    drm_compat_ioctl+0xdc/0xf0
 26545.282428:    __arm64_compat_sys_ioctl+0xc8/0x100
 26545.287169:    el0_svc_common+0xf8/0x250
 26545.291025:    do_el0_svc_compat+0x28/0x54
 26545.295066:    el0_svc_compat+0x10/0x1c
 26545.298838:    el0_sync_compat_handler+0xa8/0xcc
 26545.303403:    el0_sync_compat+0x188/0x1c0
 26545.307445:   Code: d503201f d503201f 52800028 4b0803e8 (b8680008)
 26545.318799:   Kernel panic - not syncing: Oops: Fatal exception

Signed-off-by: Akhil P Oommen 
Link: https://lore.kernel.org/r/20211118154903.2.I3ae019673a0cc45d83a193a7858748dd03dbb820@changeid
Signed-off-by: Rob Clark

drm/msm: Demote debug message

2021-11-21T20:52:13+00:00

Mesa attempts to allocate a cached-coherent buffer in order to determine
if cached-coherent is supported.  Resulting in seeing this error message
once per process with newer mesa.  But no reason for this to be more
than a debug msg.

Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20211111230214.765476-1-robdclark@gmail.com
Signed-off-by: Rob Clark

drm/msm: Make a6xx_gpu_set_freq() static

2021-11-21T20:51:56+00:00

Reported-by: kernel test robot 
Signed-off-by: Rob Clark 
Link: https://lore.kernel.org/r/20211111230151.765228-1-robdclark@gmail.com
Signed-off-by: Rob Clark