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 b...@billgatliff.com _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev