On 06/08/15 17:21, Geert Uytterhoeven wrote:
Hi Sudeep,
On Wed, Aug 5, 2015 at 12:58 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
On 05/08/15 11:44, Geert Uytterhoeven wrote:
On Wed, Aug 5, 2015 at 11:34 AM, Sudeep Holla <sudeep.holla@xxxxxxx>
wrote:
[..]
Any particular reason whey you need all this cache-* properties ? Is
To describe the cache as good as possible.
Why if you can probe it ? IMO DT is mostly useful to describe things
that can't be probed/discovered using hardware.
something broken on these SoCs ? We should be able to get most of these
information from the SoC(reading some registers). It's good to avoid
passing them via DT if they can be discovered from hardware.
So we have all these documented properties in
Documentation/devicetree/bindings/arm/l2cc.txt, but they're not meant to
be used?
No I didn't mean that, I just wanted to know if they can't be probed due
to some hardware issue. It would avoid issues with wrong DTs especially
if they are not so easy to upgrade.
I think it works just fine without them.
Yes, in general if you specify a value in DT that can be probed, its
usually to override the probed value(useful if there is some h/w errata)...
Should I drop all cache-* properties marked optional in
Documentation/devicetree/bindings/arm/l2cc.txt?
That would be cache-size, cache-sets, cache-block-size, and cache-line-size.
... however if you incorrect values by mistake, then it's problematic
even if h/w provides correct value.
What about the L1 cache? I know Linux uses none of the d-cache-*
and i-cache-* properties.
Same there, IIRC PPC use them, but on ARM I think so far the need has
not arise.
Just to re-iterate myself, I am not against adding them, but it's not
really needed. I just wanted to know if there was any h/w issue.
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
