lkml.org 
[lkml]   [2022]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/19] dma-buf-map: Add read/write helpers
On Thu, Jan 27, 2022 at 03:26:43PM +0100, Thomas Zimmermann wrote:
>Hi
>
>Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
>>In certain situations it's useful to be able to read or write to an
>>offset that is calculated by having the memory layout given by a struct
>>declaration. Usually we are going to read/write a u8, u16, u32 or u64.
>>
>>Add a pair of macros dma_buf_map_read_field()/dma_buf_map_write_field()
>>to calculate the offset of a struct member and memcpy the data from/to
>>the dma_buf_map. We could use readb, readw, readl, readq and the write*
>>counterparts, however due to alignment issues this may not work on all
>>architectures. If alignment needs to be checked to call the right
>>function, it's not possible to decide at compile-time which function to
>>call: so just leave the decision to the memcpy function that will do
>>exactly that on IO memory or dereference the pointer.
>>
>>Cc: Sumit Semwal <sumit.semwal@linaro.org>
>>Cc: Christian König <christian.koenig@amd.com>
>>Cc: linux-media@vger.kernel.org
>>Cc: dri-devel@lists.freedesktop.org
>>Cc: linaro-mm-sig@lists.linaro.org
>>Cc: linux-kernel@vger.kernel.org
>>Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>>---
>> include/linux/dma-buf-map.h | 81 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 81 insertions(+)
>>
>>diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
>>index 19fa0b5ae5ec..65e927d9ce33 100644
>>--- a/include/linux/dma-buf-map.h
>>+++ b/include/linux/dma-buf-map.h
>>@@ -6,6 +6,7 @@
>> #ifndef __DMA_BUF_MAP_H__
>> #define __DMA_BUF_MAP_H__
>>+#include <linux/kernel.h>
>> #include <linux/io.h>
>> #include <linux/string.h>
>>@@ -229,6 +230,46 @@ static inline void dma_buf_map_clear(struct dma_buf_map *map)
>> }
>> }
>>+/**
>>+ * dma_buf_map_memcpy_to_offset - Memcpy into offset of dma-buf mapping
>>+ * @dst: The dma-buf mapping structure
>>+ * @offset: The offset from which to copy
>>+ * @src: The source buffer
>>+ * @len: The number of byte in src
>>+ *
>>+ * Copies data into a dma-buf mapping with an offset. 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_offset(struct dma_buf_map *dst, size_t offset,
>>+ const void *src, size_t len)
>>+{
>>+ if (dst->is_iomem)
>>+ memcpy_toio(dst->vaddr_iomem + offset, src, len);
>>+ else
>>+ memcpy(dst->vaddr + offset, src, len);
>>+}
>
>Please don't add a new function. Rather please add the offset
>parameter to dma_buf_map_memcpy_to() and update the callers. There are
>only two calls to dma_buf_map_memcpy_to() within the kernel. To make
>it clear what the offset applies to, I'd call the parameter
>'dst_offset'.
>
>>+
>>+/**
>>+ * dma_buf_map_memcpy_from_offset - Memcpy from offset of dma-buf mapping into system memory
>>+ * @dst: Destination in system memory
>>+ * @src: The dma-buf mapping structure
>>+ * @src: The offset from which to copy
>>+ * @len: The number of byte in src
>>+ *
>>+ * Copies data from a dma-buf mapping with an offset. The dest buffer is in
>>+ * system memory. Depending on the mapping location, the helper picks the
>>+ * correct method of accessing the memory.
>>+ */
>>+static inline void dma_buf_map_memcpy_from_offset(void *dst, const struct dma_buf_map *src,
>>+ size_t offset, size_t len)
>>+{
>>+ if (src->is_iomem)
>>+ memcpy_fromio(dst, src->vaddr_iomem + offset, len);
>>+ else
>>+ memcpy(dst, src->vaddr + offset, len);
>>+}
>>+
>
>With the dma_buf_map_memcpy_to() changes, please just call this
>function dma_buf_map_memcpy_from().
>
>> /**
>> * dma_buf_map_memcpy_to - Memcpy into dma-buf mapping
>> * @dst: The dma-buf mapping structure
>>@@ -263,4 +304,44 @@ static inline void dma_buf_map_incr(struct dma_buf_map *map, size_t incr)
>> map->vaddr += incr;
>> }
>>+/**
>>+ * dma_buf_map_read_field - Read struct member from dma-buf mapping with
>>+ * arbitrary size and handling un-aligned accesses
>>+ *
>>+ * @map__: The dma-buf mapping structure
>>+ * @type__: The struct to be used containing the field to read
>>+ * @field__: Member from struct we want to read
>>+ *
>>+ * Read a value from dma-buf mapping calculating the offset and size: this assumes
>>+ * the dma-buf mapping is aligned with a a struct type__. A single u8, u16, u32
>>+ * or u64 can be read, based on the offset and size of type__.field__.
>>+ */
>>+#define dma_buf_map_read_field(map__, type__, field__) ({ \
>>+ type__ *t__; \
>>+ typeof(t__->field__) val__; \
>>+ dma_buf_map_memcpy_from_offset(&val__, map__, offsetof(type__, field__), \
>>+ sizeof(t__->field__)); \
>>+ val__; \
>>+})
>>+
>>+/**
>>+ * dma_buf_map_write_field - Write struct member to the dma-buf mapping with
>>+ * arbitrary size and handling un-aligned accesses
>>+ *
>>+ * @map__: The dma-buf mapping structure
>>+ * @type__: The struct to be used containing the field to write
>>+ * @field__: Member from struct we want to write
>>+ * @val__: Value to be written
>>+ *
>>+ * Write a value to the dma-buf mapping calculating the offset and size.
>>+ * A single u8, u16, u32 or u64 can be written based on the offset and size of
>>+ * type__.field__.
>>+ */
>>+#define dma_buf_map_write_field(map__, type__, field__, val__) ({ \
>>+ type__ *t__; \
>>+ typeof(t__->field__) val____ = val__; \
>>+ dma_buf_map_memcpy_to_offset(map__, offsetof(type__, field__), \
>>+ &val____, sizeof(t__->field__)); \
>>+})
>
>As the original author of this file, I feel like this shouldn't be
>here. At least not until we have another driver using that pattern.

