On Tue, 2015-09-29 at 17:47 +0000, Tirdea, Irina wrote:

quoted

-----Original Message-----
From: Bastien Nocera [mailto:hadess-0MeiytkfxGOsTnJN9+BGXg@public.gmane.org]
Sent: 29 September, 2015 5:04
To: Tirdea, Irina; linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Rob Herring; Pawel Moll; Ian
Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
Rutland; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init

On Fri, 2015-09-25 at 21:04 +0000, Tirdea, Irina wrote:

quoted

<snip>

quoted

quoted

The warning from your dmesg output will not cause probe to fail.
If you look at the code for byt_gpio_direction_output, it will
just
print
a warning and continue [1]:
	WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
		"Potential Error: Setting GPIO with direct_irq_en to
output");
I thought probe finishes successfully, but due to the warning in
dmesg you
are not sure whether the IRQ GPIO pin can be used as output.
If probe fails, it must be for another reason than the
direct_irq_en
warning.

quoted

Would you have a patch for me to test that would bypass this
error,
or
at least fallback gracefully to not resetting, not probing
GPIOs if
they're badly setup?

If the driver fails to initialize the GPIOs, it will at least
print
some
"Failed to get GPIO" warnings in dmesg. Do you have such messages
in
dmesg or any additional information on why probe fails?

The current code will ignore GPIOs if they are not defined in
ACPI
(see the check for -ENOENT), but does not ignore other error
codes.
If you want to bypass all GPIO errors, you can use the code
below.

The failure isn't there, it's when running goodix_i2c_test():
Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test
failed attempt 1: -121
Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: i2c test
failed attempt 2: -121
Sep 25 16:39:20 winbook kernel: Goodix-TS i2c-GDIX1001:00: I2C
communication failure: -121
Sep 25 16:39:20 winbook kernel: Goodix-TS: probe of i2c-GDIX1001:00 
failed with error -121

Are you using v6 of the patches? There was an issue with reset that
Aleksei reported
and was fixed in v6 (although he had a different i2c error and a
different scenario).

Pretty certain. Your current patchset is at:
https://github.com/hadess/gt9xx/tree/irina-tirdea

And the patches are yours, with the prefix and Documentation removed.

quoted

The GPIO setup seems to work (bar the warnings), and the reset as
well,
but then the device fails to communicate. Likely a fallout from the
reset actually failing.

Swapping around the RST and INT pins leads to the same problem.
Either
this device's GPIO PINs aren't actually functional, and the
firmware
contains garbage, or something else is wrong.

I agree. Either the interrupt pin cannot be used as output in your
configuration
or there are some specifics in the ACPI tables that prevent using
these pins. 

quoted

I'm not sure how we can detect, and blacklist, those devices. At
least
my original device, the Onda v975w, and the WinBook TW100 would
have
those problems.

I can use DMI quirks to exclude these devices from using the features
that
depend on the gpio pins. I already have the DMI information for
WinBook TW100
and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and
DMI_PRODUCT_NAME for Onda v975w so I can add it as well?

I don't have access to the Onda v975w anymore, but let me CC: a few
people that could also help with testing.

Carlos, Cosimo, Christian, there's a patchset for you to test on the
Onda v975w at:
https://github.com/hadess/gt9xx/commits/irina-tirdea

Doing an "rmmod goodix ; insmod ./goodix_backport.ko" should be enough
to test whether the patch set works. If it doesn't work correctly,
you'll need to reboot the machine, swap the irq_idx and rst_idx values
at:
https://github.com/hadess/gt9xx/commit/c27de79f494c2b2e7a198ff4d27976ae93669dbd#diff-dddc2849e36327439530f3e2faacec4fR321

and try again.

If all that fails, could you please send the output of "dmidecode" to
Irina?

Cheers
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html