All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	Kumar Gala <galak@codeaurora.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
Date: Wed, 8 Jan 2014 10:05:38 +0000	[thread overview]
Message-ID: <20140108100538.GA2927@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140107201239.GD14405@codeaurora.org>

On Tue, Jan 07, 2014 at 08:12:39PM +0000, Stephen Boyd wrote:
> 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?

Sorry, my bad, you are right.

> 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>.'

We need to define it properly for ARM, I am not sure we can use level
as defined in CLIDR, I need to think more about this.

> > 
> > > +
> > > +	- 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.

Ok, I will try to update the bindings with the interrupt part and copy
you in, even though the level definition worries me a bit, it is an
important property for power management and I need to find a proper
solution before bindings can get accepted (basically the problem is:
if different CPUs can see a cache at different levels as defined in the
CLIDR we cannot describe a cache with a single cache level or put it
differently, level can not represent the value in the CLIDR hence we
need to describe it differently).

Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC
Date: Wed, 8 Jan 2014 10:05:38 +0000	[thread overview]
Message-ID: <20140108100538.GA2927@e102568-lin.cambridge.arm.com> (raw)
In-Reply-To: <20140107201239.GD14405@codeaurora.org>

On Tue, Jan 07, 2014 at 08:12:39PM +0000, Stephen Boyd wrote:
> 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?

Sorry, my bad, you are right.

> 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>.'

We need to define it properly for ARM, I am not sure we can use level
as defined in CLIDR, I need to think more about this.

> > 
> > > +
> > > +	- 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.

Ok, I will try to update the bindings with the interrupt part and copy
you in, even though the level definition worries me a bit, it is an
important property for power management and I need to find a proper
solution before bindings can get accepted (basically the problem is:
if different CPUs can see a cache at different levels as defined in the
CLIDR we cannot describe a cache with a single cache level or put it
differently, level can not represent the value in the CLIDR hence we
need to describe it differently).

Lorenzo

  reply	other threads:[~2014-01-08 10:05 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-30 20:14 [PATCH v4 0/6] Krait L1/L2 EDAC driver Stephen Boyd
2013-12-30 20:14 ` Stephen Boyd
2013-12-30 20:14 ` Stephen Boyd
2013-12-30 20:14 ` [PATCH v4 1/6] edac: Don't try to cancel workqueue when it's never setup Stephen Boyd
2013-12-30 20:14   ` Stephen Boyd
2014-01-07 17:19   ` Borislav Petkov
2014-01-07 17:19     ` Borislav Petkov
2014-01-07 17:19     ` Borislav Petkov
2013-12-30 20:14 ` [PATCH v4 2/6] genirq: export percpu irq functions for module usage Stephen Boyd
2013-12-30 20:14   ` Stephen Boyd
2014-01-07 23:02   ` Borislav Petkov
2014-01-07 23:02     ` Borislav Petkov
2013-12-30 20:14 ` [PATCH v4 3/6] ARM: Add Krait L2 accessor functions Stephen Boyd
2013-12-30 20:14   ` Stephen Boyd
2014-01-07 23:07   ` Borislav Petkov
2014-01-07 23:07     ` Borislav Petkov
2014-01-07 23:09     ` Stephen Boyd
2014-01-07 23:09       ` Stephen Boyd
2014-01-09  0:53   ` Courtney Cavin
2014-01-09  0:53     ` Courtney Cavin
2014-01-09  0:53     ` Courtney Cavin
2014-01-09  1:54     ` Stephen Boyd
2014-01-09  1:54       ` Stephen Boyd
2014-01-09  1:54       ` Stephen Boyd
2014-01-09 11:03       ` Borislav Petkov
2014-01-09 11:03         ` Borislav Petkov
2014-01-09 11:03         ` Borislav Petkov
     [not found] ` <1388434457-4194-1-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-12-30 20:14   ` [PATCH v4 4/6] devicetree: bindings: Document Krait L1/L2 EDAC Stephen Boyd
2013-12-30 20:14     ` Stephen Boyd
2013-12-30 20:14     ` Stephen Boyd
2014-01-07 10:54     ` Lorenzo Pieralisi
2014-01-07 10:54       ` Lorenzo Pieralisi
2014-01-07 10:54       ` Lorenzo Pieralisi
2014-01-07 20:12       ` Stephen Boyd
2014-01-07 20:12         ` Stephen Boyd
2014-01-07 20:12         ` Stephen Boyd
2014-01-08 10:05         ` Lorenzo Pieralisi [this message]
2014-01-08 10:05           ` Lorenzo Pieralisi
2014-01-08 10:05           ` Lorenzo Pieralisi
2014-01-09 20:52           ` Stephen Boyd
2014-01-09 20:52             ` Stephen Boyd
2014-01-09 20:52             ` Stephen Boyd
2014-01-10 10:54             ` Lorenzo Pieralisi
2014-01-10 10:54               ` Lorenzo Pieralisi
2014-01-10 10:54               ` Lorenzo Pieralisi
2013-12-30 20:14 ` [PATCH v4 5/6] edac: Add support for Krait CPU cache error detection Stephen Boyd
2013-12-30 20:14   ` Stephen Boyd
2014-01-07 23:43   ` Borislav Petkov
2014-01-07 23:43     ` Borislav Petkov
2013-12-30 20:14 ` [PATCH v4 6/6] ARM: dts: msm: Add Krait CPU/L2 nodes Stephen Boyd
2013-12-30 20:14   ` Stephen Boyd
2014-01-04 10:19 ` [PATCH v4 0/6] Krait L1/L2 EDAC driver Borislav Petkov
2014-01-04 10:19   ` Borislav Petkov
     [not found]   ` <20140104101901.GA4439-K5JNixvcfoxupOikMc4+xw@public.gmane.org>
2014-01-06 22:09     ` Stephen Boyd
2014-01-06 22:09       ` Stephen Boyd
2014-01-06 22:09       ` Stephen Boyd

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=20140108100538.GA2927@e102568-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sboyd@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.