Thread (44 messages) 44 messages, 3 authors, 2016-04-11

N900 sleep mode (in 4.5-rc0, if that matters)

From: tony@atomide.com (Tony Lindgren)
Date: 2016-01-25 22:50:32
Also in: linux-omap, lkml

* Pavel Machek [off-list ref] [160125 14:24]:
Hi!

First, thanks for the help!
quoted
quoted
So far, the LEDs stubbornly stay on :-(. Machine is booted off
sd-card, and I'm connected to it over wifi. GSM is active, X is
running.
If LEDs stay on, you're not entering deeper idle states.
Yes... Strange thing is, I'm not entering deeper idle states, and it still breaks my wifi ;-).
quoted
quoted
64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms
Latencies of several hundred ms are expected when hitting off
mode during idle as the latency for power off the system during
idle is long. It could also be that there's a wakeirq config
missing somewhere. Does the WLAN have a separate GPIO irq?
Fair enough.

        wl1251_pins: pinmux_wl1251 {
		     		   pinctrl-single,pins = < 0x0ce (PIN_OUTPUT | MUX_MODE4)
		     		   /* gpio 87 => w\ l1251 enable */
				                           0x05a (PIN_INPUT | MUX_MODE4)
		     		   /* gpio 42 => w\ l1251 irq */
				                   >;
 };

Aha. wl1251 is on the spi bus, too.

&mcspi4 {
        pinctrl-names = "default";
	        pinctrl-0 = <&mcspi4_pins>;

        wl1251 at 0 {
	...
	                interrupt-parent = <&gpio2>;
			                interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
        };

And yes, it has a GPIO irq -- irq 42. What should be configured to
make gpio 42 wake the system from deep idle?
We should do dev_pm_set_dedicated_wake_irq() on the pin related
to gpio42 in the WLAN driver. That way the pinctrl interrupt will
wake up the system and the GPIO interrupt should show up as it
presumably is a level interrupt. The interrupt probably should be
requested by wlcore as the SDIO chips also can have a GPIO interrupt.
That's the interrupts-extended entries we already have for 8250 and
MMC etc.
quoted
The workaround for now is to mux those pins permanently with
PIN_INPUT_PULLUP | MUX_MODE7 to keep them high using the
internal pull. So in this case, maybe give a try for adding
a pinctrl entry for tsc2005 for gpio104 to have it always
in PIN_INPUT_PULLUP | MUX_MODE7.
So the glitches on the GPIOs reset the tsc2005, even when it should be
operational? That would explain stuff.
Yeah.
I'll try to figure out the pinmux stuff. ... but I guess touchscreen
is not really usable with screen off.
Could still wake up the system I guess if configured.
quoted
Typically you need at least USB disconnected and LCD blanked
to start hitting the deeper idle states :)
Right. So I was able to get SD-card to work, so USB was disconnected,
but I was watching power consumption figures in a GTK window... on a
LCD. Ok. I guess I can monitor the power consumption over the wlan.
Yeah in the long run initramfs + ssh over WLAN is probably the best
to develop with if you don't have a serial console wired up. That
allows hitting idle states with mosh at least working OK as long as
the WLAN wakeirq works properly.

Regards,

Tony
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help