All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.