linux-kernel - Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent system timers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <528F8959.7080207@ti.com>
Date:	Fri, 22 Nov 2013 10:42:01 -0600
From:	Joel Fernandes <joelf@...com>
To:	Rob Herring <robherring2@...il.com>
CC:	linux-omap <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	<jgchunter@...il.com>, <rnayak@...com>,
	Felipe Balbi <balbi@...com>,
	Santosh Shilimkar <santosh.shilimkar@...com>,
	<benoit.cousson@...aro.org>
Subject: Re: [PATCH 5/8] ARM: OMAP2+: timer: Introduce OF-friendly clocksource/clockevent
 system timers

On 11/22/2013 09:58 AM, Rob Herring wrote:
> On Thu, Nov 21, 2013 at 7:56 PM, Joel Fernandes <joelf@...com> 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@...com>
>> ---
>>  .../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.

> 
> 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.

thanks,

-Joel

[1] http://marc.info/?l=linux-arm-kernel&m=138513299917850&w=2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/