mbox series

[v3,0/3] Add generic framebuffer support to EFI earlycon driver

Message ID 20221221105402.6598-1-markuss.broks@gmail.com (mailing list archive)
Headers show
Series Add generic framebuffer support to EFI earlycon driver | expand

Message

Markuss Broks Dec. 21, 2022, 10:53 a.m. UTC
Make the EFI earlycon driver be suitable for any linear framebuffers.
This should be helpful for early porting of boards with no other means of
output, like smartphones/tablets. There seems to be an issue with early_ioremap
function on ARM32, but I am unable to find the exact cause. It appears the mappings
returned by it are somehow incorrect, thus the driver is disabled on ARM. EFI early
console was disabled on IA64 previously because of missing early_memremap_prot,
and this is inherited to this driver.

This patch also changes behavior on EFI systems, by selecting the mapping type
based on if the framebuffer region intersects with system RAM. If it does, it's
common sense that it should be in RAM as a whole, and so the system RAM mapping is
used. It was tested to be working on my PC (Intel Z490 platform), as well as several
ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...).

Markuss Broks (2):
  drivers: serial: earlycon: Pass device-tree node
  efi: earlycon: Add support for generic framebuffers and move to fbdev
    subsystem


v1 -> v2:

- a new patch correcting serial/earlycon.c argument name to "offset" instead
  of "node"
- move IA64 exclusion from EFI earlycon Kconfig to earlycon driver Kconfig
  (IA64 has no early_memremap_prot)
- move driver from fbdev to console subsystem
- select EFI earlycon by default
- fetch stride manually from device-tree, as on some devices it seems stride
  doesn't match the horizontal resolution * bpp.
- use saner format (e.g. 1920x1080x32 instead of 1920,1080,32).


Markuss Broks (3):
  drivers: serial: earlycon: Pass device-tree node
  efi: earlycon: move to video/console to prepare for changes
  efi: earlycon: Add support for generic framebuffers

 .../admin-guide/kernel-parameters.txt         |  12 +-
 MAINTAINERS                                   |   5 +
 drivers/firmware/efi/Kconfig                  |   7 +-
 drivers/firmware/efi/Makefile                 |   1 -
 drivers/firmware/efi/earlycon.c               | 246 --------------
 drivers/tty/serial/earlycon.c                 |   3 +
 drivers/video/console/Kconfig                 |  11 +
 drivers/video/console/Makefile                |   1 +
 drivers/video/console/earlycon.c              | 305 ++++++++++++++++++
 include/linux/serial_core.h                   |   1 +
 10 files changed, 336 insertions(+), 256 deletions(-)
 delete mode 100644 drivers/firmware/efi/earlycon.c
 create mode 100644 drivers/video/console/earlycon.c

Comments

Ard Biesheuvel Dec. 23, 2022, 2:42 p.m. UTC | #1
(cc Andy)


On Wed, 21 Dec 2022 at 11:54, Markuss Broks <markuss.broks@gmail.com> wrote:
>
> Make the EFI earlycon driver be suitable for any linear framebuffers.
> This should be helpful for early porting of boards with no other means of
> output, like smartphones/tablets. There seems to be an issue with early_ioremap
> function on ARM32, but I am unable to find the exact cause. It appears the mappings
> returned by it are somehow incorrect, thus the driver is disabled on ARM.

The reason that this driver is disabled on ARM is because the struct
screen_info is not populated early enough, as it is retrieved from a
UEFI configuration table.

early_ioremap() works fine on ARM as long as they mapping is torn down
before paging_init()

> EFI early
> console was disabled on IA64 previously because of missing early_memremap_prot,
> and this is inherited to this driver.
>
> This patch also changes

"This patch also changes ..." is usually a strong hint to self that
the patches need to be split up.

