On 02/19/14 05:00, Olof Johansson wrote:
On Tue, Feb 18, 2014 at 11:52 AM, John Stultz<john.stultz@xxxxxxxxxx> wrote:
On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann<arnd@xxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
