On Fri, Nov 11, 2011 at 9:53 PM, Roman Mamedov <r...@romanrm.ru> wrote: > Hello, > > I have noticed that enabling the MFGPT timer in kernel config results in a > lower power consumption on the Yeeloong. It also seems that the CPU > temperature is generally a bit lower. My guess is that's due to MFGPT > allowing the kernel to utilize the "wait instruction" to put the CPU in a > low-power state. I have read that MFGPT causes side effects by making system > clock run incorrect, but so far I did not observe any problem with clock.
Yes, your analysis is almost right, one side, with the r4k timer for CPUFreq, the CPU can not enter into idle mode, but can only enter into the lowest active mode(2/8 of the 4 watt), which may consume more power, but on the other side, this r4k timer can make the CPUFreq work normally. I didn't test the whole power-consuming improvement of the r4k timer(compare to MFGPT timer), but If you enable the auto suspend(for example, ask gnome-power-manager or kpowersave to suspend your system if no action in 10 seconds or more, don't set the timeout to 30 minutes or more, they are not power-save friendly ^_^) and ondemand CPUFreq governor(Only use highest freq when the system are busy), I think, using R4K Timer may be better, for the suspend can put the whole system(including the CPU) into idle mode(the whole system is about 5~6 watt) eventually. One 'bad' side effect of using MFGPT timer is that the time precision is not good enough for making CPUfreq work normally, that's why we have tried to make the dynamic-frequency-R4K Timer work(Because it can not get precise time when the CPU is completely idle, although we can get the time from external RTC while in idle, the cost of time reading from a unprecise timer for a precise timer may introduce big time offset, that is why with it, the CPU can not enter into idle; Note: the current implemetation of the R4K Timer for CPUFreq is not good enough, may have about 10s offset in one day, it should be fixed at last, may be fixed through adding the lost time which have spent on maintaining the virtual 64bit counter). Another 'bad' side effect of using MFGPT timer(the new implementation) is the system clock becomes incorrect(Reported by the developer and the other users), but the old implementation is basically ok(but the CPUFreq driver doesn't work well with it). So, we have suggested Loongson, In order to save more powe, make CPUFreq work normally and provide high precision timer, a 64bit fixed-frequency high-precision R4K counter register should be provided, which means, the clock of R4K timer should be independent from the CPU and if possible, this R4K counter should be 64bit, as a result, no need to maintain a virtual 64bit counter and we can easierly get a high precision and low-latency sched_clock() too, a high precision and low-lateny sched_clock() is very important for kernel tracing, expecially for real time latency tracing and real time system itself. Thanks, Wu Zhangjin > > > Linux 3.1.0-libre-lemote-rm1 > CONFIG_CS5536_MFGPT n > CONFIG_R4K_TIMER_FOR_CPUFREQ y > > system type : lemote-yeeloong-2f-8.9inches > processor : 0 > cpu model : ICT Loongson-2 V0.3 FPU V0.1 > BogoMIPS : 797.00 > wait instruction : no > microsecond timers : yes > tlb_entries : 64 > extra interrupt vector : no > hardware watchpoint : yes, count: 0, address/irw mask: [] > ASEs implemented : > shadow register sets : 1 > kscratch registers : 0 > core : 0 > VCED exceptions : not available > VCEI exceptions : not available > > Linux 3.1.0-libre-lemote-rm2-mfgpt > CONFIG_CS5536_MFGPT y > CONFIG_R4K_TIMER_FOR_CPUFREQ n > + unbreak_CS5536_MFGPT.patch > + loongson_cpufreq_include.patch > Patches are attached; I'd like to propose these to be included in the > loongson-community kernel release to allow people experiment with enabling > MFGPT a bit more easily. > > system type : lemote-yeeloong-2f-8.9inches > processor : 0 > cpu model : ICT Loongson-2 V0.3 FPU V0.1 > BogoMIPS : 528.38 > wait instruction : yes > microsecond timers : yes > tlb_entries : 64 > extra interrupt vector : no > hardware watchpoint : yes, count: 0, address/irw mask: [] > ASEs implemented : > shadow register sets : 1 > kscratch registers : 0 > core : 0 > VCED exceptions : not available > VCEI exceptions : not available > > > Power consumption at idle (X.org at GDM login screen): > Linux 3.1.0-libre-lemote-rm1 12.2 to 12.3 watt > Linux 3.1.0-libre-lemote-rm2-mfgpt 11.5 to 11.6 watt (-6%) > > -- > With respect, > Roman > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Stallman had a printer, > with code he could not see. > So he began to tinker, > and set the software free." > -- You received this message because you are subscribed to the Google Groups "loongson-dev" group. To post to this group, send email to loongson-dev@googlegroups.com. To unsubscribe from this group, send email to loongson-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
