* Ben Tucker <benjamint@xxxxxxxxxxx> [151009 10:27]:
> On Fri, Oct 09, 2015 at 09:16:28AM -0700, Tony Lindgren wrote:
> >
> > Hmm so what's the use case for PIN_OFF_INPUT* then?
> On the face of it if the peripheral behind the pin is powered off which
> will be the case when we have powered the domains off, then it cannot
> process any input values.
>
> However there are two uses for input off mode I can think of:
>
> 1- the pin is not connected, in which case you want to make it an input
> so that there is no driver enabled for it. I am guessing this would save
> a little power even though the pin has no load. Note an internal pull
> resister should be enabled in this case to avoid the pin acting like a
> aerial and switching internal logic, which again would be a source of
> power draw.
> (Having just read the TRM, I see that the safe-mode can be used for most
> N/C pins)
Right.. So that has not been used again.
> 2- we want to enable a wakeup of the system on the pin
For the IO chain wake-up PIN_OFF_INPUT is not needed either..
FYI, the IO chain wake-up can be done just by enabling the WAKEUPENABLE
bit for the pin. All that's now automatically handled with the Linux
generic dedicated wakeirq. For the serial drivers all you need to do
is specify is something like what we do in omap3-beagle-xm.dts for
example:
&uart3 {
interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>;
pinctrl-names = "default";
pinctrl-0 = <&uart3_pins>;
};
> Something else you may want to look out for is the fact that the omap4
> mux config is has the same active low OFFOUTENABLE as omap3. I do not
> know if the same problem exists in the omap4 mux control code. I do not
> think it is shared with the omap3 mux control code.
> (Just my 2p worth)
And we also need to update include/dt-bindings/pinctrl/omap.h too.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
