Date: Fri, 7 Aug 2015 11:19:32 +0800
From: Chenhui Zhao <chenhui.zhao@freescale.com>
Subject: Re: [PATCH 1/3] Powerpc: mpc85xx: refactor the PM operations
To: Scott Wood <scottwood@freescale.com>
CC: <b29983@freescale.com>, <b07421@freescale.com>,
        <linux-kernel@vger.kernel.org>,
        Tang Yuantian <Yuantian.Tang@freescale.com>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Message-ID: <1438917572.2431.0@remotesmtp.freescale.net>
In-Reply-To: <1438884172.2097.155.camel@freescale.com>
References: <1438334444-31919-1-git-send-email-b29983@freescale.com>
	<1438387178.19345.77.camel@freescale.com>
	<1438601578.7515.2@remotesmtp.freescale.net>
	<1438633568.2097.35.camel@freescale.com>
	<1438769477.21522.0@remotesmtp.freescale.net>
	<1438829848.2097.129.camel@freescale.com>
	<1438834837.23384.0@remotesmtp.freescale.net>
	<1438839985.2097.151.camel@freescale.com>
	<1438840466.23384.2@remotesmtp.freescale.net>
	<1438884172.2097.155.camel@freescale.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2015 03:19:36.0239
 (UTC)
X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d;Ip=[192.88.158.2];Helo=[az84smr01.freescale.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR03MB574
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 3175
Lines: 103


On Fri, Aug 7, 2015 at 2:02 AM, Scott Wood <scottwood@freescale.com> 
wrote:
> On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote:
>>  On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood <scottwood@freescale.com>
>>  wrote:
>>  > On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
>>  > >  On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
>>  > > <scottwood@freescale.com>
>>  > >  wrote:
>>  > >  > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
>>  > >  > >  On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood
>>  > > <scottwood@freescale.com>
>>  > >  > >  wrote:
>>  > >  > >  > On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
>>  > >  > >  > >  >
>>  > >  > >  >
>>  > >  > >  > >  On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
>>  > >  > > <scottwood@freescale.com>
>>  > >  > >  > >  wrote:
>>  > >  > >  >
>>  > >  > >  > >  >
>>  > >  > >  > >  > Could you explain irq_mask()?  Why would there 
>> still be
>>  > > IRQs
>>  > >  > >  > > destined
>>  > >  > >  > >  > for
>>  > >  > >  > >  > this CPU at this point?
>>  > >  > >  > >
>>  > >  > >  > >  This function just masks irq by setting the 
>> registers in
>>  > > RCPM
>>  > >  > > (for
>>  > >  > >  > >  example, RCPM_CPMIMR, RCPM_CPMCIMR). Actually, all 
>> irqs to
>>  > >  > > this CPU
>>  > >  > >  > >  have been migrated to other CPUs.
>>  > >  > >  >
>>  > >  > >  > So why do we need to set those bits in RCPM?  Is it just
>>  > > caution?
>>  > >  > >
>>  > >  > >  Setting these bits can mask interrupts signalled to RCPM 
>> from
>>  > > MPIC
>>  > >  > > as a
>>  > >  > >  means of
>>  > >  > >  waking up from a lower power state. So, cores will not be
>>  > > waked up
>>  > >  > >  unexpectedly.
>>  > >  >
>>  > >  > Why would the MPIC be signalling those interrupts if they've 
>> been
>>  > >  > masked at
>>  > >  > the MPIC?
>>  > >  >
>>  > >  > -Scott
>>  > >  >
>>  > >
>>  > >  The interrupts to RCPM from MPIC are IRQ, Machine Check, NMI 
>> and
>>  > >  Critical interrupts. Some of them didn't be masked in MPIC.
>>  >
>>  > What interrupt could actually happen to a sleeping cpu that this
>>  > protects
>>  > against?
>>  >
>>  > -Scott
>> 
>>  Not sure. Maybe spurious interrupts or hardware exceptions.
> 
> Spurious interrupts happen due to race conditions.  They don't happen 
> because
> the MPIC is bored and decides to ring a CPU's doorbell and hide in 
> the bushes.
> 
> If by "hardware exceptions" you mean machine checks, how would such a 
> machine
> check be generated by a core that is off?
> 
>>   However, setting them make sure dead cpus can not be waked up 
>> unexpectedly.
> 
> I'm not seeing enough value here to warrant resurrecting the old 
> sleep node
> stuff.
> 
> -Scott

My guess maybe not accurate. My point is that electronic parts don't 
always work as expected. Taking preventative measures can make the 
system more robust. In addition, this step is required in deep sleep 
procedure.

-Chenhui


--
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/