[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D0F6E33AE@AcuExch.aculab.com>
Date: Thu, 20 Mar 2014 11:59:14 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Kevin Hao' <haokexin@...il.com>,
Scott Wood <scottwood@...escale.com>
CC: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"Chenhui Zhao" <chenhui.zhao@...escale.com>,
"Jason.Jin@...escale.com" <Jason.Jin@...escale.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
From: Kevin Hao
> Sent: 20 March 2014 11:48
> To: Scott Wood
> Cc: linuxppc-dev@...ts.ozlabs.org; Chenhui Zhao; Jason.Jin@...escale.com; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
>
> On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood wrote:
> > > The sequence "write, readback, sync" will guarantee this according to the manual.
> >
> > If you're referring to the section you quoted above, the manual does not
> > say that. It only talks about when accesses "to memory regions affected
> > by the configuration register write" can be safely made.
>
> To guarantee that the results of any sequence of writes to configuration
> registers are in effect, the final configuration register write should be
> immediately followed by a read of the same register, and that should be
> followed by a SYNC instruction. Then accesses can safely be made to memory
> regions affected by the configuration register write.
That sort of sequence is need to force the operations through any
external bus - after the cpu itself has issued the bus cycles.
Mostly required because writes are often 'posted' (ie address and data
latched, and then performed synchronously).
> According to the above description in t4240 RM manual (2.6.1 Accessing CCSR
> Memory from the Local Processor), that the writing to configuration register
> takes effect is a prerequisite for the memory access to the affected regions.
...
> OK, so the intention of 'twi, isync' following the load is not to order the
> following storage access, but order the following delay loop instructions,
> right
I tried to work out what the 'twi, isync' instructions were for (in in_le32()).
The best I could come up with was to ensure a synchronous bus-fault.
But bus faults are probably only expected during device probing - not
normal operation, and the instructions will have a significant cost.
Additionally in_le32() and out_le32() both start with a 'sync' instruction.
In many cases that isn't needed either - an explicit iosync() can be
used after groups of instructions.
David
Powered by blists - more mailing lists