| Message ID | 20200429205825.10604-1-robh@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Modularizing Versatile Express | expand |
Hi, On Wed, Apr 29, 2020 at 03:58:09PM -0500, Rob Herring wrote: > [...] > > 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. Ok, please also drop me from Cc for v3 :) Thanks, -- Sebastian
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. > > A complete git branch is here[1]. Tested on Fast Model FVP Rev C. I am assuming you will send pull request to ARM SoC guys directly. Let me know what's the plan if that's not the case. -- Regards, Sudeep
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. 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? Daniel. > > 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
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.