Created attachment 233011 [details] dmesg log when it fails Chuwi Hi12 tablet with Intel cherry-trail Atom Z8300 intermittently the touchscreen does not work after bootup. When it fails the dmesg log shows the error "Invalid config, using defaults" and when it works this error is not present. I've experimented with code changes here: https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c I've added... Line 197: added missing ID 9111 for Chuwi Hi12 which sets ts->cfg_len correctly Line 713: set int_trigger_type in invalid config (failure) case
Here is the dmesg log from when it is working: http://pastebin.com/cdDxpiv3
Preliminary testing from the Hi12 user reports it's no longer failing with the code changes I made. See this post and discussion thread: https://forums.linuxmint.com/viewtopic.php?f=49&t=223426&p=1213767#p1213767 I'm not a developer, so I don't know how to get this fixed merged into the mainline code.
eh, spoke too soon. It eventually failed... [ 9.999403] goodix_backport: loading out-of-tree module taints kernel. [ 9.999502] goodix_backport: module verification failed: signature and/or required key missing - tainting kernel [ 10.012314] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 [ 10.017706] Goodix-TS i2c-GDIX1001:00: dev_info: cfg_len: 186, x_max: 0, y_max: 0, touch_num: 0, trigger_type: 0 [ 10.017711] Goodix-TS i2c-GDIX1001:00: Invalid config, using defaults [ 10.017826] Goodix-TS i2c-GDIX1001:00: dev_info: cfg_len: 186, x_max: 2160, y_max: 2160, touch_num: 5, trigger_type: 1 [ 10.018021] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/808622C1:05/i2c-13/i2c-GDIX1001:00/input/input6 When it worked the log looked like this... [ 10.121234] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 [ 10.127143] Goodix-TS i2c-GDIX1001:00: dev_info: cfg_len: 186, x_max: 2160, y_max: 2160, touch_num: 10, trigger_type: 0 [ 10.127151] Goodix-TS i2c-GDIX1001:00: dev_info: cfg_len: 186, x_max: 2160, y_max: 2160, touch_num: 10, trigger_type: 0 So I changed the code to set the defaults (when read_config fails) to trigger_type=0 and put the touch_num=10 as it was originally. Awaiting test results/logs from the user.
Also note. It was reported that running modprobe on it after booting up made it work reliably/always, so maybe when it's failing it's due to it initializing too soon in the bootup sequence?
The Android source for this driver shows... #define GTP_IRQ_TAB_RISING 0 #define GTP_IRQ_TAB_FALLING 1 #if GTP_CUSTOM_CFG #define GTP_MAX_HEIGHT 800 #define GTP_MAX_WIDTH 480 #define GTP_INT_TRIGGER GTP_IRQ_TAB_RISING #else #define GTP_MAX_HEIGHT 4096 #define GTP_MAX_WIDTH 4096 #define GTP_INT_TRIGGER GTP_IRQ_TAB_FALLING #endif So in the Linux driver code when read_config is success and it works the trigger_type=0 (RISING) and when read_config fails it was defaulting to trigger_type=1 (FALLING) I changed the default from 1 to 0 to test it here: https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c
dmesg log when it's failing: http://pastebin.com/dd84n85a
emailed linux-input list: http://www.spinics.net/lists/linux-input/msg46754.html
(In reply to Brad Baker from comment #5) > The Android source for this driver shows... > > #define GTP_IRQ_TAB_RISING 0 > #define GTP_IRQ_TAB_FALLING 1 > #if GTP_CUSTOM_CFG > #define GTP_MAX_HEIGHT 800 > #define GTP_MAX_WIDTH 480 > #define GTP_INT_TRIGGER GTP_IRQ_TAB_RISING > #else > #define GTP_MAX_HEIGHT 4096 > #define GTP_MAX_WIDTH 4096 > #define GTP_INT_TRIGGER GTP_IRQ_TAB_FALLING > #endif > > So in the Linux driver code when read_config is success and it works the > trigger_type=0 (RISING) and when read_config fails it was defaulting to > trigger_type=1 (FALLING) > > I changed the default from 1 to 0 to test it here: > https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c Did this work? I had a similar issue and this workaround fixed it for me temporarily.
I had similar problems with some Goodix devices until I enabled the reset sequence: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ec6e1b4082d9f5b0858ce33169a1c22a27a982f6. Although the touch screen was initialized and I could read/write to/from the device, I read only 0s from the configuration registers. The datasheet recommends using the reset procedure at power on, so I could not find any information on how to make the device work reliably without it. Resetting the device at boot fixed the problem for me. For backwards compatibility, the reset sequence is only available if the interrupt and reset gpio pins are connected and configured through _DSD properties in the ACPI table or DT properties. I assume you have a tablet with ACPI. Could you share the ACPI table so I can see if the gpio pins are properly declared? You can find the binary acpi tables in /sys/firmware/acpi/tables/* and you can decompile them with iasl -G *.
Irina, I actually don't have one of these tablets. I'm merely trying to help a number of people get Linux running correctly on this low cost and increasingly popular brand of tablets. The logs provide are from one Ubuntu user in the above posted link to a LinuxMint forum thread. FYI, I'm not a kernel developer but I can usually figure things out despite my limited experience with Linux and C programming. I'll request the ACPI table data and post it here. Thanks for your attention to this.
Irina, decompiling with iasl -G *. on my machine did not work but I figured out what you wanted and asked that the user run this simple script. No doubt there's a more efficient method but this worked for me... mkdir ~/acpitables cd /sys/firmware/acpi/tables/ for i in * ; do sudo cat $i > ~/acpitables/$i.dat; done cd ~/acpitables for i in * ; do iasl -d $i ; done cat *.dsl >> chuwi_hi12_acpi.dsl
Irina, here is the ACPI table data you requested for this device (Chuwi Hi12 tablet) : http://pastebin.com/84cjD8kp On Mon, Sep 12, 2016 at 2:32 PM, Brad Baker <bbaker6212@gmail.com> wrote: > Irina, > The user just reported... "the TS is not working every time, here is > a log from when it is not working". The below logging appears to show > that setting the default trigger_type=0 when read_config fails does > not make a difference. His statement that it's not working *every > time* is curious because he said before it was working like 9 out of > 10 times he booted up. > > http://pastebin.com/hpWbgpTe > [ 10.922484] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 > [ 10.927791] Goodix-TS i2c-GDIX1001:00: dev_info: cfg_len: 186, > x_max: 0, y_max: 0, touch_num: 0, trigger_type: 0 > [ 10.927797] Goodix-TS i2c-GDIX1001:00: Invalid config, using defaults > [ 10.927912] Goodix-TS i2c-GDIX1001:00: dev_info: cfg_len: 186, > x_max: 2160, y_max: 2160, touch_num: 10, trigger_type: 0 > [ 10.928112] input: Goodix Capacitive TouchScreen as > /devices/pci0000:00/808622C1:05/i2c-13/i2c-GDIX1001:00/input/input6 > > source: https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c > > > Also: following is an older log prior to my code changes where > read_config was succeeding but the user reported the touchscreen was > registering touch events in the wrong place. This may have been some > fluke as he has not been reporting this type of problem happening > often or since. Also appended to the end of this log is output from > dmidecode if it's helpful: http://pastebin.com/6QWF6JB8
"GpioInt (Edge, ActiveLow, Shared, PullDefault, 0x0000, ..." According to the ACPI the proper IRQ config is IRQF_TRIGGER_FALLING for the device.
Brad, Thanks for all the information & logs. Seems to me there is more going on than just having the wrong interrupt type in this case, since it still does not work when setting trigger_type to 0. Also, as Dmitry mentioned, according to the ACPI table, the driver should work with the default of trigger_type = 1. Normally the device configuration and ACPI settings for the irq flags should match, but in this case they are opposite. The problem might be caused by not having the proper power-on timings. Given the information you provided, I made a test patch that will enable reset for the device (0001-Input-goodix-enable-reset-sequence-for-Chuwi-Hi12-ta.patch). You should also enable debug for the driver so we can see all messages (0002-Input-goodix-enable-debug.patch). The patches are rebased on top of your github code (https://github.com/blocksonic/gt9xx/commits/device-tree), so they should apply with no conflicts. Could you forward a driver with these changes to the user and check if this solves the problem?
Created attachment 233221 [details] Enable reset sequence for Goodix device on Chuwi Hi12 tablet
Created attachment 233231 [details] Enable debug for the goodix driver
Dunno if this info helps but here is the output of running lspci -vv on the tablet: http://pastebin.com/CRtPM0FL Thanks Irina, will have him run the module with your patches.
Btw, about the user's statement "it's not working every time" he realized it's failing every time starting up (powering on) but works every time when restarting.
Here are the new logs: not working: http://pastebin.com/7WbGuHwH working: http://pastebin.com/weUhWK6L However the user reports the symptoms when it's "working" now is worse than before. Now every time it's registering touches in the wrong place. One obvious thing I saw in the log is the line: [ 10.364431] Goodix-TS i2c-GDIX1001:00: Direct firmware load for goodix_9111_cfg.bin failed with error -2 This is because I added the ID 9111 to the code which is specific to the Chuwi Hi12. How can we create this firmware file (and for the Chuwi Hi10 as well)? Btw, perhaps a side note is the error: [ 7.922526] intel_sst_acpi 808622A8:00: No matching machine driver found This is the sound/audio device? It looks to be the same as the Microsoft Surface 3 tablet, which is also an Atom Cherry-Trail Z8300 device, who's audio I read was fixed in ALSA 1.1.2 yet to be rolled into kernel 4.8 The audio on the Hi12 also does not work. Should I open a separate bug on this?
(In reply to Brad Baker from comment #19) > Here are the new logs: > > not working: http://pastebin.com/7WbGuHwH > > working: http://pastebin.com/weUhWK6L > > However the user reports the symptoms when it's "working" now is worse than > before. Now every time it's registering touches in the wrong place. Is there a pattern for this wrong values of the touches? There is a setting in the device configuration that switches the X and Y axes. Do these wrong touches follow this pattern or are they just random? > One obvious thing I saw in the log is the line: > > [ 10.364431] Goodix-TS i2c-GDIX1001:00: Direct firmware load for > goodix_9111_cfg.bin failed with error -2 > > This is because I added the ID 9111 to the code which is specific to the > Chuwi Hi12. How can we create this firmware file (and for the Chuwi Hi10 as > well)? > Right. I was hoping it will work without the need to provide this configuration file, but it seems it is not the case. You can generate a configuration file based on the the device configuration when it is working. You can find documentation on how to do that in my latest patches (that have not been merged yet) [1]. I noticed you are not using the latest version of the upstream Goodix driver on github. There are no major differences between these version, but it might be best to use the latest version. You can use my github version of the driver [2]. First you need to read a working configuration from the device. You might need to revert the patch that enables reset for the Chuwi tablet [3]. With the patches from my github you can read the device configuration from /sys/class/input/input6/device/dump. Following the instructions in the documentation [1], you can generate a goodix_9111_cfg.bin file that needs to be copied to /lib/firmware. To have the configuration updated, you need to have the patch that enables reset for the Chuwi tablet [3]. Let me know if something is not clear. [1] https://github.com/itirdea/linux/commit/811fe93ef8492608c6e920a815f4b3d3e5f9fb76 [2] https://github.com/itirdea/linux/commits/goodix-chuwi [3] https://github.com/itirdea/linux/commit/8f2a62ff67233d0eb32221dc4f9bb1574a68abc4
(In reply to Brad Baker from comment #19) > Btw, perhaps a side note is the error: > > [ 7.922526] intel_sst_acpi 808622A8:00: No matching machine driver found > > This is the sound/audio device? It looks to be the same as the Microsoft > Surface 3 tablet, which is also an Atom Cherry-Trail Z8300 device, who's > audio I read was fixed in ALSA 1.1.2 yet to be rolled into kernel 4.8 > The audio on the Hi12 also does not work. Should I open a separate bug on > this? This error comes from the sound device (sound/soc/intel/atom/sst/sst_acpi.c). You should open a separate bug on this, since it is not related to the input/goodix devices and/or e-mail alsa-devel mailing list.
FYI, if it helps. Found this page showing a quirk applied that worked for another goodix tablet (ID=911) not (9111). Similar debug output to the Hi12. Scroll down to Touchscreen section: https://wiki.debian.org/InstallingDebianOn/PIPO/PIPO%20X8
(In reply to Brad Baker from comment #22) > FYI, if it helps. Found this page showing a quirk applied that worked for > another goodix tablet (ID=911) not (9111). Similar debug output to the Hi12. > Scroll down to Touchscreen section: > https://wiki.debian.org/InstallingDebianOn/PIPO/PIPO%20X8 They seem to have a similar problem with the mixed up X and Y axes. The dmi quirk applied in this case is reversing the axes. This is why I asked above if there is a pattern to the wrong touches, since it probably is something similar. As for the failure, the debug output seems quite different. The driver fails to register in the system at all, due to a GPIO/ACPI patch probably missing in 4.4, but merged in 4.5. Since you mentioned you are using 4.8-rc5 kernel, it should not be a problem.
(In reply to Irina Tirdea from comment #20) > (In reply to Brad Baker from comment #19) > > Here are the new logs: > > > > not working: http://pastebin.com/7WbGuHwH > > > > working: http://pastebin.com/weUhWK6L > > > > However the user reports the symptoms when it's "working" now is worse than > > before. Now every time it's registering touches in the wrong place. > > Is there a pattern for this wrong values of the touches? There is a setting > in the device configuration that switches the X and Y axes. Do these wrong > touches follow this pattern or are they just random? > Its reading the touches about half a inch too high. I'm guessing for lack of that firmware file.
Hi Irina, In the directions for generating the firware file I did not understand this: "set Config_Fresh to 1 and generate the binary config firmware image" Where is Config_Fresh set? Do I set it to 1 at the top of the shell script?... https://github.com/blocksonic/gt9xx/blob/device-tree/goodix-generate-fw.sh thanks, -Brad-
Also, your comment above was not clear to me... "You might need to revert the patch that enables reset for the Chuwi tablet [3]"
Irina, someone on the Chuwi user forums posted this Windows config file for the Hi12. Can this be used to generate the Linux firmware file with that script you pointed to above?... [Setting] ;UpdateCFG=0 SendCFG=1 ;Send CFG to touch IC when loading driver SleepDisable=0 PhysicalXsize=3072 ;Physical size£¬the unit is 0.1mm PhysicalYsize=1800 [Support] ESD=1 ;Driver supports ESD recovery processing ;SensorID=0 ;According to the different SensorID send different configuration GtpTool=0 ;GuitarTestPlateform tool support X2X=0 Y2Y=0 X2Y=0 Log=0 Flashless=0 ICType=GT910 PrtScreen=0 CtrlAltDel=0 HomeKeyTouchTime=1 VolumeKeyEnable=0 FingerFirst=0 PenAsFinger=0 resetRevert=0 [Feature] Pen=1 ;stylus/pen support NumberOfKey=1 ;The total number of keys supported,equal to 0 does not support key Key1=0xe3 ;0xe3 is home key,Must be a hexadecimal number Key2= Key3= Key4= [CFG] ;--------- 8047 8048 8049 804A 804B 804C 804D 804E 804F 8050 8051 8052 8053 8054 DefaultCFG=0x00,0x70,0x08,0x78,0x05,0x0A,0x7D,0x01,0x01,0x01,0x19,0x0F,0x41,0x32,0x03,0x05,0x00,0x00,0x00,0x00,0x12,0x23,0x00,0x18,0x1A,0x1E,0x14,0x95,0x35,0xFF,0x38,0x3A,0x12,0x0C,0x00,0x00,0x00,0x21,0x03,0x1D,0x16,0x18,0x1A,0xA0,0x82,0x03,0x41,0x28,0x1E,0x00,0x00,0x31,0x4F,0x94,0xD5,0x02,0x08,0x00,0x00,0x04,0x8F,0x33,0x00,0x88,0x38,0x00,0x7F,0x3E,0x00,0x79,0x44,0x00,0x73,0x4B,0x00,0x73,0x80,0x00,0x00,0x00,0xF0,0x4A,0x3A,0xFF,0xFF,0x27,0xFF,0x00,0x00,0x4A,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x2A,0x29,0x28,0x27,0x26,0x25,0x24,0x23,0x22,0x21,0x20,0x1F,0x1E,0x1D,0x1C,0x1B,0x19,0x18,0x17,0x16,0x15,0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01,0x00,0x111,0x01 ;DefaultCFG=0x00,0x70,0x08,0x78,0x05,0x0A,0x7D,0x01,0x01,0x08,0x19,0x0F,0x64,0x3C,0x03,0x05,0x00,0x00,0x00,0x00,0x12,0x23,0x00,0x18,0x1A,0x1E,0x14,0x95,0x35,0xFF,0x38,0x3A,0x12,0x0C,0x00,0x00,0x00,0x21,0x03,0x1D,0x16,0x18,0x1A,0xA0,0x82,0x03,0x41,0x28,0x1E,0x00,0x00,0x31,0x4F,0x94,0xD5,0x02,0x08,0x00,0x00,0x04,0x8F,0x33,0x00,0x88,0x38,0x00,0x7F,0x3E,0x00,0x79,0x44,0x00,0x73,0x4B,0x00,0x73,0x80,0x00,0x00,0x00,0xF0,0x4A,0x3A,0xFF,0xFF,0x27,0xFF,0x00,0x00,0x4A,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x2A,0x29,0x28,0x27,0x26,0x25,0x24,0x23,0x22,0x21,0x20,0x1F,0x1E,0x1D,0x1C,0x1B,0x19,0x18,0x17,0x16,0x15,0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01,0x00,0xDD,0x01 ;DefaultCFG=0x00,0x80,0x07,0x38,0x04,0x0A,0x7D,0x41,0x01,0x03,0x50,0x0F,0x41,0x32,0x03,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x18,0x1A,0x1E,0x14,0x95,0x15,0xFF,0x17,0x15,0xA6,0x22,0x00,0x00,0x00,0x84,0x03,0x1D,0x00,0x00,0x00,0x80,0x82,0x02,0x1E,0x23,0x14,0x0F,0x00,0x0F,0x23,0x94,0xC5,0x02,0x07,0x00,0x00,0x04,0xA0,0x10,0x00,0x8F,0x13,0x00,0x83,0x16,0x00,0x75,0x1B,0x00,0x6D,0x20,0x00,0x6D,0xF0,0x00,0x00,0x00,0x23,0xF0,0xB0,0xFF,0xFF,0x27,0x00,0x00,0x00,0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x1D,0x1C,0x1B,0x1A,0x19,0x18,0x17,0x16,0x15,0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01,0x00,0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17,0x18,0x19,0x1B,0x1C,0x1D,0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25,0x26,0x27,0x28,0x29,0x2A,0x00,0x76,0x01 senserid_0= senserid_1= senserid_2= senserid_3= senserid_4= senserid_5=
If it helps at all, here is what the user is seeing running the latest code. Is this -121 probe error due to the lack of the firmware file? My current source code pulled from Irina's: https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c [ 8.635097] goodix_backport: loading out-of-tree module taints kernel. [ 8.635878] goodix_backport: module verification failed: signature and/or required key missing - tainting kernel [ 8.644537] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 [ 8.644549] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk [ 8.679120] EFI Variables Facility v0.08 2004-May-17 [ 8.690345] pstore: using zlib compression [ 8.690382] pstore: Registered efi as persistent store backend [ 8.741171] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121 [ 8.772461] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121 [ 8.797575] Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121 [ 8.819003] SSE version of gcm_enc/dec engaged. [ 8.821731] Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121
Irina, also you may already be aware of this but in various dmesg logs I see this error ("i2c_designware: probe of 808622C1:06 failed with error -110") and wonder if it's related to the intermittent failure to read the goodix config info at startup. Though, the correlation with this Goodix TS failure is not 100%. Could it be related to the Designware DMA controller (dw_dmac) failing?... [ 8.229488] dw_dmac INTL9C60:00: Missing DT data [ 8.254307] dw_dmac INTL9C60:00: DesignWare DMA Controller, 8 channels [ 8.277530] dw_dmac INTL9C60:01: Missing DT data [ 8.297992] dw_dmac INTL9C60:01: DesignWare DMA Controller, 8 channels [ 8.318971] proc_thermal 0000:00:0b.0: enabling device (0000 -> 0002) [ 8.469729] i2c_designware 808622C1:06: I2C bus managed by PUNIT [ 8.565772] Adding 4112380k swap on /dev/mmcblk0p3. Priority:-1 extents:1 across:4112380k SSFS [ 8.569612] i2c_designware 808622C1:06: punit semaphore timed out, resetting [ 8.569635] i2c_designware 808622C1:06: PUNIT SEM: 2 [ 8.569639] ------------[ cut here ]------------ [ 8.569654] WARNING: CPU: 0 PID: 393 at /home/kernel/COD/linux/drivers/i2c/busses/i2c-designware-baytrail.c:106 baytrail_i2c_acquire+0x145/0x1e0 [i2c_designware_platform] [ 8.569656] Modules linked in: joydev cfg80211 snd_intel_sst_acpi(+) snd_intel_sst_core snd_soc_sst_mfld_platform snd_soc_sst_match snd_soc_core snd_compress ac97_bus mei_txe snd_pcm_dmaengine mei lpc_ich snd_pcm snd_seq_midi snd_seq_midi_event processor_thermal_device snd_rawmidi intel_soc_dts_iosf snd_seq snd_seq_device snd_timer hci_uart snd dw_dmac btbcm dw_dmac_core btqca btintel intel_hid sparse_keymap soundcore bluetooth i2c_designware_platform(+) i2c_designware_core rfkill pwm_lpss_platform spi_pxa2xx_platform pwm_lpss tpm_crb int3403_thermal int3400_thermal soc_button_array evdev dptf_power acpi_thermal_rel int3406_thermal int340x_thermal_zone ac acpi_pad parport_pc ppdev lp parport efivarfs autofs4 ext4 crc16 jbd2 fscrypto mbcache btrfs xor raid6_pq dm_mirror dm_region_hash dm_log dm_mod [ 8.569733] hid_logitech_hidpp hid_logitech_dj usbhid hid mmc_block i915 i2c_algo_bit crc32c_intel xhci_pci drm_kms_helper xhci_hcd syscopyarea sysfillrect sysimgblt fb_sys_fops usbcore drm sdhci_pci usb_common thermal video fjes sdhci_acpi sdhci mmc_core pinctrl_cherryview button [ 8.569768] CPU: 0 PID: 393 Comm: systemd-udevd Tainted: G W 4.8.0-040800rc8-generic #201609252231 [ 8.569769] Hardware name: Default string Default string/Cherry Trail CR, BIOS 5.11 04/28/2016 [ 8.569773] 0000000000000286 00000000cf2040f1 ffffffffad35ade4 0000000000000000 [ 8.569779] 0000000000000000 ffffffffad07f8ae 00000000ffffff92 ffff9e9031a9a818 [ 8.569784] 00000000fffee363 ffffffffc06f4870 00000000fffee34a ffff9e903a16b410 [ 8.569789] Call Trace: [ 8.569800] [<ffffffffad35ade4>] ? dump_stack+0x5c/0x78 [ 8.569807] [<ffffffffad07f8ae>] ? __warn+0xbe/0xe0 [ 8.569812] [<ffffffffc06f38b5>] ? baytrail_i2c_acquire+0x145/0x1e0 [i2c_designware_platform] [ 8.569818] [<ffffffffc06e022e>] ? i2c_dw_init+0x1e/0x450 [i2c_designware_core] [ 8.569822] [<ffffffffc06e1034>] ? i2c_dw_probe+0x34/0x1c0 [i2c_designware_core] [ 8.569829] [<ffffffffad4bfabe>] ? pm_runtime_forbid+0x4e/0x50 [ 8.569833] [<ffffffffc06f348a>] ? dw_i2c_plat_probe+0x1da/0x420 [i2c_designware_platform] [ 8.569838] [<ffffffffad4b5f3a>] ? platform_drv_probe+0x4a/0xb0 [ 8.569841] [<ffffffffad4b0266>] ? devices_kset_move_last+0x46/0x90 [ 8.569845] [<ffffffffad4b3fca>] ? driver_probe_device+0x21a/0x420 [ 8.569848] [<ffffffffad4b42aa>] ? __driver_attach+0xda/0xe0 [ 8.569852] [<ffffffffad4b41d0>] ? driver_probe_device+0x420/0x420 [ 8.569854] [<ffffffffad4b1ae7>] ? bus_for_each_dev+0x67/0xb0 [ 8.569858] [<ffffffffad4b319a>] ? bus_add_driver+0x16a/0x260 [ 8.569860] [<ffffffffc06f8000>] ? 0xffffffffc06f8000 [ 8.569864] [<ffffffffad4b4c07>] ? driver_register+0x57/0xc0 [ 8.569866] [<ffffffffc06f8000>] ? 0xffffffffc06f8000 [ 8.569872] [<ffffffffad00218b>] ? do_one_initcall+0x4b/0x180 [ 8.569877] [<ffffffffad1f1940>] ? kmem_cache_alloc_trace+0x150/0x1d0 [ 8.569882] [<ffffffffad1884dc>] ? do_init_module+0x5b/0x1ed [ 8.569887] [<ffffffffad10b7e8>] ? load_module+0x1938/0x1ca0 [ 8.569889] [<ffffffffad107990>] ? m_show+0x1b0/0x1b0 [ 8.569895] [<ffffffffad10bd96>] ? SYSC_finit_module+0xc6/0xf0 [ 8.569901] [<ffffffffad6e31b6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 8.569903] ---[ end trace b16951fabdaf6745 ]--- [ 8.569907] i2c_designware 808622C1:06: couldn't acquire bus ownership [ 8.569965] i2c_designware: probe of 808622C1:06 failed with error -110 [ 8.618186] intel_sst_acpi 808622A8:00: No matching machine driver found [ 8.635097] goodix_backport: loading out-of-tree module taints kernel. [ 8.635878] goodix_backport: module verification failed: signature and/or required key missing - tainting kernel [ 8.644537] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 [ 8.644549] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk [ 8.679120] EFI Variables Facility v0.08 2004-May-17 [ 8.690345] pstore: using zlib compression [ 8.690382] pstore: Registered efi as persistent store backend [ 8.741171] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121 [ 8.772461] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121 [ 8.797575] Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121 [ 8.819003] SSE version of gcm_enc/dec engaged. [ 8.821731] Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121
(In reply to Brad Baker from comment #25) > Hi Irina, In the directions for generating the firware file I did not > understand this: > "set Config_Fresh to 1 and generate the binary config firmware image" > Where is Config_Fresh set? Do I set it to 1 at the top of the shell > script?... > https://github.com/blocksonic/gt9xx/blob/device-tree/goodix-generate-fw.sh > > thanks, -Brad- Config_Fresh is set by the goodix-generate-fw.sh [1]. If you are using the goodix-generate-fw.sh you only need to provide the desired configuration and the script will update all needed information (set Config_Fresh, compute the checksum and convert the text configuration to a binary firmware file needed by the driver). The format of the Goodix configuration firmware is described in the datasheet [2] (section 6.2 b) of GT911 datasheet.pdf). In short, it has 186 bytes (for gt911) with the following format: byte 1 - config_version ... byte 185 - config_checksum byte 186 - config_fresh Config_fresh is the last byte of the configuration firmware and it signals the device that this is a new firmware and it needs to update it. So when generating a new configuration we need to make sure Config_Fresh is 1 so that the device will update it. [1] https://github.com/itirdea/linux/commit/811fe93ef8492608c6e920a815f4b3d3e5f9fb76#diff-a801683e0dcab41ee35eb23f1370feb1R147 [2] https://drive.google.com/folderview?id=0BxCVOQS3ZymGfmJyY2RKbE5XbVlKNlktVTlwV0lxNEdxd2dzeWZER094cmJPVnMxN1F0Yzg&usp=sharing
(In reply to Brad Baker from comment #27) > Irina, someone on the Chuwi user forums posted this Windows config file for > the Hi12. Can this be used to generate the Linux firmware file with that > script you pointed to above?... > > [Setting] > ;UpdateCFG=0 > SendCFG=1 ;Send CFG to touch IC when loading driver > SleepDisable=0 > PhysicalXsize=3072 ;Physical size£¬the unit is 0.1mm > PhysicalYsize=1800 > > [Support] > ESD=1 ;Driver supports ESD recovery processing > ;SensorID=0 ;According to the different SensorID send different > configuration > GtpTool=0 ;GuitarTestPlateform tool support > X2X=0 > Y2Y=0 > X2Y=0 > Log=0 > Flashless=0 > ICType=GT910 > PrtScreen=0 > CtrlAltDel=0 > HomeKeyTouchTime=1 > VolumeKeyEnable=0 > FingerFirst=0 > PenAsFinger=0 > resetRevert=0 > > [Feature] > Pen=1 ;stylus/pen support > NumberOfKey=1 ;The total number of keys supported,equal to 0 does not > support key > Key1=0xe3 ;0xe3 is home key,Must be a hexadecimal number > Key2= > Key3= > Key4= > > [CFG] > ;--------- 8047 8048 8049 804A 804B 804C 804D 804E 804F 8050 8051 8052 8053 > 8054 > DefaultCFG=0x00,0x70,0x08,0x78,0x05,0x0A,0x7D,0x01,0x01,0x01,0x19,0x0F,0x41, > 0x32,0x03,0x05,0x00,0x00,0x00,0x00,0x12,0x23,0x00,0x18,0x1A,0x1E,0x14,0x95, > 0x35,0xFF,0x38,0x3A,0x12,0x0C,0x00,0x00,0x00,0x21,0x03,0x1D,0x16,0x18,0x1A, > 0xA0,0x82,0x03,0x41,0x28,0x1E,0x00,0x00,0x31,0x4F,0x94,0xD5,0x02,0x08,0x00, > 0x00,0x04,0x8F,0x33,0x00,0x88,0x38,0x00,0x7F,0x3E,0x00,0x79,0x44,0x00,0x73, > 0x4B,0x00,0x73,0x80,0x00,0x00,0x00,0xF0,0x4A,0x3A,0xFF,0xFF,0x27,0xFF,0x00, > 0x00,0x4A,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x02,0x03,0x04,0x05, > 0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14, > 0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x2A,0x29,0x28,0x27,0x26,0x25, > 0x24,0x23,0x22,0x21,0x20,0x1F,0x1E,0x1D,0x1C,0x1B,0x19,0x18,0x17,0x16,0x15, > 0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09,0x08,0x07,0x06, > 0x05,0x04,0x03,0x02,0x01,0x00,0x111,0x01 > ;DefaultCFG=0x00,0x70,0x08,0x78,0x05,0x0A,0x7D,0x01,0x01,0x08,0x19,0x0F,0x64, > 0x3C,0x03,0x05,0x00,0x00,0x00,0x00,0x12,0x23,0x00,0x18,0x1A,0x1E,0x14,0x95, > 0x35,0xFF,0x38,0x3A,0x12,0x0C,0x00,0x00,0x00,0x21,0x03,0x1D,0x16,0x18,0x1A, > 0xA0,0x82,0x03,0x41,0x28,0x1E,0x00,0x00,0x31,0x4F,0x94,0xD5,0x02,0x08,0x00, > 0x00,0x04,0x8F,0x33,0x00,0x88,0x38,0x00,0x7F,0x3E,0x00,0x79,0x44,0x00,0x73, > 0x4B,0x00,0x73,0x80,0x00,0x00,0x00,0xF0,0x4A,0x3A,0xFF,0xFF,0x27,0xFF,0x00, > 0x00,0x4A,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x01,0x02,0x03,0x04,0x05, > 0x06,0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14, > 0x15,0x16,0x17,0x18,0x19,0x1A,0x1B,0x1C,0x1D,0x2A,0x29,0x28,0x27,0x26,0x25, > 0x24,0x23,0x22,0x21,0x20,0x1F,0x1E,0x1D,0x1C,0x1B,0x19,0x18,0x17,0x16,0x15, > 0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09,0x08,0x07,0x06, > 0x05,0x04,0x03,0x02,0x01,0x00,0xDD,0x01 > ;DefaultCFG=0x00,0x80,0x07,0x38,0x04,0x0A,0x7D,0x41,0x01,0x03,0x50,0x0F,0x41, > 0x32,0x03,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x04,0x18,0x1A,0x1E,0x14,0x95, > 0x15,0xFF,0x17,0x15,0xA6,0x22,0x00,0x00,0x00,0x84,0x03,0x1D,0x00,0x00,0x00, > 0x80,0x82,0x02,0x1E,0x23,0x14,0x0F,0x00,0x0F,0x23,0x94,0xC5,0x02,0x07,0x00, > 0x00,0x04,0xA0,0x10,0x00,0x8F,0x13,0x00,0x83,0x16,0x00,0x75,0x1B,0x00,0x6D, > 0x20,0x00,0x6D,0xF0,0x00,0x00,0x00,0x23,0xF0,0xB0,0xFF,0xFF,0x27,0x00,0x00, > 0x00,0x0F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, > 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x1D,0x1C,0x1B,0x1A,0x19,0x18, > 0x17,0x16,0x15,0x14,0x13,0x12,0x11,0x10,0x0F,0x0E,0x0D,0x0C,0x0B,0x0A,0x09, > 0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01,0x00,0x01,0x02,0x03,0x04,0x05,0x06, > 0x07,0x08,0x09,0x0A,0x0B,0x0C,0x0D,0x0E,0x0F,0x10,0x11,0x12,0x13,0x14,0x15, > 0x16,0x17,0x18,0x19,0x1B,0x1C,0x1D,0x1E,0x1F,0x20,0x21,0x22,0x23,0x24,0x25, > 0x26,0x27,0x28,0x29,0x2A,0x00,0x76,0x01 > > senserid_0= > senserid_1= > senserid_2= > senserid_3= > senserid_4= > senserid_5= Yes. The config firmware should be one of the DefaultCFG. However, since you have 3 DefaultCFG entries above, I am not sure which one you can use. If you will read /sys/class/input/input6/device/dump, you will probably find similar values to one of the DefaultCFG entries above. Since you already have a Linux working configuration (the one that works after reset and not after reboot), you could use that one to make sure it works consistently for both reboot and reset.
(In reply to Brad Baker from comment #28) > If it helps at all, here is what the user is seeing running the latest code. > Is this -121 probe error due to the lack of the firmware file? > My current source code pulled from Irina's: > https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c > > [ 8.635097] goodix_backport: loading out-of-tree module taints kernel. > [ 8.635878] goodix_backport: module verification failed: signature and/or > required key missing - tainting kernel > [ 8.644537] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 > [ 8.644549] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk > [ 8.679120] EFI Variables Facility v0.08 2004-May-17 > [ 8.690345] pstore: using zlib compression > [ 8.690382] pstore: Registered efi as persistent store backend > [ 8.741171] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121 > [ 8.772461] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121 > [ 8.797575] Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121 > [ 8.819003] SSE version of gcm_enc/dec engaged. > [ 8.821731] Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121 No, this is not due to the firmware file. The driver does not manage to communicate with the device at all (driver probe fails with error 121: "Remote I/O error"). The problem comes from the I2C bus which fails to initialize ("i2c_designware: probe of 808622C1:06 failed with error -110"). 808622C1 is the I2C controller and it seems to fail to initialize due to connection timing out (110). You mentioned that you cloned my git repository, which was based on the latest linux mainline tree at that time. Probably between 4.8-rc5 (your working version) and my github tree version, some i2c designware patches messed thing up. I think the easiest thing at this point would be to use your working version of the linux tree (4.8-rc5) and just cherry-pick the patches you need from my github.
(In reply to Irina Tirdea from comment #31) > (In reply to Brad Baker from comment #27) > > Irina, someone on the Chuwi user forums posted this Windows config file for > > the Hi12. Can this be used to generate the Linux firmware file with that > > script you pointed to above?... > > > > [Setting] > > ;UpdateCFG=0 ... > > senserid_5= > > Yes. The config firmware should be one of the DefaultCFG. However, since you > have 3 DefaultCFG entries above, I am not sure which one you can use. If you > will read /sys/class/input/input6/device/dump, you will probably find > similar values to one of the DefaultCFG entries above. > > Since you already have a Linux working configuration (the one that works > after reset and not after reboot), you could use that one to make sure it > works consistently for both reboot and reset. Irina, thanks for the reply. I'll give it a try. Probably the first uncommented DefaultCFG will work. Multiple people on the Chuwi forum reported it worked and/or worked better than their previous config. About your last paragraph, are you saying that I should NOT have pulled and used your latest code? What I did was was changed to use your code and only added two lines - a debug logging line in read_config and added the '9111' ID for the Hi12 in the case statement that checks the device ID. You can diff my code to see: https://github.com/blocksonic/gt9xx (sorry, as I said I'm not yet great with using Git and diff/patches so I just do things manually :-)
(In reply to Irina Tirdea from comment #32) > (In reply to Brad Baker from comment #28) > > If it helps at all, here is what the user is seeing running the latest > code. > > Is this -121 probe error due to the lack of the firmware file? > > My current source code pulled from Irina's: > > https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c > > > > [ 8.635097] goodix_backport: loading out-of-tree module taints kernel. > > [ 8.635878] goodix_backport: module verification failed: signature > and/or > > required key missing - tainting kernel > > [ 8.644537] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 > > [ 8.644549] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk > > [ 8.679120] EFI Variables Facility v0.08 2004-May-17 > > [ 8.690345] pstore: using zlib compression > > [ 8.690382] pstore: Registered efi as persistent store backend > > [ 8.741171] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121 > > [ 8.772461] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121 > > [ 8.797575] Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121 > > [ 8.819003] SSE version of gcm_enc/dec engaged. > > [ 8.821731] Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121 > > No, this is not due to the firmware file. The driver does not manage to > communicate with the device at all (driver probe fails with error 121: > "Remote I/O error"). > > The problem comes from the I2C bus which fails to initialize > ("i2c_designware: probe of 808622C1:06 failed with error -110"). 808622C1 is > the I2C controller and it seems to fail to initialize due to connection > timing out (110). > > You mentioned that you cloned my git repository, which was based on the > latest linux mainline tree at that time. Probably between 4.8-rc5 (your > working version) and my github tree version, some i2c designware patches > messed thing up. > > I think the easiest thing at this point would be to use your working version > of the linux tree (4.8-rc5) and just cherry-pick the patches you need from > my github. Irina, How do I determine which of your patches I need, and which I do not? I am not really clear on what all the things you have done/added and why.
(In reply to Brad Baker from comment #26) > Also, your comment above was not clear to me... > "You might need to revert the patch that enables reset for the Chuwi tablet > [3]" OK, let me try to clarify that. There are 3 steps you need to do (and 2 separate builds of the driver). 1. First you should read a working firmware configuration from the device. To do that, you should start from a working linux kernel version (probably 4.8-rc5). This is best in order to avoid the i2c issue you mentioned above. You should start with the 4.8-rc5 kernel version of the Goodix driver (without any additional patches). As you mentioned, in this configuration the Goodix touch should work perfectly after reboot and have some touch problems after power on. On this kernel tree, you should apply the "Input: goodix - add sysfs interface to dump config" patch from my github tree [1]. This patch exposes the /sys/class/input/input6/device/dump interface so that you can read the firmware configuration. With this version of the driver, you should observe the same behaviour for the touch, but now you should have the dump entry in sysfs (/sys/class/input/input6/device/dump). After reboot (so that everything works with the touchscreen), you should read /sys/class/input/input6/device/dump to a new file goodix_9111_cfg. 2. Once you have the text version of the working firmware configuration, all you need to do is run the goodix-generate-fw.sh script: ./goodix-generate-fw.sh goodix_9111_cfg This should generate a goodix_9111_cfg.bin file (the binary version of the configuration firmware, with the config_fresh field set to 1). 3. To write the firmware to the device, you will need to do another build of the driver. Starting from the linux kernel from step 1, you should add one more patch: just apply patch "Input: goodix - enable reset sequence for Chuwi Hi12 tablet" [2] from my github tree. This patch will enable the reset sequence and will allow writing the firmware for the Chuwi Hi12 tablet. You should also copy the goodix_9111_cfg.bin file in /lib/firmware. With this version, you should be able to test if the firmware will fix the power on issue. [1] https://github.com/itirdea/linux/commit/13008b8535120c4a35f0bc8951895455cd706290 [2] https://github.com/itirdea/linux/commit/8f2a62ff67233d0eb32221dc4f9bb1574a68abc4
Irina, thank you so much for taking the time to educate me on this. Hopefully I can appy what I learn to help get this working on various cherry-trail devices. There is a big interest from users to get Linux running on lots of different inexpensive China-branded Atom Z8300 tablets. cheers, -Brad-
(In reply to Brad Baker from comment #33) > (In reply to Irina Tirdea from comment #31) > > (In reply to Brad Baker from comment #27) > > > Irina, someone on the Chuwi user forums posted this Windows config file > for > > > the Hi12. Can this be used to generate the Linux firmware file with that > > > script you pointed to above?... > > > > > > [Setting] > > > ;UpdateCFG=0 > ... > > > senserid_5= > > > > Yes. The config firmware should be one of the DefaultCFG. However, since > you > > have 3 DefaultCFG entries above, I am not sure which one you can use. If > you > > will read /sys/class/input/input6/device/dump, you will probably find > > similar values to one of the DefaultCFG entries above. > > > > Since you already have a Linux working configuration (the one that works > > after reset and not after reboot), you could use that one to make sure it > > works consistently for both reboot and reset. > > Irina, thanks for the reply. I'll give it a try. > Probably the first uncommented DefaultCFG will work. Multiple people on the > Chuwi forum reported it worked and/or worked better than their previous > config. > Please note that the format of the Windows config is a little bit different from what goodix-generate-fw.sh expects. If you want to use the windows version, you should just copy the content of the DefaultCFG entry to a separate file and remove the "0x" prefix from all values. You should also check that the checksum is correct and that config_fresh is set to one (see my previous comment on what these values are). Then you should convert it to binary using the goodix-generate-fw.sh script. Alternatively, if other people already used this they might give you the binary to use. However, you should still try to read you current configuration first (as I mentioned in a previous reply). The new firmware might not be updated if the current config_version is higher than the one in the DefaultCFG. > About your last paragraph, are you saying that I should NOT have pulled and > used your latest code? What I did was was changed to use your code and only > added two lines - a debug logging line in read_config and added the '9111' > ID for the Hi12 in the case statement that checks the device ID. You can > diff my code to see: https://github.com/blocksonic/gt9xx (sorry, as I said > I'm not yet great with using Git and diff/patches so I just do things > manually :-) No, it was OK to pull my latest code. I would have probably done the same :-). Unfortunately, it seems that in the meantime something got broken in the I2C code (unrelated to the touch). This is why I suggested to get back to a working kernel version.
(In reply to Brad Baker from comment #34) > (In reply to Irina Tirdea from comment #32) > > (In reply to Brad Baker from comment #28) > > > If it helps at all, here is what the user is seeing running the latest > code. > > > Is this -121 probe error due to the lack of the firmware file? > > > My current source code pulled from Irina's: > > > https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c > > > > > > [ 8.635097] goodix_backport: loading out-of-tree module taints kernel. > > > [ 8.635878] goodix_backport: module verification failed: signature > and/or > > > required key missing - tainting kernel > > > [ 8.644537] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 > > > [ 8.644549] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk > > > [ 8.679120] EFI Variables Facility v0.08 2004-May-17 > > > [ 8.690345] pstore: using zlib compression > > > [ 8.690382] pstore: Registered efi as persistent store backend > > > [ 8.741171] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121 > > > [ 8.772461] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121 > > > [ 8.797575] Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121 > > > [ 8.819003] SSE version of gcm_enc/dec engaged. > > > [ 8.821731] Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121 > > > > No, this is not due to the firmware file. The driver does not manage to > > communicate with the device at all (driver probe fails with error 121: > > "Remote I/O error"). > > > > The problem comes from the I2C bus which fails to initialize > > ("i2c_designware: probe of 808622C1:06 failed with error -110"). 808622C1 > is > > the I2C controller and it seems to fail to initialize due to connection > > timing out (110). > > > > You mentioned that you cloned my git repository, which was based on the > > latest linux mainline tree at that time. Probably between 4.8-rc5 (your > > working version) and my github tree version, some i2c designware patches > > messed thing up. > > > > I think the easiest thing at this point would be to use your working > version > > of the linux tree (4.8-rc5) and just cherry-pick the patches you need from > > my github. > > Irina, How do I determine which of your patches I need, and which I do not? > I am not really clear on what all the things you have done/added and why. You probably need only 3 patches (used for the 2 builds I mentioned in my previous reply): [1], [2] and [3]. You can just save these files from your browser, since the ones I referenced here are already in patch format. Once you have the files you can apply them to your kernel version with git am filename.patch. [1] https://github.com/itirdea/linux/commit/13008b8535120c4a35f0bc8951895455cd706290.patch [2] https://github.com/itirdea/linux/commit/8f2a62ff67233d0eb32221dc4f9bb1574a68abc4.patch [3] https://github.com/itirdea/linux/commit/a107dfdbc1a71c10b4ef9d7f93b75d0963207bf5.patch
(In reply to Brad Baker from comment #36) > Irina, thank you so much for taking the time to educate me on this. > Hopefully I can appy what I learn to help get this working on various > cherry-trail devices. There is a big interest from users to get Linux > running on lots of different inexpensive China-branded Atom Z8300 tablets. > cheers, -Brad- Glad to help :-). This is quite a tricky touch screen and we have also encountered multiple problems with it. I hope writing the right firmware will fix these issues.
Hi Irina, another Hi12 user was able to take your code from (patch [1] of Comment 38 above) and create the firmware file. He says his touchscreen is now working with this. You can see his repo pulled from you [1] with the additional folder [2] containing the config data, firmware binary, and build script. This does not have the addition I made with the device ID '9111' that was being reported for the Hi12 tablet. Not sure if that's important. So, where do we go from here? [1] https://gitlab.com/SergK/chuwi_hi12/tree/master [2] https://gitlab.com/SergK/chuwi_hi12/tree/master/genfw
(In reply to Brad Baker from comment #40) > Hi Irina, another Hi12 user was able to take your code from (patch [1] of > Comment 38 above) and create the firmware file. He says his touchscreen is > now working with this. You can see his repo pulled from you [1] with the > additional folder [2] containing the config data, firmware binary, and build > script. This does not have the addition I made with the device ID '9111' > that was being reported for the Hi12 tablet. Not sure if that's important. > So, where do we go from here? > > [1] > https://gitlab.com/SergK/chuwi_hi12/tree/master > > [2] > https://gitlab.com/SergK/chuwi_hi12/tree/master/genfw He said he used this release ubuntu-16.10-beta2-desktop-amd64.iso
(In reply to Brad Baker from comment #41) > (In reply to Brad Baker from comment #40) > > Hi Irina, another Hi12 user was able to take your code from (patch [1] of > > Comment 38 above) and create the firmware file. He says his touchscreen is > > now working with this. You can see his repo pulled from you [1] with the > > additional folder [2] containing the config data, firmware binary, and > build > > script. This does not have the addition I made with the device ID '9111' > > that was being reported for the Hi12 tablet. Not sure if that's important. > > So, where do we go from here? > > > > [1] > > https://gitlab.com/SergK/chuwi_hi12/tree/master > > > > [2] > > https://gitlab.com/SergK/chuwi_hi12/tree/master/genfw > > He said he used this release ubuntu-16.10-beta2-desktop-amd64.iso Great! Probably the different kernel version in the Ubuntu image changes platform boot timings and the touch screen has time to initialize properly. If I understand correctly, this works with the kernel driver from the Ubuntu 16.10 image without any additional patches. I also took a look at sergk's git tree and he does not seem to write any firmware to the device. If this solves all problems, you can close this bug. If not, you can try to write the firmware if you run into platforms that still have problems.
Irina, he later said he tried the newest code on Arch Linux and the kernel goodix (not backport driver) worked fine without firmware. That's odd. I wonder if his Hi12 had different BIOS or other changes than other people's tablet... "actually I think no need to do nothing - have remastering my arch, now I am on 4.8.1 - standard goodix works fine! All that is needed -rmmod, modprobe. on my HI12 works fine, but have no so many time to test it thoroughsly. the wonder is ;-) even not present any firmware!"
Do you think his results may possibly be that that previous I2C problem was fixed in later Kernel release?... "probe of i2c-GDIX1001:00 failed with error -121"
(In reply to Brad Baker from comment #43) > Irina, he later said he tried the newest code on Arch Linux and the kernel > goodix (not backport driver) worked fine without firmware. That's odd. I > wonder if his Hi12 had different BIOS or other changes than other people's > tablet... > > "actually I think no need to do nothing - have remastering my arch, now I am > on 4.8.1 - standard goodix works fine! > All that is needed -rmmod, modprobe. > on my HI12 works fine, but have no so many time to test it thoroughsly. > the wonder is ;-) even not present any firmware!" Wait - is he removing the module and then inserting it again? Isn't that the same workaround you mentioned for the other platforms? You mentioned that the kernel driver did not work at power on, but it did work after rmmod and modprobe. It seems to me this is the same situation. Am I missing something?
(In reply to Brad Baker from comment #44) > Do you think his results may possibly be that that previous I2C problem was > fixed in later Kernel release?... > > "probe of i2c-GDIX1001:00 failed with error -121" We have run into 2 issues related to the touchscreen in this bug: 1. The i2c problem you mentioned above. This was not present in the version you tested with (4.8-rc5), but was present in some later version which I used for my github tree. Most likely it was fixed in a later version. 2. The goodix touchscreen problem which is the real scope of this bug: goodix touchscreen fails to provide accurate touches after power on, but works after reboot. You mentioned that a workaround was to remove and insert the module again. This has probably not been fixed in the goodix driver (since there are no other changes merged for the goodix driver after 4.8-rc5 (which you are using). However, different configurations might behave differently.
(In reply to Irina Tirdea from comment #45) > (In reply to Brad Baker from comment #43) > > Irina, he later said he tried the newest code on Arch Linux and the kernel > > goodix (not backport driver) worked fine without firmware. That's odd. I > > wonder if his Hi12 had different BIOS or other changes than other people's > > tablet... > > > > "actually I think no need to do nothing - have remastering my arch, now I > am > > on 4.8.1 - standard goodix works fine! > > All that is needed -rmmod, modprobe. > > on my HI12 works fine, but have no so many time to test it thoroughsly. > > the wonder is ;-) even not present any firmware!" > > Wait - is he removing the module and then inserting it again? Isn't that the > same workaround you mentioned for the other platforms? You mentioned that > the kernel driver did not work at power on, but it did work after rmmod and > modprobe. It seems to me this is the same situation. Am I missing something? ah, I think you're right. I did not notice and/or think enough about what he was saying. I think you're right. He just reloaded the driver, which really is not a fix.
(In reply to Brad Baker from comment #47) > (In reply to Irina Tirdea from comment #45) > > (In reply to Brad Baker from comment #43) > > > Irina, he later said he tried the newest code on Arch Linux and the > kernel > > > goodix (not backport driver) worked fine without firmware. That's odd. > I > > > wonder if his Hi12 had different BIOS or other changes than other > people's > > > tablet... > > > > > > "actually I think no need to do nothing - have remastering my arch, now I > am > > > on 4.8.1 - standard goodix works fine! > > > All that is needed -rmmod, modprobe. > > > on my HI12 works fine, but have no so many time to test it thoroughsly. > > > the wonder is ;-) even not present any firmware!" > > > > Wait - is he removing the module and then inserting it again? Isn't that > the > > same workaround you mentioned for the other platforms? You mentioned that > > the kernel driver did not work at power on, but it did work after rmmod and > > modprobe. It seems to me this is the same situation. Am I missing > something? > > ah, I think you're right. I did not notice and/or think enough about what he > was saying. I think you're right. He just reloaded the driver, which really > is not a fix. Sergk, was not involved in the discussion thread with the previous Hi12 user, and I think he did not have much time and was just looking for how to get his TS working sufficiently enough to use.
(In reply to Irina Tirdea from comment #46) > (In reply to Brad Baker from comment #44) > > Do you think his results may possibly be that that previous I2C problem was > > fixed in later Kernel release?... > > > > "probe of i2c-GDIX1001:00 failed with error -121" > > We have run into 2 issues related to the touchscreen in this bug: > > 1. The i2c problem you mentioned above. This was not present in the version > you tested with (4.8-rc5), but was present in some later version which I > used for my github tree. Most likely it was fixed in a later version. > > 2. The goodix touchscreen problem which is the real scope of this bug: > goodix touchscreen fails to provide accurate touches after power on, but > works after reboot. You mentioned that a workaround was to remove and insert > the module again. This has probably not been fixed in the goodix driver > (since there are no other changes merged for the goodix driver after 4.8-rc5 > (which you are using). However, different configurations might behave > differently. OK understood. Thanks for clarifying. I think Sergk is too busy to followup so this might have to wait until some other Hi12 users get involved in the LinuxMint thread [1] where previous users had given input. [1] https://forums.linuxmint.com/viewtopic.php?p=1227530#p1227190
Irina, When I have the time, I might take another stab at building the driver that loads the firmware file now that we have from Sergk. There are enough users that want this so I'm sure another will come along willing to test it. Will advise later. Cheers, -Brad-
(In reply to Brad Baker from comment #40) This does not have the addition I made with the device ID '9111' > that was being reported for the Hi12 tablet. Not sure if that's important. Actually, that change is important. You need to add your change to both builds I mentioned in comment #35. Otherwise, the firmware write might fail due to invalid length of the firmware.
(In reply to Brad Baker from comment #50) > Irina, When I have the time, I might take another stab at building the > driver that loads the firmware file now that we have from Sergk. There are > enough users that want this so I'm sure another will come along willing to > test it. Will advise later. Cheers, -Brad- OK. You might start with the kernel version from Ubuntu, which you know now that does not have the i2c bug. Also, besides the instructions in comment #35, you need to add you change that updates the firmware size for touch screen ID 9111 (in both step 1 and step 2).
(In reply to Irina Tirdea from comment #51) > (In reply to Brad Baker from comment #40) > This does not have the addition I made with the device ID '9111' > > that was being reported for the Hi12 tablet. Not sure if that's important. > > Actually, that change is important. You need to add your change to both > builds I mentioned in comment #35. Otherwise, the firmware write might fail > due to invalid length of the firmware. That's what I thought and why I made the comment to find out if you agree. I was trying to confirm what I thought about how the driver works :)
(In reply to Irina Tirdea from comment #52) > (In reply to Brad Baker from comment #50) > > Irina, When I have the time, I might take another stab at building the > > driver that loads the firmware file now that we have from Sergk. There are > > enough users that want this so I'm sure another will come along willing to > > test it. Will advise later. Cheers, -Brad- > > OK. You might start with the kernel version from Ubuntu, which you know now > that does not have the i2c bug. Also, besides the instructions in comment > #35, you need to add you change that updates the firmware size for touch > screen ID 9111 (in both step 1 and step 2). OK where should I pull the kernel code from?
(In reply to Brad Baker from comment #54) > (In reply to Irina Tirdea from comment #52) > > (In reply to Brad Baker from comment #50) > > > Irina, When I have the time, I might take another stab at building the > > > driver that loads the firmware file now that we have from Sergk. There > are > > > enough users that want this so I'm sure another will come along willing > to > > > test it. Will advise later. Cheers, -Brad- > > > > OK. You might start with the kernel version from Ubuntu, which you know now > > that does not have the i2c bug. Also, besides the instructions in comment > > #35, you need to add you change that updates the firmware size for touch > > screen ID 9111 (in both step 1 and step 2). > > OK where should I pull the kernel code from? You might use the stable kernel 4.8.2 [1] or find the Ubuntu git sources for their latest release. [1] https://www.kernel.org/
Hi Irina, I just saw some firmware related patches to the goodix touchscreen driver submitted on the linux-input list. Should I apply these (only), or in addition to your patches (before or after?), and before adding my Hi12 specific changes? thanks, -Brad- [PATCH 0/4] Input: goodix - Support dynamic reconfiguration Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com>
(In reply to Brad Baker from comment #56) > Hi Irina, I just saw some firmware related patches to the goodix > touchscreen driver submitted on the linux-input list. Should I apply these > (only), or in addition to your patches (before or after?), and before adding > my Hi12 specific changes? thanks, -Brad- > > [PATCH 0/4] Input: goodix - Support dynamic reconfiguration > Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> These patches are mostly relevant for devices that are using device tree, so you don't need them.
Created attachment 250681 [details] Turbostat for CHI running Manjaro w/4.10-rc2 auto-demotion is also helpful with 4.10-rc2 with Manjaro Cinnamon on ASUS T100CHI (~80 hours w/o freeze.) I also see the "msr 0 offset 0x3fe read failed: Input/output error". Will resume testing with 4.8.16 (Mint)
Hello, I have Chuwi Hi12 tablet and the Goodix touch screen stopped working after kernel 4.13. On 4.12 it does work , but requires to do rmmod goodix and modprobe goodix, I made a systemd service which does it after sddm.service. On >=4.13, including the latest 4.14-rc3, it does not help, and it does not work anyhow. Dmesg from 4.12 with working touchscreen: $ cat dmesg4_12.log | grep -i goodix [ 6.166582] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 [ 6.173840] Goodix-TS i2c-GDIX1001:00: Invalid config, using defaults [ 6.173997] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/808622C1:05/i2c-13/i2c-GDIX1001:00/input/input7 [ 25.146197] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 [ 25.153807] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/808622C1:05/i2c-13/i2c-GDIX1001:00/input/input11 From 4.14-rc3 with NOT working touchscreen: $ cat dmesg4_14rc3.log | grep -i goodix [ 7.332504] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 [ 7.341796] Goodix-TS i2c-GDIX1001:00: Invalid config, using defaults [ 7.341950] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/808622C1:05/i2c-5/i2c-GDIX1001:00/input/input7 [ 25.029432] Goodix-TS i2c-GDIX1001:00: ID 9111, version: 1060 [ 25.036726] Goodix-TS i2c-GDIX1001:00: Invalid config, using defaults [ 25.037066] input: Goodix Capacitive TouchScreen as /devices/pci0000:00/808622C1:05/i2c-5/i2c-GDIX1001:00/input/input13 They seem to be the same. Error in reading the config error does not prevent it from working in 4.12. More insormation about the hardware and logs from my system are available here: https://linux-hardware.org/index.php?probe=432a39d713
Irina, on Chuwi hi12 I made a systemd service which rmmod goodix; sleep 5; modprobe goodix after loading sddm.service, and the touch screen worked. Starting from 4.13 the touchscreen does not work in any way, this patch was applied in 4.13 https://github.com/itirdea/linux/commit/8f2a62ff67233d0eb32221dc4f9bb1574a68abc4#diff-9d3c60168cd7beddb5bb6670b2e3d4aa
I disabled that systemd service and the Goodix touchscreen still does not work on Chuwi Hi12 on Linux >= 4.13 (I thought that maybe it works only on the fist module load and does not on the next ones after module reloading, but no).
I have built 4.13 with https://github.com/kernins/linux-chwhi12/blob/master/drivers/input/touchscreen/goodix.c , and there touchscreen works correctly without the need of reloading the module 'goodix'
(In reply to Irina Tirdea from comment #38) > (In reply to Brad Baker from comment #34) > > (In reply to Irina Tirdea from comment #32) > > > (In reply to Brad Baker from comment #28) > > > > If it helps at all, here is what the user is seeing running the latest > > code. > > > > Is this -121 probe error due to the lack of the firmware file? > > > > My current source code pulled from Irina's: > > > > https://github.com/blocksonic/gt9xx/blob/device-tree/goodix.c > > > > > > > > [ 8.635097] goodix_backport: loading out-of-tree module taints > kernel. > > > > [ 8.635878] goodix_backport: module verification failed: signature > > and/or > > > > required key missing - tainting kernel > > > > [ 8.644537] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 > > > > [ 8.644549] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk > > > > [ 8.679120] EFI Variables Facility v0.08 2004-May-17 > > > > [ 8.690345] pstore: using zlib compression > > > > [ 8.690382] pstore: Registered efi as persistent store backend > > > > [ 8.741171] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: > -121 > > > > [ 8.772461] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: > -121 > > > > [ 8.797575] Goodix-TS i2c-GDIX1001:00: I2C communication failure: > -121 > > > > [ 8.819003] SSE version of gcm_enc/dec engaged. > > > > [ 8.821731] Goodix-TS: probe of i2c-GDIX1001:00 failed with error > -121 > > > > > > No, this is not due to the firmware file. The driver does not manage to > > > communicate with the device at all (driver probe fails with error 121: > > > "Remote I/O error"). > > > > > > The problem comes from the I2C bus which fails to initialize > > > ("i2c_designware: probe of 808622C1:06 failed with error -110"). 808622C1 > > is > > > the I2C controller and it seems to fail to initialize due to connection > > > timing out (110). > > > > > > You mentioned that you cloned my git repository, which was based on the > > > latest linux mainline tree at that time. Probably between 4.8-rc5 (your > > > working version) and my github tree version, some i2c designware patches > > > messed thing up. > > > > > > I think the easiest thing at this point would be to use your working > > version > > > of the linux tree (4.8-rc5) and just cherry-pick the patches you need > from > > > my github. > > > > Irina, How do I determine which of your patches I need, and which I do not? > > I am not really clear on what all the things you have done/added and why. > > You probably need only 3 patches (used for the 2 builds I mentioned in my > previous reply): [1], [2] and [3]. > > You can just save these files from your browser, since the ones I referenced > here are already in patch format. Once you have the files you can apply them > to your kernel version with git am filename.patch. > > [1] > https://github.com/itirdea/linux/commit/ > 13008b8535120c4a35f0bc8951895455cd706290.patch > [2] > https://github.com/itirdea/linux/commit/ > 8f2a62ff67233d0eb32221dc4f9bb1574a68abc4.patch > [3] > https://github.com/itirdea/linux/commit/ > a107dfdbc1a71c10b4ef9d7f93b75d0963207bf5.patch Alcatel Plus 10 has similar problem,want to get the dump_config to generate a bin file. only add these three patch on 4.20 kernel, add Alcatel Plus 10 dmi quirk, error -121 [ 6.511180] Goodix-TS i2c-GDIX1001:00: I2C Address: 0x14 [ 6.511203] Goodix-TS i2c-GDIX1001:00: Applying gpios quirk [ 6.597413] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 1: -121 [ 6.620464] Goodix-TS i2c-GDIX1001:00: i2c test failed attempt 2: -121 [ 6.643027] Goodix-TS i2c-GDIX1001:00: I2C communication failure: -121 [ 6.677149] Goodix-TS: probe of i2c-GDIX1001:00 failed with error -121