arm64: defconfig: add config fragment for Freescale SoCs
RFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
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.
--- arch/arm64/configs/freescale.config | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 arch/arm64/configs/freescale.config
arch/arm64/configs/freescale.config new file +19 -0
@@ -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
Signature · 1 line
1.9.0
Catalin Marinas
maintainerRFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
Quoted 2 lines · Stuart Yoder
Add a config fragment enabling a reasonably useful set of devices and options for Freescale ARM v8 SoCs.
A gentle NAK ;).
Quoted 2 lines
I realize that we are trying to avoid the defconfig hell in
arch/armwith 100+ defconfigs, but the single defconfig inarch/arm64has some problems too.
Can we address these problems in defconfig?
Quoted 2 lines
I think what we want with
arch/arm64/configare 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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 1 line
+CONFIG_STAGING=y
Well, apart from this. You should put effort in getting the required drivers out of staging.
Signature · 1 line
Catalin
RFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
Quoted 11 lines · On Thursday 14 April 2016 18:04:33 Catalin Marinas wrote:
Quoted 7 lines
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
Catalin Marinas
maintainerRFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
Quoted 8 lines · Arnd Bergmann
Quoted 7 lines · On Thursday 14 April 2016 18:04:33 Catalin Marinas wrote:
Quoted 6 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 5 lines
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).
Signature · 1 line
Catalin
RFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
In reply to Catalin MarinasQuoted 27 lines · Catalin Marinas
Quoted 2 lines · Stuart Yoder
Add a config fragment enabling a reasonably useful set of devices and options for Freescale ARM v8 SoCs.
A gentle NAK ;).
Quoted 2 lines
I realize that we are trying to avoid the defconfig hell in
arch/armwith 100+ defconfigs, but the single defconfig inarch/arm64has some problems too.Can we address these problems in defconfig?
Quoted 2 lines
I think what we want with
arch/arm64/configare 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.
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 24 lines
Quoted 7 lines
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.
Quoted 1 line
+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
Catalin Marinas
maintainerRFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
Quoted 9 lines · Martinez Kristofer
Quoted 7 lines · Catalin Marinas
Quoted 5 lines · Stuart Yoder
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.
Quoted 8 lines
Quoted 4 lines
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, ifCONFIG_ACPI
is seleceted, thenCONFIG_ARM64_VA_BITS_48will 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.
Signature · 1 line
Catalin
RFC PATCH 1/1 arm64: defconfig: add config fragment for Freescale SoCs
In reply to Martinez KristoferQuoted 46 lines
-----Original Message-----
From: Martinez Kristofer [mailto:kristofer.s.martinez at gmail.com]
Sent: Sunday, April 17, 2016 4:11 AM
To: Catalin Marinas <[email protected]>
Cc: Stuart Yoder <[email protected]>; mark.rutland at arm.com; marc.zyngier at arm.com; will.deacon at arm.com; Yang-Leo Li <[email protected]>; Scott Wood <[email protected]>; linux-arm- kernel at lists.infradead.org
Subject: Re: [RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCsQuoted 27 lines · Catalin Marinas
Quoted 2 lines · Stuart Yoder
Add a config fragment enabling a reasonably useful set of devices and options for Freescale ARM v8 SoCs.
A gentle NAK ;).
Quoted 2 lines
I realize that we are trying to avoid the defconfig hell in
arch/armwith 100+ defconfigs, but the single defconfig inarch/arm64has some problems too.Can we address these problems in defconfig?
Quoted 2 lines
I think what we want with
arch/arm64/configare 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.
Quoted 5 lines
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.Quoted 5 lines
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.
Quoted 6 lines
Here my suggestion is 48-bit VA will be depended on the
CONFIG_ACPI, IOW, ifCONFIG_ACPI
is seleceted, thenCONFIG_ARM64_VA_BITS_48will 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 1/1 arm64: defconfig: add config fragment for Freescale SoCs
In reply to Catalin MarinasQuoted 37 lines
-----Original Message-----
From: Catalin Marinas [mailto:catalin.marinas at arm.com]
Sent: Thursday, April 14, 2016 12:05 PM
To: Stuart Yoder <[email protected]>
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 <[email protected]>; Yang-Leo Li <[email protected]>
Subject: Re: [RFC PATCH] arm64: defconfig: add config fragment for Freescale SoCsQuoted 2 lines · Stuart Yoder
Add a config fragment enabling a reasonably useful set of devices and options for Freescale ARM v8 SoCs.
A gentle NAK ;).
Quoted 2 lines
I realize that we are trying to avoid the defconfig hell in
arch/armwith 100+ defconfigs, but the single defconfig inarch/arm64has some problems too.Can we address these problems in defconfig?
Quoted 2 lines
I think what we want with
arch/arm64/configare 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.
Quoted 5 lines
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.
Quoted 4 lines
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