[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Stuart Yoder]

Add a config fragment enabling a reasonably useful set of
devices and options for Freescale ARM v8 SoCs.

I realize that we are trying to avoid the defconfig hell in arch/arm with 100+
defconfigs, but the single defconfig in arch/arm64 has some problems too.
I think what we want with arch/arm64/config are some reasonable in-kernel
defconfigs/fragments with built-in drivers for convenience.

The proposal is to allow a chip vendor 1 vendor-specific kconfig fragment
to cover all their chips, allowing them to _override_ the default config
options in defconfig.  One specific issue we have is that due to the ls2080a
physical address map, the combination of 4KB pages and 39-bit VA does not
allow us to see all our DDR.  And, thus we need CONFIG_ARM64_VA_BITS_48=y.
(which I presume no one else wants).

Allowing us to have a freescale.config gives us the flexibility of
adding Freescale specific options without having to keep this in
some other external repo.  It also keeps vendor specific clutter
out of the base defconfig.  With the number of new armv8 chips 
coming out the single defconfig is going to produce increasingly
large kernels, since all drivers are built-in.

We want people to be able to clone the kernel.org kernel, merge the
freescale.config fragment with defconfig, and get a decent kernel.

Signed-off-by: Stuart Yoder <stuart.yoder@nxp.com>
---
 arch/arm64/configs/freescale.config | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 arch/arm64/configs/freescale.config

diff --git a/arch/arm64/configs/freescale.config b/arch/arm64/configs/freescale.config
new file mode 100644
index 0000000..5f5bd7e
--- /dev/null
+++ b/arch/arm64/configs/freescale.config
@@ -0,0 +1,19 @@
+# general options
+CONFIG_ARM64_VA_BITS_48=y
+# dpaa2
+CONFIG_STAGING=y
+CONFIG_FSL_MC_BUS=y
+# clock driver
+CONFIG_CLK_QORIQ=y
+# ahci/sata
+CONFIG_AHCI_QORIQ=y
+# esdhc
+CONFIG_MMC_SDHCI_OF_ESDHC=y
+# I2C
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
+CONFIG_I2C_IMX=y
+CONFIG_HWMON=y
+CONFIG_SENSORS_LM90=y
+CONFIG_SENSORS_INA2XX=y
+CONFIG_RTC_DRV_DS3232=y
-- 
1.9.0

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Catalin Marinas]

On Thu, Apr 14, 2016 at 09:21:25AM -0500, Stuart Yoder wrote:
> Add a config fragment enabling a reasonably useful set of
> devices and options for Freescale ARM v8 SoCs.

A gentle NAK ;).

> I realize that we are trying to avoid the defconfig hell in arch/arm with 100+
> defconfigs, but the single defconfig in arch/arm64 has some problems too.

Can we address these problems in defconfig?

> I think what we want with arch/arm64/config are some reasonable in-kernel
> defconfigs/fragments with built-in drivers for convenience.

A hard requirement for arm64 is single Image and having all SoCs in
defconfig is a good way to regularly test this.

I am aware that at some point the defconfig size will get too big but
that's when (ideally before) we should put effort into building more
stuff as loadable modules.

> The proposal is to allow a chip vendor 1 vendor-specific kconfig fragment
> to cover all their chips, allowing them to _override_ the default config
> options in defconfig.  One specific issue we have is that due to the ls2080a
> physical address map, the combination of 4KB pages and 39-bit VA does not
> allow us to see all our DDR.  And, thus we need CONFIG_ARM64_VA_BITS_48=y.

And I'm fine to add this to defconfig. We had a case for Seattle needing
48-bit VA but we eventually decoupled the number of levels for idmap and
swapper. If it can't be addressed in a similar way on ls2080a, we may
need to increase the VA space to 48-bit.

> Allowing us to have a freescale.config gives us the flexibility of
> adding Freescale specific options without having to keep this in
> some other external repo.  It also keeps vendor specific clutter
> out of the base defconfig.  With the number of new armv8 chips 
> coming out the single defconfig is going to produce increasingly
> large kernels, since all drivers are built-in.

