On 09/12/15 17:21, Mark Rutland wrote:
On Wed, Dec 09, 2015 at 05:58:38PM +0100, Dirk Behme wrote:
For what is the arm64 dts entry
cpu@0 {
...
next-level-cache = <&L2_0>;
};
L2_0: l2-cache0 {
compatible = "cache";
};
good for at all, then?
With the other properties from ePAPR you can acquire information on the
geometry of the cache, which cannot be acquired from architected
registers.
Just for my understanding: Yes, if other properties from ePAPR like
geometry of the cache are added to the device tree l2 cache entries
then it makes sense to have them.
But an "empty" entry like the one given in the example above doesn't
make much sense and could be removed without loosing any
functionality?
It looks to me that most of the L2 entries we have in
arch/arm64/boot/dts are such "empty" entries.
Is this understanding correct?
You are mostly correct, just missing some history.
It was previously (erroneously) assumed that the cache geometry could be
derived from architected registers used for set/way maintenance.
However, we knew that this did not describe how those caches were linked
to each other (e.g. which CPU shared with level x cache). So the
description in DT was required to provide that.
Now, we all know that the geometry is necessary too. Those DTs should be
fixed.
Sudeep, do you know what's happening on that front?
No updates yet. I thought Alex Van Brunt would pick that. I have a patch
for PPC which never got tested/reviewed. It moves PPC code to reuse the
generic cacheinfo. If I can revive that and look into ways of moving it
to core code.
--
Regards,
Sudeep
--
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
