| Message ID | 1444663477-30062-3-git-send-email-irina.tirdea@intel.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, Oct 12, 2015 at 06:24:30PM +0300, 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 properly 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. This functionality will not be > available for devices that use indexed gpio pins declared in the _CRS > section (we need to provide backward compatibility with devices > that do not support using the interrupt gpio pin as output). > > 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> > Acked-by: Bastien Nocera <hadess@hadess.net> > Tested-by: Bastien Nocera <hadess@hadess.net> > Tested-by: Aleksei Mamlin <mamlinav@gmail.com> > --- > .../bindings/input/touchscreen/goodix.txt | 5 + > drivers/input/touchscreen/Kconfig | 1 + > drivers/input/touchscreen/goodix.c | 101 +++++++++++++++++++++ > 3 files changed, 107 insertions(+) > > 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/Kconfig b/drivers/input/touchscreen/Kconfig > index 771d95c..76f5a9d 100644 > --- a/drivers/input/touchscreen/Kconfig > +++ b/drivers/input/touchscreen/Kconfig > @@ -324,6 +324,7 @@ config TOUCHSCREEN_FUJITSU > config TOUCHSCREEN_GOODIX > tristate "Goodix I2C touchscreen" > depends on I2C > + depends on GPIOLIB > help > Say Y here if you have the Goodix touchscreen (such as one > installed in Onda v975w tablets) connected to your > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c > index 56d0330..87304ac 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 > @@ -237,6 +243,88 @@ 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); > +} > + > +/** > + * 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; > + > + /* Get the interrupt GPIO pin number */ > + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN); Why isn't this devm_gpiod_get_optional()? Then you would not need to clobber the return value down in goodix_ts_probe(). I can fix it up locally. Thanks.
> -----Original Message----- > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] > Sent: 12 October, 2015 19:48 > To: Tirdea, Irina > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > On Mon, Oct 12, 2015 at 06:24:30PM +0300, 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 properly 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. This functionality will not be > > available for devices that use indexed gpio pins declared in the _CRS > > section (we need to provide backward compatibility with devices > > that do not support using the interrupt gpio pin as output). > > > > 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> > > Acked-by: Bastien Nocera <hadess@hadess.net> > > Tested-by: Bastien Nocera <hadess@hadess.net> > > Tested-by: Aleksei Mamlin <mamlinav@gmail.com> > > --- > > .../bindings/input/touchscreen/goodix.txt | 5 + > > drivers/input/touchscreen/Kconfig | 1 + > > drivers/input/touchscreen/goodix.c | 101 +++++++++++++++++++++ > > 3 files changed, 107 insertions(+) > > > > 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/Kconfig b/drivers/input/touchscreen/Kconfig > > index 771d95c..76f5a9d 100644 > > --- a/drivers/input/touchscreen/Kconfig > > +++ b/drivers/input/touchscreen/Kconfig > > @@ -324,6 +324,7 @@ config TOUCHSCREEN_FUJITSU > > config TOUCHSCREEN_GOODIX > > tristate "Goodix I2C touchscreen" > > depends on I2C > > + depends on GPIOLIB > > help > > Say Y here if you have the Goodix touchscreen (such as one > > installed in Onda v975w tablets) connected to your > > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c > > index 56d0330..87304ac 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 > > @@ -237,6 +243,88 @@ 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); > > +} > > + > > +/** > > + * 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; > > + > > + /* Get the interrupt GPIO pin number */ > > + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN); > > Why isn't this devm_gpiod_get_optional()? Then you would not need to > clobber the return value down in goodix_ts_probe(). > I did not use devm_gpiod_get_optional() in order to ignore more errors than -ENOENT. This is needed because the ACPI gpio core will fall back to indexed gpios if named gpios are not found. In the common case of having 2 indexed gpio pins declared in the ACPI table, the first devm_gpiod_get() will successfully get indexed gpio pin 0 and the second devm_gpiod_get() will try to get the same gpio pin 0 and return -EBUSY. Considering this, I thought it is better to just ignore all errors in order not to break any platforms currently using this driver. > I can fix it up locally. > Sure, you can replace devm_gpiod_get with devm_gpiod_get_optional, but the error handling code should remain the same. Thanks, Irina > Thanks. > > -- > Dmitry -- 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 Tue, Oct 13, 2015 at 06:38:23AM +0000, Tirdea, Irina wrote: > > > > -----Original Message----- > > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] > > Sent: 12 October, 2015 19:48 > > To: Tirdea, Irina > > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > > kernel@vger.kernel.org; devicetree@vger.kernel.org > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > > > On Mon, Oct 12, 2015 at 06:24:30PM +0300, 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 properly 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. This functionality will not be > > > available for devices that use indexed gpio pins declared in the _CRS > > > section (we need to provide backward compatibility with devices > > > that do not support using the interrupt gpio pin as output). > > > > > > 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> > > > Acked-by: Bastien Nocera <hadess@hadess.net> > > > Tested-by: Bastien Nocera <hadess@hadess.net> > > > Tested-by: Aleksei Mamlin <mamlinav@gmail.com> > > > --- > > > .../bindings/input/touchscreen/goodix.txt | 5 + > > > drivers/input/touchscreen/Kconfig | 1 + > > > drivers/input/touchscreen/goodix.c | 101 +++++++++++++++++++++ > > > 3 files changed, 107 insertions(+) > > > > > > 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/Kconfig b/drivers/input/touchscreen/Kconfig > > > index 771d95c..76f5a9d 100644 > > > --- a/drivers/input/touchscreen/Kconfig > > > +++ b/drivers/input/touchscreen/Kconfig > > > @@ -324,6 +324,7 @@ config TOUCHSCREEN_FUJITSU > > > config TOUCHSCREEN_GOODIX > > > tristate "Goodix I2C touchscreen" > > > depends on I2C > > > + depends on GPIOLIB > > > help > > > Say Y here if you have the Goodix touchscreen (such as one > > > installed in Onda v975w tablets) connected to your > > > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c > > > index 56d0330..87304ac 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 > > > @@ -237,6 +243,88 @@ 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); > > > +} > > > + > > > +/** > > > + * 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; > > > + > > > + /* Get the interrupt GPIO pin number */ > > > + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN); > > > > Why isn't this devm_gpiod_get_optional()? Then you would not need to > > clobber the return value down in goodix_ts_probe(). > > > > I did not use devm_gpiod_get_optional() in order to ignore more errors > than -ENOENT. This is needed because the ACPI gpio core will fall back > to indexed gpios if named gpios are not found. In the common case of > having 2 indexed gpio pins declared in the ACPI table, the first > devm_gpiod_get() will successfully get indexed gpio pin 0 and the > second devm_gpiod_get() will try to get the same gpio pin 0 and return > -EBUSY. Considering this, I thought it is better to just ignore all errors in > order not to break any platforms currently using this driver. This seems like issue with ACPI gpio lookup implementation. If I am requesting named gpio and it is not present then I definitely do not need to be returned some random gpio. Doing so breaks all other drivers that use several names to retrieve GPIOs. We basically can't trust GPIO API on ACPI systems. I can see why we wanted to provide unnamed gpios even in presence of con_id, but it does not work when using several names. I wonder if acpi_find_gpio will have to keep track of state (requested names) and stop falling back to unnamed gpios if more than one con_id was suppolied for the same object. Thanks.
> -----Original Message----- > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] > Sent: 13 October, 2015 10:08 > To: Tirdea, Irina > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > On Tue, Oct 13, 2015 at 06:38:23AM +0000, Tirdea, Irina wrote: > > > > > > > -----Original Message----- > > > From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com] > > > Sent: 12 October, 2015 19:48 > > > To: Tirdea, Irina > > > Cc: Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > > > kernel@vger.kernel.org; devicetree@vger.kernel.org > > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > > > > > On Mon, Oct 12, 2015 at 06:24:30PM +0300, 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 properly 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. This functionality will not be > > > > available for devices that use indexed gpio pins declared in the _CRS > > > > section (we need to provide backward compatibility with devices > > > > that do not support using the interrupt gpio pin as output). > > > > > > > > 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> > > > > Acked-by: Bastien Nocera <hadess@hadess.net> > > > > Tested-by: Bastien Nocera <hadess@hadess.net> > > > > Tested-by: Aleksei Mamlin <mamlinav@gmail.com> > > > > --- > > > > .../bindings/input/touchscreen/goodix.txt | 5 + > > > > drivers/input/touchscreen/Kconfig | 1 + > > > > drivers/input/touchscreen/goodix.c | 101 +++++++++++++++++++++ > > > > 3 files changed, 107 insertions(+) > > > > > > > > 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/Kconfig b/drivers/input/touchscreen/Kconfig > > > > index 771d95c..76f5a9d 100644 > > > > --- a/drivers/input/touchscreen/Kconfig > > > > +++ b/drivers/input/touchscreen/Kconfig > > > > @@ -324,6 +324,7 @@ config TOUCHSCREEN_FUJITSU > > > > config TOUCHSCREEN_GOODIX > > > > tristate "Goodix I2C touchscreen" > > > > depends on I2C > > > > + depends on GPIOLIB > > > > help > > > > Say Y here if you have the Goodix touchscreen (such as one > > > > installed in Onda v975w tablets) connected to your > > > > diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c > > > > index 56d0330..87304ac 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 > > > > @@ -237,6 +243,88 @@ 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); > > > > +} > > > > + > > > > +/** > > > > + * 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; > > > > + > > > > + /* Get the interrupt GPIO pin number */ > > > > + gpiod = devm_gpiod_get(dev, GOODIX_GPIO_INT_NAME, GPIOD_IN); > > > > > > Why isn't this devm_gpiod_get_optional()? Then you would not need to > > > clobber the return value down in goodix_ts_probe(). > > > > > > > I did not use devm_gpiod_get_optional() in order to ignore more errors > > than -ENOENT. This is needed because the ACPI gpio core will fall back > > to indexed gpios if named gpios are not found. In the common case of > > having 2 indexed gpio pins declared in the ACPI table, the first > > devm_gpiod_get() will successfully get indexed gpio pin 0 and the > > second devm_gpiod_get() will try to get the same gpio pin 0 and return > > -EBUSY. Considering this, I thought it is better to just ignore all errors in > > order not to break any platforms currently using this driver. > > This seems like issue with ACPI gpio lookup implementation. If I am > requesting named gpio and it is not present then I definitely do not > need to be returned some random gpio. Doing so breaks all other drivers > that use several names to retrieve GPIOs. We basically can't trust GPIO > API on ACPI systems. > I'm not sure there is a way to avoid fall back to indexed gpios when requesting named gpios. Adding Mika to this thread as he might help answer this. > I can see why we wanted to provide unnamed gpios even in presence of > con_id, but it does not work when using several names. I wonder if > acpi_find_gpio will have to keep track of state (requested names) and > stop falling back to unnamed gpios if more than one con_id was suppolied > for the same object. > For devices that need to support more than one named gpio, the driver has to declare an acpi_gpio_mapping structure (that maps names to indexed gpios) and register it with acpi_dev_add_driver_gpios [1]. I have actually implemented this in v7 of this patchset [2], before finding out that the platforms Bastien was testing with do not support writing to the interrupt pin. In order to avoid adding exceptions to the driver through dmi quirks, the gpio dependent functionality is available only to devices that declare named gpios. Thanks, Irina [1] http://lxr.free-electrons.com/source/Documentation/acpi/gpio-properties.txt [2] https://lkml.org/lkml/2015/10/8/222 > Thanks. > > -- > Dmitry -- 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 Tue, Oct 13, 2015 at 08:54:12AM +0000, Tirdea, Irina wrote: > > > I did not use devm_gpiod_get_optional() in order to ignore more errors > > > than -ENOENT. This is needed because the ACPI gpio core will fall back > > > to indexed gpios if named gpios are not found. In the common case of > > > having 2 indexed gpio pins declared in the ACPI table, the first > > > devm_gpiod_get() will successfully get indexed gpio pin 0 and the > > > second devm_gpiod_get() will try to get the same gpio pin 0 and return > > > -EBUSY. Considering this, I thought it is better to just ignore all errors in > > > order not to break any platforms currently using this driver. > > > > This seems like issue with ACPI gpio lookup implementation. If I am > > requesting named gpio and it is not present then I definitely do not > > need to be returned some random gpio. Doing so breaks all other drivers > > that use several names to retrieve GPIOs. We basically can't trust GPIO > > API on ACPI systems. > > > > I'm not sure there is a way to avoid fall back to indexed gpios when requesting > named gpios. > Adding Mika to this thread as he might help answer this. Before ACPI 5.1 _DSD device properties were introduced all we had was an array of GPIOs returned by _CRS ACPI method. Ordering of those GPIOs could change from one vendor to another :-( We can (and do) use acpi_dev_add_driver_gpios() to pass correct mappings where _DSD is not present based on the device ACPI ID for instance. Not all drivers do that, though. I would like to get rid of the fallback completely at some point. We have had already problems with the API because then some ACPI only drivers did this: reset_gpio = gpiod_get_index(dev, NULL, 0); power_gpio = gpiod_get_index(dev, NULL, 1); which might not do what is expected on DT systems. That's why acpi_dev_add_driver_gpios() was added in the first place IIRC. -- 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 Tue, Oct 13, 2015 at 01:07:24PM +0300, mika.westerberg@linux.intel.com wrote: > On Tue, Oct 13, 2015 at 08:54:12AM +0000, Tirdea, Irina wrote: > > > > I did not use devm_gpiod_get_optional() in order to ignore more errors > > > > than -ENOENT. This is needed because the ACPI gpio core will fall back > > > > to indexed gpios if named gpios are not found. In the common case of > > > > having 2 indexed gpio pins declared in the ACPI table, the first > > > > devm_gpiod_get() will successfully get indexed gpio pin 0 and the > > > > second devm_gpiod_get() will try to get the same gpio pin 0 and return > > > > -EBUSY. Considering this, I thought it is better to just ignore all errors in > > > > order not to break any platforms currently using this driver. > > > > > > This seems like issue with ACPI gpio lookup implementation. If I am > > > requesting named gpio and it is not present then I definitely do not > > > need to be returned some random gpio. Doing so breaks all other drivers > > > that use several names to retrieve GPIOs. We basically can't trust GPIO > > > API on ACPI systems. > > > > > > > I'm not sure there is a way to avoid fall back to indexed gpios when requesting > > named gpios. > > Adding Mika to this thread as he might help answer this. > > Before ACPI 5.1 _DSD device properties were introduced all we had was an > array of GPIOs returned by _CRS ACPI method. Ordering of those GPIOs > could change from one vendor to another :-( > > We can (and do) use acpi_dev_add_driver_gpios() to pass correct mappings > where _DSD is not present based on the device ACPI ID for instance. Not > all drivers do that, though. > > I would like to get rid of the fallback completely at some point. We > have had already problems with the API because then some ACPI only > drivers did this: > > reset_gpio = gpiod_get_index(dev, NULL, 0); > power_gpio = gpiod_get_index(dev, NULL, 1); > > which might not do what is expected on DT systems. That's why > acpi_dev_add_driver_gpios() was added in the first place IIRC. I understand why one might use acpi_dev_add_driver_gpios() to augment data in ACPI, however here we have completely different issue: driver that expects named gpios gets returned gpio that has nothing to do with what it requested, because gpiolib acpi code always falls back to unnamed gpio if it does not find named gpio. That can be acceptable if driver uses the same con_id for all requests to gpiolib, but is not working when driver supplies different con_ids. Thanks.
On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > I understand why one might use acpi_dev_add_driver_gpios() to augment > data in ACPI, however here we have completely different issue: driver > that expects named gpios gets returned gpio that has nothing to do with > what it requested, because gpiolib acpi code always falls back to > unnamed gpio if it does not find named gpio. That can be acceptable if > driver uses the same con_id for all requests to gpiolib, but is not > working when driver supplies different con_ids. Right, the ACPI fallback ignores con_id completely and uses only the index. AFAIK there is only one driver using ACPI _CRS index method: sdhci-[acpi|pci].c. If we can convert that to use acpi_dev_add_driver_gpios() to feed names for card detection GPIOs, I think we can remove the fallback alltogether in favor of named GPIOs for ACPI. -- 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 Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerberg@linux.intel.com wrote: > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > data in ACPI, however here we have completely different issue: driver > > that expects named gpios gets returned gpio that has nothing to do with > > what it requested, because gpiolib acpi code always falls back to > > unnamed gpio if it does not find named gpio. That can be acceptable if > > driver uses the same con_id for all requests to gpiolib, but is not > > working when driver supplies different con_ids. > > Right, the ACPI fallback ignores con_id completely and uses only the > index. > > AFAIK there is only one driver using ACPI _CRS index method: > sdhci-[acpi|pci].c. If we can convert that to use acpi_dev_add_driver_gpios() > to feed names for card detection GPIOs, I think we can remove the > fallback alltogether in favor of named GPIOs for ACPI. Nah, there seems to be several drivers relying on this already :-/ -- 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: linux-input-owner@vger.kernel.org [mailto:linux-input-owner@vger.kernel.org] On Behalf Of > mika.westerberg@linux.intel.com > Sent: 14 October, 2015 16:44 > To: Dmitry Torokhov > Cc: Tirdea, Irina; Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > kernel@vger.kernel.org; devicetree@vger.kernel.org > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerberg@linux.intel.com wrote: > > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > > data in ACPI, however here we have completely different issue: driver > > > that expects named gpios gets returned gpio that has nothing to do with > > > what it requested, because gpiolib acpi code always falls back to > > > unnamed gpio if it does not find named gpio. That can be acceptable if > > > driver uses the same con_id for all requests to gpiolib, but is not > > > working when driver supplies different con_ids. > > > > Right, the ACPI fallback ignores con_id completely and uses only the > > index. > > > > AFAIK there is only one driver using ACPI _CRS index method: > > sdhci-[acpi|pci].c. If we can convert that to use acpi_dev_add_driver_gpios() > > to feed names for card detection GPIOs, I think we can remove the > > fallback alltogether in favor of named GPIOs for ACPI. > > Nah, there seems to be several drivers relying on this already :-/ Would it be possible to add an optional parameter to the GPIO API to specify whether we want to fall back to indexed GPIOs for ACPI? > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 Mon, Oct 19, 2015 at 02:32:24PM +0000, Tirdea, Irina wrote: > > > > -----Original Message----- > > From: linux-input-owner@vger.kernel.org [mailto:linux-input-owner@vger.kernel.org] On Behalf Of > > mika.westerberg@linux.intel.com > > Sent: 14 October, 2015 16:44 > > To: Dmitry Torokhov > > Cc: Tirdea, Irina; Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > > kernel@vger.kernel.org; devicetree@vger.kernel.org > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > > > On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerberg@linux.intel.com wrote: > > > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > > > data in ACPI, however here we have completely different issue: driver > > > > that expects named gpios gets returned gpio that has nothing to do with > > > > what it requested, because gpiolib acpi code always falls back to > > > > unnamed gpio if it does not find named gpio. That can be acceptable if > > > > driver uses the same con_id for all requests to gpiolib, but is not > > > > working when driver supplies different con_ids. > > > > > > Right, the ACPI fallback ignores con_id completely and uses only the > > > index. > > > > > > AFAIK there is only one driver using ACPI _CRS index method: > > > sdhci-[acpi|pci].c. If we can convert that to use acpi_dev_add_driver_gpios() > > > to feed names for card detection GPIOs, I think we can remove the > > > fallback alltogether in favor of named GPIOs for ACPI. > > > > Nah, there seems to be several drivers relying on this already :-/ > > Would it be possible to add an optional parameter to the GPIO API > to specify whether we want to fall back to indexed GPIOs for ACPI? I don't think it's a good idea to add ACPI specifics to generic APIs. I went through ACPI enabled drivers calling GPIO APIs and majority of them are doing this: static int stk8312_gpio_probe(struct i2c_client *client) { struct device *dev; struct gpio_desc *gpio; int ret; if (!client) return -EINVAL; dev = &client->dev; /* data ready gpio interrupt pin */ gpio = devm_gpiod_get_index(dev, STK8312_GPIO, 0, GPIOD_IN); if (IS_ERR(gpio)) { dev_err(dev, "acpi gpio get index failed\n"); return PTR_ERR(gpio); } ret = gpiod_to_irq(gpio); dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret); return ret; } We can drop all this because I2C core already handles GpioInt -> interrupt number translation. Few drivers are doing something more complex but I think we can still convert them to use acpi_dev_add_driver_gpios() and eventually get rid of the whole _CRS index lookup. -- 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 Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote: > On Mon, Oct 19, 2015 at 05:52:39PM +0300, mika.westerberg@linux.intel.com wrote: > > On Mon, Oct 19, 2015 at 02:32:24PM +0000, Tirdea, Irina wrote: > > > > > > > > > > -----Original Message----- > > > > From: linux-input-owner@vger.kernel.org [mailto:linux-input-owner@vger.kernel.org] On Behalf Of > > > > mika.westerberg@linux.intel.com > > > > Sent: 14 October, 2015 16:44 > > > > To: Dmitry Torokhov > > > > Cc: Tirdea, Irina; Bastien Nocera; Aleksei Mamlin; Karsten Merker; linux-input@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux- > > > > kernel@vger.kernel.org; devicetree@vger.kernel.org > > > > Subject: Re: [PATCH v9 2/9] Input: goodix - reset device at init > > > > > > > > On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerberg@linux.intel.com wrote: > > > > > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > > > > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > > > > > data in ACPI, however here we have completely different issue: driver > > > > > > that expects named gpios gets returned gpio that has nothing to do with > > > > > > what it requested, because gpiolib acpi code always falls back to > > > > > > unnamed gpio if it does not find named gpio. That can be acceptable if > > > > > > driver uses the same con_id for all requests to gpiolib, but is not > > > > > > working when driver supplies different con_ids. > > > > > > > > > > Right, the ACPI fallback ignores con_id completely and uses only the > > > > > index. > > > > > > > > > > AFAIK there is only one driver using ACPI _CRS index method: > > > > > sdhci-[acpi|pci].c. If we can convert that to use acpi_dev_add_driver_gpios() > > > > > to feed names for card detection GPIOs, I think we can remove the > > > > > fallback alltogether in favor of named GPIOs for ACPI. > > > > > > > > Nah, there seems to be several drivers relying on this already :-/ > > > > > > Would it be possible to add an optional parameter to the GPIO API > > > to specify whether we want to fall back to indexed GPIOs for ACPI? > > > > I don't think it's a good idea to add ACPI specifics to generic APIs. > > > > I went through ACPI enabled drivers calling GPIO APIs and majority of > > them are doing this: > > > > static int stk8312_gpio_probe(struct i2c_client *client) > > { > > struct device *dev; > > struct gpio_desc *gpio; > > int ret; > > > > if (!client) > > return -EINVAL; > > > > dev = &client->dev; > > > > /* data ready gpio interrupt pin */ > > gpio = devm_gpiod_get_index(dev, STK8312_GPIO, 0, GPIOD_IN); > > if (IS_ERR(gpio)) { > > dev_err(dev, "acpi gpio get index failed\n"); > > return PTR_ERR(gpio); > > } > > > > ret = gpiod_to_irq(gpio); > > dev_dbg(dev, "GPIO resource, no:%d irq:%d\n", desc_to_gpio(gpio), ret); > > > > return ret; > > } > > > > We can drop all this because I2C core already handles GpioInt -> interrupt > > number translation. > > > > Few drivers are doing something more complex but I think we can still convert > > them to use acpi_dev_add_driver_gpios() and eventually get rid of the whole > > _CRS index lookup. > > cpi_dev_add_driver_gpios() does not really help with generic drivers > (unless we keep adding more and more board specific data to them). How > about we keep track of names used and only allow conversion for the > first name used, like in the patch below? > > -- > Dmitry > > gpiolib: tighten up ACPI legacy gpio lookups > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > We should not fall back to the legacy unnamed gpio lookup style if the > driver requests gpios with different names, because we'll give out the same > gpio twice. Let's keep track of the names that were used for the device and > only do the fallback for the first name used. > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > drivers/gpio/gpiolib.c | 42 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index 5db3445..4ae5447 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1738,6 +1738,45 @@ static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id, > return desc; > } > > +struct acpi_gpio_lookup { > + struct list_head node; > + struct device *dev; > + const char *con_id; > +}; > + > +static DEFINE_MUTEX(acpi_gpio_lookup_lock); > +static LIST_HEAD(acpi_gpio_lookup_list); > + > +static bool acpi_can_fallback_crs(struct device *dev, const char *con_id) > +{ > + struct acpi_gpio_lookup *l, *lookup = NULL; > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + list_for_each_entry(l, &acpi_gpio_lookup_list, node) { > + if (l->dev == dev) { > + lookup = l; > + break; > + } > + } > + > + if (!lookup) { > + lookup = kmalloc(sizeof(*lookup), GFP_KERNEL); > + if (lookup) { > + lookup->dev = dev; > + lookup->con_id = con_id; > + list_add_tail(&lookup->node, &acpi_gpio_lookup_list); > + } > + } > + > + mutex_lock(&acpi_gpio_lookup_lock); This should of course be mutex_unlock() according to the awesome 0-day build bot. > + > + return lookup && > + ((!lookup->con_id && !con_id) || > + (lookup->con_id && con_id && > + strcmp(lookup->con_id, con_id) == 0)); > +} > + > static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > unsigned int idx, > enum gpio_lookup_flags *flags) > @@ -1765,7 +1804,8 @@ static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > > /* Then from plain _CRS GPIOs */ > if (IS_ERR(desc)) { > - desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); > + if (acpi_can_fallback_crs(dev, con_id)) > + desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); > if (IS_ERR(desc)) > return desc; > }
On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote: > cpi_dev_add_driver_gpios() does not really help with generic drivers > (unless we keep adding more and more board specific data to them). How > about we keep track of names used and only allow conversion for the > first name used, like in the patch below? That works but it misses one case: When you have optional GPIOs and not all of them are provided. Currently it ends up the same situation returning the same GPIO. I've commented below how we could handle that case as well. > -- > Dmitry > > gpiolib: tighten up ACPI legacy gpio lookups > > From: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > We should not fall back to the legacy unnamed gpio lookup style if the > driver requests gpios with different names, because we'll give out the same > gpio twice. Let's keep track of the names that were used for the device and > only do the fallback for the first name used. > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > drivers/gpio/gpiolib.c | 42 +++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index 5db3445..4ae5447 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -1738,6 +1738,45 @@ static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id, > return desc; > } > > +struct acpi_gpio_lookup { > + struct list_head node; > + struct device *dev; > + const char *con_id; > +}; > + > +static DEFINE_MUTEX(acpi_gpio_lookup_lock); > +static LIST_HEAD(acpi_gpio_lookup_list); > + > +static bool acpi_can_fallback_crs(struct device *dev, const char *con_id) > +{ > + struct acpi_gpio_lookup *l, *lookup = NULL; I'm thinking if we here do struct acpi_device *adev = ACPI_COMPANION(dev); /* Never fallback if the device has properties */ if (adev->data.properties || adev->driver_gpios) return false; > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + list_for_each_entry(l, &acpi_gpio_lookup_list, node) { > + if (l->dev == dev) { > + lookup = l; > + break; > + } > + } > + > + if (!lookup) { > + lookup = kmalloc(sizeof(*lookup), GFP_KERNEL); > + if (lookup) { > + lookup->dev = dev; > + lookup->con_id = con_id; > + list_add_tail(&lookup->node, &acpi_gpio_lookup_list); > + } > + } > + > + mutex_lock(&acpi_gpio_lookup_lock); > + > + return lookup && > + ((!lookup->con_id && !con_id) || > + (lookup->con_id && con_id && > + strcmp(lookup->con_id, con_id) == 0)); > +} > + > static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > unsigned int idx, > enum gpio_lookup_flags *flags) > @@ -1765,7 +1804,8 @@ static struct gpio_desc *acpi_find_gpio(struct device *dev, const char *con_id, > > /* Then from plain _CRS GPIOs */ > if (IS_ERR(desc)) { > - desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); > + if (acpi_can_fallback_crs(dev, con_id)) > + desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); and here we could do if (!acpi_can_fallback_crs(dev, con_id)) return ERR_PTR(-ENOENT); desc = acpi_get_gpiod_by_index(adev, NULL, idx, &info); So instead return -ENOENT so that gpiod_get_index_optional() handles the missing optional GPIO properly. > if (IS_ERR(desc)) > return desc; > } -- 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/Kconfig b/drivers/input/touchscreen/Kconfig index 771d95c..76f5a9d 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -324,6 +324,7 @@ config TOUCHSCREEN_FUJITSU config TOUCHSCREEN_GOODIX tristate "Goodix I2C touchscreen" depends on I2C + depends on GPIOLIB help Say Y here if you have the Goodix touchscreen (such as one installed in Onda v975w tablets) connected to your diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c index 56d0330..87304ac 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 @@ -237,6 +243,88 @@ 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); +} + +/** + * 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; + + /* 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_dbg(dev, "Failed to get %s GPIO: %d\n", + GOODIX_GPIO_INT_NAME, error); + return error; + } + 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_dbg(dev, "Failed to get %s GPIO: %d\n", + GOODIX_GPIO_RST_NAME, error); + return error; + } + ts->gpiod_rst = gpiod; + + return 0; +} + /** * goodix_read_config - Read the embedded configuration of the panel * @@ -405,6 +493,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);
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 properly 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. This functionality will not be available for devices that use indexed gpio pins declared in the _CRS section (we need to provide backward compatibility with devices that do not support using the interrupt gpio pin as output). 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> Acked-by: Bastien Nocera <hadess@hadess.net> Tested-by: Bastien Nocera <hadess@hadess.net> Tested-by: Aleksei Mamlin <mamlinav@gmail.com> --- .../bindings/input/touchscreen/goodix.txt | 5 + drivers/input/touchscreen/Kconfig | 1 + drivers/input/touchscreen/goodix.c | 101 +++++++++++++++++++++ 3 files changed, 107 insertions(+)