Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 6 Jun 2023 12:02:01 -0700
From:   Dmitry Torokhov <dmitry.torokhov@gmail.com>
To:     Neil Armstrong <neil.armstrong@linaro.org>
Cc:     Hans de Goede <hdegoede@redhat.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Bastien Nocera <hadess@hadess.net>,
        Henrik Rydberg <rydberg@bitmath.org>,
        linux-input@vger.kernel.org, linux-arm-msm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/4] input: touchscreen: add initial support for
 Goodix Berlin touchscreen IC
Message-ID: <ZH+CqXOFt6WsdZ8L@google.com>
References: <20230606-topic-goodix-berlin-upstream-initial-v1-0-4a0741b8aefd@linaro.org>
 <f5f20de8-851a-fe20-4664-62b6de14ebd7@redhat.com>
 <2677ae8c-59d3-b658-dc3f-918838ac0fb6@linaro.org>
 <ZH9+ndrF0RIgFhnI@google.com>
 <665c9aa5-ef70-65ce-7d9c-4b3b93874934@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <665c9aa5-ef70-65ce-7d9c-4b3b93874934@linaro.org>
Precedence: bulk

On Tue, Jun 06, 2023 at 08:55:35PM +0200, Neil Armstrong wrote:
> 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.

OK, it looks like Hans' preference is also to have a separate driver, so
let's keep them separate.

Thanks.

-- 
Dmitry