jitterless touchscreen input in .34 [working proof of concept]

[Gennady Kupava]

Hi, all.

I have tons of ideas how to improve kernel more. But I am very uncertain
_then_ i'll be able to spend any time on it. So, here is what i already
have, my patch to fix jitter without filtering. I think as everyone gone
to .34, it may be important now.

Main idea is to slow down glamo pixplock while doing adc conversions.
So, it works like this:

<get ts down interrupt>
<wait for vsync>
<slow down glamo pixclock>
<start ts adc>
<wait for full adc cycle>
<restore glamo pixclock>

it is not really simple. busy waiting for vsync if really too long (eats
cpu and so), so it were changed to waiting for hsync (i can't recall
details) and i didn't find way to understand if we 'close to vsync end'.
doing this without any waiting will procude small but noticeable visual
effects (1 white line per second). reducing averaging sample count also
required because overwise glamo will be slowed down for long time, which
increase probability of visible effects.

Expirements show that probability of getting wrong data is 10 or 100
times lower while glamo pixclock slowed down. I wrote proof of concept
patch. It works well here for few months. Result is not ideal, worse in
some aspects and better in other aspects than _filtering driver_ but
much better than with default .34 driver, i can say that event data is
fully usable for any kind of work after this change.

One who want to test it will need to manually apply patches, because i
had to extract code from my custom tree.

patch: http://www.bsdmn.com/openmoko/kernel/jitterlessts34.patch

As you have no need to filter, it generates significantly less events
and doing less conversions, which should have positive influence on both
power consumption and performance. I works here for several months in my
debian.

Known limitations/hacks:
I can't do proper locking, so it is more like working proof of concept,
it just sets pixclock to predefined portrait-mode value, that's why it
shows snow in landscape mode while rotated. I don't know how to do
proper allocation of 'glamo' struct.

Regards,
Gennady

[Martin Jansa]

Post by Gennady Kupava
Hi, all.
I have tons of ideas how to improve kernel more. But I am very uncertain
_then_ i'll be able to spend any time on it. So, here is what i already
have, my patch to fix jitter without filtering. I think as everyone gone
to .34, it may be important now.

Sure, great! Thanks for sharing the patch!

I can confirm that ts behaves much better with it (I'll probably push it
with new shr-u, even when it's intended as proof of concept).

Patch applied on top of SHR 2.6.34 kernel:
http://gitorious.org/~jama/htc-msm-2-6-32/openmoko-kernel/commit/ca0ced6d80c32dd7eed1c3ea2e539a38692a4fd7

Regards,

[Radek Polak]

Post by Gennady Kupava
I have tons of ideas how to improve kernel more. But I am very uncertain
_then_ i'll be able to spend any time on it. So, here is what i already
have, my patch to fix jitter without filtering. I think as everyone gone
to .34, it may be important now.

Hi Gennady,
you deserve some very high place in openmoko hall of fame for your work.
Tested the patch and i am also happy to confirm that it works.

Thanks!

Radek

[Gennady Kupava]

Post by Radek Polak
you deserve some very high place in openmoko hall of fame for your work.
Tested the patch and i am also happy to confirm that it works.

Hi, Radek.

If should be done better:

a. this patch links glamo to ts, this should be done in different way.
It should do proper locking and allocating of glamo resourse.
b. It should save current register setting.
c. It is possible to avoid waiting completely and probably get less
jitter but setting s3c timer to wait specific time calculated based on
current x-y position and pixclock rate.
d. It also highlight some strange behaviour of s3c ts then it is touched
too gently - it sometimes generates events diagonally moved to corner
relative to correct position.

Because of all this i bet it has even inplemented well it has less
chances to be merged upstream one day than kernel filtering driver. But
this solution is without any doubt much better than userspace filtering
or without any filtering. If p. (c) is implemented, this will be better
than any filtering without doubts.

And now, as this conceptual hack put me so high to hall of fame, i
consider i can cast 3 simple wishes for qtmoko ;) :

