Re: About Goodix-TS on Bay Trail, and ACPI and interrupts

Antonio Ospite
2015-01-27T14:46:07Z

On Wed, 21 Jan 2015 12:16:54 +0200
Mika Westerberg <mika.westerberg@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?