linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 1/2] Documentation: arm: add cache DT bindings
Date: Mon, 2 Dec 2013 18:34:12 +0000	[thread overview]
Message-ID: <20131202183412.GA13791@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <CB2ECFBB-A959-4A44-B301-0188EA5599A3@codeaurora.org>

On Mon, Dec 02, 2013 at 05:59:56PM +0000, Kumar Gala wrote:
> 
> On Dec 2, 2013, at 11:50 AM, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> 
> > On Mon, Dec 02, 2013 at 05:28:41PM +0000, Kumar Gala wrote:
> >> 
> >> On Dec 2, 2013, at 10:20 AM, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> >> 
> >>> On ARM systems the cache topology cannot be probed at runtime, in
> >>> particular, it is impossible to probe which CPUs share a given cache
> >>> level. Power management software requires this knowledge to implement
> >>> optimized power down sequences, hence this patch adds a document that
> >>> defines the DT cache bindings for ARM systems. The bindings are compliant
> >>> with ePAPR (PowerPC bindings), and rely on the cache bindings already
> >>> standardized in the ePAPR v1.1 document; ARM required updates are underlined
> >>> in the binding document.
> >>> 
> >>> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>> ---
> >>> Documentation/devicetree/bindings/arm/cache.txt | 25 +++++++++++++++++++++++++
> >>> 1 file changed, 25 insertions(+)
> >>> create mode 100644 Documentation/devicetree/bindings/arm/cache.txt
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/arm/cache.txt b/Documentation/devicetree/bindings/arm/cache.txt
> >>> new file mode 100644
> >>> index 0000000..009cddb
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/cache.txt
> >>> @@ -0,0 +1,25 @@
> >>> +==========================================
> >>> +ARM processors cache binding description
> >>> +==========================================
> >>> +
> >>> +Device tree bindings for ARM processor caches adhere to the cache bindings
> >>> +described in [3], in section 3.8 for multi-level and shared caches.
> >>> +
> >>> +On ARM, internal caches cannot be described in the cpu node but require
> >>> +specific nodes marked with compatible string set to "cache" (see [3],
> >>> +section 3.8).
> >> 
> >> can you explain why
> > 
> > ARM v7 and v8 processors have a concept of cache levels which is valid
> > even for internal caches. So either we add a cache-level property to
> > internal caches or we do not use them for ARM.
> 
> There isn't anything precluding a cachel-level property for internal caches.
> 
> > On top of that the definition of internal caches in the ePAPR is not
> > well defined (for ARM) (what if you have multiple levels of internal
> > caches ? - do we describe just L1 in the cpu node ?).
> 
> ePAPR has examples of multiple level's of internal cache in the cpu node.

Where ? 3.7.3 (ePAPR v1.1) Internal (L1) Cache properties ? I do not think so.

It does by using the definitions in 3.8 "Multi level and shared caches".

So, since the cache bindings in 3.8 allow to describe a cache hierarchy
on ARM, that's what I used. Declaring L1 in the CPU node buys us nothing, so
I do not think there is a point in using it on ARM. That's why instead
of changing the bindings for internal (L1) caches to require cache-level
we should just ignore them IMHO.

ePAPR v1.1 contains a bug (example page 47 - line 47) since a cpu node cannot
contain a cache-level property, that's not a property of internal caches and
it has to be declared in a node with:

compatible = "cache";

unless my understanding of ePAPR is wrong.

All I am saying is that multi-level cache bindings can be used to
describe all cache hierarchies for ARM, we do not need internal (L1)
cache bindings at all, it is just legacy stuff.

Lorenzo

  reply	other threads:[~2013-12-02 18:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-02 16:20 [PATCH RFC 0/2] ARM: defining power states DT bindings Lorenzo Pieralisi
2013-12-02 16:20 ` [PATCH RFC 1/2] Documentation: arm: add cache " Lorenzo Pieralisi
2013-12-02 17:28   ` Kumar Gala
2013-12-02 17:50     ` Lorenzo Pieralisi
2013-12-02 17:59       ` Kumar Gala
2013-12-02 18:34         ` Lorenzo Pieralisi [this message]
2013-12-04 13:29   ` Dave Martin
2013-12-04 15:00     ` Lorenzo Pieralisi
2013-12-02 16:20 ` [PATCH RFC 2/2] Documentation: arm: define DT C-states bindings Lorenzo Pieralisi
2013-12-02 18:08   ` Kumar Gala
2013-12-03 10:40     ` Lorenzo Pieralisi
2013-12-04 15:36       ` Kumar Gala
2013-12-04 16:31         ` Lorenzo Pieralisi
2013-12-03 11:52   ` Daniel Lezcano
2013-12-04 15:20   ` Dave Martin
2013-12-04 17:06     ` Lorenzo Pieralisi
2013-12-06 14:54       ` Vincent Guittot
2013-12-10  6:31   ` Antti Miettinen
2013-12-10 13:27     ` Lorenzo Pieralisi
2013-12-10 22:04       ` Antti Miettinen
2013-12-16 12:11         ` Lorenzo Pieralisi

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=20131202183412.GA13791@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@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).