Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family

From: John Stultz <john.stultz@linaro.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Olof Johansson <olof@lixom.net>,
	Kukjin Kim <kgene.kim@samsung.com>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Ilho Lee <ilho215.lee@samsung.com>,
	Thomas Abraham <thomas.ab@samsung.com>,
	Kumar Gala <galak@codeaurora.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
Date: Tue, 18 Feb 2014 11:52:25 -0800	[thread overview]
Message-ID: <CALAqxLX6STNqUeVO2G18bm_HKabpoRxZTa3uK6i-JP97zEYVZg@mail.gmail.com> (raw)
In-Reply-To: <6032891.ndY8FikAMY@wuerfel>

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