Op 30 jan 2009, om 23:03 heeft Woodruff, Richard het volgende geschreven:
Just a thought, do you still see these problems when using the CPUfreqperformance governor instead of the ondemand governor? It could be pointing to some bugs in the switching of operating points.Speaking of operating points, is there a reason why cpufreq only goes to 550MHz? It's disappointing that omap3 gets marketed with "600MHz",but that TI won't let it run at that speed with their cpufreq drivers.Run at that speed on your board if you like. You can run even faster if you like but at some point you will start to have odd failures.The 600MHz overdrive operating point is such that if you use it all the time your part life may be reduced. If you use the stock ondemand governor with no kind of policy teak you'll be at that OPP a lot.Percentage operation in overdrive figures into expected life of a given part. For reference code we just make the needed use cases explicitly ask for overdrive. This way usage is predictable in well defined mobile product.Depending on the chip you buy things are rated differently. This rating requires part sorting which typically pushes the price up some. Any step you add into fabrication of high volumes increases cost.
If you look at http://beagleboard.org/hardware it says "600Mhz" multiple times, so I'd expect the board to be running at 600MHz if I were a customer. If I read the TRM right I can run the cpu at 600MHz continuously for a few years, which exceeds the lifespan of most mobile products I have owned. So my real question is: why limit it in the kernel if all that's needed is a costum userspace governer?
regards, Koen
Attachment:
PGP.sig
Description: Dit deel van het bericht is digitaal ondertekend
