From: Segher Boessenkool <segher@kernel.crashing.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 83xx GPIO/EXT int in arch/powerpc/
Date: Wed, 6 Jun 2007 11:47:42 +0200 [thread overview]
Message-ID: <3641c2a601dbccc9757fe9443d9330ca@kernel.crashing.org> (raw)
In-Reply-To: <1181113438.31677.234.camel@localhost.localdomain>
> In addition, linux always reserve numbers 0...15. 0 is
> always illegal and 1..15 can only be mapped to a 8259 type legacy ISA
> controller. This is to avoid problem with stupid drivers from the x86
> world.
Of course, it doesn't help if you have an i8259 but have
non-legacy-PC devices on it. Oh the horror!
> Now, there is no automagic way of setting up GPIOs. You have to
> manually
> (from your firmware that is, or maybe from your platform code),
> configure the appropriate GPIO to the appropriate HW irq source on the
> IPIC that matches what you put in your DTS.
It *really* shouldn't be Linux platform code, if you can
avoid it at all. It's just more trouble than it's worth.
> - You can create a device-node for the PCI device. PCI devices
> normally, in linux, don't need to have device-nodes in the DTS, at
> least
> it's not mandatory, but you -can- do it. If your node has the correct
> "reg" property,
What is "correct" in this case? We probably should describe
what properties are required in a (non-phb) pci node for
platforms that don't use the device tree for probing PCI.
In this specific case, do you only need the configuration
address in the "reg"?
> it should be matches by the linux parser, and thus you
> have the ability to put an interrupts property in there. It would
> normally be a PCI interrupt specification, but you can specify
> explicitely an interrupt parent that points to the IPIC and thus have
> an
> interrupt pointing directly there. That's the example that, I think,
> Andy gave you
Yeah.
> - You can do it in your interrupt-map. That's probably the cleanest
> way
> to do it.
Not really. If the device interrupt is physically connected
directly to a GPIO or a PIC or whatever, if it doesn't go
through the PCI bus; then it shouldn't be represented in
the device tree as if it did. The higher-up bridge has
nothing whatsoever to do with this device's interrupt.
It's a simple hack of course, it can be useful sometimes.
It's not "clean" at all however.
> Just make sure you have
> an entry there for your device pin A dev/fn whose specification points
> to the IPIC with the appropriate IRQ number and that should work fine.
Depending on the rest of the tree, this would often mean
you have to do a much bigger interrupt-map-mask than
without this hack, and the corresponding explosion in
interrupt-map size.
> Now, that's assuming GPIOs, when used as external interrupts, are
> directly routed to the IPIC. I don't know the 83xx so I just assumed
> it :-)
Almost always that's how it works yeah. And the "GPIO"
stage isn't normally represented in the device tree, GPIO
settings are considered a part of the PCB layout ;-) (one
more reason why Linux shouldn't have to touch it).
> If that's not the case, you may need some intermediary cascaded
> interrupt controller or something around those lines.
Yeah, but that's just the more general case of the
general case :-)
Segher
next prev parent reply other threads:[~2007-06-06 9:47 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-04 9:56 83xx GPIO/EXT int in arch/powerpc/ Marc Leeman
2007-06-04 19:25 ` Andy Fleming
2007-06-04 19:35 ` Segher Boessenkool
2007-06-04 21:17 ` Marc Leeman
2007-06-04 21:57 ` Andy Fleming
2007-06-05 10:13 ` Segher Boessenkool
2007-06-06 7:03 ` Benjamin Herrenschmidt
2007-06-06 9:47 ` Segher Boessenkool [this message]
2007-06-06 22:31 ` Benjamin Herrenschmidt
2007-06-07 12:55 ` Segher Boessenkool
2007-06-11 16:21 ` Marc Leeman
2007-06-12 13:31 ` Kumar Gala
2007-06-12 16:06 ` Marc Leeman
2007-06-14 21:04 ` Kumar Gala
2007-06-15 8:12 ` Marc Leeman
2007-06-05 10:12 ` 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=3641c2a601dbccc9757fe9443d9330ca@kernel.crashing.org \
--to=segher@kernel.crashing.org \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).