Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 6 Jun 2023 20:55:35 +0200 | From | Neil Armstrong <> | Subject | Re: [PATCH RFC 0/4] input: touchscreen: add initial support for Goodix Berlin touchscreen IC |
| |
Hi Dmitry,
On 06/06/2023 20:44, Dmitry Torokhov wrote: > On Tue, Jun 06, 2023 at 08:12:04PM +0200, Neil Armstrong wrote: >> Hi, >> >> On 06/06/2023 17:31, Hans de Goede wrote: >>> Hi Neil, >>> >>> On 6/6/23 16:31, Neil Armstrong wrote: >>>> These touchscreen ICs support SPI, I2C and I3C interface, up to >>>> 10 finger touch, stylus and gestures events. >>>> >>>> This initial driver is derived from the Goodix goodix_ts_berlin >>>> available at [1] and [2] and only supports the GT9916 IC >>>> present on the Qualcomm SM8550 MTP & QRD touch panel. >>>> >>>> The current implementation only supports BerlinD, aka GT9916. >>>> >>>> Support for advanced features like: >>>> - Firmware & config update >>>> - Stylus events >>>> - Gestures events >>>> - Previous revisions support (BerlinA or BerlinB) >>>> is not included in current version. >>>> >>>> The current support will work with currently flashed firmware >>>> and config, and bail out if firmware or config aren't flashed yet. >>> >>> What I'm missing here / in the commit msg of >>> "input: touchscreen: add core support for Goodix Berlin Touchscreen IC" >>> >>> is an explanation why this is a new driver instead of adding >>> support to the existing goodix.c code. >>> >>> I assume you have good reasons for this, but it would be good >>> if you can write the reasons for this down. >> >> Sure, should I write it down here and/or update the commit message in a new revision ? >> >> Anyway, here's the reasons: >> - globally the event handling "looks like" the current goodix.c, but again the offsets >> are again different and none of the register address are the same, and unlike the current >> support all registers are provided by the "ic_info" structure >> - while with the current code it *could* be possible to merge it, with a lot of changes, >> the firmware management looks really different, and it would be really hard to merge. >> >> But I may be wrong, and may be misleaded by the goodix driver structure (even if it >> went through a really heavy cleaning process). >> >> Globally it seems they tried to match the "event handling" process of the previous >> generations, but the firmware interface is completely different. > > It is not unprecedented for drivers to share event processing and > implement several ways/generations of firmware update mechanisms.
Thanks for your reply, I'm perfectly aware of that, this is why I posted this as RFC.
If the event handling is vaguely similar, I'm not sure it's worth refactoring the current driver since I do not have the old and current IC datasheet nor HW to check for current support non-regression.
What I'm sure is that not a single register address, flag or struct is even close to the current upstream defined ones.
Neil
> > Thanks. >
| ![\](/images/icornerr.gif) |