kernel/linux.git/drivers/gpu/drm/ingenic, branch v5.10.257

drm/ingenic: Fix missing platform_driver_unregister() call in ingenic_drm_init()

2023-01-14T09:16:37+00:00

commit 47078311b8efebdefd5b3b2f87e2b02b14f49c66 upstream. A problem about modprobe ingenic-drm failed is triggered with the following log given: [ 303.561088] Error: Driver 'ingenic-ipu' is already registered, aborting... modprobe: ERROR: could not insert 'ingenic_drm': Device or resource busy The reason is that ingenic_drm_init() returns platform_driver_register() directly without checking its return value, if platform_driver_register() failed, it returns without unregistering ingenic_ipu_driver_ptr, resulting the ingenic-drm can never be installed later. A simple call graph is shown as below: ingenic_drm_init() platform_driver_register() # ingenic_ipu_driver_ptr are registered platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without unregister ingenic_ipu_driver_ptr Fixing this problem by checking the return value of platform_driver_register() and do platform_unregister_drivers() if error happened. Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") Signed-off-by: Yuan Can Cc: stable@vger.kernel.org Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/20221104064512.8569-1-yuancan@huawei.com Signed-off-by: Greg Kroah-Hartman

drm/ingenic: Reset pixclock rate when parent clock rate changes

2022-06-09T08:21:00+00:00

[ Upstream commit 33700f6f7d9f6b4e1e6df933ef7fd388889c662c ] Old Ingenic SoCs can overclock very well, up to +50% of their nominal clock rate, whithout requiring overvolting or anything like that, just by changing the rate of the main PLL. Unfortunately, all clocks on the system are derived from that PLL, and when the PLL rate is updated, so is our pixel clock. To counter that issue, we make sure that the panel is in VBLANK before the rate change happens, and we will then re-set the pixel clock rate afterwards, once the PLL has been changed, to be as close as possible to the pixel rate requested by the encoder. v2: Add comment about mutex usage Signed-off-by: Paul Cercueil Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-2-paul@crapouillou.net Signed-off-by: Sasha Levin

drm/ingenic: Switch IPU plane to type OVERLAY

2021-07-20T14:05:37+00:00

commit 68b433fe6937cfa3f8975d18643d5956254edd6a upstream. It should have been an OVERLAY from the beginning. The documentation stipulates that there should be an unique PRIMARY plane per CRTC. Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") Cc: # 5.8+ Signed-off-by: Paul Cercueil Acked-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20210329175046.214629-2-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

drm/ingenic: Fix non-OSD mode

2021-07-20T14:05:37+00:00

commit 7b4957684e5d813fcbdc98144e3cc5c4467b3e2e upstream. Even though the JZ4740 did not have the OSD mode, it had (according to the documentation) two DMA channels, but there is absolutely no information about how to select the second DMA channel. Make the ingenic-drm driver work in non-OSD mode by using the foreground0 plane (which is bound to the DMA0 channel) as the primary plane, instead of the foreground1 plane, which is the primary plane when in OSD mode. Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode") Cc: # v5.8+ Signed-off-by: Paul Cercueil Acked-by: Daniel Vetter Tested-by: H. Nikolaus Schaller Link: https://patchwork.freedesktop.org/patch/msgid/20210124085552.29146-5-paul@crapouillou.net Signed-off-by: Greg Kroah-Hartman

drm/ingenic: Fix bad revert

2020-10-12T18:26:14+00:00

Fix a badly reverted commit. The revert commit was cherry-picked from drm-misc-next to drm-misc-next-fixes, and in the process some unrelated code was added. Fixes: a3fb64c00d44 ("Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"") Signed-off-by: Paul Cercueil Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201012102509.10690-1-paul@crapouillou.net

Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"

2020-10-07T19:57:59+00:00

This reverts commit 37054fc81443 ("gpu/drm: ingenic: Add option to mmap GEM buffers cached") At the very moment this commit was created, the DMA API it relied on was modified in the DMA tree, which caused the driver to break in linux-next. Revert it for now, and it will be resubmitted later to work with the new DMA API. Signed-off-by: Paul Cercueil Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201004141758.1013317-1-paul@crapouillou.net

gpu/drm: ingenic: Add option to mmap GEM buffers cached

2020-09-14T23:32:26+00:00

Ingenic SoCs are most notably used in cheap chinese handheld gaming consoles. There, the games and applications generally render in software directly into GEM buffers. Traditionally, GEM buffers are mapped write-combine. Writes to the buffer are accelerated, and reads are slow. Application doing lots of alpha-blending paint inside shadow buffers, which is then memcpy'd into the final GEM buffer. On recent Ingenic SoCs however, it is much faster to have a fully cached GEM buffer, in which applications paint directly, and whose data is invalidated before scanout, than having a write-combine GEM buffer, even when alpha blending is not used. Add an optional 'cached_gem_buffers' parameter to the ingenic-drm driver to allow GEM buffers to be mapped fully-cached, in order to speed up software rendering. v2: Use standard noncoherent DMA APIs v3: Use damage clips instead of invalidating full frames v4: Avoid dma_pgprot() which is not exported. Using vm_get_page_prot() is enough in this case. v5: - Avoid calling drm_gem_cma_prime_mmap(). It has the side effect that an extra object reference is obtained, which causes our dumb buffers to never be freed. It should have been drm_gem_cma_mmap_obj(). However, our custom mmap function only differs with one flag, so we can cleanly handle both modes in ingenic_drm_gem_mmap(). - Call drm_gem_vm_close() if drm_mmap_attrs() failed, just like in drm_gem_cma_mmap_obj(). Signed-off-by: Paul Cercueil Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200912195639.176001-1-paul@crapouillou.net

Merge v5.9-rc5 into drm-next

2020-09-14T15:19:11+00:00

Paul needs 1a21e5b930e8 ("drm/ingenic: Fix leak of device_node pointer") and 3b5b005ef7d9 ("drm/ingenic: Fix driver not probing when IPU port is missing") from -fixes to be able to merge further ingenic patches into -next. Signed-off-by: Daniel Vetter

drm/ingenic: Fix driver not probing when IPU port is missing

2020-08-30T22:52:40+00:00

Even if support for the IPU was compiled in, we may run on a device (e.g. the Qi LB60) where the IPU is not available, or simply with an old devicetree without the IPU node. In that case the ingenic-drm refused to probe. Fix the driver so that it will probe even if the IPU node is not present in devicetree (but then IPU support is disabled of course). v2: Take a different approach Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") Signed-off-by: Paul Cercueil Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200827114404.36748-2-paul@crapouillou.net

drm/ingenic: Fix leak of device_node pointer

2020-08-30T22:52:32+00:00

of_graph_get_remote_node() requires of_node_put() to be called on the device_node pointer when it's no more in use. Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU") Signed-off-by: Paul Cercueil Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200827114404.36748-1-paul@crapouillou.net