On Tue, 2008-08-05 at 07:15 -0500, Woodruff, Richard wrote: > > Is the controller allowed to write dirty cache lines out at any time > > it > > likes? Surely a better fix is to drain the cache of the changes before > > changing the clock for the SDRAM? > > - Previously the SRAM was marked as cached. _Execution_ using that > attribute will generate line fetches to SRAM. This will cause > displacement write-outs of resident DDR lines. Similarly, > _load/store_ sequences in that code have the same effect. This cast > outs dead lock the CPU and it can't fetch to progress. [...] > * Flushing the entire L1 & L2 cache frequently is very expensive and > better not done if you don't have. Also, it is not sufficient for the > context-restore path which needs to NOT live in DDR. > > The code need to execute in a non-cached region. I don't think there is any guarantee that dirty cache line won't be evicted to SDRAM even if your code uses uncached memory only. The CPU is allowed to do speculative reads from the normal cached memory and these reads may force a dirty cache line to be written back to memory. You may need to do at least a cache clean operation (invalidate not necessary). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
