summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-09-29dma-buf: Use struct dma_buf_map in dma_buf_vunmap() interfacesThomas Zimmermann16-34/+66
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: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Tomasz Figa <tfiga@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-4-tzimmermann@suse.de
2020-09-29dma-buf: Use struct dma_buf_map in dma_buf_vmap() interfacesThomas Zimmermann17-61/+143
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 <tzimmermann@suse.de> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Tomasz Figa <tfiga@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-3-tzimmermann@suse.de
2020-09-29dma-buf: Add struct dma-buf-map for storing struct dma_buf.vaddr_ptrThomas Zimmermann3-8/+91
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: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-2-tzimmermann@suse.de
2020-09-29drm/qxl: simplify the return expression of qxl_plane_prepare_fb()Qinglang Miao1-6/+1
Simplify the return expression. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200921131022.91649-1-miaoqinglang@huawei.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: advertise features to userspaceGurchetan Singh1-1/+10
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.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: resource create blob ioctlGerd Hoffmann4-3/+144
Implement resource create blob as specified. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-18-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
2020-09-29drm/virtio: implement blob resources: report blob mem to userspaceGurchetan Singh1-0/+3
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-17-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: fix stride discrepancyGurchetan Singh3-6/+47
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-16-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: refactor UUID code somewhatGurchetan Singh2-13/+31
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-15-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: blob display integrationGurchetan Singh1-6/+17
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-14-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: hypercall interfaceGurchetan Singh2-0/+80
This implements the blob hypercall interface. 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-13-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: implement vram objectGerd Hoffmann7-3/+293
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: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-12-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
2020-09-29drm/virtio: implement blob resources: add new fields to internal structsGurchetan Singh1-3/+14
Useful for upcoming blob resources. 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-11-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: expose virtio_gpu_resource_id_getGurchetan Singh2-2/+3
VRAM object will need 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-10-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: implement blob resources: probe for host visible regionGerd Hoffmann3-2/+25
The availability of the host visible region means host 3D allocations can be directly mapped in the guest. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-9-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
2020-09-29drm/virtio: implement blob resources: probe for the feature.Gerd Hoffmann4-3/+10
Let's proble for VIRTIO_GPU_F_RESOURCE_BLOB. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 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-8-gurchetansingh@chromium.org
2020-09-29drm/virtgpu api: cross-device featureGurchetan Singh1-0/+1
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 <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-7-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtgpu api: host visible featureGurchetan Singh1-0/+1
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: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-6-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtgpu api: blob resourcesGurchetan Singh1-1/+36
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: Gurchetan Singh <gurchetansingh@chromium.org> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-5-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29virtio-gpu api: host visible featureGerd Hoffmann1-0/+35
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 <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-4-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
2020-09-29virtio-gpu api: blob resourcesGerd Hoffmann1-0/+43
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: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Chia-I Wu <olvaffe@gmail.com> Acked-by: Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-3-gurchetansingh@chromium.org Co-developed-by: Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org>
2020-09-29drm/virtio: blob prep: make CPU responses more genericGurchetan Singh3-11/+11
RESOURCE_MAP_BLOB / RESOURCE_UNMAP_BLOB can use this. 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-2-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/virtio: blob prep: refactor getting pages and attaching backingGurchetan Singh1-8/+8
Useful for upcoming blob resources. 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-1-gurchetansingh@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-09-29drm/rockchip: Include <drm/drm_gem_cma_helper> for drm_gem_cm_vm_opsThomas Zimmermann1-0/+1
Include <drm/drm_gem_cma_helper.h> to get drm_gem_cma_vm_ops. Fallout from the recent conversion to GEM object functions. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Reported-by: kernel test robot <lkp@intel.com> Fixes: 0d590af3140d ("drm/rockchip: Convert to drm_gem_object_funcs") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Christian König <christian.koenig@amd.com> Cc: Sandy Huang <hjc@rock-chips.com> Cc: "Heiko Stübner" <heiko@sntech.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Link: https://patchwork.freedesktop.org/patch/msgid/20200928081643.8575-1-tzimmermann@suse.de
2020-09-28drm/hisilicon: Deleted the drm_device declarationTian Tao1-2/+0
drm_framebuffer.h already declares struct drm_device, so there's no need to declare it in hibmc_drm_drv.h v2: fixed spelling errors in commit message. v3: rewrite the commit message. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1601020086-43652-1-git-send-email-tiantao6@hisilicon.com
2020-09-28drm/ttm: remove fault callbackChristian König2-25/+0
Another one bites the dust. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/392325/
2020-09-28drm/nouveau: stop using TTMs fault callbackChristian König3-28/+33
We already implemented the fault handler ourself, just open code what is necessary here. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/392323/
2020-09-28drm/amdgpu: stop using TTMs fault callbackChristian König3-16/+46
Implement the fault handler ourself using the provided TTM functions. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/392324/
2020-09-28drm/radeon: stop using TTMs fault callbackChristian König3-19/+34
We already implemented the fault handler ourself, just open code what is necessary here. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/392322/
2020-09-28drm/ttm: move SG flag check into ttm_bo_vm_reserveChristian König1-7/+9
Just check earlier if a BO can be page faulted in the first place. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/392321/
2020-09-28drm/ingenic: Add support for paletted 8bppPaul Cercueil1-4/+62
On JZ4725B and newer, the F0 plane supports paletted 8bpp with a 256-entry palette. Add support for it. v3: Only accept a full 256-entry palette. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200927193645.262612-2-paul@crapouillou.net
2020-09-26drm/ingenic: Add support for 24-bit modesPaul Cercueil2-0/+10
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. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-8-paul@crapouillou.net
2020-09-26drm/ingenic: Add support for 30-bit modesPaul Cercueil2-0/+9
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. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-7-paul@crapouillou.net
2020-09-26drm/ingenic: Support handling different pixel formats in F0/F1 planesPaul Cercueil1-10/+47
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. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-5-paul@crapouillou.net
2020-09-26drm/ingenic: Alloc F0 and F1 DMA descriptors at oncePaul Cercueil1-23/+28
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. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-4-paul@crapouillou.net
2020-09-26drm/ingenic: Add support for reserved memoryPaul Cercueil1-0/+19
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. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-3-paul@crapouillou.net
2020-09-26drm/ingenic: Reset pixclock rate when parent clock rate changesPaul Cercueil1-1/+60
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. v2: Add comment about mutex usage Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200926170501.1109197-2-paul@crapouillou.net
2020-09-25fbdev: sbuslib: remove compat_alloc_user_space usageArnd Bergmann1-25/+70
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. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200918100926.1447563-3-arnd@arndb.de
2020-09-25fbdev: sbuslib: remove unused FBIOSCURSOR32 helperArnd Bergmann1-28/+1
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. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200918100926.1447563-2-arnd@arndb.de
2020-09-25fbdev: simplify fb_getput_cmap()Arnd Bergmann1-25/+19
This function is one of the remaining users of compat_alloc_user_space() and copy_in_user(). Clean it up by copying to a local data structure copy instead, which also leads to more readable code. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200918100926.1447563-1-arnd@arndb.de
2020-09-25drm/vram-helper: Don't put new BOs into VRAMThomas Zimmermann1-2/+1
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. v2: * rebased onto latest drm-tip Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200922145700.25413-4-tzimmermann@suse.de
2020-09-25drm/vram-helper: Set object function iff they are not provided by driverThomas Zimmermann1-4/+12
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() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20200922145700.25413-3-tzimmermann@suse.de
2020-09-25drm/vram-helper: Integrate drm_gem_vram_init() into drm_gem_vram_create()Thomas Zimmermann1-48/+29
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. v2: * rebased onto latest drm-tip * fixed typo in commit message (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200922145700.25413-2-tzimmermann@suse.de
2020-09-25drm: Remove obsolete GEM and PRIME callbacks from struct drm_driverThomas Zimmermann7-137/+38
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) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-23-tzimmermann@suse.de
2020-09-25drm/xlnx: Initialize DRM driver instance with CMA helper macroThomas Zimmermann1-13/+1
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) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-22-tzimmermann@suse.de
2020-09-25drm/xen: Introduce GEM object functionsThomas Zimmermann3-27/+34
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) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-21-tzimmermann@suse.de
2020-09-25drm/vkms: Introduce GEM object functionsThomas Zimmermann2-8/+13
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. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-20-tzimmermann@suse.de
2020-09-25drm/virtgpu: Set PRIME export function in struct drm_gem_object_funcsThomas Zimmermann2-1/+1
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. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-19-tzimmermann@suse.de
2020-09-25drm/vgem: Introduce GEM object functionsThomas Zimmermann1-7/+14
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. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-18-tzimmermann@suse.de
2020-09-25drm/vc4: Introduce GEM object functionsThomas Zimmermann3-14/+20
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. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-17-tzimmermann@suse.de
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-08 06:05:38 +0000