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

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Tue Oct 26 22:01:53 CEST 2010

Martix wrote:
> 2010/10/25 Gennady Kupava <gb at bsdmn.com>:
>> В Пнд, 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...


More information about the openmoko-kernel mailing list