Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755406Ab3C2NyO (ORCPT ); Fri, 29 Mar 2013 09:54:14 -0400 Received: from mail-gg0-f181.google.com ([209.85.161.181]:41288 "EHLO mail-gg0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754847Ab3C2NyN (ORCPT ); Fri, 29 Mar 2013 09:54:13 -0400 Message-ID: <51559D01.9070607@gmail.com> Date: Fri, 29 Mar 2013 08:54:09 -0500 From: Rob Herring User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Stefano Stabellini CC: Nicolas Pitre , "xen-devel@lists.xensource.com" , "linux@arm.linux.org.uk" , "arnd@arndb.de" , Marc Zyngier , Will Deacon , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH v3] [RFC] arm: use PSCI if available References: <1364388639-11210-1-git-send-email-stefano.stabellini@eu.citrix.com> <20130327133811.GE18429@mudshark.cambridge.arm.com> <20130327172306.GB20990@mudshark.cambridge.arm.com> <51545BE4.9050206@gmail.com> <51548E1C.4070508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4277 Lines: 96 On 03/29/2013 08:22 AM, Stefano Stabellini wrote: > On Thu, 28 Mar 2013, Rob Herring wrote: >> On 03/28/2013 10:39 AM, Nicolas Pitre wrote: >>> On Thu, 28 Mar 2013, Rob Herring wrote: >>> >>>> On 03/28/2013 09:51 AM, Nicolas Pitre wrote: >>>>> On Thu, 28 Mar 2013, Stefano Stabellini wrote: >>>>> >>>>>> - the interface to bring up secondary cpus is different and based on >>>>>> PSCI, in fact Xen is going to add a PSCI node to the device tree so that >>>>>> Dom0 can use it. >>>>>> >>>>>> Oh wait, Dom0 is not going to use the PSCI interface even if the node is >>>>>> present on device tree because it's going to prefer the platform smp_ops >>>>>> instead. >>>>> >>>>> Waitaminute... I must have missed this part. >>>>> >>>>> Who said platform specific methods must be used in preference to PSCI? >>>> >>>> I did. Specifically, I said the platform should be allowed to provide >>>> its own smp_ops. A platform may need to do addtional things on top of >>>> PSCI for example. >>> >>> Then the platform should have its special hook that would override the >>> default PSCI methods. But, by *default* the PSCI methods should be used >>> if the related DT information is present. >> >> Agreed. The special hook to override is setting mach desc smp_ops, right? > > If you consider the mach smp_ops a platform specific override, then > again PSCI and providing a PSCI node on DT doesn't solve the Xen problem > at all. > > See above: Xen adds a PSCI node to DT, and Linux still does not use it. Okay, I see. I wasn't distinguishing Dom0 vs DomU cases. Is this really the only issue with having a platform run in Dom0? We expect all platforms to work without any modifications? I would think for more complex platforms there would be some other work needed. How is Xen going to really do physical cpu power management if a platform does not provide PSCI firmware? Are you going to pull all the platform specific code we have in the kernel now into Xen? If you make PSCI firmware a requirement for Xen, then you would only be modifying existing PSCI data to the DTB and the platform would be converted to use PSCI already. >>>>> If DT does provide PSCI description, then PSCI should be used. Doing >>>>> otherwise is senseless. If PSCI is not to be used, then it should not >>>>> be present in DT. >>>> >>>> You can't assume the DT and kernel are in-sync. For example, I've added >>>> PSCI in the firmware and DTB (part of the firmware), but the highbank >>>> kernel may or may not use it depending if I convert it. >>> >>> If the kernel does not understand PSCI bindings in the DT, it naturally >>> won't use PSCI, right? Conversely, if the firmware and therefore >>> provided DT don't have PSCI, then the PSCI enabled kernel won't use PSCI >>> either. So what is the problem? >> >> I'm distinguishing the kernel in general is enabled for PSCI and a >> platform is enabled. The kernel may have PSCI smp_ops and the DTB may >> have PSCI data, but that alone should not make a platform use the >> default PSCI smp_ops. The platform has to make the decision and it >> cannot be just based on the platform's dtb having PSCI data. > > I can see how this would give greater flexibility to firmware > developers, but on the other hand it would limit the flexibility of the > kernel. It limits the flexibility of the kernel too. If PSCI is present in the DTB, then the kernel must use it and the platform has no say? That's not flexible. > > In fact, unfortunately, it is diametrically the opposite of what Xen > needs. > > I would kindly ask the maintainers to let me know what direction I > should take to move forward. My argument is somewhat academic. I fully expect to convert highbank over to PSCI for 3.10 assuming this patch gets sorted out in time. So it is not really an issue for me. Adding Nico's smp_init function could give the platform flexibility later if needed. We're only talking about the behavior of a small portion of the patch, so I would go ahead with implementing the rest of the feedback. Rob -- 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/