| Message ID | 1397554134-11827-6-git-send-email-sachin.kamat@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Sachin, On 15.04.2014 11:28, Sachin Kamat wrote: > From: Arnd Bergmann <arnd@arndb.de> > > This makes it possible to enable the exynos platform as part of a > multiplatform kernel, in addition to keeping the single-platform > Exynos support. > sparsemem is currently not supported in multiplatform. Is this still true as of today? Otherwise looks fine. Best regards, Tomasz
On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: > On 15.04.2014 11:28, Sachin Kamat wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > This makes it possible to enable the exynos platform as part of a > > multiplatform kernel, in addition to keeping the single-platform > > Exynos support. > > sparsemem is currently not supported in multiplatform. > > Is this still true as of today? > > Otherwise looks fine. sparsemem is still not supported in multiplatform, but after I looked at it in more detail, I came to the conclusion that there is no reason why it couldn't be. It just needs testing so we are confident that it doesn't break other platforms, and we need to find good platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS to put into asm/memory.h, since we can't have them set in mach/memory.h for multiplatform. Looking at my patch again now, I would actually prefer to kill off the single-platform support for exynos right away. I don't see any reason to keep it now, and it complicates the test matrix. Arnd
On 16.04.2014 16:31, Arnd Bergmann wrote: > On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: >> On 15.04.2014 11:28, Sachin Kamat wrote: >>> From: Arnd Bergmann <arnd@arndb.de> >>> >>> This makes it possible to enable the exynos platform as part of a >>> multiplatform kernel, in addition to keeping the single-platform >>> Exynos support. >>> sparsemem is currently not supported in multiplatform. >> >> Is this still true as of today? >> >> Otherwise looks fine. > > sparsemem is still not supported in multiplatform, but after I looked > at it in more detail, I came to the conclusion that there is no > reason why it couldn't be. It just needs testing so we are confident > that it doesn't break other platforms, and we need to find good > platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS > to put into asm/memory.h, since we can't have them set in mach/memory.h > for multiplatform. > > Looking at my patch again now, I would actually prefer to kill off > the single-platform support for exynos right away. I don't see > any reason to keep it now, and it complicates the test matrix. That would be the best option, assuming that it wouldn't introduce feature regressions. Unfortunately there is still ongoing work on cpufreq driver to make it multiplatform-aware, so dropping single platform support right now would introduce at least this one regression. Thomas, is there any progress on new version of Exynos cpufreq rework series? Best regards, Tomasz
On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa <t.figa@samsung.com> wrote: > On 16.04.2014 16:31, Arnd Bergmann wrote: >> >> On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: >>> >>> On 15.04.2014 11:28, Sachin Kamat wrote: >>>> >>>> From: Arnd Bergmann <arnd@arndb.de> >>>> >>>> This makes it possible to enable the exynos platform as part of a >>>> multiplatform kernel, in addition to keeping the single-platform >>>> Exynos support. >>>> sparsemem is currently not supported in multiplatform. >>> >>> >>> Is this still true as of today? >>> >>> Otherwise looks fine. >> >> >> sparsemem is still not supported in multiplatform, but after I looked >> at it in more detail, I came to the conclusion that there is no >> reason why it couldn't be. It just needs testing so we are confident >> that it doesn't break other platforms, and we need to find good >> platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS >> to put into asm/memory.h, since we can't have them set in mach/memory.h >> for multiplatform. >> >> Looking at my patch again now, I would actually prefer to kill off >> the single-platform support for exynos right away. I don't see >> any reason to keep it now, and it complicates the test matrix. > > > That would be the best option, assuming that it wouldn't introduce feature > regressions. Unfortunately there is still ongoing work on cpufreq driver to > make it multiplatform-aware, so dropping single platform support right now > would introduce at least this one regression. > > Thomas, is there any progress on new version of Exynos cpufreq rework > series? Hi Tomasz, Yes, I am preparing the fourth version of the cpufreq patches and will post it next week. Mostly, the changes will be addressing your review comments. Thanks, Thomas. > > Best regards, > Tomasz
Hi Thomas, On 16.04.2014 16:55, Thomas Abraham wrote: > On Wed, Apr 16, 2014 at 8:18 PM, Tomasz Figa <t.figa@samsung.com> wrote: >> On 16.04.2014 16:31, Arnd Bergmann wrote: >>> >>> On Wednesday 16 April 2014 15:51:29 Tomasz Figa wrote: >>>> >>>> On 15.04.2014 11:28, Sachin Kamat wrote: >>>>> >>>>> From: Arnd Bergmann <arnd@arndb.de> >>>>> >>>>> This makes it possible to enable the exynos platform as part of a >>>>> multiplatform kernel, in addition to keeping the single-platform >>>>> Exynos support. >>>>> sparsemem is currently not supported in multiplatform. >>>> >>>> >>>> Is this still true as of today? >>>> >>>> Otherwise looks fine. >>> >>> >>> sparsemem is still not supported in multiplatform, but after I looked >>> at it in more detail, I came to the conclusion that there is no >>> reason why it couldn't be. It just needs testing so we are confident >>> that it doesn't break other platforms, and we need to find good >>> platform-independent values for MAX_PHYSMEM_BITS and SECTION_SIZE_BITS >>> to put into asm/memory.h, since we can't have them set in mach/memory.h >>> for multiplatform. >>> >>> Looking at my patch again now, I would actually prefer to kill off >>> the single-platform support for exynos right away. I don't see >>> any reason to keep it now, and it complicates the test matrix. >> >> >> That would be the best option, assuming that it wouldn't introduce feature >> regressions. Unfortunately there is still ongoing work on cpufreq driver to >> make it multiplatform-aware, so dropping single platform support right now >> would introduce at least this one regression. >> >> Thomas, is there any progress on new version of Exynos cpufreq rework >> series? > > Hi Tomasz, > > Yes, I am preparing the fourth version of the cpufreq patches and will > post it next week. Mostly, the changes will be addressing your review > comments. OK. Looking forward to it. Thanks for an update on this. Best regards, Tomasz
On Tue, Apr 15, 2014 at 2:28 AM, Sachin Kamat <sachin.kamat@linaro.org> wrote: > From: Arnd Bergmann <arnd@arndb.de> > > This makes it possible to enable the exynos platform as part of a > multiplatform kernel, in addition to keeping the single-platform > Exynos support. > sparsemem is currently not supported in multiplatform. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> > --- > arch/arm/Kconfig | 27 +++------------------------ > arch/arm/configs/exynos_defconfig | 2 +- > arch/arm/mach-exynos/Kconfig | 27 +++++++++++++++++++++++++++ > arch/arm/mach-exynos/Makefile | 2 ++ > arch/arm/plat-samsung/Makefile | 3 +++ > 5 files changed, 36 insertions(+), 25 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 4422601059e8..9d459e9c396b 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -828,34 +828,13 @@ config ARCH_S5PV210 > help > Samsung S5PV210/S5PC110 series based systems > > -config ARCH_EXYNOS > +config ARCH_EXYNOS_SINGLE > bool "Samsung EXYNOS" > - select ARCH_HAS_BANDGAP > - select ARCH_HAS_CPUFREQ > - select ARCH_HAS_HOLES_MEMORYMODEL > - select ARCH_REQUIRE_GPIOLIB > + select ARCH_EXYNOS > select ARCH_SPARSEMEM_ENABLE > - select ARM_AMBA > - select ARM_GIC > - select CLKSRC_OF > - select COMMON_CLK > - select CPU_V7 > - select GENERIC_CLOCKEVENTS > - select HAVE_ARM_SCU if SMP > - select HAVE_S3C2410_I2C if I2C > - select HAVE_S3C2410_WATCHDOG if WATCHDOG > - select HAVE_S3C_RTC if RTC_CLASS > - select HAVE_SMP > select NEED_MACH_MEMORY_H > - select PINCTRL > - select PINCTRL_EXYNOS > - select PM_GENERIC_DOMAINS if PM_RUNTIME > - select S5P_DEV_MFC > - select SAMSUNG_DMADEV > - select SPARSE_IRQ > - select USE_OF > help > - Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) > + Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) I don't think there's a point in keeping this around. A "single-platform" config is just enabling a single platform in the config, it's not a specific option. I don't think any of the other platforms use anything like this today. -Olof
On Tuesday 22 April 2014, Olof Johansson wrote: > I don't think there's a point in keeping this around. A > "single-platform" config is just enabling a single platform in the > config, it's not a specific option. I don't think any of the other > platforms use anything like this today. The only one doing that is shmobile, but only because they have some SoCs that are multiplatform capable and some that are not. This isn't the case for Exynos, so it should no longer be needed. When I originally created this patch 18 months ago, there were a number of drivers that broke when multiplatform got enabled. Now the cpufreq driver is the only one left, but it seems that it will make it for 3.16, and I wouldn't wait for it if it doesn't. Let's just do multiplatform-only. Arnd
Arnd Bergmann wrote: > > On Tuesday 22 April 2014, Olof Johansson wrote: > > I don't think there's a point in keeping this around. A > > "single-platform" config is just enabling a single platform in the > > config, it's not a specific option. I don't think any of the other > > platforms use anything like this today. > > The only one doing that is shmobile, but only because they have > some SoCs that are multiplatform capable and some that are not. > This isn't the case for Exynos, so it should no longer be needed. > > When I originally created this patch 18 months ago, there were a > number of drivers that broke when multiplatform got enabled. > Now the cpufreq driver is the only one left, but it seems that > it will make it for 3.16, and I wouldn't wait for it if it doesn't. > Let's just do multiplatform-only. > In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and EXYNOS5 because IMHO selecting each series would be helpful on real product, multiplatform is available though. Additionally EXYNOS3 is being added. It's true we can support exynos-multiplatform even though above options are included... Thanks, Kukjin
On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote: > Arnd Bergmann wrote: > > > > On Tuesday 22 April 2014, Olof Johansson wrote: > > > I don't think there's a point in keeping this around. A > > > "single-platform" config is just enabling a single platform in the > > > config, it's not a specific option. I don't think any of the other > > > platforms use anything like this today. > > > > The only one doing that is shmobile, but only because they have > > some SoCs that are multiplatform capable and some that are not. > > This isn't the case for Exynos, so it should no longer be needed. > > > > When I originally created this patch 18 months ago, there were a > > number of drivers that broke when multiplatform got enabled. > > Now the cpufreq driver is the only one left, but it seems that > > it will make it for 3.16, and I wouldn't wait for it if it doesn't. > > Let's just do multiplatform-only. > > > In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and > EXYNOS5 because IMHO selecting each series would be helpful on real product, > multiplatform is available though. Additionally EXYNOS3 is being added. > > It's true we can support exynos-multiplatform even though above options are > included... I think we are talking about different questions here: What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option that is there for building EXYNOS but not allowing any other SoC. What I think you mean is that you want the individual EXYNOS versions to be separate Kconfig options, so you can build a kernel that supports EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far as I'm concerned, and it's not directly related to the first point. Note that if you enable LPAE, you will still only be able to build EXYNOS5 after the patch, but then you can have it in the same kernel as e.g. Tegra4 and Snapdragon 600. Arnd
On Tue, May 13, 2014 at 2:15 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote: >> Arnd Bergmann wrote: >> > >> > On Tuesday 22 April 2014, Olof Johansson wrote: >> > > I don't think there's a point in keeping this around. A >> > > "single-platform" config is just enabling a single platform in the >> > > config, it's not a specific option. I don't think any of the other >> > > platforms use anything like this today. >> > >> > The only one doing that is shmobile, but only because they have >> > some SoCs that are multiplatform capable and some that are not. >> > This isn't the case for Exynos, so it should no longer be needed. >> > >> > When I originally created this patch 18 months ago, there were a >> > number of drivers that broke when multiplatform got enabled. >> > Now the cpufreq driver is the only one left, but it seems that >> > it will make it for 3.16, and I wouldn't wait for it if it doesn't. >> > Let's just do multiplatform-only. >> > >> In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and >> EXYNOS5 because IMHO selecting each series would be helpful on real product, >> multiplatform is available though. Additionally EXYNOS3 is being added. >> >> It's true we can support exynos-multiplatform even though above options are >> included... > > I think we are talking about different questions here: > > What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option > that is there for building EXYNOS but not allowing any other SoC. Yes. i.e. the only way forward is multiplatform _only_. _BUT_ you can choose to disable all other platforms in a kernel, and thus turn it into a single-platform build. That's fine. What we don't want is added logic like the EXYNOS_SINGLE Kconfig was, just to do that. > What I think you mean is that you want the individual EXYNOS versions > to be separate Kconfig options, so you can build a kernel that supports > EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far > as I'm concerned, and it's not directly related to the first point. I'm also OK with that, but please don't make it more granular than per family if you can avoid it. > Note that if you enable LPAE, you will still only be able to build EXYNOS5 > after the patch, but then you can have it in the same kernel as e.g. > Tegra4 and Snapdragon 600. Yep, and that's as expected. -Olof
Olof Johansson wrote: > > On Tue, May 13, 2014 at 2:15 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Tuesday 13 May 2014 13:37:33 Kukjin Kim wrote: > >> Arnd Bergmann wrote: > >> > > >> > On Tuesday 22 April 2014, Olof Johansson wrote: > >> > > I don't think there's a point in keeping this around. A > >> > > "single-platform" config is just enabling a single platform in the > >> > > config, it's not a specific option. I don't think any of the other > >> > > platforms use anything like this today. > >> > > >> > The only one doing that is shmobile, but only because they have > >> > some SoCs that are multiplatform capable and some that are not. > >> > This isn't the case for Exynos, so it should no longer be needed. > >> > > >> > When I originally created this patch 18 months ago, there were a > >> > number of drivers that broke when multiplatform got enabled. > >> > Now the cpufreq driver is the only one left, but it seems that > >> > it will make it for 3.16, and I wouldn't wait for it if it doesn't. > >> > Let's just do multiplatform-only. > >> > > >> In my position in S.LSI, I'd like to keep the current ARCH_EXYNOS4 and > >> EXYNOS5 because IMHO selecting each series would be helpful on real product, > >> multiplatform is available though. Additionally EXYNOS3 is being added. > >> > >> It's true we can support exynos-multiplatform even though above options are > >> included... > > > > I think we are talking about different questions here: > > Thanks for your clarification. > > What Olof and I mean is we don't want to have an ARCH_EXYNOS_SINGLE option > > that is there for building EXYNOS but not allowing any other SoC. > Yes and agreed ;-) > Yes. i.e. the only way forward is multiplatform _only_. _BUT_ you can > choose to disable all other platforms in a kernel, and thus turn it > into a single-platform build. That's fine. What we don't want is added > logic like the EXYNOS_SINGLE Kconfig was, just to do that. > Sure. > > What I think you mean is that you want the individual EXYNOS versions > > to be separate Kconfig options, so you can build a kernel that supports > > EXYNOS4 but not EXYNOS5 if you want to. This is totally fine as far > > as I'm concerned, and it's not directly related to the first point. > OK, thanks :-) > I'm also OK with that, but please don't make it more granular than per > family if you can avoid it. > Sure. > > Note that if you enable LPAE, you will still only be able to build EXYNOS5 > > after the patch, but then you can have it in the same kernel as e.g. > > Tegra4 and Snapdragon 600. > > Yep, and that's as expected. > OK. Thanks, Kukjin
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 4422601059e8..9d459e9c396b 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -828,34 +828,13 @@ config ARCH_S5PV210 help Samsung S5PV210/S5PC110 series based systems -config ARCH_EXYNOS +config ARCH_EXYNOS_SINGLE bool "Samsung EXYNOS" - select ARCH_HAS_BANDGAP - select ARCH_HAS_CPUFREQ - select ARCH_HAS_HOLES_MEMORYMODEL - select ARCH_REQUIRE_GPIOLIB + select ARCH_EXYNOS select ARCH_SPARSEMEM_ENABLE - select ARM_AMBA - select ARM_GIC - select CLKSRC_OF - select COMMON_CLK - select CPU_V7 - select GENERIC_CLOCKEVENTS - select HAVE_ARM_SCU if SMP - select HAVE_S3C2410_I2C if I2C - select HAVE_S3C2410_WATCHDOG if WATCHDOG - select HAVE_S3C_RTC if RTC_CLASS - select HAVE_SMP select NEED_MACH_MEMORY_H - select PINCTRL - select PINCTRL_EXYNOS - select PM_GENERIC_DOMAINS if PM_RUNTIME - select S5P_DEV_MFC - select SAMSUNG_DMADEV - select SPARSE_IRQ - select USE_OF help - Support for SAMSUNG's EXYNOS SoCs (EXYNOS4/5) + Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) config ARCH_DAVINCI bool "TI DaVinci" diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 4ce7b70ea901..103a676256cd 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -7,7 +7,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set CONFIG_PARTITION_ADVANCED=y -CONFIG_ARCH_EXYNOS=y +CONFIG_ARCH_EXYNOS_SINGLE=y CONFIG_S3C_LOWLEVEL_UART_PORT=3 CONFIG_S3C24XX_PWM=y CONFIG_ARCH_EXYNOS5=y diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index 5c34dc26cec6..bc55af76a05f 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -7,6 +7,33 @@ # Configuration options for the EXYNOS4 +config ARCH_EXYNOS + bool "Samsung EXYNOS" if ARCH_MULTI_V7 + select ARCH_HAS_BANDGAP + select ARCH_HAS_CPUFREQ + select ARCH_HAS_HOLES_MEMORYMODEL + select ARCH_REQUIRE_GPIOLIB + select ARM_AMBA + select ARM_GIC + select CLKSRC_OF + select COMMON_CLK + select CPU_V7 + select GENERIC_CLOCKEVENTS + select HAVE_ARM_SCU if SMP + select HAVE_S3C2410_I2C if I2C + select HAVE_S3C2410_WATCHDOG if WATCHDOG + select HAVE_S3C_RTC if RTC_CLASS + select HAVE_SMP + select PINCTRL + select PINCTRL_EXYNOS + select PM_GENERIC_DOMAINS if PM_RUNTIME + select S5P_DEV_MFC + select SAMSUNG_DMADEV + select SPARSE_IRQ + select USE_OF + help + Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5) + if ARCH_EXYNOS menu "SAMSUNG EXYNOS SoCs Support" diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile index f6dcc256db56..24a8efe3d4bd 100644 --- a/arch/arm/mach-exynos/Makefile +++ b/arch/arm/mach-exynos/Makefile @@ -5,6 +5,8 @@ # # Licensed under GPLv2 +ccflags-$(CONFIG_ARCH_MULTIPLATFORM) += -I$(srctree)/$(src)/include -I$(srctree)/arch/arm/plat-samsung/include + obj-y := obj-m := obj-n := diff --git a/arch/arm/plat-samsung/Makefile b/arch/arm/plat-samsung/Makefile index 25c826ed3b65..5e5beaa9ae15 100644 --- a/arch/arm/plat-samsung/Makefile +++ b/arch/arm/plat-samsung/Makefile @@ -4,6 +4,9 @@ # # Licensed under GPLv2 +ccflags-$(CONFIG_ARCH_MULTI_V7) += -I$(srctree)/$(src)/include +ccflags-$(CONFIG_ARCH_EXYNOS) += -I$(srctree)/arch/arm/mach-exynos/include + obj-y := obj-m := obj-n := dummy.o