Commit 24417d5b0c ("drm/bridge: ti-sn65dsi83: Implement .detach
callback") moved the unregistration of the bridge DSI device and bridge
itself to the detach callback.
While this is correct for the DSI device detach and unregistration, the
bridge is added in the driver probe, and should thus be removed as part
of its remove callback.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Fixes: 24417d5b0c ("drm/bridge: ti-sn65dsi83: Implement .detach callback")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-14-maxime@cerno.tech
Linking the CMA framebuffer helpers into a CMA helper library in
commit 4b2b5e142f ("drm: Move GEM memory managers into modules")
results in linker errors:
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: \
in function `drm_fb_cma_get_gem_obj': \
drivers/gpu/drm/drm_fb_cma_helper.c:46: undefined reference \
to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46: \
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:46: \
undefined reference to `drm_gem_fb_get_obj'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.o: in \
function `drm_fb_cma_sync_non_coherent': \
drivers/gpu/drm/drm_fb_cma_helper.c:133: undefined reference \
to `drm_atomic_helper_damage_iter_init'
arm-linux-gnueabihf-ld: drivers/gpu/drm/drm_fb_cma_helper.c:135: \
undefined reference to `drm_atomic_helper_damage_iter_next'
Link the CMA framebuffer helpers into the KMS helper library to
fix the problem.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 4b2b5e142f ("drm: Move GEM memory managers into modules")
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20211026175700.27664-1-tzimmermann@suse.de
The new driver incorrectly unwinds after errors, as clang points out:
drivers/dma-buf/st-dma-resv.c:295:7: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (r) {
^
drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here
while (i--)
^
drivers/dma-buf/st-dma-resv.c:295:3: note: remove the 'if' if its condition is always false
if (r) {
^~~~~~~~
drivers/dma-buf/st-dma-resv.c:288:6: error: variable 'i' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (r) {
^
drivers/dma-buf/st-dma-resv.c:336:9: note: uninitialized use occurs here
while (i--)
^
drivers/dma-buf/st-dma-resv.c:288:2: note: remove the 'if' if its condition is always false
if (r) {
^~~~~~~~
drivers/dma-buf/st-dma-resv.c:280:10: note: initialize the variable 'i' to silence this warning
int r, i;
^
= 0
Skip cleaning up the bits that have not been allocated at this point.
Fixes: 1d51775cd3 ("dma-buf: add dma_resv selftest v4")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026083448.3471055-1-arnd@kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
Since commit 875a4d5368 ("drm/vc4: drv: Disable the CRTC at boot
time"), during the initial setup of the driver we call into the VC4 HDMI
controller hooks to make sure the controller is properly disabled.
However, we were never making sure that the device was properly powered
while doing so. This never resulted in any (reported) issue in practice,
but since the introduction of commit 4209f03fcb8e ("drm/vc4: hdmi: Warn
if we access the controller while disabled") we get a loud complaint
when we do that kind of access.
Let's make sure we have the HDMI controller properly powered while
disabling it.
Fixes: 875a4d5368 ("drm/vc4: drv: Disable the CRTC at boot time")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210923185013.826679-1-maxime@cerno.tech
Similarly to what we encountered with the detect hook with DRM, nothing
actually prevents any of the CEC callback from being run while the HDMI
output is disabled.
However, this is an issue since any register access to the controller
when it's powered down will result in a silent hang.
Let's make sure we run the runtime_pm hooks when the CEC adapter is
opened and closed by the userspace to avoid that issue.
Fixes: 15b4511a4a ("drm/vc4: add HDMI CEC support")
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210819135931.895976-6-maxime@cerno.tech
Since our pre_crtc_configure hook returned void, we didn't implement a
goto-based error path handling, leading to errors like failing to put
back the device in pm_runtime in all the error paths, but also failing
to disable the pixel clock if clk_set_min_rate on the HSM clock fails.
Move to a goto-based implementation to have an easier consitency.
Fixes: 4f6e3d66ac ("drm/vc4: Add runtime PM support to the HDMI encoder driver")
Link: https://patchwork.freedesktop.org/patch/msgid/20210819135931.895976-4-maxime@cerno.tech
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
The driver, once it found a divider, tries to round it up by increasing
the least significant bit of the fractional part by one when the
round_up argument is set and there's a remainder.
However, since it increases the divider it will actually reduce the
clock rate below what we were asking for, leading to issues with
clk_set_min_rate() that will complain that our rounded clock rate is
below the minimum of the rate.
Since the dividers are fairly precise already, let's remove that part so
that we can have clk_set_min_rate() working.
This is effectively a revert of 9c95b32ca0 ("clk: bcm2835: add a round
up ability to the clock divisor").
Fixes: 9c95b32ca0 ("clk: bcm2835: add a round up ability to the clock divisor")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenz@kernel.org> # boot and basic functionality
Tested-by: Michael Stapelberg <michael@stapelberg.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-3-maxime@cerno.tech
The driver currently tries to pick the closest rate that is lower than
the rate being requested.
This causes an issue with clk_set_min_rate() since it actively checks
for the rounded rate to be above the minimum that was just set.
Let's change the logic a bit to pick the closest rate to the requested
rate, no matter if it's actually higher or lower.
Fixes: 6d18b8adbe ("clk: bcm2835: Support for clock parent selection")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Tested-by: Nicolas Saenz Julienne <nsaenz@kernel.org> # boot and basic functionality
Tested-by: Michael Stapelberg <michael@stapelberg.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-2-maxime@cerno.tech
