> 
> Hi There
> 
> The last I posted, I'd figured the fxp (etherexpress) driver was showing
> symptoms of lack of cache sync....(i.e. I disabled the data cacheing and it
> suddenly worked).
> 
> Anyway, checking out the driver itself seemed to indicate (IMHO) that the
> "bus_dmamap_sync" was in fact getting called where necessary.
> 
> Then I checked out the "_bus_dmamap_sync(t, map, offset, len, ops)" in
> "arm32/arm32/bus_dma.c" and noticed that nothing gets done for the
> BUS_DMASYNC_POSTREAD and BUS_DMASYNC_POSTWRITE cases.
> I.O.W, the whole _bus_dmamap_sync function lives inside this "if"
> 
> if (ops & (BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE))
> ........
> 
> so I changed it to "if (1)" (i.e. to always do whatever it does....)
> 
> and now the FXP driver works just fine with all the caching enabled.

I can't think why there should need to be any cache sync operations on the 
POST... calls; the transfer has already taken place by this time.  This 
makes me wonder if a PRE operation is being called with a POST flag set, 
or with no flag set at all.  Of course, if you are using bounce buffers, 
the POSTREAD needs to copy the data from the bounce buffer to its real 
destination, but that shouldn't need a cache sync either.

A possible (but somewhat unlikely) reason why this might make things work 
is if the sync is causing some other, unrelated, data to get written out 
to the device.

> Specifically: What processing should be done POSTREAD/POSTWRITE?

POSTWRITE is normally a nop (unless there are resources to release); 
POSTREAD should be used to synchronize with a bounce buffer if one is in 
use.

> Who is "looking after" that particular piece of code (bus dma stuff for
> arm)?

Well, most of this code was written by Jason Thorpe, but that doesn't mean 
he is maintaining it.

> Should I do an "official" bug report?

Always a good idea; then it won't get "forgotten".

Richard.