On Thu, Jan 28, 2010 at 03:04:49PM -0800, Larry Bassel wrote: > Hopefully this is a better description of the patch: > > Some Qualcomm SOCs (such as the MSM7x27) require a write to > strongly ordered memory in order to fully flush the AXI bus. > Although the generic ARM code provides MT_DEVICE, which starts > as strongly ordered, it later turns on the buffered flag to > make this memory shared. Let me correct you here. MT_DEVICE is for defining regions for devices. What you ultimately end up with depends on the CPU architecture you have, and the terminology is dependent on the CPU architecture. If you have ARMv4 or lower, then it is 'uncached unbuffered' memory. (The term 'strongly ordered' does not apply to these CPUs.) For CPUs which have distinct memory types (ARMv6 and later), the memory type is configured to be 'shared device'. (This has nothing to do with buffering, and indeed talking about buffered flag is meaningless for these CPUs.) Practically, ARMv5 CPUs can be either ARMv4 or ARMv6-like depending on who makes them. Now, I think what you're referring to when you talk about AXI bus flushing is that the AXI bus has a write posting ability - where you can write to devices, and the write doesn't hit the device until some time later. Any system with PCI also has this problem - in the absence of any other activity, writes to devices on PCI can sit on any bridge indefinitely, and not reach the device. The solution Linux chose for this was to read back from the device. Since PCI requires that a read can not bypass a write, the bridge has to flush the write to the device before allowing the read to complete. I would strongly suggest a similar approach is used if possible with AXI, rather than resorting to strongly ordered mappings. This is going to be even more important with ARMv7 because (ISTR) strongly ordered reads/writes are no longer ordered with respect to device and memory accesses. -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
