On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > > 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. > > 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. 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. -Olof
