On Tue, Apr 10, 2012 at 01:48:22, Hunter, Jon wrote: > Hi Vaibhav, > > On 04/09/2012 01:19 AM, Hiremath, Vaibhav wrote: > > [...] > > > Let me summarize it here again, > > > > Currently, the timer code is using config option CONFIG_OMAP_32K_TIMER, > > to choose between 32ksync counter and gptimer; it is compile time option. > > If user wants to use gptimer for HR ticks, he must build the kernel without > > CONFIG_OMAP_32K_TIMER option. > > > > AM335x family of devices doesn't have 32ksync_counter available, only option > > here is to use gptimer for kernel clocksource and clockevents. > > > > So in order to support, multi-omap build including devices like AM335x, we > > must get rid of this option CONFIG_OMAP_32K_TIMER, atleast from clocksource > > registration perspective. > > > > So that means, we need to have some mechanism to handle or detect available > > clocksource runtime. Options would be, > > > > - Use HWMOD to detect availability of 32ksync_counter, else fallback > > to gptimer. [This was my original patch] > > > > But this restricts the use of gptimer completely on omap architecture, > > where we have 32ksync counter module. > > True, but we would always want to use the 32k timer if CONFIG_PM is > specified. So what I am saying is that if a device has a 32ksync timer > and CONFIG_PM is defined, we always want to use the 32ksync timer and a > gptimer should never be used. > > So we should/must restrict the use of a gptimer is CONFIG_PM is enabled > for devices that have the 32ksync timer. > > > - So the next solution is to still keep compile time option, so that user > > will get to use gptimer atleast just changing the kernel config option. > > > > But, still, this is going to be kernel rebuild. > > > > - Next option came up was, register both the timers and override using > > kernel parameter. > > > > This will work only if, both the timers run at same rate/frequency; since > > we have one more layer here setup_sched_clock(), which actually can be > > called only once. > > > > - Next option suggested by Santosh, is to use kernel parameter as in parse > > it early, to make decision on if user wants to override default > > clocksource (32ksync) > > > > This is something will work for us and solves all above issues. > > What happens if PM is enabled? Can you still override the default? I > don't think this should be allowed for devices with a 32ksync timer. > If user is overriding it explicitly, that itself means he knows what he is doing here. I too much to ask for...and unnecessary thing or expectation from SW. Thanks, Vaibhav -- 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
