From: Thomas Zimmermann <tzimmermann@suse.de>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: luben.tuikov@amd.com, airlied@linux.ie,
nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
chris@chris-wilson.co.uk, melissa.srw@gmail.com,
ray.huang@amd.com, kraxel@redhat.com, emil.velikov@collabora.com,
linux-samsung-soc@vger.kernel.org, jy0922.shim@samsung.com,
lima@lists.freedesktop.org, oleksandr_andrushchenko@epam.com,
krzk@kernel.org, steven.price@arm.com,
linux-rockchip@lists.infradead.org, kgene@kernel.org,
alyssa.rosenzweig@collabora.com, linux+etnaviv@armlinux.org.uk,
spice-devel@lists.freedesktop.org, bskeggs@redhat.com,
etnaviv@lists.freedesktop.org, hdegoede@redhat.com,
xen-devel@lists.xenproject.org,
virtualization@lists.linux-foundation.org, sean@poorly.run,
apaneers@amd.com, linux-arm-kernel@lists.infradead.org,
linaro-mm-sig@lists.linaro.org, amd-gfx@lists.freedesktop.org,
tomeu.vizoso@collabora.com, sw0312.kim@samsung.com,
hjc@rock-chips.com, kyungmin.park@samsung.com,
miaoqinglang@huawei.com, yuq825@gmail.com,
alexander.deucher@amd.com, linux-media@vger.kernel.org,
christian.koenig@amd.com
Subject: Re: [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces
Date: Fri, 16 Oct 2020 12:39:31 +0200 [thread overview]
Message-ID: <20201016123931.10dd3930@linux-uq9g> (raw)
In-Reply-To: <20201016100854.GA1042954@ravnborg.org>
Hi Sam
On Fri, 16 Oct 2020 12:08:54 +0200 Sam Ravnborg <sam@ravnborg.org> wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> > To do framebuffer updates, one needs memcpy from system memory and a
> > pointer-increment function. Add both interfaces with documentation.
> >
> > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Looks good.
> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Thanks. If you have the time, may I ask you to test this patchset on the
bochs/sparc64 system that failed with the original code?
Best regards
Thomas
>
> > ---
> > include/linux/dma-buf-map.h | 72 +++++++++++++++++++++++++++++++------
> > 1 file changed, 62 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> > index 2e8bbecb5091..6ca0f304dda2 100644
> > --- a/include/linux/dma-buf-map.h
> > +++ b/include/linux/dma-buf-map.h
> > @@ -32,6 +32,14 @@
> > * accessing the buffer. Use the returned instance and the helper
> > functions
> > * to access the buffer's memory in the correct way.
> > *
> > + * The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers
> > are
> > + * actually independent from the dma-buf infrastructure. When sharing
> > buffers
> > + * among devices, drivers have to know the location of the memory to
> > access
> > + * the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
> > + * solves this problem for dma-buf and its users. If other drivers or
> > + * sub-systems require similar functionality, the type could be
> > generalized
> > + * and moved to a more prominent header file.
> > + *
> > * Open-coding access to :c:type:`struct dma_buf_map <dma_buf_map>` is
> > * considered bad style. Rather then accessing its fields directly, use
> > one
> > * of the provided helper functions, or implement your own. For example,
> > @@ -51,6 +59,14 @@
> > *
> > * dma_buf_map_set_vaddr_iomem(&map. 0xdeadbeaf);
> > *
> > + * Instances of struct dma_buf_map do not have to be cleaned up, but
> > + * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
> > + * always refer to system memory.
> > + *
> > + * .. code-block:: c
> > + *
> > + * dma_buf_map_clear(&map);
> > + *
> > * Test if a mapping is valid with either dma_buf_map_is_set() or
> > * dma_buf_map_is_null().
> > *
> > @@ -73,17 +89,19 @@
> > * if (dma_buf_map_is_equal(&sys_map, &io_map))
> > * // always false
> > *
> > - * Instances of struct dma_buf_map do not have to be cleaned up, but
> > - * can be cleared to NULL with dma_buf_map_clear(). Cleared mappings
> > - * always refer to system memory.
> > + * A set up instance of struct dma_buf_map can be used to access or
> > manipulate
> > + * the buffer memory. Depending on the location of the memory, the
> > provided
> > + * helpers will pick the correct operations. Data can be copied into the
> > memory
> > + * with dma_buf_map_memcpy_to(). The address can be manipulated with
> > + * dma_buf_map_incr().
> > *
> > - * The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers
> > are
> > - * actually independent from the dma-buf infrastructure. When sharing
> > buffers
> > - * among devices, drivers have to know the location of the memory to
> > access
> > - * the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
> > - * solves this problem for dma-buf and its users. If other drivers or
> > - * sub-systems require similar functionality, 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);
> > + * dma_buf_map_incr(&map, 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
next prev parent reply other threads:[~2020-10-16 10:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-15 12:37 [PATCH v4 00/10] Support GEM object mappings from I/O memory Thomas Zimmermann
2020-10-15 12:37 ` [PATCH v4 01/10] drm/vram-helper: Remove invariant parameters from internal kmap function Thomas Zimmermann
2020-10-15 13:57 ` Christian König
2020-10-15 12:37 ` [PATCH v4 02/10] drm/cma-helper: Remove empty drm_gem_cma_prime_vunmap() Thomas Zimmermann
2020-10-15 13:58 ` Christian König
2020-10-15 12:37 ` [PATCH v4 03/10] drm/etnaviv: Remove empty etnaviv_gem_prime_vunmap() Thomas Zimmermann
2020-10-15 13:59 ` Christian König
2020-10-15 12:38 ` [PATCH v4 04/10] drm/exynos: Remove empty exynos_drm_gem_prime_{vmap,vunmap}() Thomas Zimmermann
2020-10-15 14:00 ` Christian König
2020-10-15 12:38 ` [PATCH v4 05/10] drm/ttm: Add vmap/vunmap to TTM and TTM GEM helpers Thomas Zimmermann
2020-10-15 14:08 ` Christian König
2020-10-15 16:49 ` Daniel Vetter
2020-10-15 17:52 ` Thomas Zimmermann
2020-10-16 9:41 ` Christian König
2020-10-15 17:56 ` Thomas Zimmermann
2020-10-19 9:08 ` Thomas Zimmermann
2020-10-19 9:45 ` Christian König
2020-10-19 15:46 ` Daniel Vetter
2020-10-15 12:38 ` [PATCH v4 06/10] drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends Thomas Zimmermann
2020-10-15 14:21 ` Christian König
2020-10-15 12:38 ` [PATCH v4 07/10] drm/gem: Update internal GEM vmap/vunmap interfaces to use struct dma_buf_map Thomas Zimmermann
2020-10-15 12:38 ` [PATCH v4 08/10] drm/gem: Store client buffer mappings as " Thomas Zimmermann
2020-10-15 12:38 ` [PATCH v4 09/10] dma-buf-map: Add memcpy and pointer-increment interfaces Thomas Zimmermann
2020-10-16 10:08 ` Sam Ravnborg
2020-10-16 10:39 ` Thomas Zimmermann [this message]
2020-10-16 11:31 ` Sam Ravnborg
2020-10-15 12:38 ` [PATCH v4 10/10] drm/fb_helper: Support framebuffers in I/O memory Thomas Zimmermann
2020-10-16 10:58 ` Sam Ravnborg
2020-10-16 11:34 ` Thomas Zimmermann
2020-10-16 12:03 ` Sam Ravnborg
2020-10-16 12:19 ` Thomas Zimmermann
2020-10-16 12:48 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201016123931.10dd3930@linux-uq9g \
--to=tzimmermann@suse.de \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=alyssa.rosenzweig@collabora.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=apaneers@amd.com \
--cc=bskeggs@redhat.com \
--cc=chris@chris-wilson.co.uk \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.velikov@collabora.com \
--cc=etnaviv@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=hjc@rock-chips.com \
--cc=jy0922.shim@samsung.com \
--cc=kgene@kernel.org \
--cc=kraxel@redhat.com \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=lima@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=luben.tuikov@amd.com \
--cc=melissa.srw@gmail.com \
--cc=miaoqinglang@huawei.com \
--cc=nouveau@lists.freedesktop.org \
--cc=oleksandr_andrushchenko@epam.com \
--cc=ray.huang@amd.com \
--cc=sam@ravnborg.org \
--cc=sean@poorly.run \
--cc=spice-devel@lists.freedesktop.org \
--cc=steven.price@arm.com \
--cc=sw0312.kim@samsung.com \
--cc=tomeu.vizoso@collabora.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xenproject.org \
--cc=yuq825@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).