All drivers should have a move callback now so make it compulsory.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-6-airlied@gmail.com

This will always do memcpy moves.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-5-airlied@gmail.com

This just copies the fallback to vmwgfx, I'm going to iterate on this
a bit until it's not the same as the fallback path.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-4-airlied@gmail.com

Both fns checked mem == NULL, just move the check outside.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-3-airlied@gmail.com

v2: drop the wrapper struct
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-2-airlied@gmail.com

no need for driver to wait here.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924051845.397177-29-airlied@gmail.com

The idea is to flip the core over to calling the driver always,
so add support for moves here.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200924051845.397177-6-airlied@gmail.com

This patch restores DRM connector registration in the TC358764 bridge
driver and restores usage of the old drm_panel_* API, thus allows dynamic
panel registration. This fixes panel operation on Exynos5250-based
Arndale board.

This is equivalent to the revert of the following commits:
1644127f "drm/bridge: tc358764: add drm_panel_bridge support"
385ca38d "drm/bridge: tc358764: drop drm_connector_(un)register"
and removal of the calls to drm_panel_attach()/drm_panel_detach(), which
were no-ops and has been removed in meanwhile.
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200930114042.5806-1-m.szyprowski@samsung.com

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: NRikard Falkeborn <rikard.falkeborn@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201004200653.14702-1-rikard.falkeborn@gmail.com

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: NTom Rix <trix@redhat.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20201003193928.18869-1-trix@redhat.com

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: NBoris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/393486/

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: NGowtham Tammana <g-tammana@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200826134409.473554-1-tomi.valkeinen@ti.com

Add assigned-clocks, assigned-clock-parents and dma-coherent optional
properties.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200916131009.221252-3-tomi.valkeinen@ti.com

Add assigned-clocks, assigned-clock-parents and dma-coherent optional
properties.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200916131009.221252-2-tomi.valkeinen@ti.com

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: NPaul Cercueil <paul@crapouillou.net>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201004141758.1013317-1-paul@crapouillou.net

Crank up the warning a notch and point at the right set of locking
functions for atomic drivers.
Acked-by: NMaxime Ripard <mripard@kernel.org>
Signed-off-by: NDaniel 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

Simplify the return expression.
Signed-off-by: NQinglang Miao <miaoqinglang@huawei.com>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NSteven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200921131021.91604-1-miaoqinglang@huawei.com

Simplify the return expression.
Signed-off-by: NQinglang Miao <miaoqinglang@huawei.com>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: NSteven Price <steven.price@arm.com>
Signed-off-by: NSteven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200921131019.91558-1-miaoqinglang@huawei.com

It has been a fun ride since 2017 but unfortunately I don't have
enough time to look after it properly anymore.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7b709254-9412-8473-250c-0c4e006259b3@samsung.com

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: NAlistair Delva <adelva@google.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200929215333.1241-1-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

The macro PADDING is no longer used. Delete it.
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1601340326-14049-1-git-send-email-tiantao6@hisilicon.com

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: NTian Tao <tiantao6@hisilicon.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1601282978-45534-1-git-send-email-tiantao6@hisilicon.com

- debugfs cleanup has moved forward thanks to the cleanup Wambui has
  done
Acked-by: NMelissa Wen <melissa.srw@gmail.com>
Reviewed-by: NGreg 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: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200929150333.3441576-1-daniel.vetter@ffwll.ch

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: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGerd Hoffmann <kraxel@redhat.com>
Tested-by: NGerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/392561/?series=82199&rev=1

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: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-5-tzimmermann@suse.de

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: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NTomasz Figa <tfiga@chromium.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-4-tzimmermann@suse.de

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: NThomas Zimmermann <tzimmermann@suse.de>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NTomasz Figa <tfiga@chromium.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-3-tzimmermann@suse.de

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: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-2-tzimmermann@suse.de

Simplify the return expression.
Signed-off-by: NQinglang Miao <miaoqinglang@huawei.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200921131022.91649-1-miaoqinglang@huawei.comSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

New api changes are now available to userspace. Also, the
comparison to true is redundant, so remove it.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-19-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

Implement resource create blob as specified.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-18-gurchetansingh@chromium.orgCo-developed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-17-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-16-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-15-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-14-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

This implements the blob hypercall interface.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-13-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

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: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-12-gurchetansingh@chromium.orgCo-developed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>

Useful for upcoming blob resources.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-11-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

VRAM object will need it.
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-10-gurchetansingh@chromium.orgSigned-off-by: NGerd Hoffmann <kraxel@redhat.com>

The availability of the host visible region means host 3D
allocations can be directly mapped in the guest.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Acked-by: NTomeu Vizoso <tomeu.vizoso@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200924003214.662-9-gurchetansingh@chromium.orgCo-developed-by: NGurchetan Singh <gurchetansingh@chromium.org>
Signed-off-by: NGurchetan Singh <gurchetansingh@chromium.org>