[1/2] arm64: change ARCH_SPRD Kconfig to tristate

Commit Message

Chunyan Zhang March 5, 2020, 10:32 a.m. UTC

From: Chunyan Zhang <[e-mail]>

The default value of Kconfig for almost all sprd drivers are the same with
ARCH_SPRD, making these drivers built as modules as default would be easier
if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.

Signed-off-by: Chunyan Zhang <[e-mail]>
---
 arch/arm64/Kconfig.platforms | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Geert Uytterhoeven March 9, 2020, 8:03 a.m. UTC | #1

Hi Chunyan.

On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> From: Chunyan Zhang <[e-mail]>
>
> The default value of Kconfig for almost all sprd drivers are the same with
> ARCH_SPRD, making these drivers built as modules as default would be easier
> if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
>
> Signed-off-by: Chunyan Zhang <[e-mail]>

Can you actually boot a kernel on a Spreadtrum platform when all platform
and driver support is modular?

> +++ b/arch/arm64/Kconfig.platforms
> @@ -249,7 +249,7 @@ config ARCH_TEGRA
>           This enables support for the NVIDIA Tegra SoC family.
>
>  config ARCH_SPRD
> -       bool "Spreadtrum SoC platform"
> +       tristate "Spreadtrum SoC platform"
>         help
>           Support for Spreadtrum ARM based SoCs

Gr{oetje,eeting}s,

                        Geert

Chunyan Zhang March 9, 2020, 8:32 a.m. UTC | #2

Hi Geert,

On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
>
> Hi Chunyan.
>
> On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > From: Chunyan Zhang <[e-mail]>
> >
> > The default value of Kconfig for almost all sprd drivers are the same with
> > ARCH_SPRD, making these drivers built as modules as default would be easier
> > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> >
> > Signed-off-by: Chunyan Zhang <[e-mail]>
>
> Can you actually boot a kernel on a Spreadtrum platform when all platform
> and driver support is modular?

Yes, even if all drivers are modular.
But I hope serial can be builtin, then I can have a console to see
kernel output before loading modules.
Also, this's what Google GKI [1] asked :)

Regards,
Chunyan

[1] https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/

>
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -249,7 +249,7 @@ config ARCH_TEGRA
> >           This enables support for the NVIDIA Tegra SoC family.
> >
> >  config ARCH_SPRD
> > -       bool "Spreadtrum SoC platform"
> > +       tristate "Spreadtrum SoC platform"
> >         help
> >           Support for Spreadtrum ARM based SoCs
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Geert Uytterhoeven March 9, 2020, 10:32 a.m. UTC | #3

Hi Chunyan,

On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > From: Chunyan Zhang <[e-mail]>
> > >
> > > The default value of Kconfig for almost all sprd drivers are the same with
> > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > >
> > > Signed-off-by: Chunyan Zhang <[e-mail]>
> >
> > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > and driver support is modular?
>
> Yes, even if all drivers are modular.

Cool. No hard dependencies on e.g. regulators that are turned off when
unused?

> But I hope serial can be builtin, then I can have a console to see
> kernel output before loading modules.

No dependency on the clock driver?
Oh, I see you have a hack in the serial driver, to assume default
values when the serial port's parent clock is not found.  That may
limit use of the other serial ports, depending on the actual serial
hardware.
And on Sharkl64, the serial port's clock is a fixed-clock anyway, so
you don't even need the hack.

But in general you cannot rely on that, especially if your SoC has clock
and/or power domains.

BTW, what about the watchdog driver? That one does need a clock, and
loading it too late will reboot your system.

> Also, this's what Google GKI [1] asked :)
>
> Regards,
> Chunyan
>
> [1] https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/

Let's see how having everything modular works out on an SoC where all
hardware is part of a clock and power domain.

Thanks!

Gr{oetje,eeting}s,

                        Geert

Sandeep Patil March 10, 2020, 4:19 a.m. UTC | #4

Hi Geert,

