Re: 83xx GPIO/EXT int in arch/powerpc/

quoted

  - You can do it in your interrupt-map. That's probably the cleanest

quoted

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.

I disagree :-)

I think you didn't notice that I was talking about
pretending the IRQ signal of a device on PCI bus #1
being routed through PCI bus #0, the grandparent bus
of the device instead of the parent bus.  If it were
about the direct parent bus than anything could be
handled with an interrupt-map just fine, in the current
situation it is just ugly and wrong and it cannot work
in slightly more general situations, either.

The interrupt-map simply provides for each slot where the interrupt
goes. It's perfectly fine and clean to use it when those interrupts are
hooked to GPIOs and has been a common practice. I really don't see a
problem with that.

You shouldn't map interrupts from devices on your
children's busses, that's the problem.

quoted

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.

Not really again. Besides, devices normally use only int#A, only 
bridges
use more.

Again, in the case under discussion, PCI bus# needs to
be part of the map-mask, and you can't do swizzling (or
a simple direct translation, whatever is appropriate)
for the bus-bus connection -- you have to spell out every
source deep down the domain.

Segher, I feel here that your inability to resist arguing about
everything in that case is confusing what is a fairly simple issue in
the first place :-)

It isn't simple.  It is also wrong.  If a bus does
not deliver interrupts from its children to its
parent, than the device tree should not pretend it
does.

Poor guy trying to figure out the right way to do
his stuff will run away screaming and go back hard coding his number in
his platform code before we are finished :-)

Heh I hope not.

So I would say, taking a dicator hat, that the right way to fix his
problem is also the simplest, which is to make sure the interrupt-map
entry for that slot points to the right GPIO interrupt :-)

It's wrong and not simple.  Let me show you with some
pictures.  A device X on PCI bus P1, interrupt goes
straight to interrupt controller I.

Here's what you say is right:

P0      interrupt-map < ...reg 19000 irq IRQ -> I... >
|
P1
|
X@12    reg <19000>
         interrupt-parent <P0>
         interrupt <IRQ>

And here is my version:

P0
|
P1      interrupt-map < ... reg 9000 irq IRQ -> I ... >
|
X@12    reg <19000>
         interrupt-parent <P0>
         interrupt <IRQ>

Easy isn't it ?

Yes, it's only hard if you're trying to avoid doing
mapping properties where they are necessary, including
stand-alone interrupt nexus nodes (not needed in this
case btw, not needed most simple cases).


Segher