[PATCH v1 0/3] gpio: Add gpio-delay support

[PATCH v1 0/3] gpio: Add gpio-delay support

[Alexander Stein]

Hello everyone,

thanks for the feedback I've received. This is the first non-RFC series for
adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.

Changes compared to RFC v2 are mentioned in each patch.

Thanks and best regards,
Alexander

Alexander Stein (3):
  dt-bindings: gpio: Add gpio-delay binding document
  gpio: Add gpio delay driver
  [DNI] arm64: dts: mba8mx: Use gpio-delay for LVDS bridge

 .../devicetree/bindings/gpio/gpio-delay.yaml  |  79 +++++++++
 arch/arm64/boot/dts/freescale/mba8mx.dtsi     |  10 +-
 drivers/gpio/Kconfig                          |   8 +
 drivers/gpio/Makefile                         |   1 +
 drivers/gpio/gpio-delay.c                     | 164 ++++++++++++++++++
 5 files changed, 261 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-delay.yaml
 create mode 100644 drivers/gpio/gpio-delay.c

-- 
2.34.1

[PATCH v1 1/3] dt-bindings: gpio: Add gpio-delay binding document

[Alexander Stein]

This adds bindings for a GPIO enable/disable delay driver.

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes since RFC v2:
* Remove 'input' prefix for GPIOs
* Add minItems/maxItems for GPIOs
* Adjust example
* Added Linus' A-b

 .../devicetree/bindings/gpio/gpio-delay.yaml  | 79 +++++++++++++++++++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/gpio-delay.yaml

diff --git a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
new file mode 100644
index 000000000000..7c16a4e1a768
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/gpio-delay.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO delay controller
+
+maintainers:
+  - Alexander Stein <linux@ew.tq-group.com>
+
+description: |
+  This binding describes an electrical setup where setting an GPIO output
+  is delayed by some external setup, e.g. RC curcuit.
+
+  +----------+                    +-----------+
+  |          |             VCC_B  |           |
+  |          |              |     |           |
+  |          | VCC_A        _     |           |
+  |  GPIO    |             | | R  |  Consumer |
+  |controller|        ___  |_|    |           |
+  |          |       |   |  |     |           |
+  |      [IOx|-------|   |--+-----|-----+     |
+  |          |       |___|  |     |   input   |
+  |          |              |     |           |
+  +----------+             --- C  +-----------+
+                           ---
+                            |
+                            -
+                           GND
+
+  If the input on the consumer is controlled by an open-drain signal
+  attached to an RC curcuit the ramp-up delay is not under control
+  of the GPIO controller.
+
+properties:
+  compatible:
+    const: gpio-delay
+
+  "#gpio-cells":
+    description: |
+      Specifies the pin, ramp-up and ramp-down delays. The
+      delays are specified in microseconds.
+    const: 3
+
+  gpios:
+    description: Array of GPIOs which output signal change is delayed
+    minItems: 1
+    maxItems: 32
+
+  gpio-controller: true
+
+  gpio-line-names:
+    minItems: 1
+    maxItems: 32
+
+required:
+  - compatible
+  - "#gpio-cells"
+  - gpio-controller
+  - gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    enable_delay: enable-delay {
+        compatible = "gpio-delay";
+        #gpio-cells = <3>;
+        gpio-controller;
+        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
+                <&gpio3 1 GPIO_ACTIVE_HIGH>;
+    };
+
+    consumer {
+        enable-gpios = <&enable_delay 0 130000 30000>;
+    };
-- 
2.34.1

Re: [PATCH v1 1/3] dt-bindings: gpio: Add gpio-delay binding document

[Krzysztof Kozlowski]

On 06/04/2023 11:33, Alexander Stein wrote:
> This adds bindings for a GPIO enable/disable delay driver.
> 
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---


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

Best regards,
Krzysztof

Re: [PATCH v1 1/3] dt-bindings: gpio: Add gpio-delay binding document

[Bartosz Golaszewski]

On Thu, Apr 6, 2023 at 11:33 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
>
> This adds bindings for a GPIO enable/disable delay driver.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Changes since RFC v2:
> * Remove 'input' prefix for GPIOs
> * Add minItems/maxItems for GPIOs
> * Adjust example
> * Added Linus' A-b
>
>  .../devicetree/bindings/gpio/gpio-delay.yaml  | 79 +++++++++++++++++++
>  1 file changed, 79 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-delay.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-delay.yaml b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
> new file mode 100644
> index 000000000000..7c16a4e1a768
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-delay.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/gpio-delay.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: GPIO delay controller
> +
> +maintainers:
> +  - Alexander Stein <linux@ew.tq-group.com>
> +
> +description: |
> +  This binding describes an electrical setup where setting an GPIO output
> +  is delayed by some external setup, e.g. RC curcuit.
> +
> +  +----------+                    +-----------+
> +  |          |             VCC_B  |           |
> +  |          |              |     |           |
> +  |          | VCC_A        _     |           |
> +  |  GPIO    |             | | R  |  Consumer |
> +  |controller|        ___  |_|    |           |
> +  |          |       |   |  |     |           |
> +  |      [IOx|-------|   |--+-----|-----+     |
> +  |          |       |___|  |     |   input   |
> +  |          |              |     |           |
> +  +----------+             --- C  +-----------+
> +                           ---
> +                            |
> +                            -
> +                           GND
> +
> +  If the input on the consumer is controlled by an open-drain signal
> +  attached to an RC curcuit the ramp-up delay is not under control
> +  of the GPIO controller.
> +
> +properties:
> +  compatible:
> +    const: gpio-delay
> +
> +  "#gpio-cells":
> +    description: |
> +      Specifies the pin, ramp-up and ramp-down delays. The
> +      delays are specified in microseconds.
> +    const: 3
> +
> +  gpios:
> +    description: Array of GPIOs which output signal change is delayed
> +    minItems: 1
> +    maxItems: 32
> +
> +  gpio-controller: true
> +
> +  gpio-line-names:
> +    minItems: 1
> +    maxItems: 32
> +
> +required:
> +  - compatible
> +  - "#gpio-cells"
> +  - gpio-controller
> +  - gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    enable_delay: enable-delay {
> +        compatible = "gpio-delay";
> +        #gpio-cells = <3>;
> +        gpio-controller;
> +        gpios = <&gpio0 3 GPIO_ACTIVE_LOW>,
> +                <&gpio3 1 GPIO_ACTIVE_HIGH>;
> +    };
> +
> +    consumer {
> +        enable-gpios = <&enable_delay 0 130000 30000>;
> +    };
> --
> 2.34.1
>

Applied, thanks!

Bart

[PATCH v1 2/3] gpio: Add gpio delay driver

[Alexander Stein]

This driver implements a GPIO enable/disable delay. It supports a list
of GPIO outputs, which ramp-up/ramp-down delay can be specified at
consumer location.
The main purpose is to address external, passive delays upon line
voltage changes.

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
Changes since RFC v2:
* Removed 'input' con_id
* Added Linus' A-b

 drivers/gpio/Kconfig      |   8 ++
 drivers/gpio/Makefile     |   1 +
 drivers/gpio/gpio-delay.c | 164 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 173 insertions(+)
 create mode 100644 drivers/gpio/gpio-delay.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 5521f060d58e..87c79d7a4aea 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -1733,6 +1733,14 @@ config GPIO_AGGREGATOR
 	      industrial control context, to be operated from userspace using
 	      the GPIO chardev interface.
 
+config GPIO_DELAY
+	tristate "GPIO delay"
+	help
+	  Say yes here to enable the GPIO delay, which provides a way to
+	  configure platform specific delays for GPIO ramp-up or ramp-down
+	  delays. This can serve the following purposes:
+	    - Open-drain output using an RC filter
+
 config GPIO_LATCH
 	tristate "GPIO latch driver"
 	help
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 20036af3acb1..abb6ead17d83 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_GPIO_DA9052)		+= gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)		+= gpio-da9055.o
 obj-$(CONFIG_GPIO_DAVINCI)		+= gpio-davinci.o
 obj-$(CONFIG_GPIO_DLN2)			+= gpio-dln2.o
