devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Kaechele <felix@kaechele.ca>
To: Andreas Kemnade <andreas@kemnade.info>,
	Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: 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
Date: Thu, 25 Apr 2024 22:54:13 -0400	[thread overview]
Message-ID: <7dd1eb70-b011-4247-aea9-173ddcd17dc7@kaechele.ca> (raw)
In-Reply-To: <20240425185417.0a5f9c19@aktux>

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:
>
>> On Fri, Apr 5, 2024 at 7:28 PM Andreas Kemnade <andreas@kemnade.info> wrote: >>> On Fri, 5 Apr 2024 18:13:45 +0300
>>> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

...

>>>> Why a different vendor prefix?

...

>>> 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.
>>
>> But does the driver use that? AFAICS it uses edt. Perhaps it's due to
>> a business split, not to my knowledge anyway.

I've been looking into this over the past few weeks as I was working on 
mainline support for an Android device.
And please forgive me if any of the following is not fully accurate, I'm 
not an industry expert.

After some research, my understanding of this is as follows:

- There are companies that make touch ICs, LCD driver ICs and sometimes 
even ICs that are both. Focaltech or Himax are examples of such companies.

- There are companies that make LCMs. These are complete assemblies of 
panel, backlight, touch layer and driver circuitry PCBs. This is what 
OEMs generally purchase when they design a consumer device. Emerging 
Display Technologies Corp. (EDT) is such a LCM manufacturing company. 
More often than not LCM manufacturers do not make their own driver ICs.

LCM manufacturers include ICs from Focaltech in their LCMs.
To my knowledge Focaltech is not a manufacturer of LCMs.

As such, an interpretation of the compatible string "edt,edt-ft5406" 
could be: Unspecified EDT LCM with Focaltech FT5406 IC.

 From my perspective, more correct would either be something like 
"edt,etm070001bdh6" (the LCM by EDT that contains this IC, especially if 
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 
we have now though.

> Well, lets cite edt-ft5x06.rst:
>
> "The edt-ft5x06 driver is useful for the EDT "Polytouch" family of capacitive > touch screens. Note that it is *not* suitable for other devices based 
on the
> focaltec ft5x06 devices, since they contain vendor-specific firmware. In
> particular this driver is not suitable for the Nook tablet."

That contradicts my experience with this driver. It works fine on a BOE 
TV080WXM-LL4 LCM with a FT8201 without modifications.

> So chips from focaltech which can be equipped with different firmware?

Firmware can change, the vendor drivers support handling firmware transfers.
Apparently firmware is handled differently, depending on how a 
manufacturer designs their LCM.
They can be shipped without flash, with flash but no firmware programmed 
or complete with firmware.

In all but the last scenario the driver would have to load (and possibly 
program to flash) the firmware for the LCM to be fully operational to 
specifications. Today, this driver doesn't do that. As such the 
behaviour is unlikely to change and could as well be described in the 
devicetree instead of having the driver try guessing.

I personally would rather trust whoever is performing the integration 
work to properly describe the hardware in the devicetree if the firmware 
doesn't allow for a definitive way to identify how it would like to be 
treated.
If the driver ever gained firmware handling features I'd expect the 
filename for the firmware to be defined in the devicetree together with 
the properties describing the treatment it expects.

> So edt prefix means EDT firmware?

I don't think that's how the compatible strings are used today, but it 
is what would make sense in my opinion.

> Looking around I found this:
>              if (tsdata->version == EV_FT)
>                          swap(x, y);
> ...
>                 case 0x59:  /* Evervision Display with FT5xx6 TS */
>                          tsdata->version = EV_FT;
>
> I need swap(x.y), I am using touchscreen-swapped-x-y property now.
> So evervision prefix?

The compatible string doesn't have any bearing on whether x and y are 
swapped. The driver relies on its device detection heuristic for that 
determination.
Ideally, the driver would allow describing this property

   1. in the devicetree using the "touchscreen-swapped-x-y" property 
from the common touchscreen bindings

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

The only reason I created this wall of text is because I am intending to 
submit a very similar patch, using the "focaltech,ft8201" string. So 
getting a decision on this would be helpful for my efforts as well.

Regards,
Felix

  reply	other threads:[~2024-04-26  2:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-04 22:20 [PATCH v2 0/2] Input: add ft5426 Andreas Kemnade
2024-04-04 22:20 ` [PATCH v2 1/2] dt-bindings: input: touchscreen: edt-ft5x06: Add ft5426 Andreas Kemnade
2024-04-04 22:20 ` [PATCH v2 2/2] Input: edt-ft5x06 - add ft5426 Andreas Kemnade
2024-04-05 15:13   ` Andy Shevchenko
2024-04-05 16:28     ` Andreas Kemnade
2024-04-05 17:21       ` Andy Shevchenko
2024-04-05 18:56         ` Andreas Kemnade
2024-04-25 16:54         ` Andreas Kemnade
2024-04-26  2:54           ` Felix Kaechele [this message]
2024-04-26  7:56             ` Andreas Kemnade
2024-04-26 13:51               ` Andy Shevchenko
2024-04-26 18:53                 ` Andreas Kemnade

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7dd1eb70-b011-4247-aea9-173ddcd17dc7@kaechele.ca \
    --to=felix@kaechele.ca \
    --cc=andreas@kemnade.info \
    --cc=andy.shevchenko@gmail.com \
    --cc=caleb.connolly@linaro.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=p.puschmann@pironex.com \
    --cc=robh+dt@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=ye.xingchen@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).