Some msm targets have timers whose lower bits are unreliable. So, we
present our timers as lower frequency than they actually are, and ignore
the bottom 5 bits on such targets. This compensation was erroneously
removed from the msm_read_timer_count function, so restore it.
This was broken by 94790ec25 "msm: timer: SMP timer support for msm".
Signed-off-by: Jeff Ohlstein <[email protected]>
---
arch/arm/mach-msm/timer.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index 38b95e9..608ec4d 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -100,7 +100,11 @@ static cycle_t msm_read_timer_count(struct clocksource *cs)
{
struct msm_clock *clk = container_of(cs, struct msm_clock, clocksource);
- return readl(clk->global_counter);
+ /*
+ * Shift timer count down by a constant due to unreliable lower bits
+ * on some targets.
+ */
+ return readl(clk->global_counter) >> clk->shift;
}
static struct msm_clock *clockevent_to_clock(struct clock_event_device *evt)
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Fri, Jun 17, 2011 at 01:55:38PM -0700, Jeff Ohlstein wrote:
> Some msm targets have timers whose lower bits are unreliable. So, we
> present our timers as lower frequency than they actually are, and ignore
> the bottom 5 bits on such targets. This compensation was erroneously
> removed from the msm_read_timer_count function, so restore it.
>
> This was broken by 94790ec25 "msm: timer: SMP timer support for msm".
>
> Signed-off-by: Jeff Ohlstein <[email protected]>
> ---
> arch/arm/mach-msm/timer.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read Documentation/stable_kernel_rules.txt
for how to do this properly.
</formletter>
On Mon, Jun 20 2011, Greg KH wrote:
> On Fri, Jun 17, 2011 at 01:55:38PM -0700, Jeff Ohlstein wrote:
>> Some msm targets have timers whose lower bits are unreliable. So, we
>> present our timers as lower frequency than they actually are, and ignore
>> the bottom 5 bits on such targets. This compensation was erroneously
>> removed from the msm_read_timer_count function, so restore it.
>>
>> This was broken by 94790ec25 "msm: timer: SMP timer support for msm".
>>
>> Signed-off-by: Jeff Ohlstein <[email protected]>
>> ---
>> arch/arm/mach-msm/timer.c | 6 +++++-
>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>
I don't think this patch was intended for stable in the first place.
Jeff, this is a fix for 3.0-rcx, right?
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
On Mon, Jun 20, 2011 at 04:27:16PM -0700, David Brown wrote:
> On Mon, Jun 20 2011, Greg KH wrote:
>
> > On Fri, Jun 17, 2011 at 01:55:38PM -0700, Jeff Ohlstein wrote:
> >> Some msm targets have timers whose lower bits are unreliable. So, we
> >> present our timers as lower frequency than they actually are, and ignore
> >> the bottom 5 bits on such targets. This compensation was erroneously
> >> removed from the msm_read_timer_count function, so restore it.
> >>
> >> This was broken by 94790ec25 "msm: timer: SMP timer support for msm".
> >>
> >> Signed-off-by: Jeff Ohlstein <[email protected]>
> >> ---
> >> arch/arm/mach-msm/timer.c | 6 +++++-
> >> 1 files changed, 5 insertions(+), 1 deletions(-)
> >>
> >
> > <formletter>
> >
> > This is not the correct way to submit patches for inclusion in the
> > stable kernel tree. Please read Documentation/stable_kernel_rules.txt
> > for how to do this properly.
> >
> > </formletter>
>
> I don't think this patch was intended for stable in the first place.
> Jeff, this is a fix for 3.0-rcx, right?
Then why was it sent to [email protected]?
confused,
greg k-h