Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753465Ab2HQNOT (ORCPT ); Fri, 17 Aug 2012 09:14:19 -0400 Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:22763 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751567Ab2HQNOE (ORCPT ); Fri, 17 Aug 2012 09:14:04 -0400 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 98.234.237.12 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+CGKqyjny5XO5Px5if459d Date: Fri, 17 Aug 2012 06:13:59 -0700 From: Tony Lindgren To: "Shilimkar, Santosh" Cc: Catalin Marinas , "linux-arch@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Will Deacon Subject: Re: [PATCH v2 02/31] arm64: Kernel booting and initialisation Message-ID: <20120817131358.GF11011@atomide.com> References: <1344966752-16102-1-git-send-email-catalin.marinas@arm.com> <1344966752-16102-3-git-send-email-catalin.marinas@arm.com> <502E11B6.4020104@ti.com> <20120817100533.GE24389@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2049 Lines: 43 * Shilimkar, Santosh [120817 03:11]: > On Fri, Aug 17, 2012 at 3:35 PM, Catalin Marinas > wrote: > > > > On Fri, Aug 17, 2012 at 10:41:10AM +0100, Santosh Shilimkar wrote: > > > > > > So you expect all the secondary CPUs to be in wakeup state and probably > > > looping in WFE for a signal from kernel to boot. There is one issue > > > with this requirement though. For large CPU system, you need to reset > > > all the CPUs and hit this waiting loop. This will lead to large inrush > > > current need at bootup which may be not be supported. To avoid this > > > issue, secondary CPUs are kept in OFF state and then they are woken > > > up from kernel one by one whenever they need to be brought into the > > > system. This requirement should be considered. > > > > I agree, this part will be extended. That's one method that we currently > > support and suitable to the model. > > > > The better method is the SMC standardisation that Charles Garcia-Tobin > > has written (to be made available soon) and was presented at the last > > Linaro Connect in HK. Given that the CPU power is usually controlled by > > the secure side, we'll ask for an SMC to be issued for waking up > > secondary CPUs, so it's up to the secure firmware to write the correct > > hardware registers. > > > Thanks for the information. SMC standardization would indeed help > to overcome some of these. Will wait for that information before > next set of questions. Yes please. If the SMC is not standardized for most calls at least, we'll end up with a horrible mess of SoC specific calls like we currently have. Related to that, the virtualization calls should be also standardized so we don't end up with multiple different hypervisors with different calls. Regards, Tony -- 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/