On Sat, Sep 18, 2004 at 12:10:01AM -0600, Grant Grundler wrote:
> Jesse Barnes wrote:
> ...
> > Btw Andrew (Vasquez), there's a small doc I put together that should describe
> > when you have to worry about PCI posting. It's in the tree:
> > Documentation/io_ordering.txt. If it's incomplete or confusing, just let me
> > know and I'll update it.
>
> Jesse,
> Both. incomplete and confusing.
> "concrete example of a hypothetical driver" wasn't my first warning
> this document needed work. :^)
Not just incomplete and confusing, but actively wrong. spin_lock/
spin_unlock should imply ordering of readb(). What you're describing
there is __readb(). See Documentation/DocBook/deviceiobook.tmpl. Also,
rmb() should ensure ordering of io reads; there should be no need to
touch the device.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
On Saturday, September 18, 2004 10:57 am, Matthew Wilcox wrote:
> On Sat, Sep 18, 2004 at 12:10:01AM -0600, Grant Grundler wrote:
> > Jesse Barnes wrote:
> > ...
> >
> > > Btw Andrew (Vasquez), there's a small doc I put together that should
> > > describe when you have to worry about PCI posting. It's in the tree:
> > > Documentation/io_ordering.txt. If it's incomplete or confusing, just
> > > let me know and I'll update it.
> >
> > Jesse,
> > Both. incomplete and confusing.
> > "concrete example of a hypothetical driver" wasn't my first warning
> > this document needed work. :^)
>
> Not just incomplete and confusing, but actively wrong. spin_lock/
> spin_unlock should imply ordering of readb(). What you're describing
> there is __readb(). See Documentation/DocBook/deviceiobook.tmpl. Also,
> rmb() should ensure ordering of io reads; there should be no need to
> touch the device.
I already sent a reply to this, so you now know that I was wrong in describing
the ordering issue as one of weak ordering, rather it's just supposed to be
describing simple write posting. Also, the first sample code is incorrect,
since the second spinlock protected region has a read before a write and
incorrectly states that the second write may arrive before the first. I
think Grant has some updates, if not I'll post a patch to fixup the doc.
Thanks,
Jesse
On Saturday, September 18, 2004 10:57 am, Matthew Wilcox wrote:
> On Sat, Sep 18, 2004 at 12:10:01AM -0600, Grant Grundler wrote:
> > Jesse Barnes wrote:
> > ...
> >
> > > Btw Andrew (Vasquez), there's a small doc I put together that should
> > > describe when you have to worry about PCI posting. It's in the tree:
> > > Documentation/io_ordering.txt. If it's incomplete or confusing, just
> > > let me know and I'll update it.
> >
> > Jesse,
> > Both. incomplete and confusing.
> > "concrete example of a hypothetical driver" wasn't my first warning
> > this document needed work. :^)
>
> Not just incomplete and confusing, but actively wrong. spin_lock/
> spin_unlock should imply ordering of readb(). What you're describing
> there is __readb(). See Documentation/DocBook/deviceiobook.tmpl. Also,
> rmb() should ensure ordering of io reads; there should be no need to
> touch the device.
Is this any better? I just sent it off to Grant too.
Thanks,
Jesse