From: Kevin Hilman <khilman@deeprootsystems.com>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>, Mike Chan <mikechan@google.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick
Date: Thu, 18 Jun 2009 08:03:15 -0700 [thread overview]
Message-ID: <87ab45twi4.fsf@deeprootsystems.com> (raw)
In-Reply-To: <13B9B4C6EF24D648824FF11BE8967162038E2AC611@dlee02.ent.ti.com> (Richard Woodruff's message of "Wed\, 17 Jun 2009 19\:04\:58 -0500")
"Woodruff, Richard" <r-woodruff2@ti.com> writes:
> Hi Paul,
>
> Hm, seems my mailing is out to lunch today... I'll be worse than normal in protocol and top post.
>
> I've seen this issue on a couple custom boards. In these instances
> I've not had access to boot loaders. I would expect this issue
> would show up in the wild in some devices. It might be ok to move
> to at least init. Having it at deadlock spot is a bit more
> conservative.
Richard, since Paul and I cannot reproduce this currently, would you be able to test
if a fix at init fixes the problems that you've seen?
Kevin
> I've only seen the condition along side of very aggressive SDRC_POWER settings. Its my guess beagle doesn't enable all those features yet. Unless you have a bunch of beagle accessories attached, I'm not sure how good a reference beagle is for system DVFS validation.
>
> I've not taken stat's to see how much it happens. The alternate to the latency spike is a dead lock which is clealry not wanted. Net-Net I see this as more a plus than a minus in current form.
>
> If you have some time you might expirment with beagle and see if you can trigger the condition.
>
> Regards,
> Richard W.
>
> -----Original Message-----
> From: Paul Walmsley [mailto:paul@pwsan.com]
> Sent: Wednesday, June 17, 2009 3:04 AM
>
> So, what is different about your setup? The usual suite of questions:
>
> - What chip revisions/boards does this affect?
>
> - Is this specific to certain bootloaders?
>
> - Has anyone else out there seen this problem?
>
> Rather than working around an occasional DLL failure to lock, is it possible to reset the DLL earlier in the boot process, as Richard's commit message suggests? That would be preferable to this approach. A back-of-the-envelope assessment suggests that this patch could cause unpredictable, additional 1.5 millisecond latency spikes whenever the workaround triggers (since OCM RAM is marked uncacheable).
next prev parent reply other threads:[~2009-06-18 15:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-15 22:42 [PATCH -pm 0/2] SDRC tweaks for stuck DLL state machine Kevin Hilman
2009-06-15 22:42 ` [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick Kevin Hilman
2009-06-15 22:42 ` [PATCH -pm 2/2] SDRC: whitespace cleanups in DLL lock code Kevin Hilman
2009-06-17 8:04 ` [PATCH -pm 1/2] SDRC: check for stuck DLL state machine and kick Paul Walmsley
2009-06-18 0:04 ` Woodruff, Richard
2009-06-18 15:03 ` Kevin Hilman [this message]
2009-06-18 19:21 ` Woodruff, Richard
2009-06-18 21:06 ` Paul Walmsley
2009-06-20 1:42 ` Woodruff, Richard
2009-06-23 20:05 ` Paul Walmsley
2009-06-23 20:11 ` Woodruff, Richard
2009-06-26 8:45 ` Paul Walmsley
2009-06-26 16:07 ` Woodruff, Richard
[not found] ` <8bb80c380906181142m54f543c2v626849983f4507b4@mail.gmail.com>
2009-06-18 18:55 ` Woodruff, Richard
2009-06-18 19:27 ` Wang Sawsd-A24013
2009-06-18 19:32 ` Woodruff, Richard
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=87ab45twi4.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.com \
--cc=linux-omap@vger.kernel.org \
--cc=mikechan@google.com \
--cc=paul@pwsan.com \
--cc=r-woodruff2@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox