| Message ID | 20200429205825.10604-1-robh@kernel.org |
|---|---|
| Headers | show |
| Series | Modularizing Versatile Express | expand |
On Wed, Jun 17, 2020 at 9:08 AM Daniel Thompson <daniel.thompson@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
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@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.