This feature was recently added to virtio-gpu, lets make
it userspace queryable. It's an error to use
BLOB_FLAG_USE_CROSS_DEVICE when this feature is not present.
This makes blob resources available to guest userspace. They are needed
for GL4.5, Vulkan and zero-copy virtio-gpu.
For Mesa, blob resources have been tested with Piglit's ARB_buffer_storage
tests and apitraces. Apitraces of GL4.5 games show we're between 70%
to 80% of host performance on Iris, based on a apitrace of a 2013 GL4.5
game:
11.204 FPS (guest)
15.947 FPS (host)
This is still better than the status quo, when said game was unplayable
with Virgl due to an inefficient GL4.3 fallback. But there's still room
for improvement if we want to match HW-assisted virtualization.
For Vulkan, blob resources have been tested with dEQP.vk.memory* and
running Vulkan applications in production with the "Cuttlefish" virtual
Android device. This has been done with Lingfeng Yang's "gfxstream"
Vulkan implementation, which virtualizes Vulkan across many Google
products.
This patch adds a new virtgpu feature that allows directly
mapping host allocated resources.
This is based on virtio shared memory regions, which allows
querying for memory regions using PCI transport. Each shared
memory region has an associated "shmid", the meaning of which
is device specific.
For virtio-gpu, we can define the shared memory region with id
VIRTIO_GPU_SHM_ID_HOST_VISIBLE to be the "host visible memory
region".
The presence of the host visible memory region means the following
hypercalls are supported:
1) VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB
This hypercall tells the host to inject the host resource's
mapping in an offset into virtio-gpu's PCI address space.
This is typically done via KVM_SET_USER_MEMORY_REGION on Linux
hosts.
On success, VIRTIO_GPU_RESP_OK_MAP_INFO is returned, which
specifies the host buffer's caching type and possibly in the
future performance hints about the buffer..
2) VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB
This hypercall tells the host to remove the host resource's
mapping from the guest VM.
A blob resource is a container for:
- VIRTIO_GPU_BLOB_MEM_GUEST: a guest memory allocation
(referred to as a "guest-only blob resource")
- VIRTIO_GPU_BLOB_MEM_HOST3D: a host3d memory allocation
(referred to as a "host-only blob resource")
- VIRTIO_GPU_BLOB_MEM_HOST3D_GUEST: a guest + host3d memory allocation
(referred to as a "default blob resource").
The memory properties of the blob resource must be described by
`blob_mem`.
For default and guest only blob resources set, `nents` guest system
pages are assigned to the resource. For default blob resources,
these guest pages are used for transfer operations. Attach/detach is
also possible to allow swap-in/swap-out, but isn't required since it
may not be applicable to future blob mem types
(shared guest/guest vram).
Host allocations depend on whether the 3D is supported. If 3D is not
supported, the only valid field for `blob_mem` is
VIRTIO_GPU_BLOB_MEM_GUEST.
If 3D is supported, the virtio-gpu resource is created from the
context local object identified by the `blob_id`. The actual host
allocation done by the CMD_SUBMIT_3D.
Userspace must specify if the blob resource is intended to be used
for userspace mapping, sharing between virtio-gpu contexts and/or
sharing between virtio devices. This is done via `blob_flags`.
For 3D hosts, both VIRTIO_GPU_CMD_TRANSFER_TO_HOST_3D and
VIRTIO_GPU_CMD_TRANSFER_FROM_HOST_3D may be used to update
the host resource. There is no restriction on the image/buffer
view the guest/host userspace has on the blob resource.
VIRTIO_GPU_CMD_SET_SCANOUT_BLOB / VIRTIO_GPU_CMD_RESOURCE_FLUSH may
be used with blob resources as well. The modifier is intentionally
left out of SCANOUT_BLOB, and auxilary blobs are also left out
as a simplification.
The use case for blob resources is zero-copy, needed for coherent
memory in virglrenderer. Host only blob resources are not mappable
without the feature described in the next patch, but are shareable.
Future work:
- Emulated coherent `blob_mem` type for QEMU/vhost-user
- A `blob_mem` type for guest-only resources imported in
cache-coherent FOSS GPU/display drivers.
- Display integration involving the blob model using seamless
Wayland windows.
Paul Cercueil [Sat, 26 Sep 2020 17:05:01 +0000 (19:05 +0200)]
drm/ingenic: Add support for 24-bit modes
Starting from the JZ4725B SoC, the primary and overlay planes support
24-bit pixel modes (8 bits per color component, without dummy byte).
Add support for these in the ingenic-drm driver.
Paul Cercueil [Sat, 26 Sep 2020 17:05:00 +0000 (19:05 +0200)]
drm/ingenic: Add support for 30-bit modes
Starting from the JZ4760 SoC, the primary and overlay planes support
30-bit pixel modes (10 bits per color component). Add support for these
in the ingenic-drm driver.
Paul Cercueil [Sat, 26 Sep 2020 17:04:58 +0000 (19:04 +0200)]
drm/ingenic: Support handling different pixel formats in F0/F1 planes
Until now the ingenic-drm driver supported the same pixel formats on the
F0 and F1 planes, and across all SoCs. However, the F0 plane does support
paletted 8bpp, while the F1 plane doesn't.
Furthermore, the three SoCs currently supported all have different pixel
formats available; 24bpp was added in JZ4725B, 30bpp was added in
JZ4770.
Prepare the inclusion of paletted 8bpp, 24bpp and 30bpp support by
having separate pixel format lists for F0 and F1 planes.
Paul Cercueil [Sat, 26 Sep 2020 17:04:57 +0000 (19:04 +0200)]
drm/ingenic: Alloc F0 and F1 DMA descriptors at once
Instead of calling dmam_alloc_coherent() once for each 4-bit DMA
hardware descriptor, we can have them both in a physical memory page, as
long as they are aligned to 16 bytes. This reduces memory consumption,
and will make it easier to add more DMA descriptors in the future.
Note that the old code would not create the F0 descriptor on SoCs that
don't support multiple planes. We don't care, because:
- we don't use more memory by allocating two descriptors instead of a
single one;
- the only SoC that does not support multiple planes (JZ4740) still has
two independent DMA channels, for an unknown reason.
Paul Cercueil [Sat, 26 Sep 2020 17:04:56 +0000 (19:04 +0200)]
drm/ingenic: Add support for reserved memory
Add support for static memory reserved from Device Tree. Since we're
using GEM buffers backed by CMA, it is interesting to have an option to
specify the CMA area where the GEM buffers will be allocated.
v2: Don't abort probe if reserved memory cannot be obtained. The driver
will still work fine provided the kernel configuration is sane.
Paul Cercueil [Sat, 26 Sep 2020 17:04:55 +0000 (19:04 +0200)]
drm/ingenic: Reset pixclock rate when parent clock rate changes
Old Ingenic SoCs can overclock very well, up to +50% of their nominal
clock rate, whithout requiring overvolting or anything like that, just
by changing the rate of the main PLL. Unfortunately, all clocks on the
system are derived from that PLL, and when the PLL rate is updated, so
is our pixel clock.
To counter that issue, we make sure that the panel is in VBLANK before
the rate change happens, and we will then re-set the pixel clock rate
afterwards, once the PLL has been changed, to be as close as possible to
the pixel rate requested by the encoder.
This is one of the last users of compat_alloc_user_space()
and copy_in_user(). The actual handler is implemented in the
same file and could be shared, but as I couldn't test this
properly I leave the native case alone and just make a straight
copy of it for the compat case, with a minimum set of
modifications.
No driver implements FBIOSCURSOR, so this function has no purpose
and can be removed. Apparently it was added in linux-2.1.44 to handle
compatibility for drivers/sbus/char/sunfb.c but lost its purpose when
that driver got rewritten in linux-2.5.63.
Thomas Zimmermann [Tue, 22 Sep 2020 14:57:00 +0000 (16:57 +0200)]
drm/vram-helper: Don't put new BOs into VRAM
Most drivers that use VRAM helpers have only a few MiB of framebuffer
memory available. To reduce fragmentation, new BOs are now put into
system memory by default. Only pin operations are allowed to move BOs
into VRAM.
Thomas Zimmermann [Tue, 22 Sep 2020 14:56:59 +0000 (16:56 +0200)]
drm/vram-helper: Set object function iff they are not provided by driver
Don't override the GEM object functions unconditionally. If the driver
sets the GEM functions, VRAM helpers will not set them. The idea has been
taken from SHMEM helpers.
v2:
* updated the commit message (Sam)
* document the new feature for drm_gem_vram_create()
Thomas Zimmermann [Tue, 22 Sep 2020 14:56:58 +0000 (16:56 +0200)]
drm/vram-helper: Integrate drm_gem_vram_init() into drm_gem_vram_create()
The drm_gem_vram_create() function is the only caller of the internal
helper drm_gem_vram_init(). Streamline the code by putting all code into
the create function.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:59 +0000 (12:21 +0200)]
drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.
What is also gone is gem_vm_ops in struct drm_driver. All drivers now
use struct drm_gem_object_funcs.vm_ops instead.
While at it, the patch also improves error handling around calls
to .free and .get_sg_table callbacks.
v3:
* restore default call to drm_gem_prime_export() in
drm_gem_prime_handle_to_fd()
* return -ENOSYS if get_sg_table is not set
* drop all checks for obj->funcs
* clean up TODO list and documentation
v2:
* update related TODO item (Sam)
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:58 +0000 (12:21 +0200)]
drm/xlnx: Initialize DRM driver instance with CMA helper macro
The xlnx driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .dumb_destroy and .gem_prime_import, were initialized
to their default implementations, so they are just kept empty now.
v2:
* initialize with DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE (Laurent)
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:57 +0000 (12:21 +0200)]
drm/xen: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in xen. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* convert xen_drm_drv_free_object_unlocked() to static
callback (Oleksandr)
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:56 +0000 (12:21 +0200)]
drm/vkms: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vkms.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:55 +0000 (12:21 +0200)]
drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcs
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces virtgpu's per-driver PRIME export
function with a per-object function.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:54 +0000 (12:21 +0200)]
drm/vgem: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vgem. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:53 +0000 (12:21 +0200)]
drm/vc4: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in vc4. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:52 +0000 (12:21 +0200)]
drm/tegra: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in tegra.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:51 +0000 (12:21 +0200)]
drm/rockchip: Convert to drm_gem_object_funcs
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in rockchip. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:50 +0000 (12:21 +0200)]
drm/radeon: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.
v2:
* move object-function instance to radeon_gem.c (Christian)
* set callbacks in radeon_gem_object_create() (Christian)
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:49 +0000 (12:21 +0200)]
drm/pl111: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in pl111. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v2:
* use drm_gem_cma_create_object_default_funcs() (Eric)
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:48 +0000 (12:21 +0200)]
drm/omapdrm: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in omapdrm.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:47 +0000 (12:21 +0200)]
drm/nouveau: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in nouveau.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:46 +0000 (12:21 +0200)]
drm/msm: Introduce GEM object funcs
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in msm. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:45 +0000 (12:21 +0200)]
drm/mediatek: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in mediatek. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:44 +0000 (12:21 +0200)]
drm/imx/dcss: Initialize DRM driver instance with CMA helper macro
The i.MX DCSS driver uses CMA helpers with default callback functions.
Initialize the driver structure with the rsp CMA helper macro. The
driver is being converted to use GEM object functions as part of
this change.
Two callbacks, .gem_prime_export and .gem_prime_import, were initialized
to their default implementations, so they are just kept empty now.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:43 +0000 (12:21 +0200)]
drm/i915: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in i915.
v2:
* move object-function instance to i915_gem_object.c (Jani)
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:42 +0000 (12:21 +0200)]
drm/gma500: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in gma500.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:41 +0000 (12:21 +0200)]
drm/exynos: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in exynos. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:40 +0000 (12:21 +0200)]
drm/etnaviv: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in etnaviv. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:39 +0000 (12:21 +0200)]
drm/armada: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in armada.
Thomas Zimmermann [Wed, 23 Sep 2020 10:21:38 +0000 (12:21 +0200)]
drm/amdgpu: Introduce GEM object functions
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
v3:
* remove amdgpu_object.c from patch (Christian)
v2:
* move object-function instance to amdgpu_gem.c (Christian)
* set callbacks in amdgpu_gem_object_create() (Christian)
Antonio Borneo [Tue, 22 Sep 2020 07:42:42 +0000 (09:42 +0200)]
drm/panel: otm8009a: remove hack to force commands in HS
The panel is able to receive commands in LP. The current hack to
force backlight commands in HS was due to workaround an incorrect
settings on DSI controller that prevents sending LP commands while
video out was active.
Christian König [Mon, 21 Sep 2020 12:43:59 +0000 (14:43 +0200)]
drm/vram-helper: switch over to the new pin interface
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/391603/?series=81973&rev=1
Thomas Zimmermann [Tue, 22 Sep 2020 14:46:55 +0000 (16:46 +0200)]
drm/ast: Reload gamma LUT after changing primary plane's color format
The gamma LUT has to be reloaded after changing the primary plane's
color format. This used to be done implicitly by the CRTC atomic_enable()
helper after updating the primary plane. With the recent reordering of
the steps, the primary plane's setup was moved last and invalidated
the gamma LUT. Fix this by setting the LUT from within atomic_flush().
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 2f0ddd89fe32 ("drm/ast: Enable CRTC before planes") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20200922144655.23624-1-tzimmermann@suse.de
Daniel Vetter [Thu, 17 Sep 2020 16:47:22 +0000 (18:47 +0200)]
drm/doc: Document that modifiers are always required for fb
Even for legacy userspace, since otherwise GETFB2 is broken and if you
switch between modifier-less and modifier-aware compositors, smooth
transitions break.
Also it's just best practice to make sure modifiers are invariant for
a given drm_fb, and that a modifier-aware kms drivers only has one
place to store them, ignoring any old implicit bo flags or whatever
else might float around.
Motivated by some irc discussion with Bas about amdgpu modifier
support.
Acked-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Acked-by: Simon Ser <contact@emersion.fr> Acked-by: Daniel Stone <daniels@collabora.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Fixes: 455e00f1412f ("drm: Add getfb2 ioctl") Cc: Daniel Stone <daniels@collabora.com> Cc: Juston Li <juston.li@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Marek Olšák <maraeo@gmail.com> Cc: "Wentland, Harry" <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200917164721.2038541-1-daniel.vetter@ffwll.ch
Christian König [Fri, 18 Sep 2020 14:34:49 +0000 (16:34 +0200)]
drm/ttm: stop dangerous caching attribute change
When we swapout/in a BO we try to change the caching
attributes of the pages before/after doing the copy.
On x86 this is done by calling set_pages_uc(),
set_memory_wc() or set_pages_wb() for not highmem pages
to update the linear mapping of the page.
On all other platforms we do exactly nothing.
Now on x86 this is unnecessary because copy_highpage() will
either create a temporary mapping of the page which is wb
anyway and destroyed immediately again or use the linear
mapping with the correct caching attributes.
So stop this nonsense and just keep the caching as it is and
return an error when a driver tries to change the caching of
an already populated TT object.
This is much more defensive since changing caching
attributes is platform and driver specific and usually
doesn't work after the page was initially allocated.
Koba Ko [Tue, 22 Sep 2020 06:53:13 +0000 (14:53 +0800)]
drm/dp_mst: Retrieve extended DPCD caps for topology manager
As per DP-1.3, First check DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 1,read the DP_DP13_DPCD_REV to
get the faster capability.
If DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT is 0,read DP_DPCD_REV.
Thomas Zimmermann [Mon, 21 Sep 2020 14:25:36 +0000 (16:25 +0200)]
drm/vram-helper: Fix use of top-down placement
Commit 7053e0eab473 ("drm/vram-helper: stop using TTM placement flags")
cleared the BO placement flags if top-down placement had been selected.
Hence, BOs that were supposed to go into VRAM are now placed in a default
location in system memory.
Trying to scanout the incorrectly pinned BO results in displayed garbage
and an error message.
Fix the bug by keeping the placement flags. The top-down placement flag
is stored in a separate variable.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Fixes: 7053e0eab473 ("drm/vram-helper: stop using TTM placement flags") Cc: Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> 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/20200921142536.4392-1-tzimmermann@suse.de
Wang ShaoBo [Fri, 11 Sep 2020 01:44:14 +0000 (09:44 +0800)]
drm/imx/dcss: fix unused but set variable warnings
Fix unused but set variable warning building with `make W=1`:
drivers/gpu/drm/imx/dcss/dcss-plane.c:270:6: warning:
variable ‘pixel_format’ set but not used [-Wunused-but-set-variable]
u32 pixel_format;
^~~~~~~~~~~~
Fixes: 9021c317b770 ("drm/imx: Add initial support for DCSS on iMX8MQ") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200911014414.4663-1-bobo.shaobowang@huawei.com
Maxime Ripard [Thu, 17 Sep 2020 12:16:23 +0000 (14:16 +0200)]
drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing
The vc4 display engine has a first controller called the HVS that will
perform the composition of the planes. That HVS has 3 FIFOs and can
therefore compose planes for up to three outputs. The timings part is
generated through a component called the Pixel Valve, and the BCM2711 has 6
of them.
Thus, the HVS has some bits to control which FIFO gets output to which
Pixel Valve. The current code supports that muxing by looking at all the
CRTCs in a new DRM atomic state in atomic_check, and given the set of
constraints that we have, assigns FIFOs to CRTCs or reject the mode
entirely. The actual muxing will occur during atomic_commit.
However, that doesn't work if only a fraction of the CRTCs' state is
updated in that state, since it will ignore the CRTCs that are kept running
unmodified, and will thus unassign its associated FIFO, and later disable
it.
In order to make the code work as expected, let's pull the CRTC state of
all the enabled CRTC in our atomic_check so that we can operate on all the
running CRTCs, no matter whether they are affected by the new state or not.
Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Tested-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200917121623.42023-1-maxime@cerno.tech
Tian Tao [Fri, 18 Sep 2020 09:52:58 +0000 (17:52 +0800)]
drm/ttm: update kernel-doc line comments
Update kernel-doc line comments to fix warnings reported by make W=1.
drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or
member 'glob' not described in 'ttm_shrink'
drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or
member 'from_wq' not described in 'ttm_shrink'
drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or
member 'extra' not described in 'ttm_shrink'
drivers/gpu/drm/ttm/ttm_memory.c:271: warning: Function parameter or
member 'ctx' not described in 'ttm_shrink'
Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/391317/ Signed-off-by: Christian König <christian.koenig@amd.com>
Neil Armstrong [Wed, 16 Sep 2020 15:01:47 +0000 (17:01 +0200)]
drm/panfrost: add Amlogic GPU integration quirks
This adds the required GPU quirks, including the quirk in the PWR
registers at the GPU reset time and the IOMMU quirk for shareability
issues observed on G52 in Amlogic G12B SoCs.
Neil Armstrong [Wed, 16 Sep 2020 15:01:46 +0000 (17:01 +0200)]
drm/panfrost: add amlogic reset quirk callback
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM,
G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset
time.
Since the Amlogic's integration of the GPU cores with the SoC is not
publicly documented we do not know what does these values, but they
permit having a fully functional GPU running with Panfrost.
projects / users / jedix / linux-maple.git / log