| Message ID | 1444299575-17417-3-git-send-email-irina.tirdea@intel.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote: > After power on, it is recommended that the driver resets the device. > The reset procedure timing is described in the datasheet and is used > at device init (before writing device configuration) and > for power management. It is a sequence of setting the interrupt > and reset pins high/low at specific timing intervals. This procedure > also includes setting the slave address to the one specified in the > ACPI/device tree. > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > driver gt9xx.c for Android (publicly available in Android kernel > trees for various devices). > > For reset the driver needs to control the interrupt and > reset gpio pins (configured through ACPI/device tree). For devices > that do not have the gpio pins declared, the functionality depending > on these pins will not be available, but the device can still be used > with basic functionality. > > For both device tree and ACPI, the interrupt gpio pin configuration is > read from the "irq-gpio" property and the reset pin configuration is > read from the "reset-gpio" property. For ACPI 5.1, named properties > can be specified using the _DSD section. If there is no _DSD section > in the ACPI table, the driver will fall back to using indexed gpio > pins declared in the _CRS section. Would it help to use a plain "gpios" property here to always look up the lines by index? > +/* > + * Some platforms specify the gpio pins for interrupt and reset properly > + * in ACPI, but cannot use the interrupt pin as output due to their specific > + * HW configuration. > + */ > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = { > +#if defined(CONFIG_DMI) && defined(CONFIG_X86) > + { > + .ident = "Onda v975w", > + .matches = { > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), > + DMI_MATCH(DMI_PRODUCT_UUID, > + "03000200-0400-0500-0006-000700080009"), > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), > + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"), > + } > + }, I think lists like this in drivers should be avoided if at all possible, it just leads to other people adding their platform in the lists as opposed to fixing their boot loaders. Can you find another way to detect at runtime whether it works, and print a warning if it doesn't? If there is no way to detect that kind of device, we should probably have another property that the driver can read to determine this, so we can avoid adding each system here. > + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */ > + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14); > + if (error) > + return error; If the "interrupt" gpio is used as an output, maybe it has the wrong name? Is that the name from the goodix datasheet (that would be ok) or something you picked? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2015-10-08 at 12:54 +0200, Arnd Bergmann wrote: > I think lists like this in drivers should be avoided if at all > possible, > it just leads to other people adding their platform in the lists as > opposed to fixing their boot loaders. Instructions on fixing UEFI firmwares without the sources welcome. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Arnd Bergmann [mailto:arnd@arndb.de] > Sent: 08 October, 2015 13:54 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org > Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init > > On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote: > > After power on, it is recommended that the driver resets the device. > > The reset procedure timing is described in the datasheet and is used > > at device init (before writing device configuration) and > > for power management. It is a sequence of setting the interrupt > > and reset pins high/low at specific timing intervals. This procedure > > also includes setting the slave address to the one specified in the > > ACPI/device tree. > > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > > driver gt9xx.c for Android (publicly available in Android kernel > > trees for various devices). > > > > For reset the driver needs to control the interrupt and > > reset gpio pins (configured through ACPI/device tree). For devices > > that do not have the gpio pins declared, the functionality depending > > on these pins will not be available, but the device can still be used > > with basic functionality. > > > > For both device tree and ACPI, the interrupt gpio pin configuration is > > read from the "irq-gpio" property and the reset pin configuration is > > read from the "reset-gpio" property. For ACPI 5.1, named properties > > can be specified using the _DSD section. If there is no _DSD section > > in the ACPI table, the driver will fall back to using indexed gpio > > pins declared in the _CRS section. > > Would it help to use a plain "gpios" property here to always look > up the lines by index? > The problem with ACPI indexed gpios is that platforms declare the pins in random order. In this case we have some platforms that declare the interrupt pin first and others that declare the reset pin first. There is no way to differentiate between them so the only way to support these platforms is to pick a default and list all exceptions in the driver. My previous implementation did that with indexed gpios and dmi quirks. [1] This can be solved by using named gpios, which are available starting with ACPI 5.1. In this way we know exactly which is the interrupt pin and which is the reset pin and we do not need to add any additional exceptions to the driver. However, we still need to support the platforms that are already out there so we fall back to indexed gpios. [1] https://lkml.org/lkml/2015/9/15/609 > > +/* > > + * Some platforms specify the gpio pins for interrupt and reset properly > > + * in ACPI, but cannot use the interrupt pin as output due to their specific > > + * HW configuration. > > + */ > > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = { > > +#if defined(CONFIG_DMI) && defined(CONFIG_X86) > > + { > > + .ident = "Onda v975w", > > + .matches = { > > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), > > + DMI_MATCH(DMI_PRODUCT_UUID, > > + "03000200-0400-0500-0006-000700080009"), > > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), > > + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"), > > + } > > + }, > > I think lists like this in drivers should be avoided if at all possible, > it just leads to other people adding their platform in the lists as > opposed to fixing their boot loaders. > > Can you find another way to detect at runtime whether it works, and > print a warning if it doesn't? I agree with you on this, but unfortunately I have not found a better way to do it. The main problem comes from the interrupt pin. This device uses the interrupt pin as output, which some platforms do not support (either due to the HW configuration or due to flagging it wrong in BIOS) [2] [3]. There is no error returned, just a warning in dmesg. [2] https://lkml.org/lkml/2015/9/28/851 [3] https://lkml.org/lkml/2015/9/30/607 > If there is no way to detect that kind > of device, we should probably have another property that the driver > can read to determine this, so we can avoid adding each system here. > If one or both gpio pins are not declared in ACPI/DT or if gpio initialization fails, the driver will work without the functionality that depends on them. However, this will not work for platforms that are already out and for which we cannot modify the ACPI table (like Onda v975w, WinBook TW100 and WinBook TW700). > > + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */ > > + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14); > > + if (error) > > + return error; > > If the "interrupt" gpio is used as an output, maybe it has the wrong > name? Is that the name from the goodix datasheet (that would be ok) > or something you picked? > This is from the goodix datasheet [4]. The pin that is used for receiving interrupts is also used as output (for reset and suspend procedures). [4] https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing Thanks, Irina > Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 08 October 2015 12:18:37 Tirdea, Irina wrote: > > From: Arnd Bergmann [mailto:arnd@arndb.de] > > Sent: 08 October, 2015 13:54 > > To: Tirdea, Irina > > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > > kernel@vger.kernel.org; devicetree@vger.kernel.org > > Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init > > > > On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote: > > > After power on, it is recommended that the driver resets the device. > > > The reset procedure timing is described in the datasheet and is used > > > at device init (before writing device configuration) and > > > for power management. It is a sequence of setting the interrupt > > > and reset pins high/low at specific timing intervals. This procedure > > > also includes setting the slave address to the one specified in the > > > ACPI/device tree. > > > > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > > > driver gt9xx.c for Android (publicly available in Android kernel > > > trees for various devices). > > > > > > For reset the driver needs to control the interrupt and > > > reset gpio pins (configured through ACPI/device tree). For devices > > > that do not have the gpio pins declared, the functionality depending > > > on these pins will not be available, but the device can still be used > > > with basic functionality. > > > > > > For both device tree and ACPI, the interrupt gpio pin configuration is > > > read from the "irq-gpio" property and the reset pin configuration is > > > read from the "reset-gpio" property. For ACPI 5.1, named properties > > > can be specified using the _DSD section. If there is no _DSD section > > > in the ACPI table, the driver will fall back to using indexed gpio > > > pins declared in the _CRS section. > > > > Would it help to use a plain "gpios" property here to always look > > up the lines by index? > > > > The problem with ACPI indexed gpios is that platforms declare the > pins in random order. In this case we have some platforms that declare > the interrupt pin first and others that declare the reset pin first. > There is no way to differentiate between them so the only way to support > these platforms is to pick a default and list all exceptions in the driver. > My previous implementation did that with indexed gpios and dmi quirks. [1] > > This can be solved by using named gpios, which are available starting with ACPI 5.1. > In this way we know exactly which is the interrupt pin and which is the reset pin > and we do not need to add any additional exceptions to the driver. > However, we still need to support the platforms that are already out there so > we fall back to indexed gpios. > > [1] https://lkml.org/lkml/2015/9/15/609 Right. > > > +/* > > > + * Some platforms specify the gpio pins for interrupt and reset properly > > > + * in ACPI, but cannot use the interrupt pin as output due to their specific > > > + * HW configuration. > > > + */ > > > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = { > > > +#if defined(CONFIG_DMI) && defined(CONFIG_X86) > > > + { > > > + .ident = "Onda v975w", > > > + .matches = { > > > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), > > > + DMI_MATCH(DMI_PRODUCT_UUID, > > > + "03000200-0400-0500-0006-000700080009"), > > > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), > > > + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"), > > > + } > > > + }, > > > > I think lists like this in drivers should be avoided if at all possible, > > it just leads to other people adding their platform in the lists as > > opposed to fixing their boot loaders. > > > > Can you find another way to detect at runtime whether it works, and > > print a warning if it doesn't? > > I agree with you on this, but unfortunately I have not found a better way to do it. > > The main problem comes from the interrupt pin. This device uses the interrupt pin > as output, which some platforms do not support (either due to the HW configuration > or due to flagging it wrong in BIOS) [2] [3]. There is no error returned, just a warning > in dmesg. > > [2] https://lkml.org/lkml/2015/9/28/851 > [3] https://lkml.org/lkml/2015/9/30/607 Would it be possible to combine those two and require future firmware to use the named gpios if they want the proper reset, but fall back to not doing it if they use an anonymous list of GPIOs? > > > + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */ > > > + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14); > > > + if (error) > > > + return error; > > > > If the "interrupt" gpio is used as an output, maybe it has the wrong > > name? Is that the name from the goodix datasheet (that would be ok) > > or something you picked? > > > > This is from the goodix datasheet [4]. The pin that is used for receiving interrupts > is also used as output (for reset and suspend procedures). > > [4] https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing > Ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----Original Message----- > From: Arnd Bergmann [mailto:arnd@arndb.de] > Sent: 08 October, 2015 16:01 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org > Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init > > On Thursday 08 October 2015 12:18:37 Tirdea, Irina wrote: > > > From: Arnd Bergmann [mailto:arnd@arndb.de] > > > Sent: 08 October, 2015 13:54 > > > To: Tirdea, Irina > > > Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > > > kernel@vger.kernel.org; devicetree@vger.kernel.org > > > Subject: Re: [PATCH v7 2/9] Input: goodix - reset device at init > > > > > > On Thursday 08 October 2015 13:19:28 Irina Tirdea wrote: > > > > After power on, it is recommended that the driver resets the device. > > > > The reset procedure timing is described in the datasheet and is used > > > > at device init (before writing device configuration) and > > > > for power management. It is a sequence of setting the interrupt > > > > and reset pins high/low at specific timing intervals. This procedure > > > > also includes setting the slave address to the one specified in the > > > > ACPI/device tree. > > > > > > > > This is based on Goodix datasheets for GT911 and GT9271 and on Goodix > > > > driver gt9xx.c for Android (publicly available in Android kernel > > > > trees for various devices). > > > > > > > > For reset the driver needs to control the interrupt and > > > > reset gpio pins (configured through ACPI/device tree). For devices > > > > that do not have the gpio pins declared, the functionality depending > > > > on these pins will not be available, but the device can still be used > > > > with basic functionality. > > > > > > > > For both device tree and ACPI, the interrupt gpio pin configuration is > > > > read from the "irq-gpio" property and the reset pin configuration is > > > > read from the "reset-gpio" property. For ACPI 5.1, named properties > > > > can be specified using the _DSD section. If there is no _DSD section > > > > in the ACPI table, the driver will fall back to using indexed gpio > > > > pins declared in the _CRS section. > > > > > > Would it help to use a plain "gpios" property here to always look > > > up the lines by index? > > > > > > > The problem with ACPI indexed gpios is that platforms declare the > > pins in random order. In this case we have some platforms that declare > > the interrupt pin first and others that declare the reset pin first. > > There is no way to differentiate between them so the only way to support > > these platforms is to pick a default and list all exceptions in the driver. > > My previous implementation did that with indexed gpios and dmi quirks. [1] > > > > This can be solved by using named gpios, which are available starting with ACPI 5.1. > > In this way we know exactly which is the interrupt pin and which is the reset pin > > and we do not need to add any additional exceptions to the driver. > > However, we still need to support the platforms that are already out there so > > we fall back to indexed gpios. > > > > [1] https://lkml.org/lkml/2015/9/15/609 > > Right. > > > > > +/* > > > > + * Some platforms specify the gpio pins for interrupt and reset properly > > > > + * in ACPI, but cannot use the interrupt pin as output due to their specific > > > > + * HW configuration. > > > > + */ > > > > +static const struct dmi_system_id goodix_no_gpio_pins_support[] = { > > > > +#if defined(CONFIG_DMI) && defined(CONFIG_X86) > > > > + { > > > > + .ident = "Onda v975w", > > > > + .matches = { > > > > + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), > > > > + DMI_MATCH(DMI_PRODUCT_UUID, > > > > + "03000200-0400-0500-0006-000700080009"), > > > > + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), > > > > + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"), > > > > + } > > > > + }, > > > > > > I think lists like this in drivers should be avoided if at all possible, > > > it just leads to other people adding their platform in the lists as > > > opposed to fixing their boot loaders. > > > > > > Can you find another way to detect at runtime whether it works, and > > > print a warning if it doesn't? > > > > I agree with you on this, but unfortunately I have not found a better way to do it. > > > > The main problem comes from the interrupt pin. This device uses the interrupt pin > > as output, which some platforms do not support (either due to the HW configuration > > or due to flagging it wrong in BIOS) [2] [3]. There is no error returned, just a warning > > in dmesg. > > > > [2] https://lkml.org/lkml/2015/9/28/851 > > [3] https://lkml.org/lkml/2015/9/30/607 > > Would it be possible to combine those two and require future firmware to > use the named gpios if they want the proper reset, but fall back to not > doing it if they use an anonymous list of GPIOs? > Yes, that would work. I will send a new version that includes this change. Thanks, Irina > > > > + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */ > > > > + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14); > > > > + if (error) > > > > + return error; > > > > > > If the "interrupt" gpio is used as an output, maybe it has the wrong > > > name? Is that the name from the goodix datasheet (that would be ok) > > > or something you picked? > > > > > > > This is from the goodix datasheet [4]. The pin that is used for receiving interrupts > > is also used as output (for reset and suspend procedures). > > > > [4] > https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg& > usp=sharing > > > > Ok. > > Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt index 8ba98ee..7137881 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt @@ -12,6 +12,8 @@ Required properties: - reg : I2C address of the chip. Should be 0x5d or 0x14 - interrupt-parent : Interrupt controller to which the chip is connected - interrupts : Interrupt to which the chip is connected + - irq-gpio : GPIO pin used for IRQ + - reset-gpio : GPIO pin used for reset Example: @@ -23,6 +25,9 @@ Example: reg = <0x5d>; interrupt-parent = <&gpio>; interrupts = <0 0>; + + irq-gpio = <&gpio1 0 0>; + reset-gpio = <&gpio1 1 0>; }; /* ... */ diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c index 56d0330..916198d 100644 --- a/drivers/input/touchscreen/goodix.c +++ b/drivers/input/touchscreen/goodix.c @@ -16,6 +16,7 @@ #include <linux/kernel.h> #include <linux/dmi.h> +#include <linux/gpio.h> #include <linux/i2c.h> #include <linux/input.h> #include <linux/input/mt.h> @@ -37,8 +38,13 @@ struct goodix_ts_data { unsigned int int_trigger_type; bool rotated_screen; int cfg_len; + struct gpio_desc *gpiod_int; + struct gpio_desc *gpiod_rst; }; +#define GOODIX_GPIO_INT_NAME "irq" +#define GOODIX_GPIO_RST_NAME "reset" + #define GOODIX_MAX_HEIGHT 4096 #define GOODIX_MAX_WIDTH 4096 #define GOODIX_INT_TRIGGER 1 @@ -89,6 +95,41 @@ static const struct dmi_system_id rotated_screen[] = { {} }; +/* + * Some platforms specify the gpio pins for interrupt and reset properly + * in ACPI, but cannot use the interrupt pin as output due to their specific + * HW configuration. + */ +static const struct dmi_system_id goodix_no_gpio_pins_support[] = { +#if defined(CONFIG_DMI) && defined(CONFIG_X86) + { + .ident = "Onda v975w", + .matches = { + DMI_MATCH(DMI_BIOS_VENDOR, "American Megatrends Inc."), + DMI_MATCH(DMI_PRODUCT_UUID, + "03000200-0400-0500-0006-000700080009"), + DMI_MATCH(DMI_BOARD_VENDOR, "AMI Corporation"), + DMI_MATCH(DMI_BOARD_NAME, "Aptio CRB"), + } + }, + { + .ident = "WinBook TW100", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "WinBook"), + DMI_MATCH(DMI_PRODUCT_NAME, "TW100") + } + }, + { + .ident = "WinBook TW700", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "WinBook"), + DMI_MATCH(DMI_PRODUCT_NAME, "TW700") + }, + }, +#endif + {} +}; + /** * goodix_i2c_read - read data from a register of the i2c slave device. * @@ -237,6 +278,114 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void *dev_id) return IRQ_HANDLED; } +static int goodix_int_sync(struct goodix_ts_data *ts) +{ + int error; + + error = gpiod_direction_output(ts->gpiod_int, 0); + if (error) + return error; + msleep(50); /* T5: 50ms */ + + return gpiod_direction_input(ts->gpiod_int); +} + +/** + * goodix_reset - Reset device during power on + * + * @ts: goodix_ts_data pointer + */ +static int goodix_reset(struct goodix_ts_data *ts) +{ + int error; + + /* begin select I2C slave addr */ + error = gpiod_direction_output(ts->gpiod_rst, 0); + if (error) + return error; + msleep(20); /* T2: > 10ms */ + /* HIGH: 0x28/0x29, LOW: 0xBA/0xBB */ + error = gpiod_direction_output(ts->gpiod_int, ts->client->addr == 0x14); + if (error) + return error; + usleep_range(100, 2000); /* T3: > 100us */ + error = gpiod_direction_output(ts->gpiod_rst, 1); + if (error) + return error; + usleep_range(6000, 10000); /* T4: > 5ms */ + /* end select I2C slave addr */ + error = gpiod_direction_input(ts->gpiod_rst); + if (error) + return error; + return goodix_int_sync(ts); +} + +static const struct acpi_gpio_params goodix_first_gpio = { 0, 0, false }; +static const struct acpi_gpio_params goodix_second_gpio = { 1, 0, false }; + +static const struct acpi_gpio_mapping goodix_default_gpios[] = { + { GOODIX_GPIO_INT_NAME "-gpio", &goodix_first_gpio, 1 }, + { GOODIX_GPIO_RST_NAME "-gpio", &goodix_second_gpio, 1 }, + { }, +}; + +/** + * goodix_get_gpio_config - Get GPIO config from ACPI/DT + * + * @ts: goodix_ts_data pointer + */ +static int goodix_get_gpio_config(struct goodix_ts_data *ts) +{ + int error; + struct device *dev; + struct gpio_desc *gpiod; + + if (!ts->client) + return -EINVAL; + dev = &ts->client->dev; + + if (dmi_check_system(goodix_no_gpio_pins_support)) { + dev_dbg(&ts->client->dev, "GPIO pins not supported.\n"); + return 0; + } + + if (ACPI_HANDLE(dev)) { + error = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), + goodix_default_gpios); + if (error) + return error; + } + + /* Get the interrupt GPIO pin number */ + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN); + if (IS_ERR(gpiod)) { + error = PTR_ERR(gpiod); + if (error != -EPROBE_DEFER) + dev_warn(dev, "Failed to get %s GPIO: %d\n", + GOODIX_GPIO_INT_NAME, error); + goto out_err; + } + ts->gpiod_int = gpiod; + + /* Get the reset line GPIO pin number */ + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_RST_NAME, GPIOD_IN); + if (IS_ERR(gpiod)) { + error = PTR_ERR(gpiod); + if (error != -EPROBE_DEFER) + dev_warn(dev, "Failed to get %s GPIO: %d\n", + GOODIX_GPIO_RST_NAME, error); + goto out_err; + } + ts->gpiod_rst = gpiod; + + return 0; + +out_err: + if (ACPI_HANDLE(dev)) + acpi_dev_remove_driver_gpios(ACPI_COMPANION(dev)); + return error; +} + /** * goodix_read_config - Read the embedded configuration of the panel * @@ -405,6 +554,19 @@ static int goodix_ts_probe(struct i2c_client *client, ts->client = client; i2c_set_clientdata(client, ts); + error = goodix_get_gpio_config(ts); + if (error == -EPROBE_DEFER) + return error; + + if (ts->gpiod_int && ts->gpiod_rst) { + /* reset the controller */ + error = goodix_reset(ts); + if (error) { + dev_err(&client->dev, "Controller reset failed.\n"); + return error; + } + } + error = goodix_i2c_test(client); if (error) { dev_err(&client->dev, "I2C communication failure: %d\n", error); @@ -437,6 +599,19 @@ static int goodix_ts_probe(struct i2c_client *client, return 0; } +static int goodix_ts_remove(struct i2c_client *client) +{ + struct goodix_ts_data *ts = i2c_get_clientdata(client); + + if (!ts->gpiod_int || !ts->gpiod_rst) + return 0; + + if (ACPI_HANDLE(&ts->client->dev)) + acpi_dev_remove_driver_gpios(ACPI_COMPANION(&ts->client->dev)); + + return 0; +} + static const struct i2c_device_id goodix_ts_id[] = { { "GDIX1001:00", 0 }, { } @@ -467,6 +642,7 @@ MODULE_DEVICE_TABLE(of, goodix_of_match); static struct i2c_driver goodix_ts_driver = { .probe = goodix_ts_probe, + .remove = goodix_ts_remove, .id_table = goodix_ts_id, .driver = { .name = "Goodix-TS",
After power on, it is recommended that the driver resets the device. The reset procedure timing is described in the datasheet and is used at device init (before writing device configuration) and for power management. It is a sequence of setting the interrupt and reset pins high/low at specific timing intervals. This procedure also includes setting the slave address to the one specified in the ACPI/device tree. This is based on Goodix datasheets for GT911 and GT9271 and on Goodix driver gt9xx.c for Android (publicly available in Android kernel trees for various devices). For reset the driver needs to control the interrupt and reset gpio pins (configured through ACPI/device tree). For devices that do not have the gpio pins declared, the functionality depending on these pins will not be available, but the device can still be used with basic functionality. For both device tree and ACPI, the interrupt gpio pin configuration is read from the "irq-gpio" property and the reset pin configuration is read from the "reset-gpio" property. For ACPI 5.1, named properties can be specified using the _DSD section. If there is no _DSD section in the ACPI table, the driver will fall back to using indexed gpio pins declared in the _CRS section. For ACPI, the pins can be specified using ACPI 5.1: Device (STAC) { Name (_HID, "GDIX1001") ... Method (_CRS, 0, Serialized) { Name (RBUF, ResourceTemplate () { I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\I2C0", 0x00, ResourceConsumer, , ) GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x0000, "\\I2C0", 0x00, ResourceConsumer, , ) { // Pin list 0 } GpioIo (Exclusive, PullDown, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\I2C0", 0x00, ResourceConsumer, , ) { 1 } }) Return (RBUF) } Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }}, Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }}, ... } } Signed-off-by: Octavian Purdila <octavian.purdila@intel.com> Signed-off-by: Irina Tirdea <irina.tirdea@intel.com> --- .../bindings/input/touchscreen/goodix.txt | 5 + drivers/input/touchscreen/goodix.c | 176 +++++++++++++++++++++ 2 files changed, 181 insertions(+)