From patchwork Thu Aug 22 03:13:30 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wang Dongsheng-B40534 X-Patchwork-Id: 268932 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [IPv6:::1]) by ozlabs.org (Postfix) with ESMTP id 2B8BA2C00E4 for ; Thu, 22 Aug 2013 13:14:09 +1000 (EST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "MSIT Machine Auth CA 2" (not verified)) by ozlabs.org (Postfix) with ESMTPS id E7F532C00C6 for ; Thu, 22 Aug 2013 13:13:42 +1000 (EST) Received: from mail176-db8-R.bigfish.com (10.174.8.235) by DB8EHSOBE034.bigfish.com (10.174.4.97) with Microsoft SMTP Server id 14.1.225.22; Thu, 22 Aug 2013 03:13:37 +0000 Received: from mail176-db8 (localhost [127.0.0.1]) by mail176-db8-R.bigfish.com (Postfix) with ESMTP id 0C746D80169; Thu, 22 Aug 2013 03:13:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: 7 X-BigFish: VS7(z52aesz98dI9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h8275bh8275dh1de097hz2dh2a8h839h8e2h8e3h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5hbe9i1155h) Received: from mail176-db8 (localhost.localdomain [127.0.0.1]) by mail176-db8 (MessageSwitch) id 1377141215741246_24007; Thu, 22 Aug 2013 03:13:35 +0000 (UTC) Received: from DB8EHSMHS002.bigfish.com (unknown [10.174.8.239]) by mail176-db8.bigfish.com (Postfix) with ESMTP id B11FD160049; Thu, 22 Aug 2013 03:13:35 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB8EHSMHS002.bigfish.com (10.174.4.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 22 Aug 2013 03:13:35 +0000 Received: from 039-SN2MPN1-021.039d.mgd.msft.net ([169.254.1.10]) by 039-SN1MMR1-002.039d.mgd.msft.net ([10.84.1.15]) with mapi id 14.03.0146.002; Thu, 22 Aug 2013 03:13:31 +0000 From: Wang Dongsheng-B40534 To: Wood Scott-B07421 , Kumar Gala Subject: RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state Thread-Topic: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state Thread-Index: AQHOmlkO4Crz0HAYp0u5/qpWfUxqHpmXq6AAgABhN4CAA8gewIABcY4AgAIa/vA= Date: Thu, 22 Aug 2013 03:13:30 +0000 Message-ID: References: <1376637789-27330-1-git-send-email-dongsheng.wang@freescale.com> <83499AB5-DCE7-407D-AEC1-B2493D1D38BE@kernel.crashing.org> <1376671853.31636.252.camel@snotra.buserror.net> <1376959116.31636.392.camel@snotra.buserror.net> In-Reply-To: <1376959116.31636.392.camel@snotra.buserror.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.208.117] MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "linuxppc-dev@lists.ozlabs.org" , Zhao Chenhui-B35336 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.16rc2 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" > -----Original Message----- > From: Wood Scott-B07421 > Sent: Tuesday, August 20, 2013 8:39 AM > To: Wang Dongsheng-B40534 > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter > altivec idle state > > On Sun, 2013-08-18 at 21:53 -0500, Wang Dongsheng-B40534 wrote: > > Thanks for your feedback. > > > > > -----Original Message----- > > > From: Wood Scott-B07421 > > > Sent: Saturday, August 17, 2013 12:51 AM > > > To: Kumar Gala > > > Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org > > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically > enter > > > altivec idle state > > > > > > On Fri, 2013-08-16 at 06:02 -0500, Kumar Gala wrote: > > > > On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote: > > > > > > > > > From: Wang Dongsheng > > > > > > > > > > Each core's AltiVec unit may be placed into a power savings mode > > > > > by turning off power to the unit. Core hardware will > automatically > > > > > power down the AltiVec unit after no AltiVec instructions have > > > > > executed in N cycles. The AltiVec power-control is triggered by > > > hardware. > > > > > > > > > > Signed-off-by: Wang Dongsheng > > > > > > > > Why treat this as a idle HW governor vs just some one time setup at > > > boot of the time delay? > > > > > > It is being done as one-time setup, despite the function name. > > > > > > Maybe it should be moved into __setup/restore_cpu_e6500 (BTW, we > really > > > should refactor those to reduce duplication) with the timebase bit > > > number hardcoded rather than a time in us. > > > > > The frequency of the different platforms timebase is not the same. > > It's close enough. Remember, this number is a vague initial guess, not > something that's been carefully calibrated. Though, it would make it > harder to substitute the number with one that's been more carefully > calibrated... but wouldn't different chips possibly have different > optimal delays anyway? > > > If we use it, we need to set different timebase bit on each platform. > > That is why I did not put the code in __setup/restore_cpu_e6500, I need > > use tb_ticks_per_usec to get timebase bit. So we only need to set a > time > > for each platform, and not set different timebase bit. > > It just seems wrong to have an ad-hoc mechanism for running > core-specific code when we have cputable... If we really need this, > maybe we should add a "cpu_setup_late" function pointer. > > With your patch, when does the power management register get set when > hot plugging a cpu? > Um.. I don't deal with this situation. I will fix it. __setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, not on each cpu. I think this is a bug. Fix code: > > > As for the PVR check, the upstream kernel doesn't need to care about > > > rev1, so knowing it's an e6500 is good enough. > > > > > But AltiVec idle & PW20 cannot work on rev1 platform. > > We didn't have to deal with it? > > Upstream does not run on rev1. > :), But already have customers in the use of rev1. Why we don't need to care about that? diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 2cfed9e..2a9a718 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -603,6 +603,9 @@ __secondary_start: /* Set thread priority to MEDIUM */ HMT_MEDIUM +#ifdef CONFIG_PPC_BOOK3E + bl call_setup_cpu /* Call setup_cpu for this CPU */ +#endif /* Initialize the kernel stack */ LOAD_REG_ADDR(r3, current_set) sldi r28,r24,3 /* get current_set[cpu#] */ diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index b863b87..7d84bf4 100644 --- a/arch/powerpc/kernel/misc_64.S +++ b/arch/powerpc/kernel/misc_64.S @@ -55,6 +55,17 @@ _GLOBAL(call_handle_irq) mtlr r0 blr +_GLOBAL(call_setup_cpu) + LOAD_REG_ADDR(r4, cur_cpu_spec) + ld r4, 0(r4) + ld r5, CPU_SPEC_SETUP(r4) + + cmpwi 0, r5, 0 + beqlr + ld r5, 0(r5) + mtctr r5 + bctr + .section ".toc","aw" PPC64_CACHES: .tc ppc64_caches[TC],ppc64_caches