From: Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 4/6] edac: Document Krait L1/L2 EDAC driver binding
Date: Thu, 31 Oct 2013 10:30:47 -0700 [thread overview]
Message-ID: <20131031173047.GK21983@codeaurora.org> (raw)
In-Reply-To: <D081E03B-01D6-497F-B8D0-E994219C8282-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On 10/30, Kumar Gala wrote:
>
> On Oct 30, 2013, at 4:58 PM, Stephen Boyd wrote:
>
> > On 10/30/13 14:56, Kumar Gala wrote:
> >> On Oct 30, 2013, at 4:48 PM, Stephen Boyd wrote:
> >>
> >>> On 10/30/13 14:45, Kumar Gala wrote:
> >>>> On Oct 30, 2013, at 3:25 PM, Stephen Boyd wrote:
> >>>>> +l2-cache node containing the following properties:
> >>>> Is the L1 interrupt not per core L1 cache (even if they are OR together at PIC)?
> >>> Yes it is per CPU. That is what the 0xf part of the cpus interrupts
> >>> property is showing.
> >> Than why not have it in each cpu node?
> >
> > Because that duplicates things unnecessarily? The cpus node can hold
> > things that are common to all CPUs to avoid duplication. If it was a
> > different PPI for each CPU then I would agree that we need to put it in
> > each cpu node.
>
> Ok, I'll accept that as the binding is specific to Krait (and I assume all SoCs w/Krait wire this up to a common interrupt)
>
Can I take that as an ack? I'll resend with the s/an/a/ fix
today.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/6] edac: Document Krait L1/L2 EDAC driver binding
Date: Thu, 31 Oct 2013 10:30:47 -0700 [thread overview]
Message-ID: <20131031173047.GK21983@codeaurora.org> (raw)
In-Reply-To: <D081E03B-01D6-497F-B8D0-E994219C8282@codeaurora.org>
On 10/30, Kumar Gala wrote:
>
> On Oct 30, 2013, at 4:58 PM, Stephen Boyd wrote:
>
> > On 10/30/13 14:56, Kumar Gala wrote:
> >> On Oct 30, 2013, at 4:48 PM, Stephen Boyd wrote:
> >>
> >>> On 10/30/13 14:45, Kumar Gala wrote:
> >>>> On Oct 30, 2013, at 3:25 PM, Stephen Boyd wrote:
> >>>>> +l2-cache node containing the following properties:
> >>>> Is the L1 interrupt not per core L1 cache (even if they are OR together at PIC)?
> >>> Yes it is per CPU. That is what the 0xf part of the cpus interrupts
> >>> property is showing.
> >> Than why not have it in each cpu node?
> >
> > Because that duplicates things unnecessarily? The cpus node can hold
> > things that are common to all CPUs to avoid duplication. If it was a
> > different PPI for each CPU then I would agree that we need to put it in
> > each cpu node.
>
> Ok, I'll accept that as the binding is specific to Krait (and I assume all SoCs w/Krait wire this up to a common interrupt)
>
Can I take that as an ack? I'll resend with the s/an/a/ fix
today.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Kumar Gala <galak@codeaurora.org>
Cc: linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2 4/6] edac: Document Krait L1/L2 EDAC driver binding
Date: Thu, 31 Oct 2013 10:30:47 -0700 [thread overview]
Message-ID: <20131031173047.GK21983@codeaurora.org> (raw)
In-Reply-To: <D081E03B-01D6-497F-B8D0-E994219C8282@codeaurora.org>
On 10/30, Kumar Gala wrote:
>
> On Oct 30, 2013, at 4:58 PM, Stephen Boyd wrote:
>
> > On 10/30/13 14:56, Kumar Gala wrote:
> >> On Oct 30, 2013, at 4:48 PM, Stephen Boyd wrote:
> >>
> >>> On 10/30/13 14:45, Kumar Gala wrote:
> >>>> On Oct 30, 2013, at 3:25 PM, Stephen Boyd wrote:
> >>>>> +l2-cache node containing the following properties:
> >>>> Is the L1 interrupt not per core L1 cache (even if they are OR together at PIC)?
> >>> Yes it is per CPU. That is what the 0xf part of the cpus interrupts
> >>> property is showing.
> >> Than why not have it in each cpu node?
> >
> > Because that duplicates things unnecessarily? The cpus node can hold
> > things that are common to all CPUs to avoid duplication. If it was a
> > different PPI for each CPU then I would agree that we need to put it in
> > each cpu node.
>
> Ok, I'll accept that as the binding is specific to Krait (and I assume all SoCs w/Krait wire this up to a common interrupt)
>
Can I take that as an ack? I'll resend with the s/an/a/ fix
today.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-10-31 17:30 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-30 20:25 [PATCH v2 0/6] Krait L1/L2 EDAC driver Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` [PATCH v2 1/6] edac: Don't try to cancel workqueue when it's never setup Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` [PATCH v2 2/6] genirq: export percpu irq functions for module usage Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` [PATCH v2 3/6] ARM: Add Krait L2 accessor functions Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` [PATCH v2 4/6] edac: Document Krait L1/L2 EDAC driver binding Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 21:45 ` Kumar Gala
2013-10-30 21:45 ` Kumar Gala
2013-10-30 21:45 ` Kumar Gala
2013-10-30 21:48 ` Stephen Boyd
2013-10-30 21:48 ` Stephen Boyd
2013-10-30 21:48 ` Stephen Boyd
2013-10-30 21:56 ` Kumar Gala
2013-10-30 21:56 ` Kumar Gala
2013-10-30 21:58 ` Stephen Boyd
2013-10-30 21:58 ` Stephen Boyd
2013-10-30 22:02 ` Kumar Gala
2013-10-30 22:02 ` Kumar Gala
[not found] ` <D081E03B-01D6-497F-B8D0-E994219C8282-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-10-31 17:30 ` Stephen Boyd [this message]
2013-10-31 17:30 ` Stephen Boyd
2013-10-31 17:30 ` Stephen Boyd
2013-10-31 17:44 ` Kumar Gala
2013-10-31 17:44 ` Kumar Gala
2013-10-30 20:25 ` [PATCH v2 5/6] edac: Add support for Krait CPU cache error detection Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:25 ` [PATCH v2 6/6] ARM: dts: msm: Add Krait CPU/L2 nodes Stephen Boyd
2013-10-30 20:25 ` Stephen Boyd
2013-10-30 20:27 ` David Brown
2013-10-30 20:27 ` David Brown
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=20131031173047.GK21983@codeaurora.org \
--to=sboyd-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-edac-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.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.