> behavior on EFI systems, by selecting the mapping type
> based on if the framebuffer region intersects with system RAM. If it does, it's
> common sense that it should be in RAM as a whole, and so the system RAM mapping is
> used. It was tested to be working on my PC (Intel Z490 platform), as well as several
> ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...).
>
> Markuss Broks (2):
>   drivers: serial: earlycon: Pass device-tree node
>   efi: earlycon: Add support for generic framebuffers and move to fbdev
>     subsystem
>
>
> v1 -> v2:
>
> - a new patch correcting serial/earlycon.c argument name to "offset" instead
>   of "node"
> - move IA64 exclusion from EFI earlycon Kconfig to earlycon driver Kconfig
>   (IA64 has no early_memremap_prot)
> - move driver from fbdev to console subsystem
> - select EFI earlycon by default
> - fetch stride manually from device-tree, as on some devices it seems stride
>   doesn't match the horizontal resolution * bpp.
> - use saner format (e.g. 1920x1080x32 instead of 1920,1080,32).
>
>
> Markuss Broks (3):
>   drivers: serial: earlycon: Pass device-tree node
>   efi: earlycon: move to video/console to prepare for changes
>   efi: earlycon: Add support for generic framebuffers
>
>  .../admin-guide/kernel-parameters.txt         |  12 +-
>  MAINTAINERS                                   |   5 +
>  drivers/firmware/efi/Kconfig                  |   7 +-
>  drivers/firmware/efi/Makefile                 |   1 -
>  drivers/firmware/efi/earlycon.c               | 246 --------------
>  drivers/tty/serial/earlycon.c                 |   3 +
>  drivers/video/console/Kconfig                 |  11 +
>  drivers/video/console/Makefile                |   1 +
>  drivers/video/console/earlycon.c              | 305 ++++++++++++++++++
>  include/linux/serial_core.h                   |   1 +
>  10 files changed, 336 insertions(+), 256 deletions(-)
>  delete mode 100644 drivers/firmware/efi/earlycon.c
>  create mode 100644 drivers/video/console/earlycon.c
>
> --
> 2.39.0
>
Markuss Broks Dec. 23, 2022, 2:58 p.m. UTC | #2
Hi Ard,

On 12/23/22 16:42, Ard Biesheuvel wrote:
> (cc Andy)
>
>
> On Wed, 21 Dec 2022 at 11:54, Markuss Broks <markuss.broks@gmail.com> wrote:
>> Make the EFI earlycon driver be suitable for any linear framebuffers.
>> This should be helpful for early porting of boards with no other means of
>> output, like smartphones/tablets. There seems to be an issue with early_ioremap
>> function on ARM32, but I am unable to find the exact cause. It appears the mappings
>> returned by it are somehow incorrect, thus the driver is disabled on ARM.
> The reason that this driver is disabled on ARM is because the struct
> screen_info is not populated early enough, as it is retrieved from a
> UEFI configuration table.

I believe I must be hitting some other bug then, since my driver should 
not use `struct screen_info` when the arguments are specified manually 
(e.g. in device-tree or in kernel command line options), and it still is 
broken on ARM when they are. I got it to work on ARM when I moved the 
early console initialization later into the kernel booting process, but 
that mostly defeats the purpose of early console driver, I believe. I've 
been thinking that it could be some stuff not getting initialized early 
enough indeed, but I've got no clue what could it be.

>
> early_ioremap() works fine on ARM as long as they mapping is torn down
> before paging_init()
>
>> EFI early
>> console was disabled on IA64 previously because of missing early_memremap_prot,
>> and this is inherited to this driver.
>>
>> This patch also changes
> "This patch also changes ..." is usually a strong hint to self that
> the patches need to be split up.
>
>> behavior on EFI systems, by selecting the mapping type
>> based on if the framebuffer region intersects with system RAM. If it does, it's
>> common sense that it should be in RAM as a whole, and so the system RAM mapping is
>> used. It was tested to be working on my PC (Intel Z490 platform), as well as several
>> ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...).
>>
>> Markuss Broks (2):
>>    drivers: serial: earlycon: Pass device-tree node
>>    efi: earlycon: Add support for generic framebuffers and move to fbdev
>>      subsystem
>>
>>
>> v1 -> v2:
>>
>> - a new patch correcting serial/earlycon.c argument name to "offset" instead
>>    of "node"
>> - move IA64 exclusion from EFI earlycon Kconfig to earlycon driver Kconfig
>>    (IA64 has no early_memremap_prot)
>> - move driver from fbdev to console subsystem
>> - select EFI earlycon by default
>> - fetch stride manually from device-tree, as on some devices it seems stride
>>    doesn't match the horizontal resolution * bpp.
>> - use saner format (e.g. 1920x1080x32 instead of 1920,1080,32).
>>
>>
>> Markuss Broks (3):
>>    drivers: serial: earlycon: Pass device-tree node
>>    efi: earlycon: move to video/console to prepare for changes
>>    efi: earlycon: Add support for generic framebuffers
>>
>>   .../admin-guide/kernel-parameters.txt         |  12 +-
>>   MAINTAINERS                                   |   5 +
>>   drivers/firmware/efi/Kconfig                  |   7 +-
>>   drivers/firmware/efi/Makefile                 |   1 -
>>   drivers/firmware/efi/earlycon.c               | 246 --------------
>>   drivers/tty/serial/earlycon.c                 |   3 +
>>   drivers/video/console/Kconfig                 |  11 +
>>   drivers/video/console/Makefile                |   1 +
>>   drivers/video/console/earlycon.c              | 305 ++++++++++++++++++
>>   include/linux/serial_core.h                   |   1 +
>>   10 files changed, 336 insertions(+), 256 deletions(-)
>>   delete mode 100644 drivers/firmware/efi/earlycon.c
>>   create mode 100644 drivers/video/console/earlycon.c
>>
>> --
>> 2.39.0
>>
- Markuss