1. i wish compiled-in guid partition table type into kernel;
2. i wish xfs module to kernel (as ubifs is comressed fs, it should not
eat too much space);
3. i wish 100HZ patch included to qtmoko
(http://www.bsdmn.com/openmoko/kernel/0001-Use-100-as-HZ-value-on-S3C24XX.patch)

Regards,
Gennady

[Radek Polak]

Post by Gennady Kupava
And now, as this conceptual hack put me so high to hall of fame, i
1. i wish compiled-in guid partition table type into kernel;

I can try if i find correct config options. If not i'll ask :)

Post by Gennady Kupava
2. i wish xfs module to kernel (as ubifs is comressed fs, it should not
eat too much space);

As module or compiled in?

Post by Gennady Kupava
3. i wish 100HZ patch included to qtmoko
(http://www.bsdmn.com/openmoko/kernel/0001-Use-100-as-HZ-value-on-S3C24XX.p
atch)

Oki, i can try, is there any description for the patch? E.g. What does it do
and how can i test it?

Regards

Radek

[Gennady Kupava]

Post by Radek Polak

Post by Gennady Kupava
And now, as this conceptual hack put me so high to hall of fame, i
1. i wish compiled-in guid partition table type into kernel;

I can try if i find correct config options. If not i'll ask :)

CONFIG_EFI_PARTITION, thanks :)

Post by Radek Polak

Post by Gennady Kupava
2. i wish xfs module to kernel (as ubifs is comressed fs, it should not
eat too much space);

As module or compiled in?

Module is ok. It's a bit too large to compile in for everyone due to our
128Mb of ram size.

Post by Radek Polak

Post by Gennady Kupava
3. i wish 100HZ patch included to qtmoko
(http://www.bsdmn.com/openmoko/kernel/0001-Use-100-as-HZ-value-on-S3C24XX.p
atch)

Oki, i can try, is there any description for the patch? E.g. What does it do
and how can i test it?

It does simple thing - change HZ value of linux kernel from 200HZ to
100HZ. Main reason is performance.

My rationale is following:
Basically this mean that timer interrupts amount will be reduced from
200 per second to 100 per second. This allows:

Pros:
1. Stay more in IDLE state. (less power consumption)
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.
3. Less interrupts is good on it's own.

Cons:
1. Worse granilarity of delays and sheduled works. I think it's
impossible
2. May reveal some bugs, as any new non-trivial system-wide change.
Basically it works here, but i didn't test everything.

Other arguments:
I checked other boards config files and it turned out that only few of
them (10% or so) using 200 as HZ value.

I did lmbenching and found that difference is few percent, but still
noticeable.

I can't 'feel' that something changed.

So, this patch is just sets new value for HZ and changes s3c timer
interrupt frequency.

Big thanks to Vasily 'anarsoul' Khoruzhick for patch written on my
request.

Regards,
Gennady

[Riccardo Magliocchetti]

Post by Gennady Kupava

Post by Radek Polak

Post by Gennady Kupava
3. i wish 100HZ patch included to qtmoko
(http://www.bsdmn.com/openmoko/kernel/0001-Use-100-as-HZ-value-on-S3C24XX.p
atch)

Oki, i can try, is there any description for the patch? E.g. What does it do
and how can i test it?

It does simple thing - change HZ value of linux kernel from 200HZ to
100HZ. Main reason is performance.
Basically this mean that timer interrupts amount will be reduced from
1. Stay more in IDLE state. (less power consumption)

I think that this is something that would be more noticeable with Vasily's
"S3C24xx GENERIC_TIME / GENERIC_CLOCKEVENT support" patch.

Post by Gennady Kupava
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.
3. Less interrupts is good on it's own.
1. Worse granilarity of delays and sheduled works. I think it's
impossible
2. May reveal some bugs, as any new non-trivial system-wide change.
Basically it works here, but i didn't test everything.
I checked other boards config files and it turned out that only few of
them (10% or so) using 200 as HZ value.
I did lmbenching and found that difference is few percent, but still
noticeable.
I can't 'feel' that something changed.

Has anyone investigated gathering some data with ftrace? examples start
from line 246.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/trace/ftrace.txt;h=557c1edeccaf72535464298743cddd3c8eb01bea;hb=HEAD

Post by Gennady Kupava
So, this patch is just sets new value for HZ and changes s3c timer
interrupt frequency.

Wouldn't something like that in arch/arm/Kconfig avoid changes in
arch/arm/plat-samsung/time.c?

default 100 if ARCH_S3C2410

Just asking :)

thanks,
riccardo

[Vasily Khoruzhick]

Post by Riccardo Magliocchetti
I think that this is something that would be more noticeable with Vasily's
"S3C24xx GENERIC_TIME / GENERIC_CLOCKEVENT support" patch.

