From: "Cousson, Benoit" <b-cousson@ti.com>
To: Paul Walmsley <paul@pwsan.com>
Cc: linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
khilman@ti.com, Vaibhav Hiremath <hvaibhav@ti.com>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [PATCH] ARM: OMAP2+: hwmod code/data: fix 32K sync timer
Date: Wed, 6 Jun 2012 09:56:34 +0200 [thread overview]
Message-ID: <4FCF0D32.1030403@ti.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1206051737000.30737@utopia.booyaka.com>
On 6/6/2012 2:28 AM, Paul Walmsley wrote:
> Hello Benoît
>
> On Tue, 5 Jun 2012, Paul Walmsley wrote:
>
>> On Tue, 29 May 2012, Cousson, Benoit wrote:
>>
>>> So in fact, I'm wondering if a new flag is needed. We can potentially
>>> apply that if idlemodes == (SIDLE_FORCE | SIDLE_NO).
>>>
>>> We need to check which IP will have that to ensure that does not add
>>> any side-effects.
>>
>> I guess that means me :-)
>
> I looked at a few TRMs. Based on that incomplete survey, the above
> behavior would probably work for existing chips.
>
> But it seems perverse to assume that it is generally safe to set an IP
> block to force-idle while it's being used. That seems really dependent on
> the IP block's integration.
Not really, because this behavior is implemented in the IP itself. The
point is the this IP is so dumb that force_idle = smart_idle. There is
not reason to delay the idle_ack since this IP does not do any internal
processing. That's probably why it was not implemented in the HW.
> So in terms of a general fix, the flag approach seems safest to me in the
> long run.
Well, for the long run we can expect the HW to be fixed, so since we do
have only one IP with that and we can detect that with the current
flags, I still do not think it is needed.
> The other advantage of using a flag is that it indicates that this is a
> hardware workaround; something that it would be nice to fix in future
> chips.
Yeah, I'm still not convinced, but it is not a big deal either so it is
up to you.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-06-06 7:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-25 21:56 [PATCH] ARM: OMAP2+: hwmod code/data: fix 32K sync timer Paul Walmsley
2012-05-29 12:45 ` Cousson, Benoit
2012-06-05 22:55 ` Paul Walmsley
2012-06-06 0:28 ` Paul Walmsley
2012-06-06 7:56 ` Cousson, Benoit [this message]
2012-06-06 7:21 ` Cousson, Benoit
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=4FCF0D32.1030403@ti.com \
--to=b-cousson@ti.com \
--cc=hvaibhav@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).