* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-23 12:10 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-23 12:10 UTC (permalink / raw) To: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, tony, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! I enabled the sleep leds, and am using following script to set the machine up for power management: #!/bin/bash uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done sudo mount /dev/zero -t debugfs /sys/kernel/debug/ echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode 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. Normally, ping looks like this: 64 bytes from 192.168.43.15: icmp_seq=371 ttl=64 time=2.18 ms 64 bytes from 192.168.43.15: icmp_seq=372 ttl=64 time=2.21 ms 64 bytes from 192.168.43.15: icmp_seq=373 ttl=64 time=2.94 ms When I enable the off mode: echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode Wifi is no longer happy: 64 bytes from 192.168.43.15: icmp_seq=426 ttl=64 time=351 ms 64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms 64 bytes from 192.168.43.15: icmp_seq=428 ttl=64 time=2.36 ms and touchscreen stops working: [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting [99486.995758] bq27xxx-battery 2-0055: battery is not calibrated! ignoring capacity values [99488.564147] tsc2005 spi1.0: TSC200X not responding - resetting [99495.550018] bq27xxx-battery 2-0055: battery is not calibrated! ignoring capacity values [99496.564208] tsc2005 spi1.0: TSC200X not responding - resetting [99504.129852] bq27xxx-battery 2-0055: battery is not calibrated! ignoring capacity values [99504.564208] tsc2005 spi1.0: TSC200X not responding - resetting echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode Fixes both wifi and touchscreen. Is off_mode expected to break touchscreen? Any ideas what needs to be shut down so that the sleep leds go off? Power consumption seems to be in 500mA range, regardless of off_mode. That would mean about 2 hours of battery life, AFAICT. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-23 12:10 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-23 12:10 UTC (permalink / raw) To: linux-arm-kernel Hi! I enabled the sleep leds, and am using following script to set the machine up for power management: #!/bin/bash uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done sudo mount /dev/zero -t debugfs /sys/kernel/debug/ echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode 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. Normally, ping looks like this: 64 bytes from 192.168.43.15: icmp_seq=371 ttl=64 time=2.18 ms 64 bytes from 192.168.43.15: icmp_seq=372 ttl=64 time=2.21 ms 64 bytes from 192.168.43.15: icmp_seq=373 ttl=64 time=2.94 ms When I enable the off mode: echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode Wifi is no longer happy: 64 bytes from 192.168.43.15: icmp_seq=426 ttl=64 time=351 ms 64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms 64 bytes from 192.168.43.15: icmp_seq=428 ttl=64 time=2.36 ms and touchscreen stops working: [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting [99486.995758] bq27xxx-battery 2-0055: battery is not calibrated! ignoring capacity values [99488.564147] tsc2005 spi1.0: TSC200X not responding - resetting [99495.550018] bq27xxx-battery 2-0055: battery is not calibrated! ignoring capacity values [99496.564208] tsc2005 spi1.0: TSC200X not responding - resetting [99504.129852] bq27xxx-battery 2-0055: battery is not calibrated! ignoring capacity values [99504.564208] tsc2005 spi1.0: TSC200X not responding - resetting echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode Fixes both wifi and touchscreen. Is off_mode expected to break touchscreen? Any ideas what needs to be shut down so that the sleep leds go off? Power consumption seems to be in 500mA range, regardless of off_mode. That would mean about 2 hours of battery life, AFAICT. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-23 12:10 ` Pavel Machek @ 2016-01-25 16:33 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-25 16:33 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160123 04:11]: > > 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. > Normally, ping looks like this: > > 64 bytes from 192.168.43.15: icmp_seq=371 ttl=64 time=2.18 ms > 64 bytes from 192.168.43.15: icmp_seq=372 ttl=64 time=2.21 ms > 64 bytes from 192.168.43.15: icmp_seq=373 ttl=64 time=2.94 ms > > When I enable the off mode: > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > Wifi is no longer happy: > > 64 bytes from 192.168.43.15: icmp_seq=426 ttl=64 time=351 ms > 64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms > 64 bytes from 192.168.43.15: icmp_seq=428 ttl=64 time=2.36 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? > and touchscreen stops working: > > [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting > [99486.995758] bq27xxx-battery 2-0055: battery is not calibrated! > ignoring capacity values > [99488.564147] tsc2005 spi1.0: TSC200X not responding - resetting > [99495.550018] bq27xxx-battery 2-0055: battery is not calibrated! > ignoring capacity values > [99496.564208] tsc2005 spi1.0: TSC200X not responding - resetting > [99504.129852] bq27xxx-battery 2-0055: battery is not calibrated! > ignoring capacity values > [99504.564208] tsc2005 spi1.0: TSC200X not responding - resetting This could be because we're still lacking i2c-omap + pinctrl handling for erratum 1.158. Without that, any GPIO pins not in GPIO bank 1 used for enabling devices may have glitches during off-mode. 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. The long term solution is to do this dynamically for each GPIO pin.. I do have some WIP patches for that but those still need work before I dare to post them. > echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > > Fixes both wifi and touchscreen. Is off_mode expected to break > touchscreen? Any ideas what needs to be shut down so that the sleep > leds go off? Yes you can dump the idlest regs during idle and see the blockers. Below is a hack patch I've been using, that could potentially be turned into something we could actually merge. Needs to have separate hooks for various SoCs though, this works only on omap3.. > Power consumption seems to be in 500mA range, regardless of > off_mode. That would mean about 2 hours of battery life, AFAICT. Sounds like you have USB connected and charging? You can get into just few mW range with the mainline kernel for sure on omap3. It's just a quetion of fixing whatever few drivers that are still causing issues on n900. Typically you need at least USB disconnected and LCD blanked to start hitting the deeper idle states :) Regards, Tony 8< ----------- From: Tony Lindgren <tony@atomide.com> Date: Thu, 26 Mar 2015 14:01:31 -0700 Subject: [PATCH] Test patch for dumping omap3 off idle blocking bits Not for merging. Allows seeing the deeper idle state blockers in /sys/kernel/debug/pm_debug/count. For example, when off idle is working on beaglboard xm, this is what I see: # sleep 5; cat /sys/kernel/debug/pm_debug/count ... 0006ffff 48005020 (fa005020) cm_idlest_per blocking bits: 00010000 e7ffffbd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0000000d 48004a28 (fa004a28) cm_idlest3_core --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -142,10 +142,76 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user) return 0; } +#include "iomap.h" + +struct dregs { + const char *desc; + u32 phys; + void __iomem *virt; + u32 mask; +}; + +#define PER_CM_BASE 0x48005000 +#define PER_CM_REG(name, offset, mask) \ + { name, PER_CM_BASE + offset, \ + OMAP2_L4_IO_ADDRESS(PER_CM_BASE + offset), mask, } + +static struct dregs cm_per[] = { + PER_CM_REG("cm_idlest_per", 0x20, 0xfff80000), /* p 513 */ + { NULL, }, +}; + +#define CORE_CM_BASE 0x48004a00 +#define CORE_CM_REG(name, offset, mask) \ + { name, CORE_CM_BASE + offset, \ + OMAP2_L4_IO_ADDRESS(CORE_CM_BASE + offset), mask, } + +static struct dregs cm_core[] = { + CORE_CM_REG("cm_idlest1_core", 0x20, 0x9c800109), /* p 467 */ + CORE_CM_REG("cm_idlest3_core", 0x28, 0xfffffffb), + { NULL, }, +}; + +void __dregs_dump(struct dregs *dregs, struct seq_file *s) +{ + for (; dregs->desc; dregs++) { + u32 val, blockers; + + val = __raw_readl(dregs->virt); + + seq_printf(s, "%08x %08x (%p) %s", + val, dregs->phys, dregs->virt, + dregs->desc); + + if (dregs->mask) { + blockers = ~val; + blockers &= ~dregs->mask; + + if (blockers) + seq_printf(s, " blocking bits: %08x", + blockers); + } + + seq_printf(s, "\n"); + } +} + +void cm_per_dump(struct seq_file *s) +{ + __dregs_dump(cm_per, s); +} + +void cm_core_dump(struct seq_file *s) +{ + __dregs_dump(cm_core, s); +} + static int pm_dbg_show_counters(struct seq_file *s, void *unused) { pwrdm_for_each(pwrdm_dbg_show_counter, s); clkdm_for_each(clkdm_dbg_show_counter, s); + cm_per_dump(s); + cm_core_dump(s); return 0; } ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-25 16:33 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-25 16:33 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160123 04:11]: > > 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. > Normally, ping looks like this: > > 64 bytes from 192.168.43.15: icmp_seq=371 ttl=64 time=2.18 ms > 64 bytes from 192.168.43.15: icmp_seq=372 ttl=64 time=2.21 ms > 64 bytes from 192.168.43.15: icmp_seq=373 ttl=64 time=2.94 ms > > When I enable the off mode: > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > Wifi is no longer happy: > > 64 bytes from 192.168.43.15: icmp_seq=426 ttl=64 time=351 ms > 64 bytes from 192.168.43.15: icmp_seq=427 ttl=64 time=178 ms > 64 bytes from 192.168.43.15: icmp_seq=428 ttl=64 time=2.36 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? > and touchscreen stops working: > > [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting > [99486.995758] bq27xxx-battery 2-0055: battery is not calibrated! > ignoring capacity values > [99488.564147] tsc2005 spi1.0: TSC200X not responding - resetting > [99495.550018] bq27xxx-battery 2-0055: battery is not calibrated! > ignoring capacity values > [99496.564208] tsc2005 spi1.0: TSC200X not responding - resetting > [99504.129852] bq27xxx-battery 2-0055: battery is not calibrated! > ignoring capacity values > [99504.564208] tsc2005 spi1.0: TSC200X not responding - resetting This could be because we're still lacking i2c-omap + pinctrl handling for erratum 1.158. Without that, any GPIO pins not in GPIO bank 1 used for enabling devices may have glitches during off-mode. 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. The long term solution is to do this dynamically for each GPIO pin.. I do have some WIP patches for that but those still need work before I dare to post them. > echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode > > Fixes both wifi and touchscreen. Is off_mode expected to break > touchscreen? Any ideas what needs to be shut down so that the sleep > leds go off? Yes you can dump the idlest regs during idle and see the blockers. Below is a hack patch I've been using, that could potentially be turned into something we could actually merge. Needs to have separate hooks for various SoCs though, this works only on omap3.. > Power consumption seems to be in 500mA range, regardless of > off_mode. That would mean about 2 hours of battery life, AFAICT. Sounds like you have USB connected and charging? You can get into just few mW range with the mainline kernel for sure on omap3. It's just a quetion of fixing whatever few drivers that are still causing issues on n900. Typically you need at least USB disconnected and LCD blanked to start hitting the deeper idle states :) Regards, Tony 8< ----------- From: Tony Lindgren <tony@atomide.com> Date: Thu, 26 Mar 2015 14:01:31 -0700 Subject: [PATCH] Test patch for dumping omap3 off idle blocking bits Not for merging. Allows seeing the deeper idle state blockers in /sys/kernel/debug/pm_debug/count. For example, when off idle is working on beaglboard xm, this is what I see: # sleep 5; cat /sys/kernel/debug/pm_debug/count ... 0006ffff 48005020 (fa005020) cm_idlest_per blocking bits: 00010000 e7ffffbd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0000000d 48004a28 (fa004a28) cm_idlest3_core --- a/arch/arm/mach-omap2/pm-debug.c +++ b/arch/arm/mach-omap2/pm-debug.c @@ -142,10 +142,76 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm, void *user) return 0; } +#include "iomap.h" + +struct dregs { + const char *desc; + u32 phys; + void __iomem *virt; + u32 mask; +}; + +#define PER_CM_BASE 0x48005000 +#define PER_CM_REG(name, offset, mask) \ + { name, PER_CM_BASE + offset, \ + OMAP2_L4_IO_ADDRESS(PER_CM_BASE + offset), mask, } + +static struct dregs cm_per[] = { + PER_CM_REG("cm_idlest_per", 0x20, 0xfff80000), /* p 513 */ + { NULL, }, +}; + +#define CORE_CM_BASE 0x48004a00 +#define CORE_CM_REG(name, offset, mask) \ + { name, CORE_CM_BASE + offset, \ + OMAP2_L4_IO_ADDRESS(CORE_CM_BASE + offset), mask, } + +static struct dregs cm_core[] = { + CORE_CM_REG("cm_idlest1_core", 0x20, 0x9c800109), /* p 467 */ + CORE_CM_REG("cm_idlest3_core", 0x28, 0xfffffffb), + { NULL, }, +}; + +void __dregs_dump(struct dregs *dregs, struct seq_file *s) +{ + for (; dregs->desc; dregs++) { + u32 val, blockers; + + val = __raw_readl(dregs->virt); + + seq_printf(s, "%08x %08x (%p) %s", + val, dregs->phys, dregs->virt, + dregs->desc); + + if (dregs->mask) { + blockers = ~val; + blockers &= ~dregs->mask; + + if (blockers) + seq_printf(s, " blocking bits: %08x", + blockers); + } + + seq_printf(s, "\n"); + } +} + +void cm_per_dump(struct seq_file *s) +{ + __dregs_dump(cm_per, s); +} + +void cm_core_dump(struct seq_file *s) +{ + __dregs_dump(cm_core, s); +} + static int pm_dbg_show_counters(struct seq_file *s, void *unused) { pwrdm_for_each(pwrdm_dbg_show_counter, s); clkdm_for_each(clkdm_dbg_show_counter, s); + cm_per_dump(s); + cm_core_dump(s); return 0; } ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-25 16:33 ` Tony Lindgren @ 2016-01-25 22:23 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-25 22:23 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! First, thanks for the help! > > 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 ;-). > > 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@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? > > and touchscreen stops working: > > > > [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting ... > This could be because we're still lacking i2c-omap + pinctrl > handling for erratum 1.158. Without that, any GPIO pins not in > GPIO bank 1 used for enabling devices may have glitches during > off-mode. > > 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. I'll try to figure out the pinmux stuff. ... but I guess touchscreen is not really usable with screen off. > The long term solution is to do this dynamically for each GPIO > pin.. I do have some WIP patches for that but those still need > work before I dare to post them. No patch is too ugly for testing :-). > Yes you can dump the idlest regs during idle and see the blockers. > Below is a hack patch I've been using, that could potentially > be turned into something we could actually merge. Needs to have > separate hooks for various SoCs though, this works only on omap3.. Thanks, wil try. > > Power consumption seems to be in 500mA range, regardless of > > off_mode. That would mean about 2 hours of battery life, AFAICT. > > Sounds like you have USB connected and charging? You can > get into just few mW range with the mainline kernel for sure > on omap3. It's just a quetion of fixing whatever few drivers > that are still causing issues on n900. > > 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. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-25 22:23 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-25 22:23 UTC (permalink / raw) To: linux-arm-kernel Hi! First, thanks for the help! > > 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 ;-). > > 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? > > and touchscreen stops working: > > > > [99480.564910] tsc2005 spi1.0: TSC200X not responding - resetting ... > This could be because we're still lacking i2c-omap + pinctrl > handling for erratum 1.158. Without that, any GPIO pins not in > GPIO bank 1 used for enabling devices may have glitches during > off-mode. > > 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. I'll try to figure out the pinmux stuff. ... but I guess touchscreen is not really usable with screen off. > The long term solution is to do this dynamically for each GPIO > pin.. I do have some WIP patches for that but those still need > work before I dare to post them. No patch is too ugly for testing :-). > Yes you can dump the idlest regs during idle and see the blockers. > Below is a hack patch I've been using, that could potentially > be turned into something we could actually merge. Needs to have > separate hooks for various SoCs though, this works only on omap3.. Thanks, wil try. > > Power consumption seems to be in 500mA range, regardless of > > off_mode. That would mean about 2 hours of battery life, AFAICT. > > Sounds like you have USB connected and charging? You can > get into just few mW range with the mainline kernel for sure > on omap3. It's just a quetion of fixing whatever few drivers > that are still causing issues on n900. > > 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. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-25 22:23 ` Pavel Machek @ 2016-01-25 22:50 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-25 22:50 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160125 14:24]: > Hi! > > First, thanks for the help! > > > > 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 ;-). > > > > 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@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. > > 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. > > 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-25 22:50 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-25 22:50 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160125 14:24]: > Hi! > > First, thanks for the help! > > > > 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 ;-). > > > > 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. > > 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. > > 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 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-25 16:33 ` Tony Lindgren @ 2016-01-26 14:00 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-26 14:00 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > Power consumption seems to be in 500mA range, regardless of > > off_mode. That would mean about 2 hours of battery life, AFAICT. > > Sounds like you have USB connected and charging? You can > get into just few mW range with the mainline kernel for sure > on omap3. It's just a quetion of fixing whatever few drivers > that are still causing issues on n900. > > Typically you need at least USB disconnected and LCD blanked > to start hitting the deeper idle states :) Ok, no 4.4 kernel + your patch this time, USB disconnected, LCD blanked, but wifi connected and X session running on inactive vt. GSM connected to network. It seems like I have rather lot of blocking bits: usbhost_pwrdm (ON),OFF:3321,RET:37501,INA:0,ON:40823,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:3321,RET:33,INA:0,ON:3355,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:3321,RET:19014,INA:0,ON:22336,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (ON),OFF:3321,RET:37500,INA:2,ON:40824,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:3321,RET:37501,INA:0,ON:40823,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:3321,RET:37501,INA:0,ON:40823,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RE T-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (1) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (19) cam_clkdm->cam_pwrdm (1) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (20) core_l3_clkdm->core_pwrdm (2) neon_clkdm->neon_pwrdm (0) 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 0000000d 48004a28 (fa004a28) cm_idlest3_core cm_idlest1_core changes periodicall often, to 00218072. The rest seems constant. I'm using script below: #!/bin/bash uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done sudo mount /dev/zero -t debugfs /sys/kernel/debug/ echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode sudo cat /sys/kernel/debug/pm_debug/count . Does it mean that more than 5 devices block the suspend? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-26 14:00 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-26 14:00 UTC (permalink / raw) To: linux-arm-kernel Hi! > > Power consumption seems to be in 500mA range, regardless of > > off_mode. That would mean about 2 hours of battery life, AFAICT. > > Sounds like you have USB connected and charging? You can > get into just few mW range with the mainline kernel for sure > on omap3. It's just a quetion of fixing whatever few drivers > that are still causing issues on n900. > > Typically you need at least USB disconnected and LCD blanked > to start hitting the deeper idle states :) Ok, no 4.4 kernel + your patch this time, USB disconnected, LCD blanked, but wifi connected and X session running on inactive vt. GSM connected to network. It seems like I have rather lot of blocking bits: usbhost_pwrdm (ON),OFF:3321,RET:37501,INA:0,ON:40823,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:3321,RET:33,INA:0,ON:3355,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:3321,RET:19014,INA:0,ON:22336,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (ON),OFF:3321,RET:37500,INA:2,ON:40824,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:3321,RET:37501,INA:0,ON:40823,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:3321,RET:37501,INA:0,ON:40823,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RE T-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (1) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (19) cam_clkdm->cam_pwrdm (1) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (20) core_l3_clkdm->core_pwrdm (2) neon_clkdm->neon_pwrdm (0) 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 0000000d 48004a28 (fa004a28) cm_idlest3_core cm_idlest1_core changes periodicall often, to 00218072. The rest seems constant. I'm using script below: #!/bin/bash uarts=$(find /sys/class/tty/ttyO*/device/power/ -type d) for uart in $uarts; do echo 3000 > $uart/autosuspend_delay_ms done uarts=$(find /sys/class/tty/ttyO*/power/ -type d) for uart in $uarts; do echo enabled > $uart/wakeup echo auto > $uart/control done sudo mount /dev/zero -t debugfs /sys/kernel/debug/ echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode sudo cat /sys/kernel/debug/pm_debug/count . Does it mean that more than 5 devices block the suspend? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-26 14:00 ` Pavel Machek @ 2016-01-26 17:25 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-26 17:25 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160126 06:01]: > > It seems like I have rather lot of blocking bits: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 Looks like most of these are for GPIO banks, that's OK those get saved and restored in the idle loop. Here bit 18 UART4 is a mystery though.. It's uart4 on 36xx but reserved on 34xx. I do have that too on my n900, but it's hitting off mode with v4.4. > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > constant. For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 blocking which is for OTG and it's PHY. That's a known issue with musb and setting pm_runtime_irq_safe() on the MUSB parent. If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will start going off assuming the McSPI bit goes low with WLAN idling. Looks like we have some regression with v4.5-rc1 where n900 is not hitting deeper idle states though. I'll run git bisect between v4.4..v4.5-rc1. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-26 17:25 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-26 17:25 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160126 06:01]: > > It seems like I have rather lot of blocking bits: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 Looks like most of these are for GPIO banks, that's OK those get saved and restored in the idle loop. Here bit 18 UART4 is a mystery though.. It's uart4 on 36xx but reserved on 34xx. I do have that too on my n900, but it's hitting off mode with v4.4. > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > constant. For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 blocking which is for OTG and it's PHY. That's a known issue with musb and setting pm_runtime_irq_safe() on the MUSB parent. If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will start going off assuming the McSPI bit goes low with WLAN idling. Looks like we have some regression with v4.5-rc1 where n900 is not hitting deeper idle states though. I'll run git bisect between v4.4..v4.5-rc1. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-26 17:25 ` Tony Lindgren @ 2016-01-26 22:51 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-26 22:51 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Tony Lindgren <tony@atomide.com> [160126 09:26]: > > Looks like we have some regression with v4.5-rc1 where n900 is not > hitting deeper idle states though. I'll run git bisect between > v4.4..v4.5-rc1. Sent more info about that in thread "PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1" FYI. Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-26 22:51 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-01-26 22:51 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [160126 09:26]: > > Looks like we have some regression with v4.5-rc1 where n900 is not > hitting deeper idle states though. I'll run git bisect between > v4.4..v4.5-rc1. Sent more info about that in thread "PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1" FYI. Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-26 17:25 ` Tony Lindgren @ 2016-01-30 20:02 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-30 20:02 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > constant. > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > blocking which is for OTG and it's PHY. That's a known issue with > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > start going off assuming the McSPI bit goes low with WLAN idling. Ok, so I tried to compile kernel without omap2430/phy-twl4030usb . That did not help. So I thought, ok, maybe rmmod is needed to trigger some powersaving? But that is not exactly easy to do: pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko Error: Module phy_twl4030_usb is in use pavel@n900:/my/tui/ofone$ Any ideas what jumps to use the modules? Charger code? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-30 20:02 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-30 20:02 UTC (permalink / raw) To: linux-arm-kernel Hi! > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > constant. > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > blocking which is for OTG and it's PHY. That's a known issue with > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > start going off assuming the McSPI bit goes low with WLAN idling. Ok, so I tried to compile kernel without omap2430/phy-twl4030usb . That did not help. So I thought, ok, maybe rmmod is needed to trigger some powersaving? But that is not exactly easy to do: pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko pavel at n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko Error: Module phy_twl4030_usb is in use pavel at n900:/my/tui/ofone$ Any ideas what jumps to use the modules? Charger code? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-30 20:02 ` Pavel Machek @ 2016-01-30 20:14 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-30 20:14 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge On Sat 2016-01-30 21:02:45, Pavel Machek wrote: > Hi! > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > constant. > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > blocking which is for OTG and it's PHY. That's a known issue with > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > start going off assuming the McSPI bit goes low with WLAN idling. > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > . That did not help. So I thought, ok, maybe rmmod is needed to > trigger some powersaving? But that is not exactly easy to do: > > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > Error: Module phy_twl4030_usb is in use > pavel@n900:/my/tui/ofone$ > > Any ideas what jumps to use the modules? Charger code? I tried a kernel without charger code, and no luck, rmmod fails the same way. dmesg says: [ 111.093078] wlan0: authenticated [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 status=0 aid=2) [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), will use 2 [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), will use 2 [ 111.256652] wlan0: associated [ 184.681427] HS USB OTG: no transceiver configured [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 184.681976] HS USB OTG: no transceiver configured [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 187.690338] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: Initialized TWL4030 USB module [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 [ 187.698333] musb-hdrc: setup fifo_mode 4 [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory pavel@n900:/my/tui/ofone$ Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-30 20:14 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-30 20:14 UTC (permalink / raw) To: linux-arm-kernel On Sat 2016-01-30 21:02:45, Pavel Machek wrote: > Hi! > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > constant. > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > blocking which is for OTG and it's PHY. That's a known issue with > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > start going off assuming the McSPI bit goes low with WLAN idling. > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > . That did not help. So I thought, ok, maybe rmmod is needed to > trigger some powersaving? But that is not exactly easy to do: > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > pavel at n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > Error: Module phy_twl4030_usb is in use > pavel at n900:/my/tui/ofone$ > > Any ideas what jumps to use the modules? Charger code? I tried a kernel without charger code, and no luck, rmmod fails the same way. dmesg says: [ 111.093078] wlan0: authenticated [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 status=0 aid=2) [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), will use 2 [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), will use 2 [ 111.256652] wlan0: associated [ 184.681427] HS USB OTG: no transceiver configured [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 184.681976] HS USB OTG: no transceiver configured [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -517 [ 187.690338] twl4030_usb 48070000.i2c:twl at 48:twl4030-usb: Initialized TWL4030 USB module [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 [ 187.698333] musb-hdrc: setup fifo_mode 4 [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory pavel at n900:/my/tui/ofone$ Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-30 20:14 ` Pavel Machek @ 2016-01-30 22:15 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-30 22:15 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > > constant. > > > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > > blocking which is for OTG and it's PHY. That's a known issue with > > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > > start going off assuming the McSPI bit goes low with WLAN idling. > > > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > > . That did not help. So I thought, ok, maybe rmmod is needed to > > trigger some powersaving? But that is not exactly easy to do: > > > > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > > pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > > Error: Module phy_twl4030_usb is in use > > pavel@n900:/my/tui/ofone$ > > > > Any ideas what jumps to use the modules? Charger code? > > I tried a kernel without charger code, and no luck, rmmod fails the > same way. dmesg says: > [ 111.093078] wlan0: authenticated > [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) > [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 > status=0 aid=2) > [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), > will use 2 > [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), > will use 2 > [ 111.256652] wlan0: associated > [ 184.681427] HS USB OTG: no transceiver configured > [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > with status -517 > [ 184.681976] HS USB OTG: no transceiver configured > [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > with status -517 > [ 187.690338] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: > Initialized TWL4030 USB module > [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 > [ 187.698333] musb-hdrc: setup fifo_mode 4 > [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory > pavel@n900:/my/tui/ofone$ I added following hack to phy-twl4030-usb.c so that I could avoid modules and module unloading problem. But still could not get it to sleep :-(. Pavel diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 3a707dd..ac3761b 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -532,6 +532,43 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev, } static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL); +static ssize_t twl4030_test_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct twl4030_usb *twl = dev_get_drvdata(dev); + int ret = -EINVAL; + + mutex_lock(&twl->lock); + ret = sprintf(buf, "%s\n", "hello, world"); + mutex_unlock(&twl->lock); + + return ret; +} + +static int twl4030_shutdown(struct twl4030_usb *twl); + +static ssize_t twl4030_test_store(struct device *dev, + struct device_attribute *attr, const char *buf, size_t count) +{ + unsigned long tmp; + + struct twl4030_usb *twl = dev_get_drvdata(dev); + + mutex_lock(&twl->lock); + sscanf(buf, "%lX", &tmp); + printk("TWL HACK: tmp = 0x%lX\n", tmp); + mutex_unlock(&twl->lock); + + if (tmp == 0xdead) { + printk("TWL HACK: killing hardware\n"); + printk("TWL HACK: killing hardware = %d\n", twl4030_shutdown(twl)); + } + + return strnlen(buf, count); +} + +static DEVICE_ATTR(test, 0664, twl4030_test_show, twl4030_test_store); + static irqreturn_t twl4030_usb_irq(int irq, void *_twl) { struct twl4030_usb *twl = _twl; @@ -710,6 +747,9 @@ static int twl4030_usb_probe(struct platform_device *pdev) if (device_create_file(&pdev->dev, &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs file\n"); + if (device_create_file(&pdev->dev, &dev_attr_test)) + dev_warn(&pdev->dev, "could not create sysfs file #2\n"); + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier); pm_runtime_use_autosuspend(&pdev->dev); @@ -745,14 +785,12 @@ static int twl4030_usb_probe(struct platform_device *pdev) return 0; } -static int twl4030_usb_remove(struct platform_device *pdev) +static int twl4030_shutdown(struct twl4030_usb *twl) { - struct twl4030_usb *twl = platform_get_drvdata(pdev); int val; pm_runtime_get_sync(twl->dev); cancel_delayed_work(&twl->id_workaround_work); - device_remove_file(twl->dev, &dev_attr_vbus); /* set transceiver mode to power on defaults */ twl4030_usb_set_mode(twl, -1); @@ -779,6 +817,17 @@ static int twl4030_usb_remove(struct platform_device *pdev) return 0; } + +static int twl4030_usb_remove(struct platform_device *pdev) +{ + struct twl4030_usb *twl = platform_get_drvdata(pdev); + + device_remove_file(twl->dev, &dev_attr_vbus); + device_remove_file(twl->dev, &dev_attr_test); + + return twl4030_shutdown(twl); +} + #ifdef CONFIG_OF static const struct of_device_id twl4030_usb_id_table[] = { { .compatible = "ti,twl4030-usb" }, -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply related [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-01-30 22:15 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-01-30 22:15 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > > constant. > > > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > > blocking which is for OTG and it's PHY. That's a known issue with > > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > > start going off assuming the McSPI bit goes low with WLAN idling. > > > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > > . That did not help. So I thought, ok, maybe rmmod is needed to > > trigger some powersaving? But that is not exactly easy to do: > > > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > > pavel at n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > > Error: Module phy_twl4030_usb is in use > > pavel at n900:/my/tui/ofone$ > > > > Any ideas what jumps to use the modules? Charger code? > > I tried a kernel without charger code, and no luck, rmmod fails the > same way. dmesg says: > [ 111.093078] wlan0: authenticated > [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) > [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 > status=0 aid=2) > [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), > will use 2 > [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), > will use 2 > [ 111.256652] wlan0: associated > [ 184.681427] HS USB OTG: no transceiver configured > [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > with status -517 > [ 184.681976] HS USB OTG: no transceiver configured > [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > with status -517 > [ 187.690338] twl4030_usb 48070000.i2c:twl at 48:twl4030-usb: > Initialized TWL4030 USB module > [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 > [ 187.698333] musb-hdrc: setup fifo_mode 4 > [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory > pavel at n900:/my/tui/ofone$ I added following hack to phy-twl4030-usb.c so that I could avoid modules and module unloading problem. But still could not get it to sleep :-(. Pavel diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c index 3a707dd..ac3761b 100644 --- a/drivers/phy/phy-twl4030-usb.c +++ b/drivers/phy/phy-twl4030-usb.c @@ -532,6 +532,43 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev, } static DEVICE_ATTR(vbus, 0444, twl4030_usb_vbus_show, NULL); +static ssize_t twl4030_test_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct twl4030_usb *twl = dev_get_drvdata(dev); + int ret = -EINVAL; + + mutex_lock(&twl->lock); + ret = sprintf(buf, "%s\n", "hello, world"); + mutex_unlock(&twl->lock); + + return ret; +} + +static int twl4030_shutdown(struct twl4030_usb *twl); + +static ssize_t twl4030_test_store(struct device *dev, + struct device_attribute *attr, const char *buf, size_t count) +{ + unsigned long tmp; + + struct twl4030_usb *twl = dev_get_drvdata(dev); + + mutex_lock(&twl->lock); + sscanf(buf, "%lX", &tmp); + printk("TWL HACK: tmp = 0x%lX\n", tmp); + mutex_unlock(&twl->lock); + + if (tmp == 0xdead) { + printk("TWL HACK: killing hardware\n"); + printk("TWL HACK: killing hardware = %d\n", twl4030_shutdown(twl)); + } + + return strnlen(buf, count); +} + +static DEVICE_ATTR(test, 0664, twl4030_test_show, twl4030_test_store); + static irqreturn_t twl4030_usb_irq(int irq, void *_twl) { struct twl4030_usb *twl = _twl; @@ -710,6 +747,9 @@ static int twl4030_usb_probe(struct platform_device *pdev) if (device_create_file(&pdev->dev, &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs file\n"); + if (device_create_file(&pdev->dev, &dev_attr_test)) + dev_warn(&pdev->dev, "could not create sysfs file #2\n"); + ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier); pm_runtime_use_autosuspend(&pdev->dev); @@ -745,14 +785,12 @@ static int twl4030_usb_probe(struct platform_device *pdev) return 0; } -static int twl4030_usb_remove(struct platform_device *pdev) +static int twl4030_shutdown(struct twl4030_usb *twl) { - struct twl4030_usb *twl = platform_get_drvdata(pdev); int val; pm_runtime_get_sync(twl->dev); cancel_delayed_work(&twl->id_workaround_work); - device_remove_file(twl->dev, &dev_attr_vbus); /* set transceiver mode to power on defaults */ twl4030_usb_set_mode(twl, -1); @@ -779,6 +817,17 @@ static int twl4030_usb_remove(struct platform_device *pdev) return 0; } + +static int twl4030_usb_remove(struct platform_device *pdev) +{ + struct twl4030_usb *twl = platform_get_drvdata(pdev); + + device_remove_file(twl->dev, &dev_attr_vbus); + device_remove_file(twl->dev, &dev_attr_test); + + return twl4030_shutdown(twl); +} + #ifdef CONFIG_OF static const struct of_device_id twl4030_usb_id_table[] = { { .compatible = "ti,twl4030-usb" }, -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply related [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-01-30 22:15 ` Pavel Machek @ 2016-02-01 18:13 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-01 18:13 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160130 14:16]: > Hi! > > > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > > > constant. > > > > > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > > > blocking which is for OTG and it's PHY. That's a known issue with > > > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > > > start going off assuming the McSPI bit goes low with WLAN idling. > > > > > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > > > . That did not help. So I thought, ok, maybe rmmod is needed to > > > trigger some powersaving? But that is not exactly easy to do: > > > > > > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > > > pavel@n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > > > pavel@n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > > > Error: Module phy_twl4030_usb is in use > > > pavel@n900:/my/tui/ofone$ > > > > > > Any ideas what jumps to use the modules? Charger code? > > > > I tried a kernel without charger code, and no luck, rmmod fails the > > same way. dmesg says: > > [ 111.093078] wlan0: authenticated > > [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) > > [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 > > status=0 aid=2) > > [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), > > will use 2 > > [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), > > will use 2 > > [ 111.256652] wlan0: associated > > [ 184.681427] HS USB OTG: no transceiver configured > > [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > with status -517 > > [ 184.681976] HS USB OTG: no transceiver configured > > [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > with status -517 > > [ 187.690338] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: > > Initialized TWL4030 USB module > > [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk > > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > > [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 > > [ 187.698333] musb-hdrc: setup fifo_mode 4 > > [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory > > pavel@n900:/my/tui/ofone$ > > I added following hack to phy-twl4030-usb.c so that I could avoid > modules and module unloading problem. But still could not get it to > sleep :-(. Are you sure you're using v4.5-rc? I recently patched away some issues where rmmod of the musb related modules did not work. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-01 18:13 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-01 18:13 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160130 14:16]: > Hi! > > > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072 > > > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > > > > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems > > > > > constant. > > > > > > > > For cm_idlest1_core 42 is the answer.. Here you have bits 4 and 5 > > > > blocking which is for OTG and it's PHY. That's a known issue with > > > > musb and setting pm_runtime_irq_safe() on the MUSB parent. > > > > > > > > If you do rmmod omap2430 and phy-twl4030usb chances are the LEDs will > > > > start going off assuming the McSPI bit goes low with WLAN idling. > > > > > > Ok, so I tried to compile kernel without omap2430/phy-twl4030usb > > > . That did not help. So I thought, ok, maybe rmmod is needed to > > > trigger some powersaving? But that is not exactly easy to do: > > > > > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/omap2430.ko > > > pavel at n900:/my/tui/ofone$ sudo insmod /my/modules/phy-twl4030-usb.ko > > > pavel at n900:/my/tui/ofone$ sudo rmmod phy-twl4030-usb.ko > > > Error: Module phy_twl4030_usb is in use > > > pavel at n900:/my/tui/ofone$ > > > > > > Any ideas what jumps to use the modules? Charger code? > > > > I tried a kernel without charger code, and no luck, rmmod fails the > > same way. dmesg says: > > [ 111.093078] wlan0: authenticated > > [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) > > [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 > > status=0 aid=2) > > [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), > > will use 2 > > [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), > > will use 2 > > [ 111.256652] wlan0: associated > > [ 184.681427] HS USB OTG: no transceiver configured > > [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > with status -517 > > [ 184.681976] HS USB OTG: no transceiver configured > > [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > with status -517 > > [ 187.690338] twl4030_usb 48070000.i2c:twl at 48:twl4030-usb: > > Initialized TWL4030 USB module > > [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk > > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > > [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 > > [ 187.698333] musb-hdrc: setup fifo_mode 4 > > [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory > > pavel at n900:/my/tui/ofone$ > > I added following hack to phy-twl4030-usb.c so that I could avoid > modules and module unloading problem. But still could not get it to > sleep :-(. Are you sure you're using v4.5-rc? I recently patched away some issues where rmmod of the musb related modules did not work. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-01 18:13 ` Tony Lindgren @ 2016-02-01 21:17 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-01 21:17 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > > Any ideas what jumps to use the modules? Charger code? > > > > > > I tried a kernel without charger code, and no luck, rmmod fails the > > > same way. dmesg says: > > > [ 111.093078] wlan0: authenticated > > > [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) > > > [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 > > > status=0 aid=2) > > > [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), > > > will use 2 > > > [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), > > > will use 2 > > > [ 111.256652] wlan0: associated > > > [ 184.681427] HS USB OTG: no transceiver configured > > > [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > > with status -517 > > > [ 184.681976] HS USB OTG: no transceiver configured > > > [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > > with status -517 > > > [ 187.690338] twl4030_usb 48070000.i2c:twl@48:twl4030-usb: > > > Initialized TWL4030 USB module > > > [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk > > > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > > > [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 > > > [ 187.698333] musb-hdrc: setup fifo_mode 4 > > > [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory > > > pavel@n900:/my/tui/ofone$ > > > > I added following hack to phy-twl4030-usb.c so that I could avoid > > modules and module unloading problem. But still could not get it to > > sleep :-(. > > Are you sure you're using v4.5-rc? I recently patched away some > issues where rmmod of the musb related modules did not work. No, sorry, that was with 4.4. As you hit "PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid v4.5-rc. (I assume I have to insmod and rmmod, right? Because powersave is not entered if I simply compile-out usb). Would you have commit ids for those rmmod fixes? It might be good to push them into stable, and I should try again with them applied... Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-01 21:17 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-01 21:17 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > Any ideas what jumps to use the modules? Charger code? > > > > > > I tried a kernel without charger code, and no luck, rmmod fails the > > > same way. dmesg says: > > > [ 111.093078] wlan0: authenticated > > > [ 111.097442] wlan0: associate with 06:27:22:f9:10:6a (try 1/3) > > > [ 111.104553] wlan0: RX AssocResp from 06:27:22:f9:10:6a (capab=0x421 > > > status=0 aid=2) > > > [ 111.104705] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 2), > > > will use 2 > > > [ 111.104736] wlan0: AP has invalid WMM params (AIFSN=1 for ACI 3), > > > will use 2 > > > [ 111.256652] wlan0: associated > > > [ 184.681427] HS USB OTG: no transceiver configured > > > [ 184.681488] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > > with status -517 > > > [ 184.681976] HS USB OTG: no transceiver configured > > > [ 184.682006] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed > > > with status -517 > > > [ 187.690338] twl4030_usb 48070000.i2c:twl at 48:twl4030-usb: > > > Initialized TWL4030 USB module > > > [ 187.698303] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk > > > combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn) > > > [ 187.698333] musb-hdrc: MHDRC RTL version 1.400 > > > [ 187.698333] musb-hdrc: setup fifo_mode 4 > > > [ 187.698394] musb-hdrc: 28/31 max ep, 16384/16384 memory > > > pavel at n900:/my/tui/ofone$ > > > > I added following hack to phy-twl4030-usb.c so that I could avoid > > modules and module unloading problem. But still could not get it to > > sleep :-(. > > Are you sure you're using v4.5-rc? I recently patched away some > issues where rmmod of the musb related modules did not work. No, sorry, that was with 4.4. As you hit "PM regression with commit 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid v4.5-rc. (I assume I have to insmod and rmmod, right? Because powersave is not entered if I simply compile-out usb). Would you have commit ids for those rmmod fixes? It might be good to push them into stable, and I should try again with them applied... Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-01 21:17 ` Pavel Machek @ 2016-02-01 22:11 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-01 22:11 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160201 13:18]: > > No, sorry, that was with 4.4. As you hit "PM regression with commit > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > v4.5-rc. OK > (I assume I have to insmod and rmmod, right? Because powersave is not > entered if I simply compile-out usb). Depending on what the bootloader does and probably also if USB was used during the booting.. So yeah you may need to modprobe and then rmmod. > Would you have commit ids for those rmmod fixes? It might be good to > push them into stable, and I should try again with them applied... 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-01 22:11 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-01 22:11 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160201 13:18]: > > No, sorry, that was with 4.4. As you hit "PM regression with commit > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > v4.5-rc. OK > (I assume I have to insmod and rmmod, right? Because powersave is not > entered if I simply compile-out usb). Depending on what the bootloader does and probably also if USB was used during the booting.. So yeah you may need to modprobe and then rmmod. > Would you have commit ids for those rmmod fixes? It might be good to > push them into stable, and I should try again with them applied... 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-01 22:11 ` Tony Lindgren @ 2016-02-04 5:35 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-04 5:35 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Tony Lindgren <tony@atomide.com> [160201 14:12]: > * Pavel Machek <pavel@ucw.cz> [160201 13:18]: > > > > No, sorry, that was with 4.4. As you hit "PM regression with commit > > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > > v4.5-rc. > > OK > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > entered if I simply compile-out usb). > > Depending on what the bootloader does and probably also if > USB was used during the booting.. So yeah you may need to modprobe > and then rmmod. > > > Would you have commit ids for those rmmod fixes? It might be good to > > push them into stable, and I should try again with them applied... > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") Oh and looks like these two phy-twl4030-phy fixes never got merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for unloading the module": phy: twl4030-usb: Relase usb phy on unload phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload I'll resend those. But without those again deeper idle states are blocked.. And it could be that n900 needs similar additional patches for it's USB PHY as I've tested things so far only with phy-twl4030-usb PHY based systems. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-04 5:35 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-04 5:35 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [160201 14:12]: > * Pavel Machek <pavel@ucw.cz> [160201 13:18]: > > > > No, sorry, that was with 4.4. As you hit "PM regression with commit > > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > > v4.5-rc. > > OK > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > entered if I simply compile-out usb). > > Depending on what the bootloader does and probably also if > USB was used during the booting.. So yeah you may need to modprobe > and then rmmod. > > > Would you have commit ids for those rmmod fixes? It might be good to > > push them into stable, and I should try again with them applied... > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") Oh and looks like these two phy-twl4030-phy fixes never got merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for unloading the module": phy: twl4030-usb: Relase usb phy on unload phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload I'll resend those. But without those again deeper idle states are blocked.. And it could be that n900 needs similar additional patches for it's USB PHY as I've tested things so far only with phy-twl4030-usb PHY based systems. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-04 5:35 ` Tony Lindgren (?) @ 2016-02-07 21:37 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-07 21:37 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > No, sorry, that was with 4.4. As you hit "PM regression with commit > > > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > > > v4.5-rc. > > > > OK > > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > entered if I simply compile-out usb). > > > > Depending on what the bootloader does and probably also if > > USB was used during the booting.. So yeah you may need to modprobe > > and then rmmod. > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > push them into stable, and I should try again with them applied... > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > Oh and looks like these two phy-twl4030-phy fixes never got > merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for > unloading the module": > > phy: twl4030-usb: Relase usb phy on unload > phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload > > I'll resend those. But without those again deeper idle states > are blocked.. And it could be that n900 needs similar additional > patches for it's USB PHY as I've tested things so far only with > phy-twl4030-usb PHY based systems. I don't get it. I was using +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_TWL4030_USB=m on the n900. Are you suggesting I should be using something else on the N900? If so, what? Pali, do you have deeper sleep states working on 4.4 kernel? (Or anything 4.X?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-07 21:37 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-07 21:37 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > No, sorry, that was with 4.4. As you hit "PM regression with commit > > > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > > > v4.5-rc. > > > > OK > > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > entered if I simply compile-out usb). > > > > Depending on what the bootloader does and probably also if > > USB was used during the booting.. So yeah you may need to modprobe > > and then rmmod. > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > push them into stable, and I should try again with them applied... > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > Oh and looks like these two phy-twl4030-phy fixes never got > merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for > unloading the module": > > phy: twl4030-usb: Relase usb phy on unload > phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload > > I'll resend those. But without those again deeper idle states > are blocked.. And it could be that n900 needs similar additional > patches for it's USB PHY as I've tested things so far only with > phy-twl4030-usb PHY based systems. I don't get it. I was using +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_TWL4030_USB=m on the n900. Are you suggesting I should be using something else on the N900? If so, what? Pali, do you have deeper sleep states working on 4.4 kernel? (Or anything 4.X?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-07 21:37 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-07 21:37 UTC (permalink / raw) To: Tony Lindgren Cc: ivo.g.dimitrov.75, khilman, aaro.koskinen, kernel list, sre, pali.rohar, linux-omap, patrikbachan, linux-arm-kernel, serge Hi! > > > No, sorry, that was with 4.4. As you hit "PM regression with commit > > > 5de85b9d57ab PM runtime re-init in v4.5-rc1", I thought I'd avoid > > > v4.5-rc. > > > > OK > > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > entered if I simply compile-out usb). > > > > Depending on what the bootloader does and probably also if > > USB was used during the booting.. So yeah you may need to modprobe > > and then rmmod. > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > push them into stable, and I should try again with them applied... > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > Oh and looks like these two phy-twl4030-phy fixes never got > merged from thread "[PATCH 0/2] Two phy-twl4030-usb fixes for > unloading the module": > > phy: twl4030-usb: Relase usb phy on unload > phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload > > I'll resend those. But without those again deeper idle states > are blocked.. And it could be that n900 needs similar additional > patches for it's USB PHY as I've tested things so far only with > phy-twl4030-usb PHY based systems. I don't get it. I was using +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_TWL4030_USB=m on the n900. Are you suggesting I should be using something else on the N900? If so, what? Pali, do you have deeper sleep states working on 4.4 kernel? (Or anything 4.X?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-07 21:37 ` Pavel Machek @ 2016-02-08 8:51 ` Pali Rohár -1 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-02-08 8:51 UTC (permalink / raw) To: Pavel Machek Cc: Tony Lindgren, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge On Sunday 07 February 2016 22:37:20 Pavel Machek wrote: > Pali, do you have deeper sleep states working on 4.4 kernel? (Or > anything 4.X?) Do not know, at least I did not play or test this part of power management yet. -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-08 8:51 ` Pali Rohár 0 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-02-08 8:51 UTC (permalink / raw) To: linux-arm-kernel On Sunday 07 February 2016 22:37:20 Pavel Machek wrote: > Pali, do you have deeper sleep states working on 4.4 kernel? (Or > anything 4.X?) Do not know, at least I did not play or test this part of power management yet. -- Pali Roh?r pali.rohar at gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-01 22:11 ` Tony Lindgren @ 2016-02-07 21:23 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-07 21:23 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > (I assume I have to insmod and rmmod, right? Because powersave is not > > entered if I simply compile-out usb). > > Depending on what the bootloader does and probably also if > USB was used during the booting.. So yeah you may need to modprobe > and then rmmod. > > > Would you have commit ids for those rmmod fixes? It might be good to > > push them into stable, and I should try again with them applied... > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") Ok, with that, I can insmod and rmmod. But I still get: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 0000000d 48004a28 (fa004a28) cm_idlest3_core Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-07 21:23 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-02-07 21:23 UTC (permalink / raw) To: linux-arm-kernel Hi! > > (I assume I have to insmod and rmmod, right? Because powersave is not > > entered if I simply compile-out usb). > > Depending on what the bootloader does and probably also if > USB was used during the booting.. So yeah you may need to modprobe > and then rmmod. > > > Would you have commit ids for those rmmod fixes? It might be good to > > push them into stable, and I should try again with them applied... > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") Ok, with that, I can insmod and rmmod. But I still get: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 0000000d 48004a28 (fa004a28) cm_idlest3_core Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-07 21:23 ` Pavel Machek @ 2016-02-09 17:24 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-09 17:24 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > Hi! > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > entered if I simply compile-out usb). > > > > Depending on what the bootloader does and probably also if > > USB was used during the booting.. So yeah you may need to modprobe > > and then rmmod. > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > push them into stable, and I should try again with them applied... > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > Ok, with that, I can insmod and rmmod. But I still get: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 I think the cm_idlest_per is fine. > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > 0000000d 48004a28 (fa004a28) cm_idlest3_core Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? If not, the're PM runtime missing or broken somewhere. FYI, below is my omap3 usb test script that I use to start and stop USB, it also works on n900. And after stopping it n900 continues hitting deeper idle states just fine. That is with these two phy patches applied on v4.5-rc3: "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload") "phy: twl4030-usb: Relase usb phy on unload") Maybe I gave you wrong info on the USB patches needed.. But these two above are needed on v4.5-rc3. And looks like Kishon has now applied them. Oh and I also have the MMC PM runtime regression fix here that I have not yet posted. Will post today. But I guess you're on v4.4 right now still. Regards, Tony 8< -------- #!/bin/bash # Change for your UDC controller phy_module=phy_twl4030_usb udc_glue=omap2430 udc_module=musb_hdrc udc_name=musb-hdrc.0.auto start_usb_gadgets() { vendor=0x1d6b product=0x0106 file=$1 mount -t configfs none /sys/kernel/config mkdir /sys/kernel/config/usb_gadget/g1 old_pwd=$(pwd) cd /sys/kernel/config/usb_gadget/g1 echo $product > idProduct echo $vendor > idVendor mkdir strings/0x409 echo 123456789 > strings/0x409/serialnumber echo foo > strings/0x409/manufacturer echo "Multi Gadget" > strings/0x409/product mkdir configs/c.1 echo 100 > configs/c.1/MaxPower mkdir configs/c.1/strings/0x409 echo "Config 100mA" > configs/c.1/strings/0x409/configuration mkdir configs/c.5 echo 500 > configs/c.5/MaxPower mkdir configs/c.5/strings/0x409 echo "Config 500mA" > configs/c.5/strings/0x409/configuration mkdir functions/mass_storage.0 echo $file > functions/mass_storage.0/lun.0/file ln -s functions/mass_storage.0 configs/c.1 ln -s functions/mass_storage.0 configs/c.5 mkdir functions/acm.0 ln -s functions/acm.0 configs/c.1 ln -s functions/acm.0 configs/c.5 mkdir functions/ecm.0 ln -s functions/ecm.0 configs/c.1 ln -s functions/ecm.0 configs/c.5 # Adding rndis seems to cause alignment trap or some # random oops on reboot after rmmod $udc_glue echo $udc_name > /sys/kernel/config/usb_gadget/g1/UDC cd $old_pwd } stop_usb_gadgets() { old_pwd=$(pwd) cd /sys/kernel/config/usb_gadget/g1 echo "" > /sys/kernel/config/usb_gadget/g1/UDC rm configs/c.1/ecm.0 rm configs/c.5/ecm.0 rmdir functions/ecm.0 rm configs/c.1/acm.0 rm configs/c.5/acm.0 rmdir functions/acm.0 echo "" > functions/mass_storage.0/lun.0/file rm configs/c.1/mass_storage.0 rm configs/c.5/mass_storage.0 rmdir functions/mass_storage.0 rmmod $udc_glue rmmod $phy_module rmmod $udc_module cd $old_pwd } case $1 in start) modprobe libcomposite modprobe $phy_module modprobe $udc_glue start_usb_gadgets "" ;; stop) stop_usb_gadgets ;; *) ;; esac ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-09 17:24 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-09 17:24 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > Hi! > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > entered if I simply compile-out usb). > > > > Depending on what the bootloader does and probably also if > > USB was used during the booting.. So yeah you may need to modprobe > > and then rmmod. > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > push them into stable, and I should try again with them applied... > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > Ok, with that, I can insmod and rmmod. But I still get: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 I think the cm_idlest_per is fine. > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > 0000000d 48004a28 (fa004a28) cm_idlest3_core Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? If not, the're PM runtime missing or broken somewhere. FYI, below is my omap3 usb test script that I use to start and stop USB, it also works on n900. And after stopping it n900 continues hitting deeper idle states just fine. That is with these two phy patches applied on v4.5-rc3: "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload") "phy: twl4030-usb: Relase usb phy on unload") Maybe I gave you wrong info on the USB patches needed.. But these two above are needed on v4.5-rc3. And looks like Kishon has now applied them. Oh and I also have the MMC PM runtime regression fix here that I have not yet posted. Will post today. But I guess you're on v4.4 right now still. Regards, Tony 8< -------- #!/bin/bash # Change for your UDC controller phy_module=phy_twl4030_usb udc_glue=omap2430 udc_module=musb_hdrc udc_name=musb-hdrc.0.auto start_usb_gadgets() { vendor=0x1d6b product=0x0106 file=$1 mount -t configfs none /sys/kernel/config mkdir /sys/kernel/config/usb_gadget/g1 old_pwd=$(pwd) cd /sys/kernel/config/usb_gadget/g1 echo $product > idProduct echo $vendor > idVendor mkdir strings/0x409 echo 123456789 > strings/0x409/serialnumber echo foo > strings/0x409/manufacturer echo "Multi Gadget" > strings/0x409/product mkdir configs/c.1 echo 100 > configs/c.1/MaxPower mkdir configs/c.1/strings/0x409 echo "Config 100mA" > configs/c.1/strings/0x409/configuration mkdir configs/c.5 echo 500 > configs/c.5/MaxPower mkdir configs/c.5/strings/0x409 echo "Config 500mA" > configs/c.5/strings/0x409/configuration mkdir functions/mass_storage.0 echo $file > functions/mass_storage.0/lun.0/file ln -s functions/mass_storage.0 configs/c.1 ln -s functions/mass_storage.0 configs/c.5 mkdir functions/acm.0 ln -s functions/acm.0 configs/c.1 ln -s functions/acm.0 configs/c.5 mkdir functions/ecm.0 ln -s functions/ecm.0 configs/c.1 ln -s functions/ecm.0 configs/c.5 # Adding rndis seems to cause alignment trap or some # random oops on reboot after rmmod $udc_glue echo $udc_name > /sys/kernel/config/usb_gadget/g1/UDC cd $old_pwd } stop_usb_gadgets() { old_pwd=$(pwd) cd /sys/kernel/config/usb_gadget/g1 echo "" > /sys/kernel/config/usb_gadget/g1/UDC rm configs/c.1/ecm.0 rm configs/c.5/ecm.0 rmdir functions/ecm.0 rm configs/c.1/acm.0 rm configs/c.5/acm.0 rmdir functions/acm.0 echo "" > functions/mass_storage.0/lun.0/file rm configs/c.1/mass_storage.0 rm configs/c.5/mass_storage.0 rmdir functions/mass_storage.0 rmmod $udc_glue rmmod $phy_module rmmod $udc_module cd $old_pwd } case $1 in start) modprobe libcomposite modprobe $phy_module modprobe $udc_glue start_usb_gadgets "" ;; stop) stop_usb_gadgets ;; *) ;; esac ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-09 17:24 ` Tony Lindgren @ 2016-02-09 17:38 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-09 17:38 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Tony Lindgren <tony@atomide.com> [160209 09:26]: > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > Hi! > > > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > > entered if I simply compile-out usb). > > > > > > Depending on what the bootloader does and probably also if > > > USB was used during the booting.. So yeah you may need to modprobe > > > and then rmmod. > > > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > > push them into stable, and I should try again with them applied... > > > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > > > Ok, with that, I can insmod and rmmod. But I still get: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > I think the cm_idlest_per is fine. > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. > > FYI, below is my omap3 usb test script that I use to start and > stop USB, it also works on n900. And after stopping it n900 > continues hitting deeper idle states just fine. > > That is with these two phy patches applied on v4.5-rc3: > > "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload") > "phy: twl4030-usb: Relase usb phy on unload") > > Maybe I gave you wrong info on the USB patches needed.. But these > two above are needed on v4.5-rc3. And looks like Kishon has now > applied them. > > Oh and I also have the MMC PM runtime regression fix here that I > have not yet posted. Will post today. But I guess you're on > v4.4 right now still. And looks like the USB RNDIS gadget has some extra issues breaking reboot. So I'd stick to ECM if possible and leave out RNDIS completely. Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-09 17:38 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-09 17:38 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [160209 09:26]: > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > Hi! > > > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > > entered if I simply compile-out usb). > > > > > > Depending on what the bootloader does and probably also if > > > USB was used during the booting.. So yeah you may need to modprobe > > > and then rmmod. > > > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > > push them into stable, and I should try again with them applied... > > > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > > > Ok, with that, I can insmod and rmmod. But I still get: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > I think the cm_idlest_per is fine. > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. > > FYI, below is my omap3 usb test script that I use to start and > stop USB, it also works on n900. And after stopping it n900 > continues hitting deeper idle states just fine. > > That is with these two phy patches applied on v4.5-rc3: > > "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload") > "phy: twl4030-usb: Relase usb phy on unload") > > Maybe I gave you wrong info on the USB patches needed.. But these > two above are needed on v4.5-rc3. And looks like Kishon has now > applied them. > > Oh and I also have the MMC PM runtime regression fix here that I > have not yet posted. Will post today. But I guess you're on > v4.4 right now still. And looks like the USB RNDIS gadget has some extra issues breaking reboot. So I'd stick to ECM if possible and leave out RNDIS completely. Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-09 17:38 ` Tony Lindgren @ 2016-03-20 8:38 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-20 8:38 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > Oh and I also have the MMC PM runtime regression fix here that I > > have not yet posted. Will post today. But I guess you're on > > v4.4 right now still. > > And looks like the USB RNDIS gadget has some extra issues > breaking reboot. So I'd stick to ECM if possible and leave out > RNDIS completely. Thanks for the information. I should be using ECM CONFIG_USB_F_ECM=y # CONFIG_USB_ETH_RNDIS is not set Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-03-20 8:38 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-20 8:38 UTC (permalink / raw) To: linux-arm-kernel Hi! > > Oh and I also have the MMC PM runtime regression fix here that I > > have not yet posted. Will post today. But I guess you're on > > v4.4 right now still. > > And looks like the USB RNDIS gadget has some extra issues > breaking reboot. So I'd stick to ECM if possible and leave out > RNDIS completely. Thanks for the information. I should be using ECM CONFIG_USB_F_ECM=y # CONFIG_USB_ETH_RNDIS is not set Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-09 17:24 ` Tony Lindgren (?) @ 2016-02-11 1:08 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-11 1:08 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Tony Lindgren <tony@atomide.com> [160209 09:26]: > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. Just tested n900 wlan here and it's working for me with Emil's patch from the "" thread and the PM runtime regression fix for hsmmc I posted earlier today. Looks like n900 is hitting off mode just fine with wlan0 configured. It does not wake up to pings from outside from off mode though until the system wakes up. I'll take a look and send a patch for that separately. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-11 1:08 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-11 1:08 UTC (permalink / raw) To: linux-arm-kernel * Tony Lindgren <tony@atomide.com> [160209 09:26]: > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. Just tested n900 wlan here and it's working for me with Emil's patch from the "" thread and the PM runtime regression fix for hsmmc I posted earlier today. Looks like n900 is hitting off mode just fine with wlan0 configured. It does not wake up to pings from outside from off mode though until the system wakes up. I'll take a look and send a patch for that separately. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-02-11 1:08 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-02-11 1:08 UTC (permalink / raw) To: Pavel Machek Cc: ivo.g.dimitrov.75, khilman, aaro.koskinen, kernel list, sre, pali.rohar, linux-omap, patrikbachan, linux-arm-kernel, serge * Tony Lindgren <tony@atomide.com> [160209 09:26]: > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. Just tested n900 wlan here and it's working for me with Emil's patch from the "" thread and the PM runtime regression fix for hsmmc I posted earlier today. Looks like n900 is hitting off mode just fine with wlan0 configured. It does not wake up to pings from outside from off mode though until the system wakes up. I'll take a look and send a patch for that separately. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-11 1:08 ` Tony Lindgren @ 2016-03-23 14:37 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-23 14:37 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge On Wed 2016-02-10 17:08:18, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [160209 09:26]: > > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > > > If not, the're PM runtime missing or broken somewhere. > > Just tested n900 wlan here and it's working for me with Emil's > patch from the "" thread and the PM runtime regression fix for > hsmmc I posted earlier today. Looks like n900 is hitting off > mode just fine with wlan0 configured. Emil's patch, would that be: commit fb724ed5c6175a2407b256d506c9e703c6bb62d4 Author: Emil Goode <emil.fsw@goode.io> Date: Wed Feb 10 02:22:16 2016 +0100 wlcore: Fix regression in wlcore_set_partition() The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a regression causing the wlcore to time out and go into recovery. Reverting the changes regarding write of the last partition size brings the module back to it's functional state. Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") ? Hsmmc regression, that's Date: Wed, 10 Feb 2016 15:02:44 -0800 From: Tony Lindgren <tony@atomide.com> To: linux-omap@vger.kernel.org Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit ? Aha, but the patch this regression fixes does not seem to be in 4.4, so I should be fine unless I go to 4.5. > It does not wake up to pings from outside from off mode though > until the system wakes up. Ok, I guess I'm trying to get it to sleep, first, then we can talk about wakeup ;-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-03-23 14:37 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-23 14:37 UTC (permalink / raw) To: linux-arm-kernel On Wed 2016-02-10 17:08:18, Tony Lindgren wrote: > * Tony Lindgren <tony@atomide.com> [160209 09:26]: > > * Pavel Machek <pavel@ucw.cz> [160207 13:24]: > > > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > > > If not, the're PM runtime missing or broken somewhere. > > Just tested n900 wlan here and it's working for me with Emil's > patch from the "" thread and the PM runtime regression fix for > hsmmc I posted earlier today. Looks like n900 is hitting off > mode just fine with wlan0 configured. Emil's patch, would that be: commit fb724ed5c6175a2407b256d506c9e703c6bb62d4 Author: Emil Goode <emil.fsw@goode.io> Date: Wed Feb 10 02:22:16 2016 +0100 wlcore: Fix regression in wlcore_set_partition() The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a regression causing the wlcore to time out and go into recovery. Reverting the changes regarding write of the last partition size brings the module back to it's functional state. Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") ? Hsmmc regression, that's Date: Wed, 10 Feb 2016 15:02:44 -0800 From: Tony Lindgren <tony@atomide.com> To: linux-omap at vger.kernel.org Subject: [PATCH 1/7] mmc: omap_hsmmc: Fix PM regression with deferred probe for pm_runtime_reinit ? Aha, but the patch this regression fixes does not seem to be in 4.4, so I should be fine unless I go to 4.5. > It does not wake up to pings from outside from off mode though > until the system wakes up. Ok, I guess I'm trying to get it to sleep, first, then we can talk about wakeup ;-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-09 17:24 ` Tony Lindgren @ 2016-03-20 8:33 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-20 8:33 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! First, sorry for the delay. Busy with other projects, then tried to keep USB in 4.5 from regressing. I'm now back on 4.4 branch. > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > > entered if I simply compile-out usb). > > > > > > Depending on what the bootloader does and probably also if > > > USB was used during the booting.. So yeah you may need to modprobe > > > and then rmmod. > > > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > > push them into stable, and I should try again with them applied... > > > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > > > Ok, with that, I can insmod and rmmod. But I still get: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > I think the cm_idlest_per is fine. > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? I'm using sudo iw dev wlan0 set power_save on ; not sure if it matters. I now have: f7de3e8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 0021c072 So that bit seems to stay here. Aha... and it went off now: f7fe3e8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 0001c072 Good. I still have some work in USB disabling. > If not, the're PM runtime missing or broken somewhere. > > FYI, below is my omap3 usb test script that I use to start and > stop USB, it also works on n900. And after stopping it n900 > continues hitting deeper idle states just fine. > > That is with these two phy patches applied on v4.5-rc3: > > "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload") > "phy: twl4030-usb: Relase usb phy on unload") > > Maybe I gave you wrong info on the USB patches needed.. But these > two above are needed on v4.5-rc3. And looks like Kishon has now > applied them. Lets see... yes, I seem to have those. Messing with modules is hard in my environment, and I push kernels over usb from the "NOLO" IIRC. > Oh and I also have the MMC PM runtime regression fix here that I > have not yet posted. Will post today. But I guess you're on > v4.4 right now still. Yes. I can now go to 4.5 (or even 4.6-rc0 if needed), but I guess staying on 4.4 is easiest for now. Thanks for the script. > rmmod $udc_glue > rmmod $phy_module > rmmod $udc_module Aha, you are removing one more module; I was not working with musb_hdrc. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-03-20 8:33 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-20 8:33 UTC (permalink / raw) To: linux-arm-kernel Hi! First, sorry for the delay. Busy with other projects, then tried to keep USB in 4.5 from regressing. I'm now back on 4.4 branch. > > > > (I assume I have to insmod and rmmod, right? Because powersave is not > > > > entered if I simply compile-out usb). > > > > > > Depending on what the bootloader does and probably also if > > > USB was used during the booting.. So yeah you may need to modprobe > > > and then rmmod. > > > > > > > Would you have commit ids for those rmmod fixes? It might be good to > > > > push them into stable, and I should try again with them applied... > > > > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > > > Ok, with that, I can insmod and rmmod. But I still get: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > I think the cm_idlest_per is fine. > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? I'm using sudo iw dev wlan0 set power_save on ; not sure if it matters. I now have: f7de3e8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 0021c072 So that bit seems to stay here. Aha... and it went off now: f7fe3e8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 0001c072 Good. I still have some work in USB disabling. > If not, the're PM runtime missing or broken somewhere. > > FYI, below is my omap3 usb test script that I use to start and > stop USB, it also works on n900. And after stopping it n900 > continues hitting deeper idle states just fine. > > That is with these two phy patches applied on v4.5-rc3: > > "phy: twl4030-usb: Fix unbalanced pm_runtime_enable on module reload") > "phy: twl4030-usb: Relase usb phy on unload") > > Maybe I gave you wrong info on the USB patches needed.. But these > two above are needed on v4.5-rc3. And looks like Kishon has now > applied them. Lets see... yes, I seem to have those. Messing with modules is hard in my environment, and I push kernels over usb from the "NOLO" IIRC. > Oh and I also have the MMC PM runtime regression fix here that I > have not yet posted. Will post today. But I guess you're on > v4.4 right now still. Yes. I can now go to 4.5 (or even 4.6-rc0 if needed), but I guess staying on 4.4 is easiest for now. Thanks for the script. > rmmod $udc_glue > rmmod $phy_module > rmmod $udc_module Aha, you are removing one more module; I was not working with musb_hdrc. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-02-09 17:24 ` Tony Lindgren @ 2016-03-23 12:38 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-23 12:38 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > > > Ok, with that, I can insmod and rmmod. But I still get: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > I think the cm_idlest_per is fine. > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. > > FYI, below is my omap3 usb test script that I use to start and > stop USB, it also works on n900. And after stopping it n900 > continues hitting deeper idle states just fine. You rmmod musb_hdrc, so I checked, and found: 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1093) static void musb_shutdown(struct platform_de vice *pdev) 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1094) { 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1095) struct musb *musb = dev_to_musb(&pdev ->dev); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1096) unsigned long flags; 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1097) 4f9edd2d7 (Hema HK 2011-03-22 16:02:12 +0530 1098) pm_runtime_get_sync(musb->controller); 24307caef (Grazvydas Ignotas 2012-01-12 15:22:45 +0200 1099) 2cc65feab (Daniel Mack 2013-04-10 21:55:47 +0200 1100) musb_host_cleanup(musb); 24307caef (Grazvydas Ignotas 2012-01-12 15:22:45 +0200 1101) musb_gadget_cleanup(musb); 24307caef (Grazvydas Ignotas 2012-01-12 15:22:45 +0200 1102) 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1103) spin_lock_irqsave(&musb->lock, flags); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1104) musb_platform_disable(musb); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1105) musb_generic_disable(musb); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1106) spin_unlock_irqrestore(&musb->lock, flags ); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1107) 120d074c5 (Grazvydas Ignotas 2010-10-10 13:52:22 -0500 1108) musb_writeb(musb->mregs, MUSB_DEVCTL, 0); 120d074c5 (Grazvydas Ignotas 2010-10-10 13:52:22 -0500 1109) musb_platform_exit(musb); 120d074c5 (Grazvydas Ignotas 2010-10-10 13:52:22 -0500 1110) 4f9edd2d7 (Hema HK 2011-03-22 16:02:12 +0530 1111) pm_runtime_put(musb->controller); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1112) /* FIXME power down */ 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1113) } I thought i was responsible for the FIXME, but apparently not... If you happen to have some changes there, that would be useful to know.... Ok, another attempt at shutting USB down: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 0000000d 48004a28 (fa004a28) cm_idlest3_core Tried again today: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 0000000d 48004a28 (fa004a28) cm_idlest3_core pavel@n900:/my/tui/ofone$ sleep test 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 0000000d 48004a28 (fa004a28) cm_idlest3_core 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 fedffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 01200062 0000000d 48004a28 (fa004a28) cm_idlest3_core 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 0000000d 48004a28 (fa004a28) cm_idlest3_core Is there documentation for the cm_idlest1_ bits? How idle system do I need to have? Screen is blanked and machine should be mostly idle, but there's X running on another vt with Mate desktop, and some python scripts... GSM modem should be online. Are you booting over USB from NOLO? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-03-23 12:38 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-03-23 12:38 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > 055555fc459 ("usb: musb: core: Fix handling of the phy notifications") > > > 03e43528ab68 ("usb: musb: Fix unbalanced pm_runtime_enable") > > > > Ok, with that, I can insmod and rmmod. But I still get: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > I think the cm_idlest_per is fine. > > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go > down if do sleep 5; cat /sys/kernel/debug/pm_debug/count ? > > If not, the're PM runtime missing or broken somewhere. > > FYI, below is my omap3 usb test script that I use to start and > stop USB, it also works on n900. And after stopping it n900 > continues hitting deeper idle states just fine. You rmmod musb_hdrc, so I checked, and found: 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1093) static void musb_shutdown(struct platform_de vice *pdev) 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1094) { 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1095) struct musb *musb = dev_to_musb(&pdev ->dev); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1096) unsigned long flags; 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1097) 4f9edd2d7 (Hema HK 2011-03-22 16:02:12 +0530 1098) pm_runtime_get_sync(musb->controller); 24307caef (Grazvydas Ignotas 2012-01-12 15:22:45 +0200 1099) 2cc65feab (Daniel Mack 2013-04-10 21:55:47 +0200 1100) musb_host_cleanup(musb); 24307caef (Grazvydas Ignotas 2012-01-12 15:22:45 +0200 1101) musb_gadget_cleanup(musb); 24307caef (Grazvydas Ignotas 2012-01-12 15:22:45 +0200 1102) 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1103) spin_lock_irqsave(&musb->lock, flags); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1104) musb_platform_disable(musb); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1105) musb_generic_disable(musb); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1106) spin_unlock_irqrestore(&musb->lock, flags ); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1107) 120d074c5 (Grazvydas Ignotas 2010-10-10 13:52:22 -0500 1108) musb_writeb(musb->mregs, MUSB_DEVCTL, 0); 120d074c5 (Grazvydas Ignotas 2010-10-10 13:52:22 -0500 1109) musb_platform_exit(musb); 120d074c5 (Grazvydas Ignotas 2010-10-10 13:52:22 -0500 1110) 4f9edd2d7 (Hema HK 2011-03-22 16:02:12 +0530 1111) pm_runtime_put(musb->controller); 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1112) /* FIXME power down */ 550a7375f (Felipe Balbi 2008-07-24 12:27:36 +0300 1113) } I thought i was responsible for the FIXME, but apparently not... If you happen to have some changes there, that would be useful to know.... Ok, another attempt at shutting USB down: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 0000000d 48004a28 (fa004a28) cm_idlest3_core Tried again today: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 0000000d 48004a28 (fa004a28) cm_idlest3_core pavel at n900:/my/tui/ofone$ sleep test 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 0000000d 48004a28 (fa004a28) cm_idlest3_core 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 fedffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 01200062 0000000d 48004a28 (fa004a28) cm_idlest3_core 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 0000000d 48004a28 (fa004a28) cm_idlest3_core Is there documentation for the cm_idlest1_ bits? How idle system do I need to have? Screen is blanked and machine should be mostly idle, but there's X running on another vt with Mate desktop, and some python scripts... GSM modem should be online. Are you booting over USB from NOLO? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-03-23 12:38 ` Pavel Machek @ 2016-03-30 19:12 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-03-30 19:12 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160323 05:38]: > > Ok, another attempt at shutting USB down: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Tried again today: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > pavel@n900:/my/tui/ofone$ sleep test > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > fedffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 01200062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Is there documentation for the cm_idlest1_ bits? Yes, see the TRM. > How idle system do I need to have? Screen is blanked and machine > should be mostly idle, but there's X running on another vt with Mate > desktop, and some python scripts... GSM modem should be online. Well I think it's the USB only you have blocking deeper idle states. Are you sure you rmmod:ed all the USB related modules like in my test script? MUSB currently has an unresolved issue where it blocks idle states if loaded. > Are you booting over USB from NOLO? I'm booting over smc91x using u-boot. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-03-30 19:12 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-03-30 19:12 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160323 05:38]: > > Ok, another attempt at shutting USB down: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Tried again today: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > pavel at n900:/my/tui/ofone$ sleep test > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > fedffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 01200062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffde7e9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218062 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > Is there documentation for the cm_idlest1_ bits? Yes, see the TRM. > How idle system do I need to have? Screen is blanked and machine > should be mostly idle, but there's X running on another vt with Mate > desktop, and some python scripts... GSM modem should be online. Well I think it's the USB only you have blocking deeper idle states. Are you sure you rmmod:ed all the USB related modules like in my test script? MUSB currently has an unresolved issue where it blocks idle states if loaded. > Are you booting over USB from NOLO? I'm booting over smc91x using u-boot. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-03-30 19:12 ` Tony Lindgren @ 2016-04-04 11:09 ` Pali Rohár -1 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-04-04 11:09 UTC (permalink / raw) To: Tony Lindgren Cc: Pavel Machek, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge On Wednesday 30 March 2016 12:12:09 Tony Lindgren wrote: > > How idle system do I need to have? Screen is blanked and machine > > should be mostly idle, but there's X running on another vt with Mate > > desktop, and some python scripts... GSM modem should be online. > > Well I think it's the USB only you have blocking deeper idle states. > > Are you sure you rmmod:ed all the USB related modules like in my > test script? > > MUSB currently has an unresolved issue where it blocks idle states > if loaded. Is somebody working on this musb issue? Is there any progress? -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-04-04 11:09 ` Pali Rohár 0 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-04-04 11:09 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 30 March 2016 12:12:09 Tony Lindgren wrote: > > How idle system do I need to have? Screen is blanked and machine > > should be mostly idle, but there's X running on another vt with Mate > > desktop, and some python scripts... GSM modem should be online. > > Well I think it's the USB only you have blocking deeper idle states. > > Are you sure you rmmod:ed all the USB related modules like in my > test script? > > MUSB currently has an unresolved issue where it blocks idle states > if loaded. Is somebody working on this musb issue? Is there any progress? -- Pali Roh?r pali.rohar at gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-04-04 11:09 ` Pali Rohár @ 2016-04-04 22:31 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-04 22:31 UTC (permalink / raw) To: Pali Rohár Cc: Pavel Machek, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Bin Liu * Pali Rohár <pali.rohar@gmail.com> [160404 04:10]: > On Wednesday 30 March 2016 12:12:09 Tony Lindgren wrote: > > > How idle system do I need to have? Screen is blanked and machine > > > should be mostly idle, but there's X running on another vt with Mate > > > desktop, and some python scripts... GSM modem should be online. > > > > Well I think it's the USB only you have blocking deeper idle states. > > > > Are you sure you rmmod:ed all the USB related modules like in my > > test script? > > > > MUSB currently has an unresolved issue where it blocks idle states > > if loaded. > > Is somebody working on this musb issue? Is there any progress? No idea when I might get to it.. Please take a look if you have a chance to work on it, I think all we have to do: 1. Change musb_gadget_pullup() to run as tasklet/delayed_work to avoid trying to access I2C PHY's from atomic context. See 3e43a0725637 ("usb: musb: core: add pm_runtime_irq_safe()") for more info. Not sure if this should be done in a generic way or for MUSB only. It could be that I remember wrong what I thought needs to be done. But we want to get rid of the pm_runtime_irq_save() as that currently forever blocks PM for the MUSB hardware specific wrapper driver. 2. Remove pm_runtime_irq_safe() added in commit 3e43a0725637 Adding Bin to Cc, maybe he has some better fix in mind. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-04-04 22:31 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-04 22:31 UTC (permalink / raw) To: linux-arm-kernel * Pali Roh?r <pali.rohar@gmail.com> [160404 04:10]: > On Wednesday 30 March 2016 12:12:09 Tony Lindgren wrote: > > > How idle system do I need to have? Screen is blanked and machine > > > should be mostly idle, but there's X running on another vt with Mate > > > desktop, and some python scripts... GSM modem should be online. > > > > Well I think it's the USB only you have blocking deeper idle states. > > > > Are you sure you rmmod:ed all the USB related modules like in my > > test script? > > > > MUSB currently has an unresolved issue where it blocks idle states > > if loaded. > > Is somebody working on this musb issue? Is there any progress? No idea when I might get to it.. Please take a look if you have a chance to work on it, I think all we have to do: 1. Change musb_gadget_pullup() to run as tasklet/delayed_work to avoid trying to access I2C PHY's from atomic context. See 3e43a0725637 ("usb: musb: core: add pm_runtime_irq_safe()") for more info. Not sure if this should be done in a generic way or for MUSB only. It could be that I remember wrong what I thought needs to be done. But we want to get rid of the pm_runtime_irq_save() as that currently forever blocks PM for the MUSB hardware specific wrapper driver. 2. Remove pm_runtime_irq_safe() added in commit 3e43a0725637 Adding Bin to Cc, maybe he has some better fix in mind. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-03-30 19:12 ` Tony Lindgren @ 2016-04-04 21:30 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-04 21:30 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > How idle system do I need to have? Screen is blanked and machine > > should be mostly idle, but there's X running on another vt with Mate > > desktop, and some python scripts... GSM modem should be online. > > Well I think it's the USB only you have blocking deeper idle states. > > Are you sure you rmmod:ed all the USB related modules like in my > test script? I tested with rmmoding two, and then modified kernel to do equivalent operations. Let me try again: phy_module=phy_twl4030_usb udc_glue=omap2430 udc_module=musb_hdrc Ok, I did "start" with your script. After some fiddling it seems to work, and PC detected the values: [25379.533127] usb 1-5: USB disconnect, device number 12 [27161.884132] usb 1-5: new high-speed USB device number 13 using ehci-pci [27161.996037] usb 1-5: device descriptor read/64, error -32 [27162.420048] usb 4-1: new full-speed USB device number 2 using uhci_hcd [27162.563098] usb 4-1: not running at top speed; connect to a high speed hub [27162.601106] usb 4-1: New USB device found, idVendor=1d6b, idProduct=0106 [27162.601112] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [27162.601115] usb 4-1: Product: Multi Gadget [27162.601118] usb 4-1: Manufacturer: foo [27162.601121] usb 4-1: SerialNumber: 123456789 [27162.614766] cdc_ether 4-1:1.0 usb0: register 'cdc_ether' at usb-0000:00:1d.2-1, CDC Ethernet Device, c6:8b:83:74:f2:f3 [27163.195272] cdc_ether 4-1:1.0 usb0: kevent 12 may have been dropped Stop seemed to work, too: root@n900:/my/tui/ofone# ./gadgets.sh stop rm: cannot remove `configs/c.1/acm.0': No such file or directory rm: cannot remove `configs/c.5/acm.0': No such file or directory rmdir: failed to remove `functions/acm.0': No such file or directory ./gadgets.sh: line 74: functions/mass_storage.0/lun.0/file: No such file or directory rm: cannot remove `configs/c.1/mass_storage.0': No such file or directory rm: cannot remove `configs/c.5/mass_storage.0': No such file or directory rmdir: failed to remove `functions/mass_storage.0': No such file or directory root@n900:/my/tui/ofone# lsmod Module Size Used by root@n900:/my/tui/ofone# Display off, on wifi: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 0000000d 48004a28 (fa004a28) cm_idlest3_core 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 ..so I believe gadget bits are still set. > I'm booting over smc91x using u-boot. I'm booting directly from NOLO over usb. Machine is running X, but they are not active -- chvt. Screen is off. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-04-04 21:30 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-04 21:30 UTC (permalink / raw) To: linux-arm-kernel Hi! > > How idle system do I need to have? Screen is blanked and machine > > should be mostly idle, but there's X running on another vt with Mate > > desktop, and some python scripts... GSM modem should be online. > > Well I think it's the USB only you have blocking deeper idle states. > > Are you sure you rmmod:ed all the USB related modules like in my > test script? I tested with rmmoding two, and then modified kernel to do equivalent operations. Let me try again: phy_module=phy_twl4030_usb udc_glue=omap2430 udc_module=musb_hdrc Ok, I did "start" with your script. After some fiddling it seems to work, and PC detected the values: [25379.533127] usb 1-5: USB disconnect, device number 12 [27161.884132] usb 1-5: new high-speed USB device number 13 using ehci-pci [27161.996037] usb 1-5: device descriptor read/64, error -32 [27162.420048] usb 4-1: new full-speed USB device number 2 using uhci_hcd [27162.563098] usb 4-1: not running at top speed; connect to a high speed hub [27162.601106] usb 4-1: New USB device found, idVendor=1d6b, idProduct=0106 [27162.601112] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [27162.601115] usb 4-1: Product: Multi Gadget [27162.601118] usb 4-1: Manufacturer: foo [27162.601121] usb 4-1: SerialNumber: 123456789 [27162.614766] cdc_ether 4-1:1.0 usb0: register 'cdc_ether' at usb-0000:00:1d.2-1, CDC Ethernet Device, c6:8b:83:74:f2:f3 [27163.195272] cdc_ether 4-1:1.0 usb0: kevent 12 may have been dropped Stop seemed to work, too: root at n900:/my/tui/ofone# ./gadgets.sh stop rm: cannot remove `configs/c.1/acm.0': No such file or directory rm: cannot remove `configs/c.5/acm.0': No such file or directory rmdir: failed to remove `functions/acm.0': No such file or directory ./gadgets.sh: line 74: functions/mass_storage.0/lun.0/file: No such file or directory rm: cannot remove `configs/c.1/mass_storage.0': No such file or directory rm: cannot remove `configs/c.5/mass_storage.0': No such file or directory rmdir: failed to remove `functions/mass_storage.0': No such file or directory root at n900:/my/tui/ofone# lsmod Module Size Used by root at n900:/my/tui/ofone# Display off, on wifi: 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 0000000d 48004a28 (fa004a28) cm_idlest3_core 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 ..so I believe gadget bits are still set. > I'm booting over smc91x using u-boot. I'm booting directly from NOLO over usb. Machine is running X, but they are not active -- chvt. Screen is off. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-04-04 21:30 ` Pavel Machek @ 2016-04-04 22:07 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-04 22:07 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160404 14:31]: > > Display off, on wifi: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > ..so I believe gadget bits are still set. Nope, you got PM working now for the USB as it's now ending with 0x42 instead of 0x62 :) You still have bit 21 blocking, sorry don't remember what that one is, but that's in the TRM for idlest1 register. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-04-04 22:07 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-04 22:07 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160404 14:31]: > > Display off, on wifi: > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > ..so I believe gadget bits are still set. Nope, you got PM working now for the USB as it's now ending with 0x42 instead of 0x62 :) You still have bit 21 blocking, sorry don't remember what that one is, but that's in the TRM for idlest1 register. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-04-04 22:07 ` Tony Lindgren @ 2016-04-05 10:09 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 10:09 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge On Mon 2016-04-04 15:07:49, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [160404 14:31]: > > > > Display off, on wifi: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > > ..so I believe gadget bits are still set. > > Nope, you got PM working now for the USB as it's now ending with 0x42 > instead of 0x62 :) You still have bit 21 blocking, sorry don't > remember what that one is, but that's in the TRM for idlest1 > register. Aha... I thought the "0x42" was the problem, not "0x30". That was going on and off for me for a long while. Actually, I don't think I did anything special with USB gadget in this boot, and it is still 0x42. Bit 21 is wifi, AFAICT. With right sleeps between reading the debug file and talking to wifi, I now get: Battery 4.16V 4.18V 4.14V 95% 93% 100% 1569/1569 mAh Charging 49/650/1800 mA fffffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 Battery 4.16V 4.18V 4.14V 95% 93% 100% 1569/1569 mAh Charging 48/650/1800 mA fffffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0x02 seems to be SDRC. 0x40 seems to be OMAPCTRL I get 0x18000 randomly, too. That should be I2C1, and I2C2. But even when idlest1_blocking_bits are 0x42, the left and right backlight on keyboard is lit constantly -- not blinking -- indicating that it is still not sleeping. Full debug is: Battery 4.15V 4.18V 4.13V 94% 93% 100% 1569/1569 mAh Charging 29/650/1800 mA usbhost_pwrdm (ON),OFF:12183,RET:277831,INA:0,ON:290015,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:12183,RET:0,INA:0,ON:12184,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:12183,RET:267009,INA:0,ON:279193,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (ON),OFF:12183,RET:277826,INA:2,ON:290012,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:12183,RET:277832,INA:0,ON:290016,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:12183,RET:277830,INA:0,ON:290014,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (1) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (19) cam_clkdm->cam_pwrdm (1) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (19) core_l3_clkdm->core_pwrdm (1) neon_clkdm->neon_pwrdm (0) 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 fffffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0000000d 48004a28 (fa004a28) cm_idlest3_core ^CTraceback (most recent call last): File "./sleepmond", line 24, in <module> time.sleep(5) KeyboardInterrupt Anything else I should look at? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-04-05 10:09 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 10:09 UTC (permalink / raw) To: linux-arm-kernel On Mon 2016-04-04 15:07:49, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [160404 14:31]: > > > > Display off, on wifi: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > > ..so I believe gadget bits are still set. > > Nope, you got PM working now for the USB as it's now ending with 0x42 > instead of 0x62 :) You still have bit 21 blocking, sorry don't > remember what that one is, but that's in the TRM for idlest1 > register. Aha... I thought the "0x42" was the problem, not "0x30". That was going on and off for me for a long while. Actually, I don't think I did anything special with USB gadget in this boot, and it is still 0x42. Bit 21 is wifi, AFAICT. With right sleeps between reading the debug file and talking to wifi, I now get: Battery 4.16V 4.18V 4.14V 95% 93% 100% 1569/1569 mAh Charging 49/650/1800 mA fffffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 Battery 4.16V 4.18V 4.14V 95% 93% 100% 1569/1569 mAh Charging 48/650/1800 mA fffffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0x02 seems to be SDRC. 0x40 seems to be OMAPCTRL I get 0x18000 randomly, too. That should be I2C1, and I2C2. But even when idlest1_blocking_bits are 0x42, the left and right backlight on keyboard is lit constantly -- not blinking -- indicating that it is still not sleeping. Full debug is: Battery 4.15V 4.18V 4.13V 94% 93% 100% 1569/1569 mAh Charging 29/650/1800 mA usbhost_pwrdm (ON),OFF:12183,RET:277831,INA:0,ON:290015,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:12183,RET:0,INA:0,ON:12184,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:12183,RET:267009,INA:0,ON:279193,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (ON),OFF:12183,RET:277826,INA:2,ON:290012,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:12183,RET:277832,INA:0,ON:290016,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:12183,RET:277830,INA:0,ON:290014,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (1) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (19) cam_clkdm->cam_pwrdm (1) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (19) core_l3_clkdm->core_pwrdm (1) neon_clkdm->neon_pwrdm (0) 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 fffffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0000000d 48004a28 (fa004a28) cm_idlest3_core ^CTraceback (most recent call last): File "./sleepmond", line 24, in <module> time.sleep(5) KeyboardInterrupt Anything else I should look at? Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: N900 sleep mode (in 4.5-rc0, if that matters) 2016-04-04 22:07 ` Tony Lindgren @ 2016-04-05 13:17 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 13:17 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > > Display off, on wifi: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > > ..so I believe gadget bits are still set. > > Nope, you got PM working now for the USB as it's now ending with 0x42 > instead of 0x62 :) You still have bit 21 blocking, sorry don't > remember what that one is, but that's in the TRM for idlest1 > register. Looking more through the registers... GPIO banks seem to be listed in cm_idlest_per. You mentioned that they should be automatically controlled? Does that still work when they are exported to the userspace? pavel@n900:~$ ls /sys/class/gpio/ export gpio177 gpio73 gpio75 gpiochip128 gpiochip32 gpiochip64 unexport gpio157 gpio70 gpio74 gpiochip0 gpiochip160 gpiochip494 gpiochip96 Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* N900 sleep mode (in 4.5-rc0, if that matters) @ 2016-04-05 13:17 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 13:17 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > Display off, on wifi: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > > ..so I believe gadget bits are still set. > > Nope, you got PM working now for the USB as it's now ending with 0x42 > instead of 0x62 :) You still have bit 21 blocking, sorry don't > remember what that one is, but that's in the TRM for idlest1 > register. Looking more through the registers... GPIO banks seem to be listed in cm_idlest_per. You mentioned that they should be automatically controlled? Does that still work when they are exported to the userspace? pavel at n900:~$ ls /sys/class/gpio/ export gpio177 gpio73 gpio75 gpiochip128 gpiochip32 gpiochip64 unexport gpio157 gpio70 gpio74 gpiochip0 gpiochip160 gpiochip494 gpiochip96 Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-04 22:07 ` Tony Lindgren @ 2016-04-05 14:22 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 14:22 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > * Pavel Machek <pavel@ucw.cz> [160404 14:31]: > > > > Display off, on wifi: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > > ..so I believe gadget bits are still set. > > Nope, you got PM working now for the USB as it's now ending with 0x42 > instead of 0x62 :) You still have bit 21 blocking, sorry don't > remember what that one is, but that's in the TRM for idlest1 > register. Ok, I realized that _something_ set up my keyboard on console, too, so I'm able to do "init 1" and still interact with the console. cm_idlest1_core blocking bits are now 0x42 pretty consistently. But they stay 0x42, even when screen is on (and screen on prevents low power, right?) so I guess they are not the whole story. I'm able to get down to 50mA power consumption with screen off. I was getting 90mA with X, wifi in powersave and screen off. Head proximity sensor is still on in this configuration. But I guess that should not keep the system busy...? Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and "Lock button" interrupts ... at something like 20/second. Without touching anything. Hmm. Also "pm_wkup", but that might be expected. Plus, 49052000.gpio and 49054000.gpio are rather active. Might be related to the above. Also "gp_timer" and 48070000.i2c are active, perhaps also related. I don't think I have the camera working... "Lock button" interrupt stops increasing as long as I hold the lock button in the "unlock" position. "Camera Focus" and "Camera Capture" will stop increasing when I hold down the Camera button. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-05 14:22 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 14:22 UTC (permalink / raw) To: linux-arm-kernel Hi! > * Pavel Machek <pavel@ucw.cz> [160404 14:31]: > > > > Display off, on wifi: > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > 0000000d 48004a28 (fa004a28) cm_idlest3_core > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffde7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042 > > > > 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042 > > > > ..so I believe gadget bits are still set. > > Nope, you got PM working now for the USB as it's now ending with 0x42 > instead of 0x62 :) You still have bit 21 blocking, sorry don't > remember what that one is, but that's in the TRM for idlest1 > register. Ok, I realized that _something_ set up my keyboard on console, too, so I'm able to do "init 1" and still interact with the console. cm_idlest1_core blocking bits are now 0x42 pretty consistently. But they stay 0x42, even when screen is on (and screen on prevents low power, right?) so I guess they are not the whole story. I'm able to get down to 50mA power consumption with screen off. I was getting 90mA with X, wifi in powersave and screen off. Head proximity sensor is still on in this configuration. But I guess that should not keep the system busy...? Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and "Lock button" interrupts ... at something like 20/second. Without touching anything. Hmm. Also "pm_wkup", but that might be expected. Plus, 49052000.gpio and 49054000.gpio are rather active. Might be related to the above. Also "gp_timer" and 48070000.i2c are active, perhaps also related. I don't think I have the camera working... "Lock button" interrupt stops increasing as long as I hold the lock button in the "unlock" position. "Camera Focus" and "Camera Capture" will stop increasing when I hold down the Camera button. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-05 14:22 ` Pavel Machek @ 2016-04-05 15:29 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-05 15:29 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160405 07:23]: > > Ok, I realized that _something_ set up my keyboard on console, too, so > I'm able to do "init 1" and still interact with the console. > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > they stay 0x42, even when screen is on (and screen on prevents low > power, right?) so I guess they are not the whole story. Yes they stay at 0x42. And it seems you've configured the UART idle timeouts too. > I'm able to get down to 50mA power consumption with screen off. I was > getting 90mA with X, wifi in powersave and screen off. > > Head proximity sensor is still on in this configuration. But I guess > that should not keep the system busy...? > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > "Lock button" interrupts ... at something like 20/second. Without > touching anything. Hmm. Also "pm_wkup", but that might be > expected. Plus, 49052000.gpio and 49054000.gpio are rather > active. Might be related to the above. Also "gp_timer" and > 48070000.i2c are active, perhaps also related. I don't think I have > the camera working... Hmm that does not sound right at all for the GPIOs. The pm_wkup interrupt triggers every time you hit wfi pretty much, so that should be OK. > "Lock button" interrupt stops increasing as long as I hold the lock > button in the "unlock" position. "Camera Focus" and "Camera Capture" > will stop increasing when I hold down the Camera button. I have not seen that issue last time I checked. Sorry won't be able to test it until Thursday, maybe there's some GPIO regression now. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-05 15:29 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-05 15:29 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160405 07:23]: > > Ok, I realized that _something_ set up my keyboard on console, too, so > I'm able to do "init 1" and still interact with the console. > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > they stay 0x42, even when screen is on (and screen on prevents low > power, right?) so I guess they are not the whole story. Yes they stay at 0x42. And it seems you've configured the UART idle timeouts too. > I'm able to get down to 50mA power consumption with screen off. I was > getting 90mA with X, wifi in powersave and screen off. > > Head proximity sensor is still on in this configuration. But I guess > that should not keep the system busy...? > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > "Lock button" interrupts ... at something like 20/second. Without > touching anything. Hmm. Also "pm_wkup", but that might be > expected. Plus, 49052000.gpio and 49054000.gpio are rather > active. Might be related to the above. Also "gp_timer" and > 48070000.i2c are active, perhaps also related. I don't think I have > the camera working... Hmm that does not sound right at all for the GPIOs. The pm_wkup interrupt triggers every time you hit wfi pretty much, so that should be OK. > "Lock button" interrupt stops increasing as long as I hold the lock > button in the "unlock" position. "Camera Focus" and "Camera Capture" > will stop increasing when I hold down the Camera button. I have not seen that issue last time I checked. Sorry won't be able to test it until Thursday, maybe there's some GPIO regression now. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-05 15:29 ` Tony Lindgren @ 2016-04-05 20:51 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 20:51 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > Ok, I realized that _something_ set up my keyboard on console, too, so > > I'm able to do "init 1" and still interact with the console. > > > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > > they stay 0x42, even when screen is on (and screen on prevents low > > power, right?) so I guess they are not the whole story. > > Yes they stay at 0x42. And it seems you've configured the UART > idle timeouts too. Yes, thanks for the script ;-). > > I'm able to get down to 50mA power consumption with screen off. I was > > getting 90mA with X, wifi in powersave and screen off. > > > > Head proximity sensor is still on in this configuration. But I guess > > that should not keep the system busy...? > > > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > > "Lock button" interrupts ... at something like 20/second. Without > > touching anything. Hmm. Also "pm_wkup", but that might be > > expected. Plus, 49052000.gpio and 49054000.gpio are rather > > active. Might be related to the above. Also "gp_timer" and > > 48070000.i2c are active, perhaps also related. I don't think I have > > the camera working... > > Hmm that does not sound right at all for the GPIOs. The pm_wkup > interrupt triggers every time you hit wfi pretty much, so that > should be OK. Wifi was down at that point. Some more testing: after boot, interrupt counts stay low, as expected. But when I attempt to enable power management, they start rising. Sometimes 60/second, sometimes less. Things are fine as long as I don't enable the off mode; when I enable the off mode, "echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode" interrupt counts start rising immediately. "echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode" stops that. But no matter what configuration, activity LEDs still indicate it is busy, and idle power consumption is cca 53mA. > > "Lock button" interrupt stops increasing as long as I hold the lock > > button in the "unlock" position. "Camera Focus" and "Camera Capture" > > will stop increasing when I hold down the Camera button. > > I have not seen that issue last time I checked. Sorry won't > be able to test it until Thursday, maybe there's some GPIO > regression now. No problem, thanks for all the help. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-05 20:51 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-05 20:51 UTC (permalink / raw) To: linux-arm-kernel Hi! > > Ok, I realized that _something_ set up my keyboard on console, too, so > > I'm able to do "init 1" and still interact with the console. > > > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > > they stay 0x42, even when screen is on (and screen on prevents low > > power, right?) so I guess they are not the whole story. > > Yes they stay at 0x42. And it seems you've configured the UART > idle timeouts too. Yes, thanks for the script ;-). > > I'm able to get down to 50mA power consumption with screen off. I was > > getting 90mA with X, wifi in powersave and screen off. > > > > Head proximity sensor is still on in this configuration. But I guess > > that should not keep the system busy...? > > > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > > "Lock button" interrupts ... at something like 20/second. Without > > touching anything. Hmm. Also "pm_wkup", but that might be > > expected. Plus, 49052000.gpio and 49054000.gpio are rather > > active. Might be related to the above. Also "gp_timer" and > > 48070000.i2c are active, perhaps also related. I don't think I have > > the camera working... > > Hmm that does not sound right at all for the GPIOs. The pm_wkup > interrupt triggers every time you hit wfi pretty much, so that > should be OK. Wifi was down at that point. Some more testing: after boot, interrupt counts stay low, as expected. But when I attempt to enable power management, they start rising. Sometimes 60/second, sometimes less. Things are fine as long as I don't enable the off mode; when I enable the off mode, "echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode" interrupt counts start rising immediately. "echo 0 > /sys/kernel/debug/pm_debug/enable_off_mode" stops that. But no matter what configuration, activity LEDs still indicate it is busy, and idle power consumption is cca 53mA. > > "Lock button" interrupt stops increasing as long as I hold the lock > > button in the "unlock" position. "Camera Focus" and "Camera Capture" > > will stop increasing when I hold down the Camera button. > > I have not seen that issue last time I checked. Sorry won't > be able to test it until Thursday, maybe there's some GPIO > regression now. No problem, thanks for all the help. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-05 20:51 ` Pavel Machek @ 2016-04-07 17:40 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-07 17:40 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi, * Pavel Machek <pavel@ucw.cz> [160405 13:52]: > Hi! > > > > Ok, I realized that _something_ set up my keyboard on console, too, so > > > I'm able to do "init 1" and still interact with the console. > > > > > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > > > they stay 0x42, even when screen is on (and screen on prevents low > > > power, right?) so I guess they are not the whole story. > > > > Yes they stay at 0x42. And it seems you've configured the UART > > idle timeouts too. > > Yes, thanks for the script ;-). > > > > I'm able to get down to 50mA power consumption with screen off. I was > > > getting 90mA with X, wifi in powersave and screen off. > > > > > > Head proximity sensor is still on in this configuration. But I guess > > > that should not keep the system busy...? > > > > > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > > > "Lock button" interrupts ... at something like 20/second. Without > > > touching anything. Hmm. Also "pm_wkup", but that might be > > > expected. Plus, 49052000.gpio and 49054000.gpio are rather > > > active. Might be related to the above. Also "gp_timer" and > > > 48070000.i2c are active, perhaps also related. I don't think I have > > > the camera working... > > > > Hmm that does not sound right at all for the GPIOs. The pm_wkup > > interrupt triggers every time you hit wfi pretty much, so that > > should be OK. > > Wifi was down at that point. > > Some more testing: after boot, interrupt counts stay low, as > expected. But when I attempt to enable power management, they start > rising. Sometimes 60/second, sometimes less. > > Things are fine as long as I don't enable the off mode; when I enable > the off mode, "echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode" > interrupt counts start rising immediately. "echo 0 > > /sys/kernel/debug/pm_debug/enable_off_mode" stops that. > > But no matter what configuration, activity LEDs still indicate it is > busy, and idle power consumption is cca 53mA. Not seeing that here at all. My n900 with v4.6-rc2 and omap2plus_defconfig booted with u-boot keeps hitting off mode with both LEDs going off just fine. It's waking up about once a second or a litte bit more often. Care to post your .config somewhere, I could give that a try? Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-07 17:40 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-07 17:40 UTC (permalink / raw) To: linux-arm-kernel Hi, * Pavel Machek <pavel@ucw.cz> [160405 13:52]: > Hi! > > > > Ok, I realized that _something_ set up my keyboard on console, too, so > > > I'm able to do "init 1" and still interact with the console. > > > > > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > > > they stay 0x42, even when screen is on (and screen on prevents low > > > power, right?) so I guess they are not the whole story. > > > > Yes they stay at 0x42. And it seems you've configured the UART > > idle timeouts too. > > Yes, thanks for the script ;-). > > > > I'm able to get down to 50mA power consumption with screen off. I was > > > getting 90mA with X, wifi in powersave and screen off. > > > > > > Head proximity sensor is still on in this configuration. But I guess > > > that should not keep the system busy...? > > > > > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > > > "Lock button" interrupts ... at something like 20/second. Without > > > touching anything. Hmm. Also "pm_wkup", but that might be > > > expected. Plus, 49052000.gpio and 49054000.gpio are rather > > > active. Might be related to the above. Also "gp_timer" and > > > 48070000.i2c are active, perhaps also related. I don't think I have > > > the camera working... > > > > Hmm that does not sound right at all for the GPIOs. The pm_wkup > > interrupt triggers every time you hit wfi pretty much, so that > > should be OK. > > Wifi was down at that point. > > Some more testing: after boot, interrupt counts stay low, as > expected. But when I attempt to enable power management, they start > rising. Sometimes 60/second, sometimes less. > > Things are fine as long as I don't enable the off mode; when I enable > the off mode, "echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode" > interrupt counts start rising immediately. "echo 0 > > /sys/kernel/debug/pm_debug/enable_off_mode" stops that. > > But no matter what configuration, activity LEDs still indicate it is > busy, and idle power consumption is cca 53mA. Not seeing that here at all. My n900 with v4.6-rc2 and omap2plus_defconfig booted with u-boot keeps hitting off mode with both LEDs going off just fine. It's waking up about once a second or a litte bit more often. Care to post your .config somewhere, I could give that a try? Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-07 17:40 ` Tony Lindgren @ 2016-04-07 19:48 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-07 19:48 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge [-- Attachment #1: Type: text/plain, Size: 3787 bytes --] Hi! > > > > Ok, I realized that _something_ set up my keyboard on console, too, so > > > > I'm able to do "init 1" and still interact with the console. > > > > > > > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > > > > they stay 0x42, even when screen is on (and screen on prevents low > > > > power, right?) so I guess they are not the whole story. > > > > > > Yes they stay at 0x42. And it seems you've configured the UART > > > idle timeouts too. > > > > Yes, thanks for the script ;-). > > > > > > I'm able to get down to 50mA power consumption with screen off. I was > > > > getting 90mA with X, wifi in powersave and screen off. > > > > > > > > Head proximity sensor is still on in this configuration. But I guess > > > > that should not keep the system busy...? > > > > > > > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > > > > "Lock button" interrupts ... at something like 20/second. Without > > > > touching anything. Hmm. Also "pm_wkup", but that might be > > > > expected. Plus, 49052000.gpio and 49054000.gpio are rather > > > > active. Might be related to the above. Also "gp_timer" and > > > > 48070000.i2c are active, perhaps also related. I don't think I have > > > > the camera working... > > > > > > Hmm that does not sound right at all for the GPIOs. The pm_wkup > > > interrupt triggers every time you hit wfi pretty much, so that > > > should be OK. > > > > Wifi was down at that point. > > > > Some more testing: after boot, interrupt counts stay low, as > > expected. But when I attempt to enable power management, they start > > rising. Sometimes 60/second, sometimes less. > > > > Things are fine as long as I don't enable the off mode; when I enable > > the off mode, "echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode" > > interrupt counts start rising immediately. "echo 0 > > > /sys/kernel/debug/pm_debug/enable_off_mode" stops that. > > > > But no matter what configuration, activity LEDs still indicate it is > > busy, and idle power consumption is cca 53mA. > > Not seeing that here at all. My n900 with v4.6-rc2 and omap2plus_defconfig > booted with u-boot keeps hitting off mode with both LEDs going off just > fine. It's waking up about once a second or a litte bit more often. Ok, that was 4.4 (with patches that should not be related). I now checked with 4.6-rc2+mini_changes, and I'm getting similar results: Battery 4.05V 4.07V 4.11V 85% 91% 98% 1546/1569 mAh Full -131/550/100 mA 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7fffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0000000d 48004a28 (fa004a28) cm_idlest3_core I'm booting from NOLO, and I'm _not_ loading/removing gadget modules, as blocking bits are 0x42, so gadget is not a problem. (Let me know if I'm wrong). Let me retry with 4.6-rc2 (9735a22799b9214d17d3c231fe377fc852f042e9), no modifications. Aha, but vanilla 4.6-rc2 does not have cm_idlest1_core display in debugfs :-(. And yes, I see the same effect in /proc/interrupts: 180: 280 49052000.gpio 4 Edge Camera Focus 181: 280 49052000.gpio 5 Edge Camera Capture (few seconds after that) 180: 738 49052000.gpio 4 Edge Camera Focus 181: 738 49052000.gpio 5 Edge Camera Capture after I do echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode . > Care to post your .config somewhere, I could give that a try? gzipped config is attached. Note that I'm still using NOLO. I enabled the sleep, then went to runlevel 1. LEDs still stay on, 55mA power consumption. That was with 1 in off_mode. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 24857 bytes --] ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-07 19:48 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-07 19:48 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > Ok, I realized that _something_ set up my keyboard on console, too, so > > > > I'm able to do "init 1" and still interact with the console. > > > > > > > > cm_idlest1_core blocking bits are now 0x42 pretty consistently. But > > > > they stay 0x42, even when screen is on (and screen on prevents low > > > > power, right?) so I guess they are not the whole story. > > > > > > Yes they stay at 0x42. And it seems you've configured the UART > > > idle timeouts too. > > > > Yes, thanks for the script ;-). > > > > > > I'm able to get down to 50mA power consumption with screen off. I was > > > > getting 90mA with X, wifi in powersave and screen off. > > > > > > > > Head proximity sensor is still on in this configuration. But I guess > > > > that should not keep the system busy...? > > > > > > > > Ok, wait a moment, I'm getting "Camera Focus", "Camera Capture" and > > > > "Lock button" interrupts ... at something like 20/second. Without > > > > touching anything. Hmm. Also "pm_wkup", but that might be > > > > expected. Plus, 49052000.gpio and 49054000.gpio are rather > > > > active. Might be related to the above. Also "gp_timer" and > > > > 48070000.i2c are active, perhaps also related. I don't think I have > > > > the camera working... > > > > > > Hmm that does not sound right at all for the GPIOs. The pm_wkup > > > interrupt triggers every time you hit wfi pretty much, so that > > > should be OK. > > > > Wifi was down at that point. > > > > Some more testing: after boot, interrupt counts stay low, as > > expected. But when I attempt to enable power management, they start > > rising. Sometimes 60/second, sometimes less. > > > > Things are fine as long as I don't enable the off mode; when I enable > > the off mode, "echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode" > > interrupt counts start rising immediately. "echo 0 > > > /sys/kernel/debug/pm_debug/enable_off_mode" stops that. > > > > But no matter what configuration, activity LEDs still indicate it is > > busy, and idle power consumption is cca 53mA. > > Not seeing that here at all. My n900 with v4.6-rc2 and omap2plus_defconfig > booted with u-boot keeps hitting off mode with both LEDs going off just > fine. It's waking up about once a second or a litte bit more often. Ok, that was 4.4 (with patches that should not be related). I now checked with 4.6-rc2+mini_changes, and I'm getting similar results: Battery 4.05V 4.07V 4.11V 85% 91% 98% 1546/1569 mAh Full -131/550/100 mA 00001fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000 f7fffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00000042 0000000d 48004a28 (fa004a28) cm_idlest3_core I'm booting from NOLO, and I'm _not_ loading/removing gadget modules, as blocking bits are 0x42, so gadget is not a problem. (Let me know if I'm wrong). Let me retry with 4.6-rc2 (9735a22799b9214d17d3c231fe377fc852f042e9), no modifications. Aha, but vanilla 4.6-rc2 does not have cm_idlest1_core display in debugfs :-(. And yes, I see the same effect in /proc/interrupts: 180: 280 49052000.gpio 4 Edge Camera Focus 181: 280 49052000.gpio 5 Edge Camera Capture (few seconds after that) 180: 738 49052000.gpio 4 Edge Camera Focus 181: 738 49052000.gpio 5 Edge Camera Capture after I do echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode . > Care to post your .config somewhere, I could give that a try? gzipped config is attached. Note that I'm still using NOLO. I enabled the sleep, then went to runlevel 1. LEDs still stay on, 55mA power consumption. That was with 1 in off_mode. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -------------- next part -------------- A non-text attachment was scrubbed... Name: config.gz Type: application/gzip Size: 24857 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160407/6f758f45/attachment-0001.gz> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-07 19:48 ` Pavel Machek @ 2016-04-07 21:32 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-07 21:32 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160407 12:49]: > > gzipped config is attached. > > Note that I'm still using NOLO. I enabled the sleep, then went to > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > 1 in off_mode. Nothing idling for me with your .config.. And it seems slower to boot compared to omap2plus_defconfig? Maybe because of the extra GPIO interrupts? Looks like you have 117 additional entries in .config enabled compared to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal changes and verify it idles properly first? I'm suspecting it's some driver(s) you have enabled causing the issue. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-07 21:32 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-07 21:32 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160407 12:49]: > > gzipped config is attached. > > Note that I'm still using NOLO. I enabled the sleep, then went to > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > 1 in off_mode. Nothing idling for me with your .config.. And it seems slower to boot compared to omap2plus_defconfig? Maybe because of the extra GPIO interrupts? Looks like you have 117 additional entries in .config enabled compared to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal changes and verify it idles properly first? I'm suspecting it's some driver(s) you have enabled causing the issue. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-07 21:32 ` Tony Lindgren @ 2016-04-07 23:01 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-07 23:01 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > gzipped config is attached. > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > 1 in off_mode. > > Nothing idling for me with your .config.. And it seems slower to boot > compared to omap2plus_defconfig? Maybe because of the extra GPIO > interrupts? Extra interrupts only happen when enable_off_mode is 1, so that should not be an issue during boot. > Looks like you have 117 additional entries in .config enabled compared > to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal > changes and verify it idles properly first? > > I'm suspecting it's some driver(s) you have enabled causing the > issue. I guess so. Do you (or anyone else) have minimum non-modular config for N900 that boots with video? Could I get lsmod from your system? (Yes, I still have nightmares from getting .config that works). Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-07 23:01 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-07 23:01 UTC (permalink / raw) To: linux-arm-kernel Hi! > > gzipped config is attached. > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > 1 in off_mode. > > Nothing idling for me with your .config.. And it seems slower to boot > compared to omap2plus_defconfig? Maybe because of the extra GPIO > interrupts? Extra interrupts only happen when enable_off_mode is 1, so that should not be an issue during boot. > Looks like you have 117 additional entries in .config enabled compared > to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal > changes and verify it idles properly first? > > I'm suspecting it's some driver(s) you have enabled causing the > issue. I guess so. Do you (or anyone else) have minimum non-modular config for N900 that boots with video? Could I get lsmod from your system? (Yes, I still have nightmares from getting .config that works). Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-07 23:01 ` Pavel Machek @ 2016-04-07 23:41 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-07 23:41 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Pavel Machek <pavel@ucw.cz> [160407 16:02]: > Hi! > > > > gzipped config is attached. > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > 1 in off_mode. > > > > Nothing idling for me with your .config.. And it seems slower to boot > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > interrupts? > > Extra interrupts only happen when enable_off_mode is 1, so that should > not be an issue during boot. OK maybe it's just the extra driver probe time then. > > Looks like you have 117 additional entries in .config enabled compared > > to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal > > changes and verify it idles properly first? > > > > I'm suspecting it's some driver(s) you have enabled causing the > > issue. > > I guess so. Do you (or anyone else) have minimum non-modular config > for N900 that boots with video? Could I get lsmod from your system? > (Yes, I still have nightmares from getting .config that works). Well I've been just using omap2plus_defconfig with: # modprobe tsc2005 # modprobe gpio_backlight # modprobe panel_sony_acx565akm # modprobe omapfb # echo 255 > /sys/class/backlight/acx565akm/brightness And then the following to blank for idle: # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank But in the world of eternal regressions, I'm not seeing anything on the framebuffer with v4.6-rc2 :( No idea what broke it or when as my n900 is in the rack. Anyways, below is also my lsmod output. Regards, Tony Module Size Used by panel_sharp_ls037v7dw01 4148 0 ads7846 12959 0 hwmon 4213 1 ads7846 gpio_keys 9053 0 twl4030_keypad 3896 0 matrix_keymap 2801 1 twl4030_keypad omapfb 39255 1 cfbfillrect 3614 1 omapfb cfbimgblt 2416 1 omapfb cfbcopyarea 3187 1 omapfb panel_sony_acx565akm 7895 1 omapdss 269684 4 panel_sharp_ls037v7dw01,omapfb,panel_sony_acx565akm gpio_backlight 2804 0 tsc2005 1782 0 tsc200x_core 7337 1 tsc2005 ledtrig_default_on 1119 0 leds_gpio 3530 0 led_class 5418 1 leds_gpio rtc_twl 6234 0 twl4030_wdt 2711 0 ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-07 23:41 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-07 23:41 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160407 16:02]: > Hi! > > > > gzipped config is attached. > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > 1 in off_mode. > > > > Nothing idling for me with your .config.. And it seems slower to boot > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > interrupts? > > Extra interrupts only happen when enable_off_mode is 1, so that should > not be an issue during boot. OK maybe it's just the extra driver probe time then. > > Looks like you have 117 additional entries in .config enabled compared > > to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal > > changes and verify it idles properly first? > > > > I'm suspecting it's some driver(s) you have enabled causing the > > issue. > > I guess so. Do you (or anyone else) have minimum non-modular config > for N900 that boots with video? Could I get lsmod from your system? > (Yes, I still have nightmares from getting .config that works). Well I've been just using omap2plus_defconfig with: # modprobe tsc2005 # modprobe gpio_backlight # modprobe panel_sony_acx565akm # modprobe omapfb # echo 255 > /sys/class/backlight/acx565akm/brightness And then the following to blank for idle: # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank But in the world of eternal regressions, I'm not seeing anything on the framebuffer with v4.6-rc2 :( No idea what broke it or when as my n900 is in the rack. Anyways, below is also my lsmod output. Regards, Tony Module Size Used by panel_sharp_ls037v7dw01 4148 0 ads7846 12959 0 hwmon 4213 1 ads7846 gpio_keys 9053 0 twl4030_keypad 3896 0 matrix_keymap 2801 1 twl4030_keypad omapfb 39255 1 cfbfillrect 3614 1 omapfb cfbimgblt 2416 1 omapfb cfbcopyarea 3187 1 omapfb panel_sony_acx565akm 7895 1 omapdss 269684 4 panel_sharp_ls037v7dw01,omapfb,panel_sony_acx565akm gpio_backlight 2804 0 tsc2005 1782 0 tsc200x_core 7337 1 tsc2005 ledtrig_default_on 1119 0 leds_gpio 3530 0 led_class 5418 1 leds_gpio rtc_twl 6234 0 twl4030_wdt 2711 0 ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-07 23:41 ` Tony Lindgren @ 2016-04-08 9:19 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-08 9:19 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > Looks like you have 117 additional entries in .config enabled compared > > > to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal > > > changes and verify it idles properly first? > > > > > > I'm suspecting it's some driver(s) you have enabled causing the > > > issue. > > > > I guess so. Do you (or anyone else) have minimum non-modular config > > for N900 that boots with video? Could I get lsmod from your system? > > (Yes, I still have nightmares from getting .config that works). > > Well I've been just using omap2plus_defconfig with: > > # modprobe tsc2005 > # modprobe gpio_backlight > # modprobe panel_sony_acx565akm > # modprobe omapfb > > # echo 255 > /sys/class/backlight/acx565akm/brightness > > And then the following to blank for idle: > > # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank > > But in the world of eternal regressions, I'm not seeing anything > on the framebuffer with v4.6-rc2 :( No idea what broke it or when > as my n900 is in the rack. Well, for the record, framebuffer works in my config with v4.6-rc2. So that is another config issue. Hopefully it is not the same issue ;-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-08 9:19 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-08 9:19 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > Looks like you have 117 additional entries in .config enabled compared > > > to omap2plus_defconfig. Maybe go back to omap2plus_defconfig with minimal > > > changes and verify it idles properly first? > > > > > > I'm suspecting it's some driver(s) you have enabled causing the > > > issue. > > > > I guess so. Do you (or anyone else) have minimum non-modular config > > for N900 that boots with video? Could I get lsmod from your system? > > (Yes, I still have nightmares from getting .config that works). > > Well I've been just using omap2plus_defconfig with: > > # modprobe tsc2005 > # modprobe gpio_backlight > # modprobe panel_sony_acx565akm > # modprobe omapfb > > # echo 255 > /sys/class/backlight/acx565akm/brightness > > And then the following to blank for idle: > > # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank > > But in the world of eternal regressions, I'm not seeing anything > on the framebuffer with v4.6-rc2 :( No idea what broke it or when > as my n900 is in the rack. Well, for the record, framebuffer works in my config with v4.6-rc2. So that is another config issue. Hopefully it is not the same issue ;-). Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.6-rc2: regression with omap video and lockdep (was Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)) 2016-04-07 23:41 ` Tony Lindgren @ 2016-04-11 8:27 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-11 8:27 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > Nothing idling for me with your .config.. And it seems slower to boot > > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > > interrupts? > > > > Extra interrupts only happen when enable_off_mode is 1, so that should > > not be an issue during boot. > > OK maybe it's just the extra driver probe time then. Heh. I had earlyprintk enabled. That should explain it. > Well I've been just using omap2plus_defconfig with: > > # modprobe tsc2005 > # modprobe gpio_backlight > # modprobe panel_sony_acx565akm > # modprobe omapfb > > # echo 255 > /sys/class/backlight/acx565akm/brightness > > And then the following to blank for idle: > > # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank > > But in the world of eternal regressions, I'm not seeing anything > on the framebuffer with v4.6-rc2 :( No idea what broke it or when > as my n900 is in the rack. Can you try this patch to your config -- disabling lockdep? It should fix the video for you. (And if you have the serial console... do you see any warnings from lockdep?) Thanks, Pavel --- config.def 2016-04-08 21:50:04.519622137 +0200 +++ .config 2016-04-11 10:22:52.988193318 +0200 @@ -4183,15 +4183,12 @@ CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set -CONFIG_DEBUG_LOCK_ALLOC=y -CONFIG_PROVE_LOCKING=y -CONFIG_LOCKDEP=y +# CONFIG_DEBUG_LOCK_ALLOC is not set +# CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set -# CONFIG_DEBUG_LOCKDEP is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_LOCK_TORTURE_TEST is not set -CONFIG_TRACE_IRQFLAGS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set @@ -4204,8 +4201,7 @@ # # RCU Debugging # -CONFIG_PROVE_RCU=y -# CONFIG_PROVE_RCU_REPEATEDLY is not set +# CONFIG_PROVE_RCU is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_TORTURE_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.6-rc2: regression with omap video and lockdep (was Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)) @ 2016-04-11 8:27 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-11 8:27 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > Nothing idling for me with your .config.. And it seems slower to boot > > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > > interrupts? > > > > Extra interrupts only happen when enable_off_mode is 1, so that should > > not be an issue during boot. > > OK maybe it's just the extra driver probe time then. Heh. I had earlyprintk enabled. That should explain it. > Well I've been just using omap2plus_defconfig with: > > # modprobe tsc2005 > # modprobe gpio_backlight > # modprobe panel_sony_acx565akm > # modprobe omapfb > > # echo 255 > /sys/class/backlight/acx565akm/brightness > > And then the following to blank for idle: > > # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank > > But in the world of eternal regressions, I'm not seeing anything > on the framebuffer with v4.6-rc2 :( No idea what broke it or when > as my n900 is in the rack. Can you try this patch to your config -- disabling lockdep? It should fix the video for you. (And if you have the serial console... do you see any warnings from lockdep?) Thanks, Pavel --- config.def 2016-04-08 21:50:04.519622137 +0200 +++ .config 2016-04-11 10:22:52.988193318 +0200 @@ -4183,15 +4183,12 @@ CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y # CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set -CONFIG_DEBUG_LOCK_ALLOC=y -CONFIG_PROVE_LOCKING=y -CONFIG_LOCKDEP=y +# CONFIG_DEBUG_LOCK_ALLOC is not set +# CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set -# CONFIG_DEBUG_LOCKDEP is not set # CONFIG_DEBUG_ATOMIC_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_LOCK_TORTURE_TEST is not set -CONFIG_TRACE_IRQFLAGS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_BUGVERBOSE is not set @@ -4204,8 +4201,7 @@ # # RCU Debugging # -CONFIG_PROVE_RCU=y -# CONFIG_PROVE_RCU_REPEATEDLY is not set +# CONFIG_PROVE_RCU is not set # CONFIG_SPARSE_RCU_POINTER is not set # CONFIG_TORTURE_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-07 23:41 ` Tony Lindgren @ 2016-04-11 9:30 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-11 9:30 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > > gzipped config is attached. > > > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > > 1 in off_mode. > > > > > > Nothing idling for me with your .config.. And it seems slower to boot > > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > > interrupts? > > > > Extra interrupts only happen when enable_off_mode is 1, so that should > > not be an issue during boot. > > OK maybe it's just the extra driver probe time then. Ok, I did try to minimize config differences. I'm still booting from NOLO. Now I'm doing the tests from init=... boot. idlest1_core blocking bits says 0042. But the LEDs still don't blink. I made config with pretty minimal differences from defconfig (making required drivers =y, lockdep off so that video works). Do you think you could try with my config? > # echo 255 > /sys/class/backlight/acx565akm/brightness > > And then the following to blank for idle: > > # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank Yes, I'm doing this, on console. Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-11 9:30 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-11 9:30 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > gzipped config is attached. > > > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > > 1 in off_mode. > > > > > > Nothing idling for me with your .config.. And it seems slower to boot > > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > > interrupts? > > > > Extra interrupts only happen when enable_off_mode is 1, so that should > > not be an issue during boot. > > OK maybe it's just the extra driver probe time then. Ok, I did try to minimize config differences. I'm still booting from NOLO. Now I'm doing the tests from init=... boot. idlest1_core blocking bits says 0042. But the LEDs still don't blink. I made config with pretty minimal differences from defconfig (making required drivers =y, lockdep off so that video works). Do you think you could try with my config? > # echo 255 > /sys/class/backlight/acx565akm/brightness > > And then the following to blank for idle: > > # echo 1 > /sys/devices/platform/omapfb/graphics/fb0/blank Yes, I'm doing this, on console. Thanks and best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-11 9:30 ` Pavel Machek @ 2016-04-11 9:41 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-11 9:41 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge Hi! > > > > > gzipped config is attached. > > > > > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > > > 1 in off_mode. > > > > > > > > Nothing idling for me with your .config.. And it seems slower to boot > > > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > > > interrupts? > > > > > > Extra interrupts only happen when enable_off_mode is 1, so that should > > > not be an issue during boot. > > > > OK maybe it's just the extra driver probe time then. > > Ok, I did try to minimize config differences. I'm still booting from > NOLO. Now I'm doing the tests from init=... boot. idlest1_core > blocking bits says 0042. But the LEDs still don't blink. > > I made config with pretty minimal differences from defconfig (making > required drivers =y, lockdep off so that video works). > > Do you think you could try with my config? Ok, it works now. I was doing tests in daylight so it was poorly visible. The right part of keyboard stays lit (but that's expected AFAICT), but the left part blinks. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-11 9:41 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-11 9:41 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > > gzipped config is attached. > > > > > > > > > > Note that I'm still using NOLO. I enabled the sleep, then went to > > > > > runlevel 1. LEDs still stay on, 55mA power consumption. That was with > > > > > 1 in off_mode. > > > > > > > > Nothing idling for me with your .config.. And it seems slower to boot > > > > compared to omap2plus_defconfig? Maybe because of the extra GPIO > > > > interrupts? > > > > > > Extra interrupts only happen when enable_off_mode is 1, so that should > > > not be an issue during boot. > > > > OK maybe it's just the extra driver probe time then. > > Ok, I did try to minimize config differences. I'm still booting from > NOLO. Now I'm doing the tests from init=... boot. idlest1_core > blocking bits says 0042. But the LEDs still don't blink. > > I made config with pretty minimal differences from defconfig (making > required drivers =y, lockdep off so that video works). > > Do you think you could try with my config? Ok, it works now. I was doing tests in daylight so it was poorly visible. The right part of keyboard stays lit (but that's expected AFAICT), but the left part blinks. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) 2016-04-11 9:41 ` Pavel Machek @ 2016-04-11 21:10 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-11 21:10 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen Hi, Adding Tomi to Cc. * Pavel Machek <pavel@ucw.cz> [160411 02:42]: > > I made config with pretty minimal differences from defconfig (making > > required drivers =y, lockdep off so that video works). > > > > Do you think you could try with my config? Yeah disabling lockdep by removing PROVE_LOCKING from omap2plus_defconfig makes n900 LCD work for me again. Not getting any lockdep warnings during boot with lockdep enabled though. So basically the following patch makes LCD work on n900 with omap2plus_defconfig. Tomi, got any ideas? > Ok, it works now. I was doing tests in daylight so it was poorly > visible. The right part of keyboard stays lit (but that's expected > AFAICT), but the left part blinks. During idle, both should go off and are doing so for me. Both LEDs off indicates off mode, left LED off is for retention mode. So you still have something blocking off mode, maybe check: echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode Regards, Tony 8< ------------------- --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -472,7 +472,6 @@ CONFIG_DEBUG_INFO_DWARF4=y CONFIG_MAGIC_SYSRQ=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y -CONFIG_PROVE_LOCKING=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y ^ permalink raw reply [flat|nested] 120+ messages in thread
* 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) @ 2016-04-11 21:10 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-11 21:10 UTC (permalink / raw) To: linux-arm-kernel Hi, Adding Tomi to Cc. * Pavel Machek <pavel@ucw.cz> [160411 02:42]: > > I made config with pretty minimal differences from defconfig (making > > required drivers =y, lockdep off so that video works). > > > > Do you think you could try with my config? Yeah disabling lockdep by removing PROVE_LOCKING from omap2plus_defconfig makes n900 LCD work for me again. Not getting any lockdep warnings during boot with lockdep enabled though. So basically the following patch makes LCD work on n900 with omap2plus_defconfig. Tomi, got any ideas? > Ok, it works now. I was doing tests in daylight so it was poorly > visible. The right part of keyboard stays lit (but that's expected > AFAICT), but the left part blinks. During idle, both should go off and are doing so for me. Both LEDs off indicates off mode, left LED off is for retention mode. So you still have something blocking off mode, maybe check: echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode Regards, Tony 8< ------------------- --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -472,7 +472,6 @@ CONFIG_DEBUG_INFO_DWARF4=y CONFIG_MAGIC_SYSRQ=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y -CONFIG_PROVE_LOCKING=y # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_SECURITY=y CONFIG_CRYPTO_MICHAEL_MIC=y ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-11 21:10 ` Tony Lindgren (?) @ 2016-04-12 12:16 ` Pavel Machek 2016-04-12 12:30 ` Pavel Machek -1 siblings, 1 reply; 120+ messages in thread From: Pavel Machek @ 2016-04-12 12:16 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen Hi! > > > Do you think you could try with my config? > > Yeah disabling lockdep by removing PROVE_LOCKING from omap2plus_defconfig > makes n900 LCD work for me again. Not getting any lockdep warnings > during boot with lockdep enabled though. So basically the following > patch makes LCD work on n900 with omap2plus_defconfig. Good, at least it is consistent. > > Ok, it works now. I was doing tests in daylight so it was poorly > > visible. The right part of keyboard stays lit (but that's expected > > AFAICT), but the left part blinks. > > During idle, both should go off and are doing so for me. Both LEDs off > indicates off mode, left LED off is for retention mode. So you still > have something blocking off mode, maybe check: > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode What is the power difference between retention and off? I'm now down to cca 25mA, which should be around 50 hours standby time. Not ideal, but should be usable. In the meantime, I found what is causing the rention mode to break for me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. I still get problems with the camera button, in config similar to defconfig. For some reason, I'm even getting (autorepeating) ^@ on console. As long as I hold camera button down, I even get it into off mode for brief period. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-12 12:16 ` Nokia N900 retention mode in v4.6, camera buttons fun Pavel Machek @ 2016-04-12 12:30 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-12 12:30 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen Hi! > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > visible. The right part of keyboard stays lit (but that's expected > > > AFAICT), but the left part blinks. > > > > During idle, both should go off and are doing so for me. Both LEDs off > > indicates off mode, left LED off is for retention mode. So you still > > have something blocking off mode, maybe check: > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > What is the power difference between retention and off? I'm now down > to cca 25mA, which should be around 50 hours standby time. Not ideal, > but should be usable. > > In the meantime, I found what is causing the rention mode to break for > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > I still get problems with the camera button, in config similar to > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > console. As long as I hold camera button down, I even get it into off > mode for brief period. Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause problems for you?) Any idea why it enters off mode only once after each screenblank? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-12 12:30 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-12 12:30 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > visible. The right part of keyboard stays lit (but that's expected > > > AFAICT), but the left part blinks. > > > > During idle, both should go off and are doing so for me. Both LEDs off > > indicates off mode, left LED off is for retention mode. So you still > > have something blocking off mode, maybe check: > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > What is the power difference between retention and off? I'm now down > to cca 25mA, which should be around 50 hours standby time. Not ideal, > but should be usable. > > In the meantime, I found what is causing the rention mode to break for > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > I still get problems with the camera button, in config similar to > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > console. As long as I hold camera button down, I even get it into off > mode for brief period. Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause problems for you?) Any idea why it enters off mode only once after each screenblank? Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-12 12:30 ` Pavel Machek @ 2016-04-12 16:30 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-12 16:30 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen * Pavel Machek <pavel@ucw.cz> [160412 05:31]: > Hi! > > > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > > visible. The right part of keyboard stays lit (but that's expected > > > > AFAICT), but the left part blinks. > > > > > > During idle, both should go off and are doing so for me. Both LEDs off > > > indicates off mode, left LED off is for retention mode. So you still > > > have something blocking off mode, maybe check: > > > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > What is the power difference between retention and off? I'm now down > > to cca 25mA, which should be around 50 hours standby time. Not ideal, > > but should be usable. The 25mA sounds way too big to me even for retention mode, some devices must be still on. The off mode makes a huge difference for standby time, it should cut down the total power consumption to something like 10+ mW with modem enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW for memory and 5 or more for the modem. Sorry I don't know the exact numbers for the modem. But with 37xx torpedo, mainline kernel is already getting very close to the 900 uW + 5 mW numbers for the CPU module during idle measured from the ina219 shunt on the torpedo devkit. > > In the meantime, I found what is causing the rention mode to break for > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > I still get problems with the camera button, in config similar to > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > console. As long as I hold camera button down, I even get it into off > > mode for brief period. > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > problems for you?) > > Any idea why it enters off mode only once after each screenblank? After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and blanking the screen, my n900 hits off mode just fine about once a second. Sounds like you still have some extra devices enabled causing it. With LCD enabled, both LEDs are on contantly. I think we should be able to hit retention in that state, at least n950 is doing it with the Nokia kernel. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-12 16:30 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-12 16:30 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160412 05:31]: > Hi! > > > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > > visible. The right part of keyboard stays lit (but that's expected > > > > AFAICT), but the left part blinks. > > > > > > During idle, both should go off and are doing so for me. Both LEDs off > > > indicates off mode, left LED off is for retention mode. So you still > > > have something blocking off mode, maybe check: > > > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > What is the power difference between retention and off? I'm now down > > to cca 25mA, which should be around 50 hours standby time. Not ideal, > > but should be usable. The 25mA sounds way too big to me even for retention mode, some devices must be still on. The off mode makes a huge difference for standby time, it should cut down the total power consumption to something like 10+ mW with modem enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW for memory and 5 or more for the modem. Sorry I don't know the exact numbers for the modem. But with 37xx torpedo, mainline kernel is already getting very close to the 900 uW + 5 mW numbers for the CPU module during idle measured from the ina219 shunt on the torpedo devkit. > > In the meantime, I found what is causing the rention mode to break for > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > I still get problems with the camera button, in config similar to > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > console. As long as I hold camera button down, I even get it into off > > mode for brief period. > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > problems for you?) > > Any idea why it enters off mode only once after each screenblank? After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and blanking the screen, my n900 hits off mode just fine about once a second. Sounds like you still have some extra devices enabled causing it. With LCD enabled, both LEDs are on contantly. I think we should be able to hit retention in that state, at least n950 is doing it with the Nokia kernel. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-12 16:30 ` Tony Lindgren (?) @ 2016-04-13 5:52 ` Tomi Valkeinen -1 siblings, 0 replies; 120+ messages in thread From: Tomi Valkeinen @ 2016-04-13 5:52 UTC (permalink / raw) To: Tony Lindgren, Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge [-- Attachment #1.1: Type: text/plain, Size: 334 bytes --] On 12/04/16 19:30, Tony Lindgren wrote: > With LCD enabled, both LEDs are on contantly. I think we should > be able to hit retention in that state, at least n950 is doing it > with the Nokia kernel. N900's display needs constant updating, where N950's display has internal framebuffer, allowing OMAP to be off. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-13 5:52 ` Tomi Valkeinen 0 siblings, 0 replies; 120+ messages in thread From: Tomi Valkeinen @ 2016-04-13 5:52 UTC (permalink / raw) To: linux-arm-kernel On 12/04/16 19:30, Tony Lindgren wrote: > With LCD enabled, both LEDs are on contantly. I think we should > be able to hit retention in that state, at least n950 is doing it > with the Nokia kernel. N900's display needs constant updating, where N950's display has internal framebuffer, allowing OMAP to be off. Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160413/99c7cbc4/attachment.sig> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-13 5:52 ` Tomi Valkeinen 0 siblings, 0 replies; 120+ messages in thread From: Tomi Valkeinen @ 2016-04-13 5:52 UTC (permalink / raw) To: Tony Lindgren, Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge [-- Attachment #1.1: Type: text/plain, Size: 334 bytes --] On 12/04/16 19:30, Tony Lindgren wrote: > With LCD enabled, both LEDs are on contantly. I think we should > be able to hit retention in that state, at least n950 is doing it > with the Nokia kernel. N900's display needs constant updating, where N950's display has internal framebuffer, allowing OMAP to be off. Tomi [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-13 5:52 ` Tomi Valkeinen @ 2016-04-13 15:15 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-13 15:15 UTC (permalink / raw) To: Tomi Valkeinen Cc: Pavel Machek, pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge * Tomi Valkeinen <tomi.valkeinen@ti.com> [160412 22:53]: > > On 12/04/16 19:30, Tony Lindgren wrote: > > > With LCD enabled, both LEDs are on contantly. I think we should > > be able to hit retention in that state, at least n950 is doing it > > with the Nokia kernel. > > N900's display needs constant updating, where N950's display has > internal framebuffer, allowing OMAP to be off. OK, so the results are as expected then. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-13 15:15 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-13 15:15 UTC (permalink / raw) To: linux-arm-kernel * Tomi Valkeinen <tomi.valkeinen@ti.com> [160412 22:53]: > > On 12/04/16 19:30, Tony Lindgren wrote: > > > With LCD enabled, both LEDs are on contantly. I think we should > > be able to hit retention in that state, at least n950 is doing it > > with the Nokia kernel. > > N900's display needs constant updating, where N950's display has > internal framebuffer, allowing OMAP to be off. OK, so the results are as expected then. Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-12 16:30 ` Tony Lindgren @ 2016-04-17 17:55 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-17 17:55 UTC (permalink / raw) To: Tony Lindgren Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen Hi! > > > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > > > visible. The right part of keyboard stays lit (but that's expected > > > > > AFAICT), but the left part blinks. > > > > > > > > During idle, both should go off and are doing so for me. Both LEDs off > > > > indicates off mode, left LED off is for retention mode. So you still > > > > have something blocking off mode, maybe check: > > > > > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > > > What is the power difference between retention and off? I'm now down > > > to cca 25mA, which should be around 50 hours standby time. Not ideal, > > > but should be usable. > > The 25mA sounds way too big to me even for retention mode, some > devices must be still on. Yes, cca 60mW. > The off mode makes a huge difference for standby time, it should cut > down the total power consumption to something like 10+ mW with modem > enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW > for memory and 5 or more for the modem. Sorry I don't know the exact > numbers for the modem. But with 37xx torpedo, mainline kernel is > already getting very close to the 900 uW + 5 mW numbers for the CPU > module during idle measured from the ina219 shunt on the torpedo > devkit. CONFIG_HSI breaks power management completely, so power management with modem will be another topic. > > > In the meantime, I found what is causing the rention mode to break for > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > I still get problems with the camera button, in config similar to > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > console. As long as I hold camera button down, I even get it into off > > > mode for brief period. > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > problems for you?) > > > > Any idea why it enters off mode only once after each screenblank? > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > blanking the screen, my n900 hits off mode just fine about once > a second. Sounds like you still have some extra devices enabled > causing it. I checked again... also with vanilla 4.6-rc2 to double check... same effect. Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the off mode. If I don't do that (tm), it seems to work way better. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-17 17:55 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-17 17:55 UTC (permalink / raw) To: linux-arm-kernel Hi! > > > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > > > visible. The right part of keyboard stays lit (but that's expected > > > > > AFAICT), but the left part blinks. > > > > > > > > During idle, both should go off and are doing so for me. Both LEDs off > > > > indicates off mode, left LED off is for retention mode. So you still > > > > have something blocking off mode, maybe check: > > > > > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > > > What is the power difference between retention and off? I'm now down > > > to cca 25mA, which should be around 50 hours standby time. Not ideal, > > > but should be usable. > > The 25mA sounds way too big to me even for retention mode, some > devices must be still on. Yes, cca 60mW. > The off mode makes a huge difference for standby time, it should cut > down the total power consumption to something like 10+ mW with modem > enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW > for memory and 5 or more for the modem. Sorry I don't know the exact > numbers for the modem. But with 37xx torpedo, mainline kernel is > already getting very close to the 900 uW + 5 mW numbers for the CPU > module during idle measured from the ina219 shunt on the torpedo > devkit. CONFIG_HSI breaks power management completely, so power management with modem will be another topic. > > > In the meantime, I found what is causing the rention mode to break for > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > I still get problems with the camera button, in config similar to > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > console. As long as I hold camera button down, I even get it into off > > > mode for brief period. > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > problems for you?) > > > > Any idea why it enters off mode only once after each screenblank? > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > blanking the screen, my n900 hits off mode just fine about once > a second. Sounds like you still have some extra devices enabled > causing it. I checked again... also with vanilla 4.6-rc2 to double check... same effect. Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the off mode. If I don't do that (tm), it seems to work way better. Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-17 17:55 ` Pavel Machek @ 2016-04-18 23:47 ` Tony Lindgren -1 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-18 23:47 UTC (permalink / raw) To: Pavel Machek Cc: pali.rohar, sre, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen * Pavel Machek <pavel@ucw.cz> [160417 10:56]: > > The off mode makes a huge difference for standby time, it should cut > > down the total power consumption to something like 10+ mW with modem > > enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW > > for memory and 5 or more for the modem. Sorry I don't know the exact > > numbers for the modem. But with 37xx torpedo, mainline kernel is > > already getting very close to the 900 uW + 5 mW numbers for the CPU > > module during idle measured from the ina219 shunt on the torpedo > > devkit. > > CONFIG_HSI breaks power management completely, so power management > with modem will be another topic. OK > > > > In the meantime, I found what is causing the rention mode to break for > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > I still get problems with the camera button, in config similar to > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > console. As long as I hold camera button down, I even get it into off > > > > mode for brief period. > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > problems for you?) > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > blanking the screen, my n900 hits off mode just fine about once > > a second. Sounds like you still have some extra devices enabled > > causing it. > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > off mode. If I don't do that (tm), it seems to work way better. Ah I see yeah :) Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-18 23:47 ` Tony Lindgren 0 siblings, 0 replies; 120+ messages in thread From: Tony Lindgren @ 2016-04-18 23:47 UTC (permalink / raw) To: linux-arm-kernel * Pavel Machek <pavel@ucw.cz> [160417 10:56]: > > The off mode makes a huge difference for standby time, it should cut > > down the total power consumption to something like 10+ mW with modem > > enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW > > for memory and 5 or more for the modem. Sorry I don't know the exact > > numbers for the modem. But with 37xx torpedo, mainline kernel is > > already getting very close to the 900 uW + 5 mW numbers for the CPU > > module during idle measured from the ina219 shunt on the torpedo > > devkit. > > CONFIG_HSI breaks power management completely, so power management > with modem will be another topic. OK > > > > In the meantime, I found what is causing the rention mode to break for > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > I still get problems with the camera button, in config similar to > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > console. As long as I hold camera button down, I even get it into off > > > > mode for brief period. > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > problems for you?) > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > blanking the screen, my n900 hits off mode just fine about once > > a second. Sounds like you still have some extra devices enabled > > causing it. > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > off mode. If I don't do that (tm), it seems to work way better. Ah I see yeah :) Regards, Tony ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-17 17:55 ` Pavel Machek @ 2016-04-21 13:04 ` Pali Rohár -1 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-04-21 13:04 UTC (permalink / raw) To: sre, Pavel Machek Cc: Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen On Sunday 17 April 2016 19:55:40 Pavel Machek wrote: > Hi! > > > > > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > > > > visible. The right part of keyboard stays lit (but that's expected > > > > > > AFAICT), but the left part blinks. > > > > > > > > > > During idle, both should go off and are doing so for me. Both LEDs off > > > > > indicates off mode, left LED off is for retention mode. So you still > > > > > have something blocking off mode, maybe check: > > > > > > > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > > > > > What is the power difference between retention and off? I'm now down > > > > to cca 25mA, which should be around 50 hours standby time. Not ideal, > > > > but should be usable. > > > > The 25mA sounds way too big to me even for retention mode, some > > devices must be still on. > > Yes, cca 60mW. > > > The off mode makes a huge difference for standby time, it should cut > > down the total power consumption to something like 10+ mW with modem > > enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW > > for memory and 5 or more for the modem. Sorry I don't know the exact > > numbers for the modem. But with 37xx torpedo, mainline kernel is > > already getting very close to the 900 uW + 5 mW numbers for the CPU > > module during idle measured from the ina219 shunt on the torpedo > > devkit. > > CONFIG_HSI breaks power management completely, so power management > with modem will be another topic. Sebastian, any idea why power management does not work for HSI? > > > > In the meantime, I found what is causing the rention mode to break for > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > I still get problems with the camera button, in config similar to > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > console. As long as I hold camera button down, I even get it into off > > > > mode for brief period. > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > problems for you?) > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > blanking the screen, my n900 hits off mode just fine about once > > a second. Sounds like you still have some extra devices enabled > > causing it. > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > off mode. If I don't do that (tm), it seems to work way better. So what is result? Is power management working for CONFIG_KEYBOARD_GPIO? Or problem is somewhere in CONFIG_PROVE_LOCKING? -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-21 13:04 ` Pali Rohár 0 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-04-21 13:04 UTC (permalink / raw) To: linux-arm-kernel On Sunday 17 April 2016 19:55:40 Pavel Machek wrote: > Hi! > > > > > > > Ok, it works now. I was doing tests in daylight so it was poorly > > > > > > visible. The right part of keyboard stays lit (but that's expected > > > > > > AFAICT), but the left part blinks. > > > > > > > > > > During idle, both should go off and are doing so for me. Both LEDs off > > > > > indicates off mode, left LED off is for retention mode. So you still > > > > > have something blocking off mode, maybe check: > > > > > > > > > > echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode > > > > > > > > What is the power difference between retention and off? I'm now down > > > > to cca 25mA, which should be around 50 hours standby time. Not ideal, > > > > but should be usable. > > > > The 25mA sounds way too big to me even for retention mode, some > > devices must be still on. > > Yes, cca 60mW. > > > The off mode makes a huge difference for standby time, it should cut > > down the total power consumption to something like 10+ mW with modem > > enabled. Aproximately the breakdown is roughly: 900 uW for omap, 5 mW > > for memory and 5 or more for the modem. Sorry I don't know the exact > > numbers for the modem. But with 37xx torpedo, mainline kernel is > > already getting very close to the 900 uW + 5 mW numbers for the CPU > > module during idle measured from the ina219 shunt on the torpedo > > devkit. > > CONFIG_HSI breaks power management completely, so power management > with modem will be another topic. Sebastian, any idea why power management does not work for HSI? > > > > In the meantime, I found what is causing the rention mode to break for > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > I still get problems with the camera button, in config similar to > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > console. As long as I hold camera button down, I even get it into off > > > > mode for brief period. > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > problems for you?) > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > blanking the screen, my n900 hits off mode just fine about once > > a second. Sounds like you still have some extra devices enabled > > causing it. > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > off mode. If I don't do that (tm), it seems to work way better. So what is result? Is power management working for CONFIG_KEYBOARD_GPIO? Or problem is somewhere in CONFIG_PROVE_LOCKING? -- Pali Roh?r pali.rohar at gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-21 13:04 ` Pali Rohár @ 2016-04-21 21:28 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-21 21:28 UTC (permalink / raw) To: Pali Rohár Cc: sre, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen Hi! > > CONFIG_HSI breaks power management completely, so power management > > with modem will be another topic. > > Sebastian, any idea why power management does not work for HSI? > > > > > > In the meantime, I found what is causing the rention mode to break for > > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > > > I still get problems with the camera button, in config similar to > > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > > console. As long as I hold camera button down, I even get it into off > > > > > mode for brief period. > > > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > > problems for you?) > > > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > > blanking the screen, my n900 hits off mode just fine about once > > > a second. Sounds like you still have some extra devices enabled > > > causing it. > > > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > > off mode. If I don't do that (tm), it seems to work way better. > > So what is result? Is power management working for CONFIG_KEYBOARD_GPIO? camera and unlock button GPIOs seem to break the powermanagement, too. I disabled it for now. Next hint I got from Sebastian was that I may need to enable power management in /sys. pavel@n900:/my/tui/ofone$ cat /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/runtime_status active pavel@n900:/my/tui/ofone$ cat /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms cat: /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms: Input/output error root@n900:/my/tui/ofone# cat /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/control auto I could not get it to sleep :-(. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-21 21:28 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-04-21 21:28 UTC (permalink / raw) To: linux-arm-kernel Hi! > > CONFIG_HSI breaks power management completely, so power management > > with modem will be another topic. > > Sebastian, any idea why power management does not work for HSI? > > > > > > In the meantime, I found what is causing the rention mode to break for > > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > > > I still get problems with the camera button, in config similar to > > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > > console. As long as I hold camera button down, I even get it into off > > > > > mode for brief period. > > > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > > problems for you?) > > > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > > blanking the screen, my n900 hits off mode just fine about once > > > a second. Sounds like you still have some extra devices enabled > > > causing it. > > > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > > off mode. If I don't do that (tm), it seems to work way better. > > So what is result? Is power management working for CONFIG_KEYBOARD_GPIO? camera and unlock button GPIOs seem to break the powermanagement, too. I disabled it for now. Next hint I got from Sebastian was that I may need to enable power management in /sys. pavel at n900:/my/tui/ofone$ cat /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/runtime_status active pavel at n900:/my/tui/ofone$ cat /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms cat: /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms: Input/output error root at n900:/my/tui/ofone# cat /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/control auto I could not get it to sleep :-(. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-21 21:28 ` Pavel Machek @ 2016-04-22 7:05 ` Pali Rohár -1 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-04-22 7:05 UTC (permalink / raw) To: Pavel Machek Cc: sre, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen On Thursday 21 April 2016 23:28:08 Pavel Machek wrote: > Hi! > > > > CONFIG_HSI breaks power management completely, so power management > > > with modem will be another topic. > > > > Sebastian, any idea why power management does not work for HSI? > > > > > > > > In the meantime, I found what is causing the rention mode to break for > > > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > > > > > I still get problems with the camera button, in config similar to > > > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > > > console. As long as I hold camera button down, I even get it into off > > > > > > mode for brief period. > > > > > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > > > problems for you?) > > > > > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > > > blanking the screen, my n900 hits off mode just fine about once > > > > a second. Sounds like you still have some extra devices enabled > > > > causing it. > > > > > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > > > > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > > > off mode. If I don't do that (tm), it seems to work way better. > > > > So what is result? Is power management working for CONFIG_KEYBOARD_GPIO? > > camera and unlock button GPIOs seem to break the powermanagement, > too. I disabled it for now. So this sounds like a problem in gpio keyboard driver. Maybe you can ping maintainers of that driver? > Next hint I got from Sebastian was that I may need to enable power > management in /sys. > > pavel@n900:/my/tui/ofone$ cat > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/runtime_status > active > pavel@n900:/my/tui/ofone$ cat > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms > cat: > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms: > Input/output error > root@n900:/my/tui/ofone# cat > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/control > auto > > I could not get it to sleep :-(. > > Best regards, > Pavel > Maybe down phonet0 interface and other hsi/ssi interfaces? -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-22 7:05 ` Pali Rohár 0 siblings, 0 replies; 120+ messages in thread From: Pali Rohár @ 2016-04-22 7:05 UTC (permalink / raw) To: linux-arm-kernel On Thursday 21 April 2016 23:28:08 Pavel Machek wrote: > Hi! > > > > CONFIG_HSI breaks power management completely, so power management > > > with modem will be another topic. > > > > Sebastian, any idea why power management does not work for HSI? > > > > > > > > In the meantime, I found what is causing the rention mode to break for > > > > > > me: CONFIG_HSI (aka wireless modem support). With HSI off, it seems to work. > > > > > > > > > > > > I still get problems with the camera button, in config similar to > > > > > > defconfig. For some reason, I'm even getting (autorepeating) ^@ on > > > > > > console. As long as I hold camera button down, I even get it into off > > > > > > mode for brief period. > > > > > > > > > > Ok, if I turn off CONFIG_KEYBOARD_GPIO, I get it into off > > > > > mode... once per screen blank, for about a second. (Does CONFIG_KEYBOARD_GPIO also cause > > > > > problems for you?) > > > > > > > > > > Any idea why it enters off mode only once after each screenblank? > > > > > > > > After disabling CONFIG_PROVE_LOCKING, loading the LCD modules, and > > > > blanking the screen, my n900 hits off mode just fine about once > > > > a second. Sounds like you still have some extra devices enabled > > > > causing it. > > > > > > I checked again... also with vanilla 4.6-rc2 to double check... same effect. > > > > > > Aha, got it... cat-ing /sys/kernel/debug/pm_debug/count breaks the > > > off mode. If I don't do that (tm), it seems to work way better. > > > > So what is result? Is power management working for CONFIG_KEYBOARD_GPIO? > > camera and unlock button GPIOs seem to break the powermanagement, > too. I disabled it for now. So this sounds like a problem in gpio keyboard driver. Maybe you can ping maintainers of that driver? > Next hint I got from Sebastian was that I may need to enable power > management in /sys. > > pavel at n900:/my/tui/ofone$ cat > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/runtime_status > active > pavel at n900:/my/tui/ofone$ cat > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms > cat: > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/autosuspend_delay_ms: > Input/output error > root at n900:/my/tui/ofone# cat > /sys/devices/platform/68000000.ocp/48058000.ssi-controller/power/control > auto > > I could not get it to sleep :-(. > > Best regards, > Pavel > Maybe down phonet0 interface and other hsi/ssi interfaces? -- Pali Roh?r pali.rohar at gmail.com ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-21 13:04 ` Pali Rohár @ 2016-04-29 20:06 ` Sebastian Reichel -1 siblings, 0 replies; 120+ messages in thread From: Sebastian Reichel @ 2016-04-29 20:06 UTC (permalink / raw) To: Pali Rohár Cc: Pavel Machek, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen [-- Attachment #1: Type: text/plain, Size: 719 bytes --] Hi, On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Rohár wrote: > > CONFIG_HSI breaks power management completely, so power management > > with modem will be another topic. > > Sebastian, any idea why power management does not work for HSI? I wasn't aware, that pm_runtime_irq_safe() basically breaks runtime PM until Tony's fix for musb (even though it's logical when thinking about it). Currently omap-ssi and omap-ssi-port make use of pm_runtime_irq_safe(). Since pm_runtime_get_sync/pm_runtime_put_sync is called from tasklets in omap-ssi (and omap-ssi-port) it cannot be simply removed. So fixing PM for the ssi controller requires reworking the driver in a non trivial way. -- Sebastian [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-04-29 20:06 ` Sebastian Reichel 0 siblings, 0 replies; 120+ messages in thread From: Sebastian Reichel @ 2016-04-29 20:06 UTC (permalink / raw) To: linux-arm-kernel Hi, On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Roh?r wrote: > > CONFIG_HSI breaks power management completely, so power management > > with modem will be another topic. > > Sebastian, any idea why power management does not work for HSI? I wasn't aware, that pm_runtime_irq_safe() basically breaks runtime PM until Tony's fix for musb (even though it's logical when thinking about it). Currently omap-ssi and omap-ssi-port make use of pm_runtime_irq_safe(). Since pm_runtime_get_sync/pm_runtime_put_sync is called from tasklets in omap-ssi (and omap-ssi-port) it cannot be simply removed. So fixing PM for the ssi controller requires reworking the driver in a non trivial way. -- Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160429/91c1c8c2/attachment-0001.sig> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-04-29 20:06 ` Sebastian Reichel @ 2016-05-01 8:52 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-05-01 8:52 UTC (permalink / raw) To: Sebastian Reichel Cc: Pali Rohár, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen On Fri 2016-04-29 22:06:00, Sebastian Reichel wrote: > Hi, > > On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Rohár wrote: > > > CONFIG_HSI breaks power management completely, so power management > > > with modem will be another topic. > > > > Sebastian, any idea why power management does not work for HSI? > > I wasn't aware, that pm_runtime_irq_safe() basically breaks runtime > PM until Tony's fix for musb (even though it's logical when thinking > about it). Currently omap-ssi and omap-ssi-port make use of > pm_runtime_irq_safe(). > > Since pm_runtime_get_sync/pm_runtime_put_sync is called from > tasklets in omap-ssi (and omap-ssi-port) it cannot be simply > removed. So fixing PM for the ssi controller requires reworking > the driver in a non trivial way. I see latest series, and it also talks about frequency scaling. But I guess it is not going to fix this issue? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-05-01 8:52 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-05-01 8:52 UTC (permalink / raw) To: linux-arm-kernel On Fri 2016-04-29 22:06:00, Sebastian Reichel wrote: > Hi, > > On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Roh?r wrote: > > > CONFIG_HSI breaks power management completely, so power management > > > with modem will be another topic. > > > > Sebastian, any idea why power management does not work for HSI? > > I wasn't aware, that pm_runtime_irq_safe() basically breaks runtime > PM until Tony's fix for musb (even though it's logical when thinking > about it). Currently omap-ssi and omap-ssi-port make use of > pm_runtime_irq_safe(). > > Since pm_runtime_get_sync/pm_runtime_put_sync is called from > tasklets in omap-ssi (and omap-ssi-port) it cannot be simply > removed. So fixing PM for the ssi controller requires reworking > the driver in a non trivial way. I see latest series, and it also talks about frequency scaling. But I guess it is not going to fix this issue? Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-05-01 8:52 ` Pavel Machek @ 2016-05-01 15:48 ` Sebastian Reichel -1 siblings, 0 replies; 120+ messages in thread From: Sebastian Reichel @ 2016-05-01 15:48 UTC (permalink / raw) To: Pavel Machek Cc: Pali Rohár, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen [-- Attachment #1: Type: text/plain, Size: 1239 bytes --] Hi, On Sun, May 01, 2016 at 10:52:36AM +0200, Pavel Machek wrote: > On Fri 2016-04-29 22:06:00, Sebastian Reichel wrote: > > On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Rohár wrote: > > > > CONFIG_HSI breaks power management completely, so power management > > > > with modem will be another topic. > > > > > > Sebastian, any idea why power management does not work for HSI? > > > > I wasn't aware, that pm_runtime_irq_safe() basically breaks runtime > > PM until Tony's fix for musb (even though it's logical when thinking > > about it). Currently omap-ssi and omap-ssi-port make use of > > pm_runtime_irq_safe(). > > > > Since pm_runtime_get_sync/pm_runtime_put_sync is called from > > tasklets in omap-ssi (and omap-ssi-port) it cannot be simply > > removed. So fixing PM for the ssi controller requires reworking > > the driver in a non trivial way. > > I see latest series, and it also talks about frequency scaling. But I > guess it is not going to fix this issue? No, this is independent of the runtime PM problems. I also worked on runtime PM/idling yesterday and pm_runtime_irq_safe is the main culprit for breaking it (not the only one, though). It's not yet finished though -- Sebastian [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-05-01 15:48 ` Sebastian Reichel 0 siblings, 0 replies; 120+ messages in thread From: Sebastian Reichel @ 2016-05-01 15:48 UTC (permalink / raw) To: linux-arm-kernel Hi, On Sun, May 01, 2016 at 10:52:36AM +0200, Pavel Machek wrote: > On Fri 2016-04-29 22:06:00, Sebastian Reichel wrote: > > On Thu, Apr 21, 2016 at 03:04:50PM +0200, Pali Roh?r wrote: > > > > CONFIG_HSI breaks power management completely, so power management > > > > with modem will be another topic. > > > > > > Sebastian, any idea why power management does not work for HSI? > > > > I wasn't aware, that pm_runtime_irq_safe() basically breaks runtime > > PM until Tony's fix for musb (even though it's logical when thinking > > about it). Currently omap-ssi and omap-ssi-port make use of > > pm_runtime_irq_safe(). > > > > Since pm_runtime_get_sync/pm_runtime_put_sync is called from > > tasklets in omap-ssi (and omap-ssi-port) it cannot be simply > > removed. So fixing PM for the ssi controller requires reworking > > the driver in a non trivial way. > > I see latest series, and it also talks about frequency scaling. But I > guess it is not going to fix this issue? No, this is independent of the runtime PM problems. I also worked on runtime PM/idling yesterday and pm_runtime_irq_safe is the main culprit for breaking it (not the only one, though). It's not yet finished though -- Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160501/4466ff82/attachment-0001.sig> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-05-01 15:48 ` Sebastian Reichel @ 2016-05-02 20:12 ` Sebastian Reichel -1 siblings, 0 replies; 120+ messages in thread From: Sebastian Reichel @ 2016-05-02 20:12 UTC (permalink / raw) To: Pavel Machek Cc: Pali Rohár, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen [-- Attachment #1: Type: text/plain, Size: 682 bytes --] Hi Pavel, On Sun, May 01, 2016 at 05:48:56PM +0200, Sebastian Reichel wrote: > > I see latest series, and it also talks about frequency scaling. > > But I guess it is not going to fix this issue? > > No, this is independent of the runtime PM problems. I also worked > on runtime PM/idling yesterday and pm_runtime_irq_safe is the main > culprit for breaking it (not the only one, though). It's not yet > finished though I will be on vacation for a week starting tomorrow. If you want to play around with my intermediate SSI PM status, you can try this branch: https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/log/?h=runtime-pm-fixes -- Sebastian [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-05-02 20:12 ` Sebastian Reichel 0 siblings, 0 replies; 120+ messages in thread From: Sebastian Reichel @ 2016-05-02 20:12 UTC (permalink / raw) To: linux-arm-kernel Hi Pavel, On Sun, May 01, 2016 at 05:48:56PM +0200, Sebastian Reichel wrote: > > I see latest series, and it also talks about frequency scaling. > > But I guess it is not going to fix this issue? > > No, this is independent of the runtime PM problems. I also worked > on runtime PM/idling yesterday and pm_runtime_irq_safe is the main > culprit for breaking it (not the only one, though). It's not yet > finished though I will be on vacation for a week starting tomorrow. If you want to play around with my intermediate SSI PM status, you can try this branch: https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/log/?h=runtime-pm-fixes -- Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160502/70e10112/attachment.sig> ^ permalink raw reply [flat|nested] 120+ messages in thread
* Re: Nokia N900 retention mode in v4.6, camera buttons fun 2016-05-02 20:12 ` Sebastian Reichel @ 2016-05-28 11:09 ` Pavel Machek -1 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-05-28 11:09 UTC (permalink / raw) To: Sebastian Reichel Cc: Pali Rohár, Tony Lindgren, kernel list, linux-arm-kernel, linux-omap, khilman, aaro.koskinen, ivo.g.dimitrov.75, patrikbachan, serge, Tomi Valkeinen On Mon 2016-05-02 22:12:17, Sebastian Reichel wrote: > Hi Pavel, > > On Sun, May 01, 2016 at 05:48:56PM +0200, Sebastian Reichel wrote: > > > I see latest series, and it also talks about frequency scaling. > > > But I guess it is not going to fix this issue? > > > > No, this is independent of the runtime PM problems. I also worked > > on runtime PM/idling yesterday and pm_runtime_irq_safe is the main > > culprit for breaking it (not the only one, though). It's not yet > > finished though > > I will be on vacation for a week starting tomorrow. If you want to > play around with my intermediate SSI PM status, you can try this branch: > > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/log/?h=runtime-pm-fixes Ok, I did: pavel@amd:/data/l/linux-n900$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git runtime-pm-fixes remote: Counting objects: 65, done. remote: Compressing objects: 100% (25/25), done. remote: Total 65 (delta 51), reused 54 (delta 40) Unpacking objects: 100% (65/65), done. And yes, now the LED goes off (so far with modem enabled but not used). Thanks! (You can have my Tested-by: when you submit them, or something :-) ) Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
* Nokia N900 retention mode in v4.6, camera buttons fun @ 2016-05-28 11:09 ` Pavel Machek 0 siblings, 0 replies; 120+ messages in thread From: Pavel Machek @ 2016-05-28 11:09 UTC (permalink / raw) To: linux-arm-kernel On Mon 2016-05-02 22:12:17, Sebastian Reichel wrote: > Hi Pavel, > > On Sun, May 01, 2016 at 05:48:56PM +0200, Sebastian Reichel wrote: > > > I see latest series, and it also talks about frequency scaling. > > > But I guess it is not going to fix this issue? > > > > No, this is independent of the runtime PM problems. I also worked > > on runtime PM/idling yesterday and pm_runtime_irq_safe is the main > > culprit for breaking it (not the only one, though). It's not yet > > finished though > > I will be on vacation for a week starting tomorrow. If you want to > play around with my intermediate SSI PM status, you can try this branch: > > https://git.kernel.org/cgit/linux/kernel/git/sre/linux-hsi.git/log/?h=runtime-pm-fixes Ok, I did: pavel at amd:/data/l/linux-n900$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-hsi.git runtime-pm-fixes remote: Counting objects: 65, done. remote: Compressing objects: 100% (25/25), done. remote: Total 65 (delta 51), reused 54 (delta 40) Unpacking objects: 100% (65/65), done. And yes, now the LED goes off (so far with modem enabled but not used). Thanks! (You can have my Tested-by: when you submit them, or something :-) ) Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ^ permalink raw reply [flat|nested] 120+ messages in thread
end of thread, other threads:[~2016-05-28 11:09 UTC | newest] Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-23 12:10 N900 sleep mode (in 4.5-rc0, if that matters) Pavel Machek 2016-01-23 12:10 ` Pavel Machek 2016-01-25 16:33 ` Tony Lindgren 2016-01-25 16:33 ` Tony Lindgren 2016-01-25 22:23 ` Pavel Machek 2016-01-25 22:23 ` Pavel Machek 2016-01-25 22:50 ` Tony Lindgren 2016-01-25 22:50 ` Tony Lindgren 2016-01-26 14:00 ` Pavel Machek 2016-01-26 14:00 ` Pavel Machek 2016-01-26 17:25 ` Tony Lindgren 2016-01-26 17:25 ` Tony Lindgren 2016-01-26 22:51 ` Tony Lindgren 2016-01-26 22:51 ` Tony Lindgren 2016-01-30 20:02 ` Pavel Machek 2016-01-30 20:02 ` Pavel Machek 2016-01-30 20:14 ` Pavel Machek 2016-01-30 20:14 ` Pavel Machek 2016-01-30 22:15 ` Pavel Machek 2016-01-30 22:15 ` Pavel Machek 2016-02-01 18:13 ` Tony Lindgren 2016-02-01 18:13 ` Tony Lindgren 2016-02-01 21:17 ` Pavel Machek 2016-02-01 21:17 ` Pavel Machek 2016-02-01 22:11 ` Tony Lindgren 2016-02-01 22:11 ` Tony Lindgren 2016-02-04 5:35 ` Tony Lindgren 2016-02-04 5:35 ` Tony Lindgren 2016-02-07 21:37 ` Pavel Machek 2016-02-07 21:37 ` Pavel Machek 2016-02-07 21:37 ` Pavel Machek 2016-02-08 8:51 ` Pali Rohár 2016-02-08 8:51 ` Pali Rohár 2016-02-07 21:23 ` Pavel Machek 2016-02-07 21:23 ` Pavel Machek 2016-02-09 17:24 ` Tony Lindgren 2016-02-09 17:24 ` Tony Lindgren 2016-02-09 17:38 ` Tony Lindgren 2016-02-09 17:38 ` Tony Lindgren 2016-03-20 8:38 ` Pavel Machek 2016-03-20 8:38 ` Pavel Machek 2016-02-11 1:08 ` Tony Lindgren 2016-02-11 1:08 ` Tony Lindgren 2016-02-11 1:08 ` Tony Lindgren 2016-03-23 14:37 ` Pavel Machek 2016-03-23 14:37 ` Pavel Machek 2016-03-20 8:33 ` Pavel Machek 2016-03-20 8:33 ` Pavel Machek 2016-03-23 12:38 ` Pavel Machek 2016-03-23 12:38 ` Pavel Machek 2016-03-30 19:12 ` Tony Lindgren 2016-03-30 19:12 ` Tony Lindgren 2016-04-04 11:09 ` Pali Rohár 2016-04-04 11:09 ` Pali Rohár 2016-04-04 22:31 ` Tony Lindgren 2016-04-04 22:31 ` Tony Lindgren 2016-04-04 21:30 ` Pavel Machek 2016-04-04 21:30 ` Pavel Machek 2016-04-04 22:07 ` Tony Lindgren 2016-04-04 22:07 ` Tony Lindgren 2016-04-05 10:09 ` Pavel Machek 2016-04-05 10:09 ` Pavel Machek 2016-04-05 13:17 ` Pavel Machek 2016-04-05 13:17 ` Pavel Machek 2016-04-05 14:22 ` 4.4: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) Pavel Machek 2016-04-05 14:22 ` Pavel Machek 2016-04-05 15:29 ` Tony Lindgren 2016-04-05 15:29 ` Tony Lindgren 2016-04-05 20:51 ` Pavel Machek 2016-04-05 20:51 ` Pavel Machek 2016-04-07 17:40 ` Tony Lindgren 2016-04-07 17:40 ` Tony Lindgren 2016-04-07 19:48 ` 4.4, 4.6: " Pavel Machek 2016-04-07 19:48 ` Pavel Machek 2016-04-07 21:32 ` Tony Lindgren 2016-04-07 21:32 ` Tony Lindgren 2016-04-07 23:01 ` Pavel Machek 2016-04-07 23:01 ` Pavel Machek 2016-04-07 23:41 ` Tony Lindgren 2016-04-07 23:41 ` Tony Lindgren 2016-04-08 9:19 ` Pavel Machek 2016-04-08 9:19 ` Pavel Machek 2016-04-11 8:27 ` 4.6-rc2: regression with omap video and lockdep (was Re: 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode)) Pavel Machek 2016-04-11 8:27 ` Pavel Machek 2016-04-11 9:30 ` 4.4, 4.6: camera and unlock buttons produce tons of interrupts (was Re: N900 sleep mode) Pavel Machek 2016-04-11 9:30 ` Pavel Machek 2016-04-11 9:41 ` Pavel Machek 2016-04-11 9:41 ` Pavel Machek 2016-04-11 21:10 ` Tony Lindgren 2016-04-11 21:10 ` Tony Lindgren 2016-04-12 12:16 ` Nokia N900 retention mode in v4.6, camera buttons fun Pavel Machek 2016-04-12 12:30 ` Pavel Machek 2016-04-12 12:30 ` Pavel Machek 2016-04-12 16:30 ` Tony Lindgren 2016-04-12 16:30 ` Tony Lindgren 2016-04-13 5:52 ` Tomi Valkeinen 2016-04-13 5:52 ` Tomi Valkeinen 2016-04-13 5:52 ` Tomi Valkeinen 2016-04-13 15:15 ` Tony Lindgren 2016-04-13 15:15 ` Tony Lindgren 2016-04-17 17:55 ` Pavel Machek 2016-04-17 17:55 ` Pavel Machek 2016-04-18 23:47 ` Tony Lindgren 2016-04-18 23:47 ` Tony Lindgren 2016-04-21 13:04 ` Pali Rohár 2016-04-21 13:04 ` Pali Rohár 2016-04-21 21:28 ` Pavel Machek 2016-04-21 21:28 ` Pavel Machek 2016-04-22 7:05 ` Pali Rohár 2016-04-22 7:05 ` Pali Rohár 2016-04-29 20:06 ` Sebastian Reichel 2016-04-29 20:06 ` Sebastian Reichel 2016-05-01 8:52 ` Pavel Machek 2016-05-01 8:52 ` Pavel Machek 2016-05-01 15:48 ` Sebastian Reichel 2016-05-01 15:48 ` Sebastian Reichel 2016-05-02 20:12 ` Sebastian Reichel 2016-05-02 20:12 ` Sebastian Reichel 2016-05-28 11:09 ` Pavel Machek 2016-05-28 11:09 ` Pavel Machek
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.