As I said, for the time being please add all the sane the options to
defconfig. I want to be able to build a defconfig and run on all
supported SoCs.

> +CONFIG_STAGING=y

Well, apart from this. You should put effort in getting the required
drivers out of staging.

-- 
Catalin

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Arnd Bergmann]

On Thursday 14 April 2016 18:04:33 Catalin Marinas wrote:
> 
> > Allowing us to have a freescale.config gives us the flexibility of
> > adding Freescale specific options without having to keep this in
> > some other external repo.  It also keeps vendor specific clutter
> > out of the base defconfig.  With the number of new armv8 chips 
> > coming out the single defconfig is going to produce increasingly
> > large kernels, since all drivers are built-in.
> 
> As I said, for the time being please add all the sane the options to
> defconfig. I want to be able to build a defconfig and run on all
> supported SoCs.

I'd suggest making the non-essential drivers loadable modules though,
in particular the sensor drivers.

There are two block device drivers included here (SoC specific
front-ends for AHCI and SDHCI), I'm not sure about what to do with
them, but we should try to do it consistently, either making
them all built-in to simplify booting from them without a ramdisk,
or try to make them all modules as well.

	Arnd

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Catalin Marinas]

On Sat, Apr 16, 2016 at 06:50:53PM +0200, Arnd Bergmann wrote:
> On Thursday 14 April 2016 18:04:33 Catalin Marinas wrote:
> > > Allowing us to have a freescale.config gives us the flexibility of
> > > adding Freescale specific options without having to keep this in
> > > some other external repo.  It also keeps vendor specific clutter
> > > out of the base defconfig.  With the number of new armv8 chips 
> > > coming out the single defconfig is going to produce increasingly
> > > large kernels, since all drivers are built-in.
> > 
> > As I said, for the time being please add all the sane the options to
> > defconfig. I want to be able to build a defconfig and run on all
> > supported SoCs.
> 
> I'd suggest making the non-essential drivers loadable modules though,
> in particular the sensor drivers.

I'm fine with this.

> There are two block device drivers included here (SoC specific
> front-ends for AHCI and SDHCI), I'm not sure about what to do with
> them, but we should try to do it consistently, either making
> them all built-in to simplify booting from them without a ramdisk,
> or try to make them all modules as well.

For now, I think all drivers required for mounting the root filesystem
(whether it's on some non-volatile memory or NFS) should be built in.

It would be nice to have (mostly) everything as loadable modules but, at
least for kernel developers, there isn't a simple way to get the modules
in a ramdisk and easily test such kernels (that's more of a distro
feature). IIRC there were discussions at an ARM mini-summit in the past
around minimal kbuild support for generating a ramdisk with modules and
necessary tools. But I don't know whether anyone started looking into
this (in the 32-bit ARM context).

-- 
Catalin

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Martinez Kristofer]

On Fri, Apr 15, 2016 at 1:04 AM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Thu, Apr 14, 2016 at 09:21:25AM -0500, Stuart Yoder wrote:
>> Add a config fragment enabling a reasonably useful set of
>> devices and options for Freescale ARM v8 SoCs.
>
> A gentle NAK ;).
>
>> I realize that we are trying to avoid the defconfig hell in arch/arm with 100+
>> defconfigs, but the single defconfig in arch/arm64 has some problems too.
>
> Can we address these problems in defconfig?
>
>> I think what we want with arch/arm64/config are some reasonable in-kernel
>> defconfigs/fragments with built-in drivers for convenience.
>
> A hard requirement for arm64 is single Image and having all SoCs in
> defconfig is a good way to regularly test this.
>
> I am aware that at some point the defconfig size will get too big but
> that's when (ideally before) we should put effort into building more
> stuff as loadable modules.
>
>> The proposal is to allow a chip vendor 1 vendor-specific kconfig fragment
>> to cover all their chips, allowing them to _override_ the default config
>> options in defconfig.  One specific issue we have is that due to the ls2080a
>> physical address map, the combination of 4KB pages and 39-bit VA does not
>> allow us to see all our DDR.  And, thus we need CONFIG_ARM64_VA_BITS_48=y.
>
> And I'm fine to add this to defconfig. We had a case for Seattle needing
> 48-bit VA but we eventually decoupled the number of levels for idmap and
> swapper. If it can't be addressed in a similar way on ls2080a, we may
> need to increase the VA space to 48-bit.
>

