Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Alison Wang <alison.wang@nxp.com>
To:     Thomas Gleixner <tglx@linutronix.de>,
        Russell King - ARM Linux <linux@arm.linux.org.uk>,
        Leo Li <leoyang.li@nxp.com>
CC:     Arnd Bergmann <arnd@arndb.de>,
        LAK <linux-arm-kernel@lists.infradead.org>,
        "mark.rutland@arm.com" <mark.rutland@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Huan Wang <alison.wang@freescale.com>,
        "Daniel Lezcano" <daniel.lezcano@linaro.org>,
        John Stultz <john.stultz@linaro.org>
Subject: RE: [PATCH] arm: kernel: utilize hrtimer based broadcast
Thread-Topic: [PATCH] arm: kernel: utilize hrtimer based broadcast
Thread-Index: AQHRJ+n4K0E1kuUBN0uZtCJSriMvb57gLndwgABOtwCAAbPGAIAGEEOAgASp34CERWkAEA==
Date:   Fri, 1 Dec 2017 03:33:49 +0000
Message-ID: <VI1PR04MB3039EB80F5468E55263ABECBF4390@VI1PR04MB3039.eurprd04.prod.outlook.com>
References: <1437124312-44700-1-git-send-email-b18965@freescale.com>
 <20151027081834.GB1425@svinekod>
 <DB3PR04MB07407D83CC5F8F5F19A7207F4FB0@DB3PR04MB074.eurprd04.prod.outlook.com>
 <4875455.lvoc6XpkZc@wuerfel> <alpine.DEB.2.11.1512291449380.28591@nanos>
 <20160102102955.GP8644@n2100.arm.linux.org.uk>
 <alpine.DEB.2.11.1601051039320.3689@nanos>
In-Reply-To: <alpine.DEB.2.11.1601051039320.3689@nanos>
Accept-Language: zh-CN, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 96358a1c-8b85-45e2-db7a-08d5386c5668
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2017 03:33:49.8410
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0401MB1701
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi, Russell,

> On Sat, 2 Jan 2016, Russell King - ARM Linux wrote:
> > On Tue, Dec 29, 2015 at 02:54:10PM +0100, Thomas Gleixner wrote:
> > > I have no real opinion about that patch. It does no harm to
> > > unconditionally setup the hrtimer based broadcast even if it's never
> used.
> > >
> > > Up to the arch maintainer to decide.
> >
> > That's really not fair to keep shovelling these kinds of decisions
> > onto architecture maintainers without any kind of explanation about
> > how an architecture maintainer should make such a decision.
> >
> > Do I roll a 6-face dice, and if it gives an odd number, I apply this
> > patch, otherwise I reject it?
> >
> > Is there a technical basis for making the decision?  If so, please
> > explain what the technical arguments are against having or not having
> > this change.
>=20
> The hrtimer based broadcast device is used when you have per cpu timers
> which stop in deeper power states, but you have no other timer hardware o=
n
> the chip which can backup the per cpu timer in deep power states. The
> trick is that it emulates a timer hardware via a hrtimer and then tells
> the cpu idle code not to go into deep power states on the cpu which owns
> that hrtimer. All other cpus can go as deep as they want and still get
> woken up.
>=20
> The only downside of adding this unconditionally is extra code in case
> that it is not needed on a particular platform.
>=20
> Hope that helps.
>=20
[Alison Wang] What's your opinion about this explanation? Is this patch acc=
eptable?

Best Regards,
Alison Wang

From 1585560690256904713@xxx Fri Dec 01 06:08:27 +0000 2017
X-GM-THRID: 1585560690256904713
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread