able() for details.
>
> Fortunately, here (for special Xen device) we can avoid using
> pages and calculate gfns directly from dma addresses provided by
> the sg table.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Oleksandr Tyshchenko
> Acked-by: Christian König
> Reviewed-b
iewed-by: Muchun Song
On the 5 drm patches (I counted 2 ttm and 3 drivers) for merging through
some other tree (since I'm assuming that's how this will land):
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 15 +++
> include/linux/shrinker
On Mon, Nov 08, 2021 at 11:28:46AM +0100, Thomas Zimmermann wrote:
> The hook gem_prime_mmap in struct drm_driver is deprecated. Document
> the new requirements.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 11
2 weeks here's
my:
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 13 ++-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 20 ++-
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 43 +--
> drivers/gpu/drm/exynos/exynos_drm_g
Goes through all the drivers and deletes the default hook since it's
the default now.
Acked-by: David Lechner
Acked-by: Noralf Trønnes
Acked-by: Oleksandr Andrushchenko
Acked-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes&q
On Fri, May 21, 2021 at 04:09:13PM +0200, Noralf Trønnes wrote:
>
>
> Den 21.05.2021 11.09, skrev Daniel Vetter:
> > Goes through all the drivers and deletes the default hook since it's
> > the default now.
> >
> > Signed-off-by: Daniel Vetter
>
>
Goes through all the drivers and deletes the default hook since it's
the default now.
Signed-off-by: Daniel Vetter
Cc: Joel Stanley
Cc: Andrew Jeffery
Cc: "Noralf Trønnes"
Cc: Linus Walleij
Cc: Emma Anholt
Cc: David Lechner
Cc: Kamlesh Gurudasani
Cc: Oleksandr Andrushche
On Thu, Mar 25, 2021 at 10:16 AM Daniel Vetter wrote:
>
> On Thu, Mar 25, 2021 at 7:53 AM Oleksandr Andrushchenko
> wrote:
> >
> > Hi,
> >
> > On 3/25/21 8:19 AM, Wan Jiabing wrote:
> > > struct xen_drm_front_drm_info has been declared.
> > > R
vers/gpu/drm/xen/xen_drm_front_conn.h
> > @@ -16,7 +16,6 @@
> > struct drm_connector;
> > struct xen_drm_front_drm_info;
> >
> > -struct xen_drm_front_drm_info;
> >
> > int xen_drm_front_conn_init(struct xen_drm_front_drm_info *drm_info,
> > struct drm_connector *connector);
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
lect DRM_XEN
> > select DRM_KMS_HELPER
> > select VIDEOMODE_HELPERS
> > select XEN_XENBUS_FRONTEND
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
helper.h
> index 08b96ccea325..91e73d23fea8 100644
> --- a/include/drm/drm_gem_atomic_helper.h
> +++ b/include/drm/drm_gem_atomic_helper.h
> @@ -9,6 +9,14 @@
>
> struct drm_simple_display_pipe;
>
> +/*
> + * Plane Helpers
> + */
> +
> +int drm_gem_prepare_fb(struct drm_plane *plane, struct drm_plane_state
> *state);
> +int drm_gem_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe
> *pipe,
> +struct drm_plane_state *plane_state);
> +
> /*
> * Helpers for planes with shadow buffers
> */
> diff --git a/include/drm/drm_gem_framebuffer_helper.h
> b/include/drm/drm_gem_framebuffer_helper.h
> index 6b013154911d..495d174d9989 100644
> --- a/include/drm/drm_gem_framebuffer_helper.h
> +++ b/include/drm/drm_gem_framebuffer_helper.h
> @@ -9,9 +9,11 @@ struct drm_framebuffer;
> struct drm_framebuffer_funcs;
> struct drm_gem_object;
> struct drm_mode_fb_cmd2;
> +#if 0
> struct drm_plane;
> struct drm_plane_state;
> struct drm_simple_display_pipe;
> +#endif
>
> #define AFBC_VENDOR_AND_TYPE_MASKGENMASK_ULL(63, 52)
>
> @@ -44,8 +46,4 @@ int drm_gem_fb_afbc_init(struct drm_device *dev,
>const struct drm_mode_fb_cmd2 *mode_cmd,
>struct drm_afbc_framebuffer *afbc_fb);
>
> -int drm_gem_fb_prepare_fb(struct drm_plane *plane,
> - struct drm_plane_state *state);
> -int drm_gem_fb_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe
> *pipe,
> - struct drm_plane_state
> *plane_state);
> #endif
> diff --git a/include/drm/drm_modeset_helper_vtables.h
> b/include/drm/drm_modeset_helper_vtables.h
> index eb706342861d..8d41d3734153 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -1179,7 +1179,7 @@ struct drm_plane_helper_funcs {
>* members in the plane structure.
>*
>* Drivers which always have their buffers pinned should use
> - * drm_gem_fb_prepare_fb() for this hook.
> + * drm_gem_prepare_fb() for this hook.
>*
>* The helpers will call @cleanup_fb with matching arguments for every
>* successful call to this hook.
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 95ab14a4336a..be08b6b1fde0 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -79,8 +79,8 @@ struct drm_plane_state {
>* preserved.
>*
>* Drivers should store any implicit fence in this from their
> - * &drm_plane_helper_funcs.prepare_fb callback. See
> drm_gem_fb_prepare_fb()
> - * and drm_gem_fb_simple_display_pipe_prepare_fb() for suitable helpers.
> + * &drm_plane_helper_funcs.prepare_fb callback. See drm_gem_prepare_fb()
> + * and drm_gem_simple_display_pipe_prepare_fb() for suitable helpers.
>*/
> struct dma_fence *fence;
>
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index 40b34573249f..ef9944e9c5fc 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -117,7 +117,7 @@ struct drm_simple_display_pipe_funcs {
>* more details.
>*
>* Drivers which always have their buffers pinned should use
> - * drm_gem_fb_simple_display_pipe_prepare_fb() for this hook.
> + * drm_gem_simple_display_pipe_prepare_fb() for this hook.
>*/
> int (*prepare_fb)(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *plane_state);
> --
> 2.30.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ightmare. And when an oops happens, 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 the only
real solution if you care about performance in that case is to use kms
natively, and use a dirty rectangle flip (or the DIRTY syscall).
And in there drivers should (and do) use any dma engines they have to
upload the frames already.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 fd1aba545fdf..2e8bbecb5091 100644
> > > > --- a/include/linux/dma-buf-map.h
> > > > +++ b/include/linux/dma-buf-map.h
> > > > @@ -45,6 +45,12 @@
> > > > *
> > > > * dma_buf_map_set_vaddr(&map. 0xdeadbeaf);
> > > > *
> > > > + * To set an address in I/O memory, use dma_buf_map_set_vaddr_iomem().
> > > > + *
> > > > + * .. code-block:: c
> > > > + *
> > > > + * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf);
> > > > + *
> > > > * Test if a mapping is valid with either dma_buf_map_is_set() or
> > > > * dma_buf_map_is_null().
> > > > *
> > > > @@ -118,6 +124,20 @@ static inline void dma_buf_map_set_vaddr(struct
> > > > dma_buf_map *map, void *vaddr)
> > > > 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
> > > > + *
> > > > + * Sets the address and the I/O-memory flag.
> > > > + */
> > > > +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_map *map,
> > > > + void __iomem *vaddr_iomem)
> > > > +{
> > > > + map->vaddr_iomem = vaddr_iomem;
> > > > + map->is_iomem = true;
> > > > +}
> > > > +
> > > > /**
> > > > * dma_buf_map_is_equal - Compares two dma-buf mapping structures
> > > > for equality
> > > > * @lhs: The dma-buf mapping structure
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel&data=04%7C01%7Cchristian.koenig%40amd.com%7C07bc68af3c6440b5be8d08d8740e9b32%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637386953433558595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RlGCmjzyZERvqfnl4kA1bEHez5bkLf3F9OlKi2ybDAM%3D&reserved=0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 Fri, Oct 09, 2020 at 12:49:44PM -0700, ira.we...@intel.com wrote:
> From: Ira Weiny
>
> These kmap() calls in the gpu stack are localized to a single thread.
> To avoid the over head of global PKRS updates use the new kmap_thread()
> call.
>
> Cc: David Airlie
>
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 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
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
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;
> + struct dma_buf_map map;
>
> /**
>* @fb: DRM framebuffer
> @@ -155,7 +156,7 @@ struct drm_client_buffer *
> drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32
> height, u32 format);
> void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
> int drm_client_framebuffer_flush(struct drm_client_buffer *buffer, struct
> drm_rect *rect);
> -void *drm_client_buffer_vmap(struct drm_client_buffer *buffer);
> +int drm_client_buffer_vmap(struct drm_client_buffer *buffer, struct
> dma_buf_map *map);
> void drm_client_buffer_vunmap(struct drm_client_buffer *buffer);
>
> int drm_client_modeset_create(struct drm_client_dev *client);
Reviewed-by: Daniel Vetter
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
> ---
merge cycle. To avoid
upsetting sfr from linux-next we keep those -next branches out of
linux-next until after -rc1 again. iow, rebasing onto linux-next and
smashing this into 5.10 sounds like the right approach (since everyone
else freezes a bunch later afaik).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
> > + *
> > + * Sets the address and the I/O-memory flag.
> > + */
> > +static inline void dma_buf_map_set_vaddr_iomem(struct dma_buf_map *map,
> > +void __iomem *vaddr_iomem)
> > +{
> > + map->vaddr_iomem = vaddr_iomem;
> > + map->is_iomem = true;
> > +}
> > +
> > /**
> >* dma_buf_map_is_equal - Compares two dma-buf mapping structures for
> > equality
> >* @lhs:The dma-buf mapping structure
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ate related TODO item (Sam)
>
> Signed-off-by: Thomas Zimmermann
Nice work!
Acked-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 7 +--
> drivers/gpu/drm/drm_gem.c| 35 +++-
> drivers/gpu/drm/drm_gem_cma_helper.c | 6 +-
> dri
y: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.c| 1 -
> drivers/gpu/drm/virtio/virtgpu_object.c | 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c
> b/drivers/gpu/drm/
gt; which is non-trivial to convert.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 5 -
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 10 ++
> 2 files changed, 10 insertions(+), 5 deletions(-)
nn
Hm ttm and gem mmap world still quite disjoint ... Anyway that's an
entirely different thing.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 9 -
> drivers/gpu/drm/nouveau/nouveau_gem.c | 13 +
> drivers/gpu/drm/nouveau/no
which is non-trivial to convert.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/msm/msm_drv.c | 13 -
> drivers/gpu/drm/msm/msm_drv.h | 1 -
> drivers/gpu/drm/msm/msm_gem.c | 19 ++-
> 3 files change
d long size)
> {
> @@ -25,6 +34,8 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct
> drm_device *dev,
> if (!mtk_gem_obj)
> return ERR_PTR(-ENOMEM);
>
> + mtk_gem_obj->base.funcs = &mtk_drm_gem_object_funcs;
> +
> ret
n
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/gma500/framebuffer.c | 2 ++
> drivers/gpu/drm/gma500/gem.c | 18 --
> drivers/gpu/drm/gma500/gem.h | 3 +++
> drivers/gpu/drm/gma500/psb_drv.c | 9 -
> drivers/gpu/drm/gma500
On Wed, Sep 16, 2020 at 12:36:28PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 16.09.20 um 12:03 schrieb Daniel Vetter:
> > On Tue, Sep 15, 2020 at 04:59:41PM +0200, Thomas Zimmermann wrote:
> >> GEM object functions deprecate several similar callback interfaces in
>
> + .free = etnaviv_gem_free_object,
> + .pin = etnaviv_gem_prime_pin,
> + .unpin = etnaviv_gem_prime_unpin,
> + .get_sg_table = etnaviv_gem_prime_get_sg_table,
> + .vmap = etnaviv_gem_prime_vmap,
> + .vunmap = etnaviv_gem_prime_vunmap,
> + .vm_ops
+};
Hm moving the drm_gem_cma_vm_ops into drm_gem.h or so and maybe calling
them drm_gem_simple_ops or so would remove a pile of these. But perhaps a
quick follow up series.
Reviewed-by: Daniel Vetter
> +
> +static const struct drm_gem_object_funcs exynos_drm_gem_object_funcs =
virtio_has_dma_quirk() checks isn't going to fly.
>
> Using dma_max_mapping_size() should be fine though. It might use a
> lower limit than needed for virtio, but it should not break things.
Makes sense. On this patch here:
Reviewed-by: Daniel Vetter
And I guess would be good if
On Tue, Sep 08, 2020 at 07:48:58AM +0200, Gerd Hoffmann wrote:
> On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote:
> > On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote:
> > >
> > > Add drm_device argument to drm_prime_pages_to_sg(), so we can
> >
vers/gpu/drm/vgem/vgem_drv.c
> @@ -321,7 +321,7 @@ static struct sg_table *vgem_prime_get_sg_table(struct
> drm_gem_object *obj)
> {
> struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
>
> - return drm_prime_pages_to_sg(bo->pages, bo->base.size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(obj->dev, bo->pages, bo->base.size >>
> PAGE_SHIFT);
> }
>
> static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> index 39ff95b75357..aed7510e2710 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> @@ -179,7 +179,8 @@ struct sg_table *xen_drm_front_gem_get_sg_table(struct
> drm_gem_object *gem_obj)
> if (!xen_obj->pages)
> return ERR_PTR(-ENOMEM);
>
> - return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
> + return drm_prime_pages_to_sg(gem_obj->dev,
> +xen_obj->pages, xen_obj->num_pages);
> }
>
> struct drm_gem_object *
> --
> 2.27.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
information */
> + struct drm_vma_offset_manager *vma_offset_manager;
> +
> + /**
> +* @max_segment:
> +*
> +* Max size for scatter list segments for GEM objects. When
> + * unset the default (SCATTERLIST_MAX_SEGMENT) is used.
> +*/
> + size_t max_segment;
> +};
> +
> struct drm_gem_object;
>
> /**
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+321,8 @@ static struct sg_table *vgem_prime_get_sg_table(struct
> drm_gem_object *obj)
> {
> struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
>
> - return drm_prime_pages_to_sg(bo->pages, bo->base.size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(bo->pages, bo->base.size >> PAGE_SHIFT,
> + obj->dev->max_segment);
> }
>
> static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> index f0b85e094111..61a8c1a9fb04 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
> @@ -179,7 +179,8 @@ struct sg_table *xen_drm_front_gem_get_sg_table(struct
> drm_gem_object *gem_obj)
> if (!xen_obj->pages)
> return ERR_PTR(-ENOMEM);
>
> - return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages);
> + return drm_prime_pages_to_sg(xen_obj->pages, xen_obj->num_pages,
> + gem_obj->dev->max_segment);
> }
>
> struct drm_gem_object *
> --
> 2.18.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; > So please just select ZONE_DEVICE if this is so much better rather
> > than maintaining two variants.
>
> We still need to other variant for Arm at least, so both need to be
> maintained anyway, even if we force ZONE_DEVICE on x86.
Why does arm not have ZONE_DEVICE?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
m_file
> > *filp,
> > obj = xen_drm_front_gem_create(dev, args->size);
> > if (IS_ERR_OR_NULL(obj)) {
> > - ret = PTR_ERR(obj);
> > + ret = PTR_ERR_OR_ZERO(obj);
> > goto fail;
> > }
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
@lists.xenproject.org
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
---
drivers/gpu/drm/drm_drv.c | 3 +++
drivers/gpu/drm/xen/xen_drm_front.c | 2
On Sat, Mar 07, 2020 at 09:06:08AM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:25:44PM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put in the failure path. Fix that up too.
>
>
Author: Gerd Hoffmann
Date: Tue Feb 11 14:58:04 2020 +0100
drm/virtio: add drm_driver.release callback.
Cc: Gerd Hoffmann
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime
Author: Gerd Hoffmann
Date: Tue Feb 11 14:58:04 2020 +0100
drm/virtio: add drm_driver.release callback.
Cc: Gerd Hoffmann
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime
Author: Gerd Hoffmann
Date: Tue Feb 11 14:58:04 2020 +0100
drm/virtio: add drm_driver.release callback.
Cc: Gerd Hoffmann
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime
On Wed, Feb 19, 2020 at 03:41:07PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 2:39 PM Laurent Pinchart
> wrote:
> >
> > Hi Daniel,
> >
> > Thank you for the patch.
> >
> > On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> >
On Wed, Feb 19, 2020 at 2:39 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Wed, Feb 19, 2020 at 11:20:34AM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put
Author: Gerd Hoffmann
Date: Tue Feb 11 14:58:04 2020 +0100
drm/virtio: add drm_driver.release callback.
Cc: Gerd Hoffmann
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David
; (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
le automatic vblank events explictly.
>
> v4:
> * separate commit from core vblank changes
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
On all the driver patches:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 13
re lacks vblank support entirely,
> + * drivers can set &struct drm_crtc_state.no_vblank in
> + * &struct drm_simple_display_pipe_funcs.check and let DRM's
> + * atomic helper fake a vblank event.
>*/
> void (*update)(struct drm_sim
On Wed, Jan 22, 2020 at 09:53:42AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 22.01.20 um 09:31 schrieb Daniel Vetter:
> > On Mon, Jan 20, 2020 at 01:20:48PM +0100, Thomas Zimmermann wrote:
> >> The new interface drm_crtc_has_vblank() return true if vblanking has
>
*
> + * Another usage is CRTCs feeding a writeback connector operating in
> + * oneshot mode. In this case the VBLANK event is only generated when
> + * a job is queued to the writeback connector, and we want the core
> + * to fake VBLANK events when this
blank.h
> @@ -206,6 +206,7 @@ struct drm_vblank_crtc {
> };
>
> int drm_vblank_init(struct drm_device *dev, unsigned int num_crtcs);
> +bool drm_crtc_has_vblank(const struct drm_crtc *crtc);
> u64 drm_crtc_vblank_count(struct drm_crtc *crtc);
&g
On Fri, Jan 17, 2020 at 08:17:10AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 17.01.20 um 00:59 schrieb Daniel Vetter:
> > On Thu, Jan 16, 2020 at 05:22:34PM +, Emil Velikov wrote:
> >> Hi all,
> >>
> >> On Thu, 16 Jan 2020 at 07:37, Thomas Zimmerm
) specific to simple pipe helpers feels kinda
wrong. Simple pipe tends to have a higher ratio of drivers for hw without
vblank support, but by far not the only ones. Having that special case
feels confusing to me (and likely will trip up some people, vblank and
event handling is already a huge source o
efault value to some other/better place in the atomic
helpers, not sure what the best one is.
Plus then in the documentation patch also highlight the link between
crtc_state->no_vblank and drm_dev_has_vblank respectively
drm_device.num_crtcs.
That should plug this issue once for all across the board.
On Fri, Nov 15, 2019 at 10:33:24AM +, Oleksandr Andrushchenko wrote:
> On 11/15/19 11:21 AM, Daniel Vetter wrote:
> > The current code is a pretty good wtf moment, since we drop the
> > reference before we use it. It's not a big deal, because a) we only
> > use the p
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
--
Ack f
7;t of complicated games that
baffle.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b/d
en_drm_front_kms.c
> > @@ -45,7 +45,7 @@ static void fb_destroy(struct drm_framebuffer *fb)
> > drm_gem_fb_destroy(fb);
> > }
> > -static struct drm_framebuffer_funcs fb_funcs = {
> > +static const struct drm_framebuffer_funcs fb_funcs = {
> > .destroy = fb_destroy,
>
Split out to make the functional changes stick out more.
v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE.
v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE.
v4: Don't add a space in i915_drv.c (Sam)
Cc: Sam Ravnborg
Reviewed-by: Eric Anholt
Signed-off-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.o
Split out to make the functional changes stick out more.
v2: amdgpu gained DRIVER_SYNCOBJ_TIMELINE.
v3: amdgpu lost DRIVER_SYNCOBJ_TIMELINE.
Signed-off-by: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: etna...@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: intel
They're the default.
Aside: Would be really nice to switch the others over to
drm_gem_object_funcs.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-devel@lists.xenproject.org
---
drivers/gpu/drm/xen/xen_drm_front.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/dr
fault value.
>
> I'm actually perfectly fine going down any route, but this just seemed to me
> simplest and with the least risk of breaking anything. Opinions?
I think given all our discussions and plans the argument object makes tons
of sense. Much easier to document well than a l
On Thu, Jan 24, 2019 at 10:46:47AM +0100, Daniel Vetter wrote:
> On Wed, Jan 23, 2019 at 06:00:15PM +0100, Sam Ravnborg wrote:
> > Hi Daniel.
> >
> > On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> > > Having the probe helper stuff (which pretty muc
On Wed, Jan 23, 2019 at 06:00:15PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Thu, Jan 17, 2019 at 10:03:34PM +0100, Daniel Vetter wrote:
> > Having the probe helper stuff (which pretty much everyone needs) in
> > the drm_crtc_helper.h file (which atomic drivers
eah in the process of splitting up drmP.h we've created a few smaller
such piles of headers. I think in some cases it's just not going to be
worth it to fully split them up, e.g. drm_crtc_helper.h is going to be
a pure legacy helper, only needed by pre-atomic drivers. Splitting
that up
_helper.h| 27 +++
> This on the other hand is fine - as expected as this is a new file.
>
> But the above is just some random comments so:
>
> Acked-by: Sam Ravnborg
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
On Thu, Dec 20, 2018 at 7:33 PM Christoph Hellwig wrote:
>
> On Thu, Dec 20, 2018 at 07:29:37PM +0100, Daniel Vetter wrote:
> > What we most definitely not want to end up with though is actually
> > streaming dma, because with that all the zero copy buffer sharing
> >
ally
streaming dma, because with that all the zero copy buffer sharing
tricks become pointless. There's pretty epic amounts of hacks to work
around this, I have no idea what's supposed to give here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
On Fri, Dec 14, 2018 at 09:09:45AM +0200, Oleksandr Andrushchenko wrote:
> On 12/13/18 5:48 PM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
> > > Daniel, could you please comment?
> > Cross-revieweing someone else&#x
8,6 @@ struct page **xen_drm_front_gem_get_pages(struct
> > drm_gem_object *gem_obj)
> > return xen_obj->pages;
> > }
> > -struct sg_table *xen_drm_front_gem_get_sg_table(struct drm_gem_object
> > *gem_obj)
> >
On Mon, Dec 10, 2018 at 12:12:05PM +0200, Oleksandr Andrushchenko wrote:
> On 12/10/18 12:03 PM, Daniel Vetter wrote:
> > Doesn't do anything for atomic.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Oleksandr Andrushchenko
> > Cc: xen-de...@lists.xen
On Mon, Dec 10, 2018 at 02:40:25PM +0100, Benjamin Gaignard wrote:
> Le lun. 10 déc. 2018 à 12:10, Benjamin Gaignard
> a écrit :
> >
> > Le lun. 10 déc. 2018 à 11:24, Thierry Reding
> > a écrit :
> > >
> > > On Mon, Dec 10, 2018 at 11:11:33AM +0100, Dan
drm_crtc_helper.h includes.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: etna...@lists.freedesktop.org
Cc: linux-samsung-...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo
drm_crtc_helper.h includes.
Signed-off-by: Daniel Vetter
Cc: linux-arm-ker...@lists.infradead.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: etna...@lists.freedesktop.org
Cc: linux-samsung-...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: linux-media...@lists.infradead.org
Cc: linux-amlo
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_conn.c
b/drivers/gpu/dr
; -
> - ret = alloc_storage(buf);
> - if (ret)
> - goto fail;
> -
> - ret = grant_references(buf);
> - if (ret)
> - goto fail;
> -
> - buf->ops->fill_page_dir(buf);
> -
> - return buf;
> -
> -fail:
> -
ned. That's a hard constraint of the linux
dma-buf interface spec.
-Daniel
> > thanks,
> > DW
> Thank you,
> Oleksandr
> > On Tue, Apr 24, 2018 at 02:59:39PM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/24/2018 02:54 PM, Daniel Vetter wrote:
&g
rivers do).
-Daniel
>
> Balloon driver extension, which is needed for contiguous/DMA
> buffers, will be to provide new *kernel API*, no UAPI is needed.
>
> > Wei.
> Thank you,
> Oleksandr
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
t; as it is not a Xen specific driver?
>
> That would be my preference if feasible, simply because it can be
> reused by other use-cases that need to create dma-bufs in user-space.
>
> In any case I just knew about dma-bufs this morning, there might be
> things that I'm missin
> > On 04/17/2018 11:57 PM, Dongwon Kim wrote:
> > > > > On Tue, Apr 17, 2018 at 09:59:28AM +0200, Daniel Vetter wrote:
> > > > > > On Mon, Apr 16, 2018 at 12:29:05PM -0700, Dongwon Kim wrote:
> > > > 3.2 Backend exports dma-buf to xen-front
> &g
to require guest-contig
memory for xen buffer sharing using grants.
With the commit message improved:
Acked-by: Daniel Vetter
>
> Signed-off-by: Oleksandr Andrushchenko
> Suggested-by: Daniel Vetter
> ---
> Documentation/gpu/xen-front.rst | 12
>
t; > >
> > > Documentation/gpu/drivers.rst | 1 +
> > > Documentation/gpu/xen-zcopy.rst | 32 +
> > > drivers/gpu/drm/xen/Kconfig | 25 +
> > > drivers/gpu/drm/xen/Makefile| 5 +
> > > drivers/gpu/drm/xen/xen_dr
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter
Cc: Oleksandr Andrushchenko
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
b
On Fri, Apr 06, 2018 at 02:25:08PM +0300, Oleksandr Andrushchenko wrote:
> On 04/03/2018 12:47 PM, Daniel Vetter wrote:
> > On Thu, Mar 29, 2018 at 04:19:31PM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko
> > > +static int to_refs_
't assume that an sgt is struct page backed.
And you probably want to check this at import/attach time.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
1 - 100 of 118 matches
Mail list logo