Unfortunatelly kernel hangs after resume with this patch :)

Regards
Vasily

[Gennady Kupava]

Post by Riccardo Magliocchetti

Post by Gennady Kupava

Post by Radek Polak

Post by Gennady Kupava
3. i wish 100HZ patch included to qtmoko
(http://www.bsdmn.com/openmoko/kernel/0001-Use-100-as-HZ-value-on-S3C24XX.p
atch)

Oki, i can try, is there any description for the patch? E.g. What does it do
and how can i test it?

It does simple thing - change HZ value of linux kernel from 200HZ to
100HZ. Main reason is performance.
Basically this mean that timer interrupts amount will be reduced from
1. Stay more in IDLE state. (less power consumption)

I think that this is something that would be more noticeable with Vasily's
"S3C24xx GENERIC_TIME / GENERIC_CLOCKEVENT support" patch.

This is not so trivial changes as in HZ patch.

Post by Riccardo Magliocchetti

Post by Gennady Kupava
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.
3. Less interrupts is good on it's own.
1. Worse granilarity of delays and sheduled works. I think it's
impossible
2. May reveal some bugs, as any new non-trivial system-wide change.
Basically it works here, but i didn't test everything.
I checked other boards config files and it turned out that only few of
them (10% or so) using 200 as HZ value.
I did lmbenching and found that difference is few percent, but still
noticeable.
I can't 'feel' that something changed.

Here, I mean that I can't feel any difference while using system with
100HZ timer. Main purpose of high HZ is to make task switching so fast
so human can't notice it.

[Patryk Benderz]

[cut]

Post by Gennady Kupava
1. Stay more in IDLE state. (less power consumption)
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.

Hi Gennady,
each time you come with such a news, it makes me wonder how much more
can be done to make FR run faster? :)

[cut]

Post by Gennady Kupava
I did lmbenching and found that difference is few percent, but still
noticeable.

Remember: small performance gain here, small there, and nex year it will
be twice faster :)

BTW, can you tell me if FCSE is already enabled in some recent kernel
available for mere mortal users? If so, how can one check it?

[Gennady Kupava]

Post by Radek Polak
[cut]

Post by Gennady Kupava
1. Stay more in IDLE state. (less power consumption)
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.

Hi Gennady,
each time you come with such a news, it makes me wonder how much more
can be done to make FR run faster? :)

Hi, Patryk

Hm... why not make short list of interesting non-trivial kernel
ideas? :)

Who knows, may be some fellow kernel dev who wish to learn something
about HW will find something interesting in list.

1. Performance: Investigate strange sd card speed (already tested that
this is not glamo<->cpu bus speed problem).
2. Performance: Investigate strange sdram r/w speed. Really not easy but
interesting task.
3. Performance: Implement usd card DMA
4. Performance: Our flash still do software ECC check while hw can do hw
ECC without problems.
5. Power consumption: In suspend, our dear PMU unit seem in Active
state. Investigate can we put it to Standby (this should save near 1mA
out of 5mA in Standby)

Post by Radek Polak
[cut]

Post by Gennady Kupava
I did lmbenching and found that difference is few percent, but still
noticeable.

Remember: small performance gain here, small there, and nex year it will
be twice faster :)
BTW, can you tell me if FCSE is already enabled in some recent kernel
available for mere mortal users? If so, how can one check it?

Now it is not included in any kernel AFAIK.

Personally i am waiting for FCSE patch (as you can recall author
promised that he can do it then he'll have free time) for .34 kernel to
test it, do lmbenching and then attempt to convience Radek to include it
to QtMoko :)

Regards,
Gennady

[Martix]

Post by Gennady Kupava

Post by Radek Polak
[cut]

Post by Gennady Kupava
1. Stay more in IDLE state. (less power consumption)
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.

Hi Gennady,
each time you come with such a news, it makes me wonder how much more
can be done to make FR run faster? :)

Hi, Patryk
Hm... why not make short list of interesting non-trivial kernel
ideas? :)
Who knows, may be some fellow kernel dev who wish to learn something
about HW will find something interesting in list.
1. Performance: Investigate strange sd card speed (already tested that
this is not glamo<->cpu bus speed problem).
2. Performance: Investigate strange sdram r/w speed. Really not easy but
interesting task.
3. Performance: Implement usd card DMA
4. Performance: Our flash still do software ECC check while hw can do hw
ECC without problems.

I read on #openmoko-cdevel few months ago that hardware NAND ECC is
buggy. What changed? Was it only rumor or SW bug?

Post by Gennady Kupava
5. Power consumption: In suspend, our dear PMU unit seem in Active
state. Investigate can we put it to Standby (this should save near 1mA
out of 5mA in Standby)

According to An Analysis of Power Consumption in a Smartphone*
components like Glamo, Wi-Fi and Audio consumes some miliwats in
suspend. Perhaps its just leakage current, but can we power down the
PMU regulators and save more energy? We need to investigate how actual
are this results, because 68,8 mW is too much than actual 16,5 mW (5
mA * approx. 3,3 V.

* http://ertos.nicta.com.au/publications/papers/Carroll_Heiser_10.pdf

Post by Gennady Kupava

Post by Radek Polak
[cut]

Post by Gennady Kupava
I did lmbenching and found that difference is few percent, but still
noticeable.

Remember: small performance gain here, small there, and nex year it will
be twice faster :)
BTW, can you tell me if FCSE is already enabled in some recent kernel
available for mere mortal users? If so, how can one check it?

Now it is not included in any kernel AFAIK.

FCSE patch is not included in SHR kernel yet.

Post by Gennady Kupava
Personally i am waiting for FCSE patch (as you can recall author
promised that he can do it then he'll have free time) for .34 kernel to
test it, do lmbenching and then attempt to convience Radek to include it
to QtMoko :)

I added FCSE patch author to CC for a remind.

Post by Gennady Kupava
Regards,
Gennady

Regards,

Martix

[Vasily Khoruzhick]

Post by Martix
I read on #openmoko-cdevel few months ago that hardware NAND ECC is
buggy. What changed? Was it only rumor or SW bug?

It's buggy on some s3c2410 CPUs, it's bug free on s3c2442, but ECC layout is a
bit weird :)

Regards
Vasily

[Gennady Kupava]

Post by Martix

Post by Martix
I read on #openmoko-cdevel few months ago that hardware NAND ECC is
buggy.

What changed? Was it only rumor or SW bug?
It's buggy on some s3c2410 CPUs, it's bug free on s3c2442, but ECC layout is a
bit weird :)

But ECC calculations for HW ECC and SW ECC are same? In-kernel
implementation is ok? So... need to investigate how to turn it on.

Gennady.

[Lars-Peter Clausen]

Post by Gennady Kupava

Post by Martix

Post by Martix
I read on #openmoko-cdevel few months ago that hardware NAND ECC is
buggy.

What changed? Was it only rumor or SW bug?
It's buggy on some s3c2410 CPUs, it's bug free on s3c2442, but ECC layout is a
bit weird :)

But ECC calculations for HW ECC and SW ECC are same? In-kernel
implementation is ok? So... need to investigate how to turn it on.
Gennady.

Pretty simple: boot with hardware_ecc=1

But I think the ecc layout is different between HW and SW ECC, so you'll probably
need to turn on HW ECC in u-boot as well.

- - Lars

[Gennady Kupava]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Gennady Kupava

Post by Martix

Post by Martix
I read on #openmoko-cdevel few months ago that hardware NAND ECC is
buggy.

What changed? Was it only rumor or SW bug?
It's buggy on some s3c2410 CPUs, it's bug free on s3c2442, but ECC layout is a
bit weird :)

But ECC calculations for HW ECC and SW ECC are same? In-kernel
implementation is ok? So... need to investigate how to turn it on.
Gennady.

Pretty simple: boot with hardware_ecc=1
But I think the ecc layout is different between HW and SW ECC, so you'll probably
need to turn on HW ECC in u-boot as well.

Thanks for suggestion, i tested it. Seem it works very well.

And yes, it's just bootloader that do not support it. So, i just backup
my qtmoko, enabled ecc in kernel in bootloader, reformat my / partition
on flash, copy qtmoko back, and it works very well. In-kernel support
seem fine, i am using it for 2 days and it's working well.

I did some tests, seem ubifs with zlib, in reading urandom data (same
for each test of course) test speed is increased from 3.9Mb/s to 4.2Mb/s
while using hw ecc.

My plan is to add support of hw ecc to u-boot: may be port from linux
kernel of use some patches for u-boot floating around.