Let me try to clear out the confusion. Then maybe I can extend
the documentation of this function in v2 if I'm able to convince this is
useful here.

This is not about importer/exporter, having this to work cross-driver.
This is about using dma_buf_map (which we are talking about on renaming
to iosys_map or something else) for inner driver
allocations/abstractions. The abstraction added by iosys_map helps on
sharing the same functions we had before. And this macro here is very
useful when the buffer is described by a struct layout. Example:

struct bla {
struct inner inner1;
struct inner inner2;
u32 x, y ,z;
};

Functions that would previously do:

struct bla *bla = ...;

bla->x = 100;
bla->y = 200;
bla->inner1.inner_inner_field = 30;

Can do the below, having the system/IO memory abstracted away
(calling it iosys_map here instead of dma_buf_map, hopeful it helps):

struct iosys_map *map = ...;

iosys_map_write_field(map, struct bla, x, 100);
iosys_map_write_field(map, struct bla, y, 200);
iosys_map_write_field(map, struct bla,
inner1.inner_inner_field, 30);

When we are using mostly the same map, the individual drivers can add
quick helpers on top. See the ads_blob_write() added in this series,
which guarantees the map it's working on is always the guc->ads_map,
while reducing verbosity to use the API. From patch
"drm/i915/guc: Add read/write helpers for ADS blob":

#define ads_blob_read(guc_, field_) \
dma_buf_map_read_field(&(guc_)->ads_map, struct __guc_ads_blob, \
field_)

#define ads_blob_write(guc_, field_, val_) \
dma_buf_map_write_field(&(guc_)->ads_map, struct __guc_ads_blob,\
field_, val_)

So in intel_guc_ads, we can have a lot of:

- bla->x = 100;
+ ads_blob_write(guc, x, 10);

thanks
Lucas De Marchi

\
 
 \ /
  Last update: 2022-01-27 17:34    [W:0.130 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site