Re: [SHR] Suspend / Resume speed

2009-02-27 Thread W.Kenworthy
On Fri, 2009-02-27 at 17:20 +0900, W.Kenworthy wrote:
> On Thu, 2009-02-26 at 22:31 +0100, Florian Hackenberger wrote:
> > On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote:
> > > Check your uboot commandline loglevel value... It highly impacts on the
> > > suspend/resume time. I've set it to 3 (but some time ago was set by the
> > > system to 8, and I had to wait more than 6-7 seconds to wake the phone,
> > > while it generally takes just 1-2 secs).
> > 
> > Thanks, that solved it! I documented this fact in the FAQ:
> > http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow
> > 
> > Cheers,
> > Florian
> > 
> This does make a huge difference! - wow! - I used to fail to answer
> calls because they had almost rang out by the FR resumed.
> 
> The test I just did had the ring almost coincident with the ring tone in
> the calling phones hand piece!
> 
> But ... how can I make it permanent? - I issue "saveenv" and it seems to
> do so, but if I power off and reboot its gone :(
> 
> BillK
> 
eh - the last part was operator error - cant save to "nor"!

BillK




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-27 Thread W.Kenworthy
On Thu, 2009-02-26 at 22:31 +0100, Florian Hackenberger wrote:
> On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote:
> > Check your uboot commandline loglevel value... It highly impacts on the
> > suspend/resume time. I've set it to 3 (but some time ago was set by the
> > system to 8, and I had to wait more than 6-7 seconds to wake the phone,
> > while it generally takes just 1-2 secs).
> 
> Thanks, that solved it! I documented this fact in the FAQ:
> http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow
> 
> Cheers,
>   Florian
> 
This does make a huge difference! - wow! - I used to fail to answer
calls because they had almost rang out by the FR resumed.

The test I just did had the ring almost coincident with the ring tone in
the calling phones hand piece!

But ... how can I make it permanent? - I issue "saveenv" and it seems to
do so, but if I power off and reboot its gone :(

BillK




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-27 Thread W.Kenworthy
Only part of the problem :(

There is also firmware upgrade - since moko11 (tried ~1 week) I did not
lose any calls/sms.  I then moved to shr-unstable and its finally
working almost like a phone 

BillK


On Thu, 2009-02-26 at 17:50 -0500, Warren Baird wrote:
> Interesting!
> 
> Would this impact resume from suspend on an incoming phone call?   The
> reason I abandoned the 2008.X family was that I was missing 3/4 of my
> incoming calls because by the time the phone unsuspended I had missed
> the call...   If this will fix it, maybe I can finally move off QtE...
> 
> Warren
> 
> 
> On Thu, Feb 26, 2009 at 4:31 PM, Florian Hackenberger
>  wrote:
> On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño)
> wrote:
> > Check your uboot commandline loglevel value... It highly
> impacts on the
> > suspend/resume time. I've set it to 3 (but some time ago was
> set by the
> > system to 8, and I had to wait more than 6-7 seconds to wake
> the phone,
> > while it generally takes just 1-2 secs).
> 
> 
> Thanks, that solved it! I documented this fact in the FAQ:
> http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow
> 
> Cheers,
>Florian
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread Warren Baird
Interesting!

Would this impact resume from suspend on an incoming phone call?   The
reason I abandoned the 2008.X family was that I was missing 3/4 of my
incoming calls because by the time the phone unsuspended I had missed the
call...   If this will fix it, maybe I can finally move off QtE...

Warren


On Thu, Feb 26, 2009 at 4:31 PM, Florian Hackenberger <
f.hackenber...@chello.at> wrote:

