From mboxrd@z Thu Jan 1 00:00:00 1970 From: huangtao@rock-chips.com (Huang Tao) Date: Fri, 29 Aug 2014 19:44:33 +0800 Subject: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc In-Reply-To: <20140829112242.GC21473@leverpostej> References: <1409190017-12656-1-git-send-email-kever.yang@rock-chips.com> <20140828091758.GB14650@leverpostej> <20140828151121.GM14650@leverpostej> <53FFEE40.3010001@rock-chips.com> <20140829112242.GC21473@leverpostej> Message-ID: <540067A1.6090005@rock-chips.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, ? 2014?08?29? 19:22, Mark Rutland ??: >> ? 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. > > Okay, so this patch is wrong as I expected. Thank you! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Huang Tao Subject: Re: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc Date: Fri, 29 Aug 2014 19:44:33 +0800 Message-ID: <540067A1.6090005@rock-chips.com> References: <1409190017-12656-1-git-send-email-kever.yang@rock-chips.com> <20140828091758.GB14650@leverpostej> <20140828151121.GM14650@leverpostej> <53FFEE40.3010001@rock-chips.com> <20140829112242.GC21473@leverpostej> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20140829112242.GC21473@leverpostej> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Mark Rutland Cc: Kever Yang , "heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org" , "dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "sonnyrao-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org" , "addy.ke-TNX95d0MmH7DzftRWevZcw@public.gmane.org" , "cf-TNX95d0MmH7DzftRWevZcw@public.gmane.org" , "xjq-TNX95d0MmH7DzftRWevZcw@public.gmane.org" , "wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org" , "lyz-TNX95d0MmH7DzftRWevZcw@public.gmane.org" , "hj-TNX95d0MmH7DzftRWevZcw@public.gmane.org" , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , Russell King , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Lorenzo Pieralisi List-Id: devicetree@vger.kernel.org Hi, =E5=9C=A8 2014=E5=B9=B408=E6=9C=8829=E6=97=A5 19:22, Mark Rutland =E5=86= =99=E9=81=93: >> =E5=9C=A8 2014=E5=B9=B408=E6=9C=8828=E6=97=A5 23:11, Mark Rutland =E5= =86=99=E9=81=93: >>> To clarify: if there are low power states that the CPU can enter wh= ere >>> 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.=20 > >> 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, th= ere > is no reason not to add it now. > >>> A more general approach would be to enable the broadcast hrtimer fo= r >>> 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. > > Okay, so this patch is wrong as I expected. Thank you! -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753318AbaH2Los (ORCPT ); Fri, 29 Aug 2014 07:44:48 -0400 Received: from regular1.263xmail.com ([211.150.99.137]:52561 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753250AbaH2Lop (ORCPT ); Fri, 29 Aug 2014 07:44:45 -0400 X-Greylist: delayed 31074 seconds by postgrey-1.27 at vger.kernel.org; Fri, 29 Aug 2014 07:44:43 EDT X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-ABS-CHECKED: 4 X-KSVirus-check: 0 X-RL-SENDER: huangtao@rock-chips.com X-FST-TO: huangtao@rock-chips.com X-SENDER-IP: 127.0.0.1 X-LOGIN-NAME: huangtao@rock-chips.com X-UNIQUE-TAG: <76f9beab9c951148a205946107f65124> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 1 Message-ID: <540067A1.6090005@rock-chips.com> Date: Fri, 29 Aug 2014 19:44:33 +0800 From: Huang Tao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Mark Rutland CC: Kever Yang , "heiko@sntech.de" , "dianders@chromium.org" , "sonnyrao@chromium.org" , "addy.ke@rock-chips.com" , "cf@rock-chips.com" , "xjq@rock-chips.com" , "wulf@rock-chips.com" , "lyz@rock-chips.com" , "hj@rock-chips.com" , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , Russell King , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Lorenzo Pieralisi Subject: Re: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc References: <1409190017-12656-1-git-send-email-kever.yang@rock-chips.com> <20140828091758.GB14650@leverpostej> <20140828151121.GM14650@leverpostej> <53FFEE40.3010001@rock-chips.com> <20140829112242.GC21473@leverpostej> In-Reply-To: <20140829112242.GC21473@leverpostej> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, 在 2014年08月29日 19:22, Mark Rutland 写道: >> 在 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. > > Okay, so this patch is wrong as I expected. Thank you!