Add silead fw for GPD Q9

[phhusson]

This firmware has been successfully tested on mainline master 42dc814987c1feb6410904e58cfd4c36c4146150, with plasma as input consumer to confirm X/Y positions

[onitake]

Could you add an entry to https://github.com/onitake/gsl-firmware/blob/master/README.md , please?

And are you going to submit a kernel patch as well?

[phhusson]

Thanks for your answer. I'll add to the README (I kind assumed I would have done other mistakes)

I'm guessing your question about kernel patch, is that I need to specify the firmware name somewhere (in dts?). Is that correct? (for the moment I did my testing using the default firmware name). For the moment I haven't planned pushing that device tree to mainline (I probably will in due time, but I'm still at a clean-up stage)

FWIW, I have another patch that I'll need to include in kernel: phhusson/linux@e355fb7

I'm not 100% sure whether this patch is correct, or if it's a bug of my i2c controller. (Well there is no doubt that the silead chip does something weird that triggers rockchip i2c controller in that case)

[onitake]

Yes, this section in the readme explains how to patch the kernel: https://github.com/onitake/gsl-firmware#silead_ts
This is optional, of course, but if you plan to do it, I'll wait with merging until everything is ready.

As for phhusson/linux@e355fb7 , I don't really know if this is appropriate. Maybe you can take a look @jwrdegoede ? Thanks!

[jwrdegoede]

Yes, this section in the readme explains how to patch the kernel: https://github.com/onitake/gsl-firmware#silead_ts

Note this is about using the mainline silead driver on x86 devices, to address short-comings of the info in API. Where as I see that @phhusson 's kernel branch is called rk3288 so I assume that phusson is using a rockchip ARM device with devicetree so this does not apply to this specific device.

As for phhusson/linux@e355fb7

I'm not sure what to make of that. It does not look too bad. From what I'm seeing I guess that the controller drops of the i2c bus because of going into reset before the host has processed the controllers ack.

@phhusson at what speed are you running the controller? From my experience it will often cause i2c errors when being run at 100KHz did you try 400KHz ?

If this still happens with a 400KHz i2c bus speed, please submit the ignore-reset-errors patch upstream with me ([email protected]) in the Cc and then we'll see from there.