All of lore.kernel.org
 help / color / mirror / Atom feed
From: Caesar Wang <wxt@rock-chips.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: "Huang, Tao" <huangtao@rock-chips.com>,
	Heiko Stuebner <heiko@sntech.de>,
	dianders@chromium.org, briannorris@google.com,
	smbarber@google.com, linux-rockchip@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	cf@rock-chips.com, devicetree@vger.kernel.org,
	Xing Zheng <zhengxing@rock-chips.com>,
	Jianqun Xu <jay.xu@rock-chips.com>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Brian Norris <briannorris@chromium.org>,
	linux-kernel@vger.kernel.org,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Rob Herring <robh+dt@kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399
Date: Tue, 14 Jun 2016 17:12:12 +0800	[thread overview]
Message-ID: <575FCA6C.1010405@rock-chips.com> (raw)
In-Reply-To: <575F814C.104@rock-chips.com>


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

WARNING: multiple messages have this Message-ID (diff)
From: wxt@rock-chips.com (Caesar Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399
Date: Tue, 14 Jun 2016 17:12:12 +0800	[thread overview]
Message-ID: <575FCA6C.1010405@rock-chips.com> (raw)
In-Reply-To: <575F814C.104@rock-chips.com>


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 at rock-chip.com

  reply	other threads:[~2016-06-14  9:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07  4:54 [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer for rk3399 Caesar Wang
2016-06-07  4:54 ` Caesar Wang
2016-06-07  4:54 ` [PATCH v2 1/4] dt-bindings: document rk3399 rk-timer bindings Caesar Wang
2016-06-07  4:54   ` Caesar Wang
2016-06-07  4:54 ` [PATCH v2 2/4] clocksource: rockchip: add dynamic irq flag to the timer Caesar Wang
2016-06-07  4:54   ` Caesar Wang
2016-06-07  4:54 ` [PATCH v2 3/4] clocksource: rockchip: add support for rk3399 SoC Caesar Wang
2016-06-07  4:54   ` Caesar Wang
2016-06-07  4:54 ` [PATCH v2 4/4] arm64: dts: rockchip: add rktimer device node for rk3399 Caesar Wang
2016-06-07  4:54   ` Caesar Wang
     [not found] ` <1465275273-22076-1-git-send-email-wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-06-13 13:06   ` [PATCH v2 0/4] clocksource: rockchip/timer: Support rktimer " Daniel Lezcano
2016-06-13 13:06     ` Daniel Lezcano
2016-06-13 13:06     ` Daniel Lezcano
2016-06-14  4:00     ` Huang, Tao
2016-06-14  4:00       ` Huang, Tao
2016-06-14  9:12       ` Caesar Wang [this message]
2016-06-14  9:12         ` Caesar Wang
2016-06-16 14:26 ` Daniel Lezcano
2016-06-16 14:26   ` Daniel Lezcano
2016-06-17  1:08   ` Caesar Wang
2016-06-17  1:08     ` Caesar Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=575FCA6C.1010405@rock-chips.com \
    --to=wxt@rock-chips.com \
    --cc=briannorris@chromium.org \
    --cc=briannorris@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=cf@rock-chips.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=heiko@sntech.de \
    --cc=huangtao@rock-chips.com \
    --cc=jay.xu@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    --cc=smbarber@google.com \
    --cc=tglx@linutronix.de \
    --cc=will.deacon@arm.com \
    --cc=yamada.masahiro@socionext.com \
    --cc=zhengxing@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.