From: Scott Wood <scottwood@freescale.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Detlev Zundel <dzu@denx.de>,
Markus Fischer <markus.fischer.ec@ifm.com>,
devicetree-discuss@lists.ozlabs.org,
Michael Weiss <michael.weiss@ifm.com>,
linuxppc-dev@ozlabs.org, Anatolij Gustschin <agust@denx.de>,
Wolfgang Grandegger <wg@denx.de>
Subject: Re: [PATCH 2/2] powerpc/mpc5121: add initial support for PDM360NG board
Date: Tue, 22 Jun 2010 16:39:38 -0500 [thread overview]
Message-ID: <4C212D9A.5020908@freescale.com> (raw)
In-Reply-To: <AANLkTinxuFz3SSLZtF3yGYtRN8nsW8_6EDiqzmJilYE9@mail.gmail.com>
On 05/19/2010 04:47 PM, Grant Likely wrote:
> On Wed, May 19, 2010 at 3:37 PM, Scott Wood<scottwood@freescale.com> wrote:
>> I believe the only part of this that is new with ePAPR is that it asks that
>> the interrupt controller address cells be explicitly specified, as it's a
>> bit icky for it to default to 2 in some contexts and 0 in others.
>
> Hmmm. I've not seen that before. On the 5200 the value of
> #address-cells for interrupt controllers has apparently defaulted to
> <0> so I've never encountered or thought about it. I'm not even sure
> what #address-cells != 0 would mean in the context of interrupt
> mapping, or where it would be relevant.
The address component is mainly used in PCI interrupt mapping, where
each slot has a distinct wiring.
It would be weird to see it on a normal interrupt controller, but
explicitly setting it to zero helps avoid someone deciding that an
interrupt controller ought to have a child node for whatever reason
(this was an issue with MPIC), setting address cells to something
non-zero, and messing up interrupt maps.
-Scott
WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: Detlev Zundel <dzu-ynQEQJNshbs@public.gmane.org>,
Markus Fischer <markus.fischer.ec-Jj5Fu8i2Z9Q@public.gmane.org>,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Michael Weiss <michael.weiss-Jj5Fu8i2Z9Q@public.gmane.org>,
linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
Wolfgang Grandegger <wg-ynQEQJNshbs@public.gmane.org>
Subject: Re: [PATCH 2/2] powerpc/mpc5121: add initial support for PDM360NG board
Date: Tue, 22 Jun 2010 16:39:38 -0500 [thread overview]
Message-ID: <4C212D9A.5020908@freescale.com> (raw)
In-Reply-To: <AANLkTinxuFz3SSLZtF3yGYtRN8nsW8_6EDiqzmJilYE9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/19/2010 04:47 PM, Grant Likely wrote:
> On Wed, May 19, 2010 at 3:37 PM, Scott Wood<scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> I believe the only part of this that is new with ePAPR is that it asks that
>> the interrupt controller address cells be explicitly specified, as it's a
>> bit icky for it to default to 2 in some contexts and 0 in others.
>
> Hmmm. I've not seen that before. On the 5200 the value of
> #address-cells for interrupt controllers has apparently defaulted to
> <0> so I've never encountered or thought about it. I'm not even sure
> what #address-cells != 0 would mean in the context of interrupt
> mapping, or where it would be relevant.
The address component is mainly used in PCI interrupt mapping, where
each slot has a distinct wiring.
It would be weird to see it on a normal interrupt controller, but
explicitly setting it to zero helps avoid someone deciding that an
interrupt controller ought to have a child node for whatever reason
(this was an issue with MPIC), setting address cells to something
non-zero, and messing up interrupt maps.
-Scott
next prev parent reply other threads:[~2010-06-22 21:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 20:30 [PATCH 1/2] powerpc/mpc512x: Group mpc512x board's selection menu Anatolij Gustschin
2010-04-30 20:30 ` [PATCH 2/2] powerpc/mpc5121: add initial support for PDM360NG board Anatolij Gustschin
2010-04-30 20:30 ` Anatolij Gustschin
2010-05-02 14:54 ` Grant Likely
2010-05-02 14:54 ` Grant Likely
2010-05-03 9:22 ` Anatolij Gustschin
2010-05-03 9:22 ` Anatolij Gustschin
2010-05-03 16:34 ` Scott Wood
2010-05-03 16:34 ` Scott Wood
2010-05-19 21:27 ` Grant Likely
2010-05-19 21:27 ` Grant Likely
2010-05-19 21:37 ` Scott Wood
2010-05-19 21:47 ` Grant Likely
2010-05-19 21:47 ` Grant Likely
2010-06-22 21:39 ` Scott Wood [this message]
2010-06-22 21:39 ` Scott Wood
2010-05-03 10:23 ` [PATCH v2 " Anatolij Gustschin
2010-05-03 10:23 ` Anatolij Gustschin
2010-07-23 13:49 ` [PATCH v3 " Anatolij Gustschin
2010-07-23 13:49 ` Anatolij Gustschin
2010-07-25 7:42 ` Grant Likely
2010-07-25 7:42 ` Grant Likely
2010-07-27 10:36 ` Anatolij Gustschin
2010-07-27 10:36 ` Anatolij Gustschin
2010-07-27 16:58 ` Grant Likely
2010-07-27 16:58 ` Grant Likely
2010-07-27 17:28 ` Anatolij Gustschin
2010-07-27 17:28 ` Anatolij Gustschin
2010-07-27 17:43 ` Grant Likely
2010-07-27 17:43 ` Grant Likely
2010-07-27 21:26 ` [PATCH v4 " Anatolij Gustschin
2010-07-27 21:26 ` Anatolij Gustschin
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=4C212D9A.5020908@freescale.com \
--to=scottwood@freescale.com \
--cc=agust@denx.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dzu@denx.de \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.org \
--cc=markus.fischer.ec@ifm.com \
--cc=michael.weiss@ifm.com \
--cc=wg@denx.de \
/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.