On 03/11, Lorenzo Pieralisi wrote:
> On Fri, Mar 07, 2014 at 11:08:56PM +, Stephen Boyd wrote:
> >
> > Or should we be expressing the L1 cache as well? Something like:
> >
> > cpus {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> >
On Fri, Mar 07, 2014 at 11:08:56PM +, Stephen Boyd wrote:
> On 02/26, Lorenzo Pieralisi wrote:
> > On Tue, Feb 25, 2014 at 08:48:38PM +, Kumar Gala wrote:
> > >
> > > On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi
> > > wrote:
> > > >
> > > > As I mentioned, I do not like the idea of
On Fri, Mar 07, 2014 at 11:08:56PM +, Stephen Boyd wrote:
On 02/26, Lorenzo Pieralisi wrote:
On Tue, Feb 25, 2014 at 08:48:38PM +, Kumar Gala wrote:
On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi
lorenzo.pieral...@arm.com wrote:
As I mentioned, I do not like the idea
On 03/11, Lorenzo Pieralisi wrote:
On Fri, Mar 07, 2014 at 11:08:56PM +, Stephen Boyd wrote:
Or should we be expressing the L1 cache as well? Something like:
cpus {
#address-cells = 1;
#size-cells = 0;
cpu@0 {
On 02/26, Lorenzo Pieralisi wrote:
> On Tue, Feb 25, 2014 at 08:48:38PM +, Kumar Gala wrote:
> >
> > On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi
> > wrote:
> > >
> > > As I mentioned, I do not like the idea of adding compatible properties
> > > just to force the kernel to create
On 02/26, Lorenzo Pieralisi wrote:
On Tue, Feb 25, 2014 at 08:48:38PM +, Kumar Gala wrote:
On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com
wrote:
As I mentioned, I do not like the idea of adding compatible properties
just to force the kernel to
On Tue, Feb 25, 2014 at 08:48:38PM +, Kumar Gala wrote:
>
> On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi
> wrote:
>
> > Hi Stephen,
> >
> > On Wed, Feb 19, 2014 at 12:20:43AM +, Stephen Boyd wrote:
> >> (Sorry, this discussion stalled due to merge window + life events)
> >
> >
On Tue, Feb 25, 2014 at 08:48:38PM +, Kumar Gala wrote:
On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com
wrote:
Hi Stephen,
On Wed, Feb 19, 2014 at 12:20:43AM +, Stephen Boyd wrote:
(Sorry, this discussion stalled due to merge window + life events)
On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi
wrote:
> Hi Stephen,
>
> On Wed, Feb 19, 2014 at 12:20:43AM +, Stephen Boyd wrote:
>> (Sorry, this discussion stalled due to merge window + life events)
>
> Sorry for the delay in replying on my side too.
>
>> On 01/17, Lorenzo Pieralisi
Hi Stephen,
On Wed, Feb 19, 2014 at 12:20:43AM +, Stephen Boyd wrote:
> (Sorry, this discussion stalled due to merge window + life events)
Sorry for the delay in replying on my side too.
> On 01/17, Lorenzo Pieralisi wrote:
> > On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
>
Hi Stephen,
On Wed, Feb 19, 2014 at 12:20:43AM +, Stephen Boyd wrote:
(Sorry, this discussion stalled due to merge window + life events)
Sorry for the delay in replying on my side too.
On 01/17, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
On
On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi lorenzo.pieral...@arm.com
wrote:
Hi Stephen,
On Wed, Feb 19, 2014 at 12:20:43AM +, Stephen Boyd wrote:
(Sorry, this discussion stalled due to merge window + life events)
Sorry for the delay in replying on my side too.
On 01/17,
(Sorry, this discussion stalled due to merge window + life events)
On 01/17, Lorenzo Pieralisi wrote:
> On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
> > On 01/16, Lorenzo Pieralisi wrote:
> > > On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
> > > > On 01/16,
(Sorry, this discussion stalled due to merge window + life events)
On 01/17, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
On 01/16, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
On 01/16, Lorenzo
On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
> On 01/16, Lorenzo Pieralisi wrote:
> > On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
> > > On 01/16, Lorenzo Pieralisi wrote:
> > > > Do we really want to do that ? I am not sure. A cpus node is supposed to
> > > > be
On Thu, Jan 16, 2014 at 07:26:17PM +, Stephen Boyd wrote:
On 01/16, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
On 01/16, Lorenzo Pieralisi wrote:
Do we really want to do that ? I am not sure. A cpus node is supposed to
be a container
On 01/16, Lorenzo Pieralisi wrote:
> On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
> > On 01/16, Lorenzo Pieralisi wrote:
> > > Do we really want to do that ? I am not sure. A cpus node is supposed to
> > > be a container node, we should not define this binding just because we
> >
On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
> On 01/16, Lorenzo Pieralisi wrote:
> > On Thu, Jan 16, 2014 at 01:38:40AM +, Stephen Boyd wrote:
> > > On 01/15, Stephen Boyd wrote:
> > > >
> > > > Ah sorry, I forgot to put the compatible property here like in
> > > > the dts
On 01/16, Lorenzo Pieralisi wrote:
> On Thu, Jan 16, 2014 at 01:38:40AM +, Stephen Boyd wrote:
> > On 01/15, Stephen Boyd wrote:
> > >
> > > Ah sorry, I forgot to put the compatible property here like in
> > > the dts change. I'll do that in the next revision. Yes we need a
> > > compatible
On Thu, Jan 16, 2014 at 01:38:40AM +, Stephen Boyd wrote:
> On 01/15, Stephen Boyd wrote:
> >
> > Ah sorry, I forgot to put the compatible property here like in
> > the dts change. I'll do that in the next revision. Yes we need a
> > compatible property here to match the platform driver.
> >
On Thu, Jan 16, 2014 at 01:38:40AM +, Stephen Boyd wrote:
On 01/15, Stephen Boyd wrote:
Ah sorry, I forgot to put the compatible property here like in
the dts change. I'll do that in the next revision. Yes we need a
compatible property here to match the platform driver.
This is
On 01/16, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 01:38:40AM +, Stephen Boyd wrote:
On 01/15, Stephen Boyd wrote:
Ah sorry, I forgot to put the compatible property here like in
the dts change. I'll do that in the next revision. Yes we need a
compatible property here to
On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
On 01/16, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 01:38:40AM +, Stephen Boyd wrote:
On 01/15, Stephen Boyd wrote:
Ah sorry, I forgot to put the compatible property here like in
the dts change. I'll do
On 01/16, Lorenzo Pieralisi wrote:
On Thu, Jan 16, 2014 at 06:05:05PM +, Stephen Boyd wrote:
On 01/16, Lorenzo Pieralisi wrote:
Do we really want to do that ? I am not sure. A cpus node is supposed to
be a container node, we should not define this binding just because we
know the
On 01/15, Stephen Boyd wrote:
>
> Ah sorry, I forgot to put the compatible property here like in
> the dts change. I'll do that in the next revision. Yes we need a
> compatible property here to match the platform driver.
>
This is the replacement patch
-8<--
From: Stephen Boyd
On 01/15, Lorenzo Pieralisi wrote:
> On Tue, Jan 14, 2014 at 09:30:32PM +, Stephen Boyd wrote:
> > The Krait CPU/L1 error reporting device is made up a per-CPU
> > interrupt. While we're here, document the next-level-cache
> > property that's used by the Krait EDAC driver.
> >
> > Cc: Lorenzo
On Tue, Jan 14, 2014 at 09:30:32PM +, Stephen Boyd wrote:
> The Krait CPU/L1 error reporting device is made up a per-CPU
> interrupt. While we're here, document the next-level-cache
> property that's used by the Krait EDAC driver.
>
> Cc: Lorenzo Pieralisi
> Cc: Mark Rutland
> Cc: Kumar
On Tue, Jan 14, 2014 at 09:30:32PM +, Stephen Boyd wrote:
The Krait CPU/L1 error reporting device is made up a per-CPU
interrupt. While we're here, document the next-level-cache
property that's used by the Krait EDAC driver.
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Mark
On 01/15, Lorenzo Pieralisi wrote:
On Tue, Jan 14, 2014 at 09:30:32PM +, Stephen Boyd wrote:
The Krait CPU/L1 error reporting device is made up a per-CPU
interrupt. While we're here, document the next-level-cache
property that's used by the Krait EDAC driver.
Cc: Lorenzo Pieralisi
On 01/15, Stephen Boyd wrote:
Ah sorry, I forgot to put the compatible property here like in
the dts change. I'll do that in the next revision. Yes we need a
compatible property here to match the platform driver.
This is the replacement patch
-8--
From: Stephen Boyd
The Krait CPU/L1 error reporting device is made up a per-CPU
interrupt. While we're here, document the next-level-cache
property that's used by the Krait EDAC driver.
Cc: Lorenzo Pieralisi
Cc: Mark Rutland
Cc: Kumar Gala
Cc:
Signed-off-by: Stephen Boyd
---
The Krait CPU/L1 error reporting device is made up a per-CPU
interrupt. While we're here, document the next-level-cache
property that's used by the Krait EDAC driver.
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Kumar Gala ga...@codeaurora.org
Cc:
32 matches
Mail list logo
