linux.git/drivers/gpu/drm/tegra/plane.c, branch v5.16 Linux kernel source tree Merge drm/drm-next into drm-misc-next 2021-09-14T07:25:30+00:00 Maxime Ripard maxime@cerno.tech 2021-09-14T07:25:30+00:00 2f76520561d01a5f37e6d6ed2c2e441b6a355a96 Kickstart new drm-misc-next cycle. Signed-off-by: Maxime Ripard <maxime@cerno.tech> 
Kickstart new drm-misc-next cycle.

Signed-off-by: Maxime Ripard <maxime@cerno.tech>
drm/tegra: Use fourcc_mod_is_vendor() helper 2021-08-16T10:19:21+00:00 Thierry Reding treding@nvidia.com 2021-06-10T11:12:36+00:00 c1d3cfbc41a15d3eadde760c00fe6ce58a1d4e29 Rather than open-coding the vendor extraction operation, use the newly introduced helper macro. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210610111236.3814211-3-thierry.reding@gmail.com 
Rather than open-coding the vendor extraction operation, use the newly
introduced helper macro.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210610111236.3814211-3-thierry.reding@gmail.com
drm/tegra: dc: Support memory bandwidth management 2021-08-13T10:30:33+00:00 Dmitry Osipenko digetx@gmail.com 2021-06-01T04:21:07+00:00 04d5d5df9df79f9045e76404775fc8a084aac23d Display controller (DC) performs isochronous memory transfers, and thus, has a requirement for a minimum memory bandwidth that shall be fulfilled, otherwise framebuffer data can't be fetched fast enough and this results in a DC's data-FIFO underflow that follows by a visual corruption. The Memory Controller drivers provide facility for memory bandwidth management via interconnect API. Let's wire up the interconnect API support to the DC driver in order to fix the distorted display output on T30 Ouya, T124 TK1 and other Tegra devices. Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124 Signed-off-by: Dmitry Osipenko <digetx@gmail.com> [treding@nvidia.com: unbreak Tegra186+ display support] Signed-off-by: Thierry Reding <treding@nvidia.com> 
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.

The Memory Controller drivers provide facility for memory bandwidth
management via interconnect API. Let's wire up the interconnect API
support to the DC driver in order to fix the distorted display output
on T30 Ouya, T124 TK1 and other Tegra devices.

Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30
Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Tested-by: Nicolas Chauvet <kwizart@gmail.com> # PAZ00 T20 and TK1 T124
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
[treding@nvidia.com: unbreak Tegra186+ display support]
Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/tegra: hub: Fix YUV support 2021-05-31T12:30:11+00:00 Thierry Reding treding@nvidia.com 2021-05-27T18:15:46+00:00 e16efff4e5f490ce34a8c60d9ae7297dca5eb616 The driver currently exposes several YUV formats but fails to properly program all the registers needed to display such formats. Add the right programming sequences so that overlay windows can be used to accelerate color format conversions in multimedia playback use-cases. Signed-off-by: Thierry Reding <treding@nvidia.com> 
The driver currently exposes several YUV formats but fails to properly
program all the registers needed to display such formats. Add the right
programming sequences so that overlay windows can be used to accelerate
color format conversions in multimedia playback use-cases.

Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/tegra: Support sector layout on Tegra194 2021-03-31T15:42:14+00:00 Thierry Reding treding@nvidia.com 2021-03-26T14:51:39+00:00 7b6f846785f41d57917e36851c120cfbe87f0809 Tegra194 has a special physical address bit that enables some memory swizzling logic to support different sector layouts. Support the bit that selects the sector layout which is passed in the framebuffer modifier. Signed-off-by: Thierry Reding <treding@nvidia.com> 
Tegra194 has a special physical address bit that enables some memory
swizzling logic to support different sector layouts. Support the bit
that selects the sector layout which is passed in the framebuffer
modifier.

Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/tegra: gem: Add a clarifying comment 2021-03-31T15:42:14+00:00 Thierry Reding treding@nvidia.com 2021-03-26T14:51:36+00:00 476e93205ff61a6507bcba28f4f01269b65ebb38 Clarify when a fixed IOV address can be used and when a buffer has to be mapped before the IOVA can be used. Signed-off-by: Thierry Reding <treding@nvidia.com> 
Clarify when a fixed IOV address can be used and when a buffer has to
be mapped before the IOVA can be used.

Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/gem: Move drm_gem_fb_prepare_fb() to GEM atomic helpers 2021-02-23T07:54:22+00:00 Thomas Zimmermann tzimmermann@suse.de 2021-02-22T14:17:56+00:00 820c1707177c6fe96beed7f8cc842a683afbf890 The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting, but currently located next to framebuffer helpers. Move it to GEM atomic helpers, rename it slightly and adopt the drivers. Same for the rsp simple-pipe helper. Compile-tested with x86-64, aarch64 and arm. The patch is fairly large, but there are no functional changes. v3: * remove out-comented line in drm_gem_framebuffer_helper.h (Maxime) v2: * rename to drm_gem_plane_helper_prepare_fb() (Daniel) * add tutorial-style documentation Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210222141756.7864-1-tzimmermann@suse.de 
The function drm_gem_fb_prepare_fb() is a helper for atomic modesetting,
but currently located next to framebuffer helpers. Move it to GEM atomic
helpers, rename it slightly and adopt the drivers. Same for the rsp
simple-pipe helper.

Compile-tested with x86-64, aarch64 and arm. The patch is fairly large,
but there are no functional changes.

v3:
	* remove out-comented line in drm_gem_framebuffer_helper.h
	  (Maxime)
v2:
	* rename to drm_gem_plane_helper_prepare_fb() (Daniel)
	* add tutorial-style documentation

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210222141756.7864-1-tzimmermann@suse.de
drm: tegra: fix common struct sg_table related issues 2020-09-10T06:18:35+00:00 Marek Szyprowski m.szyprowski@samsung.com 2020-04-28T11:10:10+00:00 d4fea3e61b47a22e57a58d7afd6f0209051208bd The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function returns the number of the created entries in the DMA address space. However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and dma_unmap_sg must be called with the original number of the entries passed to the dma_map_sg(). struct sg_table is a common structure used for describing a non-contiguous memory buffer, used commonly in the DRM and graphics subsystems. It consists of a scatterlist with memory pages and DMA addresses (sgl entry), as well as the number of scatterlist entries: CPU pages (orig_nents entry) and DMA mapped pages (nents entry). It turned out that it was a common mistake to misuse nents and orig_nents entries, calling DMA-mapping functions with a wrong number of entries or ignoring the number of mapped entries returned by the dma_map_sg() function. To avoid such issues, lets use a common dma-mapping wrappers operating directly on the struct sg_table objects and use scatterlist page iterators where possible. This, almost always, hides references to the nents and orig_nents entries, making the code robust, easier to follow and copy/paste safe. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> 
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_map_sg().

struct sg_table is a common structure used for describing a non-contiguous
memory buffer, used commonly in the DRM and graphics subsystems. It
consists of a scatterlist with memory pages and DMA addresses (sgl entry),
as well as the number of scatterlist entries: CPU pages (orig_nents entry)
and DMA mapped pages (nents entry).

It turned out that it was a common mistake to misuse nents and orig_nents
entries, calling DMA-mapping functions with a wrong number of entries or
ignoring the number of mapped entries returned by the dma_map_sg()
function.

To avoid such issues, lets use a common dma-mapping wrappers operating
directly on the struct sg_table objects and use scatterlist page
iterators where possible. This, almost always, hides references to the
nents and orig_nents entries, making the code robust, easier to follow
and copy/paste safe.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
drm/tegra: plane: Support horizontal reflection 2020-07-17T14:06:17+00:00 Dmitry Osipenko digetx@gmail.com 2020-06-17T23:40:39+00:00 cd740777d29d7053e0172c7e0105789428425941 Support horizontal reflection mode which will allow to support 180° rotation mode when combined with the vertical reflection. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
Support horizontal reflection mode which will allow to support 180°
rotation mode when combined with the vertical reflection.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
drm/tegra: plane: Rename bottom_up to reflect_y 2020-07-17T14:06:16+00:00 Dmitry Osipenko digetx@gmail.com 2020-06-17T23:40:38+00:00 e9e476f7f7eaaf12058290f83cccbcb076596b2f This makes the naming consistent with the DRM core. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> 
This makes the naming consistent with the DRM core.

Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>