Message ID | 1395809563-31872-2-git-send-email-chao.xie@marvell.com |
---|---|
State | Superseded, archived |
Headers | show |
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
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
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
>> >> >> >> +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
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 --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