* Adam Ford <aford173@xxxxxxxxx> [181227 14:33]: > On Sun, Dec 23, 2018 at 10:30 AM Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > > * Adam Ford <aford173@xxxxxxxxx> [181222 20:54]: > > > I noticed for your patch, I noticed you listed both the IRQ, gpio 149 > > > as well as uart1_rts. Looking at the device tree, I see that > > > uart1_rts is configured as gpio 149. > > > > The uart1_rts is just the pad name used in the TRM, so it should > > probably say uart1_rts.gpio_149 meaning pad uart1_rts is muxed to > > gpio_149. > > > > Would that clear the issue for you? > > That part I understand. I poorly phrased my question. What was > mostly confusing to me is why both irq and wakeup interrupts are > needed since it seems like > > <&gpio5 21 IRQ_TYPE_EDGE_RISING>, > > and > <&omap3_pmx_core 0x14e>; > point to the same pin. Or did I mis-interpret the datasheet again? :-) Ah OK. Yes the same pin can trigger interrupts at two different controllers. During runtime a proper GPIO is triggered, and then in deeper idle states only the padconf interrupt is triggered as the GPIO can be powered off. So the padconf interrupt is there to provide wake-up events if configured. This allows the device to enter off-mode during idle with things like ping and ssh working with some extra latency :) The padconf interrupt can also be something other than a GPIO pin, such as UART RX pin, and the padconf device is separate from the GPIO device. So they're treated as two separate interrupt controllers. They can be both active the same time although that is undesired for the extra overhead. Eventually we should be able to make the GPIO interrupts work in a transparent way with the padconf interrupts. Regards, Tony
