From: Kevin Hilman <khilman@ti.com>
To: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: linux-omap@vger.kernel.org, dave.long@linaro.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.
Date: Tue, 13 Mar 2012 09:31:46 -0700 [thread overview]
Message-ID: <87vcm8tqbx.fsf@ti.com> (raw)
In-Reply-To: <4F5F098E.4040006@ti.com> (Santosh Shilimkar's message of "Tue, 13 Mar 2012 14:17:10 +0530")
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On OMAP4, recently a synchronisation bug is discovered by hardware
>>> team, which leads to incorrect timer value read from 32K sync timer
>>> IP when the IP is comming out of idle.
>>>
>>> The issue is due to the synchronization methodology used in the SYNCTIMER IP.
>>> The value of the counter register in 32kHz domain is synchronized to the OCP
>>> domain register only at count up event, and if the OCP clock is switched off,
>>> the OCP register gets out of synch until the first count up event after the
>>> clock is switched back -at the next falling edge of the 32kHz clock.
>>>
>>> Further investigation revealed that it applies to gptimer1 and watchdog timer2
>>> as well which may run on 32KHz. This patch fixes the issue for all the
>>> applicable modules.
>>
>> The changelog describes the problem ver well, but doesn't actually
>> describe the fix (enable static dep.) Can you update the changelog do
>> describe the fix, and why it fixes the problem.
>>
> Sure. Updated patch below. The idea is to ensure that synctimer is
> syncronised before software does any reads on the counter. The BUG
> will get fixed in future OMAP designs
Thanks for the updated changelog.
Since this doesn't qualify as a regression, queuing for v3.4 (branch: for_3.4/fixes/pm)
Kevin
WARNING: multiple messages have this Message-ID (diff)
From: khilman@ti.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer.
Date: Tue, 13 Mar 2012 09:31:46 -0700 [thread overview]
Message-ID: <87vcm8tqbx.fsf@ti.com> (raw)
In-Reply-To: <4F5F098E.4040006@ti.com> (Santosh Shilimkar's message of "Tue, 13 Mar 2012 14:17:10 +0530")
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Monday 12 March 2012 10:21 PM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On OMAP4, recently a synchronisation bug is discovered by hardware
>>> team, which leads to incorrect timer value read from 32K sync timer
>>> IP when the IP is comming out of idle.
>>>
>>> The issue is due to the synchronization methodology used in the SYNCTIMER IP.
>>> The value of the counter register in 32kHz domain is synchronized to the OCP
>>> domain register only at count up event, and if the OCP clock is switched off,
>>> the OCP register gets out of synch until the first count up event after the
>>> clock is switched back -at the next falling edge of the 32kHz clock.
>>>
>>> Further investigation revealed that it applies to gptimer1 and watchdog timer2
>>> as well which may run on 32KHz. This patch fixes the issue for all the
>>> applicable modules.
>>
>> The changelog describes the problem ver well, but doesn't actually
>> describe the fix (enable static dep.) Can you update the changelog do
>> describe the fix, and why it fixes the problem.
>>
> Sure. Updated patch below. The idea is to ensure that synctimer is
> syncronised before software does any reads on the counter. The BUG
> will get fixed in future OMAP designs
Thanks for the updated changelog.
Since this doesn't qualify as a regression, queuing for v3.4 (branch: for_3.4/fixes/pm)
Kevin
next prev parent reply other threads:[~2012-03-13 16:31 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 15:33 [PATCH] ARM: OMAP4: Workaround the OCP synchronisation issue with 32K synctimer Santosh Shilimkar
2012-03-12 15:33 ` Santosh Shilimkar
2012-03-12 16:51 ` Kevin Hilman
2012-03-12 16:51 ` Kevin Hilman
2012-03-13 8:47 ` Santosh Shilimkar
2012-03-13 8:47 ` Santosh Shilimkar
2012-03-13 16:31 ` Kevin Hilman [this message]
2012-03-13 16:31 ` Kevin Hilman
2012-03-13 16:40 ` Shilimkar, Santosh
2012-03-13 16:40 ` Shilimkar, Santosh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vcm8tqbx.fsf@ti.com \
--to=khilman@ti.com \
--cc=dave.long@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=santosh.shilimkar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.