[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VdaDyyqRw9fAkUOhNjsyifeozVx6JuYXSU1HpoO+VHDNA@mail.gmail.com>
Date: Thu, 28 Jul 2022 23:19:55 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Markuss Broks <markuss.broks@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
Jonathan Corbet <corbet@....net>,
Ard Biesheuvel <ardb@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Helge Deller <deller@....de>,
"Paul E. McKenney" <paulmck@...nel.org>,
Borislav Petkov <bp@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Kees Cook <keescook@...omium.org>,
Randy Dunlap <rdunlap@...radead.org>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Javier Martinez Canillas <javierm@...hat.com>,
Michal Suchanek <msuchanek@...e.de>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Arnd Bergmann <arnd@...db.de>,
Wei Ming Chen <jj251510319013@...il.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Tony Lindgren <tony@...mide.com>,
Linux Documentation List <linux-doc@...r.kernel.org>,
linux-efi <linux-efi@...r.kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
"open list:FRAMEBUFFER LAYER" <linux-fbdev@...r.kernel.org>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Rob Herring <robh@...nel.org>
Subject: Re: [PATCH 2/2] efi: earlycon: Add support for generic framebuffers
and move to fbdev subsystem
On Thu, Jul 28, 2022 at 4:32 PM Markuss Broks <markuss.broks@...il.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.
...
> - efifb,[options]
> + efifb
> Start an early, unaccelerated console on the EFI
> - memory mapped framebuffer (if available). On cache
> - coherent non-x86 systems that use system memory for
> - the framebuffer, pass the 'ram' option so that it is
> - mapped with the correct attributes.
> + memory mapped framebuffer (if available).
If somebody passes those (legacy) options, what will happen?
...
> config EFI_EARLYCON
> - def_bool y
> - depends on SERIAL_EARLYCON && !ARM && !IA64
> - select FONT_SUPPORT
> - select ARCH_USE_MEMREMAP_PROT
> + bool "EFI early console support"
> + depends on FB_EARLYCON && !IA64
This doesn't sound right. Previously on my configuration it was
selected automatically, now I need to select it explicitly? I mean
that for me EFI_EARLYCON should be selected by default as it was
before.
...
> +static int __init simplefb_earlycon_remap_fb(void)
> +{
> + int is_ram;
+ blank line.
> + /* bail if there is no bootconsole or it has been disabled already */
> + if (!earlycon_console || !(earlycon_console->flags & CON_ENABLED))
> + return 0;
> +
> + is_ram = region_intersects(info.phys_base, info.size,
> + IORESOURCE_SYSTEM_RAM, IORES_DESC_NONE);
> + is_ram = is_ram == REGION_INTERSECTS;
Was it in the original code? Otherwise, I would go with plain conditional:
if (region_intersects())
base = ...
else
base = ...
> + info.virt_base = memremap(info.phys_base, info.size,
> + is_ram ? MEMREMAP_WB : MEMREMAP_WC);
> +
> + return info.virt_base ? 0 : -ENOMEM;
> +}
...
> +static void simplefb_earlycon_write_char(u8 *dst, unsigned char c, unsigned int h)
> +{
> + const u8 *src;
> + int m, n, bytes;
> + u8 x;
> +
> + bytes = BITS_TO_BYTES(font->width);
> + src = font->data + c * font->height * bytes + h * bytes;
> +
> + for (m = 0; m < font->width; m++) {
> + n = m % 8;
> + x = *(src + m / 8);
> + if ((x >> (7 - n)) & 1)
> + memset(dst, 0xff, (info.depth / 8));
> + else
> + memset(dst, 0, (info.depth / 8));
> + dst += (info.depth / 8);
> + }
> +}
Wondering if we already have something like this in DRM/fbdev and can
split into a generic helper.
...
> + ret = sscanf(device->options, "%u,%u,%u", &info.x, &info.y, &info.depth);
> + if (ret != 3)
> + return -ENODEV;
Don't we have some standard template of this, something like XxYxD,
where X, Y, and D are respective decimal numbers?
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists