Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
- From: "Shilimkar, Santosh" <santosh.shilimkar@xxxxxx>
- Date: Wed, 21 Mar 2012 19:30:01 +0530
- Cc: Ming Lei <tom.leiming@xxxxxxxxx>, "Hilman, Kevin" <khilman@xxxxxx>, "linux-omap@xxxxxxxxxxxxxxx" <linux-omap@xxxxxxxxxxxxxxx>, "linux-arm-kernel@xxxxxxxxxxxxxxxxxxx" <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, "marc.zyngier@xxxxxxx" <marc.zyngier@xxxxxxx>, "johnstul@xxxxxxxxxx" <johnstul@xxxxxxxxxx>, "Balbi, Felipe" <balbi@xxxxxx>, "Cousson, Benoit" <b-cousson@xxxxxx>, Tony Lindgren <tony@xxxxxxxxxxx>, Paul Walmsley <paul@xxxxxxxxx>, "DebBarma, Tarun Kanti" <tarun.kanti@xxxxxx>
- In-reply-to: <79CD15C6BA57404B839C016229A409A83182386C@DBDE01.ent.ti.com>
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote:
> On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
>> On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
>> > On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote:
>> >>
>> >> I think you made very good point here. With the above patch, we are almost missing the capability of registering dmtimer as a clocksource for OMAP.
>> >> It will always use 32k-counter, and never fall back to dmtimer.
>> >>
>> >> Then the only options we have here is,
>> >>
>> >> 1) Register both the timers, 32k-counter and dmtimer for clocksource; let
>> >> Kernel pick up best rating clocksource out of these two.
>> >>
>> >> In case of OMAP1/2/3/4, kernel will use dmtimer, since it has better
>> >> Rating. User can choose the 32k-counter clocksource via bootargs.
>> >>
>> >> Impact: without bootargs for clocksource selection, kernel will choose
>> >> dmtimer, impacting loss of time during suspend/resume.
>> >>
>> This is the right option. The problem is gptimer clocksource
>> doesn't work across power transitions and hence it is broken.
>>
>> Even for the perf, with PM enabled, dmtimer can't be used or it needs
>> to be used with 32KHz clock which makes it no better than sync timer.
>>
>> So here keeping 32K sync timer is default clocksource makes sense since
>> it is the only working and viable option.
>>
>> So what can be done is register both 32K and gptimer together but make
>> gptimer clocksource registration depends on PM enabled.
>>
>> This should solve all the needs I guess.
>>
>
> I am not sure this will work on all platforms, for example, AM33XX, where
> We do not have 32ksync timer available, but we need PM support. Also, I
> personally think, we should not again use compile time option here.
>
Why not ?
If 32ksync timer is not available, don't register it. Then in AM case
you just have one clock-source. I am against the idea of making
gptimer as the default and asking user to choose sync32k from
command-line.
Btw, if you need PM, how are you going to use GPTIMER
as a clocksource. Note sys-clock is generally stopped in
low power states. So that leaves you option with using
gptimer with 32K clock and in that case, GPTIMER
is not a better clock-source compare to 32K sync timer
and so shouldn't be the rating.
Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Arm (vger)]
[ARM Kernel]
[ARM MSM]
[Linux Tegra]
[Maemo Users]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]