[PATCH] ARM: cache-l2x0: Parse properties from DT for PL310 cache controller

Sudeep Holla Sudeep.Holla at arm.com
Tue Jan 7 11:43:27 EST 2014


On 07/01/14 16:12, Arnd Bergmann wrote:
> On Tuesday 07 January 2014 15:55:45 Sudeep Holla wrote:
>> On 07/01/14 12:54, Arnd Bergmann wrote:
>>> On Tuesday 07 January 2014 12:41:42 Sudeep Holla wrote:
>>>> Hi Tushar,
>>>>
>>>> This has been discussed couple of times in past[1][2], and the opinion was not
>>>> to have these in DT as they are more configuration data than the actual hardware
>>>> description.
>>>
>>> How do you suggest we get rid of the magic constants in platform code then?
>>> I definitely don't want to keep the current state, and having configuration
>>> data in DT seems the lesser evil.
>>>
>>
>> I agree, but since these are more L2CC configuration than hardware description,
>> IMO chosen node is one option. However it's good to get opinion from DT guys.
> 
> I think one of the discussions we had during the Edinburgh kernel summit resulted
> in being more relaxed towards configuration data in device nodes.
> 

Ok.

>>> Are there some reasonable defaults that Linux could use independent of the
>>> platform and of what the boot loader defaults to?
>>>
>>
>> Most of these registers can't be programmed in Non-secure mode. So as mentioned
>> already in previous discussions it is better to avoid these settings in kernel.
>> It would be better if bootloader programs these settings even if Linux runs in
>> secure mode for simplicity.
> 
> Yes, that would be ideal, but I fear we have to live with the boot loaders that
> are in existence already. Whether or not the registers can be programmed in
> non-secure mode is certainly a piece of information that belongs into the DT
> node, so we don't try to write them when we shouldn't. We could also have a

But the main problem is that there is no way to detect the current mode (i.e.
secure or non-secure). So it won't be of any help even if we can get these
information from DT. It's better to assume Linux runs in non-secure mode and
avoid using any registers with secure only access. Any attempt to such
restricted access in non-secure mode results in error.

> property that identifies whether the boot loader has in fact set up the cache
> controller correctly or whether Linux has to do it. There should be no
> argument about this being out of scope, since it describes a platform property
> (presence of a sane boot loader) rather than the actual configuration.
> 
> If we decide to have such properties and we boot on a system where we can
> and should change the settings, is there a way for Linux to know what the
> settings are supposed to be other than reading them from a DT file or
> from a per-platform default?
> 

Yes I understand, but for above mentioned reason it's difficult.

Regards,
Sudeep





More information about the linux-arm-kernel mailing list