On Mon, Mar 09, 2020 at 11:32:06AM +0100, Geert Uytterhoeven wrote:
> Hi Chunyan,
> 
> On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> > On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > > From: Chunyan Zhang <[e-mail]>
> > > >
> > > > The default value of Kconfig for almost all sprd drivers are the same with
> > > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > > >
> > > > Signed-off-by: Chunyan Zhang <[e-mail]>
> > >
> > > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > > and driver support is modular?
> >
> > Yes, even if all drivers are modular.
> 
> Cool. No hard dependencies on e.g. regulators that are turned off when
> unused?
> 
> > But I hope serial can be builtin, then I can have a console to see
> > kernel output before loading modules.
> 
> No dependency on the clock driver?
> Oh, I see you have a hack in the serial driver, to assume default
> values when the serial port's parent clock is not found.  That may
> limit use of the other serial ports, depending on the actual serial
> hardware.
> And on Sharkl64, the serial port's clock is a fixed-clock anyway, so
> you don't even need the hack.
> 
> But in general you cannot rely on that, especially if your SoC has clock
> and/or power domains.
> 
> BTW, what about the watchdog driver? That one does need a clock, and
> loading it too late will reboot your system.
> 
> > Also, this's what Google GKI [1] asked :)
> >
> > Regards,
> > Chunyan
> >
> > [1] https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/
> 
> Let's see how having everything modular works out on an SoC where all
> hardware is part of a clock and power domain.

I'm curious, are there any problems that we should be aware of? We know about
the regulator sync state and consumer-supplier dependencies. [1]

(Adding Saravana inline)

Thanks,
- ssp

Sandeep Patil March 10, 2020, 4:27 a.m. UTC | #5

On Mon, Mar 09, 2020 at 09:19:03PM -0700, Sandeep Patil wrote:
> Hi Geert,
> 
> On Mon, Mar 09, 2020 at 11:32:06AM +0100, Geert Uytterhoeven wrote:
> > Hi Chunyan,
> > 
> > On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> > > On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > > > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > > > From: Chunyan Zhang <[e-mail]>
> > > > >
> > > > > The default value of Kconfig for almost all sprd drivers are the same with
> > > > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > > > >
> > > > > Signed-off-by: Chunyan Zhang <[e-mail]>
> > > >
> > > > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > > > and driver support is modular?
> > >
> > > Yes, even if all drivers are modular.
> > 
> > Cool. No hard dependencies on e.g. regulators that are turned off when
> > unused?
> > 
> > > But I hope serial can be builtin, then I can have a console to see
> > > kernel output before loading modules.
> > 
> > No dependency on the clock driver?
> > Oh, I see you have a hack in the serial driver, to assume default
> > values when the serial port's parent clock is not found.  That may
> > limit use of the other serial ports, depending on the actual serial
> > hardware.
> > And on Sharkl64, the serial port's clock is a fixed-clock anyway, so
> > you don't even need the hack.
> > 
> > But in general you cannot rely on that, especially if your SoC has clock
> > and/or power domains.
> > 
> > BTW, what about the watchdog driver? That one does need a clock, and
> > loading it too late will reboot your system.
> > 
> > > Also, this's what Google GKI [1] asked :)
> > >
> > > Regards,
> > > Chunyan
> > >
> > > [1] https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/
> > 
> > Let's see how having everything modular works out on an SoC where all
> > hardware is part of a clock and power domain.
> 
> I'm curious, are there any problems that we should be aware of? We know about
> the regulator sync state and consumer-supplier dependencies. [1]
> 
> (Adding Saravana inline)
> 

(oops, forgot to paste the link to presentation)
1. https://linuxplumbersconf.org/event/4/contributions/402/attachments/320/544/Solving_issues_associated_with_modules_and_supplier-consumer_dependencies.pdf

Geert Uytterhoeven March 10, 2020, 8:47 a.m. UTC | #6

Hi Sandeep,

On Tue, Mar 10, 2020 at 5:27 AM Sandeep Patil <[e-mail]> wrote:
> On Mon, Mar 09, 2020 at 09:19:03PM -0700, Sandeep Patil wrote:
> > On Mon, Mar 09, 2020 at 11:32:06AM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> > > > On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > > > > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > > > > From: Chunyan Zhang <[e-mail]>
> > > > > >
> > > > > > The default value of Kconfig for almost all sprd drivers are the same with
> > > > > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > > > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > > > > >
> > > > > > Signed-off-by: Chunyan Zhang <[e-mail]>
> > > > >
> > > > > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > > > > and driver support is modular?
> > > >
> > > > Yes, even if all drivers are modular.
> > >
> > > Cool. No hard dependencies on e.g. regulators that are turned off when
> > > unused?
> > >
> > > > But I hope serial can be builtin, then I can have a console to see
> > > > kernel output before loading modules.
> > >
> > > No dependency on the clock driver?
> > > Oh, I see you have a hack in the serial driver, to assume default
> > > values when the serial port's parent clock is not found.  That may
> > > limit use of the other serial ports, depending on the actual serial
> > > hardware.
> > > And on Sharkl64, the serial port's clock is a fixed-clock anyway, so
> > > you don't even need the hack.
> > >
> > > But in general you cannot rely on that, especially if your SoC has clock
> > > and/or power domains.

