public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH 01/19] dma-buf-map: Add read/write helpers
Date: Thu, 27 Jan 2022 08:59:36 +0100	[thread overview]
Message-ID: <0f948558-6f31-fd81-5349-38ab21379f86@amd.com> (raw)
In-Reply-To: <20220127073637.GA17282@jons-linux-dev-box>

Am 27.01.22 um 08:36 schrieb Matthew Brost:
> [SNIP]
>>>    /**
>>>     * 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__));			\
>>> +})
>>> +
>> Uff well that absolutely looks like overkill to me.
>>
> Hold on...
>
>> That's a rather special use case as far as I can see and I think we should
>> only have this in the common framework if more than one driver is using it.
>>
> I disagree, this is rather elegant.
>
> The i915 can't be the *only* driver that defines a struct which
> describes the layout of a dma_buf object.

That's not the problem, amdgpu as well as nouveau are doing that as 
well. The problem is DMA-buf is a buffer sharing framework between drivers.

In other words which importer is supposed to use this with a DMA-buf 
exported by another device?

> IMO this base macro allows *all* other drivers to build on this write
> directly to fields in structures those drivers have defined.

Exactly that's the point. This is something drivers should absolutely 
*NOT* do.

That are driver internals and it is extremely questionable to move this 
into the common framework.

Regards,
Christian.

>   Patches
> later in this series do this for the GuC ads.
>
> Matt
>   
>> Regards,
>> Christian.
>>
>>>    #endif /* __DMA_BUF_MAP_H__ */


  reply	other threads:[~2022-01-27  7:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 20:36 [PATCH 00/19] drm/i915/guc: Refactor ADS access to use dma_buf_map Lucas De Marchi
2022-01-26 20:36 ` [PATCH 01/19] dma-buf-map: Add read/write helpers Lucas De Marchi
2022-01-27  7:24   ` Christian König
2022-01-27  7:36     ` Matthew Brost
2022-01-27  7:59       ` Christian König [this message]
2022-01-27  9:02         ` [Intel-gfx] " Daniel Vetter
2022-01-27 14:26   ` Thomas Zimmermann
2022-01-27 16:34     ` Lucas De Marchi
2022-01-28  8:32       ` Thomas Zimmermann
2022-01-26 20:36 ` [PATCH 02/19] dma-buf-map: Add helper to initialize second map Lucas De Marchi
2022-01-27  7:27   ` Christian König
2022-01-27  7:57     ` Lucas De Marchi
2022-01-27  8:02       ` Christian König
2022-01-27  8:18         ` [Intel-gfx] " Lucas De Marchi
2022-01-27  8:55           ` Christian König
2022-01-27  9:12             ` Lucas De Marchi
2022-01-27  9:21               ` Christian König
2022-01-27  8:57         ` Daniel Vetter
2022-01-27  9:33           ` [Intel-gfx] " Lucas De Marchi
2022-01-27 10:00             ` Daniel Vetter
2022-01-27 10:21               ` Christian König
2022-01-27 11:16                 ` Daniel Vetter
2022-01-27 11:44                   ` [Linaro-mm-sig] " Christian König
2022-01-27 11:56                     ` Daniel Vetter
2022-01-27 16:13                     ` Lucas De Marchi
2022-01-27 14:52                 ` Thomas Zimmermann
2022-01-27 16:12                 ` Lucas De Marchi
2022-01-27 14:33   ` Thomas Zimmermann
2022-01-27 15:59     ` [Intel-gfx] " Lucas De Marchi
2022-01-28  8:15       ` Thomas Zimmermann
2022-01-28  8:34         ` Thomas Zimmermann
2022-01-26 20:36 ` [PATCH 09/19] dma-buf-map: Add wrapper over memset Lucas De Marchi
2022-01-27  7:28   ` Christian König
2022-01-27 14:54   ` Thomas Zimmermann
2022-01-27 15:38     ` [Intel-gfx] " Lucas De Marchi
2022-01-27 15:47       ` Thomas Zimmermann

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=0f948558-6f31-fd81-5349-38ab21379f86@amd.com \
    --to=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.brost@intel.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