[PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Tomasz Figa]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Bartlomiej Zolnierkiewicz]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Olof Johansson]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Bartlomiej Zolnierkiewicz]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Olof Johansson]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Tomasz Figa]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Sachin Kamat]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Kukjin Kim]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Olof Johansson]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Tomasz Figa]

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

Re: [PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[Tomasz Figa]

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

[PATCH 1/1] ARM: EXYNOS: Consolidate Kconfig entries

[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