> 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? In reference code all OPPs are modeled. They all are just not exported to cpufreq. Any driver or user space can peg the system to max opp. There is nothing stopping anyone from hooking opp selection to cpufreq. However, it does require a custom governor or a little policy script to set limits. This is not the default in main line builds. It could be pushed if someone wanted to do the work. For the general testing and usage it is easy to just use ondemand. It's a good general purpose governor. There is no need to recreate it for general use. Then treat special needs out of band. If you want to create a new governor and can get a lot of people to use it then nothing is in the way but time to try and sell up stream people it is needed. Initial design for customers required the ability to plug in custom managers which sit at the cpufreq level. Not everyone in the world uses cpufreq for this kind of thing. Because of this we purposefully kept separation. Novice uses which just grab a kernel and take the root file system of the day will get it wrong. Off hand I'm not sure which kernel level mechanism is blocking you in l-o. I haven't had bandwidth to follow line by line. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
