linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep.Holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: cache-l2x0: Parse properties from DT for PL310 cache controller
Date: Tue, 07 Jan 2014 16:43:27 +0000	[thread overview]
Message-ID: <52CC2EAF.7050800@arm.com> (raw)
In-Reply-To: <6680044.VpT1oREkGO@wuerfel>

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

      reply	other threads:[~2014-01-07 16:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-07 11:41 [PATCH] ARM: cache-l2x0: Parse properties from DT for PL310 cache controller Tushar Behera
2014-01-07 11:57 ` Arnd Bergmann
2014-01-07 12:10   ` Tushar Behera
2014-01-07 12:41 ` Sudeep Holla
2014-01-07 12:54   ` Arnd Bergmann
2014-01-07 15:55     ` Sudeep Holla
2014-01-07 16:12       ` Arnd Bergmann
2014-01-07 16:43         ` Sudeep Holla [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52CC2EAF.7050800@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).