Message-ID: <CAOesGMhHK7Z8Ki+UFRi24dXTdk4=YC6ExneOnfkVmG2HFiVMKw@mail.gmail.com>
Date:   Fri, 1 Oct 2021 08:27:02 -0700
From:   Olof Johansson <olof@...om.net>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Saravana Kannan <saravanak@...gle.com>,
        Will McVicker <willmcvicker@...gle.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>,
        Russell King <linux@...linux.org.uk>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        Tomasz Figa <tomasz.figa@...il.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alessandro Zummo <a.zummo@...ertech.it>,
        Alexandre Belloni <alexandre.belloni@...tlin.com>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Lee Jones <lee.jones@...aro.org>,
        "Cc: Android Kernel" <kernel-team@...roid.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-samsung-soc <linux-samsung-soc@...r.kernel.org>,
        linux-clk <linux-clk@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-rtc@...r.kernel.org
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs

On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@...gle.com> 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

Powered by blists - more mailing lists