Question on MPC52xx IRQ[123] pins

Question on MPC52xx IRQ[123] pins

[Bill Gatliff]

Guys:


I think I already know the answer to this, having read most of the
MPC52xx manual.  But I'll ask anyway, just to be sure I'm not missing
something obvious...  :)

Is it possible to treat the external IRQ[123] pins on the MPC52xx as
GPIO inputs?  And if so, how do I tweak my dts file and other code, if
necessary, to make that happen?

Reason I ask is, I'm trying to enhance
drivers/input/misc/rotary-encoder.c to use device trees, and one of the
encoder inputs is on IRQ2.  My strategy so far is to just provide an
of_probe() function that builds a rotary_encoder_platform_data structure
and then calls platform_device_register().  And that ain't working.  :)

First off, the rotary-encoder driver assumes that both of its inputs are
both known to gpiolib, so that they can do both gpio_to_irq() and
gpio_get_value() on them.  There isn't any existing code that I can find
that allows you to read the states of IRQ pins, be it under gpiolib or
otherwise.  And I think the reason for that is that there's no way to
actually read the states of those pins at all--- the hardware just
doesn't work that way.

Or am I missing something?

Second, if I get all this working then my rotary encoders won't be
platform devices--- they'll be openfirmware devices, which means I'll
have to do other work in the code as well.  That's a subtle point I
know, but rotary-encoder's assumption that all rotary encoder devices
are also platform devices is kind of like mixing policy with
implementation, it turns out.  Almost like trying to reuse a PCI driver
as a platform driver.  I didn't spot how important that was until I
started hacking on the code itself...



Thanks!


b.g.

-- 
Bill Gatliff
bgat@billgatliff.com

Re: Question on MPC52xx IRQ[123] pins

[Grant Likely]

On Mon, Dec 21, 2009 at 3:30 PM, Bill Gatliff <bgat@billgatliff.com> wrote:
> gpio_get_value() on them. =A0There isn't any existing code that I can fin=
d
> that allows you to read the states of IRQ pins, be it under gpiolib or
> otherwise. =A0And I think the reason for that is that there's no way to
> actually read the states of those pins at all--- the hardware just
> doesn't work that way.

Correct.  IRQ2 can only be used as IRQ2.  It cannot be used a GPIO.
(Well, I suppose you *could* try to hack into the interrupt controller
driver and fetch the pin state that way; but I don't know if you can
read the state of masked out IRQ pins, and it sure would be ugly.)

g.

--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Question on MPC52xx IRQ[123] pins

[Bill Gatliff]

Grant Likely wrote:
> Correct.  IRQ2 can only be used as IRQ2.  It cannot be used a GPIO.
> (Well, I suppose you *could* try to hack into the interrupt controller
> driver and fetch the pin state that way; but I don't know if you can
> read the state of masked out IRQ pins, and it sure would be ugly.)
>   

Actually, I did think of a way you could do this.  You could register an
interrupt handler on the line, and set the irq type to level-low or
level-high.  Depending on whether the handler fires right away, you know
what the state of the pin must be.  And when the interrupt handler does
fire, you switch the irq type to the opposite setting.

I think that approach rates pretty high on the "ugly scale" too, but
perhaps tolerably so.  In fact, were I to actually need to interface one
of the IRQ lines to gpiolib, I might attempt this...


b.g.

-- 
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com