[U-Boot] About the volatile data type in include/net.h

[Mike Frysinger]

On Wednesday 23 November 2011 17:42:11 Simon Glass wrote:
> On Wed, Nov 23, 2011 at 2:27 PM, Mike Frysinger wrote:
> > On Wednesday 23 November 2011 14:21:20 Simon Glass wrote:
> >> On Mon, Nov 21, 2011 at 7:06 PM, Macpaul Lin wrote:
> >> > I have found there are some variables declared as volatile in
> >> > include/net.h. Some of them are used as in send and receive functions.
> >> > Since some of them seems won't be update by hardware, like sending
> >> > functions. Should we check and clean them up?
> >> 
> >> I think so, since any access should go through read()l/writel() anyway.
> > 
> > i don't think so ... there's no reason to use readl/writel on packet
> > buffers sitting in external memory
> 
> I suppose DMA takes care of these, fair enough. Do no boards maually
> read/write packet buffers any more?

normally the process is:
 - core executes common net code and constructs packet in external memory then 
passes pointer to driver
 - driver flushes cache if need be, then sets up dma controller to send it to 
peripheral hardware
 - hardware sends it out

> But (re your other email) I can't see that volatile would avoid the
> cache problems. Some boards will have network problems with the dcache
> turned on. But these would not be fixed by volatile, only by
> flush/invalidate. I think USB has an example of how to do that, but it
> doesn't seem to be everywhere in U-Boot yet.

right, i think mostly because ARM has taken so long to get cache running.  the 
Blackfin port has been running with cache almost from the start, so notice when 
things go wrong in common code.  but that's much less common as cache/dma 
problems are most often driver code, and that is mostly SoC specific.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111123/f425fd64/attachment.pgp>