[PATCH 0/5] Unmappable DRM client buffers for fbdev emulation

[Noralf Trønnes]

Den 04.07.2019 13.10, skrev Thomas Zimmermann:
> Hi
> 
> Am 04.07.19 um 12:18 schrieb Noralf Trønnes:
>>
>>
>> Den 04.07.2019 09.43, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 03.07.19 um 21:27 schrieb Noralf Trønnes:
>>>>
>>>>
>>>> Den 03.07.2019 10.32, skrev Thomas Zimmermann:
>>>>> DRM client buffers are permanently mapped throughout their lifetime. This
>>>>> prevents us from using generic framebuffer emulation for devices with
>>>>> small dedicated video memory, such as ast or mgag200. With fb buffers
>>>>> permanently mapped, such devices often won't have enougth space left to
>>>>> display other content (e.g., X11).
>>>>>
>>>>> This patch set introduces unmappable DRM client buffers for framebuffer
>>>>> emulation with shadow buffers. While the shadow buffer remains in system
>>>>> memory permanently, the respective buffer object will only be mapped briefly
>>>>> during updates from the shadow buffer. Hence, the driver can relocate he
>>>>> buffer object among memory regions as needed.
>>>>>
>>>>> The default behoviour for DRM client buffers is still to be permanently
>>>>> mapped.
>>>>>
>>>>> The patch set converts ast and mgag200 to generic framebuffer emulation
>>>>> and removes a large amount of framebuffer code from these drivers. For
>>>>> bochs, a problem was reported where the driver could not display the console
>>>>> because it was pinned in system memory. [1] The patch set fixes this bug
>>>>> by converting bochs to use the shadow fb.
>>>>>
>>>>> The patch set has been tested on ast and mga200 HW.
>>>>>
>>>>
>>>> I've been thinking, this enables dirty tracking in DRM userspace for
>>>> these drivers since the dirty callback is now set on all framebuffers.
>>>> Is this OK? Should we add a drm_fbdev_generic_shadow_setup() that sets a
>>>> flag enabling the shadow buffer instead?
>>>
>>> Fbdev emulation is special wrt framebuffer setup and there's no way to
>>> distinguish a regular FB from the fbdev's FB. I've been trying
>>> drm_fbdev_generic_shadow_setup(), but ended up duplicating
>>> functionality. The problem was that we cannot get state-flag arguments
>>> into drm_fb_helper_generic_probe().
>>>
>>> There already is struct mode_config.prefer_shadow. It signals shadow FB
>>> rendering to userspace. The easiest solution is to add
>>> prefer_shadow_fbdev as well. If either flag is true, fbdev emulation
>>> would enable shadow buffering.
>>
>> How about something like this:
> 
> I had something like that in mind, but maybe without a separate
> function. I'll post my variant as part of the patch set's next iteration.
> 

<snip>

>>>
>>> I'm not sure if we should check for the dirty() callback at all.
>>>
>>
>> Hm, why do you think that?
> 
> Drivers may already come with their own shadow buffer. Cirrus is an
> example of that. It uses shmem buffer objects as shadow fbs and
> internally updates the device frame buffer in its dirty callback. Using
> dirty() to select the shadow fbdev adds another buffer (and another
> memcpy) for no reason.

Cirruc uses shmem buffers and they won't work with fbdev defio (both use
page->lru). shmem is the reason I added shadow buffering to generic
fbdev in the first place. It will now work with whatever backing buffer
the driver uses, as long as it can provide a virtual address on the dumb
buffer (not the case with rockchip for instance, due to limited virtual
address space).

Noralf.

> 
> Best regards
> Thomas
> 
>> The thing with fbdev defio is that it only supports kmalloc and vmalloc
>> allocated memory (page->lru is avail.). This means that only the CMA
>> drivers can use defio without shadow memory. To keep things simple
>> everyone with a dirty() callback gets a shadow buffer.
>>
>> Noralf.
>>
>>> Best regards
>>> Thomas
>>>
>>>> Really nice diffstat by the way :-)
>>>>
>>>> Noralf.
>>>>
>>>>> [1] https://lists.freedesktop.org/archives/dri-devel/2019-June/224423.html
>>>>>
>>>>> Thomas Zimmermann (5):
>>>>>   drm/client: Support unmapping of DRM client buffers
>>>>>   drm/fb-helper: Unmap BO for shadow-buffered framebuffer console
>>>>>   drm/ast: Replace struct ast_fbdev with generic framebuffer emulation
>>>>>   drm/bochs: Use shadow buffer for bochs framebuffer console
>>>>>   drm/mgag200: Replace struct mga_fbdev with generic framebuffer
>>>>>     emulation
>>>>>
>>>>>  drivers/gpu/drm/ast/Makefile           |   2 +-
>>>>>  drivers/gpu/drm/ast/ast_drv.c          |  22 +-
>>>>>  drivers/gpu/drm/ast/ast_drv.h          |  17 --
>>>>>  drivers/gpu/drm/ast/ast_fb.c           | 341 -------------------------
>>>>>  drivers/gpu/drm/ast/ast_main.c         |  30 ++-
>>>>>  drivers/gpu/drm/ast/ast_mode.c         |  21 --
>>>>>  drivers/gpu/drm/bochs/bochs_kms.c      |   2 +-
>>>>>  drivers/gpu/drm/drm_client.c           |  71 ++++-
>>>>>  drivers/gpu/drm/drm_fb_helper.c        |  14 +-
>>>>>  drivers/gpu/drm/mgag200/Makefile       |   2 +-
>>>>>  drivers/gpu/drm/mgag200/mgag200_drv.h  |  19 --
>>>>>  drivers/gpu/drm/mgag200/mgag200_fb.c   | 309 ----------------------
>>>>>  drivers/gpu/drm/mgag200/mgag200_main.c |  61 +++--
>>>>>  drivers/gpu/drm/mgag200/mgag200_mode.c |  27 --
>>>>>  include/drm/drm_client.h               |   3 +
>>>>>  15 files changed, 154 insertions(+), 787 deletions(-)
>>>>>  delete mode 100644 drivers/gpu/drm/ast/ast_fb.c
>>>>>  delete mode 100644 drivers/gpu/drm/mgag200/mgag200_fb.c
>>>>>
>>>>> --
>>>>> 2.21.0
>>>>>
>>>> _______________________________________________
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>