linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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).