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>
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>
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 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>
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>
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 partially reverts the DMA API support that was recently merged
because it was causing performance regressions on older Tegra devices.
Unfortunately, the cache maintenance performed by dma_map_sg() and
dma_unmap_sg() causes performance to drop by a factor of 10.
The right solution for this would be to cache mappings for buffers per
consumer device, but that's a bit involved. Instead, we simply revert to
the old behaviour of sharing IOVA mappings when we know that devices can
do so (i.e. they share the same IOMMU domain).
Cc: <stable@vger.kernel.org> # v5.5
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
All the display related blocks on Tegra require contiguous memory. Using
the DMA API, there is no knowing at import time which device will end up
using the buffer, so it's not known whether or not an IOMMU will be used
to map the buffer.
Move the check for non-contiguous buffers/mappings to the tegra_dc_pin()
function which is now the earliest point where it is known if a DMA BUF
can be used by the given device or not.
v2: add check for contiguous buffer/mapping in tegra_dc_pin()
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If a display controller is not attached to an explicit IOMMU domain,
which usually means that it's connected to an IOMMU domain controlled by
the DMA API, make sure to map the framebuffer to the display controller
address space. This allows us to transparently handle setups where the
display controller is attached to an IOMMU or setups where it isn't. It
also allows the driver to work with a DMA API that is backed by an
IOMMU.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Drop use of the deprecated drmP.h header file.
For all touched files divide include files into blocks,
and sort them within the blocks.
Fix fallout.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: linux-tegra@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190804094132.29463-3-sam@ravnborg.org
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently only the DRM_MODE_REFLECT_Y rotation is supported. The driver
already supports reflection on the Y axis via a custom flag which is not
very useful because it requires custom userspace. Add the standard
rotation property that supports 0 degree rotation and Y axis reflection
for primary and overlay planes to provide a better interface than the
custom flag.
v2: keep custom flag for ABI compatibility (Dmitry)
Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Older Tegra's do not support plane's Z position handling in hardware,
but the hardware provides knobs to implement it in software.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJauCZfAAoJEHm+PkMAQRiGWGUH/2rhdQDkoJpYWnjaQkolECG8
MxpGE7nmIIHxQcbSDdHTGJ8IhVm6Z5wZ7ym/PwCDTT043Y1y341sJrIwL2/nTG6d
HVidk8hFvgN6QzlzVAHT3ZZMII/V9Zt+VV5SUYLGnPAVuJNHo/6uzWlTU5g+NTFo
IquFDdQUaGBlkKqby+NoAFnkV1UAIkW0g22cfvPnlO5GMer0gusGyVNvVp7TNj3C
sqj4Hvt3RMDLMNe9RZ2pFTiOD096n8FWpYftZneUTxFImhRV3Jg5MaaYZm9SI3HW
tXrv/LChT/F1mi5Pkx6tkT5Hr8WvcrwDMJ4It1kom10RqWAgjxIR3CMm448ileY=
=YKUG
-----END PGP SIGNATURE-----
Backmerge tag 'v4.16-rc7' into drm-next
Linux 4.16-rc7
This was requested by Daniel, and things were getting
a bit hard to reconcile, most of the conflicts were
trivial though.
This fixes mmap() for fbdev devices by providing a custom implementation
based on the KMS variant. This is a fairly exotic case these days, hence
why it is not flagged for stable.
There is also support for dedicating one of the overlay planes to serve
as a hardware cursor on older Tegra that did support hardware cursors
but not RGBA formats for it.
Planes will now also export the IN_FORMATS property by supporting the
various block-linear tiling modifiers for RGBA pixel formats.
Other than that, there's a bit of cleanup of DMA API abuse, use of the
private object infrastructure for global state (rather than subclassing
atomic state objects) and an implementation of ->{begin,end}_cpu_access
callbacks for PRIME exported buffers, which allow users to perform cache
maintenance on these buffers.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlqviKkTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zod+zD/9p04Jmsbd30dttPqb1Dns1e4N/cXcP
hLgqYjc+Apov3ksrFS7bhlmIKxMcIXvw6s/ciwapO4tNMuWfKke6+LX7eGxyzMFn
aGm7Na0fcb+R6U7Cs8J45b9XB0NBGuz2Vv9rIne/I7BoVE1XCPfEBYgYGT6hR0cj
fPWKAldD1CVJXJX48mIsgUe8w8PHBijN0qEfrNTmQTA/zZ4PeZQpdoilLS8lsb74
fg9BWaTHYLchHFaLShsuSJwS/qHCMLCMv01dhCV5OlpaZWXki4iqhjuIuHeZnk3c
ygWcmjDkE4Aaihq5mcPD1tYe8D223TW3XbtHDsl1MKVLdHliSSp3xsWlbqB42BiK
QtXNhmEUbx4cnvNA6e/5wXTZImNHRJnkcAIMro7z5Vq3Xav+4bcPiLROd9nz28GS
WNuAoV26YedWtK9taJEAoO6Nas6K+f2jQKcph97Rrii+LwkZqNLeHzikTXcIAwDF
M55wIcLRt1b2a3ZPxWOE3sl0gTyMdJbITt5t2zyl3OXCnGINmSCn6Bfm8EZsFY+j
2J8v25T6VTQC5MWyR75abppMvdqk4ihIWSmIH4vdlpj202dD5q9T+CWaLCguxZPY
racx4bDUEJB9Gt5iJAQNVq8alDhioynygXwGbVuPY7BAiBKQWNyHBbgRWBAPGjXR
CnGh3KfFFEFWkA==
=gOLI
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.17-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.17-rc1
This fixes mmap() for fbdev devices by providing a custom implementation
based on the KMS variant. This is a fairly exotic case these days, hence
why it is not flagged for stable.
There is also support for dedicating one of the overlay planes to serve
as a hardware cursor on older Tegra that did support hardware cursors
but not RGBA formats for it.
Planes will now also export the IN_FORMATS property by supporting the
various block-linear tiling modifiers for RGBA pixel formats.
Other than that, there's a bit of cleanup of DMA API abuse, use of the
private object infrastructure for global state (rather than subclassing
atomic state objects) and an implementation of ->{begin,end}_cpu_access
callbacks for PRIME exported buffers, which allow users to perform cache
maintenance on these buffers.
* tag 'drm/tegra/for-4.17-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: prime: Implement ->{begin,end}_cpu_access()
drm/tegra: gem: Map pages via the DMA API
drm/tegra: hub: Use private object for global state
drm/tegra: fb: Properly support linear modifier
drm/tegra: plane: Support format modifiers
drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's
drm/tegra: plane: Make tegra_plane_get_overlap_index() static
drm/tegra: fb: Implement ->fb_mmap() callback
drm/tegra: gem: Make __tegra_gem_mmap() available more widely
drm/tegra: gem: Reshuffle declarations
Pass the list of valid format modifiers to planes upon initialization
and implement the ->format_mod_supported() callback so that userspace
can query for the valid combinations of formats and modifiers.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Keep old 'dependent' state of unaffected planes, this way new state takes
into account current state of unaffected planes.
Fixes: ebae8d0743 ("drm/tegra: dc: Implement legacy blending")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This function is not used outside of the file and can be static.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The opaque/alpha format conversion code is currently only looking at
XRGB formats because they have an equivalent ARGB format. The opaque
format for RGB565 is RGB565 itself, much like the YUV formats map to
themselves.
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Fixes: ebae8d0743 ("drm/tegra: dc: Implement legacy blending")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
v2: Rebase due to tegra_plane_state_add() relocating to plane.c
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123190502.28449-13-ville.syrjala@linux.intel.com
Commit ebae8d0743 ("drm/tegra: dc: Implement legacy blending") broke
support for YUV overlays by accident. The reason is that YUV formats are
considered opaque because they have no alpha component, but on the other
hand no corresponding format with an alpha component can be returned. In
the case of YUV formats, the opaque format is the same as the alpha
format, so add the special case to restore YUV overlay support.
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This implements alpha blending on legacy display controllers (Tegra20,
Tegra30 and Tegra114). While it's theoretically possible to support the
zpos property to enable userspace to specify the Z-order of each plane
individually, this is not currently supported and the same fixed Z-
order as previously defined is used.
Reverts commit 71835caa00 ("drm/tegra: fb: Force alpha formats") since
the opaque formats are now supported.
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Fixes: 7772fdaef9 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Thierry Reding <treding@nvidia.com>
Also, split up formats into per-SoC lists because not all generations
support all of them. Note that the list is now exhaustive for all RGB
formats, but not for YUV and indexed formats.
Signed-off-by: Thierry Reding <treding@nvidia.com>
These formats can easily be supported on all generations of Tegra.
Note that the XRGB and XBGR formats that we supported were in fact using
the ARGB and ABGR Tegra formats. This happened to work in cases where no
alpha was being considered. This change is also a fix for those formats.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Subsequent patches will add support for Tegra186 which has a different
architecture and needs different plane code but which can share a lot of
code with earlier Tegra support.
Signed-off-by: Thierry Reding <treding@nvidia.com>