+obj-$(CONFIG_GPIO_DELAY)		+= gpio-delay.o
 obj-$(CONFIG_GPIO_DWAPB)		+= gpio-dwapb.o
 obj-$(CONFIG_GPIO_EIC_SPRD)		+= gpio-eic-sprd.o
 obj-$(CONFIG_GPIO_ELKHARTLAKE)		+= gpio-elkhartlake.o
diff --git a/drivers/gpio/gpio-delay.c b/drivers/gpio/gpio-delay.c
new file mode 100644
index 000000000000..b489b561b225
--- /dev/null
+++ b/drivers/gpio/gpio-delay.c
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2022 TQ-Systems GmbH
+ * Author: Alexander Stein <linux@ew.tq-group.com>
+ */
+
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+#include <linux/gpio/driver.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/platform_device.h>
+#include <linux/delay.h>
+
+#include "gpiolib.h"
+
+struct gpio_delay_timing {
+	unsigned long ramp_up_delay_us;
+	unsigned long ramp_down_delay_us;
+};
+
+struct gpio_delay_priv {
+	struct gpio_chip gc;
+	struct gpio_descs *input_gpio;
+	struct gpio_delay_timing *delay_timings;
+};
+
+static int gpio_delay_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+	return GPIO_LINE_DIRECTION_OUT;
+}
+
+static void gpio_delay_set(struct gpio_chip *gc, unsigned int offset, int val)
+{
+	struct gpio_delay_priv *priv = gpiochip_get_data(gc);
+	struct gpio_desc *gpio_desc = priv->input_gpio->desc[offset];
+	const struct gpio_delay_timing *delay_timings;
+	bool ramp_up;
+
+	gpiod_set_value(gpio_desc, val);
+
+	delay_timings = &priv->delay_timings[offset];
+	ramp_up = (!gpiod_is_active_low(gpio_desc) && val) ||
+		  (gpiod_is_active_low(gpio_desc) && !val);
+
+	if (ramp_up && delay_timings->ramp_up_delay_us)
+		udelay(delay_timings->ramp_up_delay_us);
+	if (!ramp_up && delay_timings->ramp_down_delay_us)
+		udelay(delay_timings->ramp_down_delay_us);
+}
+
+static void gpio_delay_set_can_sleep(struct gpio_chip *gc, unsigned int offset, int val)
+{
+	struct gpio_delay_priv *priv = gpiochip_get_data(gc);
+	struct gpio_desc *gpio_desc = priv->input_gpio->desc[offset];
+	const struct gpio_delay_timing *delay_timings;
+	bool ramp_up;
+
+	gpiod_set_value_cansleep(gpio_desc, val);
+
+	delay_timings = &priv->delay_timings[offset];
+	ramp_up = (!gpiod_is_active_low(gpio_desc) && val) ||
+		  (gpiod_is_active_low(gpio_desc) && !val);
+
+	if (ramp_up && delay_timings->ramp_up_delay_us)
+		fsleep(delay_timings->ramp_up_delay_us);
+	if (!ramp_up && delay_timings->ramp_down_delay_us)
+		fsleep(delay_timings->ramp_down_delay_us);
+}
+
+static int gpio_delay_of_xlate(struct gpio_chip *gc,
+			       const struct of_phandle_args *gpiospec,
+			       u32 *flags)
+{
+	struct gpio_delay_priv *priv = gpiochip_get_data(gc);
+	struct gpio_delay_timing *timings;
+	u32 line;
+
+	if (gpiospec->args_count != gc->of_gpio_n_cells)
+		return -EINVAL;
+
+	line = gpiospec->args[0];
+	if (line >= gc->ngpio)
+		return -EINVAL;
+
+	timings = &priv->delay_timings[line];
+	timings->ramp_up_delay_us = gpiospec->args[1];
+	timings->ramp_down_delay_us = gpiospec->args[2];
+
+	return line;
+}
+
+static bool gpio_delay_can_sleep(const struct gpio_delay_priv *priv)
+{
+	int i;
+
+	for (i = 0; i < priv->input_gpio->ndescs; i++)
+		if (gpiod_cansleep(priv->input_gpio->desc[i]))
+			return true;
+
+	return false;
+}
+
+static int gpio_delay_probe(struct platform_device *pdev)
+{
+	struct gpio_delay_priv *priv;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	priv->input_gpio = devm_gpiod_get_array(&pdev->dev, NULL, GPIOD_OUT_LOW);
+	if (IS_ERR(priv->input_gpio))
+		return dev_err_probe(&pdev->dev, PTR_ERR(priv->input_gpio),
+				     "Failed to get input-gpios");
+
+	priv->delay_timings = devm_kcalloc(&pdev->dev,
+					   priv->input_gpio->ndescs,
+					   sizeof(*priv->delay_timings),
+					   GFP_KERNEL);
+	if (!priv->delay_timings)
+		return -ENOMEM;
+
+	if (gpio_delay_can_sleep(priv)) {
+		priv->gc.can_sleep = true;
+		priv->gc.set = gpio_delay_set_can_sleep;
+	} else {
+		priv->gc.can_sleep = false;
+		priv->gc.set = gpio_delay_set;
+	}
+
+	priv->gc.get_direction = gpio_delay_get_direction;
+	priv->gc.of_xlate = gpio_delay_of_xlate;
+	priv->gc.of_gpio_n_cells = 3;
+	priv->gc.ngpio = priv->input_gpio->ndescs;
+	priv->gc.owner = THIS_MODULE;
+	priv->gc.base = -1;
+	priv->gc.parent = &pdev->dev;
+
+	platform_set_drvdata(pdev, priv);
+
+	return devm_gpiochip_add_data(&pdev->dev, &priv->gc, priv);
+}
+
+static const struct of_device_id gpio_delay_ids[] = {
+	{
+		.compatible = "gpio-delay",
+	},
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, gpio_delay_ids);
+
+static struct platform_driver gpio_delay_driver = {
+	.driver	= {
+		.name		= "gpio-delay",
+		.of_match_table	= gpio_delay_ids,
+	},
+	.probe	= gpio_delay_probe,
+};
+module_platform_driver(gpio_delay_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Alexander Stein <alexander.stein@ew.tq-group.com>");
+MODULE_DESCRIPTION("GPIO delay driver");
-- 
2.34.1

Re: [PATCH v1 2/3] gpio: Add gpio delay driver

[Bartosz Golaszewski]

On Thu, Apr 6, 2023 at 11:33 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
>
> This driver implements a GPIO enable/disable delay. It supports a list
> of GPIO outputs, which ramp-up/ramp-down delay can be specified at
> consumer location.
> The main purpose is to address external, passive delays upon line
> voltage changes.
>
> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> ---

Applied, thanks!

Bart

[PATCH v1 3/3] [DNI] arm64: dts: mba8mx: Use gpio-delay for LVDS bridge

[Alexander Stein]

Add a gpio-delay for LVDS_BRIDGE_EN_1V8 which ramp-up time is defined
by the external RC filter.

Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes since RFC v2:
* Removed 'input' prefix
* Removed 'gpio-line-names' for GPIO controller node

 arch/arm64/boot/dts/freescale/mba8mx.dtsi | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/mba8mx.dtsi b/arch/arm64/boot/dts/freescale/mba8mx.dtsi
index 691e91e84dec..3bae1c8fb8ed 100644
--- a/arch/arm64/boot/dts/freescale/mba8mx.dtsi
+++ b/arch/arm64/boot/dts/freescale/mba8mx.dtsi
@@ -75,6 +75,14 @@ led2: led2 {
 		};
 	};
 