Btw, also i've found that ubifs contains additional crc check, which can
be disabled (while reading only), raising speed from 3.7Ms/s to 3.9Mb/s.
(mount option no_chk_data_crc or kernel option
'rootflags=no_chk_data_crc')
Suggest to remove that crc, as we already have ecc and write verify
turned on.

Such sad read speed in general caused by zlib, according to this tab:
http://www.linux-mtd.infradead.org/misc.html#L_ubifs_compr it should be
much better with lzo, but i can understand value of free space :)

regards,
Gennady.

[Vasily Khoruzhick]

Post by Gennady Kupava
But ECC calculations for HW ECC and SW ECC are same? In-kernel
implementation is ok? So... need to investigate how to turn it on.

They aren't same, s3c2442 nand controller uses it's own ecc layout, it is not
compatible with default linux layout, so it's not easy to switch from sw ecc
to hw ecc.

Regards
Vasily

[Gilles Chanteperdrix]

Post by Martix

Post by Gennady Kupava

Post by Radek Polak
[cut]

Post by Gennady Kupava
1. Stay more in IDLE state. (less power consumption)
2. If several tasks are active, do 2 times less context switches (and
our context switches are expensive). Do not think it will be 'slow'.
This is not applied to all tasks - but only to CPU bound ones.

Hi Gennady,
each time you come with such a news, it makes me wonder how much more
can be done to make FR run faster? :)

Hi, Patryk
Hm... why not make short list of interesting non-trivial kernel
ideas? :)
Who knows, may be some fellow kernel dev who wish to learn something
about HW will find something interesting in list.
1. Performance: Investigate strange sd card speed (already tested that
this is not glamo<->cpu bus speed problem).
2. Performance: Investigate strange sdram r/w speed. Really not easy but
interesting task.
3. Performance: Implement usd card DMA
4. Performance: Our flash still do software ECC check while hw can do hw
ECC without problems.

I read on #openmoko-cdevel few months ago that hardware NAND ECC is
buggy. What changed? Was it only rumor or SW bug?

Post by Gennady Kupava
5. Power consumption: In suspend, our dear PMU unit seem in Active
state. Investigate can we put it to Standby (this should save near 1mA
out of 5mA in Standby)

According to An Analysis of Power Consumption in a Smartphone*
components like Glamo, Wi-Fi and Audio consumes some miliwats in
suspend. Perhaps its just leakage current, but can we power down the
PMU regulators and save more energy? We need to investigate how actual
are this results, because 68,8 mW is too much than actual 16,5 mW (5
mA * approx. 3,3 V.
* http://ertos.nicta.com.au/publications/papers/Carroll_Heiser_10.pdf

Post by Gennady Kupava

Post by Radek Polak
[cut]

Post by Gennady Kupava
I did lmbenching and found that difference is few percent, but still
noticeable.

Remember: small performance gain here, small there, and nex year it will
be twice faster :)
BTW, can you tell me if FCSE is already enabled in some recent kernel
available for mere mortal users? If so, how can one check it?

Now it is not included in any kernel AFAIK.

FCSE patch is not included in SHR kernel yet.

Post by Gennady Kupava
Personally i am waiting for FCSE patch (as you can recall author
promised that he can do it then he'll have free time) for .34 kernel to
test it, do lmbenching and then attempt to convience Radek to include it
to QtMoko :)

I added FCSE patch author to CC for a remind.

Ok. The FCSE patch author is still busy with some other stuff. Thanks
for the reminder. I can not provide any delay...

[Gennady Kupava]

Post by Radek Polak

Post by Gennady Kupava
And now, as this conceptual hack put me so high to hall of fame, i

Hi Gennady,
it's done now, i hope i did it ok.
http://github.com/radekp/linux-2.6/tree/qtmoko-v29
Radek

Radek, execellent, thanks!

Now i can use this tree as basis for any experiments/fixes as it seem
has all essential patches I used.

I'll build it soon and start using it for main phone distro (qtmoko v28)
and for my debian on sd.

I want to say, now worst problem with my freerunner is not speed but few
remaining bugs.

So far, i can report few serous problems noticed in v28 (sorry), just
for record. I can live with em. (My qtmoko is with udev, u-boot with
2-4-2).

1. (?) I can't shutdown device via power-button menu. Poweroff from ssh
works just fine.

2. (ubifs?) Almost each time i am doing unclean shutdown (including
after p.1) something weird happens - it resets my theme, show me green
welcome screen, but do not ask for calibration. So i bet some files
geting lost/corrupted. But fs does not look corrupted. I should notice,
once i had same thing with jffs2. I lost my messages btw. Really major
problem, but somehow i think this is not ubifs problems. I've read on
it's site that is it designed to handle hard-resets with adequate
results.

3. (suspend) Once it didn't resume (on manual resume with power button)
without any visible reason (it were at home). I didn't tried to ping.
(it made me sad)

4. (GSM) Once it were unable to set proper alsa(?) settings from GSM
call which were recieved while suspend. Phone resume, show incoming call
properly, but i were unable to hear anything. I didn't test GSM after
that.

5. really unsure: may be also something wrong with GPS. Seem it works
well after boot, but after resume it had problems to get fix. But same
were in .29.

But yeah, finally temperature-dependent WSOD should be forget and closed
forewer. I used in on the street where is quite cold now, and my
previous qtmoko got 100% constant, reliable, unrecoverable WS.

ubifs works well i think, and overall system is very usable. For a few
days i had to use phone in very heavy way and were completely happy how
did it perform (expect 1 case of p.4).

Gennady.

[Radek Polak]

Post by Gennady Kupava
Now i can use this tree as basis for any experiments/fixes as it seem
has all essential patches I used.

Nice

Post by Gennady Kupava
1. (?) I can't shutdown device via power-button menu. Poweroff from ssh
works just fine.

What is the problem? I can press POWER for 2s and it brings me to the power
menu where i can restart/power off and it works.

Post by Gennady Kupava
2. (ubifs?) Almost each time i am doing unclean shutdown (including
after p.1) something weird happens - it resets my theme, show me green
welcome screen, but do not ask for calibration. So i bet some files
geting lost/corrupted. But fs does not look corrupted. I should notice,
once i had same thing with jffs2. I lost my messages btw. Really major
problem, but somehow i think this is not ubifs problems. I've read on
it's site that is it designed to handle hard-resets with adequate
results.

Yes it's doing ubifs. JFFS2 maybe had the same problem but i have personally
never seen it. With ubifs i sometimes get the welcome screen too. It would be
interesting to explore why the welcome screen shows up. Maybe some config file
remains open during hard reset and ubifs does not like it.

Post by Gennady Kupava
3. (suspend) Once it didn't resume (on manual resume with power button)
without any visible reason (it were at home). I didn't tried to ping.
(it made me sad)

I think i hit something like this too, but very rarely.

Post by Gennady Kupava
4. (GSM) Once it were unable to set proper alsa(?) settings from GSM
call which were recieved while suspend. Phone resume, show incoming call
properly, but i were unable to hear anything. I didn't test GSM after
that.

No idea, i get only very few calls so i havent hit it yet.

Post by Gennady Kupava
5. really unsure: may be also something wrong with GPS. Seem it works
well after boot, but after resume it had problems to get fix. But same
were in .29.

It would be nice to have application which shows GPS sattelites for debugging
this. In fact such app is already there [1] but works only with GPSD. I wanted
to modify qtopia gps api so that it provides GPSD compatible socket so that
gpsd apps like this one and e.g. tangogps can work out of the box.

You can also try to comment out agps data dumping/restoring in
/opt/qtmoko/bin/gps* scripts.

Post by Gennady Kupava
ubifs works well i think, and overall system is very usable. For a few
days i had to use phone in very heavy way and were completely happy how
did it perform (expect 1 case of p.4).

I also think 2.6.34 is very usable. If there is problem it's very rare. Andy-
tracking was probably more stable, but also it's ugly mess without future from
my POV. I can keep 2.6.29 supported forever in my git, but i will probably not
do any qtmoko releases based on 2.6.29.

Regards

Radek


[1] http://github.com/radekp/qtopiagps

[Patryk Benderz]

[cut]

Post by Radek Polak
What is the problem? I can press POWER for 2s and it brings me to the power
menu where i can restart/power off and it works.

I can confirm this - power button works fine here.

[cut]

Post by Radek Polak

Post by Gennady Kupava
3. (suspend) Once it didn't resume (on manual resume with power button)
without any visible reason (it were at home). I didn't tried to ping.
(it made me sad)

