Messages in this thread | | | Subject | Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040 | From | Scott Wood <> | Date | Fri, 21 Mar 2014 16:16:33 -0500 |
| |
On Fri, 2014-03-21 at 09:21 +0000, David Laight wrote: > From: Scott Wood [mailto:scottwood@freescale.com] > > On Thu, 2014-03-20 at 11:59 +0000, David Laight wrote: > > > 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. > > > > The idea is that it's better to be maximally safe by default, and let > > performance critical sections be optimized using raw accessors and > > explicit synchronization if needed, than to have hard-to-debug bugs due > > to missing/wrong sync. A lot of I/O is slow enough that the performance > > impact doesn't really matter, but the brain-time cost of getting the > > sync right is still there. > > Hmmm.... > > That might be an excuse for the 'sync', but not the twi and isync.
That might be true if I/O is always cache inhibited and guarded, in which case I think we can rely on that to ensure that the load has completed before we do things like wrtee or rfi. In any case, I'd want to hear Ben's explanation.
> I was setting up a dma request (for the ppc 83xx PCIe bridge) and > was doing back to back little-endian writes into memory. > I had difficulty finding and including header files containing > the definitions for byteswapped accesses I needed. > arch/powerpc/include/asm/swab.h contains some - but I couldn't > work out how to get it included (apart from giving the full path). > > In any case you need to understand when synchronisation is > required - otherwise you will get it wrong. > Especially since non-byteswapped accesses are done by direct > access.
Yes, it's bad that rawness combines the lack of byteswapping with the lack of synchronization. Ideally the raw accessors would also come in big and little endian form, plus a native endian form if it's really needed.
-Scott
| |