> 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. - In addition to the DVFS path there is a context-restore path which also needs to live in non-cached SRAM. It will reset and reprogram the registers. You can't completely re-program the DDR controller from the same memory it is executing from. * You can go through all the trouble of pre-loading and locking to cache for the same code then unlocking but it adds unnecessary complexity. It also exposes you to lots of early processor errata. * 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. Regards, Richard W. -- 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
