- 29 Oct, 2021 10 commits
-
-
Paul Cercueil authored
When using C8 color mode, make sure that the palette is always uploaded before a frame; otherwise the very first frame will have wrong colors. Do that by changing the link order of the DMA descriptors. v3: Fix ingenic_drm_get_new_priv_state() called instead of ingenic_drm_get_priv_state() Signed-off-by:Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-6-paul@crapouillou.netTested-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
Setting the DMA descriptor chain register in the probe function has been fine until now, because we only ever had one descriptor per foreground. As the driver will soon have real descriptor chains, and the DMA descriptor chain register updates itself to point to the current descriptor being processed, this register needs to be reset after a full modeset to point to the first descriptor of the chain. Signed-off-by:
-
Paul Cercueil authored
The IPU scaling information is computed in the plane's ".atomic_check" callback, and used in the ".atomic_update" callback. As such, it is state-specific, and should be moved to a private state structure. Signed-off-by:
-
Paul Cercueil authored
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to put state-specific information in their respective private structure. Add boilerplate code to support private objects in the two drivers, so that state-specific information can be put in the state-specific private structure. Signed-off-by:
-
Paul Cercueil authored
Instead of having one 'hwdesc' variable for the plane #0, one for the plane #1 and one for the palette, use a 'hwdesc[3]' array, where the DMA hardware descriptors are indexed by the plane's number. v2: dma_hwdesc_addr() extended to support palette hwdesc. The palette hwdesc is now hwdesc[3] to simplify things. Add ingenic_drm_configure_hwdesc*() functions to factorize code. Signed-off-by: -
Marcel Ziswiler authored
Today's -next fails building arm64 defconfig as follows: ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vunmap from namespace DMA_BUF, but does not import it. ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vmap from namespace DMA_BUF, but does not import it. Fix this by importing DMA_BUF namespace into drm_cma_helper.ko. Also fix the problem with drm_shmem_helper.ko. Reported-by:
Linux Kernel Functional Testing <lkft@linaro.org> Fixes: 4b2b5e14 ("drm: Move GEM memory managers into modules") Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211027212506.3418521-1-marcel@ziswiler.com
-
Christian König authored
Makes the handling a bit more complex, but avoids the use of dma_resv_get_excl_unlocked(). Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-27-christian.koenig@amd.com
-
Colin Ian King authored
The left shift of unsigned int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where value is 32 or more this can lead to an overflow (value can be in range 0..MAX_CAPSET_ID (63). Fix this by shifting the value 1ULL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: 4fb530e5 ("drm/virtio: implement context init: support init ioctl") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210930102748.16922-1-colin.king@canonical.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Colin Ian King authored
The left shift of unsigned int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where i is 32 or more this can lead to an overflow. Fix this by shifting the value 1ULL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: 8d6b006e ("drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK") Signed-off-by: -
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:
-
- 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:
-
- 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:
Naresh Kamboju <naresh.kamboju@linaro.org> Reported-by:
-
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:
-
