diff mbox

[1/4] clocksource: mmp: add mmp timer driver

Message ID 1395809563-31872-2-git-send-email-chao.xie@marvell.com
State Superseded, archived
Headers show

Commit Message

Chao Xie March 26, 2014, 4:52 a.m. UTC
From: Chao Xie <chao.xie@marvell.com>

MMP timer is attached to APB bus, It has the following
limitation.
1. When get count of timer counter, it need some delay
   to get a stable count.
2. When set match register, it need disable the counter
   first, and enable it after set the match register.
   The disabling need wait for 2 clock cycle to take
   effect.

To improve above #1, shadow register for count is added.
To improve above #2, CRSR register is added for quick updating.

So there are three types of timer.
timer1: old timer.
timer2: old timer with shadow register.
timer3: old timer with shadow and CRSR register.

This timer driver will be used for many SOCes.
1. pxa168, pxa910, pxa988 pxa1088 have only timer1.
2. pxa1L88, pxa1U88 have timer1 and timer3.
3. pxa1928 has timer 2.

The driver supports DT and non-DT initialization.
The driver supports UP/SMP SOCes and 64 bit core.

Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
 .../devicetree/bindings/arm/mrvl/timer.txt         |  73 +-
 drivers/clocksource/Makefile                       |   1 +
 drivers/clocksource/timer-mmp.c                    | 866 +++++++++++++++++++++
 3 files changed, 934 insertions(+), 6 deletions(-)
 create mode 100644 drivers/clocksource/timer-mmp.c

Comments

Mark Rutland March 26, 2014, 10:41 a.m. UTC | #1
On Wed, Mar 26, 2014 at 04:52:40AM +0000, Chao Xie wrote:
> From: Chao Xie <chao.xie@marvell.com>
>
> MMP timer is attached to APB bus, It has the following
> limitation.
> 1. When get count of timer counter, it need some delay
>    to get a stable count.
> 2. When set match register, it need disable the counter
>    first, and enable it after set the match register.
>    The disabling need wait for 2 clock cycle to take
>    effect.
>
> To improve above #1, shadow register for count is added.
> To improve above #2, CRSR register is added for quick updating.
>
> So there are three types of timer.
> timer1: old timer.
> timer2: old timer with shadow register.
> timer3: old timer with shadow and CRSR register.
>
> This timer driver will be used for many SOCes.
> 1. pxa168, pxa910, pxa988 pxa1088 have only timer1.
> 2. pxa1L88, pxa1U88 have timer1 and timer3.
> 3. pxa1928 has timer 2.
>
> The driver supports DT and non-DT initialization.
> The driver supports UP/SMP SOCes and 64 bit core.
>
> Signed-off-by: Chao Xie <chao.xie@marvell.com>
> ---
>  .../devicetree/bindings/arm/mrvl/timer.txt         |  73 +-
>  drivers/clocksource/Makefile                       |   1 +
>  drivers/clocksource/timer-mmp.c                    | 866 +++++++++++++++++++++
>  3 files changed, 934 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/clocksource/timer-mmp.c
>
> diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> index 9a6e251..b9af4bf 100644
> --- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> @@ -1,13 +1,74 @@
>  * Marvell MMP Timer controller
>
> +Each timer have multiple counters, so the timer DT need include counter's
> +description.
> +
> +1. Timer
> +
>  Required properties:
> -- compatible : Should be "mrvl,mmp-timer".
> +- compatible : Should be "marvell,mmp-timer".
>  - reg : Address and length of the register set of timer controller.
> -- interrupts : Should be the interrupt number.
> +- marvell,timer-id : The index of the timer. The timer controller may
> +  include several timers.

Is this a single entry or a list?

> +- marvell,timer-fastclk-frequency : The fast clock frequency of the timer.
> +  Timer will have several clock inputs: fast clock, 32KHZ, 1KHZ. For all
> +  SOCes use this timer controller, fast clock may not be same.
> +- marvell,timer-apb-frequency : The fequency of the apb bus that the timer
> +  attached to. This frequency and "marvell,timer-fastclk-frequency" are used
> +  to calculated delay loops for clock operations.

Wouldn't these be better described as clock inputs?

> +
> +Optional properties:
> +- marvell,timer-has-crsr : This timer has CRSR register.
> +- marvell,timer-has-shadow : This timer has shadow register.
> +
> +2. Counter
> +
> +Required properties:
> +- compatible : It can be
> +      "marvell,timer-counter-clkevt" : The counter is used for clock event
> +                                       device.
> +      "marvell,timer-counter-clksrc" : The counter is used for clock source.
> +      "marvell,timer-counter-delay" : The counter is used for delay timer.

These are _not_ hardware properties. Why can the driver not choose how
to use each of the counter sub-blocks?

How would blocks with each of these strings actually differ?

> +- marvell,timer-counter-id : The counter index in this timer.

Perhaps use a reg for this?

>
> -Example:
> -       timer0: timer@d4014000 {
> -               compatible = "mrvl,mmp-timer";
> -               reg = <0xd4014000 0x100>;
> +Optional properties:
> +- interrupts : The counters may have different IRQs or share same IRQs.
> +  Only valid for "marvell,timer-counter-clkevt".

Describe what the interrupt is logically.

What is the interrupt logically?

> +- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
> +  "marvell,timer-counter-clkevt".

How is the counter bound to a particular CPU? Is there really a
relationship in hardware between a given CPU and counter?

> +- "marvell,timer-counter-rating" : The rating when register clock event device
> +  or clock source. Only valid for "marvell,timer-counter-clkevt" and
> +  "marvell,timer-counter-clksrc".

What does this mean? This seems like another leak of Linux internals.

> +- marvell,timer-counter-broadcast : When this counter acts as clock event
> +  device. It is broadcast clock event device.
> +  Only valid for "marvell,timer-counter-clkevt".

This does not seem like a hardware property. Why can Linux not decide
which counter (if any) to use as the broadcast source?

> +- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
> +  event device, it cannot switch the IRQ of broadcast clock event to any CPU.
> +  Only valid for "marvell,timer-counter-clkevt".

Likewise this does not sound like a hardware property.

Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chao Xie March 27, 2014, 1:27 a.m. UTC | #2
On Wed, Mar 26, 2014 at 6:41 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Mar 26, 2014 at 04:52:40AM +0000, Chao Xie wrote:
>> From: Chao Xie <chao.xie@marvell.com>
>>
>> MMP timer is attached to APB bus, It has the following
>> limitation.
>> 1. When get count of timer counter, it need some delay
>>    to get a stable count.
>> 2. When set match register, it need disable the counter
>>    first, and enable it after set the match register.
>>    The disabling need wait for 2 clock cycle to take
>>    effect.
>>
>> To improve above #1, shadow register for count is added.
>> To improve above #2, CRSR register is added for quick updating.
>>
>> So there are three types of timer.
>> timer1: old timer.
>> timer2: old timer with shadow register.
>> timer3: old timer with shadow and CRSR register.
>>
>> This timer driver will be used for many SOCes.
>> 1. pxa168, pxa910, pxa988 pxa1088 have only timer1.
>> 2. pxa1L88, pxa1U88 have timer1 and timer3.
>> 3. pxa1928 has timer 2.
>>
>> The driver supports DT and non-DT initialization.
>> The driver supports UP/SMP SOCes and 64 bit core.
>>
>> Signed-off-by: Chao Xie <chao.xie@marvell.com>
>> ---
>>  .../devicetree/bindings/arm/mrvl/timer.txt         |  73 +-
>>  drivers/clocksource/Makefile                       |   1 +
>>  drivers/clocksource/timer-mmp.c                    | 866 +++++++++++++++++++++
>>  3 files changed, 934 insertions(+), 6 deletions(-)
>>  create mode 100644 drivers/clocksource/timer-mmp.c
>>
>> diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
>> index 9a6e251..b9af4bf 100644
>> --- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
>> @@ -1,13 +1,74 @@
>>  * Marvell MMP Timer controller
>>
>> +Each timer have multiple counters, so the timer DT need include counter's
>> +description.
>> +
>> +1. Timer
>> +
>>  Required properties:
>> -- compatible : Should be "mrvl,mmp-timer".
>> +- compatible : Should be "marvell,mmp-timer".
>>  - reg : Address and length of the register set of timer controller.
>> -- interrupts : Should be the interrupt number.
>> +- marvell,timer-id : The index of the timer. The timer controller may
>> +  include several timers.
>
> Is this a single entry or a list?

Generally, the may be 2/3/4 timers, and each timers will have at most
3 coounters.
Each counters will have 3 matches. Each counter may have its own
interrupts, or share same
interrupts(counter1 has one interrupts, counter2 and 3 share one). It depends on
how SOC connets the signals.

The DT will be
timer 0 {
     ...
     ...
     counter0 {
     };
     counter2 {
     };
}

>
>> +- marvell,timer-fastclk-frequency : The fast clock frequency of the timer.
>> +  Timer will have several clock inputs: fast clock, 32KHZ, 1KHZ. For all
>> +  SOCes use this timer controller, fast clock may not be same.
>> +- marvell,timer-apb-frequency : The fequency of the apb bus that the timer
>> +  attached to. This frequency and "marvell,timer-fastclk-frequency" are used
>> +  to calculated delay loops for clock operations.
>
> Wouldn't these be better described as clock inputs?

"apb" frequency is only used to calculated the delay loop.
I do not want to fix the delay loop in the driver.
So pass it in DT directly will make the things easier to handle.

"fastclk" is a clock input. So waht do you mean "described as clock inputs"?

>
>> +
>> +Optional properties:
>> +- marvell,timer-has-crsr : This timer has CRSR register.
>> +- marvell,timer-has-shadow : This timer has shadow register.
>> +
>> +2. Counter
>> +
>> +Required properties:
>> +- compatible : It can be
>> +      "marvell,timer-counter-clkevt" : The counter is used for clock event
>> +                                       device.
>> +      "marvell,timer-counter-clksrc" : The counter is used for clock source.
>> +      "marvell,timer-counter-delay" : The counter is used for delay timer.
>
> These are _not_ hardware properties. Why can the driver not choose how
> to use each of the counter sub-blocks?
>
> How would blocks with each of these strings actually differ?
>

SOCes may have 2 or 3 or 4 timers, some timers may be used by CP not AP but
AP can still access it.
There may be UP SOC, or SMP SOC. So there are may be some general usage
1. UP SOC: need one clocksource, need one clock event device
2. SMP SOC: need one clocksource, need one broadcast clock event device because
   arch timer will be shutdown when core is down
3. SMP SOC: it has bug with arch timer. So need one clock source,
NR_CPUs clock event
    device to replace the arch timer. There are may be 2 cores or 4 cores.


Above requeimetns are also hardware requriments from SOCes.

The driver will be used for many SOCes, we can not to fix the counter
usage in driver.


>> +- marvell,timer-counter-id : The counter index in this timer.
>
> Perhaps use a reg for this?
>

The counter does not have its own register space. They are belongs to a timer.
Counter does not need to map the regsiter spance, it is done by timer.
For example, for counter enable, all coutners share same register. CER
For interrupt enable, each counter has its own register. IERx

So if we use like "reg = <IERx offset>", i do not see any benefit. while
direct setting "marvell,timer-counter-id" seems make the DT more clear.

>>
>> -Example:
>> -       timer0: timer@d4014000 {
>> -               compatible = "mrvl,mmp-timer";
>> -               reg = <0xd4014000 0x100>;
>> +Optional properties:
>> +- interrupts : The counters may have different IRQs or share same IRQs.
>> +  Only valid for "marvell,timer-counter-clkevt".
>
> Describe what the interrupt is logically.
>
> What is the interrupt logically?
>

The interrupt topolog is designed by SOCes.
Each counter has one interrupt, but SOCes may connects some coutners' interrupt
into one.
In timer driver, we do not care about it. We depeneds on IRQ chip to handle it.

>> +- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
>> +  "marvell,timer-counter-clkevt".
>
> How is the counter bound to a particular CPU? Is there really a
> relationship in hardware between a given CPU and counter?
>

For some SMP SOCes, for example, marvell's pxa988/pxa1088/pxa1L88
They have bug in arch timer. So we make each CPU to have one dedicated
counter to replace the arch timer.

>> +- "marvell,timer-counter-rating" : The rating when register clock event device
>> +  or clock source. Only valid for "marvell,timer-counter-clkevt" and
>> +  "marvell,timer-counter-clksrc".
>
> What does this mean? This seems like another leak of Linux internals.

It is the rating when register clock source and clock event.
I think i can fix it in the driver.

>
>> +- marvell,timer-counter-broadcast : When this counter acts as clock event
>> +  device. It is broadcast clock event device.
>> +  Only valid for "marvell,timer-counter-clkevt".
>
> This does not seem like a hardware property. Why can Linux not decide
> which counter (if any) to use as the broadcast source?
>

For some SMP soces, for example, marvell's pxa988/pxa1088/pxa1L88
They have bug in arch timer. So we make each CPU to have one dedicated
counter to replace the arch timer. So for these SOCes, broadcast timer is not
needed. For these counters, we have to set IRQ affinity to the specific core.

For some SMP soces, for example, they can use arch timer, but we have
to register
a clock event device for broadcast because we lose arch timer if core is down.
For this coutner, we have to set IRQ affinity to ALL cores.

>> +- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
>> +  event device, it cannot switch the IRQ of broadcast clock event to any CPU.
>> +  Only valid for "marvell,timer-counter-clkevt".
>
> Likewise this does not sound like a hardware property.

For a broadcast timer, there is feature "CLOCK_EVT_FEAT_DYNIRQ".
This feature is a clock event device's fearture. It means that the
clock event device's irq can
be set to any core.
In fact it does not for all SOCes that the interrupt of the counter
can be set to any core.

>
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mark Rutland March 27, 2014, 9:59 a.m. UTC | #3
On Thu, Mar 27, 2014 at 01:27:33AM +0000, Chao Xie wrote:
> On Wed, Mar 26, 2014 at 6:41 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Wed, Mar 26, 2014 at 04:52:40AM +0000, Chao Xie wrote:
> >> From: Chao Xie <chao.xie@marvell.com>
> >>
> >> MMP timer is attached to APB bus, It has the following
> >> limitation.
> >> 1. When get count of timer counter, it need some delay
> >>    to get a stable count.
> >> 2. When set match register, it need disable the counter
> >>    first, and enable it after set the match register.
> >>    The disabling need wait for 2 clock cycle to take
> >>    effect.
> >>
> >> To improve above #1, shadow register for count is added.
> >> To improve above #2, CRSR register is added for quick updating.
> >>
> >> So there are three types of timer.
> >> timer1: old timer.
> >> timer2: old timer with shadow register.
> >> timer3: old timer with shadow and CRSR register.
> >>
> >> This timer driver will be used for many SOCes.
> >> 1. pxa168, pxa910, pxa988 pxa1088 have only timer1.
> >> 2. pxa1L88, pxa1U88 have timer1 and timer3.
> >> 3. pxa1928 has timer 2.
> >>
> >> The driver supports DT and non-DT initialization.
> >> The driver supports UP/SMP SOCes and 64 bit core.
> >>
> >> Signed-off-by: Chao Xie <chao.xie@marvell.com>
> >> ---
> >>  .../devicetree/bindings/arm/mrvl/timer.txt         |  73 +-
> >>  drivers/clocksource/Makefile                       |   1 +
> >>  drivers/clocksource/timer-mmp.c                    | 866 +++++++++++++++++++++
> >>  3 files changed, 934 insertions(+), 6 deletions(-)
> >>  create mode 100644 drivers/clocksource/timer-mmp.c
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> >> index 9a6e251..b9af4bf 100644
> >> --- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> >> +++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
> >> @@ -1,13 +1,74 @@
> >>  * Marvell MMP Timer controller
> >>
> >> +Each timer have multiple counters, so the timer DT need include counter's
> >> +description.
> >> +
> >> +1. Timer
> >> +
> >>  Required properties:
> >> -- compatible : Should be "mrvl,mmp-timer".
> >> +- compatible : Should be "marvell,mmp-timer".
> >>  - reg : Address and length of the register set of timer controller.
> >> -- interrupts : Should be the interrupt number.
> >> +- marvell,timer-id : The index of the timer. The timer controller may
> >> +  include several timers.
> >
> > Is this a single entry or a list?
> 
> Generally, the may be 2/3/4 timers, and each timers will have at most
> 3 coounters.
> Each counters will have 3 matches. Each counter may have its own
> interrupts, or share same
> interrupts(counter1 has one interrupts, counter2 and 3 share one). It depends on
> how SOC connets the signals.
> 
> The DT will be
> timer 0 {
>      ...
>      ...
>      counter0 {
>      };
>      counter2 {
>      };
> }

I'm somewhat confused here.

The top level node appears to be a timer controller (per the reg
property description), but the marvell,timer-id property describes an
index within the timer controller. This does not seem to make sense.

How do you describe multiple timers within a given timer contoller? Is
the timer-id a list? Or do you describe the controller repeatedly?

> 
> >
> >> +- marvell,timer-fastclk-frequency : The fast clock frequency of the timer.
> >> +  Timer will have several clock inputs: fast clock, 32KHZ, 1KHZ. For all
> >> +  SOCes use this timer controller, fast clock may not be same.
> >> +- marvell,timer-apb-frequency : The fequency of the apb bus that the timer
> >> +  attached to. This frequency and "marvell,timer-fastclk-frequency" are used
> >> +  to calculated delay loops for clock operations.
> >
> > Wouldn't these be better described as clock inputs?
> 
> "apb" frequency is only used to calculated the delay loop.
> I do not want to fix the delay loop in the driver.
> So pass it in DT directly will make the things easier to handle.
> 
> "fastclk" is a clock input. So waht do you mean "described as clock inputs"?

Using the clock bindings:

	clocks = <&apb_plck>, <&clock_controller 0 3>;
	clock-names = "apb_pclk", "fastclk";

The driver can then query the frequencies, enable/disable the clocks as
required, etc.

> 
> >
> >> +
> >> +Optional properties:
> >> +- marvell,timer-has-crsr : This timer has CRSR register.
> >> +- marvell,timer-has-shadow : This timer has shadow register.
> >> +
> >> +2. Counter
> >> +
> >> +Required properties:
> >> +- compatible : It can be
> >> +      "marvell,timer-counter-clkevt" : The counter is used for clock event
> >> +                                       device.
> >> +      "marvell,timer-counter-clksrc" : The counter is used for clock source.
> >> +      "marvell,timer-counter-delay" : The counter is used for delay timer.
> >
> > These are _not_ hardware properties. Why can the driver not choose how
> > to use each of the counter sub-blocks?
> >
> > How would blocks with each of these strings actually differ?
> >
> 
> SOCes may have 2 or 3 or 4 timers, some timers may be used by CP not AP but
> AP can still access it.
> There may be UP SOC, or SMP SOC. So there are may be some general usage
> 1. UP SOC: need one clocksource, need one clock event device
> 2. SMP SOC: need one clocksource, need one broadcast clock event device because
>    arch timer will be shutdown when core is down
> 3. SMP SOC: it has bug with arch timer. So need one clock source,
> NR_CPUs clock event
>     device to replace the arch timer. There are may be 2 cores or 4 cores.

Ok, but in all of these cases the blocks that you are giving different
compatible strings are identical. The only difference is how you expect
Linux to use them.

Why can you not just describe the set of timers available to Linux and
allow it to allocate them as required?

> Above requeimetns are also hardware requriments from SOCes.
> 
> The driver will be used for many SOCes, we can not to fix the counter
> usage in driver.

I'm arguing for dynamically deciding how to use the timers, not assuming
one of the three cases you've laid out above, and not describing a
possible software use of the counters in the DT.

> >> +- marvell,timer-counter-id : The counter index in this timer.
> >
> > Perhaps use a reg for this?
> >
> 
> The counter does not have its own register space. They are belongs to a timer.
> Counter does not need to map the regsiter spance, it is done by timer.
> For example, for counter enable, all coutners share same register. CER
> For interrupt enable, each counter has its own register. IERx
> 
> So if we use like "reg = <IERx offset>", i do not see any benefit. while
> direct setting "marvell,timer-counter-id" seems make the DT more clear.

The reg doesn't have to be a register space -- it's often used simply as
a form of address/identifier without a size (consider SPI's use of the
reg property). Here the index is essentially an address/identifier for
the counter.

Given that the each timer also seems to have a unique ID perhaps using
the reg is not the best strategy here. I was simply raising the
possiblity.

> 
> >>
> >> -Example:
> >> -       timer0: timer@d4014000 {
> >> -               compatible = "mrvl,mmp-timer";
> >> -               reg = <0xd4014000 0x100>;
> >> +Optional properties:
> >> +- interrupts : The counters may have different IRQs or share same IRQs.
> >> +  Only valid for "marvell,timer-counter-clkevt".
> >
> > Describe what the interrupt is logically.
> >
> > What is the interrupt logically?
> >
> 
> The interrupt topolog is designed by SOCes.
> Each counter has one interrupt, but SOCes may connects some coutners' interrupt
> into one.
> In timer driver, we do not care about it. We depeneds on IRQ chip to handle it.

How the interrupt is wired and whether it is shared is not important
from the view of the binding. What is important is which interrupt from
the timer is being described. If it has a given name, that should be
mentioned. Otherwise a simple description will suffice.

The presence of external interrupt muxing doesn't seem to be important
here to the binding -- in that case an OS could request shared
interrupts or decide to only make use of a subset of interrupts. That
seems to be outside of the scope of the binding.

> 
> >> +- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
> >> +  "marvell,timer-counter-clkevt".
> >
> > How is the counter bound to a particular CPU? Is there really a
> > relationship in hardware between a given CPU and counter?
> >
> 
> For some SMP SOCes, for example, marvell's pxa988/pxa1088/pxa1L88
> They have bug in arch timer. So we make each CPU to have one dedicated
> counter to replace the arch timer.

Is there any real topological relationship between CPUs and counters, or
is this arbitrary? If the latter, why can the kernel not decide how to
allocate timers to CPUs?

> 
> >> +- "marvell,timer-counter-rating" : The rating when register clock event device
> >> +  or clock source. Only valid for "marvell,timer-counter-clkevt" and
> >> +  "marvell,timer-counter-clksrc".
> >
> > What does this mean? This seems like another leak of Linux internals.
> 
> It is the rating when register clock source and clock event.
> I think i can fix it in the driver.

Ok. This is a Linux interenal detail that I do not think should be in
the DT.

> 
> >
> >> +- marvell,timer-counter-broadcast : When this counter acts as clock event
> >> +  device. It is broadcast clock event device.
> >> +  Only valid for "marvell,timer-counter-clkevt".
> >
> > This does not seem like a hardware property. Why can Linux not decide
> > which counter (if any) to use as the broadcast source?
> >
> 
> For some SMP soces, for example, marvell's pxa988/pxa1088/pxa1L88
> They have bug in arch timer. So we make each CPU to have one dedicated
> counter to replace the arch timer. So for these SOCes, broadcast timer is not
> needed. For these counters, we have to set IRQ affinity to the specific core.

That's fine, we can do that in the absence of both this property and
another timer (the arch timer).

> For some SMP soces, for example, they can use arch timer, but we have
> to register
> a clock event device for broadcast because we lose arch timer if core is down.
> For this coutner, we have to set IRQ affinity to ALL cores.

In that case the arch timer will register (which can have a higher
rating than this timer), and this timers can be automatically repurposed
as the broadcast source.

I do not see the necessity of this property.

> >> +- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
> >> +  event device, it cannot switch the IRQ of broadcast clock event to any CPU.
> >> +  Only valid for "marvell,timer-counter-clkevt".
> >
> > Likewise this does not sound like a hardware property.
> 
> For a broadcast timer, there is feature "CLOCK_EVT_FEAT_DYNIRQ".
> This feature is a clock event device's fearture. It means that the
> clock event device's irq can
> be set to any core.
> In fact it does not for all SOCes that the interrupt of the counter
> can be set to any core.

The naming and use of this property still seems incredibly
Linux-specific.

Why can some of the counter interrupts not be routed to an arbitrary
CPU?

Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chao Xie March 27, 2014, 12:13 p.m. UTC | #4
>> >>
>> >> +Each timer have multiple counters, so the timer DT need include counter's
>> >> +description.
>> >> +
>> >> +1. Timer
>> >> +
>> >>  Required properties:
>> >> -- compatible : Should be "mrvl,mmp-timer".
>> >> +- compatible : Should be "marvell,mmp-timer".
>> >>  - reg : Address and length of the register set of timer controller.
>> >> -- interrupts : Should be the interrupt number.
>> >> +- marvell,timer-id : The index of the timer. The timer controller may
>> >> +  include several timers.
>> >
>> > Is this a single entry or a list?
>>
>> Generally, the may be 2/3/4 timers, and each timers will have at most
>> 3 coounters.
>> Each counters will have 3 matches. Each counter may have its own
>> interrupts, or share same
>> interrupts(counter1 has one interrupts, counter2 and 3 share one). It depends on
>> how SOC connets the signals.
>>
>> The DT will be
>> timer 0 {
>>      ...
>>      ...
>>      counter0 {
>>      };
>>      counter2 {
>>      };
>> }
>
> I'm somewhat confused here.
>
> The top level node appears to be a timer controller (per the reg
> property description), but the marvell,timer-id property describes an
> index within the timer controller. This does not seem to make sense.
>
> How do you describe multiple timers within a given timer contoller? Is
> the timer-id a list? Or do you describe the controller repeatedly?
>
Thanks for your reply.

the driver only take care of one timer node, if we have 3 timer node defined.
It means that the driver will be probed 3 times.

Each timer is a controller, and one timer has 3 counters. each counter can be
set to be free running or period mode.

marvell,timer-id may not be needed, but the marvell,counter-id need to
be passed.
The timer driver depends on the id to distinguish the register or bit
in the register.

>>
>> >
>> >> +- marvell,timer-fastclk-frequency : The fast clock frequency of the timer.
>> >> +  Timer will have several clock inputs: fast clock, 32KHZ, 1KHZ. For all
>> >> +  SOCes use this timer controller, fast clock may not be same.
>> >> +- marvell,timer-apb-frequency : The fequency of the apb bus that the timer
>> >> +  attached to. This frequency and "marvell,timer-fastclk-frequency" are used
>> >> +  to calculated delay loops for clock operations.
>> >
>> > Wouldn't these be better described as clock inputs?
>>
>> "apb" frequency is only used to calculated the delay loop.
>> I do not want to fix the delay loop in the driver.
>> So pass it in DT directly will make the things easier to handle.
>>
>> "fastclk" is a clock input. So waht do you mean "described as clock inputs"?
>
> Using the clock bindings:
>
>         clocks = <&apb_plck>, <&clock_controller 0 3>;
>         clock-names = "apb_pclk", "fastclk";
>
> The driver can then query the frequencies, enable/disable the clocks as
> required, etc.
>
It is the final choice, but it depends on the clock DT support.
I just begin the clock DT support for mach-mmp. They are still in design phase.
Clock framework is more complicated than the timer controller.

>>
>> >
>> >> +
>> >> +Optional properties:
>> >> +- marvell,timer-has-crsr : This timer has CRSR register.
>> >> +- marvell,timer-has-shadow : This timer has shadow register.
>> >> +
>> >> +2. Counter
>> >> +
>> >> +Required properties:
>> >> +- compatible : It can be
>> >> +      "marvell,timer-counter-clkevt" : The counter is used for clock event
>> >> +                                       device.
>> >> +      "marvell,timer-counter-clksrc" : The counter is used for clock source.
>> >> +      "marvell,timer-counter-delay" : The counter is used for delay timer.
>> >
>> > These are _not_ hardware properties. Why can the driver not choose how
>> > to use each of the counter sub-blocks?
>> >
>> > How would blocks with each of these strings actually differ?
>> >
>>
>> SOCes may have 2 or 3 or 4 timers, some timers may be used by CP not AP but
>> AP can still access it.
>> There may be UP SOC, or SMP SOC. So there are may be some general usage
>> 1. UP SOC: need one clocksource, need one clock event device
>> 2. SMP SOC: need one clocksource, need one broadcast clock event device because
>>    arch timer will be shutdown when core is down
>> 3. SMP SOC: it has bug with arch timer. So need one clock source,
>> NR_CPUs clock event
>>     device to replace the arch timer. There are may be 2 cores or 4 cores.
>
> Ok, but in all of these cases the blocks that you are giving different
> compatible strings are identical. The only difference is how you expect
> Linux to use them.
>
> Why can you not just describe the set of timers available to Linux and
> allow it to allocate them as required?
>


So how can I make Linux to allocate them as required?


>> Above requeimetns are also hardware requriments from SOCes.
>>
>> The driver will be used for many SOCes, we can not to fix the counter
>> usage in driver.
>
> I'm arguing for dynamically deciding how to use the timers, not assuming
> one of the three cases you've laid out above, and not describing a
> possible software use of the counters in the DT.
>

I am a little confused.

So what is your suggestions?
we have the below usage
1. UP SOC, we need clock source, clock event device
2. SMP SOC with arch timer, we need clock source, broadcast clock event device
3. SMP SOC without arch timer, we need clock source, NR_CPU clock
event device and delay timer.


>> >> +- marvell,timer-counter-id : The counter index in this timer.
>> >
>> > Perhaps use a reg for this?
>> >
>>
>> The counter does not have its own register space. They are belongs to a timer.
>> Counter does not need to map the regsiter spance, it is done by timer.
>> For example, for counter enable, all coutners share same register. CER
>> For interrupt enable, each counter has its own register. IERx
>>
>> So if we use like "reg = <IERx offset>", i do not see any benefit. while
>> direct setting "marvell,timer-counter-id" seems make the DT more clear.
>
> The reg doesn't have to be a register space -- it's often used simply as
> a form of address/identifier without a size (consider SPI's use of the
> reg property). Here the index is essentially an address/identifier for
> the counter.
>
> Given that the each timer also seems to have a unique ID perhaps using
> the reg is not the best strategy here. I was simply raising the
> possiblity.
>
>>
>> >>
>> >> -Example:
>> >> -       timer0: timer@d4014000 {
>> >> -               compatible = "mrvl,mmp-timer";
>> >> -               reg = <0xd4014000 0x100>;
>> >> +Optional properties:
>> >> +- interrupts : The counters may have different IRQs or share same IRQs.
>> >> +  Only valid for "marvell,timer-counter-clkevt".
>> >
>> > Describe what the interrupt is logically.
>> >
>> > What is the interrupt logically?
>> >
>>
>> The interrupt topolog is designed by SOCes.
>> Each counter has one interrupt, but SOCes may connects some coutners' interrupt
>> into one.
>> In timer driver, we do not care about it. We depeneds on IRQ chip to handle it.
>
> How the interrupt is wired and whether it is shared is not important
> from the view of the binding. What is important is which interrupt from
> the timer is being described. If it has a given name, that should be
> mentioned. Otherwise a simple description will suffice.
>
> The presence of external interrupt muxing doesn't seem to be important
> here to the binding -- in that case an OS could request shared
> interrupts or decide to only make use of a subset of interrupts. That
> seems to be outside of the scope of the binding.
>

I see. I think a simple description is enough. i do not need mention the shared
interrupts here because the timer driver does not care about it.

>>
>> >> +- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
>> >> +  "marvell,timer-counter-clkevt".
>> >
>> > How is the counter bound to a particular CPU? Is there really a
>> > relationship in hardware between a given CPU and counter?
>> >
>>
>> For some SMP SOCes, for example, marvell's pxa988/pxa1088/pxa1L88
>> They have bug in arch timer. So we make each CPU to have one dedicated
>> counter to replace the arch timer.
>
> Is there any real topological relationship between CPUs and counters, or
> is this arbitrary? If the latter, why can the kernel not decide how to
> allocate timers to CPUs?
>

All the timers can be seen by every CPUes.
For arch timer, each CPU see its own instance, while for the mmp
timers, each CPU
can see all of them.
So there are some problems
1. The number of the timer is not fixed. It can be 2, 3, 4
2. Some timers can be seen by CP, and CP will use these timers. Which
timer can be seen
    by CP is defined by SOC design
3. Some counter share one interrupt, these counters can not be
allocated for per cpu timer to replace
    arch timer.
So which counter allocated is limited by SOC design.

So if do not have above limitation, can you tell me that how can i let
kernel to decide allocation?
Thanks.

>>
>> >> +- "marvell,timer-counter-rating" : The rating when register clock event device
>> >> +  or clock source. Only valid for "marvell,timer-counter-clkevt" and
>> >> +  "marvell,timer-counter-clksrc".
>> >
>> > What does this mean? This seems like another leak of Linux internals.
>>
>> It is the rating when register clock source and clock event.
>> I think i can fix it in the driver.
>
> Ok. This is a Linux interenal detail that I do not think should be in
> the DT.
>
>>
>> >
>> >> +- marvell,timer-counter-broadcast : When this counter acts as clock event
>> >> +  device. It is broadcast clock event device.
>> >> +  Only valid for "marvell,timer-counter-clkevt".
>> >
>> > This does not seem like a hardware property. Why can Linux not decide
>> > which counter (if any) to use as the broadcast source?
>> >
>>
>> For some SMP soces, for example, marvell's pxa988/pxa1088/pxa1L88
>> They have bug in arch timer. So we make each CPU to have one dedicated
>> counter to replace the arch timer. So for these SOCes, broadcast timer is not
>> needed. For these counters, we have to set IRQ affinity to the specific core.
>
> That's fine, we can do that in the absence of both this property and
> another timer (the arch timer).
>
>> For some SMP soces, for example, they can use arch timer, but we have
>> to register
>> a clock event device for broadcast because we lose arch timer if core is down.
>> For this coutner, we have to set IRQ affinity to ALL cores.
>
> In that case the arch timer will register (which can have a higher
> rating than this timer), and this timers can be automatically repurposed
> as the broadcast source.
>
> I do not see the necessity of this property.
>
It is true that arch timer is first priority.
There are something need to be considered
1. we registered NR_CPU timers to acts as arch timer. We set the
cpu_mask of be cpu_mask(cpu_id), not
    cpu_mask(ALL_CPUes). We also bind the interrupt to the dedicated
CPU. For example, if timer 0 counter 0
    is used by CPU0 to replace arch timer. the counter's IRQ only
route to the CPU0.
    If we have arch timers, it means that there are NR_CPU timers, i
do not think they can be acts as broadcast timer
2. As i said, some coutners share interrupts. We can not allocated
this kind of counter as per cpu clock event device.
    For exmaple, timer 0 coutner1 and counter 2 share same interrupt.
If they are used by CPU0 and CPU1, it means that
    same interrupt will be bind to two CPUes. each timer interrupt
happens, a power-down core need wake up to check the
    interrupt does not targets at it.

So how to use these counter in fact depends on the SOCes design.
That why i need pass this kind of information to timer driver.

>> >> +- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
>> >> +  event device, it cannot switch the IRQ of broadcast clock event to any CPU.
>> >> +  Only valid for "marvell,timer-counter-clkevt".
>> >
>> > Likewise this does not sound like a hardware property.
>>
>> For a broadcast timer, there is feature "CLOCK_EVT_FEAT_DYNIRQ".
>> This feature is a clock event device's fearture. It means that the
>> clock event device's irq can
>> be set to any core.
>> In fact it does not for all SOCes that the interrupt of the counter
>> can be set to any core.
>
> The naming and use of this property still seems incredibly
> Linux-specific.
>
> Why can some of the counter interrupts not be routed to an arbitrary
> CPU?
>
The reason is couple idle.
The couple idle implementation implies that CPU0 will be first core wake up.
So, we can not have CLOCK_EVT_FEAT_DYNIRQ because it may make CPU1 to
be first core wake up.

> Cheers,
> Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chao Xie March 28, 2014, 1:55 a.m. UTC | #5
hi, Mark

Thanks very much for your review. I appreiciate your professional
suggestions and comments.

In order to make it clear, i need describe the HW fist.

There are several timer controllers, and we call each one as "timer". Each timer
has its own register space.
A timer will have 3 counters, and each counter can be seperately
disabled/enabled.
Each counter has 3 match registers. Any match of the three matches
will generate the same
interrupt.
>From the timer controller, each counter will export its own interrupt
siginal out of the controller,
but before it is connected to interrupt chip, SOC designer may combine them.

There is a silicon requirment for the timer reading.
Every time read the count, there will be a delay, or you may read a
part of the counter.
So we repeatly read the counter until two reads are same.

There is a slicon requirment for the timer setting
When we set match registers, we need disable the counter first, then
set the match register,
after that enable the counter. Disabling and re-enabling the counter
will make the counter
restart from 0.

There are two clock inputs: fastclk and 32K. fastclk will be 3.25M,
6.5M or somehing else.
Fastclk can not work if the system goes to some deep idle states.
These deep idle states: core subsystem shutdown and some clock unit will
shutdown.
We make use of these deep idle states as part of CPU idle states to
save more power.
For these power states, only 32K clock can work.

So you have questions about the DT settings
1. "marvell,timer-fastclk-frequency" marvell,timer-apb-frequency
You suggest to use  the clock bindings:

       clocks = <&apb_plck>, <&clock_controller 0 3>;
       clock-names = "apb_pclk", "fastclk";
I agree with you. The problem is now mach-mmp CLOCK DT support just starts.
I am afraid in this patch set, i can not do like this, but i am sure i
can change it
after clock DT support is done.

2. "marvell,timer-id" "marvlll,timer-counter-id"
The "marvell,timer-id" i think is not needed, because i do not need to know
the index of the timer. ALL the timer are same to me.
I need "marvell,timer-counter-id" because i need distinuish it when
set the registers

3. "marvell,timer-counter-rating"
I agree with you. It need to be fix in the code not exported in DT file.

4. "marvell,timer-counter-clkevt", "marvell,timer-counter-clksrc",
marvell,timer-counter-delay
For UP SOC, it need at least 1 clksrc and 1 clockevent device

For SMP SOC with arch timer, it need at least 1 clksrc, 1 clockevent
device for broadcast, 1 delay timer
The reason for needing delay timer: It will be running at fastclk to
achieve more accurate delay. clksrc need to be
 set 32K or i will lose the count if system goes to deep idle.
The reason for needing broadcast clkevt: arch timer will not work if
core subsystem is down, i will make them switch to
broadcast timer, so timer can still wake up cores out of idle.

For SMP SOC without arch timer, it only happens for some early version
of SOCes. except the clock devices
needed buy SMP SOC, we create the per cpu clock event device to
replace the arch timer.

So i still do not understand your suggestions "Why can you not just
describe the set of timers available to Linux and
allow it to allocate them as required?"
Can you describe it more clear?

5. marvell,timer-counter-nodynirq
The reason is couple idle.
The couple idle implementation implies that CPU0 will be first core wake up.
So, we can not have CLOCK_EVT_FEAT_DYNIRQ because it may make CPU1 to
be first core wake up.


On Thu, Mar 27, 2014 at 8:13 PM, Chao Xie <xiechao.mail@gmail.com> wrote:
>>> >>
>>> >> +Each timer have multiple counters, so the timer DT need include counter's
>>> >> +description.
>>> >> +
>>> >> +1. Timer
>>> >> +
>>> >>  Required properties:
>>> >> -- compatible : Should be "mrvl,mmp-timer".
>>> >> +- compatible : Should be "marvell,mmp-timer".
>>> >>  - reg : Address and length of the register set of timer controller.
>>> >> -- interrupts : Should be the interrupt number.
>>> >> +- marvell,timer-id : The index of the timer. The timer controller may
>>> >> +  include several timers.
>>> >
>>> > Is this a single entry or a list?
>>>
>>> Generally, the may be 2/3/4 timers, and each timers will have at most
>>> 3 coounters.
>>> Each counters will have 3 matches. Each counter may have its own
>>> interrupts, or share same
>>> interrupts(counter1 has one interrupts, counter2 and 3 share one). It depends on
>>> how SOC connets the signals.
>>>
>>> The DT will be
>>> timer 0 {
>>>      ...
>>>      ...
>>>      counter0 {
>>>      };
>>>      counter2 {
>>>      };
>>> }
>>
>> I'm somewhat confused here.
>>
>> The top level node appears to be a timer controller (per the reg
>> property description), but the marvell,timer-id property describes an
>> index within the timer controller. This does not seem to make sense.
>>
>> How do you describe multiple timers within a given timer contoller? Is
>> the timer-id a list? Or do you describe the controller repeatedly?
>>
> Thanks for your reply.
>
> the driver only take care of one timer node, if we have 3 timer node defined.
> It means that the driver will be probed 3 times.
>
> Each timer is a controller, and one timer has 3 counters. each counter can be
> set to be free running or period mode.
>
> marvell,timer-id may not be needed, but the marvell,counter-id need to
> be passed.
> The timer driver depends on the id to distinguish the register or bit
> in the register.
>
>>>
>>> >
>>> >> +- marvell,timer-fastclk-frequency : The fast clock frequency of the timer.
>>> >> +  Timer will have several clock inputs: fast clock, 32KHZ, 1KHZ. For all
>>> >> +  SOCes use this timer controller, fast clock may not be same.
>>> >> +- marvell,timer-apb-frequency : The fequency of the apb bus that the timer
>>> >> +  attached to. This frequency and "marvell,timer-fastclk-frequency" are used
>>> >> +  to calculated delay loops for clock operations.
>>> >
>>> > Wouldn't these be better described as clock inputs?
>>>
>>> "apb" frequency is only used to calculated the delay loop.
>>> I do not want to fix the delay loop in the driver.
>>> So pass it in DT directly will make the things easier to handle.
>>>
>>> "fastclk" is a clock input. So waht do you mean "described as clock inputs"?
>>
>> Using the clock bindings:
>>
>>         clocks = <&apb_plck>, <&clock_controller 0 3>;
>>         clock-names = "apb_pclk", "fastclk";
>>
>> The driver can then query the frequencies, enable/disable the clocks as
>> required, etc.
>>
> It is the final choice, but it depends on the clock DT support.
> I just begin the clock DT support for mach-mmp. They are still in design phase.
> Clock framework is more complicated than the timer controller.
>
>>>
>>> >
>>> >> +
>>> >> +Optional properties:
>>> >> +- marvell,timer-has-crsr : This timer has CRSR register.
>>> >> +- marvell,timer-has-shadow : This timer has shadow register.
>>> >> +
>>> >> +2. Counter
>>> >> +
>>> >> +Required properties:
>>> >> +- compatible : It can be
>>> >> +      "marvell,timer-counter-clkevt" : The counter is used for clock event
>>> >> +                                       device.
>>> >> +      "marvell,timer-counter-clksrc" : The counter is used for clock source.
>>> >> +      "marvell,timer-counter-delay" : The counter is used for delay timer.
>>> >
>>> > These are _not_ hardware properties. Why can the driver not choose how
>>> > to use each of the counter sub-blocks?
>>> >
>>> > How would blocks with each of these strings actually differ?
>>> >
>>>
>>> SOCes may have 2 or 3 or 4 timers, some timers may be used by CP not AP but
>>> AP can still access it.
>>> There may be UP SOC, or SMP SOC. So there are may be some general usage
>>> 1. UP SOC: need one clocksource, need one clock event device
>>> 2. SMP SOC: need one clocksource, need one broadcast clock event device because
>>>    arch timer will be shutdown when core is down
>>> 3. SMP SOC: it has bug with arch timer. So need one clock source,
>>> NR_CPUs clock event
>>>     device to replace the arch timer. There are may be 2 cores or 4 cores.
>>
>> Ok, but in all of these cases the blocks that you are giving different
>> compatible strings are identical. The only difference is how you expect
>> Linux to use them.
>>
>> Why can you not just describe the set of timers available to Linux and
>> allow it to allocate them as required?
>>
>
>
> So how can I make Linux to allocate them as required?
>
>
>>> Above requeimetns are also hardware requriments from SOCes.
>>>
>>> The driver will be used for many SOCes, we can not to fix the counter
>>> usage in driver.
>>
>> I'm arguing for dynamically deciding how to use the timers, not assuming
>> one of the three cases you've laid out above, and not describing a
>> possible software use of the counters in the DT.
>>
>
> I am a little confused.
>
> So what is your suggestions?
> we have the below usage
> 1. UP SOC, we need clock source, clock event device
> 2. SMP SOC with arch timer, we need clock source, broadcast clock event device
> 3. SMP SOC without arch timer, we need clock source, NR_CPU clock
> event device and delay timer.
>
>
>>> >> +- marvell,timer-counter-id : The counter index in this timer.
>>> >
>>> > Perhaps use a reg for this?
>>> >
>>>
>>> The counter does not have its own register space. They are belongs to a timer.
>>> Counter does not need to map the regsiter spance, it is done by timer.
>>> For example, for counter enable, all coutners share same register. CER
>>> For interrupt enable, each counter has its own register. IERx
>>>
>>> So if we use like "reg = <IERx offset>", i do not see any benefit. while
>>> direct setting "marvell,timer-counter-id" seems make the DT more clear.
>>
>> The reg doesn't have to be a register space -- it's often used simply as
>> a form of address/identifier without a size (consider SPI's use of the
>> reg property). Here the index is essentially an address/identifier for
>> the counter.
>>
>> Given that the each timer also seems to have a unique ID perhaps using
>> the reg is not the best strategy here. I was simply raising the
>> possiblity.
>>
>>>
>>> >>
>>> >> -Example:
>>> >> -       timer0: timer@d4014000 {
>>> >> -               compatible = "mrvl,mmp-timer";
>>> >> -               reg = <0xd4014000 0x100>;
>>> >> +Optional properties:
>>> >> +- interrupts : The counters may have different IRQs or share same IRQs.
>>> >> +  Only valid for "marvell,timer-counter-clkevt".
>>> >
>>> > Describe what the interrupt is logically.
>>> >
>>> > What is the interrupt logically?
>>> >
>>>
>>> The interrupt topolog is designed by SOCes.
>>> Each counter has one interrupt, but SOCes may connects some coutners' interrupt
>>> into one.
>>> In timer driver, we do not care about it. We depeneds on IRQ chip to handle it.
>>
>> How the interrupt is wired and whether it is shared is not important
>> from the view of the binding. What is important is which interrupt from
>> the timer is being described. If it has a given name, that should be
>> mentioned. Otherwise a simple description will suffice.
>>
>> The presence of external interrupt muxing doesn't seem to be important
>> here to the binding -- in that case an OS could request shared
>> interrupts or decide to only make use of a subset of interrupts. That
>> seems to be outside of the scope of the binding.
>>
>
> I see. I think a simple description is enough. i do not need mention the shared
> interrupts here because the timer driver does not care about it.
>
>>>
>>> >> +- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
>>> >> +  "marvell,timer-counter-clkevt".
>>> >
>>> > How is the counter bound to a particular CPU? Is there really a
>>> > relationship in hardware between a given CPU and counter?
>>> >
>>>
>>> For some SMP SOCes, for example, marvell's pxa988/pxa1088/pxa1L88
>>> They have bug in arch timer. So we make each CPU to have one dedicated
>>> counter to replace the arch timer.
>>
>> Is there any real topological relationship between CPUs and counters, or
>> is this arbitrary? If the latter, why can the kernel not decide how to
>> allocate timers to CPUs?
>>
>
> All the timers can be seen by every CPUes.
> For arch timer, each CPU see its own instance, while for the mmp
> timers, each CPU
> can see all of them.
> So there are some problems
> 1. The number of the timer is not fixed. It can be 2, 3, 4
> 2. Some timers can be seen by CP, and CP will use these timers. Which
> timer can be seen
>     by CP is defined by SOC design
> 3. Some counter share one interrupt, these counters can not be
> allocated for per cpu timer to replace
>     arch timer.
> So which counter allocated is limited by SOC design.
>
> So if do not have above limitation, can you tell me that how can i let
> kernel to decide allocation?
> Thanks.
>
>>>
>>> >> +- "marvell,timer-counter-rating" : The rating when register clock event device
>>> >> +  or clock source. Only valid for "marvell,timer-counter-clkevt" and
>>> >> +  "marvell,timer-counter-clksrc".
>>> >
>>> > What does this mean? This seems like another leak of Linux internals.
>>>
>>> It is the rating when register clock source and clock event.
>>> I think i can fix it in the driver.
>>
>> Ok. This is a Linux interenal detail that I do not think should be in
>> the DT.
>>
>>>
>>> >
>>> >> +- marvell,timer-counter-broadcast : When this counter acts as clock event
>>> >> +  device. It is broadcast clock event device.
>>> >> +  Only valid for "marvell,timer-counter-clkevt".
>>> >
>>> > This does not seem like a hardware property. Why can Linux not decide
>>> > which counter (if any) to use as the broadcast source?
>>> >
>>>
>>> For some SMP soces, for example, marvell's pxa988/pxa1088/pxa1L88
>>> They have bug in arch timer. So we make each CPU to have one dedicated
>>> counter to replace the arch timer. So for these SOCes, broadcast timer is not
>>> needed. For these counters, we have to set IRQ affinity to the specific core.
>>
>> That's fine, we can do that in the absence of both this property and
>> another timer (the arch timer).
>>
>>> For some SMP soces, for example, they can use arch timer, but we have
>>> to register
>>> a clock event device for broadcast because we lose arch timer if core is down.
>>> For this coutner, we have to set IRQ affinity to ALL cores.
>>
>> In that case the arch timer will register (which can have a higher
>> rating than this timer), and this timers can be automatically repurposed
>> as the broadcast source.
>>
>> I do not see the necessity of this property.
>>
> It is true that arch timer is first priority.
> There are something need to be considered
> 1. we registered NR_CPU timers to acts as arch timer. We set the
> cpu_mask of be cpu_mask(cpu_id), not
>     cpu_mask(ALL_CPUes). We also bind the interrupt to the dedicated
> CPU. For example, if timer 0 counter 0
>     is used by CPU0 to replace arch timer. the counter's IRQ only
> route to the CPU0.
>     If we have arch timers, it means that there are NR_CPU timers, i
> do not think they can be acts as broadcast timer
> 2. As i said, some coutners share interrupts. We can not allocated
> this kind of counter as per cpu clock event device.
>     For exmaple, timer 0 coutner1 and counter 2 share same interrupt.
> If they are used by CPU0 and CPU1, it means that
>     same interrupt will be bind to two CPUes. each timer interrupt
> happens, a power-down core need wake up to check the
>     interrupt does not targets at it.
>
> So how to use these counter in fact depends on the SOCes design.
> That why i need pass this kind of information to timer driver.
>
>>> >> +- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
>>> >> +  event device, it cannot switch the IRQ of broadcast clock event to any CPU.
>>> >> +  Only valid for "marvell,timer-counter-clkevt".
>>> >
>>> > Likewise this does not sound like a hardware property.
>>>
>>> For a broadcast timer, there is feature "CLOCK_EVT_FEAT_DYNIRQ".
>>> This feature is a clock event device's fearture. It means that the
>>> clock event device's irq can
>>> be set to any core.
>>> In fact it does not for all SOCes that the interrupt of the counter
>>> can be set to any core.
>>
>> The naming and use of this property still seems incredibly
>> Linux-specific.
>>
>> Why can some of the counter interrupts not be routed to an arbitrary
>> CPU?
>>
> The reason is couple idle.
> The couple idle implementation implies that CPU0 will be first core wake up.
> So, we can not have CLOCK_EVT_FEAT_DYNIRQ because it may make CPU1 to
> be first core wake up.
>
>> Cheers,
>> Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/arm/mrvl/timer.txt b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
index 9a6e251..b9af4bf 100644
--- a/Documentation/devicetree/bindings/arm/mrvl/timer.txt
+++ b/Documentation/devicetree/bindings/arm/mrvl/timer.txt
@@ -1,13 +1,74 @@ 
 * Marvell MMP Timer controller
 
+Each timer have multiple counters, so the timer DT need include counter's
+description.
+
+1. Timer
+
 Required properties:
-- compatible : Should be "mrvl,mmp-timer".
+- compatible : Should be "marvell,mmp-timer".
 - reg : Address and length of the register set of timer controller.
-- interrupts : Should be the interrupt number.
+- marvell,timer-id : The index of the timer. The timer controller may
+  include several timers.
+- marvell,timer-fastclk-frequency : The fast clock frequency of the timer.
+  Timer will have several clock inputs: fast clock, 32KHZ, 1KHZ. For all
+  SOCes use this timer controller, fast clock may not be same.
+- marvell,timer-apb-frequency : The fequency of the apb bus that the timer
+  attached to. This frequency and "marvell,timer-fastclk-frequency" are used
+  to calculated delay loops for clock operations.
+
+Optional properties:
+- marvell,timer-has-crsr : This timer has CRSR register.
+- marvell,timer-has-shadow : This timer has shadow register.
+
+2. Counter
+
+Required properties:
+- compatible : It can be
+      "marvell,timer-counter-clkevt" : The counter is used for clock event
+                                       device.
+      "marvell,timer-counter-clksrc" : The counter is used for clock source.
+      "marvell,timer-counter-delay" : The counter is used for delay timer.
+- marvell,timer-counter-id : The counter index in this timer.
 
-Example:
-	timer0: timer@d4014000 {
-		compatible = "mrvl,mmp-timer";
-		reg = <0xd4014000 0x100>;
+Optional properties:
+- interrupts : The counters may have different IRQs or share same IRQs.
+  Only valid for "marvell,timer-counter-clkevt".
+- marvell,timer-counter-cpu : which CPU the counter is bound. Only valid for
+  "marvell,timer-counter-clkevt".
+- "marvell,timer-counter-rating" : The rating when register clock event device
+  or clock source. Only valid for "marvell,timer-counter-clkevt" and
+  "marvell,timer-counter-clksrc".
+- marvell,timer-counter-broadcast : When this counter acts as clock event
+  device. It is broadcast clock event device.
+  Only valid for "marvell,timer-counter-clkevt".
+- marvell,timer-counter-nodynirq : When this counter acts as broadcast clock
+  event device, it cannot switch the IRQ of broadcast clock event to any CPU.
+  Only valid for "marvell,timer-counter-clkevt".
+
+3. Examples
+
+timer0: timer@d4014000 {
+	compatible = "marvell,mmp-timer";
+	reg = <0xd4014000 0xc8>;
+	marvell,timer-id = <0>;
+	marvell,timer-fastclk-frequency = <3250000>;
+	marvell,timer-apb-frequency = <26000000>;
+	status = "okay";
+
+	counter0 {
+		compatible = "marvell,timer-counter-clkevt";
 		interrupts = <13>;
+		marvell,timer-counter-id = <0>;
+		marvell,timer-counter-cpu = <0>;
+		marvell,timer-counter-frequency = <32768>;
+		marvell,timer-counter-rating = <200>;
+	};
+
+	counter1 {
+		compatible = "marvell,timer-counter-clksrc";
+		marvell,timer-counter-id = <1>;
+		marvell,timer-counter-frequency = <32768>;
+		marvell,timer-counter-rating = <200>;
 	};
+};
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index fb0d82e0..b877a1e 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -17,6 +17,7 @@  obj-$(CONFIG_ARMADA_370_XP_TIMER)	+= time-armada-370-xp.o
 obj-$(CONFIG_ORION_TIMER)	+= time-orion.o
 obj-$(CONFIG_ARCH_BCM2835)	+= bcm2835_timer.o
 obj-$(CONFIG_ARCH_MARCO)	+= timer-marco.o
+obj-$(CONFIG_ARCH_MMP)		+= timer-mmp.o
 obj-$(CONFIG_ARCH_MOXART)	+= moxart_timer.o
 obj-$(CONFIG_ARCH_MXS)		+= mxs_timer.o
 obj-$(CONFIG_ARCH_PRIMA2)	+= timer-prima2.o
diff --git a/drivers/clocksource/timer-mmp.c b/drivers/clocksource/timer-mmp.c
new file mode 100644
index 0000000..c83d722
--- /dev/null
+++ b/drivers/clocksource/timer-mmp.c
@@ -0,0 +1,866 @@ 
+/*
+ * driver/clocksource/timer-mmp.c
+ *
+ *   Support for clocksource and clockevents
+ *
+ * Copyright (C) 2008 Marvell International Ltd.
+ * All rights reserved.
+ *
+ *   2008-04-11: Jason Chagas <Jason.chagas@marvell.com>
+ *   2008-10-08: Bin Yang <bin.yang@marvell.com>
+ *
+ * The timers module actually includes three timers, each timer with up to
+ * three match comparators. Timer #0 is used here in free-running mode as
+ * the clock source, and match comparator #1 used as clock event device.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/clockchips.h>
+
+#include <linux/io.h>
+#include <linux/irq.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/cpu.h>
+#include <linux/mmp_timer.h>
+#include <linux/clockchips.h>
+#include <linux/sched_clock.h>
+
+#define TMR_CCR		(0x0000)
+#define TMR_TN_MM(n, m)	(0x0004 + ((n) << 3) + (((n) + (m)) << 2))
+#define TMR_CR(n)	(0x0028 + ((n) << 2))
+#define TMR_SR(n)	(0x0034 + ((n) << 2))
+#define TMR_IER(n)	(0x0040 + ((n) << 2))
+#define TMR_PLVR(n)	(0x004c + ((n) << 2))
+#define TMR_PLCR(n)	(0x0058 + ((n) << 2))
+#define TMR_WMER	(0x0064)
+#define TMR_WMR		(0x0068)
+#define TMR_WVR		(0x006c)
+#define TMR_WSR		(0x0070)
+#define TMR_ICR(n)	(0x0074 + ((n) << 2))
+#define TMR_WICR	(0x0080)
+#define TMR_CER		(0x0084)
+#define TMR_CMR		(0x0088)
+#define TMR_ILR(n)	(0x008c + ((n) << 2))
+#define TMR_WCR		(0x0098)
+#define TMR_WFAR	(0x009c)
+#define TMR_WSAR	(0x00A0)
+#define TMR_CVWR(n)	(0x00A4 + ((n) << 2))
+#define TMR_CRSR        (0x00B0)
+
+#define TMR_CCR_CS_0(x)	(((x) & 0x3) << 0)
+#define TMR_CCR_CS_1(x)	(((x) & 0x3) << 2)
+#define TMR_CCR_CS_2(x)	(((x) & 0x3) << 5)
+
+#define MAX_EVT_NUM		5
+
+#define MAX_DELTA		(0xfffffffe)
+#define MIN_DELTA		(5)
+
+#define MMP_MAX_COUNTER		3
+#define MMP_MAX_TIMER		4
+
+#define TMR_CER_COUNTER(cid)	(1 << (cid))
+#define MMP_ALL_COUNTERS	((1 << MMP_MAX_COUNTER) - 1)
+
+#define MMP_TIMER_CLOCK_32KHZ	32768
+#define MMP_TIMER_CLOCK_1KHZ	1000
+
+struct mmp_timer;
+struct mmp_timer_counter {
+	unsigned int id;
+	unsigned int usage;
+	unsigned int cnt_freq;
+	int cpu;
+	int loop_delay;
+	struct mmp_timer *timer;
+};
+
+struct mmp_timer {
+	unsigned int id;
+	void __iomem *base;
+	struct mmp_timer_counter counters[MMP_MAX_COUNTER];
+	unsigned int flag;
+	int loop_delay_fastclk;
+	unsigned int fc_freq;
+	/* lock to protect hw operation. */
+	spinlock_t tm_lock;
+};
+
+struct mmp_timer_clkevt {
+	struct mmp_timer_counter *counter;
+	struct clock_event_device ced;
+	struct irqaction irqa;
+	struct notifier_block nb;
+};
+
+struct mmp_timer_clksrc {
+	struct mmp_timer_counter *counter;
+	struct clocksource cs;
+};
+
+#ifdef CONFIG_ARM
+struct mmp_timer_dclk {
+	struct mmp_timer_counter *counter;
+	struct delay_timer *dt;
+};
+static struct mmp_timer_dclk *dclk;
+#endif
+
+static struct mmp_timer *mmp_timers[MMP_MAX_TIMER];
+static struct mmp_timer_clksrc *clksrc;
+
+static int timer_counter_switch_clock(int tid, int cid, unsigned int freq)
+{
+	struct mmp_timer *tm = mmp_timers[tid];
+	u32 ccr, mask;
+
+	ccr = __raw_readl(tm->base + TMR_CCR);
+
+	if (cid == 0)
+		mask = TMR_CCR_CS_0(3);
+	else if (cid == 1)
+		mask = TMR_CCR_CS_1(3);
+	else
+		mask = TMR_CCR_CS_2(3);
+
+	ccr &= ~mask;
+
+	if (freq == MMP_TIMER_CLOCK_32KHZ) {
+		if (cid == 2)
+			ccr |= TMR_CCR_CS_2(2);
+		else if (cid == 1)
+			ccr |= TMR_CCR_CS_1(1);
+		else if (cid == 0)
+			ccr |= TMR_CCR_CS_0(1);
+	} else if (freq == MMP_TIMER_CLOCK_1KHZ) {
+		if (cid == 2)
+			ccr |= TMR_CCR_CS_2(1);
+		else if (cid == 1)
+			ccr |= TMR_CCR_CS_1(2);
+	} else if (freq == tm->fc_freq) {
+		if (cid == 2)
+			ccr |= TMR_CCR_CS_2(0);
+		else if (cid == 1)
+			ccr |= TMR_CCR_CS_1(0);
+		else if (cid == 0)
+			ccr |= TMR_CCR_CS_0(0);
+	} else {
+		pr_err("Timer %d:%d: invalid clock rate %d\n", tid, cid, freq);
+		return -EINVAL;
+	}
+
+	__raw_writel(ccr, tm->base + TMR_CCR);
+
+	return 0;
+}
+
+static void timer_counter_disable(struct mmp_timer_counter *cnt)
+{
+	struct mmp_timer *tm = cnt->timer;
+	int delay = tm->loop_delay_fastclk;
+	u32 cer;
+
+	/*
+	 * Stop the counter will need mutiple timer clock to take effect.
+	 * Some operations can only be done when counter is disabled. So
+	 * add delay here.
+	 */
+	/* Step1: disable counter */
+	cer = __raw_readl(tm->base + TMR_CER);
+	__raw_writel(cer & ~(1 << cnt->id), tm->base + TMR_CER);
+
+	/*
+	 * Step2: switch to fast clock, so the delay can be completed
+	 * quickly.
+	 */
+	if (cnt->cnt_freq != tm->fc_freq)
+		timer_counter_switch_clock(tm->id, cnt->id, tm->fc_freq);
+
+	/*
+	 * Step3: Loop for mutiple timer cycles. We do it by clearing
+	 * pending interrupt status.
+	 */
+	while (delay--)
+		__raw_writel(0x1, tm->base + TMR_ICR(cnt->id));
+}
+
+static void timer_counter_enable(struct mmp_timer_counter *cnt)
+{
+	struct mmp_timer *tm = cnt->timer;
+	u32 cer;
+
+	/* Switch to original clock */
+	if (cnt->cnt_freq != tm->fc_freq)
+		timer_counter_switch_clock(tm->id, cnt->id, cnt->cnt_freq);
+
+	/* Enable timer */
+	cer = __raw_readl(tm->base + TMR_CER);
+	__raw_writel(cer | (1 << cnt->id), tm->base + TMR_CER);
+}
+
+static inline uint32_t timer_read(struct mmp_timer_counter *cnt)
+{
+	struct mmp_timer *tm = cnt->timer;
+	int has_shadow = tm->flag & MMP_TIMER_FLAG_SHADOW;
+	int delay = 3;
+	u32 val1, val2;
+
+	if (has_shadow) {
+		return __raw_readl(tm->base + TMR_CR(cnt->id));
+	} else {
+		if (cnt->cnt_freq != tm->fc_freq) {
+			/* slow clock */
+			do {
+				val1 = __raw_readl(tm->base + TMR_CR(cnt->id));
+				val2 = __raw_readl(tm->base + TMR_CR(cnt->id));
+			} while (val2 != val1);
+		} else {
+			/* fast clock */
+			__raw_writel(1, tm->base + TMR_CVWR(cnt->id));
+			while (delay--)
+				val1 = __raw_readl(tm->base +
+						TMR_CVWR(cnt->id));
+		}
+		return val1;
+	}
+}
+
+static irqreturn_t timer_interrupt(int irq, void *dev_id)
+{
+	struct clock_event_device *c = dev_id;
+	struct mmp_timer_clkevt *evt;
+	struct mmp_timer_counter *counter;
+	unsigned int cnt;
+	unsigned long flags;
+	void __iomem *base;
+	int has_crsr;
+
+	evt = container_of(c, struct mmp_timer_clkevt, ced);
+	counter = evt->counter;
+	cnt = counter->id;
+	base = counter->timer->base;
+	has_crsr = counter->timer->flag & MMP_TIMER_FLAG_CRSR;
+
+	spin_lock_irqsave(&(counter->timer->tm_lock), flags);
+	/* We only use match #0 for the counter. */
+	if (__raw_readl(base + TMR_SR(cnt)) & 0x1) {
+		if (!has_crsr)
+			timer_counter_disable(counter);
+
+		/* Disable the interrupt. */
+		__raw_writel(0x00, base + TMR_IER(cnt));
+		/* Clear interrupt status */
+		__raw_writel(0x01, base + TMR_ICR(cnt));
+
+		spin_unlock_irqrestore(&(counter->timer->tm_lock), flags);
+
+		c->event_handler(c);
+
+		return IRQ_HANDLED;
+	}
+
+	spin_unlock_irqrestore(&(counter->timer->tm_lock), flags);
+
+	return IRQ_NONE;
+}
+
+static int timer_set_next_event(unsigned long delta,
+				struct clock_event_device *dev)
+{
+	struct mmp_timer_counter *cnt;
+	struct mmp_timer_clkevt *evt;
+	unsigned long flags;
+	unsigned int cid;
+	u32 cer, crsr;
+	void __iomem *base;
+	int delay, has_crsr;
+
+	evt = container_of(dev, struct mmp_timer_clkevt, ced);
+	cnt = evt->counter;
+	cid = cnt->id;
+	base = cnt->timer->base;
+	has_crsr = cnt->timer->flag & MMP_TIMER_FLAG_CRSR;
+
+	spin_lock_irqsave(&(cnt->timer->tm_lock), flags);
+	if (has_crsr) {
+		/*
+		 * Use TMR_CRSR to restart the counter and make match
+		 * register take effect. This bit should be 0 before
+		 * set it again.
+		 * The polling loop is defined by loop_delay.
+		 */
+		delay = cnt->loop_delay;
+		do {
+			crsr = __raw_readl(base + TMR_CRSR);
+			delay--;
+		} while ((crsr & (1 << cid)) && delay > 0);
+
+		BUG_ON(delay <= 0);
+
+		__raw_writel(delta - 1, base + TMR_TN_MM(cid, 0));
+		/*
+		 * After counter is restart, clear the interrupt status for
+		 * safe, and re-enable the interrupt for match #0.
+		 */
+		__raw_writel(0x01, base + TMR_ICR(cid));
+		__raw_writel(0x01, base + TMR_IER(cid));
+		__raw_writel((1 << cid), base + TMR_CRSR);
+	} else {
+		cer = __raw_readl(base + TMR_CER);
+
+		/* If the timer counter is enabled, first disable it. */
+		if (cer & (1 << cid))
+			timer_counter_disable(cnt);
+
+		/* Setup new counter value */
+		__raw_writel(delta - 1, base + TMR_TN_MM(cid, 0));
+
+		/* enable the matching interrupt */
+		__raw_writel(0x1, base + TMR_IER(cid));
+
+		timer_counter_enable(cnt);
+	}
+	spin_unlock_irqrestore(&(cnt->timer->tm_lock), flags);
+
+	return 0;
+}
+
+static void timer_set_mode(enum clock_event_mode mode,
+			   struct clock_event_device *dev)
+{
+	unsigned long flags;
+	unsigned int cnt;
+	struct mmp_timer_counter *counter;
+	struct mmp_timer_clkevt *evt;
+	void __iomem *base;
+
+	evt = container_of(dev, struct mmp_timer_clkevt, ced);
+	counter = evt->counter;
+	cnt = counter->id;
+	base = counter->timer->base;
+
+	spin_lock_irqsave(&(counter->timer->tm_lock), flags);
+	switch (mode) {
+	case CLOCK_EVT_MODE_UNUSED:
+	case CLOCK_EVT_MODE_SHUTDOWN:
+		timer_counter_disable(counter);
+		break;
+	case CLOCK_EVT_MODE_RESUME:
+	case CLOCK_EVT_MODE_PERIODIC:
+	case CLOCK_EVT_MODE_ONESHOT:
+		timer_counter_enable(counter);
+		break;
+	}
+	spin_unlock_irqrestore(&(counter->timer->tm_lock), flags);
+}
+
+static cycle_t clksrc_read(struct clocksource *cs)
+{
+	return timer_read(clksrc->counter);
+}
+
+static u64 notrace mmp_read_sched_clock(void)
+{
+	return timer_read(clksrc->counter);
+}
+
+#ifdef CONFIG_ARM
+static unsigned long d_read_current_timer(void)
+{
+	return timer_read(dclk->counter);
+}
+
+static struct delay_timer d_timer = {
+	.read_current_timer	= d_read_current_timer,
+};
+#endif
+
+static int mmp_timer_cpu_notify(struct notifier_block *self,
+					   unsigned long action, void *hcpu)
+{
+	struct mmp_timer_clkevt *evt;
+	struct mmp_timer_counter *cnt;
+
+	evt = container_of(self, struct mmp_timer_clkevt, nb);
+	cnt = evt->counter;
+
+	if (cnt->cpu != (unsigned long)hcpu)
+		return NOTIFY_OK;
+
+	switch (action & ~CPU_TASKS_FROZEN) {
+	case CPU_STARTING:
+		clockevents_config_and_register(&evt->ced,
+						cnt->cnt_freq,
+						MIN_DELTA, MAX_DELTA);
+		break;
+	case CPU_ONLINE:
+		irq_set_affinity(evt->ced.irq, evt->ced.cpumask);
+		enable_irq(evt->ced.irq);
+		break;
+	case CPU_DYING:
+		clockevents_set_mode(&evt->ced,
+				     CLOCK_EVT_MODE_SHUTDOWN);
+		disable_irq(evt->ced.irq);
+		break;
+	}
+
+	return NOTIFY_OK;
+}
+
+int __init mmp_timer_init(int tid, void __iomem *base,
+			unsigned int flag, unsigned int fc_freq,
+			unsigned int apb_freq)
+{
+	struct mmp_timer *tm = mmp_timers[tid];
+	u32 tmp, delay;
+	int cid;
+
+	if (tm)
+		return -EINVAL;
+
+	tm = kzalloc(sizeof(*tm), GFP_KERNEL);
+	if (!tm)
+		return -ENOMEM;
+
+	/*
+	 * The calculation formula for the loop cycle is:
+	 *
+	 * (1) need wait for 2 timer's clock cycle:
+	 *        1             2
+	 *     ------- x 2 = -------
+	 *     fc_freq       fc_freq
+	 *
+	 * (2) convert to apb clock cycle:
+	 *        2          1        apb_freq * 2
+	 *     ------- / -------- = ----------------
+	 *     fc_freq   apb_freq       fc_freq
+	 *
+	 * (3) every apb register's accessing will take 8 apb clock cycle,
+	 *     also consider add extral one more time for safe way;
+	 *     so finally need loop times for the apb register accessing:
+	 *
+	 *       (apb_freq * 2)
+	 *     ------------------ / 8 + 1
+	 *          fc_freq
+	 */
+	delay = ((apb_freq * 2) / fc_freq / 8) + 1;
+	pr_debug("Timer %d: loop_delay_fastclk is %d\n", tid, delay);
+
+	tm->id = tid;
+	tm->base = base;
+	tm->flag = flag;
+	tm->loop_delay_fastclk = delay;
+	tm->fc_freq = fc_freq;
+	spin_lock_init(&(tm->tm_lock));
+
+	mmp_timers[tid] = tm;
+
+	for (cid = 0; cid < MMP_MAX_COUNTER; cid++) {
+		tm->counters[cid].id = cid;
+		tm->counters[cid].timer = tm;
+
+		/* We will disable all counters. Switch to fastclk first. */
+		timer_counter_switch_clock(tid, cid, fc_freq);
+	}
+
+	/* disalbe all counters */
+	tmp = __raw_readl(base + TMR_CER) & ~MMP_ALL_COUNTERS;
+	__raw_writel(tmp, base + TMR_CER);
+
+	/* disable matching interrupt */
+	__raw_writel(0x00, base + TMR_IER(0));
+	__raw_writel(0x00, base + TMR_IER(1));
+	__raw_writel(0x00, base + TMR_IER(2));
+
+	while (delay--) {
+		/* Clear pending interrupt status */
+		__raw_writel(0x1, base + TMR_ICR(0));
+		__raw_writel(0x1, base + TMR_ICR(1));
+		__raw_writel(0x1, base + TMR_ICR(2));
+		__raw_writel(tmp, base + TMR_CER);
+	}
+
+	return 0;
+}
+
+static int __init mmp_timer_counter_hw_init(struct mmp_timer *tm, int cid,
+					unsigned int freq)
+{
+	u32 tmp, delay;
+	unsigned int ratio;
+	int ret;
+
+	ret = timer_counter_switch_clock(tm->id, cid, freq);
+	if (ret)
+		return ret;
+
+	ratio = tm->fc_freq / tm->counters[cid].cnt_freq;
+	tm->counters[cid].cnt_freq = freq;
+	tm->counters[cid].loop_delay = tm->loop_delay_fastclk * ratio;
+
+	/* set timer to free-running mode */
+	tmp = __raw_readl(tm->base + TMR_CMR) | TMR_CER_COUNTER(cid);
+	__raw_writel(tmp, tm->base + TMR_CMR);
+
+	/* free-running */
+	__raw_writel(0x0, tm->base + TMR_PLCR(cid));
+	/* clear status */
+	__raw_writel(0x7, tm->base + TMR_ICR(cid));
+
+	/* enable counter */
+	tmp = __raw_readl(tm->base + TMR_CER) | TMR_CER_COUNTER(cid);
+	__raw_writel(tmp, tm->base + TMR_CER);
+
+	delay = tm->counters[cid].loop_delay;
+	while (delay--)
+		__raw_writel(tmp, tm->base + TMR_CER);
+
+	return 0;
+}
+
+int __init mmp_counter_clocksource_init(int tid, int cid, int rating,
+		unsigned int freq)
+{
+	struct mmp_timer *mt = mmp_timers[tid];
+	int ret;
+
+	if (!mt)
+		return -EINVAL;
+
+	if (cid < 0 || cid >= MMP_MAX_COUNTER)
+		return -EINVAL;
+
+	if (clksrc) {
+		pr_err("One clksrc has already been registered!\n");
+		return -EINVAL;
+	}
+	clksrc = kzalloc(sizeof(*clksrc), GFP_KERNEL);
+	if (!clksrc)
+		return -ENOMEM;
+
+	mt->counters[cid].usage |= MMP_TIMER_COUNTER_CLKSRC;
+	mt->counters[cid].cnt_freq = freq;
+
+	clksrc->counter = &mt->counters[cid];
+	clksrc->cs.name = "clocksource-mmp";
+	clksrc->cs.rating = rating;
+	clksrc->cs.read = clksrc_read;
+	clksrc->cs.mask = CLOCKSOURCE_MASK(32);
+	clksrc->cs.flags = CLOCK_SOURCE_IS_CONTINUOUS;
+
+	sched_clock_register(mmp_read_sched_clock, 32, freq);
+
+	clocksource_register_hz(&(clksrc->cs), freq);
+
+	ret = mmp_timer_counter_hw_init(mt, cid, freq);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+int __init mmp_counter_timer_delay_init(int tid, int cid, unsigned int freq)
+{
+#ifdef CONFIG_ARM
+	struct mmp_timer *mt = mmp_timers[tid];
+	int ret;
+
+	if (!mt)
+		return -EINVAL;
+
+	if (cid < 0 || cid >= MMP_MAX_COUNTER)
+		return -EINVAL;
+
+	if (dclk) {
+		pr_err("Delay clock has already been registered!\n");
+		return -EINVAL;
+	}
+	dclk = kzalloc(sizeof(*dclk), GFP_KERNEL);
+	if (!dclk)
+		return -ENOMEM;
+
+	mt->counters[cid].usage |= MMP_TIMER_COUNTER_DELAY;
+	mt->counters[cid].cnt_freq = freq;
+
+	dclk->counter = &mt->counters[cid];
+	dclk->dt = &d_timer;
+	d_timer.freq = freq;
+	register_current_timer_delay(&d_timer);
+
+	ret = mmp_timer_counter_hw_init(mt, cid, freq);
+	if (ret)
+		return ret;
+#endif
+	return 0;
+}
+
+int __init mmp_counter_clockevent_init(int tid, int cid, int rating, int irq,
+		int freq, int dynirq, unsigned int cpu)
+{
+	struct mmp_timer *mt = mmp_timers[tid];
+	struct mmp_timer_clkevt *clkevt;
+	int broadcast = 0;
+	int ret;
+
+	if (!mt)
+		return -EINVAL;
+
+	if (cid < 0 || cid >= MMP_MAX_COUNTER)
+		return -EINVAL;
+
+	if (cpu == MMP_TIMER_ALL_CPU)
+		broadcast = 1;
+	else if (cpu >= num_possible_cpus())
+		return -EINVAL;
+
+	mt->counters[cid].usage |= MMP_TIMER_COUNTER_CLKEVT;
+	mt->counters[cid].cnt_freq = freq;
+	mt->counters[cid].cpu = cpu;
+
+	clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL);
+	if (!clkevt)
+		return -ENOMEM;
+	clkevt->counter = &mt->counters[cid];
+	clkevt->ced.name = "clockevent-mmp";
+	clkevt->ced.features = CLOCK_EVT_FEAT_ONESHOT;
+	clkevt->ced.rating = rating;
+	clkevt->ced.set_next_event = timer_set_next_event;
+	clkevt->ced.set_mode = timer_set_mode;
+	clkevt->ced.irq = irq;
+
+	clkevt->irqa.flags = IRQF_DISABLED | IRQF_TIMER |
+		IRQF_IRQPOLL;
+	clkevt->irqa.handler = timer_interrupt;
+	clkevt->irqa.dev_id = &(clkevt->ced);
+
+	ret = mmp_timer_counter_hw_init(mt, cid, freq);
+	if (ret)
+		return ret;
+
+	if (broadcast) {
+		clkevt->irqa.name = "broadcast-timer";
+		if (dynirq)
+			clkevt->ced.features |= CLOCK_EVT_FEAT_DYNIRQ;
+		clkevt->ced.cpumask = cpu_possible_mask;
+		setup_irq(clkevt->ced.irq, &(clkevt->irqa));
+		clockevents_config_and_register(&clkevt->ced,
+						freq, MIN_DELTA, MAX_DELTA);
+	} else {
+		clkevt->irqa.name = "local-timer";
+		clkevt->ced.cpumask = cpumask_of(cpu);
+		clkevt->nb.notifier_call = mmp_timer_cpu_notify;
+		register_cpu_notifier(&clkevt->nb);
+		setup_irq(clkevt->ced.irq, &(clkevt->irqa));
+		/* Enable clock event device for boot CPU. */
+		if (cpu == smp_processor_id()) {
+			clockevents_config_and_register(&clkevt->ced,
+							freq, MIN_DELTA,
+							MAX_DELTA);
+			/* Only online CPU can be set affinity. */
+			irq_set_affinity(clkevt->ced.irq, cpumask_of(cpu));
+		} else {
+			/* disable none boot CPU's irq at first */
+			disable_irq(clkevt->ced.irq);
+		}
+	}
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+
+struct of_device_id mmp_counter_of_id[] = {
+	{
+		.compatible = "marvell,timer-counter-clksrc",
+		.data = (void *)MMP_TIMER_COUNTER_CLKSRC,
+	},
+	{
+		.compatible = "marvell,timer-counter-clkevt",
+		.data = (void *)MMP_TIMER_COUNTER_CLKEVT,
+	},
+	{
+		.compatible = "marvell,timer-counter-delay",
+		.data = (void *)MMP_TIMER_COUNTER_DELAY,
+	},
+	{ },
+};
+
+static int __init mmp_of_counter_init(struct device_node *np, int tid,
+					unsigned int usage)
+{
+	int irq, ret, dynirq;
+	unsigned int cid, freq, cpu, rating;
+
+	if (!np)
+		return -EINVAL;
+
+	ret = of_property_read_u32(np, "marvell,timer-counter-id", &cid);
+	if (ret) {
+		pr_err("Timer %d: fail to get counter id\n", tid);
+		return ret;
+	}
+
+	ret = of_property_read_u32(np, "marvell,timer-counter-frequency",
+			&freq);
+	if (ret) {
+		pr_err("Timer %d:%d: fail to get counter frequency\n",
+		       tid, cid);
+		return ret;
+	}
+
+	if (usage & MMP_TIMER_COUNTER_DELAY) {
+		ret = mmp_counter_timer_delay_init(tid, cid, freq);
+		if (ret) {
+			pr_err("Timer %d:%d: fail to create delay timer\n",
+			       tid, cid);
+			return ret;
+		}
+	}
+
+	if (usage & (MMP_TIMER_COUNTER_CLKSRC | MMP_TIMER_COUNTER_CLKEVT)) {
+		ret = of_property_read_u32(np,
+				"marvell,timer-counter-rating", &rating);
+		if (ret) {
+			pr_err("Timer %d:%d: fail to get counter rating\n",
+			       tid, cid);
+			return ret;
+		}
+	}
+	if (usage & MMP_TIMER_COUNTER_CLKSRC) {
+		ret = mmp_counter_clocksource_init(tid, cid, rating,
+					freq);
+		if (ret) {
+			pr_err("Timer %d:%d: fail to create clksrc\n",
+			       tid, cid);
+			return ret;
+		}
+	}
+	if (usage & MMP_TIMER_COUNTER_CLKEVT) {
+		if (of_property_read_bool(np,
+					  "marvell,timer-counter-broadcast")) {
+			cpu = MMP_TIMER_ALL_CPU;
+		} else {
+			ret = of_property_read_u32(np,
+					"marvell,timer-counter-cpu", &cpu);
+			if (ret) {
+				pr_err("Timer %d:%d: fail to get cpu\n",
+				       tid, cid);
+				return ret;
+			}
+		}
+		dynirq = !of_property_read_bool(np,
+				"marvell,timer-counter-nodynirq");
+		irq = irq_of_parse_and_map(np, 0);
+		ret = mmp_counter_clockevent_init(tid, cid, rating,
+					irq, freq, dynirq, cpu);
+		if (ret) {
+			pr_err("Timer %d:%d: fail to create clkevt\n",
+			       tid, cid);
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void __init mmp_of_timer_init(struct device_node *np)
+{
+	int tid;
+	unsigned int flag, fc_freq, apb_freq;
+	void __iomem *base;
+	struct device_node *child_np;
+	const struct of_device_id *match;
+	int ret = 0;
+
+	/* timer initialization */
+	ret = of_property_read_u32(np, "marvell,timer-id", &tid);
+	if (ret) {
+		pr_err("Timer: fail to get timer id with err %d\n", ret);
+		goto out;
+	}
+	if (tid < 0 || tid >= MMP_MAX_TIMER) {
+		pr_err("Timer: id too large or too small\n");
+		ret = -EINVAL;
+		goto out;
+	}
+	base = of_iomap(np, 0);
+	if (!base) {
+		pr_err("Timer: fail to map register space\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	flag = 0;
+	if (of_property_read_bool(np, "marvell,timer-has-crsr"))
+		flag |= MMP_TIMER_FLAG_CRSR;
+
+	if (of_property_read_bool(np, "marvell,timer-has-shadow"))
+		flag |= MMP_TIMER_FLAG_SHADOW;
+
+	/* timer's fast clock and apb frequency */
+	ret = of_property_read_u32(np, "marvell,timer-fastclk-frequency",
+			&fc_freq);
+	if (ret) {
+		pr_err("Timer %d: fail to get fastclk-frequency with err %d\n",
+		       tid, ret);
+		goto out;
+	}
+	ret = of_property_read_u32(np, "marvell,timer-apb-frequency",
+			&apb_freq);
+	if (ret) {
+		pr_err("Timer %d: fail to get apb-frequency with err %d\n",
+		       tid, ret);
+		goto out;
+	}
+
+	/*
+	 * Need use loop for more safe register's accessing,
+	 * so at here dynamically calculate the loop time.
+	 */
+	if (!fc_freq || !apb_freq) {
+		pr_err("mmp timer's fast clock or apb freq are incorrect!\n");
+		ret = -EINVAL;
+		goto out;
+	}
+
+	ret = mmp_timer_init(tid, base, flag, fc_freq, apb_freq);
+	if (ret)
+		goto out;
+
+	/*
+	 * If device node is marked as not available,
+	 * we then don't try to enable the counter again
+	 */
+	if (!of_device_is_available(np)) {
+		pr_warn("Timer %d: is not used\n", tid);
+		return;
+	}
+
+	/* counter initialization */
+	for_each_child_of_node(np, child_np) {
+		match = of_match_node(mmp_counter_of_id, child_np);
+		ret = mmp_of_counter_init(child_np, tid,
+					(unsigned int)match->data);
+		if (ret)
+			goto out;
+	}
+
+	return;
+out:
+	if (ret)
+		pr_err("Failed to get timer from dtb with error:%d\n", ret);
+	return;
+}
+
+CLOCKSOURCE_OF_DECLARE(mmp_timer, "marvell,mmp-timer", mmp_of_timer_init);
+#endif