Tried 10 times in a row but couldn't reproduce - it wakes up instantly!
Runs smoothly after waking up from suspend. Twice I was able to notice a
performance loss within ~10-15 seconds after wake up.
[cut]

[Gennady Kupava]

Post by Patryk Benderz
[cut]

Post by Gennady Kupava
3. (suspend) Once it didn't resume (on manual resume with power button)
without any visible reason (it were at home). I didn't tried to ping.
(it made me sad)

Tried 10 times in a row but couldn't reproduce - it wakes up instantly!
Runs smoothly after waking up from suspend. Twice I was able to notice a
performance loss within ~10-15 seconds after wake up.
[cut]

It worked 100 times. But once it didn't. May be this related for example
to https://docs.openmoko.org/trac/ticket/2309 .

Gennady.

[Gennady Kupava]

Hi, Radek, David.

Post by Radek Polak

Post by Gennady Kupava
5. really unsure: may be also something wrong with GPS. Seem it works
well after boot, but after resume it had problems to get fix. But same
were in .29.

It would be nice to have application which shows GPS sattelites for debugging
this. In fact such app is already there [1] but works only with GPSD. I wanted
to modify qtopia gps api so that it provides GPSD compatible socket so that
gpsd apps like this one and e.g. tangogps can work out of the box.

Yes! Such application is really really missing. Something with just
displaying some kind debugging info and satellites signal levels, like
in my Garmin would be very useful, as it will help greatly. Is it
getting fix or not? how long it will take? how much satellites visible?
Current situation in nerongps (fix/not fix) is not really informative.
Also it is great idea to support most common universal unix GPS
interface.

Post by Radek Polak
Could you try with Qi? I've not tried with qtmoko, but I have the same

sympthoms with u-boot + shr.

Nice hint, thanks! If so fix for u-boot should be relatively simple.
Something related to serials setup :) I'll try to fix this... later.

Post by Radek Polak
"One difference between uboot and qi is that qi doesn't initialize the

display."

NO! I am sure where is much more difference. I am sure main problem of u-boot were
'too complicated to make changes, let's rewrite'. I am sure where is MORE difference, as
bootloader seem responsible to initial init of many openmoko's hardware.
For example, with NOR u-boot, current in suspend in 10 times more than with NAND one with same
kernel. Most voltages, memory timings, cpu frequency are set in bootloader and not touched by kernel
(it's just what i know). Serial ports seem setup also somehow related to bootloader.

Btw, as we have absolutely no WSODs no with u-boot (which inits display), and WSOD issue
can be attributed to particular patches, where is no reason not to init display.

Regards,
Gennady.

[Gennady Kupava]

Hi, all.

Seem i fixed this one. Need fix for both kernel and u-boot. Kernel fix
is complete harmless, it will work under any conditions.

U-boot patch:
http://www.bsdmn.com/openmoko/gpsfix/uboot_do_not_touch_serials.patch
Idea of this patch is to keep u-boot from controlling serial's GPIO
configuration. It turned out that u-boot also touch GSM port
configuration on resume. This turns this off.

Kernel patch:
http://www.bsdmn.com/openmoko/gpsfix/kernel_Force-GPS-power-up-on-resume-if-it-were-powered-up-on-suspend.patch

I also did precompiled versions for whoose who using u-boot and qtmoko:

Compiled u-boot (242 + this fix):
http://www.bsdmn.com/openmoko/gpsfix/u-boot_242_gps.udfu
Compiled kernel (qtmoko29 + latest ts jitter + this fix):
http://www.bsdmn.com/openmoko/gpsfix/uImage-b6.bin
Kernel modules: http://www.bsdmn.com/openmoko/gpsfix/modules-b6.tar.gz

Extract kernel to /, do depmod -a 2.6.34b6-v28, flash kernel, u-boot and
it should work.

Regards,
Gennady.

Post by Gennady Kupava
Hi, Radek, David.

Post by Radek Polak

Post by Gennady Kupava
5. really unsure: may be also something wrong with GPS. Seem it works
well after boot, but after resume it had problems to get fix. But same
were in .29.

It would be nice to have application which shows GPS sattelites for debugging
this. In fact such app is already there [1] but works only with GPSD. I wanted
to modify qtopia gps api so that it provides GPSD compatible socket so that
gpsd apps like this one and e.g. tangogps can work out of the box.

Yes! Such application is really really missing. Something with just
displaying some kind debugging info and satellites signal levels, like
in my Garmin would be very useful, as it will help greatly. Is it
getting fix or not? how long it will take? how much satellites visible?
Current situation in nerongps (fix/not fix) is not really informative.
Also it is great idea to support most common universal unix GPS
interface.

Post by Radek Polak
Could you try with Qi? I've not tried with qtmoko, but I have the same

sympthoms with u-boot + shr.
Nice hint, thanks! If so fix for u-boot should be relatively simple.
Something related to serials setup :) I'll try to fix this... later.