Here my suggestion is 48-bit VA will be depended on the CONFIG_ACPI,
IOW, if CONFIG_ACPI
is seleceted, then CONFIG_ARM64_VA_BITS_48 will be selected too.
The premise is ACPI will be used in larger VA space segment as it did
in Server area.
Stuart, does your ls2080a need to be configured with ACPI?

M.K.

>
>> Allowing us to have a freescale.config gives us the flexibility of
>> adding Freescale specific options without having to keep this in
>> some other external repo.  It also keeps vendor specific clutter
>> out of the base defconfig.  With the number of new armv8 chips
>> coming out the single defconfig is going to produce increasingly
>> large kernels, since all drivers are built-in.
>
> As I said, for the time being please add all the sane the options to
> defconfig. I want to be able to build a defconfig and run on all
> supported SoCs.
>
>> +CONFIG_STAGING=y
>
> Well, apart from this. You should put effort in getting the required
> drivers out of staging.
>
> --
> Catalin
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Catalin Marinas]

On Sun, Apr 17, 2016 at 05:10:42PM +0800, Martinez Kristofer wrote:
> On Fri, Apr 15, 2016 at 1:04 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Thu, Apr 14, 2016 at 09:21:25AM -0500, Stuart Yoder wrote:
> >> The proposal is to allow a chip vendor 1 vendor-specific kconfig fragment
> >> to cover all their chips, allowing them to _override_ the default config
> >> options in defconfig.  One specific issue we have is that due to the ls2080a
> >> physical address map, the combination of 4KB pages and 39-bit VA does not
> >> allow us to see all our DDR.  And, thus we need CONFIG_ARM64_VA_BITS_48=y.
> >
> > And I'm fine to add this to defconfig. We had a case for Seattle needing
> > 48-bit VA but we eventually decoupled the number of levels for idmap and
> > swapper. If it can't be addressed in a similar way on ls2080a, we may
> > need to increase the VA space to 48-bit.
> 
> Here my suggestion is 48-bit VA will be depended on the CONFIG_ACPI,
> IOW, if CONFIG_ACPI
> is seleceted, then CONFIG_ARM64_VA_BITS_48 will be selected too.

I don't see why 48-bit VA should depend on CONFIG_ACPI, they are
unrelated options. Anyway, we are going to enable ACPI in the arm64
defconfig, so you get both.

-- 
Catalin

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Stuart Yoder]

> -----Original Message-----
> From: Martinez Kristofer [mailto:kristofer.s.martinez at gmail.com]
> Sent: Sunday, April 17, 2016 4:11 AM
> To: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Stuart Yoder <stuart.yoder@nxp.com>; mark.rutland at arm.com; marc.zyngier at arm.com;
> will.deacon at arm.com; Yang-Leo Li <leoyang.li@nxp.com>; Scott Wood <scott.wood@nxp.com>; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs
> 
> On Fri, Apr 15, 2016 at 1:04 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Thu, Apr 14, 2016 at 09:21:25AM -0500, Stuart Yoder wrote:
> >> Add a config fragment enabling a reasonably useful set of
> >> devices and options for Freescale ARM v8 SoCs.
> >
> > A gentle NAK ;).
> >
> >> I realize that we are trying to avoid the defconfig hell in arch/arm with 100+
> >> defconfigs, but the single defconfig in arch/arm64 has some problems too.
> >
> > Can we address these problems in defconfig?
> >
> >> I think what we want with arch/arm64/config are some reasonable in-kernel
> >> defconfigs/fragments with built-in drivers for convenience.
> >
> > A hard requirement for arm64 is single Image and having all SoCs in
> > defconfig is a good way to regularly test this.
> >
> > I am aware that at some point the defconfig size will get too big but
> > that's when (ideally before) we should put effort into building more
> > stuff as loadable modules.
> >
> >> The proposal is to allow a chip vendor 1 vendor-specific kconfig fragment
> >> to cover all their chips, allowing them to _override_ the default config
> >> options in defconfig.  One specific issue we have is that due to the ls2080a
> >> physical address map, the combination of 4KB pages and 39-bit VA does not
> >> allow us to see all our DDR.  And, thus we need CONFIG_ARM64_VA_BITS_48=y.
> >
> > And I'm fine to add this to defconfig. We had a case for Seattle needing
> > 48-bit VA but we eventually decoupled the number of levels for idmap and
> > swapper. If it can't be addressed in a similar way on ls2080a, we may
> > need to increase the VA space to 48-bit.
> >
> 
> Here my suggestion is 48-bit VA will be depended on the CONFIG_ACPI,
> IOW, if CONFIG_ACPI
> is seleceted, then CONFIG_ARM64_VA_BITS_48 will be selected too.
> The premise is ACPI will be used in larger VA space segment as it did
> in Server area.
> Stuart, does your ls2080a need to be configured with ACPI?

No, the ls2080a does not currently use ACPI, but it may (optionally)
in the future.  For us the issue is simply having enough virtual
address bits for the kernel's linear mapping to cover 2 discontiguous
regions of DDR.

Stuart

[RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs

[Stuart Yoder]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Thursday, April 14, 2016 12:05 PM
> To: Stuart Yoder <stuart.yoder@nxp.com>
> Cc: linux-arm-kernel at lists.infradead.org; will.deacon at arm.com; marc.zyngier at arm.com;
> mark.rutland at arm.com; Scott Wood <scott.wood@nxp.com>; Yang-Leo Li <leoyang.li@nxp.com>
> Subject: Re: [RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCs
> 
> On Thu, Apr 14, 2016 at 09:21:25AM -0500, Stuart Yoder wrote:
> > Add a config fragment enabling a reasonably useful set of
> > devices and options for Freescale ARM v8 SoCs.
> 
> A gentle NAK ;).
> 
> > I realize that we are trying to avoid the defconfig hell in arch/arm with 100+
> > defconfigs, but the single defconfig in arch/arm64 has some problems too.
> 
> Can we address these problems in defconfig?
> 
> > I think what we want with arch/arm64/config are some reasonable in-kernel
> > defconfigs/fragments with built-in drivers for convenience.
> 
> A hard requirement for arm64 is single Image and having all SoCs in
> defconfig is a good way to regularly test this.
> 
> I am aware that at some point the defconfig size will get too big but
> that's when (ideally before) we should put effort into building more
> stuff as loadable modules.
> 
> > The proposal is to allow a chip vendor 1 vendor-specific kconfig fragment
> > to cover all their chips, allowing them to _override_ the default config
> > options in defconfig.  One specific issue we have is that due to the ls2080a
> > physical address map, the combination of 4KB pages and 39-bit VA does not
> > allow us to see all our DDR.  And, thus we need CONFIG_ARM64_VA_BITS_48=y.
> 
> And I'm fine to add this to defconfig. We had a case for Seattle needing
> 48-bit VA but we eventually decoupled the number of levels for idmap and
> swapper. If it can't be addressed in a similar way on ls2080a, we may
> need to increase the VA space to 48-bit.

The issue for us is the linear mapping covering the 2 very discontiguous
memory regions on the ls2080a.  We've tried some experiments to locate all
DDR high, but that results in issues for some devices with 32-bit DMA masks,
that need bounce buffers.

I'll submit a patch to increase the VA space to 48-bit, along with 
the other options.

Thanks,
Stuart