> -----Original Message----- > From: linux-input-owner@xxxxxxxxxxxxxxx [mailto:linux-input-owner@xxxxxxxxxxxxxxx] On Behalf Of Bastien Nocera > Sent: 09 June, 2015 18:53 > To: Tirdea, Irina > Cc: Dmitry Torokhov; Mark Rutland; linux-input@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; Rob > Herring; Pawel Moll; Ian Campbell; Kumar Gala; Purdila, Octavian > Subject: Re: [PATCH v2 4/8] input: goodix: reset device at init > > On Tue, 2015-06-09 at 17:34 +0200, Bastien Nocera wrote: > > On Mon, 2015-06-08 at 17:37 +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 breaks the touchscreen on my Onda v975w: > > [ 239.732858] Goodix-TS i2c-GDIX1001:00: ID 9271, version: 1020 > > [ 239.732977] Goodix-TS i2c-GDIX1001:00: Failed to get reset GPIO: > > -16 > > [ 239.736071] Goodix-TS: probe of i2c-GDIX1001:00 failed with error > > -16 > > > > This is the DSDT for that device: > > https://bugzilla.kernel.org/attachment.cgi?id=149331 > Oops. That's right - I am using named interrupts which are available only for ACPI 5.1, so devices already out there will not work. The problem here is that handling -ENOENT will not help. The gpio pins are declared in the ACPI DSDT, but are not named. The devm_gpiod_get API will look for the named interrupt first and fallback to searching by index if not found. Index will be 0 in both cases, this is why the first call will succeed and the second will fail with -EBUSY. One way to handle this would be to use indexed gpio pins instead of named gpio pins: e.g. consider the first gpio pin to be the reset pin and the second to be the interrupt pin. This is used in other drivers as well, e.g. zforce_ts. The problem with this approach is that any devices that declare the gpio pins in reversed order in the DSDT will not work and give no warning (the pins will be requested successfully, but some of the functionality will not work). The DSDT mentioned in https://bugzilla.kernel.org/attachment.cgi?id=149331 lists the reset pin first, while I am working on some devices that declare the interrupt gpio pin first. Another way to handle this is to treat -EBUSY like -ENOENT and not use any functionality that depends on the gpio pins. Unfortunately, this means we will not have suspend, esd and custom configs even if the pins are connected on the board and available in ACPI(just not named). I would go with the first approach and document the order requested for the pins, but I would like to hear what you think first. Is there a better way to do this? > (Note that this means that I haven't been able to test any following > patches in that series than 4/8). Sure, that makes sense. The following patches depend on the gpio pins so they would not have worked either. Thanks, Irina > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{��)��^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
