Messages in this thread | | | Subject | Re: 2.6.7-rc1-mm1 | From | (Eric W. Biederman) | Date | 01 Jun 2004 00:38:14 -0600 |
| |
Andrew Morton <akpm@osdl.org> writes:
> add-i386-readq.patch > add i386 readq()/writeq()
- Again this is logically broken.
On 32bit-PCI bursts (the basic unit of transfer) can be split and merged on 32bit boundaries so you can't be atomic on the bus. But note even if a 64bit transaction is split (which is unlikely) the order of the operations on the device will remain the same because of pci ordering rules.
On 64bit-PCI bursts can only be split on 64bit boundaries so there are 64bit atomic cycles on the bus.
In PCI-X bursts can only be split when the address is a multiple of 128. So cards can care about atomic 64bit cycles.
In PCI-E switches do not touch the packets and devices are explicitly allowed to reject any packet they don't like.
So a readq or a writeq can on existing hardware be detected, and cared about.
The strongest argument that this readq/writeq is broken is this chunk of the hpet patch.
+#if BITS_PER_LONG == 64 +#define write_counter(V, MC) writeq(V, MC) +#define read_counter(MC) readq(MC) +#else +#define write_counter(V, MC) writel(V, MC) +#define read_counter(MC) readl(MC) +#endif
The code still cares and does not trust the readq/writeq emulations to do the same thing as their atomic counter parts.
So would a patch that names those helper functions readl2 and writel2 be acceptable? Just so it is clear what they do?
Eric - 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/
| |