From: huangtao@rock-chips.com (Huang Tao)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc
Date: Fri, 29 Aug 2014 11:06:40 +0800 [thread overview]
Message-ID: <53FFEE40.3010001@rock-chips.com> (raw)
In-Reply-To: <20140828151121.GM14650@leverpostej>
Hi, Mark:
? 2014?08?28? 23:11, Mark Rutland ??:
> To clarify: if there are low power states that the CPU can enter where
> we lose state, then this patch isn't correct.
Right now, the software of RK3288 SoC only support CPU hotplug
(cpu_on/off) and power off all CPUs on suspend.
We do not implement cpuidle to power off CPU. Do you think we should
introduce a broadcast timer?
On our early kernel, I never see any interrupt on a broadcast timer
(yes, we implement it with a external timer).
>
> A more general approach would be to enable the broadcast hrtimer for
> arm, as has been done for arm64.
Yes. I think it should be done by arm framework.
>
> See commit 5d1638acb9f6 (tick: Introduce hrtimer based broadcast) which
> introduced the broadcast hrtimer, and commit 9358d755bd5c (arm64:
> kernel: initialize broadcast hrtimer based clock event device) which
> added the requisite plumbing for arm64.
WARNING: multiple messages have this Message-ID (diff)
From: Huang Tao <huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org"
<heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
"dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org"
<dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org"
<sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org"
<addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"cf-TNX95d0MmH7DzftRWevZcw@public.gmane.org"
<cf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"xjq-TNX95d0MmH7DzftRWevZcw@public.gmane.org"
<xjq-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org"
<wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"lyz-TNX95d0MmH7DzftRWevZcw@public.gmane.org"
<lyz-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"hj-TNX95d0MmH7DzftRWevZcw@public.gmane.org"
<hj-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <Pawel.Moll-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org
Subject: Re: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc
Date: Fri, 29 Aug 2014 11:06:40 +0800 [thread overview]
Message-ID: <53FFEE40.3010001@rock-chips.com> (raw)
In-Reply-To: <20140828151121.GM14650@leverpostej>
Hi, Mark:
在 2014年08月28日 23:11, Mark Rutland 写道:
> To clarify: if there are low power states that the CPU can enter where
> we lose state, then this patch isn't correct.
Right now, the software of RK3288 SoC only support CPU hotplug
(cpu_on/off) and power off all CPUs on suspend.
We do not implement cpuidle to power off CPU. Do you think we should
introduce a broadcast timer?
On our early kernel, I never see any interrupt on a broadcast timer
(yes, we implement it with a external timer).
>
> A more general approach would be to enable the broadcast hrtimer for
> arm, as has been done for arm64.
Yes. I think it should be done by arm framework.
>
> See commit 5d1638acb9f6 (tick: Introduce hrtimer based broadcast) which
> introduced the broadcast hrtimer, and commit 9358d755bd5c (arm64:
> kernel: initialize broadcast hrtimer based clock event device) which
> added the requisite plumbing for arm64.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Huang Tao <huangtao@rock-chips.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: Kever Yang <kever.yang@rock-chips.com>,
"heiko@sntech.de" <heiko@sntech.de>,
"dianders@chromium.org" <dianders@chromium.org>,
"sonnyrao@chromium.org" <sonnyrao@chromium.org>,
"addy.ke@rock-chips.com" <addy.ke@rock-chips.com>,
"cf@rock-chips.com" <cf@rock-chips.com>,
"xjq@rock-chips.com" <xjq@rock-chips.com>,
"wulf@rock-chips.com" <wulf@rock-chips.com>,
"lyz@rock-chips.com" <lyz@rock-chips.com>,
"hj@rock-chips.com" <hj@rock-chips.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <Pawel.Moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Russell King <linux@arm.linux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
lorenzo.pieralisi@arm.com
Subject: Re: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc
Date: Fri, 29 Aug 2014 11:06:40 +0800 [thread overview]
Message-ID: <53FFEE40.3010001@rock-chips.com> (raw)
In-Reply-To: <20140828151121.GM14650@leverpostej>
Hi, Mark:
在 2014年08月28日 23:11, Mark Rutland 写道:
> To clarify: if there are low power states that the CPU can enter where
> we lose state, then this patch isn't correct.
Right now, the software of RK3288 SoC only support CPU hotplug
(cpu_on/off) and power off all CPUs on suspend.
We do not implement cpuidle to power off CPU. Do you think we should
introduce a broadcast timer?
On our early kernel, I never see any interrupt on a broadcast timer
(yes, we implement it with a external timer).
>
> A more general approach would be to enable the broadcast hrtimer for
> arm, as has been done for arm64.
Yes. I think it should be done by arm framework.
>
> See commit 5d1638acb9f6 (tick: Introduce hrtimer based broadcast) which
> introduced the broadcast hrtimer, and commit 9358d755bd5c (arm64:
> kernel: initialize broadcast hrtimer based clock event device) which
> added the requisite plumbing for arm64.
next prev parent reply other threads:[~2014-08-29 3:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-28 1:40 [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc Kever Yang
2014-08-28 1:40 ` Kever Yang
2014-08-28 1:40 ` Kever Yang
2014-08-28 9:17 ` Mark Rutland
2014-08-28 9:17 ` Mark Rutland
2014-08-28 9:17 ` Mark Rutland
2014-08-28 15:11 ` Mark Rutland
2014-08-28 15:11 ` Mark Rutland
2014-08-28 15:11 ` Mark Rutland
2014-08-29 0:35 ` Kever Yang
2014-08-29 0:35 ` Kever Yang
2014-08-29 0:35 ` Kever Yang
2014-08-29 3:06 ` Huang Tao [this message]
2014-08-29 3:06 ` Huang Tao
2014-08-29 3:06 ` Huang Tao
2014-08-29 11:22 ` Mark Rutland
2014-08-29 11:22 ` Mark Rutland
2014-08-29 11:22 ` Mark Rutland
2014-08-29 11:44 ` Huang Tao
2014-08-29 11:44 ` Huang Tao
2014-08-29 11:44 ` Huang Tao
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=53FFEE40.3010001@rock-chips.com \
--to=huangtao@rock-chips.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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.