Hi, On Tue, Apr 06, 2010 at 12:57:16AM +0200, ext Kevin Hilman wrote:
What' you've created is not a generic clocksource driver but one that can only work with the 32k sync timer.
so I achieved my goal, which was to convert *32k-sync timer* into a platform_driver.
If you're going to create a generic driver, it should be generic enough to work with any timer source: 32k, timer GP, off-chip RTC, etc. To do this, it would need a generic read function passed in with the platform_device.
yeah, I don't really see what you're trying to do. IMO we should just register all clocksources to the kernel but it doesn't mean they have to all come from the same platform_driver. The driver I wrote is for the 32k-sync timer, gp timers, mpu-timer they all would have to be converted.
I really don't see the point in having all clocksources as one unique driver since the kernel is (or should be) smart enough to choose the best one for us at runtime.
If you really want one driver that would cope with all clocksources, be my guest, but IMO, that's not the way to go.
It would also need a more generic way of handling clock names and frequencies. Currently the clock rate is hard-coded to 32kHz. clk_get_rate() should be used in a generic driver.
but that's what 32k-sync timer uses, right ? for anything else, then it would need more thinking. -- balbi -- 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
