| Message ID | 1392100183-30930-3-git-send-email-kgene.kim@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 02/13/14 04:14, Arnd Bergmann wrote: > On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> wrote: >>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote: >>>> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. >>> >>> We already converted some of them (those depending on ARCH_VEXPRESS) to >>> just depend on ARM64. Ideally, at some point I’d like to see them as >>> defaulting to modules but I don’t think we are there yet (we had some >>> discussions at the last KS, I’m not sure anyone started looking into >>> this). >> >> I’m torn about this, I think for something like VEXPRESS it makes sense, >> however I think its reasonable to still have an config symbol for a full >> SoC family or something of that nature. > > I think for SBSA compliant systems, we should be able to live with a > generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, > we may need something more specific. > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about compliant with SBSA Level1 and having some specific features? - 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
On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > This patch adds support for Samsung GH7 SoC in arm64/Kconfig. > > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > Cc: Catalin Marinas <catalin.marinas@arm.com> The overhead of building one more device tree isn't very large, and I don't see any other need to have a Kconfig entry per SoC at this time. It's of course up to Catalin, but you might just want to always compile all dts files instead. -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 Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > This patch adds support for Samsung GH7 SoC in arm64/Kconfig. > > > > Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> > > Cc: Catalin Marinas <catalin.marinas@arm.com> > > The overhead of building one more device tree isn't very large, and I > don't see any other need to have a Kconfig entry per SoC at this time. > It's of course up to Catalin, but you might just want to always > compile all dts files instead. For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, only that I haven't heard any strong opinion either way (in which case I'll do it, with a risk of single Image getting bigger and bigger and people needing smaller Image can trim their .config).
On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>> Cc: Catalin Marinas <catalin.marinas@arm.com> >> >> The overhead of building one more device tree isn't very large, and I >> don't see any other need to have a Kconfig entry per SoC at this time. >> It's of course up to Catalin, but you might just want to always >> compile all dts files instead. > > For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, > only that I haven't heard any strong opinion either way (in which case > I'll do it, with a risk of single Image getting bigger and bigger and > people needing smaller Image can trim their .config). One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. - k
On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: > On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > >> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>>> >>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>>> Cc: Catalin Marinas <catalin.marinas@arm.com> >>> >>> The overhead of building one more device tree isn't very large, and I >>> don't see any other need to have a Kconfig entry per SoC at this time. >>> It's of course up to Catalin, but you might just want to always >>> compile all dts files instead. >> >> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, >> only that I haven't heard any strong opinion either way (in which case >> I'll do it, with a risk of single Image getting bigger and bigger and >> people needing smaller Image can trim their .config). > > One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. We already converted some of them (those depending on ARCH_VEXPRESS) to just depend on ARM64. Ideally, at some point I’d like to see them as defaulting to modules but I don’t think we are there yet (we had some discussions at the last KS, I’m not sure anyone started looking into this).-- 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 Feb 12, 2014, at 12:12 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: >> On Feb 12, 2014, at 4:38 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: >> >>> On Tue, Feb 11, 2014 at 11:39:27PM +0000, Olof Johansson wrote: >>>> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>>>> >>>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>>>> Cc: Catalin Marinas <catalin.marinas@arm.com> >>>> >>>> The overhead of building one more device tree isn't very large, and I >>>> don't see any other need to have a Kconfig entry per SoC at this time. >>>> It's of course up to Catalin, but you might just want to always >>>> compile all dts files instead. >>> >>> For arm64, I thought of getting rid of ARCH_* Kconfig entries entirely, >>> only that I haven't heard any strong opinion either way (in which case >>> I'll do it, with a risk of single Image getting bigger and bigger and >>> people needing smaller Image can trim their .config). >> >> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. > > We already converted some of them (those depending on ARCH_VEXPRESS) to > just depend on ARM64. Ideally, at some point I’d like to see them as > defaulting to modules but I don’t think we are there yet (we had some > discussions at the last KS, I’m not sure anyone started looking into > this). I’m torn about this, I think for something like VEXPRESS it makes sense, however I think its reasonable to still have an config symbol for a full SoC family or something of that nature. - k
On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > On Feb 12, 2014, at 12:12 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > > On 12 Feb 2014, at 16:25, Kumar Gala <galak@codeaurora.org> wrote: > >> One reason to keep around ARCH_* is for drivers shared between arm and arm64 that depend on it. > > > > We already converted some of them (those depending on ARCH_VEXPRESS) to > > just depend on ARM64. Ideally, at some point I’d like to see them as > > defaulting to modules but I don’t think we are there yet (we had some > > discussions at the last KS, I’m not sure anyone started looking into > > this). > > I’m torn about this, I think for something like VEXPRESS it makes sense, > however I think its reasonable to still have an config symbol for a full > SoC family or something of that nature. I think for SBSA compliant systems, we should be able to live with a generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, we may need something more specific. Arnd -- 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 Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 02/13/14 04:14, Arnd Bergmann wrote: >> >> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>> >>> On Feb 12, 2014, at 12:12 PM, Catalin Marinas<catalin.marinas@arm.com> >>> wrote: >>>> >>>> On 12 Feb 2014, at 16:25, Kumar Gala<galak@codeaurora.org> wrote: >>>>> >>>>> One reason to keep around ARCH_* is for drivers shared between arm and >>>>> arm64 that depend on it. >>>> >>>> >>>> We already converted some of them (those depending on ARCH_VEXPRESS) to >>>> just depend on ARM64. Ideally, at some point I'd like to see them as >>>> defaulting to modules but I don't think we are there yet (we had some >>>> discussions at the last KS, I'm not sure anyone started looking into >>>> this). >>> >>> >>> I'm torn about this, I think for something like VEXPRESS it makes sense, >>> however I think its reasonable to still have an config symbol for a full >>> SoC family or something of that nature. >> >> >> I think for SBSA compliant systems, we should be able to live with a >> generic ARCH_SBSA Kconfig symbol. For more irregular embedded platforms, >> we may need something more specific. >> > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > compliant with SBSA Level1 and having some specific features? (It's a little hard to answer since nobody can download the doc and then talk about it.) What kind of features are you expecting though? More IP blocks/devices? Those are just kernel config options to enable, ideally as modules. x86 doesn't need config options for each generation of their platform, and neither should ARM64. Sure, there might be drivers that don't make sense to enable on some platforms, but that's what defconfigs (or distro configs), and modules are for -- the modules won't load unless the hardware is there. As long as we're not talking about massive amounts of code that is part of the base platform, separating out per version again doesn't make sense -- just enable for SBSA and it'll support Level 1 through whatever. If the kernel size becomes a concern we can revisit, but let's not start out that way. -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 Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote: > On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >> >> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >> Cc: Catalin Marinas <catalin.marinas@arm.com> > > The overhead of building one more device tree isn't very large, and I > don't see any other need to have a Kconfig entry per SoC at this time. > It's of course up to Catalin, but you might just want to always > compile all dts files instead. I think having "make dtbs" build all regardless of the config would be better. Perhaps a "all_dtbs" target could be added and everyone can get what they want. If/when we add checking into dtc, this we certainly become more desirable. Rob -- 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 13, 2014 at 12:08 PM, Rob Herring <robherring2@gmail.com> wrote: > On Tue, Feb 11, 2014 at 5:39 PM, Olof Johansson <olof@lixom.net> wrote: >> On Mon, Feb 10, 2014 at 10:29 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> This patch adds support for Samsung GH7 SoC in arm64/Kconfig. >>> >>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> >>> Cc: Catalin Marinas <catalin.marinas@arm.com> >> >> The overhead of building one more device tree isn't very large, and I >> don't see any other need to have a Kconfig entry per SoC at this time. >> It's of course up to Catalin, but you might just want to always >> compile all dts files instead. > > I think having "make dtbs" build all regardless of the config would be > better. We can do that too, but that doesn't mean it's useful to have this kconfig entry. > Perhaps a "all_dtbs" target could be added and everyone can > get what they want. If/when we add checking into dtc, this we > certainly become more desirable. -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 13 February 2014, Olof Johansson wrote: > On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > On 02/13/14 04:14, Arnd Bergmann wrote: > >> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > > Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > > define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > > compliant with SBSA Level1 and having some specific features? My feeling is that we don't need to use the levels for Kconfig, although we might want to use them DT compatible strings, even if it ends up looking a little funny when you do compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > What kind of features are you expecting though? More IP > blocks/devices? Those are just kernel config options to enable, > ideally as modules. Right, I think we can just put them into defconfig. No need to "select" them from Kconfig since the extra options wouldn't be required for booting or using the system. Arnd -- 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 02/15/14 02:06, Arnd Bergmann wrote: > On Thursday 13 February 2014, Olof Johansson wrote: >> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >>> On 02/13/14 04:14, Arnd Bergmann wrote: >>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to >>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about >>> compliant with SBSA Level1 and having some specific features? > Well, how about ARMv8 mobile SoC? I think, it is not compatible with SBSA. For example, you know MCT can be used for ARMv8 cores instead of ARCH Timer. So I'm not sure ARCH_SBSA is really good choice... > My feeling is that we don't need to use the levels for Kconfig, although > we might want to use them DT compatible strings, even if it ends up looking > a little funny when you do > > compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > >> What kind of features are you expecting though? More IP >> blocks/devices? Those are just kernel config options to enable, >> ideally as modules. > > Right, I think we can just put them into defconfig. No need to > "select" them from Kconfig since the extra options wouldn't be > required for booting or using the system. > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, it is not for used for GH7 though... - 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
On Tuesday 18 February 2014 10:10:30 Kukjin Kim wrote: > On 02/15/14 02:06, Arnd Bergmann wrote: > > On Thursday 13 February 2014, Olof Johansson wrote: > >> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: > >>> On 02/13/14 04:14, Arnd Bergmann wrote: > >>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: > >>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need to > >>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about > >>> compliant with SBSA Level1 and having some specific features? > > > Well, how about ARMv8 mobile SoC? I think, it is not compatible with > SBSA. For example, you know MCT can be used for ARMv8 cores instead of > ARCH Timer. So I'm not sure ARCH_SBSA is really good choice... Sure, if you are talking about an embedded SoC that is not SBSA compliant, we shouldn't try to make it work with ARCH_SBSA and instead give it its own Kconfig symbol. > > My feeling is that we don't need to use the levels for Kconfig, although > > we might want to use them DT compatible strings, even if it ends up looking > > a little funny when you do > > > > compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > > > >> What kind of features are you expecting though? More IP > >> blocks/devices? Those are just kernel config options to enable, > >> ideally as modules. > > > > Right, I think we can just put them into defconfig. No need to > > "select" them from Kconfig since the extra options wouldn't be > > required for booting or using the system. > > > As I commented above, how about MCT? Samsung has a plan to use MCT on > ARMv8, it is not for used for GH7 though... If it's just one driver that is needed in addition to the usual stuff, we can also just make it a standalone option and turn it on in the generic defconfig. We won't need a per-platform option in that case. Arnd -- 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 Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > On 02/15/14 02:06, Arnd Bergmann wrote: >> >> On Thursday 13 February 2014, Olof Johansson wrote: >>> >>> On Mon, Feb 10, 2014 at 6:52 PM, Kukjin Kim<kgene.kim@samsung.com> >>> wrote: >>>> >>>> On 02/13/14 04:14, Arnd Bergmann wrote: >>>>> >>>>> On Wednesday 12 February 2014 13:04:40 Kumar Gala wrote: >>>> >>>> Basically, I agreed with Arnd's suggestion to use ARCH_SBSA. Or we need >>>> to >>>> define level in Kconfig like ARCH_SBSA_L1 for level1. BTW, how about >>>> compliant with SBSA Level1 and having some specific features? >> >> > Well, how about ARMv8 mobile SoC? I think, it is not compatible with SBSA. > For example, you know MCT can be used for ARMv8 cores instead of ARCH Timer. > So I'm not sure ARCH_SBSA is really good choice... > > >> My feeling is that we don't need to use the levels for Kconfig, although >> we might want to use them DT compatible strings, even if it ends up >> looking >> a little funny when you do >> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >> >>> What kind of features are you expecting though? More IP >>> blocks/devices? Those are just kernel config options to enable, >>> ideally as modules. >> >> >> Right, I think we can just put them into defconfig. No need to >> "select" them from Kconfig since the extra options wouldn't be >> required for booting or using the system. >> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, > it is not for used for GH7 though... It looks like the clocksource drivers are all based around being enabled based on platforms instead of individually selectable. That causes a problem here. I think we should change the clocksource Kconfig instead. Then it's just a matter of making sure your defconfig has the needed driver enabled. (Adding Daniel and Thomas in case they have objections to that approach) -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 Tue, Feb 18, 2014 at 01:10:30AM +0000, Kukjin Kim wrote: > As I commented above, how about MCT? Samsung has a plan to use MCT on > ARMv8, it is not for used for GH7 though... Any reason for not using the generic timer?
On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: > On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: > > On 02/15/14 02:06, Arnd Bergmann wrote: > >> My feeling is that we don't need to use the levels for Kconfig, although > >> we might want to use them DT compatible strings, even if it ends up > >> looking > >> a little funny when you do > >> > >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; > >> > >>> What kind of features are you expecting though? More IP > >>> blocks/devices? Those are just kernel config options to enable, > >>> ideally as modules. > >> > >> > >> Right, I think we can just put them into defconfig. No need to > >> "select" them from Kconfig since the extra options wouldn't be > >> required for booting or using the system. > >> > > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, > > it is not for used for GH7 though... > > It looks like the clocksource drivers are all based around being > enabled based on platforms instead of individually selectable. That > causes a problem here. I think we should change the clocksource > Kconfig instead. Then it's just a matter of making sure your defconfig > has the needed driver enabled. > > (Adding Daniel and Thomas in case they have objections to that approach) +John Stultz IIRC it was John who insisted on doing it the current way, although I can't remember his reasoning. Arnd -- 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 Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >> > On 02/15/14 02:06, Arnd Bergmann wrote: >> >> My feeling is that we don't need to use the levels for Kconfig, although >> >> we might want to use them DT compatible strings, even if it ends up >> >> looking >> >> a little funny when you do >> >> >> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >> >> >> >>> What kind of features are you expecting though? More IP >> >>> blocks/devices? Those are just kernel config options to enable, >> >>> ideally as modules. >> >> >> >> >> >> Right, I think we can just put them into defconfig. No need to >> >> "select" them from Kconfig since the extra options wouldn't be >> >> required for booting or using the system. >> >> >> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >> > it is not for used for GH7 though... >> >> It looks like the clocksource drivers are all based around being >> enabled based on platforms instead of individually selectable. That >> causes a problem here. I think we should change the clocksource >> Kconfig instead. Then it's just a matter of making sure your defconfig >> has the needed driver enabled. >> >> (Adding Daniel and Thomas in case they have objections to that approach) > > +John Stultz > > IIRC it was John who insisted on doing it the current way, although > I can't remember his reasoning. Are we really expecting there to be SoC specific clocksources here? I thought we were getting away from that sort of stuff with the architecture timer? I'm fine with clocksources being selected by other functionality options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, but depends on the ACPI option). I just don't want to force users to have to navigate through tons of deep menus to select clocksource options that logically duplicate other selections already made. But again, I handed this maintainership over to Daniel, so I can be considered just a crank yelling from the sidelines :) thanks -john -- 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 Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: > On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>> >> My feeling is that we don't need to use the levels for Kconfig, although >>> >> we might want to use them DT compatible strings, even if it ends up >>> >> looking >>> >> a little funny when you do >>> >> >>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>> >> >>> >>> What kind of features are you expecting though? More IP >>> >>> blocks/devices? Those are just kernel config options to enable, >>> >>> ideally as modules. >>> >> >>> >> >>> >> Right, I think we can just put them into defconfig. No need to >>> >> "select" them from Kconfig since the extra options wouldn't be >>> >> required for booting or using the system. >>> >> >>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>> > it is not for used for GH7 though... >>> >>> It looks like the clocksource drivers are all based around being >>> enabled based on platforms instead of individually selectable. That >>> causes a problem here. I think we should change the clocksource >>> Kconfig instead. Then it's just a matter of making sure your defconfig >>> has the needed driver enabled. >>> >>> (Adding Daniel and Thomas in case they have objections to that approach) >> >> +John Stultz >> >> IIRC it was John who insisted on doing it the current way, although >> I can't remember his reasoning. > > Are we really expecting there to be SoC specific clocksources here? I > thought we were getting away from that sort of stuff with the > architecture timer? Unfortunately vendors can do crazy stuff if they want to. But we also have an option to choose to enable it. Maybe the answer here is to say no to MCT on 64-bit, they get to use the arch timers like everybody else. Or at least motivate why they're not good enough. > I'm fine with clocksources being selected by other functionality > options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, > but depends on the ACPI option). I just don't want to force users to > have to navigate through tons of deep menus to select clocksource > options that logically duplicate other selections already made. > > But again, I handed this maintainership over to Daniel, so I can be > considered just a crank yelling from the sidelines :) I think you have a good point. Until we hear why MCT is needed this is mostly speculation, so let's see what Kukjin says about that. -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 Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson <olof@lixom.net> wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>>> >> My feeling is that we don't need to use the levels for Kconfig, although >>>> >> we might want to use them DT compatible strings, even if it ends up >>>> >> looking >>>> >> a little funny when you do >>>> >> >>>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>> >> >>>> >>> What kind of features are you expecting though? More IP >>>> >>> blocks/devices? Those are just kernel config options to enable, >>>> >>> ideally as modules. >>>> >> >>>> >> >>>> >> Right, I think we can just put them into defconfig. No need to >>>> >> "select" them from Kconfig since the extra options wouldn't be >>>> >> required for booting or using the system. >>>> >> >>>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>> > it is not for used for GH7 though... >>>> >>>> It looks like the clocksource drivers are all based around being >>>> enabled based on platforms instead of individually selectable. That >>>> causes a problem here. I think we should change the clocksource >>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>> has the needed driver enabled. >>>> >>>> (Adding Daniel and Thomas in case they have objections to that approach) >>> >>> +John Stultz >>> >>> IIRC it was John who insisted on doing it the current way, although >>> I can't remember his reasoning. >> >> Are we really expecting there to be SoC specific clocksources here? I >> thought we were getting away from that sort of stuff with the >> architecture timer? > > Unfortunately vendors can do crazy stuff if they want to. But we also > have an option to choose to enable it. Maybe the answer here is to say > no to MCT on 64-bit, they get to use the arch timers like everybody > else. Or at least motivate why they're not good enough. > >> I'm fine with clocksources being selected by other functionality >> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >> but depends on the ACPI option). I just don't want to force users to >> have to navigate through tons of deep menus to select clocksource >> options that logically duplicate other selections already made. >> >> But again, I handed this maintainership over to Daniel, so I can be >> considered just a crank yelling from the sidelines :) > > I think you have a good point. Until we hear why MCT is needed this is > mostly speculation, so let's see what Kukjin says about that. Yea. And on x86 (well, i386 actually) there are system specific clocksources as well, such as the cyclone timer used by "summit" based x440 and similar NUMA systems, but those systems had more general config options that had to be enabled which the cyclone clocksource depended on. thanks -john -- 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 Tue, Feb 18, 2014 at 12:06 PM, John Stultz <john.stultz@linaro.org> wrote: > On Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson <olof@lixom.net> wrote: >> On Tue, Feb 18, 2014 at 11:52 AM, John Stultz <john.stultz@linaro.org> wrote: >>> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann <arnd@arndb.de> wrote: >>>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim <kgene.kim@samsung.com> wrote: >>>>> > On 02/15/14 02:06, Arnd Bergmann wrote: >>>>> >> My feeling is that we don't need to use the levels for Kconfig, although >>>>> >> we might want to use them DT compatible strings, even if it ends up >>>>> >> looking >>>>> >> a little funny when you do >>>>> >> >>>>> >> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>>> >> >>>>> >>> What kind of features are you expecting though? More IP >>>>> >>> blocks/devices? Those are just kernel config options to enable, >>>>> >>> ideally as modules. >>>>> >> >>>>> >> >>>>> >> Right, I think we can just put them into defconfig. No need to >>>>> >> "select" them from Kconfig since the extra options wouldn't be >>>>> >> required for booting or using the system. >>>>> >> >>>>> > As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>>> > it is not for used for GH7 though... >>>>> >>>>> It looks like the clocksource drivers are all based around being >>>>> enabled based on platforms instead of individually selectable. That >>>>> causes a problem here. I think we should change the clocksource >>>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>>> has the needed driver enabled. >>>>> >>>>> (Adding Daniel and Thomas in case they have objections to that approach) >>>> >>>> +John Stultz >>>> >>>> IIRC it was John who insisted on doing it the current way, although >>>> I can't remember his reasoning. >>> >>> Are we really expecting there to be SoC specific clocksources here? I >>> thought we were getting away from that sort of stuff with the >>> architecture timer? >> >> Unfortunately vendors can do crazy stuff if they want to. But we also >> have an option to choose to enable it. Maybe the answer here is to say >> no to MCT on 64-bit, they get to use the arch timers like everybody >> else. Or at least motivate why they're not good enough. >> >>> I'm fine with clocksources being selected by other functionality >>> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >>> but depends on the ACPI option). I just don't want to force users to >>> have to navigate through tons of deep menus to select clocksource >>> options that logically duplicate other selections already made. >>> >>> But again, I handed this maintainership over to Daniel, so I can be >>> considered just a crank yelling from the sidelines :) >> >> I think you have a good point. Until we hear why MCT is needed this is >> mostly speculation, so let's see what Kukjin says about that. > > Yea. And on x86 (well, i386 actually) there are system specific > clocksources as well, such as the cyclone timer used by "summit" based > x440 and similar NUMA systems, but those systems had more general > config options that had to be enabled which the cyclone clocksource > depended on. So, after giving this some more thought (and getting my hands dirty in some of this code), I think I'm going to change my mind on this. For mobile platforms I think it might make sense to bring over the toplevel platform Kconfig from arch/arm, to simplify dependencies without tearing up the driver subtree with churn like this. This, of course, only holds true for v8 mobile platforms. Samsung isn't saying if GH7 is a server platform and not, and they don't have to tell us. But I think we should consider only enabling and bringing over the mobile ones (and ideally try to avoid even that, but it might make sense to do some of them at least initially -- it does provide some convenient ways to enable larger subsets of default drivers per platform/vendor family). I.e. I'd be OK with an ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we should add more finegrained options than that globally on ARM64, at least not until truly proven to be needed. We're trying to push back against new per-SoC Kconfig entries on 32-bit as well right now. -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 Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: > So, after giving this some more thought (and getting my hands dirty in > some of this code), I think I'm going to change my mind on this. For > mobile platforms I think it might make sense to bring over the > toplevel platform Kconfig from arch/arm, to simplify dependencies > without tearing up the driver subtree with churn like this. > > This, of course, only holds true for v8 mobile platforms. Samsung > isn't saying if GH7 is a server platform and not, and they don't have > to tell us. But I think we should consider only enabling and bringing > over the mobile ones (and ideally try to avoid even that, but it might > make sense to do some of them at least initially -- it does provide > some convenient ways to enable larger subsets of default drivers per > platform/vendor family). > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. I'm fine with this. Do we still need something for ARMv8 server platforms like ARCH_ARM_SBSA? The only advantage would be to make it easier for mobile targeted kernel builds to disable server features but I'm not sure there are so many such features, people can trim the .config manually. Two additional points: 1. Single arm64 defconfig file covering everything 2. Modules rather than built-in by default where possible (especially for server platforms)
On Thursday 20 February 2014 11:22:48 Catalin Marinas wrote: > > I'm fine with this. Do we still need something for ARMv8 server > platforms like ARCH_ARM_SBSA? The only advantage would be to make it > easier for mobile targeted kernel builds to disable server features but > I'm not sure there are so many such features, people can trim the > .config manually. I think in particular for SBSA compliant platforms we should not have per-platform options at all the way we do for embedded, as they will be much more homogenous. > Two additional points: > > 1. Single arm64 defconfig file covering everything > 2. Modules rather than built-in by default where possible (especially > for server platforms) +1 Arnd -- 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 20, 2014 at 3:22 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Thu, Feb 20, 2014 at 09:03:30AM +0000, Olof Johansson wrote: >> So, after giving this some more thought (and getting my hands dirty in >> some of this code), I think I'm going to change my mind on this. For >> mobile platforms I think it might make sense to bring over the >> toplevel platform Kconfig from arch/arm, to simplify dependencies >> without tearing up the driver subtree with churn like this. >> >> This, of course, only holds true for v8 mobile platforms. Samsung >> isn't saying if GH7 is a server platform and not, and they don't have >> to tell us. But I think we should consider only enabling and bringing >> over the mobile ones (and ideally try to avoid even that, but it might >> make sense to do some of them at least initially -- it does provide >> some convenient ways to enable larger subsets of default drivers per >> platform/vendor family). >> >> I.e. I'd be OK with an >> ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we >> should add more finegrained options than that globally on ARM64, at >> least not until truly proven to be needed. We're trying to push back >> against new per-SoC Kconfig entries on 32-bit as well right now. > > I'm fine with this. Do we still need something for ARMv8 server > platforms like ARCH_ARM_SBSA? The only advantage would be to make it > easier for mobile targeted kernel builds to disable server features but > I'm not sure there are so many such features, people can trim the > .config manually. I don't think there's all that much that's unique to SBSA for a Kconfig entry. If anything it could be useful to describe dependencies (i.e. you very likely don't want to turn off the standardized UART driver, etc). But doing that through Kconfig is a bit clumsy, we might be better off doing it through example defconfigs. I'm not sure we want to do it through selects. > Two additional points: > > 1. Single arm64 defconfig file covering everything > 2. Modules rather than built-in by default where possible (especially > for server platforms) Sounds good to me. Are you also willing to pick up one defconfig per vendor (but not more)? I think it's been useful to have those on arm, even on multiplatform kernels. We used them on powerpc as well, where we had a two-layer approach (ppc64_defconfig and per-platform configs, pseries/iseries/pasemi/g5/cell). -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 Thu, Feb 20, 2014 at 05:09:59PM +0000, Olof Johansson wrote: > On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas > > Two additional points: > > > > 1. Single arm64 defconfig file covering everything > > 2. Modules rather than built-in by default where possible (especially > > for server platforms) > > Sounds good to me. Are you also willing to pick up one defconfig per > vendor (but not more)? I think it's been useful to have those on arm, > even on multiplatform kernels. We used them on powerpc as well, where > we had a two-layer approach (ppc64_defconfig and per-platform configs, > pseries/iseries/pasemi/g5/cell). Initially I would keep a single defconfig with everything just to get wider coverage of single Image. Later on, if just deselecting config entries doesn't work, we can revisit per-vendor defconfigs.
On 02/19/14 05:00, Olof Johansson wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz<john.stultz@linaro.org> wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann<arnd@arndb.de> wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim<kgene.kim@samsung.com> wrote: >>>>> On 02/15/14 02:06, Arnd Bergmann wrote: >>>>>> My feeling is that we don't need to use the levels for Kconfig, although >>>>>> we might want to use them DT compatible strings, even if it ends up >>>>>> looking >>>>>> a little funny when you do >>>>>> >>>>>> compatible = "arm,sbsa-l3", "arm,sbsa-l2", "arm,sbsa-l1"; >>>>>> >>>>>>> What kind of features are you expecting though? More IP >>>>>>> blocks/devices? Those are just kernel config options to enable, >>>>>>> ideally as modules. >>>>>> >>>>>> >>>>>> Right, I think we can just put them into defconfig. No need to >>>>>> "select" them from Kconfig since the extra options wouldn't be >>>>>> required for booting or using the system. >>>>>> >>>>> As I commented above, how about MCT? Samsung has a plan to use MCT on ARMv8, >>>>> it is not for used for GH7 though... >>>> >>>> It looks like the clocksource drivers are all based around being >>>> enabled based on platforms instead of individually selectable. That >>>> causes a problem here. I think we should change the clocksource >>>> Kconfig instead. Then it's just a matter of making sure your defconfig >>>> has the needed driver enabled. >>>> >>>> (Adding Daniel and Thomas in case they have objections to that approach) >>> >>> +John Stultz >>> >>> IIRC it was John who insisted on doing it the current way, although >>> I can't remember his reasoning. >> >> Are we really expecting there to be SoC specific clocksources here? I >> thought we were getting away from that sort of stuff with the >> architecture timer? > > Unfortunately vendors can do crazy stuff if they want to. But we also > have an option to choose to enable it. Maybe the answer here is to say > no to MCT on 64-bit, they get to use the arch timers like everybody > else. Or at least motivate why they're not good enough. > >> I'm fine with clocksources being selected by other functionality >> options (ie: on x86 ACPI PM timer clocksource doesn't have a prompt, >> but depends on the ACPI option). I just don't want to force users to >> have to navigate through tons of deep menus to select clocksource >> options that logically duplicate other selections already made. >> >> But again, I handed this maintainership over to Daniel, so I can be >> considered just a crank yelling from the sidelines :) > > I think you have a good point. Until we hear why MCT is needed this is > mostly speculation, so let's see what Kukjin says about that. > Using MCT on ARMv8 is an example, it's true on some Samsung ARMv8 SoC though. I don't want to argue what's the benefit of MCT in this thread, but just possibility. As you know, generally ARM SoC vendor is open to use any IPs...So I'd like to say we need to consider the situation. Anyway, basically I agree with you guys suggestion to use common CONFIG on ARMv8 like multiplatform supporting on arm32. Thanks, Kukji -- 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 02/21/14 03:58, Catalin Marinas wrote: > On Thu, Feb 20, 2014 at 05:09:59PM +0000, Olof Johansson wrote: >> On Thu, Feb 20, 2014 at 3:22 AM, Catalin Marinas >>> Two additional points: >>> >>> 1. Single arm64 defconfig file covering everything >>> 2. Modules rather than built-in by default where possible (especially >>> for server platforms) >> >> Sounds good to me. Are you also willing to pick up one defconfig per >> vendor (but not more)? I think it's been useful to have those on arm, >> even on multiplatform kernels. We used them on powerpc as well, where >> we had a two-layer approach (ppc64_defconfig and per-platform configs, >> pseries/iseries/pasemi/g5/cell). > > Initially I would keep a single defconfig with everything just to get > wider coverage of single Image. Later on, if just deselecting config > entries doesn't work, we can revisit per-vendor defconfigs. > OK, agreed with single defconfig on ARMv8 for now. And as Olof said, it's expected that each vendor maybe needs to use per-vendor defconfig soon and agreed too :-) Thanks, 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
On 02/20/14 18:03, Olof Johansson wrote: [...] > > I.e. I'd be OK with an > ARCH_EXYNOS/ARCH_TEGRA/ARCH_IMX/ARCH_<whatever>, but I don't think we > should add more finegrained options than that globally on ARM64, at > least not until truly proven to be needed. We're trying to push back > against new per-SoC Kconfig entries on 32-bit as well right now. > OK, agreed. - 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
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index dd4327f..7d71823 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -111,6 +111,11 @@ source "kernel/Kconfig.freezer" menu "Platform selection" +config ARCH_GH7 + bool "Samsung ARMv8 GH7 SoC" + help + This enables support for Samsung GH7 SoC + config ARCH_VEXPRESS bool "ARMv8 software model (Versatile Express)" select ARCH_REQUIRE_GPIOLIB diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index c52bdb0..54fb0cf 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -1,3 +1,4 @@ +dtb-$(CONFIG_ARCH_GH7) += samsung-ssdk-gh7.dtb dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
This patch adds support for Samsung GH7 SoC in arm64/Kconfig. Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Cc: Catalin Marinas <catalin.marinas@arm.com> --- arch/arm64/Kconfig | 5 +++++ arch/arm64/boot/dts/Makefile | 1 + 2 files changed, 6 insertions(+)