| Message ID | 1460643685-13670-1-git-send-email-stuart.yoder@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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.
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).
> -----Original Message----- > From: Martinez Kristofer [mailto:kristofer.s.martinez@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@arm.com; marc.zyngier@arm.com; > will.deacon@arm.com; Yang-Leo Li <leoyang.li@nxp.com>; Scott Wood <scott.wood@nxp.com>; linux-arm- > kernel@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
> -----Original Message----- > From: Catalin Marinas [mailto:catalin.marinas@arm.com] > Sent: Thursday, April 14, 2016 12:05 PM > To: Stuart Yoder <stuart.yoder@nxp.com> > Cc: linux-arm-kernel@lists.infradead.org; will.deacon@arm.com; marc.zyngier@arm.com; > mark.rutland@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
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
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