> On Thu, Oct 29, 2009 at 10:00:28AM +0100, Joakim Tjernlund wrote: > > > I have found the problem. It occurred to me in the shower (okay > not really, > > > but most good ideas happen there). > > > > > > What was happening is that I was in fact able to write to the > correct > > > registers. However, I would try and write to them in a batch. > But the way > > > mmap works (at least according to the man page) with MAP_SHARED > is that the > > > file may not be updated until msync() is called. Now, I thought > that O_SYNC > > > would take care of that when I open /dev/mem, but that was not > the case. > > > > > > Anyway, to make a long story short, I inserted an msync() after > each > > > assignment to the flash. This resolved my problem and I can now > program my flash. > > > > Ouch, this was news to me too. Calling msync() after every write > kills performance. > > We use mmap(/dev/mem) to access HW and havn't seen any issues yet. > Is this > > perhaps a new behaviour for mmap(/dev/mem) and is there a way > > to avoid calling msync()? > > I suspect that the msync() was merely serving as a very heavyweight > memory barrier.
I did try hacking the mb() calls from the kernel source to use them in user space, but they had no effect. I still had to include the calls to msync(). _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
