lkml.org 
[lkml]   [2022]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers and move to fbdev subsystem
From
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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2022-07-28 20:14    [W:0.108 / U:1.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site