+	gpio_delays: gpio-delays {
+		compatible = "gpio-delay";
+		#gpio-cells = <3>;
+		gpio-controller;
+		gpios = <&expander0 6 GPIO_ACTIVE_HIGH>;
+		gpio-line-names = "LVDS_BRIDGE_EN_1V8";
+	};
+
 	panel0: panel_lvds0 {
 		/*
 		 * Display is not fixed, so compatible has to be added from
@@ -269,7 +277,7 @@ &i2c3 {
 	dsi_lvds_bridge: bridge@2d {
 		compatible = "ti,sn65dsi83";
 		reg = <0x2d>;
-		enable-gpios = <&expander0 6 GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio_delays 0 130000 0>;
 		vcc-supply = <&reg_sn65dsi83_1v8>;
 		status = "disabled";
 
-- 
2.34.1

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[andy.shevchenko]

Thu, Apr 06, 2023 at 11:33:41AM +0200, Alexander Stein kirjoitti:
> Hello everyone,
> 
> thanks for the feedback I've received. This is the first non-RFC series for
> adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.
> 
> Changes compared to RFC v2 are mentioned in each patch.

Reading the (poor?) documentation does not clarify the use case.
Looking at them I think that this is can be implemented as debounce.
Also I have no clue why it's so important that we _need_ to have a
driver for this. We have plenty of consumer drivers that implement
delays on ramping up or down or whatever if they need.

Which part(s) did I got wrong?

P.S. Are we going to have a _driver_ per each subtle feature like this?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Alexander Stein]

Hi Andy,

Am Freitag, 7. April 2023, 20:57:32 CEST schrieb andy.shevchenko@gmail.com:
> Thu, Apr 06, 2023 at 11:33:41AM +0200, Alexander Stein kirjoitti:
> > Hello everyone,
> > 
> > thanks for the feedback I've received. This is the first non-RFC series
> > for
> > adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.
> > 
> > Changes compared to RFC v2 are mentioned in each patch.
> 
> Reading the (poor?) documentation does not clarify the use case.
> Looking at them I think that this is can be implemented as debounce.

Debounce for GPIOs? There is nothing like that yet.

> Also I have no clue why it's so important that we _need_ to have a
> driver for this. We have plenty of consumer drivers that implement
> delays on ramping up or down or whatever if they need.

But this delay I am dealing with is actually not consumer dependent, e.g. a 
power-on delay specified in a datasheet. Instead this driver deals with a 
platform-specific curiosity, e.g. RC-circuit on an open-drain output. So this 
is something which sits inbetween ICs.
In the RFC we came to the conclusion to not adjust (each) consumer to deal 
with this, given this will be rarely used. Instead provide a generic way for 
specifying this delay.

> Which part(s) did I got wrong?

Maybe there needs to be an explicit example in the bindings document what's 
the actual issue to deal with.
Right now if a GPIO is set, it is expected the signal on the receiver side has 
changed as well within a negligible time as well. But due to external reasons 
(see RC_curcuit above) the change on the receiver side can occur much later, 
>100ms in my case.

Best regards,
Alexander

> P.S. Are we going to have a _driver_ per each subtle feature like this?

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
> Am Freitag, 7. April 2023, 20:57:32 CEST schrieb andy.shevchenko@gmail.com:
> > Thu, Apr 06, 2023 at 11:33:41AM +0200, Alexander Stein kirjoitti:

...

> > > thanks for the feedback I've received. This is the first non-RFC series
> > > for
> > > adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.
> > >
> > > Changes compared to RFC v2 are mentioned in each patch.
> >
> > Reading the (poor?) documentation does not clarify the use case.
> > Looking at them I think that this can be implemented as debounce.
>
> Debounce for GPIOs? There is nothing like that yet.

At least that what we have already done in the code, you can just
provide a similar feature to the output pins, no?

> > Also I have no clue why it's so important that we _need_ to have a
> > driver for this. We have plenty of consumer drivers that implement
> > delays on ramping up or down or whatever if they need.
>
> But this delay I am dealing with is actually not consumer dependent, e.g. a
> power-on delay specified in a datasheet. Instead this driver deals with a
> platform-specific curiosity, e.g. RC-circuit on an open-drain output. So this
> is something which sits inbetween ICs.
> In the RFC we came to the conclusion to not adjust (each) consumer to deal
> with this, given this will be rarely used. Instead provide a generic way for
> specifying this delay.

So, taking the above into consideration, why is it GPIO property to
begin with? This is PCB property of the certain platform design that
needs to be driven by a specific driver, correct?
At the very least this is pin configuration (but external to the SoC),
so has to be a _separate_ pin control in my opinion.

> > Which part(s) did I got wrong?
>
> Maybe there needs to be an explicit example in the bindings document what's
> the actual issue to deal with.
> Right now if a GPIO is set, it is expected the signal on the receiver side has
> changed as well within a negligible time as well. But due to external reasons
> (see RC_curcuit above) the change on the receiver side can occur much later,
> >100ms in my case.

I still don't understand why it is a problem. If each signal is
delayed then the caller should be aware of the delay, no?


--
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Alexander Stein]

Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> 
> <alexander.stein@ew.tq-group.com> wrote:
> > Am Freitag, 7. April 2023, 20:57:32 CEST schrieb 
andy.shevchenko@gmail.com:
> > > Thu, Apr 06, 2023 at 11:33:41AM +0200, Alexander Stein kirjoitti:
> ...
> 
> > > > thanks for the feedback I've received. This is the first non-RFC
> > > > series
> > > > for
> > > > adressing a platform specific ramp-up/ramp-down delay on GPIO outputs.
> > > > 
> > > > Changes compared to RFC v2 are mentioned in each patch.
> > > 
> > > Reading the (poor?) documentation does not clarify the use case.
> > > Looking at them I think that this can be implemented as debounce.
> > 
> > Debounce for GPIOs? There is nothing like that yet.
> 
> At least that what we have already done in the code, you can just
> provide a similar feature to the output pins, no?

Adding this kind of property to outputs (GPIO chips) has been rejected 
already, both on DT side as well as libgpio side, see [1] and [2].

> > > Also I have no clue why it's so important that we _need_ to have a
> > > driver for this. We have plenty of consumer drivers that implement
> > > delays on ramping up or down or whatever if they need.
> > 
> > But this delay I am dealing with is actually not consumer dependent, e.g.
> > a
> > power-on delay specified in a datasheet. Instead this driver deals with a
> > platform-specific curiosity, e.g. RC-circuit on an open-drain output. So
> > this is something which sits inbetween ICs.
> > In the RFC we came to the conclusion to not adjust (each) consumer to deal
> > with this, given this will be rarely used. Instead provide a generic way
> > for specifying this delay.
> 
> So, taking the above into consideration, why is it GPIO property to
> begin with? This is PCB property of the certain platform design that
> needs to be driven by a specific driver, correct?

True this is induced by the PCB, but this property applies to the GPIO, 
neither the GPIO controller output, nor the GPIO consumer is aware of.
So it has to be added in between. The original idea to add a property for the 
consumer driver is also rejected, because this kind of behavior is not limited 
to this specific driver.
That's why the delay is inserted in between the GPIO output and GPIO consumer.

> At the very least this is pin configuration (but external to the SoC),
> so has to be a _separate_ pin control in my opinion.

Sorry, I don't get what you mean by _separate_ pin control.

> > > Which part(s) did I got wrong?
> > 
> > Maybe there needs to be an explicit example in the bindings document
> > what's
> > the actual issue to deal with.
> > Right now if a GPIO is set, it is expected the signal on the receiver side
> > has changed as well within a negligible time as well. But due to external
> > reasons (see RC_curcuit above) the change on the receiver side can occur
> > much later,> 
> > >100ms in my case.
> 
> I still don't understand why it is a problem. If each signal is
> delayed then the caller should be aware of the delay, no?

Then we are back to square one, to decide where to take consideration of that 
delay. Up until now there have been several proposals:
1. GPIO consumer [3]
2. GPIO controller [4]
3. GPIO delay node (this series)

1. and 2. have been rejected, because that delay is taken care of where it is 
not caused.
3. explicitly declares the location of that delay. It's less/not intrusive to 
existing parts and purely optional. Given this is a rare case, but not limited 
to us, option 3 seems a good way to go.

Best regards,
Alexander

[1] https://lore.kernel.org/linux-gpio/CAL_JsqLeqpMuRkvpT2-x5q+8e4bHf4oLDML2QqCOgRMAg8=CsA@mail.gmail.com/
[2] https://lore.kernel.org/linux-gpio/
CACRpkdYioW1GROHFxA1vuAEiXqHh6fAu5CXNLcTvW_w3mWjSPw@mail.gmail.com/
[3] https://lore.kernel.org/dri-devel/20221209083339.3780776-1-alexander.stein@ew.tq-group.com/
[4] https://lore.kernel.org/linux-gpio/20221212103525.231298-1-alexander.stein@ew.tq-group.com/

-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> > On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> > <alexander.stein@ew.tq-group.com> wrote:
...

> > So, taking the above into consideration, why is it GPIO property to
> > begin with? This is PCB property of the certain platform design that
> > needs to be driven by a specific driver, correct?
>
> True this is induced by the PCB, but this property applies to the GPIO,
> neither the GPIO controller output, nor the GPIO consumer is aware of.
> So it has to be added in between. The original idea to add a property for the
> consumer driver is also rejected, because this kind of behavior is not limited
> to this specific driver.
> That's why the delay is inserted in between the GPIO output and GPIO consumer.
>
> > At the very least this is pin configuration (but external to the SoC),
> > so has to be a _separate_ pin control in my opinion.
>
> Sorry, I don't get what you mean by _separate_ pin control.

As you mentioned above this can be applied theoretically to any pin of
the SoC, That pin may or may not be a GPIO or a pin that can be
switched to the GPIO mode. Hence this entire idea shouldn't be part of
the existing _in-SoC_ pin control driver if any. This is a purely
separate entity, but at the same time it adds a property to a pin,
hence pin control.
At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.

> > > > Which part(s) did I got wrong?
> > >
> > > Maybe there needs to be an explicit example in the bindings document
> > > what's
> > > the actual issue to deal with.
> > > Right now if a GPIO is set, it is expected the signal on the receiver side
> > > has changed as well within a negligible time as well. But due to external
> > > reasons (see RC_curcuit above) the change on the receiver side can occur
> > > much later,>
> > > >100ms in my case.
> >
> > I still don't understand why it is a problem. If each signal is
> > delayed then the caller should be aware of the delay, no?
>
> Then we are back to square one, to decide where to take consideration of that
> delay. Up until now there have been several proposals:
> 1. GPIO consumer [3]
> 2. GPIO controller [4]
> 3. GPIO delay node (this series)
>
> 1. and 2. have been rejected, because that delay is taken care of where it is
> not caused.
> 3. explicitly declares the location of that delay. It's less/not intrusive to
> existing parts and purely optional. Given this is a rare case, but not limited
> to us, option 3 seems a good way to go.

All three are for the particular case of the pin. I do not think it's
_solely_ related to GPIO, esp. if the pin can switch modes from GPIO
to some native function. To me it sounds like it has to be a pin
configuration (of pin control) delay node. I.o.w. the #3, but without
tights to the GPIO.

> [1] https://lore.kernel.org/linux-gpio/CAL_JsqLeqpMuRkvpT2-x5q+8e4bHf4oLDML2QqCOgRMAg8=CsA@mail.gmail.com/
> [2] https://lore.kernel.org/linux-gpio/
> CACRpkdYioW1GROHFxA1vuAEiXqHh6fAu5CXNLcTvW_w3mWjSPw@mail.gmail.com/
> [3] https://lore.kernel.org/dri-devel/20221209083339.3780776-1-alexander.stein@ew.tq-group.com/
> [4] https://lore.kernel.org/linux-gpio/20221212103525.231298-1-alexander.stein@ew.tq-group.com/

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Krzysztof Kozlowski]

On 15/04/2023 17:06, Andy Shevchenko wrote:
> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> <alexander.stein@ew.tq-group.com> wrote:
>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
>>> <alexander.stein@ew.tq-group.com> wrote:
> ...
> 
>>> So, taking the above into consideration, why is it GPIO property to
>>> begin with? This is PCB property of the certain platform design that
>>> needs to be driven by a specific driver, correct?
>>
>> True this is induced by the PCB, but this property applies to the GPIO,
>> neither the GPIO controller output, nor the GPIO consumer is aware of.
>> So it has to be added in between. The original idea to add a property for the
>> consumer driver is also rejected, because this kind of behavior is not limited
>> to this specific driver.
>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
>>
>>> At the very least this is pin configuration (but external to the SoC),
>>> so has to be a _separate_ pin control in my opinion.
>>
>> Sorry, I don't get what you mean by _separate_ pin control.
> 
> As you mentioned above this can be applied theoretically to any pin of
> the SoC, That pin may or may not be a GPIO or a pin that can be
> switched to the GPIO mode. Hence this entire idea shouldn't be part of
> the existing _in-SoC_ pin control driver if any. This is a purely
> separate entity, but at the same time it adds a property to a pin,
> hence pin control.
> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.

I don't think that anything here is related to pin control. Pin control
is specific function of some device which allows different properties or
different functions of a pin.

This has nothing to do with different
properties/configuration/functions, thus it is not pin control. The pin
control maintainer also acked the patches.

The choice was discussed before, so I am surprised why you jump late in
discussions.

Although different problem is calling it v1. This is not v1, but v3 or
v4. Keep proper versioning. After v2 goes v3. RFC does not mean "v-2".

Best regards,
Krzysztof

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 15/04/2023 17:06, Andy Shevchenko wrote:
> > On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> > <alexander.stein@ew.tq-group.com> wrote:
> >> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> >>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> >>> <alexander.stein@ew.tq-group.com> wrote:

...

> >>> So, taking the above into consideration, why is it GPIO property to
> >>> begin with? This is PCB property of the certain platform design that
> >>> needs to be driven by a specific driver, correct?
> >>
> >> True this is induced by the PCB, but this property applies to the GPIO,
> >> neither the GPIO controller output, nor the GPIO consumer is aware of.
> >> So it has to be added in between. The original idea to add a property for the
> >> consumer driver is also rejected, because this kind of behavior is not limited
> >> to this specific driver.
> >> That's why the delay is inserted in between the GPIO output and GPIO consumer.
> >>
> >>> At the very least this is pin configuration (but external to the SoC),
> >>> so has to be a _separate_ pin control in my opinion.
> >>
> >> Sorry, I don't get what you mean by _separate_ pin control.
> >
> > As you mentioned above this can be applied theoretically to any pin of
> > the SoC, That pin may or may not be a GPIO or a pin that can be
> > switched to the GPIO mode. Hence this entire idea shouldn't be part of
> > the existing _in-SoC_ pin control driver if any. This is a purely
> > separate entity, but at the same time it adds a property to a pin,
> > hence pin control.
> > At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
>
> I don't think that anything here is related to pin control. Pin control
> is specific function of some device which allows different properties or
> different functions of a pin.

Sorry, but from a hardware perspective I have to disagree with you.
It's a property of the _pin_ and not of a GPIO. Any pin might have the
same property. That's why it's definitely _not_ a property of GPIO,
but wider than that.

> This has nothing to do with different
> properties/configuration/functions, thus it is not pin control. The pin
> control maintainer also acked the patches.

This series is about GPIO, so the pin control maintainer acked that,
and not reviewed it, so let's take this into account. The GPIO
maintainer has yet to comment on my reply, if he has anything to say.

> The choice was discussed before, so I am surprised why you jump late in
> discussions.

Why? I was not in the initial submission and I jumped as quickly as I
noticed this.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Krzysztof Kozlowski]

On 16/04/2023 11:36, Andy Shevchenko wrote:
> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 15/04/2023 17:06, Andy Shevchenko wrote:
>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
>>> <alexander.stein@ew.tq-group.com> wrote:
>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
>>>>> <alexander.stein@ew.tq-group.com> wrote:
> 
> ...
> 
>>>>> So, taking the above into consideration, why is it GPIO property to
>>>>> begin with? This is PCB property of the certain platform design that
>>>>> needs to be driven by a specific driver, correct?
>>>>
>>>> True this is induced by the PCB, but this property applies to the GPIO,
>>>> neither the GPIO controller output, nor the GPIO consumer is aware of.
>>>> So it has to be added in between. The original idea to add a property for the
>>>> consumer driver is also rejected, because this kind of behavior is not limited
>>>> to this specific driver.
>>>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
>>>>
>>>>> At the very least this is pin configuration (but external to the SoC),
>>>>> so has to be a _separate_ pin control in my opinion.
>>>>
>>>> Sorry, I don't get what you mean by _separate_ pin control.
>>>
>>> As you mentioned above this can be applied theoretically to any pin of
>>> the SoC, That pin may or may not be a GPIO or a pin that can be
>>> switched to the GPIO mode. Hence this entire idea shouldn't be part of
>>> the existing _in-SoC_ pin control driver if any. This is a purely
>>> separate entity, but at the same time it adds a property to a pin,
>>> hence pin control.
>>> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
>>
>> I don't think that anything here is related to pin control. Pin control
>> is specific function of some device which allows different properties or
>> different functions of a pin.
> 
> Sorry, but from a hardware perspective I have to disagree with you.
> It's a property of the _pin_ and not of a GPIO. Any pin might have the
> same property. That's why it's definitely _not_ a property of GPIO,
> but wider than that.

I did not say this is a property of GPIO. I said this is nothing to do
with pin control, configuration and pinctrl as is.

Otherwise bindings would be in directory matching the real hardware...
but they are not. So you can of course call it as you wish, but from
hardware perspective this is not pin control. This is RC circuit, not
pin related thingy.

Best regards,
Krzysztof

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 16/04/2023 11:36, Andy Shevchenko wrote:
> > On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >> On 15/04/2023 17:06, Andy Shevchenko wrote:
> >>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> >>> <alexander.stein@ew.tq-group.com> wrote:
> >>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> >>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> >>>>> <alexander.stein@ew.tq-group.com> wrote:
> >
> > ...
> >
> >>>>> So, taking the above into consideration, why is it GPIO property to
> >>>>> begin with? This is PCB property of the certain platform design that
> >>>>> needs to be driven by a specific driver, correct?
> >>>>
> >>>> True this is induced by the PCB, but this property applies to the GPIO,
> >>>> neither the GPIO controller output, nor the GPIO consumer is aware of.
> >>>> So it has to be added in between. The original idea to add a property for the
> >>>> consumer driver is also rejected, because this kind of behavior is not limited
> >>>> to this specific driver.
> >>>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
> >>>>
> >>>>> At the very least this is pin configuration (but external to the SoC),
> >>>>> so has to be a _separate_ pin control in my opinion.
> >>>>
> >>>> Sorry, I don't get what you mean by _separate_ pin control.
> >>>
> >>> As you mentioned above this can be applied theoretically to any pin of
> >>> the SoC, That pin may or may not be a GPIO or a pin that can be
> >>> switched to the GPIO mode. Hence this entire idea shouldn't be part of
> >>> the existing _in-SoC_ pin control driver if any. This is a purely
> >>> separate entity, but at the same time it adds a property to a pin,
> >>> hence pin control.
> >>> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
> >>
> >> I don't think that anything here is related to pin control. Pin control
> >> is specific function of some device which allows different properties or
> >> different functions of a pin.
> >
> > Sorry, but from a hardware perspective I have to disagree with you.
> > It's a property of the _pin_ and not of a GPIO. Any pin might have the
> > same property. That's why it's definitely _not_ a property of GPIO,
> > but wider than that.
>
> I did not say this is a property of GPIO. I said this is nothing to do
> with pin control, configuration and pinctrl as is.

Ah, I see. But still is a property of the pin on the PCB level. That's
why I said that it should be like a "proxy" driver that has to be a
consumer of the pins on one side and provide the pins with this
property on the other.

> Otherwise bindings would be in directory matching the real hardware...
> but they are not. So you can of course call it as you wish, but from
> hardware perspective this is not pin control. This is RC circuit, not
> pin related thingy.

Yep, I put it as a pin configuration which is part of pin control in
the Linux kernel right now. But I agree with your above explanation
and it seems that we lack a, let's say, "pin modification" framework
that stacks additional (PCB level or why not even some special in-SoC
ones) properties and adds them to the given pins.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Krzysztof Kozlowski]

On 16/04/2023 13:14, Andy Shevchenko wrote:
> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 16/04/2023 11:36, Andy Shevchenko wrote:
>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
>>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
>>>>> <alexander.stein@ew.tq-group.com> wrote:
>>>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
>>>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
>>>>>>> <alexander.stein@ew.tq-group.com> wrote:
>>>
>>> ...
>>>
>>>>>>> So, taking the above into consideration, why is it GPIO property to
>>>>>>> begin with? This is PCB property of the certain platform design that
>>>>>>> needs to be driven by a specific driver, correct?
>>>>>>
>>>>>> True this is induced by the PCB, but this property applies to the GPIO,
>>>>>> neither the GPIO controller output, nor the GPIO consumer is aware of.
>>>>>> So it has to be added in between. The original idea to add a property for the
>>>>>> consumer driver is also rejected, because this kind of behavior is not limited
>>>>>> to this specific driver.
>>>>>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
>>>>>>
>>>>>>> At the very least this is pin configuration (but external to the SoC),
>>>>>>> so has to be a _separate_ pin control in my opinion.
>>>>>>
>>>>>> Sorry, I don't get what you mean by _separate_ pin control.
>>>>>
>>>>> As you mentioned above this can be applied theoretically to any pin of
>>>>> the SoC, That pin may or may not be a GPIO or a pin that can be
>>>>> switched to the GPIO mode. Hence this entire idea shouldn't be part of
>>>>> the existing _in-SoC_ pin control driver if any. This is a purely
>>>>> separate entity, but at the same time it adds a property to a pin,
>>>>> hence pin control.
>>>>> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
>>>>
>>>> I don't think that anything here is related to pin control. Pin control
>>>> is specific function of some device which allows different properties or
>>>> different functions of a pin.
>>>
>>> Sorry, but from a hardware perspective I have to disagree with you.
>>> It's a property of the _pin_ and not of a GPIO. Any pin might have the
>>> same property. That's why it's definitely _not_ a property of GPIO,
>>> but wider than that.
>>
>> I did not say this is a property of GPIO. I said this is nothing to do
>> with pin control, configuration and pinctrl as is.
> 
> Ah, I see. But still is a property of the pin on the PCB level. 

No, it is property of a circuit, so property of two pins and a wire
between them. Not a property of one pin.


> That's
> why I said that it should be like a "proxy" driver that has to be a
> consumer of the pins on one side and provide the pins with this
> property on the other.

Not sure, why do you need it for anything else than GPIOs? What is the
real world use case for proxy driver of non-GPIO lines?

> 
>> Otherwise bindings would be in directory matching the real hardware...
>> but they are not. So you can of course call it as you wish, but from
>> hardware perspective this is not pin control. This is RC circuit, not
>> pin related thingy.
> 
> Yep, I put it as a pin configuration which is part of pin control in
> the Linux kernel right now. But I agree with your above explanation
> and it seems that we lack a, let's say, "pin modification" framework
> that stacks additional (PCB level or why not even some special in-SoC
> ones) properties and adds them to the given pins.

It's nothing to do with modification of properties of some pin. It's a
separate circuit which has an effect on how two connected pins behave.
If you look from an effect point of view, only one side is more
interested in the effect - consumer. But still this sits in the middle.

Best regards,
Krzysztof

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Sun, Apr 16, 2023 at 2:21 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
> On 16/04/2023 13:14, Andy Shevchenko wrote:
> > On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >> On 16/04/2023 11:36, Andy Shevchenko wrote:
> >>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
> >>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> >>>>> <alexander.stein@ew.tq-group.com> wrote:
> >>>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> >>>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> >>>>>>> <alexander.stein@ew.tq-group.com> wrote:
> >>>
> >>> ...
> >>>
> >>>>>>> So, taking the above into consideration, why is it GPIO property to
> >>>>>>> begin with? This is PCB property of the certain platform design that
> >>>>>>> needs to be driven by a specific driver, correct?
> >>>>>>
> >>>>>> True this is induced by the PCB, but this property applies to the GPIO,
> >>>>>> neither the GPIO controller output, nor the GPIO consumer is aware of.
> >>>>>> So it has to be added in between. The original idea to add a property for the
> >>>>>> consumer driver is also rejected, because this kind of behavior is not limited
> >>>>>> to this specific driver.
> >>>>>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
> >>>>>>
> >>>>>>> At the very least this is pin configuration (but external to the SoC),
> >>>>>>> so has to be a _separate_ pin control in my opinion.
> >>>>>>
> >>>>>> Sorry, I don't get what you mean by _separate_ pin control.
> >>>>>
> >>>>> As you mentioned above this can be applied theoretically to any pin of
> >>>>> the SoC, That pin may or may not be a GPIO or a pin that can be
> >>>>> switched to the GPIO mode. Hence this entire idea shouldn't be part of
> >>>>> the existing _in-SoC_ pin control driver if any. This is a purely
> >>>>> separate entity, but at the same time it adds a property to a pin,
> >>>>> hence pin control.
> >>>>> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
> >>>>
> >>>> I don't think that anything here is related to pin control. Pin control
> >>>> is specific function of some device which allows different properties or
> >>>> different functions of a pin.
> >>>
> >>> Sorry, but from a hardware perspective I have to disagree with you.
> >>> It's a property of the _pin_ and not of a GPIO. Any pin might have the
> >>> same property. That's why it's definitely _not_ a property of GPIO,
> >>> but wider than that.
> >>
> >> I did not say this is a property of GPIO. I said this is nothing to do
> >> with pin control, configuration and pinctrl as is.
> >
> > Ah, I see. But still is a property of the pin on the PCB level.
>
> No, it is property of a circuit, so property of two pins and a wire
> between them. Not a property of one pin.

Electrically speaking -- yes, software speaking, no, this is the
property of the one end (platfrom abstraction in the software) and as
you said, consumer which may be SoC, or the device connected to the
SoC (depending on the signal direction), or both (like pull-up for
I2C).

> > That's
> > why I said that it should be like a "proxy" driver that has to be a
> > consumer of the pins on one side and provide the pins with this
> > property on the other.
>
> Not sure, why do you need it for anything else than GPIOs? What is the
> real world use case for proxy driver of non-GPIO lines?

I2C is an example where we have something in between, which both of
the ends are using and this is the property of PCB, but luckily we
don't need anything special in the software for that, right? But from
the electrical point of view it's exactly a non-GPIO property. That's
why "proxy".

> >> Otherwise bindings would be in directory matching the real hardware...
> >> but they are not. So you can of course call it as you wish, but from
> >> hardware perspective this is not pin control. This is RC circuit, not
> >> pin related thingy.
> >
> > Yep, I put it as a pin configuration which is part of pin control in
> > the Linux kernel right now. But I agree with your above explanation
> > and it seems that we lack a, let's say, "pin modification" framework
> > that stacks additional (PCB level or why not even some special in-SoC
> > ones) properties and adds them to the given pins.
>
> It's nothing to do with modification of properties of some pin. It's a
> separate circuit which has an effect on how two connected pins behave.
> If you look from an effect point of view, only one side is more
> interested in the effect - consumer. But still this sits in the middle.

Yes, see above. And we are programming only one side of this scenario.
For us it's a property of one side of the equation.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Krzysztof Kozlowski]

On 16/04/2023 13:33, Andy Shevchenko wrote:
> On Sun, Apr 16, 2023 at 2:21 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>> On 16/04/2023 13:14, Andy Shevchenko wrote:
>>> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>> On 16/04/2023 11:36, Andy Shevchenko wrote:
>>>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
>>>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
>>>>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
>>>>>>> <alexander.stein@ew.tq-group.com> wrote:
>>>>>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
>>>>>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
>>>>>>>>> <alexander.stein@ew.tq-group.com> wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>>>> So, taking the above into consideration, why is it GPIO property to
>>>>>>>>> begin with? This is PCB property of the certain platform design that
>>>>>>>>> needs to be driven by a specific driver, correct?
>>>>>>>>
>>>>>>>> True this is induced by the PCB, but this property applies to the GPIO,
>>>>>>>> neither the GPIO controller output, nor the GPIO consumer is aware of.
>>>>>>>> So it has to be added in between. The original idea to add a property for the
>>>>>>>> consumer driver is also rejected, because this kind of behavior is not limited
>>>>>>>> to this specific driver.
>>>>>>>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
>>>>>>>>
>>>>>>>>> At the very least this is pin configuration (but external to the SoC),
>>>>>>>>> so has to be a _separate_ pin control in my opinion.
>>>>>>>>
>>>>>>>> Sorry, I don't get what you mean by _separate_ pin control.
>>>>>>>
>>>>>>> As you mentioned above this can be applied theoretically to any pin of
>>>>>>> the SoC, That pin may or may not be a GPIO or a pin that can be
>>>>>>> switched to the GPIO mode. Hence this entire idea shouldn't be part of
>>>>>>> the existing _in-SoC_ pin control driver if any. This is a purely
>>>>>>> separate entity, but at the same time it adds a property to a pin,
>>>>>>> hence pin control.
>>>>>>> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
>>>>>>
>>>>>> I don't think that anything here is related to pin control. Pin control
>>>>>> is specific function of some device which allows different properties or
>>>>>> different functions of a pin.
>>>>>
>>>>> Sorry, but from a hardware perspective I have to disagree with you.
>>>>> It's a property of the _pin_ and not of a GPIO. Any pin might have the
>>>>> same property. That's why it's definitely _not_ a property of GPIO,
>>>>> but wider than that.
>>>>
>>>> I did not say this is a property of GPIO. I said this is nothing to do
>>>> with pin control, configuration and pinctrl as is.
>>>
>>> Ah, I see. But still is a property of the pin on the PCB level.
>>
>> No, it is property of a circuit, so property of two pins and a wire
>> between them. Not a property of one pin.
> 
> Electrically speaking -- yes, software speaking, no, this is the
> property of the one end (platfrom abstraction in the software) and as
> you said, consumer which may be SoC, or the device connected to the
> SoC (depending on the signal direction), or both (like pull-up for
> I2C).
> 
>>> That's
>>> why I said that it should be like a "proxy" driver that has to be a
>>> consumer of the pins on one side and provide the pins with this
>>> property on the other.
>>
>> Not sure, why do you need it for anything else than GPIOs? What is the
>> real world use case for proxy driver of non-GPIO lines?
> 
> I2C is an example where we have something in between, which both of

Are you sure you have RC (not just resistor) in I2C?

> the ends are using and this is the property of PCB, but luckily we
> don't need anything special in the software for that, right? But from
> the electrical point of view it's exactly a non-GPIO property. That's
> why "proxy".

Still I do not see any reason to call it anything else than GPIO. If you
think that there is any other usage, please bring it as an real,
non-theoretical example.

Best regards,
Krzysztof

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Sun, Apr 16, 2023 at 2:42 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/04/2023 13:33, Andy Shevchenko wrote:
> > On Sun, Apr 16, 2023 at 2:21 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >> On 16/04/2023 13:14, Andy Shevchenko wrote:
> >>> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>> On 16/04/2023 11:36, Andy Shevchenko wrote:
> >>>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> >>>>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
> >>>>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> >>>>>>> <alexander.stein@ew.tq-group.com> wrote:
> >>>>>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy Shevchenko:
> >>>>>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> >>>>>>>>> <alexander.stein@ew.tq-group.com> wrote:
> >>>>>
> >>>>> ...
> >>>>>
> >>>>>>>>> So, taking the above into consideration, why is it GPIO property to
> >>>>>>>>> begin with? This is PCB property of the certain platform design that
> >>>>>>>>> needs to be driven by a specific driver, correct?
> >>>>>>>>
> >>>>>>>> True this is induced by the PCB, but this property applies to the GPIO,
> >>>>>>>> neither the GPIO controller output, nor the GPIO consumer is aware of.
> >>>>>>>> So it has to be added in between. The original idea to add a property for the
> >>>>>>>> consumer driver is also rejected, because this kind of behavior is not limited
> >>>>>>>> to this specific driver.
> >>>>>>>> That's why the delay is inserted in between the GPIO output and GPIO consumer.
> >>>>>>>>
> >>>>>>>>> At the very least this is pin configuration (but external to the SoC),
> >>>>>>>>> so has to be a _separate_ pin control in my opinion.
> >>>>>>>>
> >>>>>>>> Sorry, I don't get what you mean by _separate_ pin control.
> >>>>>>>
> >>>>>>> As you mentioned above this can be applied theoretically to any pin of
> >>>>>>> the SoC, That pin may or may not be a GPIO or a pin that can be
> >>>>>>> switched to the GPIO mode. Hence this entire idea shouldn't be part of
> >>>>>>> the existing _in-SoC_ pin control driver if any. This is a purely
> >>>>>>> separate entity, but at the same time it adds a property to a pin,
> >>>>>>> hence pin control.
> >>>>>>> At the same time, it's not an SoC related one, it's a PCB. Hence _separate_.
> >>>>>>
> >>>>>> I don't think that anything here is related to pin control. Pin control
> >>>>>> is specific function of some device which allows different properties or
> >>>>>> different functions of a pin.
> >>>>>
> >>>>> Sorry, but from a hardware perspective I have to disagree with you.
> >>>>> It's a property of the _pin_ and not of a GPIO. Any pin might have the
> >>>>> same property. That's why it's definitely _not_ a property of GPIO,
> >>>>> but wider than that.
> >>>>
> >>>> I did not say this is a property of GPIO. I said this is nothing to do
> >>>> with pin control, configuration and pinctrl as is.
> >>>
> >>> Ah, I see. But still is a property of the pin on the PCB level.
> >>
> >> No, it is property of a circuit, so property of two pins and a wire
> >> between them. Not a property of one pin.
> >
> > Electrically speaking -- yes, software speaking, no, this is the
> > property of the one end (platfrom abstraction in the software) and as
> > you said, consumer which may be SoC, or the device connected to the
> > SoC (depending on the signal direction), or both (like pull-up for
> > I2C).
> >
> >>> That's
> >>> why I said that it should be like a "proxy" driver that has to be a
> >>> consumer of the pins on one side and provide the pins with this
> >>> property on the other.
> >>
> >> Not sure, why do you need it for anything else than GPIOs? What is the
> >> real world use case for proxy driver of non-GPIO lines?
> >
> > I2C is an example where we have something in between, which both of
>
> Are you sure you have RC (not just resistor) in I2C?

I'm talking about an analogue. In principle the pull-up is part of PCB
and not of the SoC.

> > the ends are using and this is the property of PCB, but luckily we
> > don't need anything special in the software for that, right? But from
> > the electrical point of view it's exactly a non-GPIO property. That's
> > why "proxy".
>
> Still I do not see any reason to call it anything else than GPIO. If you
> think that there is any other usage, please bring it as an real,
> non-theoretical example.

The first, which one I found, is time-stretched ADC. The idea is that
the portion of the signal is split to the phases and each phase is
passed via time stretcher for the low-speed ADC to be digitized. So,
if we have an SoC with 4+ ADCs, on the PCB one can add an externally
clocked mux and then 4+ time stretching lines and on the SoC side it
will be ADC (note, not a GPIO!).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Alexander Stein]

Hi everybody,

Am Sonntag, 16. April 2023, 20:46:43 CEST schrieb Andy Shevchenko:
> On Sun, Apr 16, 2023 at 2:42 PM Krzysztof Kozlowski
> 
> <krzysztof.kozlowski@linaro.org> wrote:
> > On 16/04/2023 13:33, Andy Shevchenko wrote:
> > > On Sun, Apr 16, 2023 at 2:21 PM Krzysztof Kozlowski
> > > 
> > > <krzysztof.kozlowski@linaro.org> wrote:
> > >> On 16/04/2023 13:14, Andy Shevchenko wrote:
> > >>> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> > >>> 
> > >>> <krzysztof.kozlowski@linaro.org> wrote:
> > >>>> On 16/04/2023 11:36, Andy Shevchenko wrote:
> > >>>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> > >>>>> 
> > >>>>> <krzysztof.kozlowski@linaro.org> wrote:
> > >>>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
> > >>>>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> > >>>>>>> 
> > >>>>>>> <alexander.stein@ew.tq-group.com> wrote:
> > >>>>>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy 
Shevchenko:
> > >>>>>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> > >>>>> 
> > >>>>>>>>> <alexander.stein@ew.tq-group.com> wrote:
> > >>>>> ...
> > >>>>> 
> > >>>>>>>>> So, taking the above into consideration, why is it GPIO property
> > >>>>>>>>> to
> > >>>>>>>>> begin with? This is PCB property of the certain platform design
> > >>>>>>>>> that
> > >>>>>>>>> needs to be driven by a specific driver, correct?
> > >>>>>>>> 
> > >>>>>>>> True this is induced by the PCB, but this property applies to the
> > >>>>>>>> GPIO,
> > >>>>>>>> neither the GPIO controller output, nor the GPIO consumer is
> > >>>>>>>> aware of.
> > >>>>>>>> So it has to be added in between. The original idea to add a
> > >>>>>>>> property for the consumer driver is also rejected, because this
> > >>>>>>>> kind of behavior is not limited to this specific driver.
> > >>>>>>>> That's why the delay is inserted in between the GPIO output and
> > >>>>>>>> GPIO consumer.> >>>>>>>> 
> > >>>>>>>>> At the very least this is pin configuration (but external to the
> > >>>>>>>>> SoC),
> > >>>>>>>>> so has to be a _separate_ pin control in my opinion.
> > >>>>>>>> 
> > >>>>>>>> Sorry, I don't get what you mean by _separate_ pin control.
> > >>>>>>> 
> > >>>>>>> As you mentioned above this can be applied theoretically to any
> > >>>>>>> pin of
> > >>>>>>> the SoC, That pin may or may not be a GPIO or a pin that can be
> > >>>>>>> switched to the GPIO mode. Hence this entire idea shouldn't be
> > >>>>>>> part of
> > >>>>>>> the existing _in-SoC_ pin control driver if any. This is a purely
> > >>>>>>> separate entity, but at the same time it adds a property to a pin,
> > >>>>>>> hence pin control.
> > >>>>>>> At the same time, it's not an SoC related one, it's a PCB. Hence
> > >>>>>>> _separate_.> >>>>>> 
> > >>>>>> I don't think that anything here is related to pin control. Pin
> > >>>>>> control
> > >>>>>> is specific function of some device which allows different
> > >>>>>> properties or
> > >>>>>> different functions of a pin.
> > >>>>> 
> > >>>>> Sorry, but from a hardware perspective I have to disagree with you.
> > >>>>> It's a property of the _pin_ and not of a GPIO. Any pin might have
> > >>>>> the
> > >>>>> same property. That's why it's definitely _not_ a property of GPIO,
> > >>>>> but wider than that.
> > >>>> 
> > >>>> I did not say this is a property of GPIO. I said this is nothing to
> > >>>> do
> > >>>> with pin control, configuration and pinctrl as is.
> > >>> 
> > >>> Ah, I see. But still is a property of the pin on the PCB level.
> > >> 
> > >> No, it is property of a circuit, so property of two pins and a wire
> > >> between them. Not a property of one pin.
> > > 
> > > Electrically speaking -- yes, software speaking, no, this is the
> > > property of the one end (platfrom abstraction in the software) and as
> > > you said, consumer which may be SoC, or the device connected to the
> > > SoC (depending on the signal direction), or both (like pull-up for
> > > I2C).
> > > 
> > >>> That's
> > >>> why I said that it should be like a "proxy" driver that has to be a
> > >>> consumer of the pins on one side and provide the pins with this
> > >>> property on the other.
> > >> 
> > >> Not sure, why do you need it for anything else than GPIOs? What is the
> > >> real world use case for proxy driver of non-GPIO lines?
> > > 
> > > I2C is an example where we have something in between, which both of
> > 
> > Are you sure you have RC (not just resistor) in I2C?
> 
> I'm talking about an analogue. In principle the pull-up is part of PCB
> and not of the SoC.
> 
> > > the ends are using and this is the property of PCB, but luckily we
> > > don't need anything special in the software for that, right? But from
> > > the electrical point of view it's exactly a non-GPIO property. That's
> > > why "proxy".
> > 
> > Still I do not see any reason to call it anything else than GPIO. If you
> > think that there is any other usage, please bring it as an real,
> > non-theoretical example.
> 
> The first, which one I found, is time-stretched ADC. The idea is that
> the portion of the signal is split to the phases and each phase is
> passed via time stretcher for the low-speed ADC to be digitized. So,
> if we have an SoC with 4+ ADCs, on the PCB one can add an externally
> clocked mux and then 4+ time stretching lines and on the SoC side it
> will be ADC (note, not a GPIO!).

What do I need to do to get progress on this topic? Without this kind of delay 
handling the DSI-LVDS bridge on our hardware cannot be used in mainline.

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Wed, May 31, 2023 at 9:53 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:
> Am Sonntag, 16. April 2023, 20:46:43 CEST schrieb Andy Shevchenko:
> > On Sun, Apr 16, 2023 at 2:42 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> > > On 16/04/2023 13:33, Andy Shevchenko wrote:
> > > > On Sun, Apr 16, 2023 at 2:21 PM Krzysztof Kozlowski
> > > > <krzysztof.kozlowski@linaro.org> wrote:
> > > >> On 16/04/2023 13:14, Andy Shevchenko wrote:
> > > >>> On Sun, Apr 16, 2023 at 2:04 PM Krzysztof Kozlowski
> > > >>> <krzysztof.kozlowski@linaro.org> wrote:
> > > >>>> On 16/04/2023 11:36, Andy Shevchenko wrote:
> > > >>>>> On Sun, Apr 16, 2023 at 10:42 AM Krzysztof Kozlowski
> > > >>>>> <krzysztof.kozlowski@linaro.org> wrote:
> > > >>>>>> On 15/04/2023 17:06, Andy Shevchenko wrote:
> > > >>>>>>> On Fri, Apr 14, 2023 at 9:37 AM Alexander Stein
> > > >>>>>>> <alexander.stein@ew.tq-group.com> wrote:
> > > >>>>>>>> Am Dienstag, 11. April 2023, 11:34:16 CEST schrieb Andy
> Shevchenko:
> > > >>>>>>>>> On Tue, Apr 11, 2023 at 10:19 AM Alexander Stein
> > > >>>>>>>>> <alexander.stein@ew.tq-group.com> wrote:

...

> > > >>>>>>>>> So, taking the above into consideration, why is it GPIO property
> > > >>>>>>>>> to
> > > >>>>>>>>> begin with? This is PCB property of the certain platform design
> > > >>>>>>>>> that
> > > >>>>>>>>> needs to be driven by a specific driver, correct?
> > > >>>>>>>>
> > > >>>>>>>> True this is induced by the PCB, but this property applies to the
> > > >>>>>>>> GPIO,
> > > >>>>>>>> neither the GPIO controller output, nor the GPIO consumer is
> > > >>>>>>>> aware of.
> > > >>>>>>>> So it has to be added in between. The original idea to add a
> > > >>>>>>>> property for the consumer driver is also rejected, because this
> > > >>>>>>>> kind of behavior is not limited to this specific driver.
> > > >>>>>>>> That's why the delay is inserted in between the GPIO output and
> > > >>>>>>>> GPIO consumer.> >>>>>>>>
> > > >>>>>>>>> At the very least this is pin configuration (but external to the
> > > >>>>>>>>> SoC),
> > > >>>>>>>>> so has to be a _separate_ pin control in my opinion.
> > > >>>>>>>>
> > > >>>>>>>> Sorry, I don't get what you mean by _separate_ pin control.
> > > >>>>>>>
> > > >>>>>>> As you mentioned above this can be applied theoretically to any
> > > >>>>>>> pin of
> > > >>>>>>> the SoC, That pin may or may not be a GPIO or a pin that can be
> > > >>>>>>> switched to the GPIO mode. Hence this entire idea shouldn't be
> > > >>>>>>> part of
> > > >>>>>>> the existing _in-SoC_ pin control driver if any. This is a purely
> > > >>>>>>> separate entity, but at the same time it adds a property to a pin,
> > > >>>>>>> hence pin control.
> > > >>>>>>> At the same time, it's not an SoC related one, it's a PCB. Hence
> > > >>>>>>> _separate_.> >>>>>>
> > > >>>>>> I don't think that anything here is related to pin control. Pin
> > > >>>>>> control
> > > >>>>>> is specific function of some device which allows different
> > > >>>>>> properties or
> > > >>>>>> different functions of a pin.
> > > >>>>>
> > > >>>>> Sorry, but from a hardware perspective I have to disagree with you.
> > > >>>>> It's a property of the _pin_ and not of a GPIO. Any pin might have
> > > >>>>> the
> > > >>>>> same property. That's why it's definitely _not_ a property of GPIO,
> > > >>>>> but wider than that.
> > > >>>>
> > > >>>> I did not say this is a property of GPIO. I said this is nothing to
> > > >>>> do
> > > >>>> with pin control, configuration and pinctrl as is.
> > > >>>
> > > >>> Ah, I see. But still is a property of the pin on the PCB level.
> > > >>
> > > >> No, it is property of a circuit, so property of two pins and a wire
> > > >> between them. Not a property of one pin.
> > > >
> > > > Electrically speaking -- yes, software speaking, no, this is the
> > > > property of the one end (platfrom abstraction in the software) and as
> > > > you said, consumer which may be SoC, or the device connected to the
> > > > SoC (depending on the signal direction), or both (like pull-up for
> > > > I2C).
> > > >
> > > >>> That's
> > > >>> why I said that it should be like a "proxy" driver that has to be a
> > > >>> consumer of the pins on one side and provide the pins with this
> > > >>> property on the other.
> > > >>
> > > >> Not sure, why do you need it for anything else than GPIOs? What is the
> > > >> real world use case for proxy driver of non-GPIO lines?
> > > >
> > > > I2C is an example where we have something in between, which both of
> > >
> > > Are you sure you have RC (not just resistor) in I2C?
> >
> > I'm talking about an analogue. In principle the pull-up is part of PCB
> > and not of the SoC.
> >
> > > > the ends are using and this is the property of PCB, but luckily we
> > > > don't need anything special in the software for that, right? But from
> > > > the electrical point of view it's exactly a non-GPIO property. That's
> > > > why "proxy".
> > >
> > > Still I do not see any reason to call it anything else than GPIO. If you
> > > think that there is any other usage, please bring it as an real,
> > > non-theoretical example.
> >
> > The first, which one I found, is time-stretched ADC. The idea is that
> > the portion of the signal is split to the phases and each phase is
> > passed via time stretcher for the low-speed ADC to be digitized. So,
> > if we have an SoC with 4+ ADCs, on the PCB one can add an externally
> > clocked mux and then 4+ time stretching lines and on the SoC side it
> > will be ADC (note, not a GPIO!).
>
> What do I need to do to get progress on this topic? Without this kind of delay
> handling the DSI-LVDS bridge on our hardware cannot be used in mainline.

I have looked into the entire thread and found no replies from Linus W and Bart.
They are GPIO maintainers and should fuel up this discussion.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Linus Walleij]

On Wed, May 31, 2023 at 8:53 AM Alexander Stein
<alexander.stein@ew.tq-group.com> wrote:

> What do I need to do to get progress on this topic? Without this kind of delay
> handling the DSI-LVDS bridge on our hardware cannot be used in mainline.

The DT binding maintainers (Rob, Krzysztof) need to ACK the approach to
how this is modeled in the DT bindings.

For trivial-to-medium changes I am convenient to apply changes after 1-2
weeks of silence, but these are pretty fundamental issues so the binding
maintainers need to sign off on it.

I think they are a bit offline for the moment, but I would read through the
feedback from the binding maintainers and draft a binding patch that they
can accept.

Yours,
Linus Walleij

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Andy Shevchenko]

On Wed, May 31, 2023 at 4:45 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, May 31, 2023 at 8:53 AM Alexander Stein
> <alexander.stein@ew.tq-group.com> wrote:
>
> > What do I need to do to get progress on this topic? Without this kind of delay
> > handling the DSI-LVDS bridge on our hardware cannot be used in mainline.
>
> The DT binding maintainers (Rob, Krzysztof) need to ACK the approach to
> how this is modeled in the DT bindings.
>
> For trivial-to-medium changes I am convenient to apply changes after 1-2
> weeks of silence, but these are pretty fundamental issues so the binding
> maintainers need to sign off on it.
>
> I think they are a bit offline for the moment, but I would read through the
> feedback from the binding maintainers and draft a binding patch that they
> can accept.

Are you okay with this to be the part of a GPIO controller rather than
the platform stuff related to the consumer?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v1 0/3] gpio: Add gpio-delay support

[Krzysztof Kozlowski]

On 31/05/2023 15:44, Linus Walleij wrote:
> On Wed, May 31, 2023 at 8:53 AM Alexander Stein
> <alexander.stein@ew.tq-group.com> wrote:
> 
>> What do I need to do to get progress on this topic? Without this kind of delay
>> handling the DSI-LVDS bridge on our hardware cannot be used in mainline.
> 
> The DT binding maintainers (Rob, Krzysztof) need to ACK the approach to
> how this is modeled in the DT bindings.

I left it for Rob as he was involved in v0 and v-1, I think, but since
this calls for attention I replied now. Sorry for the delays.

Best regards,
Krzysztof