Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Fri, Feb 06, 2015 at 05:00:13PM +0100, Antonio Ospite wrote:
Last doubt, now that I am fixing the DSDT I am going to add an
Interrupt resource, but what is the correct way to specify its value?
Pin 3 of GPO2 is mapped to IRQ 220 by the mainline kernel, so I added
this:
Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, )
{
0x00DC,
}
And it works, but doesn't this rely on the way linux maps interrupt
numbers? Is this going to be OS agnostic? My doubt arises from the
fact that on the Android kernel the same pin is mapped to IRQ
389.
You should specify GpioInt() instead and turn it to interrupt using
gpiod_to_irq().
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Tue, 27 Jan 2015 15:45:59 +0100
Antonio Ospite a...@ao2.it wrote:
On Wed, 21 Jan 2015 12:16:54 +0200
Mika Westerberg mika.westerb...@intel.com wrote:
On Tue, Jan 20, 2015 at 05:56:45PM +0100, Antonio Ospite wrote:
[...]
[9.056300] gpiochip_get_desc: hwnum: 68 chip-ngpio: 44
[9.056303] acpi_find_gpio: desc_error: -22
[9.056306] acpi_find_gpio: ares-type: 17
[9.056308] acpi_find_gpio: ares-type: 7
[9.056314] i2c_hid i2c-GODX0911:01: lookup for GPIO irq failed
[9.056319] i2c_hid i2c-GODX0911:01: Failed to get GPIO interrupt
[9.073895] i2c_hid: probe of i2c-GODX0911:01 failed with error -22
As I was trying to say in the original mail, the DSDT declares a gpio
pin number (68) grater than the number of gpios for GPO2 (which on Bay
Trail is 44, isn't it?).
That's right.
Is the DSDT just wrong? Or could there be anything missing in the
pinctrl-baytrail driver?
I think the DSDT is wrong here.
I found out from my mail archives that similar Goodix panel was used on
some internal reference design boards (it also used Goodix driver, btw).
Those also had the 0x44 GPIO there but that was wrong and it looked like
the correct GPIO number is 3 (in GPO2).
And indeed it was the DSDT which had wrong both the interrupt pin _and_
the reset pin (GPO1.TCD3)...
Now I am sure that the android kernel doesn't use the platform data from
ACPI but provides it to drivers with some machine specific code, which I
don't have access to.
I was able to make the touchscreen work by using these resources:
Reset line (GPO1.TCD3) is: pin 9 on GPO1
Interrupt line is: pin 3 on GPO2
The reset sequence is performed when calling the _PS0 method, and with
the correct values the goodix driver can even retrieve the stored
configuration, no need to use the hardcoded default one.
Last doubt, now that I am fixing the DSDT I am going to add an
Interrupt resource, but what is the correct way to specify its value?
Pin 3 of GPO2 is mapped to IRQ 220 by the mainline kernel, so I added
this:
Interrupt (ResourceConsumer, Edge, ActiveHigh, Exclusive, ,, )
{
0x00DC,
}
And it works, but doesn't this rely on the way linux maps interrupt
numbers? Is this going to be OS agnostic? My doubt arises from the
fact that on the Android kernel the same pin is mapped to IRQ
389.
JFTR since I had no access to the kernel source (the device
manufacturer does not reply...), I had to derive the correct gpios from
the running Android kernel.
The interrupt one was easy, to verify that it was pin 3 of GPO2 I looked
in /proc/interrupts, done some subtractions and figured it out.
The reset line was trickier for me, first I thought that I could rmmod
the android goodix driver and look at some status changes, but the
driver was not rmmod-safe, the kernel hung... then I thought that the
touchscreen may be turned off when the screen is turned off and that did
it; in the end I managed to spot it by comparing /sys/kernel/debug/gpio
with the screen on and off; inteltool from coreboot would have worked
just as well.
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Wed, 21 Jan 2015 12:16:54 +0200 Mika Westerberg mika.westerb...@intel.com wrote: On Tue, Jan 20, 2015 at 05:56:45PM +0100, Antonio Ospite wrote: Hi Mika, I tested the patch but I still can't get the IRQ. The new code in i2c-hid does more or less what I was trying to do in the goodix driver as proof of concept: http://ao2.it/tmp/Goodix-TS_Teclast-X98-Air-3G/0001-XXX-goodix-add-support-for-GODX0911.patch The gpio chip correspondent to the pin can be retrieved, but the gpio descriptor can't be obtained and so the conversion from gpio to irq can't happen, here is the full dmesg: http://ao2.it/tmp/Goodix-TS_Teclast-X98-Air-3G/dmesg_Teclast_X98_Air_3G_mainline_i2c-hid_patch.log I am pasting here the interesting parts, with some more printouts I added to understand what was going on: [9.056071] i2c_hid i2c-GODX0911:01: GPIO lookup for consumer irq [9.056080] i2c_hid i2c-GODX0911:01: using ACPI for GPIO lookup [9.056086] acpi GODX0911:01: GPIO: looking up irq-gpios [9.056093] acpi GODX0911:01: GPIO: _DSD returned GODX0911:01 3 0 0 1 [9.056160] acpi_find_gpio: ares-type: 19 [9.056164] acpi_find_gpio: ares-type: 17 [9.056167] acpi_find_gpio: pin_index: 0, agpio-pin_table_length: 1 [9.056170] acpi_get_gpiod: path: \_SB.GPO2 pin: 68 [9.056176] acpi_get_gpiod: handle found [9.056180] acpi_get_gpiod: gpiochip found [9.056183] acpi_get_gpiod: pin: 68 [9.056186] acpi_get_gpiod: offset: 68 [9.056189] gpiochip_get_desc: hwnum: 68 chip-ngpio: 44 [9.056192] acpi_find_gpio: desc_error: -22 [9.056195] acpi_find_gpio: ares-type: 17 [9.056198] acpi_find_gpio: ares-type: 7 [9.056204] acpi GODX0911:01: GPIO: looking up irq-gpio [9.056209] acpi GODX0911:01: GPIO: looking up 0 in _CRS [9.056272] acpi_find_gpio: ares-type: 19 [9.056276] acpi_find_gpio: ares-type: 17 [9.056280] acpi_find_gpio: pin_index: 0, agpio-pin_table_length: 1 [9.056283] acpi_get_gpiod: path: \_SB.GPO2 pin: 68 [9.056288] acpi_get_gpiod: handle found [9.056291] acpi_get_gpiod: gpiochip found [9.056294] acpi_get_gpiod: pin: 68 [9.056297] acpi_get_gpiod: offset: 68 [9.056300] gpiochip_get_desc: hwnum: 68 chip-ngpio: 44 [9.056303] acpi_find_gpio: desc_error: -22 [9.056306] acpi_find_gpio: ares-type: 17 [9.056308] acpi_find_gpio: ares-type: 7 [9.056314] i2c_hid i2c-GODX0911:01: lookup for GPIO irq failed [9.056319] i2c_hid i2c-GODX0911:01: Failed to get GPIO interrupt [9.073895] i2c_hid: probe of i2c-GODX0911:01 failed with error -22 As I was trying to say in the original mail, the DSDT declares a gpio pin number (68) grater than the number of gpios for GPO2 (which on Bay Trail is 44, isn't it?). That's right. Is the DSDT just wrong? Or could there be anything missing in the pinctrl-baytrail driver? I think the DSDT is wrong here. I found out from my mail archives that similar Goodix panel was used on some internal reference design boards (it also used Goodix driver, btw). Those also had the 0x44 GPIO there but that was wrong and it looked like the correct GPIO number is 3 (in GPO2). First of all, thanks for looking. The goodix driver under Android also says it uses gpio 133 which seems consistent with this, as GPO2 base is 130 in the gpio-valleyview2 driver used in Android. Not sure if that's the case here but maybe worth trying. I tried overriding the DSDT but I am stuck with this issue: http://article.gmane.org/gmane.linux.acpi.devel/73176 I'll try hard-coding the gpio number in the code as quick test. Ciao, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Tue, Jan 20, 2015 at 11:31:52AM -0500, Benjamin Tissoires wrote: What makes you think it should use the goodix driver? The fact that the 3.19-rc4 log says: [2.424370] i2c_hid i2c-GODX0911:01: unexpected HID descriptor bcdVersion (0x) Which is rather troublesome and shows that we might have received a 0 answer when requesting the HID descriptor. Then Antonio tried to poke the device with the goodix driver and got a better answer from the version point of view. Right, I missed that from the logs. -- To unsubscribe from this list: send the line unsubscribe linux-input in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Mon, Jan 19, 2015 at 10:37:58AM -0500, Benjamin Tissoires wrote:
Hi Antonio,
[adding Mika in CC, he implemented most of the ACPI and GPIO for
i2c-hid]
On Jan 17 2015 or thereabouts, Antonio Ospite wrote:
Hi,
I am trying to make the Goodix driver (drivers/input/touchscreen/goodix.c)
working with a Teclast X98 Air 3G, a tablet based on Intel Bay Trail,
but I am new to ACPI and I could use some help.
I am working with a 3.19-rc4 kernel compiled for x86_64.
This is the DSDT section in the UEFI firmware:
Device (TCS0)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, GODX0911) // _HID: Hardware ID
Name (_CID, PNP0C50 /* HID Protocol Device (I2C bus) */)
// _CID: Compatible ID
urgh, this is bad. It declares itself as i2c-hid, but it is not :(
Anyway, according to your logs, i2c-hid probe() just fails, so it's not
a big problem.
Actually, I think this device should use i2c-hid. All the ACPI plumbing
is there including _DSM.
What makes you think it should use the goodix driver?
Name (_S0W, Zero) // _S0W: S0 Device Wake State
Name (_DEP, Package (0x02) // _DEP: Dependencies
{
GPO1,
I2C5
})
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
If ((^^^I2C5.PMIC.AVBG == One)) {}
}
Method (_PS0, 0, Serialized) // _PS0: Power State 0
{
If ((^^^GPO1.AVBL == One))
{
^^^GPO1.TCD3 = Zero
}
Sleep (0x05)
If ((^^^I2C5.PMIC.AVBG == One)) {}
Sleep (0x1E)
If ((^^^GPO1.AVBL == One))
{
^^^GPO1.TCD3 = One
}
Sleep (0x78)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource
Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated,
0x0019F0A0,
AddressingMode7Bit, \\_SB.I2C4,
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionInputOnly,
\\_SB.GPO2, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0044
}
})
Name (ABUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated,
0x0019F0A0,
AddressingMode7Bit, \\_SB.I2C4,
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionInputOnly,
\\_SB.GPO2, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0044
}
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
\\_SB.GPO1, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x001A
}
})
It looks like the GPIOs are correctly declared. The ACPI code should set
the client-irq auto-magically. It's not the case, so I guess Mika
should be able to tell us more on that.
The current i2c-hid.c does not cope with GPIO interrupts. I've attached
an experimental patch that should convert the driver to use them.
Antonio, can you try that out and check if i2c-hid driver gets you
working touch screen? Also please add i2c_hid.debug=1 to the kernel
command line so we can see if it returns proper HID descriptor.
From 9b7518976295978b28e1ad7a2404a139b0cd9345 Mon Sep 17 00:00:00 2001
From: Mika Westerberg mika.westerb...@linux.intel.com
Date: Fri, 3 Oct 2014 17:07:10 +0300
Subject: [PATCH] HID: i2c-hid: Preliminary support for GPIO interrupts
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
---
drivers/hid/i2c-hid/i2c-hid.c | 70 ---
1 file changed, 52 insertions(+), 18 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
index d43e967e7533..fd22e638830f 100644
--- a/drivers/hid/i2c-hid/i2c-hid.c
+++ b/drivers/hid/i2c-hid/i2c-hid.c
@@ -37,6 +37,7 @@
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Tue, 20 Jan 2015 12:05:48 +0200
Mika Westerberg mika.westerb...@intel.com wrote:
On Mon, Jan 19, 2015 at 10:37:58AM -0500, Benjamin Tissoires wrote:
Hi Antonio,
[adding Mika in CC, he implemented most of the ACPI and GPIO for
i2c-hid]
On Jan 17 2015 or thereabouts, Antonio Ospite wrote:
Hi,
I am trying to make the Goodix driver (drivers/input/touchscreen/goodix.c)
working with a Teclast X98 Air 3G, a tablet based on Intel Bay Trail,
but I am new to ACPI and I could use some help.
I am working with a 3.19-rc4 kernel compiled for x86_64.
This is the DSDT section in the UEFI firmware:
Device (TCS0)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, GODX0911) // _HID: Hardware ID
Name (_CID, PNP0C50 /* HID Protocol Device (I2C bus)
*/) // _CID: Compatible ID
[...]
Name (ABUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated,
0x0019F0A0,
AddressingMode7Bit, \\_SB.I2C4,
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionInputOnly,
\\_SB.GPO2, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0044
}
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
\\_SB.GPO1, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x001A
}
})
It looks like the GPIOs are correctly declared. The ACPI code should set
the client-irq auto-magically. It's not the case, so I guess Mika
should be able to tell us more on that.
The current i2c-hid.c does not cope with GPIO interrupts. I've attached
an experimental patch that should convert the driver to use them.
Antonio, can you try that out and check if i2c-hid driver gets you
working touch screen? Also please add i2c_hid.debug=1 to the kernel
command line so we can see if it returns proper HID descriptor.
Hi Mika, I tested the patch but I still can't get the IRQ.
The new code in i2c-hid does more or less what I was trying to do in
the goodix driver as proof of concept:
http://ao2.it/tmp/Goodix-TS_Teclast-X98-Air-3G/0001-XXX-goodix-add-support-for-GODX0911.patch
The gpio chip correspondent to the pin can be retrieved, but the gpio
descriptor can't be obtained and so the conversion from gpio to irq
can't happen, here is the full dmesg:
http://ao2.it/tmp/Goodix-TS_Teclast-X98-Air-3G/dmesg_Teclast_X98_Air_3G_mainline_i2c-hid_patch.log
I am pasting here the interesting parts, with some more printouts I
added to understand what was going on:
[9.056071] i2c_hid i2c-GODX0911:01: GPIO lookup for consumer irq
[9.056080] i2c_hid i2c-GODX0911:01: using ACPI for GPIO lookup
[9.056086] acpi GODX0911:01: GPIO: looking up irq-gpios
[9.056093] acpi GODX0911:01: GPIO: _DSD returned GODX0911:01 3 0 0 1
[9.056160] acpi_find_gpio: ares-type: 19
[9.056164] acpi_find_gpio: ares-type: 17
[9.056167] acpi_find_gpio: pin_index: 0, agpio-pin_table_length: 1
[9.056170] acpi_get_gpiod: path: \_SB.GPO2 pin: 68
[9.056176] acpi_get_gpiod: handle found
[9.056180] acpi_get_gpiod: gpiochip found
[9.056183] acpi_get_gpiod: pin: 68
[9.056186] acpi_get_gpiod: offset: 68
[9.056189] gpiochip_get_desc: hwnum: 68 chip-ngpio: 44
[9.056192] acpi_find_gpio: desc_error: -22
[9.056195] acpi_find_gpio: ares-type: 17
[9.056198] acpi_find_gpio: ares-type: 7
[9.056204] acpi GODX0911:01: GPIO: looking up irq-gpio
[9.056209] acpi GODX0911:01: GPIO: looking up 0 in _CRS
[9.056272] acpi_find_gpio: ares-type: 19
[9.056276] acpi_find_gpio: ares-type: 17
[9.056280] acpi_find_gpio: pin_index: 0, agpio-pin_table_length: 1
[9.056283] acpi_get_gpiod: path: \_SB.GPO2 pin: 68
[9.056288] acpi_get_gpiod: handle found
[9.056291] acpi_get_gpiod: gpiochip found
[9.056294] acpi_get_gpiod: pin: 68
[9.056297] acpi_get_gpiod: offset: 68
[9.056300] gpiochip_get_desc: hwnum: 68 chip-ngpio: 44
[9.056303] acpi_find_gpio: desc_error: -22
[9.056306] acpi_find_gpio: ares-type: 17
[9.056308] acpi_find_gpio: ares-type: 7
[9.056314] i2c_hid i2c-GODX0911:01: lookup for GPIO irq failed
[9.056319] i2c_hid i2c-GODX0911:01: Failed to get GPIO interrupt
[9.073895] i2c_hid: probe of i2c-GODX0911:01 failed with error -22
As I was trying to say in the original mail, the DSDT declares a gpio
pin number (68) grater than the number of gpios for GPO2 (which on
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
On Jan 20 2015 or thereabouts, Mika Westerberg wrote:
On Mon, Jan 19, 2015 at 10:37:58AM -0500, Benjamin Tissoires wrote:
Hi Antonio,
[adding Mika in CC, he implemented most of the ACPI and GPIO for
i2c-hid]
On Jan 17 2015 or thereabouts, Antonio Ospite wrote:
Hi,
I am trying to make the Goodix driver (drivers/input/touchscreen/goodix.c)
working with a Teclast X98 Air 3G, a tablet based on Intel Bay Trail,
but I am new to ACPI and I could use some help.
I am working with a 3.19-rc4 kernel compiled for x86_64.
This is the DSDT section in the UEFI firmware:
Device (TCS0)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, GODX0911) // _HID: Hardware ID
Name (_CID, PNP0C50 /* HID Protocol Device (I2C bus)
*/) // _CID: Compatible ID
urgh, this is bad. It declares itself as i2c-hid, but it is not :(
Anyway, according to your logs, i2c-hid probe() just fails, so it's not
a big problem.
Actually, I think this device should use i2c-hid. All the ACPI plumbing
is there including _DSM.
What makes you think it should use the goodix driver?
The fact that the 3.19-rc4 log says:
[2.424370] i2c_hid i2c-GODX0911:01: unexpected HID descriptor bcdVersion
(0x)
Which is rather troublesome and shows that we might have received a 0
answer when requesting the HID descriptor. Then Antonio tried to poke
the device with the goodix driver and got a better answer from the
version point of view.
Cheers,
Benjamin
--
To unsubscribe from this list: send the line unsubscribe linux-input in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About Goodix-TS on Bay Trail, and ACPI and interrupts
Hi Antonio,
[adding Mika in CC, he implemented most of the ACPI and GPIO for
i2c-hid]
On Jan 17 2015 or thereabouts, Antonio Ospite wrote:
Hi,
I am trying to make the Goodix driver (drivers/input/touchscreen/goodix.c)
working with a Teclast X98 Air 3G, a tablet based on Intel Bay Trail,
but I am new to ACPI and I could use some help.
I am working with a 3.19-rc4 kernel compiled for x86_64.
This is the DSDT section in the UEFI firmware:
Device (TCS0)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, GODX0911) // _HID: Hardware ID
Name (_CID, PNP0C50 /* HID Protocol Device (I2C bus) */)
// _CID: Compatible ID
urgh, this is bad. It declares itself as i2c-hid, but it is not :(
Anyway, according to your logs, i2c-hid probe() just fails, so it's not
a big problem.
Name (_S0W, Zero) // _S0W: S0 Device Wake State
Name (_DEP, Package (0x02) // _DEP: Dependencies
{
GPO1,
I2C5
})
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
If ((^^^I2C5.PMIC.AVBG == One)) {}
}
Method (_PS0, 0, Serialized) // _PS0: Power State 0
{
If ((^^^GPO1.AVBL == One))
{
^^^GPO1.TCD3 = Zero
}
Sleep (0x05)
If ((^^^I2C5.PMIC.AVBG == One)) {}
Sleep (0x1E)
If ((^^^GPO1.AVBL == One))
{
^^^GPO1.TCD3 = One
}
Sleep (0x78)
}
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource
Settings
{
Name (RBUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated, 0x0019F0A0,
AddressingMode7Bit, \\_SB.I2C4,
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionInputOnly,
\\_SB.GPO2, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0044
}
})
Name (ABUF, ResourceTemplate ()
{
I2cSerialBus (0x0014, ControllerInitiated, 0x0019F0A0,
AddressingMode7Bit, \\_SB.I2C4,
0x00, ResourceConsumer, ,
)
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionInputOnly,
\\_SB.GPO2, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0044
}
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
\\_SB.GPO1, 0x00, ResourceConsumer, ,
)
{ // Pin list
0x001A
}
})
It looks like the GPIOs are correctly declared. The ACPI code should set
the client-irq auto-magically. It's not the case, so I guess Mika
should be able to tell us more on that.
If ((OSSL 0x80))
{
Return (ABUF) /* \_SB_.I2C4.TCS0._CRS.ABUF */
}
Else
{
Return (RBUF) /* \_SB_.I2C4.TCS0._CRS.RBUF */
}
}
Method (_DSM, 4, Serialized) // _DSM: Device-Specific Method
{
Name (_T_1, Zero) // _T_x: Emitted by ASL Compiler
Name (_T_0, Zero) // _T_x: Emitted by ASL Compiler
Debug = Method _DSM begin
If ((Arg0 == ToUUID
(3cdff6f7-4267-4555-ad05-b30a3d8938de) /* HID I2C Device */))
{
While (One)
{
_T_0 = ToInteger (Arg2)
If ((_T_0 == Zero))
{
While (One)
{
_T_1 = ToInteger (Arg1)
If ((_T_1 == One))
{
Debug = Method _DSM Function Query
Return (Buffer
