Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option
On Tue, Nov 3, 2015 at 2:02 AM, Arnd Bergmann wrote: > I suspect this will come up again in the future. The problem is > really that drivers/clocksource has different rules from almost > everything else, by requiring the platform to 'select' the driver. > > The second version that Krzysztof posted is how we handle this in > other driver subsystems, and I would generally prefer it to do this > consistently for everything, but John Stultz has in the past argued > strongly for using 'select' in all clocksource drivers. The reason > is that for each platform we know in advance which driver we want, > and there is never a need for the user to have to select the right > one. And just to clarify, I don't necessarily think "select" is the right method, as creating an option that defaults to Y if the right architecture/platform support is present is fine too. I just don't want users to have to search deeply through menuconfig to find a clocksource driver checkbox when they have already selected a platform and provided enough information for us to know which clocksource driver is needed. So my argument its really all about avoiding user-prompts in kconfig for clocksources. It is conceptually easier to do this w/ select, but you can also do it via default y and proper dependencies. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
On Tue, Feb 18, 2014 at 12:00 PM, Olof Johansson wrote: > On Tue, Feb 18, 2014 at 11:52 AM, John Stultz wrote: >> On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann wrote: >>> On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >>>> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] arm64: Add Kconfig option for Samsung GH7 SoC family
On Tue, Feb 18, 2014 at 10:13 AM, Arnd Bergmann wrote: > On Tuesday 18 February 2014 08:16:13 Olof Johansson wrote: >> On Mon, Feb 17, 2014 at 5:10 PM, Kukjin Kim 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On 03/25/2013 03:36 PM, Arnd Bergmann wrote: On Monday 25 March 2013, Rob Herring wrote: I count integrator-cp, realview, versatile and non-DT VExpress that do this (not surprisingly) and 25 platforms or timer implementations plus arm64 that do sched_clock setup in time_init. What's broken by not moving these earlier? timekeeping_init() will leave the persistent_clock_exist variable as "false", which is read in rtc_suspend() and timekeeping_inject_sleeptime(). Are you mixing up the persistent_clock and sched_clock here? From a generic stand-point they have different requirements. For all I can tell, you will get a little jitter every time you do a suspend in that case. Or perhaps it means the system clock will be forwarded by the amount of time spent in suspend twice after wakeup, but I'm probably misreading the code for that case. No, you shouldn't see timekeeping being incremented twice, we check in rtc_resume code if the persistent clock is present if so we won't inject any measured suspend time there. But you're probably right that we're being a little overly paranoid checking the same value twice. As far as the benefit to the persistent clock: it is just a little better to use, since we can access it earlier in resume, prior to interrupts being enabled. So we should see less time error introduced each suspend. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS: Keep USB related LDOs always active on Origen
On 02/21/2013 10:48 PM, Tushar Behera wrote: LDO3 and LDO8 are used for powering both device and host phy controllers. These regulators are not handled in USB host driver. Hence we get unexpected behaviour when the regulators are disabled elsewhere. It would be best to keep these regulators always on. Signed-off-by: Tushar Behera --- Based on v3.8. This works great for me! Thanks so much Tushar! Tested-by: John Stultz -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
