Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932469AbbHCVTB (ORCPT ); Mon, 3 Aug 2015 17:19:01 -0400 Received: from mail-bl2on0133.outbound.protection.outlook.com ([65.55.169.133]:26048 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932378AbbHCVS7 (ORCPT ); Mon, 3 Aug 2015 17:18:59 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=scottwood@freescale.com; Message-ID: <1438636720.2097.63.camel@freescale.com> Subject: Re: [PATCH 2/3] PowerPC/mpc85xx: Add hotplug support on E5500 and E500MC cores From: Scott Wood To: Chenhui Zhao CC: , , , Tang Yuantian , Date: Mon, 3 Aug 2015 16:18:40 -0500 In-Reply-To: <1438602724.7515.3@remotesmtp.freescale.net> References: <1438334444-31919-1-git-send-email-b29983@freescale.com> <1438334444-31919-2-git-send-email-b29983@freescale.com> <1438388082.19345.85.camel@freescale.com> <1438602724.7515.3@remotesmtp.freescale.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.0-fta1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:448:8100:f9f:12bf:48ff:fe84:c9a0] X-ClientProxiedBy: BY2PR07CA046.namprd07.prod.outlook.com (10.141.251.21) To BN3PR03MB1478.namprd03.prod.outlook.com (25.163.35.141) X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1478;2:F6nQGe2qbxXmrx+04/rrC5+nPmu08bWBKGaRHyQq628ehoqmkHoZctgrLSul2PeLDA/QYESc+pzwQBYn3+Un1F5X2ipfV4V7A/WDVUD9NxArxq/jLNvgwlp0UhKhg2DrDnwyaKn0+90vdmMKFnxUdCB2gXgmaQXnOksTH6Bx4G0=;3:tpx0lz5TX59FnWlBPWMKsUFWjJtVaU9BqnGeg4qpO3va4wYg6tn+T7XLcMxo6F8RZog0N/HhPAMO9PFYswLveexNkx0H/sejiTu8tTbLRBbXYzILOz0mJf+LHa4Q9CGIdwYBQgL4lQxRCJzaPio3ow==;25:rRNuyyfY/3qpXumJIL2CHr1T/nEVyvPWBQZhk1WQiUdUCHmOD1NtUZ3hDiV5HePUOoQjajCD0sW8i0CdUV2w6I7WhaSbcNhSjMVj3efbuLcqCmTzydRGBWXu8KoTSfKxjnA+K+HeuwB/MhNfGE+zk7KBFpjMDFjTE6rfJt7qqUhIzytsHVMlMLpR5LjrG/TfGrBZtfdruw/gz9/Se+WOvjYjCZ46DxZu9uAdzVq8R8zKZpRFPOgIaivj9oWb4S8AHX/UM1Et7ZP5fMTe54KnTw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1478; X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1478;20:J87yLVXJgxOxrYpQ8h9lBFIX37HR+9zEbE6t62B26V9muW7zNdMgRIalJCBz504uzC42zHfKXBeOOxo6wX5wR10kR5GAH1pPxAgoHc9uxBYbfA7sIeF9NkFi3zjrrP4zcdI4tLN2Ez8uXOi2hYHTzd+J6MJbXn7x1hbmCgtw31mUUOEceXwPwz6WhffAGT1SLifyiCLOGNbHdJe63r+UzlwOx1RApqfpqOC137W6q8tGLuShyYZaZZd3FZDImVaPA43pZsvtMZn8G4p5VLlJmpQo1Qqjv0r96W3TbsTBzMoj56VkPCVM+4ihLgvOnHIJyZv//hFwn7TRK5BjptXIlX/r4TPKnno8KKBL4ZApP/XCO+TN5mm3COHEyxDd1Km09L3PGYRsCPnt8wxB5I1Sqkst+QTi/oNeUcrGEF7HcvuJ0+1mmTVf/0ULOI8Ib94VtcwD/S9REAROukBUJLeGRgcWwcaXMXyvw1ZxqyaB+3ertmS8BhZyT2CaV1C3gJPR;4:xwzkNbcmC5gJGDpjbgIeMYg0KYInaymTczxSWVdIBqY/3Faiw4tE7tBGAP0ScAvQkntAu+7sTV0HA1NpS0atCIhMtmLDcgTL/3gFDFWPBDRxX1Rektag9X1ONRUvYPEjijXD/ncDBnVqkEHFuR3bT8COV8JP66ifWryDAWP8vIIBUv4Ja/s17wLWprUaoRaQBv0ytkpwZA0yDW5AePQlSCBtXt0xCaoEFAKdER4/7reRq+Jdq/nzLCWMiO2mkGgV2KW29uZcIaIPw7YjpOcLt7Y+488iP/QMu/19JuM0hqI= BN3PR03MB1478: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BN3PR03MB1478;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1478; X-Forefront-PRVS: 0657D528EC X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6009001)(377454003)(189002)(377424004)(24454002)(199003)(122386002)(110136002)(103116003)(5001960100002)(77156002)(23676002)(101416001)(105586002)(4001540100001)(97736004)(46102003)(92566002)(19580405001)(42186005)(93886004)(64706001)(189998001)(5001860100001)(86362001)(40100003)(5820100001)(19580395003)(47776003)(87976001)(62966003)(5001920100001)(2950100001)(76176999)(81156007)(5001830100001)(50466002)(575784001)(106356001)(68736005)(50986999)(77096005)(33646002)(4001450100002)(36756003)(50226001)(99106002)(3826002)(5001840100002);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR03MB1478;H:[IPv6:2601:448:8100:f9f:12bf:48ff:fe84:c9a0];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAzTUIxNDc4OzIzOnpzOUpTVHpESStITFphSzhuL3kxbm5haE5C?= =?utf-8?B?alBKd1VtdjVUTEI3QlJFN3BHL1IzS1ZiMkhKRWpiTFNaamEvemdWWUQxN3F1?= =?utf-8?B?K3ZuWkhPLytCMjlzMzRtZE5vN3k4ZkhRUVY5RWtMLzAyN2xaTGNnclE0SDFs?= =?utf-8?B?QnNDTXRKdEJsNk8zYkxKM1JmOEJYd2crd25ENGZaKzNMUURCTnkySFhBRUhX?= =?utf-8?B?dEUycnN4a1hUK1VKUXZPRGNSSUpqemhuNGRjbXdSRDVGSThlVTlxb0lTVFJD?= =?utf-8?B?YVZyRFJxc2dieHVuRnhQL0crU1RJRzBxb1JWTnI1d0lGWThLNXBNNmpGVFFv?= =?utf-8?B?VUtjUDJTeHp2cFYwK2hNVzFEZEY4NHNUQ3I0ZytFMEwzQVJCOEY0cXFTZDJW?= =?utf-8?B?MkVzVUF2dm00cWZMaDRVeUJlUmRuVXZUZlBzajNibG1vN0VLbmJvSml0YWR0?= =?utf-8?B?T1N4cTZCTEZBSm45ciszOTZwc3RDY2JQV2NpUDVOTWIwWXEzTE5iOFZEaUJ2?= =?utf-8?B?d2pPbEpRZnhjcCtUQzlGT21Hem1ucWdZY0lRMVB4TWdNWUczTWFrYWt5QUhw?= =?utf-8?B?TklvRFhwMnIwandLSEtDU2tlRjU4d0gvNWZveG5zOWdVeTlQMmkzaTZVTlFz?= =?utf-8?B?ZHJCWEtkZkIyeDVwMi9YUmU2YnlmRVNkVEdxTzU5ZHR2ZTE3Tm5sQmhkWkxW?= =?utf-8?B?OU1hUUZqK25TemZIMWxkYWlMemFibTg3L2NOZTFaUEQ1T1RBUnFreFRnbWht?= =?utf-8?B?TXhiamY2dW5sWjUrb2NJcmN2Mzh0MFJuYm5FZ1FpOTQ1NjJjRDdjNlkwSlVZ?= =?utf-8?B?RkhPZXVZR3pOZGlEcnNEY1dEVzJpbEZiMi9xNWcwSVVJdGZDZ0Y4cFFBUjhr?= =?utf-8?B?TU5tenRiZ2RHbXhTbVFUMTNvUzNqQzF2aVd1U3lvWkUrMkEvOHJDOHFOckRO?= =?utf-8?B?Y2owOUxYdTBZK3IyRC8wRTRSOTdEdWRIUkk4MHVNYnNaWU9GT1lva3VvQy9q?= =?utf-8?B?Tk05amE4RkFlOFhjeDlWbk16ZjFsZ0dZalJ1MnduVzhKalVmQVVZWmphZHY0?= =?utf-8?B?Z1NNYXN1NDJicmpnUjFOYTVUbXFxV2I5UDU0WGx6Z2RDWEpENTJ3WndKbXVZ?= =?utf-8?B?THFNTWZsS1ZwNitSM1NPR3FSWUErZVQrcEdjcVFIOVpyYzBPcGl2emhZTStI?= =?utf-8?B?NHZZU21rWTZpZHhsa2tCWlUyc0N5ZjJVNW1qNTNScUN3eGFScXVtME5yL3U1?= =?utf-8?B?ZU9jUW8wSDVLeWY3NUloOEFKWUhTVjY3TWtrKzlJa2xnOStQcHYrMVFQcEJH?= =?utf-8?B?dlBTNzNWTXBncEhqZzFKYkwzb0V5V3hKSnFsZ2hkeStOOGNjY3JGVXViemFn?= =?utf-8?B?ZW5FZFh2VXY3RkdpOUgzTk9sb05xTHB2Ymg3cGowU1J4bHZVWDIwUytKN2VR?= =?utf-8?B?WExnNWhoNlhZbFlPWmFTL05TWkNBSUM1SEhReWJKb2s3Vytic0xDVS9WdWVG?= =?utf-8?B?eWRMN0piYnYxM2NqUXZqazVvRXRUTm1kVFFtc1NmZkxQMmtJRkJ5UHFOcS9T?= =?utf-8?B?WHNkNGpkNWVQSi9iUDE5TGVvK0wxZFp1ZXplSlhLNTB1WlFueFpJTDFzTUMy?= =?utf-8?B?MTZianpWTDgvZE1jWVZUTWo5RDNDOTZpU3VPZ1F5OHEyK3FTTnkvcXRHT1dQ?= =?utf-8?B?bk83ekRqdHl0dTJFYlVyZFVLbG5kblc0YnQwajg2YzVHNUJ3ZUVFM2hCRkxa?= =?utf-8?B?NnlySndxdUloTXdpNDFldz09?= X-Microsoft-Exchange-Diagnostics: 1;BN3PR03MB1478;5:hggKW9Yt6fT8yvusP19HuofJDwX/kTV63np4f+gZrOutvLZeoC0hSDwoLP4tjADxL421zzIYmfR9fQNs+v/a8OPgHlaHgFO1AcVe8MSsj/Gq/4dI4HKtQ9693tSgv1WAjEGSFYQnenxywrkaBdYrvg==;24:IzOVZC30/F+/WDJMy8pvFa8UZdEXoYHG0IG9jxconfTqINVS9vjnKQMPjG55PCa8GR0B2zzU01zJMjWMsBYeT0AW37+HbZZrBHaxumbvJpc=;20:nDrKq6y5E6mS1jI7ChmSpsuDSt2e4PsNmkTnJZsxIGhXG4MstKGLCEeYZL49pOV8fkWGkaX135V7N29G17R8pw== X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2015 21:18:55.1557 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1478 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7582 Lines: 223 [Added linuxppc-dev@lists.ozlabs.org. Besides that list being required for review of PPC patches, it feeds the patchwork that I use to track and apply patches.] On Mon, 2015-08-03 at 19:52 +0800, Chenhui Zhao wrote: > On Sat, Aug 1, 2015 at 8:14 AM, Scott Wood > wrote: > > On Fri, 2015-07-31 at 17:20 +0800, b29983@freescale.comwrote: > > > From: Tang Yuantian > > > > > > Freescale E500MC and E5500 core-based platforms, like P4080, T1040, > > > support disabling/enabling CPU dynamically. > > > This patch adds this feature on those platforms. > > > > > > Signed-off-by: Chenhui Zhao > > > Signed-off-by: Tang Yuantian > > > --- > > > arch/powerpc/Kconfig | 2 +- > > > arch/powerpc/include/asm/smp.h | 1 + > > > arch/powerpc/kernel/smp.c | 5 +++++ > > > arch/powerpc/platforms/85xx/smp.c | 39 > > > ++++++++++++++++++++++++++++++++---- > > > --- > > > 4 files changed, 39 insertions(+), 8 deletions(-) > > > > > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > > > index 5ef2711..dd9e252 100644 > > > --- a/arch/powerpc/Kconfig > > > +++ b/arch/powerpc/Kconfig > > > @@ -386,7 +386,7 @@ config SWIOTLB > > > config HOTPLUG_CPU > > > bool "Support for enabling/disabling CPUs" > > > depends on SMP && (PPC_PSERIES || \ > > > - PPC_PMAC || PPC_POWERNV || (PPC_85xx && !PPC_E500MC)) > > > + PPC_PMAC || PPC_POWERNV || FSL_SOC_BOOKE) > > > ---help--- > > > Say Y here to be able to disable and re-enable individual > > > CPUs at runtime on SMP machines. > > > > > > > > > diff --git a/arch/powerpc/include/asm/smp.h > > > b/arch/powerpc/include/asm/smp.h > > > index 825663c..bf37d17 100644 > > > --- a/arch/powerpc/include/asm/smp.h > > > +++ b/arch/powerpc/include/asm/smp.h > > > @@ -67,6 +67,7 @@ void generic_cpu_die(unsigned int cpu); > > > void generic_set_cpu_dead(unsigned int cpu); > > > void generic_set_cpu_up(unsigned int cpu); > > > int generic_check_cpu_restart(unsigned int cpu); > > > +int generic_check_cpu_dead(unsigned int cpu); > > > #endif > > > > > > #ifdef CONFIG_PPC64 > > > diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c > > > index ec9ec20..2cca27a 100644 > > > --- a/arch/powerpc/kernel/smp.c > > > +++ b/arch/powerpc/kernel/smp.c > > > @@ -454,6 +454,11 @@ int generic_check_cpu_restart(unsigned int cpu) > > > return per_cpu(cpu_state, cpu) == CPU_UP_PREPARE; > > > } > > > > > > +int generic_check_cpu_dead(unsigned int cpu) > > > +{ > > > + return per_cpu(cpu_state, cpu) == CPU_DEAD; > > > +} > > > > Is there a non-generic check_cpu_dead()? > > NO, just follow the name "generic_check_cpu_restart()". But it's not the same situation as generic_check_cpu_restart(). > > It gets open-coded in generic_cpu_die()... Either open-code it > > elsewhere, or > > call it check_cpu_dead() and use it everywhere there's a CPU_DEAD > > check. > > > > > > > + > > > static bool secondaries_inhibited(void) > > > { > > > return kvm_hv_mode_active(); > > > diff --git a/arch/powerpc/platforms/85xx/smp.c > > > b/arch/powerpc/platforms/85xx/smp.c > > > index 6811a5b..7f0dadb 100644 > > > --- a/arch/powerpc/platforms/85xx/smp.c > > > +++ b/arch/powerpc/platforms/85xx/smp.c > > > @@ -42,6 +42,7 @@ struct epapr_spin_table { > > > u32 pir; > > > }; > > > > > > +#ifdef CONFIG_HOTPLUG_CPU > > > static u64 timebase; > > > static int tb_req; > > > static int tb_valid; > > > @@ -111,7 +112,7 @@ static void mpc85xx_take_timebase(void) > > > local_irq_restore(flags); > > > } > > > > > > -#ifdef CONFIG_HOTPLUG_CPU > > > +#ifndef CONFIG_PPC_E500MC > > > static void e500_cpu_idle(void) > > > > What happens if we bisect to patch 1/3 and run this on e500mc? > > > > Please move the ifdef to that patch. > > OK. > > > > > > > > { > > > u32 tmp; > > > @@ -127,6 +128,7 @@ static void e500_cpu_idle(void) > > > mtmsr(tmp); > > > isync(); > > > } > > > +#endif > > > > > > static void qoriq_cpu_dying(void) > > > { > > > @@ -144,11 +146,30 @@ static void qoriq_cpu_dying(void) > > > > > > generic_set_cpu_dead(cpu); > > > > > > +#ifndef CONFIG_PPC_E500MC > > > e500_cpu_idle(); > > > +#endif > > > > > > while (1) > > > ; > > > } > > > + > > > +static void qoriq_real_cpu_die(unsigned int cpu) > > > > Real as opposed to...? > > It's hard to find a good name. :) There are too many cpu_die() functions as is, and adding cpu_dying makes it worse. Even just trying to come up with suggestions I've been having a hard time keeping track of which one goes in which ops struct. This problem goes beyond the 85xx code, to the ridiculous and undocumented distinction between cpu_die() and __cpu_die(). It wouldn't be so bad if each layer were self contained, rather than multiple layers being defined in the same file. I suggest keeping the existing convention whereby ppc_md.cpu_die ends in "_mach_cpu_die". Don't call anything "cpu_dying". I'd call qoriq_pm_ops->cpu_die something else (e.g. cpu_kill) even though it is in a separate file, just because of how confused and overused the name is elsewhere. > +{ > > > + int i; > > > + > > > + for (i = 0; i < 50000; i++) { > > > + if (generic_check_cpu_dead(cpu)) { > > > + qoriq_pm_ops->cpu_die(cpu); > > > +#ifdef CONFIG_PPC64 > > > + paca[cpu].cpu_start = 0; > > > +#endif > > > + return; > > > + } > > > + udelay(10); > > > + } > > > + pr_err("%s: CPU%d didn't die...\n", __func__, cpu); > > > +} > > > > Only 500ms timeout, versus 10sec in generic_cpu_die()? > > The process is fast. Maybe 10 second is too large. Is it fast 100% of the time? What if the CPU you intend to die is in a long critical section? What harm is there to having a longer timeout, similar to what other platforms use? > > > > > > #endif > > > > > > static inline void flush_spin_table(void *spin_table) > > > @@ -246,11 +267,7 @@ static int smp_85xx_kick_cpu(int nr) > > > spin_table = phys_to_virt(*cpu_rel_addr); > > > > > > local_irq_save(flags); > > > -#ifdef CONFIG_PPC32 > > > #ifdef CONFIG_HOTPLUG_CPU > > > - /* Corresponding to generic_set_cpu_dead() */ > > > - generic_set_cpu_up(nr); > > > - > > > if (system_state == SYSTEM_RUNNING) { > > > /* > > > * To keep it compatible with old boot program which > > > uses > > > @@ -263,6 +280,7 @@ static int smp_85xx_kick_cpu(int nr) > > > out_be32(&spin_table->addr_l, 0); > > > flush_spin_table(spin_table); > > > > > > + qoriq_pm_ops->cpu_up(nr); > > > > Again, is it possible to get here without a valid qoriq_pm_ops (i.e. > > is there > > anything stopping the user from trying to initiate CPU hotplug)? > > > > -Scott > > For every platform running this code, should has a valid qoriq_pm_ops. > If not valid, it's a bug. How do you prevent this code from running when there is no valid qoriq_pm_ops? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/