[PATCH v2 00/17] Modularizing Versatile Express

[Rob Herring]

On Wed, Jun 17, 2020 at 9:08 AM Daniel Thompson
<daniel.thompson at linaro.org> wrote:
>
> On Wed, Apr 29, 2020 at 03:58:09PM -0500, Rob Herring wrote:
> > This series enables building various Versatile Express platform drivers
> > as modules. The primary target is the Fast Model FVP which is supported
> > in Android. As Android is moving towards their GKI, or generic kernel,
> > the hardware support has to be in modules. Currently ARCH_VEXPRESS
> > enables several built-in only drivers. Some of these are needed, but
> > some are only needed for older 32-bit VExpress platforms and can just
> > be disabled. For FVP, the pl111 display driver is needed. The pl111
> > driver depends on vexpress-osc clocks which had a dependency chain of
> > vexpress-config --> vexpress-syscfg --> vexpress-sysreg. These
> > components relied on fixed initcall ordering and didn't support deferred
> > probe which would have complicated making them modules. All these levels
> > of abstraction are needlessly complicated, so this series simplifies
> > things a bit by merging the vexpress-config and vexpress-syscfg
> > functionality.
> >
> > There's a couple of other pieces to this which I've sent out separately
> > as they don't have dependencies with this series. The cross subsystem
> > dependencies in this series are mainly the ordering of enabling drivers
> > as modules.
>
> This series results in the vexpress-a15 console not coming up until very
> late in the boot process because the console arch_initcall() ends up
> being deferred because it's dependencies are no longer use
> core_initcall() to ensure they get in first.

Which was a hack...

> Is there a problem registering vexpress-osc, vexpress-sysreg and
> vexpress-config as core_initcall's so the console behaves nicely
> when they are all compiled as built-ins?

I think the correct way to solve this is with devlinks which reduces
the deferred probes. Can you see if that's better? That's still off by
default and needs a kernel command line option. That may just get the
console up at an earlier initcall level, but not before other h/w
drivers. I think having some way to prioritize probe order without
initcall hacks would be good. Then you could prioritize a console or
splash screen or ???.

Also, if you really need an early console, then use earlycon.

Rob