Re: GPE handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2007-11-09 at 12:45 +0300, Alexey Starikovskiy wrote:
> Shaohua,
> There is cond_resched() before the exit from deferred execution routine,
> specifically to let notify thread a chance to execute.
> Thus by the time deferred execution is exited, notify should be already 
> done,
> and we could safely enable _Lxx again.
> Do you think it is not sufficient?
Certainly not. A resched() can help to give a chance for other threads
to execute, but it's very unreliable. If it works, just because of luck.
We should add a wait there to guarantee.

Thanks,
Shaohua

> 
> Li, Shaohua wrote:
> > Bob & Ming,
> > I'm working on adding wakeup GPE support at system runtime, this
> > capability can help us
> > Identify which device invokes a wakeup event at runtime, this is
> > required for runtime device
> > Power management.
> >
> > Below is the ASL code. For example, _L0c, USB3 will send a wakeup GPE
> > and invoke
> > a notify. In the notify handler, OS will clear USB3's PCI PME status to
> > avoid wakeup
> > event flood. But in current code, acpi_ev_asynch_execute_gpe_method will
> > start an asynchronous
> > execution of notify and return soon. Just before the return,
> > acpi_ev_asynch_execute_gpe_method
> > will reenable GPE 0C. That means GPE is enabled before OS execute
> > notification handler and USB3's
> > PCI PME status is cleared, and cause GPE flood. Ideally, I think we
> > should delay GPE enable
> > of _L0c till notification handler is finished or simply the method _L0c
> > is really finished.
> > What do you think?
> >
> > Thanks,
> > Shaohua
> >
> >
> >         Method (_L0C, 0, NotSerialized)
> >         {
> >             Notify (\_SB.PCI0.USB3, 0x02)
> >         }
> >
> >         Method (_L0D, 0, NotSerialized)
> >         {
> >             Notify (\_SB.PCI0.USB7, 0x02)
> >         }
> >
> >         Method (_L0E, 0, NotSerialized)
> >         {
> >             Notify (\_SB.PCI0.USB4, 0x02)
> >         }
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >   
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux