This is a small patch to deviceiobook.tmpl to describe the new mmiowb routine
a bit more completely. I've also updated it to provide pointers to drivers
that do write flushing, use mmiowb, and use the readX_relaxed routines.
Acked-by: Grant Grundler <[email protected]>
Signed-off-by: Jesse Barnes <[email protected]>
Thanks,
Jesse
On Fri, 2004-10-29 at 17:47 -0700, Jesse Barnes wrote:
> This is a small patch to deviceiobook.tmpl to describe the new mmiowb routine
> a bit more completely. I've also updated it to provide pointers to drivers
> that do write flushing, use mmiowb, and use the readX_relaxed routines.
It's all good, but your semantics and description are very tailored to
your specific arch problem vs. unlock.
What about my suggestion of defining a broader semantic of mmiowb() as
beeing a barrier ordering MMIOs vs. the rest of the world ? The later
includes stores to memory _and_ spinlock/unlock.
I still intend to eventually make good use of that on ppc64 to get rid
of the expensive barriers we had to put in our writeX() implementations,
though I didn't have time to work on that yet.
Ben.
On Friday, October 29, 2004 7:35 pm, Benjamin Herrenschmidt wrote:
> On Fri, 2004-10-29 at 17:47 -0700, Jesse Barnes wrote:
> > This is a small patch to deviceiobook.tmpl to describe the new mmiowb
> > routine a bit more completely. I've also updated it to provide pointers
> > to drivers that do write flushing, use mmiowb, and use the readX_relaxed
> > routines.
>
> It's all good, but your semantics and description are very tailored to
> your specific arch problem vs. unlock.
>
> What about my suggestion of defining a broader semantic of mmiowb() as
> beeing a barrier ordering MMIOs vs. the rest of the world ? The later
> includes stores to memory _and_ spinlock/unlock.
Yeah, that's ok with me, just be sure to update the documentation when you add
the PPC stuff. Seems like a worthwhile optimization.
thanks,
Jesse