> From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] > > Most of the weak memory attributes in newer ARMs are not exploited > > today in tree. I'll guess this was more a correctness and > capability > > judgment from Russell. > > Not entirely true. We do as much as is safe to do - which is > basically > using 'device' mappings for devices and ioremap, and 'memory' mappings > for the main memory, module and vmalloc mappings.
Is DEVICE really safe for things other than FIFOs with out the use of barriers? Accesses are in order but they can be buffered. The bus is free to post/buffer these writes as long as it preserves the order (and it does). I want to know the write happened before moving on in some code. Yes some barrier can be added to the code to fix it but its not there in most drivers today. I recall you gave an explanation on list a while back where MPCORE had to use DEVICE or it wouldn't work. That restriction is not there for others. We do in some drivers today get spurious interrupts when DEVICE is used but don't see them when using SO. Originally the IC-Architect wanted two memory windows per device, one SO for register control and one DEVICE for FIFO access. Given that we do DMA (which doesn't care about how ARM sees the world) on the performance hungry devices not doing this was ok. > What we don't do is mark DMA memory ask being normal uncached memory, > thereby allowing that to be reordered with device accesses - we make > it strongly ordered. The reason being that the kernel doesn't have > barriers necessary to ensure that writes to DMA memory hit physical > memory before the device access to enable DMA hits the DMA controller. For an experiment a couple years back we did convert the dma alloc pool addresses as NC. All worked -except- for OHCI-USB which started failing some tests. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
