On Fri, Oct 1, 2021 at 8:27 AM Olof Johansson [off-list ref] wrote:

On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann [off-list ref] wrote:

quoted

On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven [off-list ref] wrote:

quoted

On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan [off-list ref] wrote:

quoted

GIC and arch timer. Basically the minimal kernel would need a timer
for the scheduler tick and IRQ controller to get the timer IRQ and the
fixed clock driver if the archtimer uses one to get its frequency and
the early UART console is pointless as a module (so build it in to
allow debugging/development).

And then all new drivers, we should make sure are implemented as
tristate drivers. And we can go back and slowly work on converting
existing drivers to modules (community effort -- not one person or
entity) -- at least the ones where the author has hardware or ones
where the change is very likely to be correct and someone else is
willing to test it. We'll never be able to support some/all ARM32 (do
they even have a GIC/arch timer standard?), but at least for ARM64,
this seems like a viable goal.

Cortex-A7/A15 and later have GIC and architectured timer, so it should
work for contemporary systems.
Cortex-A9 systems may have GIC, and TWD and/or Global Timer (but I've
seen SoCs where the interrupt for the latter was not wired :-(.

There are a number of well-known examples even with 64-bit chips or
Cortex-A7/A15 based SoCs that can't use the architected timer,
irqchip or iommu.

Apple M1, Broadcom BCM283x, Samsung Exynos5 and
some Hisilicon server parts come to mind, I'm sure there
are more.

There's also more and more movement towards having coprocessors with
standardized interfaces dealing with this functionality. We're
currently at the point where they have coprocessors with
non-standardized interfaces, and it's useful to keep encouraging
convergence in this area to everybody's benefit. I don't find it
particularly useful to make life easier for the custom solutions at
the expense of others like this patchset does, when that's (just
beyond? on?) the horizon.

quoted

quoted

What are the plans for other architectures?
I've seen similar patches being applied for e.g. MIPS.

There is some work in the more actively maintained MIPS
platforms to make those behave more like Arm/powerpc/riscv/m68k
platforms, using a single image and moving drivers into modules.
Most MIPS platforms seem unlikely to get updated to this,
and will continue to require a SoC specific kernel binary forever,
similar to the renesas superh platforms. Most of the less
common architectures (arc, csky, hexagon, nios2, xtensa,
microblaze, nds32, openrisc, sparc/leon) are way behind that
though, and generally don't work at all without out-of-tree
code.

One of the arguments for needing some of these core drivers in-kernel
is that some platforms boot at very conservative DVFS operating
points, to a degree that you really want to turn up the CPU clocks
fairly early during boot.

If you don't have the drivers built-in, you can't do that and/or you
create possible fragile or awkward inter-module dependencies with
deferred probing, etc. We do care about boot time enough to prefer to
just build them in for this reason.

Go look at a Pixel 5, we got this working just fine with all these
drivers as modules and we definitely care about boot time. You just
need to load your CPU freq driver and the other ones it needs early
on. And with fw_devlink=on (default in upstream), there's hardly any
deferred probing.

If vmlinux binary size is a concern, maybe it's time to consider
splitting the drivers into a bare-minimum piece that's not a module
for early setup, and the rest that can be loaded post-boot.

Isn't this literally what I was suggesting with my
ARM64_MINIMAL_GENERIC_KERNEL suggestion? Build in all the bare minimum
drivers that are needed before module loading can happen? You'd just
select them all under that config. And any existing platform that
wants to use it would break up their drivers into modules and switch
to it.

-Saravana

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel