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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Martin Jansa
On Wed, Oct 20, 2010 at 08:58:32PM +0400, Gennady Kupava wrote:
> 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,

--
Martin 'JaMa' Jansa     jabber: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Radek Polak
In reply to this post by Gennady Kupava
Gennady Kupava wrote:

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Gennady Kupava
В Чтв, 21/10/2010 в 22:04 +0200, 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Radek Polak
You wrote: > В Чтв, 21/10/2010 в 22:04 +0200, Radek Polak пишет:

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

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

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

As module or compiled in?

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

HZ value change groundings (Was: jitterless touchscreen input in .34)

Gennady Kupava
В Вск, 24/10/2010 в 19:34 +0200, Radek Polak пишет:
> You wrote: > В Чтв, 21/10/2010 в 22:04 +0200, Radek Polak пишет:
>
> > 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;
>
> I can try if i find correct config options. If not i'll ask :)

CONFIG_EFI_PARTITION, thanks :)

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

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34)

Riccardo Magliocchetti
Il 24/10/2010 20:10, Gennady Kupava ha scritto:

> В Вск, 24/10/2010 в 19:34 +0200, Radek Polak пишет:
>> You wrote:>  В Чтв, 21/10/2010 в 22:04 +0200, Radek Polak пишет:
>>
>>> 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)

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

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

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34)

Vasily Khoruzhick
On Monday 25 October 2010 10:15:13 Riccardo Magliocchetti wrote:

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Patryk Benderz
In reply to this post by Gennady Kupava
[cut]
> 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.
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]
> 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?
--
Patryk "LeadMan" Benderz
Linux Registered User #377521
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34)

Gennady Kupava
In reply to this post by Riccardo Magliocchetti
В Пнд, 25/10/2010 в 09:15 +0200, Riccardo Magliocchetti пишет:

> Il 24/10/2010 20:10, Gennady Kupava ha scritto:
> > В Вск, 24/10/2010 в 19:34 +0200, Radek Polak пишет:
> >> You wrote:>  В Чтв, 21/10/2010 в 22:04 +0200, Radek Polak пишет:
> >>
> >>> 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)
>
> 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.

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

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. From performance point of view, HZ of 10 will
be ok most purposes and will bring more performance over time than HZ of
100. But human will notice such HZ with any interactive session. So, if
I can't feel it - it is good, as this means that this HZ change only
brings performance benefits.

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

Oh... Seem it can provide tons of data about context switches, latency
and preemption and help find out many possible problems. Surely worth
trying.

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

All changes are in function specific to S3C2410. (It's not ok than code
has set of magic numbers of course, but this is other problem, yes? ;)

Regards,
Gennady


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Gennady Kupava
In reply to this post by Patryk Benderz
В Пнд, 25/10/2010 в 11:14 +0200, Patryk Benderz пишет:
> [cut]
> > 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.
> 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)

>
> [cut]
> > 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Martix
2010/10/25 Gennady Kupava <[hidden email]>:

> В Пнд, 25/10/2010 в 11:14 +0200, Patryk Benderz пишет:
>> [cut]
>> > 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.
>> 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?

> 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

>>
>> [cut]
>> > 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.

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

> Regards,
> Gennady

Regards,

Martix

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Vasily Khoruzhick
On Monday 25 October 2010 18:13:13 Martix wrote:

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Gennady Kupava
В Пнд, 25/10/2010 в 18:24 +0300, Vasily Khoruzhick пишет:
> On Monday 25 October 2010 18:13:13 Martix wrote:
>
> > I read on #openmoko-cdevel few months ago that hardware NAND ECC is
> > buggy.

Here is archive of openmoko-cdevel:

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Lars-Peter Clausen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gennady Kupava wrote:

> В Пнд, 25/10/2010 в 18:24 +0300, Vasily Khoruzhick пишет:
>> On Monday 25 October 2010 18:13:13 Martix wrote:
>>
>>> I read on #openmoko-cdevel few months ago that hardware NAND ECC is
>>> buggy.
>
> Here is archive of openmoko-cdevel:
>
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkzF6f0ACgkQBX4mSR26RiNIkACeMHAeS6CtkpuQHonP8fq6NvBA
E2gAn3M3SdYF4KMYVVP2I8oErDLW9GgP
=v6Nd
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Vasily Khoruzhick
In reply to this post by Gennady Kupava
On Monday 25 October 2010 22:27:27 Gennady Kupava wrote:

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Qtmoko] qtmoko v28 (was: HZ value change groundings)

Gennady Kupava
In reply to this post by Gennady Kupava
В Втр, 26/10/2010 в 09:36 +0200, Radek Polak пишет:

> On Sunday 24 October 2010 20:10:00 Gennady Kupava wrote:
>
> > > > And now, as this conceptual hack put me so high to hall of fame, i
> > > > consider i can cast 3 simple wishes for qtmoko ;) :
>
> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question

Gilles Chanteperdrix
In reply to this post by Martix
Martix wrote:

> 2010/10/25 Gennady Kupava <[hidden email]>:
>> В Пнд, 25/10/2010 в 11:14 +0200, Patryk Benderz пишет:
>>> [cut]
>>>> 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.
>>> 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?
>
>> 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
>
>>> [cut]
>>>> 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.
>
>> 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...


--
                                                                Gilles.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Qtmoko] qtmoko v28 (was: HZ value change groundings)

Radek Polak
In reply to this post by Gennady Kupava
On Tuesday 26 October 2010 17:48:30 Gennady Kupava wrote:

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

Nice

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

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

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

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

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

> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Qtmoko] qtmoko v28 (was: HZ value change groundings)

Davide
In reply to this post by Gennady Kupava

O Martes, 26 de Outubro de 2010, Gennady Kupava escribiu:

> В Втр, 26/10/2010 в 09:36 +0200, Radek Polak пишет:

> > On Sunday 24 October 2010 20:10:00 Gennady Kupava wrote:

>

> 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/[hidden email]/msg05539.html

--

David Garabana Barro

jabber & google talk ID: [hidden email]

Clave pública PGP/GPG: http://davide.garabana.com/pgp.html


signature.asc (205 bytes) Download Attachment
12
Loading...