Messages in this thread | | | Date | Wed, 10 Sep 2014 10:52:46 -0700 | Subject | Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested | From | Doug Anderson <> |
| |
Mark,
On Wed, Sep 10, 2014 at 10:27 AM, Mark Rutland <mark.rutland@arm.com> wrote: > Hi Sonny, > > On Wed, Aug 27, 2014 at 10:03:39PM +0100, Sonny Rao wrote: >> This is a bug fix for using physical arch timers when >> the arch_timer_use_virtual boolean is false. It restores the >> arch_counter_get_cntpct() function after removal in >> >> 0d651e4e "clocksource: arch_timer: use virtual counters" >> >> and completes the implementation of memory mapped access for physical >> timers, so if a system is trying to use physical timers, it will >> function properly. > > To get back to the topic at hand: > > Which platform is this required by?
I've seen similar problems on the A7s on exynos5420 / exynos5800 and on rk3288. I can't say what other platforms might be affected. Note that the arch timers on exyno5420/exynos5800 are not supported anyway, so I guess that means we're just worrying about the rk3288.
> Why exactly is arch_timer_use_virtual false in this case?
To re-summarize my understanding of everything (many of the below is secondhand knowledge, so correct if wrong):
1. The initial problem is that the virtual offset is not initialized by anyone and is per core (each core gets a different, random offset). That makes the virtual counter useless. ...but the kernel only uses virtual counters.
2. As far as I know, we don't have any particular need for HYP mode nor for limiting access to secure mode.
3. You can only change the virtual offset from HYP mode. That means someone needs to transition to HYP mode if we want to use virtual counters.
4. If the kernel happens to be in HYP mode it will init the virtual offset.
5. We could transition to HYP mode once in the firmware and boot the kernel like that, but since firmware is gone after we've booted the kernel, we run into the same problem when we power off a processor and when we resume from S3. The firmware is not involved in these cases. In these cases the processors have an uninitialized virtual offset again. These processors don't appear to magically come up in HYP mode. Thus it would be up to the kernel to transition to HYP mode, init the offset, and get out of HYP mode. ...or just use the physical counter.
If you can suggest something that doesn't require us to involve the firmware in processor bringup and in resume, I'm all ears. We have a desire not to involve the firmware there because of all the issues of keeping kernel/firmware in sync and because of the extra difficultly of shipping firmware updates (understandably the QA needed to validate a new firmware is much higher than the QA needed to validate a new kernel).
-Doug
| |