linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: imx: replace imx6q_restart() with mxc_restart()
Date: Tue, 29 Oct 2013 11:37:56 +0000	[thread overview]
Message-ID: <20131029113756.GP16735@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20131029095332.5d926e8b@ipc1.ka-ro>

On Tue, Oct 29, 2013 at 09:53:32AM +0100, Lothar Wa?mann wrote:
> Hi,
> 
> Shawn Guo wrote:
> > On Mon, Oct 28, 2013 at 10:46:02AM -0700, Olof Johansson wrote:
> > > By the way, the errata document says that you must write it twice
> > > within one 32kHz clock period. You might want to write it three times
> > > just in case two of them happen to straddle that period by pure bad
> > > luck. I'm guessing it's rare enough that you haven't been able to
> > > reproduce it though.
> > 
> > With CPU running at hundred MHz, two writes in the row should not
> > straddle one 32kHz clock period - 31.25 us.
> > 
> But they still may end up in adjacent periods of the 32MHz
> clock. If both writes have to happen within the same period of the
> clock, the third write may be necessary to guarantee this.

Yes, that is correct to the description given.  It's also rather vague
in that it doesn't describe the mechanism for the bug, so we can't say
for certain whether two or three writes are sufficient.

If the problem is to do with a write too close to the 32kHz clock edge,
then two writes should solve it (if the first is too close, the second
one will likely be afterwards).  If the problem is something else, then
three writes would be sensible.

As we don't have this information, I'd suggest using three just to be
sure as Lothar suggests.

  reply	other threads:[~2013-10-29 11:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-06  9:06 [PATCH] ARM: imx: replace imx6q_restart() with mxc_restart() Shawn Guo
2013-10-08 15:32 ` Nathan Lynch
2013-10-08 15:49   ` Shawn Guo
     [not found] ` <857E9EDCA6C0904DB3357321AA9123EB62506837@NA-MBX-01.mgc.mentorg.com>
2013-10-21  3:32   ` jiada
2013-10-21  4:59     ` Shawn Guo
     [not found]       ` <857E9EDCA6C0904DB3357321AA9123EB62506BEA@NA-MBX-01.mgc.mentorg.com>
2013-10-21  6:13         ` jiada
2013-10-21  7:04           ` Shawn Guo
2013-10-28  2:41             ` jiada
2013-10-28  2:52               ` Shawn Guo
2013-10-28  7:45               ` Shawn Guo
2013-10-30  3:13                 ` jiada
2013-10-30 17:54                   ` Russell King - ARM Linux
2013-10-31  5:23                     ` Shawn Guo
2013-10-31  5:31                     ` jiada
2013-10-28  5:17 ` Olof Johansson
2013-10-28  8:14   ` Shawn Guo
2013-10-28 17:46     ` Olof Johansson
2013-10-29  2:06       ` Shawn Guo
2013-10-29  8:53         ` Lothar Waßmann
2013-10-29 11:37           ` Russell King - ARM Linux [this message]
2013-10-29 13:37             ` Shawn Guo

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=20131029113756.GP16735@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).