Received-SPF: pass (google.com: domain of linux-kernel+bounces-159664-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 26 Apr 2024 09:56:17 +0200
From: Andreas Kemnade <andreas@kemnade.info>
To: Felix Kaechele <felix@kaechele.ca>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>, dmitry.torokhov@gmail.com,
 robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
 o.rempel@pengutronix.de, u.kleine-koenig@pengutronix.de,
 hdegoede@redhat.com, ye.xingchen@zte.com.cn, p.puschmann@pironex.com,
 linux-input@vger.kernel.org, devicetree@vger.kernel.org,
 linux-kernel@vger.kernel.org, caleb.connolly@linaro.org
Subject: Re: [PATCH v2 2/2] Input: edt-ft5x06 - add ft5426
Message-ID: <20240426095617.4e442681@aktux>
In-Reply-To: <7dd1eb70-b011-4247-aea9-173ddcd17dc7@kaechele.ca>
References: <20240404222009.670685-1-andreas@kemnade.info>
	<20240404222009.670685-3-andreas@kemnade.info>
	<CAHp75VeZ9U_+1rJQjr4KvvzjYQGzfKtk+BK00vqvKcVn2-yP3g@mail.gmail.com>
	<20240405182832.4e457695@aktux>
	<CAHp75VckoDheCN-KQ0KcSk9rE_-cXFUujurtA4sK6KAixDttQQ@mail.gmail.com>
	<20240425185417.0a5f9c19@aktux>
	<7dd1eb70-b011-4247-aea9-173ddcd17dc7@kaechele.ca>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, 25 Apr 2024 22:54:13 -0400
Felix Kaechele <felix@kaechele.ca> wrote:

> On 2024-04-25 12:54, Andreas Kemnade wrote:
> > On Fri, 5 Apr 2024 20:21:19 +0300
> > Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> > =20
> >> On Fri, Apr 5, 2024 at 7:28=E2=80=AFPM Andreas Kemnade <andreas@kemnad=
e.info> wrote: >>> On Fri, 5 Apr 2024 18:13:45 +0300 =20
> >>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote: =20
>=20
> ...
>=20
> >>>> Why a different vendor prefix? =20
>=20
> ...
>=20
> >>> I sorted by the numbers. Looking at datasheets for other controllers =
I see >>> https://www.displayfuture.com/Display/datasheet/controller/FT5x06=
pdf
> >>> it only mentions FocalTech Systems Co., Ltd. =20
> >>
> >> But does the driver use that? AFAICS it uses edt. Perhaps it's due to
> >> a business split, not to my knowledge anyway. =20
>=20
> I've been looking into this over the past few weeks as I was working on=20
> mainline support for an Android device.
> And please forgive me if any of the following is not fully accurate, I'm=
=20
> not an industry expert.
>=20
> After some research, my understanding of this is as follows:
>=20
> - There are companies that make touch ICs, LCD driver ICs and sometimes=20
> even ICs that are both. Focaltech or Himax are examples of such companies.
>=20
> - There are companies that make LCMs. These are complete assemblies of=20
> panel, backlight, touch layer and driver circuitry PCBs. This is what=20
> OEMs generally purchase when they design a consumer device. Emerging=20
> Display Technologies Corp. (EDT) is such a LCM manufacturing company.=20
> More often than not LCM manufacturers do not make their own driver ICs.
>=20
> LCM manufacturers include ICs from Focaltech in their LCMs.
> To my knowledge Focaltech is not a manufacturer of LCMs.
>=20
> As such, an interpretation of the compatible string "edt,edt-ft5406"=20
> could be: Unspecified EDT LCM with Focaltech FT5406 IC.
>=20
>  From my perspective, more correct would either be something like=20
> "edt,etm070001bdh6" (the LCM by EDT that contains this IC, especially if=
=20
> it had model specific quirks) or "focaltech,ft5406".
> But "edt,edt-ft5406" is incorrect if being specific is the goal here.
> Given that the driver predates much of the DT binding rigour it's what=20
> we have now though.
>=20
I think focaltech,ft5406 is better because it is consistent with other driv=
ers/
bindings. We do not specify the display it is used on on other touchscreen
bindings. We do not specify the actual LEDs behind a LED interface chip.
And often the chip name is more easily to find out than the name of a
display.
[...]

> I don't think that's how the compatible strings are used today, but it=20
> is what would make sense in my opinion.
>=20
> > Looking around I found this:
> >              if (tsdata->version =3D=3D EV_FT)
> >                          swap(x, y);
> > ...
> >                 case 0x59:  /* Evervision Display with FT5xx6 TS */
> >                          tsdata->version =3D EV_FT;
> >
> > I need swap(x.y), I am using touchscreen-swapped-x-y property now.
> > So evervision prefix? =20
>=20
> The compatible string doesn't have any bearing on whether x and y are=20
> swapped. The driver relies on its device detection heuristic for that=20
> determination.

Well, I think, yes, it could have a bearing, on some models, maybe x is
swapped with some pressure value in some record.

> Ideally, the driver would allow describing this property
>=20
>    1. in the devicetree using the "touchscreen-swapped-x-y" property=20
> from the common touchscreen bindings
>=20
It allows that right now.
Well, the devicetree should be driver/os independent, so it describes the
hardware. so the driver should spit out the records specified as x
in the chip manual as x and the ones specified as y as y.

If the display is then wired up to the controller in an unusual way,
it can be compensated by the devicetree specification (if we go the
focaltech,ftxxxx road instead of edt,etm070001bdh6).=20

But datasheets... where are you? So we need a heuristic. I guess
the order used most is probably the one used in the data sheet.

>    2. by extending the edt_i2c_chip_data struct to hold that property=20
> and set it based on the compatible string if it is, in fact, a property=20
> of that specific IC
>=20
yes, agreed.

Regards,
Andreas