Robin Farine writes: > I did not mean that the compiler was optimizing the read access out, > but rather that the CPU might not complete a pending store to isp > chip until the target operand of the read from the uncached > Sorry, misunderstanding.
> location is actually used as source operand, thus the "mov %1, %1" > in my version. At least that is what I understand from "Intel® > PXA26x Processor Family Developer's Manual, 2.4 Input/Output > Ordering". > Probably you're right (though I wouldn't trust Intel documentation farther than I can throw the PDF document ;), but my scope was telling me that it worked as expected. > > I'm getting ~700ns delay with the UNCACHED_PHYS_0 access alone. > > OK then, but this has to be verified with a scope for each platform > since e.g. on a PXA with a 100Mhz memory clock, an uncached read > from SDRAM can theoretically take ~70ns right? > An SDRAM memory cycle may be 70ns, but UNCACHED_PHYS_0 is mapped to phys addr 0x00000000 which is the static CS0 (usually FLASH ROM) on PXA2xx. Lothar Wassmann ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
