lkml.org 
[lkml]   [2022]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
From
Hi

Am 28.01.22 um 09:15 schrieb Thomas Zimmermann:
...
>
>>
>> While with the construct below
>>
>>          other_map;
>>          ...
>>          other_map = INITIALIZER()
>>
>> I can rely on the compiler complaining about uninitialized var. And
>> in most of the cases I can just have this single line in the beggining
>> of the
>> function when the offset is constant:
>>
>>          struct dma_buf_map other_map = INITIALIZER(bla_map,
>> offsetof(..));
>>
>>
>> This is useful when you have several small functions in charge of
>> updating/reading inner struct members.
>
> You won't need an extra variable or the initializer macro if you add an
> offset parameter to dma_buf_memcpy_{from,to}.  Simple pass offsetof(..)
> to that parameter and it will do the right thing.
>
> It avoids the problems of the current macro and is even more flexible.
> On top of that, you can build whatever convenience macros you need for
> i915.

And maybe put all changes to the dma_buf_map interface into a single
patch. It makes it easier to review and discuss.

Best regards
Thomas

>
> Best regards
> Thomas
>
>>
>>>
>>> I've also been very careful to distinguish between .vaddr and
>>> .vaddr_iomem, even in places where I wouldn't have to. This macro
>>> breaks the assumption.
>>
>> That's one reason I think if we have this macro, it should be in the
>> dma_buf_map.h header (or whatever we rename these APIs to). It's the
>> only place where we can safely add code that relies on the implementation
>> of the "private" fields in struct dma_buf_map.
>>
>> Lucas De Marchi
>>
>>>
>>> Best regards
>>> Thomas
>>>
>>>>  /**
>>>>   * dma_buf_map_set_vaddr - Sets a dma-buf mapping structure to an
>>>> address in system memory
>>>>   * @map:    The dma-buf mapping structure
>>>
>>> --
>>> Thomas Zimmermann
>>> Graphics Driver Developer
>>> SUSE Software Solutions Germany GmbH
>>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>>> (HRB 36809, AG Nürnberg)
>>> Geschäftsführer: Ivo Totev
>>
>>
>>
>

--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2022-01-28 09:35    [W:0.074 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site