- 05 Oct, 2020 6 commits
-
-
Rikard Falkeborn authored
The only usage of dw_hdmi_i2s_ops is to assign its address to the ops field in the hdmi_codec_pdata struct, which is a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201004200653.14702-1-rikard.falkeborn@gmail.com
-
Tom Rix authored
clang static analysis reports this problem: cdv_intel_dp.c:2101:2: warning: Attempt to free released memory kfree(gma_connector); ^~~~~~~~~~~~~~~~~~~~ In cdv_intel_dp_init() when the call to cdv_intel_edp_panel_vdd_off() fails, the handler calls cdv_intel_dp_destroy(connector) which does the first free of gma_connector. So adjust the goto label and skip the second free. Fixes: d112a816 ("gma500/cdv: Add eDP support") Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
Boris Brezillon authored
If we don't initialize the entity to idle and the entity is never scheduled before being destroyed we end up with an infinite wait in the destroy path. v2: - Add Steven's R-b Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Gowtham Tammana authored
drm_gem_fb_prepare_fb() extracts fence and attaches to plane state. The fence info is needed if implicit fencing is used. Add this as prepare_fb function pointer to plane helper funcs. Signed-off-by:
Gowtham Tammana <g-tammana@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826134409.473554-1-tomi.valkeinen@ti.com
-
Tomi Valkeinen authored
Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200916131009.221252-3-tomi.valkeinen@ti.com
-
Tomi Valkeinen authored
Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by:
-
- 04 Oct, 2020 1 commit
-
-
Paul Cercueil authored
This reverts commit 37054fc8 ("gpu/drm: ingenic: Add option to mmap GEM buffers cached") At the very moment this commit was created, the DMA API it relied on was modified in the DMA tree, which caused the driver to break in linux-next. Revert it for now, and it will be resubmitted later to work with the new DMA API. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201004141758.1013317-1-paul@crapouillou.net
-
- 02 Oct, 2020 1 commit
-
-
Daniel Vetter authored
Crank up the warning a notch and point at the right set of locking functions for atomic drivers. Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.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> Link: https://patchwork.freedesktop.org/patch/msgid/20201002075620.4157591-1-daniel.vetter@ffwll.ch
-
- 01 Oct, 2020 2 commits
-
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Reviewed-by:
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
-
- 30 Sep, 2020 4 commits
-
-
Bartlomiej Zolnierkiewicz authored
It has been a fun ride since 2017 but unfortunately I don't have enough time to look after it properly anymore. Reviewed-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/7b709254-9412-8473-250c-0c4e006259b3@samsung.com
-
Alistair Delva authored
We encountered this issue when booting blob with a 32-bit kernel. The implementation doesn't match v6 of the virtio-spec change, so fix this. Fixes: ff886cbd ("virtio-gpu api: blob resources") Signed-off-by:
Alistair Delva <adelva@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200929215333.1241-1-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Tian Tao authored
The macro PADDING is no longer used. Delete it. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1601340326-14049-1-git-send-email-tiantao6@hisilicon.com
-
Tian Tao authored
Using the to_hibmc_drm_private to convert over all uses of dev_private, and fix a little formatting issue. v2: fixed the commit message. Signed-off-by:
-
- 29 Sep, 2020 26 commits
-
-
Daniel Vetter authored
- debugfs cleanup has moved forward thanks to the cleanup Wambui has done Acked-by:
Melissa Wen <melissa.srw@gmail.com> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Wambui Karuga <wambui.karugax@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
-
Christian König authored
We need to use ttm_bo_init_reserved here to make sure that the BO is pinned before it becomes visible on the LRU. Signed-off-by:
-
Thomas Zimmermann authored
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included. v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1 Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to use struct dma_buf_map. The interfaces used to receive a buffer address. This address is now given in an instance of the structure. Users of the functions are updated accordingly. This is only an interface change. It is currently expected that dma-buf memory can be accessed with system memory load/store operations. v2: * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Acked-by:
-
Thomas Zimmermann authored
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use struct dma_buf_map. The interfaces used to return a buffer address. This address now gets stored in an instance of the structure that is given as an additional argument. The functions return an errno code on errors. Users of the functions are updated accordingly. This is only an interface change. It is currently expected that dma-buf memory can be accessed with system memory load/store operations. v3: * update fastrpc driver (kernel test robot) v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
The new type struct dma_buf_map represents a mapping of dma-buf memory into kernel space. It contains a flag, is_iomem, that signals users to access the mapped memory with I/O operations instead of regular loads and stores. It was assumed that DMA buffer memory can be accessed with regular load and store operations. Some architectures, such as sparc64, require the use of I/O operations to access dma-map buffers that are located in I/O memory. Providing struct dma_buf_map allows drivers to implement this. This was specifically a problem when refreshing the graphics framebuffer on such systems. [1] As the first step, struct dma_buf stores an instance of struct dma_buf_map internally. Afterwards, dma-buf's vmap and vunmap interfaces are be converted. Finally, affected drivers can be fixed. v3: * moved documentation into separate patch * test for NULL pointers with !<ptr> [1] https://lore.kernel.org/dri-devel/20200725191012.GA434957@ravnborg.org/Signed-off-by:
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
-
Gurchetan Singh authored
New api changes are now available to userspace. Also, the comparison to true is redundant, so remove it. Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Acked-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-19-gurchetansingh@chromium.orgSigned-off-by:
-
Gerd Hoffmann authored
Implement resource create blob as specified. Signed-off-by:
-
Gurchetan Singh authored
The stride field has never been used, so repurpose it to be "blob_mem". This way, userspace can know the memory properties of the blob if it's passed between userspace processes and no suitable userspace API exists to transmit that knowledge. Signed-off-by:
-
Gurchetan Singh authored
The old transfer ioctls may work on blob resources, and there is no TRANSFER_BLOB hypercall now for simplicity. The guest may have a image view on the blob resources such that the stride is not equal to width * bytes_per_pixel. For host-only blobs, we can repurpose the transfer ioctls to synchronize caches as well. For guest-only blobs, these operations are undefined for now so leave them out. Also, with seamless Wayland integration between guest/host looking increasingly attractive, it also makes sense to keep track of one value for stride. Signed-off-by:
-
Gurchetan Singh authored
For upcoming blob resources, userspace can specify that the resource will be used for cross-device sharing. This is mainly for exportable blobs that will only shared with the virtgpu display but not across devices. Signed-off-by:
-
Gurchetan Singh authored
SCANOUT_BLOB forwards the DRM framebuffer metadata to the host. The modifier is intentionally left out -- it may be possible to query the host for that. We also assume one blob resource per DRM framebuffer. That too is an intentional simplification. Signed-off-by:
-
Gurchetan Singh authored
This implements the blob hypercall interface. Signed-off-by:
-
Gerd Hoffmann authored
A virtio-gpu vram object is based on range-based allocation. No guest shmemfs backing, so we call drm_gem_private_object_init. This is for host memory without any guest backing (atleast initially). Signed-off-by:
-
Gurchetan Singh authored
Useful for upcoming blob resources. Signed-off-by:
-
Gurchetan Singh authored
VRAM object will need it. Signed-off-by:
-
Gerd Hoffmann authored
The availability of the host visible region means host 3D allocations can be directly mapped in the guest. Signed-off-by:
-
Gerd Hoffmann authored
Let's proble for VIRTIO_GPU_F_RESOURCE_BLOB. Signed-off-by:
-
Gurchetan Singh authored
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. Signed-off-by:
-
Gurchetan Singh authored
This exposes the host visible feature to userspace. Without it, it is an error to specify BLOB_MEM_HOST3D with BLOG_FLAG_USE_MAPPABLE. Signed-off-by:
Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-6-gurchetansingh@chromium.orgSigned-off-by:
-
Gurchetan Singh authored
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. Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Acked-by:
-
Gerd Hoffmann authored
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. Signed-off-by:
-
Gerd Hoffmann authored
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. Signed-off-by: -
Gurchetan Singh authored
RESOURCE_MAP_BLOB / RESOURCE_UNMAP_BLOB can use this. Signed-off-by:
-
Gurchetan Singh authored
Useful for upcoming blob resources. Signed-off-by:
-
