On Fri, Nov 22, 2013 at 10:42 AM, Joel Fernandes <joelf@xxxxxx> wrote: > On 11/22/2013 09:58 AM, Rob Herring wrote: >> On Thu, Nov 21, 2013 at 7:56 PM, Joel Fernandes <joelf@xxxxxx> wrote: >>> This work is a migration effort of OMAP system timers to the >>> clocksource/clockevent framework. Consider this as a first-pass in this effort. >>> There are few cleanups that need to be done first. The HWMOD code is >>> intertwined with the timer code. HWMOD code cleanups in the future will >>> hopefully make most of this code go away, so till then we separate out the >>> power/clocks portion of the code from the actual timer bits. This will >>> facilitate near-future work of adapting the system timer as a clocksource. >>> >>> New functions for OF-only boot are introduced, and we can soon delete the old >>> versions once we migrate all platforms. Currently only AM335x is migrated and >>> testedA new omap_generic_timer_init function is introduced for DT platforms. >>> Code required earlier for non-DT platforms such as setup of timer IDs and timer >>> parent clock is not required. parent clocks are automatically setup by the mux >>> clock driver through DT so they no longer need to be hardcoded. >>> >>> The init code will try to pick the best timer for clocksource and clockevent >>> however bindings are added to force a particular timer as clocksource or >>> clockevent through DT. >>> >>> Signed-off-by: Joel Fernandes <joelf@xxxxxx> >>> --- >>> .../devicetree/bindings/arm/omap/timer.txt | 12 ++ >>> arch/arm/mach-omap2/common.h | 1 + >>> arch/arm/mach-omap2/timer.c | 235 +++++++++++++++++++++ >>> 3 files changed, 248 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt >>> index d02e27c..6cf7a75 100644 >>> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt >>> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt >>> @@ -32,6 +32,18 @@ Optional properties: >>> - ti,timer-secure: Indicates the timer is reserved on a secure OMAP device >>> and therefore cannot be used by the kernel. >>> >>> +- ti,timer-clockevent, >>> + ti,timer-clocksource These properties force the system timer code to choose >>> + the particular timer as a clockevent or clocksource. >>> + If these properties are not specified, the timer code >>> + picks up a "ti,timer-alwon" as the clocksource and a >>> + timer containing one of the following properties as >>> + the clockevent in the following order: >>> + ti,timer-alwon >>> + ti,timer-dsp >>> + ti,timer-pwm >>> + ti,timer-secure >> >> These properties were added specifically for the reason of avoiding >> linux specific properties like these. When is this not sufficient? > > Some platforms cannot use certain timers as clockevents and clocksource, to keep > this code functionally equivalent and working, I added these properties so that > its possible to select specific timers as clockevents/sources as was being done > in the non-DT case. I'm open to suggestions for doing this in a better way for DT. There has to be a defined reason why a given timer cannot be used. You are not explaining what that reason is. Define a property or set of properties that describe the h/w feature or quirk. >> >> And I agree with the comment to use OF_CLKSRC. >> > > There are difficulties I mentioned in a previous post [1] stating why it may not > be possible to use OF_CLKSRC macros, and still keep the code functionally > equivalent to when it was non-DT. Sorry, I don't buy it. Rob -- 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