Hi!
> >
> > Display off, on wifi:
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042
> > 000d 48004a28 (fa004a28) cm_idlest3_core
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking
Hi!
> >
> > Display off, on wifi:
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042
> > 000d 48004a28 (fa004a28) cm_idlest3_core
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking
On Mon 2016-04-04 15:07:49, Tony Lindgren wrote:
> * Pavel Machek [160404 14:31]:
> >
> > Display off, on wifi:
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042
> > 000d 48004a28
On Mon 2016-04-04 15:07:49, Tony Lindgren wrote:
> * Pavel Machek [160404 14:31]:
> >
> > Display off, on wifi:
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> > f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042
> > 000d 48004a28 (fa004a28)
* Pali Rohár [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...
* Pali Rohár [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
* Pavel Machek [160404 14:31]:
>
> Display off, on wifi:
>
> 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042
> 000d 48004a28 (fa004a28) cm_idlest3_core
>
> 1fff 48005020 (fa005020)
* Pavel Machek [160404 14:31]:
>
> Display off, on wifi:
>
> 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> f7de7ebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00218042
> 000d 48004a28 (fa004a28) cm_idlest3_core
>
> 1fff 48005020 (fa005020) cm_idlest_per
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
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
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
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
* Pavel Machek [160323 05:38]:
>
> Ok, another attempt at shutting USB down:
>
> 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062
> 000d 48004a28 (fa004a28) cm_idlest3_core
>
> Tried
* Pavel Machek [160323 05:38]:
>
> Ok, another attempt at shutting USB down:
>
> 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
> f7dffe9d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200062
> 000d 48004a28 (fa004a28) cm_idlest3_core
>
> Tried again today:
>
>
On Wed 2016-02-10 17:08:18, Tony Lindgren wrote:
> * Tony Lindgren [160209 09:26]:
> > * Pavel Machek [160207 13:24]:
> >
> > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> > > 000d 48004a28 (fa004a28) cm_idlest3_core
> >
> > Bit 21
On Wed 2016-02-10 17:08:18, Tony Lindgren wrote:
> * Tony Lindgren [160209 09:26]:
> > * Pavel Machek [160207 13:24]:
> >
> > > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> > > 000d 48004a28 (fa004a28) cm_idlest3_core
> >
> > Bit 21 in cm_idlest1_core is for
Hi!
> > > 05fc459 ("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:
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
>
> I
Hi!
> > > 05fc459 ("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:
> >
> > 1fff 48005020 (fa005020) cm_idlest_per blocking bits: 0007e000
>
> I
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
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
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
>
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
>
* Tony Lindgren [160209 09:26]:
> * Pavel Machek [160207 13:24]:
>
> > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> > 000d 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
* Tony Lindgren [160209 09:26]:
> * Pavel Machek [160207 13:24]:
>
> > ffdffebd 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200042
> > 000d 48004a28 (fa004a28) cm_idlest3_core
>
> Bit 21 in cm_idlest1_core is for MCSPI4 so WLAN. Does that go
> down
* Tony Lindgren [160209 09:26]:
> * Pavel Machek [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
* Pavel Machek [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
* Pavel Machek [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
* Tony Lindgren [160209 09:26]:
> * Pavel Machek [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
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.ro...@gmail.com
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.ro...@gmail.com
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
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
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
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
* Tony Lindgren [160201 14:12]:
> * Pavel Machek [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
* Tony Lindgren [160201 14:12]:
> * Pavel Machek [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
* Pavel Machek [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
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)
> > > [
* Pavel Machek [160130 14:16]:
> Hi!
>
> > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > > > 000d 48004a28 (fa004a28) cm_idlest3_core
> > > > >
> > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems
> > > > > constant.
> > > >
>
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)
> > > [
* Pavel Machek [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
* Pavel Machek [160130 14:16]:
> Hi!
>
> > > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > > > 000d 48004a28 (fa004a28) cm_idlest3_core
> > > > >
> > > > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems
> > > > >
Hi!
> > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > > 000d 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
On Sat 2016-01-30 21:02:45, Pavel Machek wrote:
> Hi!
>
> > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > 000d 48004a28 (fa004a28) cm_idlest3_core
> > >
> > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems
> > > constant.
> >
> > For
Hi!
> > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > 000d 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
>
Hi!
> > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > 000d 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
>
On Sat 2016-01-30 21:02:45, Pavel Machek wrote:
> Hi!
>
> > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > 000d 48004a28 (fa004a28) cm_idlest3_core
> > >
> > > cm_idlest1_core changes periodicall often, to 00218072. The rest seems
> > > constant.
> >
> > For
Hi!
> > > > ffdffe8d 48004a20 (fa004a20) cm_idlest1_core blocking bits: 00200072
> > > > 000d 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
* Tony Lindgren [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"
* Pavel Machek [160126 06:01]:
>
> It seems like I have rather lot of blocking bits:
>
> 1fff 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
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
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
* Pavel Machek [160126 06:01]:
>
> It seems like I have rather lot of blocking bits:
>
> 1fff 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
* Tony Lindgren [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
* Pavel Machek [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.
>
>
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
* Pavel Machek [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
* Pavel Machek [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
* Pavel Machek [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
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
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/
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/
62 matches
Mail list logo