- 27 Oct, 2021 23 commits
-
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-18-maxime@cerno.tech
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge but don't remove its driver. Acked-by:
-
Maxime Ripard authored
Commit 24417d5b ("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:
Marek Vasut <marex@denx.de> Fixes: 24417d5b ("drm/bridge: ti-sn65dsi83: Implement .detach callback") Signed-off-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device on removal. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
-
Maxime Ripard authored
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by:
-
Thomas Zimmermann authored
Linking the CMA framebuffer helpers into a CMA helper library in commit 4b2b5e14 ("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: 4b2b5e14 ("drm: Move GEM memory managers into modules") Reviewed-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
-
Bjorn Andersson authored
The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4, with the primary purpose of controlling the backlight of the attached panel. Add an implementation that exposes this using the standard PWM framework, to allow e.g. pwm-backlight to expose this to the user. Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211025170925.3096444-3-bjorn.andersson@linaro.org
-
Bjorn Andersson authored
The multi-register u16 write operation can use regmap_bulk_write() instead of two separate regmap_write() calls. It's uncertain if this has any effect on the actual updates of the underlying registers, but this at least gives the hardware the opportunity and saves us one transation on the bus. Signed-off-by:
-
Bjorn Andersson authored
The existing pxa driver and the upcoming addition of PWM support in the TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and thereby a need for a of_xlate function with the period as its single argument. Introduce a common helper function in the core that can be used as of_xlate by such drivers and migrate the pxa driver to use this. Signed-off-by:
Steev Klimaszewski <steev@kali.org> Tested-By:
-
Christian König authored
We certainly hold the reservation lock here, no need for the RCU dance. Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211025080532.177424-3-christian.koenig@amd.com
-
Christian König authored
Instead of hand rolling the logic. Signed-off-by:
-
- 26 Oct, 2021 1 commit
-
-
Arnd Bergmann authored
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: 1d51775c ("dma-buf: add dma_resv selftest v4") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
- 25 Oct, 2021 16 commits
-
-
Yang Li authored
Eliminate the following coccicheck warning: ./drivers/gpu/drm/panel/panel-novatek-nt35950.c:639:2-3: Unneeded semicolon Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Fixes: 623a3531 ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels") Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
chongjiapeng authored
This symbol is not used outside of panel-novatek-nt35950.c, so marks it static. Fixes the following sparse warning: drivers/gpu/drm/panel/panel-novatek-nt35950.c:671:33: warning: symbol 'sharp_ls055d1sx04' was not declared. Should it be static? Reported-by:
chongjiapeng <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
John Keeping authored
The panel orientation needs to parsed from a device-tree and assigned to the panel's connector in order to make orientation property available to userspace. That's what this patch does for ILI9881C based panels. Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
-
John Keeping authored
Allow the standard rotation property from panel-common for ILI9881C based panels. Signed-off-by:
-
John Keeping authored
The properties below refer to items in panel-common.yaml, which means that needs to be referenced in the schema. Signed-off-by:
-
Maxime Ripard authored
Since commit 875a4d53 ("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: 875a4d53 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Tested-by:
-
Maxime Ripard authored
We've had many silent hangs where the kernel would look like it just stalled due to the access to one of the HDMI registers while the controller was disabled. Add a warning if we're about to do that so that it's at least not silent anymore. Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
Maxime Ripard authored
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: 15b4511a ("drm/vc4: add HDMI CEC support") Reviewed-by:
-
Maxime Ripard authored
In order to ease further additions to the CEC enable and disable, let's split the function into two functions, one to enable and the other to disable. Reviewed-by:
-
Maxime Ripard authored
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: 4f6e3d66 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Link: https://patchwork.freedesktop.org/patch/msgid/20210819135931.895976-4-maxime@cerno.techReviewed-by:
-
Maxime Ripard authored
In the bind hook, we actually need the device to have the HSM clock running during the final part of the display initialisation where we reset the controller and initialise the CEC component. Failing to do so will result in a complete, silent, hang of the CPU. Fixes: 411efa18 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Link: https://patchwork.freedesktop.org/patch/msgid/20210819135931.895976-3-maxime@cerno.techReviewed-by:
-
Maxime Ripard authored
If the HPD GPIO is not available and drm_probe_ddc fails, we end up reading the HDMI_HOTPLUG register, but the controller might be powered off resulting in a CPU hang. Make sure we have the power domain and the HSM clock powered during the detect cycle to prevent the hang from happening. Fixes: 4f6e3d66 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by:
Michael Stapelberg <michael@stapelberg.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-6-maxime@cerno.tech
-
Maxime Ripard authored
In order to access the HDMI controller, we need to make sure the HSM clock is enabled. If we were to access it with the clock disabled, the CPU would completely hang, resulting in an hard crash. Since we have different code path that would require it, let's move that clock enable / disable to runtime_pm that will take care of the reference counting for us. Since we also want to change the HSM clock rate and it's only valid while the clock is disabled, we need to move the clk_set_min_rate() call on the HSM clock above pm_runtime_get_and_sync(). Fixes: 4f6e3d66 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by:
-
Maxime Ripard authored
When the firmware doesn't setup the HSM rate (such as when booting without an HDMI cable plugged in), its rate is 0 and thus any register access results in a CPU stall, even though HSM is enabled. Let's enforce a minimum rate at boot to avoid this issue. Fixes: 4f6e3d66 ("drm/vc4: Add runtime PM support to the HDMI encoder driver") Signed-off-by:
-
Maxime Ripard authored
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 9c95b32c ("clk: bcm2835: add a round up ability to the clock divisor"). Fixes: 9c95b32c ("clk: bcm2835: add a round up ability to the clock divisor") Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Reviewed-by:
-
Maxime Ripard authored
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: 6d18b8ad ("clk: bcm2835: Support for clock parent selection") Signed-off-by:
-
