Age | Commit message (Collapse) | Author |
|
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-6-greenfoo@gluegarage.com
|
|
There are no more places where this (deprecated) function is being used
from, thus it can now be removed.
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-5-greenfoo@gluegarage.com
|
|
This patch unifies the naming of DRM functions for reference counting as
requested on Documentation/gpu/todo.rst
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-4-greenfoo@gluegarage.com
|
|
There are no more places where these (deprecated) functions are being
used from, thus they can now be removed.
Signed-off-by: Fernando Ramos <greenfoo@gluegarage.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115221634.22715-3-greenfoo@gluegarage.com
|
|
For real commits we WARN if ->hw_done hasn't been completed by the time
drm_atomic_helper_commit_cleanup_done() is called. Let's do the same for
the fake commit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122143412.11655-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
Consider the following scenario:
1. nonblocking enable crtc
2. wait for the event
3. nonblocking disable crtc
On i915 this can lead to a spurious -EBUSY from step 3 on
account of non-enabled planes getting the fake_commit in step 1
and we don't complete the fake_commit-> flip_done until
drm_atomic_helper_commit_hw_done() which can happen a long
time after the flip event was sent out.
This will become somewhat easy to hit on SKL+ once we start
to add all the planes for the crtc to every modeset commit
for the purposes of forcing a watermark register programming
[1].
To make the race a little less pronounced let's complete
fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
For the single crtc case this should make the race quite
theoretical, assuming drm_atomic_helper_wait_for_flip_done()
actually has to wait for the real commit flip_done. In case
the real commit flip_done gets completed singificantly before
drm_atomic_helper_wait_for_flip_done(), or we are dealing with
multiple crtcs whose vblanks don't line up nicely the race still
exists.
[1] https://patchwork.freedesktop.org/patch/262670/
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 080de2e5be2d ("drm/atomic: Check for busy planes/connectors before setting the commit")
Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122143412.11655-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
drivers/gpu/drm/drm_prime.c: In function 'drm_gem_prime_mmap':
>> drivers/gpu/drm/drm_prime.c:688:1: warning: the frame size of 1592 bytes is larger than 1024 bytes [-Wframe-larger-than=]
Fix by allocating on the heap.
Fixes: 7698799f9554 ("drm/prime: Add drm_gem_prime_mmap()")
Reported-by: kbuild test robot <lkp@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121180215.13881-1-noralf@tronnes.org
|
|
Render like lima will attach a fence to the framebuffer
dma_buf, display like sun4i should wait it finish before
show the framebuffer. Otherwise tearing will be observed.
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181122014417.23285-1-yuq825@gmail.com
|
|
Ever since
commit cb6458f97b53d7f73043206c18014b3ca63ac345
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Aug 8 15:41:34 2013 +0200
drm: remove procfs code, take 2
Having the code shared between procfs and debugfs in the separate
drm_info.c file stopped making sense. Merge them.
Noticed because Lyude asked some questions on irc about why we even
have drm_info_node and I remember this old story.
Cc: Lyude Paul <lyude@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121213510.31260-1-daniel.vetter@ffwll.ch
|
|
Suggested by Qiang Yu <yuq825@gmail.com> to fix tearing artefacts in the
Kodi GUI.
Suggested-by: Qiang Yu <yuq825@gmail.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: added Suggested-by tag]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1542621759-26413-1-git-send-email-koen@dominion.thruhere.net
|
|
linux guest driver implementation of the VIRTIO_GPU_F_EDID feature.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030063206.19528-3-kraxel@redhat.com
|
|
The feature allows the guest request an EDID blob (describing monitor
capabilities) for a given scanout (aka virtual monitor connector).
It brings a new command message, which has just a scanout field (beside
the standard virtio-gpu header) and a response message which carries the
EDID data.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030063206.19528-2-kraxel@redhat.com
|
|
QEMU keeps a vram reference to the last QXLCursorCmd it received.
This QXLCursorCmd command points to a QXLCursor instance (stored in vram
too). However, while the QXLCursorCmd memory is pinned, the QXLCursor
memory is not.
When booting a recent Fedora to its login screen while monitoring the
QXLCursorCmd QEMU holds, it's possible to see the QXLCursor memory
becoming invalid shortly after boot. Pinning that memory ensures that
that QXLCursor memory is not going to be moved by the guest kernel.
Moving the pin/unpin to qxl_release_list_add()/qxl_release_free_list()
would be a more generic fix. However, doing this quickly exhausts QXL
video memory, so more fixing would be needed before this is workable.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181120162004.22807-3-cfergeau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
The 'domain' argument to qxl_bo_pin is redundant with 'bo', and
'gpu_addr' is unused, so we can remove both.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181120162004.22807-2-cfergeau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
qxl_bo_unref() is already performing a NULL check.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181120162004.22807-1-cfergeau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/cirrus/cirrus_fbdev.c: In function 'cirrusfb_create':
drivers/gpu/drm/cirrus/cirrus_fbdev.c:172:20: warning:
variable 'bo' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit
f9aa76a85248 ("drm/kms: driver for virtual cirrus under qemu")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1542283836-152176-1-git-send-email-yuehaibing@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
v7: Added is_yuv field initialization according to latest
drm_fourcc format structure initialization changes.
v8: Edited commit message to be more clear about skl+, renamed
PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
doesn't support per-pixel alpha. Fixed minor code issues.
v9: Moved DRM format check to proper place in intel_framebuffer_init.
v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV8888
v11: Fixed rebase conflict, caused by added new formats to drm-tip
meanwhile.
Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
[vsyrjala: Removed stray tab and sorted the formats differently]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109093916.25858-2-stanislav.lisovskiy@intel.com
|
|
The CMA helper now has the functionality to ensure a virtual address on
imported buffer so use that.
While touching all tinydrm drivers, remove the unnecessary inclusion of
drm_fb_helper.h in some drivers.
Cc: David Lechner <david@lechnology.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-6-noralf@tronnes.org
|
|
This adds functionality to the CMA helper which ensures that the kernel
virtual address is set on the CMA GEM object also for imported buffers.
The drivers have been audited to ensure that none set ->vaddr on imported
buffers, making the conditional dma_buf_vunmap() call in
drm_gem_cma_free_object() safe.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-5-noralf@tronnes.org
|
|
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the the various buffer types. The driver
only has to make the decision about buffer type on GEM object creation
and all other callbacks can be handled by the chosen helper.
drm_driver->gem_prime_res_obj has not been added since there's a todo to
put a reservation_object into drm_gem_object.
v3: Add todo entry
v2: Drop drm_gem_object_funcs->prime_mmap in favour of
drm_gem_prime_mmap() (Daniel Vetter)
v1:
- drm_gem_object_funcs.map -> .prime_map let it only do PRIME mmap like
the function it superseeds (Daniel Vetter)
- Flip around the if ladders and make obj->funcs the first choice
highlighting the fact that this the new default way of doing it
(Daniel Vetter)
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-4-noralf@tronnes.org
|
|
Add a generic PRIME GEM mmap function.
v2: Fix link in docs (Daniel Vetter)
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-3-noralf@tronnes.org
|
|
The majority of drivers use drm_gem_prime_export() and
drm_gem_prime_import() for these callbacks so let's make them the
default.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-2-noralf@tronnes.org
|
|
Trivial fix to spelling mistake in DRM_DEV_ERROR error message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106154022.9209-1-colin.king@canonical.com
|
|
kbuild test robot reports:
>> ERROR: "i2c_mux_add_adapter" [drivers/gpu/drm/bridge/sii902x.ko] undefined!
>> ERROR: "i2c_mux_alloc" [drivers/gpu/drm/bridge/sii902x.ko] undefined!
>> ERROR: "i2c_mux_del_adapters" [drivers/gpu/drm/bridge/sii902x.ko] undefined!
Quite obviously the driver depends on I2C_MUX, but adding a "depends on"
introduces a recursive dependency, therefore this patch selects I2C_MUX
instead.
Fixes: 21d808405fe4 ("drm/bridge/sii902x: Fix EDID readback")
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Link: https://lists.01.org/pipermail/kbuild-all/2018-November/054924.html
Acked-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1542633978-22064-1-git-send-email-fabrizio.castro@bp.renesas.com
|
|
Some of the functions (like cdn_dp_dpcd_read, cdn_dp_get_edid_block)
allow to read 64KiB, but the cdn_dp_mailbox_read_receive, that is
used by them, can read only up to 255 bytes at once. Normally, it's
not a big issue as DPCD or EDID reads won't (hopefully) exceed that
value.
The real issue here is the revocation list read during the HDCP
authentication process. (problematic use case:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/gpu/drm/rockchip/cdn-dp-reg.c#1152)
The list can reach 127*5+4 bytes (num devs * 5 bytes per ID/Bksv +
4 bytes of an additional info).
In other words - CTSes with HDCP Repeater won't pass without this
fix. Oh, and the driver will most likely stop working (best case
scenario).
Signed-off-by: Damian Kos <dkos@cadence.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1541518625-25984-1-git-send-email-dkos@cadence.com
|
|
While adding SiI9022A support to the iwg23s board, it came
up that when the HDMI transmitter is in pass through mode the
device is not compliant with the I2C specification anymore,
as it requires a far bigger tbuf, due to a delay the HDMI
transmitter is adding when relaying the STOP condition on the
monitor i2c side of things.
When not providing an appropriate delay after the STOP condition
the i2c bus would get stuck. Also, any other traffic on the bus
while talking to the monitor may cause the transaction to fail
or even cause issues with the i2c bus as well.
I2c-gates seemed to reach consent as a possible way to address
these issues, and as such this patch is implementing a solution
based on that. Since others are clearly relying on the current
implementation of the driver, this patch won't require any DT
changes.
Since we don't want any interference during the DDC Bus
Request/Grant procedure and while talking to the monitor, we
have to use the adapter locking primitives rather than the
i2c-mux locking primitives.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Yannick Fertré <yannick.fertre@st.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541505156-8097-1-git-send-email-fabrizio.castro@bp.renesas.com
|
|
The TPO TPG110 bindings were using the DPI bindings (popular
in the fbdev subsystem) but this misses the finer points
learned in the DRM subsystem.
We need to augment the bindings for proper DRM integration:
the timings are expressed by the hardware, not put into the
device tree. I.e. this hardware is self-describing and can
report the resolutions and timings needed. It should not
be described in the device tree.
Further the device was incorrectly modeled with GPIO lines
instead of an SPI child, even though the device was using
SPI.
No known deployments of the device using device tree
exist, so it should be fine to augment the bindings.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101213256.12097-1-linus.walleij@linaro.org
|
|
I just got a new GDP Win2 device with an updated firmware, which still
requires this quirk to get the rotation right, so add the new firmware
date to the quirk matching table.
This should go to drm-misc-next.
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181018193136.4910-1-krisman@collabora.co.uk
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/qxl/qxl_release.c: In function 'qxl_release_fence_buffer_objects':
drivers/gpu/drm/qxl/qxl_release.c:431:17: warning:
variable 'qbo' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/qxl/qxl_release.c:430:24: warning:
variable 'driver' set but not used [-Wunused-but-set-variable]
'qbo' not used since commit f2c24b83ae90 ("drm/ttm: flip the switch, and convert
to dma_fence")
And 'driver' never used since introduction in
8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1542029556-88107-1-git-send-email-yuehaibing@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/qxl/qxl_object.c: In function 'qxl_bo_kunmap_atomic_page':
drivers/gpu/drm/qxl/qxl_object.c:189:21: warning:
variable 'map' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1541821486-40631-1-git-send-email-yuehaibing@huawei.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
The allocation for vfpriv is being leaked on an error return path,
fix this by kfree'ing it before returning.
Detected by CoverityScan, CID#1475380 ("Resource Leak")
Fixes: 6a37c49a94a9 ("drm/virtio: Handle context ID allocation errors")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181107203122.6861-1-colin.king@canonical.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
To reflect the (backward compatible) changes in the uabi we are bumping
the driver's version.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-5-robert.foss@collabora.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd and wait on it before submitting the draw call.
On the out-fence side we get fence returned by the submitted draw call
and attach it to a sync_file and send the sync_file fd to userspace. On
error -1 is returned to userspace.
VIRTGPU_EXECBUF_FENCE_FD_IN & VIRTGPU_EXECBUF_FENCE_FD_OUT
are supported at the simultaneously and can be flagged
for simultaneously.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-4-robert.foss@collabora.com
Suggested-by: Rob Herring <robh@kernel.org>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Add a new field called fence_fd that will be used by userspace to send
in-fences to the kernel and receive out-fences created by the kernel.
This uapi enables virtio to take advantage of explicit synchronization of
dma-bufs.
There are two new flags:
* VIRTGPU_EXECBUF_FENCE_FD_IN to be used when passing an in-fence fd.
* VIRTGPU_EXECBUF_FENCE_FD_OUT to be used when requesting an out-fence fd
The execbuffer IOCTL is now read-write to allow the userspace to read the
out-fence.
On error -1 should be returned in the fence_fd field.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-3-robert.foss@collabora.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
Refactor fence creation, add fences to relevant GPU
operations and add cursor helper functions.
This removes the potential for allocation failures from the
cmd_submit and atomic_commit paths.
Now a fence will be allocated first and only after that
will we proceed with the rest of the execution.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Robert Foss <robert.foss@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181112165157.32765-2-robert.foss@collabora.com
Suggested-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
0-based IDAs are more efficient than any other base. Convert the
1-based IDAs to be 0-based.
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-2-willy@infradead.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
ida_alloc() can return -ENOMEM in the highly unlikely case we run out
of memory. The current code creates an object with an invalid ID.
Signed-off-by: Matthew Wilcox <willy@infradead.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20181030165352.13065-1-willy@infradead.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
This patch adds support for the Primary Plane scaling.
On the Amlogic GX SoCs, the primary plane is used as On-Screen-Display
layer on top of video, and it's needed to keep the OSD layer to a lower
size as the physical display size to :
- lower the memory bandwidth
- lower the OSD rendering
- lower the memory usage
This use-case is used when setting the display mode to 3840x2160 and the
OSD layer is rendered using the GPU. In this case, the GXBB & GXL cannot
work on more than 2000x2000 buffer, thus needing the OSD layer to be kept
at 1920x1080 and upscaled to 3840x2160 in hardware.
The primary plane atomic check still allow 1:1 scaling, allowing native
3840x2160 if needed by user-space applications.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[narmstrong: fixed apply from malformed patch]
Link: https://patchwork.freedesktop.org/patch/msgid/1541497202-20570-4-git-send-email-narmstrong@baylibre.com
|
|
In preparation to support the Primary Plane scaling, move the basic
OSD Interlace-Only scaler setup code into the primary plane atomic
update callback and handle the vsync scaler update like the overlay
plane scaling registers update.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1541497202-20570-3-git-send-email-narmstrong@baylibre.com
|
|
The Amlogic Meson GX SoCs support an Overlay plane behind the primary
plane for video rendering.
This Overlay plane support various YUV layouts :
- YUYV
- NV12 / NV21
- YUV444 / 422 / 420 / 411 / 410
The scaler supports a wide range of scaling ratios, but for simplicity,
plane atomic check limits the scaling from x5 to /5 in vertical and
horizontal scaling.
The z-order is fixed and always behind the primary plane and cannot be changed.
The scaling parameter algorithm was taken from the Amlogic vendor kernel
code and rewritten to match the atomic universal plane requirements.
The video rendering using this overlay plane support has been tested using
the new Kodi DRM-KMS Prime rendering path along the in-review V4L2 Mem2Mem
Hardware Video Decoder up to 3840x2160 NV12 frames on various display modes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Maxime Jourdan <mjourdan@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541497202-20570-2-git-send-email-narmstrong@baylibre.com
|
|
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/sti/sti_crtc.c: In function 'sti_crtc_vblank_cb':
drivers/gpu/drm/sti/sti_crtc.c:255:22: warning:
variable 'priv' set but not used [-Wunused-but-set-variable]
It never used since introduction in
commit 9e1f05b28009 ("drm/sti: rename files and functions")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/1541818660-37168-1-git-send-email-yuehaibing@huawei.com
|
|
This is the first step into converting the meson/drm driver to use
the canvas module.
If a canvas provider node is detected in DT, use it. Otherwise,
fall back to what is currently being done.
Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
[narmstrong: added back priv in meson_drv_unbind()]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105104508.23090-3-mjourdan@baylibre.com
|
|
Allows using the new canvas provider module if present.
Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181105104508.23090-2-mjourdan@baylibre.com
|
|
drm-next is forwarded to v4.20-rc1, and we need this to make
a patch series apply.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
|
We need to include the revert of commit 783195ec1cad ("drm/syncobj:
disable the timeline UAPI for now v2") along with undoing the change to
drm/i915.
Fixes: 131280a162e7 ("drm: Revert syncobj timeline changes.")
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Sean Paul <sean@poorly.run>
Cc: David Airlie <airlied@linux.ie>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112152130.12275-1-chris@chris-wilson.co.uk
|
|
Daniel suggested I submit this, since we're still seeing regressions
from it. This is a revert to before 48197bc564c7 ("drm: add syncobj
timeline support v9") and its followon fixes.
Fixes this on first V3D testcase execution:
[ 48.767088] ============================================
[ 48.772410] WARNING: possible recursive locking detected
[ 48.777739] 4.19.0-rc6+ #489 Not tainted
[ 48.781668] --------------------------------------------
[ 48.786993] shader_runner/3284 is trying to acquire lock:
[ 48.792408] ce309d7f (&(&array->lock)->rlock){....}, at: dma_fence_add_callback+0x30/0x23c
[ 48.800714]
[ 48.800714] but task is already holding lock:
[ 48.806559] c5952bd3 (&(&array->lock)->rlock){....}, at: dma_fence_add_callback+0x30/0x23c
[ 48.814862]
[ 48.814862] other info that might help us debug this:
[ 48.821410] Possible unsafe locking scenario:
[ 48.821410]
[ 48.827338] CPU0
[ 48.829788] ----
[ 48.832239] lock(&(&array->lock)->rlock);
[ 48.836434] lock(&(&array->lock)->rlock);
[ 48.840640]
[ 48.840640] *** DEADLOCK ***
[ 48.840640]
[ 48.846582] May be due to missing lock nesting notation
[ 130.763560] 1 lock held by cts-runner/3270:
[ 130.767745] #0: 7834b793 (&(&array->lock)->rlock){-...}, at: dma_fence_add_callback+0x30/0x23c
[ 130.776461]
stack backtrace:
[ 130.780825] CPU: 1 PID: 3270 Comm: cts-runner Not tainted 4.19.0-rc6+ #486
[ 130.787706] Hardware name: Broadcom STB (Flattened Device Tree)
[ 130.793645] [<c021269c>] (unwind_backtrace) from [<c020db1c>] (show_stack+0x10/0x14)
[ 130.801404] [<c020db1c>] (show_stack) from [<c0c2c4b0>] (dump_stack+0xa8/0xd4)
[ 130.808642] [<c0c2c4b0>] (dump_stack) from [<c0281a84>] (__lock_acquire+0x848/0x1a68)
[ 130.816483] [<c0281a84>] (__lock_acquire) from [<c02835d8>] (lock_acquire+0xd8/0x22c)
[ 130.824326] [<c02835d8>] (lock_acquire) from [<c0c49948>] (_raw_spin_lock_irqsave+0x54/0x68)
[ 130.832777] [<c0c49948>] (_raw_spin_lock_irqsave) from [<c086bf54>] (dma_fence_add_callback+0x30/0x23c)
[ 130.842183] [<c086bf54>] (dma_fence_add_callback) from [<c086d4c8>] (dma_fence_array_enable_signaling+0x58/0xec)
[ 130.852371] [<c086d4c8>] (dma_fence_array_enable_signaling) from [<c086c00c>] (dma_fence_add_callback+0xe8/0x23c)
[ 130.862647] [<c086c00c>] (dma_fence_add_callback) from [<c06d8774>] (drm_syncobj_wait_ioctl+0x518/0x614)
[ 130.872143] [<c06d8774>] (drm_syncobj_wait_ioctl) from [<c06b8458>] (drm_ioctl_kernel+0xb0/0xf0)
[ 130.880940] [<c06b8458>] (drm_ioctl_kernel) from [<c06b8818>] (drm_ioctl+0x1d8/0x390)
[ 130.888782] [<c06b8818>] (drm_ioctl) from [<c03a4510>] (do_vfs_ioctl+0xb0/0x8ac)
[ 130.896187] [<c03a4510>] (do_vfs_ioctl) from [<c03a4d40>] (ksys_ioctl+0x34/0x60)
[ 130.903593] [<c03a4d40>] (ksys_ioctl) from [<c0201000>] (ret_fast_syscall+0x0/0x28)
Cc: Chunming Zhou <david1.zhou@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/261044/
|
|
The HVS spec recommends using PPF when the downscaling ratio is
between 2/3 and 1. Let's modify vc4_get_scaling_mode() to follow this
recommendation.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-2-boris.brezillon@bootlin.com
|
|
For the YUV conversion to work properly, ->x_scaling[1] should never
be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
into VC4_SCALING_PPF when that happens.
The old ->x_scaling[0] adjustment is dropped as I couldn't find any
mention to this constraint in the spec and it's proven to be
unnecessary (I tested various multi-planar YUV formats with scaling
disabled, and all of them worked fine without this adjustment).
Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109102633.32603-1-boris.brezillon@bootlin.com
|
|
Some panels need an active-low data enable (DE) signal for the RGB
interface. This requires flipping a bit in the TCON0 polarity register
when setting up the mode for the RGB interface.
Match the associated bus flag and use it to set the polarity inversion
bit for the DE signal when required.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107181843.27628-4-contact@paulk.fr
|
|
Features such as dithering and pixel data edge configuration currently
rely on the panel registered with the TCON driver. However, bridges are
also supported in addition to panels for RGB setup.
Instead of retrieving the connector from the panel, get it from the
encoder with the dedicated helper.
Even in the case of bridges, the connector is registered with the
encoder from our driver and is accessible when iterating connectors.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181107181843.27628-3-contact@paulk.fr
|