Post by Radek Polak
"One difference between uboot and qi is that qi doesn't initialize the

display."
NO! I am sure where is much more difference. I am sure main problem of u-boot were
'too complicated to make changes, let's rewrite'. I am sure where is MORE difference, as
bootloader seem responsible to initial init of many openmoko's hardware.
For example, with NOR u-boot, current in suspend in 10 times more than with NAND one with same
kernel. Most voltages, memory timings, cpu frequency are set in bootloader and not touched by kernel
(it's just what i know). Serial ports seem setup also somehow related to bootloader.
Btw, as we have absolutely no WSODs no with u-boot (which inits display), and WSOD issue
can be attributed to particular patches, where is no reason not to init display.
Regards,
Gennady.

[David Garabana Barro]

Post by Gennady Kupava
Hi, all.
Seem i fixed this one. Need fix for both kernel and u-boot. Kernel fix
is complete harmless, it will work under any conditions.
http://www.bsdmn.com/openmoko/gpsfix/uboot_do_not_touch_serials.patch
Idea of this patch is to keep u-boot from controlling serial's GPIO
configuration. It turned out that u-boot also touch GSM port
configuration on resume. This turns this off.
http://www.bsdmn.com/openmoko/gpsfix/kernel_Force-GPS-power-up-on-resume-if
-it-were-powered-up-on-suspend.patch
http://www.bsdmn.com/openmoko/gpsfix/u-boot_242_gps.udfu
http://www.bsdmn.com/openmoko/gpsfix/uImage-b6.bin
Kernel modules: http://www.bsdmn.com/openmoko/gpsfix/modules-b6.tar.gz
Extract kernel to /, do depmod -a 2.6.34b6-v28, flash kernel, u-boot and
it should work.

Gennady

I've just tried patched u-boot with stock shr kernel (uImage-2.6.34.7-
oe9+gitr9+e4182f3551f1b8e8f8bd07a2d68e49a0ec4cd04a-r0-om-gta02.bin) and it
works for me.

Now I get a fix after suspending shr.

Don't know why it works without kernel patch, but it works.

Thanks a lot for fixing this!

[Gennady Kupava]

Post by Radek Polak

Post by Gennady Kupava
1. (?) I can't shutdown device via power-button menu. Poweroff from ssh
works just fine.

What is the problem? I can press POWER for 2s and it brings me to the power
menu where i can restart/power off and it works.

Ah, this seem my mistake! Really seem just somehow automatically pressed
wrong button 'Shutdown qt extended' (at least twice). Retested now 3
times, all is working.

Gennady.

[Timo Jyrinki]

Post by Radek Polak
I also think 2.6.34 is very usable. If there is problem it's very rare. Andy-
tracking was probably more stable, but also it's ugly mess without future from
my POV.

Well, "stable" as in "there were only five more rc releases and six
stable releases released to 2.6.29 after the andy-tracking branched
off at 2.6.29rc3". Openmoko wise yes some parts have seen more
testing, but it wouldn't be surprising if people have been hitting
various issues simply because the andy-tracking was really an early
development snapshot of 2.6.29 kernel.

Anyway, 2.6.34 is so much nearer to upstream (ca. 75 commits on top of
Torvalds' final commit) and actually based on a released kernel - it's
great to see that people are now more or less happily using it already
at this point!

-Timo

[David Garabana Barro]

Post by Gennady Kupava
5. really unsure: may be also something wrong with GPS. Seem it works
well after boot, but after resume it had problems to get fix. But same
were in .29.

Gennady
Could you try with Qi?

I've not tried with qtmoko, but I have the same sympthoms with u-boot + shr.
GPS only works until FR is suspended. More info on this thread:

http://www.mail-archive.com/shr-***@lists.shr-project.org/msg05539.html