From: Segher Boessenkool <segher@kernel.crashing.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
Stuart Yoder <b08248@freescale.com>
Subject: Re: [PATCH] powerpc: document new interrupt-array property
Date: Thu, 22 Feb 2007 12:06:09 +0100 [thread overview]
Message-ID: <b16b3a03ce9b890909b3f64f50e78b75@kernel.crashing.org> (raw)
In-Reply-To: <20070222103410.GB11014@localhost.localdomain>
>> Not really a hack, this is documented in the interrupt
>> binding:
>
> No, it really is a hack, I'm afraid. interrupt-map doesn't in general
> make sense for mapping interrupt-children which are not physical
> children. Why? Because the interrupt map includes unit specifiers,
> which means the expected addressing format in the interrupt map must
> match that of the reg property in every node mapped through it.
Hrm I guess I misunderstood the way you do things now.
Could you give an example? I'm too lazy to look up
the DTS file :-)
> We get away with it in this case because we ignore the unit specifier
> part,
That's perfectly fine for many interrupt maps.
> and the kernel parser happens to use the interrupt parent's
> #address-cells value, rather than the physical parent's.
For the child interrupt specifiers, the "#address-cells"
value in the node containing the "interrupt-map" itself
should be used. For the parent interrupt specifier, the
"#address-cells" value in whatever node the "interrupt-map"
for the matching entry points to should be used.
It sounds like the kernel does the right thing here?
[Of course the #a value better be the same as the value
in the physical parent, and all nodes mapping via a
particular "interrupt-map" better have unique unit
address for that map].
>>> 3.3. "interrupt-map" property
>>> At any level in the interrupt tree, a mapping may need to take
>>> place between the child interrupt domain and the parent=92s. This
>>> is represented by a new property called "interrupt-map".
>>
>> Note it says "*any* level".
>
> We could do this properly via an interrupt map by placing the MAL
> under a MAL-interrupt-nexus node, which exists to do nothing but remap
> the interrupts. That's pretty horrible, though.
It doesn't have to physically be under there, only in the
*interrupt* tree. This situation isn't specific to your
situation; it happens in other cases with weird wiring
too.
>> As an added bonus you end up
>> with one single namespace for the interrupts (one interrupt
>> domain in interrupt-mapping speak), which is probably what
>> the chip documentation does as well.
>
> No, actually. Afaict for the 4xx chips, the user manuals just give
> the interrupt mapping in tables in the the chapter on the interrupt
> controllers. There's a separate table, with separate interrupt
> numbers for each UIC.
Oh okay.
Segher
next prev parent reply other threads:[~2007-02-22 13:40 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-21 23:25 [PATCH] powerpc: document new interrupt-array property Stuart Yoder
2007-02-22 0:29 ` Kumar Gala
2007-02-22 1:18 ` David Gibson
2007-02-22 7:01 ` Segher Boessenkool
2007-02-22 10:34 ` David Gibson
2007-02-22 11:06 ` Segher Boessenkool [this message]
2007-02-22 15:47 ` Yoder Stuart-B08248
2007-02-22 17:09 ` Segher Boessenkool
2007-02-23 19:15 ` Yoder Stuart-B08248
2007-02-23 21:30 ` Segher Boessenkool
2007-02-23 21:57 ` Yoder Stuart-B08248
2007-02-23 22:30 ` Segher Boessenkool
2007-02-24 6:42 ` Benjamin Herrenschmidt
2007-02-24 6:40 ` Benjamin Herrenschmidt
2007-02-24 11:24 ` Segher Boessenkool
2007-02-26 4:16 ` David Gibson
2007-02-26 5:36 ` Segher Boessenkool
2007-02-26 13:08 ` David Gibson
2007-02-26 14:26 ` Segher Boessenkool
2007-02-27 2:32 ` David Gibson
2007-02-27 2:52 ` Segher Boessenkool
2007-02-27 3:45 ` David Gibson
2007-02-27 11:49 ` Segher Boessenkool
2007-02-28 0:40 ` David Gibson
2007-02-28 1:00 ` Segher Boessenkool
2007-02-28 6:40 ` Benjamin Herrenschmidt
2007-02-26 16:53 ` Yoder Stuart-B08248
2007-02-22 22:57 ` David Gibson
2007-02-23 0:07 ` Segher Boessenkool
2007-02-23 0:33 ` David Gibson
2007-02-23 0:50 ` Segher Boessenkool
2007-02-23 16:07 ` Yoder Stuart-B08248
2007-02-23 16:14 ` Kumar Gala
2007-02-23 17:00 ` Segher Boessenkool
2007-02-23 16:55 ` Segher Boessenkool
2007-02-23 17:01 ` Yoder Stuart-B08248
2007-02-23 17:51 ` Segher Boessenkool
2007-02-22 22:48 ` David Gibson
2007-02-23 0:25 ` Segher Boessenkool
2007-02-24 6:30 ` Benjamin Herrenschmidt
2007-02-24 11:16 ` Segher Boessenkool
2007-02-22 7:19 ` Segher Boessenkool
2007-02-24 6:35 ` Benjamin Herrenschmidt
2007-02-24 11:11 ` Segher Boessenkool
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=b16b3a03ce9b890909b3f64f50e78b75@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=b08248@freescale.com \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.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.