> On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote:
> > Check your uboot commandline loglevel value... It highly impacts on the
> > suspend/resume time. I've set it to 3 (but some time ago was set by the
> > system to 8, and I had to wait more than 6-7 seconds to wake the phone,
> > while it generally takes just 1-2 secs).
>
> Thanks, that solved it! I documented this fact in the FAQ:
> http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow
>
> Cheers,
> Florian
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread Florian Hackenberger
On Thursday 26 February 2009 18:08:54 Marco Trevisan (Treviño) wrote:
> Check your uboot commandline loglevel value... It highly impacts on the
> suspend/resume time. I've set it to 3 (but some time ago was set by the
> system to 8, and I had to wait more than 6-7 seconds to wake the phone,
> while it generally takes just 1-2 secs).

Thanks, that solved it! I documented this fact in the FAQ:
http://wiki.openmoko.org/wiki/FAQ#Why_is_resuming_from_suspend_so_slow

Cheers,
Florian

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread Cameron Frazier
On Thu, Feb 26, 2009 at 12:08 PM, "Marco Trevisan (Treviño)"
 wrote:
> Florian Hackenberger wrote:
>> I noticed that suspending / resuming on 2008.12 is quite fast compared
>> to SHR. The difference which is most noticeable is that SHR switches to
>> a virtual terminal before and right after suspending, as opposed to
>> 2008.12 which resumes right into X. Is there a way to replicate this
>> behaviour on SHR? I suspect that we could save at least a second of
>> resume time, because printing and scrolling a few hundred lines of
>> kernel log in addition to the mode switches takes a bit of time.
>
> Check your uboot commandline loglevel value... It highly impacts on the
> suspend/resume time. I've set it to 3 (but some time ago was set by the
> system to 8, and I had to wait more than 6-7 seconds to wake the phone,
> while it generally takes just 1-2 secs).
>
> Those commands in the uBoot shell should do the work:
> setenv bootargs roofstype=ext2 root=/dev/mmcblk0p2 console=tty0
> console=ttySAC2,115200 loglevel=3
> setenv bootargs_base rootfstype=jffs2 root=/dev/mtdblock6
> console=ttySAC2,115200 console=tty0 loglevel=3

Marco,

I tried what you have above and it seems to work quite well.
There is a small spelling mistake in the first command though:

"roofstype" should be "rootfstype", correct?

Also just to clarify, I almost missed it myself (caught it whilst
doing a typo check), the first command is for a SD card bootloader,
whereas the second command is for the internal flash?

Wicked fast resume though, I like it.

Regards,

Cameron

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread Marco Trevisan (Treviño)
Florian Hackenberger wrote:
> I noticed that suspending / resuming on 2008.12 is quite fast compared 
> to SHR. The difference which is most noticeable is that SHR switches to 
> a virtual terminal before and right after suspending, as opposed to 
> 2008.12 which resumes right into X. Is there a way to replicate this 
> behaviour on SHR? I suspect that we could save at least a second of 
> resume time, because printing and scrolling a few hundred lines of 
> kernel log in addition to the mode switches takes a bit of time.

Check your uboot commandline loglevel value... It highly impacts on the
suspend/resume time. I've set it to 3 (but some time ago was set by the
system to 8, and I had to wait more than 6-7 seconds to wake the phone,
while it generally takes just 1-2 secs).

Those commands in the uBoot shell should do the work:
setenv bootargs roofstype=ext2 root=/dev/mmcblk0p2 console=tty0
console=ttySAC2,115200 loglevel=3
setenv bootargs_base rootfstype=jffs2 root=/dev/mtdblock6
console=ttySAC2,115200 console=tty0 loglevel=3

-- 
Treviño's World - Life and Linux
http://www.3v1n0.net/


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:
| Michael 'Mickey' Lauer wrote:
|
|>> I don't think that they simply disable the backlight. Resuming from SHR
|>> unstable takes about 5-6 seconds (no incoming call), while 2008.12
resumes
|>> under 3 seconds. While this is not a scientific measurement, 2008.12
surely
|>> is a lot faster. Any other ideas what they do differently?
|> No idea, sorry. I have never seen 2008.12. It's definitely not a problem
|> in the base system, since FSO ms5.1 resolves in 1 second (admittedly,
|> with Qi, with U-Boot it might be 2 seconds).
|>
| My SHR resumed in about 4s. (Running from internal flash, not SDcard.)
| First, nothing happens. Then the console shows itself for a little
| while. finally, graphichs take over and the screen is redrawn.
|
| 1s would surely be an improvement.

If your kernel has the printk timestamping enabled, maybe the dmesg
during suspend / resume has a hint if it's something on the kernel side.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmmlxoACgkQOjLpvpq7dMptXwCdH85IfZksSKJyDQ6u5Akk4T7p
3a0AnRwU+LRs9p2d2syTWBT88wZbvibq
=GWNa
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread Helge Hafting
Michael 'Mickey' Lauer wrote:

>> I don't think that they simply disable the backlight. Resuming from SHR 
>> unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes 
>> under 3 seconds. While this is not a scientific measurement, 2008.12 surely 
>> is a lot faster. Any other ideas what they do differently?
> 
> No idea, sorry. I have never seen 2008.12. It's definitely not a problem
> in the base system, since FSO ms5.1 resolves in 1 second (admittedly,
> with Qi, with U-Boot it might be 2 seconds).
> 
My SHR resumed in about 4s. (Running from internal flash, not SDcard.)
First, nothing happens. Then the console shows itself for a little 
while. finally, graphichs take over and the screen is redrawn.

1s would surely be an improvement.

Helge Hafting

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-26 Thread arne anka
> It'll just be different loglevel= or console= on kernel commandline
> depending on which bootloader and where you're booting from.

which for which and where to find information on the parameters?
and btw: is there a way to do that to an already running system, sysfs or  
so? i never had any luck with changing uboot's cmd line.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-25 Thread Andy Green
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Somebody in the thread at some point said:

| Are you booting from NAND or NOR flash?  I know when I boot from NAND
| flash I see a bunch of text scroll by on resume.  I don't see that
| when booted from NOR.  I don't know why...  Have you tried that?

It'll just be different loglevel= or console= on kernel commandline
depending on which bootloader and where you're booting from.

- -Andy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmmBSkACgkQOjLpvpq7dMoQAwCaAj4gYunzAQGaAT4mc2R7DmfO
SPYAn1o0cBKB55DyKYYrUXIBM5qdwbWc
=1n1k
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-25 Thread Steven **
Are you booting from NAND or NOR flash?  I know when I boot from NAND
flash I see a bunch of text scroll by on resume.  I don't see that
when booted from NOR.  I don't know why...  Have you tried that?

-Steven

On Mon, Feb 23, 2009 at 2:32 AM, Florian Hackenberger
 wrote:
> I suspect that we could save at least a second of
> resume time, because printing and scrolling a few hundred lines of
> kernel log in addition to the mode switches takes a bit of time.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-25 Thread Michael 'Mickey' Lauer
Am Mittwoch, den 25.02.2009, 19:05 +0100 schrieb Florian Hackenberger:
> On Monday 23 February 2009 12:08:10 Michael 'Mickey' Lauer wrote:
> > Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger:
> > > I noticed that suspending / resuming on 2008.12 is quite fast compared
> > > to SHR. The difference which is most noticeable is that SHR switches to
> > > a virtual terminal before and right after suspending, as opposed to
> > > 2008.12 which resumes right into X.
> > Chances are they just cover up by turning backlight off prior to doing
> > real suspend and then wait until resume has happened before turning it
> > on again. We're not doing this yet, since we had our share with
> > suspend/resume problems in the past and only will do that once it proves
> > 100% solid.
> 
> I don't think that they simply disable the backlight. Resuming from SHR 
> unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes 
> under 3 seconds. While this is not a scientific measurement, 2008.12 surely 
> is a lot faster. Any other ideas what they do differently?

No idea, sorry. I have never seen 2008.12. It's definitely not a problem
in the base system, since FSO ms5.1 resolves in 1 second (admittedly,
with Qi, with U-Boot it might be 2 seconds).

> 
> > > Is there a way to replicate this
> > > behaviour on SHR? I suspect that we could save at least a second
> of
> > > resume time, because printing and scrolling a few hundred lines of
> > > kernel log in addition to the mode switches takes a bit of time.
> > IIRC Garmin had a patch in their Navi sources that removes switching
> the
> > VT on suspend/resume, which gave a) a better user experience and b)
> a
> > small speedup. We should pick that up IMO.
> 
> It should be easier to copy from 2008.12 shouldn't it?

No, 2008.12 certainly has no kernel patches like that.

:M:


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-25 Thread Florian Hackenberger
On Monday 23 February 2009 12:08:10 Michael 'Mickey' Lauer wrote:
> Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger:
> > I noticed that suspending / resuming on 2008.12 is quite fast compared
> > to SHR. The difference which is most noticeable is that SHR switches to
> > a virtual terminal before and right after suspending, as opposed to
> > 2008.12 which resumes right into X.
> Chances are they just cover up by turning backlight off prior to doing
> real suspend and then wait until resume has happened before turning it
> on again. We're not doing this yet, since we had our share with
> suspend/resume problems in the past and only will do that once it proves
> 100% solid.

I don't think that they simply disable the backlight. Resuming from SHR 
unstable takes about 5-6 seconds (no incoming call), while 2008.12 resumes 
under 3 seconds. While this is not a scientific measurement, 2008.12 surely 
is a lot faster. Any other ideas what they do differently?

> > Is there a way to replicate this
> > behaviour on SHR? I suspect that we could save at least a second of
> > resume time, because printing and scrolling a few hundred lines of
> > kernel log in addition to the mode switches takes a bit of time.
> IIRC Garmin had a patch in their Navi sources that removes switching the
> VT on suspend/resume, which gave a) a better user experience and b) a
> small speedup. We should pick that up IMO.

It should be easier to copy from 2008.12 shouldn't it?

Cheers,
Florian


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-23 Thread Michael 'Mickey' Lauer
Am Montag, den 23.02.2009, 09:32 +0100 schrieb Florian Hackenberger:
> I noticed that suspending / resuming on 2008.12 is quite fast compared 
> to SHR. The difference which is most noticeable is that SHR switches to 
> a virtual terminal before and right after suspending, as opposed to 
> 2008.12 which resumes right into X.

Chances are they just cover up by turning backlight off prior to doing
real suspend and then wait until resume has happened before turning it
on again. We're not doing this yet, since we had our share with
suspend/resume problems in the past and only will do that once it proves
100% solid.

> Is there a way to replicate this 
> behaviour on SHR? I suspect that we could save at least a second of 
> resume time, because printing and scrolling a few hundred lines of 
> kernel log in addition to the mode switches takes a bit of time.

IIRC Garmin had a patch in their Navi sources that removes switching the
VT on suspend/resume, which gave a) a better user experience and b) a
small speedup. We should pick that up IMO.

:M:


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [SHR] Suspend / Resume speed

2009-02-23 Thread Timo Juhani Lindfors
Florian Hackenberger  writes:
> behaviour on SHR? I suspect that we could save at least a second of 

Are you sure? To me it seemed that 2008.12 just turned the backlight
on only when you were already in X?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


[SHR] Suspend / Resume speed

2009-02-23 Thread Florian Hackenberger
Hi!

I noticed that suspending / resuming on 2008.12 is quite fast compared 
to SHR. The difference which is most noticeable is that SHR switches to 
a virtual terminal before and right after suspending, as opposed to 
2008.12 which resumes right into X. Is there a way to replicate this 
behaviour on SHR? I suspect that we could save at least a second of 
resume time, because printing and scrolling a few hundred lines of 
kernel log in addition to the mode switches takes a bit of time.

Cheers,
Florian

-- 
DI Florian Hackenberger
flor...@hackenberger.at
www.hackenberger.at

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community