Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: sunxi graphic console, try 2

Looks good to me! Thanks for your patience with me on this one.


On Sat, 7 Apr 2018, Manuel Bouyer wrote:

with Jared's feedback, I reimplemented console handling for the sunxi graphic
drivers. There are 3 problems to solve:
- proper handling for console=xxx in the bootargs. I want to switch from
 graphic to serial, or back, from bootargs without changing
 /chosen/stdout-path entry in the device tree each time.
 The kernel can change stdout-path early in the boot process,
 and at this time it's not pratical to make it point to anything
 but serial or /chosen/framebuffer (we don't want to parse the whole
 device tree at this time).
 So I just change sunxi_platform_bootstrap() to understand console=serial
 in bootargs, so is stdout-path points to some graphic device in the
 device tree we can switch back to serial.

- attaching the graphic console to the graphic pipeline instead of simplefb.
 The graphic driver doesn't want to claim the consle at FDT_CONSOLE() time,
 because at this time it doens't know if it will be active or not
 (not to mention which of the 2 pipelines will be active, and will be console).
 In addition, simplefb may be functional until the graphic driver takes over.
 So in sunxi_debe I use FDT_CONSOLE() only to remember the
 simple-framebuffer phandle, which sunxi_debe will need to decide if
 it's console later.

- preventing simplefb from attaching. Once the graphic drivers have attached
 simplefb is not functional any more. So even if there is an active
 simple-framebuffer compatible not in the fdt, we should not attach it.
 I could add a sunxi_simplefb driver which return a higther match
 score, but I don't like the idea of adding a void driver just
 to prevent another one from attaching. Among others, this could
 cause strange effects if the kernel config omits it, hard to debug as
 this is touching the console.
 Basically we have several fdt nodes pointing to the same hardware,
 and we don't want to use them all.
 I added public fdt functions to explicitely inactivate arbitrary
 fdt nodes (here I remove them from the node list but that's implementation
 detail). There is fdt_remove_bycompat(const char *[]) to remove nodes
 matching on compatible strings; for completeness I also added
 fdt_remove_byhandle(int) but I don't need it.

Manuel Bouyer <bouyer%antioche.eu.org@localhost>
    NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index