On 11/13/2012 03:14 AM, Igor Grinberg wrote: > On 11/12/12 21:15, Jon Hunter wrote: >> >> On 11/11/2012 05:28 AM, Igor Grinberg wrote: >>> >>> >>> On 11/08/12 21:16, Jon Hunter wrote: >>>> >>>> On 11/08/2012 12:59 PM, Hiremath, Vaibhav wrote: >>>>> On Fri, Nov 09, 2012 at 00:24:23, Hunter, Jon wrote: >>>>>> >>>>>> On 11/08/2012 01:59 AM, Igor Grinberg wrote: >>>>>> >>>>>> [snip] >>>>>> >>>>>>> There is no reliable way to determine which source should be used in runtime >>>>>>> for boards that do not have the 32k oscillator wired. >>>>>> >>>>>> So thinking about this some more and given that we are moving away from >>>>>> board files, if a board does not provide a 32kHz clock source, then this >>>>>> should be reflected in the device-tree source file for that board. >>>>>> Hence, at boot time we should be able to determine if a 32kHz clock >>>>>> source can be used. >>>>>> >>>>> >>>>> Let me feed some more thoughts here :) >>>>> >>>>> The way it is being detected currently is based on timer idle status bit. >>>>> I am worried that, this is the only option we have. >>>> >>>> Why not use device-tree to indicate the presence of a 32k clock source? >>>> This seems like a board level configuration and so device-tree seems to >>>> be the perfect place for this IMO. >>> >>> Well, that is what my commit message says... >> >> Sorry, but that was not clear to me from whats in the commit message. > > From the commit message: > "1) Timer structures and initialization functions are named by the platform > name and the clock source in use. The decision which timer is > used is done statically from the machine_desc structure. In the > future it should come from DT." > > The last sentence has it. Right, but it does not go into the details. It would be good to have added a comment to the effect of "some boards do not have a 32k clock source and in the future this should be handled by device-tree". > The transition to DT is not immediate and we can't (still) neglect > the non-DT setups. Absolutely, but I am trying to understand if there are boards being "neglected". I see now that your CM-T3517 would be. This was not clear from your patch as even the CM-T3517 board was being configured to the use the sync32k timer. So from looking at your patch I did not see any neglected boards, however, I understand your motivation to add all these init functions so that boards could be customised easily. >> Should we be doing this now instead of adding all these static timer >> init functions? > > I don't see this as "adding ...", I see this as expanding the setup > which was previously hidden by the CONFIG_OMAP_32K_TIMER option. > >> >> Are there any boards today (supported in the kernel that is), that don't >> support a 32k? > > Yes, starting from revision 1.2, CM-T3517 does not have the 32k. Thanks, this is the exact information I was looking for. You should put this in your commit message to highlight the fact that there are boards that don't have a 32k clock source. I am familiar with the OMAP devices, but less familiar with these AMxxxx derivatives (as I don't work with these) and so it is good to put these specifics in the commit message. Cheers Jon -- 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