So I gave it a try on my platform (R-Car), with just the serial driver
builtin.  I can see the kernel booting using earlycon.
However, the serial driver is never probed, as the pin control driver is
missing. And after that, it would need the clock domain (power domain
and clock drivers), and more serial clock inputs (clock driver, again).
Fortunately DMA is optional (dmac driver, and optional iommu driver).

I guess core platform-specific drivers can be loaded from the initramfs,
after which the serial driver would be probed, finally.  If the
initramfs includes a storage driver, anything else can be loaded from
e.g. eMMC.

> > > > Also, this's what Google GKI [1] asked :)

> > > > [1] https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/
> > >
> > > Let's see how having everything modular works out on an SoC where all
> > > hardware is part of a clock and power domain.
> >
> > I'm curious, are there any problems that we should be aware of? We know about
> > the regulator sync state and consumer-supplier dependencies. [1]

Care must be taken, as probe deferral behaves differently after
late_initcall time (see driver_deferred_probe_check_state_continue),
which may cause issues with "optional" components like DMA controllers
and IOMMUs.  Unused clocks and power domains are not turned off,
unlike for the builtin case.

On some SoCs, even the interrupt controller (GIC) may be part of a clock
and/or power domain, while the GIC driver is not aware of that.
For the clock, that is handled by CLK_IS_CRITICAL in the clock driver.
For power domains, that is not handled explicitly on Renesas SoCs, as
the GIC is always in the same power domain as other devices that are
Runtime PM-aware.  But if those devices would have modular drivers, that
power domain could still be turned off.

So on a modern ARM system, I assume a generic kernel with no
vendor-specific drivers builtin can indeed work.
On older systems, without an ARM architectured timer, you will need at
least the platform-specific timer driver (and the clock driver) builtin.
Assumed the timer's power domain has been powered up by the firmware.

> (oops, forgot to paste the link to presentation)
> 1. https://linuxplumbersconf.org/event/4/contributions/402/attachments/320/544/Solving_issues_associated_with_modules_and_supplier-consumer_dependencies.pdf

Thanks, hadn't seen that presentation.
It matches my understanding.

Gr{oetje,eeting}s,

                        Geert

Orson Zhai March 10, 2020, 9:41 a.m. UTC | #7

Hi Geert,

On Mon, Mar 9, 2020 at 6:32 PM Geert Uytterhoeven <[e-mail]> wrote:
>
> Hi Chunyan,
>
> On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> > On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > > From: Chunyan Zhang <[e-mail]>
> > > >
> > > > The default value of Kconfig for almost all sprd drivers are the same with
> > > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > > >
> > > > Signed-off-by: Chunyan Zhang <[e-mail]>
> > >
> > > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > > and driver support is modular?
> >
> > Yes, even if all drivers are modular.
>
> Cool. No hard dependencies on e.g. regulators that are turned off when
> unused?
>
> > But I hope serial can be builtin, then I can have a console to see
> > kernel output before loading modules.
>
> No dependency on the clock driver?
> Oh, I see you have a hack in the serial driver, to assume default
> values when the serial port's parent clock is not found.  That may
> limit use of the other serial ports, depending on the actual serial
> hardware.

There is an function named "sprd_uart_is_console()" in the driver
code. So the hack could be only applied when the
port is identified as console. And other ports might return
PROBE_DEFER until the clock is ready.

Could it work out of the limitation?

-Orson

> And on Sharkl64, the serial port's clock is a fixed-clock anyway, so
> you don't even need the hack.
>
> But in general you cannot rely on that, especially if your SoC has clock
> and/or power domains.
>
> BTW, what about the watchdog driver? That one does need a clock, and
> loading it too late will reboot your system.
>
> > Also, this's what Google GKI [1] asked :)
> >
> > Regards,
> > Chunyan
> >
> > [1] https://arstechnica.com/gadgets/2019/11/google-outlines-plans-for-mainline-linux-kernel-support-in-android/
>
> Let's see how having everything modular works out on an SoC where all
> hardware is part of a clock and power domain.
>
> Thanks!
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Geert Uytterhoeven March 10, 2020, 9:52 a.m. UTC | #8

