[PATCH v2 00/17] Modularizing Versatile Express

[Daniel Thompson]

On Wed, Jul 08, 2020 at 10:39:43AM -0600, Rob Herring wrote:
> 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

"fw_devlink=on", right?

I didn't see any difference on time to console activation with this
enabled.


> 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 ???.

I don't disagree on "the right thing to do" although I am a little
surprised to see the old hack removed a replacement is ready. IIUC
the modularization for GKI doesn't require them to be changed.


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

To be honest I have relaxed a few expectations in my test harness and
have already moved on ;-).

Right now the console will not come up until after we have decompressed
the ramdisk even when we have configure the kernel to have a rich set of
console drivers built in. That does feel pretty uncomfortable as a user,
especially if you have a large initrd but the test suite doesn't mind!


Daniel.