[RFC 0/4] how to link a panel to a touchscreen controller driver

[RFC 0/4] how to link a panel to a touchscreen controller driver

[Martin Kepplinger]

hi,

When there's a panel/touchscreen combination that is sold as a combinded
module (with the reset line shared even), how would I connect the 2
drivers and make sure the touchscreen driver probes after the panel is ready?

I have the feeling there is https://docs.kernel.org/driver-api/device_link.html
for such cases. Can you show me examples of 2 "random" drivers connected
in this case?

In the past I also played with CONFIG_RESET_GPIO using the reset-controller
logic, but I *think* this is more for 2+ of the *same* devices connected.

Might there be yet a different way in devicetree I'm not aware of?

The below patches - for completeness - are only the workaround for what I'd
like to do, exposing the state of the panel so that the touchscreen can query
it.

thank you very much for any hints,

                               martin



Guido Günther (2):
  hack: drm: panel: mantix: Allow to query enabled state
  hack: Input: edt-ft5x06: hackery to probe after panel

Martin Kepplinger (2):
  hack: edt-ft5x06 / panel-mantix-mlaf057we51: declare
    mantix_panel_prepared() in drm_panel.h
  hack: arm64: dts: imx8mq-librem5: add purism,panel-librem5-workaround

 .../boot/dts/freescale/imx8mq-librem5.dtsi    |  1 +
 .../gpu/drm/panel/panel-mantix-mlaf057we51.c  | 12 ++++++++++
 drivers/input/touchscreen/edt-ft5x06.c        | 22 +++++++++++++++++++
 include/drm/drm_panel.h                       |  2 ++
 4 files changed, 37 insertions(+)

-- 
2.47.3

[RFC 1/4] hack: drm: panel: mantix: Allow to query enabled state

[Martin Kepplinger]

From: Guido Günther <agx@sigxcpu.org>

This will be used by the touch controller.

Signed-off-by: Guido Günther <agx@sigxcpu.org>
---
 drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
index 55664f5d5aa5d..16c0e5c6b7da7 100644
--- a/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
+++ b/drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c
@@ -40,6 +40,14 @@ struct mantix {
 	const struct drm_display_mode *default_mode;
 };
 
+static bool panel_prepared;
+
+bool mantix_panel_prepared(void)
+{
+  return panel_prepared;
+}
+EXPORT_SYMBOL_GPL(mantix_panel_prepared);
+
 static inline struct mantix *panel_to_mantix(struct drm_panel *panel)
 {
 	return container_of(panel, struct mantix, panel);
@@ -114,6 +122,8 @@ static int mantix_unprepare(struct drm_panel *panel)
 	/* T14 */
 	msleep(50);
 
+	panel_prepared = false;
+
 	return 0;
 }
 
@@ -155,6 +165,8 @@ static int mantix_prepare(struct drm_panel *panel)
 	/* T6 */
 	msleep(50);
 
+	panel_prepared = true;
+
 	return 0;
 }
 
-- 
2.47.3

[RFC 2/4] hack: edt-ft5x06 / panel-mantix-mlaf057we51: declare mantix_panel_prepared() in drm_panel.h

[Martin Kepplinger]

From: Martin Kepplinger <martin.kepplinger@puri.sm>

and use that header in the touchscreen driver. This avoids:

drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c:45:6: error: no previous prototype for 'mantix_panel_prepared' [-Werror=missing-prototypes]
   45 | bool mantix_panel_prepared(void)
      |      ^~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
---
 drivers/input/touchscreen/edt-ft5x06.c | 3 +++
 include/drm/drm_panel.h                | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index bf498bd4dea96..2a27750c76444 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -34,6 +34,9 @@
 
 #include <linux/unaligned.h>
 
