Messages in this thread | | | Date | Thu, 10 Jan 2002 14:59:48 -0800 | From | Jesse Barnes <> | Subject | Re: memory-mapped i/o barrier |
| |
On Thu, Jan 10, 2002 at 11:05:04PM +0000, Alan Cox wrote: > > ia64, and I'm wondering if you guys will accept something similar. On > > mips64, mmiob() could just be implemented as a 'sync', but I'm not > > sure how to do it (or if it's even necessary) on other platforms. > > Wouldn't it be wise to pass the device to this. Someone somewhere is going > to have to read a bus dependant chipset register and need to know which > pci_device * is involved ?
David and I went back and forth on that a little. My hope is that most platforms will have a reasonable way (i.e. no pci_device needed) to ensure ordering. I'm only aware of two platforms at the moment that have i/o ordering issues: mips64 and ia64/sn. On the former, a simple 'sync' instruction is sufficient to barrier i/o, while on the latter, a read from the local numa hub suffices.
If only a few platforms need info about which busses have outstanding i/o, it should be possible to build a list of bridge chips or devices and loop, reading from each (where presumably the read would act as the barrier op).
If, OTOH, there are lots of platforms that need a pci_device so they can read from a corresponding bridge to ensure ordering, it would be a good idea to add an argument to the macro, as David initially suggested.
Thoughts?
Jesse - 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/
| |