From: Tomasz Figa <tomasz.figa@gmail.com>
To: Saravana Kannan <saravanak@google.com>
Cc: Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@arndb.de>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Will McVicker <willmcvicker@google.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Chanwoo Choi <cw00.choi@samsung.com>,
Linus Walleij <linus.walleij@linaro.org>,
Alessandro Zummo <a.zummo@towertech.it>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
John Stultz <john.stultz@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Lee Jones <lee.jones@linaro.org>,
"Cc: Android Kernel" <kernel-team@android.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
linux-clk <linux-clk@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
linux-rtc@vger.kernel.org
Subject: Re: [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs
Date: Sat, 2 Oct 2021 10:47:13 +0900 [thread overview]
Message-ID: <CA+Ln22FzMvoyANjBN9hPKWXzgDip+Yi3Re3jZf3BdgMywU47xg@mail.gmail.com> (raw)
In-Reply-To: <CAGETcx_UFLCwmqs_d5c8JY8Je9r=jy=KnELz1h91Qbrw9z+kaw@mail.gmail.com>
2021年10月2日(土) 4:26 Saravana Kannan <saravanak@google.com>:
>
> On Fri, Oct 1, 2021 at 8:27 AM Olof Johansson <olof@lixom.net> wrote:
> >
> > On Fri, Oct 1, 2021 at 2:01 AM Arnd Bergmann <arnd@arndb.de> wrote:
> > >
> > > On Fri, Oct 1, 2021 at 10:19 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Oct 1, 2021 at 7:24 AM Saravana Kannan <saravanak@google.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.
>
> 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.
I think the point here is that pinctrl and clk are considered a part
of "bare minimum" for Exynos.
next prev parent reply other threads:[~2021-10-02 1:47 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-28 23:56 [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs Will McVicker
2021-09-28 23:56 ` [PATCH v2 01/12] arm64: don't have ARCH_EXYNOS select EXYNOS_CHIPID Will McVicker
2021-09-29 13:58 ` (subset) " Krzysztof Kozlowski
2021-09-29 14:00 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 02/12] timekeeping: add API for getting timekeeping_suspended Will McVicker
2021-09-29 3:42 ` John Stultz
2021-09-29 20:01 ` Will McVicker
2021-09-29 20:46 ` John Stultz
2021-09-30 18:31 ` Will McVicker
2021-09-28 23:56 ` [PATCH v2 03/12] clk: samsung: add support for CPU clocks Will McVicker
2021-09-28 23:56 ` [PATCH v2 04/12] clk: samsung: exynos5433: update apollo and atlas clock probing Will McVicker
2021-09-28 23:56 ` [PATCH v2 05/12] clk: export __clk_lookup Will McVicker
2021-10-08 4:31 ` Stephen Boyd
2021-09-28 23:56 ` [PATCH v2 06/12] clk: samsung: modularize exynos arm64 clk drivers Will McVicker
2021-09-28 23:56 ` [PATCH v2 07/12] clk: samsung: set exynos arm64 clk driver as tristate Will McVicker
2021-09-29 13:09 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 08/12] pinctrl: samsung: modularize the ARM and ARM64 pinctrls Will McVicker
2021-09-29 2:01 ` Chanho Park
2021-09-28 23:56 ` [PATCH v2 09/12] pinctrl: samsung: set PINCTRL_EXYNOS and PINCTRL_SAMSUNG as tristate Will McVicker
2021-09-28 23:56 ` [PATCH v2 10/12] soc: samsung: pmu: modularize the Exynos ARMv8 PMU driver Will McVicker
2021-09-29 13:11 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 11/12] soc: samsung: pm_domains: modularize EXYNOS_PM_DOMAINS Will McVicker
2021-09-29 13:36 ` Krzysztof Kozlowski
2021-09-28 23:56 ` [PATCH v2 12/12] ARM: rtc: remove HAVE_S3C_RTC in favor of direct dependencies Will McVicker
2021-09-29 11:52 ` Alexandre Belloni
2021-09-29 13:02 ` [PATCH v2 00/12] arm64: Kconfig: Update ARCH_EXYNOS select configs Krzysztof Kozlowski
2021-09-29 19:48 ` Will McVicker
2021-09-30 6:14 ` Krzysztof Kozlowski
2021-09-30 9:01 ` Arnd Bergmann
2021-09-30 9:30 ` Lee Jones
2021-09-30 10:33 ` Krzysztof Kozlowski
2021-09-30 12:34 ` Lee Jones
2021-09-30 12:38 ` Krzysztof Kozlowski
2021-09-30 10:05 ` Geert Uytterhoeven
2021-09-30 9:23 ` Lee Jones
2021-09-30 10:17 ` Geert Uytterhoeven
2021-09-30 10:56 ` Lee Jones
2021-09-30 11:25 ` Geert Uytterhoeven
2021-09-30 12:08 ` Lee Jones
2021-09-30 16:09 ` Geert Uytterhoeven
2021-09-30 10:52 ` Krzysztof Kozlowski
2021-09-30 12:32 ` Lee Jones
2021-09-30 11:01 ` Tomasz Figa
2021-09-30 11:27 ` Geert Uytterhoeven
2021-09-30 11:51 ` Lee Jones
2021-09-30 12:10 ` Tomasz Figa
2021-09-30 12:15 ` Krzysztof Kozlowski
2021-09-30 12:45 ` Lee Jones
2021-10-01 4:01 ` Christoph Hellwig
2021-10-01 4:52 ` Saravana Kannan
2021-10-01 4:55 ` Christoph Hellwig
2021-09-30 12:21 ` Krzysztof Kozlowski
2021-09-30 12:39 ` Lee Jones
2021-09-30 13:08 ` Krzysztof Kozlowski
2021-09-30 13:29 ` Lee Jones
2021-09-30 16:12 ` Geert Uytterhoeven
2021-09-30 16:21 ` Lee Jones
2021-09-30 16:26 ` Geert Uytterhoeven
2021-09-30 18:02 ` Will McVicker
2021-10-01 4:04 ` Christoph Hellwig
2021-10-01 4:52 ` Olof Johansson
2021-10-01 5:23 ` Saravana Kannan
2021-10-01 5:35 ` Olof Johansson
2021-10-01 5:59 ` Will McVicker
2021-10-01 8:01 ` Krzysztof Kozlowski
2021-10-01 6:02 ` Saravana Kannan
2021-10-01 6:27 ` Olof Johansson
2021-10-01 6:30 ` Olof Johansson
2021-10-01 12:00 ` Arnd Bergmann
2021-10-01 12:31 ` Lee Jones
2021-10-01 15:43 ` Olof Johansson
2021-10-01 11:38 ` Linus Walleij
2021-10-01 11:59 ` Geert Uytterhoeven
2021-10-01 15:59 ` Olof Johansson
2021-10-01 16:51 ` Will McVicker
2021-10-01 17:15 ` Olof Johansson
2021-10-01 17:48 ` Will McVicker
2021-10-01 8:19 ` Geert Uytterhoeven
2021-10-01 9:00 ` Arnd Bergmann
2021-10-01 15:27 ` Olof Johansson
2021-10-01 19:26 ` Saravana Kannan
2021-10-02 1:47 ` Tomasz Figa [this message]
2021-10-02 21:03 ` Olof Johansson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+Ln22FzMvoyANjBN9hPKWXzgDip+Yi3Re3jZf3BdgMywU47xg@mail.gmail.com \
--to=tomasz.figa@gmail.com \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=cw00.choi@samsung.com \
--cc=geert@linux-m68k.org \
--cc=john.stultz@linaro.org \
--cc=kernel-team@android.com \
--cc=krzysztof.kozlowski@canonical.com \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mturquette@baylibre.com \
--cc=olof@lixom.net \
--cc=s.nawrocki@samsung.com \
--cc=saravanak@google.com \
--cc=sboyd@kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).