Re: [PATCH 1/3] drm/bochs: Move to tiny/

2021-06-30 Thread Daniel Vetter
> Signed-off-by: Thomas Zimmermann Really nice! On the series: Acked-by: Daniel Vetter I think I've found one missing static below. Cheers, Daniel > --- > MAINTAINERS | 2 +- > drivers/gpu/drm/Kconfig | 2 - > drivers/gpu/drm/Makefile

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

2021-04-26 Thread Daniel Vetter
On Mon, Apr 26, 2021 at 02:18:05PM +0200, Thomas Zimmermann wrote: > Hi > > Am 20.04.21 um 10:46 schrieb Daniel Vetter: > > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > > > Hi Thomas, > > > > > > On Fri, Apr 16, 2021 a

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

2021-04-20 Thread Daniel Vetter
On Tue, Apr 20, 2021 at 11:16:09AM +0200, Geert Uytterhoeven wrote: > Hi Daniel, > > On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote: > > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote: > > > On Fri, Apr 16, 2021 at 11:00 AM Thomas

Re: [PATCH v4 0/9] drm: Support simple-framebuffer devices and firmware fbs

2021-04-20 Thread Daniel Vetter
here's not much userspace for it. In other words, it would work as well as current offb would, but that's at least that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] drm: Fix fbcon blank on QEMU graphics drivers

2021-04-16 Thread Daniel Vetter
bool deferred_setup; > > + /** > +* @no_dpms_blank: > +* > +* A flag indicating that the driver doesn't support blanking. > + * Then fbcon core code falls back to its generic handler. > +*/ > + bool no_dpms_blank; > + >

Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership

2021-04-16 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 09:12:14PM +0200, Thomas Zimmermann wrote: > Hi > > Am 15.04.21 um 14:57 schrieb Daniel Vetter: > > On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote: > > > Hi > > > > > > Am 09.04.21 um 11:22 schrieb Daniel Vett

Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership

2021-04-15 Thread Daniel Vetter
On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote: > Hi > > Am 09.04.21 um 11:22 schrieb Daniel Vetter: > > > Is it that easy? simepldrm's detach function has code to synchronize with > > > concurrent hotplug removals. If we can use drm_dev_unp

Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership

2021-04-09 Thread Daniel Vetter
On Fri, Apr 09, 2021 at 09:54:03AM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 11:48 schrieb Daniel Vetter: > > On Thu, Mar 18, 2021 at 11:29:15AM +0100, Thomas Zimmermann wrote: > > > Platform devices might operate on firmware framebuffers, such as VESA or &g

Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership

2021-04-09 Thread Daniel Vetter
On Fri, Apr 09, 2021 at 09:06:56AM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 11:48 schrieb Daniel Vetter: > > > > Maybe just me, but to avoid overstretching the attention spawn of doc > > readers I'd avoid this example here. And maybe make the recommendat

