[v3,0/5] Add support for Focaltech FTS Touchscreen

Changes in v3:(Suggested by Krzysztof Kozlowski and Konrad Dybcio)
--------------
- dts: removed the invalid "input-enable" property
- dts: replace interrupts with interrupts-extended
- dts: removed redundant dma configuration
- dts: reorder pinctrl and pinctrl-names
- bindings: moved unevaluatedProperties after required
- bindings: make interrupts a required property (new change from my end)
- bindings: update example based on dts changes

I have made the interrupts a required property in the bindings as the driver
will not function without an interrupt. Because of this new change, I have not
picked up the reviewed by tag of Krzysztof Kozlowski for the bindings.

Changes in v2:
--------------
1. dt-bindings changes (Suggested by Krzysztof Kozlowski)
	- changed file name from focaltech,fts.yaml to focaltech,fts5452.yaml
	- removed focaltech,max-touch-number property, handled in driver now
	- removed touchscreen-* properties and used unevaluatedProperties: false
	instead of additionalProperties: false
	- fixed the example dts node name to be generic
	
2. FTS Touchscreen driver changes (Suggested by Markuss Broks and Jeff LaBundy)
	- removed repeated license terms since SPDX tag is used
	- includes are now sorted
	- added the missing input_mt_sync_frame when reporting touch
	- focaltech,max-touch-number is no longer read from dts and instead
	specified in the driver as compatible data.
	- removed redundant __set_bits
	- input_mt_init_slots is now called after the axes are defined
	- irq handler now returns IRQ_NONE when there is an i2c error
	- other minor fixes and refactoring as suggested
	- renamed driver filename from focaltech_fts.c to focaltech_fts5452.c
	(Suggested by Krzysztof Kozlowski)
	
3. dts changes (Suggested by Krzysztof Kozlowski)
	- use generic touchscreen nodes
	- removed focaltech,max-touch-number property
	- irq type was specified wrongly for Poco F1 in v1. Changed the irq
	type to IRQ_TYPE_EDGE_FALLING as that is correct.

Some Clarifications on v1 comments:
-----------------------------------
1. Jeff LaBundy suggested I could read chip id with the following:
	__be16 val;
	regmap_raw_read(data->regmap, FTS_REG_CHIP_ID_H, &val, sizeof(val));
But this is not possible because FTS_REG_CHIP_ID_H and FTS_REG_CHIP_ID_L
are not continuous register, therefore reading it together as 16-bit values
will not work. So I went with what Markuss Broks suggested:
	regmap_read(data->regmap, FTS_REG_CHIP_ID_L, &id);
        regmap_read(data->regmap, FTS_REG_CHIP_ID_H, &val);
        id |= val << 8;

2. As Markuss Broks suggested, I tried to cast the buffer to struct, but 
unfortunately was not able to successfully do it. The buffer layout is 
weirdly split into 4 bits and 12 bits at someplaces which makes it hard 
to cast into a struct. For example, we can note
	type = buf[base + 3] >> 6
	x = ((buf[base + 3] & 0x0F) << 8) + (buf[base + 4] & 0xFF);
Here at buffer index 3, the first two bits (>>6) are used for denoting
event type. The next two bits are not used. But the last 4 bits (&0x0F)
of buffer[3] are added with buffer index 4 to get the x position. 
I don't know how to handle these when casting to a struct. I tried
experimenting with bitfields in struct, but to no avail. So I am sticking
with my initial implementation for now.

Kindly let me know if any further improvements are needed. Thanks.

The Focaltech FTS driver supports several variants of focaltech
touchscreens found in ~2018 era smartphones including variants found on
the PocoPhone F1 and the SHIFT6mq which are already present in mainline.
This driver is loosely based on the original driver from Focaltech and
the patches submitted by Caleb Connolly previously[1] but has been
simplified and largely reworked.

[1] https://patchwork.kernel.org/project/linux-input/patch/20220123173650.290349-3-caleb@connolly.tech/

Joel Selvaraj (5):
  dt-bindings: input: touchscreen: add focaltech,fts5452 touchscreen
  Input: add driver for Focaltech FTS touchscreen
  arm64: dts: qcom: sdm845-xiaomi-beryllium-common: add touchscreen
    related nodes
  arm64: dts: qcom: sdm845-xiaomi-beryllium-ebbg: introduce support for
    fts touchscreen
  arm64: dts: qcom: sdm845-shift-axolotl: update focaltech touchscreen
    properties

 .../input/touchscreen/focaltech,fts5452.yaml  |  71 +++
 MAINTAINERS                                   |   8 +
 .../boot/dts/qcom/sdm845-shift-axolotl.dts    |  18 +-
 .../qcom/sdm845-xiaomi-beryllium-common.dtsi  |  37 ++
 .../dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts |  21 +
 drivers/input/touchscreen/Kconfig             |  12 +
 drivers/input/touchscreen/Makefile            |   1 +
 drivers/input/touchscreen/focaltech_fts5452.c | 432 ++++++++++++++++++
 8 files changed, 590 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/touchscreen/focaltech,fts5452.yaml
 create mode 100644 drivers/input/touchscreen/focaltech_fts5452.c

On 15/04/2023 04:02, Joel Selvaraj wrote:
> Changes in v3:(Suggested by Krzysztof Kozlowski and Konrad Dybcio)
> --------------
> - dts: removed the invalid "input-enable" property
> - dts: replace interrupts with interrupts-extended
> - dts: removed redundant dma configuration
> - dts: reorder pinctrl and pinctrl-names
> - bindings: moved unevaluatedProperties after required
> - bindings: make interrupts a required property (new change from my end)
> - bindings: update example based on dts changes
> 
> I have made the interrupts a required property in the bindings as the driver
> will not function without an interrupt. Because of this new change, I have not

Driver does not really matter for the bindings. The BSD driver for
example might function without an interrupt, so why requiring it? The
reason for requiring or not is in the hardware and how it works.

Best regards,
Krzysztof

On 15/04/2023 04:02, Joel Selvaraj wrote:
> Document the Focaltech FTS touchscreen driver.
> 
> Signed-off-by: Joel Selvaraj <joelselvaraj.oss@gmail.com>
> Signed-off-by: Caleb Connolly <caleb@connolly.tech>
> ---
>  .../input/touchscreen/focaltech,fts5452.yaml  | 71 +++++++++++++++++++


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof