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
 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


___
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
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-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 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 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 Cameron Frazier
On Thu, Feb 26, 2009 at 12:08 PM, Marco Trevisan (Treviño)
m...@3v1n0.net 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 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 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-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-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
f.hackenber...@chello.at 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 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


[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


Re: [SHR] Suspend / Resume speed

2009-02-23 Thread Timo Juhani Lindfors
Florian Hackenberger f.hackenber...@chello.at 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


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