> -----Original Message----- > From: Tony Lindgren [mailto:tony@xxxxxxxxxxx] > Sent: Saturday, March 05, 2011 5:32 AM > To: DebBarma, Tarun Kanti > Cc: Hilman, Kevin; linux-omap@xxxxxxxxxxxxxxx; Basak, Partha > Subject: Re: [PATCH v11 7/8] OMAP: dmtimer: pm_runtime support > > * DebBarma, Tarun Kanti <tarun.kanti@xxxxxx> [110304 11:50]: > > > > In that case we have to associate probably a dev attribute to system > timer. > > Do you have alternate proposal? > > No need for that. Keep the system timer code to the minimum so > it does not have any unnecessary dependencies. That code needs to > be running early and efficient, while the other timers should > really be a device driver. > > You can have shared timer read/write functions that don't depend > on dev. And you can just tag the pysical timer used for system > timer as reserved. > > Then you can initialize the other timers later on and skip the > system timer. For the other timers you can have dev oriented > timer read/write wrapper functions for the other timers. There is a single timer list created during driver probe. It can not be done separately for system timer except through Common build and probe. If we try other way it would get complicated I believe with the current design because clockevent management code in timer-gp.c calls common exported APIs. Now, coming back to our present requirement where we initialize Only the system timer early and is skipped later, here is the plan: (1) Have a separate class in hwmod database with unique name "system_timer" (2) Initialize just this one during early init > > Cheers, > > 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