Re: [PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers

2021-04-08 Thread Daniel Vetter
On Thu, Apr 08, 2021 at 01:34:03PM +0200, Thomas Zimmermann wrote: > Hi > > Am 08.04.21 um 13:16 schrieb Daniel Vetter: > > On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote: > > > The implementation of drm_driver.dumb_map_offset is the same for several

Re: [PATCH 0/4] drm: Generic dumb_map_offset for TTM-based drivers

2021-04-08 Thread Daniel Vetter
clude/drm/drm_gem_ttm_helper.h | 5 ++- > include/drm/drm_gem_vram_helper.h | 7 +--- > 12 files changed, 45 insertions(+), 103 deletions(-) > > -- > 2.30.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _

Re: [PATCH v2 00/10] drm: Support simple-framebuffer devices and firmware fbs

2021-04-08 Thread Daniel Vetter
-over, so on > >>>> many Laptops running say Fedora workstation the fbcon code is actually > >>>> unused > >>>> until the user manually switches to another virtual-console to log in in > >>>> text-mode: > >>>> > >>&

Re: [PATCH v2 03/10] drm/aperture: Move fbdev conflict helpers into drm_aperture.h

2021-04-08 Thread Daniel Vetter
+#include > + > +/** > + * drm_fb_helper_remove_conflicting_framebuffers - remove > firmware-configured framebuffers Annoying bikeshed, but I'd give them drm_aperture_ prefixes, for ocd consistency. Also make them real functions, they're quite big and will grow more in the

Re: [PATCH v2 04/10] drm/aperture: Add infrastructure for aperture ownership

2021-04-08 Thread Daniel Vetter
re private > * rebase onto existing drm_aperture.h header file > * use MIT license only for simplicity > * documentation > > Signed-off-by: Thomas Zimmermann > Tested-by: nerdopolis Bunch of bikesheds for your considerations below, but overall lgtm. Acked-by: D

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

2021-02-08 Thread Daniel Vetter
he host side (like displays I guess? or maybe video encode if this is for cloug gaming?), then using virtio-gpu in render mode should also allow you to pass the dma_fence back Which we'll need too, not just the dma-buf. So at a first guess I'd say "render-only virtio-gpu mode" sounds like s

Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver

2021-02-05 Thread Daniel Vetter
buf(struct virtio_vdmabuf_info *info, > + struct virtio_vdmabuf_buf *new) > +{ > + hash_add(info->buf_list, >node, new->buf_id.id); > + return 0; > +} > + > +/* comparing two vdmabuf IDs */ > +static inline bool > +is_same_buf(virtio_vdmabuf_bu

Re: [PATCH 2/6] drm/shmem-helper: Add additional KMS helpers

2021-02-03 Thread Daniel Vetter
On Wed, Feb 3, 2021 at 3:26 PM Thomas Zimmermann wrote: > > Hi > > Am 03.02.21 um 15:01 schrieb Daniel Vetter: > > On Wed, Feb 03, 2021 at 02:10:42PM +0100, Thomas Zimmermann wrote: > >> Several drivers use GEM SHMEM buffer objects as shadow buffers for > >>

Re: [PATCH 2/6] drm/shmem-helper: Add additional KMS helpers

2021-02-03 Thread Daniel Vetter
le_display_pipe *pipe, > + struct drm_plane_state > *plane_state); > + > +/** > + * DRM_GEM_SHMEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS - > + * Initializes struct drm_simple_display_pipe_funcs for SHMEM shadow planes > + * >

Re: [PATCH v4 5/5] drm/qxl: properly free qxl releases

2021-02-03 Thread Daniel Vetter
int qxl_release_bo_alloc(struct qxl_device *qdev, > @@ -344,6 +345,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev, > unsigned long size, > *rbo = NULL; > return idr_ret; > } > + atomic_inc(>release_count); > >

Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings

2021-02-02 Thread Daniel Vetter
On Wed, Jan 27, 2021 at 01:08:05PM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.21 um 17:50 schrieb Daniel Vetter: > > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote: > > > Implementations of the vmap/vunmap GEM callbacks may perform pinning > &g

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

2021-01-22 Thread Daniel Vetter
them. Setting it to 0 kinda defeats the warning. -Daniel > > Not calling ttm_bo_unpin() makes ttm_bo_release() throw > a WARN() because of the pin. > > Clearing pin_count (which is how ttm fixes things up > in the error path) wor

Re: [PATCH v4] drm/virtio: Track total GPU memory for virtio driver

2021-01-22 Thread Daniel Vetter
full use cases on Android's closed stacks. And it is uapi. Tech debt isn't measured in lines of code, but in how expensive it's going to be to fix up the mess in the future. uapi is expensive no matter how few lines are used to implement it. So yeah this needs to be properly thought out,

Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver

2021-01-20 Thread Daniel Vetter
On Wed, Jan 20, 2021 at 10:51 AM Yiwei Zhang‎ wrote: > > On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote: > > > > On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote: > > > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote: > > > > > &g

Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver

2021-01-20 Thread Daniel Vetter
On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote: > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote: > > > > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote: > > > > > > On the success of virtio_gpu_object_create, add size of newly allocated

Re: [PATCH v2] drm/virtio: Track total GPU memory for virtio driver

2021-01-18 Thread Daniel Vetter
md_unref_resource(vgdev, bo); > virtio_gpu_notify(vgdev); > /* completion handler calls virtio_gpu_cleanup_object() */ > @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device > *vgdev, >

Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings

2021-01-12 Thread Daniel Vetter
On Tue, Jan 12, 2021 at 02:11:24PM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.21 um 17:50 schrieb Daniel Vetter: > > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote: > > > Implementations of the vmap/vunmap GEM callbacks may perform pinning > &g

Re: [PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update

2021-01-12 Thread Daniel Vetter
On Tue, Jan 12, 2021 at 08:54:02AM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.01.21 um 18:06 schrieb Daniel Vetter: > > On Fri, Jan 08, 2021 at 10:43:38AM +0100, Thomas Zimmermann wrote: > > > Cursor updates in vboxvideo require a short-term mapping of

Re: [PATCH v4 11/13] drm/vboxvideo: Use drm_gem_vram_vmap_local() in cursor update

2021-01-11 Thread Daniel Vetter
t drm_plane > *plane, > data_size = width * height * 4 + mask_size; > > copy_cursor_image(src, vbox->cursor_data, width, height, mask_size); > - drm_gem_vram_vunmap(gbo, ); > + drm_gem_vram_vunmap_local(gbo, ); > + dma_resv_unlock(obj->resv)

Re: [PATCH v4 06/13] drm/cirrus: Use drm_gem_shmem_vmap_local() in damage handling

2021-01-11 Thread Daniel Vetter
On Mon, Jan 11, 2021 at 06:00:42PM +0100, Daniel Vetter wrote: > On Fri, Jan 08, 2021 at 10:43:33AM +0100, Thomas Zimmermann wrote: > > Damage handling in cirrus requires a short-term mapping of the source > > BO. Use drm_gem_shmem_vmap_local(). > > > > Signed-off-by:

Re: [PATCH v4 07/13] drm/gm12u320: Use drm_gem_shmem_vmap_local() in damage handling

2021-01-11 Thread Daniel Vetter
. -Daniel > vunmap: > - drm_gem_shmem_vunmap(fb->obj[0], ); > + drm_gem_shmem_vunmap_local(fb->obj[0], ); > put_fb: > drm_framebuffer_put(fb); > gm12u320->fb_update.fb = NULL; > -- > 2.29.2 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 06/13] drm/cirrus: Use drm_gem_shmem_vmap_local() in damage handling

2021-01-11 Thread Daniel Vetter
on't we vmap/vunmap these in prepare/cleanup_fb? Generally we'd want a long-term vmap here to make sure this all works nicely. Since it's nothing new, on this patch: Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/tiny/cirrus.c | 10 -- > 1 file changed, 8 insertions(+), 2 d

Re: [PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling

2021-01-11 Thread Daniel Vetter
On Mon, Jan 11, 2021 at 05:53:41PM +0100, Daniel Vetter wrote: > On Fri, Jan 08, 2021 at 10:43:32AM +0100, Thomas Zimmermann wrote: > > Damage handling in mgag200 requires a short-term mapping of the source > > BO. Use drm_gem_shmem_vmap_local(). > > > > Signe

Re: [PATCH v4 05/13] drm/mgag200: Use drm_gem_shmem_vmap_local() in damage handling

2021-01-11 Thread Daniel Vetter
On Fri, Jan 08, 2021 at 10:43:32AM +0100, Thomas Zimmermann wrote: > Damage handling in mgag200 requires a short-term mapping of the source > BO. Use drm_gem_shmem_vmap_local(). > > Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/mgag

Re: [PATCH v4 13/13] drm/vram-helper: Remove unused drm_gem_vram_{vmap,vunmap}()

2021-01-11 Thread Daniel Vetter
nmap operations in VRAM helpers are therefore unused > and can be removed. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_gem_vram_helper.c | 98 --- > include/drm/drm_gem_vram_helper.h | 2 - > 2 files

Re: [PATCH v4 04/13] drm/shmem-helper: Provide a vmap function for short-term mappings

2021-01-11 Thread Daniel Vetter
ude/drm/drm_gem_shmem_helper.h > index 434328d8a0d9..3f59bdf749aa 100644 > --- a/include/drm/drm_gem_shmem_helper.h > +++ b/include/drm/drm_gem_shmem_helper.h > @@ -114,7 +114,9 @@ void drm_gem_shmem_put_pages(struct drm_gem_shmem_object > *shmem); > int drm_gem_shmem_pin(stru

Re: [PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings

2021-01-07 Thread Daniel Vetter
On Thu, Jan 7, 2021 at 11:28 AM Thomas Zimmermann wrote: > > Hi Daniel > > Am 11.12.20 um 10:50 schrieb Daniel Vetter: > [...] > >> +/** > >> + * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM > >> object > >> + * @shmem:

Re: [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations

2020-12-11 Thread Daniel Vetter
s a virtual mapping that wa sestablished by @vmap_local. > + * > + * This callback is optional. > + */ > + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > }; > > /** > @@ -506,4 +538,6 @@ int dma_buf_mmap(struct dma_buf *, stru

Re: [PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker

2020-12-11 Thread Daniel Vetter
On Fri, Dec 11, 2020 at 11:16:25AM +0100, Thomas Zimmermann wrote: > Hi > > Am 11.12.20 um 11:01 schrieb Daniel Vetter: > > On Wed, Dec 09, 2020 at 03:25:27PM +0100, Thomas Zimmermann wrote: > > > Fbdev emulation has to lock the BO into place while flushing the shadow &g

Re: [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates

2020-12-11 Thread Daniel Vetter
On Fri, Dec 11, 2020 at 11:49:48AM +0100, Thomas Zimmermann wrote: > > > Am 11.12.20 um 11:18 schrieb Daniel Vetter: > > On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote: > > > The HW cursor's BO used to be mapped permanently into the kernel's > &g

Re: [PATCH v3 2/8] drm/ast: Only map cursor BOs during updates

2020-12-11 Thread Daniel Vetter
in commit description > > Signed-off-by: Thomas Zimmermann > Acked-by: Christian König Acked-by: Daniel Vetter Now there's a pretty big issue here though: We can't take dma_resv_lock in commit_tail, because of possible deadlocks on at least gpus that do real async rendering b

Re: [PATCH v3 1/8] drm/ast: Don't pin cursor source BO explicitly during update

2020-12-11 Thread Daniel Vetter
On Wed, Dec 09, 2020 at 03:25:20PM +0100, Thomas Zimmermann wrote: > Vmapping the cursor source BO contains an implicit pin operation, > so there's no need to do this manually. > > Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter > --- > drivers/gpu/drm/ast

Re: [PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings

2020-12-11 Thread Daniel Vetter
On Fri, Dec 11, 2020 at 10:40:00AM +0100, Daniel Vetter wrote: > On Wed, Dec 09, 2020 at 03:25:24PM +0100, Thomas Zimmermann wrote: > > Implementations of the vmap/vunmap GEM callbacks may perform pinning > > of the BO and may acquire the associated reservation object's lock. > &

Re: [PATCH v3 8/8] drm/fb-helper: Move BO locking from DRM client to fbdev damage worker

2020-12-11 Thread Daniel Vetter
ease delete. That will also make it clearer in the diff what's going on and that it makes sense to have the client and fb-helper part in one patch. With that: Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_client.c| 91 + >

Re: [PATCH v3 7/8] drm/vram-helper: Provide a vmap function for short-term mappings

2020-12-11 Thread Daniel Vetter
ap_local() with the returned address to > unmap and > + * unpin the GEM VRAM object. > + * > + * The function is called with the BO's reservation object locked. For > short-term > + * mappings, callers must hold the lock until after unmapping the buffer. For "the lock" is

Re: [PATCH v3 6/8] drm/shmem-helper: Provide a vmap function for short-term mappings

2020-12-11 Thread Daniel Vetter
ret = mutex_lock_interruptible(>vmap_lock); This bites. You need to check for shmem->import_attach and call dma_buf_vmap_local directly here before you take any shmem helper locks. Real fix would be to replace both vmap_lock and pages_lock with dma_resv lock, but that's more work.

Re: [PATCH v3 5/8] drm/cma-helper: Provide a vmap function for short-term mappings

2020-12-11 Thread Daniel Vetter
vc4_bo *bo = to_vc4_bo(obj); > + > + if (bo->validated_shader) { This freaks me out. It should be impossible to export a validated shader as a dma-buf, and indeed the check exists already. All the wrapper functions here are imo pointless. Either we should remove them, or replace the i

Re: [PATCH v3 4/8] drm/gem: Create infrastructure for GEM vmap_local

2020-12-11 Thread Daniel Vetter
5e6daa1c982f..1281f26de494 100644 > --- a/include/drm/drm_gem.h > +++ b/include/drm/drm_gem.h > @@ -151,6 +151,26 @@ struct drm_gem_object_funcs { >*/ > void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map); > > + /** > + * @vm

Re: [PATCH v3 3/8] dma-buf: Add vmap_local and vnumap_local operations

2020-12-11 Thread Daniel Vetter
cal. ^^established > + * > + * This callback is optional. > + */ > + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map); > }; > > /** > @@ -506,4 +538,6 @@ int

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-03 Thread Daniel Vetter
On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas

Re: [PATCH 14/15] drm/vmwgfx: Remove references to struct drm_device.pdev

2020-12-02 Thread Daniel Vetter
you're OK with that, I'd merge the vmwgfx patch through > > drm-misc-next as well. > > Sounds good. I’ll make sure to rebase our latest patch set on top of it when > it’s in. Thanks! btw if you want to avoid multi-tree coordination headaches, we can also manage vmwgfx in

Re: [PATCH] drm/qxl: Remove fbcon acceleration leftovers

2020-11-17 Thread Daniel Vetter
On Thu, Oct 29, 2020 at 02:33:47PM +0100, Daniel Vetter wrote: > These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev > emulation code"). > > v2: Somehow these structs provided the struct qxl_device pre-decl, > reorder the header to not anger compi

Re: [PATCH v5 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces

2020-11-05 Thread Daniel Vetter
pens, this might be the only thing that manages to get the oops to the user. Unless someone really starts caring about fbcon acceleration I really wouldn't bother. Ok maybe it also matters for fbdev, but the problem is that the page fault intercepting alone is already expensive, so

[PATCH 5/6] drm/: Constify struct drm_driver

2020-11-04 Thread Daniel Vetter
message (Sam) Acked-by: Sam Ravnborg Cc: kernel test robot Acked-by: Maxime Ripard Reviewed-by: Alex Deucher Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc

[PATCH 5/5] drm/: Constify struct drm_driver

2020-10-30 Thread Daniel Vetter
Cc: kernel test robot Acked-by: Maxime Ripard Signed-off-by: Daniel Vetter Cc: Sam Ravnborg Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs

[PATCH] drm/qxl: Remove fbcon acceleration leftovers

2020-10-29 Thread Daniel Vetter
These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev emulation code"). v2: Somehow these structs provided the struct qxl_device pre-decl, reorder the header to not anger compilers. Acked-by: Gerd Hoffmann Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Ho

[PATCH 3/3] drm/qxl: Remove fbcon acceleration leftovers

2020-10-29 Thread Daniel Vetter
These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev emulation code"). Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org --- drivers/gpu/drm/qxl/qxl_drv.h | 14 ---

Re: [PATCH 6/8] drm: atomic: use krealloc_array()

2020-10-27 Thread Daniel Vetter
On Tue, Oct 27, 2020 at 01:17:23PM +0100, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > Use the helper that checks for overflows internally instead of manually > calculating the size of the new array. > > Signed-off-by: Bartosz Golaszewski Acked-by: Daniel Vette

Re: [PATCH 5/5] drm/: Constify struct drm_driver

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 9:43 AM Thomas Zimmermann wrote: > > Hi > > Am 23.10.20 um 14:28 schrieb Daniel Vetter: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > - nouveau, becau

Re: [PATCH] drm/: Constify struct drm_driver

2020-10-25 Thread Daniel Vetter
On Sun, Oct 25, 2020 at 11:23 PM Sam Ravnborg wrote: > > Hi Daniel. > > On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote: > > Only the following drivers aren't converted: > > - amdgpu, because of the driver_feature mangling due to virt support > > -

[PATCH] drm/: Constify struct drm_driver

2020-10-23 Thread Daniel Vetter
(everyone else is way too much). v2: Fix one misplaced const static, should be static const (0day) Cc: kernel test robot Acked-by: Maxime Ripard Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex

[PATCH 5/5] drm/: Constify struct drm_driver

2020-10-23 Thread Daniel Vetter
(everyone else is way too much). Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org Cc: Harry Wentland Cc: Leo Li Cc: Alex Deucher Cc: Christian König Cc: Eric Anholt Cc: Maxime Ripard Cc: Ben Skeggs Cc: nouv...@lists.freedesktop.org

Re: [PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map

2020-10-22 Thread Daniel Vetter
On Thu, Oct 22, 2020 at 11:18 AM Thomas Zimmermann wrote: > > Hi > > On 22.10.20 10:49, Daniel Vetter wrote: > > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: > >> Kernel DRM clients now store their framebuffer address in an instance > >&

Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory

2020-10-22 Thread Daniel Vetter
On Thu, Oct 22, 2020 at 10:37:56AM +0200, Thomas Zimmermann wrote: > Hi > > On 22.10.20 10:05, Daniel Vetter wrote: > > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote: > >> At least sparc64 requires I/O-specific access to framebuffers. This > >>

Re: [PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map

2020-10-22 Thread Daniel Vetter
_vmap() receive a copy of the value in > the call's supplied arguments. It can be accessed and modified with > dma_buf_map interfaces. > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Daniel Vetter > Tested-by: Sam Ravnborg > --- >

Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory

2020-10-22 Thread Daniel Vetter
dependencies on the fbdev module. Some of the > +helpers could further benefit from using struct dma_buf_map instead of > +raw pointers. > + > +Contact: Thomas Zimmermann , Daniel Vetter > + > +Level: Advanced > + > + > drm_framebuffer_funcs and drm_mode_config_funcs.f

Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

2020-10-19 Thread Daniel Vetter
_bo_mmap_obj - mmap memory backed by a ttm buffer object. > > > >    * > > > > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h > > > > index fd1aba545fdf..2e8bbecb5091 100644 > > > > --- a/include/linux/dma-buf-map.h > > > &g

Re: [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers

2020-10-15 Thread Daniel Vetter
invidual page (again using the dma_buf_map stuff). I'll let Christian with the details, but at a high level this is definitely Acked-by: Daniel Vetter Thanks a lot for doing all this. -Daniel > > > > > Signed-off-by: Thomas Zimmermann > > --- >

Re: [PATCH v3 6/7] drm/fb_helper: Support framebuffers in I/O memory

2020-10-08 Thread Daniel Vetter
On Thu, Oct 8, 2020 at 11:25 AM Thomas Zimmermann wrote: > > Hi > > Am 02.10.20 um 20:44 schrieb Daniel Vetter: > > On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote: > >> > >> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote: > >>&g

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-10-07 Thread Daniel Vetter
On Wed, Oct 7, 2020 at 3:25 PM Christian König wrote: > > Am 07.10.20 um 15:20 schrieb Thomas Zimmermann: > > Hi > > > > Am 07.10.20 um 15:10 schrieb Daniel Vetter: > >> On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann > >> wrote: > >>> Hi

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-10-07 Thread Daniel Vetter
On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann wrote: > > Hi > > Am 02.10.20 um 11:58 schrieb Daniel Vetter: > > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > >> On Wed, Sep 30, 2020 at 2:34 PM Christian König > >> wrote: > >&g

Re: [PATCH v3 6/7] drm/fb_helper: Support framebuffers in I/O memory

2020-10-02 Thread Daniel Vetter
On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote: > > On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote: > > At least sparc64 requires I/O-specific access to framebuffers. This > > patch updates the fbdev console accordingly. > > > >

Re: [PATCH v3 7/7] drm/todo: Update entries around struct dma_buf_map

2020-10-02 Thread Daniel Vetter
On Tue, Sep 29, 2020 at 05:14:37PM +0200, Thomas Zimmermann wrote: > Instances of struct dma_buf_map should be useful throughout DRM's > memory management code. Furthermore, several drivers can now use > generic fbdev emulation. > > Signed-off-by: Thomas Zimmermann Acked-by

Re: [PATCH v3 6/7] drm/fb_helper: Support framebuffers in I/O memory

2020-10-02 Thread Daniel Vetter
gt; + * .. code-block:: c > + * > + * const void *src = ...; // source buffer > + * size_t len = ...; // length of src > + * > + * dma_buf_map_memcpy_to(, src, len); > + * dma_buf_map_incr(, len); // go to first byte after the memcpy > */ > > /** >

Re: [PATCH v3 5/7] drm/gem: Store client buffer mappings as struct dma_buf_map

2020-10-02 Thread Daniel Vetter
uffer > + * @map: Virtual address for the buffer >*/ > - void *vaddr; > + struct dma_buf_map map; > > /** >* @fb: DRM framebuffer > @@ -155,7 +156,7 @@ struct drm_client_buffer * > drm_client_framebuffer_create(struct drm_client_dev *

Re: [PATCH v3 4/7] drm/gem: Update internal GEM vmap/vunmap interfaces to use struct dma_buf_map

2020-10-02 Thread Daniel Vetter
gt; */ > int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map) > { > struct drm_gem_object *obj = dma_buf->priv; > - void *vaddr; > > - vaddr = drm_gem_vmap(obj); > - if (IS_ERR(vaddr)) > - return PTR_ERR(vaddr); > -

Re: [PATCH v3 3/7] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends

2020-10-02 Thread Daniel Vetter
On Tue, Sep 29, 2020 at 05:14:33PM +0200, Thomas Zimmermann wrote: > This patch replaces the vmap/vunmap's use of raw pointers in GEM object > functions with instances of struct dma_buf_map. GEM backends are > converted as well. > > For most GEM backends, this simply change the returned type. GEM

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-10-02 Thread Daniel Vetter
On Fri, Oct 2, 2020 at 1:30 PM Christian König wrote: > > Am 02.10.20 um 11:58 schrieb Daniel Vetter: > > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > >> On Wed, Sep 30, 2020 at 2:34 PM Christian König > >> wrote: > >>>

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-10-02 Thread Daniel Vetter
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote: > On Wed, Sep 30, 2020 at 2:34 PM Christian König > wrote: > > > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: > > >&

Re: [PATCH v3 1/7] drm/vram-helper: Remove invariant parameters from internal kmap function

2020-10-02 Thread Daniel Vetter
On Tue, Sep 29, 2020 at 05:14:31PM +0200, Thomas Zimmermann wrote: > The parameters map and is_iomem are always of the same value. Removed them > to prepares the function for conversion to struct dma_buf_map. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter > ---

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-09-30 Thread Daniel Vetter
On Wed, Sep 30, 2020 at 2:34 PM Christian König wrote: > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote: > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > >>> Hi > >>> >

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-09-30 Thread Daniel Vetter
lock:: c > > > > > > + * > > > > > > + *    dma_buf_map_set_vaddr_iomem( 0xdeadbeaf); > > > > > > + * > > > > > >    * Test if a mapping is valid with either dma_buf_map_is_set() or > > > > > >    * dma_buf_map_is_null

Re: [PATCH v3 2/7] drm/ttm: Add ttm_kmap_obj_to_dma_buf_map() for type conversion

2020-09-29 Thread Daniel Vetter
> > } > > > > +/** > > + * dma_buf_map_set_vaddr_iomem - Sets a dma-buf mapping structure to an > > address in I/O memory > > + * @map: The dma-buf mapping structure > > + * @vaddr_iomem: An I/O-memory address > > + * &g

Re: [PATCH v2 4/4] drm/qxl: use qxl pin function

2020-09-29 Thread Daniel Vetter
erved, then ttm_bo_pin, then ttm_bo_unreserve, all explicitly. -Daniel > *bo_ptr = bo; > return 0; > } > -- > 2.27.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing

Re: [PATCH 1/3] drm/qxl: use drmm_mode_config_init

2020-09-08 Thread Daniel Vetter
On Tue, Sep 08, 2020 at 11:39:10AM +0200, Gerd Hoffmann wrote: > Signed-off-by: Gerd Hoffmann Btw going all in on devm_drm_dev_alloc and managed functions might be good cleanup for virtio. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/qxl/qxl_display.c | 5 +++-- > 1 fil

Re: [PATCH] drm/virtio: drop quirks handling

2020-09-08 Thread Daniel Vetter
virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo); > > - if (use_dma_api) > - dma_sync_sg_for_device(vgdev->vdev->dev.parent, > - shmem->pages->sgl, shmem->pages->nents

Re: [PATCH 1/2] drm/virtio: fix unblank

2020-09-01 Thread Daniel Vetter
gt;src_y || > + output->needs_modeset) { > + output->needs_modeset = false; > DRM_DEBUG("handle 0x%x, crtc %dx%d+%d+%d, src %dx%d+%d+%d\n", > bo->hw_res_handle, > plane->state->crtc_w, plane->state->crtc_h, > -- > 2.18.4 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 1/2] drm/virtio: fix unblank

2020-09-01 Thread Daniel Vetter
> > > > Cc: 1882...@bugs.launchpad.net > > > Fixes: 3954ff10e06e ("drm/virtio: skip set_scanout if framebuffer didn't > > > change") > > > Signed-off-by: Gerd Hoffmann > > > > Tested-by: Jiri Slaby >

Re: [PATCH] drm/virtio: fix unblank

2020-08-07 Thread Daniel Vetter
bo->hw_res_handle, > plane->state->crtc_w, plane->state->crtc_h, > @@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct > drm_plane *plane, > plane->state->src_h >> 16, >

Re: [PATCH v2] drm/qxl: don't take vga ports on rev5+

2020-08-07 Thread Daniel Vetter
ga ports any more to avoid that happening. > > Signed-off-by: Gerd Hoffmann Does what it says on the label. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/qxl/qxl_drv.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/qx

Re: [PATCH 2/2] drm/virtio: Remove open-coded commit-tail function

2020-07-14 Thread Daniel Vetter
On Thu, Jul 09, 2020 at 04:05:31PM +0200, Sam Ravnborg wrote: > On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote: > > Exactly matches the one in the helpers. > > > > This avoids me having to roll out dma-fence critical section > > annotations to thi

[PATCH 2/2] drm/virtio: Remove open-coded commit-tail function

2020-07-09 Thread Daniel Vetter
Exactly matches the one in the helpers. This avoids me having to roll out dma-fence critical section annotations to this copy. Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org --- drivers/gpu/drm/virtio/virtgpu_display.c | 20

Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects

2020-05-15 Thread Daniel Vetter
On Fri, May 15, 2020 at 02:07:06PM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 9:30 PM Daniel Vetter wrote: > > On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote: > > > Sorry for the duplicate reply, didn't notice this until now. > > > > >

Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects

2020-05-14 Thread Daniel Vetter
RT_SYMBOL_GPL. I wouldn't shed a big tear if they don't fit anymore, they're kinda not great to begin with. Much midlayer, not much of valued added, but at least the _GPL is gone. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _

Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects

2020-05-14 Thread Daniel Vetter
re's locking involved. Makes stuff more complicated, invariant attributes are a lot easier generally. Registering that uuid just always doesn't work, and blocking when you're exporting? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects

2020-05-14 Thread Daniel Vetter
On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote: > On Thu, May 14, 2020 at 12:45 AM Daniel Vetter wrote: > > On Wed, Mar 11, 2020 at 12:20 PM David Stevens > > wrote: > > > > > > This change adds a new dma-buf operation that allows dma-bufs t

Re: [PATCH v3 1/4] dma-buf: add support for virtio exported objects

2020-05-13 Thread Daniel Vetter
unsigned long); > void *dma_buf_vmap(struct dma_buf *); > void dma_buf_vunmap(struct dma_buf *, void *vaddr); > + > +int dma_buf_get_uuid(struct dma_buf *dmabuf, uuid_t *uuid); > + > #endif /* __DMA_BUF_H__ */ > -- > 2.25.1.481.gfbce0eb8

