Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendlyclocksource/clockevent system timers

[Rob Herring]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/