All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
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 12:22:42 +0100	[thread overview]
Message-ID: <20140829112242.GC21473@leverpostej> (raw)
In-Reply-To: <53FFEE40.3010001@rock-chips.com>

On Fri, Aug 29, 2014 at 04:06:40AM +0100, Huang Tao wrote:
> Hi, Mark:

Hi,

> ? 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.

Sure, but that's a Linux implementation detail rather than a fixed
property of the hardware. Given those states exist, the "always-on"
property is not appropriate.

> We do not implement cpuidle to power off CPU. Do you think we should
> introduce a broadcast timer?

If one is present, yes. 

> On our early kernel, I never see any interrupt on a broadcast timer
> (yes, we implement it with a external timer).

That's fine; Linux doesn't need to use it just yet. However, when we
want to use low power states later, it will be necessary to enable
placing all CPUS into a low power state.

If your external timer is already supported by an existing driver, there
is no reason not to add it now.

> > 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.

Patches welcome.

I also think it would make sense to enable this for arm.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
To: Huang Tao <huangtao-TNX95d0MmH7DzftRWevZcw@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
	<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 12:22:42 +0100	[thread overview]
Message-ID: <20140829112242.GC21473@leverpostej> (raw)
In-Reply-To: <53FFEE40.3010001-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Fri, Aug 29, 2014 at 04:06:40AM +0100, Huang Tao wrote:
> Hi, Mark:

Hi,

> 在 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.

Sure, but that's a Linux implementation detail rather than a fixed
property of the hardware. Given those states exist, the "always-on"
property is not appropriate.

> We do not implement cpuidle to power off CPU. Do you think we should
> introduce a broadcast timer?

If one is present, yes. 

> On our early kernel, I never see any interrupt on a broadcast timer
> (yes, we implement it with a external timer).

That's fine; Linux doesn't need to use it just yet. However, when we
want to use low power states later, it will be necessary to enable
placing all CPUS into a low power state.

If your external timer is already supported by an existing driver, there
is no reason not to add it now.

> > 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.

Patches welcome.

I also think it would make sense to enable this for arm.

Thanks,
Mark.
--
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: Mark Rutland <mark.rutland@arm.com>
To: Huang Tao <huangtao@rock-chips.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 <Lorenzo.Pieralisi@arm.com>
Subject: Re: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc
Date: Fri, 29 Aug 2014 12:22:42 +0100	[thread overview]
Message-ID: <20140829112242.GC21473@leverpostej> (raw)
In-Reply-To: <53FFEE40.3010001@rock-chips.com>

On Fri, Aug 29, 2014 at 04:06:40AM +0100, Huang Tao wrote:
> Hi, Mark:

Hi,

> 在 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.

Sure, but that's a Linux implementation detail rather than a fixed
property of the hardware. Given those states exist, the "always-on"
property is not appropriate.

> We do not implement cpuidle to power off CPU. Do you think we should
> introduce a broadcast timer?

If one is present, yes. 

> On our early kernel, I never see any interrupt on a broadcast timer
> (yes, we implement it with a external timer).

That's fine; Linux doesn't need to use it just yet. However, when we
want to use low power states later, it will be necessary to enable
placing all CPUS into a low power state.

If your external timer is already supported by an existing driver, there
is no reason not to add it now.

> > 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.

Patches welcome.

I also think it would make sense to enable this for arm.

Thanks,
Mark.

  reply	other threads:[~2014-08-29 11:22 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
2014-08-29  3:06       ` Huang Tao
2014-08-29  3:06       ` Huang Tao
2014-08-29 11:22       ` Mark Rutland [this message]
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=20140829112242.GC21473@leverpostej \
    --to=mark.rutland@arm.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.