Re: Does gpio_to_irq() work for MPC52xx gpios?

[Bill Gatliff <bgat@billgatliff.com>]

Guys:


Ok, I have gpio_to_irq() more-or-less showing signs of life for the
MPC5200.  But I'm having some trouble using it the way I want to.

Recall that I have a rotary encoder that's tied to IRQ2 and
GPIO_WKUP_7.  I want to be able to describe it something like this:

    rotary-encoder {
        compatible = "linux,rotary-encoder","rotary-encoder";
        interrupts = <&mpc5200_pic 2 3 &gpio_wkup 0 1>; // "IRQ2 on the
MPC5200 PIC,
                                                                                               
// and pin 0 on GPIO_WKUP"
        type = <1>; // what event signal to generate
        val-ccw = <0x4a>; // what code to use for counter-clockwise rotation
        val-cw = <78>; // what code to use for clockwise rotation
    };

I've had some limited success with this, but not for any good reason. 
It turns out that the explanation for why I was getting a valid number
for the first interrupt specification was because the device tree
compiler was assuming that the interrupt-parent was the mpc5200_pic; my
reference to the node in that list was utterly meaningless.  The dtc
also appears to have ignored the &gpio_wkup word, and interpreted the
following zero as being the zero-th interrupt channel in the
mpc5200_pic.  Or something like that.  Clearly, I don't understand the
device tree syntax at all yet.

Anyway, when I change the statement to this:

    rotary-encoder {
        compatible = "linux,rotary-encoder","rotary-encoder";
        interrupt-parent = <&gpio_wkup>;
        interrupts = <0 0>;
        type = <1>;
        val-ccw = <0x4a>;
        val-cw = <78>;
        };

... then the magic number that the dtc comes up with is causing my new
chained interrupt handler for the gpio_wkup peripheral to come alive. 
(Of course it doesn't actually work yet, but that's not the point!)

So here's my question: does the device tree compiler/syntax limit you to
only one interrupt parent?

I think the answer is no, because what I'm trying to do doesn't seem
that much different from how one specifies GPIO pins coming from
different controllers.

Any suggestions?


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com