Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem

[Thomas Zimmermann <tzimmermann@suse.de>]

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

Hi

Am 28.07.22 um 17:16 schrieb Arnd Bergmann:
> On Thu, Jul 28, 2022 at 4:57 PM Markuss Broks <markuss.broks@gmail.com> wrote:
>> On 7/28/22 17:48, Arnd Bergmann wrote:
>>> On Thu, Jul 28, 2022 at 4:28 PM Markuss Broks <markuss.broks@gmail.com> wrote:
>>>>
>>>> Add early console support for generic linear framebuffer devices.
>>>> This driver supports probing from cmdline early parameters
>>>> or from the device-tree using information in simple-framebuffer node.
>>>> The EFI functionality should be retained in whole.
>>>> The driver was disabled on ARM because of a bug in early_ioremap
>>>> implementation on ARM.
>>>>
>>>> Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
>>>> ---
>>>>    .../admin-guide/kernel-parameters.txt         |  12 +-
>>>>    MAINTAINERS                                   |   5 +
>>>>    drivers/firmware/efi/Kconfig                  |   6 +-
>>>>    drivers/firmware/efi/Makefile                 |   1 -
>>>>    drivers/firmware/efi/earlycon.c               | 246 --------------
>>>>    drivers/video/fbdev/Kconfig                   |  11 +
>>>>    drivers/video/fbdev/Makefile                  |   1 +
>>>>    drivers/video/fbdev/earlycon.c                | 301 ++++++++++++++++++
>>>
>>> It looks like this is not actually related to fbdev, and since drivers are
>>> moving from fbdev/simplefb towards drm/simpledrm, maybe it would be
>>> better to put this into either drivers/gpu/drm/tiny/ or possibly
>>> drivers/video/console to let this be used without enabling fbdev?
>>
>> Ideally this shouldn't depend on anything, because it isn't utilizing
>> any of fbdev code and won't be utilizing any of drm/console code. I
>> agree that either of those would be a better place for it, but which one
>> do you think would suit more for this driver?
> 
> I think ideally this would be integrated with simpledrm in the long run,
> but I have no idea what that means in terms of future code changes.
> 
> Maybe Thomas Zimmermann has an idea here.

It's not a graphics driver, so it doesn't belong to fbdev or DRM. I'd 
put the code under drivers/video/console.

Direct integration with simpledrm (or any other firmware graphics 
driver) is probably not an option. Those drivers operate on platform 
devices, which aren't available when earlycon runs.

There's no management of framebuffer ownership AFAICT? For fbdev and 
DRM, we manage the ownership of the framebuffer memory. When a driver 
takes over the framebuffer, it first has to remove any driver previously 
owning that memory.  That apparently hasn't been a need for early 
consoles so far (?) Maybe we should integrate them into the ownership 
management (see drivers/video/aperture.c).

Best regards
Thomas

> 
>          Arnd

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

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