- 29 Oct, 2021 1 commit
-
-
Chia-I Wu authored
Add Gurchetan Singh and me as reviewers for virtio-gpu. Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Acked-by:
Gurchetan Singh <gurchetansingh@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Daniel Stone <daniels@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211028213446.955338-1-olvaffe@gmail.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
- 28 Oct, 2021 2 commits
-
-
Bjorn Andersson authored
When built without CONFIG_PWM there are no references to ti_sn65dsi86_read_u16(), avoid the W=1 build warning by marking the function as __maybe_unused. __maybe_unused is used insted of a #ifdef guard as it looks slighly cleaner and it avoids issues if in the future other permutations of the config options would use the function. Reported-by:
kernel test robot <lkp@intel.com> Fixes: cea86c5b ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211028163548.273736-1-bjorn.andersson@linaro.orgSigned-off-by:
-
Guangming Cao authored
In this patch(https://patchwork.freedesktop.org/patch/310349), it add a new IOCTL to support dma-buf user to set debug name. But it also added a limitation of this IOCTL, it needs the attachments of dmabuf should be empty, otherwise it will fail. For the original series, the idea was that allowing name change mid-use could confuse the users about the dma-buf. However, the rest of the series also makes sure each dma-buf have a unique inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting should probably use that, without relying on the name as much. So, removing this restriction will let dma-buf userspace users to use it more comfortably and without any side effect. Signed-off-by:
Guangming Cao <Guangming.Cao@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014102551.54983-1-guangming.cao@mediatek.comReviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 27 Oct, 2021 28 commits
-
-
Anitha Chrisanthus authored
Enable support for fbcon (framebuffer console). v2: added missing static clk_enable v3: removed module parameter, use fbdev_emulation instead. Use preferred depth of 24 for color depth. (Thomas Z.) Signed-off-by:
Anitha Chrisanthus <anitha.chrisanthus@intel.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211019230719.789958-2-anitha.chrisanthus@intel.com
-
Rob Clark authored
Switch to the documented order dsi-host vs bridge probe. Tested-by:
Amit Pundir <amit.pundir@linaro.org> Tested-by:
Caleb Connolly <caleb.connolly@linaro.org> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211025151536.1048186-22-maxime@cerno.tech
-
Maxime Ripard authored
Without proper care and an agreement between how DSI hosts and devices drivers register their MIPI-DSI entities and potential components, we can end up in a situation where the drivers can never probe. Most drivers were taking evasive maneuvers to try to workaround this, but not all of them were following the same conventions, resulting in various incompatibilities between DSI hosts and devices. Now that we have a sequence agreed upon and documented, let's convert kirin to it. 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:
-
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:
-
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:
-
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:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
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:
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 8 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:
-
