[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH 1/3] ACPI: Add infrastructure for refcounting GPE consumers
I have a couple of comments and questions:

1) The core issue that needs to be solved concerns enabling/disabling the wake and wake/run GPEs, is this correct? As far as I can tell, the normal runtime GPEs do not need any change. The runtime GPEs are mostly defined by _Lxx/_Exx methods. The main exception to this is the EC, it has a GPE defined by the _GPE method under the EC device. Are there any issues here?

2) A large change that goes unmentioned is that the ACPICA core would no longer execute the _PRW control methods in order to discover the wake GPEs. This makes sense to me because it is clear that the bus scan code must execute these _PRW methods anyway, in order to obtain the wake GPE and other info. So it makes sense to just remove the _PRW and wake GPE management code from ACPICA and let the host OS and drivers handle this task, since it does it already anyway. Do I understand this correctly?


>-----Original Message-----
>From: Rafael J. Wysocki []
>Sent: Tuesday, September 15, 2009 2:31 PM
>To: Matthew Garrett
>Cc: Moore, Robert;;
>Subject: Re: [PATCH 1/3] ACPI: Add infrastructure for refcounting GPE
>On Wednesday 02 September 2009, Matthew Garrett wrote:
>> ACPI GPEs may map to multiple devices. The current GPE interface only
>> provides a mechanism for enabling and disabling GPEs, making it difficult
>> to change the state of GPEs at runtime without extensive cooperation
>> between devices. Add an API to allow devices to indicate whether or not
>> they want their device's GPE to be enabled for both runtime and wakeup
>> events.
>Looks fine in general, but are we going to do anything about unbalanced

 \ /
  Last update: 2009-09-17 23:21    [W:0.053 / U:6.892 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site