Messages in this thread | ![/](/images/icornerl.gif) | | From | Michael Buesch <> | Subject | Re: Opinion on ordering of writel vs. stores to RAM | Date | Sun, 10 Sep 2006 19:35:09 +0200 |
| |
On Sunday 10 September 2006 19:19, Jesse Barnes wrote: > On Saturday, September 09, 2006 8:09 am, Alan Cox wrote: > > Ar Sad, 2006-09-09 am 17:23 +1000, ysgrifennodd Benjamin > Herrenschmidt: > > > The problem is that very few people have any clear idea of what > > > mmiowb is :) In fact, what you described is not the definition of > > > mmiowb according to Jesse > > > > Some of us talked a little about this at Linux Kongress and one > > suggestion so people did understand it was > > > > spin_lock_io(); > > spin_unlock_io(); > > > > so that it can be expressed not as a weird barrier op but as part of > > the locking. > > That's what IRIX had. It would let us get rid of mmiowb and avoid doing > a full sync in writeX, so may be the best option.
Last time I suggested that, people did not want it. Probably about 9 months ago. Don't remember exactly. We came to the decision that if a driver depends on some weak ordering, it should either directly use mmiowb() or have its own locking wrapper which wraps spin_unlock() and mmiowb().
There is one little problem in practice with something like spin_unlock_io().
spin_lock_io(&lock); foovalue = new_foovalue; if (device_is_fooing) writel(foovalue, REGISTER); spin_unlock_io(&lock);
That would be an unneccessary sync in case device is not fooing. In contrast to the explicit version:
spin_lock(&lock); foovalue = new_foovalue; if (device_is_fooing) { writel(foovalue, REGISTER); mmiowb(); } spin_unlock(&lock);
-- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |