Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1420814 > unrolled thread
| Started by | Daniel Lezcano <daniel.lezcano@linaro.org> |
|---|---|
| First post | 2016-06-13 15:10 +0200 |
| Last post | 2016-06-14 11:20 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399 Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-06-13 15:10 +0200
Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399 "Huang, Tao" <huangtao@rock-chips.com> - 2016-06-14 06:10 +0200
Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399 Caesar Wang <wxt@rock-chips.com> - 2016-06-14 11:20 +0200
| From | Daniel Lezcano <daniel.lezcano@linaro.org> |
|---|---|
| Date | 2016-06-13 15:10 +0200 |
| Subject | Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399 |
| Message-ID | <rJzMS-6In-29@gated-at.bofh.it> |
On Tue, Jun 07, 2016 at 12:54:29PM +0800, Caesar Wang wrote: > This series patches had been tested on rockchip inside kernel. > In order to support the rk3399 SoC timer and turn off interrupts and IPIs to > save power in idle. For my personnal information, are the arch_timer in the same power domain than the CPU ? IOW, what is the 'always-on' property in the DT ? > Okay, it still works bootup on rk3288/other SoCs, even though many socs > hasn't used > the broadcast timer. Yes, unfortunately the SoC design on rk3288 and the previous ones do not allow to use a cpuidle driver with cpu/cluster power down, so obviously the broadcast timer is pointless on these boards :) > History version: > v1: > https://lkml.org/lkml/2016/5/25/186 > > Easy to test for my borad. > localhost / # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 > 1: 0 0 0 0 0 0 GICv3 29 Edge arch_timer > ... > 5: 0 0 0 0 0 0 GICv3 113 Level rk_timer > .. > > localhost / # cat /proc/timer_list | grep event_handler > get "event_handler: hrtimer_interrupt" > event_handler: tick_handle_oneshot_broadcast > event_handler: hrtimer_interrupt What are you trying to demonstrate here ? There are no interrupts for both arch_timer and rk_timer. > That should work for my board. What do you mean ?
[toc] | [next] | [standalone]
| From | "Huang, Tao" <huangtao@rock-chips.com> |
|---|---|
| Date | 2016-06-14 06:10 +0200 |
| Message-ID | <rJNPP-7YV-1@gated-at.bofh.it> |
| In reply to | #1420814 |
Hi Daniel:
On 2016年06月13日 21:06, Daniel Lezcano wrote:
> On Tue, Jun 07, 2016 at 12:54:29PM +0800, Caesar Wang wrote:
>> This series patches had been tested on rockchip inside kernel.
>> In order to support the rk3399 SoC timer and turn off interrupts and IPIs to
>> save power in idle.
>
> For my personnal information, are the arch_timer in the same power domain
> than the CPU ? IOW, what is the 'always-on' property in the DT ?
Yes. In our SoC design, all arch (generic) timer in the same power
domain of CPU core. So if one CPU core power down, the arch (generic)
timer will lose it's state and stop working.
While rk timer maybe in peri power domain or pmu power domain, so the
timer will still work when CPU power down.
But before RK3399, all SoCs with CPU power domain, do not support auto
power down while cpu idle. So the arch timer can be seem as always on,
i.e. we don't need a broadcast timer at all.
>
>> Okay, it still works bootup on rk3288/other SoCs, even though many socs
>> hasn't used
>> the broadcast timer.
>
> Yes, unfortunately the SoC design on rk3288 and the previous ones do not
> allow to use a cpuidle driver with cpu/cluster power down, so obviously the
> broadcast timer is pointless on these boards :)
>
You are right.
>> History version:
>> v1:
>> https://lkml.org/lkml/2016/5/25/186
>>
>> Easy to test for my borad.
>> localhost / # cat /proc/interrupts
>> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
>> 1: 0 0 0 0 0 0 GICv3 29 Edge arch_timer
>> ...
>> 5: 0 0 0 0 0 0 GICv3 113 Level rk_timer
>> ..
>>
>> localhost / # cat /proc/timer_list | grep event_handler
>> get "event_handler: hrtimer_interrupt"
>> event_handler: tick_handle_oneshot_broadcast
>> event_handler: hrtimer_interrupt
>
> What are you trying to demonstrate here ? There are no interrupts for both
> arch_timer and rk_timer.
I don't know. Maybe Caesar do something wrong :(
This is my output:
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
...
2: 2911 1967 1588 1608 1295 1606
GICv3 30 Edge arch_timer
5: 578 637 684 626 161 165
GICv3 113 Level rk_timer
[toc] | [prev] | [next] | [standalone]
| From | Caesar Wang <wxt@rock-chips.com> |
|---|---|
| Date | 2016-06-14 11:20 +0200 |
| Message-ID | <rJSFQ-2Rh-11@gated-at.bofh.it> |
| In reply to | #1421562 |
On 2016年06月14日 12:00, Huang, Tao wrote:
> Hi Daniel:
> On 2016年06月13日 21:06, Daniel Lezcano wrote:
>> On Tue, Jun 07, 2016 at 12:54:29PM +0800, Caesar Wang wrote:
>>> This series patches had been tested on rockchip inside kernel.
>>> In order to support the rk3399 SoC timer and turn off interrupts and IPIs to
>>> save power in idle.
>> For my personnal information, are the arch_timer in the same power domain
>> than the CPU ? IOW, what is the 'always-on' property in the DT ?
> Yes. In our SoC design, all arch (generic) timer in the same power
> domain of CPU core. So if one CPU core power down, the arch (generic)
> timer will lose it's state and stop working.
> While rk timer maybe in peri power domain or pmu power domain, so the
> timer will still work when CPU power down.
>
> But before RK3399, all SoCs with CPU power domain, do not support auto
> power down while cpu idle. So the arch timer can be seem as always on,
> i.e. we don't need a broadcast timer at all.
>
>>> Okay, it still works bootup on rk3288/other SoCs, even though many socs
>>> hasn't used
>>> the broadcast timer.
>> Yes, unfortunately the SoC design on rk3288 and the previous ones do not
>> allow to use a cpuidle driver with cpu/cluster power down, so obviously the
>> broadcast timer is pointless on these boards :)
>>
> You are right.
>
>>> History version:
>>> v1:
>>> https://lkml.org/lkml/2016/5/25/186
>>>
>>> Easy to test for my borad.
>>> localhost / # cat /proc/interrupts
>>> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
>>> 1: 0 0 0 0 0 0 GICv3 29 Edge arch_timer
>>> ...
>>> 5: 0 0 0 0 0 0 GICv3 113 Level rk_timer
>>> ..
>>>
>>> localhost / # cat /proc/timer_list | grep event_handler
>>> get "event_handler: hrtimer_interrupt"
>>> event_handler: tick_handle_oneshot_broadcast
>>> event_handler: hrtimer_interrupt
>> What are you trying to demonstrate here ? There are no interrupts for both
>> arch_timer and rk_timer.
My god!! let's forget it now!
Sorry for forgetting what happened.
---
Re-picked them up for my board since I'm doing other things to run a
single cpu.
localhost / # cat /proc/interrupts
CPU0
1: 0 GICv3 29 Edge arch_timer
2: 807 GICv3 30 Edge arch_timer
5: 712 GICv3 113 Level rk_timer
....
> I don't know. Maybe Caesar do something wrong :(
> This is my output:
> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
>
> ...
> 2: 2911 1967 1588 1608 1295 1606
> GICv3 30 Edge arch_timer
> 5: 578 637 684 626 161 165
> GICv3 113 Level rk_timer
>
>
>
--
caesar wang | software engineer | wxt@rock-chip.com
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web