linux-stable.git/drivers/gpu/drm/vc4, branch v5.17.2 Linux kernel stable tree Merge tag 'drm-misc-fixes-2022-02-23' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes 2022-02-24T03:53:13+00:00 Dave Airlie airlied@redhat.com 2022-02-24T03:51:46+00:00 753a64c7799034a413083ad03b9fe51dfcad9fb2 * edid: Always set RGB444 * imx/dcss: Select GEM CMA helpers * radeon: Fix some variables's type * vc4: Fix codec cleanup; Fix PM reference counting Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YhaKj4zWJ42YWRts@linux-uq9g.fritz.box 
 * edid: Always set RGB444
 * imx/dcss: Select GEM CMA helpers
 * radeon: Fix some variables's type
 * vc4: Fix codec cleanup; Fix PM reference counting

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YhaKj4zWJ42YWRts@linux-uq9g.fritz.box
drm/vc4: crtc: Fix runtime_pm reference counting 2022-02-17T16:27:59+00:00 Maxime Ripard maxime@cerno.tech 2022-02-03T10:20:03+00:00 6764eb690e77ecded48587d6d4e346ba2e196546 At boot on the BCM2711, if the HDMI controllers are running, the CRTC driver will disable itself and its associated HDMI controller to work around a hardware bug that would leave some pixels stuck in a FIFO. In order to avoid that issue, we need to run some operations in lockstep between the CRTC and HDMI controller, and we need to make sure the HDMI controller will be powered properly. However, since we haven't enabled it through KMS, the runtime_pm state is off at this point so we need to make sure the device is powered through pm_runtime_resume_and_get, and once the operations are complete, we call pm_runtime_put. However, the HDMI controller will do that itself in its post_crtc_powerdown, which means we'll end up calling pm_runtime_put for a single pm_runtime_get, throwing the reference counting off. Let's remove the pm_runtime_put call in the CRTC code in order to have the proper counting. Fixes: bca10db67bda ("drm/vc4: crtc: Make sure the HDMI controller is powered when disabling") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203102003.1114673-1-maxime@cerno.tech 
At boot on the BCM2711, if the HDMI controllers are running, the CRTC
driver will disable itself and its associated HDMI controller to work
around a hardware bug that would leave some pixels stuck in a FIFO.

In order to avoid that issue, we need to run some operations in lockstep
between the CRTC and HDMI controller, and we need to make sure the HDMI
controller will be powered properly.

However, since we haven't enabled it through KMS, the runtime_pm state
is off at this point so we need to make sure the device is powered
through pm_runtime_resume_and_get, and once the operations are complete,
we call pm_runtime_put.

However, the HDMI controller will do that itself in its
post_crtc_powerdown, which means we'll end up calling pm_runtime_put for
a single pm_runtime_get, throwing the reference counting off. Let's
remove the pm_runtime_put call in the CRTC code in order to have the
proper counting.

Fixes: bca10db67bda ("drm/vc4: crtc: Make sure the HDMI controller is powered when disabling")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203102003.1114673-1-maxime@cerno.tech
drm/vc4: hdmi: Unregister codec device on unbind 2022-02-17T16:27:54+00:00 Maxime Ripard maxime@cerno.tech 2022-01-27T11:14:52+00:00 e40945ab7c7f966d0c37b7bd7b0596497dfe228d On bind we will register the HDMI codec device but we don't unregister it on unbind, leading to a device leakage. Unregister our device at unbind. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127111452.222002-1-maxime@cerno.tech 
On bind we will register the HDMI codec device but we don't unregister
it on unbind, leading to a device leakage. Unregister our device at
unbind.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127111452.222002-1-maxime@cerno.tech
Merge tag 'drm-misc-fixes-2022-02-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes 2022-02-11T02:06:15+00:00 Dave Airlie airlied@redhat.com 2022-02-11T02:05:04+00:00 df2bb4dc285e60665930889e6f8c5bb38b90249a * drm/panel: simple: Fix assignments from panel_dpi_probe() * drm/privacy-screen: Cleanups * drm/rockchip: Fix HDMI error cleanup; Fix RK3399 VOP register fields * drm/vc4: HDMI fixes; Cleanups * fbdev: Add fbdev core module with Daniel as maintainer; Cleanups Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/YgTf1Zsflzq3JSFo@linux-uq9g 
 * drm/panel: simple: Fix assignments from panel_dpi_probe()
 * drm/privacy-screen: Cleanups
 * drm/rockchip: Fix HDMI error cleanup; Fix RK3399 VOP register fields
 * drm/vc4: HDMI fixes; Cleanups
 * fbdev: Add fbdev core module with Daniel as maintainer; Cleanups

