| Message ID | 1391687996-26011-1-git-send-email-sachin.kamat@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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(-)