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.h |
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
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_gem.h |
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"
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
>
> Ack
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 Andrushchenko
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
t; 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
ck,
> .update = display_update,
> };
> diff --git a/include/drm/drm_gem_atomic_helper.h
> b/include/drm/drm_gem_atomic_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 @@
>
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 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
> >>
_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
> ---
>
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
_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( 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( 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-develdata=04%7C01%7Cchristian.koenig%40amd.com%7C07bc68af3c6440b5be8d08d8740e9b32%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637386953433558595%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RlGCmjzyZERvqfnl4kA1bEHez5bkLf3F9OlKi2ybDAM%3Dreserved=0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
> > ---
>
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
Acked-by
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.
> >
> >
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
> */
>
> /**
> @@ -210,4 +228,38 @@ static inline void dma_buf_map_clear(struct dma_buf_map
> *map)
> }
> }
>
> +/**
> + * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
> + * @dst: The dma-buf mapping structure
> + * @src: The source buffer
> + * @len: The number of byte in src
> + *
> + * Copies data into a dma-buf mapping. The source buffer is in system
> + * memory. Depending on the buffer's location, the helper picks the correct
> + * method of accessing the memory.
> + */
> +static inline void dma_buf_map_memcpy_to(struct dma_buf_map *dst, const void
> *src, size_t len)
> +{
> + if (dst->is_iomem)
> + memcpy_toio(dst->vaddr_iomem, src, len);
> + else
> + memcpy(dst->vaddr, src, len);
> +}
> +
> +/**
> + * dma_buf_map_incr - Increments the address stored in a dma-buf mapping
> + * @map: The dma-buf mapping structure
> + * @incr:The number of bytes to increment
> + *
> + * Increments the address stored in a dma-buf mapping. Depending on the
> + * buffer's location, the correct value will be updated.
> + */
> +static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
> +{
> + if (map->is_iomem)
> + map->vaddr_iomem += incr;
> + else
> + map->vaddr += incr;
> +}
> +
> #endif /* __DMA_BUF_MAP_H__ */
> --
> 2.28.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 *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
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);
> -
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:
> >>>
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
> ---
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
> >>>
>
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
> > }
> >
> > +/**
> > + * 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
omas 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/virti
,
> 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(-)
ermann
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/nouveau
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
> {
> @@ -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 = _drm_gem_object_funcs;
> +
> ret = drm_gem_object_init(dev, _gem_obj->base, size);
> if (ret < 0) {
> DRM_ERROR("failed to initialize gem object\n");
> --
> 2.28.0
Reviewed-by: Daniel Vetter
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
mann
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 i
naviv_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 = _op
m_device *dev,
> unsigned long size)
> {
> @@ -143,6 +156,8 @@ static struct exynos_drm_gem *exynos_drm_gem_init(struct
> drm_device *dev,
> exynos_gem->size = size;
> obj = _gem->base;
>
> + obj->fu
hecks 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 virtio pushes a bit m
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
>
gem/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
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
sgt);
> goto put_pages;
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
> index 313339bbff90..045461dc6319 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -321,7 +321,8 @@ static struct sg_ta
; > 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
t; > *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_de
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
he 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 since no vblank". So maybe that function should be
called _send_eve
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
* drm_simple_display_pipe_funcs.check and let DRM's
> + * atomic helper fake a vblank event.
>*/
> void (*update)(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *old_plane_state);
> diff --git a/include/drm/drm_vblank.h b/inclu
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 h
rated when
> + * a job is queued to the writeback connector, and we want the core
> + * to fake VBLANK events when this part of the pipeline hasn't changed
> + * but others had or when the CRTC and connectors are being disabled.
> *
> * __drm_atomic_helper_crtc_duplicate
@@ 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);
> u64 drm_crtc_vblank_count_
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 Zimme
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 of confusion in drm).
One idea behind dr
e 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.
There's still t
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 pointe
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 for merging
ted 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/drivers/gpu/drm/
nt_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.org
Cc
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/drivers
;
> 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 long list of parameters.
M
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 (wh
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 driv
h 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 doesn't seem to
er.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
> >
ming 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 - http://blog.ffwll.c
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's
> > 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)
> > -{
> > - struct xen_gem_object *xen_obj = to_xen_gem_obj(gem_obj);
> > -
> > - if (!xen_o
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.org
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
of
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
of
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/drm/xen
->ops->calc_num_grefs(buf);
> -
> - ret = alloc_storage(buf);
> - if (ret)
> - goto fail;
> -
> - ret = grant_references(buf);
> - if (ret)
> - goto fail;
> -
> - buf->ops->fill_page_dir(buf);
> -
> - return buf;
>
a-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:
> > > > On Mon, Apr 23, 2018 at 03:10:35
> 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
Instead, we have to make all that fancy stuff
> > with VAs <-> device-X and have that device-X driver live out of drivers/xen
> > 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
> > 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
exist. But there's technically no reason to require guest-contig
memory for xen buffer sharing using grants.
With the commit message improved:
Acked-by: Daniel Vetter <daniel.vet...@ffwll.ch>
>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epa
tation/gpu/xen-zcopy.rst | 32 +
> > > drivers/gpu/drm/xen/Kconfig | 25 +
> > > drivers/gpu/drm/xen/Makefile| 5 +
> > > drivers/gpu/drm/xen/xen_drm_zcopy.c | 880
> > >
> &
I missed this one because on an older tree.
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
Cc: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com>
Cc: xen-de...@lists.xen.org
---
drivers/gpu/drm/xen/xen_drm_front_kms.c | 8 +---
1 file changed, 1 insertion(+),
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 <oleksandr_andrushche...@epam.c
ick drive-by: You can'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 115 matches
Mail list logo
