On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood [off-list ref]
wrote:
On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
quoted
On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood [off-list ref]
wrote:
> On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> > >
>
> > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
[off-list ref]
> > 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.
-Chenhui
From: Scott Wood <hidden> Date: 2015-08-06 05:46:39
On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood [off-list ref]
wrote:
quoted
On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
quoted
On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood [off-list ref]
wrote:
> On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> > >
>
> > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
[off-list ref]
> > 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
On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood [off-list ref]
wrote:
On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
quoted
On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
[off-list ref]
wrote:
> On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
> > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood
[off-list ref]
> > wrote:
> > > On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> > > > >
> > >
> > > > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
> > [off-list ref]
> > > > 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. However,
setting them make sure dead cpus can not be waked up unexpectedly.
-Chenhui
From: Scott Wood <hidden> Date: 2015-08-06 18:03:05
On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote:
On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood [off-list ref]
wrote:
quoted
On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
quoted
On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
[off-list ref]
wrote:
> On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
> > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood
[off-list ref]
> > wrote:
> > > On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> > > > >
> > >
> > > > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
> > [off-list ref]
> > > > 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
On Fri, Aug 7, 2015 at 2:02 AM, Scott Wood [off-list ref]
wrote:
On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote:
quoted
On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood [off-list ref]
wrote:
> On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
> > On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
> > [off-list ref]
> > wrote:
> > > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
> > > > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood
> > [off-list ref]
> > > > wrote:
> > > > > On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> > > > > > >
> > > > >
> > > > > > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
> > > > [off-list ref]
> > > > > > 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?
quoted
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
From: Scott Wood <hidden> Date: 2015-08-08 00:14:03
On Fri, 2015-08-07 at 11:19 +0800, Chenhui Zhao wrote:
On Fri, Aug 7, 2015 at 2:02 AM, Scott Wood [off-list ref]
wrote:
quoted
On Thu, 2015-08-06 at 13:54 +0800, Chenhui Zhao wrote:
quoted
On Thu, Aug 6, 2015 at 1:46 PM, Scott Wood [off-list ref]
wrote:
> On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote:
> > On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood
> > [off-list ref]
> > wrote:
> > > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote:
> > > > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood
> > [off-list ref]
> > > > wrote:
> > > > > On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> > > > > > >
> > > > >
> > > > > > On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
> > > > [off-list ref]
> > > > > > 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?
quoted
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.
The deep sleep part is more convincing -- so MPIC masking is not effective
during deep sleep?
-Scott