HZ value change groundings (Was: jitterless touchscreen input in .34) + FCSE question
martix.cz at gmail.com
Mon Oct 25 17:13:13 CEST 2010
2010/10/25 Gennady Kupava <gb at bsdmn.com>:
> В Пнд, 25/10/2010 в 11:14 +0200, Patryk Benderz пишет:
>> > 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.
>> > 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.
More information about the openmoko-kernel