linux-stable.git/drivers/gpu/drm/msm, branch v5.4.22 Linux kernel stable tree drm/msm/adreno: fix zap vs no-zap handling 2020-02-24T07:36:25+00:00 Rob Clark robdclark@chromium.org 2019-11-24T22:23:38+00:00 4a8bb7ce9f0bbd0b1571b4b743273abfab565bc6 [ Upstream commit 15ab987c423df561e0949d77fb5043921ae59956 ] We can have two cases, when it comes to "zap" fw. Either the fw requires zap fw to take the GPU out of secure mode at boot, or it does not and we can write RBBM_SECVID_TRUST_CNTL directly. Previously we decided based on whether zap fw load succeeded, but this is not a great plan because: 1) we could have zap fw in the filesystem on a device where it is not required 2) we could have the inverse case Instead, shift to deciding based on whether we have a 'zap-shader' node in dt. In practice, there is only one device (currently) with upstream dt that does not use zap (cheza), and it already has a /delete-node/ for the zap-shader node. Fixes: abccb9fe3267 ("drm/msm/a6xx: Add zap shader load") Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 15ab987c423df561e0949d77fb5043921ae59956 ]

We can have two cases, when it comes to "zap" fw.  Either the fw
requires zap fw to take the GPU out of secure mode at boot, or it does
not and we can write RBBM_SECVID_TRUST_CNTL directly.  Previously we
decided based on whether zap fw load succeeded, but this is not a great
plan because:

1) we could have zap fw in the filesystem on a device where it is not
   required
2) we could have the inverse case

Instead, shift to deciding based on whether we have a 'zap-shader' node
in dt.  In practice, there is only one device (currently) with upstream
dt that does not use zap (cheza), and it already has a /delete-node/ for
the zap-shader node.

Fixes: abccb9fe3267 ("drm/msm/a6xx: Add zap shader load")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm: msm: mdp4: Adjust indentation in mdp4_dsi_encoder_enable 2020-02-11T12:35:45+00:00 Nathan Chancellor natechancellor@gmail.com 2019-12-09T20:32:30+00:00 da535ca18ef5974eadd0329aa0a2a7df1de92dc3 commit 251e3cb1418ff3f5061ee31335e346e852b16573 upstream. Clang warns: ../drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c:124:3: warning: misleading indentation; statement is not part of the previous 'if' [-Wmisleading-indentation] mdp4_crtc_set_config(encoder->crtc, ^ ../drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c:121:2: note: previous statement is here if (mdp4_dsi_encoder->enabled) ^ This warning occurs because there is a space after the tab on this line. Remove it so that the indentation is consistent with the Linux kernel coding style and clang no longer warns. Fixes: 776638e73a19 ("drm/msm/dsi: Add a mdp4 encoder for DSI") Link: https://github.com/ClangBuiltLinux/linux/issues/792 Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 251e3cb1418ff3f5061ee31335e346e852b16573 upstream.

Clang warns:

../drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c:124:3: warning:
misleading indentation; statement is not part of the previous 'if'
[-Wmisleading-indentation]
         mdp4_crtc_set_config(encoder->crtc,
         ^
../drivers/gpu/drm/msm/disp/mdp4/mdp4_dsi_encoder.c:121:2: note:
previous statement is here
        if (mdp4_dsi_encoder->enabled)
        ^

This warning occurs because there is a space after the tab on this line.
Remove it so that the indentation is consistent with the Linux kernel
coding style and clang no longer warns.

Fixes: 776638e73a19 ("drm/msm/dsi: Add a mdp4 encoder for DSI")
Link: https://github.com/ClangBuiltLinux/linux/issues/792
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/msm: include linux/sched/task.h 2020-01-09T09:20:01+00:00 Arnd Bergmann arnd@arndb.de 2019-09-18T19:57:07+00:00 fe8adb0aae33905bdd6b682907d8c48b1857ec99 commit 70082a52f96a45650dfc3d8cdcd2c42bdac9f6f0 upstream. Without this header file, compile-testing may run into a missing declaration: drivers/gpu/drm/msm/msm_gpu.c:444:4: error: implicit declaration of function 'put_task_struct' [-Werror,-Wimplicit-function-declaration] Fixes: 482f96324a4e ("drm/msm: Fix task dump in gpu recovery") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 70082a52f96a45650dfc3d8cdcd2c42bdac9f6f0 upstream.

Without this header file, compile-testing may run into a missing
declaration:

drivers/gpu/drm/msm/msm_gpu.c:444:4: error: implicit declaration of function 'put_task_struct' [-Werror,-Wimplicit-function-declaration]

Fixes: 482f96324a4e ("drm/msm: Fix task dump in gpu recovery")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm: msm: a6xx: fix debug bus register configuration 2019-12-31T15:44:48+00:00 Sharat Masetty smasetty@codeaurora.org 2019-11-06T11:49:23+00:00 2eb7ab5e756c903fc86c9d596f9bda46ebb79941 [ Upstream commit 7f4009c4bbea4438b50f3b12d1c57da3f5cd8db3 ] Fix the cx debugbus related register configuration, to collect accurate bus data during gpu snapshot. This helps with complete snapshot dump and also complete proper GPU recovery. Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/339165 Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7f4009c4bbea4438b50f3b12d1c57da3f5cd8db3 ]

Fix the cx debugbus related register configuration, to collect accurate
bus data during gpu snapshot. This helps with complete snapshot dump
and also complete proper GPU recovery.

Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/339165
Signed-off-by: Sasha Levin <sashal@kernel.org>
drm/msm: fix memleak on release 2019-12-13T07:42:54+00:00 Johan Hovold johan@kernel.org 2019-10-10T13:13:30+00:00 693f39975385452191f33e762a9d2bb15c4844b2 commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream. If a process is interrupted while accessing the "gpu" debugfs file and the drm device struct_mutex is contended, release() could return early and fail to free related resources. Note that the return value from release() is ignored. Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Cc: stable <stable@vger.kernel.org> # 4.18 Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a64fc11b9a520c55ca34d82e5ca32274f49b6b15 upstream.

If a process is interrupted while accessing the "gpu" debugfs file and
the drm device struct_mutex is contended, release() could return early
and fail to free related resources.

Note that the return value from release() is ignored.

Fixes: 4f776f4511c7 ("drm/msm/gpu: Convert the GPU show function to use the GPU state")
Cc: stable <stable@vger.kernel.org>     # 4.18
Cc: Jordan Crouse <jcrouse@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/msm/dsi: Implement reset correctly 2019-10-11T18:04:31+00:00 Jeffrey Hugo jeffrey.l.hugo@gmail.com 2019-10-11T13:39:39+00:00 78e31c42261779a01bc73472d0f65f15378e9de3 On msm8998, vblank timeouts are observed because the DSI controller is not reset properly, which ends up stalling the MDP. This is because the reset logic is not correct per the hardware documentation. The documentation states that after asserting reset, software should wait some time (no indication of how long), or poll the status register until it returns 0 before deasserting reset. wmb() is insufficient for this purpose since it just ensures ordering, not timing between writes. Since asserting and deasserting reset occurs on the same register, ordering is already guaranteed by the architecture, making the wmb extraneous. Since we would define a timeout for polling the status register to avoid a possible infinite loop, lets just use a static delay of 20 ms, since 16.666 ms is the time available to process one frame at 60 fps. Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Cc: Hai Li <hali@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by: Sean Paul <sean@poorly.run> [seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS] Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.com 
On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP.  This is because the reset
logic is not correct per the hardware documentation.

The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.

wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes.  Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.

Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.

Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li <hali@codeaurora.org>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Reviewed-by: Sean Paul <sean@poorly.run>
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.hugo@gmail.com
drm/msm: Use the correct dma_sync calls harder 2019-09-04T17:05:05+00:00 Rob Clark robdclark@chromium.org 2019-09-04T16:56:03+00:00 9f614197c744002f9968e82c649fdf7fe778e1e7 Looks like the dma_sync calls don't do what we want on armv7 either. Fixes: Unable to handle kernel paging request at virtual address 50001000 pgd = (ptrval) [50001000] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4 Hardware name: Freescale i.MX53 (Device Tree Support) PC is at v7_dma_clean_range+0x20/0x38 LR is at __dma_page_cpu_to_dev+0x28/0x90 pc : [<c011c76c>] lr : [<c01181c4>] psr: 20000013 sp : d80b5a88 ip : de96c000 fp : d840ce6c r10: 00000000 r9 : 00000001 r8 : d843e010 r7 : 00000000 r6 : 00008000 r5 : ddb6c000 r4 : 00000000 r3 : 0000003f r2 : 00000040 r1 : 50008000 r0 : 50001000 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 70004019 DAC: 00000051 Process swapper/0 (pid: 1, stack limit = 0x(ptrval)) Signed-off-by: Rob Clark <robdclark@chromium.org> Fixes: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem") Tested-by: Fabio Estevam <festevam@gmail.com> 
Looks like the dma_sync calls don't do what we want on armv7 either.
Fixes:

  Unable to handle kernel paging request at virtual address 50001000
  pgd = (ptrval)
  [50001000] *pgd=00000000
  Internal error: Oops: 805 [#1] SMP ARM
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc6-00271-g9f159ae07f07 #4
  Hardware name: Freescale i.MX53 (Device Tree Support)
  PC is at v7_dma_clean_range+0x20/0x38
  LR is at __dma_page_cpu_to_dev+0x28/0x90
  pc : [<c011c76c>]    lr : [<c01181c4>]    psr: 20000013
  sp : d80b5a88  ip : de96c000  fp : d840ce6c
  r10: 00000000  r9 : 00000001  r8 : d843e010
  r7 : 00000000  r6 : 00008000  r5 : ddb6c000  r4 : 00000000
  r3 : 0000003f  r2 : 00000040  r1 : 50008000  r0 : 50001000
  Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: 70004019  DAC: 00000051
  Process swapper/0 (pid: 1, stack limit = 0x(ptrval))

Signed-off-by: Rob Clark <robdclark@chromium.org>
Fixes: 3de433c5b38a ("drm/msm: Use the correct dma_sync calls in msm_gem")
Tested-by: Fabio Estevam <festevam@gmail.com>
drm/msm: remove unlikely() from WARN_ON() conditions 2019-09-04T15:42:45+00:00 Denis Efremov efremov@linux.com 2019-08-29T16:50:16+00:00 c044e86f541a20085891c41e685a4201064430b5 "unlikely(WARN_ON(x))" is excessive. WARN_ON() already uses unlikely() internally. Signed-off-by: Denis Efremov <efremov@linux.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Joe Perches <joe@perches.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Rob Clark <robdclark@chromium.org> 
"unlikely(WARN_ON(x))" is excessive. WARN_ON() already uses unlikely()
internally.

Signed-off-by: Denis Efremov <efremov@linux.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Joe Perches <joe@perches.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
drm/msm/dsi: Fix return value check for clk_get_parent 2019-09-03T23:17:02+00:00 Sean Paul seanpaul@chromium.org 2019-08-07T18:51:50+00:00 5fb9b797d5ccf311ae4aba69e86080d47668b5f7 clk_get_parent returns an error pointer upon failure, not NULL. So the checks as they exist won't catch a failure. This patch changes the checks and the return values to properly handle an error pointer. Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions") Cc: Sibi Sankar <sibis@codeaurora.org> Cc: Sean Paul <seanpaul@chromium.org> Cc: Rob Clark <robdclark@chromium.org> Cc: <stable@vger.kernel.org> # v4.19+ Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Rob Clark <robdclark@chromium.org> 
clk_get_parent returns an error pointer upon failure, not NULL. So the
checks as they exist won't catch a failure. This patch changes the
checks and the return values to properly handle an error pointer.

Fixes: c4d8cfe516dc ("drm/msm/dsi: add implementation for helper functions")
Cc: Sibi Sankar <sibis@codeaurora.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Rob Clark <robdclark@chromium.org>
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
drm/msm: add atomic traces 2019-09-03T23:17:02+00:00 Rob Clark robdclark@chromium.org 2019-08-29T16:45:18+00:00 d934a712c5e6a3724dd560b8e92eb230b025ee8d This was useful for debugging fps drops. I suspect it will be useful again. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Sean Paul <sean@poorly.run> 
This was useful for debugging fps drops.  I suspect it will be useful
again.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Sean Paul <sean@poorly.run>