[Intel-gfx] [PATCH v3 0/4] dma-buf: Flag vmap'ed memory as system or I/O memory

[Christian König]

Am 27.09.20 um 21:16 schrieb Sam Ravnborg:
> Hi Thomas.
>
>>> struct simap {
>>>         union {
>>>                 void __iomem *vaddr_iomem;
>>>                 void *vaddr;
>>>         };
>>>         bool is_iomem;
>>> };
>>>
>>> Where simap is a shorthand for system_iomem_map
>>> And it could al be stuffed into a include/linux/simap.h file.
>>>
>>> Not totally sold on the simap name - but wanted to come up with
>>> something.
>> Yes. Others, myself included, have suggested to use a name that does not
>> imply a connection to the dma-buf framework, but no one has come up with
>>   a good name.
>>
>> I strongly dislike simap, as it's entirely non-obvious what it does.
>> dma-buf-map is not actually wrong. The structures represents the mapping
>> of a dma-able buffer in most cases.
>>
>>> With this approach users do not have to pull in dma-buf to use it and
>>> users will not confuse that this is only for dma-buf usage.
>> There's no need to enable dma-buf. It's all in the header file without
>> dependencies on dma-buf. It's really just the name.
>>
>> But there's something else to take into account. The whole issue here is
>> that the buffer is disconnected from its originating driver, so we don't
>> know which kind of memory ops we have to use. Thinking about it, I
>> realized that no one else seemed to have this problem until now.
>> Otherwise there would be a solution already. So maybe the dma-buf
>> framework *is* the native use case for this data structure.
> We have at least:
> linux/fb.h:
> 	union {
> 		char __iomem *screen_base;      /* Virtual address */
> 		char *screen_buffer;
> 	};
>
> Which solve more or less the same problem.

I also already noted that in TTM we have exactly the same problem and a 
whole bunch of helpers to allow operations on those pointers.

Christian.

>
>   
>> Anyway, if a better name than dma-buf-map comes in, I'm willing to
>> rename the thing. Otherwise I intend to merge the patchset by the end of
>> the week.
> Well, the main thing is that I think this shoud be moved away from
> dma-buf. But if indeed dma-buf is the only relevant user in drm then
> I am totally fine with the current naming.
>
> One alternative named that popped up in my head: struct sys_io_map {}
> But again, if this is kept in dma-buf then I am fine with the current
> naming.
>
> In other words, if you continue to think this is mostly a dma-buf
> thing all three patches are:
> Acked-by: Sam Ravnborg <sam at ravnborg.org>
>
> 	Sam