Re: [PATCH v2 0/3] drm/prime: Only call dma_map_sgtable() for devices with DMA support

[Thomas Zimmermann <tzimmermann@suse.de>]

[-- Attachment #1.1: Type: text/plain, Size: 5058 bytes --]

Hi

Am 22.02.21 um 17:10 schrieb Daniel Vetter:
> On Mon, Feb 22, 2021 at 2:24 PM Thomas Zimmermann <tzimmermann@suse.de> wrote:
>>
>> Hi
>>
>> Am 22.02.21 um 14:09 schrieb Christian König:
>>>
>>>
>>> Am 22.02.21 um 13:43 schrieb Thomas Zimmermann:
>>>> USB-based drivers cannot use DMA, so the importing of dma-buf attachments
>>>> currently fails for udl and gm12u320. This breaks joining/mirroring of
>>>> displays.
>>>>
>>>> The fix is now a little series. To solve the issue on the importer
>>>> side (i.e., the affected USB-based driver), patch 1 introduces a new
>>>> PRIME callback, struct drm_driver.gem_prime_create_object, which creates
>>>> an object and gives more control to the importing driver. Specifically,
>>>> udl and gm12u320 can now avoid the creation of a scatter/gather table
>>>> for the imported pages. Patch 1 is self-contained in the sense that it
>>>> can be backported into older kernels.
>>>
>>> Mhm, that sounds like a little overkill to me.
>>>
>>> Drivers can already import the DMA-bufs all by them selves without the
>>> help of the DRM functions. See amdgpu for an example.
>>>
>>> Daniel also already noted to me that he sees the DRM helper as a bit
>>> questionable middle layer.
>>
>> And this bug proves that it is. :)
> 
> The trouble here is actually gem_bo->import_attach, which isn't really
> part of the questionable midlayer, but fairly mandatory (only
> exception is vmwgfx because not using gem) caching to make sure we
> don't end up with duped imports and fun stuff like that.
> 
> And dma_buf_attach now implicitly creates the sg table already, so
> we're already in game over land. I think we'd need to make
> import_attach a union with import_buf or something like that, so that
> you can do attachment-less importing.

Creating the sg table is not the problem; mapping it is. So 
dma_buf_attach shouldn't be a problem.

> 
>>> Have you thought about doing that instead?
>>
>> There appears to be some useful code in drm_gem_prime_import_dev(). But
>> if the general sentiment goes towards removing
>> gem_prime_import_sg_table, we can work towards that as well.
> 
> I still think this part is a bit a silly midlayer for no good reason,
> but I think that's orthogonal to the issue at hand here.
> 
> I'd suggest we first try to paper over the issue by using
> prime_import_dev with the host controller (which hopefully is
> dma-capable for most systems). And then, at leisure, try to untangle
> the obj->import_attach issue.

I really don't want to do this. My time is also limited, and I''ll spend 
time papering over the thing. And then more time for the real fix. I'd 
rather pull drm_gem_prime_import_dev() in to USB drivers and avoid the 
dma_buf_map().

Best regard
Thomas

> -Daniel
> 
>>
>> Best regards
>> Thomas
>>
>>>
>>> Christian.
>>>
>>>>
>>>> Patches 2 and 3 update SHMEM and CMA helpers to use the new callback.
>>>> Effectively this moves the sg table setup from the PRIME helpers into
>>>> the memory managers. SHMEM now supports devices without DMA support,
>>>> so custom code can be removed from udl and g12u320.
>>>>
>>>> Tested by joining/mirroring displays of udl and radeon under Gnome/X11.
>>>>
>>>> v2:
>>>>      * move fix to importer side (Christian, Daniel)
>>>>      * update SHMEM and CMA helpers for new PRIME callbacks
>>>>
>>>> Thomas Zimmermann (3):
>>>>     drm: Support importing dmabufs into drivers without DMA
>>>>     drm/shmem-helper: Implement struct drm_driver.gem_prime_create_object
>>>>     drm/cma-helper: Implement struct drm_driver.gem_prime_create_object
>>>>
>>>>    drivers/gpu/drm/drm_gem_cma_helper.c    | 62 ++++++++++++++-----------
>>>>    drivers/gpu/drm/drm_gem_shmem_helper.c  | 38 ++++++++++-----
>>>>    drivers/gpu/drm/drm_prime.c             | 43 +++++++++++------
>>>>    drivers/gpu/drm/lima/lima_drv.c         |  2 +-
>>>>    drivers/gpu/drm/panfrost/panfrost_drv.c |  2 +-
>>>>    drivers/gpu/drm/panfrost/panfrost_gem.c |  6 +--
>>>>    drivers/gpu/drm/panfrost/panfrost_gem.h |  4 +-
>>>>    drivers/gpu/drm/pl111/pl111_drv.c       |  8 ++--
>>>>    drivers/gpu/drm/v3d/v3d_bo.c            |  6 +--
>>>>    drivers/gpu/drm/v3d/v3d_drv.c           |  2 +-
>>>>    drivers/gpu/drm/v3d/v3d_drv.h           |  5 +-
>>>>    include/drm/drm_drv.h                   | 12 +++++
>>>>    include/drm/drm_gem_cma_helper.h        | 12 ++---
>>>>    include/drm/drm_gem_shmem_helper.h      |  6 +--
>>>>    14 files changed, 120 insertions(+), 88 deletions(-)
>>>>
>>>> --
>>>> 2.30.1
>>>>
>>>
>>
>> --
>> 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
>>
> 
> 

-- 
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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]