+/* bool mantix_panel_prepared(void); */
+#include <drm/drm_panel.h>
+
 #define WORK_REGISTER_THRESHOLD		0x00
 #define WORK_REGISTER_REPORT_RATE	0x08
 #define WORK_REGISTER_GAIN		0x30
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 2407bfa60236f..ea43b3f908d05 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -392,4 +392,6 @@ static inline int drm_panel_of_backlight(struct drm_panel *panel)
 }
 #endif
 
+bool mantix_panel_prepared(void);
+
 #endif
-- 
2.47.3

[RFC 3/4] hack: Input: edt-ft5x06: hackery to probe after panel

[Martin Kepplinger]

From: Guido Günther <agx@sigxcpu.org>

With other probing issues out of the way (by marking LCD_1V8 always on)
it turns out we can't use either touch or DSI until we pulled both RESX
and TP_RSTN¹ so instead of guessing wait until the panel is up.

This replaces one hack (probe defers) by another (more reliable) one.

¹) This appeared to be otherwise since even a failed probe of the touch
controller (happening way too early before avdd/avee are up) is enough
and thaat only became appearend when not loading the touch controller
module at all.

Signed-off-by: Guido Günther <agx@sigxcpu.org>

When the (temporary) DT property "purism,panel-touchscreen-workaround"
is found, wait for the mantix panel to be prepared, before continuing
in probe().
---
 drivers/input/touchscreen/edt-ft5x06.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 2a27750c76444..3084ae5fc320a 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -14,6 +14,8 @@
  *    http://www.glyn.com/Products/Displays
  */
 
+#define DEBUG
+
 #include <linux/debugfs.h>
 #include <linux/delay.h>
 #include <linux/gpio/consumer.h>
@@ -964,6 +966,9 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
 			snprintf(model_name, EDT_NAME_LEN,
 				 "EVERVISION-FT5726NEi");
 			break;
+		case 0x02:   /* FT 8506 */
+			snprintf(model_name, EDT_NAME_LEN, "Focaltec FT8006P");
+			break;
 		default:
 			snprintf(model_name, EDT_NAME_LEN,
 				 "generic ft5x06 (%02x)",
@@ -1136,6 +1141,8 @@ static void edt_ft5x06_disable_regulators(void *arg)
 	regulator_disable(data->iovcc);
 }
 
+bool mantix_panel_prepared(void);
+
 static int edt_ft5x06_ts_probe(struct i2c_client *client)
 {
 	const struct i2c_device_id *id = i2c_client_get_device_id(client);
@@ -1147,6 +1154,18 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client)
 	int error;
 	u32 report_rate;
 
+	if (device_property_read_bool(&client->dev,
+				      "purism,panel-librem5-workaround")) {
+		/*
+		 * Since the Librem 5's panel handles the reset via gpio we
+		 * need to wait until the panel is up.
+		 */
+		if (!mantix_panel_prepared()) {
+			dev_dbg(&client->dev, "Panel not yet ready\n");
+			return -EPROBE_DEFER;
+		}
+	}
+
 	dev_dbg(&client->dev, "probing for EDT FT5x06 I2C\n");
 
 	tsdata = devm_kzalloc(&client->dev, sizeof(*tsdata), GFP_KERNEL);
-- 
2.47.3

[RFC 4/4] hack: arm64: dts: imx8mq-librem5: add purism, panel-librem5-workaround

[Martin Kepplinger]

From: Martin Kepplinger <martin.kepplinger@puri.sm>

Until we have a better solution, we need the touchscreen driver to
wait for the panel to be prepared, before it can continue to
execute probe().

A better driver is needed, so this is marked as a hack.
---
 arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
index 2b1b90c6b42b8..7d010258d3212 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
@@ -1248,6 +1248,7 @@ touchscreen@38 {
 		touchscreen-size-x = <720>;
 		touchscreen-size-y = <1440>;
 		vcc-supply = <&reg_lcd_1v8>;
+		purism,panel-librem5-workaround;
 	};
 };
 
-- 
2.47.3

