Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752595AbaFJPWD (ORCPT ); Tue, 10 Jun 2014 11:22:03 -0400 Received: from mail-vc0-f170.google.com ([209.85.220.170]:34803 "EHLO mail-vc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752018AbaFJPWA (ORCPT ); Tue, 10 Jun 2014 11:22:00 -0400 MIME-Version: 1.0 In-Reply-To: References: <1402090985-8061-1-git-send-email-dianders@chromium.org> <20140607181221.GB25068@e102568-lin.cambridge.arm.com> <20140609223831.GB16889@e102568-lin.cambridge.arm.com> Date: Tue, 10 Jun 2014 08:21:59 -0700 X-Google-Sender-Auth: 7M0r-g7IrWEz20NDC3a76wKOTx8 Message-ID: Subject: Re: [PATCH] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start From: Doug Anderson To: Chander Kashyap Cc: Lorenzo Pieralisi , Kukjin Kim , Nicolas Pitre , Abhilash Kesavan , Andrew Bresticker , Inderpal Singh , Thomas Abraham , "olof@lixom.net" , Tushar Behera , Kevin Hilman , Javier Martinez Canillas , "linux-samsung-soc@vger.kernel.org" , "linux@arm.linux.org.uk" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Chander, On Tue, Jun 10, 2014 at 1:12 AM, Chander Kashyap wrote: > On 10 June 2014 04:08, Lorenzo Pieralisi wrote: >> On Mon, Jun 09, 2014 at 06:03:31PM +0100, Doug Anderson wrote: >> >> [...] >> >>> Cold boot and resume from suspend are detected via various special >>> flags in various special locations. Resume from suspend looks at >>> INFORM1 (0x10048004) for flags. This register is 0 during a cold boot >>> and has special values set by the kernel at resume time. >>> >>> It also looks as if some code looks at 0x10040900 (PMU_SPARE0) to help >>> tell initial cold boot and secondary CPU bringup. >> >> Ok, thanks a lot. It looks like firmware paths should be ready to >> detect cold vs warm boot, and hopefully do not rely on a specific >> MPIDR to come up first out of power states. >> >>> > I am asking to check if on this platform CPUidle (where the notion of >>> > primary CPU disappears) has a chance to run properly. >>> >>> I believe it should be possible, but we don't have CPUidle implemented >>> in our current system. Abhilash may be able to comment more. >> > > Cpuidle is implemented for exynos5420, and is tested on chromebook. My S-state knowledge is not strong, but I believe that Lorenzo's questions matter if we're using S2 for CPUidle (where we actually turn off power and hot unplug CPUs) but not when we're using S1 for CPUidle (where we just enter WFI/WFE). I believe that in ChromeOS we use S1 CPUidle and that it works fine. We've never implemented S2 that I'm aware of. -Doug -- 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/