Signed-off-by: Dave Airlie <airlied@redhat.com>

From: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/YgTf1Zsflzq3JSFo@linux-uq9g
drm/vc4: crtc: Fix redundant variable assignment 2022-02-07T10:15:53+00:00 Maxime Ripard maxime@cerno.tech 2022-02-03T15:11:51+00:00 fc764b103b81ebe88f69f9ae4f116551ab8cfc5d The variable is assigned twice to the same value. Let's drop one. Reported-by: kernel test robot <yujie.liu@intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220203151151.1270461-1-maxime@cerno.tech 
The variable is assigned twice to the same value. Let's drop one.

Reported-by: kernel test robot <yujie.liu@intel.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203151151.1270461-1-maxime@cerno.tech
drm/vc4: hdmi: Allow DBLCLK modes even if horz timing is odd. 2022-02-03T15:07:59+00:00 Dave Stevenson dave.stevenson@raspberrypi.com 2022-01-27T13:51:16+00:00 1d118965965f89948236ebe23072bb1fca5e7832 The 2711 pixel valve can't produce odd horizontal timings, and checks were added to vc4_hdmi_encoder_atomic_check and vc4_hdmi_encoder_mode_valid to filter out/block selection of such modes. Modes with DRM_MODE_FLAG_DBLCLK double all the horizontal timing values before programming them into the PV. The PV values, therefore, can not be odd, and so the modes can be supported. Amend the filtering appropriately. Fixes: 57fb32e632be ("drm/vc4: hdmi: Block odd horizontal timings") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127135116.298278-1-maxime@cerno.tech 
The 2711 pixel valve can't produce odd horizontal timings, and
checks were added to vc4_hdmi_encoder_atomic_check and
vc4_hdmi_encoder_mode_valid to filter out/block selection of
such modes.

Modes with DRM_MODE_FLAG_DBLCLK double all the horizontal timing
values before programming them into the PV. The PV values,
therefore, can not be odd, and so the modes can be supported.

Amend the filtering appropriately.

Fixes: 57fb32e632be ("drm/vc4: hdmi: Block odd horizontal timings")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127135116.298278-1-maxime@cerno.tech
drm/vc4: hdmi: Don't try disabling SCDC on Pi0-3. 2022-02-03T15:07:59+00:00 Dave Stevenson dave.stevenson@raspberrypi.com 2022-01-27T13:45:59+00:00 71702c495b78dfbc22eeac32ea9cda452862750d The code that set the scdc_enabled flag to ensure it was disabled at boot time also ran on Pi0-3 where there is no SCDC support. This lead to a warning in vc4_hdmi_encoder_post_crtc_disable due to vc4_hdmi_disable_scrambling being called and trying to read (and write) register HDMI_SCRAMBLER_CTL which doesn't exist on those platforms. Only set the flag should the interface be configured to support more than HDMI 1.4. Fixes: 1998646129fa ("drm/vc4: hdmi: Introduce a scdc_enabled flag") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127134559.292778-1-maxime@cerno.tech 
The code that set the scdc_enabled flag to ensure it was
disabled at boot time also ran on Pi0-3 where there is no
SCDC support. This lead to a warning in vc4_hdmi_encoder_post_crtc_disable
due to vc4_hdmi_disable_scrambling being called and trying to
read (and write) register HDMI_SCRAMBLER_CTL which doesn't
exist on those platforms.

Only set the flag should the interface be configured to support
more than HDMI 1.4.

Fixes: 1998646129fa ("drm/vc4: hdmi: Introduce a scdc_enabled flag")
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127134559.292778-1-maxime@cerno.tech
drm/vc4: hdmi: Ensure we don't use 2711 HPD registers on Pi0-3 2022-02-03T15:07:59+00:00 Dave Stevenson dave.stevenson@raspberrypi.com 2022-01-27T13:17:54+00:00 3404b39919c3c87677cdba45405d24033b3276f3 The existing logic was flawed in that it could try reading the 2711 specific registers for HPD on a CM1/3 where the HPD GPIO hadn't been defined in DT. Ensure we don't do the 2711 register read on invalid hardware, and then Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127131754.236074-1-maxime@cerno.tech 
The existing logic was flawed in that it could try reading the
2711 specific registers for HPD on a CM1/3 where the HPD GPIO
hadn't been defined in DT.