Re: [RFC 0/4] how to link a panel to a touchscreen controller driver

[Marco Felsch]

Hi Martin,

On 25-11-19, Martin Kepplinger wrote:
> hi,
> 
> When there's a panel/touchscreen combination that is sold as a combinded
> module (with the reset line shared even), how would I connect the 2
> drivers and make sure the touchscreen driver probes after the panel is ready?
> 
> I have the feeling there is https://docs.kernel.org/driver-api/device_link.html
> for such cases. Can you show me examples of 2 "random" drivers connected
> in this case?

are you aware of the "struct drm_panel_follower" API? This doesn't
ensure that the touchscreen driver is probed after the panel driver, but
it ensures that the touchscreen power-state follows the panel
power-state.

> In the past I also played with CONFIG_RESET_GPIO using the reset-controller
> logic, but I *think* this is more for 2+ of the *same* devices connected.

Unfortunately sharing the same reset line for different devices is not
uncommon. We saw this on NXP IW61x WiFi/BT chips as well. In that
particular case, the API was changed to the reset API which you linked
above, to gain refcount support. This works very well.

> Might there be yet a different way in devicetree I'm not aware of?

You an check for the 'panel' property within the
Documentation/devicetree/bindings/input/.

Regards,
  Marco

> 
> The below patches - for completeness - are only the workaround for what I'd
> like to do, exposing the state of the panel so that the touchscreen can query
> it.
> 
> thank you very much for any hints,
> 
>                                martin
> 
> 
> 
> Guido Günther (2):
>   hack: drm: panel: mantix: Allow to query enabled state
>   hack: Input: edt-ft5x06: hackery to probe after panel
> 
> Martin Kepplinger (2):
>   hack: edt-ft5x06 / panel-mantix-mlaf057we51: declare
>     mantix_panel_prepared() in drm_panel.h
>   hack: arm64: dts: imx8mq-librem5: add purism,panel-librem5-workaround
> 
>  .../boot/dts/freescale/imx8mq-librem5.dtsi    |  1 +
>  .../gpu/drm/panel/panel-mantix-mlaf057we51.c  | 12 ++++++++++
>  drivers/input/touchscreen/edt-ft5x06.c        | 22 +++++++++++++++++++
>  include/drm/drm_panel.h                       |  2 ++
>  4 files changed, 37 insertions(+)
> 
> -- 
> 2.47.3
> 
> 
> 

-- 
#gernperDu 
#CallMeByMyFirstName

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | https://www.pengutronix.de/ |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-9    |

Re: [RFC 3/4] hack: Input: edt-ft5x06: hackery to probe after panel

[kernel test robot]

Hi Martin,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build errors:

[auto build test ERROR on dtor-input/next]
[also build test ERROR on dtor-input/for-linus staging/staging-testing staging/staging-next staging/staging-linus linus/master v6.18-rc6 next-20251121]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Martin-Kepplinger/hack-drm-panel-mantix-Allow-to-query-enabled-state/20251120-121327
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
patch link:    https://lore.kernel.org/r/20251119065109.910251-4-martink%40posteo.de
patch subject: [RFC 3/4] hack: Input: edt-ft5x06: hackery to probe after panel
config: arm-randconfig-002-20251123 (https://download.01.org/0day-ci/archive/20251123/202511230502.L6yEiuAI-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 9e9fe08b16ea2c4d9867fb4974edf2a3776d6ece)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251123/202511230502.L6yEiuAI-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511230502.L6yEiuAI-lkp@intel.com/

All errors (new ones prefixed by >>):

>> ld.lld: error: undefined symbol: mantix_panel_prepared
   >>> referenced by edt-ft5x06.c:1163 (drivers/input/touchscreen/edt-ft5x06.c:1163)
   >>>               drivers/input/touchscreen/edt-ft5x06.o:(edt_ft5x06_ts_probe) in archive vmlinux.a

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki