Wood Scott-B07421 wrote: > > Careful with the barriers. > > You've got a raw readback, which means it's not going to wait for > completion with the twi/isync hack.
You told me that since I'm doing a read following a write to uncached memory, that I don't need a sync. And what twi/isync hack are you talking about? The one in in_8? > > Ordinarily that would be OK, since you only need ordering between the > readb and the first access in set_mux_to_diu(). Unfortunately, that > first access is an 8-bit access, which for some strange reason does > sync differently than 16/32-bit accesses. The latter do sync+write, > but 8-bit does write+eieio. So there's no barrier between the read > and the write. Wait, I don't understand. Where are you getting this from? What do you mean by 16-bit accesses does sync+write vs. write+eieio? Where is the sync/eieio coming from? As for why I don't use in_8, etc, it's because I'm trying to optimize this code. Unlike Dave's code, this stuff needs to be as fast as possible. Although, I wonder if an extra sync will make a difference considering the overhead of switching the muxes. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot