On Mon, Jan 27, 2014 at 12:58:39PM +0000, Russell King - ARM Linux wrote: > On Tue, Jan 21, 2014 at 11:49:01AM +0000, Dave Martin wrote: > > I do have a worry that because the kernel won't normally use this > > information, by default it will get pasted between .dts files, won't get > > tested and will be wrong rather often. It also violates the DT principle > > that probeable information should not be present in the DT -- ePAPR > > obviously envisages systems where cache geometry information is not > > probeable, but that's not the case for architected caches on ARM, except > > in rare cases where the CLIDR is wrong. > > That statement is wrong. There are caches on ARM CPUs where there is no > CLIDR register. I suggest reading the earlier DDI0100 revisions. You're right; I should have qualified that statement with the proviso that there _is_ a CLIDR (or some other reliably way to discover the cache geometry directly from the hardware). In particular, this applies to all v7-[AR] CPUs, but not to <=v5. Not sure about v6 -- it may be a mixture. My worry was about duplication of information; so if there is no discovery mechanism then there is no duplication and no problem -- on those older CPUs, the corresponding information could be placed in the DT, or where it doesn't cause a problem it can remain hard-coded into the kernel, as at present. If we _allow_ inclusion of that information in the DT for pre-v7, that still raises questions about what information gets used if there is hard-coded geometry in the kernel too. I can't see a sufficient reason to advocate churn for pre-v7 platforms, but other people's views may differ. Cheers ---Dave -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