[PATCH 4/9] drm/virtio: Call the right shmem helpers

2020-05-11 Thread Daniel Vetter
88f106 Author: Gerd Hoffmann Date: Fri Feb 7 08:46:38 2020 +0100 drm/virtio: move virtio_gpu_mem_entry initialization to new function Signed-off-by: Daniel Vetter Cc: David Airlie Cc: Gerd Hoffmann Cc: virtualization@lists.linux-foundation.org --- drivers/gpu/drm/virtio/virtgpu_object.c | 2

Re: [PATCH 26/59] drm/qxl: Use devm_drm_dev_alloc

2020-04-28 Thread Daniel Vetter
On Tue, Apr 28, 2020 at 07:00:26PM +0200, Sam Ravnborg wrote: > On Tue, Apr 28, 2020 at 04:00:11PM +0200, Daniel Vetter wrote: > > On Fri, Apr 24, 2020 at 05:09:11PM +0200, Sam Ravnborg wrote: > > > Hi Daniel > > > > > > On Wed, Apr 15, 2020 at 09:40:01AM +020

Re: [PATCH 26/59] drm/qxl: Use devm_drm_dev_alloc

2020-04-28 Thread Daniel Vetter
On Fri, Apr 24, 2020 at 05:09:11PM +0200, Sam Ravnborg wrote: > Hi Daniel > > On Wed, Apr 15, 2020 at 09:40:01AM +0200, Daniel Vetter wrote: > > Also need to remove the drm_dev_put from the remove hook. > > > > Acked-by: Gerd Hoffmann > > Signed-off-by: D

Re: [PATCH 37/59] drm/cirrus: Move to drm/tiny

2020-04-15 Thread Daniel Vetter
On Wed, Apr 15, 2020 at 10:46 AM Thomas Zimmermann wrote: > > > > Am 15.04.20 um 10:19 schrieb Daniel Vetter: > > On Wed, Apr 15, 2020 at 10:01 AM Thomas Zimmermann > > wrote: > >> > >> > >> > >> Am 15.04.20 um 09:40 schrieb Daniel Vet

  1   2   3   4   >