[PATCH 00/22] drm/dma-helper: Add dedicated fbdev emulation
Thomas Zimmermann
tzimmermann at suse.de
Tue Mar 7 19:55:29 AEDT 2023
Hi
Am 06.03.23 um 23:19 schrieb Linus Walleij:
> On Wed, Mar 1, 2023 at 4:31 PM Thomas Zimmermann <tzimmermann at suse.de> wrote:
>
>> Add fbdev emulation that is optimized for DMA helpers, as used by most
>> drivers. It operates directly on GEM DMA buffers in system memory.
>> Memory pages are mmap'ed directly to userspace. No implicit shadow
>> buffers need to be allocated; as can happen with the generic fbdev
>> emulation. Convert drivers that fulfil the requirements.
>>
>> Tested with fbcon and IGT on vc4.
>>
>> Future direction: providing a dedicated fbdev emulation for GEM DMA
>> helpers will allow us to remove this case from the generic fbdev code.
>> The latter can then be simplified.
>
> 1) I love your work.
Thank you. :)
>
> 2) Why isn't this DRM driver changed?
> drivers/gpu/drm/mcde/mcde_drv.c
> AFAICT it also uses GEM buffers in system memory.
This driver requires damage handling
https://elixir.bootlin.com/linux/v6.2/source/drivers/gpu/drm/mcde/mcde_drv.c#L97
for which we have to call the framebuffer's dirty callback
https://elixir.bootlin.com/linux/v6.2/source/drivers/gpu/drm/drm_gem_framebuffer_helper.c#L285
after each write.
Doing this with fbdev emulation requires tracking of mmap'ed pages via
fbdev's deferred-I/O mechanisms. That makes the fbdev-emulation code
more complex. AFAICT, the existing generic fbdev emulation already
implements this case 'good enough.'
>
> 3) This one:
> drivers/gpu/drm/pl111/pl111_drv.c
> is also very similar, but can sometimes use a dedicated
> RAM memory for allocations using CMA, does that make
> it not a candidate?
Thanks, I think I simply missed pl111.
Best regards
Thomas
>
> They aren't much different in how they work from the TVE200.
>
> Yours,
> Linus Walleij
--
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linux-aspeed/attachments/20230307/f4147fe7/attachment.sig>
More information about the Linux-aspeed
mailing list