Ensure we don't do the 2711 register read on invalid hardware,
and then

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127131754.236074-1-maxime@cerno.tech
drm/vc4: Fix deadlock on DSI device attach error 2022-01-19T09:08:48+00:00 Padmanabha Srinivasaiah treasure4paddy@gmail.com 2022-01-18T00:51:26+00:00 0a3d12ab5097b1d045e693412e6b366b7e82031b DSI device attach to DSI host will be done with host device's lock held. Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display. Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20 Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184 Signed-off-by: Padmanabha Srinivasaiah <treasure4paddy@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220118005127.29015-1-treasure4paddy@gmail.com 
DSI device attach to DSI host will be done with host device's lock
held.

Un-registering host in "device attach" error path (ex: probe retry)
will result in deadlock with below call trace and non operational
DSI display.

Startup Call trace:
[   35.043036]  rt_mutex_slowlock.constprop.21+0x184/0x1b8
[   35.043048]  mutex_lock_nested+0x7c/0xc8
[   35.043060]  device_del+0x4c/0x3e8
[   35.043075]  device_unregister+0x20/0x40
[   35.043082]  mipi_dsi_remove_device_fn+0x18/0x28
[   35.043093]  device_for_each_child+0x68/0xb0
[   35.043105]  mipi_dsi_host_unregister+0x40/0x90
[   35.043115]  vc4_dsi_host_attach+0xf0/0x120 [vc4]
[   35.043199]  mipi_dsi_attach+0x30/0x48
[   35.043209]  tc358762_probe+0x128/0x164 [tc358762]
[   35.043225]  mipi_dsi_drv_probe+0x28/0x38
[   35.043234]  really_probe+0xc0/0x318
[   35.043244]  __driver_probe_device+0x80/0xe8
[   35.043254]  driver_probe_device+0xb8/0x118
[   35.043263]  __device_attach_driver+0x98/0xe8
[   35.043273]  bus_for_each_drv+0x84/0xd8
[   35.043281]  __device_attach+0xf0/0x150
[   35.043290]  device_initial_probe+0x1c/0x28
[   35.043300]  bus_probe_device+0xa4/0xb0
[   35.043308]  deferred_probe_work_func+0xa0/0xe0
[   35.043318]  process_one_work+0x254/0x700
[   35.043330]  worker_thread+0x4c/0x448
[   35.043339]  kthread+0x19c/0x1a8
[   35.043348]  ret_from_fork+0x10/0x20

Shutdown Call trace:
[  365.565417] Call trace:
[  365.565423]  __switch_to+0x148/0x200
[  365.565452]  __schedule+0x340/0x9c8
[  365.565467]  schedule+0x48/0x110
[  365.565479]  schedule_timeout+0x3b0/0x448
[  365.565496]  wait_for_completion+0xac/0x138
[  365.565509]  __flush_work+0x218/0x4e0
[  365.565523]  flush_work+0x1c/0x28
[  365.565536]  wait_for_device_probe+0x68/0x158
[  365.565550]  device_shutdown+0x24/0x348
[  365.565561]  kernel_restart_prepare+0x40/0x50
[  365.565578]  kernel_restart+0x20/0x70
[  365.565591]  __do_sys_reboot+0x10c/0x220
[  365.565605]  __arm64_sys_reboot+0x2c/0x38
[  365.565619]  invoke_syscall+0x4c/0x110
[  365.565634]  el0_svc_common.constprop.3+0xfc/0x120
[  365.565648]  do_el0_svc+0x2c/0x90
[  365.565661]  el0_svc+0x4c/0xf0
[  365.565671]  el0t_64_sync_handler+0x90/0xb8
[  365.565682]  el0t_64_sync+0x180/0x184

Signed-off-by: Padmanabha Srinivasaiah <treasure4paddy@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118005127.29015-1-treasure4paddy@gmail.com
Merge drm/drm-next into drm-misc-next 2021-12-16T13:48:27+00:00 Thomas Zimmermann tzimmermann@suse.de 2021-12-16T13:47:38+00:00 9758ff2fa240173e9a45613b07774b7a78b7653e Backmerging for v5.16-rc5. Resolves a conflict between drm-misc-next and drm-misc-fixes in the vc4 driver. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> 
Backmerging for v5.16-rc5. Resolves a conflict between drm-misc-next
and drm-misc-fixes in the vc4 driver.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>