e not been converted (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
e not been converted (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...@l
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
> >>
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
> >>
fer_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
&g
en without 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_conf
> > > /**
> > > > * ttm_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 fd1aba545f
pers to map an 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
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
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
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
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.
> >
> > For dri
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
Ack
nctionality, the type could be generalized
> - * and moved to a more prominent header file.
> + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(&map, src, len);
> +
t; @@ -141,9 +142,9 @@ struct drm_client_buffer {
> struct drm_gem_object *gem;
>
> /**
> - * @vaddr: Virtual address for the buffer
> + * @map: Virtual address for the buffer
>*/
> - void *vaddr;
> +
rns 0 on success or a negative errno code otherwise.
> */
> 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
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
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:
> >>> Am 30.09.20
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:
> > >&
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
> ---
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
> >>>
>
> > > > + * .. code-block:: c
> > > > > > + *
> > > > > > + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf);
> > > > > > + *
> > > > > > * Test if a mapping is valid with either dma_buf_map_is_set(
map->is_iomem = false;
> > }
> >
> > +/**
> > + * 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
_init_reserved, 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
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
; struct 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-
!= old_state->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
> >
> > > 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 Sla
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,
the
> vga 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/
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 this c
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
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.
> > >
>
EXPORT_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
_
do something and there'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://blo
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 to b
area_struct
> *,
> 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__ */
> --
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
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
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
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
On Wed, Apr 15, 2020 at 10:01 AM Thomas Zimmermann wrote:
>
>
>
> Am 15.04.20 um 09:40 schrieb Daniel Vetter:
> > Because it is. Huge congrats to everyone who made this kind of
> > refactoring happen!
>
> Every other week, I felt an urge to send out this patch. Than
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Acked-by: Gerd Hoffmann
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
This is leftovers from the old drm_driver->load callback
upside-down issues. It doesn't do anything for not-hotplugged
connectors since drm_dev_register takes care of that.
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/d
Because it is. Huge congrats to everyone who made this kind of
refactoring happen!
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
MAINTAINERS | 2 +-
drivers/gpu/drm/Kconfig | 2
Already using devm_drm_dev_init, so very simple replacment.
Acked-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: "Noralf Trønnes"
Cc: Rob Herring
Cc: Thomas Zimmermann
Cc: virt
Also need to remove the drm_dev_put from the remove hook.
Acked-by: Gerd Hoffmann
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.c | 15 ---
drivers
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Acked-by: Eric Anholt
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Eric
On Mon, Apr 6, 2020 at 7:29 PM Thomas Zimmermann wrote:
>
>
>
> Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> > Also need to remove the drm_dev_put from the remove hook.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Dave Airlie
> > Cc: Gerd Ho
_gpu_object_create")
>
> Both are in drm-misc-next. I suspect the fix was added after
> drm-misc-next was closed for the 5.7 merge window and thus should
> have been submitted to drm-misc-next-fixes instead.
>
> So, what to do now? Should I cherry-pick 0666a8d7f6a4 i
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Eric Anholt
Cc: Thomas Zimmermann
Cc: virt
Also need to remove the drm_dev_put from the remove hook.
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.c | 15 ---
drivers/gpu/drm/qxl/qxl_drv.h
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
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_debugfs.c | 7
Already using devm_drm_dev_init, so very simple replacment.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: "Noralf Trønnes"
Cc: Rob Herring
Cc: Thomas Zimmermann
Cc: virtualization@lists.linux-foundation.org
Cc: Em
().
v2: Explain why this cleanup is possible (Laurent).
v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
Acked-by: Gerd Hoffmann
Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vette
Hoffmann
Acked-by: Sam Ravnborg
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/bochs/bochs.h | 1 -
drivers/gpu/drm/bochs/bochs_drv.c | 6 ++
drivers/gpu/drm
by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Linus Walleij
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/cirrus/cirrus.c | 14 +++---
1 file changed, 7 insert
With this we can drop the final kfree from the release function.
Acked-by: Gerd Hoffmann
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.c | 2 --
drivers/gpu
On Wed, Mar 18, 2020 at 7:49 AM Gerd Hoffmann wrote:
>
> On Tue, Mar 17, 2020 at 05:49:41PM +0100, Daniel Vetter wrote:
> > On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
> > > Shutdown of firmware framebuffer has a bunch of problems. Because
> > >
OR("Cannot request framebuffer\n");
> - return -EBUSY;
> - }
> + if (pci_request_region(pdev, 0, "bochs-drm") != 0)
> + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
>
> bochs->fb_map = ioremap(addr,
alloc
their encoders. But I guess simplifying stuff like you do here will at
least give us a nice list of things to look at once we get to the
drmm_simple_encoder_init version of all this. On the series:
Acked-by: Daniel Vetter
>
> Thomas Zimmermann (22):
> drm/arc: Use simple enco
ries, since with just the first part it's really not any
better. I also have a pile more ideas on top, so hopefully once this lands
I can get around to them and make everything even better :-)
Cheers, Daniel
>
> In any case:
> Acked-by: Gerd Hoffmann
>
> cheers,
> Gerd
&g
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Tr
().
v2: Explain why this cleanup is possible (Laurent).
v3: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
Cc: Sam Ravnborg
Acked-by: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc
Cc: Thomas Zimmermann
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/bochs/bochs.h | 1 -
drivers/gpu/drm/bochs/bochs_drv.c | 6 ++
drivers/gpu/drm/bochs/bochs_kms.c | 14 +-
3 files
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: D
With this we can drop the final kfree from the release function.
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.c | 2 --
drivers/gpu/drm/qxl/qxl_kms.c | 2 ++
2
drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
v2: Explain why this cleanup is possible (Laurent).
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Ho
().
v2: Explain why this cleanup is possible (Laurent).
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Tr
With this we can drop the final kfree from the release function.
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.c | 2 --
drivers/gpu/drm/qxl/qxl_kms.c | 2 ++
2
With this we can drop the final kfree from the release function.
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.c | 2 --
drivers/gpu/drm/qxl/qxl_kms.c | 2 ++
2
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Tr
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Ho
().
v2: Explain why this cleanup is possible (Laurent).
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/
drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
v2: Explain why this cleanup is possible (Laurent).
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc
gt;> -
> > >> -
> > >> struct mga_i2c_chan {
> > >> struct i2c_adapter adapter;
> > >> struct drm_device *dev;
> > >
> > > Any particular reason why the drm_encoder is not embedded in struct
> >
Instead rely on the automatic clean, for which we just need to check
that drm_mode_config_init succeeded. To avoid an inversion in the
cleanup we also have to move the dev_private allocation over to
drmm_kzalloc.
Signed-off-by: Daniel Vetter
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Tr
We can even delete the drm_driver.release hook now!
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/cirrus/cir
With this we can drop the final kfree from the release function.
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.c | 2 --
drivers/gpu/drm/qxl/qxl_kms.c | 2 ++
2
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Ho
re and there.
>
> v4: add changelog.
> v3: use drm_dev_*().
>
> Signed-off-by: Gerd Hoffmann
Looks reasonable I think.
Reviewed-by: Daniel Vetter
I didn't review whether you need more drm_dev_enter/exit pairs, virtio is
a bit more complex for that and I have no idea how e
l.
>
> v4: add changelog.
> v3: use drm_dev*.
> v2: stop touching hardware after pci_remove().
>
> Signed-off-by: Gerd Hoffmann
I think you got them all with drm_dev_enter/exit.
Reviewed-by: Daniel Vetter
Aside: everyone ignores the return value of cirrus_fb_blit_rect and
c
: add changelog.
> v3: use drm_dev_*().
> v2: move hardware deinit to pci_remove().
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Btw I checked around whether there's anything else that obviously needs a
drm_dev_enter/exit, and I spotted the !bochs->mmio check in
t; unsigned long offset;
> - unsigned int vx, vy, vwidth;
> + unsigned int vx, vy, vwidth, idx;
> +
> + if (!drm_dev_enter(bochs->dev, &idx))
> + return;
>
> bochs->stride = stride;
> offset = (unsigned long)addr +
> @@ -2
elemcnt = 1;
>
> @@ -462,8 +467,10 @@ static void virtio_gpu_queue_cursor(struct
> virtio_gpu_device *vgdev,
> int ret;
> int outcnt;
>
> - if (!vgdev->vqs_ready)
> + if (!vgdev->vqs_ready) {
> + free_vbuf(vgdev, vbuf);
> return;
> + }
>
> sg_init_one(&ccmd, vbuf->buf, vbuf->size);
> sgs[0] = &ccmd;
> --
> 2.18.1
>
--
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
de_config_cleanup(dev);
> + drm_atomic_helper_shutdown(dev);
> iounmap(cirrus->mmio);
> + cirrus->mmio = NULL;
> iounmap(cirrus->vram);
> + cirrus->vram = NULL;
> drm_dev_put(dev);
> - kfree(cirrus);
> pci_release_regions(pdev);
> }
>
> --
> 2.18.1
>
--
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
gt; + qxl_modeset_fini(qdev);
So the drm_mode_config_cleanup call in here belongs in ->release, but the
qxl_destroy_monitors_object feels like should be perfectly fine in the
remove hook. You might need to sprinkle a few drm_dev_enter/exit around to
protect code paths thought.
Aside from this lgtm, for the s
return;
> +
> DRM_DEBUG_DRIVER("format %c%c%c%c\n",
>(format->format >> 0) & 0xff,
>(format->format >> 8) & 0xff,
> @@ -264,6 +275,9 @@ void bochs_hw_setbase(struct bochs_device *bochs,
>
On Fri, Feb 07, 2020 at 03:02:00PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.02.20 um 14:37 schrieb Daniel Vetter:
> > On Fri, Feb 07, 2020 at 09:41:31AM +0100, Thomas Zimmermann wrote:
> >> The simple-encoder helpers initialize an encoder with an empty
> >>
> + ret = -ENOMEM;
> > + goto err_devm_kfree;
> > + }
> > + }
> > +
> > + ret = __drm_encoder_init(dev, encoder,
> > +&drm_simple_encoder_funcs_destroy,
> > +
gt; +{
> + struct virtio_gpu_device *vgdev = dev->dev_private;
>
> virtio_gpu_modeset_fini(vgdev);
This calls drm_atomic_helper_shutdown, probably want that in the remove
hook? Everything else looks like it's in the right spot. So with that
call moved into the top of
On Fri, Feb 07, 2020 at 01:43:48PM +0100, Gerd Hoffmann wrote:
> Check whenever mode_config was actually properly
> initialized before trying to clean it up.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
Really need to get managed drm cleanup going ...
-Daniel
>
encoder_type, const char *name, ...);
>
> +__printf(4, 5)
> +int drm_simple_encoder_init(struct drm_device *dev,
> + struct drm_encoder *encoder,
> + int encoder_type, const char *name, ...);
> +
> +__printf(3, 4)
> +stru
qxl_ring_free(qdev->command_ring);
> - qxl_ring_free(qdev->cursor_ring);
> - qxl_ring_free(qdev->release_ring);
> qxl_gem_fini(qdev);
> qxl_bo_fini(qdev);
> + flush_work(&qdev->gc_work);
> + qxl_ring_free(qdev->command_r
evice *dev = pci_get_drvdata(pdev);
>
> - drm_atomic_helper_shutdown(dev);
> drm_dev_unregister(dev);
> - bochs_unload(dev);
> + drm_atomic_helper_shutdown(dev);
> drm_dev_put(dev);
> }
>
> --
> 2.18.1
>
--
Daniel Vetter
Software E
; (it's an event from the
compositor).
Maybe the confusion is with the helper function that generates the
fake_vblank, since it's not really a fake vblank at all, it's just "send
out this atomic completion event now, I'm not going to do it as part of
the vblank processing si
101 - 200 of 422 matches
Mail list logo
