Pick a patch for synapitics rmi4 reset gpio support

[minlexx]

Pick a patch for synapitics rmi4 reset gpio support from its original author.

Also test all other our devices with rmi4 touchscreen, which may be affected:

$ grep -rn "rmi4-i2c" ../arch/arm64/boot/dts/qcom/sdm6*
../arch/arm64/boot/dts/qcom/sdm630-sony-xperia-nile.dtsi:168:           compatible = "syna,rmi4-i2c";
../arch/arm64/boot/dts/qcom/sdm636-motorola-beckham.dts:217:            compatible = "syna,rmi4-i2c";
../arch/arm64/boot/dts/qcom/sdm636-xiaomi-whyred.dts:168:               compatible = "syna,rmi4-i2c";
../arch/arm64/boot/dts/qcom/sdm660-bbry-common.dtsi:370:                compatible = "syna,rmi4-i2c";

any maybe remove the long delay hacks from whyred/pioneer

[minlexx]

Seems to boot fine on whyred, dmesg https://paste.sr.ht/~minlexx/cc1bc4de8a498e848d9ccf737e3eb13cba465392
touch but touch sometimes works fine, sometimes not

sometimes an error is seen:

$ sudo dmesg | grep -i rmi
[    2.995508] rmi4_i2c 0-0020: supply vdd not found, using dummy regulator
[    3.452962] rmi4_i2c 0-0020: registering I2C-connected sensor
[    3.680759] rmi4_physical rmi4-00: Could not read PDT properties from 0x00ef (code -6). Assuming 0x00.
[    3.680903] rmi4_physical rmi4-00: Read PDT entry at 0x00e9 failed, code: -6.
[    3.680914] rmi4_physical rmi4-00: IRQ counting failed with code -6.

[minlexx]

Interesting things happen when you define the same GPIO as reset-gpio for both panel and touchscreen: tons of red errors in dmesg, but finally at some moment it magically works. Does kernel have some mechanism for shared reset GPIOs now? 🤔

So for our case if you set TLMM GPIO 53 as reset-gpios = <&tlmm 53 GPIO_ACTIVE_LOW>; in both panel node and Synaptics touch node, this happens

sony-pioneer [~]# dmesg | grep -i -E '(rmi|gpu|dpu|panel)'
...
[    0.770357] platform 5000000.gpu: Adding to iommu group 0
[    8.835945] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[    8.853337] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[    9.009387] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[    9.022091] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   13.433055] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   13.450121] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   13.638796] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   13.644867] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   13.683101] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   13.687168] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   13.754447] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   13.847442] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   13.850499] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   13.853832] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.222278] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.222305] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.222563] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.275906] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.275932] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.297303] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.373436] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.373463] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.373779] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.380092] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.380114] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.380463] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.550775] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.550816] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.564742] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.691322] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.691379] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.709273] panel-td4322-truly c994000.dsi.0: cannot find GPIO chip gpiolib_shared.proxy.1, deferring
[   22.718263] rmi4_i2c 0-0070: cannot find GPIO chip gpiolib_shared.proxy.3, deferring
[   22.718301] rmi4_i2c 0-0070: failed to get reset GPIO: -517
[   22.729732] msm_dpu c901000.display-controller: bound c994000.dsi (ops dsi_ops [msm])
[   22.730185] adreno 5000000.gpu: GPU speedbin fuse 146 (0x92), mapped to opp-supp-hw 0x4
[   22.732263] adreno 5000000.gpu: supply vdd not found, using dummy regulator
[   22.732480] adreno 5000000.gpu: supply vddcx not found, using dummy regulator
[   22.741584] msm_dpu c901000.display-controller: bound 5000000.gpu (ops a3xx_ops [msm])
[   23.052093] [drm:dpu_kms_hw_init:1173] dpu hardware revision:0x30030000
[   23.110596] msm_dpu c901000.display-controller: [drm:adreno_request_fw [msm]] loaded qcom/a530_pm4.fw from new location
[   23.111807] msm_dpu c901000.display-controller: [drm:adreno_request_fw [msm]] loaded qcom/a530_pfp.fw from new location
[   23.115363] msm_dpu c901000.display-controller: [drm:adreno_request_fw [msm]] loaded qcom/a508_zap.mdt from new location
[   23.687293] msm_dpu c901000.display-controller: [drm] fb0: msmdrmfb frame buffer device
[   23.694805] rmi4_i2c 0-0070: supply vdd not found, using dummy regulator
[   23.937190] rmi4_i2c 0-0070: flipping reset-gpio and waiting for 200 ms
[   24.161734] rmi4_i2c 0-0070: registering I2C-connected sensor
[   24.372984] rmi4_f01 rmi4-00.fn01: found RMI device, manufacturer: Synaptics, product: TD4322Test, fw id: 2610092
[   24.397291] input: Synaptics TD4322Test as /devices/platform/soc@0/c175000.i2c/i2c-0/0-0070/rmi4-00/input/input3

So, initially they both fail to request GPIO, then after msm framebuffer comes online, they both suddenly probe? And it all works after that.

[minlexx]

So yeah, it seems kernel now is very smart when some gpios are specified in different nodes.

• https://elixir.bootlin.com/linux/v7.1.2/source/drivers/gpio/gpiolib-shared.c#L270
• https://elixir.bootlin.com/linux/v7.1.2/source/drivers/gpio/gpiolib-shared.c#L129

So maybe doing it like this is okay, both display and touch come reliably every boot, before failed rmi_i2c probe lead to diplay panel to not show anything, only backlight...

[minlexx]

For whyred though, resetting using GPIO_66 does nothing. If numbers in various syna,xx-delay-ms are too low - rmi4_i2c still fails to probe. It still needs to probe right after, or approximately at the same time when panel probes.

It's compltely placebo effect. What new code does here, is that if reset-gpio is defined for rmi_i2c node, then additional extra reset-delay-ms is applied, further delaying touch probe at later point in time, so it just adds more delay, allowing it to probe after display panel :D

[minlexx]

So while it seems to be partially completely useless, it makes stuation better when making use of same reset-gpios for panel/touch (like for pioneer use case, where there are no reset-gpio neither in downstream dtb, nor in shematics).

I'll pick jason's dts/yaml/makefile commits here and test it on jason too. And we'll live with it