* Kevin Hilman <khilman@xxxxxx> [110329 10:48]: > > The reset code is an example of something that will not be able to be > shared between a system timer driver and a real device driver. In the > real driver, the reset (as well as smart-idle, autoidle, wakeup > capability, etc.) will all be handled by the hwmod. > > With a hwmod conversion, the system timer will have to have > duplicate/alternate compared to the real timer. Well the hwmod is already there also for system timer, so that should not be a problem. See the init_one function in the next patch in the series. > Ideally, what we need is a way for the system timer to be early_init > only. When the real driver is available, it switches to that. This > could probably be done pretty easily by using the 'rating' field of the > clockevent so when the "real" timer driver becomes available with a > higher rating, the clockevent code would switch to it. I don't think this is needed. When the dmtimer driver code initializes it just picks up the already initialized struct omap_dm_timer entries but does not reset them. At that point the struct dev entry can be created, but from system timer point of view nothing changes. Regards, Tony -- 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
