| Message ID | 20090331230217.GA31599@srcf.ucam.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers | show |
On Wed, Apr 1, 2009 at 4:02 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > Ok, can you try this and let me know what codes it generates (if it > generates any)? It should go on top of the previous patches. Nothing gets generated, even if I change the method to ".INFO" and hotkey events enabled with hci_write2(HCI_HOTKEY_EVENT, 1, 1, &hci_result) and TECF set to 1 (see my DSDT). I was playing with the code yesterday trying to get some events reported, but no luck so far. It appears that TOHK variable is _volatile_ and it just stores hotkey events temporarily and they don't get _stored_ like in the System Event FIFO. On the patches I sent to the omnibook module I'm able to get events but they seem to get repeated 3 times, or perhaps I'm polling to often. Saludos Azael
On Thu, Apr 02, 2009 at 09:50:59AM +1700, Azael Avalos wrote: > On Wed, Apr 1, 2009 at 4:02 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > Ok, can you try this and let me know what codes it generates (if it > > generates any)? It should go on top of the previous patches. > > Nothing gets generated, even if I change the method to ".INFO" and hotkey > events enabled with hci_write2(HCI_HOTKEY_EVENT, 1, 1, &hci_result) and > TECF set to 1 (see my DSDT). > > I was playing with the code yesterday trying to get some events reported, but no > luck so far. > > It appears that TOHK variable is _volatile_ and it just stores hotkey events > temporarily and they don't get _stored_ like in the System Event FIFO. Yes, you shouldn't be reading directly from TOHK at any point. It seems to be a purely internal variable - I'm fairly sure that the INFO method is the only one that should be called on event generation. > On the patches I sent to the omnibook module I'm able to get events but they > seem to get repeated 3 times, or perhaps I'm polling to often. Hm. I don't have test hardware right now, I'm afraid. I'll look at some DSDTs a bit more and see if anything springs to mind.
On Thu, Apr 2, 2009 at 9:53 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Apr 02, 2009 at 09:50:59AM +1700, Azael Avalos wrote: >> On Wed, Apr 1, 2009 at 4:02 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: >> > Ok, can you try this and let me know what codes it generates (if it >> > generates any)? It should go on top of the previous patches. >> >> Nothing gets generated, even if I change the method to ".INFO" and hotkey >> events enabled with hci_write2(HCI_HOTKEY_EVENT, 1, 1, &hci_result) and >> TECF set to 1 (see my DSDT). >> >> I was playing with the code yesterday trying to get some events reported, but no >> luck so far. >> >> It appears that TOHK variable is _volatile_ and it just stores hotkey events >> temporarily and they don't get _stored_ like in the System Event FIFO. > > Yes, you shouldn't be reading directly from TOHK at any point. It seems > to be a purely internal variable - I'm fairly sure that the INFO method > is the only one that should be called on event generation. Well, on the patches sent to the omnibook module I was polling TOHK directly, it is until now that I realized that I can poll the events via INFO method, that is, if I enable TECF first via method \\_SB.PCI0.LPCB.EC0.NTFY > >> On the patches I sent to the omnibook module I'm able to get events but they >> seem to get repeated 3 times, or perhaps I'm polling to often. > > Hm. I don't have test hardware right now, I'm afraid. I'll look at some > DSDTs a bit more and see if anything springs to mind. Well, I brought my laptop to work (I'm a sysadmin so I got plenty of time :-P) and I can test if that helps > > -- > Matthew Garrett | mjg59@srcf.ucam.org > Saludos Azael
On Thu, Apr 02, 2009 at 10:03:05AM +1700, Azael Avalos wrote: > On Thu, Apr 2, 2009 at 9:53 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > > Yes, you shouldn't be reading directly from TOHK at any point. It seems > > to be a purely internal variable - I'm fairly sure that the INFO method > > is the only one that should be called on event generation. > > Well, on the patches sent to the omnibook module I was polling TOHK directly, > it is until now that I realized that I can poll the events via INFO > method, that is, > if I enable TECF first via method \\_SB.PCI0.LPCB.EC0.NTFY Mm. None of the TOS1900 DSDTs I have here have TECF or NTFY methods, so again that doesn't sound like the right way of driving them. Does the ENAB method not do this? > > > >> On the patches I sent to the omnibook module I'm able to get events but they > >> seem to get repeated 3 times, or perhaps I'm polling to often. > > > > Hm. I don't have test hardware right now, I'm afraid. I'll look at some > > DSDTs a bit more and see if anything springs to mind. > > Well, I brought my laptop to work (I'm a sysadmin so I got plenty of time :-P) > and I can test if that helps I'll dig some more and let you know. Thanks!
On Thu, Apr 2, 2009 at 10:07 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Apr 02, 2009 at 10:03:05AM +1700, Azael Avalos wrote: >> On Thu, Apr 2, 2009 at 9:53 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: >> > Yes, you shouldn't be reading directly from TOHK at any point. It seems >> > to be a purely internal variable - I'm fairly sure that the INFO method >> > is the only one that should be called on event generation. >> >> Well, on the patches sent to the omnibook module I was polling TOHK directly, >> it is until now that I realized that I can poll the events via INFO >> method, that is, >> if I enable TECF first via method \\_SB.PCI0.LPCB.EC0.NTFY > > Mm. None of the TOS1900 DSDTs I have here have TECF or NTFY methods, so > again that doesn't sound like the right way of driving them. Does the > ENAB method not do this? At least not in my model, the ENAB method is empty, heres a snippet of the DSDT: Method (ENAB, 0, NotSerialized) { } Method (INFO, 0, NotSerialized) { If (TECF) { Store (Zero, TECF) Store (^^PCI0.LPCB.EC0.TOHK, Local0) Store (Zero, ^^PCI0.LPCB.EC0.TOHK) } Else { Store (Zero, Local0) } Return (Local0) } And above scope _SB you can find Method (NTFY, 0, NotSerialized) { Store (One, ^^^^VALZ.TECF) Notify (VALZ, 0x80) Return (0xAA) } Saludos Azael
diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c index 9fb4873..8552e1a 100644 --- a/drivers/platform/x86/toshiba_acpi.c +++ b/drivers/platform/x86/toshiba_acpi.c @@ -185,7 +185,6 @@ static int write_acpi_int(const char *methodName, int val) return (status == AE_OK); } -#if 0 static int read_acpi_int(const char *methodName, int *pVal) { struct acpi_buffer results; @@ -200,7 +199,6 @@ static int read_acpi_int(const char *methodName, int *pVal) return (status == AE_OK) && (out_objs[0].type == ACPI_TYPE_INTEGER); } -#endif static const char *method_hci /*= 0*/ ; @@ -802,6 +800,13 @@ static void toshiba_acpi_notify(acpi_handle handle, u32 event, void **data) if (event != 0x80) return; + + if (is_valid_acpi_path(TOSH_INTERFACE_2 SPFC_METHOD)) { + read_acpi_int(TOSH_INTERFACE_2 SPFC_METHOD, &value); + printk("Received 0x%x\n", value); + return; + } + do { hci_read1(HCI_SYSTEM_EVENT, &value, &hci_result); if (hci_result == HCI_SUCCESS) {