Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC

[Stephen Boyd]

On 01/07, Lorenzo Pieralisi wrote:
> 
> Not sure this binding (cache node) belongs in cpus.txt
> 
> I am working on defining cache bindings for ARM within the C-state
> standardization effort:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/215543.html

Thanks I'll take a look.

> 
> > +
> > +	Description: Describes a cache in an ARM based system
> > +
> > +	- compatible
> > +		Usage: required
> > +		Value type: <string>
> > +		Definition: shall contain at least "cache"
> 
> It is a bit vague, can't we just follow the ePAPR compatible definition ?
> See posting above.

Hm.. I thought this did follow the ePAPR spec. I see 'compatible,
required, string, A standard property. The value shall include
the string "cache".' Looks the same?

And I see 'cache-level, required, u32, Specifies the level in the
cache hierarchy. For example, a level 2 cache has a value of
<2>.'

> 
> > +
> > +	- cache-level
> > +		Usage: required
> > +		Value type: <u32>
> > +		Definition: level in the cache heirachy
> 
> "hierarchy".

Thanks.

> I have a problem with the cache level definition, and in
> particular the numbering, ie what the level number represents. If we
> mean the cache level seen through the CLIDR and co., it is hard to use
> it for shared caches since the level seen by different CPUs can actually
> be different, or put it differently the level number might not be unique for
> a shared cache. I need to think about a proper way to sort this out.
> 

Ok. I don't even use this property in my driver. All I really
need is the phandle from cpus pointing to the L2 and the
interrupts property in the L2 node.

How do you want to proceed here? If your cache binding goes
through I would just need to add the interrupts part. Or you
could even add that part in the same patch, you could have my
signed-off-by for that.

-- 
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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/