P.S. Just noticed I forgot to Ctrl^S the cover letter before saving... 
The main change v3 does is separate the moving action and edit action 
into two separate commits, I don't think there're more major changes. 
With v4 I'd try to attach the proper version log.
Andy Shevchenko Dec. 28, 2022, 2:03 p.m. UTC | #3
On Fri, Dec 23, 2022 at 03:42:33PM +0100, Ard Biesheuvel wrote:
> (cc Andy)

I believe there are two reasons I'm Cc'ed now:
- the Cc was forgotten. because I remember reviewing some parts
  of this contribution
- this conflicts (to some extent) with my patch that speeds up
  the scrolling

For the first it's obvious what to do, I think Markuss can include me
in his v4.

For the second I don't see the functional clash. The scrolling in this
series is not anyhow optimized. I think my patch should go first as
- it is less intrusive
- it has been tested, or can be tested easily

Tell me if I'm missing something here.

> On Wed, 21 Dec 2022 at 11:54, Markuss Broks <markuss.broks@gmail.com> wrote:
> >
> > Make the EFI earlycon driver be suitable for any linear framebuffers.
> > This should be helpful for early porting of boards with no other means of
> > output, like smartphones/tablets. There seems to be an issue with early_ioremap
> > function on ARM32, but I am unable to find the exact cause. It appears the mappings
> > returned by it are somehow incorrect, thus the driver is disabled on ARM.
> 
> The reason that this driver is disabled on ARM is because the struct
> screen_info is not populated early enough, as it is retrieved from a
> UEFI configuration table.
> 
> early_ioremap() works fine on ARM as long as they mapping is torn down
> before paging_init()
> 
> > EFI early
> > console was disabled on IA64 previously because of missing early_memremap_prot,
> > and this is inherited to this driver.
> >
> > This patch also changes
> 
> "This patch also changes ..." is usually a strong hint to self that
> the patches need to be split up.
> 
> > behavior on EFI systems, by selecting the mapping type
> > based on if the framebuffer region intersects with system RAM. If it does, it's
> > common sense that it should be in RAM as a whole, and so the system RAM mapping is
> > used. It was tested to be working on my PC (Intel Z490 platform), as well as several
> > ARM64 boards (Samsung Galaxy S9 (Exynos), iPad Air 2, Xiaomi Mi Pad 4, ...).
Ard Biesheuvel Jan. 10, 2023, 2:30 p.m. UTC | #4
On Wed, 28 Dec 2022 at 15:04, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Fri, Dec 23, 2022 at 03:42:33PM +0100, Ard Biesheuvel wrote:
> > (cc Andy)
>
> I believe there are two reasons I'm Cc'ed now:
> - the Cc was forgotten. because I remember reviewing some parts
>   of this contribution
> - this conflicts (to some extent) with my patch that speeds up
>   the scrolling
>
> For the first it's obvious what to do, I think Markuss can include me
> in his v4.
>
> For the second I don't see the functional clash. The scrolling in this
> series is not anyhow optimized. I think my patch should go first as
> - it is less intrusive
> - it has been tested, or can be tested easily
>
> Tell me if I'm missing something here.
>

Thanks for your input.
Ard Biesheuvel Jan. 10, 2023, 2:32 p.m. UTC | #5
On Fri, 23 Dec 2022 at 15:58, Markuss Broks <markuss.broks@gmail.com> wrote:
>
> Hi Ard,
>
> On 12/23/22 16:42, Ard Biesheuvel wrote:
> > (cc Andy)
> >
> >
> > On Wed, 21 Dec 2022 at 11:54, Markuss Broks <markuss.broks@gmail.com> wrote:
> >> Make the EFI earlycon driver be suitable for any linear framebuffers.
> >> This should be helpful for early porting of boards with no other means of
> >> output, like smartphones/tablets. There seems to be an issue with early_ioremap
> >> function on ARM32, but I am unable to find the exact cause. It appears the mappings
> >> returned by it are somehow incorrect, thus the driver is disabled on ARM.
> > The reason that this driver is disabled on ARM is because the struct
> > screen_info is not populated early enough, as it is retrieved from a
> > UEFI configuration table.
>
> I believe I must be hitting some other bug then, since my driver should
> not use `struct screen_info` when the arguments are specified manually
> (e.g. in device-tree or in kernel command line options), and it still is
> broken on ARM when they are.

Define 'broken'

> I got it to work on ARM when I moved the
> early console initialization later into the kernel booting process, but
> that mostly defeats the purpose of early console driver, I believe. I've
> been thinking that it could be some stuff not getting initialized early
> enough indeed, but I've got no clue what could it be.
>

This is likely due to the fact that the ARM init code sets up the PTE
bits for various memory types, and using them beforehand is likely to
result in problems.