[v2,00/17] Modularizing Versatile Express

Message ID 20200429205825.10604-1-robh@kernel.org
Headers show
Series
  • Modularizing Versatile Express
Related show

Message

Rob Herring April 29, 2020, 8:58 p.m.
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.

A complete git branch is here[1]. Tested on Fast Model FVP Rev C.

v2:
The major change is a boot fix for 32-bit VExpress platforms with patch 3.
I also dropped 'power/reset: vexpress: Support building as a module' as it
was incomplete and not needed for this series.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git vexpress-modules-v4

Rob Herring (16):
  ARM: vexpress: Move vexpress_flags_set() into arch code
  arm64: vexpress: Don't select CONFIG_POWER_RESET_VEXPRESS
  amba: Retry adding deferred devices at late_initcall
  clk: versatile: Rework kconfig structure
  clk: versatile: Only enable SP810 on 32-bit by default
  clk: vexpress-osc: Use the devres clock API variants
  clk: vexpress-osc: Support building as a module
  mfd: vexpress-sysreg: Drop selecting CONFIG_CLKSRC_MMIO
  mfd: vexpress-sysreg: Drop unused syscon child devices
  mfd: vexpress-sysreg: Use devres API variants
  mfd: vexpress-sysreg: Support building as a module
  bus: vexpress-config: Merge vexpress-syscfg into vexpress-config
  bus: vexpress-config: simplify config bus probing
  vexpress: Move setting master site to vexpress-config bus
  bus: vexpress-config: Support building as module
  ARM: vexpress: Don't select VEXPRESS_CONFIG

 arch/arm/mach-integrator/Kconfig         |   1 -
 arch/arm/mach-realview/Kconfig           |   1 -
 arch/arm/mach-versatile/Kconfig          |   1 -
 arch/arm/mach-vexpress/Kconfig           |   4 -
 arch/arm/mach-vexpress/core.h            |   1 +
 arch/arm/mach-vexpress/dcscb.c           |   1 +
 arch/arm/mach-vexpress/v2m.c             |  23 ++
 arch/arm64/Kconfig.platforms             |   3 -
 drivers/amba/bus.c                       |  14 +-
 drivers/bus/Kconfig                      |   2 +-
 drivers/bus/vexpress-config.c            | 354 ++++++++++++++++++-----
 drivers/clk/Makefile                     |   2 +-
 drivers/clk/versatile/Kconfig            |  24 +-
 drivers/clk/versatile/clk-vexpress-osc.c |  20 +-
 drivers/mfd/Kconfig                      |   5 +-
 drivers/mfd/vexpress-sysreg.c            |  99 +------
 drivers/misc/Kconfig                     |   9 -
 drivers/misc/Makefile                    |   1 -
 drivers/misc/vexpress-syscfg.c           | 280 ------------------
 include/linux/vexpress.h                 |  30 --
 20 files changed, 354 insertions(+), 521 deletions(-)
 delete mode 100644 drivers/misc/vexpress-syscfg.c


base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
--
2.20.1

Comments

Rob Herring July 8, 2020, 4:39 p.m. | #1
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
Daniel Thompson July 9, 2020, 11:33 a.m. | #2
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.