- 21 Nov, 2018 2 commits
-
-
Christophe Fergeau authored
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.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
YueHaibing authored
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 f9aa76a8 ("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.comSigned-off-by:
-
- 20 Nov, 2018 8 commits
-
-
Stanislav Lisovskiy authored
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
-
Noralf Trønnes authored
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
-
Noralf Trønnes authored
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 authored
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Noralf Trønnes authored
Add a generic PRIME GEM mmap function. v2: Fix link in docs (Daniel Vetter) Suggested-by:
-
Noralf Trønnes authored
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:
-
Colin Ian King authored
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
-
Fabrizio Castro authored
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: 21d80840 ("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.htmlAcked-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
-
- 19 Nov, 2018 1 commit
-
-
Damian Kos authored
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
-
- 15 Nov, 2018 3 commits
-
-
Fabrizio Castro authored
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:
Yannick Fertré <yannick.fertre@st.com> Signed-off-by:
-
Linus Walleij authored
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:
-
Gabriel Krisman Bertazi authored
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
-
- 14 Nov, 2018 9 commits
-
-
YueHaibing authored
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 f2c24b83 ("drm/ttm: flip the switch, and convert to dma_fence") And 'driver' never used since introduction in 8002db63 ("qxl: convert qxl driver to proper use for reservations") Signed-off-by:
-
YueHaibing authored
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:
-
Colin Ian King authored
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: 6a37c49a ("drm/virtio: Handle context ID allocation errors") Signed-off-by: -
Gustavo Padovan authored
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.comSigned-off-by:
-
Robert Foss authored
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 authored
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:
-
Robert Foss authored
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:
-
Matthew Wilcox authored
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.orgSigned-off-by:
-
Matthew Wilcox authored
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:
-
- 13 Nov, 2018 7 commits
-
-
Neil Armstrong authored
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:
-
Neil Armstrong authored
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 authored
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:
Maxime Jourdan <mjourdan@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/1541497202-20570-2-git-send-email-narmstrong@baylibre.com
-
YueHaibing authored
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 9e1f05b2 ("drm/sti: rename files and functions") 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
-
Maxime Jourdan authored
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 authored
Allows using the new canvas provider module if present. Signed-off-by:
-
Maarten Lankhorst authored
drm-next is forwarded to v4.20-rc1, and we need this to make a patch series apply. Signed-off-by:
-
- 12 Nov, 2018 2 commits
-
-
Chris Wilson authored
We need to include the revert of commit 783195ec ("drm/syncobj: disable the timeline UAPI for now v2") along with undoing the change to drm/i915. Fixes: 131280a1 ("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:
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
-
Eric Anholt authored
Daniel suggested I submit this, since we're still seeing regressions from it. This is a revert to before 48197bc5 ("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:
-
- 09 Nov, 2018 5 commits
-
-
Boris Brezillon authored
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 authored
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: fc04023f ("drm/vc4: Add support for YUV planes.") Signed-off-by:
-
Paul Kocialkowski authored
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
-
Paul Kocialkowski authored
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 authored
Passing the encoder to the TCON RGB setup functions allows accessing the connector from the encoder directly instead of relying on the panel. Signed-off-by:
-
- 08 Nov, 2018 1 commit
-
-
Christian König authored
Until we have sorted out all problems. v2: return -EINVAL during create if flag is set. Signed-off-by:
-
- 07 Nov, 2018 2 commits
-
-
Ville Syrjälä authored
Convert drm_atomic_plane_check() over to using explicit old vs. new plane states. Avoids the confusion of "what does plane->state mean again?". v2: Stick to the multi-stage logic in plane_switching_crtc() (Daniel) Signed-off-by:
-
Ville Syrjälä authored
Convert drm_atomic_crtc_check() over to using explicit old vs. new crtc states. Avoids the confusion of "what does crtc->state mean again?". Signed-off-by:
-
