Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758796Ab3DASUt (ORCPT ); Mon, 1 Apr 2013 14:20:49 -0400 Received: from mail-qc0-f171.google.com ([209.85.216.171]:61782 "EHLO mail-qc0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756501Ab3DASUs (ORCPT ); Mon, 1 Apr 2013 14:20:48 -0400 Date: Mon, 1 Apr 2013 14:20:44 -0400 (EDT) From: Nicolas Pitre To: Stefano Stabellini cc: Rob Herring , "xen-devel@lists.xensource.com" , Russell King - ARM Linux , Arnd Bergmann , "marc.zyngier@arm.com" , Will Deacon , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup In-Reply-To: Message-ID: References: <1364575371-8926-2-git-send-email-stefano.stabellini@eu.citrix.com> <5155EC28.8050608@gmail.com> User-Agent: Alpine 2.03 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3310 Lines: 82 On Mon, 1 Apr 2013, Stefano Stabellini wrote: > On Fri, 29 Mar 2013, Rob Herring wrote: > > On 03/29/2013 12:53 PM, Nicolas Pitre wrote: > > > On Fri, 29 Mar 2013, Stefano Stabellini wrote: > > > > > >> On Fri, 29 Mar 2013, Nicolas Pitre wrote: > > >>> On Fri, 29 Mar 2013, Stefano Stabellini wrote: > > >>> > > >>>> If PSCI initializes correctly and PSCI SMP operations are available, use them. > > >>>> This is required for SMP support in Dom0 on Xen. > > >>>> > > >>>> Signed-off-by: Stefano Stabellini > > >>>> CC: will.deacon@arm.com > > >>>> CC: arnd@arndb.de > > >>>> CC: marc.zyngier@arm.com > > >>>> CC: linux@arm.linux.org.uk > > >>>> CC: nico@linaro.org > > >>> > > >>> I'd suggest you also include in your series the patch I posted earlier > > >>> providing a runtime mdesc->smp_init method as well. > > >> > > >> OK. > > >> > > >> > > >>> This way the > > >>> priority order would be: > > >>> > > >>> - If mdesc->smp_init is non null then use that. > > >>> > > >>> - Otherwise, if PSCI is available then use that. > > >>> > > >>> - Otherwise use mdesc->smp. > > >>> > > >>> This way, if the PSCI default has to be overriden (like in the MCPM case > > >>> because it needs to wrap PSCI itself, or to cover Rob's concern) then > > >>> this can be achieved at run time on a per mdesc basis. > > >> > > >> Actually that's not a bad idea, it could make everybody happy. > > >> What about the following, in this precise order: > > >> > > >> - if a xen hypervisor node is present on device tree, use PSCI; > > >> - otherwise if mdesc->smp_init is non null then use it; > > >> - otherwise if PSCI is available then use it; > > >> - otherwise use mdesc->smp. > > >> > > >> It's the most practical solution to satisfy everybody's needs. > > > > > > Maybe I'm missing something obvious, but why can't xen declare a mdesc > > > of its own? Given it is going to tweak the DT passed to the kernel > > > anyway that shouldn't be a problem. > > > > Xen does have it's own mdesc. It is (or will be) mach-virt, but that is > > only for DomU guests. For Dom0, you still need all the platform specific > > code except smp_ops. However, I'm doubtful this would work without other > > changes on more complicated platforms like OMAP. > > > > I would say wait to add this until you have platforms that actually need > > the first case. > > OK, that is not unreasonable. > > What are the platforms that are going to use smp_init? Do we know how do > they intend to use it? VExpress for one. When booting on a big.LITTLE system such as TC2 on VExpress, the MCPM layer needs to arbitrate power management operations on a per cluster basis. In that case there is a MCPM specific set of SMP ops to be used, even if it may end up calling into PSCI. But the important point is that we don't know beforehand what to use, especially with a kernel that can boot on multiple different VExpress configurations. The decision has to be made at run time, and therefore a static default or mdesc->smp ops doesn't cut it. Nicolas -- 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/