[PATCH RFC 1/2] Documentation: arm: add cache DT bindings

Kumar Gala galak at codeaurora.org
Mon Dec 2 12:59:56 EST 2013


On Dec 2, 2013, at 11:50 AM, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:

> On Mon, Dec 02, 2013 at 05:28:41PM +0000, Kumar Gala wrote:
>> 
>> On Dec 2, 2013, at 10:20 AM, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
>> 
>>> On ARM systems the cache topology cannot be probed at runtime, in
>>> particular, it is impossible to probe which CPUs share a given cache
>>> level. Power management software requires this knowledge to implement
>>> optimized power down sequences, hence this patch adds a document that
>>> defines the DT cache bindings for ARM systems. The bindings are compliant
>>> with ePAPR (PowerPC bindings), and rely on the cache bindings already
>>> standardized in the ePAPR v1.1 document; ARM required updates are underlined
>>> in the binding document.
>>> 
>>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/cache.txt | 25 +++++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/cache.txt
>>> 
>>> diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt
>>> new file mode 100644
>>> index 0000000..009cddb
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/cache.txt
>>> @@ -0,0 +1,25 @@
>>> +==========================================
>>> +ARM processors cache binding description
>>> +==========================================
>>> +
>>> +Device tree bindings for ARM processor caches adhere to the cache bindings
>>> +described in [3], in section 3.8 for multi-level and shared caches.
>>> +
>>> +On ARM, internal caches cannot be described in the cpu node but require
>>> +specific nodes marked with compatible string set to "cache" (see [3],
>>> +section 3.8).
>> 
>> can you explain why
> 
> ARM v7 and v8 processors have a concept of cache levels which is valid
> even for internal caches. So either we add a cache-level property to
> internal caches or we do not use them for ARM.

There isn’t anything precluding a cachel-level property for internal caches.

> On top of that the definition of internal caches in the ePAPR is not
> well defined (for ARM) (what if you have multiple levels of internal
> caches ? - do we describe just L1 in the cpu node ?).

ePAPR has examples of multiple level’s of internal cache in the cpu node.

> Overall I think that is better to describe every cache object with a node
> and a compatible string, and shared caches are just cache nodes pointed at
> by multiple nodes (and private caches are just pointed at by one phandle
> in the respective cpu node).
> 
> No strong position on that though, provided every cache "object" on ARM has a
> cache-level attached to it.
> 
> Lorenzo
> 
>>> +
>>> +Furthermore the cache bindings in [3] require the following property update:
>>> +
>>> +- [Table 3.9] cache-level: This property of cache nodes must match the cache
>>> +			   level encoded in the processors CLIDR (v7) and
>>> +			   CLIDR_EL1 (v8) registers, as described in [1][2].
>>> +
>>> +All other properties and rules apply.
>>> +
>>> +[1] ARMv7-AR Reference Manual
>>> +    http://infocenter.arm.com/help/index.jsp
>>> +[2] ARMv8-A Reference Manual
>>> +    http://infocenter.arm.com/help/index.jsp
>>> +[3] ePAPR standard
>>> +    https://www.power.org/documentation/epapr-version-1-1/
>>> -- 
>>> 1.8.4
>>> 
>>> 
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>> 
>> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation




More information about the linux-arm-kernel mailing list