lkml.org 
[lkml]   [2023]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.
>

\
 
 \ /
  Last update: 2023-06-06 20:56    [W:0.073 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site