Hi Orson,

On Tue, Mar 10, 2020 at 10:41 AM Orson Zhai <[e-mail]> wrote:
> On Mon, Mar 9, 2020 at 6:32 PM Geert Uytterhoeven <[e-mail]> wrote:
> > On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> > > On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > > > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > > > From: Chunyan Zhang <[e-mail]>
> > > > >
> > > > > The default value of Kconfig for almost all sprd drivers are the same with
> > > > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > > > >
> > > > > Signed-off-by: Chunyan Zhang <[e-mail]>
> > > >
> > > > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > > > and driver support is modular?
> > >
> > > Yes, even if all drivers are modular.
> >
> > Cool. No hard dependencies on e.g. regulators that are turned off when
> > unused?
> >
> > > But I hope serial can be builtin, then I can have a console to see
> > > kernel output before loading modules.
> >
> > No dependency on the clock driver?
> > Oh, I see you have a hack in the serial driver, to assume default
> > values when the serial port's parent clock is not found.  That may
> > limit use of the other serial ports, depending on the actual serial
> > hardware.
>
> There is an function named "sprd_uart_is_console()" in the driver
> code. So the hack could be only applied when the
> port is identified as console. And other ports might return
> PROBE_DEFER until the clock is ready.
>
> Could it work out of the limitation?

Yes, that could work.  You also have only a single SPRD_DEFAULT_SOURCE_CLK,
which makes it simple to handle.
For other SoCs, there may be a variation of possible values, depending on
SoC and/or board.

Gr{oetje,eeting}s,

                        Geert

Orson Zhai March 10, 2020, 10:13 a.m. UTC | #9

On Tue, Mar 10, 2020 at 5:52 PM Geert Uytterhoeven <[e-mail]> wrote:
>
> Hi Orson,
>
> On Tue, Mar 10, 2020 at 10:41 AM Orson Zhai <[e-mail]> wrote:
> > On Mon, Mar 9, 2020 at 6:32 PM Geert Uytterhoeven <[e-mail]> wrote:
> > > On Mon, Mar 9, 2020 at 9:32 AM Chunyan Zhang <[e-mail]> wrote:
> > > > On Mon, 9 Mar 2020 at 16:03, Geert Uytterhoeven <[e-mail]> wrote:
> > > > > On Thu, Mar 5, 2020 at 11:33 AM Chunyan Zhang <[e-mail]> wrote:
> > > > > > From: Chunyan Zhang <[e-mail]>
> > > > > >
> > > > > > The default value of Kconfig for almost all sprd drivers are the same with
> > > > > > ARCH_SPRD, making these drivers built as modules as default would be easier
> > > > > > if we can set ARCH_SPRD as 'm', so this patch change ARCH_SPRD to tristate.
> > > > > >
> > > > > > Signed-off-by: Chunyan Zhang <[e-mail]>
> > > > >
> > > > > Can you actually boot a kernel on a Spreadtrum platform when all platform
> > > > > and driver support is modular?
> > > >
> > > > Yes, even if all drivers are modular.
> > >
> > > Cool. No hard dependencies on e.g. regulators that are turned off when
> > > unused?
> > >
> > > > But I hope serial can be builtin, then I can have a console to see
> > > > kernel output before loading modules.
> > >
> > > No dependency on the clock driver?
> > > Oh, I see you have a hack in the serial driver, to assume default
> > > values when the serial port's parent clock is not found.  That may
> > > limit use of the other serial ports, depending on the actual serial
> > > hardware.
> >
> > There is an function named "sprd_uart_is_console()" in the driver
> > code. So the hack could be only applied when the
> > port is identified as console. And other ports might return
> > PROBE_DEFER until the clock is ready.
> >
> > Could it work out of the limitation?
>
> Yes, that could work.  You also have only a single SPRD_DEFAULT_SOURCE_CLK,
> which makes it simple to handle.
> For other SoCs, there may be a variation of possible values, depending on
> SoC and/or board.

Ok, thanks.

-Orson

>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [e-mail]
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Patch

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b2b504ea6fd6..76778b2f520d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -249,7 +249,7 @@  config ARCH_TEGRA
 	  This enables support for the NVIDIA Tegra SoC family.
 
 config ARCH_SPRD
-	bool "Spreadtrum SoC platform"
+	tristate "Spreadtrum SoC platform"
 	help
 	  Support for Spreadtrum ARM based SoCs