* [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
@ 2014-02-06 11:59 Sachin Kamat
2014-02-06 14:10 ` Tomasz Figa
0 siblings, 1 reply; 13+ messages in thread
From: Sachin Kamat @ 2014-02-06 11:59 UTC (permalink / raw)
To: linux-samsung-soc; +Cc: kgene.kim, olof, sachin.kamat
Instead of repeating the Kconfig entries for every SoC, move them under
ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
machine/platform code, keep them as boolean symbols instead of user
selectable and select them from Exynos4 and 5 config symbols. Individual
SoC symbols can be removed eventually once the driver Kconfig dependencies
on these symbols are removed.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
arch/arm/Kconfig | 12 ++++++
arch/arm/mach-exynos/Kconfig | 97 ++++++++++--------------------------------
2 files changed, 35 insertions(+), 74 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e25419817791..56a9990ef58e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -829,18 +829,30 @@ config ARCH_S5PV210
config ARCH_EXYNOS
bool "Samsung EXYNOS"
+ select ARCH_HAS_BANDGAP
select ARCH_HAS_CPUFREQ
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_REQUIRE_GPIOLIB
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
+ select S5P_DEV_MFC
+ select S5P_PM if PM
+ select S5P_SLEEP if PM
+ select SAMSUNG_DMADEV
select SPARSE_IRQ
select USE_OF
help
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 4c414af75ef0..54162ef1656e 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -14,99 +14,33 @@ menu "SAMSUNG EXYNOS SoCs Support"
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
- select ARM_AMBA
- select CLKSRC_OF
+ select ARM_CPU_SUSPEND if PM
select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210
select CPU_EXYNOS4210
select GIC_NON_BANKED
select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
- select HAVE_ARM_SCU if SMP
- select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
- select PINCTRL
- select PM_GENERIC_DOMAINS if PM
- select S5P_DEV_MFC
+ select SOC_EXYNOS4212
+ select SOC_EXYNOS4412
help
- Samsung EXYNOS4 SoCs based systems
+ Samsung EXYNOS4 (Cortex-A9) SoC based systems
config ARCH_EXYNOS5
bool "SAMSUNG EXYNOS5"
- select ARM_AMBA
- select CLKSRC_OF
- select HAVE_ARM_SCU if SMP
- select HAVE_SMP
- select PINCTRL
+ default y
+ select SOC_EXYNOS5250
+ select SOC_EXYNOS5420
select USB_ARCH_HAS_XHCI
help
- Samsung EXYNOS5 (Cortex-A15) SoC based systems
+ Samsung EXYNOS5 (Cortex-A15/A7) SoC based systems
comment "EXYNOS SoCs"
-config CPU_EXYNOS4210
- bool "SAMSUNG EXYNOS4210"
- default y
- depends on ARCH_EXYNOS4
- select ARCH_HAS_BANDGAP
- select ARM_CPU_SUSPEND if PM
- select PINCTRL_EXYNOS
- select S5P_PM if PM
- select S5P_SLEEP if PM
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS4210 CPU support
-
-config SOC_EXYNOS4212
- bool "SAMSUNG EXYNOS4212"
- default y
- depends on ARCH_EXYNOS4
- select ARCH_HAS_BANDGAP
- select PINCTRL_EXYNOS
- select S5P_PM if PM
- select S5P_SLEEP if PM
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS4212 SoC support
-
-config SOC_EXYNOS4412
- bool "SAMSUNG EXYNOS4412"
- default y
- depends on ARCH_EXYNOS4
- select ARCH_HAS_BANDGAP
- select PINCTRL_EXYNOS
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS4412 SoC support
-
-config SOC_EXYNOS5250
- bool "SAMSUNG EXYNOS5250"
- default y
- depends on ARCH_EXYNOS5
- select ARCH_HAS_BANDGAP
- select PINCTRL_EXYNOS
- select PM_GENERIC_DOMAINS if PM
- select S5P_PM if PM
- select S5P_SLEEP if PM
- select S5P_DEV_MFC
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS5250 SoC support
-
-config SOC_EXYNOS5420
- bool "SAMSUNG EXYNOS5420"
- default y
- depends on ARCH_EXYNOS5
- select PM_GENERIC_DOMAINS if PM
- select S5P_PM if PM
- select S5P_SLEEP if PM
- help
- Enable EXYNOS5420 SoC support
-
config SOC_EXYNOS5440
bool "SAMSUNG EXYNOS5440"
default y
depends on ARCH_EXYNOS5
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
- select ARCH_HAS_BANDGAP
select ARCH_HAS_OPP
select HAVE_ARM_ARCH_TIMER
select AUTO_ZRELADDR
@@ -119,4 +53,19 @@ config SOC_EXYNOS5440
endmenu
+config CPU_EXYNOS4210
+ bool
+
+config SOC_EXYNOS4212
+ bool
+
+config SOC_EXYNOS4412
+ bool
+
+config SOC_EXYNOS5250
+ bool
+
+config SOC_EXYNOS5420
+ bool
+
endif
--
1.7.9.5
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-06 11:59 [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries Sachin Kamat
@ 2014-02-06 14:10 ` Tomasz Figa
2014-02-06 15:02 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2014-02-06 14:10 UTC (permalink / raw)
To: Sachin Kamat, linux-samsung-soc; +Cc: kgene.kim, olof
Hi Sachin,
On 06.02.2014 12:59, Sachin Kamat wrote:
> Instead of repeating the Kconfig entries for every SoC, move them under
> ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
> ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
> machine/platform code, keep them as boolean symbols instead of user
> selectable and select them from Exynos4 and 5 config symbols. Individual
> SoC symbols can be removed eventually once the driver Kconfig dependencies
> on these symbols are removed.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> arch/arm/Kconfig | 12 ++++++
> arch/arm/mach-exynos/Kconfig | 97 ++++++++++--------------------------------
> 2 files changed, 35 insertions(+), 74 deletions(-)
I fully agree that there is no real need of having per-SoC Kconfig
entries, since the differences caused by them are quite insignificant.
Moreover, this makes me wonder if there is even need to distinguish
between ARCH_EXYNOS4 and ARCH_EXYNOS5...
Anyway, I second this patch:
Acked-by: Tomasz Figa <t.figa@samsung.com>
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-06 14:10 ` Tomasz Figa
@ 2014-02-06 15:02 ` Bartlomiej Zolnierkiewicz
2014-02-06 18:25 ` Olof Johansson
0 siblings, 1 reply; 13+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2014-02-06 15:02 UTC (permalink / raw)
To: Tomasz Figa; +Cc: Sachin Kamat, linux-samsung-soc, kgene.kim, olof
Hi,
On Thursday, February 06, 2014 03:10:39 PM Tomasz Figa wrote:
> Hi Sachin,
>
> On 06.02.2014 12:59, Sachin Kamat wrote:
> > Instead of repeating the Kconfig entries for every SoC, move them under
> > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
> > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
> > machine/platform code, keep them as boolean symbols instead of user
All soc_is_exynosxxxx() dependent code gets thrown away is specific SoC
support is not selected. With this change this is not longer true.
Moreover some drivers are doing explicit ifdef checks for specific SoC
support, i.e. thermal driver.
> > selectable and select them from Exynos4 and 5 config symbols. Individual
> > SoC symbols can be removed eventually once the driver Kconfig dependencies
> > on these symbols are removed.
> >
> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> > ---
> > arch/arm/Kconfig | 12 ++++++
> > arch/arm/mach-exynos/Kconfig | 97 ++++++++++--------------------------------
> > 2 files changed, 35 insertions(+), 74 deletions(-)
>
> I fully agree that there is no real need of having per-SoC Kconfig
> entries, since the differences caused by them are quite insignificant.
I think so but some numbers to back it up would be good..
> Moreover, this makes me wonder if there is even need to distinguish
> between ARCH_EXYNOS4 and ARCH_EXYNOS5...
Well, once again, seeing some numbers would be good. :)
> Anyway, I second this patch:
>
> Acked-by: Tomasz Figa <t.figa@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-06 15:02 ` Bartlomiej Zolnierkiewicz
@ 2014-02-06 18:25 ` Olof Johansson
2014-02-06 18:43 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 13+ messages in thread
From: Olof Johansson @ 2014-02-06 18:25 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Tomasz Figa, Sachin Kamat, linux-samsung-soc@vger.kernel.org,
Kukjin Kim
On Thu, Feb 6, 2014 at 7:02 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>
> Hi,
>
> On Thursday, February 06, 2014 03:10:39 PM Tomasz Figa wrote:
>> Hi Sachin,
>>
>> On 06.02.2014 12:59, Sachin Kamat wrote:
>> > Instead of repeating the Kconfig entries for every SoC, move them under
>> > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
>> > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
>> > machine/platform code, keep them as boolean symbols instead of user
>
> All soc_is_exynosxxxx() dependent code gets thrown away is specific SoC
> support is not selected. With this change this is not longer true.
> Moreover some drivers are doing explicit ifdef checks for specific SoC
> support, i.e. thermal driver.
I'm guessing you're referring to exynos_tmu_data.c? That's not all
that much data, and not all that substantial compared to things like
pinctrl and clocks. Removing those ifdefs per SoC is reasonable.
I'm ok with one Kconfig per family (EXYNOS 4 and 5), but we should
avoid higher granularity than that. That's similar to how OMAP is
handled. i.MX is more granular but they aren't introducing as many
SoCs as Samsung so it's not as big a deal.
>> > selectable and select them from Exynos4 and 5 config symbols. Individual
>> > SoC symbols can be removed eventually once the driver Kconfig dependencies
>> > on these symbols are removed.
>> >
>> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
>> > ---
>> > arch/arm/Kconfig | 12 ++++++
>> > arch/arm/mach-exynos/Kconfig | 97 ++++++++++--------------------------------
>> > 2 files changed, 35 insertions(+), 74 deletions(-)
>>
>> I fully agree that there is no real need of having per-SoC Kconfig
>> entries, since the differences caused by them are quite insignificant.
>
> I think so but some numbers to back it up would be good..
>
>> Moreover, this makes me wonder if there is even need to distinguish
>> between ARCH_EXYNOS4 and ARCH_EXYNOS5...
>
> Well, once again, seeing some numbers would be good. :)
What numbers do you want? Size comparisons with all SoC options on vs only one?
-Olof
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-06 18:25 ` Olof Johansson
@ 2014-02-06 18:43 ` Bartlomiej Zolnierkiewicz
2014-02-06 18:59 ` Olof Johansson
0 siblings, 1 reply; 13+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2014-02-06 18:43 UTC (permalink / raw)
To: Olof Johansson
Cc: Tomasz Figa, Sachin Kamat, linux-samsung-soc@vger.kernel.org,
Kukjin Kim
On Thursday, February 06, 2014 10:25:09 AM Olof Johansson wrote:
> On Thu, Feb 6, 2014 at 7:02 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
> >
> > Hi,
> >
> > On Thursday, February 06, 2014 03:10:39 PM Tomasz Figa wrote:
> >> Hi Sachin,
> >>
> >> On 06.02.2014 12:59, Sachin Kamat wrote:
> >> > Instead of repeating the Kconfig entries for every SoC, move them under
> >> > ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
> >> > ARCH_EXYNOS. Also, since the individual SoCs do not have any specific
> >> > machine/platform code, keep them as boolean symbols instead of user
> >
> > All soc_is_exynosxxxx() dependent code gets thrown away is specific SoC
> > support is not selected. With this change this is not longer true.
> > Moreover some drivers are doing explicit ifdef checks for specific SoC
> > support, i.e. thermal driver.
>
> I'm guessing you're referring to exynos_tmu_data.c? That's not all
Yes.
> that much data, and not all that substantial compared to things like
> pinctrl and clocks. Removing those ifdefs per SoC is reasonable.
I agree. I just wanted to point out that the current patch description
is not entirely accurate.
> I'm ok with one Kconfig per family (EXYNOS 4 and 5), but we should
> avoid higher granularity than that. That's similar to how OMAP is
> handled. i.MX is more granular but they aren't introducing as many
> SoCs as Samsung so it's not as big a deal.
OK.
> >> > selectable and select them from Exynos4 and 5 config symbols. Individual
> >> > SoC symbols can be removed eventually once the driver Kconfig dependencies
> >> > on these symbols are removed.
> >> >
> >> > Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> >> > ---
> >> > arch/arm/Kconfig | 12 ++++++
> >> > arch/arm/mach-exynos/Kconfig | 97 ++++++++++--------------------------------
> >> > 2 files changed, 35 insertions(+), 74 deletions(-)
> >>
> >> I fully agree that there is no real need of having per-SoC Kconfig
> >> entries, since the differences caused by them are quite insignificant.
> >
> > I think so but some numbers to back it up would be good..
> >
> >> Moreover, this makes me wonder if there is even need to distinguish
> >> between ARCH_EXYNOS4 and ARCH_EXYNOS5...
> >
> > Well, once again, seeing some numbers would be good. :)
>
> What numbers do you want? Size comparisons with all SoC options on vs only one?
Yes, size comparisions with all SoCs (for given family) turned on vs
only one turned on (done on kernel without this patch applied).
Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
applied).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-06 18:43 ` Bartlomiej Zolnierkiewicz
@ 2014-02-06 18:59 ` Olof Johansson
2014-02-07 16:33 ` Tomasz Figa
0 siblings, 1 reply; 13+ messages in thread
From: Olof Johansson @ 2014-02-06 18:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: Tomasz Figa, Sachin Kamat, linux-samsung-soc@vger.kernel.org,
Kukjin Kim
On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
>> > Well, once again, seeing some numbers would be good. :)
>>
>> What numbers do you want? Size comparisons with all SoC options on vs only one?
>
> Yes, size comparisions with all SoCs (for given family) turned on vs
> only one turned on (done on kernel without this patch applied).
>
> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
> applied).
exynos_defconfig-based build data below.
text data bss dec hex filename
5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs enabled
5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
off, all EXYNOS4 SoCs enabled
5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210 enabled
5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
off, all EXYNOS5 SoCs enabled
5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250 enabled
5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
5250+5420 enabled
5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440 enabled
The main difference of disabling 5440 is that it removed the PCI
support, which explains that reduction in size.
So, I would argue that theere might be some value in disabling whole
families (since it saves about 20k of text and the same of data), but
that there's less gain per SoC member. 5440 is an oddball in this
setup so it might make sense to treat it differently due to the PCI
aspect.
-Olof
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-06 18:59 ` Olof Johansson
@ 2014-02-07 16:33 ` Tomasz Figa
2014-02-10 4:50 ` Sachin Kamat
0 siblings, 1 reply; 13+ messages in thread
From: Tomasz Figa @ 2014-02-07 16:33 UTC (permalink / raw)
To: Olof Johansson, Bartlomiej Zolnierkiewicz
Cc: Sachin Kamat, linux-samsung-soc@vger.kernel.org, Kukjin Kim
On 06.02.2014 19:59, Olof Johansson wrote:
> On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
> <b.zolnierkie@samsung.com> wrote:
>
>>>> Well, once again, seeing some numbers would be good. :)
>>>
>>> What numbers do you want? Size comparisons with all SoC options on vs only one?
>>
>> Yes, size comparisions with all SoCs (for given family) turned on vs
>> only one turned on (done on kernel without this patch applied).
>>
>> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
>> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
>> applied).
>
> exynos_defconfig-based build data below.
>
> text data bss dec hex filename
> 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs enabled
> 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
> off, all EXYNOS4 SoCs enabled
> 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210 enabled
> 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
> off, all EXYNOS5 SoCs enabled
> 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250 enabled
> 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
> 5250+5420 enabled
> 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440 enabled
>
> The main difference of disabling 5440 is that it removed the PCI
> support, which explains that reduction in size.
>
> So, I would argue that theere might be some value in disabling whole
> families (since it saves about 20k of text and the same of data), but
> that there's less gain per SoC member. 5440 is an oddball in this
> setup so it might make sense to treat it differently due to the PCI
> aspect.
Well, the numbers basically represent what I expected. Thanks for
checking this. So I second this patch even more now, but maybe let's
change it a bit and introduce third entry for Exynos5440, since it
doesn't really belong to either of ARCHs. Candidates that come to my
mind are ARCH_EXYNOS5440 (seems to specific) or ARCH_EXYNOS5_SERVER.
Feel free to suggest anything better, though.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-07 16:33 ` Tomasz Figa
@ 2014-02-10 4:50 ` Sachin Kamat
2014-02-11 6:10 ` Kukjin Kim
0 siblings, 1 reply; 13+ messages in thread
From: Sachin Kamat @ 2014-02-10 4:50 UTC (permalink / raw)
To: Tomasz Figa
Cc: Olof Johansson, Bartlomiej Zolnierkiewicz,
linux-samsung-soc@vger.kernel.org, Kukjin Kim
On 7 February 2014 22:03, Tomasz Figa <t.figa@samsung.com> wrote:
> On 06.02.2014 19:59, Olof Johansson wrote:
>>
>> On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
>> <b.zolnierkie@samsung.com> wrote:
>>
>>>>> Well, once again, seeing some numbers would be good. :)
>>>>
>>>>
>>>> What numbers do you want? Size comparisons with all SoC options on vs
>>>> only one?
>>>
>>>
>>> Yes, size comparisions with all SoCs (for given family) turned on vs
>>> only one turned on (done on kernel without this patch applied).
>>>
>>> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
>>> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
>>> applied).
>>
>>
>> exynos_defconfig-based build data below.
>>
>> text data bss dec hex filename
>> 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs
>> enabled
>> 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
>> off, all EXYNOS4 SoCs enabled
>> 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210
>> enabled
>> 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
>> off, all EXYNOS5 SoCs enabled
>> 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250
>> enabled
>> 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
>> 5250+5420 enabled
>> 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440
>> enabled
>>
>> The main difference of disabling 5440 is that it removed the PCI
>> support, which explains that reduction in size.
>>
>> So, I would argue that theere might be some value in disabling whole
>> families (since it saves about 20k of text and the same of data), but
>> that there's less gain per SoC member. 5440 is an oddball in this
>> setup so it might make sense to treat it differently due to the PCI
>> aspect.
>
>
> Well, the numbers basically represent what I expected. Thanks for checking
> this.
Thanks to Olof for coming out with these numbers.
>So I second this patch even more now,
Thanks Tomasz :)
> but maybe let's change it a bit
> and introduce third entry for Exynos5440, since it doesn't really belong to
> either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems
> to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better,
> though.
Though Exynos5440 belongs to the Exynos5 family, it is different in a
few ways and hence
I preferred to keep it as a separate entry for now. I agree with your
suggestion to have a third
ARCH category but I would prefer to wait for a while until we have one
more candidate for this
category so that we have a bit more data for naming and grouping.
--
With warm regards,
Sachin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-10 4:50 ` Sachin Kamat
@ 2014-02-11 6:10 ` Kukjin Kim
2014-02-11 6:30 ` Olof Johansson
2014-02-11 11:08 ` Tomasz Figa
0 siblings, 2 replies; 13+ messages in thread
From: Kukjin Kim @ 2014-02-11 6:10 UTC (permalink / raw)
To: Sachin Kamat
Cc: Tomasz Figa, Olof Johansson, Bartlomiej Zolnierkiewicz,
linux-samsung-soc@vger.kernel.org
2014-02-10 10:20 GMT+05:30 Sachin Kamat <sachin.kamat@linaro.org>:
>
> On 7 February 2014 22:03, Tomasz Figa <t.figa@samsung.com> wrote:
> > On 06.02.2014 19:59, Olof Johansson wrote:
> >>
> >> On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
> >> <b.zolnierkie@samsung.com> wrote:
> >>
> >>>>> Well, once again, seeing some numbers would be good. :)
> >>>>
> >>>>
> >>>> What numbers do you want? Size comparisons with all SoC options on vs
> >>>> only one?
> >>>
> >>>
> >>> Yes, size comparisions with all SoCs (for given family) turned on vs
> >>> only one turned on (done on kernel without this patch applied).
> >>>
> >>> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
> >>> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
> >>> applied).
> >>
> >>
> >> exynos_defconfig-based build data below.
> >>
> >> text data bss dec hex filename
> >> 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs
> >> enabled
> >> 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
> >> off, all EXYNOS4 SoCs enabled
> >> 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210
> >> enabled
> >> 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
> >> off, all EXYNOS5 SoCs enabled
> >> 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250
> >> enabled
> >> 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
> >> 5250+5420 enabled
> >> 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440
> >> enabled
> >>
> >> The main difference of disabling 5440 is that it removed the PCI
> >> support, which explains that reduction in size.
> >>
> >> So, I would argue that theere might be some value in disabling whole
> >> families (since it saves about 20k of text and the same of data), but
> >> that there's less gain per SoC member. 5440 is an oddball in this
> >> setup so it might make sense to treat it differently due to the PCI
> >> aspect.
> >
> >
> > Well, the numbers basically represent what I expected. Thanks for checking
> > this.
>
> Thanks to Olof for coming out with these numbers.
>
> >So I second this patch even more now,
>
> Thanks Tomasz :)
>
> > but maybe let's change it a bit
> > and introduce third entry for Exynos5440, since it doesn't really belong to
> > either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems
> > to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better,
> > though.
>
> Though Exynos5440 belongs to the Exynos5 family, it is different in a
> few ways and hence
> I preferred to keep it as a separate entry for now. I agree with your
> suggestion to have a third
> ARCH category but I would prefer to wait for a while until we have one
> more candidate for this
> category so that we have a bit more data for naming and grouping.
>
Well, I also, having soc number would be good like 5440 you thought
because I can't say upcoming exynos ARMv7 based SoCs are familiar with
previous exynos SoCs or not at this moment. And it means sometimes we
need to add the numbering and sometime we don't need. It's not fair
enough I think. And I have strong objection on Thomasz' suggestion
about ARCH_EXYNOS5_SERVER? Please don't guess.
- Kukjin
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-11 6:10 ` Kukjin Kim
@ 2014-02-11 6:30 ` Olof Johansson
2014-02-11 11:15 ` Tomasz Figa
2014-02-11 11:08 ` Tomasz Figa
1 sibling, 1 reply; 13+ messages in thread
From: Olof Johansson @ 2014-02-11 6:30 UTC (permalink / raw)
To: Kukjin Kim
Cc: Sachin Kamat, Tomasz Figa, Bartlomiej Zolnierkiewicz,
linux-samsung-soc@vger.kernel.org
Hi,
On Mon, Feb 10, 2014 at 10:10 PM, Kukjin Kim <kgene.kim@gmail.com> wrote:
> 2014-02-10 10:20 GMT+05:30 Sachin Kamat <sachin.kamat@linaro.org>:
>>
>> On 7 February 2014 22:03, Tomasz Figa <t.figa@samsung.com> wrote:
>> > On 06.02.2014 19:59, Olof Johansson wrote:
>> >>
>> >> On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
>> >> <b.zolnierkie@samsung.com> wrote:
>> >>
>> >>>>> Well, once again, seeing some numbers would be good. :)
>> >>>>
>> >>>>
>> >>>> What numbers do you want? Size comparisons with all SoC options on vs
>> >>>> only one?
>> >>>
>> >>>
>> >>> Yes, size comparisions with all SoCs (for given family) turned on vs
>> >>> only one turned on (done on kernel without this patch applied).
>> >>>
>> >>> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
>> >>> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
>> >>> applied).
>> >>
>> >>
>> >> exynos_defconfig-based build data below.
>> >>
>> >> text data bss dec hex filename
>> >> 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs
>> >> enabled
>> >> 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
>> >> off, all EXYNOS4 SoCs enabled
>> >> 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210
>> >> enabled
>> >> 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
>> >> off, all EXYNOS5 SoCs enabled
>> >> 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250
>> >> enabled
>> >> 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
>> >> 5250+5420 enabled
>> >> 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440
>> >> enabled
>> >>
>> >> The main difference of disabling 5440 is that it removed the PCI
>> >> support, which explains that reduction in size.
>> >>
>> >> So, I would argue that theere might be some value in disabling whole
>> >> families (since it saves about 20k of text and the same of data), but
>> >> that there's less gain per SoC member. 5440 is an oddball in this
>> >> setup so it might make sense to treat it differently due to the PCI
>> >> aspect.
>> >
>> >
>> > Well, the numbers basically represent what I expected. Thanks for checking
>> > this.
>>
>> Thanks to Olof for coming out with these numbers.
>>
>> >So I second this patch even more now,
>>
>> Thanks Tomasz :)
>>
>> > but maybe let's change it a bit
>> > and introduce third entry for Exynos5440, since it doesn't really belong to
>> > either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems
>> > to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better,
>> > though.
>>
>> Though Exynos5440 belongs to the Exynos5 family, it is different in a
>> few ways and hence
>> I preferred to keep it as a separate entry for now. I agree with your
>> suggestion to have a third
>> ARCH category but I would prefer to wait for a while until we have one
>> more candidate for this
>> category so that we have a bit more data for naming and grouping.
>>
> Well, I also, having soc number would be good like 5440 you thought
> because I can't say upcoming exynos ARMv7 based SoCs are familiar with
> previous exynos SoCs or not at this moment. And it means sometimes we
> need to add the numbering and sometime we don't need. It's not fair
> enough I think. And I have strong objection on Thomasz' suggestion
> about ARCH_EXYNOS5_SERVER? Please don't guess.
Well, we know that we do not want to see new options for every single
new SoC that are similar to existing ones. It's just not needed, as
the size comparisons above shows.
So, I think today, we should have three options:
EXYNOS4
EXYNOS5
EXYNOS5440
5440 can depend on EXYNOS5 today if it makes sense. Only reason to let
it have its own option is that it's substantially different from the
others in that it pulls in PCI and causes kernel size to go up. If
other SoCs are added that are quire similar to 5440, then the right
option is probably to group them under an option together with 5440.
It doesn't matter if it's called server or something else as long as
they're mostly kept together. And for now that's just theoretical
anwyay: Let's keep calling it 5440 until there's reason to change it.
-Olof
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-11 6:30 ` Olof Johansson
@ 2014-02-11 11:15 ` Tomasz Figa
0 siblings, 0 replies; 13+ messages in thread
From: Tomasz Figa @ 2014-02-11 11:15 UTC (permalink / raw)
To: Olof Johansson, Kukjin Kim
Cc: Sachin Kamat, Bartlomiej Zolnierkiewicz,
linux-samsung-soc@vger.kernel.org
On 11.02.2014 07:30, Olof Johansson wrote:
> Hi,
>
> On Mon, Feb 10, 2014 at 10:10 PM, Kukjin Kim <kgene.kim@gmail.com> wrote:
>> 2014-02-10 10:20 GMT+05:30 Sachin Kamat <sachin.kamat@linaro.org>:
>>>
>>> On 7 February 2014 22:03, Tomasz Figa <t.figa@samsung.com> wrote:
>>>> On 06.02.2014 19:59, Olof Johansson wrote:
>>>>>
>>>>> On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
>>>>> <b.zolnierkie@samsung.com> wrote:
>>>>>
>>>>>>>> Well, once again, seeing some numbers would be good. :)
>>>>>>>
>>>>>>>
>>>>>>> What numbers do you want? Size comparisons with all SoC options on vs
>>>>>>> only one?
>>>>>>
>>>>>>
>>>>>> Yes, size comparisions with all SoCs (for given family) turned on vs
>>>>>> only one turned on (done on kernel without this patch applied).
>>>>>>
>>>>>> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
>>>>>> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
>>>>>> applied).
>>>>>
>>>>>
>>>>> exynos_defconfig-based build data below.
>>>>>
>>>>> text data bss dec hex filename
>>>>> 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs
>>>>> enabled
>>>>> 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
>>>>> off, all EXYNOS4 SoCs enabled
>>>>> 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210
>>>>> enabled
>>>>> 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
>>>>> off, all EXYNOS5 SoCs enabled
>>>>> 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250
>>>>> enabled
>>>>> 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
>>>>> 5250+5420 enabled
>>>>> 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440
>>>>> enabled
>>>>>
>>>>> The main difference of disabling 5440 is that it removed the PCI
>>>>> support, which explains that reduction in size.
>>>>>
>>>>> So, I would argue that theere might be some value in disabling whole
>>>>> families (since it saves about 20k of text and the same of data), but
>>>>> that there's less gain per SoC member. 5440 is an oddball in this
>>>>> setup so it might make sense to treat it differently due to the PCI
>>>>> aspect.
>>>>
>>>>
>>>> Well, the numbers basically represent what I expected. Thanks for checking
>>>> this.
>>>
>>> Thanks to Olof for coming out with these numbers.
>>>
>>>> So I second this patch even more now,
>>>
>>> Thanks Tomasz :)
>>>
>>>> but maybe let's change it a bit
>>>> and introduce third entry for Exynos5440, since it doesn't really belong to
>>>> either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems
>>>> to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better,
>>>> though.
>>>
>>> Though Exynos5440 belongs to the Exynos5 family, it is different in a
>>> few ways and hence
>>> I preferred to keep it as a separate entry for now. I agree with your
>>> suggestion to have a third
>>> ARCH category but I would prefer to wait for a while until we have one
>>> more candidate for this
>>> category so that we have a bit more data for naming and grouping.
>>>
>> Well, I also, having soc number would be good like 5440 you thought
>> because I can't say upcoming exynos ARMv7 based SoCs are familiar with
>> previous exynos SoCs or not at this moment. And it means sometimes we
>> need to add the numbering and sometime we don't need. It's not fair
>> enough I think. And I have strong objection on Thomasz' suggestion
>> about ARCH_EXYNOS5_SERVER? Please don't guess.
>
> Well, we know that we do not want to see new options for every single
> new SoC that are similar to existing ones. It's just not needed, as
> the size comparisons above shows.
>
> So, I think today, we should have three options:
>
> EXYNOS4
> EXYNOS5
> EXYNOS5440
>
> 5440 can depend on EXYNOS5 today if it makes sense. Only reason to let
> it have its own option is that it's substantially different from the
> others in that it pulls in PCI and causes kernel size to go up.
Well, hardware-wise it's completely different. Even the pin controller
needs a separate driver (pinctrl-exynos5440.c vs
pinctrl-exynos.c+pinctrl-samsung.c), so I believe a third option is
completely justified.
> If
> other SoCs are added that are quire similar to 5440, then the right
> option is probably to group them under an option together with 5440.
> It doesn't matter if it's called server or something else as long as
> they're mostly kept together. And for now that's just theoretical
> anwyay: Let's keep calling it 5440 until there's reason to change it.
Fair enough. That was basically my first proposal, which sounded a bit
too specific to me, but I guess it can't be helped.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
2014-02-11 6:10 ` Kukjin Kim
2014-02-11 6:30 ` Olof Johansson
@ 2014-02-11 11:08 ` Tomasz Figa
1 sibling, 0 replies; 13+ messages in thread
From: Tomasz Figa @ 2014-02-11 11:08 UTC (permalink / raw)
To: Kukjin Kim, Sachin Kamat
Cc: Olof Johansson, Bartlomiej Zolnierkiewicz,
linux-samsung-soc@vger.kernel.org
On 11.02.2014 07:10, Kukjin Kim wrote:
> 2014-02-10 10:20 GMT+05:30 Sachin Kamat <sachin.kamat@linaro.org>:
>>
>> On 7 February 2014 22:03, Tomasz Figa <t.figa@samsung.com> wrote:
>>> On 06.02.2014 19:59, Olof Johansson wrote:
>>>>
>>>> On Thu, Feb 6, 2014 at 10:43 AM, Bartlomiej Zolnierkiewicz
>>>> <b.zolnierkie@samsung.com> wrote:
>>>>
>>>>>>> Well, once again, seeing some numbers would be good. :)
>>>>>>
>>>>>>
>>>>>> What numbers do you want? Size comparisons with all SoC options on vs
>>>>>> only one?
>>>>>
>>>>>
>>>>> Yes, size comparisions with all SoCs (for given family) turned on vs
>>>>> only one turned on (done on kernel without this patch applied).
>>>>>
>>>>> Also size comparisons for ARCH_EXYNOS4 and ARCH_EXYNOS5 both turned
>>>>> on vs only ARCH_EXYNOS4 or ARCH_EXYNOS5 turned on (with this patch
>>>>> applied).
>>>>
>>>>
>>>> exynos_defconfig-based build data below.
>>>>
>>>> text data bss dec hex filename
>>>> 5109986 319952 270196 5700134 56fa26 obj-tmp/vmlinux # all 4+5 SoCs
>>>> enabled
>>>> 5088312 296912 270196 5655420 564b7c obj-tmp/vmlinux # EXYNOS5
>>>> off, all EXYNOS4 SoCs enabled
>>>> 5088032 296896 270196 5655124 564a54 obj-tmp/vmlinux # Only 4210
>>>> enabled
>>>> 5079205 299928 270068 5649201 563331 obj-tmp/vmlinux # EXYNOS4
>>>> off, all EXYNOS5 SoCs enabled
>>>> 5063355 286792 270068 5620215 55c1f7 obj-tmp/vmlinux # Only 5250
>>>> enabled
>>>> 5067815 298152 270068 5636035 55ffc3 obj-tmp/vmlinux # Only
>>>> 5250+5420 enabled
>>>> 5053357 278480 269364 5601201 5577b1 obj-tmp/vmlinux # Only 5440
>>>> enabled
>>>>
>>>> The main difference of disabling 5440 is that it removed the PCI
>>>> support, which explains that reduction in size.
>>>>
>>>> So, I would argue that theere might be some value in disabling whole
>>>> families (since it saves about 20k of text and the same of data), but
>>>> that there's less gain per SoC member. 5440 is an oddball in this
>>>> setup so it might make sense to treat it differently due to the PCI
>>>> aspect.
>>>
>>>
>>> Well, the numbers basically represent what I expected. Thanks for checking
>>> this.
>>
>> Thanks to Olof for coming out with these numbers.
>>
>>> So I second this patch even more now,
>>
>> Thanks Tomasz :)
>>
>>> but maybe let's change it a bit
>>> and introduce third entry for Exynos5440, since it doesn't really belong to
>>> either of ARCHs. Candidates that come to my mind are ARCH_EXYNOS5440 (seems
>>> to specific) or ARCH_EXYNOS5_SERVER. Feel free to suggest anything better,
>>> though.
>>
>> Though Exynos5440 belongs to the Exynos5 family, it is different in a
>> few ways and hence
>> I preferred to keep it as a separate entry for now. I agree with your
>> suggestion to have a third
>> ARCH category but I would prefer to wait for a while until we have one
>> more candidate for this
>> category so that we have a bit more data for naming and grouping.
>>
> Well, I also, having soc number would be good like 5440 you thought
> because I can't say upcoming exynos ARMv7 based SoCs are familiar with
> previous exynos SoCs or not at this moment. And it means sometimes we
> need to add the numbering and sometime we don't need. It's not fair
> enough I think. And I have strong objection on Thomasz' suggestion
> about ARCH_EXYNOS5_SERVER? Please don't guess.
As I said, feel free to suggest anything better. I just came up with 2
examples. The fact that Exynos 5440 does not have much in common with
other Exynos 5 SoCs is completely obvious and so a third option should
be present in Kconfig, to not enable 5440 if you want support for just
"the other" Exynos 5 SoCs and vice versa.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries
@ 2014-04-02 8:55 Sachin Kamat
0 siblings, 0 replies; 13+ messages in thread
From: Sachin Kamat @ 2014-04-02 8:55 UTC (permalink / raw)
To: linux-samsung-soc; +Cc: kgene.kim, sachin.kamat
Instead of repeating the Kconfig entries for every SoC, move them under
ARCH_EXYNOS4 and 5 and move the entries common to both 4 and 5 under
ARCH_EXYNOS.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
Changes since previous version:
Kept the individual machines selectable as suggested by
Kukjin Kim.
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/mach-exynos/Kconfig | 45 ++++--------------------------------------
2 files changed, 14 insertions(+), 41 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a48712ed0444..73c2f2641375 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -831,18 +831,28 @@ config ARCH_S5PV210
config ARCH_EXYNOS
bool "Samsung EXYNOS"
+ select ARCH_HAS_BANDGAP
select ARCH_HAS_CPUFREQ
select ARCH_HAS_HOLES_MEMORYMODEL
select ARCH_REQUIRE_GPIOLIB
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
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index fc8bf18e222d..5c34dc26cec6 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -14,30 +14,20 @@ menu "SAMSUNG EXYNOS SoCs Support"
config ARCH_EXYNOS4
bool "SAMSUNG EXYNOS4"
default y
- select ARM_AMBA
- select CLKSRC_OF
+ select ARM_CPU_SUSPEND if PM_SLEEP
select CLKSRC_SAMSUNG_PWM if CPU_EXYNOS4210
select CPU_EXYNOS4210
select GIC_NON_BANKED
select KEYBOARD_SAMSUNG if INPUT_KEYBOARD
- select HAVE_ARM_SCU if SMP
- select HAVE_SMP
select MIGHT_HAVE_CACHE_L2X0
- select PINCTRL
- select PM_GENERIC_DOMAINS if PM_RUNTIME
- select S5P_DEV_MFC
help
- Samsung EXYNOS4 SoCs based systems
+ Samsung EXYNOS4 (Cortex-A9) SoC based systems
config ARCH_EXYNOS5
bool "SAMSUNG EXYNOS5"
- select ARM_AMBA
- select CLKSRC_OF
- select HAVE_ARM_SCU if SMP
- select HAVE_SMP
- select PINCTRL
+ default y
help
- Samsung EXYNOS5 (Cortex-A15) SoC based systems
+ Samsung EXYNOS5 (Cortex-A15/A7) SoC based systems
comment "EXYNOS SoCs"
@@ -45,59 +35,32 @@ config CPU_EXYNOS4210
bool "SAMSUNG EXYNOS4210"
default y
depends on ARCH_EXYNOS4
- select ARCH_HAS_BANDGAP
- select ARM_CPU_SUSPEND if PM_SLEEP
- select PINCTRL_EXYNOS
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS4210 CPU support
config SOC_EXYNOS4212
bool "SAMSUNG EXYNOS4212"
default y
depends on ARCH_EXYNOS4
- select ARCH_HAS_BANDGAP
- select PINCTRL_EXYNOS
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS4212 SoC support
config SOC_EXYNOS4412
bool "SAMSUNG EXYNOS4412"
default y
depends on ARCH_EXYNOS4
- select ARCH_HAS_BANDGAP
- select PINCTRL_EXYNOS
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS4412 SoC support
config SOC_EXYNOS5250
bool "SAMSUNG EXYNOS5250"
default y
depends on ARCH_EXYNOS5
- select ARCH_HAS_BANDGAP
- select PINCTRL_EXYNOS
- select PM_GENERIC_DOMAINS if PM_RUNTIME
- select S5P_DEV_MFC
- select SAMSUNG_DMADEV
- help
- Enable EXYNOS5250 SoC support
config SOC_EXYNOS5420
bool "SAMSUNG EXYNOS5420"
default y
depends on ARCH_EXYNOS5
- select PM_GENERIC_DOMAINS if PM_RUNTIME
- help
- Enable EXYNOS5420 SoC support
config SOC_EXYNOS5440
bool "SAMSUNG EXYNOS5440"
default y
depends on ARCH_EXYNOS5
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
- select ARCH_HAS_BANDGAP
select ARCH_HAS_OPP
select HAVE_ARM_ARCH_TIMER
select AUTO_ZRELADDR
--
1.7.9.5
^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-04-02 8:56 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-06 11:59 [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries Sachin Kamat
2014-02-06 14:10 ` Tomasz Figa
2014-02-06 15:02 ` Bartlomiej Zolnierkiewicz
2014-02-06 18:25 ` Olof Johansson
2014-02-06 18:43 ` Bartlomiej Zolnierkiewicz
2014-02-06 18:59 ` Olof Johansson
2014-02-07 16:33 ` Tomasz Figa
2014-02-10 4:50 ` Sachin Kamat
2014-02-11 6:10 ` Kukjin Kim
2014-02-11 6:30 ` Olof Johansson
2014-02-11 11:15 ` Tomasz Figa
2014-02-11 11:08 ` Tomasz Figa
-- strict thread matches above, loose matches on Subject: below --
2014-04-02 8:55 Sachin Kamat
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox