[PATCH 0/3] tty slave device support - version 3.

[PATCH 0/3] tty slave device support - version 3.

[NeilBrown]

Hi again,
 here is version 3 of support for tty-slaves.

 This version introduces a new bus-type for tty-slaves, and causes
 a tty-slave device to appear in /sys/devices between the uart and the
 tty.
 It effectively intercepts and calls from the tty to the uart (i.e. any
 tty_operations) and applies extra functionality at that point.

 Currently the only driver intercepts open and close.
 It powers on the device on open, and powers off at last-close.

 Power can be controlled by a regulator or by toggling a GPIO.

 I think I've incorporated most of the feed back I received from
 previous versions, but if I missed something - I apologize.  If
 this approach is structurally acceptable then I can fix up all the
 smaller issues.

Thanks for your review,
NeilBrown


---

NeilBrown (3):
      TTY: use class_find_device to find port in uart_suspend/resume.
      TTY: add support for tty_slave devices.
      tty/slaves: add a driver to power on/off UART attached devices.


 .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
 .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 
 drivers/tty/Kconfig                                |    1 
 drivers/tty/Makefile                               |    1 
 drivers/tty/serial/serial_core.c                   |   21 -
 drivers/tty/slave/Kconfig                          |   21 +
 drivers/tty/slave/Makefile                         |    4 
 drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
 drivers/tty/slave/tty_slave_core.c                 |  136 +++++
 drivers/tty/tty_io.c                               |   60 ++
 include/linux/tty.h                                |    2 
 include/linux/tty_slave.h                          |   26 +
 13 files changed, 813 insertions(+), 26 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/slave/Kconfig
 create mode 100644 drivers/tty/slave/Makefile
 create mode 100644 drivers/tty/slave/serial-power-manager.c
 create mode 100644 drivers/tty/slave/tty_slave_core.c
 create mode 100644 include/linux/tty_slave.h

--
Signature

[PATCH 2/3] TTY: add support for tty_slave devices.

[NeilBrown]

A "tty slave" is a device connected via UART.
Such a device may need its own driver, e.g. for powering
it up on tty open and powering it down on tty release.

tty-slave is a new bus-type which drivers can be written and devices
created.

A "tty slave" device is declared as a child of the uart in
device-tree:

&uart1 {
    bluetooth {
        compatible = "wi2wi,w2cbw003";
        vdd-supply = <&vaux4>;
    };
};

This device will be inserted in the driver-model tree between the uart
and the tty.

The tty-slave driver can replace any of the tty_operations functions
so a call by the tty can be intercepted before being handled by the uart.


Signed-off-by: NeilBrown <neil@brown.name>
---
 drivers/tty/Kconfig                |    1 
 drivers/tty/Makefile               |    1 
 drivers/tty/slave/Kconfig          |    7 ++
 drivers/tty/slave/Makefile         |    2 +
 drivers/tty/slave/tty_slave_core.c |  136 ++++++++++++++++++++++++++++++++++++
 drivers/tty/tty_io.c               |   54 +++++++++++---
 include/linux/tty.h                |    1 
 include/linux/tty_slave.h          |   26 +++++++
 8 files changed, 215 insertions(+), 13 deletions(-)
 create mode 100644 drivers/tty/slave/Kconfig
 create mode 100644 drivers/tty/slave/Makefile
 create mode 100644 drivers/tty/slave/tty_slave_core.c
 create mode 100644 include/linux/tty_slave.h

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b24aa010f68c..f9155a45ee7c 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -419,4 +419,5 @@ config DA_CONSOLE
 	help
 	  This enables a console on a Dash channel.
 
+source drivers/tty/slave/Kconfig
 endif # TTY
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 58ad1c05b7f8..ec57846eac29 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_GOLDFISH_TTY)	+= goldfish.o
 obj-$(CONFIG_DA_TTY)		+= metag_da.o
 
 obj-y += ipwireless/
+obj-y += slave/
diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
new file mode 100644
index 000000000000..3976760c2e28
--- /dev/null
+++ b/drivers/tty/slave/Kconfig
@@ -0,0 +1,7 @@
+menuconfig TTY_SLAVE
+	tristate "TTY slave devices"
+	depends on OF
+	help
+	  Devices which attach via a uart, but need extra
+	  driver support for power management etc.
+
diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
new file mode 100644
index 000000000000..65669acb392e
--- /dev/null
+++ b/drivers/tty/slave/Makefile
@@ -0,0 +1,2 @@
+
+obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
diff --git a/drivers/tty/slave/tty_slave_core.c b/drivers/tty/slave/tty_slave_core.c
new file mode 100644
index 000000000000..6218ea5bb69e
--- /dev/null
+++ b/drivers/tty/slave/tty_slave_core.c
@@ -0,0 +1,136 @@
+/*
+ * tty-slave-core - device bus for tty slaves
+ *
+ * Copyright (C) 2015 NeilBrown <neil@brown.name>
+ *
+ *    This program is free software; you can redistribute it and/or modify
+ *   it under the terms of the GNU General Public License as published by
+ *   the Free Software Foundation; either version 2 of the License, or
+ *   (at your option) any later version.
+ *
+ *    This program is distributed in the hope that it will be useful,
+ *   but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *   GNU General Public License for more details.
+ */
+
+/*
+ * A "tty-slave" is a device permanently attached to a particularly
+ * tty, typically wired to a UART.
+ * A tty-slave has two particular roles.
+ * Firstly it can intercept any tty_operations to provide extra control
+ * of the device.  For example it might intercept "open" and "close"
+ * in order to power the device up and down.  It might intercept
+ * "hangup" to toggle a reset line on the device.
+ *
+ * Secondly it appears as a parent of the tty in the device model, so
+ * that any attributes it presents are visible to udev when the tty
+ * is added.  This allows udev to start appropriate handlers such as
+ * hciattach or inputattach.
+ *
+ * tty-slave devices must be described in devicetree as a child node
+ * of the node which described the parent of the tty, typically a
+ * UART.
+ * If such a child is present, the tty device will not be registered
+ * until the slave device is fully probed and initialized.
+ */
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/errno.h>
+#include <linux/device.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/tty.h>
+#include <linux/tty_driver.h>
+#include <linux/tty_slave.h>
+
+
+static int tty_slave_match(struct device *dev, struct device_driver *drv)
+{
+	return of_driver_match_device(dev, drv);
+}
+
+static void tty_slave_release(struct device *dev)
+{
+	kfree(dev);
+}
+
+struct bus_type tty_slave_bus_type = {
+	.name		= "tty-slave",
+	.match		= tty_slave_match,
+};
+
+int tty_slave_register(struct device *parent, struct device_node *node,
+		       struct device *tty, struct tty_driver *drv)
+{
+	struct tty_slave *slave;
+	int retval;
+
+	if (!of_get_property(node, "compatible", NULL))
+		return -ENODEV;
+
+	slave = kzalloc(sizeof(*slave), GFP_KERNEL);
+	if (!slave)
+		return -ENOMEM;
+
+	slave->dev.bus = &tty_slave_bus_type;
+	slave->dev.parent = parent;
+	slave->dev.release = tty_slave_release;
+	slave->dev.of_node = of_node_get(node);
+	dev_set_name(&slave->dev, "%s", node->name);
+	slave->tty_dev = tty;
+	slave->tty_drv = drv;
+	slave->ops = *drv->ops;
+	retval = device_register(&slave->dev);
+	if (retval) {
+		of_node_put(node);
+		kfree(slave);
+	}
+	return retval;
+}
+EXPORT_SYMBOL(tty_slave_register);
+
+void tty_slave_activate(struct tty_struct *tty)
+{
+	struct device *parent = NULL;
+	if (tty->dev)
+		parent = tty->dev->parent;
+	if (parent &&
+	    parent->bus == &tty_slave_bus_type)
+	{
+		struct tty_slave *dev =
+			container_of(parent, struct tty_slave, dev);
+		tty->ops = &dev->ops;
+	}
+}
+EXPORT_SYMBOL(tty_slave_activate);
+
+int tty_slave_finalize(struct tty_slave *slave)
+{
+	slave->tty_dev->parent = &slave->dev;
+	return tty_register_finalize(slave->tty_drv,
+				     slave->tty_dev);
+}
+EXPORT_SYMBOL(tty_slave_finalize);
+
+int tty_slave_driver_register(struct device_driver *drv)
+{
+	drv->bus = &tty_slave_bus_type;
+	return driver_register(drv);
+}
+EXPORT_SYMBOL(tty_slave_driver_register);
+
+static int __init tty_slave_init(void)
+{
+	return bus_register(&tty_slave_bus_type);
+}
+
+static void __exit tty_slave_exit(void)
+{
+	bus_unregister(&tty_slave_bus_type);
+}
+
+postcore_initcall(tty_slave_init);
+module_exit(tty_slave_exit);
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 27632ad17d6f..2b2d3b549a58 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -95,6 +95,8 @@
 #include <linux/seq_file.h>
 #include <linux/serial.h>
 #include <linux/ratelimit.h>
+#include <linux/of.h>
+#include <linux/tty_slave.h>
 
 #include <linux/uaccess.h>
 
@@ -3124,6 +3126,7 @@ struct tty_struct *alloc_tty_struct(struct tty_driver *driver, int idx)
 	tty->index = idx;
 	tty_line_name(driver, idx, tty->name);
 	tty->dev = tty_get_device(tty);
+	tty_slave_activate(tty);
 
 	return tty;
 }
@@ -3205,6 +3208,29 @@ static void tty_device_create_release(struct device *dev)
 	kfree(dev);
 }
 
+int tty_register_finalize(struct tty_driver *driver, struct device *dev)
+{
+	int retval;
+	bool cdev = false;
+	int index = dev->devt - MKDEV(driver->major,
+				      driver->minor_start);
+	printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start, dev->devt, index);
+	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
+		retval = tty_cdev_add(driver,
+				      dev->devt,
+				      index, 1);
+		if (retval)
+			return retval;
+		cdev = true;
+	}
+	retval = device_register(dev);
+	if (retval == 0)
+		return 0;
+	if (cdev)
+		cdev_del(&driver->cdevs[index]);
+	return retval;
+}
+EXPORT_SYMBOL(tty_register_finalize);
 /**
  *	tty_register_device_attr - register a tty device
  *	@driver: the tty driver that describes the tty device
@@ -3234,7 +3260,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
 	dev_t devt = MKDEV(driver->major, driver->minor_start) + index;
 	struct device *dev = NULL;
 	int retval = -ENODEV;
-	bool cdev = false;
+	struct device_node *node;
+	bool slave_registered = false;
 
 	if (index >= driver->num) {
 		printk(KERN_ERR "Attempt to register invalid tty line number "
@@ -3247,13 +3274,6 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
 	else
 		tty_line_name(driver, index, name);
 
-	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
-		retval = tty_cdev_add(driver, devt, index, 1);
-		if (retval)
-			goto error;
-		cdev = true;
-	}
-
 	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
 	if (!dev) {
 		retval = -ENOMEM;
@@ -3268,16 +3288,24 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
 	dev->groups = attr_grp;
 	dev_set_drvdata(dev, drvdata);
 
-	retval = device_register(dev);
-	if (retval)
-		goto error;
+	if (device && device->of_node)
+		for_each_available_child_of_node(device->of_node, node) {
+			if (tty_slave_register(device, node, dev, driver) == 0)
+				slave_registered = true;
+			if (slave_registered)
+				break;
+		}
+
+	if (!slave_registered) {
+		retval = tty_register_finalize(driver, dev);
+		if (retval)
+			goto error;
+	}
 
 	return dev;
 
 error:
 	put_device(dev);
-	if (cdev)
-		cdev_del(&driver->cdevs[index]);
 	return ERR_PTR(retval);
 }
 EXPORT_SYMBOL_GPL(tty_register_device_attr);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 04d5f1213700..efb4e053b856 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -373,6 +373,7 @@ extern void proc_clear_tty(struct task_struct *p);
 extern struct tty_struct *get_current_tty(void);
 /* tty_io.c */
 extern int __init tty_init(void);
+extern int tty_register_finalize(struct tty_driver *driver, struct device *dev);
 #else
 static inline void console_init(void)
 { }
diff --git a/include/linux/tty_slave.h b/include/linux/tty_slave.h
new file mode 100644
index 000000000000..21bfd7c01a2e
--- /dev/null
+++ b/include/linux/tty_slave.h
@@ -0,0 +1,26 @@
+
+struct tty_slave {
+	struct device *tty_dev;
+	struct tty_driver *tty_drv;
+	struct tty_operations ops;
+	struct device dev;
+};
+
+int tty_slave_finalize(struct tty_slave *slave);
+int tty_slave_driver_register(struct device_driver *drv);
+#if config_enabled(CONFIG_TTY_SLAVE)
+void tty_slave_activate(struct tty_struct *tty);
+int tty_slave_register(struct device *parent, struct device_node *node,
+		       struct device *tty, struct tty_driver *drv);
+#else
+static inline void tty_slave_activate(struct tty_struct *tty)
+{
+}
+static inline int tty_slave_register(struct device *parent,
+				     struct device_node *node,
+				     struct device *tty,
+				     struct tty_driver *drv)
+{
+	return -ENODEV;
+}
+#endif

Re: [PATCH 2/3] TTY: add support for tty_slave devices.

[Paul Bolle]

Just two nits to look into once you get to fix up all the smaller
issues.

NeilBrown schreef op wo 18-03-2015 om 16:58 [+1100]:
> --- /dev/null
> +++ b/drivers/tty/slave/Kconfig
> @@ -0,0 +1,7 @@
> +menuconfig TTY_SLAVE
> +	tristate "TTY slave devices"
> +	depends on OF
> +	help
> +	  Devices which attach via a uart, but need extra
> +	  driver support for power management etc.
> +

This blank line makes "git am" whine: "new blank line at EOF".

> --- /dev/null
> +++ b/drivers/tty/slave/tty_slave_core.c

[...]

This file doesn't have a MODULE_LICENSE() macro. So I think that, if
this driver is built as a module and loaded, kernel/module.c will set
its license to "unspecified" and taint the kernel.


Paul Bolle

Re: [PATCH 2/3] TTY: add support for tty_slave devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

On Wed, 18 Mar 2015 10:11:35 +0100 Paul Bolle <pebolle@tiscali.nl> wrote:

> Just two nits to look into once you get to fix up all the smaller
> issues.

Thanks.  I've fixed both those nits.

NeilBrown


> 
> NeilBrown schreef op wo 18-03-2015 om 16:58 [+1100]:
> > --- /dev/null
> > +++ b/drivers/tty/slave/Kconfig
> > @@ -0,0 +1,7 @@
> > +menuconfig TTY_SLAVE
> > +	tristate "TTY slave devices"
> > +	depends on OF
> > +	help
> > +	  Devices which attach via a uart, but need extra
> > +	  driver support for power management etc.
> > +
> 
> This blank line makes "git am" whine: "new blank line at EOF".
> 
> > --- /dev/null
> > +++ b/drivers/tty/slave/tty_slave_core.c
> 
> [...]
> 
> This file doesn't have a MODULE_LICENSE() macro. So I think that, if
> this driver is built as a module and loaded, kernel/module.c will set
> its license to "unspecified" and taint the kernel.
> 
> 
> Paul Bolle
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCH 2/3] TTY: add support for tty_slave devices.

[Pavel Machek]

Hi!

(And yes, I now see dts examples, sorry for the noise.)

Acked-by: Pavel Machek <pavel@ucw.cz>

Minor nits below.

> --- /dev/null
> +++ b/drivers/tty/slave/tty_slave_core.c
> @@ -0,0 +1,136 @@
> +/*
> + * tty-slave-core - device bus for tty slaves

Filename actually uses underscores.

> +			container_of(parent, struct tty_slave, dev);
> +		tty->ops = &dev->ops;
> +	}
> +}
> +EXPORT_SYMBOL(tty_slave_activate);

Not "_GPL"?

> +postcore_initcall(tty_slave_init);
> +module_exit(tty_slave_exit);

Should it have MODULE_LICENSE tag?


> +int tty_register_finalize(struct tty_driver *driver, struct device *dev)
> +{
> +	int retval;
> +	bool cdev = false;
> +	int index = dev->devt - MKDEV(driver->major,
> +				      driver->minor_start);
> +	printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start, dev->devt, index);

That printk should probably be removed for merge?

> +	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> +		retval = tty_cdev_add(driver,
> +				      dev->devt,
> +				      index, 1);

You can put this on one line.

> --- /dev/null
> +++ b/include/linux/tty_slave.h
> @@ -0,0 +1,26 @@
> +
> +struct tty_slave {
> +	struct device *tty_dev;
> +	struct tty_driver *tty_drv;
> +	struct tty_operations ops;
> +	struct device dev;
> +};

Header files usually have #include guards, and some kind of comment on
top.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2350 bytes --]

On Fri, 20 Mar 2015 20:41:50 +0100 Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> (And yes, I now see dts examples, sorry for the noise.)
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> Minor nits below.
> 
> > --- /dev/null
> > +++ b/drivers/tty/slave/tty_slave_core.c
> > @@ -0,0 +1,136 @@
> > +/*
> > + * tty-slave-core - device bus for tty slaves
> 
> Filename actually uses underscores.

The filename uses underscores because all the filenames in drivers/tty do.
And this isn't a file name, it is more like a module name, and the module
tools treat '-' and '_' as equivalent.
And I prefer hyphen....

I looked at other files in drivers/tty and decided noticed that they use
spaces to separate words in this context (novel concept :-) so I've done the
same.

> 
> > +			container_of(parent, struct tty_slave, dev);
> > +		tty->ops = &dev->ops;
> > +	}
> > +}
> > +EXPORT_SYMBOL(tty_slave_activate);
> 
> Not "_GPL"?

Other exports in the files are just EXPORT_SYMBOL, so I copied.
I don't feel strongly (the code is GPL anyway) so just follow what
surrounding code does.

> 
> > +postcore_initcall(tty_slave_init);
> > +module_exit(tty_slave_exit);
> 
> Should it have MODULE_LICENSE tag?

Yes. Added.

> 
> 
> > +int tty_register_finalize(struct tty_driver *driver, struct device *dev)
> > +{
> > +	int retval;
> > +	bool cdev = false;
> > +	int index = dev->devt - MKDEV(driver->major,
> > +				      driver->minor_start);
> > +	printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start, dev->devt, index);
> 
> That printk should probably be removed for merge?

Gone.

> 
> > +	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> > +		retval = tty_cdev_add(driver,
> > +				      dev->devt,
> > +				      index, 1);
> 
> You can put this on one line.

Indeed.  Done.

> 
> > --- /dev/null
> > +++ b/include/linux/tty_slave.h
> > @@ -0,0 +1,26 @@
> > +
> > +struct tty_slave {
> > +	struct device *tty_dev;
> > +	struct tty_driver *tty_drv;
> > +	struct tty_operations ops;
> > +	struct device dev;
> > +};
> 
> Header files usually have #include guards, and some kind of comment on
> top.
> 
> 									Pavel

Of 1996 files in include/linux, 1851 seem to do that.  That's enough to
convince me.  I've done it too.

Thanks,
NeilBrown


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.

[Pavel Machek]

Hi!

> > Header files usually have #include guards, and some kind of comment on
> > top.
> 
> Of 1996 files in include/linux, 1851 seem to do that.  That's enough to
> convince me.  I've done it too.

:-)). Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.

[Pavel Machek]

Hi!

> > Header files usually have #include guards, and some kind of comment on
> > top.
> 
> Of 1996 files in include/linux, 1851 seem to do that.  That's enough to
> convince me.  I've done it too.

:-)). Thanks,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] TTY: add support for tty_slave devices.

[Jiri Slaby]

Hi,

On 03/18/2015, 06:58 AM, NeilBrown wrote:
> --- /dev/null
> +++ b/drivers/tty/slave/tty_slave_core.c
> @@ -0,0 +1,136 @@

...

> +static int tty_slave_match(struct device *dev, struct device_driver *drv)
> +{
> +	return of_driver_match_device(dev, drv);
> +}
> +
> +static void tty_slave_release(struct device *dev)
> +{
> +	kfree(dev);

This should free the slave where the dev is contained. This is never
called IMO due to missing put_device's in the code.

> +}
> +
> +struct bus_type tty_slave_bus_type = {
> +	.name		= "tty-slave",
> +	.match		= tty_slave_match,
> +};
> +
> +int tty_slave_register(struct device *parent, struct device_node *node,
> +		       struct device *tty, struct tty_driver *drv)
> +{
> +	struct tty_slave *slave;
> +	int retval;
> +
> +	if (!of_get_property(node, "compatible", NULL))
> +		return -ENODEV;
> +
> +	slave = kzalloc(sizeof(*slave), GFP_KERNEL);
> +	if (!slave)
> +		return -ENOMEM;
> +

device_initialize();

> +	slave->dev.bus = &tty_slave_bus_type;
> +	slave->dev.parent = parent;
> +	slave->dev.release = tty_slave_release;
> +	slave->dev.of_node = of_node_get(node);
> +	dev_set_name(&slave->dev, "%s", node->name);
> +	slave->tty_dev = tty;
> +	slave->tty_drv = drv;
> +	slave->ops = *drv->ops;
> +	retval = device_register(&slave->dev);
> +	if (retval) {
> +		of_node_put(node);
> +		kfree(slave);

Do device_put() instead of the two. And do the two in .release.

> +	}
> +	return retval;
> +}
> +EXPORT_SYMBOL(tty_slave_register);
...
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
...
> @@ -3205,6 +3208,29 @@ static void tty_device_create_release(struct device *dev)
>  	kfree(dev);
>  }
>  
> +int tty_register_finalize(struct tty_driver *driver, struct device *dev)
> +{
> +	int retval;
> +	bool cdev = false;
> +	int index = dev->devt - MKDEV(driver->major,
> +				      driver->minor_start);
> +	printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start, dev->devt, index);
> +	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> +		retval = tty_cdev_add(driver,
> +				      dev->devt,
> +				      index, 1);
> +		if (retval)
> +			return retval;
> +		cdev = true;
> +	}
> +	retval = device_register(dev);
> +	if (retval == 0)
> +		return 0;
> +	if (cdev)
> +		cdev_del(&driver->cdevs[index]);
> +	return retval;
> +}
> +EXPORT_SYMBOL(tty_register_finalize);
>  /**
>   *	tty_register_device_attr - register a tty device
>   *	@driver: the tty driver that describes the tty device
> @@ -3234,7 +3260,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
>  	dev_t devt = MKDEV(driver->major, driver->minor_start) + index;
>  	struct device *dev = NULL;
>  	int retval = -ENODEV;
> -	bool cdev = false;
> +	struct device_node *node;
> +	bool slave_registered = false;
>  
>  	if (index >= driver->num) {
>  		printk(KERN_ERR "Attempt to register invalid tty line number "
> @@ -3247,13 +3274,6 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
>  	else
>  		tty_line_name(driver, index, name);
>  
> -	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> -		retval = tty_cdev_add(driver, devt, index, 1);
> -		if (retval)
> -			goto error;
> -		cdev = true;
> -	}
> -
>  	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>  	if (!dev) {
>  		retval = -ENOMEM;
> @@ -3268,16 +3288,24 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
>  	dev->groups = attr_grp;
>  	dev_set_drvdata(dev, drvdata);
>  
> -	retval = device_register(dev);
> -	if (retval)
> -		goto error;
> +	if (device && device->of_node)
> +		for_each_available_child_of_node(device->of_node, node) {
> +			if (tty_slave_register(device, node, dev, driver) == 0)
> +				slave_registered = true;
> +			if (slave_registered)
> +				break;
> +		}
> +
> +	if (!slave_registered) {
> +		retval = tty_register_finalize(driver, dev);
> +		if (retval)
> +			goto error;
> +	}
>  
>  	return dev;

And what about ttys not using the tty_register_device* helpers?

What happens when the tty is unregistered?

> --- /dev/null
> +++ b/include/linux/tty_slave.h
> @@ -0,0 +1,26 @@
> +
> +struct tty_slave {
> +	struct device *tty_dev;
> +	struct tty_driver *tty_drv;
> +	struct tty_operations ops;
> +	struct device dev;
> +};
> +
> +int tty_slave_finalize(struct tty_slave *slave);
> +int tty_slave_driver_register(struct device_driver *drv);
> +#if config_enabled(CONFIG_TTY_SLAVE)

Since TTY_SLAVE is tristate, this will work only for TTY_SLAVE == y, not
m. Use IS_ENABLED instead.

> +void tty_slave_activate(struct tty_struct *tty);
> +int tty_slave_register(struct device *parent, struct device_node *node,
> +		       struct device *tty, struct tty_driver *drv);
> +#else
> +static inline void tty_slave_activate(struct tty_struct *tty)
> +{
> +}
> +static inline int tty_slave_register(struct device *parent,
> +				     struct device_node *node,
> +				     struct device *tty,
> +				     struct tty_driver *drv)
> +{
> +	return -ENODEV;
> +}
> +#endif

thanks,
-- 
js
suse labs

Re: [PATCH 2/3] TTY: add support for tty_slave devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 5974 bytes --]

On Tue, 24 Mar 2015 11:31:55 +0100 Jiri Slaby <jslaby@suse.cz> wrote:

> Hi,
> 
> On 03/18/2015, 06:58 AM, NeilBrown wrote:
> > --- /dev/null
> > +++ b/drivers/tty/slave/tty_slave_core.c
> > @@ -0,0 +1,136 @@
> 
> ...
> 
> > +static int tty_slave_match(struct device *dev, struct device_driver *drv)
> > +{
> > +	return of_driver_match_device(dev, drv);
> > +}
> > +
> > +static void tty_slave_release(struct device *dev)
> > +{
> > +	kfree(dev);
> 
> This should free the slave where the dev is contained. This is never
> called IMO due to missing put_device's in the code.

Yes of course, thanks.  I've fix the 'kfree'.


> 
> > +}
> > +
> > +struct bus_type tty_slave_bus_type = {
> > +	.name		= "tty-slave",
> > +	.match		= tty_slave_match,
> > +};
> > +
> > +int tty_slave_register(struct device *parent, struct device_node *node,
> > +		       struct device *tty, struct tty_driver *drv)
> > +{
> > +	struct tty_slave *slave;
> > +	int retval;
> > +
> > +	if (!of_get_property(node, "compatible", NULL))
> > +		return -ENODEV;
> > +
> > +	slave = kzalloc(sizeof(*slave), GFP_KERNEL);
> > +	if (!slave)
> > +		return -ENOMEM;
> > +
> 
> device_initialize();

device_initialize is only needed if you call device_add()
I use device_register() which calls both.


> 
> > +	slave->dev.bus = &tty_slave_bus_type;
> > +	slave->dev.parent = parent;
> > +	slave->dev.release = tty_slave_release;
> > +	slave->dev.of_node = of_node_get(node);
> > +	dev_set_name(&slave->dev, "%s", node->name);
> > +	slave->tty_dev = tty;
> > +	slave->tty_drv = drv;
> > +	slave->ops = *drv->ops;
> > +	retval = device_register(&slave->dev);
> > +	if (retval) {
> > +		of_node_put(node);
> > +		kfree(slave);
> 
> Do device_put() instead of the two. And do the two in .release.

Done, thanks.

> 
> > +	}
> > +	return retval;
> > +}
> > +EXPORT_SYMBOL(tty_slave_register);
> ...
> > --- a/drivers/tty/tty_io.c
> > +++ b/drivers/tty/tty_io.c
> ...
> > @@ -3205,6 +3208,29 @@ static void tty_device_create_release(struct device *dev)
> >  	kfree(dev);
> >  }
> >  
> > +int tty_register_finalize(struct tty_driver *driver, struct device *dev)
> > +{
> > +	int retval;
> > +	bool cdev = false;
> > +	int index = dev->devt - MKDEV(driver->major,
> > +				      driver->minor_start);
> > +	printk("REGISTER %d %d 0x%x %d\n", driver->major, driver->minor_start, dev->devt, index);
> > +	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> > +		retval = tty_cdev_add(driver,
> > +				      dev->devt,
> > +				      index, 1);
> > +		if (retval)
> > +			return retval;
> > +		cdev = true;
> > +	}
> > +	retval = device_register(dev);
> > +	if (retval == 0)
> > +		return 0;
> > +	if (cdev)
> > +		cdev_del(&driver->cdevs[index]);
> > +	return retval;
> > +}
> > +EXPORT_SYMBOL(tty_register_finalize);
> >  /**
> >   *	tty_register_device_attr - register a tty device
> >   *	@driver: the tty driver that describes the tty device
> > @@ -3234,7 +3260,8 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
> >  	dev_t devt = MKDEV(driver->major, driver->minor_start) + index;
> >  	struct device *dev = NULL;
> >  	int retval = -ENODEV;
> > -	bool cdev = false;
> > +	struct device_node *node;
> > +	bool slave_registered = false;
> >  
> >  	if (index >= driver->num) {
> >  		printk(KERN_ERR "Attempt to register invalid tty line number "
> > @@ -3247,13 +3274,6 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
> >  	else
> >  		tty_line_name(driver, index, name);
> >  
> > -	if (!(driver->flags & TTY_DRIVER_DYNAMIC_ALLOC)) {
> > -		retval = tty_cdev_add(driver, devt, index, 1);
> > -		if (retval)
> > -			goto error;
> > -		cdev = true;
> > -	}
> > -
> >  	dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> >  	if (!dev) {
> >  		retval = -ENOMEM;
> > @@ -3268,16 +3288,24 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
> >  	dev->groups = attr_grp;
> >  	dev_set_drvdata(dev, drvdata);
> >  
> > -	retval = device_register(dev);
> > -	if (retval)
> > -		goto error;
> > +	if (device && device->of_node)
> > +		for_each_available_child_of_node(device->of_node, node) {
> > +			if (tty_slave_register(device, node, dev, driver) == 0)
> > +				slave_registered = true;
> > +			if (slave_registered)
> > +				break;
> > +		}
> > +
> > +	if (!slave_registered) {
> > +		retval = tty_register_finalize(driver, dev);
> > +		if (retval)
> > +			goto error;
> > +	}
> >  
> >  	return dev;
> 
> And what about ttys not using the tty_register_device* helpers?

I guess they are on their own - they don't get any help...
Is there a problem that I'm not seeing here?

I think this only applies to code that calls device_create(tty_class, ...)
which is pty.c, vt.c, and "/dev/tty".  These are all virtual devices so
having a slave doesn't make much sense... does it?

> 
> What happens when the tty is unregistered?

Good question.  I hadn't thought that through.

When the tty is unregistered, it will drop the reference it has on ->parent
which the tty_slave.  So we want that to be the last reference.
So in tty_slave_finalize() I need a put_dev() on the slave.
That must be the "put_dev" that you thought was missing earlier.

However that leaves a loose end. destruct_tty_driver() calls
tty_unregister_device() on all registered ttys for that driver.
If one had a tty_slave which was finalized, that will drop the reference on
the slave so it will disappear, which is all good.
But if one has a slave for which the driver hasn't been found yet, then there
will be no tty to unregister so the tty_slave cannot be dropped.

I guess I need to either take a reference to the driver - which doesn't seem
like a good idea - or use bus_find_device() to find any tty_slaves with that
driver, and drop them.
I'll see how that works out.


Thanks a lot!

NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCH 2/3] TTY: add support for tty_slave devices.

[Peter Hurley]

On 03/18/2015 01:58 AM, NeilBrown wrote:

> + * A "tty-slave" is a device permanently attached to a particularly
> + * tty, typically wired to a UART.

Why "permanently"?
Is that a limitation of the implementation or design?

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Wed, 25 Mar 2015 12:30:00 -0400 Peter Hurley <peter@hurleysoftware.com>
wrote:

> On 03/18/2015 01:58 AM, NeilBrown wrote:
> 
> > + * A "tty-slave" is a device permanently attached to a particularly
> > + * tty, typically wired to a UART.
> 
> Why "permanently"?
> Is that a limitation of the implementation or design?
> 

The slave is described in devicetree - that only happens for permanently
attached devices, doesn't it?

I guess that with device-tree overlays and 'capes' for boards you could have
a device attached to the uart "for this power session" rather than
"permanently", but I think it is a rather subtle distinction.

Did you have something else in mind?

NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.

[Peter Hurley]

On 03/25/2015 05:17 PM, NeilBrown wrote:
> On Wed, 25 Mar 2015 12:30:00 -0400 Peter Hurley <peter@hurleysoftware.com>
> wrote:
> 
>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>
>>> + * A "tty-slave" is a device permanently attached to a particularly
>>> + * tty, typically wired to a UART.
>>
>> Why "permanently"?
>> Is that a limitation of the implementation or design?
>>
> 
> The slave is described in devicetree - that only happens for permanently
> attached devices, doesn't it?
> 
> I guess that with device-tree overlays and 'capes' for boards you could have
> a device attached to the uart "for this power session" rather than
> "permanently", but I think it is a rather subtle distinction.
> 
> Did you have something else in mind?

My primary concern is that the abstraction match the scope.

If the abstraction is at the tty layer, then the scope of the design
should support tty devices, not just hard-wired, devicetree-defined uarts.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 2/3] TTY: add support for tty_slave devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2516 bytes --]

On Fri, 27 Mar 2015 07:09:56 -0400 Peter Hurley <peter@hurleysoftware.com>
wrote:

> On 03/25/2015 05:17 PM, NeilBrown wrote:
> > On Wed, 25 Mar 2015 12:30:00 -0400 Peter Hurley <peter@hurleysoftware.com>
> > wrote:
> > 
> >> On 03/18/2015 01:58 AM, NeilBrown wrote:
> >>
> >>> + * A "tty-slave" is a device permanently attached to a particularly
> >>> + * tty, typically wired to a UART.
> >>
> >> Why "permanently"?
> >> Is that a limitation of the implementation or design?
> >>
> > 
> > The slave is described in devicetree - that only happens for permanently
> > attached devices, doesn't it?
> > 
> > I guess that with device-tree overlays and 'capes' for boards you could have
> > a device attached to the uart "for this power session" rather than
> > "permanently", but I think it is a rather subtle distinction.
> > 
> > Did you have something else in mind?
> 
> My primary concern is that the abstraction match the scope.
> 
> If the abstraction is at the tty layer, then the scope of the design
> should support tty devices, not just hard-wired, devicetree-defined uarts.

I think I see your point, and I tend to agree.  However there is a limit to
how closely we can reach the ideal...

I see a lot of conceptual overlap between line discipline and tty_slaves.
They both provide extra driver support for the thing which the tty talks to.

Line disciplines can be configured at runtime depending on what is found to
be attached.  tty_slaves are configure at boot time depending what is
declared to be attached in device-tree.

line disciplines are a lot like device drivers, but aren't implemented that
way for sound historical reasons.  I think it would be nice if they were, but
they aren't.
tty_slaves really need to be devices with device drivers so that they can
utilise information from devicetree.

line disciplines do not and cannot know about any hardware other than the
standard UART.  tty_slaves exist so that they can know about regulators and
GPIOs and anything else that might combine with the UART to control a
particular device.

So tty_slaves are really specifically for devices which present a tty, but
have more hardware controls than just a UART.  Anything that doesn't have
more hardware controls is probably best handled from user-space or in a line
discipline.

And if there are more hardware controls, then it is sure to be permanently
attached.

Does that make sense?  Does it allay your concerns?

Thanks,
NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

[PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

If a platform has a particular device permanently attached to a UART,
there may be out-of-band signaling necessary to power the device
on and off.

This driver controls that signalling for a number of different devices.
It can
 - enable/disable a regulator
 - toggle a GPIO
 - register an 'rfkill' which can force the device to be off.

When the rfkill is absent or unblocked, the device will be on when the
associated tty device is open, and closed otherwise.

Signed-off-by: NeilBrown <neil@brown.name>
---
 .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
 .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
 .../devicetree/bindings/vendor-prefixes.txt        |    1 
 drivers/tty/slave/Kconfig                          |   14 +
 drivers/tty/slave/Makefile                         |    2 
 drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
 6 files changed, 583 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
 create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
 create mode 100644 drivers/tty/slave/serial-power-manager.c

diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
new file mode 100644
index 000000000000..cfe6ee5e01e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
@@ -0,0 +1,19 @@
+wi2wi bluetooth module
+
+This is accessed via a serial port and is largely controlled via that
+link.  Extra configuration is needed to enable power on/off
+
+Required properties:
+- compatible: "wi2wi,w2cbw003"
+- vdd-supply: regulator used to power the device.
+
+The node for this device must be the child of a UART.
+
+Example:
+
+&uart1 {
+       bluetooth {
+               compatible = "wi2wi,w2cbw003";
+               vdd-supply = <&vaux4>;
+       };
+};
diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
new file mode 100644
index 000000000000..fdc52cf56533
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
@@ -0,0 +1,37 @@
+wi2wi GPS device
+
+This is accessed via a serial port and is largely controlled via that
+link.  Extra configuration is needed to enable power on/off
+
+Required properties:
+- compatible: "wi2wi,w2sg0004"
+- gpios: gpios used to toggle 'on/off' pin
+- interrupts: interrupt generated by RX pin when device
+      should be off
+
+Optional properties:
+- vdd-supply: regulator used to power antenna
+- pinctrl: "default", "off"
+      if "off" setting is provided it is imposed when device should
+      be off.  This can route the RX pin to a GPIO interrupt.
+
+The w2sg0004 uses a pin-toggle both to power-on and to
+power-off, so the driver needs to detect what state it is in.
+It does this by detecting characters on the RX line.
+When it should be off, these can optionally be detected by a GPIO.
+
+The node for this device must be the child of a UART.
+
+Example:
+&uart2 {
+       gps {
+               compatible = "wi2iw,w2sg0004";
+               vdd-supply = <&vsim>;
+               gpios = <&gpio5 17 0>; /* GPIO_145 */
+               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
+               /* When off, switch RX to be an interrupt */
+               pinctrl-names = "default", "off";
+               pinctrl-0 = <&uart2_pins>;
+               pinctrl-1 = <&uart2_pins_rx_gpio>;
+       };
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca1347a77..81d259303710 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -189,6 +189,7 @@ variscite	Variscite Ltd.
 via	VIA Technologies, Inc.
 virtio	Virtual I/O Device Specification, developed by the OASIS consortium
 voipac	Voipac Technologies s.r.o.
+wi2wi	wi2wi Inc.  http://www.wi2wi.com/
 winbond Winbond Electronics corp.
 wlf	Wolfson Microelectronics
 wm	Wondermedia Technologies, Inc.
diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
index 3976760c2e28..05c5d966ae57 100644
--- a/drivers/tty/slave/Kconfig
+++ b/drivers/tty/slave/Kconfig
@@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
 	  Devices which attach via a uart, but need extra
 	  driver support for power management etc.
 
+if TTY_SLAVE
+
+config SERIAL_POWER_MANAGER
+	tristate "Power Management controller for serial-attached devices"
+	default n
+	help
+	  Some devices permanently attached via a UART can benefit from
+	  being power-managed when the tty device is opened or closed.
+	  This driver can support several such devices with simple
+	  power requirements such as enabling a regulator.
+
+	  If in doubt, say 'N'
+
+endif
diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
index 65669acb392e..a2f7d2847319 100644
--- a/drivers/tty/slave/Makefile
+++ b/drivers/tty/slave/Makefile
@@ -1,2 +1,4 @@
 
 obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
+
+obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
new file mode 100644
index 000000000000..662a526d8630
--- /dev/null
+++ b/drivers/tty/slave/serial-power-manager.c
@@ -0,0 +1,510 @@
+/*
+ * Serial-power-manager
+ * tty-slave device that intercepts open/close events on the tty,
+ * and turns power on/off for the device which is connected.
+ *
+ * Currently supported devices:
+ *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
+ *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
+ *
+ * When appropriate, an RFKILL will be registered which
+ * can power-down the device even when it is open.
+ *
+ * Device can be turned on either by
+ *  - enabling a regulator.  Disable to turn off
+ *  - toggling a GPIO.  Toggle again to turn off.  This requires
+ *     that we know the current state.  It is assumed to be 'off'
+ *     at boot, however if an interrupt can be generated when on,
+ *     such as by connecting RX to a GPIO, that can be used to detect
+ *     if the device is on when it should be off.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/err.h>
+#include <linux/regulator/consumer.h>
+#include <linux/platform_device.h>
+#include <linux/of_device.h>
+#include <linux/tty.h>
+#include <linux/gpio.h>
+#include <linux/of_gpio.h>
+#include <linux/of_irq.h>
+#include <linux/interrupt.h>
+#include <linux/delay.h>
+#include <linux/rfkill.h>
+
+#include <linux/tty_slave.h>
+
+/* This is used for testing. Setting this module parameter
+ * will simulate booting with the device "on"
+ */
+static bool toggle_on_probe = false;
+module_param(toggle_on_probe, bool, 0);
+MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
+
+struct spm_config {
+	int	rfkill_type;		/* type of rfkill to register */
+	int	toggle_time;		/* msec to pulse GPIO for on/off */
+	int	toggle_gap;		/* min msecs between toggles */
+	bool	off_in_suspend;
+}
+	simple_config = {
+		.off_in_suspend = true,
+	},
+	w2sg_config = {
+		.rfkill_type = RFKILL_TYPE_GPS,
+		.toggle_time = 10,
+		.toggle_gap = 500,
+		.off_in_suspend = true,
+	};
+
+const static struct of_device_id spm_dt_ids[] = {
+       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
+       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},
+       {}
+};
+
+struct spm_data {
+	const struct spm_config *config;
+	struct gpio_desc *gpiod;
+	int		irq;	/* irq line from RX pin when pinctrl
+				 * set to 'idle' */
+	struct regulator *reg;
+
+	unsigned long	toggle_time;
+	unsigned long	toggle_gap;
+	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
+	unsigned long	backoff;	/* jiffies since last_toggle when
+					 * we try again
+					 */
+	enum {Idle, Down, Up} state;	/* state-machine state. */
+
+	int		open_cnt;
+	bool		requested, is_on;
+	bool		suspended;
+	bool		reg_enabled;
+
+	struct pinctrl	*pins;
+	struct pinctrl_state *pins_off;
+
+	struct delayed_work work;
+	spinlock_t	lock;
+	struct device	*dev;
+
+	struct rfkill	*rfkill;
+
+	int (*old_open)(struct tty_struct * tty, struct file * filp);
+	void (*old_close)(struct tty_struct * tty, struct file * filp);
+
+};
+
+/* When a device is powered on/off by toggling a GPIO we perform
+ * all the toggling via a workqueue to ensure only one toggle happens
+ * at a time and to allow easy timing.
+ * This is managed as a state machine which transitions
+ *  Idle -> Down -> Up -> Idle
+ * The GPIO is held down for toggle_time and then up for toggle_time,
+ * and then we assume the device has changed state.
+ * We never toggle until at least toggle_gap has passed since the
+ * last toggle.
+ */
+static void toggle_work(struct work_struct *work)
+{
+	struct spm_data *data = container_of(
+		work, struct spm_data, work.work);
+
+	if (data->gpiod == NULL)
+		return;
+
+	spin_lock_irq(&data->lock);
+	switch (data->state) {
+	case Up:
+		data->state = Idle;
+		if (data->requested == data->is_on)
+			break;
+		if (!data->requested)
+			/* Assume it is off unless activity is detected */
+			break;
+		/* Try again in a while unless we get some activity */
+		dev_dbg(data->dev, "Wait %dusec until retry\n",
+			jiffies_to_msecs(data->backoff));
+		schedule_delayed_work(&data->work, data->backoff);
+		break;
+	case Idle:
+		if (data->requested == data->is_on)
+			break;
+
+		/* Time to toggle */
+		dev_dbg(data->dev, "Starting toggle to turn %s\n",
+			data->requested ? "on" : "off");
+		data->state = Down;
+		spin_unlock_irq(&data->lock);
+		gpiod_set_value_cansleep(data->gpiod, 1);
+		schedule_delayed_work(&data->work, data->toggle_time);
+
+		return;
+
+	case Down:
+		data->state = Up;
+		data->last_toggle = jiffies;
+		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
+			data->is_on ? "off" : "on");
+		data->is_on = ! data->is_on;
+		spin_unlock_irq(&data->lock);
+
+		gpiod_set_value_cansleep(data->gpiod, 0);
+		schedule_delayed_work(&data->work, data->toggle_time);
+
+		return;
+	}
+	spin_unlock_irq(&data->lock);
+}
+
+static irqreturn_t spm_isr(int irq, void *dev_id)
+{
+	struct spm_data *data = dev_id;
+	unsigned long flags;
+
+	spin_lock_irqsave(&data->lock, flags);
+	if (!data->requested && !data->is_on && data->state == Idle &&
+	    time_after(jiffies, data->last_toggle + data->backoff)) {
+		data->is_on = 1;
+		data->backoff *= 2;
+		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
+		if (!data->suspended)
+			schedule_delayed_work(&data->work, 0);
+	}
+	spin_unlock_irqrestore(&data->lock, flags);
+	return IRQ_HANDLED;
+}
+
+static void spm_on(struct spm_data *data)
+{
+	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
+		unsigned long flags;
+
+		if (!data->reg_enabled &&
+		    data->reg &&
+		    regulator_enable(data->reg) == 0)
+			data->reg_enabled = true;
+
+		spin_lock_irqsave(&data->lock, flags);
+		if (!data->requested) {
+			dev_dbg(data->dev, "TTY open - turn device on\n");
+			data->requested = true;
+			data->backoff = data->toggle_gap;
+			if (data->irq > 0) {
+				disable_irq(data->irq);
+				pinctrl_pm_select_default_state(data->dev);
+			}
+			if (!data->suspended && data->state == Idle)
+				schedule_delayed_work(&data->work, 0);
+		}
+		spin_unlock_irqrestore(&data->lock, flags);
+	}
+}
+
+static int spm_open(struct tty_struct *tty, struct file *filp)
+{
+	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
+
+	data->open_cnt++;
+	spm_on(data);
+	if (data->old_open)
+		return data->old_open(tty, filp);
+}
+
+static void spm_off(struct spm_data *data)
+{
+	unsigned long flags;
+
+	if (data->reg && data->reg_enabled)
+		if (regulator_disable(data->reg) == 0)
+			data->reg_enabled = false;
+
+	spin_lock_irqsave(&data->lock, flags);
+	if (data->requested) {
+		data->requested = false;
+		data->backoff = data->toggle_gap;
+		if (data->pins_off) {
+			pinctrl_select_state(data->pins,
+					     data->pins_off);
+			enable_irq(data->irq);
+		}
+		if (!data->suspended && data->state == Idle)
+			schedule_delayed_work(&data->work, 0);
+	}
+	spin_unlock_irqrestore(&data->lock, flags);
+}
+
+static void spm_close(struct tty_struct *tty, struct file *filp)
+{
+	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
+
+	data->open_cnt--;
+	if (!data->open_cnt) {
+		dev_dbg(data->dev, "TTY closed - turn device off\n");
+		spm_off(data);
+	}
+
+	if (data->old_close)
+		data->old_close(tty, filp);
+}
+
+static int spm_rfkill_set_block(void *vdata, bool blocked)
+{
+	struct spm_data *data = vdata;
+
+	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
+	if (blocked)
+		spm_off(data);
+
+	if (!blocked &&
+	    data->open_cnt)
+		spm_on(data);
+
+	return 0;
+}
+
+static struct rfkill_ops spm_rfkill_ops = {
+	.set_block = spm_rfkill_set_block,
+};
+
+static int spm_suspend(struct device *dev)
+{
+	/* Ignore incoming data and just turn device off.
+	 * we cannot really wait for a separate thread to
+	 * do things, so we disable that and do it all
+	 * here
+	 */
+	struct spm_data *data = dev_get_drvdata(dev);
+
+	spin_lock_irq(&data->lock);
+	data->suspended = true;
+	spin_unlock_irq(&data->lock);
+	if (!data->config->off_in_suspend)
+		return 0;
+
+	if (data->gpiod) {
+
+		cancel_delayed_work_sync(&data->work);
+		if (data->state == Down) {
+			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
+			msleep(data->config->toggle_time);
+			gpiod_set_value_cansleep(data->gpiod, 0);
+			data->last_toggle = jiffies;
+			data->is_on = !data->is_on;
+			data->state = Up;
+		}
+		if (data->state == Up) {
+			msleep(data->config->toggle_time);
+			data->state = Idle;
+		}
+		if (data->is_on) {
+			dev_dbg(data->dev, "Suspending while device on: toggling\n");
+			gpiod_set_value_cansleep(data->gpiod, 1);
+			msleep(data->config->toggle_time);
+			gpiod_set_value_cansleep(data->gpiod, 0);
+			data->is_on = 0;
+		}
+	}
+
+	if (data->reg && data->reg_enabled)
+		if (regulator_disable(data->reg) == 0)
+			data->reg_enabled = false;
+
+	return 0;
+}
+
+static int spm_resume(struct device *dev)
+{
+	struct spm_data *data = dev_get_drvdata(dev);
+
+	spin_lock_irq(&data->lock);
+	data->suspended = false;
+	spin_unlock_irq(&data->lock);
+	schedule_delayed_work(&data->work, 0);
+
+	if (data->open_cnt &&
+	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
+		if (!data->reg_enabled &&
+		    data->reg &&
+		    regulator_enable(data->reg) == 0)
+			data->reg_enabled = true;
+	}
+	return 0;
+}
+
+static const struct dev_pm_ops spm_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
+};
+
+static int spm_probe(struct device *dev)
+{
+	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
+	struct spm_data *data;
+	struct regulator *reg;
+	int err;
+	const struct of_device_id *id;
+	const char *name;
+
+	if (dev->parent == NULL)
+		return -ENODEV;
+
+	id = of_match_device(spm_dt_ids, dev);
+	if (!id)
+		return -ENODEV;
+
+	if (dev->of_node && dev->of_node->name)
+		name = dev->of_node->name;
+	else
+		name = "serial-power-manager";
+
+	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->config = id->data;
+	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
+	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
+	data->last_toggle = jiffies;
+	data->backoff = data->toggle_gap;
+	data->state = Idle;
+	spin_lock_init(&data->lock);
+	INIT_DELAYED_WORK(&data->work, toggle_work);
+
+	/* If a regulator is provided, it is enabled on 'open'
+	 * and disabled on 'release'
+	 */
+	reg = devm_regulator_get(dev, "vdd");
+	if (IS_ERR(reg)) {
+		err = PTR_ERR(reg);
+		if (err != -ENODEV)
+			goto out;
+	} else
+		data->reg = reg;
+
+	/* If an irq is provided, any transitions are taken as
+	 * indication that the device is currently "on"
+	 */
+	data->irq = of_irq_get(dev->of_node, 0);
+	if (data->irq < 0) {
+		err = data->irq;
+		if (err != -EINVAL)
+			goto out;
+	} else {
+		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
+
+		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
+		err = devm_request_irq(dev, data->irq, spm_isr,
+				       IRQF_TRIGGER_FALLING,
+				       name, data);
+
+		if (err)
+			goto out;
+
+	}
+
+	/* If a gpio is provided, then it is used to turn the device
+	 * on/off.
+	 * If toggle_time is zero, then the GPIO directly controls
+	 * the device.  If non-zero, then the GPIO must be toggled to
+	 * change the state of the device.
+	 */
+	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
+	if (IS_ERR(data->gpiod)) {
+		err = PTR_ERR(data->gpiod);
+		if (err != -ENOENT)
+			goto out;
+		data->gpiod = NULL;
+	} else
+		dev_dbg(dev, "GPIO configured: %d\n",
+			desc_to_gpio(data->gpiod));
+
+	/* If an 'off' pinctrl state is defined, we apply that
+	 * when the device is assumed to be off.  This is expected to
+	 * route the 'rx' line to the 'irq' interrupt.
+	 */
+	data->pins = devm_pinctrl_get(dev);
+	if (data->pins && data->irq > 0) {
+		data->pins_off = pinctrl_lookup_state(data->pins, "off");
+		if (IS_ERR(data->pins_off))
+			data->pins_off = NULL;
+	}
+
+	if (data->config->rfkill_type) {
+		data->rfkill = rfkill_alloc(name, dev,
+					    data->config->rfkill_type,
+					    &spm_rfkill_ops, data);
+		if (!data->rfkill) {
+			err = -ENOMEM;
+			goto out;
+		}
+		err = rfkill_register(data->rfkill);
+		if (err) {
+			dev_err(dev, "Cannot register rfkill device");
+			rfkill_destroy(data->rfkill);
+			goto out;
+		}
+	}
+	dev_set_drvdata(dev, data);
+	data->dev = dev;
+	data->old_open = slave->ops.open;
+	data->old_close = slave->ops.close;
+	slave->ops.open = spm_open;
+	slave->ops.close = spm_close;
+	tty_slave_finalize(slave);
+
+	if (data->pins_off)
+		pinctrl_select_state(data->pins, data->pins_off);
+	if (data->irq > 0)
+		enable_irq(data->irq);
+
+	if (toggle_on_probe && data->gpiod) {
+		dev_dbg(data->dev, "Performing initial toggle\n");
+		gpiod_set_value_cansleep(data->gpiod, 1);
+		msleep(data->config->toggle_time);
+		gpiod_set_value_cansleep(data->gpiod, 0);
+		msleep(data->config->toggle_time);
+	}
+	err = 0;
+out:
+	dev_dbg(data->dev, "Probed: err=%d\n", err);
+	return err;
+}
+
+static int spm_remove(struct device *dev)
+{
+       struct spm_data *data = dev_get_drvdata(dev);
+
+       if (data->rfkill) {
+               rfkill_unregister(data->rfkill);
+               rfkill_destroy(data->rfkill);
+       }
+       return 0;
+}
+
+static struct device_driver spm_driver = {
+	.name		= "serial-power-manager",
+	.owner		= THIS_MODULE,
+	.of_match_table	= spm_dt_ids,
+	.probe		= spm_probe,
+	.remove		= spm_remove,
+};
+
+static int __init spm_init(void)
+{
+       return tty_slave_driver_register(&spm_driver);
+}
+module_init(spm_init);
+
+static void __exit spm_exit(void)
+{
+	driver_unregister(&spm_driver);
+}
+module_exit(spm_exit);
+
+MODULE_AUTHOR("NeilBrown <neil@brown.name>");
+MODULE_DEVICE_TABLE(of, spm_dt_ids);
+MODULE_DESCRIPTION("Power management for Serial-attached device.");
+MODULE_LICENSE("GPL v2");

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:

> If a platform has a particular device permanently attached to a UART,
> there may be out-of-band signaling necessary to power the device
> on and off.
> 
> This driver controls that signalling for a number of different devices.
> It can
> - enable/disable a regulator
> - toggle a GPIO
> - register an 'rfkill' which can force the device to be off.
> 
> When the rfkill is absent or unblocked, the device will be on when the
> associated tty device is open, and closed otherwise.
> 
> Signed-off-by: NeilBrown <neil@brown.name>
> ---
> .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
> .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
> .../devicetree/bindings/vendor-prefixes.txt        |    1 
> drivers/tty/slave/Kconfig                          |   14 +
> drivers/tty/slave/Makefile                         |    2 
> drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
> 6 files changed, 583 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> create mode 100644 drivers/tty/slave/serial-power-manager.c
> 
> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> new file mode 100644
> index 000000000000..cfe6ee5e01e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> @@ -0,0 +1,19 @@
> +wi2wi bluetooth module
> +
> +This is accessed via a serial port and is largely controlled via that
> +link.  Extra configuration is needed to enable power on/off
> +
> +Required properties:
> +- compatible: "wi2wi,w2cbw003"
> +- vdd-supply: regulator used to power the device.
> +
> +The node for this device must be the child of a UART.
> +
> +Example:
> +
> +&uart1 {
> +       bluetooth {
> +               compatible = "wi2wi,w2cbw003";
> +               vdd-supply = <&vaux4>;
> +       };
> +};

Wouldn’t it be easier to simply write

&uart1 {
	vdd-suppy = <&vaux4>;
}

> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> new file mode 100644
> index 000000000000..fdc52cf56533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> @@ -0,0 +1,37 @@
> +wi2wi GPS device
> +
> +This is accessed via a serial port and is largely controlled via that
> +link.  Extra configuration is needed to enable power on/off
> +
> +Required properties:
> +- compatible: "wi2wi,w2sg0004"
> +- gpios: gpios used to toggle 'on/off' pin
> +- interrupts: interrupt generated by RX pin when device
> +      should be off
> +
> +Optional properties:
> +- vdd-supply: regulator used to power antenna
> +- pinctrl: "default", "off"
> +      if "off" setting is provided it is imposed when device should
> +      be off.  This can route the RX pin to a GPIO interrupt.
> +
> +The w2sg0004 uses a pin-toggle both to power-on and to
> +power-off, so the driver needs to detect what state it is in.
> +It does this by detecting characters on the RX line.
> +When it should be off, these can optionally be detected by a GPIO.
> +
> +The node for this device must be the child of a UART.
> +
> +Example:
> +&uart2 {
> +       gps {
> +               compatible = "wi2iw,w2sg0004";
> +               vdd-supply = <&vsim>;
> +               gpios = <&gpio5 17 0>; /* GPIO_145 */
> +               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
> +               /* When off, switch RX to be an interrupt */
> +               pinctrl-names = "default", "off";
> +               pinctrl-0 = <&uart2_pins>;
> +               pinctrl-1 = <&uart2_pins_rx_gpio>;
> +       };
> +};

If the wi2wi driver is a regulator driver one would write

/ {
       gps-regulator: gps {
               compatible = "wi2iw,w2sg0004";
               vdd-supply = <&vsim>;
               gpios = <&gpio5 17 0>; /* GPIO_145 */
               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
               /* When off, switch RX to be an interrupt */
               pinctrl-names = "default", "off";
               pinctrl-0 = <&uart2_pins>;
               pinctrl-1 = <&uart2_pins_rx_gpio>;
       };
}

&uart2 {
	vdd-suppy = <&gps-regulator>;
};

Which IMHO better describes that the uart controls power of a separate driver.

And this pattern for writing a DT would IMHO be more flexible because you
can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.


> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 389ca1347a77..81d259303710 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -189,6 +189,7 @@ variscite	Variscite Ltd.
> via	VIA Technologies, Inc.
> virtio	Virtual I/O Device Specification, developed by the OASIS consortium
> voipac	Voipac Technologies s.r.o.
> +wi2wi	wi2wi Inc.  http://www.wi2wi.com/
> winbond Winbond Electronics corp.
> wlf	Wolfson Microelectronics
> wm	Wondermedia Technologies, Inc.
> diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
> index 3976760c2e28..05c5d966ae57 100644
> --- a/drivers/tty/slave/Kconfig
> +++ b/drivers/tty/slave/Kconfig
> @@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
> 	  Devices which attach via a uart, but need extra
> 	  driver support for power management etc.
> 
> +if TTY_SLAVE
> +
> +config SERIAL_POWER_MANAGER
> +	tristate "Power Management controller for serial-attached devices"
> +	default n
> +	help
> +	  Some devices permanently attached via a UART can benefit from
> +	  being power-managed when the tty device is opened or closed.
> +	  This driver can support several such devices with simple
> +	  power requirements such as enabling a regulator.
> +
> +	  If in doubt, say 'N'
> +
> +endif
> diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
> index 65669acb392e..a2f7d2847319 100644
> --- a/drivers/tty/slave/Makefile
> +++ b/drivers/tty/slave/Makefile
> @@ -1,2 +1,4 @@
> 
> obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
> +
> +obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
> diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
> new file mode 100644
> index 000000000000..662a526d8630
> --- /dev/null
> +++ b/drivers/tty/slave/serial-power-manager.c
> @@ -0,0 +1,510 @@
> +/*
> + * Serial-power-manager
> + * tty-slave device that intercepts open/close events on the tty,
> + * and turns power on/off for the device which is connected.
> + *
> + * Currently supported devices:
> + *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
> + *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
> + *
> + * When appropriate, an RFKILL will be registered which
> + * can power-down the device even when it is open.
> + *
> + * Device can be turned on either by
> + *  - enabling a regulator.  Disable to turn off
> + *  - toggling a GPIO.  Toggle again to turn off.  This requires
> + *     that we know the current state.  It is assumed to be 'off'
> + *     at boot, however if an interrupt can be generated when on,
> + *     such as by connecting RX to a GPIO, that can be used to detect
> + *     if the device is on when it should be off.

Why does this driver mix both things? 

The only thing they have in common is that both are uart slaves
and that they have a serial interface. But power control is very
different.

One driver per fundamentally different chip...

> + */
> +
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/tty.h>
> +#include <linux/gpio.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/rfkill.h>
> +
> +#include <linux/tty_slave.h>
> +
> +/* This is used for testing. Setting this module parameter
> + * will simulate booting with the device "on"
> + */
> +static bool toggle_on_probe = false;
> +module_param(toggle_on_probe, bool, 0);
> +MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
> +
> +struct spm_config {
> +	int	rfkill_type;		/* type of rfkill to register */
> +	int	toggle_time;		/* msec to pulse GPIO for on/off */
> +	int	toggle_gap;		/* min msecs between toggles */
> +	bool	off_in_suspend;
> +}
> +	simple_config = {
> +		.off_in_suspend = true,
> +	},
> +	w2sg_config = {
> +		.rfkill_type = RFKILL_TYPE_GPS,

The driver pretends to be generic by its name but incorporates a lot of specific
knowledge about the w2sg chip, e.g. that it is a GPS chip.

> +		.toggle_time = 10,
> +		.toggle_gap = 500,
> +		.off_in_suspend = true,
> +	};
> +
> +const static struct of_device_id spm_dt_ids[] = {
> +       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
> +       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},

Well, how large will this table become if other uart slave device types
are added?

> +       {}
> +};
> +
> +struct spm_data {
> +	const struct spm_config *config;
> +	struct gpio_desc *gpiod;
> +	int		irq;	/* irq line from RX pin when pinctrl
> +				 * set to 'idle' */
> +	struct regulator *reg;
> +
> +	unsigned long	toggle_time;
> +	unsigned long	toggle_gap;
> +	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
> +	unsigned long	backoff;	/* jiffies since last_toggle when
> +					 * we try again
> +					 */
> +	enum {Idle, Down, Up} state;	/* state-machine state. */
> +
> +	int		open_cnt;
> +	bool		requested, is_on;
> +	bool		suspended;
> +	bool		reg_enabled;
> +
> +	struct pinctrl	*pins;
> +	struct pinctrl_state *pins_off;
> +
> +	struct delayed_work work;
> +	spinlock_t	lock;
> +	struct device	*dev;
> +
> +	struct rfkill	*rfkill;
> +
> +	int (*old_open)(struct tty_struct * tty, struct file * filp);
> +	void (*old_close)(struct tty_struct * tty, struct file * filp);
> +
> +};
> +
> +/* When a device is powered on/off by toggling a GPIO we perform
> + * all the toggling via a workqueue to ensure only one toggle happens
> + * at a time and to allow easy timing.
> + * This is managed as a state machine which transitions
> + *  Idle -> Down -> Up -> Idle
> + * The GPIO is held down for toggle_time and then up for toggle_time,
> + * and then we assume the device has changed state.
> + * We never toggle until at least toggle_gap has passed since the
> + * last toggle.
> + */
> +static void toggle_work(struct work_struct *work)
> +{
> +	struct spm_data *data = container_of(
> +		work, struct spm_data, work.work);
> +
> +	if (data->gpiod == NULL)
> +		return;
> +
> +	spin_lock_irq(&data->lock);
> +	switch (data->state) {
> +	case Up:
> +		data->state = Idle;
> +		if (data->requested == data->is_on)
> +			break;
> +		if (!data->requested)
> +			/* Assume it is off unless activity is detected */
> +			break;
> +		/* Try again in a while unless we get some activity */
> +		dev_dbg(data->dev, "Wait %dusec until retry\n",
> +			jiffies_to_msecs(data->backoff));
> +		schedule_delayed_work(&data->work, data->backoff);
> +		break;
> +	case Idle:
> +		if (data->requested == data->is_on)
> +			break;
> +
> +		/* Time to toggle */
> +		dev_dbg(data->dev, "Starting toggle to turn %s\n",
> +			data->requested ? "on" : "off");
> +		data->state = Down;
> +		spin_unlock_irq(&data->lock);
> +		gpiod_set_value_cansleep(data->gpiod, 1);
> +		schedule_delayed_work(&data->work, data->toggle_time);
> +
> +		return;
> +
> +	case Down:
> +		data->state = Up;
> +		data->last_toggle = jiffies;
> +		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
> +			data->is_on ? "off" : "on");
> +		data->is_on = ! data->is_on;
> +		spin_unlock_irq(&data->lock);
> +
> +		gpiod_set_value_cansleep(data->gpiod, 0);
> +		schedule_delayed_work(&data->work, data->toggle_time);
> +
> +		return;
> +	}
> +	spin_unlock_irq(&data->lock);
> +}
> +
> +static irqreturn_t spm_isr(int irq, void *dev_id)
> +{
> +	struct spm_data *data = dev_id;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&data->lock, flags);
> +	if (!data->requested && !data->is_on && data->state == Idle &&
> +	    time_after(jiffies, data->last_toggle + data->backoff)) {
> +		data->is_on = 1;
> +		data->backoff *= 2;
> +		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
> +		if (!data->suspended)
> +			schedule_delayed_work(&data->work, 0);
> +	}
> +	spin_unlock_irqrestore(&data->lock, flags);
> +	return IRQ_HANDLED;
> +}
> +
> +static void spm_on(struct spm_data *data)
> +{
> +	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
> +		unsigned long flags;
> +
> +		if (!data->reg_enabled &&
> +		    data->reg &&
> +		    regulator_enable(data->reg) == 0)
> +			data->reg_enabled = true;
> +
> +		spin_lock_irqsave(&data->lock, flags);
> +		if (!data->requested) {
> +			dev_dbg(data->dev, "TTY open - turn device on\n");
> +			data->requested = true;
> +			data->backoff = data->toggle_gap;
> +			if (data->irq > 0) {
> +				disable_irq(data->irq);
> +				pinctrl_pm_select_default_state(data->dev);
> +			}
> +			if (!data->suspended && data->state == Idle)
> +				schedule_delayed_work(&data->work, 0);
> +		}
> +		spin_unlock_irqrestore(&data->lock, flags);
> +	}
> +}
> +
> +static int spm_open(struct tty_struct *tty, struct file *filp)
> +{
> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> +
> +	data->open_cnt++;
> +	spm_on(data);
> +	if (data->old_open)
> +		return data->old_open(tty, filp);
> +}
> +
> +static void spm_off(struct spm_data *data)
> +{
> +	unsigned long flags;
> +
> +	if (data->reg && data->reg_enabled)
> +		if (regulator_disable(data->reg) == 0)
> +			data->reg_enabled = false;
> +
> +	spin_lock_irqsave(&data->lock, flags);
> +	if (data->requested) {
> +		data->requested = false;
> +		data->backoff = data->toggle_gap;
> +		if (data->pins_off) {
> +			pinctrl_select_state(data->pins,
> +					     data->pins_off);
> +			enable_irq(data->irq);
> +		}
> +		if (!data->suspended && data->state == Idle)
> +			schedule_delayed_work(&data->work, 0);
> +	}
> +	spin_unlock_irqrestore(&data->lock, flags);
> +}
> +
> +static void spm_close(struct tty_struct *tty, struct file *filp)
> +{
> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> +
> +	data->open_cnt--;
> +	if (!data->open_cnt) {
> +		dev_dbg(data->dev, "TTY closed - turn device off\n");
> +		spm_off(data);
> +	}
> +
> +	if (data->old_close)
> +		data->old_close(tty, filp);
> +}
> +
> +static int spm_rfkill_set_block(void *vdata, bool blocked)
> +{
> +	struct spm_data *data = vdata;
> +
> +	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
> +	if (blocked)
> +		spm_off(data);
> +
> +	if (!blocked &&
> +	    data->open_cnt)
> +		spm_on(data);
> +
> +	return 0;
> +}
> +
> +static struct rfkill_ops spm_rfkill_ops = {
> +	.set_block = spm_rfkill_set_block,
> +};
> +
> +static int spm_suspend(struct device *dev)
> +{
> +	/* Ignore incoming data and just turn device off.
> +	 * we cannot really wait for a separate thread to
> +	 * do things, so we disable that and do it all
> +	 * here
> +	 */
> +	struct spm_data *data = dev_get_drvdata(dev);
> +
> +	spin_lock_irq(&data->lock);
> +	data->suspended = true;
> +	spin_unlock_irq(&data->lock);
> +	if (!data->config->off_in_suspend)
> +		return 0;
> +
> +	if (data->gpiod) {
> +
> +		cancel_delayed_work_sync(&data->work);
> +		if (data->state == Down) {
> +			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
> +			msleep(data->config->toggle_time);
> +			gpiod_set_value_cansleep(data->gpiod, 0);
> +			data->last_toggle = jiffies;
> +			data->is_on = !data->is_on;
> +			data->state = Up;
> +		}
> +		if (data->state == Up) {
> +			msleep(data->config->toggle_time);
> +			data->state = Idle;
> +		}
> +		if (data->is_on) {
> +			dev_dbg(data->dev, "Suspending while device on: toggling\n");
> +			gpiod_set_value_cansleep(data->gpiod, 1);
> +			msleep(data->config->toggle_time);
> +			gpiod_set_value_cansleep(data->gpiod, 0);
> +			data->is_on = 0;
> +		}
> +	}
> +
> +	if (data->reg && data->reg_enabled)
> +		if (regulator_disable(data->reg) == 0)
> +			data->reg_enabled = false;
> +
> +	return 0;
> +}
> +
> +static int spm_resume(struct device *dev)
> +{
> +	struct spm_data *data = dev_get_drvdata(dev);
> +
> +	spin_lock_irq(&data->lock);
> +	data->suspended = false;
> +	spin_unlock_irq(&data->lock);
> +	schedule_delayed_work(&data->work, 0);
> +
> +	if (data->open_cnt &&
> +	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
> +		if (!data->reg_enabled &&
> +		    data->reg &&
> +		    regulator_enable(data->reg) == 0)
> +			data->reg_enabled = true;
> +	}
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops spm_pm_ops = {
> +	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
> +};
> +
> +static int spm_probe(struct device *dev)
> +{
> +	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
> +	struct spm_data *data;
> +	struct regulator *reg;
> +	int err;
> +	const struct of_device_id *id;
> +	const char *name;
> +
> +	if (dev->parent == NULL)
> +		return -ENODEV;
> +
> +	id = of_match_device(spm_dt_ids, dev);
> +	if (!id)
> +		return -ENODEV;
> +
> +	if (dev->of_node && dev->of_node->name)
> +		name = dev->of_node->name;
> +	else
> +		name = "serial-power-manager";
> +
> +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->config = id->data;
> +	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
> +	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
> +	data->last_toggle = jiffies;
> +	data->backoff = data->toggle_gap;
> +	data->state = Idle;
> +	spin_lock_init(&data->lock);
> +	INIT_DELAYED_WORK(&data->work, toggle_work);
> +
> +	/* If a regulator is provided, it is enabled on 'open'
> +	 * and disabled on 'release'
> +	 */
> +	reg = devm_regulator_get(dev, "vdd");
> +	if (IS_ERR(reg)) {
> +		err = PTR_ERR(reg);
> +		if (err != -ENODEV)
> +			goto out;
> +	} else
> +		data->reg = reg;
> +
> +	/* If an irq is provided, any transitions are taken as
> +	 * indication that the device is currently "on"
> +	 */
> +	data->irq = of_irq_get(dev->of_node, 0);
> +	if (data->irq < 0) {
> +		err = data->irq;
> +		if (err != -EINVAL)
> +			goto out;
> +	} else {
> +		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
> +
> +		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
> +		err = devm_request_irq(dev, data->irq, spm_isr,
> +				       IRQF_TRIGGER_FALLING,
> +				       name, data);
> +
> +		if (err)
> +			goto out;
> +
> +	}

Up to here it is generic and makes no assumptions about a specific
device.

> +
> +	/* If a gpio is provided, then it is used to turn the device
> +	 * on/off.

You have a compatible record (for two well defined chips), but you
do control which functions are really used by providing/not providing
some DT parameters.

Either one is redundant.

> +	 * If toggle_time is zero, then the GPIO directly controls
> +	 * the device.

Very hidden and non-obvoius functionality.

>  If non-zero, then the GPIO must be toggled to
> +	 * change the state of the device.

All the following is very special logic for the w2sg0004 chip which should be
divided out into a separate driver.

Marek and me already had proposed such a chip specific driver (to be located
in drivers/misc) some months ago. It would encapsulate everything w2sg0004
specific and present itself as a regulator (because that is its main purpose:
control the LDO regulator inside the w2sg0004 chip).

We can resubmit it as soon as this driver stabilizes and finds acceptance.

> +	 */
> +	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
> +	if (IS_ERR(data->gpiod)) {
> +		err = PTR_ERR(data->gpiod);
> +		if (err != -ENOENT)
> +			goto out;
> +		data->gpiod = NULL;
> +	} else
> +		dev_dbg(dev, "GPIO configured: %d\n",
> +			desc_to_gpio(data->gpiod));
> +
> +	/* If an 'off' pinctrl state is defined, we apply that
> +	 * when the device is assumed to be off.  This is expected to
> +	 * route the 'rx' line to the 'irq' interrupt.
> +	 */
> +	data->pins = devm_pinctrl_get(dev);
> +	if (data->pins && data->irq > 0) {
> +		data->pins_off = pinctrl_lookup_state(data->pins, "off");
> +		if (IS_ERR(data->pins_off))
> +			data->pins_off = NULL;
> +	}
> +
> +	if (data->config->rfkill_type) {
> +		data->rfkill = rfkill_alloc(name, dev,
> +					    data->config->rfkill_type,
> +					    &spm_rfkill_ops, data);
> +		if (!data->rfkill) {
> +			err = -ENOMEM;
> +			goto out;
> +		}
> +		err = rfkill_register(data->rfkill);
> +		if (err) {
> +			dev_err(dev, "Cannot register rfkill device");
> +			rfkill_destroy(data->rfkill);
> +			goto out;
> +		}
> +	}
> +	dev_set_drvdata(dev, data);
> +	data->dev = dev;
> +	data->old_open = slave->ops.open;
> +	data->old_close = slave->ops.close;
> +	slave->ops.open = spm_open;
> +	slave->ops.close = spm_close;
> +	tty_slave_finalize(slave);
> +
> +	if (data->pins_off)
> +		pinctrl_select_state(data->pins, data->pins_off);
> +	if (data->irq > 0)
> +		enable_irq(data->irq);
> +
> +	if (toggle_on_probe && data->gpiod) {
> +		dev_dbg(data->dev, "Performing initial toggle\n");
> +		gpiod_set_value_cansleep(data->gpiod, 1);
> +		msleep(data->config->toggle_time);
> +		gpiod_set_value_cansleep(data->gpiod, 0);
> +		msleep(data->config->toggle_time);
> +	}
> +	err = 0;
> +out:
> +	dev_dbg(data->dev, "Probed: err=%d\n", err);
> +	return err;
> +}
> +
> +static int spm_remove(struct device *dev)
> +{
> +       struct spm_data *data = dev_get_drvdata(dev);
> +
> +       if (data->rfkill) {
> +               rfkill_unregister(data->rfkill);
> +               rfkill_destroy(data->rfkill);
> +       }
> +       return 0;
> +}
> +
> +static struct device_driver spm_driver = {
> +	.name		= "serial-power-manager",
> +	.owner		= THIS_MODULE,
> +	.of_match_table	= spm_dt_ids,
> +	.probe		= spm_probe,
> +	.remove		= spm_remove,
> +};
> +
> +static int __init spm_init(void)
> +{
> +       return tty_slave_driver_register(&spm_driver);
> +}
> +module_init(spm_init);
> +
> +static void __exit spm_exit(void)
> +{
> +	driver_unregister(&spm_driver);
> +}
> +module_exit(spm_exit);
> +
> +MODULE_AUTHOR("NeilBrown <neil@brown.name>");
> +MODULE_DEVICE_TABLE(of, spm_dt_ids);
> +MODULE_DESCRIPTION("Power management for Serial-attached device.");
> +MODULE_LICENSE("GPL v2");
> 
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 18.03.2015 um 06:58 schrieb NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>:

> If a platform has a particular device permanently attached to a UART,
> there may be out-of-band signaling necessary to power the device
> on and off.
> 
> This driver controls that signalling for a number of different devices.
> It can
> - enable/disable a regulator
> - toggle a GPIO
> - register an 'rfkill' which can force the device to be off.
> 
> When the rfkill is absent or unblocked, the device will be on when the
> associated tty device is open, and closed otherwise.
> 
> Signed-off-by: NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>
> ---
> .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
> .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
> .../devicetree/bindings/vendor-prefixes.txt        |    1 
> drivers/tty/slave/Kconfig                          |   14 +
> drivers/tty/slave/Makefile                         |    2 
> drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
> 6 files changed, 583 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> create mode 100644 drivers/tty/slave/serial-power-manager.c
> 
> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> new file mode 100644
> index 000000000000..cfe6ee5e01e9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> @@ -0,0 +1,19 @@
> +wi2wi bluetooth module
> +
> +This is accessed via a serial port and is largely controlled via that
> +link.  Extra configuration is needed to enable power on/off
> +
> +Required properties:
> +- compatible: "wi2wi,w2cbw003"
> +- vdd-supply: regulator used to power the device.
> +
> +The node for this device must be the child of a UART.
> +
> +Example:
> +
> +&uart1 {
> +       bluetooth {
> +               compatible = "wi2wi,w2cbw003";
> +               vdd-supply = <&vaux4>;
> +       };
> +};

Wouldn’t it be easier to simply write

&uart1 {
	vdd-suppy = <&vaux4>;
}

> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> new file mode 100644
> index 000000000000..fdc52cf56533
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> @@ -0,0 +1,37 @@
> +wi2wi GPS device
> +
> +This is accessed via a serial port and is largely controlled via that
> +link.  Extra configuration is needed to enable power on/off
> +
> +Required properties:
> +- compatible: "wi2wi,w2sg0004"
> +- gpios: gpios used to toggle 'on/off' pin
> +- interrupts: interrupt generated by RX pin when device
> +      should be off
> +
> +Optional properties:
> +- vdd-supply: regulator used to power antenna
> +- pinctrl: "default", "off"
> +      if "off" setting is provided it is imposed when device should
> +      be off.  This can route the RX pin to a GPIO interrupt.
> +
> +The w2sg0004 uses a pin-toggle both to power-on and to
> +power-off, so the driver needs to detect what state it is in.
> +It does this by detecting characters on the RX line.
> +When it should be off, these can optionally be detected by a GPIO.
> +
> +The node for this device must be the child of a UART.
> +
> +Example:
> +&uart2 {
> +       gps {
> +               compatible = "wi2iw,w2sg0004";
> +               vdd-supply = <&vsim>;
> +               gpios = <&gpio5 17 0>; /* GPIO_145 */
> +               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
> +               /* When off, switch RX to be an interrupt */
> +               pinctrl-names = "default", "off";
> +               pinctrl-0 = <&uart2_pins>;
> +               pinctrl-1 = <&uart2_pins_rx_gpio>;
> +       };
> +};

If the wi2wi driver is a regulator driver one would write

/ {
       gps-regulator: gps {
               compatible = "wi2iw,w2sg0004";
               vdd-supply = <&vsim>;
               gpios = <&gpio5 17 0>; /* GPIO_145 */
               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
               /* When off, switch RX to be an interrupt */
               pinctrl-names = "default", "off";
               pinctrl-0 = <&uart2_pins>;
               pinctrl-1 = <&uart2_pins_rx_gpio>;
       };
}

&uart2 {
	vdd-suppy = <&gps-regulator>;
};

Which IMHO better describes that the uart controls power of a separate driver.

And this pattern for writing a DT would IMHO be more flexible because you
can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.


> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 389ca1347a77..81d259303710 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -189,6 +189,7 @@ variscite	Variscite Ltd.
> via	VIA Technologies, Inc.
> virtio	Virtual I/O Device Specification, developed by the OASIS consortium
> voipac	Voipac Technologies s.r.o.
> +wi2wi	wi2wi Inc.  http://www.wi2wi.com/
> winbond Winbond Electronics corp.
> wlf	Wolfson Microelectronics
> wm	Wondermedia Technologies, Inc.
> diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
> index 3976760c2e28..05c5d966ae57 100644
> --- a/drivers/tty/slave/Kconfig
> +++ b/drivers/tty/slave/Kconfig
> @@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
> 	  Devices which attach via a uart, but need extra
> 	  driver support for power management etc.
> 
> +if TTY_SLAVE
> +
> +config SERIAL_POWER_MANAGER
> +	tristate "Power Management controller for serial-attached devices"
> +	default n
> +	help
> +	  Some devices permanently attached via a UART can benefit from
> +	  being power-managed when the tty device is opened or closed.
> +	  This driver can support several such devices with simple
> +	  power requirements such as enabling a regulator.
> +
> +	  If in doubt, say 'N'
> +
> +endif
> diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
> index 65669acb392e..a2f7d2847319 100644
> --- a/drivers/tty/slave/Makefile
> +++ b/drivers/tty/slave/Makefile
> @@ -1,2 +1,4 @@
> 
> obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
> +
> +obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
> diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
> new file mode 100644
> index 000000000000..662a526d8630
> --- /dev/null
> +++ b/drivers/tty/slave/serial-power-manager.c
> @@ -0,0 +1,510 @@
> +/*
> + * Serial-power-manager
> + * tty-slave device that intercepts open/close events on the tty,
> + * and turns power on/off for the device which is connected.
> + *
> + * Currently supported devices:
> + *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
> + *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
> + *
> + * When appropriate, an RFKILL will be registered which
> + * can power-down the device even when it is open.
> + *
> + * Device can be turned on either by
> + *  - enabling a regulator.  Disable to turn off
> + *  - toggling a GPIO.  Toggle again to turn off.  This requires
> + *     that we know the current state.  It is assumed to be 'off'
> + *     at boot, however if an interrupt can be generated when on,
> + *     such as by connecting RX to a GPIO, that can be used to detect
> + *     if the device is on when it should be off.

Why does this driver mix both things? 

The only thing they have in common is that both are uart slaves
and that they have a serial interface. But power control is very
different.

One driver per fundamentally different chip...

> + */
> +
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/err.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/tty.h>
> +#include <linux/gpio.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_irq.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <linux/rfkill.h>
> +
> +#include <linux/tty_slave.h>
> +
> +/* This is used for testing. Setting this module parameter
> + * will simulate booting with the device "on"
> + */
> +static bool toggle_on_probe = false;
> +module_param(toggle_on_probe, bool, 0);
> +MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
> +
> +struct spm_config {
> +	int	rfkill_type;		/* type of rfkill to register */
> +	int	toggle_time;		/* msec to pulse GPIO for on/off */
> +	int	toggle_gap;		/* min msecs between toggles */
> +	bool	off_in_suspend;
> +}
> +	simple_config = {
> +		.off_in_suspend = true,
> +	},
> +	w2sg_config = {
> +		.rfkill_type = RFKILL_TYPE_GPS,

The driver pretends to be generic by its name but incorporates a lot of specific
knowledge about the w2sg chip, e.g. that it is a GPS chip.

> +		.toggle_time = 10,
> +		.toggle_gap = 500,
> +		.off_in_suspend = true,
> +	};
> +
> +const static struct of_device_id spm_dt_ids[] = {
> +       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
> +       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},

Well, how large will this table become if other uart slave device types
are added?

> +       {}
> +};
> +
> +struct spm_data {
> +	const struct spm_config *config;
> +	struct gpio_desc *gpiod;
> +	int		irq;	/* irq line from RX pin when pinctrl
> +				 * set to 'idle' */
> +	struct regulator *reg;
> +
> +	unsigned long	toggle_time;
> +	unsigned long	toggle_gap;
> +	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
> +	unsigned long	backoff;	/* jiffies since last_toggle when
> +					 * we try again
> +					 */
> +	enum {Idle, Down, Up} state;	/* state-machine state. */
> +
> +	int		open_cnt;
> +	bool		requested, is_on;
> +	bool		suspended;
> +	bool		reg_enabled;
> +
> +	struct pinctrl	*pins;
> +	struct pinctrl_state *pins_off;
> +
> +	struct delayed_work work;
> +	spinlock_t	lock;
> +	struct device	*dev;
> +
> +	struct rfkill	*rfkill;
> +
> +	int (*old_open)(struct tty_struct * tty, struct file * filp);
> +	void (*old_close)(struct tty_struct * tty, struct file * filp);
> +
> +};
> +
> +/* When a device is powered on/off by toggling a GPIO we perform
> + * all the toggling via a workqueue to ensure only one toggle happens
> + * at a time and to allow easy timing.
> + * This is managed as a state machine which transitions
> + *  Idle -> Down -> Up -> Idle
> + * The GPIO is held down for toggle_time and then up for toggle_time,
> + * and then we assume the device has changed state.
> + * We never toggle until at least toggle_gap has passed since the
> + * last toggle.
> + */
> +static void toggle_work(struct work_struct *work)
> +{
> +	struct spm_data *data = container_of(
> +		work, struct spm_data, work.work);
> +
> +	if (data->gpiod == NULL)
> +		return;
> +
> +	spin_lock_irq(&data->lock);
> +	switch (data->state) {
> +	case Up:
> +		data->state = Idle;
> +		if (data->requested == data->is_on)
> +			break;
> +		if (!data->requested)
> +			/* Assume it is off unless activity is detected */
> +			break;
> +		/* Try again in a while unless we get some activity */
> +		dev_dbg(data->dev, "Wait %dusec until retry\n",
> +			jiffies_to_msecs(data->backoff));
> +		schedule_delayed_work(&data->work, data->backoff);
> +		break;
> +	case Idle:
> +		if (data->requested == data->is_on)
> +			break;
> +
> +		/* Time to toggle */
> +		dev_dbg(data->dev, "Starting toggle to turn %s\n",
> +			data->requested ? "on" : "off");
> +		data->state = Down;
> +		spin_unlock_irq(&data->lock);
> +		gpiod_set_value_cansleep(data->gpiod, 1);
> +		schedule_delayed_work(&data->work, data->toggle_time);
> +
> +		return;
> +
> +	case Down:
> +		data->state = Up;
> +		data->last_toggle = jiffies;
> +		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
> +			data->is_on ? "off" : "on");
> +		data->is_on = ! data->is_on;
> +		spin_unlock_irq(&data->lock);
> +
> +		gpiod_set_value_cansleep(data->gpiod, 0);
> +		schedule_delayed_work(&data->work, data->toggle_time);
> +
> +		return;
> +	}
> +	spin_unlock_irq(&data->lock);
> +}
> +
> +static irqreturn_t spm_isr(int irq, void *dev_id)
> +{
> +	struct spm_data *data = dev_id;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&data->lock, flags);
> +	if (!data->requested && !data->is_on && data->state == Idle &&
> +	    time_after(jiffies, data->last_toggle + data->backoff)) {
> +		data->is_on = 1;
> +		data->backoff *= 2;
> +		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
> +		if (!data->suspended)
> +			schedule_delayed_work(&data->work, 0);
> +	}
> +	spin_unlock_irqrestore(&data->lock, flags);
> +	return IRQ_HANDLED;
> +}
> +
> +static void spm_on(struct spm_data *data)
> +{
> +	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
> +		unsigned long flags;
> +
> +		if (!data->reg_enabled &&
> +		    data->reg &&
> +		    regulator_enable(data->reg) == 0)
> +			data->reg_enabled = true;
> +
> +		spin_lock_irqsave(&data->lock, flags);
> +		if (!data->requested) {
> +			dev_dbg(data->dev, "TTY open - turn device on\n");
> +			data->requested = true;
> +			data->backoff = data->toggle_gap;
> +			if (data->irq > 0) {
> +				disable_irq(data->irq);
> +				pinctrl_pm_select_default_state(data->dev);
> +			}
> +			if (!data->suspended && data->state == Idle)
> +				schedule_delayed_work(&data->work, 0);
> +		}
> +		spin_unlock_irqrestore(&data->lock, flags);
> +	}
> +}
> +
> +static int spm_open(struct tty_struct *tty, struct file *filp)
> +{
> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> +
> +	data->open_cnt++;
> +	spm_on(data);
> +	if (data->old_open)
> +		return data->old_open(tty, filp);
> +}
> +
> +static void spm_off(struct spm_data *data)
> +{
> +	unsigned long flags;
> +
> +	if (data->reg && data->reg_enabled)
> +		if (regulator_disable(data->reg) == 0)
> +			data->reg_enabled = false;
> +
> +	spin_lock_irqsave(&data->lock, flags);
> +	if (data->requested) {
> +		data->requested = false;
> +		data->backoff = data->toggle_gap;
> +		if (data->pins_off) {
> +			pinctrl_select_state(data->pins,
> +					     data->pins_off);
> +			enable_irq(data->irq);
> +		}
> +		if (!data->suspended && data->state == Idle)
> +			schedule_delayed_work(&data->work, 0);
> +	}
> +	spin_unlock_irqrestore(&data->lock, flags);
> +}
> +
> +static void spm_close(struct tty_struct *tty, struct file *filp)
> +{
> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> +
> +	data->open_cnt--;
> +	if (!data->open_cnt) {
> +		dev_dbg(data->dev, "TTY closed - turn device off\n");
> +		spm_off(data);
> +	}
> +
> +	if (data->old_close)
> +		data->old_close(tty, filp);
> +}
> +
> +static int spm_rfkill_set_block(void *vdata, bool blocked)
> +{
> +	struct spm_data *data = vdata;
> +
> +	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
> +	if (blocked)
> +		spm_off(data);
> +
> +	if (!blocked &&
> +	    data->open_cnt)
> +		spm_on(data);
> +
> +	return 0;
> +}
> +
> +static struct rfkill_ops spm_rfkill_ops = {
> +	.set_block = spm_rfkill_set_block,
> +};
> +
> +static int spm_suspend(struct device *dev)
> +{
> +	/* Ignore incoming data and just turn device off.
> +	 * we cannot really wait for a separate thread to
> +	 * do things, so we disable that and do it all
> +	 * here
> +	 */
> +	struct spm_data *data = dev_get_drvdata(dev);
> +
> +	spin_lock_irq(&data->lock);
> +	data->suspended = true;
> +	spin_unlock_irq(&data->lock);
> +	if (!data->config->off_in_suspend)
> +		return 0;
> +
> +	if (data->gpiod) {
> +
> +		cancel_delayed_work_sync(&data->work);
> +		if (data->state == Down) {
> +			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
> +			msleep(data->config->toggle_time);
> +			gpiod_set_value_cansleep(data->gpiod, 0);
> +			data->last_toggle = jiffies;
> +			data->is_on = !data->is_on;
> +			data->state = Up;
> +		}
> +		if (data->state == Up) {
> +			msleep(data->config->toggle_time);
> +			data->state = Idle;
> +		}
> +		if (data->is_on) {
> +			dev_dbg(data->dev, "Suspending while device on: toggling\n");
> +			gpiod_set_value_cansleep(data->gpiod, 1);
> +			msleep(data->config->toggle_time);
> +			gpiod_set_value_cansleep(data->gpiod, 0);
> +			data->is_on = 0;
> +		}
> +	}
> +
> +	if (data->reg && data->reg_enabled)
> +		if (regulator_disable(data->reg) == 0)
> +			data->reg_enabled = false;
> +
> +	return 0;
> +}
> +
> +static int spm_resume(struct device *dev)
> +{
> +	struct spm_data *data = dev_get_drvdata(dev);
> +
> +	spin_lock_irq(&data->lock);
> +	data->suspended = false;
> +	spin_unlock_irq(&data->lock);
> +	schedule_delayed_work(&data->work, 0);
> +
> +	if (data->open_cnt &&
> +	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
> +		if (!data->reg_enabled &&
> +		    data->reg &&
> +		    regulator_enable(data->reg) == 0)
> +			data->reg_enabled = true;
> +	}
> +	return 0;
> +}
> +
> +static const struct dev_pm_ops spm_pm_ops = {
> +	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
> +};
> +
> +static int spm_probe(struct device *dev)
> +{
> +	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
> +	struct spm_data *data;
> +	struct regulator *reg;
> +	int err;
> +	const struct of_device_id *id;
> +	const char *name;
> +
> +	if (dev->parent == NULL)
> +		return -ENODEV;
> +
> +	id = of_match_device(spm_dt_ids, dev);
> +	if (!id)
> +		return -ENODEV;
> +
> +	if (dev->of_node && dev->of_node->name)
> +		name = dev->of_node->name;
> +	else
> +		name = "serial-power-manager";
> +
> +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->config = id->data;
> +	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
> +	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
> +	data->last_toggle = jiffies;
> +	data->backoff = data->toggle_gap;
> +	data->state = Idle;
> +	spin_lock_init(&data->lock);
> +	INIT_DELAYED_WORK(&data->work, toggle_work);
> +
> +	/* If a regulator is provided, it is enabled on 'open'
> +	 * and disabled on 'release'
> +	 */
> +	reg = devm_regulator_get(dev, "vdd");
> +	if (IS_ERR(reg)) {
> +		err = PTR_ERR(reg);
> +		if (err != -ENODEV)
> +			goto out;
> +	} else
> +		data->reg = reg;
> +
> +	/* If an irq is provided, any transitions are taken as
> +	 * indication that the device is currently "on"
> +	 */
> +	data->irq = of_irq_get(dev->of_node, 0);
> +	if (data->irq < 0) {
> +		err = data->irq;
> +		if (err != -EINVAL)
> +			goto out;
> +	} else {
> +		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
> +
> +		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
> +		err = devm_request_irq(dev, data->irq, spm_isr,
> +				       IRQF_TRIGGER_FALLING,
> +				       name, data);
> +
> +		if (err)
> +			goto out;
> +
> +	}

Up to here it is generic and makes no assumptions about a specific
device.

> +
> +	/* If a gpio is provided, then it is used to turn the device
> +	 * on/off.

You have a compatible record (for two well defined chips), but you
do control which functions are really used by providing/not providing
some DT parameters.

Either one is redundant.

> +	 * If toggle_time is zero, then the GPIO directly controls
> +	 * the device.

Very hidden and non-obvoius functionality.

>  If non-zero, then the GPIO must be toggled to
> +	 * change the state of the device.

All the following is very special logic for the w2sg0004 chip which should be
divided out into a separate driver.

Marek and me already had proposed such a chip specific driver (to be located
in drivers/misc) some months ago. It would encapsulate everything w2sg0004
specific and present itself as a regulator (because that is its main purpose:
control the LDO regulator inside the w2sg0004 chip).

We can resubmit it as soon as this driver stabilizes and finds acceptance.

> +	 */
> +	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
> +	if (IS_ERR(data->gpiod)) {
> +		err = PTR_ERR(data->gpiod);
> +		if (err != -ENOENT)
> +			goto out;
> +		data->gpiod = NULL;
> +	} else
> +		dev_dbg(dev, "GPIO configured: %d\n",
> +			desc_to_gpio(data->gpiod));
> +
> +	/* If an 'off' pinctrl state is defined, we apply that
> +	 * when the device is assumed to be off.  This is expected to
> +	 * route the 'rx' line to the 'irq' interrupt.
> +	 */
> +	data->pins = devm_pinctrl_get(dev);
> +	if (data->pins && data->irq > 0) {
> +		data->pins_off = pinctrl_lookup_state(data->pins, "off");
> +		if (IS_ERR(data->pins_off))
> +			data->pins_off = NULL;
> +	}
> +
> +	if (data->config->rfkill_type) {
> +		data->rfkill = rfkill_alloc(name, dev,
> +					    data->config->rfkill_type,
> +					    &spm_rfkill_ops, data);
> +		if (!data->rfkill) {
> +			err = -ENOMEM;
> +			goto out;
> +		}
> +		err = rfkill_register(data->rfkill);
> +		if (err) {
> +			dev_err(dev, "Cannot register rfkill device");
> +			rfkill_destroy(data->rfkill);
> +			goto out;
> +		}
> +	}
> +	dev_set_drvdata(dev, data);
> +	data->dev = dev;
> +	data->old_open = slave->ops.open;
> +	data->old_close = slave->ops.close;
> +	slave->ops.open = spm_open;
> +	slave->ops.close = spm_close;
> +	tty_slave_finalize(slave);
> +
> +	if (data->pins_off)
> +		pinctrl_select_state(data->pins, data->pins_off);
> +	if (data->irq > 0)
> +		enable_irq(data->irq);
> +
> +	if (toggle_on_probe && data->gpiod) {
> +		dev_dbg(data->dev, "Performing initial toggle\n");
> +		gpiod_set_value_cansleep(data->gpiod, 1);
> +		msleep(data->config->toggle_time);
> +		gpiod_set_value_cansleep(data->gpiod, 0);
> +		msleep(data->config->toggle_time);
> +	}
> +	err = 0;
> +out:
> +	dev_dbg(data->dev, "Probed: err=%d\n", err);
> +	return err;
> +}
> +
> +static int spm_remove(struct device *dev)
> +{
> +       struct spm_data *data = dev_get_drvdata(dev);
> +
> +       if (data->rfkill) {
> +               rfkill_unregister(data->rfkill);
> +               rfkill_destroy(data->rfkill);
> +       }
> +       return 0;
> +}
> +
> +static struct device_driver spm_driver = {
> +	.name		= "serial-power-manager",
> +	.owner		= THIS_MODULE,
> +	.of_match_table	= spm_dt_ids,
> +	.probe		= spm_probe,
> +	.remove		= spm_remove,
> +};
> +
> +static int __init spm_init(void)
> +{
> +       return tty_slave_driver_register(&spm_driver);
> +}
> +module_init(spm_init);
> +
> +static void __exit spm_exit(void)
> +{
> +	driver_unregister(&spm_driver);
> +}
> +module_exit(spm_exit);
> +
> +MODULE_AUTHOR("NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>");
> +MODULE_DEVICE_TABLE(of, spm_dt_ids);
> +MODULE_DESCRIPTION("Power management for Serial-attached device.");
> +MODULE_LICENSE("GPL v2");
> 
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 26600 bytes --]

On Fri, 20 Mar 2015 08:54:38 +0100 "Dr. H. Nikolaus Schaller"
<hns@goldelico.com> wrote:

> 
> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:
> 
> > If a platform has a particular device permanently attached to a UART,
> > there may be out-of-band signaling necessary to power the device
> > on and off.
> > 
> > This driver controls that signalling for a number of different devices.
> > It can
> > - enable/disable a regulator
> > - toggle a GPIO
> > - register an 'rfkill' which can force the device to be off.
> > 
> > When the rfkill is absent or unblocked, the device will be on when the
> > associated tty device is open, and closed otherwise.
> > 
> > Signed-off-by: NeilBrown <neil@brown.name>
> > ---
> > .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
> > .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
> > .../devicetree/bindings/vendor-prefixes.txt        |    1 
> > drivers/tty/slave/Kconfig                          |   14 +
> > drivers/tty/slave/Makefile                         |    2 
> > drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
> > 6 files changed, 583 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> > create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> > create mode 100644 drivers/tty/slave/serial-power-manager.c
> > 
> > diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> > new file mode 100644
> > index 000000000000..cfe6ee5e01e9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> > @@ -0,0 +1,19 @@
> > +wi2wi bluetooth module
> > +
> > +This is accessed via a serial port and is largely controlled via that
> > +link.  Extra configuration is needed to enable power on/off
> > +
> > +Required properties:
> > +- compatible: "wi2wi,w2cbw003"
> > +- vdd-supply: regulator used to power the device.
> > +
> > +The node for this device must be the child of a UART.
> > +
> > +Example:
> > +
> > +&uart1 {
> > +       bluetooth {
> > +               compatible = "wi2wi,w2cbw003";
> > +               vdd-supply = <&vaux4>;
> > +       };
> > +};
> 
> Wouldn’t it be easier to simply write
> 
> &uart1 {
> 	vdd-suppy = <&vaux4>;
> }

Easier to write: certainly.
Easier to justify? No.
Easier to get merged upstream?  Definitely not.
After all, the uart itself doesn't require a power supply.
It is the device connected to the uart which requires the power supply.


> 
> > diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> > new file mode 100644
> > index 000000000000..fdc52cf56533
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> > @@ -0,0 +1,37 @@
> > +wi2wi GPS device
> > +
> > +This is accessed via a serial port and is largely controlled via that
> > +link.  Extra configuration is needed to enable power on/off
> > +
> > +Required properties:
> > +- compatible: "wi2wi,w2sg0004"
> > +- gpios: gpios used to toggle 'on/off' pin
> > +- interrupts: interrupt generated by RX pin when device
> > +      should be off
> > +
> > +Optional properties:
> > +- vdd-supply: regulator used to power antenna
> > +- pinctrl: "default", "off"
> > +      if "off" setting is provided it is imposed when device should
> > +      be off.  This can route the RX pin to a GPIO interrupt.
> > +
> > +The w2sg0004 uses a pin-toggle both to power-on and to
> > +power-off, so the driver needs to detect what state it is in.
> > +It does this by detecting characters on the RX line.
> > +When it should be off, these can optionally be detected by a GPIO.
> > +
> > +The node for this device must be the child of a UART.
> > +
> > +Example:
> > +&uart2 {
> > +       gps {
> > +               compatible = "wi2iw,w2sg0004";
> > +               vdd-supply = <&vsim>;
> > +               gpios = <&gpio5 17 0>; /* GPIO_145 */
> > +               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
> > +               /* When off, switch RX to be an interrupt */
> > +               pinctrl-names = "default", "off";
> > +               pinctrl-0 = <&uart2_pins>;
> > +               pinctrl-1 = <&uart2_pins_rx_gpio>;
> > +       };
> > +};
> 
> If the wi2wi driver is a regulator driver one would write
> 
> / {
>        gps-regulator: gps {
>                compatible = "wi2iw,w2sg0004";
>                vdd-supply = <&vsim>;
>                gpios = <&gpio5 17 0>; /* GPIO_145 */
>                interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
>                /* When off, switch RX to be an interrupt */
>                pinctrl-names = "default", "off";
>                pinctrl-0 = <&uart2_pins>;
>                pinctrl-1 = <&uart2_pins_rx_gpio>;
>        };
> }
> 
> &uart2 {
> 	vdd-suppy = <&gps-regulator>;
> };
> 
> Which IMHO better describes that the uart controls power of a separate driver.

But the uart doesn't control the power.
An 'open' on the tty causes one driver to turn on a regulator, and another
driver to activate a uart so that the device represented by the tty can be
communicated with.

> 
> And this pattern for writing a DT would IMHO be more flexible because you
> can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.

I'm sure there are lots of ways we could find to make DT more flexible, only
then it wouldn't be DT any more - it would be something similar but different.

There needs to be one device-node for each device, and that device-node needs
to be a child of the device-node for the device which is the primary
connection to the child device.  That is how devicetree is structured - for
better or worse.



> 
> 
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 389ca1347a77..81d259303710 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -189,6 +189,7 @@ variscite	Variscite Ltd.
> > via	VIA Technologies, Inc.
> > virtio	Virtual I/O Device Specification, developed by the OASIS consortium
> > voipac	Voipac Technologies s.r.o.
> > +wi2wi	wi2wi Inc.  http://www.wi2wi.com/
> > winbond Winbond Electronics corp.
> > wlf	Wolfson Microelectronics
> > wm	Wondermedia Technologies, Inc.
> > diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
> > index 3976760c2e28..05c5d966ae57 100644
> > --- a/drivers/tty/slave/Kconfig
> > +++ b/drivers/tty/slave/Kconfig
> > @@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
> > 	  Devices which attach via a uart, but need extra
> > 	  driver support for power management etc.
> > 
> > +if TTY_SLAVE
> > +
> > +config SERIAL_POWER_MANAGER
> > +	tristate "Power Management controller for serial-attached devices"
> > +	default n
> > +	help
> > +	  Some devices permanently attached via a UART can benefit from
> > +	  being power-managed when the tty device is opened or closed.
> > +	  This driver can support several such devices with simple
> > +	  power requirements such as enabling a regulator.
> > +
> > +	  If in doubt, say 'N'
> > +
> > +endif
> > diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
> > index 65669acb392e..a2f7d2847319 100644
> > --- a/drivers/tty/slave/Makefile
> > +++ b/drivers/tty/slave/Makefile
> > @@ -1,2 +1,4 @@
> > 
> > obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
> > +
> > +obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
> > diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
> > new file mode 100644
> > index 000000000000..662a526d8630
> > --- /dev/null
> > +++ b/drivers/tty/slave/serial-power-manager.c
> > @@ -0,0 +1,510 @@
> > +/*
> > + * Serial-power-manager
> > + * tty-slave device that intercepts open/close events on the tty,
> > + * and turns power on/off for the device which is connected.
> > + *
> > + * Currently supported devices:
> > + *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
> > + *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
> > + *
> > + * When appropriate, an RFKILL will be registered which
> > + * can power-down the device even when it is open.
> > + *
> > + * Device can be turned on either by
> > + *  - enabling a regulator.  Disable to turn off
> > + *  - toggling a GPIO.  Toggle again to turn off.  This requires
> > + *     that we know the current state.  It is assumed to be 'off'
> > + *     at boot, however if an interrupt can be generated when on,
> > + *     such as by connecting RX to a GPIO, that can be used to detect
> > + *     if the device is on when it should be off.
> 
> Why does this driver mix both things? 
> 
> The only thing they have in common is that both are uart slaves
> and that they have a serial interface. But power control is very
> different.

Because if I wrote two drivers, they would have more code in common than they
would have differences.


> 
> One driver per fundamentally different chip...
> 
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/err.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of_device.h>
> > +#include <linux/tty.h>
> > +#include <linux/gpio.h>
> > +#include <linux/of_gpio.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/delay.h>
> > +#include <linux/rfkill.h>
> > +
> > +#include <linux/tty_slave.h>
> > +
> > +/* This is used for testing. Setting this module parameter
> > + * will simulate booting with the device "on"
> > + */
> > +static bool toggle_on_probe = false;
> > +module_param(toggle_on_probe, bool, 0);
> > +MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
> > +
> > +struct spm_config {
> > +	int	rfkill_type;		/* type of rfkill to register */
> > +	int	toggle_time;		/* msec to pulse GPIO for on/off */
> > +	int	toggle_gap;		/* min msecs between toggles */
> > +	bool	off_in_suspend;
> > +}
> > +	simple_config = {
> > +		.off_in_suspend = true,
> > +	},
> > +	w2sg_config = {
> > +		.rfkill_type = RFKILL_TYPE_GPS,
> 
> The driver pretends to be generic by its name but incorporates a lot of specific
> knowledge about the w2sg chip, e.g. that it is a GPS chip.
> 
> > +		.toggle_time = 10,
> > +		.toggle_gap = 500,
> > +		.off_in_suspend = true,
> > +	};
> > +
> > +const static struct of_device_id spm_dt_ids[] = {
> > +       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
> > +       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},
> 
> Well, how large will this table become if other uart slave device types
> are added?

When that becomes a problem it can trivially be solved.  While it is not a
problem there is no value in solving it.


> 
> > +       {}
> > +};
> > +
> > +struct spm_data {
> > +	const struct spm_config *config;
> > +	struct gpio_desc *gpiod;
> > +	int		irq;	/* irq line from RX pin when pinctrl
> > +				 * set to 'idle' */
> > +	struct regulator *reg;
> > +
> > +	unsigned long	toggle_time;
> > +	unsigned long	toggle_gap;
> > +	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
> > +	unsigned long	backoff;	/* jiffies since last_toggle when
> > +					 * we try again
> > +					 */
> > +	enum {Idle, Down, Up} state;	/* state-machine state. */
> > +
> > +	int		open_cnt;
> > +	bool		requested, is_on;
> > +	bool		suspended;
> > +	bool		reg_enabled;
> > +
> > +	struct pinctrl	*pins;
> > +	struct pinctrl_state *pins_off;
> > +
> > +	struct delayed_work work;
> > +	spinlock_t	lock;
> > +	struct device	*dev;
> > +
> > +	struct rfkill	*rfkill;
> > +
> > +	int (*old_open)(struct tty_struct * tty, struct file * filp);
> > +	void (*old_close)(struct tty_struct * tty, struct file * filp);
> > +
> > +};
> > +
> > +/* When a device is powered on/off by toggling a GPIO we perform
> > + * all the toggling via a workqueue to ensure only one toggle happens
> > + * at a time and to allow easy timing.
> > + * This is managed as a state machine which transitions
> > + *  Idle -> Down -> Up -> Idle
> > + * The GPIO is held down for toggle_time and then up for toggle_time,
> > + * and then we assume the device has changed state.
> > + * We never toggle until at least toggle_gap has passed since the
> > + * last toggle.
> > + */
> > +static void toggle_work(struct work_struct *work)
> > +{
> > +	struct spm_data *data = container_of(
> > +		work, struct spm_data, work.work);
> > +
> > +	if (data->gpiod == NULL)
> > +		return;
> > +
> > +	spin_lock_irq(&data->lock);
> > +	switch (data->state) {
> > +	case Up:
> > +		data->state = Idle;
> > +		if (data->requested == data->is_on)
> > +			break;
> > +		if (!data->requested)
> > +			/* Assume it is off unless activity is detected */
> > +			break;
> > +		/* Try again in a while unless we get some activity */
> > +		dev_dbg(data->dev, "Wait %dusec until retry\n",
> > +			jiffies_to_msecs(data->backoff));
> > +		schedule_delayed_work(&data->work, data->backoff);
> > +		break;
> > +	case Idle:
> > +		if (data->requested == data->is_on)
> > +			break;
> > +
> > +		/* Time to toggle */
> > +		dev_dbg(data->dev, "Starting toggle to turn %s\n",
> > +			data->requested ? "on" : "off");
> > +		data->state = Down;
> > +		spin_unlock_irq(&data->lock);
> > +		gpiod_set_value_cansleep(data->gpiod, 1);
> > +		schedule_delayed_work(&data->work, data->toggle_time);
> > +
> > +		return;
> > +
> > +	case Down:
> > +		data->state = Up;
> > +		data->last_toggle = jiffies;
> > +		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
> > +			data->is_on ? "off" : "on");
> > +		data->is_on = ! data->is_on;
> > +		spin_unlock_irq(&data->lock);
> > +
> > +		gpiod_set_value_cansleep(data->gpiod, 0);
> > +		schedule_delayed_work(&data->work, data->toggle_time);
> > +
> > +		return;
> > +	}
> > +	spin_unlock_irq(&data->lock);
> > +}
> > +
> > +static irqreturn_t spm_isr(int irq, void *dev_id)
> > +{
> > +	struct spm_data *data = dev_id;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +	if (!data->requested && !data->is_on && data->state == Idle &&
> > +	    time_after(jiffies, data->last_toggle + data->backoff)) {
> > +		data->is_on = 1;
> > +		data->backoff *= 2;
> > +		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
> > +		if (!data->suspended)
> > +			schedule_delayed_work(&data->work, 0);
> > +	}
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static void spm_on(struct spm_data *data)
> > +{
> > +	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
> > +		unsigned long flags;
> > +
> > +		if (!data->reg_enabled &&
> > +		    data->reg &&
> > +		    regulator_enable(data->reg) == 0)
> > +			data->reg_enabled = true;
> > +
> > +		spin_lock_irqsave(&data->lock, flags);
> > +		if (!data->requested) {
> > +			dev_dbg(data->dev, "TTY open - turn device on\n");
> > +			data->requested = true;
> > +			data->backoff = data->toggle_gap;
> > +			if (data->irq > 0) {
> > +				disable_irq(data->irq);
> > +				pinctrl_pm_select_default_state(data->dev);
> > +			}
> > +			if (!data->suspended && data->state == Idle)
> > +				schedule_delayed_work(&data->work, 0);
> > +		}
> > +		spin_unlock_irqrestore(&data->lock, flags);
> > +	}
> > +}
> > +
> > +static int spm_open(struct tty_struct *tty, struct file *filp)
> > +{
> > +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> > +
> > +	data->open_cnt++;
> > +	spm_on(data);
> > +	if (data->old_open)
> > +		return data->old_open(tty, filp);
> > +}
> > +
> > +static void spm_off(struct spm_data *data)
> > +{
> > +	unsigned long flags;
> > +
> > +	if (data->reg && data->reg_enabled)
> > +		if (regulator_disable(data->reg) == 0)
> > +			data->reg_enabled = false;
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +	if (data->requested) {
> > +		data->requested = false;
> > +		data->backoff = data->toggle_gap;
> > +		if (data->pins_off) {
> > +			pinctrl_select_state(data->pins,
> > +					     data->pins_off);
> > +			enable_irq(data->irq);
> > +		}
> > +		if (!data->suspended && data->state == Idle)
> > +			schedule_delayed_work(&data->work, 0);
> > +	}
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +}
> > +
> > +static void spm_close(struct tty_struct *tty, struct file *filp)
> > +{
> > +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> > +
> > +	data->open_cnt--;
> > +	if (!data->open_cnt) {
> > +		dev_dbg(data->dev, "TTY closed - turn device off\n");
> > +		spm_off(data);
> > +	}
> > +
> > +	if (data->old_close)
> > +		data->old_close(tty, filp);
> > +}
> > +
> > +static int spm_rfkill_set_block(void *vdata, bool blocked)
> > +{
> > +	struct spm_data *data = vdata;
> > +
> > +	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
> > +	if (blocked)
> > +		spm_off(data);
> > +
> > +	if (!blocked &&
> > +	    data->open_cnt)
> > +		spm_on(data);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct rfkill_ops spm_rfkill_ops = {
> > +	.set_block = spm_rfkill_set_block,
> > +};
> > +
> > +static int spm_suspend(struct device *dev)
> > +{
> > +	/* Ignore incoming data and just turn device off.
> > +	 * we cannot really wait for a separate thread to
> > +	 * do things, so we disable that and do it all
> > +	 * here
> > +	 */
> > +	struct spm_data *data = dev_get_drvdata(dev);
> > +
> > +	spin_lock_irq(&data->lock);
> > +	data->suspended = true;
> > +	spin_unlock_irq(&data->lock);
> > +	if (!data->config->off_in_suspend)
> > +		return 0;
> > +
> > +	if (data->gpiod) {
> > +
> > +		cancel_delayed_work_sync(&data->work);
> > +		if (data->state == Down) {
> > +			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
> > +			msleep(data->config->toggle_time);
> > +			gpiod_set_value_cansleep(data->gpiod, 0);
> > +			data->last_toggle = jiffies;
> > +			data->is_on = !data->is_on;
> > +			data->state = Up;
> > +		}
> > +		if (data->state == Up) {
> > +			msleep(data->config->toggle_time);
> > +			data->state = Idle;
> > +		}
> > +		if (data->is_on) {
> > +			dev_dbg(data->dev, "Suspending while device on: toggling\n");
> > +			gpiod_set_value_cansleep(data->gpiod, 1);
> > +			msleep(data->config->toggle_time);
> > +			gpiod_set_value_cansleep(data->gpiod, 0);
> > +			data->is_on = 0;
> > +		}
> > +	}
> > +
> > +	if (data->reg && data->reg_enabled)
> > +		if (regulator_disable(data->reg) == 0)
> > +			data->reg_enabled = false;
> > +
> > +	return 0;
> > +}
> > +
> > +static int spm_resume(struct device *dev)
> > +{
> > +	struct spm_data *data = dev_get_drvdata(dev);
> > +
> > +	spin_lock_irq(&data->lock);
> > +	data->suspended = false;
> > +	spin_unlock_irq(&data->lock);
> > +	schedule_delayed_work(&data->work, 0);
> > +
> > +	if (data->open_cnt &&
> > +	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
> > +		if (!data->reg_enabled &&
> > +		    data->reg &&
> > +		    regulator_enable(data->reg) == 0)
> > +			data->reg_enabled = true;
> > +	}
> > +	return 0;
> > +}
> > +
> > +static const struct dev_pm_ops spm_pm_ops = {
> > +	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
> > +};
> > +
> > +static int spm_probe(struct device *dev)
> > +{
> > +	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
> > +	struct spm_data *data;
> > +	struct regulator *reg;
> > +	int err;
> > +	const struct of_device_id *id;
> > +	const char *name;
> > +
> > +	if (dev->parent == NULL)
> > +		return -ENODEV;
> > +
> > +	id = of_match_device(spm_dt_ids, dev);
> > +	if (!id)
> > +		return -ENODEV;
> > +
> > +	if (dev->of_node && dev->of_node->name)
> > +		name = dev->of_node->name;
> > +	else
> > +		name = "serial-power-manager";
> > +
> > +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > +	if (!data)
> > +		return -ENOMEM;
> > +
> > +	data->config = id->data;
> > +	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
> > +	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
> > +	data->last_toggle = jiffies;
> > +	data->backoff = data->toggle_gap;
> > +	data->state = Idle;
> > +	spin_lock_init(&data->lock);
> > +	INIT_DELAYED_WORK(&data->work, toggle_work);
> > +
> > +	/* If a regulator is provided, it is enabled on 'open'
> > +	 * and disabled on 'release'
> > +	 */
> > +	reg = devm_regulator_get(dev, "vdd");
> > +	if (IS_ERR(reg)) {
> > +		err = PTR_ERR(reg);
> > +		if (err != -ENODEV)
> > +			goto out;
> > +	} else
> > +		data->reg = reg;
> > +
> > +	/* If an irq is provided, any transitions are taken as
> > +	 * indication that the device is currently "on"
> > +	 */
> > +	data->irq = of_irq_get(dev->of_node, 0);
> > +	if (data->irq < 0) {
> > +		err = data->irq;
> > +		if (err != -EINVAL)
> > +			goto out;
> > +	} else {
> > +		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
> > +
> > +		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
> > +		err = devm_request_irq(dev, data->irq, spm_isr,
> > +				       IRQF_TRIGGER_FALLING,
> > +				       name, data);
> > +
> > +		if (err)
> > +			goto out;
> > +
> > +	}
> 
> Up to here it is generic and makes no assumptions about a specific
> device.
> 
> > +
> > +	/* If a gpio is provided, then it is used to turn the device
> > +	 * on/off.
> 
> You have a compatible record (for two well defined chips), but you
> do control which functions are really used by providing/not providing
> some DT parameters.
> 
> Either one is redundant.
> 
> > +	 * If toggle_time is zero, then the GPIO directly controls
> > +	 * the device.
> 
> Very hidden and non-obvoius functionality.

Yes, that should probably be documented more clearly, or removed.


> 
> >  If non-zero, then the GPIO must be toggled to
> > +	 * change the state of the device.
> 
> All the following is very special logic for the w2sg0004 chip which should be
> divided out into a separate driver.
> 
> Marek and me already had proposed such a chip specific driver (to be located
> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> specific and present itself as a regulator (because that is its main purpose:
> control the LDO regulator inside the w2sg0004 chip).

Presenting itself as a regulator would be wrong because it isn't a regulator.


Thanks,
NeilBrown


> 
> We can resubmit it as soon as this driver stabilizes and finds acceptance.
> 
> > +	 */
> > +	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
> > +	if (IS_ERR(data->gpiod)) {
> > +		err = PTR_ERR(data->gpiod);
> > +		if (err != -ENOENT)
> > +			goto out;
> > +		data->gpiod = NULL;
> > +	} else
> > +		dev_dbg(dev, "GPIO configured: %d\n",
> > +			desc_to_gpio(data->gpiod));
> > +
> > +	/* If an 'off' pinctrl state is defined, we apply that
> > +	 * when the device is assumed to be off.  This is expected to
> > +	 * route the 'rx' line to the 'irq' interrupt.
> > +	 */
> > +	data->pins = devm_pinctrl_get(dev);
> > +	if (data->pins && data->irq > 0) {
> > +		data->pins_off = pinctrl_lookup_state(data->pins, "off");
> > +		if (IS_ERR(data->pins_off))
> > +			data->pins_off = NULL;
> > +	}
> > +
> > +	if (data->config->rfkill_type) {
> > +		data->rfkill = rfkill_alloc(name, dev,
> > +					    data->config->rfkill_type,
> > +					    &spm_rfkill_ops, data);
> > +		if (!data->rfkill) {
> > +			err = -ENOMEM;
> > +			goto out;
> > +		}
> > +		err = rfkill_register(data->rfkill);
> > +		if (err) {
> > +			dev_err(dev, "Cannot register rfkill device");
> > +			rfkill_destroy(data->rfkill);
> > +			goto out;
> > +		}
> > +	}
> > +	dev_set_drvdata(dev, data);
> > +	data->dev = dev;
> > +	data->old_open = slave->ops.open;
> > +	data->old_close = slave->ops.close;
> > +	slave->ops.open = spm_open;
> > +	slave->ops.close = spm_close;
> > +	tty_slave_finalize(slave);
> > +
> > +	if (data->pins_off)
> > +		pinctrl_select_state(data->pins, data->pins_off);
> > +	if (data->irq > 0)
> > +		enable_irq(data->irq);
> > +
> > +	if (toggle_on_probe && data->gpiod) {
> > +		dev_dbg(data->dev, "Performing initial toggle\n");
> > +		gpiod_set_value_cansleep(data->gpiod, 1);
> > +		msleep(data->config->toggle_time);
> > +		gpiod_set_value_cansleep(data->gpiod, 0);
> > +		msleep(data->config->toggle_time);
> > +	}
> > +	err = 0;
> > +out:
> > +	dev_dbg(data->dev, "Probed: err=%d\n", err);
> > +	return err;
> > +}
> > +
> > +static int spm_remove(struct device *dev)
> > +{
> > +       struct spm_data *data = dev_get_drvdata(dev);
> > +
> > +       if (data->rfkill) {
> > +               rfkill_unregister(data->rfkill);
> > +               rfkill_destroy(data->rfkill);
> > +       }
> > +       return 0;
> > +}
> > +
> > +static struct device_driver spm_driver = {
> > +	.name		= "serial-power-manager",
> > +	.owner		= THIS_MODULE,
> > +	.of_match_table	= spm_dt_ids,
> > +	.probe		= spm_probe,
> > +	.remove		= spm_remove,
> > +};
> > +
> > +static int __init spm_init(void)
> > +{
> > +       return tty_slave_driver_register(&spm_driver);
> > +}
> > +module_init(spm_init);
> > +
> > +static void __exit spm_exit(void)
> > +{
> > +	driver_unregister(&spm_driver);
> > +}
> > +module_exit(spm_exit);
> > +
> > +MODULE_AUTHOR("NeilBrown <neil@brown.name>");
> > +MODULE_DEVICE_TABLE(of, spm_dt_ids);
> > +MODULE_DESCRIPTION("Power management for Serial-attached device.");
> > +MODULE_LICENSE("GPL v2");
> > 
> > 
> > _______________________________________________
> > Gta04-owner mailing list
> > Gta04-owner@goldelico.com
> > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 26763 bytes --]

On Fri, 20 Mar 2015 08:54:38 +0100 "Dr. H. Nikolaus Schaller"
<hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:

> 
> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>:
> 
> > If a platform has a particular device permanently attached to a UART,
> > there may be out-of-band signaling necessary to power the device
> > on and off.
> > 
> > This driver controls that signalling for a number of different devices.
> > It can
> > - enable/disable a regulator
> > - toggle a GPIO
> > - register an 'rfkill' which can force the device to be off.
> > 
> > When the rfkill is absent or unblocked, the device will be on when the
> > associated tty device is open, and closed otherwise.
> > 
> > Signed-off-by: NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>
> > ---
> > .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
> > .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
> > .../devicetree/bindings/vendor-prefixes.txt        |    1 
> > drivers/tty/slave/Kconfig                          |   14 +
> > drivers/tty/slave/Makefile                         |    2 
> > drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
> > 6 files changed, 583 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> > create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> > create mode 100644 drivers/tty/slave/serial-power-manager.c
> > 
> > diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> > new file mode 100644
> > index 000000000000..cfe6ee5e01e9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> > @@ -0,0 +1,19 @@
> > +wi2wi bluetooth module
> > +
> > +This is accessed via a serial port and is largely controlled via that
> > +link.  Extra configuration is needed to enable power on/off
> > +
> > +Required properties:
> > +- compatible: "wi2wi,w2cbw003"
> > +- vdd-supply: regulator used to power the device.
> > +
> > +The node for this device must be the child of a UART.
> > +
> > +Example:
> > +
> > +&uart1 {
> > +       bluetooth {
> > +               compatible = "wi2wi,w2cbw003";
> > +               vdd-supply = <&vaux4>;
> > +       };
> > +};
> 
> Wouldn’t it be easier to simply write
> 
> &uart1 {
> 	vdd-suppy = <&vaux4>;
> }

Easier to write: certainly.
Easier to justify? No.
Easier to get merged upstream?  Definitely not.
After all, the uart itself doesn't require a power supply.
It is the device connected to the uart which requires the power supply.


> 
> > diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> > new file mode 100644
> > index 000000000000..fdc52cf56533
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> > @@ -0,0 +1,37 @@
> > +wi2wi GPS device
> > +
> > +This is accessed via a serial port and is largely controlled via that
> > +link.  Extra configuration is needed to enable power on/off
> > +
> > +Required properties:
> > +- compatible: "wi2wi,w2sg0004"
> > +- gpios: gpios used to toggle 'on/off' pin
> > +- interrupts: interrupt generated by RX pin when device
> > +      should be off
> > +
> > +Optional properties:
> > +- vdd-supply: regulator used to power antenna
> > +- pinctrl: "default", "off"
> > +      if "off" setting is provided it is imposed when device should
> > +      be off.  This can route the RX pin to a GPIO interrupt.
> > +
> > +The w2sg0004 uses a pin-toggle both to power-on and to
> > +power-off, so the driver needs to detect what state it is in.
> > +It does this by detecting characters on the RX line.
> > +When it should be off, these can optionally be detected by a GPIO.
> > +
> > +The node for this device must be the child of a UART.
> > +
> > +Example:
> > +&uart2 {
> > +       gps {
> > +               compatible = "wi2iw,w2sg0004";
> > +               vdd-supply = <&vsim>;
> > +               gpios = <&gpio5 17 0>; /* GPIO_145 */
> > +               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
> > +               /* When off, switch RX to be an interrupt */
> > +               pinctrl-names = "default", "off";
> > +               pinctrl-0 = <&uart2_pins>;
> > +               pinctrl-1 = <&uart2_pins_rx_gpio>;
> > +       };
> > +};
> 
> If the wi2wi driver is a regulator driver one would write
> 
> / {
>        gps-regulator: gps {
>                compatible = "wi2iw,w2sg0004";
>                vdd-supply = <&vsim>;
>                gpios = <&gpio5 17 0>; /* GPIO_145 */
>                interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
>                /* When off, switch RX to be an interrupt */
>                pinctrl-names = "default", "off";
>                pinctrl-0 = <&uart2_pins>;
>                pinctrl-1 = <&uart2_pins_rx_gpio>;
>        };
> }
> 
> &uart2 {
> 	vdd-suppy = <&gps-regulator>;
> };
> 
> Which IMHO better describes that the uart controls power of a separate driver.

But the uart doesn't control the power.
An 'open' on the tty causes one driver to turn on a regulator, and another
driver to activate a uart so that the device represented by the tty can be
communicated with.

> 
> And this pattern for writing a DT would IMHO be more flexible because you
> can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.

I'm sure there are lots of ways we could find to make DT more flexible, only
then it wouldn't be DT any more - it would be something similar but different.

There needs to be one device-node for each device, and that device-node needs
to be a child of the device-node for the device which is the primary
connection to the child device.  That is how devicetree is structured - for
better or worse.



> 
> 
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 389ca1347a77..81d259303710 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -189,6 +189,7 @@ variscite	Variscite Ltd.
> > via	VIA Technologies, Inc.
> > virtio	Virtual I/O Device Specification, developed by the OASIS consortium
> > voipac	Voipac Technologies s.r.o.
> > +wi2wi	wi2wi Inc.  http://www.wi2wi.com/
> > winbond Winbond Electronics corp.
> > wlf	Wolfson Microelectronics
> > wm	Wondermedia Technologies, Inc.
> > diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
> > index 3976760c2e28..05c5d966ae57 100644
> > --- a/drivers/tty/slave/Kconfig
> > +++ b/drivers/tty/slave/Kconfig
> > @@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
> > 	  Devices which attach via a uart, but need extra
> > 	  driver support for power management etc.
> > 
> > +if TTY_SLAVE
> > +
> > +config SERIAL_POWER_MANAGER
> > +	tristate "Power Management controller for serial-attached devices"
> > +	default n
> > +	help
> > +	  Some devices permanently attached via a UART can benefit from
> > +	  being power-managed when the tty device is opened or closed.
> > +	  This driver can support several such devices with simple
> > +	  power requirements such as enabling a regulator.
> > +
> > +	  If in doubt, say 'N'
> > +
> > +endif
> > diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
> > index 65669acb392e..a2f7d2847319 100644
> > --- a/drivers/tty/slave/Makefile
> > +++ b/drivers/tty/slave/Makefile
> > @@ -1,2 +1,4 @@
> > 
> > obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
> > +
> > +obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
> > diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
> > new file mode 100644
> > index 000000000000..662a526d8630
> > --- /dev/null
> > +++ b/drivers/tty/slave/serial-power-manager.c
> > @@ -0,0 +1,510 @@
> > +/*
> > + * Serial-power-manager
> > + * tty-slave device that intercepts open/close events on the tty,
> > + * and turns power on/off for the device which is connected.
> > + *
> > + * Currently supported devices:
> > + *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
> > + *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
> > + *
> > + * When appropriate, an RFKILL will be registered which
> > + * can power-down the device even when it is open.
> > + *
> > + * Device can be turned on either by
> > + *  - enabling a regulator.  Disable to turn off
> > + *  - toggling a GPIO.  Toggle again to turn off.  This requires
> > + *     that we know the current state.  It is assumed to be 'off'
> > + *     at boot, however if an interrupt can be generated when on,
> > + *     such as by connecting RX to a GPIO, that can be used to detect
> > + *     if the device is on when it should be off.
> 
> Why does this driver mix both things? 
> 
> The only thing they have in common is that both are uart slaves
> and that they have a serial interface. But power control is very
> different.

Because if I wrote two drivers, they would have more code in common than they
would have differences.


> 
> One driver per fundamentally different chip...
> 
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/slab.h>
> > +#include <linux/err.h>
> > +#include <linux/regulator/consumer.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of_device.h>
> > +#include <linux/tty.h>
> > +#include <linux/gpio.h>
> > +#include <linux/of_gpio.h>
> > +#include <linux/of_irq.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/delay.h>
> > +#include <linux/rfkill.h>
> > +
> > +#include <linux/tty_slave.h>
> > +
> > +/* This is used for testing. Setting this module parameter
> > + * will simulate booting with the device "on"
> > + */
> > +static bool toggle_on_probe = false;
> > +module_param(toggle_on_probe, bool, 0);
> > +MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
> > +
> > +struct spm_config {
> > +	int	rfkill_type;		/* type of rfkill to register */
> > +	int	toggle_time;		/* msec to pulse GPIO for on/off */
> > +	int	toggle_gap;		/* min msecs between toggles */
> > +	bool	off_in_suspend;
> > +}
> > +	simple_config = {
> > +		.off_in_suspend = true,
> > +	},
> > +	w2sg_config = {
> > +		.rfkill_type = RFKILL_TYPE_GPS,
> 
> The driver pretends to be generic by its name but incorporates a lot of specific
> knowledge about the w2sg chip, e.g. that it is a GPS chip.
> 
> > +		.toggle_time = 10,
> > +		.toggle_gap = 500,
> > +		.off_in_suspend = true,
> > +	};
> > +
> > +const static struct of_device_id spm_dt_ids[] = {
> > +       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
> > +       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},
> 
> Well, how large will this table become if other uart slave device types
> are added?

When that becomes a problem it can trivially be solved.  While it is not a
problem there is no value in solving it.


> 
> > +       {}
> > +};
> > +
> > +struct spm_data {
> > +	const struct spm_config *config;
> > +	struct gpio_desc *gpiod;
> > +	int		irq;	/* irq line from RX pin when pinctrl
> > +				 * set to 'idle' */
> > +	struct regulator *reg;
> > +
> > +	unsigned long	toggle_time;
> > +	unsigned long	toggle_gap;
> > +	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
> > +	unsigned long	backoff;	/* jiffies since last_toggle when
> > +					 * we try again
> > +					 */
> > +	enum {Idle, Down, Up} state;	/* state-machine state. */
> > +
> > +	int		open_cnt;
> > +	bool		requested, is_on;
> > +	bool		suspended;
> > +	bool		reg_enabled;
> > +
> > +	struct pinctrl	*pins;
> > +	struct pinctrl_state *pins_off;
> > +
> > +	struct delayed_work work;
> > +	spinlock_t	lock;
> > +	struct device	*dev;
> > +
> > +	struct rfkill	*rfkill;
> > +
> > +	int (*old_open)(struct tty_struct * tty, struct file * filp);
> > +	void (*old_close)(struct tty_struct * tty, struct file * filp);
> > +
> > +};
> > +
> > +/* When a device is powered on/off by toggling a GPIO we perform
> > + * all the toggling via a workqueue to ensure only one toggle happens
> > + * at a time and to allow easy timing.
> > + * This is managed as a state machine which transitions
> > + *  Idle -> Down -> Up -> Idle
> > + * The GPIO is held down for toggle_time and then up for toggle_time,
> > + * and then we assume the device has changed state.
> > + * We never toggle until at least toggle_gap has passed since the
> > + * last toggle.
> > + */
> > +static void toggle_work(struct work_struct *work)
> > +{
> > +	struct spm_data *data = container_of(
> > +		work, struct spm_data, work.work);
> > +
> > +	if (data->gpiod == NULL)
> > +		return;
> > +
> > +	spin_lock_irq(&data->lock);
> > +	switch (data->state) {
> > +	case Up:
> > +		data->state = Idle;
> > +		if (data->requested == data->is_on)
> > +			break;
> > +		if (!data->requested)
> > +			/* Assume it is off unless activity is detected */
> > +			break;
> > +		/* Try again in a while unless we get some activity */
> > +		dev_dbg(data->dev, "Wait %dusec until retry\n",
> > +			jiffies_to_msecs(data->backoff));
> > +		schedule_delayed_work(&data->work, data->backoff);
> > +		break;
> > +	case Idle:
> > +		if (data->requested == data->is_on)
> > +			break;
> > +
> > +		/* Time to toggle */
> > +		dev_dbg(data->dev, "Starting toggle to turn %s\n",
> > +			data->requested ? "on" : "off");
> > +		data->state = Down;
> > +		spin_unlock_irq(&data->lock);
> > +		gpiod_set_value_cansleep(data->gpiod, 1);
> > +		schedule_delayed_work(&data->work, data->toggle_time);
> > +
> > +		return;
> > +
> > +	case Down:
> > +		data->state = Up;
> > +		data->last_toggle = jiffies;
> > +		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
> > +			data->is_on ? "off" : "on");
> > +		data->is_on = ! data->is_on;
> > +		spin_unlock_irq(&data->lock);
> > +
> > +		gpiod_set_value_cansleep(data->gpiod, 0);
> > +		schedule_delayed_work(&data->work, data->toggle_time);
> > +
> > +		return;
> > +	}
> > +	spin_unlock_irq(&data->lock);
> > +}
> > +
> > +static irqreturn_t spm_isr(int irq, void *dev_id)
> > +{
> > +	struct spm_data *data = dev_id;
> > +	unsigned long flags;
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +	if (!data->requested && !data->is_on && data->state == Idle &&
> > +	    time_after(jiffies, data->last_toggle + data->backoff)) {
> > +		data->is_on = 1;
> > +		data->backoff *= 2;
> > +		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
> > +		if (!data->suspended)
> > +			schedule_delayed_work(&data->work, 0);
> > +	}
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static void spm_on(struct spm_data *data)
> > +{
> > +	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
> > +		unsigned long flags;
> > +
> > +		if (!data->reg_enabled &&
> > +		    data->reg &&
> > +		    regulator_enable(data->reg) == 0)
> > +			data->reg_enabled = true;
> > +
> > +		spin_lock_irqsave(&data->lock, flags);
> > +		if (!data->requested) {
> > +			dev_dbg(data->dev, "TTY open - turn device on\n");
> > +			data->requested = true;
> > +			data->backoff = data->toggle_gap;
> > +			if (data->irq > 0) {
> > +				disable_irq(data->irq);
> > +				pinctrl_pm_select_default_state(data->dev);
> > +			}
> > +			if (!data->suspended && data->state == Idle)
> > +				schedule_delayed_work(&data->work, 0);
> > +		}
> > +		spin_unlock_irqrestore(&data->lock, flags);
> > +	}
> > +}
> > +
> > +static int spm_open(struct tty_struct *tty, struct file *filp)
> > +{
> > +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> > +
> > +	data->open_cnt++;
> > +	spm_on(data);
> > +	if (data->old_open)
> > +		return data->old_open(tty, filp);
> > +}
> > +
> > +static void spm_off(struct spm_data *data)
> > +{
> > +	unsigned long flags;
> > +
> > +	if (data->reg && data->reg_enabled)
> > +		if (regulator_disable(data->reg) == 0)
> > +			data->reg_enabled = false;
> > +
> > +	spin_lock_irqsave(&data->lock, flags);
> > +	if (data->requested) {
> > +		data->requested = false;
> > +		data->backoff = data->toggle_gap;
> > +		if (data->pins_off) {
> > +			pinctrl_select_state(data->pins,
> > +					     data->pins_off);
> > +			enable_irq(data->irq);
> > +		}
> > +		if (!data->suspended && data->state == Idle)
> > +			schedule_delayed_work(&data->work, 0);
> > +	}
> > +	spin_unlock_irqrestore(&data->lock, flags);
> > +}
> > +
> > +static void spm_close(struct tty_struct *tty, struct file *filp)
> > +{
> > +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
> > +
> > +	data->open_cnt--;
> > +	if (!data->open_cnt) {
> > +		dev_dbg(data->dev, "TTY closed - turn device off\n");
> > +		spm_off(data);
> > +	}
> > +
> > +	if (data->old_close)
> > +		data->old_close(tty, filp);
> > +}
> > +
> > +static int spm_rfkill_set_block(void *vdata, bool blocked)
> > +{
> > +	struct spm_data *data = vdata;
> > +
> > +	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
> > +	if (blocked)
> > +		spm_off(data);
> > +
> > +	if (!blocked &&
> > +	    data->open_cnt)
> > +		spm_on(data);
> > +
> > +	return 0;
> > +}
> > +
> > +static struct rfkill_ops spm_rfkill_ops = {
> > +	.set_block = spm_rfkill_set_block,
> > +};
> > +
> > +static int spm_suspend(struct device *dev)
> > +{
> > +	/* Ignore incoming data and just turn device off.
> > +	 * we cannot really wait for a separate thread to
> > +	 * do things, so we disable that and do it all
> > +	 * here
> > +	 */
> > +	struct spm_data *data = dev_get_drvdata(dev);
> > +
> > +	spin_lock_irq(&data->lock);
> > +	data->suspended = true;
> > +	spin_unlock_irq(&data->lock);
> > +	if (!data->config->off_in_suspend)
> > +		return 0;
> > +
> > +	if (data->gpiod) {
> > +
> > +		cancel_delayed_work_sync(&data->work);
> > +		if (data->state == Down) {
> > +			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
> > +			msleep(data->config->toggle_time);
> > +			gpiod_set_value_cansleep(data->gpiod, 0);
> > +			data->last_toggle = jiffies;
> > +			data->is_on = !data->is_on;
> > +			data->state = Up;
> > +		}
> > +		if (data->state == Up) {
> > +			msleep(data->config->toggle_time);
> > +			data->state = Idle;
> > +		}
> > +		if (data->is_on) {
> > +			dev_dbg(data->dev, "Suspending while device on: toggling\n");
> > +			gpiod_set_value_cansleep(data->gpiod, 1);
> > +			msleep(data->config->toggle_time);
> > +			gpiod_set_value_cansleep(data->gpiod, 0);
> > +			data->is_on = 0;
> > +		}
> > +	}
> > +
> > +	if (data->reg && data->reg_enabled)
> > +		if (regulator_disable(data->reg) == 0)
> > +			data->reg_enabled = false;
> > +
> > +	return 0;
> > +}
> > +
> > +static int spm_resume(struct device *dev)
> > +{
> > +	struct spm_data *data = dev_get_drvdata(dev);
> > +
> > +	spin_lock_irq(&data->lock);
> > +	data->suspended = false;
> > +	spin_unlock_irq(&data->lock);
> > +	schedule_delayed_work(&data->work, 0);
> > +
> > +	if (data->open_cnt &&
> > +	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
> > +		if (!data->reg_enabled &&
> > +		    data->reg &&
> > +		    regulator_enable(data->reg) == 0)
> > +			data->reg_enabled = true;
> > +	}
> > +	return 0;
> > +}
> > +
> > +static const struct dev_pm_ops spm_pm_ops = {
> > +	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
> > +};
> > +
> > +static int spm_probe(struct device *dev)
> > +{
> > +	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
> > +	struct spm_data *data;
> > +	struct regulator *reg;
> > +	int err;
> > +	const struct of_device_id *id;
> > +	const char *name;
> > +
> > +	if (dev->parent == NULL)
> > +		return -ENODEV;
> > +
> > +	id = of_match_device(spm_dt_ids, dev);
> > +	if (!id)
> > +		return -ENODEV;
> > +
> > +	if (dev->of_node && dev->of_node->name)
> > +		name = dev->of_node->name;
> > +	else
> > +		name = "serial-power-manager";
> > +
> > +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > +	if (!data)
> > +		return -ENOMEM;
> > +
> > +	data->config = id->data;
> > +	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
> > +	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
> > +	data->last_toggle = jiffies;
> > +	data->backoff = data->toggle_gap;
> > +	data->state = Idle;
> > +	spin_lock_init(&data->lock);
> > +	INIT_DELAYED_WORK(&data->work, toggle_work);
> > +
> > +	/* If a regulator is provided, it is enabled on 'open'
> > +	 * and disabled on 'release'
> > +	 */
> > +	reg = devm_regulator_get(dev, "vdd");
> > +	if (IS_ERR(reg)) {
> > +		err = PTR_ERR(reg);
> > +		if (err != -ENODEV)
> > +			goto out;
> > +	} else
> > +		data->reg = reg;
> > +
> > +	/* If an irq is provided, any transitions are taken as
> > +	 * indication that the device is currently "on"
> > +	 */
> > +	data->irq = of_irq_get(dev->of_node, 0);
> > +	if (data->irq < 0) {
> > +		err = data->irq;
> > +		if (err != -EINVAL)
> > +			goto out;
> > +	} else {
> > +		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
> > +
> > +		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
> > +		err = devm_request_irq(dev, data->irq, spm_isr,
> > +				       IRQF_TRIGGER_FALLING,
> > +				       name, data);
> > +
> > +		if (err)
> > +			goto out;
> > +
> > +	}
> 
> Up to here it is generic and makes no assumptions about a specific
> device.
> 
> > +
> > +	/* If a gpio is provided, then it is used to turn the device
> > +	 * on/off.
> 
> You have a compatible record (for two well defined chips), but you
> do control which functions are really used by providing/not providing
> some DT parameters.
> 
> Either one is redundant.
> 
> > +	 * If toggle_time is zero, then the GPIO directly controls
> > +	 * the device.
> 
> Very hidden and non-obvoius functionality.

Yes, that should probably be documented more clearly, or removed.


> 
> >  If non-zero, then the GPIO must be toggled to
> > +	 * change the state of the device.
> 
> All the following is very special logic for the w2sg0004 chip which should be
> divided out into a separate driver.
> 
> Marek and me already had proposed such a chip specific driver (to be located
> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> specific and present itself as a regulator (because that is its main purpose:
> control the LDO regulator inside the w2sg0004 chip).

Presenting itself as a regulator would be wrong because it isn't a regulator.


Thanks,
NeilBrown


> 
> We can resubmit it as soon as this driver stabilizes and finds acceptance.
> 
> > +	 */
> > +	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
> > +	if (IS_ERR(data->gpiod)) {
> > +		err = PTR_ERR(data->gpiod);
> > +		if (err != -ENOENT)
> > +			goto out;
> > +		data->gpiod = NULL;
> > +	} else
> > +		dev_dbg(dev, "GPIO configured: %d\n",
> > +			desc_to_gpio(data->gpiod));
> > +
> > +	/* If an 'off' pinctrl state is defined, we apply that
> > +	 * when the device is assumed to be off.  This is expected to
> > +	 * route the 'rx' line to the 'irq' interrupt.
> > +	 */
> > +	data->pins = devm_pinctrl_get(dev);
> > +	if (data->pins && data->irq > 0) {
> > +		data->pins_off = pinctrl_lookup_state(data->pins, "off");
> > +		if (IS_ERR(data->pins_off))
> > +			data->pins_off = NULL;
> > +	}
> > +
> > +	if (data->config->rfkill_type) {
> > +		data->rfkill = rfkill_alloc(name, dev,
> > +					    data->config->rfkill_type,
> > +					    &spm_rfkill_ops, data);
> > +		if (!data->rfkill) {
> > +			err = -ENOMEM;
> > +			goto out;
> > +		}
> > +		err = rfkill_register(data->rfkill);
> > +		if (err) {
> > +			dev_err(dev, "Cannot register rfkill device");
> > +			rfkill_destroy(data->rfkill);
> > +			goto out;
> > +		}
> > +	}
> > +	dev_set_drvdata(dev, data);
> > +	data->dev = dev;
> > +	data->old_open = slave->ops.open;
> > +	data->old_close = slave->ops.close;
> > +	slave->ops.open = spm_open;
> > +	slave->ops.close = spm_close;
> > +	tty_slave_finalize(slave);
> > +
> > +	if (data->pins_off)
> > +		pinctrl_select_state(data->pins, data->pins_off);
> > +	if (data->irq > 0)
> > +		enable_irq(data->irq);
> > +
> > +	if (toggle_on_probe && data->gpiod) {
> > +		dev_dbg(data->dev, "Performing initial toggle\n");
> > +		gpiod_set_value_cansleep(data->gpiod, 1);
> > +		msleep(data->config->toggle_time);
> > +		gpiod_set_value_cansleep(data->gpiod, 0);
> > +		msleep(data->config->toggle_time);
> > +	}
> > +	err = 0;
> > +out:
> > +	dev_dbg(data->dev, "Probed: err=%d\n", err);
> > +	return err;
> > +}
> > +
> > +static int spm_remove(struct device *dev)
> > +{
> > +       struct spm_data *data = dev_get_drvdata(dev);
> > +
> > +       if (data->rfkill) {
> > +               rfkill_unregister(data->rfkill);
> > +               rfkill_destroy(data->rfkill);
> > +       }
> > +       return 0;
> > +}
> > +
> > +static struct device_driver spm_driver = {
> > +	.name		= "serial-power-manager",
> > +	.owner		= THIS_MODULE,
> > +	.of_match_table	= spm_dt_ids,
> > +	.probe		= spm_probe,
> > +	.remove		= spm_remove,
> > +};
> > +
> > +static int __init spm_init(void)
> > +{
> > +       return tty_slave_driver_register(&spm_driver);
> > +}
> > +module_init(spm_init);
> > +
> > +static void __exit spm_exit(void)
> > +{
> > +	driver_unregister(&spm_driver);
> > +}
> > +module_exit(spm_exit);
> > +
> > +MODULE_AUTHOR("NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>");
> > +MODULE_DEVICE_TABLE(of, spm_dt_ids);
> > +MODULE_DESCRIPTION("Power management for Serial-attached device.");
> > +MODULE_LICENSE("GPL v2");
> > 
> > 
> > _______________________________________________
> > Gta04-owner mailing list
> > Gta04-owner-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org
> > http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@suse.de>:

> On Fri, 20 Mar 2015 08:54:38 +0100 "Dr. H. Nikolaus Schaller"
> <hns@goldelico.com> wrote:
> 
>> 
>> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:
>> 
>>> If a platform has a particular device permanently attached to a UART,
>>> there may be out-of-band signaling necessary to power the device
>>> on and off.
>>> 
>>> This driver controls that signalling for a number of different devices.
>>> It can
>>> - enable/disable a regulator
>>> - toggle a GPIO
>>> - register an 'rfkill' which can force the device to be off.
>>> 
>>> When the rfkill is absent or unblocked, the device will be on when the
>>> associated tty device is open, and closed otherwise.
>>> 
>>> Signed-off-by: NeilBrown <neil@brown.name>
>>> ---
>>> .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
>>> .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
>>> .../devicetree/bindings/vendor-prefixes.txt        |    1 
>>> drivers/tty/slave/Kconfig                          |   14 +
>>> drivers/tty/slave/Makefile                         |    2 
>>> drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
>>> 6 files changed, 583 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> create mode 100644 drivers/tty/slave/serial-power-manager.c
>>> 
>>> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> new file mode 100644
>>> index 000000000000..cfe6ee5e01e9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> @@ -0,0 +1,19 @@
>>> +wi2wi bluetooth module
>>> +
>>> +This is accessed via a serial port and is largely controlled via that
>>> +link.  Extra configuration is needed to enable power on/off
>>> +
>>> +Required properties:
>>> +- compatible: "wi2wi,w2cbw003"
>>> +- vdd-supply: regulator used to power the device.
>>> +
>>> +The node for this device must be the child of a UART.
>>> +
>>> +Example:
>>> +
>>> +&uart1 {
>>> +       bluetooth {
>>> +               compatible = "wi2wi,w2cbw003";
>>> +               vdd-supply = <&vaux4>;
>>> +       };
>>> +};
>> 
>> Wouldn’t it be easier to simply write
>> 
>> &uart1 {
>> 	vdd-suppy = <&vaux4>;
>> }
> 
> Easier to write: certainly.
> Easier to justify? No.

I just justified.

> Easier to get merged upstream?  Definitely not.

Are you the maintainer?

> After all, the uart itself doesn't require a power supply.
> It is the device connected to the uart which requires the power supply.

Yes.

> 
> 
>> 
>>> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> new file mode 100644
>>> index 000000000000..fdc52cf56533
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> @@ -0,0 +1,37 @@
>>> +wi2wi GPS device
>>> +
>>> +This is accessed via a serial port and is largely controlled via that
>>> +link.  Extra configuration is needed to enable power on/off
>>> +
>>> +Required properties:
>>> +- compatible: "wi2wi,w2sg0004"
>>> +- gpios: gpios used to toggle 'on/off' pin
>>> +- interrupts: interrupt generated by RX pin when device
>>> +      should be off
>>> +
>>> +Optional properties:
>>> +- vdd-supply: regulator used to power antenna
>>> +- pinctrl: "default", "off"
>>> +      if "off" setting is provided it is imposed when device should
>>> +      be off.  This can route the RX pin to a GPIO interrupt.
>>> +
>>> +The w2sg0004 uses a pin-toggle both to power-on and to
>>> +power-off, so the driver needs to detect what state it is in.
>>> +It does this by detecting characters on the RX line.
>>> +When it should be off, these can optionally be detected by a GPIO.
>>> +
>>> +The node for this device must be the child of a UART.
>>> +
>>> +Example:
>>> +&uart2 {
>>> +       gps {
>>> +               compatible = "wi2iw,w2sg0004";
>>> +               vdd-supply = <&vsim>;
>>> +               gpios = <&gpio5 17 0>; /* GPIO_145 */
>>> +               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
>>> +               /* When off, switch RX to be an interrupt */
>>> +               pinctrl-names = "default", "off";
>>> +               pinctrl-0 = <&uart2_pins>;
>>> +               pinctrl-1 = <&uart2_pins_rx_gpio>;
>>> +       };
>>> +};
>> 
>> If the wi2wi driver is a regulator driver one would write
>> 
>> / {
>>       gps-regulator: gps {
>>               compatible = "wi2iw,w2sg0004";
>>               vdd-supply = <&vsim>;
>>               gpios = <&gpio5 17 0>; /* GPIO_145 */
>>               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
>>               /* When off, switch RX to be an interrupt */
>>               pinctrl-names = "default", "off";
>>               pinctrl-0 = <&uart2_pins>;
>>               pinctrl-1 = <&uart2_pins_rx_gpio>;
>>       };
>> }
>> 
>> &uart2 {
>> 	vdd-suppy = <&gps-regulator>;
>> };
>> 
>> Which IMHO better describes that the uart controls power of a separate driver.
> 
> But the uart doesn’t control the power.
> An 'open' on the tty causes one driver to turn on a regulator, and another
> driver to activate a uart so that the device represented by the tty can be
> communicated with.

Ok, that is a detail I have mixed up tty and uart.

> 
>> 
>> And this pattern for writing a DT would IMHO be more flexible because you
>> can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.
> 
> I'm sure there are lots of ways we could find to make DT more flexible, only
> then it wouldn't be DT any more - it would be something similar but different.
> 
> There needs to be one device-node for each device, and that device-node needs
> to be a child of the device-node for the device which is the primary
> connection to the child device.

Then please explain to me nodes like

/ {
	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";

	cpus {
		cpu@0 {
			cpu0-supply = <&vcc>;
		};
	};

According to the rule you apply here it should be something like

	cpu@0 {
		regulator {
			…
		}


>  That is how devicetree is structured - for
> better or worse.
> 
> 
> 
>> 
>> 
>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> index 389ca1347a77..81d259303710 100644
>>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> @@ -189,6 +189,7 @@ variscite	Variscite Ltd.
>>> via	VIA Technologies, Inc.
>>> virtio	Virtual I/O Device Specification, developed by the OASIS consortium
>>> voipac	Voipac Technologies s.r.o.
>>> +wi2wi	wi2wi Inc.  http://www.wi2wi.com/
>>> winbond Winbond Electronics corp.
>>> wlf	Wolfson Microelectronics
>>> wm	Wondermedia Technologies, Inc.
>>> diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
>>> index 3976760c2e28..05c5d966ae57 100644
>>> --- a/drivers/tty/slave/Kconfig
>>> +++ b/drivers/tty/slave/Kconfig
>>> @@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
>>> 	  Devices which attach via a uart, but need extra
>>> 	  driver support for power management etc.
>>> 
>>> +if TTY_SLAVE
>>> +
>>> +config SERIAL_POWER_MANAGER
>>> +	tristate "Power Management controller for serial-attached devices"
>>> +	default n
>>> +	help
>>> +	  Some devices permanently attached via a UART can benefit from
>>> +	  being power-managed when the tty device is opened or closed.
>>> +	  This driver can support several such devices with simple
>>> +	  power requirements such as enabling a regulator.
>>> +
>>> +	  If in doubt, say 'N'
>>> +
>>> +endif
>>> diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
>>> index 65669acb392e..a2f7d2847319 100644
>>> --- a/drivers/tty/slave/Makefile
>>> +++ b/drivers/tty/slave/Makefile
>>> @@ -1,2 +1,4 @@
>>> 
>>> obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
>>> +
>>> +obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
>>> diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
>>> new file mode 100644
>>> index 000000000000..662a526d8630
>>> --- /dev/null
>>> +++ b/drivers/tty/slave/serial-power-manager.c
>>> @@ -0,0 +1,510 @@
>>> +/*
>>> + * Serial-power-manager
>>> + * tty-slave device that intercepts open/close events on the tty,
>>> + * and turns power on/off for the device which is connected.
>>> + *
>>> + * Currently supported devices:
>>> + *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
>>> + *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
>>> + *
>>> + * When appropriate, an RFKILL will be registered which
>>> + * can power-down the device even when it is open.
>>> + *
>>> + * Device can be turned on either by
>>> + *  - enabling a regulator.  Disable to turn off
>>> + *  - toggling a GPIO.  Toggle again to turn off.  This requires
>>> + *     that we know the current state.  It is assumed to be 'off'
>>> + *     at boot, however if an interrupt can be generated when on,
>>> + *     such as by connecting RX to a GPIO, that can be used to detect
>>> + *     if the device is on when it should be off.
>> 
>> Why does this driver mix both things? 
>> 
>> The only thing they have in common is that both are uart slaves
>> and that they have a serial interface. But power control is very
>> different.
> 
> Because if I wrote two drivers, they would have more code in common than they
> would have differences.

I mostly can see the w2sg0004 part as an addition on top of a common boilerplate part.

> 
> 
>> 
>> One driver per fundamentally different chip...
>> 
>>> + */
>>> +
>>> +#include <linux/module.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/err.h>
>>> +#include <linux/regulator/consumer.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/tty.h>
>>> +#include <linux/gpio.h>
>>> +#include <linux/of_gpio.h>
>>> +#include <linux/of_irq.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/rfkill.h>
>>> +
>>> +#include <linux/tty_slave.h>
>>> +
>>> +/* This is used for testing. Setting this module parameter
>>> + * will simulate booting with the device "on"
>>> + */
>>> +static bool toggle_on_probe = false;
>>> +module_param(toggle_on_probe, bool, 0);
>>> +MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
>>> +
>>> +struct spm_config {
>>> +	int	rfkill_type;		/* type of rfkill to register */
>>> +	int	toggle_time;		/* msec to pulse GPIO for on/off */
>>> +	int	toggle_gap;		/* min msecs between toggles */
>>> +	bool	off_in_suspend;
>>> +}
>>> +	simple_config = {
>>> +		.off_in_suspend = true,
>>> +	},
>>> +	w2sg_config = {
>>> +		.rfkill_type = RFKILL_TYPE_GPS,
>> 
>> The driver pretends to be generic by its name but incorporates a lot of specific
>> knowledge about the w2sg chip, e.g. that it is a GPS chip.
>> 
>>> +		.toggle_time = 10,
>>> +		.toggle_gap = 500,
>>> +		.off_in_suspend = true,
>>> +	};
>>> +
>>> +const static struct of_device_id spm_dt_ids[] = {
>>> +       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
>>> +       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},
>> 
>> Well, how large will this table become if other uart slave device types
>> are added?
> 
> When that becomes a problem it can trivially be solved.  While it is not a
> problem there is no value in solving it.

thought-terminating argument?

> 
> 
>> 
>>> +       {}
>>> +};
>>> +
>>> +struct spm_data {
>>> +	const struct spm_config *config;
>>> +	struct gpio_desc *gpiod;
>>> +	int		irq;	/* irq line from RX pin when pinctrl
>>> +				 * set to 'idle' */
>>> +	struct regulator *reg;
>>> +
>>> +	unsigned long	toggle_time;
>>> +	unsigned long	toggle_gap;
>>> +	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
>>> +	unsigned long	backoff;	/* jiffies since last_toggle when
>>> +					 * we try again
>>> +					 */
>>> +	enum {Idle, Down, Up} state;	/* state-machine state. */
>>> +
>>> +	int		open_cnt;
>>> +	bool		requested, is_on;
>>> +	bool		suspended;
>>> +	bool		reg_enabled;
>>> +
>>> +	struct pinctrl	*pins;
>>> +	struct pinctrl_state *pins_off;
>>> +
>>> +	struct delayed_work work;
>>> +	spinlock_t	lock;
>>> +	struct device	*dev;
>>> +
>>> +	struct rfkill	*rfkill;
>>> +
>>> +	int (*old_open)(struct tty_struct * tty, struct file * filp);
>>> +	void (*old_close)(struct tty_struct * tty, struct file * filp);
>>> +
>>> +};
>>> +
>>> +/* When a device is powered on/off by toggling a GPIO we perform
>>> + * all the toggling via a workqueue to ensure only one toggle happens
>>> + * at a time and to allow easy timing.
>>> + * This is managed as a state machine which transitions
>>> + *  Idle -> Down -> Up -> Idle
>>> + * The GPIO is held down for toggle_time and then up for toggle_time,
>>> + * and then we assume the device has changed state.
>>> + * We never toggle until at least toggle_gap has passed since the
>>> + * last toggle.
>>> + */
>>> +static void toggle_work(struct work_struct *work)
>>> +{
>>> +	struct spm_data *data = container_of(
>>> +		work, struct spm_data, work.work);
>>> +
>>> +	if (data->gpiod == NULL)
>>> +		return;
>>> +
>>> +	spin_lock_irq(&data->lock);
>>> +	switch (data->state) {
>>> +	case Up:
>>> +		data->state = Idle;
>>> +		if (data->requested == data->is_on)
>>> +			break;
>>> +		if (!data->requested)
>>> +			/* Assume it is off unless activity is detected */
>>> +			break;
>>> +		/* Try again in a while unless we get some activity */
>>> +		dev_dbg(data->dev, "Wait %dusec until retry\n",
>>> +			jiffies_to_msecs(data->backoff));
>>> +		schedule_delayed_work(&data->work, data->backoff);
>>> +		break;
>>> +	case Idle:
>>> +		if (data->requested == data->is_on)
>>> +			break;
>>> +
>>> +		/* Time to toggle */
>>> +		dev_dbg(data->dev, "Starting toggle to turn %s\n",
>>> +			data->requested ? "on" : "off");
>>> +		data->state = Down;
>>> +		spin_unlock_irq(&data->lock);
>>> +		gpiod_set_value_cansleep(data->gpiod, 1);
>>> +		schedule_delayed_work(&data->work, data->toggle_time);
>>> +
>>> +		return;
>>> +
>>> +	case Down:
>>> +		data->state = Up;
>>> +		data->last_toggle = jiffies;
>>> +		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
>>> +			data->is_on ? "off" : "on");
>>> +		data->is_on = ! data->is_on;
>>> +		spin_unlock_irq(&data->lock);
>>> +
>>> +		gpiod_set_value_cansleep(data->gpiod, 0);
>>> +		schedule_delayed_work(&data->work, data->toggle_time);
>>> +
>>> +		return;
>>> +	}
>>> +	spin_unlock_irq(&data->lock);
>>> +}
>>> +
>>> +static irqreturn_t spm_isr(int irq, void *dev_id)
>>> +{
>>> +	struct spm_data *data = dev_id;
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&data->lock, flags);
>>> +	if (!data->requested && !data->is_on && data->state == Idle &&
>>> +	    time_after(jiffies, data->last_toggle + data->backoff)) {
>>> +		data->is_on = 1;
>>> +		data->backoff *= 2;
>>> +		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
>>> +		if (!data->suspended)
>>> +			schedule_delayed_work(&data->work, 0);
>>> +	}
>>> +	spin_unlock_irqrestore(&data->lock, flags);
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>> +static void spm_on(struct spm_data *data)
>>> +{
>>> +	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
>>> +		unsigned long flags;
>>> +
>>> +		if (!data->reg_enabled &&
>>> +		    data->reg &&
>>> +		    regulator_enable(data->reg) == 0)
>>> +			data->reg_enabled = true;
>>> +
>>> +		spin_lock_irqsave(&data->lock, flags);
>>> +		if (!data->requested) {
>>> +			dev_dbg(data->dev, "TTY open - turn device on\n");
>>> +			data->requested = true;
>>> +			data->backoff = data->toggle_gap;
>>> +			if (data->irq > 0) {
>>> +				disable_irq(data->irq);
>>> +				pinctrl_pm_select_default_state(data->dev);
>>> +			}
>>> +			if (!data->suspended && data->state == Idle)
>>> +				schedule_delayed_work(&data->work, 0);
>>> +		}
>>> +		spin_unlock_irqrestore(&data->lock, flags);
>>> +	}
>>> +}
>>> +
>>> +static int spm_open(struct tty_struct *tty, struct file *filp)
>>> +{
>>> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
>>> +
>>> +	data->open_cnt++;
>>> +	spm_on(data);
>>> +	if (data->old_open)
>>> +		return data->old_open(tty, filp);
>>> +}
>>> +
>>> +static void spm_off(struct spm_data *data)
>>> +{
>>> +	unsigned long flags;
>>> +
>>> +	if (data->reg && data->reg_enabled)
>>> +		if (regulator_disable(data->reg) == 0)
>>> +			data->reg_enabled = false;
>>> +
>>> +	spin_lock_irqsave(&data->lock, flags);
>>> +	if (data->requested) {
>>> +		data->requested = false;
>>> +		data->backoff = data->toggle_gap;
>>> +		if (data->pins_off) {
>>> +			pinctrl_select_state(data->pins,
>>> +					     data->pins_off);
>>> +			enable_irq(data->irq);
>>> +		}
>>> +		if (!data->suspended && data->state == Idle)
>>> +			schedule_delayed_work(&data->work, 0);
>>> +	}
>>> +	spin_unlock_irqrestore(&data->lock, flags);
>>> +}
>>> +
>>> +static void spm_close(struct tty_struct *tty, struct file *filp)
>>> +{
>>> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
>>> +
>>> +	data->open_cnt--;
>>> +	if (!data->open_cnt) {
>>> +		dev_dbg(data->dev, "TTY closed - turn device off\n");
>>> +		spm_off(data);
>>> +	}
>>> +
>>> +	if (data->old_close)
>>> +		data->old_close(tty, filp);
>>> +}
>>> +
>>> +static int spm_rfkill_set_block(void *vdata, bool blocked)
>>> +{
>>> +	struct spm_data *data = vdata;
>>> +
>>> +	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
>>> +	if (blocked)
>>> +		spm_off(data);
>>> +
>>> +	if (!blocked &&
>>> +	    data->open_cnt)
>>> +		spm_on(data);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static struct rfkill_ops spm_rfkill_ops = {
>>> +	.set_block = spm_rfkill_set_block,
>>> +};
>>> +
>>> +static int spm_suspend(struct device *dev)
>>> +{
>>> +	/* Ignore incoming data and just turn device off.
>>> +	 * we cannot really wait for a separate thread to
>>> +	 * do things, so we disable that and do it all
>>> +	 * here
>>> +	 */
>>> +	struct spm_data *data = dev_get_drvdata(dev);
>>> +
>>> +	spin_lock_irq(&data->lock);
>>> +	data->suspended = true;
>>> +	spin_unlock_irq(&data->lock);
>>> +	if (!data->config->off_in_suspend)
>>> +		return 0;
>>> +
>>> +	if (data->gpiod) {
>>> +
>>> +		cancel_delayed_work_sync(&data->work);
>>> +		if (data->state == Down) {
>>> +			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
>>> +			msleep(data->config->toggle_time);
>>> +			gpiod_set_value_cansleep(data->gpiod, 0);
>>> +			data->last_toggle = jiffies;
>>> +			data->is_on = !data->is_on;
>>> +			data->state = Up;
>>> +		}
>>> +		if (data->state == Up) {
>>> +			msleep(data->config->toggle_time);
>>> +			data->state = Idle;
>>> +		}
>>> +		if (data->is_on) {
>>> +			dev_dbg(data->dev, "Suspending while device on: toggling\n");
>>> +			gpiod_set_value_cansleep(data->gpiod, 1);
>>> +			msleep(data->config->toggle_time);
>>> +			gpiod_set_value_cansleep(data->gpiod, 0);
>>> +			data->is_on = 0;
>>> +		}
>>> +	}
>>> +
>>> +	if (data->reg && data->reg_enabled)
>>> +		if (regulator_disable(data->reg) == 0)
>>> +			data->reg_enabled = false;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int spm_resume(struct device *dev)
>>> +{
>>> +	struct spm_data *data = dev_get_drvdata(dev);
>>> +
>>> +	spin_lock_irq(&data->lock);
>>> +	data->suspended = false;
>>> +	spin_unlock_irq(&data->lock);
>>> +	schedule_delayed_work(&data->work, 0);
>>> +
>>> +	if (data->open_cnt &&
>>> +	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
>>> +		if (!data->reg_enabled &&
>>> +		    data->reg &&
>>> +		    regulator_enable(data->reg) == 0)
>>> +			data->reg_enabled = true;
>>> +	}
>>> +	return 0;
>>> +}
>>> +
>>> +static const struct dev_pm_ops spm_pm_ops = {
>>> +	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
>>> +};
>>> +
>>> +static int spm_probe(struct device *dev)
>>> +{
>>> +	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
>>> +	struct spm_data *data;
>>> +	struct regulator *reg;
>>> +	int err;
>>> +	const struct of_device_id *id;
>>> +	const char *name;
>>> +
>>> +	if (dev->parent == NULL)
>>> +		return -ENODEV;
>>> +
>>> +	id = of_match_device(spm_dt_ids, dev);
>>> +	if (!id)
>>> +		return -ENODEV;
>>> +
>>> +	if (dev->of_node && dev->of_node->name)
>>> +		name = dev->of_node->name;
>>> +	else
>>> +		name = "serial-power-manager";
>>> +
>>> +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>>> +	if (!data)
>>> +		return -ENOMEM;
>>> +
>>> +	data->config = id->data;
>>> +	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
>>> +	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
>>> +	data->last_toggle = jiffies;
>>> +	data->backoff = data->toggle_gap;
>>> +	data->state = Idle;
>>> +	spin_lock_init(&data->lock);
>>> +	INIT_DELAYED_WORK(&data->work, toggle_work);
>>> +
>>> +	/* If a regulator is provided, it is enabled on 'open'
>>> +	 * and disabled on 'release'
>>> +	 */
>>> +	reg = devm_regulator_get(dev, "vdd");
>>> +	if (IS_ERR(reg)) {
>>> +		err = PTR_ERR(reg);
>>> +		if (err != -ENODEV)
>>> +			goto out;
>>> +	} else
>>> +		data->reg = reg;
>>> +
>>> +	/* If an irq is provided, any transitions are taken as
>>> +	 * indication that the device is currently "on"
>>> +	 */
>>> +	data->irq = of_irq_get(dev->of_node, 0);
>>> +	if (data->irq < 0) {
>>> +		err = data->irq;
>>> +		if (err != -EINVAL)
>>> +			goto out;
>>> +	} else {
>>> +		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
>>> +
>>> +		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
>>> +		err = devm_request_irq(dev, data->irq, spm_isr,
>>> +				       IRQF_TRIGGER_FALLING,
>>> +				       name, data);
>>> +
>>> +		if (err)
>>> +			goto out;
>>> +
>>> +	}
>> 
>> Up to here it is generic and makes no assumptions about a specific
>> device.
>> 
>>> +
>>> +	/* If a gpio is provided, then it is used to turn the device
>>> +	 * on/off.
>> 
>> You have a compatible record (for two well defined chips), but you
>> do control which functions are really used by providing/not providing
>> some DT parameters.
>> 
>> Either one is redundant.
>> 
>>> +	 * If toggle_time is zero, then the GPIO directly controls
>>> +	 * the device.
>> 
>> Very hidden and non-obvoius functionality.
> 
> Yes, that should probably be documented more clearly, or removed.
> 
> 
>> 
>>> If non-zero, then the GPIO must be toggled to
>>> +	 * change the state of the device.
>> 
>> All the following is very special logic for the w2sg0004 chip which should be
>> divided out into a separate driver.
>> 
>> Marek and me already had proposed such a chip specific driver (to be located
>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>> specific and present itself as a regulator (because that is its main purpose:
>> control the LDO regulator inside the w2sg0004 chip).
> 
> Presenting itself as a regulator would be wrong because it isn’t a regulator.

It has a regulator that can be controlled by a gpio…

Another example to think about: the twl4030 is also not a regulator.
Nevertheless they present some regulator nodes.

Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
but has an internal pbias_regulator that needs to be controlled.

BR,
Nikolaus

> 
> 
> Thanks,
> NeilBrown
> 
> 
>> 
>> We can resubmit it as soon as this driver stabilizes and finds acceptance.
>> 
>>> +	 */
>>> +	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
>>> +	if (IS_ERR(data->gpiod)) {
>>> +		err = PTR_ERR(data->gpiod);
>>> +		if (err != -ENOENT)
>>> +			goto out;
>>> +		data->gpiod = NULL;
>>> +	} else
>>> +		dev_dbg(dev, "GPIO configured: %d\n",
>>> +			desc_to_gpio(data->gpiod));
>>> +
>>> +	/* If an 'off' pinctrl state is defined, we apply that
>>> +	 * when the device is assumed to be off.  This is expected to
>>> +	 * route the 'rx' line to the 'irq' interrupt.
>>> +	 */
>>> +	data->pins = devm_pinctrl_get(dev);
>>> +	if (data->pins && data->irq > 0) {
>>> +		data->pins_off = pinctrl_lookup_state(data->pins, "off");
>>> +		if (IS_ERR(data->pins_off))
>>> +			data->pins_off = NULL;
>>> +	}
>>> +
>>> +	if (data->config->rfkill_type) {
>>> +		data->rfkill = rfkill_alloc(name, dev,
>>> +					    data->config->rfkill_type,
>>> +					    &spm_rfkill_ops, data);
>>> +		if (!data->rfkill) {
>>> +			err = -ENOMEM;
>>> +			goto out;
>>> +		}
>>> +		err = rfkill_register(data->rfkill);
>>> +		if (err) {
>>> +			dev_err(dev, "Cannot register rfkill device");
>>> +			rfkill_destroy(data->rfkill);
>>> +			goto out;
>>> +		}
>>> +	}
>>> +	dev_set_drvdata(dev, data);
>>> +	data->dev = dev;
>>> +	data->old_open = slave->ops.open;
>>> +	data->old_close = slave->ops.close;
>>> +	slave->ops.open = spm_open;
>>> +	slave->ops.close = spm_close;
>>> +	tty_slave_finalize(slave);
>>> +
>>> +	if (data->pins_off)
>>> +		pinctrl_select_state(data->pins, data->pins_off);
>>> +	if (data->irq > 0)
>>> +		enable_irq(data->irq);
>>> +
>>> +	if (toggle_on_probe && data->gpiod) {
>>> +		dev_dbg(data->dev, "Performing initial toggle\n");
>>> +		gpiod_set_value_cansleep(data->gpiod, 1);
>>> +		msleep(data->config->toggle_time);
>>> +		gpiod_set_value_cansleep(data->gpiod, 0);
>>> +		msleep(data->config->toggle_time);
>>> +	}
>>> +	err = 0;
>>> +out:
>>> +	dev_dbg(data->dev, "Probed: err=%d\n", err);
>>> +	return err;
>>> +}
>>> +
>>> +static int spm_remove(struct device *dev)
>>> +{
>>> +       struct spm_data *data = dev_get_drvdata(dev);
>>> +
>>> +       if (data->rfkill) {
>>> +               rfkill_unregister(data->rfkill);
>>> +               rfkill_destroy(data->rfkill);
>>> +       }
>>> +       return 0;
>>> +}
>>> +
>>> +static struct device_driver spm_driver = {
>>> +	.name		= "serial-power-manager",
>>> +	.owner		= THIS_MODULE,
>>> +	.of_match_table	= spm_dt_ids,
>>> +	.probe		= spm_probe,
>>> +	.remove		= spm_remove,
>>> +};
>>> +
>>> +static int __init spm_init(void)
>>> +{
>>> +       return tty_slave_driver_register(&spm_driver);
>>> +}
>>> +module_init(spm_init);
>>> +
>>> +static void __exit spm_exit(void)
>>> +{
>>> +	driver_unregister(&spm_driver);
>>> +}
>>> +module_exit(spm_exit);
>>> +
>>> +MODULE_AUTHOR("NeilBrown <neil@brown.name>");
>>> +MODULE_DEVICE_TABLE(of, spm_dt_ids);
>>> +MODULE_DESCRIPTION("Power management for Serial-attached device.");
>>> +MODULE_LICENSE("GPL v2");
>>> 
>>> 
>>> _______________________________________________
>>> Gta04-owner mailing list
>>> Gta04-owner@goldelico.com
>>> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@suse.de>:

> On Fri, 20 Mar 2015 08:54:38 +0100 "Dr. H. Nikolaus Schaller"
> <hns@goldelico.com> wrote:
> 
>> 
>> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:
>> 
>>> If a platform has a particular device permanently attached to a UART,
>>> there may be out-of-band signaling necessary to power the device
>>> on and off.
>>> 
>>> This driver controls that signalling for a number of different devices.
>>> It can
>>> - enable/disable a regulator
>>> - toggle a GPIO
>>> - register an 'rfkill' which can force the device to be off.
>>> 
>>> When the rfkill is absent or unblocked, the device will be on when the
>>> associated tty device is open, and closed otherwise.
>>> 
>>> Signed-off-by: NeilBrown <neil@brown.name>
>>> ---
>>> .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
>>> .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
>>> .../devicetree/bindings/vendor-prefixes.txt        |    1 
>>> drivers/tty/slave/Kconfig                          |   14 +
>>> drivers/tty/slave/Makefile                         |    2 
>>> drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
>>> 6 files changed, 583 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> create mode 100644 drivers/tty/slave/serial-power-manager.c
>>> 
>>> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> new file mode 100644
>>> index 000000000000..cfe6ee5e01e9
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
>>> @@ -0,0 +1,19 @@
>>> +wi2wi bluetooth module
>>> +
>>> +This is accessed via a serial port and is largely controlled via that
>>> +link.  Extra configuration is needed to enable power on/off
>>> +
>>> +Required properties:
>>> +- compatible: "wi2wi,w2cbw003"
>>> +- vdd-supply: regulator used to power the device.
>>> +
>>> +The node for this device must be the child of a UART.
>>> +
>>> +Example:
>>> +
>>> +&uart1 {
>>> +       bluetooth {
>>> +               compatible = "wi2wi,w2cbw003";
>>> +               vdd-supply = <&vaux4>;
>>> +       };
>>> +};
>> 
>> Wouldn’t it be easier to simply write
>> 
>> &uart1 {
>> 	vdd-suppy = <&vaux4>;
>> }
> 
> Easier to write: certainly.
> Easier to justify? No.

I just justified.

> Easier to get merged upstream?  Definitely not.

Are you the maintainer?

> After all, the uart itself doesn't require a power supply.
> It is the device connected to the uart which requires the power supply.

Yes.

> 
> 
>> 
>>> diff --git a/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> new file mode 100644
>>> index 000000000000..fdc52cf56533
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
>>> @@ -0,0 +1,37 @@
>>> +wi2wi GPS device
>>> +
>>> +This is accessed via a serial port and is largely controlled via that
>>> +link.  Extra configuration is needed to enable power on/off
>>> +
>>> +Required properties:
>>> +- compatible: "wi2wi,w2sg0004"
>>> +- gpios: gpios used to toggle 'on/off' pin
>>> +- interrupts: interrupt generated by RX pin when device
>>> +      should be off
>>> +
>>> +Optional properties:
>>> +- vdd-supply: regulator used to power antenna
>>> +- pinctrl: "default", "off"
>>> +      if "off" setting is provided it is imposed when device should
>>> +      be off.  This can route the RX pin to a GPIO interrupt.
>>> +
>>> +The w2sg0004 uses a pin-toggle both to power-on and to
>>> +power-off, so the driver needs to detect what state it is in.
>>> +It does this by detecting characters on the RX line.
>>> +When it should be off, these can optionally be detected by a GPIO.
>>> +
>>> +The node for this device must be the child of a UART.
>>> +
>>> +Example:
>>> +&uart2 {
>>> +       gps {
>>> +               compatible = "wi2iw,w2sg0004";
>>> +               vdd-supply = <&vsim>;
>>> +               gpios = <&gpio5 17 0>; /* GPIO_145 */
>>> +               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
>>> +               /* When off, switch RX to be an interrupt */
>>> +               pinctrl-names = "default", "off";
>>> +               pinctrl-0 = <&uart2_pins>;
>>> +               pinctrl-1 = <&uart2_pins_rx_gpio>;
>>> +       };
>>> +};
>> 
>> If the wi2wi driver is a regulator driver one would write
>> 
>> / {
>>       gps-regulator: gps {
>>               compatible = "wi2iw,w2sg0004";
>>               vdd-supply = <&vsim>;
>>               gpios = <&gpio5 17 0>; /* GPIO_145 */
>>               interrupts-extended = <&gpio5 19 0>; /* GPIO_147 */
>>               /* When off, switch RX to be an interrupt */
>>               pinctrl-names = "default", "off";
>>               pinctrl-0 = <&uart2_pins>;
>>               pinctrl-1 = <&uart2_pins_rx_gpio>;
>>       };
>> }
>> 
>> &uart2 {
>> 	vdd-suppy = <&gps-regulator>;
>> };
>> 
>> Which IMHO better describes that the uart controls power of a separate driver.
> 
> But the uart doesn’t control the power.
> An 'open' on the tty causes one driver to turn on a regulator, and another
> driver to activate a uart so that the device represented by the tty can be
> communicated with.

Ok, that is a detail I have mixed up tty and uart.

> 
>> 
>> And this pattern for writing a DT would IMHO be more flexible because you
>> can „connect“ to any regulator, e.g. a regulator for a RS232 level shifter.
> 
> I'm sure there are lots of ways we could find to make DT more flexible, only
> then it wouldn't be DT any more - it would be something similar but different.
> 
> There needs to be one device-node for each device, and that device-node needs
> to be a child of the device-node for the device which is the primary
> connection to the child device.

Then please explain to me nodes like

/ {
	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";

	cpus {
		cpu@0 {
			cpu0-supply = <&vcc>;
		};
	};

According to the rule you apply here it should be something like

	cpu@0 {
		regulator {
			…
		}


>  That is how devicetree is structured - for
> better or worse.
> 
> 
> 
>> 
>> 
>>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> index 389ca1347a77..81d259303710 100644
>>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>>> @@ -189,6 +189,7 @@ variscite	Variscite Ltd.
>>> via	VIA Technologies, Inc.
>>> virtio	Virtual I/O Device Specification, developed by the OASIS consortium
>>> voipac	Voipac Technologies s.r.o.
>>> +wi2wi	wi2wi Inc.  http://www.wi2wi.com/
>>> winbond Winbond Electronics corp.
>>> wlf	Wolfson Microelectronics
>>> wm	Wondermedia Technologies, Inc.
>>> diff --git a/drivers/tty/slave/Kconfig b/drivers/tty/slave/Kconfig
>>> index 3976760c2e28..05c5d966ae57 100644
>>> --- a/drivers/tty/slave/Kconfig
>>> +++ b/drivers/tty/slave/Kconfig
>>> @@ -5,3 +5,17 @@ menuconfig TTY_SLAVE
>>> 	  Devices which attach via a uart, but need extra
>>> 	  driver support for power management etc.
>>> 
>>> +if TTY_SLAVE
>>> +
>>> +config SERIAL_POWER_MANAGER
>>> +	tristate "Power Management controller for serial-attached devices"
>>> +	default n
>>> +	help
>>> +	  Some devices permanently attached via a UART can benefit from
>>> +	  being power-managed when the tty device is opened or closed.
>>> +	  This driver can support several such devices with simple
>>> +	  power requirements such as enabling a regulator.
>>> +
>>> +	  If in doubt, say 'N'
>>> +
>>> +endif
>>> diff --git a/drivers/tty/slave/Makefile b/drivers/tty/slave/Makefile
>>> index 65669acb392e..a2f7d2847319 100644
>>> --- a/drivers/tty/slave/Makefile
>>> +++ b/drivers/tty/slave/Makefile
>>> @@ -1,2 +1,4 @@
>>> 
>>> obj-$(CONFIG_TTY_SLAVE) += tty_slave_core.o
>>> +
>>> +obj-$(CONFIG_SERIAL_POWER_MANAGER) += serial-power-manager.o
>>> diff --git a/drivers/tty/slave/serial-power-manager.c b/drivers/tty/slave/serial-power-manager.c
>>> new file mode 100644
>>> index 000000000000..662a526d8630
>>> --- /dev/null
>>> +++ b/drivers/tty/slave/serial-power-manager.c
>>> @@ -0,0 +1,510 @@
>>> +/*
>>> + * Serial-power-manager
>>> + * tty-slave device that intercepts open/close events on the tty,
>>> + * and turns power on/off for the device which is connected.
>>> + *
>>> + * Currently supported devices:
>>> + *  wi2wi,w2sg0004 - GPS with on/off toggle on a GPIO
>>> + *  wi2wi,w2cbw003 - bluetooth port; powered by regulator.
>>> + *
>>> + * When appropriate, an RFKILL will be registered which
>>> + * can power-down the device even when it is open.
>>> + *
>>> + * Device can be turned on either by
>>> + *  - enabling a regulator.  Disable to turn off
>>> + *  - toggling a GPIO.  Toggle again to turn off.  This requires
>>> + *     that we know the current state.  It is assumed to be 'off'
>>> + *     at boot, however if an interrupt can be generated when on,
>>> + *     such as by connecting RX to a GPIO, that can be used to detect
>>> + *     if the device is on when it should be off.
>> 
>> Why does this driver mix both things? 
>> 
>> The only thing they have in common is that both are uart slaves
>> and that they have a serial interface. But power control is very
>> different.
> 
> Because if I wrote two drivers, they would have more code in common than they
> would have differences.

I mostly can see the w2sg0004 part as an addition on top of a common boilerplate part.

> 
> 
>> 
>> One driver per fundamentally different chip...
>> 
>>> + */
>>> +
>>> +#include <linux/module.h>
>>> +#include <linux/slab.h>
>>> +#include <linux/err.h>
>>> +#include <linux/regulator/consumer.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/tty.h>
>>> +#include <linux/gpio.h>
>>> +#include <linux/of_gpio.h>
>>> +#include <linux/of_irq.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/delay.h>
>>> +#include <linux/rfkill.h>
>>> +
>>> +#include <linux/tty_slave.h>
>>> +
>>> +/* This is used for testing. Setting this module parameter
>>> + * will simulate booting with the device "on"
>>> + */
>>> +static bool toggle_on_probe = false;
>>> +module_param(toggle_on_probe, bool, 0);
>>> +MODULE_PARM_DESC(toggle_on_probe, "simulate power-on with devices active");
>>> +
>>> +struct spm_config {
>>> +	int	rfkill_type;		/* type of rfkill to register */
>>> +	int	toggle_time;		/* msec to pulse GPIO for on/off */
>>> +	int	toggle_gap;		/* min msecs between toggles */
>>> +	bool	off_in_suspend;
>>> +}
>>> +	simple_config = {
>>> +		.off_in_suspend = true,
>>> +	},
>>> +	w2sg_config = {
>>> +		.rfkill_type = RFKILL_TYPE_GPS,
>> 
>> The driver pretends to be generic by its name but incorporates a lot of specific
>> knowledge about the w2sg chip, e.g. that it is a GPS chip.
>> 
>>> +		.toggle_time = 10,
>>> +		.toggle_gap = 500,
>>> +		.off_in_suspend = true,
>>> +	};
>>> +
>>> +const static struct of_device_id spm_dt_ids[] = {
>>> +       { .compatible = "wi2wi,w2sg0004", .data = &w2sg_config},
>>> +       { .compatible = "wi2wi,w2cbw003", .data = &simple_config},
>> 
>> Well, how large will this table become if other uart slave device types
>> are added?
> 
> When that becomes a problem it can trivially be solved.  While it is not a
> problem there is no value in solving it.

thought-terminating argument?

> 
> 
>> 
>>> +       {}
>>> +};
>>> +
>>> +struct spm_data {
>>> +	const struct spm_config *config;
>>> +	struct gpio_desc *gpiod;
>>> +	int		irq;	/* irq line from RX pin when pinctrl
>>> +				 * set to 'idle' */
>>> +	struct regulator *reg;
>>> +
>>> +	unsigned long	toggle_time;
>>> +	unsigned long	toggle_gap;
>>> +	unsigned long	last_toggle;	/* jiffies when last toggle completed. */
>>> +	unsigned long	backoff;	/* jiffies since last_toggle when
>>> +					 * we try again
>>> +					 */
>>> +	enum {Idle, Down, Up} state;	/* state-machine state. */
>>> +
>>> +	int		open_cnt;
>>> +	bool		requested, is_on;
>>> +	bool		suspended;
>>> +	bool		reg_enabled;
>>> +
>>> +	struct pinctrl	*pins;
>>> +	struct pinctrl_state *pins_off;
>>> +
>>> +	struct delayed_work work;
>>> +	spinlock_t	lock;
>>> +	struct device	*dev;
>>> +
>>> +	struct rfkill	*rfkill;
>>> +
>>> +	int (*old_open)(struct tty_struct * tty, struct file * filp);
>>> +	void (*old_close)(struct tty_struct * tty, struct file * filp);
>>> +
>>> +};
>>> +
>>> +/* When a device is powered on/off by toggling a GPIO we perform
>>> + * all the toggling via a workqueue to ensure only one toggle happens
>>> + * at a time and to allow easy timing.
>>> + * This is managed as a state machine which transitions
>>> + *  Idle -> Down -> Up -> Idle
>>> + * The GPIO is held down for toggle_time and then up for toggle_time,
>>> + * and then we assume the device has changed state.
>>> + * We never toggle until at least toggle_gap has passed since the
>>> + * last toggle.
>>> + */
>>> +static void toggle_work(struct work_struct *work)
>>> +{
>>> +	struct spm_data *data = container_of(
>>> +		work, struct spm_data, work.work);
>>> +
>>> +	if (data->gpiod == NULL)
>>> +		return;
>>> +
>>> +	spin_lock_irq(&data->lock);
>>> +	switch (data->state) {
>>> +	case Up:
>>> +		data->state = Idle;
>>> +		if (data->requested == data->is_on)
>>> +			break;
>>> +		if (!data->requested)
>>> +			/* Assume it is off unless activity is detected */
>>> +			break;
>>> +		/* Try again in a while unless we get some activity */
>>> +		dev_dbg(data->dev, "Wait %dusec until retry\n",
>>> +			jiffies_to_msecs(data->backoff));
>>> +		schedule_delayed_work(&data->work, data->backoff);
>>> +		break;
>>> +	case Idle:
>>> +		if (data->requested == data->is_on)
>>> +			break;
>>> +
>>> +		/* Time to toggle */
>>> +		dev_dbg(data->dev, "Starting toggle to turn %s\n",
>>> +			data->requested ? "on" : "off");
>>> +		data->state = Down;
>>> +		spin_unlock_irq(&data->lock);
>>> +		gpiod_set_value_cansleep(data->gpiod, 1);
>>> +		schedule_delayed_work(&data->work, data->toggle_time);
>>> +
>>> +		return;
>>> +
>>> +	case Down:
>>> +		data->state = Up;
>>> +		data->last_toggle = jiffies;
>>> +		dev_dbg(data->dev, "Toggle completed, should be %s now.\n",
>>> +			data->is_on ? "off" : "on");
>>> +		data->is_on = ! data->is_on;
>>> +		spin_unlock_irq(&data->lock);
>>> +
>>> +		gpiod_set_value_cansleep(data->gpiod, 0);
>>> +		schedule_delayed_work(&data->work, data->toggle_time);
>>> +
>>> +		return;
>>> +	}
>>> +	spin_unlock_irq(&data->lock);
>>> +}
>>> +
>>> +static irqreturn_t spm_isr(int irq, void *dev_id)
>>> +{
>>> +	struct spm_data *data = dev_id;
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&data->lock, flags);
>>> +	if (!data->requested && !data->is_on && data->state == Idle &&
>>> +	    time_after(jiffies, data->last_toggle + data->backoff)) {
>>> +		data->is_on = 1;
>>> +		data->backoff *= 2;
>>> +		dev_dbg(data->dev, "Received data, must be on. Try to turn off\n");
>>> +		if (!data->suspended)
>>> +			schedule_delayed_work(&data->work, 0);
>>> +	}
>>> +	spin_unlock_irqrestore(&data->lock, flags);
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>> +static void spm_on(struct spm_data *data)
>>> +{
>>> +	if (!data->rfkill || !rfkill_blocked(data->rfkill)) {
>>> +		unsigned long flags;
>>> +
>>> +		if (!data->reg_enabled &&
>>> +		    data->reg &&
>>> +		    regulator_enable(data->reg) == 0)
>>> +			data->reg_enabled = true;
>>> +
>>> +		spin_lock_irqsave(&data->lock, flags);
>>> +		if (!data->requested) {
>>> +			dev_dbg(data->dev, "TTY open - turn device on\n");
>>> +			data->requested = true;
>>> +			data->backoff = data->toggle_gap;
>>> +			if (data->irq > 0) {
>>> +				disable_irq(data->irq);
>>> +				pinctrl_pm_select_default_state(data->dev);
>>> +			}
>>> +			if (!data->suspended && data->state == Idle)
>>> +				schedule_delayed_work(&data->work, 0);
>>> +		}
>>> +		spin_unlock_irqrestore(&data->lock, flags);
>>> +	}
>>> +}
>>> +
>>> +static int spm_open(struct tty_struct *tty, struct file *filp)
>>> +{
>>> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
>>> +
>>> +	data->open_cnt++;
>>> +	spm_on(data);
>>> +	if (data->old_open)
>>> +		return data->old_open(tty, filp);
>>> +}
>>> +
>>> +static void spm_off(struct spm_data *data)
>>> +{
>>> +	unsigned long flags;
>>> +
>>> +	if (data->reg && data->reg_enabled)
>>> +		if (regulator_disable(data->reg) == 0)
>>> +			data->reg_enabled = false;
>>> +
>>> +	spin_lock_irqsave(&data->lock, flags);
>>> +	if (data->requested) {
>>> +		data->requested = false;
>>> +		data->backoff = data->toggle_gap;
>>> +		if (data->pins_off) {
>>> +			pinctrl_select_state(data->pins,
>>> +					     data->pins_off);
>>> +			enable_irq(data->irq);
>>> +		}
>>> +		if (!data->suspended && data->state == Idle)
>>> +			schedule_delayed_work(&data->work, 0);
>>> +	}
>>> +	spin_unlock_irqrestore(&data->lock, flags);
>>> +}
>>> +
>>> +static void spm_close(struct tty_struct *tty, struct file *filp)
>>> +{
>>> +	struct spm_data *data = dev_get_drvdata(tty->dev->parent);
>>> +
>>> +	data->open_cnt--;
>>> +	if (!data->open_cnt) {
>>> +		dev_dbg(data->dev, "TTY closed - turn device off\n");
>>> +		spm_off(data);
>>> +	}
>>> +
>>> +	if (data->old_close)
>>> +		data->old_close(tty, filp);
>>> +}
>>> +
>>> +static int spm_rfkill_set_block(void *vdata, bool blocked)
>>> +{
>>> +	struct spm_data *data = vdata;
>>> +
>>> +	dev_dbg(data->dev, "rfkill_set_blocked %d\n", blocked);
>>> +	if (blocked)
>>> +		spm_off(data);
>>> +
>>> +	if (!blocked &&
>>> +	    data->open_cnt)
>>> +		spm_on(data);
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static struct rfkill_ops spm_rfkill_ops = {
>>> +	.set_block = spm_rfkill_set_block,
>>> +};
>>> +
>>> +static int spm_suspend(struct device *dev)
>>> +{
>>> +	/* Ignore incoming data and just turn device off.
>>> +	 * we cannot really wait for a separate thread to
>>> +	 * do things, so we disable that and do it all
>>> +	 * here
>>> +	 */
>>> +	struct spm_data *data = dev_get_drvdata(dev);
>>> +
>>> +	spin_lock_irq(&data->lock);
>>> +	data->suspended = true;
>>> +	spin_unlock_irq(&data->lock);
>>> +	if (!data->config->off_in_suspend)
>>> +		return 0;
>>> +
>>> +	if (data->gpiod) {
>>> +
>>> +		cancel_delayed_work_sync(&data->work);
>>> +		if (data->state == Down) {
>>> +			dev_dbg(data->dev, "Suspending while GPIO down - raising\n");
>>> +			msleep(data->config->toggle_time);
>>> +			gpiod_set_value_cansleep(data->gpiod, 0);
>>> +			data->last_toggle = jiffies;
>>> +			data->is_on = !data->is_on;
>>> +			data->state = Up;
>>> +		}
>>> +		if (data->state == Up) {
>>> +			msleep(data->config->toggle_time);
>>> +			data->state = Idle;
>>> +		}
>>> +		if (data->is_on) {
>>> +			dev_dbg(data->dev, "Suspending while device on: toggling\n");
>>> +			gpiod_set_value_cansleep(data->gpiod, 1);
>>> +			msleep(data->config->toggle_time);
>>> +			gpiod_set_value_cansleep(data->gpiod, 0);
>>> +			data->is_on = 0;
>>> +		}
>>> +	}
>>> +
>>> +	if (data->reg && data->reg_enabled)
>>> +		if (regulator_disable(data->reg) == 0)
>>> +			data->reg_enabled = false;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int spm_resume(struct device *dev)
>>> +{
>>> +	struct spm_data *data = dev_get_drvdata(dev);
>>> +
>>> +	spin_lock_irq(&data->lock);
>>> +	data->suspended = false;
>>> +	spin_unlock_irq(&data->lock);
>>> +	schedule_delayed_work(&data->work, 0);
>>> +
>>> +	if (data->open_cnt &&
>>> +	    (!data->rfkill || !rfkill_blocked(data->rfkill))) {
>>> +		if (!data->reg_enabled &&
>>> +		    data->reg &&
>>> +		    regulator_enable(data->reg) == 0)
>>> +			data->reg_enabled = true;
>>> +	}
>>> +	return 0;
>>> +}
>>> +
>>> +static const struct dev_pm_ops spm_pm_ops = {
>>> +	SET_SYSTEM_SLEEP_PM_OPS(spm_suspend, spm_resume)
>>> +};
>>> +
>>> +static int spm_probe(struct device *dev)
>>> +{
>>> +	struct tty_slave *slave = container_of(dev, struct tty_slave, dev);
>>> +	struct spm_data *data;
>>> +	struct regulator *reg;
>>> +	int err;
>>> +	const struct of_device_id *id;
>>> +	const char *name;
>>> +
>>> +	if (dev->parent == NULL)
>>> +		return -ENODEV;
>>> +
>>> +	id = of_match_device(spm_dt_ids, dev);
>>> +	if (!id)
>>> +		return -ENODEV;
>>> +
>>> +	if (dev->of_node && dev->of_node->name)
>>> +		name = dev->of_node->name;
>>> +	else
>>> +		name = "serial-power-manager";
>>> +
>>> +	data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>>> +	if (!data)
>>> +		return -ENOMEM;
>>> +
>>> +	data->config = id->data;
>>> +	data->toggle_time = msecs_to_jiffies(data->config->toggle_time) + 1;
>>> +	data->toggle_gap = msecs_to_jiffies(data->config->toggle_gap) + 1;
>>> +	data->last_toggle = jiffies;
>>> +	data->backoff = data->toggle_gap;
>>> +	data->state = Idle;
>>> +	spin_lock_init(&data->lock);
>>> +	INIT_DELAYED_WORK(&data->work, toggle_work);
>>> +
>>> +	/* If a regulator is provided, it is enabled on 'open'
>>> +	 * and disabled on 'release'
>>> +	 */
>>> +	reg = devm_regulator_get(dev, "vdd");
>>> +	if (IS_ERR(reg)) {
>>> +		err = PTR_ERR(reg);
>>> +		if (err != -ENODEV)
>>> +			goto out;
>>> +	} else
>>> +		data->reg = reg;
>>> +
>>> +	/* If an irq is provided, any transitions are taken as
>>> +	 * indication that the device is currently "on"
>>> +	 */
>>> +	data->irq = of_irq_get(dev->of_node, 0);
>>> +	if (data->irq < 0) {
>>> +		err = data->irq;
>>> +		if (err != -EINVAL)
>>> +			goto out;
>>> +	} else {
>>> +		dev_dbg(dev, "IRQ configured: %d\n", data->irq);
>>> +
>>> +		irq_set_status_flags(data->irq, IRQ_NOAUTOEN);
>>> +		err = devm_request_irq(dev, data->irq, spm_isr,
>>> +				       IRQF_TRIGGER_FALLING,
>>> +				       name, data);
>>> +
>>> +		if (err)
>>> +			goto out;
>>> +
>>> +	}
>> 
>> Up to here it is generic and makes no assumptions about a specific
>> device.
>> 
>>> +
>>> +	/* If a gpio is provided, then it is used to turn the device
>>> +	 * on/off.
>> 
>> You have a compatible record (for two well defined chips), but you
>> do control which functions are really used by providing/not providing
>> some DT parameters.
>> 
>> Either one is redundant.
>> 
>>> +	 * If toggle_time is zero, then the GPIO directly controls
>>> +	 * the device.
>> 
>> Very hidden and non-obvoius functionality.
> 
> Yes, that should probably be documented more clearly, or removed.
> 
> 
>> 
>>> If non-zero, then the GPIO must be toggled to
>>> +	 * change the state of the device.
>> 
>> All the following is very special logic for the w2sg0004 chip which should be
>> divided out into a separate driver.
>> 
>> Marek and me already had proposed such a chip specific driver (to be located
>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>> specific and present itself as a regulator (because that is its main purpose:
>> control the LDO regulator inside the w2sg0004 chip).
> 
> Presenting itself as a regulator would be wrong because it isn’t a regulator.

It has a regulator that can be controlled by a gpio…

Another example to think about: the twl4030 is also not a regulator.
Nevertheless they present some regulator nodes.

Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
but has an internal pbias_regulator that needs to be controlled.

BR,
Nikolaus

> 
> 
> Thanks,
> NeilBrown
> 
> 
>> 
>> We can resubmit it as soon as this driver stabilizes and finds acceptance.
>> 
>>> +	 */
>>> +	data->gpiod = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
>>> +	if (IS_ERR(data->gpiod)) {
>>> +		err = PTR_ERR(data->gpiod);
>>> +		if (err != -ENOENT)
>>> +			goto out;
>>> +		data->gpiod = NULL;
>>> +	} else
>>> +		dev_dbg(dev, "GPIO configured: %d\n",
>>> +			desc_to_gpio(data->gpiod));
>>> +
>>> +	/* If an 'off' pinctrl state is defined, we apply that
>>> +	 * when the device is assumed to be off.  This is expected to
>>> +	 * route the 'rx' line to the 'irq' interrupt.
>>> +	 */
>>> +	data->pins = devm_pinctrl_get(dev);
>>> +	if (data->pins && data->irq > 0) {
>>> +		data->pins_off = pinctrl_lookup_state(data->pins, "off");
>>> +		if (IS_ERR(data->pins_off))
>>> +			data->pins_off = NULL;
>>> +	}
>>> +
>>> +	if (data->config->rfkill_type) {
>>> +		data->rfkill = rfkill_alloc(name, dev,
>>> +					    data->config->rfkill_type,
>>> +					    &spm_rfkill_ops, data);
>>> +		if (!data->rfkill) {
>>> +			err = -ENOMEM;
>>> +			goto out;
>>> +		}
>>> +		err = rfkill_register(data->rfkill);
>>> +		if (err) {
>>> +			dev_err(dev, "Cannot register rfkill device");
>>> +			rfkill_destroy(data->rfkill);
>>> +			goto out;
>>> +		}
>>> +	}
>>> +	dev_set_drvdata(dev, data);
>>> +	data->dev = dev;
>>> +	data->old_open = slave->ops.open;
>>> +	data->old_close = slave->ops.close;
>>> +	slave->ops.open = spm_open;
>>> +	slave->ops.close = spm_close;
>>> +	tty_slave_finalize(slave);
>>> +
>>> +	if (data->pins_off)
>>> +		pinctrl_select_state(data->pins, data->pins_off);
>>> +	if (data->irq > 0)
>>> +		enable_irq(data->irq);
>>> +
>>> +	if (toggle_on_probe && data->gpiod) {
>>> +		dev_dbg(data->dev, "Performing initial toggle\n");
>>> +		gpiod_set_value_cansleep(data->gpiod, 1);
>>> +		msleep(data->config->toggle_time);
>>> +		gpiod_set_value_cansleep(data->gpiod, 0);
>>> +		msleep(data->config->toggle_time);
>>> +	}
>>> +	err = 0;
>>> +out:
>>> +	dev_dbg(data->dev, "Probed: err=%d\n", err);
>>> +	return err;
>>> +}
>>> +
>>> +static int spm_remove(struct device *dev)
>>> +{
>>> +       struct spm_data *data = dev_get_drvdata(dev);
>>> +
>>> +       if (data->rfkill) {
>>> +               rfkill_unregister(data->rfkill);
>>> +               rfkill_destroy(data->rfkill);
>>> +       }
>>> +       return 0;
>>> +}
>>> +
>>> +static struct device_driver spm_driver = {
>>> +	.name		= "serial-power-manager",
>>> +	.owner		= THIS_MODULE,
>>> +	.of_match_table	= spm_dt_ids,
>>> +	.probe		= spm_probe,
>>> +	.remove		= spm_remove,
>>> +};
>>> +
>>> +static int __init spm_init(void)
>>> +{
>>> +       return tty_slave_driver_register(&spm_driver);
>>> +}
>>> +module_init(spm_init);
>>> +
>>> +static void __exit spm_exit(void)
>>> +{
>>> +	driver_unregister(&spm_driver);
>>> +}
>>> +module_exit(spm_exit);
>>> +
>>> +MODULE_AUTHOR("NeilBrown <neil@brown.name>");
>>> +MODULE_DEVICE_TABLE(of, spm_dt_ids);
>>> +MODULE_DESCRIPTION("Power management for Serial-attached device.");
>>> +MODULE_LICENSE("GPL v2");
>>> 
>>> 
>>> _______________________________________________
>>> Gta04-owner mailing list
>>> Gta04-owner@goldelico.com
>>> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> 
> >> Wouldn’t it be easier to simply write
> >> 
> >> &uart1 {
> >> 	vdd-suppy = <&vaux4>;
> >> }
> > 
> > Easier to write: certainly.
> > Easier to justify? No.
> 
> I just justified.
> 
> > Easier to get merged upstream?  Definitely not.
> 
> Are you the maintainer?

And you? I believe Neil is right here, and this kind of shortcut can
not be taken.

> > After all, the uart itself doesn't require a power supply.
> > It is the device connected to the uart which requires the power supply.
> 
> Yes.

There's UART, long rs/232 cable, and a GPS.

UART needs some kind of power supply, to present voltages on the
rs/232 cable.

GPS needs some kind of power supply to work.

They are different power supplies, and we should have way to tell them
apart.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> 
> >> Wouldn’t it be easier to simply write
> >> 
> >> &uart1 {
> >> 	vdd-suppy = <&vaux4>;
> >> }
> > 
> > Easier to write: certainly.
> > Easier to justify? No.
> 
> I just justified.
> 
> > Easier to get merged upstream?  Definitely not.
> 
> Are you the maintainer?

And you? I believe Neil is right here, and this kind of shortcut can
not be taken.

> > After all, the uart itself doesn't require a power supply.
> > It is the device connected to the uart which requires the power supply.
> 
> Yes.

There's UART, long rs/232 cable, and a GPS.

UART needs some kind of power supply, to present voltages on the
rs/232 cable.

GPS needs some kind of power supply to work.

They are different power supplies, and we should have way to tell them
apart.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 5816 bytes --]

On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
<hns@goldelico.com> wrote:

> 
> Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@suse.de>:

> > There needs to be one device-node for each device, and that device-node needs
> > to be a child of the device-node for the device which is the primary
> > connection to the child device.
> 
> Then please explain to me nodes like
> 
> / {
> 	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
> 
> 	cpus {
> 		cpu@0 {
> 			cpu0-supply = <&vcc>;
> 		};
> 	};
> 
> According to the rule you apply here it should be something like
> 
> 	cpu@0 {
> 		regulator {
> 			…
> 		}
> 
> 

This exactly highlight one of the big problems with device tree as I see it.

Each device can potentially have relationships with a number of other
devices, for the supply of power, reset signalling, interrupt handled, data
transfer, command transfer etc etc etc.

devicetree provides two ways to indicated a relationship between devices.
One way is a parent/child arrangement.  The other way is ad-hoc
   attribute = <&devicename>
assignments.

Each device can only have one parent, but can have multiple arbitrary
assignments.

I would much rather that the parent/child relationship didn't exist at all.
Each device should stand alone, and list all relationships explicitly.  But
that is not the way devicetree works, and we need to live with that.

So we need a clear understanding of what the 'parent' of a given device
should be.
I don't know what the specifications say, if anything, but what I see is that
the parent is in practive a device which can 'address' the child.  i.e.
control signalling is the key parent->child relationship.
This is consistent with the fact that many device nodes have a 
		reg=<xxx>
attribute which gives the address of the node as seen by it's parent.

Given that understanding, a regulator must be a child of the device which can
control it - which can turn it on or off.  Not a child of the device which
receives power from it.

In the case of our GPS, it receives control over the serial connection from
the UART, also receives control via a GPIO to the on/off pin, and also needs
a regulator to power the antenna.

So should the parent be the uart, the on/off GPIO, or the regulator?

I would much rather there wasn't a parent, and that each of these were listed
as ad-hoc attribute assignments.  But device-tree says there must be a parent
(where possible), and the parent is the thing that is "primarily" in control.

I think the GPS is "primarily" a uart-attached device.
So I propose a device-node which describes the GPS, which is a child of the
UART, and explicitly identifies the GPIO it uses to power on/off, the
regulator it uses to power the antenna, and how it receives "on or off"
status indications from the GPS.

It is arguable that the "antenna" should be treated as a separate device - a
child of the GPS - which controls the regulator and also provides a 'extcon'
which reports whether an external GPS antenna is attached, or whether the
internal on is in use.  I haven't made the time to properly explore that
issue yet.

> >> 
> >> All the following is very special logic for the w2sg0004 chip which should be
> >> divided out into a separate driver.
> >> 
> >> Marek and me already had proposed such a chip specific driver (to be located
> >> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >> specific and present itself as a regulator (because that is its main purpose:
> >> control the LDO regulator inside the w2sg0004 chip).
> > 
> > Presenting itself as a regulator would be wrong because it isn’t a regulator.
> 
> It has a regulator that can be controlled by a gpio…

Does it?  I guess may it does.
Maybe it also has an ARM core and some memory and assorted other bits and
pieces.  But we don't really need to describe them to device tree.

The w2sg0004 is primarily a GPS device, so that needs to be stated in the
devices tree description.  If there are subcomponents that can usefully be
described as well then there could be a place to describe those subcomponents.
I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
1V8 source based on its 3V3 input.  If a board made use of that, it could be
useful to describe the regulator inside the GPS so it could be declare that
some other device which needed 1V8 made use of that regulator....

> 
> Another example to think about: the twl4030 is also not a regulator.
> Nevertheless they present some regulator nodes.

The TWL4030 is a multifunction device which contains regulators and GPIOs and
audio codec and  USB PHY etc etc etc.

So in device-tree there is a device-node for the TWL4030, and it has
child-nodes for each sub-device.   They in turn can provide services to other
devices on the board.
These sub-devices are much more independent of the whole than the regulator
inside the w2sg0004 is.

> 
> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> but has an internal pbias_regulator that needs to be controlled.

I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
device which contains a CPU and multiple other controllers and  communicators
and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
it has a device-node which is a child of the 'ocp' node - which is the main
interconnect in the OMAP3 I think.

So I'm not against describing the regulator in the w2sg0004, but for
consistency with everything else, it would need to be child-node of a
device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
that would gain anything.


Thanks,
NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 5816 bytes --]

On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
<hns@goldelico.com> wrote:

> 
> Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@suse.de>:

> > There needs to be one device-node for each device, and that device-node needs
> > to be a child of the device-node for the device which is the primary
> > connection to the child device.
> 
> Then please explain to me nodes like
> 
> / {
> 	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
> 
> 	cpus {
> 		cpu@0 {
> 			cpu0-supply = <&vcc>;
> 		};
> 	};
> 
> According to the rule you apply here it should be something like
> 
> 	cpu@0 {
> 		regulator {
> 			…
> 		}
> 
> 

This exactly highlight one of the big problems with device tree as I see it.

Each device can potentially have relationships with a number of other
devices, for the supply of power, reset signalling, interrupt handled, data
transfer, command transfer etc etc etc.

devicetree provides two ways to indicated a relationship between devices.
One way is a parent/child arrangement.  The other way is ad-hoc
   attribute = <&devicename>
assignments.

Each device can only have one parent, but can have multiple arbitrary
assignments.

I would much rather that the parent/child relationship didn't exist at all.
Each device should stand alone, and list all relationships explicitly.  But
that is not the way devicetree works, and we need to live with that.

So we need a clear understanding of what the 'parent' of a given device
should be.
I don't know what the specifications say, if anything, but what I see is that
the parent is in practive a device which can 'address' the child.  i.e.
control signalling is the key parent->child relationship.
This is consistent with the fact that many device nodes have a 
		reg=<xxx>
attribute which gives the address of the node as seen by it's parent.

Given that understanding, a regulator must be a child of the device which can
control it - which can turn it on or off.  Not a child of the device which
receives power from it.

In the case of our GPS, it receives control over the serial connection from
the UART, also receives control via a GPIO to the on/off pin, and also needs
a regulator to power the antenna.

So should the parent be the uart, the on/off GPIO, or the regulator?

I would much rather there wasn't a parent, and that each of these were listed
as ad-hoc attribute assignments.  But device-tree says there must be a parent
(where possible), and the parent is the thing that is "primarily" in control.

I think the GPS is "primarily" a uart-attached device.
So I propose a device-node which describes the GPS, which is a child of the
UART, and explicitly identifies the GPIO it uses to power on/off, the
regulator it uses to power the antenna, and how it receives "on or off"
status indications from the GPS.

It is arguable that the "antenna" should be treated as a separate device - a
child of the GPS - which controls the regulator and also provides a 'extcon'
which reports whether an external GPS antenna is attached, or whether the
internal on is in use.  I haven't made the time to properly explore that
issue yet.

> >> 
> >> All the following is very special logic for the w2sg0004 chip which should be
> >> divided out into a separate driver.
> >> 
> >> Marek and me already had proposed such a chip specific driver (to be located
> >> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >> specific and present itself as a regulator (because that is its main purpose:
> >> control the LDO regulator inside the w2sg0004 chip).
> > 
> > Presenting itself as a regulator would be wrong because it isn’t a regulator.
> 
> It has a regulator that can be controlled by a gpio…

Does it?  I guess may it does.
Maybe it also has an ARM core and some memory and assorted other bits and
pieces.  But we don't really need to describe them to device tree.

The w2sg0004 is primarily a GPS device, so that needs to be stated in the
devices tree description.  If there are subcomponents that can usefully be
described as well then there could be a place to describe those subcomponents.
I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
1V8 source based on its 3V3 input.  If a board made use of that, it could be
useful to describe the regulator inside the GPS so it could be declare that
some other device which needed 1V8 made use of that regulator....

> 
> Another example to think about: the twl4030 is also not a regulator.
> Nevertheless they present some regulator nodes.

The TWL4030 is a multifunction device which contains regulators and GPIOs and
audio codec and  USB PHY etc etc etc.

So in device-tree there is a device-node for the TWL4030, and it has
child-nodes for each sub-device.   They in turn can provide services to other
devices on the board.
These sub-devices are much more independent of the whole than the regulator
inside the w2sg0004 is.

> 
> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> but has an internal pbias_regulator that needs to be controlled.

I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
device which contains a CPU and multiple other controllers and  communicators
and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
it has a device-node which is a child of the 'ocp' node - which is the main
interconnect in the OMAP3 I think.

So I'm not against describing the regulator in the w2sg0004, but for
consistency with everything else, it would need to be child-node of a
device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
that would gain anything.


Thanks,
NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 21.03.2015 um 00:31 schrieb NeilBrown <neilb@suse.de>:

> On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
> <hns@goldelico.com> wrote:
> 
>> 
>> Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@suse.de>:
> 
>>> There needs to be one device-node for each device, and that device-node needs
>>> to be a child of the device-node for the device which is the primary
>>> connection to the child device.
>> 
>> Then please explain to me nodes like
>> 
>> / {
>> 	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
>> 
>> 	cpus {
>> 		cpu@0 {
>> 			cpu0-supply = <&vcc>;
>> 		};
>> 	};
>> 
>> According to the rule you apply here it should be something like
>> 
>> 	cpu@0 {
>> 		regulator {
>> 			…
>> 		}
>> 
>> 
> 
> This exactly highlight one of the big problems with device tree as I see it.
> 
> Each device can potentially have relationships with a number of other
> devices, for the supply of power, reset signalling, interrupt handled, data
> transfer, command transfer etc etc etc.

Yes. The network is a mesh.

> 
> devicetree provides two ways to indicated a relationship between devices.
> One way is a parent/child arrangement.  The other way is ad-hoc
>   attribute = <&devicename>
> assignments.

Yes.

> 
> Each device can only have one parent, but can have multiple arbitrary
> assignments.
> 
> I would much rather that the parent/child relationship didn't exist at all.
> Each device should stand alone, and list all relationships explicitly.  But
> that is not the way devicetree works, and we need to live with that.

Is it not how the device tree works or how we use it? Or how you think it
should better be?

What stops us from using it in arbitrary assignments like clocks and
regulators?

GPIOs are also a nice example: you just specify the gpio controller
and the gpio number to use it. There is no parent/child connection.

Why for tty / serial and serial consumers but not for GPIOs?

I have tried to find out the rules when parent>child is used (see below).

> 
> So we need a clear understanding of what the 'parent' of a given device
> should be.
> I don't know what the specifications say, if anything, but what I see is that
> the parent is in practive a device which can ‘address' the child.  

I think this holds only for “bus” devices - where it is really a good and
standard way of structuring the bus and it’s masters/slaves. One child
node per client.

> i.e.
> control signalling is the key parent->child relationship.
> This is consistent with the fact that many device nodes have a 
> 		reg=<xxx>
> attribute which gives the address of the node as seen by it's parent.
> 
> Given that understanding, a regulator must be a child of the device which can
> control it - which can turn it on or off.  Not a child of the device which
> receives power from it.

So you propose that the parent->child relationship is “control”? I.e. some
channel which allows to address some bus client (through <reg>) and
control that devices.

Makes sense. This is how i2c and spi clients are specified.

> 
> In the case of our GPS, it receives control over the serial connection from
> the UART,

Ahem - does it?

AFAIK the chip simply starts to emit NMEA records if powered on. There is no
command going over the serial interface to address it or control it.

> also receives control via a GPIO to the on/off pin, and also needs
> a regulator to power the antenna.
> 
> So should the parent be the uart, the on/off GPIO, or the regulator?
> 
> I would much rather there wasn't a parent, and that each of these were listed
> as ad-hoc attribute assignments.  But device-tree says there must be a parent
> (where possible), and the parent is the thing that is “primarily" in control.

Well, IMHO the “parent” could also be the root. Representing the whole board.

Nevertheless, I doubt your rule that “ability to control” defines the parent>child
relation (see below).

> 
> I think the GPS is “primarily" a uart-attached device.

But not in the same way as an I2C device.

Especially the serial interface is not a bus and not used for signalling and
power control. It is payload data (only).

> So I propose a device-node which describes the GPS, which is a child of the
> UART, and explicitly identifies the GPIO it uses to power on/off, the
> regulator it uses to power the antenna, and how it receives "on or off"
> status indications from the GPS.

The more I think about that, you have given good arguments *not* to use the
parent->child relationship for the UART interface of the GPS.

Let me give another example. The 3G Modem has 3 (or 4) interfaces:
1. an USB-Interface for AT signalling and payload
2. some GPIOs for power control.
3. a PCM interface for digital voice. 
4. it might also have a serial interface as alternate AT command and (GPRS
    low speed) payload.

So which one is the most prominent or most important to make it a child of?

If you use “control” you must make it a child of the USB phy and the serial interface
which requires multiple inheritance…

So I am not sure at all. None is IMHO prominent and unique enough to make it
a parent>child relation.

Threrefore, I would be happy to see it as multiple children of /. For example a
MFD with subnodes.

> 
> It is arguable that the "antenna" should be treated as a separate device - a
> child of the GPS - which controls the regulator and also provides a 'extcon'
> which reports whether an external GPS antenna is attached, or whether the
> internal on is in use.  I haven't made the time to properly explore that
> issue yet.

If you assume that parent>child relationship is about control (only). But if it
is about data flow, there is a different concept in DT. For example the CSI/DSI
(OMAP DSS) use the “port” concept. This means that indeed parent>child is
used for control, e.g. I2C or SPI to tell the panel controller to switch on.

For example we have the GTA04 panel as a subnode of SPI (because SPI is a
bus and the panel is controlled through SPI). Other panels need no control
interface and are simply a child of /.

The video stream and its connections are arranged through such ports.
For the video out management we have added our OPA362 video amplifier into
that video pipeline which starts at the VENC (Video encode) in the SoC,
goes through the OPA362 and ends in the connector (which has its own
node). All this is connected by references. The opa362 node itself is a child
of /: 

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98

So to summarize I now see exactly two cases where parent>child is used:
a) for components of an aggregate device (OMAP3 > I2C controllers)
b) for components connected to a bus controller (I2C > TWL4030)

Since the twl regulators are components of the twl chip it completely explains
why we see

omap3 > i2c > twl4030 > vaux4

Everything else is done by references. Therefore we see references for
* gpios within a controller (independently of it’s relation on a bus)
* regulators
* clocks
* any function that is not connected by a bus

There is no need (and practice) to squeeze everything into a parent > child
relationship. And I can’t see your “control” or a “main interface” rule.

At least this is my (a little limited) view from using and programming DT for
multiple boards.

Maybe this is what the DT list should comment or show a clear definition when
parent>child relations are wanted and when not.


Now back to the GPS chip connected to an UART.

Is it
a) a component of an aggregate device? no
b) is it connected to a bus (i2c, spi, address bus)? no

This comes back to the question if UART is a bus.

I still think that it is NOT a bus and therefore it should not be modeled in DT
like busses are (enforcing clients to become subnodes).

The reason is there no well defined protocol to make multiple clients and
you can’t specify a <reg>.

So you are either abusing the notion of a bus or the gps chip must be a separate
DT node (child of something else).

I hope my gut feeling that we are trying to do something fundamentally wrong
with making the gps chip a subode of serial is now argued a little better.

For making the serial device control some regulator through a reference to
a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.

> 
>>>> 
>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>> divided out into a separate driver.
>>>> 
>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>> specific and present itself as a regulator (because that is its main purpose:
>>>> control the LDO regulator inside the w2sg0004 chip).
>>> 
>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>> 
>> It has a regulator that can be controlled by a gpio…
> 
> Does it?  I guess may it does.
> Maybe it also has an ARM core and some memory and assorted other bits and
> pieces.  But we don’t really need to describe them to device tree.

Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.

Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
connected to a GPIO - would tell if the module is really active or not. Using this would
make monitoring the RX line through different pinmux states obsolete.

But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
not wired the WAKEUP line to a  GPIO.

> 
> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> devices tree description.  If there are subcomponents that can usefully be
> described as well then there could be a place to describe those subcomponents.
> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> useful to describe the regulator inside the GPS so it could be declare that
> some other device which needed 1V8 made use of that regulator….

Yes. Well, even if *we* do not use it in this way yet, we should not make it
difficult for others to do by enforcing the wrong description.

> 
>> 
>> Another example to think about: the twl4030 is also not a regulator.
>> Nevertheless they present some regulator nodes.
> 
> The TWL4030 is a multifunction device which contains regulators and GPIOs and
> audio codec and  USB PHY etc etc etc.
> 
> So in device-tree there is a device-node for the TWL4030, and it has
> child-nodes for each sub-device.   They in turn can provide services to other
> devices on the board.

Exactly as discussed above. And there, the parent>child relation for the twl4030
and its subdevices is right.

> These sub-devices are much more independent of the whole than the regulator
> inside the w2sg0004 is.

Hm. That is probably argueable as well. At least a vague ciriterion.

> 
>> 
>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>> but has an internal pbias_regulator that needs to be controlled.
> 
> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> device which contains a CPU and multiple other controllers and  communicators
> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> it has a device-node which is a child of the 'ocp' node - which is the main
> interconnect in the OMAP3 I think.
> 
> So I'm not against describing the regulator in the w2sg0004, but for
> consistency with everything else, it would need to be child-node of a
> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> that would gain anything.

Well, it would gain consistency how chips with multiple components inside
are described.

And would make it easier to see the whole w2sg0004 a child of /.

But then we need some reference from your tty/serial driver to that w2sg node.

> 
> 
> Thanks,
> NeilBrown

Thanks as well,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 21.03.2015 um 00:31 schrieb NeilBrown <neilb@suse.de>:

> On Fri, 20 Mar 2015 10:34:18 +0100 "Dr. H. Nikolaus Schaller"
> <hns@goldelico.com> wrote:
> 
>> 
>> Am 20.03.2015 um 09:54 schrieb NeilBrown <neilb@suse.de>:
> 
>>> There needs to be one device-node for each device, and that device-node needs
>>> to be a child of the device-node for the device which is the primary
>>> connection to the child device.
>> 
>> Then please explain to me nodes like
>> 
>> / {
>> 	compatible = "ti,omap3-gta04", "ti,omap36xx", "ti,omap3";
>> 
>> 	cpus {
>> 		cpu@0 {
>> 			cpu0-supply = <&vcc>;
>> 		};
>> 	};
>> 
>> According to the rule you apply here it should be something like
>> 
>> 	cpu@0 {
>> 		regulator {
>> 			…
>> 		}
>> 
>> 
> 
> This exactly highlight one of the big problems with device tree as I see it.
> 
> Each device can potentially have relationships with a number of other
> devices, for the supply of power, reset signalling, interrupt handled, data
> transfer, command transfer etc etc etc.

Yes. The network is a mesh.

> 
> devicetree provides two ways to indicated a relationship between devices.
> One way is a parent/child arrangement.  The other way is ad-hoc
>   attribute = <&devicename>
> assignments.

Yes.

> 
> Each device can only have one parent, but can have multiple arbitrary
> assignments.
> 
> I would much rather that the parent/child relationship didn't exist at all.
> Each device should stand alone, and list all relationships explicitly.  But
> that is not the way devicetree works, and we need to live with that.

Is it not how the device tree works or how we use it? Or how you think it
should better be?

What stops us from using it in arbitrary assignments like clocks and
regulators?

GPIOs are also a nice example: you just specify the gpio controller
and the gpio number to use it. There is no parent/child connection.

Why for tty / serial and serial consumers but not for GPIOs?

I have tried to find out the rules when parent>child is used (see below).

> 
> So we need a clear understanding of what the 'parent' of a given device
> should be.
> I don't know what the specifications say, if anything, but what I see is that
> the parent is in practive a device which can ‘address' the child.  

I think this holds only for “bus” devices - where it is really a good and
standard way of structuring the bus and it’s masters/slaves. One child
node per client.

> i.e.
> control signalling is the key parent->child relationship.
> This is consistent with the fact that many device nodes have a 
> 		reg=<xxx>
> attribute which gives the address of the node as seen by it's parent.
> 
> Given that understanding, a regulator must be a child of the device which can
> control it - which can turn it on or off.  Not a child of the device which
> receives power from it.

So you propose that the parent->child relationship is “control”? I.e. some
channel which allows to address some bus client (through <reg>) and
control that devices.

Makes sense. This is how i2c and spi clients are specified.

> 
> In the case of our GPS, it receives control over the serial connection from
> the UART,

Ahem - does it?

AFAIK the chip simply starts to emit NMEA records if powered on. There is no
command going over the serial interface to address it or control it.

> also receives control via a GPIO to the on/off pin, and also needs
> a regulator to power the antenna.
> 
> So should the parent be the uart, the on/off GPIO, or the regulator?
> 
> I would much rather there wasn't a parent, and that each of these were listed
> as ad-hoc attribute assignments.  But device-tree says there must be a parent
> (where possible), and the parent is the thing that is “primarily" in control.

Well, IMHO the “parent” could also be the root. Representing the whole board.

Nevertheless, I doubt your rule that “ability to control” defines the parent>child
relation (see below).

> 
> I think the GPS is “primarily" a uart-attached device.

But not in the same way as an I2C device.

Especially the serial interface is not a bus and not used for signalling and
power control. It is payload data (only).

> So I propose a device-node which describes the GPS, which is a child of the
> UART, and explicitly identifies the GPIO it uses to power on/off, the
> regulator it uses to power the antenna, and how it receives "on or off"
> status indications from the GPS.

The more I think about that, you have given good arguments *not* to use the
parent->child relationship for the UART interface of the GPS.

Let me give another example. The 3G Modem has 3 (or 4) interfaces:
1. an USB-Interface for AT signalling and payload
2. some GPIOs for power control.
3. a PCM interface for digital voice. 
4. it might also have a serial interface as alternate AT command and (GPRS
    low speed) payload.

So which one is the most prominent or most important to make it a child of?

If you use “control” you must make it a child of the USB phy and the serial interface
which requires multiple inheritance…

So I am not sure at all. None is IMHO prominent and unique enough to make it
a parent>child relation.

Threrefore, I would be happy to see it as multiple children of /. For example a
MFD with subnodes.

> 
> It is arguable that the "antenna" should be treated as a separate device - a
> child of the GPS - which controls the regulator and also provides a 'extcon'
> which reports whether an external GPS antenna is attached, or whether the
> internal on is in use.  I haven't made the time to properly explore that
> issue yet.

If you assume that parent>child relationship is about control (only). But if it
is about data flow, there is a different concept in DT. For example the CSI/DSI
(OMAP DSS) use the “port” concept. This means that indeed parent>child is
used for control, e.g. I2C or SPI to tell the panel controller to switch on.

For example we have the GTA04 panel as a subnode of SPI (because SPI is a
bus and the panel is controlled through SPI). Other panels need no control
interface and are simply a child of /.

The video stream and its connections are arranged through such ports.
For the video out management we have added our OPA362 video amplifier into
that video pipeline which starts at the VENC (Video encode) in the SoC,
goes through the OPA362 and ends in the connector (which has its own
node). All this is connected by references. The opa362 node itself is a child
of /: 

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98

So to summarize I now see exactly two cases where parent>child is used:
a) for components of an aggregate device (OMAP3 > I2C controllers)
b) for components connected to a bus controller (I2C > TWL4030)

Since the twl regulators are components of the twl chip it completely explains
why we see

omap3 > i2c > twl4030 > vaux4

Everything else is done by references. Therefore we see references for
* gpios within a controller (independently of it’s relation on a bus)
* regulators
* clocks
* any function that is not connected by a bus

There is no need (and practice) to squeeze everything into a parent > child
relationship. And I can’t see your “control” or a “main interface” rule.

At least this is my (a little limited) view from using and programming DT for
multiple boards.

Maybe this is what the DT list should comment or show a clear definition when
parent>child relations are wanted and when not.


Now back to the GPS chip connected to an UART.

Is it
a) a component of an aggregate device? no
b) is it connected to a bus (i2c, spi, address bus)? no

This comes back to the question if UART is a bus.

I still think that it is NOT a bus and therefore it should not be modeled in DT
like busses are (enforcing clients to become subnodes).

The reason is there no well defined protocol to make multiple clients and
you can’t specify a <reg>.

So you are either abusing the notion of a bus or the gps chip must be a separate
DT node (child of something else).

I hope my gut feeling that we are trying to do something fundamentally wrong
with making the gps chip a subode of serial is now argued a little better.

For making the serial device control some regulator through a reference to
a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.

> 
>>>> 
>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>> divided out into a separate driver.
>>>> 
>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>> specific and present itself as a regulator (because that is its main purpose:
>>>> control the LDO regulator inside the w2sg0004 chip).
>>> 
>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>> 
>> It has a regulator that can be controlled by a gpio…
> 
> Does it?  I guess may it does.
> Maybe it also has an ARM core and some memory and assorted other bits and
> pieces.  But we don’t really need to describe them to device tree.

Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.

Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
connected to a GPIO - would tell if the module is really active or not. Using this would
make monitoring the RX line through different pinmux states obsolete.

But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
not wired the WAKEUP line to a  GPIO.

> 
> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> devices tree description.  If there are subcomponents that can usefully be
> described as well then there could be a place to describe those subcomponents.
> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> useful to describe the regulator inside the GPS so it could be declare that
> some other device which needed 1V8 made use of that regulator….

Yes. Well, even if *we* do not use it in this way yet, we should not make it
difficult for others to do by enforcing the wrong description.

> 
>> 
>> Another example to think about: the twl4030 is also not a regulator.
>> Nevertheless they present some regulator nodes.
> 
> The TWL4030 is a multifunction device which contains regulators and GPIOs and
> audio codec and  USB PHY etc etc etc.
> 
> So in device-tree there is a device-node for the TWL4030, and it has
> child-nodes for each sub-device.   They in turn can provide services to other
> devices on the board.

Exactly as discussed above. And there, the parent>child relation for the twl4030
and its subdevices is right.

> These sub-devices are much more independent of the whole than the regulator
> inside the w2sg0004 is.

Hm. That is probably argueable as well. At least a vague ciriterion.

> 
>> 
>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>> but has an internal pbias_regulator that needs to be controlled.
> 
> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> device which contains a CPU and multiple other controllers and  communicators
> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> it has a device-node which is a child of the 'ocp' node - which is the main
> interconnect in the OMAP3 I think.
> 
> So I'm not against describing the regulator in the w2sg0004, but for
> consistency with everything else, it would need to be child-node of a
> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> that would gain anything.

Well, it would gain consistency how chips with multiple components inside
are described.

And would make it easier to see the whole w2sg0004 a child of /.

But then we need some reference from your tty/serial driver to that w2sg node.

> 
> 
> Thanks,
> NeilBrown

Thanks as well,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 12133 bytes --]

Hi,

On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> So you propose that the parent->child relationship is “control”? I.e. some
> channel which allows to address some bus client (through <reg>) and
> control that devices.
> 
> Makes sense. This is how i2c and spi clients are specified.
> 
> > 
> > In the case of our GPS, it receives control over the serial connection from
> > the UART,
> 
> Ahem - does it?
> 
> AFAIK the chip simply starts to emit NMEA records if powered on.
> There is no command going over the serial interface to address it
> or control it.

Right, since GPS basically doesn't need any configuration/control.
That's not true for other UART attached devices, though.

> > also receives control via a GPIO to the on/off pin, and also needs
> > a regulator to power the antenna.
> > 
> > So should the parent be the uart, the on/off GPIO, or the regulator?
> > 
> > I would much rather there wasn't a parent, and that each of these were listed
> > as ad-hoc attribute assignments.  But device-tree says there must be a parent
> > (where possible), and the parent is the thing that is “primarily" in control.
> 
> Well, IMHO the “parent” could also be the root. Representing the
> whole board.
> 
> Nevertheless, I doubt your rule that “ability to control” defines
> the parent>child relation (see below).
> 
> > 
> > I think the GPS is “primarily" a uart-attached device.
> 
> But not in the same way as an I2C device.
> 
> Especially the serial interface is not a bus and not used for
> signalling and power control. It is payload data (only).

Actually many I2C devices are also powered on/off via a GPIO and
even use additional GPIOs for sending interrupts. Nevertheless they
are normally identified as an I2C device.

Also for non-GPS device the serial connection is used for
controlling and configuring the device.

> > So I propose a device-node which describes the GPS, which is a child of the
> > UART, and explicitly identifies the GPIO it uses to power on/off, the
> > regulator it uses to power the antenna, and how it receives "on or off"
> > status indications from the GPS.
> 
> The more I think about that, you have given good arguments *not*
> to use the parent->child relationship for the UART interface of
> the GPS.
> 
> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
> 1. an USB-Interface for AT signalling and payload
> 2. some GPIOs for power control.
> 3. a PCM interface for digital voice. 
> 4. it might also have a serial interface as alternate AT command and (GPRS
>     low speed) payload.
> 
> So which one is the most prominent or most important to make it a child of?
> 
> If you use “control” you must make it a child of the USB phy and the serial interface
> which requires multiple inheritance…
> 
> So I am not sure at all. None is IMHO prominent and unique enough to make it
> a parent>child relation.
>
> Threrefore, I would be happy to see it as multiple children of /. For example a
> MFD with subnodes.

This scenario has already been seen before and can happen for
non-UART based devices (e.g. SPI + I2C). So far the decision was to
postpone the discussion about this kind of devices until one of them
appears.

> > It is arguable that the "antenna" should be treated as a separate device - a
> > child of the GPS - which controls the regulator and also provides a 'extcon'
> > which reports whether an external GPS antenna is attached, or whether the
> > internal on is in use.  I haven't made the time to properly explore that
> > issue yet.
> 
> If you assume that parent>child relationship is about control (only). But if it
> is about data flow, there is a different concept in DT. For example the CSI/DSI
> (OMAP DSS) use the “port” concept.

Yes, this is about data not going to the cpu / system memory.

> This means that indeed parent>child is used for control, e.g. I2C
> or SPI to tell the panel controller to switch on.

well parent > child is not about power control, but about "primary"
control. Some I2C/SPI devices have additional gpios for power
control.

> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
> bus and the panel is controlled through SPI). Other panels need no control
> interface and are simply a child of /.

Yes, some devices do not have an interface worth of being called
"primary control" :)

> The video stream and its connections are arranged through such ports.
> For the video out management we have added our OPA362 video amplifier into
> that video pipeline which starts at the VENC (Video encode) in the SoC,
> goes through the OPA362 and ends in the connector (which has its own
> node). All this is connected by references. The opa362 node itself is a child
> of /: 
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
> 
> So to summarize I now see exactly two cases where parent>child is used:
> a) for components of an aggregate device (OMAP3 > I2C controllers)
> b) for components connected to a bus controller (I2C > TWL4030)
> 
> Since the twl regulators are components of the twl chip it completely explains
> why we see
> 
> omap3 > i2c > twl4030 > vaux4
> 
> Everything else is done by references. Therefore we see references for
> * gpios within a controller (independently of it’s relation on a bus)
> * regulators
> * clocks
> * any function that is not connected by a bus
>
> There is no need (and practice) to squeeze everything into a parent > child
> relationship. And I can’t see your “control” or a “main interface” rule.

And I can't see your bus rule for me the motiviation behind the
parent > child relationship is about the system's primary way for
accessing a device.

It's coincidence, that this is currently (always?) a bus connection,
since most devices are actually connected using some kind of bus.

> At least this is my (a little limited) view from using and programming DT for
> multiple boards.
> 
> Maybe this is what the DT list should comment or show a clear definition when
> parent>child relations are wanted and when not.
>
> Now back to the GPS chip connected to an UART.
> 
> Is it
> a) a component of an aggregate device? no
> b) is it connected to a bus (i2c, spi, address bus)? no

> This comes back to the question if UART is a bus.
> 
> I still think that it is NOT a bus and therefore it should not be modeled in DT
> like busses are (enforcing clients to become subnodes).

If I use a SPI device with hardwired chip select its *very* similar
to UART.

> The reason is there no well defined protocol to make multiple clients and
> you can’t specify a <reg>.
> 
> So you are either abusing the notion of a bus or the gps chip must be a separate
> DT node (child of something else).
>
> I hope my gut feeling that we are trying to do something fundamentally wrong
> with making the gps chip a subode of serial is now argued a little better.
> 
> For making the serial device control some regulator through a reference to
> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.

NAK about referencing the regulator from the UART node. It should be
referenced from the Bluetooth / GPS node. The UART port works
without the regulator. It's the remote side, that does not work.
We also do not add the regulators of I2C clients to the I2C host.

If you want to talk with an I2C device you enable the I2C device
*and* its parent (aka the I2C host controller). I guess the same
should be done for the UART.

> >>>> All the following is very special logic for the w2sg0004 chip which should be
> >>>> divided out into a separate driver.
> >>>> 
> >>>> Marek and me already had proposed such a chip specific driver (to be located
> >>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >>>> specific and present itself as a regulator (because that is its main purpose:
> >>>> control the LDO regulator inside the w2sg0004 chip).
> >>> 
> >>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
> >> 
> >> It has a regulator that can be controlled by a gpio…
> > 
> > Does it?  I guess may it does.
> > Maybe it also has an ARM core and some memory and assorted other bits and
> > pieces.  But we don’t really need to describe them to device tree.
> 
> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
> 
> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
> connected to a GPIO - would tell if the module is really active or not. Using this would
> make monitoring the RX line through different pinmux states obsolete.
> 
> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
> not wired the WAKEUP line to a  GPIO.
>
> > The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> > devices tree description.  If there are subcomponents that can usefully be
> > described as well then there could be a place to describe those subcomponents.
> > I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> > 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> > useful to describe the regulator inside the GPS so it could be declare that
> > some other device which needed 1V8 made use of that regulator….
> 
> Yes. Well, even if *we* do not use it in this way yet, we should not make it
> difficult for others to do by enforcing the wrong description.

well this has nothing to do with the parent-child discussion, since
you can obviously reference a regulator independently of its
position in the DT.

> >> Another example to think about: the twl4030 is also not a regulator.
> >> Nevertheless they present some regulator nodes.
> > 
> > The TWL4030 is a multifunction device which contains regulators and GPIOs and
> > audio codec and  USB PHY etc etc etc.
> > 
> > So in device-tree there is a device-node for the TWL4030, and it has
> > child-nodes for each sub-device.   They in turn can provide services to other
> > devices on the board.
> 
> Exactly as discussed above. And there, the parent>child relation for the twl4030
> and its subdevices is right.
> 
> > These sub-devices are much more independent of the whole than the regulator
> > inside the w2sg0004 is.
> 
> Hm. That is probably argueable as well. At least a vague ciriterion.
> > 
> >> 
> >> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> >> but has an internal pbias_regulator that needs to be controlled.
> > 
> > I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> > device which contains a CPU and multiple other controllers and  communicators
> > and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> > it has a device-node which is a child of the 'ocp' node - which is the main
> > interconnect in the OMAP3 I think.
> > 
> > So I'm not against describing the regulator in the w2sg0004, but for
> > consistency with everything else, it would need to be child-node of a
> > device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> > that would gain anything.
> 
> Well, it would gain consistency how chips with multiple components inside
> are described.

I don't think so. Many devices do not expose all of their
subdevices. e.g. they do not expose their internal clocks.
Apart from that there are a few devices in the kernel, which
do use enable-gpio(s).

> And would make it easier to see the whole w2sg0004 a child of /.

Even with the regulator subdevice I would still make the w2sg0004 a
child of the UART port. Main reason is, that I would need to go
through the UART to "communicate" with the w2sg0004.

> But then we need some reference from your tty/serial driver to
> that w2sg node.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 12133 bytes --]

Hi,

On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> So you propose that the parent->child relationship is “control”? I.e. some
> channel which allows to address some bus client (through <reg>) and
> control that devices.
> 
> Makes sense. This is how i2c and spi clients are specified.
> 
> > 
> > In the case of our GPS, it receives control over the serial connection from
> > the UART,
> 
> Ahem - does it?
> 
> AFAIK the chip simply starts to emit NMEA records if powered on.
> There is no command going over the serial interface to address it
> or control it.

Right, since GPS basically doesn't need any configuration/control.
That's not true for other UART attached devices, though.

> > also receives control via a GPIO to the on/off pin, and also needs
> > a regulator to power the antenna.
> > 
> > So should the parent be the uart, the on/off GPIO, or the regulator?
> > 
> > I would much rather there wasn't a parent, and that each of these were listed
> > as ad-hoc attribute assignments.  But device-tree says there must be a parent
> > (where possible), and the parent is the thing that is “primarily" in control.
> 
> Well, IMHO the “parent” could also be the root. Representing the
> whole board.
> 
> Nevertheless, I doubt your rule that “ability to control” defines
> the parent>child relation (see below).
> 
> > 
> > I think the GPS is “primarily" a uart-attached device.
> 
> But not in the same way as an I2C device.
> 
> Especially the serial interface is not a bus and not used for
> signalling and power control. It is payload data (only).

Actually many I2C devices are also powered on/off via a GPIO and
even use additional GPIOs for sending interrupts. Nevertheless they
are normally identified as an I2C device.

Also for non-GPS device the serial connection is used for
controlling and configuring the device.

> > So I propose a device-node which describes the GPS, which is a child of the
> > UART, and explicitly identifies the GPIO it uses to power on/off, the
> > regulator it uses to power the antenna, and how it receives "on or off"
> > status indications from the GPS.
> 
> The more I think about that, you have given good arguments *not*
> to use the parent->child relationship for the UART interface of
> the GPS.
> 
> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
> 1. an USB-Interface for AT signalling and payload
> 2. some GPIOs for power control.
> 3. a PCM interface for digital voice. 
> 4. it might also have a serial interface as alternate AT command and (GPRS
>     low speed) payload.
> 
> So which one is the most prominent or most important to make it a child of?
> 
> If you use “control” you must make it a child of the USB phy and the serial interface
> which requires multiple inheritance…
> 
> So I am not sure at all. None is IMHO prominent and unique enough to make it
> a parent>child relation.
>
> Threrefore, I would be happy to see it as multiple children of /. For example a
> MFD with subnodes.

This scenario has already been seen before and can happen for
non-UART based devices (e.g. SPI + I2C). So far the decision was to
postpone the discussion about this kind of devices until one of them
appears.

> > It is arguable that the "antenna" should be treated as a separate device - a
> > child of the GPS - which controls the regulator and also provides a 'extcon'
> > which reports whether an external GPS antenna is attached, or whether the
> > internal on is in use.  I haven't made the time to properly explore that
> > issue yet.
> 
> If you assume that parent>child relationship is about control (only). But if it
> is about data flow, there is a different concept in DT. For example the CSI/DSI
> (OMAP DSS) use the “port” concept.

Yes, this is about data not going to the cpu / system memory.

> This means that indeed parent>child is used for control, e.g. I2C
> or SPI to tell the panel controller to switch on.

well parent > child is not about power control, but about "primary"
control. Some I2C/SPI devices have additional gpios for power
control.

> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
> bus and the panel is controlled through SPI). Other panels need no control
> interface and are simply a child of /.

Yes, some devices do not have an interface worth of being called
"primary control" :)

> The video stream and its connections are arranged through such ports.
> For the video out management we have added our OPA362 video amplifier into
> that video pipeline which starts at the VENC (Video encode) in the SoC,
> goes through the OPA362 and ends in the connector (which has its own
> node). All this is connected by references. The opa362 node itself is a child
> of /: 
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
> 
> So to summarize I now see exactly two cases where parent>child is used:
> a) for components of an aggregate device (OMAP3 > I2C controllers)
> b) for components connected to a bus controller (I2C > TWL4030)
> 
> Since the twl regulators are components of the twl chip it completely explains
> why we see
> 
> omap3 > i2c > twl4030 > vaux4
> 
> Everything else is done by references. Therefore we see references for
> * gpios within a controller (independently of it’s relation on a bus)
> * regulators
> * clocks
> * any function that is not connected by a bus
>
> There is no need (and practice) to squeeze everything into a parent > child
> relationship. And I can’t see your “control” or a “main interface” rule.

And I can't see your bus rule for me the motiviation behind the
parent > child relationship is about the system's primary way for
accessing a device.

It's coincidence, that this is currently (always?) a bus connection,
since most devices are actually connected using some kind of bus.

> At least this is my (a little limited) view from using and programming DT for
> multiple boards.
> 
> Maybe this is what the DT list should comment or show a clear definition when
> parent>child relations are wanted and when not.
>
> Now back to the GPS chip connected to an UART.
> 
> Is it
> a) a component of an aggregate device? no
> b) is it connected to a bus (i2c, spi, address bus)? no

> This comes back to the question if UART is a bus.
> 
> I still think that it is NOT a bus and therefore it should not be modeled in DT
> like busses are (enforcing clients to become subnodes).

If I use a SPI device with hardwired chip select its *very* similar
to UART.

> The reason is there no well defined protocol to make multiple clients and
> you can’t specify a <reg>.
> 
> So you are either abusing the notion of a bus or the gps chip must be a separate
> DT node (child of something else).
>
> I hope my gut feeling that we are trying to do something fundamentally wrong
> with making the gps chip a subode of serial is now argued a little better.
> 
> For making the serial device control some regulator through a reference to
> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.

NAK about referencing the regulator from the UART node. It should be
referenced from the Bluetooth / GPS node. The UART port works
without the regulator. It's the remote side, that does not work.
We also do not add the regulators of I2C clients to the I2C host.

If you want to talk with an I2C device you enable the I2C device
*and* its parent (aka the I2C host controller). I guess the same
should be done for the UART.

> >>>> All the following is very special logic for the w2sg0004 chip which should be
> >>>> divided out into a separate driver.
> >>>> 
> >>>> Marek and me already had proposed such a chip specific driver (to be located
> >>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >>>> specific and present itself as a regulator (because that is its main purpose:
> >>>> control the LDO regulator inside the w2sg0004 chip).
> >>> 
> >>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
> >> 
> >> It has a regulator that can be controlled by a gpio…
> > 
> > Does it?  I guess may it does.
> > Maybe it also has an ARM core and some memory and assorted other bits and
> > pieces.  But we don’t really need to describe them to device tree.
> 
> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
> 
> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
> connected to a GPIO - would tell if the module is really active or not. Using this would
> make monitoring the RX line through different pinmux states obsolete.
> 
> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
> not wired the WAKEUP line to a  GPIO.
>
> > The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> > devices tree description.  If there are subcomponents that can usefully be
> > described as well then there could be a place to describe those subcomponents.
> > I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> > 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> > useful to describe the regulator inside the GPS so it could be declare that
> > some other device which needed 1V8 made use of that regulator….
> 
> Yes. Well, even if *we* do not use it in this way yet, we should not make it
> difficult for others to do by enforcing the wrong description.

well this has nothing to do with the parent-child discussion, since
you can obviously reference a regulator independently of its
position in the DT.

> >> Another example to think about: the twl4030 is also not a regulator.
> >> Nevertheless they present some regulator nodes.
> > 
> > The TWL4030 is a multifunction device which contains regulators and GPIOs and
> > audio codec and  USB PHY etc etc etc.
> > 
> > So in device-tree there is a device-node for the TWL4030, and it has
> > child-nodes for each sub-device.   They in turn can provide services to other
> > devices on the board.
> 
> Exactly as discussed above. And there, the parent>child relation for the twl4030
> and its subdevices is right.
> 
> > These sub-devices are much more independent of the whole than the regulator
> > inside the w2sg0004 is.
> 
> Hm. That is probably argueable as well. At least a vague ciriterion.
> > 
> >> 
> >> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> >> but has an internal pbias_regulator that needs to be controlled.
> > 
> > I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> > device which contains a CPU and multiple other controllers and  communicators
> > and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> > it has a device-node which is a child of the 'ocp' node - which is the main
> > interconnect in the OMAP3 I think.
> > 
> > So I'm not against describing the regulator in the w2sg0004, but for
> > consistency with everything else, it would need to be child-node of a
> > device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> > that would gain anything.
> 
> Well, it would gain consistency how chips with multiple components inside
> are described.

I don't think so. Many devices do not expose all of their
subdevices. e.g. they do not expose their internal clocks.
Apart from that there are a few devices in the kernel, which
do use enable-gpio(s).

> And would make it easier to see the whole w2sg0004 a child of /.

Even with the regulator subdevice I would still make the w2sg0004 a
child of the UART port. Main reason is, that I would need to go
through the UART to "communicate" with the w2sg0004.

> But then we need some reference from your tty/serial driver to
> that w2sg node.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
>> So you propose that the parent->child relationship is “control”? I.e. some
>> channel which allows to address some bus client (through <reg>) and
>> control that devices.
>> 
>> Makes sense. This is how i2c and spi clients are specified.
>> 
>>> 
>>> In the case of our GPS, it receives control over the serial connection from
>>> the UART,
>> 
>> Ahem - does it?
>> 
>> AFAIK the chip simply starts to emit NMEA records if powered on.
>> There is no command going over the serial interface to address it
>> or control it.
> 
> Right, since GPS basically doesn't need any configuration/control.
> That’s not true for other UART attached devices, though.

Do you have an example? Usually an UART data stream is transparently
presented to a /dev/tty - and user-space daemon can configure/control the
attached device. In most cases it can mix payload data and control command
by some AT command and escape sequences.

> 
>>> also receives control via a GPIO to the on/off pin, and also needs
>>> a regulator to power the antenna.
>>> 
>>> So should the parent be the uart, the on/off GPIO, or the regulator?
>>> 
>>> I would much rather there wasn't a parent, and that each of these were listed
>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
>>> (where possible), and the parent is the thing that is “primarily" in control.
>> 
>> Well, IMHO the “parent” could also be the root. Representing the
>> whole board.
>> 
>> Nevertheless, I doubt your rule that “ability to control” defines
>> the parent>child relation (see below).
>> 
>>> 
>>> I think the GPS is “primarily" a uart-attached device.
>> 
>> But not in the same way as an I2C device.
>> 
>> Especially the serial interface is not a bus and not used for
>> signalling and power control. It is payload data (only).
> 
> Actually many I2C devices are also powered on/off via a GPIO and
> even use additional GPIOs for sending interrupts. Nevertheless they
> are normally identified as an I2C device.

Because I2C is a bus that can address multiple clients and gpio isn’t
a bus and a point-to-point connection.

But IMHO it is not because they (can) send payload data over i2c.

> 
> Also for non-GPS device the serial connection is used for
> controlling and configuring the device.

This assumes that “controls a device” is the criterion for making a device
a subnode. I doubt that.

> 
>>> So I propose a device-node which describes the GPS, which is a child of the
>>> UART, and explicitly identifies the GPIO it uses to power on/off, the
>>> regulator it uses to power the antenna, and how it receives "on or off"
>>> status indications from the GPS.
>> 
>> The more I think about that, you have given good arguments *not*
>> to use the parent->child relationship for the UART interface of
>> the GPS.
>> 
>> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
>> 1. an USB-Interface for AT signalling and payload
>> 2. some GPIOs for power control.
>> 3. a PCM interface for digital voice. 
>> 4. it might also have a serial interface as alternate AT command and (GPRS
>>    low speed) payload.
>> 
>> So which one is the most prominent or most important to make it a child of?
>> 
>> If you use “control” you must make it a child of the USB phy and the serial interface
>> which requires multiple inheritance…
>> 
>> So I am not sure at all. None is IMHO prominent and unique enough to make it
>> a parent>child relation.
>> 
>> Threrefore, I would be happy to see it as multiple children of /. For example a
>> MFD with subnodes.
> 
> This scenario has already been seen before and can happen for
> non-UART based devices (e.g. SPI + I2C). So far the decision was to
> postpone the discussion about this kind of devices until one of them
> appears.
> 
>>> It is arguable that the "antenna" should be treated as a separate device - a
>>> child of the GPS - which controls the regulator and also provides a 'extcon'
>>> which reports whether an external GPS antenna is attached, or whether the
>>> internal on is in use.  I haven't made the time to properly explore that
>>> issue yet.
>> 
>> If you assume that parent>child relationship is about control (only). But if it
>> is about data flow, there is a different concept in DT. For example the CSI/DSI
>> (OMAP DSS) use the “port” concept.
> 
> Yes, this is about data not going to the cpu / system memory.

Really? The frame buffer data is in system memory and gets to the panel. Or a
camera image ends up in system memory.

> 
>> This means that indeed parent>child is used for control, e.g. I2C
>> or SPI to tell the panel controller to switch on.
> 
> well parent > child is not about power control, but about "primary"
> control.

Can you clearly and precisely define what “primary” control is? I think
two people will have three opinions about that.

For example I would see the w2sg0004 on/off gpio as the primary “control”
which makes the light (NMES records) turned on.

Therefore we should make it the subnode of some gpio-controller, shouldn’t we?

> Some I2C/SPI devices have additional gpios for power
> control.
> 
>> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
>> bus and the panel is controlled through SPI). Other panels need no control
>> interface and are simply a child of /.
> 
> Yes, some devices do not have an interface worth of being called
> “primary control" :)

This is why I criticise this criterion to define when we need a parent/child relation.
It is not strict and does not follow a principle but opinions.

But before we stick to opinions, I have studied again:

	http://www.devicetree.org/Device_Tree_Usage#Devices

In their examples (which unfortunately don’t cover our special cases)
they make clear that subnodes are needed for “addressable” subnodes
like CPUs, Memory banks, i2c clients, ethernet clients etc.

(well, the first sentence in “Interrupts” can be read to confirm this interpretation:
“Unlike address range translation which follows the natural structure of the tree”)

In general I read from this (although it is not explicitly stated) that
parent>child hierarchy is about addressing bus clients and mapping
devices into memory address space.

Everything else is to be done through references.

> 
>> The video stream and its connections are arranged through such ports.
>> For the video out management we have added our OPA362 video amplifier into
>> that video pipeline which starts at the VENC (Video encode) in the SoC,
>> goes through the OPA362 and ends in the connector (which has its own
>> node). All this is connected by references. The opa362 node itself is a child
>> of /: 
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
>> 
>> So to summarize I now see exactly two cases where parent>child is used:
>> a) for components of an aggregate device (OMAP3 > I2C controllers)
>> b) for components connected to a bus controller (I2C > TWL4030)
>> 
>> Since the twl regulators are components of the twl chip it completely explains
>> why we see
>> 
>> omap3 > i2c > twl4030 > vaux4
>> 
>> Everything else is done by references. Therefore we see references for
>> * gpios within a controller (independently of it’s relation on a bus)
>> * regulators
>> * clocks
>> * any function that is not connected by a bus
>> 
>> There is no need (and practice) to squeeze everything into a parent > child
>> relationship. And I can’t see your “control” or a “main interface” rule.
> 
> And I can't see your bus rule for me the motiviation behind the
> parent > child relationship is about the system's primary way for
> accessing a device.

It appears not to be “my bus rule”. I just formulated in that way from the
examples I have seen…

> 
> It's coincidence, that this is currently (always?) a bus connection,
> since most devices are actually connected using some kind of bus.

I think the view must be reversed and then it is not a coincidence but a
consequence.

> 
>> At least this is my (a little limited) view from using and programming DT for
>> multiple boards.
>> 
>> Maybe this is what the DT list should comment or show a clear definition when
>> parent>child relations are wanted and when not.
>> 
>> Now back to the GPS chip connected to an UART.
>> 
>> Is it
>> a) a component of an aggregate device? no
>> b) is it connected to a bus (i2c, spi, address bus)? no
> 
>> This comes back to the question if UART is a bus.
>> 
>> I still think that it is NOT a bus and therefore it should not be modeled in DT
>> like busses are (enforcing clients to become subnodes).
> 
> If I use a SPI device with hardwired chip select its *very* similar
> to UART.

Yes, because you can just connect a single client to SPI and then question if
it is a bus. But that is a useage pattern but not a principle.

And IMHO, DT definitions should follow principles and not current need.

Otherwise I don’t understand why the virtual-gpio connected to UART DTR
or the regulator is *not* acceptable.

> 
>> The reason is there no well defined protocol to make multiple clients and
>> you can’t specify a <reg>.
>> 
>> So you are either abusing the notion of a bus or the gps chip must be a separate
>> DT node (child of something else).
>> 
>> I hope my gut feeling that we are trying to do something fundamentally wrong
>> with making the gps chip a subode of serial is now argued a little better.
>> 
>> For making the serial device control some regulator through a reference to
>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
> 
> NAK about referencing the regulator from the UART node. It should be
> referenced from the Bluetooth / GPS node. The UART port works
> without the regulator. It's the remote side, that does not work.
> We also do not add the regulators of I2C clients to the I2C host.

I think Pavel made a very good comment:

The uart node should be able to power a rs232 converter/level shifter directly
connected to it (through a regulator or gpio-regulator).

And there must be a separate mechanism to power the remote rs232 converter
and the remote device.

The standard signalling for this are the RTS/DTR lines of an UART/RS232.

UART is not only RX+TX.

> 
> If you want to talk with an I2C device you enable the I2C device
> *and* its parent (aka the I2C host controller). I guess the same
> should be done for the UART.
> 
>>>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>>>> divided out into a separate driver.
>>>>>> 
>>>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>>>> specific and present itself as a regulator (because that is its main purpose:
>>>>>> control the LDO regulator inside the w2sg0004 chip).
>>>>> 
>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>>>> 
>>>> It has a regulator that can be controlled by a gpio…
>>> 
>>> Does it?  I guess may it does.
>>> Maybe it also has an ARM core and some memory and assorted other bits and
>>> pieces.  But we don’t really need to describe them to device tree.
>> 
>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
>> 
>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
>> connected to a GPIO - would tell if the module is really active or not. Using this would
>> make monitoring the RX line through different pinmux states obsolete.
>> 
>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
>> not wired the WAKEUP line to a  GPIO.
>> 
>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
>>> devices tree description.  If there are subcomponents that can usefully be
>>> described as well then there could be a place to describe those subcomponents.
>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
>>> useful to describe the regulator inside the GPS so it could be declare that
>>> some other device which needed 1V8 made use of that regulator….
>> 
>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
>> difficult for others to do by enforcing the wrong description.
> 
> well this has nothing to do with the parent-child discussion, since
> you can obviously reference a regulator independently of its
> position in the DT.
> 
>>>> Another example to think about: the twl4030 is also not a regulator.
>>>> Nevertheless they present some regulator nodes.
>>> 
>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
>>> audio codec and  USB PHY etc etc etc.
>>> 
>>> So in device-tree there is a device-node for the TWL4030, and it has
>>> child-nodes for each sub-device.   They in turn can provide services to other
>>> devices on the board.
>> 
>> Exactly as discussed above. And there, the parent>child relation for the twl4030
>> and its subdevices is right.
>> 
>>> These sub-devices are much more independent of the whole than the regulator
>>> inside the w2sg0004 is.
>> 
>> Hm. That is probably argueable as well. At least a vague ciriterion.
>>> 
>>>> 
>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>>>> but has an internal pbias_regulator that needs to be controlled.
>>> 
>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
>>> device which contains a CPU and multiple other controllers and  communicators
>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
>>> it has a device-node which is a child of the 'ocp' node - which is the main
>>> interconnect in the OMAP3 I think.
>>> 
>>> So I'm not against describing the regulator in the w2sg0004, but for
>>> consistency with everything else, it would need to be child-node of a
>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
>>> that would gain anything.
>> 
>> Well, it would gain consistency how chips with multiple components inside
>> are described.
> 
> I don't think so. Many devices do not expose all of their
> subdevices. e.g. they do not expose their internal clocks.
> Apart from that there are a few devices in the kernel, which
> do use enable-gpio(s).

After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
revise my formulation a little.

It is not that parent>child is used for describing “busses or grouping subdevices".

It is only for “grouping addressable components”, which implies some bus.

This still explains the ocp component of the OMAP3 - which represents the
whole internal “interconnect” bus (see comment in omap3.dtsi).

Therefore you are right. It is not correct to split up a device into arbitrary
components and group them again by the parent>child pattern.

Although the structure of twl4030.dtsi appears to simply list and group
subcomponents without telling explicitly how to address them.

> 
>> And would make it easier to see the whole w2sg0004 a child of /.
> 
> Even with the regulator subdevice I would still make the w2sg0004 a
> child of the UART port.

This would mean that a tty / uart is able to address multiple clients. How
could it do that?

> Main reason is, that I would need to go
> through the UART to “communicate" with the w2sg0004.

You can always "communicate” through the UART. Even without DT. As long as
the connected chip is powered up by any means (could be some fixed-regulator
or hard wired).

Power control for open()/close() did even work with the DT based DTR->virtual-gpio
approach.

We just do not described in the DT that there is a data connection from uart1 to
the RX/TX pins. But you just open /dev/ttyO1.

Thus, describing a relation between the uart node and the GPS chip in the DT is
not even a requirement.

Probably the main problem we have is that we want to describe this data connection
but the device tree is about describing how to address components and data
flow is left to internal APIs. Or “ports” like in the video pipelines.

Let me raise the question:

Why do we need to describe in the DT (independently of Linux power control
structures and drivers!) that the GPS data interface is connected to a specific UART?

Who needs this information and for which purpose?

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
>> So you propose that the parent->child relationship is “control”? I.e. some
>> channel which allows to address some bus client (through <reg>) and
>> control that devices.
>> 
>> Makes sense. This is how i2c and spi clients are specified.
>> 
>>> 
>>> In the case of our GPS, it receives control over the serial connection from
>>> the UART,
>> 
>> Ahem - does it?
>> 
>> AFAIK the chip simply starts to emit NMEA records if powered on.
>> There is no command going over the serial interface to address it
>> or control it.
> 
> Right, since GPS basically doesn't need any configuration/control.
> That’s not true for other UART attached devices, though.

Do you have an example? Usually an UART data stream is transparently
presented to a /dev/tty - and user-space daemon can configure/control the
attached device. In most cases it can mix payload data and control command
by some AT command and escape sequences.

> 
>>> also receives control via a GPIO to the on/off pin, and also needs
>>> a regulator to power the antenna.
>>> 
>>> So should the parent be the uart, the on/off GPIO, or the regulator?
>>> 
>>> I would much rather there wasn't a parent, and that each of these were listed
>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
>>> (where possible), and the parent is the thing that is “primarily" in control.
>> 
>> Well, IMHO the “parent” could also be the root. Representing the
>> whole board.
>> 
>> Nevertheless, I doubt your rule that “ability to control” defines
>> the parent>child relation (see below).
>> 
>>> 
>>> I think the GPS is “primarily" a uart-attached device.
>> 
>> But not in the same way as an I2C device.
>> 
>> Especially the serial interface is not a bus and not used for
>> signalling and power control. It is payload data (only).
> 
> Actually many I2C devices are also powered on/off via a GPIO and
> even use additional GPIOs for sending interrupts. Nevertheless they
> are normally identified as an I2C device.

Because I2C is a bus that can address multiple clients and gpio isn’t
a bus and a point-to-point connection.

But IMHO it is not because they (can) send payload data over i2c.

> 
> Also for non-GPS device the serial connection is used for
> controlling and configuring the device.

This assumes that “controls a device” is the criterion for making a device
a subnode. I doubt that.

> 
>>> So I propose a device-node which describes the GPS, which is a child of the
>>> UART, and explicitly identifies the GPIO it uses to power on/off, the
>>> regulator it uses to power the antenna, and how it receives "on or off"
>>> status indications from the GPS.
>> 
>> The more I think about that, you have given good arguments *not*
>> to use the parent->child relationship for the UART interface of
>> the GPS.
>> 
>> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
>> 1. an USB-Interface for AT signalling and payload
>> 2. some GPIOs for power control.
>> 3. a PCM interface for digital voice. 
>> 4. it might also have a serial interface as alternate AT command and (GPRS
>>    low speed) payload.
>> 
>> So which one is the most prominent or most important to make it a child of?
>> 
>> If you use “control” you must make it a child of the USB phy and the serial interface
>> which requires multiple inheritance…
>> 
>> So I am not sure at all. None is IMHO prominent and unique enough to make it
>> a parent>child relation.
>> 
>> Threrefore, I would be happy to see it as multiple children of /. For example a
>> MFD with subnodes.
> 
> This scenario has already been seen before and can happen for
> non-UART based devices (e.g. SPI + I2C). So far the decision was to
> postpone the discussion about this kind of devices until one of them
> appears.
> 
>>> It is arguable that the "antenna" should be treated as a separate device - a
>>> child of the GPS - which controls the regulator and also provides a 'extcon'
>>> which reports whether an external GPS antenna is attached, or whether the
>>> internal on is in use.  I haven't made the time to properly explore that
>>> issue yet.
>> 
>> If you assume that parent>child relationship is about control (only). But if it
>> is about data flow, there is a different concept in DT. For example the CSI/DSI
>> (OMAP DSS) use the “port” concept.
> 
> Yes, this is about data not going to the cpu / system memory.

Really? The frame buffer data is in system memory and gets to the panel. Or a
camera image ends up in system memory.

> 
>> This means that indeed parent>child is used for control, e.g. I2C
>> or SPI to tell the panel controller to switch on.
> 
> well parent > child is not about power control, but about "primary"
> control.

Can you clearly and precisely define what “primary” control is? I think
two people will have three opinions about that.

For example I would see the w2sg0004 on/off gpio as the primary “control”
which makes the light (NMES records) turned on.

Therefore we should make it the subnode of some gpio-controller, shouldn’t we?

> Some I2C/SPI devices have additional gpios for power
> control.
> 
>> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
>> bus and the panel is controlled through SPI). Other panels need no control
>> interface and are simply a child of /.
> 
> Yes, some devices do not have an interface worth of being called
> “primary control" :)

This is why I criticise this criterion to define when we need a parent/child relation.
It is not strict and does not follow a principle but opinions.

But before we stick to opinions, I have studied again:

	http://www.devicetree.org/Device_Tree_Usage#Devices

In their examples (which unfortunately don’t cover our special cases)
they make clear that subnodes are needed for “addressable” subnodes
like CPUs, Memory banks, i2c clients, ethernet clients etc.

(well, the first sentence in “Interrupts” can be read to confirm this interpretation:
“Unlike address range translation which follows the natural structure of the tree”)

In general I read from this (although it is not explicitly stated) that
parent>child hierarchy is about addressing bus clients and mapping
devices into memory address space.

Everything else is to be done through references.

> 
>> The video stream and its connections are arranged through such ports.
>> For the video out management we have added our OPA362 video amplifier into
>> that video pipeline which starts at the VENC (Video encode) in the SoC,
>> goes through the OPA362 and ends in the connector (which has its own
>> node). All this is connected by references. The opa362 node itself is a child
>> of /: 
>> 
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
>> 
>> So to summarize I now see exactly two cases where parent>child is used:
>> a) for components of an aggregate device (OMAP3 > I2C controllers)
>> b) for components connected to a bus controller (I2C > TWL4030)
>> 
>> Since the twl regulators are components of the twl chip it completely explains
>> why we see
>> 
>> omap3 > i2c > twl4030 > vaux4
>> 
>> Everything else is done by references. Therefore we see references for
>> * gpios within a controller (independently of it’s relation on a bus)
>> * regulators
>> * clocks
>> * any function that is not connected by a bus
>> 
>> There is no need (and practice) to squeeze everything into a parent > child
>> relationship. And I can’t see your “control” or a “main interface” rule.
> 
> And I can't see your bus rule for me the motiviation behind the
> parent > child relationship is about the system's primary way for
> accessing a device.

It appears not to be “my bus rule”. I just formulated in that way from the
examples I have seen…

> 
> It's coincidence, that this is currently (always?) a bus connection,
> since most devices are actually connected using some kind of bus.

I think the view must be reversed and then it is not a coincidence but a
consequence.

> 
>> At least this is my (a little limited) view from using and programming DT for
>> multiple boards.
>> 
>> Maybe this is what the DT list should comment or show a clear definition when
>> parent>child relations are wanted and when not.
>> 
>> Now back to the GPS chip connected to an UART.
>> 
>> Is it
>> a) a component of an aggregate device? no
>> b) is it connected to a bus (i2c, spi, address bus)? no
> 
>> This comes back to the question if UART is a bus.
>> 
>> I still think that it is NOT a bus and therefore it should not be modeled in DT
>> like busses are (enforcing clients to become subnodes).
> 
> If I use a SPI device with hardwired chip select its *very* similar
> to UART.

Yes, because you can just connect a single client to SPI and then question if
it is a bus. But that is a useage pattern but not a principle.

And IMHO, DT definitions should follow principles and not current need.

Otherwise I don’t understand why the virtual-gpio connected to UART DTR
or the regulator is *not* acceptable.

> 
>> The reason is there no well defined protocol to make multiple clients and
>> you can’t specify a <reg>.
>> 
>> So you are either abusing the notion of a bus or the gps chip must be a separate
>> DT node (child of something else).
>> 
>> I hope my gut feeling that we are trying to do something fundamentally wrong
>> with making the gps chip a subode of serial is now argued a little better.
>> 
>> For making the serial device control some regulator through a reference to
>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
> 
> NAK about referencing the regulator from the UART node. It should be
> referenced from the Bluetooth / GPS node. The UART port works
> without the regulator. It's the remote side, that does not work.
> We also do not add the regulators of I2C clients to the I2C host.

I think Pavel made a very good comment:

The uart node should be able to power a rs232 converter/level shifter directly
connected to it (through a regulator or gpio-regulator).

And there must be a separate mechanism to power the remote rs232 converter
and the remote device.

The standard signalling for this are the RTS/DTR lines of an UART/RS232.

UART is not only RX+TX.

> 
> If you want to talk with an I2C device you enable the I2C device
> *and* its parent (aka the I2C host controller). I guess the same
> should be done for the UART.
> 
>>>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>>>> divided out into a separate driver.
>>>>>> 
>>>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>>>> specific and present itself as a regulator (because that is its main purpose:
>>>>>> control the LDO regulator inside the w2sg0004 chip).
>>>>> 
>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>>>> 
>>>> It has a regulator that can be controlled by a gpio…
>>> 
>>> Does it?  I guess may it does.
>>> Maybe it also has an ARM core and some memory and assorted other bits and
>>> pieces.  But we don’t really need to describe them to device tree.
>> 
>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
>> 
>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
>> connected to a GPIO - would tell if the module is really active or not. Using this would
>> make monitoring the RX line through different pinmux states obsolete.
>> 
>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
>> not wired the WAKEUP line to a  GPIO.
>> 
>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
>>> devices tree description.  If there are subcomponents that can usefully be
>>> described as well then there could be a place to describe those subcomponents.
>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
>>> useful to describe the regulator inside the GPS so it could be declare that
>>> some other device which needed 1V8 made use of that regulator….
>> 
>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
>> difficult for others to do by enforcing the wrong description.
> 
> well this has nothing to do with the parent-child discussion, since
> you can obviously reference a regulator independently of its
> position in the DT.
> 
>>>> Another example to think about: the twl4030 is also not a regulator.
>>>> Nevertheless they present some regulator nodes.
>>> 
>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
>>> audio codec and  USB PHY etc etc etc.
>>> 
>>> So in device-tree there is a device-node for the TWL4030, and it has
>>> child-nodes for each sub-device.   They in turn can provide services to other
>>> devices on the board.
>> 
>> Exactly as discussed above. And there, the parent>child relation for the twl4030
>> and its subdevices is right.
>> 
>>> These sub-devices are much more independent of the whole than the regulator
>>> inside the w2sg0004 is.
>> 
>> Hm. That is probably argueable as well. At least a vague ciriterion.
>>> 
>>>> 
>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>>>> but has an internal pbias_regulator that needs to be controlled.
>>> 
>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
>>> device which contains a CPU and multiple other controllers and  communicators
>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
>>> it has a device-node which is a child of the 'ocp' node - which is the main
>>> interconnect in the OMAP3 I think.
>>> 
>>> So I'm not against describing the regulator in the w2sg0004, but for
>>> consistency with everything else, it would need to be child-node of a
>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
>>> that would gain anything.
>> 
>> Well, it would gain consistency how chips with multiple components inside
>> are described.
> 
> I don't think so. Many devices do not expose all of their
> subdevices. e.g. they do not expose their internal clocks.
> Apart from that there are a few devices in the kernel, which
> do use enable-gpio(s).

After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
revise my formulation a little.

It is not that parent>child is used for describing “busses or grouping subdevices".

It is only for “grouping addressable components”, which implies some bus.

This still explains the ocp component of the OMAP3 - which represents the
whole internal “interconnect” bus (see comment in omap3.dtsi).

Therefore you are right. It is not correct to split up a device into arbitrary
components and group them again by the parent>child pattern.

Although the structure of twl4030.dtsi appears to simply list and group
subcomponents without telling explicitly how to address them.

> 
>> And would make it easier to see the whole w2sg0004 a child of /.
> 
> Even with the regulator subdevice I would still make the w2sg0004 a
> child of the UART port.

This would mean that a tty / uart is able to address multiple clients. How
could it do that?

> Main reason is, that I would need to go
> through the UART to “communicate" with the w2sg0004.

You can always "communicate” through the UART. Even without DT. As long as
the connected chip is powered up by any means (could be some fixed-regulator
or hard wired).

Power control for open()/close() did even work with the DT based DTR->virtual-gpio
approach.

We just do not described in the DT that there is a data connection from uart1 to
the RX/TX pins. But you just open /dev/ttyO1.

Thus, describing a relation between the uart node and the GPS chip in the DT is
not even a requirement.

Probably the main problem we have is that we want to describe this data connection
but the device tree is about describing how to address components and data
flow is left to internal APIs. Or “ports” like in the video pipelines.

Let me raise the question:

Why do we need to describe in the DT (independently of Linux power control
structures and drivers!) that the GPS data interface is connected to a specific UART?

Who needs this information and for which purpose?

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 23390 bytes --]

Hi,

On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
> > On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> >> So you propose that the parent->child relationship is “control”? I.e. some
> >> channel which allows to address some bus client (through <reg>) and
> >> control that devices.
> >> 
> >> Makes sense. This is how i2c and spi clients are specified.
> >> 
> >>> 
> >>> In the case of our GPS, it receives control over the serial connection from
> >>> the UART,
> >> 
> >> Ahem - does it?
> >> 
> >> AFAIK the chip simply starts to emit NMEA records if powered on.
> >> There is no command going over the serial interface to address it
> >> or control it.
> > 
> > Right, since GPS basically doesn't need any configuration/control.
> > That’s not true for other UART attached devices, though.
> 
> Do you have an example? Usually an UART data stream is transparently
> presented to a /dev/tty - and user-space daemon can configure/control the
> attached device. In most cases it can mix payload data and control command
> by some AT command and escape sequences.

Yes, but the configuration is minimal. Anyways as you said there
*is* some kind of control happening over the UART.

> >>> also receives control via a GPIO to the on/off pin, and also needs
> >>> a regulator to power the antenna.
> >>> 
> >>> So should the parent be the uart, the on/off GPIO, or the regulator?
> >>> 
> >>> I would much rather there wasn't a parent, and that each of these were listed
> >>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
> >>> (where possible), and the parent is the thing that is “primarily" in control.
> >> 
> >> Well, IMHO the “parent” could also be the root. Representing the
> >> whole board.
> >> 
> >> Nevertheless, I doubt your rule that “ability to control” defines
> >> the parent>child relation (see below).
> >> 
> >>> 
> >>> I think the GPS is “primarily" a uart-attached device.
> >> 
> >> But not in the same way as an I2C device.
> >> 
> >> Especially the serial interface is not a bus and not used for
> >> signalling and power control. It is payload data (only).
> > 
> > Actually many I2C devices are also powered on/off via a GPIO and
> > even use additional GPIOs for sending interrupts. Nevertheless they
> > are normally identified as an I2C device.
> 
> Because I2C is a bus that can address multiple clients and gpio isn’t
> a bus and a point-to-point connection.
> 
> But IMHO it is not because they (can) send payload data over i2c.

From my POV it's not because I2C is a bus, but because the primary
function is happening via I2C (e.g. configuring sensor, gettings its
data). The GPIOs are only needed to compensate some I2C shortcomings
(missing irq feature in I2C) or reduce the complexity of the client
(power GPIO). The actual system interaction with the I2C chip is
going via I2C, though.

> > Also for non-GPS device the serial connection is used for
> > controlling and configuring the device.
> 
> This assumes that “controls a device” is the criterion for making a device
> a subnode. I doubt that.

For me the criterion always was "accessing the device's
registers/configuration/data" from the system's point of view (so
your video port does not count, since it models a connection between
two components without system interaction).

> >>> So I propose a device-node which describes the GPS, which is a child of the
> >>> UART, and explicitly identifies the GPIO it uses to power on/off, the
> >>> regulator it uses to power the antenna, and how it receives "on or off"
> >>> status indications from the GPS.
> >> 
> >> The more I think about that, you have given good arguments *not*
> >> to use the parent->child relationship for the UART interface of
> >> the GPS.
> >> 
> >> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
> >> 1. an USB-Interface for AT signalling and payload
> >> 2. some GPIOs for power control.
> >> 3. a PCM interface for digital voice. 
> >> 4. it might also have a serial interface as alternate AT command and (GPRS
> >>    low speed) payload.
> >> 
> >> So which one is the most prominent or most important to make it a child of?
> >> 
> >> If you use “control” you must make it a child of the USB phy and the serial interface
> >> which requires multiple inheritance…
> >> 
> >> So I am not sure at all. None is IMHO prominent and unique enough to make it
> >> a parent>child relation.
> >> 
> >> Threrefore, I would be happy to see it as multiple children of /. For example a
> >> MFD with subnodes.
> > 
> > This scenario has already been seen before and can happen for
> > non-UART based devices (e.g. SPI + I2C). So far the decision was to
> > postpone the discussion about this kind of devices until one of them
> > appears.
> > 
> >>> It is arguable that the "antenna" should be treated as a separate device - a
> >>> child of the GPS - which controls the regulator and also provides a 'extcon'
> >>> which reports whether an external GPS antenna is attached, or whether the
> >>> internal on is in use.  I haven't made the time to properly explore that
> >>> issue yet.
> >> 
> >> If you assume that parent>child relationship is about control (only). But if it
> >> is about data flow, there is a different concept in DT. For example the CSI/DSI
> >> (OMAP DSS) use the “port” concept.
> > 
> > Yes, this is about data not going to the cpu / system memory.
> 
> Really? The frame buffer data is in system memory and gets to the panel. Or a
> camera image ends up in system memory.

Really? So the panel accesses the system memory? Check again. The
panel is simply connected via DSI/SDI/... and does not access the
system memory at all. The display controller OTH does. So let's have
a look at the DT structure (simplified):

ocp -> dss -> { port = <&panel>; }
... -> spi -> panel { port = <&dss>; }

So the port models a device-to-device connection, which works
independent of the remaining system. No system memory is involved.

> >> This means that indeed parent>child is used for control, e.g. I2C
> >> or SPI to tell the panel controller to switch on.
> > 
> > well parent > child is not about power control, but about "primary"
> > control.
> 
> Can you clearly and precisely define what “primary” control is? I think
> two people will have three opinions about that.
> 
> For example I would see the w2sg0004 on/off gpio as the primary “control”
> which makes the light (NMES records) turned on.
> 
> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?

I never thing of enable gpios to be the main interface, since it can
simply be connected to some voltage and be enabled constantly. It's
just some kind of helper for the device. It does not really exchange
data between the system and the device, though. (Note: This is
not true, if the GPIOs are used for bitbanging some high-level
protocol, in which case a virtual controller (like i2c-gpio) is
modelled in DT).

So let's have a look at the UART link again. It is transporting
non-trivial data from the UART to the system and it is handling
the data I actually want. It's providing access to the device's
"registers".

For me its clear, that one would expect the GPS under the UART
port, since when speaking with other developers I would describe
the GPS as being a "UART attached GPS chip". From me the
differences between a UART port and a SPI port from a system
software's POV can be reduced to missing multi-device support.

> > Some I2C/SPI devices have additional gpios for power
> > control.
> > 
> >> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
> >> bus and the panel is controlled through SPI). Other panels need no control
> >> interface and are simply a child of /.
> > 
> > Yes, some devices do not have an interface worth of being called
> > “primary control" :)
> 
> This is why I criticise this criterion to define when we need a
> parent/child relation.  It is not strict and does not follow a
> principle but opinions.
> 
> But before we stick to opinions, I have studied again:
> 
> 	http://www.devicetree.org/Device_Tree_Usage#Devices
> 
> In their examples (which unfortunately don’t cover our special cases)
> they make clear that subnodes are needed for “addressable” subnodes
> like CPUs, Memory banks, i2c clients, ethernet clients etc.
> 
> (well, the first sentence in “Interrupts” can be read to confirm
> this interpretation: “Unlike address range translation which
> follows the natural structure of the tree”)
> 
> In general I read from this (although it is not explicitly stated)
> that parent>child hierarchy is about addressing bus clients and
> mapping devices into memory address space.
> 
> Everything else is to be done through references.

Actually I think so far we had only one similar case, so its not
obviously a corner case, which is underdocumented. The one similar
case is the HSI subystem, which I maintain (so obviously I'm biased
;)). It's also describing a 1:1 dependency (also serial, but with
multiple logical channels) and uses a child node.

Actually the nokia-modem binding is quite similar to your UART
attached GPS device. It has some GPIOs for power control and even
an additional GPIO for interrupting. The primary interface is still
the HSI one, which exchanges all of the configuration and data.

> >> The video stream and its connections are arranged through such ports.
> >> For the video out management we have added our OPA362 video amplifier into
> >> that video pipeline which starts at the VENC (Video encode) in the SoC,
> >> goes through the OPA362 and ends in the connector (which has its own
> >> node). All this is connected by references. The opa362 node itself is a child
> >> of /: 
> >> 
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
> >> 
> >> So to summarize I now see exactly two cases where parent>child is used:
> >> a) for components of an aggregate device (OMAP3 > I2C controllers)
> >> b) for components connected to a bus controller (I2C > TWL4030)
> >> 
> >> Since the twl regulators are components of the twl chip it completely explains
> >> why we see
> >> 
> >> omap3 > i2c > twl4030 > vaux4
> >> 
> >> Everything else is done by references. Therefore we see references for
> >> * gpios within a controller (independently of it’s relation on a bus)
> >> * regulators
> >> * clocks
> >> * any function that is not connected by a bus
> >> 
> >> There is no need (and practice) to squeeze everything into a parent > child
> >> relationship. And I can’t see your “control” or a “main interface” rule.
> > 
> > And I can't see your bus rule for me the motiviation behind the
> > parent > child relationship is about the system's primary way for
> > accessing a device.
> 
> It appears not to be “my bus rule”. I just formulated in that way from the
> examples I have seen…

yes, me too ;)

> > It's coincidence, that this is currently (always?) a bus connection,
> > since most devices are actually connected using some kind of bus.
> 
> I think the view must be reversed and then it is not a coincidence but a
> consequence.

so show me some non-bus connections, which are actually used to
exchange non-trivial data (with on/off being trivial). We currently
do not really have them.

> >> At least this is my (a little limited) view from using and programming DT for
> >> multiple boards.
> >> 
> >> Maybe this is what the DT list should comment or show a clear definition when
> >> parent>child relations are wanted and when not.
> >> 
> >> Now back to the GPS chip connected to an UART.
> >> 
> >> Is it
> >> a) a component of an aggregate device? no
> >> b) is it connected to a bus (i2c, spi, address bus)? no
> > 
> >> This comes back to the question if UART is a bus.
> >> 
> >> I still think that it is NOT a bus and therefore it should not be modeled in DT
> >> like busses are (enforcing clients to become subnodes).
> > 
> > If I use a SPI device with hardwired chip select its *very* similar
> > to UART.
> 
> Yes, because you can just connect a single client to SPI and then
> question if it is a bus. But that is a useage pattern but not a
> principle.
> 
> And IMHO, DT definitions should follow principles and not current
> need.
> 
> Otherwise I don’t understand why the virtual-gpio connected to
> UART DTR or the regulator is *not* acceptable.

I have missed virtual-gpio UART DTR discussion and assume, that the
regulator is about the regulator on the GPS chip?

I don't think the regulator is not acceptable. I simply think its
not useful. Basically the structure would be

uart {
    /* stuff */
    gps {
        vdd-supply = <&gpsreg>;
        /* stuff */

        gpsreg: regulator {
            enable-gpio = <GPIO 42>;
            /* stuff */
        }
    }
}

and could simply be

uart {
    /* stuff */
    gps {
        enable-gpio = <GPIO 42>;
        /* stuff */
    }
}

Without loosing important information. The regulator would only be
interesting if it is also used by other devices. Other devices also
do not expose their internal clocks etc.

> >> The reason is there no well defined protocol to make multiple clients and
> >> you can’t specify a <reg>.
> >> 
> >> So you are either abusing the notion of a bus or the gps chip must be a separate
> >> DT node (child of something else).
> >> 
> >> I hope my gut feeling that we are trying to do something fundamentally wrong
> >> with making the gps chip a subode of serial is now argued a little better.
> >> 
> >> For making the serial device control some regulator through a reference to
> >> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
> > 
> > NAK about referencing the regulator from the UART node. It should be
> > referenced from the Bluetooth / GPS node. The UART port works
> > without the regulator. It's the remote side, that does not work.
> > We also do not add the regulators of I2C clients to the I2C host.
> 
> I think Pavel made a very good comment:
> 
> The uart node should be able to power a rs232 converter/level shifter directly
> connected to it (through a regulator or gpio-regulator).

Yes and this may belong to the UART node.

> And there must be a separate mechanism to power the remote rs232 converter
> and the remote device.

Yes and I think this goes to the remote device's node.

> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
> UART is not only RX+TX.

so?

> > If you want to talk with an I2C device you enable the I2C device
> > *and* its parent (aka the I2C host controller). I guess the same
> > should be done for the UART.
> > 
> >>>>>> All the following is very special logic for the w2sg0004 chip which should be
> >>>>>> divided out into a separate driver.
> >>>>>> 
> >>>>>> Marek and me already had proposed such a chip specific driver (to be located
> >>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >>>>>> specific and present itself as a regulator (because that is its main purpose:
> >>>>>> control the LDO regulator inside the w2sg0004 chip).
> >>>>> 
> >>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
> >>>> 
> >>>> It has a regulator that can be controlled by a gpio…
> >>> 
> >>> Does it?  I guess may it does.
> >>> Maybe it also has an ARM core and some memory and assorted other bits and
> >>> pieces.  But we don’t really need to describe them to device tree.
> >> 
> >> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
> >> 
> >> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
> >> connected to a GPIO - would tell if the module is really active or not. Using this would
> >> make monitoring the RX line through different pinmux states obsolete.
> >> 
> >> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
> >> not wired the WAKEUP line to a  GPIO.
> >> 
> >>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> >>> devices tree description.  If there are subcomponents that can usefully be
> >>> described as well then there could be a place to describe those subcomponents.
> >>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> >>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> >>> useful to describe the regulator inside the GPS so it could be declare that
> >>> some other device which needed 1V8 made use of that regulator….
> >> 
> >> Yes. Well, even if *we* do not use it in this way yet, we should not make it
> >> difficult for others to do by enforcing the wrong description.
> > 
> > well this has nothing to do with the parent-child discussion, since
> > you can obviously reference a regulator independently of its
> > position in the DT.
> > 
> >>>> Another example to think about: the twl4030 is also not a regulator.
> >>>> Nevertheless they present some regulator nodes.
> >>> 
> >>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
> >>> audio codec and  USB PHY etc etc etc.
> >>> 
> >>> So in device-tree there is a device-node for the TWL4030, and it has
> >>> child-nodes for each sub-device.   They in turn can provide services to other
> >>> devices on the board.
> >> 
> >> Exactly as discussed above. And there, the parent>child relation for the twl4030
> >> and its subdevices is right.
> >> 
> >>> These sub-devices are much more independent of the whole than the regulator
> >>> inside the w2sg0004 is.
> >> 
> >> Hm. That is probably argueable as well. At least a vague ciriterion.
> >>> 
> >>>> 
> >>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> >>>> but has an internal pbias_regulator that needs to be controlled.
> >>> 
> >>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> >>> device which contains a CPU and multiple other controllers and  communicators
> >>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> >>> it has a device-node which is a child of the 'ocp' node - which is the main
> >>> interconnect in the OMAP3 I think.
> >>> 
> >>> So I'm not against describing the regulator in the w2sg0004, but for
> >>> consistency with everything else, it would need to be child-node of a
> >>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> >>> that would gain anything.
> >> 
> >> Well, it would gain consistency how chips with multiple components inside
> >> are described.
> > 
> > I don't think so. Many devices do not expose all of their
> > subdevices. e.g. they do not expose their internal clocks.
> > Apart from that there are a few devices in the kernel, which
> > do use enable-gpio(s).
> 
> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
> revise my formulation a little.
> 
> It is not that parent>child is used for describing “busses or grouping subdevices".
> 
> It is only for “grouping addressable components”, which implies some bus.
> 
> This still explains the ocp component of the OMAP3 - which represents the
> whole internal “interconnect” bus (see comment in omap3.dtsi).
> 
> Therefore you are right. It is not correct to split up a device into arbitrary
> components and group them again by the parent>child pattern.
> 
> Although the structure of twl4030.dtsi appears to simply list and group
> subcomponents without telling explicitly how to address them.

Yes and this style is not only used for twl4030, but also for other
multi function devices. I do not have a problem with splitting up a
device into components as long as they are referenced by other
components. There is no point in exposing all internal information.
For the system its not relevant, that the GPS chip has a 30MHz
clock if its part of the chip and nobody else is using it.

> >> And would make it easier to see the whole w2sg0004 a child of /.
> > 
> > Even with the regulator subdevice I would still make the w2sg0004 a
> > child of the UART port.
> 
> This would mean that a tty / uart is able to address multiple clients. How
> could it do that?

In theory it's possible:

? -> uart -> multiplexer -> { device1, device2 }

I hope nobody will build such a device, though :)

I don't think addressability is important for a parent > child
connection, though. It is important for a reg node, of course.

> > Main reason is, that I would need to go
> > through the UART to “communicate" with the w2sg0004.
> 
> You can always "communicate” through the UART. Even without DT. As
> long as the connected chip is powered up by any means (could be
> some fixed-regulator or hard wired).
> 
> Power control for open()/close() did even work with the DT based
> DTR->virtual-gpio approach.
> 
> We just do not described in the DT that there is a data connection
> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
> 
> Thus, describing a relation between the uart node and the GPS chip
> in the DT is not even a requirement.

It is when the kernel should be able to handle the GPS. The DT is
supposed to be independent from Linux and other operating systems
may want to hide the tty if a GPS is attached to it and instead
provide something like /dev/gps, which could automatically be picked
up by userspace software.

> Probably the main problem we have is that we want to describe this
> data connection but the device tree is about describing how to
> address components and data flow is left to internal APIs. Or
> “ports” like in the video pipelines.

As I wrote the tree structure shows how to "reach" a component for
accessing its configuration/data from the system.

> Let me raise the question:
> 
> Why do we need to describe in the DT (independently of Linux power
> control structures and drivers!) that the GPS data interface is
> connected to a specific UART?
> Who needs this information and for which purpose?

Because an operating system can provide drivers, which completly
hide away the UART connection. Example:

Let's assume we have an UART attached Bluetooth chip connected to
the second UART.

In Linux, userspace currently must know, that the BT module is
connected to this port and correctly setup the port for BT usage.
Once this has been done the port is completly handled in the kernel
and userspace can ignore the UART.

So why must the user configure the port? Because the kernel does not
know, that a BT chip is connected to the port. If the kernel gets
this information from DT it can do all the UART handling itself and
provide a bluetooth device without any user interaction.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 23390 bytes --]

Hi,

On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
> > On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> >> So you propose that the parent->child relationship is “control”? I.e. some
> >> channel which allows to address some bus client (through <reg>) and
> >> control that devices.
> >> 
> >> Makes sense. This is how i2c and spi clients are specified.
> >> 
> >>> 
> >>> In the case of our GPS, it receives control over the serial connection from
> >>> the UART,
> >> 
> >> Ahem - does it?
> >> 
> >> AFAIK the chip simply starts to emit NMEA records if powered on.
> >> There is no command going over the serial interface to address it
> >> or control it.
> > 
> > Right, since GPS basically doesn't need any configuration/control.
> > That’s not true for other UART attached devices, though.
> 
> Do you have an example? Usually an UART data stream is transparently
> presented to a /dev/tty - and user-space daemon can configure/control the
> attached device. In most cases it can mix payload data and control command
> by some AT command and escape sequences.

Yes, but the configuration is minimal. Anyways as you said there
*is* some kind of control happening over the UART.

> >>> also receives control via a GPIO to the on/off pin, and also needs
> >>> a regulator to power the antenna.
> >>> 
> >>> So should the parent be the uart, the on/off GPIO, or the regulator?
> >>> 
> >>> I would much rather there wasn't a parent, and that each of these were listed
> >>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
> >>> (where possible), and the parent is the thing that is “primarily" in control.
> >> 
> >> Well, IMHO the “parent” could also be the root. Representing the
> >> whole board.
> >> 
> >> Nevertheless, I doubt your rule that “ability to control” defines
> >> the parent>child relation (see below).
> >> 
> >>> 
> >>> I think the GPS is “primarily" a uart-attached device.
> >> 
> >> But not in the same way as an I2C device.
> >> 
> >> Especially the serial interface is not a bus and not used for
> >> signalling and power control. It is payload data (only).
> > 
> > Actually many I2C devices are also powered on/off via a GPIO and
> > even use additional GPIOs for sending interrupts. Nevertheless they
> > are normally identified as an I2C device.
> 
> Because I2C is a bus that can address multiple clients and gpio isn’t
> a bus and a point-to-point connection.
> 
> But IMHO it is not because they (can) send payload data over i2c.

From my POV it's not because I2C is a bus, but because the primary
function is happening via I2C (e.g. configuring sensor, gettings its
data). The GPIOs are only needed to compensate some I2C shortcomings
(missing irq feature in I2C) or reduce the complexity of the client
(power GPIO). The actual system interaction with the I2C chip is
going via I2C, though.

> > Also for non-GPS device the serial connection is used for
> > controlling and configuring the device.
> 
> This assumes that “controls a device” is the criterion for making a device
> a subnode. I doubt that.

For me the criterion always was "accessing the device's
registers/configuration/data" from the system's point of view (so
your video port does not count, since it models a connection between
two components without system interaction).

> >>> So I propose a device-node which describes the GPS, which is a child of the
> >>> UART, and explicitly identifies the GPIO it uses to power on/off, the
> >>> regulator it uses to power the antenna, and how it receives "on or off"
> >>> status indications from the GPS.
> >> 
> >> The more I think about that, you have given good arguments *not*
> >> to use the parent->child relationship for the UART interface of
> >> the GPS.
> >> 
> >> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
> >> 1. an USB-Interface for AT signalling and payload
> >> 2. some GPIOs for power control.
> >> 3. a PCM interface for digital voice. 
> >> 4. it might also have a serial interface as alternate AT command and (GPRS
> >>    low speed) payload.
> >> 
> >> So which one is the most prominent or most important to make it a child of?
> >> 
> >> If you use “control” you must make it a child of the USB phy and the serial interface
> >> which requires multiple inheritance…
> >> 
> >> So I am not sure at all. None is IMHO prominent and unique enough to make it
> >> a parent>child relation.
> >> 
> >> Threrefore, I would be happy to see it as multiple children of /. For example a
> >> MFD with subnodes.
> > 
> > This scenario has already been seen before and can happen for
> > non-UART based devices (e.g. SPI + I2C). So far the decision was to
> > postpone the discussion about this kind of devices until one of them
> > appears.
> > 
> >>> It is arguable that the "antenna" should be treated as a separate device - a
> >>> child of the GPS - which controls the regulator and also provides a 'extcon'
> >>> which reports whether an external GPS antenna is attached, or whether the
> >>> internal on is in use.  I haven't made the time to properly explore that
> >>> issue yet.
> >> 
> >> If you assume that parent>child relationship is about control (only). But if it
> >> is about data flow, there is a different concept in DT. For example the CSI/DSI
> >> (OMAP DSS) use the “port” concept.
> > 
> > Yes, this is about data not going to the cpu / system memory.
> 
> Really? The frame buffer data is in system memory and gets to the panel. Or a
> camera image ends up in system memory.

Really? So the panel accesses the system memory? Check again. The
panel is simply connected via DSI/SDI/... and does not access the
system memory at all. The display controller OTH does. So let's have
a look at the DT structure (simplified):

ocp -> dss -> { port = <&panel>; }
... -> spi -> panel { port = <&dss>; }

So the port models a device-to-device connection, which works
independent of the remaining system. No system memory is involved.

> >> This means that indeed parent>child is used for control, e.g. I2C
> >> or SPI to tell the panel controller to switch on.
> > 
> > well parent > child is not about power control, but about "primary"
> > control.
> 
> Can you clearly and precisely define what “primary” control is? I think
> two people will have three opinions about that.
> 
> For example I would see the w2sg0004 on/off gpio as the primary “control”
> which makes the light (NMES records) turned on.
> 
> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?

I never thing of enable gpios to be the main interface, since it can
simply be connected to some voltage and be enabled constantly. It's
just some kind of helper for the device. It does not really exchange
data between the system and the device, though. (Note: This is
not true, if the GPIOs are used for bitbanging some high-level
protocol, in which case a virtual controller (like i2c-gpio) is
modelled in DT).

So let's have a look at the UART link again. It is transporting
non-trivial data from the UART to the system and it is handling
the data I actually want. It's providing access to the device's
"registers".

For me its clear, that one would expect the GPS under the UART
port, since when speaking with other developers I would describe
the GPS as being a "UART attached GPS chip". From me the
differences between a UART port and a SPI port from a system
software's POV can be reduced to missing multi-device support.

> > Some I2C/SPI devices have additional gpios for power
> > control.
> > 
> >> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
> >> bus and the panel is controlled through SPI). Other panels need no control
> >> interface and are simply a child of /.
> > 
> > Yes, some devices do not have an interface worth of being called
> > “primary control" :)
> 
> This is why I criticise this criterion to define when we need a
> parent/child relation.  It is not strict and does not follow a
> principle but opinions.
> 
> But before we stick to opinions, I have studied again:
> 
> 	http://www.devicetree.org/Device_Tree_Usage#Devices
> 
> In their examples (which unfortunately don’t cover our special cases)
> they make clear that subnodes are needed for “addressable” subnodes
> like CPUs, Memory banks, i2c clients, ethernet clients etc.
> 
> (well, the first sentence in “Interrupts” can be read to confirm
> this interpretation: “Unlike address range translation which
> follows the natural structure of the tree”)
> 
> In general I read from this (although it is not explicitly stated)
> that parent>child hierarchy is about addressing bus clients and
> mapping devices into memory address space.
> 
> Everything else is to be done through references.

Actually I think so far we had only one similar case, so its not
obviously a corner case, which is underdocumented. The one similar
case is the HSI subystem, which I maintain (so obviously I'm biased
;)). It's also describing a 1:1 dependency (also serial, but with
multiple logical channels) and uses a child node.

Actually the nokia-modem binding is quite similar to your UART
attached GPS device. It has some GPIOs for power control and even
an additional GPIO for interrupting. The primary interface is still
the HSI one, which exchanges all of the configuration and data.

> >> The video stream and its connections are arranged through such ports.
> >> For the video out management we have added our OPA362 video amplifier into
> >> that video pipeline which starts at the VENC (Video encode) in the SoC,
> >> goes through the OPA362 and ends in the connector (which has its own
> >> node). All this is connected by references. The opa362 node itself is a child
> >> of /: 
> >> 
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
> >> 
> >> So to summarize I now see exactly two cases where parent>child is used:
> >> a) for components of an aggregate device (OMAP3 > I2C controllers)
> >> b) for components connected to a bus controller (I2C > TWL4030)
> >> 
> >> Since the twl regulators are components of the twl chip it completely explains
> >> why we see
> >> 
> >> omap3 > i2c > twl4030 > vaux4
> >> 
> >> Everything else is done by references. Therefore we see references for
> >> * gpios within a controller (independently of it’s relation on a bus)
> >> * regulators
> >> * clocks
> >> * any function that is not connected by a bus
> >> 
> >> There is no need (and practice) to squeeze everything into a parent > child
> >> relationship. And I can’t see your “control” or a “main interface” rule.
> > 
> > And I can't see your bus rule for me the motiviation behind the
> > parent > child relationship is about the system's primary way for
> > accessing a device.
> 
> It appears not to be “my bus rule”. I just formulated in that way from the
> examples I have seen…

yes, me too ;)

> > It's coincidence, that this is currently (always?) a bus connection,
> > since most devices are actually connected using some kind of bus.
> 
> I think the view must be reversed and then it is not a coincidence but a
> consequence.

so show me some non-bus connections, which are actually used to
exchange non-trivial data (with on/off being trivial). We currently
do not really have them.

> >> At least this is my (a little limited) view from using and programming DT for
> >> multiple boards.
> >> 
> >> Maybe this is what the DT list should comment or show a clear definition when
> >> parent>child relations are wanted and when not.
> >> 
> >> Now back to the GPS chip connected to an UART.
> >> 
> >> Is it
> >> a) a component of an aggregate device? no
> >> b) is it connected to a bus (i2c, spi, address bus)? no
> > 
> >> This comes back to the question if UART is a bus.
> >> 
> >> I still think that it is NOT a bus and therefore it should not be modeled in DT
> >> like busses are (enforcing clients to become subnodes).
> > 
> > If I use a SPI device with hardwired chip select its *very* similar
> > to UART.
> 
> Yes, because you can just connect a single client to SPI and then
> question if it is a bus. But that is a useage pattern but not a
> principle.
> 
> And IMHO, DT definitions should follow principles and not current
> need.
> 
> Otherwise I don’t understand why the virtual-gpio connected to
> UART DTR or the regulator is *not* acceptable.

I have missed virtual-gpio UART DTR discussion and assume, that the
regulator is about the regulator on the GPS chip?

I don't think the regulator is not acceptable. I simply think its
not useful. Basically the structure would be

uart {
    /* stuff */
    gps {
        vdd-supply = <&gpsreg>;
        /* stuff */

        gpsreg: regulator {
            enable-gpio = <GPIO 42>;
            /* stuff */
        }
    }
}

and could simply be

uart {
    /* stuff */
    gps {
        enable-gpio = <GPIO 42>;
        /* stuff */
    }
}

Without loosing important information. The regulator would only be
interesting if it is also used by other devices. Other devices also
do not expose their internal clocks etc.

> >> The reason is there no well defined protocol to make multiple clients and
> >> you can’t specify a <reg>.
> >> 
> >> So you are either abusing the notion of a bus or the gps chip must be a separate
> >> DT node (child of something else).
> >> 
> >> I hope my gut feeling that we are trying to do something fundamentally wrong
> >> with making the gps chip a subode of serial is now argued a little better.
> >> 
> >> For making the serial device control some regulator through a reference to
> >> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
> > 
> > NAK about referencing the regulator from the UART node. It should be
> > referenced from the Bluetooth / GPS node. The UART port works
> > without the regulator. It's the remote side, that does not work.
> > We also do not add the regulators of I2C clients to the I2C host.
> 
> I think Pavel made a very good comment:
> 
> The uart node should be able to power a rs232 converter/level shifter directly
> connected to it (through a regulator or gpio-regulator).

Yes and this may belong to the UART node.

> And there must be a separate mechanism to power the remote rs232 converter
> and the remote device.

Yes and I think this goes to the remote device's node.

> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
> UART is not only RX+TX.

so?

> > If you want to talk with an I2C device you enable the I2C device
> > *and* its parent (aka the I2C host controller). I guess the same
> > should be done for the UART.
> > 
> >>>>>> All the following is very special logic for the w2sg0004 chip which should be
> >>>>>> divided out into a separate driver.
> >>>>>> 
> >>>>>> Marek and me already had proposed such a chip specific driver (to be located
> >>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >>>>>> specific and present itself as a regulator (because that is its main purpose:
> >>>>>> control the LDO regulator inside the w2sg0004 chip).
> >>>>> 
> >>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
> >>>> 
> >>>> It has a regulator that can be controlled by a gpio…
> >>> 
> >>> Does it?  I guess may it does.
> >>> Maybe it also has an ARM core and some memory and assorted other bits and
> >>> pieces.  But we don’t really need to describe them to device tree.
> >> 
> >> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
> >> 
> >> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
> >> connected to a GPIO - would tell if the module is really active or not. Using this would
> >> make monitoring the RX line through different pinmux states obsolete.
> >> 
> >> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
> >> not wired the WAKEUP line to a  GPIO.
> >> 
> >>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> >>> devices tree description.  If there are subcomponents that can usefully be
> >>> described as well then there could be a place to describe those subcomponents.
> >>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> >>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> >>> useful to describe the regulator inside the GPS so it could be declare that
> >>> some other device which needed 1V8 made use of that regulator….
> >> 
> >> Yes. Well, even if *we* do not use it in this way yet, we should not make it
> >> difficult for others to do by enforcing the wrong description.
> > 
> > well this has nothing to do with the parent-child discussion, since
> > you can obviously reference a regulator independently of its
> > position in the DT.
> > 
> >>>> Another example to think about: the twl4030 is also not a regulator.
> >>>> Nevertheless they present some regulator nodes.
> >>> 
> >>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
> >>> audio codec and  USB PHY etc etc etc.
> >>> 
> >>> So in device-tree there is a device-node for the TWL4030, and it has
> >>> child-nodes for each sub-device.   They in turn can provide services to other
> >>> devices on the board.
> >> 
> >> Exactly as discussed above. And there, the parent>child relation for the twl4030
> >> and its subdevices is right.
> >> 
> >>> These sub-devices are much more independent of the whole than the regulator
> >>> inside the w2sg0004 is.
> >> 
> >> Hm. That is probably argueable as well. At least a vague ciriterion.
> >>> 
> >>>> 
> >>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> >>>> but has an internal pbias_regulator that needs to be controlled.
> >>> 
> >>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> >>> device which contains a CPU and multiple other controllers and  communicators
> >>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> >>> it has a device-node which is a child of the 'ocp' node - which is the main
> >>> interconnect in the OMAP3 I think.
> >>> 
> >>> So I'm not against describing the regulator in the w2sg0004, but for
> >>> consistency with everything else, it would need to be child-node of a
> >>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> >>> that would gain anything.
> >> 
> >> Well, it would gain consistency how chips with multiple components inside
> >> are described.
> > 
> > I don't think so. Many devices do not expose all of their
> > subdevices. e.g. they do not expose their internal clocks.
> > Apart from that there are a few devices in the kernel, which
> > do use enable-gpio(s).
> 
> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
> revise my formulation a little.
> 
> It is not that parent>child is used for describing “busses or grouping subdevices".
> 
> It is only for “grouping addressable components”, which implies some bus.
> 
> This still explains the ocp component of the OMAP3 - which represents the
> whole internal “interconnect” bus (see comment in omap3.dtsi).
> 
> Therefore you are right. It is not correct to split up a device into arbitrary
> components and group them again by the parent>child pattern.
> 
> Although the structure of twl4030.dtsi appears to simply list and group
> subcomponents without telling explicitly how to address them.

Yes and this style is not only used for twl4030, but also for other
multi function devices. I do not have a problem with splitting up a
device into components as long as they are referenced by other
components. There is no point in exposing all internal information.
For the system its not relevant, that the GPS chip has a 30MHz
clock if its part of the chip and nobody else is using it.

> >> And would make it easier to see the whole w2sg0004 a child of /.
> > 
> > Even with the regulator subdevice I would still make the w2sg0004 a
> > child of the UART port.
> 
> This would mean that a tty / uart is able to address multiple clients. How
> could it do that?

In theory it's possible:

? -> uart -> multiplexer -> { device1, device2 }

I hope nobody will build such a device, though :)

I don't think addressability is important for a parent > child
connection, though. It is important for a reg node, of course.

> > Main reason is, that I would need to go
> > through the UART to “communicate" with the w2sg0004.
> 
> You can always "communicate” through the UART. Even without DT. As
> long as the connected chip is powered up by any means (could be
> some fixed-regulator or hard wired).
> 
> Power control for open()/close() did even work with the DT based
> DTR->virtual-gpio approach.
> 
> We just do not described in the DT that there is a data connection
> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
> 
> Thus, describing a relation between the uart node and the GPS chip
> in the DT is not even a requirement.

It is when the kernel should be able to handle the GPS. The DT is
supposed to be independent from Linux and other operating systems
may want to hide the tty if a GPS is attached to it and instead
provide something like /dev/gps, which could automatically be picked
up by userspace software.

> Probably the main problem we have is that we want to describe this
> data connection but the device tree is about describing how to
> address components and data flow is left to internal APIs. Or
> “ports” like in the video pipelines.

As I wrote the tree structure shows how to "reach" a component for
accessing its configuration/data from the system.

> Let me raise the question:
> 
> Why do we need to describe in the DT (independently of Linux power
> control structures and drivers!) that the GPS data interface is
> connected to a specific UART?
> Who needs this information and for which purpose?

Because an operating system can provide drivers, which completly
hide away the UART connection. Example:

Let's assume we have an UART attached Bluetooth chip connected to
the second UART.

In Linux, userspace currently must know, that the BT module is
connected to this port and correctly setup the port for BT usage.
Once this has been done the port is completly handled in the kernel
and userspace can ignore the UART.

So why must the user configure the port? Because the kernel does not
know, that a BT chip is connected to the port. If the kernel gets
this information from DT it can do all the UART handling itself and
provide a bluetooth device without any user interaction.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 16:21 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
>> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
>>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> So you propose that the parent->child relationship is “control”? I.e. some
>>>> channel which allows to address some bus client (through <reg>) and
>>>> control that devices.
>>>> 
>>>> Makes sense. This is how i2c and spi clients are specified.
>>>> 
>>>>> 
>>>>> In the case of our GPS, it receives control over the serial connection from
>>>>> the UART,
>>>> 
>>>> Ahem - does it?
>>>> 
>>>> AFAIK the chip simply starts to emit NMEA records if powered on.
>>>> There is no command going over the serial interface to address it
>>>> or control it.
>>> 
>>> Right, since GPS basically doesn't need any configuration/control.
>>> That’s not true for other UART attached devices, though.
>> 
>> Do you have an example? Usually an UART data stream is transparently
>> presented to a /dev/tty - and user-space daemon can configure/control the
>> attached device. In most cases it can mix payload data and control command
>> by some AT command and escape sequences.
> 
> Yes, but the configuration is minimal. Anyways as you said there
> *is* some kind of control happening over the UART.

Control is happening on a higher network stack level than UART. It
control is done through AT commands.

> 
>>>>> also receives control via a GPIO to the on/off pin, and also needs
>>>>> a regulator to power the antenna.
>>>>> 
>>>>> So should the parent be the uart, the on/off GPIO, or the regulator?
>>>>> 
>>>>> I would much rather there wasn't a parent, and that each of these were listed
>>>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
>>>>> (where possible), and the parent is the thing that is “primarily" in control.
>>>> 
>>>> Well, IMHO the “parent” could also be the root. Representing the
>>>> whole board.
>>>> 
>>>> Nevertheless, I doubt your rule that “ability to control” defines
>>>> the parent>child relation (see below).
>>>> 
>>>>> 
>>>>> I think the GPS is “primarily" a uart-attached device.
>>>> 
>>>> But not in the same way as an I2C device.
>>>> 
>>>> Especially the serial interface is not a bus and not used for
>>>> signalling and power control. It is payload data (only).
>>> 
>>> Actually many I2C devices are also powered on/off via a GPIO and
>>> even use additional GPIOs for sending interrupts. Nevertheless they
>>> are normally identified as an I2C device.
>> 
>> Because I2C is a bus that can address multiple clients and gpio isn’t
>> a bus and a point-to-point connection.
>> 
>> But IMHO it is not because they (can) send payload data over i2c.
> 
> From my POV it's not because I2C is a bus, but because the primary
> function is happening via I2C (e.g. configuring sensor, gettings its
> data). The GPIOs are only needed to compensate some I2C shortcomings
> (missing irq feature in I2C) or reduce the complexity of the client
> (power GPIO). The actual system interaction with the I2C chip is
> going via I2C, though.

Yes, but this is in my new understanding irrelevant for proper DT description.

> 
>>> Also for non-GPS device the serial connection is used for
>>> controlling and configuring the device.
>> 
>> This assumes that “controls a device” is the criterion for making a device
>> a subnode. I doubt that.
> 
> For me the criterion always was "accessing the device's
> registers/configuration/data" from the system's point of view (so
> your video port does not count, since it models a connection between
> two components without system interaction).

> 
>>>>> So I propose a device-node which describes the GPS, which is a child of the
>>>>> UART, and explicitly identifies the GPIO it uses to power on/off, the
>>>>> regulator it uses to power the antenna, and how it receives "on or off"
>>>>> status indications from the GPS.
>>>> 
>>>> The more I think about that, you have given good arguments *not*
>>>> to use the parent->child relationship for the UART interface of
>>>> the GPS.
>>>> 
>>>> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
>>>> 1. an USB-Interface for AT signalling and payload
>>>> 2. some GPIOs for power control.
>>>> 3. a PCM interface for digital voice. 
>>>> 4. it might also have a serial interface as alternate AT command and (GPRS
>>>>   low speed) payload.
>>>> 
>>>> So which one is the most prominent or most important to make it a child of?
>>>> 
>>>> If you use “control” you must make it a child of the USB phy and the serial interface
>>>> which requires multiple inheritance…
>>>> 
>>>> So I am not sure at all. None is IMHO prominent and unique enough to make it
>>>> a parent>child relation.
>>>> 
>>>> Threrefore, I would be happy to see it as multiple children of /. For example a
>>>> MFD with subnodes.
>>> 
>>> This scenario has already been seen before and can happen for
>>> non-UART based devices (e.g. SPI + I2C). So far the decision was to
>>> postpone the discussion about this kind of devices until one of them
>>> appears.
>>> 
>>>>> It is arguable that the "antenna" should be treated as a separate device - a
>>>>> child of the GPS - which controls the regulator and also provides a 'extcon'
>>>>> which reports whether an external GPS antenna is attached, or whether the
>>>>> internal on is in use.  I haven't made the time to properly explore that
>>>>> issue yet.
>>>> 
>>>> If you assume that parent>child relationship is about control (only). But if it
>>>> is about data flow, there is a different concept in DT. For example the CSI/DSI
>>>> (OMAP DSS) use the “port” concept.
>>> 
>>> Yes, this is about data not going to the cpu / system memory.
>> 
>> Really? The frame buffer data is in system memory and gets to the panel. Or a
>> camera image ends up in system memory.
> 
> Really? So the panel accesses the system memory? Check again. The
> panel is simply connected via DSI/SDI/... and does not access the
> system memory at all. The display controller OTH does. So let's have
> a look at the DT structure (simplified):
> 
> ocp -> dss -> { port = <&panel>; }
> ... -> spi -> panel { port = <&dss>; }
> 
> So the port models a device-to-device connection, which works
> independent of the remaining system. No system memory is involved.

Sorry, but I can’t exactly follow what you want to show.

Yes, the port mechanism describes a device to device connection.

But it does not describe system memory. Although it is the source of
the video (i.e. the framebuffer).

This shows that the DT does not necessarily describe data flow.

So why do you want to describe data flow from tty to uart to some connected
device?

> 
>>>> This means that indeed parent>child is used for control, e.g. I2C
>>>> or SPI to tell the panel controller to switch on.
>>> 
>>> well parent > child is not about power control, but about "primary"
>>> control.
>> 
>> Can you clearly and precisely define what “primary” control is? I think
>> two people will have three opinions about that.
>> 
>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>> which makes the light (NMES records) turned on.
>> 
>> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?
> 
> I never thing of enable gpios to be the main interface, since it can
> simply be connected to some voltage and be enabled constantly. It's
> just some kind of helper for the device. It does not really exchange
> data between the system and the device, though. (Note: This is
> not true, if the GPIOs are used for bitbanging some high-level
> protocol, in which case a virtual controller (like i2c-gpio) is
> modelled in DT).
> 
> So let's have a look at the UART link again. It is transporting
> non-trivial data from the UART to the system and it is handling
> the data I actually want. It's providing access to the device's
> “registers".

Well, this view can be followed, but is as strange and bent to fit
like my view of the w2sg0004 as a “regulator”.

> 
> For me its clear, that one would expect the GPS under the UART
> port, since when speaking with other developers I would describe
> the GPS as being a "UART attached GPS chip". From me the
> differences between a UART port and a SPI port from a system
> software’s POV can be reduced to missing multi-device support.

DT does not necessarily have to describe data flow as we have seen
in the video pipeline example.

> 
>>> Some I2C/SPI devices have additional gpios for power
>>> control.
>>> 
>>>> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
>>>> bus and the panel is controlled through SPI). Other panels need no control
>>>> interface and are simply a child of /.
>>> 
>>> Yes, some devices do not have an interface worth of being called
>>> “primary control" :)
>> 
>> This is why I criticise this criterion to define when we need a
>> parent/child relation.  It is not strict and does not follow a
>> principle but opinions.
>> 
>> But before we stick to opinions, I have studied again:
>> 
>> 	http://www.devicetree.org/Device_Tree_Usage#Devices
>> 
>> In their examples (which unfortunately don’t cover our special cases)
>> they make clear that subnodes are needed for “addressable” subnodes
>> like CPUs, Memory banks, i2c clients, ethernet clients etc.
>> 
>> (well, the first sentence in “Interrupts” can be read to confirm
>> this interpretation: “Unlike address range translation which
>> follows the natural structure of the tree”)
>> 
>> In general I read from this (although it is not explicitly stated)
>> that parent>child hierarchy is about addressing bus clients and
>> mapping devices into memory address space.
>> 
>> Everything else is to be done through references.
> 
> Actually I think so far we had only one similar case, so its not
> obviously a corner case, which is underdocumented. The one similar
> case is the HSI subystem, which I maintain (so obviously I'm biased
> ;)). It's also describing a 1:1 dependency (also serial, but with
> multiple logical channels) and uses a child node.
> 
> Actually the nokia-modem binding is quite similar to your UART
> attached GPS device. It has some GPIOs for power control and even
> an additional GPIO for interrupting. The primary interface is still
> the HSI one, which exchanges all of the configuration and data.
> 
>>>> The video stream and its connections are arranged through such ports.
>>>> For the video out management we have added our OPA362 video amplifier into
>>>> that video pipeline which starts at the VENC (Video encode) in the SoC,
>>>> goes through the OPA362 and ends in the connector (which has its own
>>>> node). All this is connected by references. The opa362 node itself is a child
>>>> of /: 
>>>> 
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
>>>> 
>>>> So to summarize I now see exactly two cases where parent>child is used:
>>>> a) for components of an aggregate device (OMAP3 > I2C controllers)
>>>> b) for components connected to a bus controller (I2C > TWL4030)
>>>> 
>>>> Since the twl regulators are components of the twl chip it completely explains
>>>> why we see
>>>> 
>>>> omap3 > i2c > twl4030 > vaux4
>>>> 
>>>> Everything else is done by references. Therefore we see references for
>>>> * gpios within a controller (independently of it’s relation on a bus)
>>>> * regulators
>>>> * clocks
>>>> * any function that is not connected by a bus
>>>> 
>>>> There is no need (and practice) to squeeze everything into a parent > child
>>>> relationship. And I can’t see your “control” or a “main interface” rule.
>>> 
>>> And I can't see your bus rule for me the motiviation behind the
>>> parent > child relationship is about the system's primary way for
>>> accessing a device.
>> 
>> It appears not to be “my bus rule”. I just formulated in that way from the
>> examples I have seen…
> 
> yes, me too ;)
> 
>>> It's coincidence, that this is currently (always?) a bus connection,
>>> since most devices are actually connected using some kind of bus.
>> 
>> I think the view must be reversed and then it is not a coincidence but a
>> consequence.
> 
> so show me some non-bus connections, which are actually used to
> exchange non-trivial data (with on/off being trivial). We currently
> do not really have them.

Are we talking about DT or data flow from user space through the kernel?

> 
>>>> At least this is my (a little limited) view from using and programming DT for
>>>> multiple boards.
>>>> 
>>>> Maybe this is what the DT list should comment or show a clear definition when
>>>> parent>child relations are wanted and when not.
>>>> 
>>>> Now back to the GPS chip connected to an UART.
>>>> 
>>>> Is it
>>>> a) a component of an aggregate device? no
>>>> b) is it connected to a bus (i2c, spi, address bus)? no
>>> 
>>>> This comes back to the question if UART is a bus.
>>>> 
>>>> I still think that it is NOT a bus and therefore it should not be modeled in DT
>>>> like busses are (enforcing clients to become subnodes).
>>> 
>>> If I use a SPI device with hardwired chip select its *very* similar
>>> to UART.
>> 
>> Yes, because you can just connect a single client to SPI and then
>> question if it is a bus. But that is a useage pattern but not a
>> principle.
>> 
>> And IMHO, DT definitions should follow principles and not current
>> need.
>> 
>> Otherwise I don’t understand why the virtual-gpio connected to
>> UART DTR or the regulator is *not* acceptable.
> 
> I have missed virtual-gpio UART DTR discussion and assume, that the
> regulator is about the regulator on the GPS chip?

Well, it was introduced in platform device kernels that it was possible
to define a dtr-gpio for the uart. And there was a driver for the w2sg0004
that presented itself as a gpio-controller with a single gpio. This “virtual”
gpio was used to power on the chip as soon as DTR was asserted.

Parts of this had been in mainline but have been removed some months
ago.

> 
> I don't think the regulator is not acceptable. I simply think its
> not useful. Basically the structure would be
> 
> uart {
>    /* stuff */
>    gps {
>        vdd-supply = <&gpsreg>;
>        /* stuff */
> 
>        gpsreg: regulator {
>            enable-gpio = <GPIO 42>;
>            /* stuff */
>        }
>    }
> }

Except that the gpsreg is a subnode of /

> 
> and could simply be
> 
> uart {
>    /* stuff */
>    gps {
>        enable-gpio = <GPIO 42>;
>        /* stuff */
>    }
> }
> 
> Without loosing important information.

Only if you assume that the gpsreg must be a subnode of the uart.

> The regulator would only be
> interesting if it is also used by other devices. Other devices also
> do not expose their internal clocks etc.
> 
>>>> The reason is there no well defined protocol to make multiple clients and
>>>> you can’t specify a <reg>.
>>>> 
>>>> So you are either abusing the notion of a bus or the gps chip must be a separate
>>>> DT node (child of something else).
>>>> 
>>>> I hope my gut feeling that we are trying to do something fundamentally wrong
>>>> with making the gps chip a subode of serial is now argued a little better.
>>>> 
>>>> For making the serial device control some regulator through a reference to
>>>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
>>> 
>>> NAK about referencing the regulator from the UART node. It should be
>>> referenced from the Bluetooth / GPS node. The UART port works
>>> without the regulator. It's the remote side, that does not work.
>>> We also do not add the regulators of I2C clients to the I2C host.
>> 
>> I think Pavel made a very good comment:
>> 
>> The uart node should be able to power a rs232 converter/level shifter directly
>> connected to it (through a regulator or gpio-regulator).
> 
> Yes and this may belong to the UART node.
> 
>> And there must be a separate mechanism to power the remote rs232 converter
>> and the remote device.
> 
> Yes and I think this goes to the remote device's node.
> 
>> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
>> UART is not only RX+TX.
> 
> so?

You said NAK about referencing a regulator from the UART node and now?

> 
>>> If you want to talk with an I2C device you enable the I2C device
>>> *and* its parent (aka the I2C host controller). I guess the same
>>> should be done for the UART.
>>> 
>>>>>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>>>>>> divided out into a separate driver.
>>>>>>>> 
>>>>>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>>>>>> specific and present itself as a regulator (because that is its main purpose:
>>>>>>>> control the LDO regulator inside the w2sg0004 chip).
>>>>>>> 
>>>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>>>>>> 
>>>>>> It has a regulator that can be controlled by a gpio…
>>>>> 
>>>>> Does it?  I guess may it does.
>>>>> Maybe it also has an ARM core and some memory and assorted other bits and
>>>>> pieces.  But we don’t really need to describe them to device tree.
>>>> 
>>>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
>>>> 
>>>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
>>>> connected to a GPIO - would tell if the module is really active or not. Using this would
>>>> make monitoring the RX line through different pinmux states obsolete.
>>>> 
>>>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
>>>> not wired the WAKEUP line to a  GPIO.
>>>> 
>>>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
>>>>> devices tree description.  If there are subcomponents that can usefully be
>>>>> described as well then there could be a place to describe those subcomponents.
>>>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
>>>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
>>>>> useful to describe the regulator inside the GPS so it could be declare that
>>>>> some other device which needed 1V8 made use of that regulator….
>>>> 
>>>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
>>>> difficult for others to do by enforcing the wrong description.
>>> 
>>> well this has nothing to do with the parent-child discussion, since
>>> you can obviously reference a regulator independently of its
>>> position in the DT.
>>> 
>>>>>> Another example to think about: the twl4030 is also not a regulator.
>>>>>> Nevertheless they present some regulator nodes.
>>>>> 
>>>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
>>>>> audio codec and  USB PHY etc etc etc.
>>>>> 
>>>>> So in device-tree there is a device-node for the TWL4030, and it has
>>>>> child-nodes for each sub-device.   They in turn can provide services to other
>>>>> devices on the board.
>>>> 
>>>> Exactly as discussed above. And there, the parent>child relation for the twl4030
>>>> and its subdevices is right.
>>>> 
>>>>> These sub-devices are much more independent of the whole than the regulator
>>>>> inside the w2sg0004 is.
>>>> 
>>>> Hm. That is probably argueable as well. At least a vague ciriterion.
>>>>> 
>>>>>> 
>>>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>>>>>> but has an internal pbias_regulator that needs to be controlled.
>>>>> 
>>>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
>>>>> device which contains a CPU and multiple other controllers and  communicators
>>>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
>>>>> it has a device-node which is a child of the 'ocp' node - which is the main
>>>>> interconnect in the OMAP3 I think.
>>>>> 
>>>>> So I'm not against describing the regulator in the w2sg0004, but for
>>>>> consistency with everything else, it would need to be child-node of a
>>>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
>>>>> that would gain anything.
>>>> 
>>>> Well, it would gain consistency how chips with multiple components inside
>>>> are described.
>>> 
>>> I don't think so. Many devices do not expose all of their
>>> subdevices. e.g. they do not expose their internal clocks.
>>> Apart from that there are a few devices in the kernel, which
>>> do use enable-gpio(s).
>> 
>> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
>> revise my formulation a little.
>> 
>> It is not that parent>child is used for describing “busses or grouping subdevices".
>> 
>> It is only for “grouping addressable components”, which implies some bus.
>> 
>> This still explains the ocp component of the OMAP3 - which represents the
>> whole internal “interconnect” bus (see comment in omap3.dtsi).
>> 
>> Therefore you are right. It is not correct to split up a device into arbitrary
>> components and group them again by the parent>child pattern.
>> 
>> Although the structure of twl4030.dtsi appears to simply list and group
>> subcomponents without telling explicitly how to address them.
> 
> Yes and this style is not only used for twl4030, but also for other
> multi function devices. I do not have a problem with splitting up a
> device into components as long as they are referenced by other
> components. There is no point in exposing all internal information.
> For the system its not relevant, that the GPS chip has a 30MHz
> clock if its part of the chip and nobody else is using it.
> 
>>>> And would make it easier to see the whole w2sg0004 a child of /.
>>> 
>>> Even with the regulator subdevice I would still make the w2sg0004 a
>>> child of the UART port.
>> 
>> This would mean that a tty / uart is able to address multiple clients. How
>> could it do that?
> 
> In theory it's possible:
> 
> ? -> uart -> multiplexer -> { device1, device2 }
> 
> I hope nobody will build such a device, though :)
> 
> I don't think addressability is important for a parent > child
> connection, though. It is important for a reg node, of course.

That is the key question I am trying to get founded answers, not opinions :)

> 
>>> Main reason is, that I would need to go
>>> through the UART to “communicate" with the w2sg0004.
>> 
>> You can always "communicate” through the UART. Even without DT. As
>> long as the connected chip is powered up by any means (could be
>> some fixed-regulator or hard wired).
>> 
>> Power control for open()/close() did even work with the DT based
>> DTR->virtual-gpio approach.
>> 
>> We just do not described in the DT that there is a data connection
>> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
>> 
>> Thus, describing a relation between the uart node and the GPS chip
>> in the DT is not even a requirement.
> 
> It is when the kernel should be able to handle the GPS. The DT is
> supposed to be independent from Linux and other operating systems
> may want to hide the tty if a GPS is attached to it and instead
> provide something like /dev/gps, which could automatically be picked
> up by userspace software.

Well, it is difficult to cover all future use cases.

But then you can still add a uart = <&uart1> reference to the DT node
of the driver. Because I understand that then the driver is the master
(and needs access to a hidden UART) and not the GPS chip a slave of
an exposed UART.

> 
>> Probably the main problem we have is that we want to describe this
>> data connection but the device tree is about describing how to
>> address components and data flow is left to internal APIs. Or
>> “ports” like in the video pipelines.
> 
> As I wrote the tree structure shows how to "reach" a component for
> accessing its configuration/data from the system.

Yes, you wrote and I already pointed out that I disagree. It contradicts
what

http://www.devicetree.org/Device_Tree_Usage#Devices

appears to tell me. So who is right?

> 
>> Let me raise the question:
>> 
>> Why do we need to describe in the DT (independently of Linux power
>> control structures and drivers!) that the GPS data interface is
>> connected to a specific UART?
>> Who needs this information and for which purpose?
> 
> Because an operating system can provide drivers, which completly
> hide away the UART connection. Example:
> 
> Let's assume we have an UART attached Bluetooth chip connected to
> the second UART.
> 
> In Linux, userspace currently must know, that the BT module is
> connected to this port and correctly setup the port for BT usage.
> Once this has been done the port is completly handled in the kernel
> and userspace can ignore the UART.

Ok, this is a reasonable example. But I still don’ see that it requires that the
bt chip must be a subnode of the uart.

> 
> So why must the user configure the port? Because the kernel does not
> know, that a BT chip is connected to the port.

Then, I would suggest to write it like you have done:

“the BT chip is connected to the port uart1”

This can be easily translated into DT language:

/ {
	bt {
		compatible = “vendor,chip”;
		uart = <&uart1>;	/* this chip is connected to uart1 */
		enable-gpio = <&gpio3 17 0>;
	};
};

This also resembles the “port” mechanism (just simplified because it is not
a backwards forward linkage).

Or exactly follows the pattern that a driver that wants to use some gpio simply
links to the gpio controller. Or a driver wants to control a gpio.

What I don’t understand is what is here so special to not use this DT pattern.

But It could also open a different solution for the tty open() -> w2sg power on problem.

/ {
	gps {
		compatible = “wi2wi,w2sg0004”;
		uart = <&uart1>;	/* this chip is connected to uart1 */
		enable-gpio = <&gpio3 17 0>;
	};
};

Here, the w2sg0004 probe function could register with uart1 to get notified
about open/close events and then do what it has to do.

In that case the w2sg0004 driver would not even need to present itself
as a virtual gpio (for DTR) or a regulator because it has a kernel internal
API to apply to tell the uart what it wants to do.

> If the kernel gets
> this information from DT it can do all the UART handling itself and
> provide a bluetooth device without any user interaction.

I think we should get a better understanding of the DT design patterns.

IMHO (or IMPoV):

* parent>child is not for describing “control” or “primary interface” but addressability
* if a driver needs access to another component, a reference property is used

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 16:21 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
>> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
>>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> So you propose that the parent->child relationship is “control”? I.e. some
>>>> channel which allows to address some bus client (through <reg>) and
>>>> control that devices.
>>>> 
>>>> Makes sense. This is how i2c and spi clients are specified.
>>>> 
>>>>> 
>>>>> In the case of our GPS, it receives control over the serial connection from
>>>>> the UART,
>>>> 
>>>> Ahem - does it?
>>>> 
>>>> AFAIK the chip simply starts to emit NMEA records if powered on.
>>>> There is no command going over the serial interface to address it
>>>> or control it.
>>> 
>>> Right, since GPS basically doesn't need any configuration/control.
>>> That’s not true for other UART attached devices, though.
>> 
>> Do you have an example? Usually an UART data stream is transparently
>> presented to a /dev/tty - and user-space daemon can configure/control the
>> attached device. In most cases it can mix payload data and control command
>> by some AT command and escape sequences.
> 
> Yes, but the configuration is minimal. Anyways as you said there
> *is* some kind of control happening over the UART.

Control is happening on a higher network stack level than UART. It
control is done through AT commands.

> 
>>>>> also receives control via a GPIO to the on/off pin, and also needs
>>>>> a regulator to power the antenna.
>>>>> 
>>>>> So should the parent be the uart, the on/off GPIO, or the regulator?
>>>>> 
>>>>> I would much rather there wasn't a parent, and that each of these were listed
>>>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
>>>>> (where possible), and the parent is the thing that is “primarily" in control.
>>>> 
>>>> Well, IMHO the “parent” could also be the root. Representing the
>>>> whole board.
>>>> 
>>>> Nevertheless, I doubt your rule that “ability to control” defines
>>>> the parent>child relation (see below).
>>>> 
>>>>> 
>>>>> I think the GPS is “primarily" a uart-attached device.
>>>> 
>>>> But not in the same way as an I2C device.
>>>> 
>>>> Especially the serial interface is not a bus and not used for
>>>> signalling and power control. It is payload data (only).
>>> 
>>> Actually many I2C devices are also powered on/off via a GPIO and
>>> even use additional GPIOs for sending interrupts. Nevertheless they
>>> are normally identified as an I2C device.
>> 
>> Because I2C is a bus that can address multiple clients and gpio isn’t
>> a bus and a point-to-point connection.
>> 
>> But IMHO it is not because they (can) send payload data over i2c.
> 
> From my POV it's not because I2C is a bus, but because the primary
> function is happening via I2C (e.g. configuring sensor, gettings its
> data). The GPIOs are only needed to compensate some I2C shortcomings
> (missing irq feature in I2C) or reduce the complexity of the client
> (power GPIO). The actual system interaction with the I2C chip is
> going via I2C, though.

Yes, but this is in my new understanding irrelevant for proper DT description.

> 
>>> Also for non-GPS device the serial connection is used for
>>> controlling and configuring the device.
>> 
>> This assumes that “controls a device” is the criterion for making a device
>> a subnode. I doubt that.
> 
> For me the criterion always was "accessing the device's
> registers/configuration/data" from the system's point of view (so
> your video port does not count, since it models a connection between
> two components without system interaction).

> 
>>>>> So I propose a device-node which describes the GPS, which is a child of the
>>>>> UART, and explicitly identifies the GPIO it uses to power on/off, the
>>>>> regulator it uses to power the antenna, and how it receives "on or off"
>>>>> status indications from the GPS.
>>>> 
>>>> The more I think about that, you have given good arguments *not*
>>>> to use the parent->child relationship for the UART interface of
>>>> the GPS.
>>>> 
>>>> Let me give another example. The 3G Modem has 3 (or 4) interfaces:
>>>> 1. an USB-Interface for AT signalling and payload
>>>> 2. some GPIOs for power control.
>>>> 3. a PCM interface for digital voice. 
>>>> 4. it might also have a serial interface as alternate AT command and (GPRS
>>>>   low speed) payload.
>>>> 
>>>> So which one is the most prominent or most important to make it a child of?
>>>> 
>>>> If you use “control” you must make it a child of the USB phy and the serial interface
>>>> which requires multiple inheritance…
>>>> 
>>>> So I am not sure at all. None is IMHO prominent and unique enough to make it
>>>> a parent>child relation.
>>>> 
>>>> Threrefore, I would be happy to see it as multiple children of /. For example a
>>>> MFD with subnodes.
>>> 
>>> This scenario has already been seen before and can happen for
>>> non-UART based devices (e.g. SPI + I2C). So far the decision was to
>>> postpone the discussion about this kind of devices until one of them
>>> appears.
>>> 
>>>>> It is arguable that the "antenna" should be treated as a separate device - a
>>>>> child of the GPS - which controls the regulator and also provides a 'extcon'
>>>>> which reports whether an external GPS antenna is attached, or whether the
>>>>> internal on is in use.  I haven't made the time to properly explore that
>>>>> issue yet.
>>>> 
>>>> If you assume that parent>child relationship is about control (only). But if it
>>>> is about data flow, there is a different concept in DT. For example the CSI/DSI
>>>> (OMAP DSS) use the “port” concept.
>>> 
>>> Yes, this is about data not going to the cpu / system memory.
>> 
>> Really? The frame buffer data is in system memory and gets to the panel. Or a
>> camera image ends up in system memory.
> 
> Really? So the panel accesses the system memory? Check again. The
> panel is simply connected via DSI/SDI/... and does not access the
> system memory at all. The display controller OTH does. So let's have
> a look at the DT structure (simplified):
> 
> ocp -> dss -> { port = <&panel>; }
> ... -> spi -> panel { port = <&dss>; }
> 
> So the port models a device-to-device connection, which works
> independent of the remaining system. No system memory is involved.

Sorry, but I can’t exactly follow what you want to show.

Yes, the port mechanism describes a device to device connection.

But it does not describe system memory. Although it is the source of
the video (i.e. the framebuffer).

This shows that the DT does not necessarily describe data flow.

So why do you want to describe data flow from tty to uart to some connected
device?

> 
>>>> This means that indeed parent>child is used for control, e.g. I2C
>>>> or SPI to tell the panel controller to switch on.
>>> 
>>> well parent > child is not about power control, but about "primary"
>>> control.
>> 
>> Can you clearly and precisely define what “primary” control is? I think
>> two people will have three opinions about that.
>> 
>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>> which makes the light (NMES records) turned on.
>> 
>> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?
> 
> I never thing of enable gpios to be the main interface, since it can
> simply be connected to some voltage and be enabled constantly. It's
> just some kind of helper for the device. It does not really exchange
> data between the system and the device, though. (Note: This is
> not true, if the GPIOs are used for bitbanging some high-level
> protocol, in which case a virtual controller (like i2c-gpio) is
> modelled in DT).
> 
> So let's have a look at the UART link again. It is transporting
> non-trivial data from the UART to the system and it is handling
> the data I actually want. It's providing access to the device's
> “registers".

Well, this view can be followed, but is as strange and bent to fit
like my view of the w2sg0004 as a “regulator”.

> 
> For me its clear, that one would expect the GPS under the UART
> port, since when speaking with other developers I would describe
> the GPS as being a "UART attached GPS chip". From me the
> differences between a UART port and a SPI port from a system
> software’s POV can be reduced to missing multi-device support.

DT does not necessarily have to describe data flow as we have seen
in the video pipeline example.

> 
>>> Some I2C/SPI devices have additional gpios for power
>>> control.
>>> 
>>>> For example we have the GTA04 panel as a subnode of SPI (because SPI is a
>>>> bus and the panel is controlled through SPI). Other panels need no control
>>>> interface and are simply a child of /.
>>> 
>>> Yes, some devices do not have an interface worth of being called
>>> “primary control" :)
>> 
>> This is why I criticise this criterion to define when we need a
>> parent/child relation.  It is not strict and does not follow a
>> principle but opinions.
>> 
>> But before we stick to opinions, I have studied again:
>> 
>> 	http://www.devicetree.org/Device_Tree_Usage#Devices
>> 
>> In their examples (which unfortunately don’t cover our special cases)
>> they make clear that subnodes are needed for “addressable” subnodes
>> like CPUs, Memory banks, i2c clients, ethernet clients etc.
>> 
>> (well, the first sentence in “Interrupts” can be read to confirm
>> this interpretation: “Unlike address range translation which
>> follows the natural structure of the tree”)
>> 
>> In general I read from this (although it is not explicitly stated)
>> that parent>child hierarchy is about addressing bus clients and
>> mapping devices into memory address space.
>> 
>> Everything else is to be done through references.
> 
> Actually I think so far we had only one similar case, so its not
> obviously a corner case, which is underdocumented. The one similar
> case is the HSI subystem, which I maintain (so obviously I'm biased
> ;)). It's also describing a 1:1 dependency (also serial, but with
> multiple logical channels) and uses a child node.
> 
> Actually the nokia-modem binding is quite similar to your UART
> attached GPS device. It has some GPIOs for power control and even
> an additional GPIO for interrupting. The primary interface is still
> the HSI one, which exchanges all of the configuration and data.
> 
>>>> The video stream and its connections are arranged through such ports.
>>>> For the video out management we have added our OPA362 video amplifier into
>>>> that video pipeline which starts at the VENC (Video encode) in the SoC,
>>>> goes through the OPA362 and ends in the connector (which has its own
>>>> node). All this is connected by references. The opa362 node itself is a child
>>>> of /: 
>>>> 
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-gta04.dtsi?id=refs/tags/v4.0-rc5#n98
>>>> 
>>>> So to summarize I now see exactly two cases where parent>child is used:
>>>> a) for components of an aggregate device (OMAP3 > I2C controllers)
>>>> b) for components connected to a bus controller (I2C > TWL4030)
>>>> 
>>>> Since the twl regulators are components of the twl chip it completely explains
>>>> why we see
>>>> 
>>>> omap3 > i2c > twl4030 > vaux4
>>>> 
>>>> Everything else is done by references. Therefore we see references for
>>>> * gpios within a controller (independently of it’s relation on a bus)
>>>> * regulators
>>>> * clocks
>>>> * any function that is not connected by a bus
>>>> 
>>>> There is no need (and practice) to squeeze everything into a parent > child
>>>> relationship. And I can’t see your “control” or a “main interface” rule.
>>> 
>>> And I can't see your bus rule for me the motiviation behind the
>>> parent > child relationship is about the system's primary way for
>>> accessing a device.
>> 
>> It appears not to be “my bus rule”. I just formulated in that way from the
>> examples I have seen…
> 
> yes, me too ;)
> 
>>> It's coincidence, that this is currently (always?) a bus connection,
>>> since most devices are actually connected using some kind of bus.
>> 
>> I think the view must be reversed and then it is not a coincidence but a
>> consequence.
> 
> so show me some non-bus connections, which are actually used to
> exchange non-trivial data (with on/off being trivial). We currently
> do not really have them.

Are we talking about DT or data flow from user space through the kernel?

> 
>>>> At least this is my (a little limited) view from using and programming DT for
>>>> multiple boards.
>>>> 
>>>> Maybe this is what the DT list should comment or show a clear definition when
>>>> parent>child relations are wanted and when not.
>>>> 
>>>> Now back to the GPS chip connected to an UART.
>>>> 
>>>> Is it
>>>> a) a component of an aggregate device? no
>>>> b) is it connected to a bus (i2c, spi, address bus)? no
>>> 
>>>> This comes back to the question if UART is a bus.
>>>> 
>>>> I still think that it is NOT a bus and therefore it should not be modeled in DT
>>>> like busses are (enforcing clients to become subnodes).
>>> 
>>> If I use a SPI device with hardwired chip select its *very* similar
>>> to UART.
>> 
>> Yes, because you can just connect a single client to SPI and then
>> question if it is a bus. But that is a useage pattern but not a
>> principle.
>> 
>> And IMHO, DT definitions should follow principles and not current
>> need.
>> 
>> Otherwise I don’t understand why the virtual-gpio connected to
>> UART DTR or the regulator is *not* acceptable.
> 
> I have missed virtual-gpio UART DTR discussion and assume, that the
> regulator is about the regulator on the GPS chip?

Well, it was introduced in platform device kernels that it was possible
to define a dtr-gpio for the uart. And there was a driver for the w2sg0004
that presented itself as a gpio-controller with a single gpio. This “virtual”
gpio was used to power on the chip as soon as DTR was asserted.

Parts of this had been in mainline but have been removed some months
ago.

> 
> I don't think the regulator is not acceptable. I simply think its
> not useful. Basically the structure would be
> 
> uart {
>    /* stuff */
>    gps {
>        vdd-supply = <&gpsreg>;
>        /* stuff */
> 
>        gpsreg: regulator {
>            enable-gpio = <GPIO 42>;
>            /* stuff */
>        }
>    }
> }

Except that the gpsreg is a subnode of /

> 
> and could simply be
> 
> uart {
>    /* stuff */
>    gps {
>        enable-gpio = <GPIO 42>;
>        /* stuff */
>    }
> }
> 
> Without loosing important information.

Only if you assume that the gpsreg must be a subnode of the uart.

> The regulator would only be
> interesting if it is also used by other devices. Other devices also
> do not expose their internal clocks etc.
> 
>>>> The reason is there no well defined protocol to make multiple clients and
>>>> you can’t specify a <reg>.
>>>> 
>>>> So you are either abusing the notion of a bus or the gps chip must be a separate
>>>> DT node (child of something else).
>>>> 
>>>> I hope my gut feeling that we are trying to do something fundamentally wrong
>>>> with making the gps chip a subode of serial is now argued a little better.
>>>> 
>>>> For making the serial device control some regulator through a reference to
>>>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
>>> 
>>> NAK about referencing the regulator from the UART node. It should be
>>> referenced from the Bluetooth / GPS node. The UART port works
>>> without the regulator. It's the remote side, that does not work.
>>> We also do not add the regulators of I2C clients to the I2C host.
>> 
>> I think Pavel made a very good comment:
>> 
>> The uart node should be able to power a rs232 converter/level shifter directly
>> connected to it (through a regulator or gpio-regulator).
> 
> Yes and this may belong to the UART node.
> 
>> And there must be a separate mechanism to power the remote rs232 converter
>> and the remote device.
> 
> Yes and I think this goes to the remote device's node.
> 
>> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
>> UART is not only RX+TX.
> 
> so?

You said NAK about referencing a regulator from the UART node and now?

> 
>>> If you want to talk with an I2C device you enable the I2C device
>>> *and* its parent (aka the I2C host controller). I guess the same
>>> should be done for the UART.
>>> 
>>>>>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>>>>>> divided out into a separate driver.
>>>>>>>> 
>>>>>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>>>>>> specific and present itself as a regulator (because that is its main purpose:
>>>>>>>> control the LDO regulator inside the w2sg0004 chip).
>>>>>>> 
>>>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>>>>>> 
>>>>>> It has a regulator that can be controlled by a gpio…
>>>>> 
>>>>> Does it?  I guess may it does.
>>>>> Maybe it also has an ARM core and some memory and assorted other bits and
>>>>> pieces.  But we don’t really need to describe them to device tree.
>>>> 
>>>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
>>>> 
>>>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
>>>> connected to a GPIO - would tell if the module is really active or not. Using this would
>>>> make monitoring the RX line through different pinmux states obsolete.
>>>> 
>>>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
>>>> not wired the WAKEUP line to a  GPIO.
>>>> 
>>>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
>>>>> devices tree description.  If there are subcomponents that can usefully be
>>>>> described as well then there could be a place to describe those subcomponents.
>>>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
>>>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
>>>>> useful to describe the regulator inside the GPS so it could be declare that
>>>>> some other device which needed 1V8 made use of that regulator….
>>>> 
>>>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
>>>> difficult for others to do by enforcing the wrong description.
>>> 
>>> well this has nothing to do with the parent-child discussion, since
>>> you can obviously reference a regulator independently of its
>>> position in the DT.
>>> 
>>>>>> Another example to think about: the twl4030 is also not a regulator.
>>>>>> Nevertheless they present some regulator nodes.
>>>>> 
>>>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
>>>>> audio codec and  USB PHY etc etc etc.
>>>>> 
>>>>> So in device-tree there is a device-node for the TWL4030, and it has
>>>>> child-nodes for each sub-device.   They in turn can provide services to other
>>>>> devices on the board.
>>>> 
>>>> Exactly as discussed above. And there, the parent>child relation for the twl4030
>>>> and its subdevices is right.
>>>> 
>>>>> These sub-devices are much more independent of the whole than the regulator
>>>>> inside the w2sg0004 is.
>>>> 
>>>> Hm. That is probably argueable as well. At least a vague ciriterion.
>>>>> 
>>>>>> 
>>>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>>>>>> but has an internal pbias_regulator that needs to be controlled.
>>>>> 
>>>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
>>>>> device which contains a CPU and multiple other controllers and  communicators
>>>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
>>>>> it has a device-node which is a child of the 'ocp' node - which is the main
>>>>> interconnect in the OMAP3 I think.
>>>>> 
>>>>> So I'm not against describing the regulator in the w2sg0004, but for
>>>>> consistency with everything else, it would need to be child-node of a
>>>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
>>>>> that would gain anything.
>>>> 
>>>> Well, it would gain consistency how chips with multiple components inside
>>>> are described.
>>> 
>>> I don't think so. Many devices do not expose all of their
>>> subdevices. e.g. they do not expose their internal clocks.
>>> Apart from that there are a few devices in the kernel, which
>>> do use enable-gpio(s).
>> 
>> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
>> revise my formulation a little.
>> 
>> It is not that parent>child is used for describing “busses or grouping subdevices".
>> 
>> It is only for “grouping addressable components”, which implies some bus.
>> 
>> This still explains the ocp component of the OMAP3 - which represents the
>> whole internal “interconnect” bus (see comment in omap3.dtsi).
>> 
>> Therefore you are right. It is not correct to split up a device into arbitrary
>> components and group them again by the parent>child pattern.
>> 
>> Although the structure of twl4030.dtsi appears to simply list and group
>> subcomponents without telling explicitly how to address them.
> 
> Yes and this style is not only used for twl4030, but also for other
> multi function devices. I do not have a problem with splitting up a
> device into components as long as they are referenced by other
> components. There is no point in exposing all internal information.
> For the system its not relevant, that the GPS chip has a 30MHz
> clock if its part of the chip and nobody else is using it.
> 
>>>> And would make it easier to see the whole w2sg0004 a child of /.
>>> 
>>> Even with the regulator subdevice I would still make the w2sg0004 a
>>> child of the UART port.
>> 
>> This would mean that a tty / uart is able to address multiple clients. How
>> could it do that?
> 
> In theory it's possible:
> 
> ? -> uart -> multiplexer -> { device1, device2 }
> 
> I hope nobody will build such a device, though :)
> 
> I don't think addressability is important for a parent > child
> connection, though. It is important for a reg node, of course.

That is the key question I am trying to get founded answers, not opinions :)

> 
>>> Main reason is, that I would need to go
>>> through the UART to “communicate" with the w2sg0004.
>> 
>> You can always "communicate” through the UART. Even without DT. As
>> long as the connected chip is powered up by any means (could be
>> some fixed-regulator or hard wired).
>> 
>> Power control for open()/close() did even work with the DT based
>> DTR->virtual-gpio approach.
>> 
>> We just do not described in the DT that there is a data connection
>> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
>> 
>> Thus, describing a relation between the uart node and the GPS chip
>> in the DT is not even a requirement.
> 
> It is when the kernel should be able to handle the GPS. The DT is
> supposed to be independent from Linux and other operating systems
> may want to hide the tty if a GPS is attached to it and instead
> provide something like /dev/gps, which could automatically be picked
> up by userspace software.

Well, it is difficult to cover all future use cases.

But then you can still add a uart = <&uart1> reference to the DT node
of the driver. Because I understand that then the driver is the master
(and needs access to a hidden UART) and not the GPS chip a slave of
an exposed UART.

> 
>> Probably the main problem we have is that we want to describe this
>> data connection but the device tree is about describing how to
>> address components and data flow is left to internal APIs. Or
>> “ports” like in the video pipelines.
> 
> As I wrote the tree structure shows how to "reach" a component for
> accessing its configuration/data from the system.

Yes, you wrote and I already pointed out that I disagree. It contradicts
what

http://www.devicetree.org/Device_Tree_Usage#Devices

appears to tell me. So who is right?

> 
>> Let me raise the question:
>> 
>> Why do we need to describe in the DT (independently of Linux power
>> control structures and drivers!) that the GPS data interface is
>> connected to a specific UART?
>> Who needs this information and for which purpose?
> 
> Because an operating system can provide drivers, which completly
> hide away the UART connection. Example:
> 
> Let's assume we have an UART attached Bluetooth chip connected to
> the second UART.
> 
> In Linux, userspace currently must know, that the BT module is
> connected to this port and correctly setup the port for BT usage.
> Once this has been done the port is completly handled in the kernel
> and userspace can ignore the UART.

Ok, this is a reasonable example. But I still don’ see that it requires that the
bt chip must be a subnode of the uart.

> 
> So why must the user configure the port? Because the kernel does not
> know, that a BT chip is connected to the port.

Then, I would suggest to write it like you have done:

“the BT chip is connected to the port uart1”

This can be easily translated into DT language:

/ {
	bt {
		compatible = “vendor,chip”;
		uart = <&uart1>;	/* this chip is connected to uart1 */
		enable-gpio = <&gpio3 17 0>;
	};
};

This also resembles the “port” mechanism (just simplified because it is not
a backwards forward linkage).

Or exactly follows the pattern that a driver that wants to use some gpio simply
links to the gpio controller. Or a driver wants to control a gpio.

What I don’t understand is what is here so special to not use this DT pattern.

But It could also open a different solution for the tty open() -> w2sg power on problem.

/ {
	gps {
		compatible = “wi2wi,w2sg0004”;
		uart = <&uart1>;	/* this chip is connected to uart1 */
		enable-gpio = <&gpio3 17 0>;
	};
};

Here, the w2sg0004 probe function could register with uart1 to get notified
about open/close events and then do what it has to do.

In that case the w2sg0004 driver would not even need to present itself
as a virtual gpio (for DTR) or a regulator because it has a kernel internal
API to apply to tell the uart what it wants to do.

> If the kernel gets
> this information from DT it can do all the UART handling itself and
> provide a bluetooth device without any user interaction.

I think we should get a better understanding of the DT design patterns.

IMHO (or IMPoV):

* parent>child is not for describing “control” or “primary interface” but addressability
* if a driver needs access to another component, a reference property is used

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 24757 bytes --]

Hi,

On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
> Am 25.03.2015 um 16:21 schrieb Sebastian Reichel <sre@kernel.org>:
> > On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
> >>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> >>>> So you propose that the parent->child relationship is “control”? I.e. some
> >>>> channel which allows to address some bus client (through <reg>) and
> >>>> control that devices.
> >>>> 
> >>>> Makes sense. This is how i2c and spi clients are specified.
> >>>> 
> >>>>> In the case of our GPS, it receives control over the serial connection from
> >>>>> the UART,
> >>>> 
> >>>> Ahem - does it?
> >>>> 
> >>>> AFAIK the chip simply starts to emit NMEA records if powered on.
> >>>> There is no command going over the serial interface to address it
> >>>> or control it.
> >>> 
> >>> Right, since GPS basically doesn't need any configuration/control.
> >>> That’s not true for other UART attached devices, though.
> >> 
> >> Do you have an example? Usually an UART data stream is transparently
> >> presented to a /dev/tty - and user-space daemon can configure/control the
> >> attached device. In most cases it can mix payload data and control command
> >> by some AT command and escape sequences.
> > 
> > Yes, but the configuration is minimal. Anyways as you said there
> > *is* some kind of control happening over the UART.
> 
> Control is happening on a higher network stack level than UART. It
> control is done through AT commands.

Yes, obviously UART is only the physical layer. The same is true for
busses and does not really matter.

> >>>>> also receives control via a GPIO to the on/off pin, and also needs
> >>>>> a regulator to power the antenna.
> >>>>> 
> >>>>> So should the parent be the uart, the on/off GPIO, or the regulator?
> >>>>> 
> >>>>> I would much rather there wasn't a parent, and that each of these were listed
> >>>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
> >>>>> (where possible), and the parent is the thing that is “primarily" in control.
> >>>> 
> >>>> Well, IMHO the “parent” could also be the root. Representing the
> >>>> whole board.
> >>>> 
> >>>> Nevertheless, I doubt your rule that “ability to control” defines
> >>>> the parent>child relation (see below).
> >>>> 
> >>>>> 
> >>>>> I think the GPS is “primarily" a uart-attached device.
> >>>> 
> >>>> But not in the same way as an I2C device.
> >>>> 
> >>>> Especially the serial interface is not a bus and not used for
> >>>> signalling and power control. It is payload data (only).
> >>> 
> >>> Actually many I2C devices are also powered on/off via a GPIO and
> >>> even use additional GPIOs for sending interrupts. Nevertheless they
> >>> are normally identified as an I2C device.
> >> 
> >> Because I2C is a bus that can address multiple clients and gpio isn’t
> >> a bus and a point-to-point connection.
> >> 
> >> But IMHO it is not because they (can) send payload data over i2c.
> > 
> > From my POV it's not because I2C is a bus, but because the primary
> > function is happening via I2C (e.g. configuring sensor, gettings its
> > data). The GPIOs are only needed to compensate some I2C shortcomings
> > (missing irq feature in I2C) or reduce the complexity of the client
> > (power GPIO). The actual system interaction with the I2C chip is
> > going via I2C, though.
> 
> Yes, but this is in my new understanding irrelevant for proper DT
> description.

And for my understanding it is. We are arguing in a circle...

> >>>> If you assume that parent>child relationship is about control (only). But if it
> >>>> is about data flow, there is a different concept in DT. For example the CSI/DSI
> >>>> (OMAP DSS) use the “port” concept.
> >>> 
> >>> Yes, this is about data not going to the cpu / system memory.
> >> 
> >> Really? The frame buffer data is in system memory and gets to the panel. Or a
> >> camera image ends up in system memory.
> > 
> > Really? So the panel accesses the system memory? Check again. The
> > panel is simply connected via DSI/SDI/... and does not access the
> > system memory at all. The display controller OTH does. So let's have
> > a look at the DT structure (simplified):
> > 
> > ocp -> dss -> { port = <&panel>; }
> > ... -> spi -> panel { port = <&dss>; }
> > 
> > So the port models a device-to-device connection, which works
> > independent of the remaining system. No system memory is involved.
> 
> Sorry, but I can’t exactly follow what you want to show.
> 
> Yes, the port mechanism describes a device to device connection.
> 
> But it does not describe system memory. Although it is the source of
> the video (i.e. the framebuffer).
> 
> This shows that the DT does not necessarily describe data flow.
> 
> So why do you want to describe data flow from tty to uart to some
> connected device?

It shows, that the tree models system memory flow and adds
references for stuff not being about the system memory flow.

So let's say I want to configure the panel - I can simply walk
through the parent structure to know how to access it. The same
is true for the display controller.

> >>>> This means that indeed parent>child is used for control, e.g. I2C
> >>>> or SPI to tell the panel controller to switch on.
> >>> 
> >>> well parent > child is not about power control, but about "primary"
> >>> control.
> >> 
> >> Can you clearly and precisely define what “primary” control is? I think
> >> two people will have three opinions about that.
> >> 
> >> For example I would see the w2sg0004 on/off gpio as the primary “control”
> >> which makes the light (NMES records) turned on.
> >> 
> >> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?
> > 
> > I never thing of enable gpios to be the main interface, since it can
> > simply be connected to some voltage and be enabled constantly. It's
> > just some kind of helper for the device. It does not really exchange
> > data between the system and the device, though. (Note: This is
> > not true, if the GPIOs are used for bitbanging some high-level
> > protocol, in which case a virtual controller (like i2c-gpio) is
> > modelled in DT).
> > 
> > So let's have a look at the UART link again. It is transporting
> > non-trivial data from the UART to the system and it is handling
> > the data I actually want. It's providing access to the device's
> > “registers".
> 
> Well, this view can be followed, but is as strange and bent to fit
> like my view of the w2sg0004 as a “regulator”.
> 
> > 
> > For me its clear, that one would expect the GPS under the UART
> > port, since when speaking with other developers I would describe
> > the GPS as being a "UART attached GPS chip". From me the
> > differences between a UART port and a SPI port from a system
> > software’s POV can be reduced to missing multi-device support.
> 
> DT does not necessarily have to describe data flow as we have seen
> in the video pipeline example.

sure, it shows how to access the device. This link may not
necessarily be the same as the one, which takes care of the
data.

> > so show me some non-bus connections, which are actually used to
> > exchange non-trivial data (with on/off being trivial). We currently
> > do not really have them.
> 
> Are we talking about DT or data flow from user space through the
> kernel?

/me is not sure why you are regularly introducing userspace. It's
completly irrelevant when its assumed, that the kernel should
abstract devices. DT is about giving the kernel knowledge about
the *hardware*, so that it can implement this abstraction without
any user interaction.

Coming back at my sentence: I asked about a non-trivial, non-bus
connected HW, which has a DT binding.

> > I have missed virtual-gpio UART DTR discussion and assume, that the
> > regulator is about the regulator on the GPS chip?
> 
> Well, it was introduced in platform device kernels that it was possible
> to define a dtr-gpio for the uart. And there was a driver for the w2sg0004
> that presented itself as a gpio-controller with a single gpio. This “virtual”
> gpio was used to power on the chip as soon as DTR was asserted.
> 
> Parts of this had been in mainline but have been removed some months
> ago.

I can't find any w2sg0004 reference in the mainline kernel's commit
messages.

> > I don't think the regulator is not acceptable. I simply think its
> > not useful. Basically the structure would be
> > 
> > uart {
> >    /* stuff */
> >    gps {
> >        vdd-supply = <&gpsreg>;
> >        /* stuff */
> > 
> >        gpsreg: regulator {
> >            enable-gpio = <GPIO 42>;
> >            /* stuff */
> >        }
> >    }
> > }
> 
> Except that the gpsreg is a subnode of /

I obviously disagree with that ;)
But even then the regulator is useless.

> > 
> > and could simply be
> > 
> > uart {
> >    /* stuff */
> >    gps {
> >        enable-gpio = <GPIO 42>;
> >        /* stuff */
> >    }
> > }
> > 
> > Without loosing important information.
> 
> Only if you assume that the gpsreg must be a subnode of the uart.

DT means device tree and not device net. I sure can follow your
argument, but from my POV its trying to create a net from the tree.

> > The regulator would only be
> > interesting if it is also used by other devices. Other devices also
> > do not expose their internal clocks etc.
> > 
> >>>> The reason is there no well defined protocol to make multiple clients and
> >>>> you can’t specify a <reg>.
> >>>> 
> >>>> So you are either abusing the notion of a bus or the gps chip must be a separate
> >>>> DT node (child of something else).
> >>>> 
> >>>> I hope my gut feeling that we are trying to do something fundamentally wrong
> >>>> with making the gps chip a subode of serial is now argued a little better.
> >>>> 
> >>>> For making the serial device control some regulator through a reference to
> >>>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
> >>> 
> >>> NAK about referencing the regulator from the UART node. It should be
> >>> referenced from the Bluetooth / GPS node. The UART port works
> >>> without the regulator. It's the remote side, that does not work.
> >>> We also do not add the regulators of I2C clients to the I2C host.
> >> 
> >> I think Pavel made a very good comment:
> >> 
> >> The uart node should be able to power a rs232 converter/level shifter directly
> >> connected to it (through a regulator or gpio-regulator).
> > 
> > Yes and this may belong to the UART node.
> > 
> >> And there must be a separate mechanism to power the remote rs232 converter
> >> and the remote device.
> > 
> > Yes and I think this goes to the remote device's node.
> > 
> >> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
> >> UART is not only RX+TX.
> > 
> > so?
> 
> You said NAK about referencing a regulator from the UART node and
> now?

No. I said NAK about referencing *the* regulator from the BT/GPS
node. My NAK was about referencing a regulator in the UART node
(local side), which is actually needed by the GPS/BT module (remote
side).

> >>> If you want to talk with an I2C device you enable the I2C device
> >>> *and* its parent (aka the I2C host controller). I guess the same
> >>> should be done for the UART.
> >>> 
> >>>>>>>> All the following is very special logic for the w2sg0004 chip which should be
> >>>>>>>> divided out into a separate driver.
> >>>>>>>> 
> >>>>>>>> Marek and me already had proposed such a chip specific driver (to be located
> >>>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >>>>>>>> specific and present itself as a regulator (because that is its main purpose:
> >>>>>>>> control the LDO regulator inside the w2sg0004 chip).
> >>>>>>> 
> >>>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
> >>>>>> 
> >>>>>> It has a regulator that can be controlled by a gpio…
> >>>>> 
> >>>>> Does it?  I guess may it does.
> >>>>> Maybe it also has an ARM core and some memory and assorted other bits and
> >>>>> pieces.  But we don’t really need to describe them to device tree.
> >>>> 
> >>>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
> >>>> 
> >>>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
> >>>> connected to a GPIO - would tell if the module is really active or not. Using this would
> >>>> make monitoring the RX line through different pinmux states obsolete.
> >>>> 
> >>>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
> >>>> not wired the WAKEUP line to a  GPIO.
> >>>> 
> >>>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> >>>>> devices tree description.  If there are subcomponents that can usefully be
> >>>>> described as well then there could be a place to describe those subcomponents.
> >>>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> >>>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> >>>>> useful to describe the regulator inside the GPS so it could be declare that
> >>>>> some other device which needed 1V8 made use of that regulator….
> >>>> 
> >>>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
> >>>> difficult for others to do by enforcing the wrong description.
> >>> 
> >>> well this has nothing to do with the parent-child discussion, since
> >>> you can obviously reference a regulator independently of its
> >>> position in the DT.
> >>> 
> >>>>>> Another example to think about: the twl4030 is also not a regulator.
> >>>>>> Nevertheless they present some regulator nodes.
> >>>>> 
> >>>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
> >>>>> audio codec and  USB PHY etc etc etc.
> >>>>> 
> >>>>> So in device-tree there is a device-node for the TWL4030, and it has
> >>>>> child-nodes for each sub-device.   They in turn can provide services to other
> >>>>> devices on the board.
> >>>> 
> >>>> Exactly as discussed above. And there, the parent>child relation for the twl4030
> >>>> and its subdevices is right.
> >>>> 
> >>>>> These sub-devices are much more independent of the whole than the regulator
> >>>>> inside the w2sg0004 is.
> >>>> 
> >>>> Hm. That is probably argueable as well. At least a vague ciriterion.
> >>>>> 
> >>>>>> 
> >>>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> >>>>>> but has an internal pbias_regulator that needs to be controlled.
> >>>>> 
> >>>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> >>>>> device which contains a CPU and multiple other controllers and  communicators
> >>>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> >>>>> it has a device-node which is a child of the 'ocp' node - which is the main
> >>>>> interconnect in the OMAP3 I think.
> >>>>> 
> >>>>> So I'm not against describing the regulator in the w2sg0004, but for
> >>>>> consistency with everything else, it would need to be child-node of a
> >>>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> >>>>> that would gain anything.
> >>>> 
> >>>> Well, it would gain consistency how chips with multiple components inside
> >>>> are described.
> >>> 
> >>> I don't think so. Many devices do not expose all of their
> >>> subdevices. e.g. they do not expose their internal clocks.
> >>> Apart from that there are a few devices in the kernel, which
> >>> do use enable-gpio(s).
> >> 
> >> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
> >> revise my formulation a little.
> >> 
> >> It is not that parent>child is used for describing “busses or grouping subdevices".
> >> 
> >> It is only for “grouping addressable components”, which implies some bus.
> >> 
> >> This still explains the ocp component of the OMAP3 - which represents the
> >> whole internal “interconnect” bus (see comment in omap3.dtsi).
> >> 
> >> Therefore you are right. It is not correct to split up a device into arbitrary
> >> components and group them again by the parent>child pattern.
> >> 
> >> Although the structure of twl4030.dtsi appears to simply list and group
> >> subcomponents without telling explicitly how to address them.
> > 
> > Yes and this style is not only used for twl4030, but also for other
> > multi function devices. I do not have a problem with splitting up a
> > device into components as long as they are referenced by other
> > components. There is no point in exposing all internal information.
> > For the system its not relevant, that the GPS chip has a 30MHz
> > clock if its part of the chip and nobody else is using it.
> > 
> >>>> And would make it easier to see the whole w2sg0004 a child of /.
> >>> 
> >>> Even with the regulator subdevice I would still make the w2sg0004 a
> >>> child of the UART port.
> >> 
> >> This would mean that a tty / uart is able to address multiple clients. How
> >> could it do that?
> > 
> > In theory it's possible:
> > 
> > ? -> uart -> multiplexer -> { device1, device2 }
> > 
> > I hope nobody will build such a device, though :)
> > 
> > I don't think addressability is important for a parent > child
> > connection, though. It is important for a reg node, of course.
> 
> That is the key question I am trying to get founded answers, not
> opinions :)
> 
> > 
> >>> Main reason is, that I would need to go
> >>> through the UART to “communicate" with the w2sg0004.
> >> 
> >> You can always "communicate” through the UART. Even without DT. As
> >> long as the connected chip is powered up by any means (could be
> >> some fixed-regulator or hard wired).
> >> 
> >> Power control for open()/close() did even work with the DT based
> >> DTR->virtual-gpio approach.
> >> 
> >> We just do not described in the DT that there is a data connection
> >> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
> >> 
> >> Thus, describing a relation between the uart node and the GPS chip
> >> in the DT is not even a requirement.
> > 
> > It is when the kernel should be able to handle the GPS. The DT is
> > supposed to be independent from Linux and other operating systems
> > may want to hide the tty if a GPS is attached to it and instead
> > provide something like /dev/gps, which could automatically be picked
> > up by userspace software.
> 
> Well, it is difficult to cover all future use cases.
> 
> But then you can still add a uart = <&uart1> reference to the DT node
> of the driver. Because I understand that then the driver is the master
> (and needs access to a hidden UART) and not the GPS chip a slave of
> an exposed UART.

Ok. It seems we are still talk past each other. All use cases can be
implemented using both ways - putting the node to / or putting it
below the UART node. It simply does not matter, since kernel code
can interpret it as needed. You just asked at some time why we need
to know about the remote side.

From my POV putting it below the UART node is more logical and from
your POV putting it below / is more logical.

> >> Probably the main problem we have is that we want to describe this
> >> data connection but the device tree is about describing how to
> >> address components and data flow is left to internal APIs. Or
> >> “ports” like in the video pipelines.
> > 
> > As I wrote the tree structure shows how to "reach" a component for
> > accessing its configuration/data from the system.
> 
> Yes, you wrote and I already pointed out that I disagree. It
> contradicts what
> 
> http://www.devicetree.org/Device_Tree_Usage#Devices
> 
> appears to tell me. So who is right?

From my POV the page is simply focused on standard bindings, which
have already been established. If I understand you right, your POV
does not allow child nodes (which are not directly under /) without
reg property / address. Just have a look at the DT binding
documentation directory in the kernel - we already have them.

> >> Let me raise the question:
> >> 
> >> Why do we need to describe in the DT (independently of Linux power
> >> control structures and drivers!) that the GPS data interface is
> >> connected to a specific UART?
> >> Who needs this information and for which purpose?
> > 
> > Because an operating system can provide drivers, which completly
> > hide away the UART connection. Example:
> > 
> > Let's assume we have an UART attached Bluetooth chip connected to
> > the second UART.
> > 
> > In Linux, userspace currently must know, that the BT module is
> > connected to this port and correctly setup the port for BT usage.
> > Once this has been done the port is completly handled in the kernel
> > and userspace can ignore the UART.
> 
> Ok, this is a reasonable example. But I still don’ see that it
> requires that the bt chip must be a subnode of the uart.

It doesn't. I just answered your question, which was independent
of the actual node position.

> > So why must the user configure the port? Because the kernel does not
> > know, that a BT chip is connected to the port.
> 
> Then, I would suggest to write it like you have done:
> 
> “the BT chip is connected to the port uart1”
> 
> This can be easily translated into DT language:
> 
> / {
> 	bt {
> 		compatible = “vendor,chip”;
> 		uart = <&uart1>;	/* this chip is connected to uart1 */
> 		enable-gpio = <&gpio3 17 0>;
> 	};
> };
> 
> This also resembles the “port” mechanism (just simplified because it is not
> a backwards forward linkage).
> 
> Or exactly follows the pattern that a driver that wants to use
> some gpio simply links to the gpio controller. Or a driver wants
> to control a gpio.
> 
> What I don’t understand is what is here so special to not use this
> DT pattern.
> 
> But It could also open a different solution for the tty open() ->
> w2sg power on problem.
> 
> / {
> 	gps {
> 		compatible = “wi2wi,w2sg0004”;
> 		uart = <&uart1>;	/* this chip is connected to uart1 */
> 		enable-gpio = <&gpio3 17 0>;
> 	};
> };
> 
> Here, the w2sg0004 probe function could register with uart1 to get notified
> about open/close events and then do what it has to do.
> 
> In that case the w2sg0004 driver would not even need to present itself
> as a virtual gpio (for DTR) or a regulator because it has a kernel internal
> API to apply to tell the uart what it wants to do.

Again the same can be done if its a child-node of the UART. It is
simply a question of reading the "uart" property vs loading the
driver from the UART and access the parent device.

> > If the kernel gets
> > this information from DT it can do all the UART handling itself and
> > provide a bluetooth device without any user interaction.
> 
> I think we should get a better understanding of the DT design patterns.
> 
> IMHO (or IMPoV):
> 
> * parent>child is not for describing “control” or “primary interface” but addressability

We obviously disagree here :)

> * if a driver needs access to another component, a reference property is used

Here we also disagree. The kernel also makes use of parent > child
connections (e.g. the driver for an i2c client node will request
data via its parent) and sometimes even sibling relationships (in
MFD devices).

So let me summarize:

 * Option A: Do not encode remote side information
   Rationale: UART port can be opened in userspace without that info
   Counterargument: This information is needed if the OS should be
   able to hide away the tty and provide support for the connected
   remote device (e.g. provide a bluetooth device instead of a tty)

 * Option B: Put UART remote side node to / and add a reference to the UART port
   Rationale: DT wiki page indicates, that child nodes must be addressable

 * Option C: Put UART remote side node below the UART node
   Rationale: Remote device is accessed through the UART

Since this is about a subsystem binding DT maintainers ACK is
definitely needed, so maybe we should just wait for their decision.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 24757 bytes --]

Hi,

On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
> Am 25.03.2015 um 16:21 schrieb Sebastian Reichel <sre@kernel.org>:
> > On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
> >>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
> >>>> So you propose that the parent->child relationship is “control”? I.e. some
> >>>> channel which allows to address some bus client (through <reg>) and
> >>>> control that devices.
> >>>> 
> >>>> Makes sense. This is how i2c and spi clients are specified.
> >>>> 
> >>>>> In the case of our GPS, it receives control over the serial connection from
> >>>>> the UART,
> >>>> 
> >>>> Ahem - does it?
> >>>> 
> >>>> AFAIK the chip simply starts to emit NMEA records if powered on.
> >>>> There is no command going over the serial interface to address it
> >>>> or control it.
> >>> 
> >>> Right, since GPS basically doesn't need any configuration/control.
> >>> That’s not true for other UART attached devices, though.
> >> 
> >> Do you have an example? Usually an UART data stream is transparently
> >> presented to a /dev/tty - and user-space daemon can configure/control the
> >> attached device. In most cases it can mix payload data and control command
> >> by some AT command and escape sequences.
> > 
> > Yes, but the configuration is minimal. Anyways as you said there
> > *is* some kind of control happening over the UART.
> 
> Control is happening on a higher network stack level than UART. It
> control is done through AT commands.

Yes, obviously UART is only the physical layer. The same is true for
busses and does not really matter.

> >>>>> also receives control via a GPIO to the on/off pin, and also needs
> >>>>> a regulator to power the antenna.
> >>>>> 
> >>>>> So should the parent be the uart, the on/off GPIO, or the regulator?
> >>>>> 
> >>>>> I would much rather there wasn't a parent, and that each of these were listed
> >>>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
> >>>>> (where possible), and the parent is the thing that is “primarily" in control.
> >>>> 
> >>>> Well, IMHO the “parent” could also be the root. Representing the
> >>>> whole board.
> >>>> 
> >>>> Nevertheless, I doubt your rule that “ability to control” defines
> >>>> the parent>child relation (see below).
> >>>> 
> >>>>> 
> >>>>> I think the GPS is “primarily" a uart-attached device.
> >>>> 
> >>>> But not in the same way as an I2C device.
> >>>> 
> >>>> Especially the serial interface is not a bus and not used for
> >>>> signalling and power control. It is payload data (only).
> >>> 
> >>> Actually many I2C devices are also powered on/off via a GPIO and
> >>> even use additional GPIOs for sending interrupts. Nevertheless they
> >>> are normally identified as an I2C device.
> >> 
> >> Because I2C is a bus that can address multiple clients and gpio isn’t
> >> a bus and a point-to-point connection.
> >> 
> >> But IMHO it is not because they (can) send payload data over i2c.
> > 
> > From my POV it's not because I2C is a bus, but because the primary
> > function is happening via I2C (e.g. configuring sensor, gettings its
> > data). The GPIOs are only needed to compensate some I2C shortcomings
> > (missing irq feature in I2C) or reduce the complexity of the client
> > (power GPIO). The actual system interaction with the I2C chip is
> > going via I2C, though.
> 
> Yes, but this is in my new understanding irrelevant for proper DT
> description.

And for my understanding it is. We are arguing in a circle...

> >>>> If you assume that parent>child relationship is about control (only). But if it
> >>>> is about data flow, there is a different concept in DT. For example the CSI/DSI
> >>>> (OMAP DSS) use the “port” concept.
> >>> 
> >>> Yes, this is about data not going to the cpu / system memory.
> >> 
> >> Really? The frame buffer data is in system memory and gets to the panel. Or a
> >> camera image ends up in system memory.
> > 
> > Really? So the panel accesses the system memory? Check again. The
> > panel is simply connected via DSI/SDI/... and does not access the
> > system memory at all. The display controller OTH does. So let's have
> > a look at the DT structure (simplified):
> > 
> > ocp -> dss -> { port = <&panel>; }
> > ... -> spi -> panel { port = <&dss>; }
> > 
> > So the port models a device-to-device connection, which works
> > independent of the remaining system. No system memory is involved.
> 
> Sorry, but I can’t exactly follow what you want to show.
> 
> Yes, the port mechanism describes a device to device connection.
> 
> But it does not describe system memory. Although it is the source of
> the video (i.e. the framebuffer).
> 
> This shows that the DT does not necessarily describe data flow.
> 
> So why do you want to describe data flow from tty to uart to some
> connected device?

It shows, that the tree models system memory flow and adds
references for stuff not being about the system memory flow.

So let's say I want to configure the panel - I can simply walk
through the parent structure to know how to access it. The same
is true for the display controller.

> >>>> This means that indeed parent>child is used for control, e.g. I2C
> >>>> or SPI to tell the panel controller to switch on.
> >>> 
> >>> well parent > child is not about power control, but about "primary"
> >>> control.
> >> 
> >> Can you clearly and precisely define what “primary” control is? I think
> >> two people will have three opinions about that.
> >> 
> >> For example I would see the w2sg0004 on/off gpio as the primary “control”
> >> which makes the light (NMES records) turned on.
> >> 
> >> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?
> > 
> > I never thing of enable gpios to be the main interface, since it can
> > simply be connected to some voltage and be enabled constantly. It's
> > just some kind of helper for the device. It does not really exchange
> > data between the system and the device, though. (Note: This is
> > not true, if the GPIOs are used for bitbanging some high-level
> > protocol, in which case a virtual controller (like i2c-gpio) is
> > modelled in DT).
> > 
> > So let's have a look at the UART link again. It is transporting
> > non-trivial data from the UART to the system and it is handling
> > the data I actually want. It's providing access to the device's
> > “registers".
> 
> Well, this view can be followed, but is as strange and bent to fit
> like my view of the w2sg0004 as a “regulator”.
> 
> > 
> > For me its clear, that one would expect the GPS under the UART
> > port, since when speaking with other developers I would describe
> > the GPS as being a "UART attached GPS chip". From me the
> > differences between a UART port and a SPI port from a system
> > software’s POV can be reduced to missing multi-device support.
> 
> DT does not necessarily have to describe data flow as we have seen
> in the video pipeline example.

sure, it shows how to access the device. This link may not
necessarily be the same as the one, which takes care of the
data.

> > so show me some non-bus connections, which are actually used to
> > exchange non-trivial data (with on/off being trivial). We currently
> > do not really have them.
> 
> Are we talking about DT or data flow from user space through the
> kernel?

/me is not sure why you are regularly introducing userspace. It's
completly irrelevant when its assumed, that the kernel should
abstract devices. DT is about giving the kernel knowledge about
the *hardware*, so that it can implement this abstraction without
any user interaction.

Coming back at my sentence: I asked about a non-trivial, non-bus
connected HW, which has a DT binding.

> > I have missed virtual-gpio UART DTR discussion and assume, that the
> > regulator is about the regulator on the GPS chip?
> 
> Well, it was introduced in platform device kernels that it was possible
> to define a dtr-gpio for the uart. And there was a driver for the w2sg0004
> that presented itself as a gpio-controller with a single gpio. This “virtual”
> gpio was used to power on the chip as soon as DTR was asserted.
> 
> Parts of this had been in mainline but have been removed some months
> ago.

I can't find any w2sg0004 reference in the mainline kernel's commit
messages.

> > I don't think the regulator is not acceptable. I simply think its
> > not useful. Basically the structure would be
> > 
> > uart {
> >    /* stuff */
> >    gps {
> >        vdd-supply = <&gpsreg>;
> >        /* stuff */
> > 
> >        gpsreg: regulator {
> >            enable-gpio = <GPIO 42>;
> >            /* stuff */
> >        }
> >    }
> > }
> 
> Except that the gpsreg is a subnode of /

I obviously disagree with that ;)
But even then the regulator is useless.

> > 
> > and could simply be
> > 
> > uart {
> >    /* stuff */
> >    gps {
> >        enable-gpio = <GPIO 42>;
> >        /* stuff */
> >    }
> > }
> > 
> > Without loosing important information.
> 
> Only if you assume that the gpsreg must be a subnode of the uart.

DT means device tree and not device net. I sure can follow your
argument, but from my POV its trying to create a net from the tree.

> > The regulator would only be
> > interesting if it is also used by other devices. Other devices also
> > do not expose their internal clocks etc.
> > 
> >>>> The reason is there no well defined protocol to make multiple clients and
> >>>> you can’t specify a <reg>.
> >>>> 
> >>>> So you are either abusing the notion of a bus or the gps chip must be a separate
> >>>> DT node (child of something else).
> >>>> 
> >>>> I hope my gut feeling that we are trying to do something fundamentally wrong
> >>>> with making the gps chip a subode of serial is now argued a little better.
> >>>> 
> >>>> For making the serial device control some regulator through a reference to
> >>>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
> >>> 
> >>> NAK about referencing the regulator from the UART node. It should be
> >>> referenced from the Bluetooth / GPS node. The UART port works
> >>> without the regulator. It's the remote side, that does not work.
> >>> We also do not add the regulators of I2C clients to the I2C host.
> >> 
> >> I think Pavel made a very good comment:
> >> 
> >> The uart node should be able to power a rs232 converter/level shifter directly
> >> connected to it (through a regulator or gpio-regulator).
> > 
> > Yes and this may belong to the UART node.
> > 
> >> And there must be a separate mechanism to power the remote rs232 converter
> >> and the remote device.
> > 
> > Yes and I think this goes to the remote device's node.
> > 
> >> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
> >> UART is not only RX+TX.
> > 
> > so?
> 
> You said NAK about referencing a regulator from the UART node and
> now?

No. I said NAK about referencing *the* regulator from the BT/GPS
node. My NAK was about referencing a regulator in the UART node
(local side), which is actually needed by the GPS/BT module (remote
side).

> >>> If you want to talk with an I2C device you enable the I2C device
> >>> *and* its parent (aka the I2C host controller). I guess the same
> >>> should be done for the UART.
> >>> 
> >>>>>>>> All the following is very special logic for the w2sg0004 chip which should be
> >>>>>>>> divided out into a separate driver.
> >>>>>>>> 
> >>>>>>>> Marek and me already had proposed such a chip specific driver (to be located
> >>>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
> >>>>>>>> specific and present itself as a regulator (because that is its main purpose:
> >>>>>>>> control the LDO regulator inside the w2sg0004 chip).
> >>>>>>> 
> >>>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
> >>>>>> 
> >>>>>> It has a regulator that can be controlled by a gpio…
> >>>>> 
> >>>>> Does it?  I guess may it does.
> >>>>> Maybe it also has an ARM core and some memory and assorted other bits and
> >>>>> pieces.  But we don’t really need to describe them to device tree.
> >>>> 
> >>>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
> >>>> 
> >>>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
> >>>> connected to a GPIO - would tell if the module is really active or not. Using this would
> >>>> make monitoring the RX line through different pinmux states obsolete.
> >>>> 
> >>>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
> >>>> not wired the WAKEUP line to a  GPIO.
> >>>> 
> >>>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
> >>>>> devices tree description.  If there are subcomponents that can usefully be
> >>>>> described as well then there could be a place to describe those subcomponents.
> >>>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
> >>>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
> >>>>> useful to describe the regulator inside the GPS so it could be declare that
> >>>>> some other device which needed 1V8 made use of that regulator….
> >>>> 
> >>>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
> >>>> difficult for others to do by enforcing the wrong description.
> >>> 
> >>> well this has nothing to do with the parent-child discussion, since
> >>> you can obviously reference a regulator independently of its
> >>> position in the DT.
> >>> 
> >>>>>> Another example to think about: the twl4030 is also not a regulator.
> >>>>>> Nevertheless they present some regulator nodes.
> >>>>> 
> >>>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
> >>>>> audio codec and  USB PHY etc etc etc.
> >>>>> 
> >>>>> So in device-tree there is a device-node for the TWL4030, and it has
> >>>>> child-nodes for each sub-device.   They in turn can provide services to other
> >>>>> devices on the board.
> >>>> 
> >>>> Exactly as discussed above. And there, the parent>child relation for the twl4030
> >>>> and its subdevices is right.
> >>>> 
> >>>>> These sub-devices are much more independent of the whole than the regulator
> >>>>> inside the w2sg0004 is.
> >>>> 
> >>>> Hm. That is probably argueable as well. At least a vague ciriterion.
> >>>>> 
> >>>>>> 
> >>>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
> >>>>>> but has an internal pbias_regulator that needs to be controlled.
> >>>>> 
> >>>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
> >>>>> device which contains a CPU and multiple other controllers and  communicators
> >>>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
> >>>>> it has a device-node which is a child of the 'ocp' node - which is the main
> >>>>> interconnect in the OMAP3 I think.
> >>>>> 
> >>>>> So I'm not against describing the regulator in the w2sg0004, but for
> >>>>> consistency with everything else, it would need to be child-node of a
> >>>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
> >>>>> that would gain anything.
> >>>> 
> >>>> Well, it would gain consistency how chips with multiple components inside
> >>>> are described.
> >>> 
> >>> I don't think so. Many devices do not expose all of their
> >>> subdevices. e.g. they do not expose their internal clocks.
> >>> Apart from that there are a few devices in the kernel, which
> >>> do use enable-gpio(s).
> >> 
> >> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
> >> revise my formulation a little.
> >> 
> >> It is not that parent>child is used for describing “busses or grouping subdevices".
> >> 
> >> It is only for “grouping addressable components”, which implies some bus.
> >> 
> >> This still explains the ocp component of the OMAP3 - which represents the
> >> whole internal “interconnect” bus (see comment in omap3.dtsi).
> >> 
> >> Therefore you are right. It is not correct to split up a device into arbitrary
> >> components and group them again by the parent>child pattern.
> >> 
> >> Although the structure of twl4030.dtsi appears to simply list and group
> >> subcomponents without telling explicitly how to address them.
> > 
> > Yes and this style is not only used for twl4030, but also for other
> > multi function devices. I do not have a problem with splitting up a
> > device into components as long as they are referenced by other
> > components. There is no point in exposing all internal information.
> > For the system its not relevant, that the GPS chip has a 30MHz
> > clock if its part of the chip and nobody else is using it.
> > 
> >>>> And would make it easier to see the whole w2sg0004 a child of /.
> >>> 
> >>> Even with the regulator subdevice I would still make the w2sg0004 a
> >>> child of the UART port.
> >> 
> >> This would mean that a tty / uart is able to address multiple clients. How
> >> could it do that?
> > 
> > In theory it's possible:
> > 
> > ? -> uart -> multiplexer -> { device1, device2 }
> > 
> > I hope nobody will build such a device, though :)
> > 
> > I don't think addressability is important for a parent > child
> > connection, though. It is important for a reg node, of course.
> 
> That is the key question I am trying to get founded answers, not
> opinions :)
> 
> > 
> >>> Main reason is, that I would need to go
> >>> through the UART to “communicate" with the w2sg0004.
> >> 
> >> You can always "communicate” through the UART. Even without DT. As
> >> long as the connected chip is powered up by any means (could be
> >> some fixed-regulator or hard wired).
> >> 
> >> Power control for open()/close() did even work with the DT based
> >> DTR->virtual-gpio approach.
> >> 
> >> We just do not described in the DT that there is a data connection
> >> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
> >> 
> >> Thus, describing a relation between the uart node and the GPS chip
> >> in the DT is not even a requirement.
> > 
> > It is when the kernel should be able to handle the GPS. The DT is
> > supposed to be independent from Linux and other operating systems
> > may want to hide the tty if a GPS is attached to it and instead
> > provide something like /dev/gps, which could automatically be picked
> > up by userspace software.
> 
> Well, it is difficult to cover all future use cases.
> 
> But then you can still add a uart = <&uart1> reference to the DT node
> of the driver. Because I understand that then the driver is the master
> (and needs access to a hidden UART) and not the GPS chip a slave of
> an exposed UART.

Ok. It seems we are still talk past each other. All use cases can be
implemented using both ways - putting the node to / or putting it
below the UART node. It simply does not matter, since kernel code
can interpret it as needed. You just asked at some time why we need
to know about the remote side.

From my POV putting it below the UART node is more logical and from
your POV putting it below / is more logical.

> >> Probably the main problem we have is that we want to describe this
> >> data connection but the device tree is about describing how to
> >> address components and data flow is left to internal APIs. Or
> >> “ports” like in the video pipelines.
> > 
> > As I wrote the tree structure shows how to "reach" a component for
> > accessing its configuration/data from the system.
> 
> Yes, you wrote and I already pointed out that I disagree. It
> contradicts what
> 
> http://www.devicetree.org/Device_Tree_Usage#Devices
> 
> appears to tell me. So who is right?

From my POV the page is simply focused on standard bindings, which
have already been established. If I understand you right, your POV
does not allow child nodes (which are not directly under /) without
reg property / address. Just have a look at the DT binding
documentation directory in the kernel - we already have them.

> >> Let me raise the question:
> >> 
> >> Why do we need to describe in the DT (independently of Linux power
> >> control structures and drivers!) that the GPS data interface is
> >> connected to a specific UART?
> >> Who needs this information and for which purpose?
> > 
> > Because an operating system can provide drivers, which completly
> > hide away the UART connection. Example:
> > 
> > Let's assume we have an UART attached Bluetooth chip connected to
> > the second UART.
> > 
> > In Linux, userspace currently must know, that the BT module is
> > connected to this port and correctly setup the port for BT usage.
> > Once this has been done the port is completly handled in the kernel
> > and userspace can ignore the UART.
> 
> Ok, this is a reasonable example. But I still don’ see that it
> requires that the bt chip must be a subnode of the uart.

It doesn't. I just answered your question, which was independent
of the actual node position.

> > So why must the user configure the port? Because the kernel does not
> > know, that a BT chip is connected to the port.
> 
> Then, I would suggest to write it like you have done:
> 
> “the BT chip is connected to the port uart1”
> 
> This can be easily translated into DT language:
> 
> / {
> 	bt {
> 		compatible = “vendor,chip”;
> 		uart = <&uart1>;	/* this chip is connected to uart1 */
> 		enable-gpio = <&gpio3 17 0>;
> 	};
> };
> 
> This also resembles the “port” mechanism (just simplified because it is not
> a backwards forward linkage).
> 
> Or exactly follows the pattern that a driver that wants to use
> some gpio simply links to the gpio controller. Or a driver wants
> to control a gpio.
> 
> What I don’t understand is what is here so special to not use this
> DT pattern.
> 
> But It could also open a different solution for the tty open() ->
> w2sg power on problem.
> 
> / {
> 	gps {
> 		compatible = “wi2wi,w2sg0004”;
> 		uart = <&uart1>;	/* this chip is connected to uart1 */
> 		enable-gpio = <&gpio3 17 0>;
> 	};
> };
> 
> Here, the w2sg0004 probe function could register with uart1 to get notified
> about open/close events and then do what it has to do.
> 
> In that case the w2sg0004 driver would not even need to present itself
> as a virtual gpio (for DTR) or a regulator because it has a kernel internal
> API to apply to tell the uart what it wants to do.

Again the same can be done if its a child-node of the UART. It is
simply a question of reading the "uart" property vs loading the
driver from the UART and access the parent device.

> > If the kernel gets
> > this information from DT it can do all the UART handling itself and
> > provide a bluetooth device without any user interaction.
> 
> I think we should get a better understanding of the DT design patterns.
> 
> IMHO (or IMPoV):
> 
> * parent>child is not for describing “control” or “primary interface” but addressability

We obviously disagree here :)

> * if a driver needs access to another component, a reference property is used

Here we also disagree. The kernel also makes use of parent > child
connections (e.g. the driver for an i2c client node will request
data via its parent) and sometimes even sibling relationships (in
MFD devices).

So let me summarize:

 * Option A: Do not encode remote side information
   Rationale: UART port can be opened in userspace without that info
   Counterargument: This information is needed if the OS should be
   able to hide away the tty and provide support for the connected
   remote device (e.g. provide a bluetooth device instead of a tty)

 * Option B: Put UART remote side node to / and add a reference to the UART port
   Rationale: DT wiki page indicates, that child nodes must be addressable

 * Option C: Put UART remote side node below the UART node
   Rationale: Remote device is accessed through the UART

Since this is about a subsystem binding DT maintainers ACK is
definitely needed, so maybe we should just wait for their decision.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 19:08 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Am 25.03.2015 um 16:21 schrieb Sebastian Reichel <sre@kernel.org>:
>>> On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
>>>>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>>> So you propose that the parent->child relationship is “control”? I.e. some
>>>>>> channel which allows to address some bus client (through <reg>) and
>>>>>> control that devices.
>>>>>> 
>>>>>> Makes sense. This is how i2c and spi clients are specified.
>>>>>> 
>>>>>>> In the case of our GPS, it receives control over the serial connection from
>>>>>>> the UART,
>>>>>> 
>>>>>> Ahem - does it?
>>>>>> 
>>>>>> AFAIK the chip simply starts to emit NMEA records if powered on.
>>>>>> There is no command going over the serial interface to address it
>>>>>> or control it.
>>>>> 
>>>>> Right, since GPS basically doesn't need any configuration/control.
>>>>> That’s not true for other UART attached devices, though.
>>>> 
>>>> Do you have an example? Usually an UART data stream is transparently
>>>> presented to a /dev/tty - and user-space daemon can configure/control the
>>>> attached device. In most cases it can mix payload data and control command
>>>> by some AT command and escape sequences.
>>> 
>>> Yes, but the configuration is minimal. Anyways as you said there
>>> *is* some kind of control happening over the UART.
>> 
>> Control is happening on a higher network stack level than UART. It
>> control is done through AT commands.
> 
> Yes, obviously UART is only the physical layer. The same is true for
> busses and does not really matter.

Fine that we agree on that. I just mentioned it because we discussed about line
disciplines and tty which are higher level.

> 
>>>>>>> also receives control via a GPIO to the on/off pin, and also needs
>>>>>>> a regulator to power the antenna.
>>>>>>> 
>>>>>>> So should the parent be the uart, the on/off GPIO, or the regulator?
>>>>>>> 
>>>>>>> I would much rather there wasn't a parent, and that each of these were listed
>>>>>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
>>>>>>> (where possible), and the parent is the thing that is “primarily" in control.
>>>>>> 
>>>>>> Well, IMHO the “parent” could also be the root. Representing the
>>>>>> whole board.
>>>>>> 
>>>>>> Nevertheless, I doubt your rule that “ability to control” defines
>>>>>> the parent>child relation (see below).
>>>>>> 
>>>>>>> 
>>>>>>> I think the GPS is “primarily" a uart-attached device.
>>>>>> 
>>>>>> But not in the same way as an I2C device.
>>>>>> 
>>>>>> Especially the serial interface is not a bus and not used for
>>>>>> signalling and power control. It is payload data (only).
>>>>> 
>>>>> Actually many I2C devices are also powered on/off via a GPIO and
>>>>> even use additional GPIOs for sending interrupts. Nevertheless they
>>>>> are normally identified as an I2C device.
>>>> 
>>>> Because I2C is a bus that can address multiple clients and gpio isn’t
>>>> a bus and a point-to-point connection.
>>>> 
>>>> But IMHO it is not because they (can) send payload data over i2c.
>>> 
>>> From my POV it's not because I2C is a bus, but because the primary
>>> function is happening via I2C (e.g. configuring sensor, gettings its
>>> data). The GPIOs are only needed to compensate some I2C shortcomings
>>> (missing irq feature in I2C) or reduce the complexity of the client
>>> (power GPIO). The actual system interaction with the I2C chip is
>>> going via I2C, though.
>> 
>> Yes, but this is in my new understanding irrelevant for proper DT
>> description.
> 
> And for my understanding it is. We are arguing in a circle…

Yes, and that is the reason why I try to go to a higher level of discussion. I.e.
find out the principles behind. If we can agree on those, it becomes easy
to decide the details.

> 
>>>>>> If you assume that parent>child relationship is about control (only). But if it
>>>>>> is about data flow, there is a different concept in DT. For example the CSI/DSI
>>>>>> (OMAP DSS) use the “port” concept.
>>>>> 
>>>>> Yes, this is about data not going to the cpu / system memory.
>>>> 
>>>> Really? The frame buffer data is in system memory and gets to the panel. Or a
>>>> camera image ends up in system memory.
>>> 
>>> Really? So the panel accesses the system memory? Check again. The
>>> panel is simply connected via DSI/SDI/... and does not access the
>>> system memory at all. The display controller OTH does. So let's have
>>> a look at the DT structure (simplified):
>>> 
>>> ocp -> dss -> { port = <&panel>; }
>>> ... -> spi -> panel { port = <&dss>; }
>>> 
>>> So the port models a device-to-device connection, which works
>>> independent of the remaining system. No system memory is involved.
>> 
>> Sorry, but I can’t exactly follow what you want to show.
>> 
>> Yes, the port mechanism describes a device to device connection.
>> 
>> But it does not describe system memory. Although it is the source of
>> the video (i.e. the framebuffer).
>> 
>> This shows that the DT does not necessarily describe data flow.
>> 
>> So why do you want to describe data flow from tty to uart to some
>> connected device?
> 
> It shows, that the tree models system memory flow and adds
> references for stuff not being about the system memory flow.
> 
> So let's say I want to configure the panel - I can simply walk
> through the parent structure to know how to access it. The same
> is true for the display controller.

Ok, I see. Someone has introduced the word “system memory” in this
discussion about addressing devices.

> 
>>>>>> This means that indeed parent>child is used for control, e.g. I2C
>>>>>> or SPI to tell the panel controller to switch on.
>>>>> 
>>>>> well parent > child is not about power control, but about "primary"
>>>>> control.
>>>> 
>>>> Can you clearly and precisely define what “primary” control is? I think
>>>> two people will have three opinions about that.
>>>> 
>>>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>>>> which makes the light (NMES records) turned on.
>>>> 
>>>> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?
>>> 
>>> I never thing of enable gpios to be the main interface, since it can
>>> simply be connected to some voltage and be enabled constantly. It's
>>> just some kind of helper for the device. It does not really exchange
>>> data between the system and the device, though. (Note: This is
>>> not true, if the GPIOs are used for bitbanging some high-level
>>> protocol, in which case a virtual controller (like i2c-gpio) is
>>> modelled in DT).
>>> 
>>> So let's have a look at the UART link again. It is transporting
>>> non-trivial data from the UART to the system and it is handling
>>> the data I actually want. It's providing access to the device's
>>> “registers".
>> 
>> Well, this view can be followed, but is as strange and bent to fit
>> like my view of the w2sg0004 as a “regulator”.
>> 
>>> 
>>> For me its clear, that one would expect the GPS under the UART
>>> port, since when speaking with other developers I would describe
>>> the GPS as being a "UART attached GPS chip". From me the
>>> differences between a UART port and a SPI port from a system
>>> software’s POV can be reduced to missing multi-device support.
>> 
>> DT does not necessarily have to describe data flow as we have seen
>> in the video pipeline example.
> 
> sure, it shows how to access the device. This link may not
> necessarily be the same as the one, which takes care of the
> data.

Ok, fine that we agree on this.

> 
>>> so show me some non-bus connections, which are actually used to
>>> exchange non-trivial data (with on/off being trivial). We currently
>>> do not really have them.
>> 
>> Are we talking about DT or data flow from user space through the
>> kernel?
> 
> /me is not sure why you are regularly introducing userspace.

Because I am under the impression that some arguments in this discussion
are driven by a user-space view.

> It's
> completly irrelevant when its assumed, that the kernel should
> abstract devices. DT is about giving the kernel knowledge about
> the *hardware*, so that it can implement this abstraction without
> any user interaction.

Agreed.

> 
> Coming back at my sentence: I asked about a non-trivial, non-bus
> connected HW, which has a DT binding.

from omap3-beagle-xm.dts:
hsusb2_phy (connected through ULPI)
sound/codec (connected through McBSPs)
gpio-keys (it is not a trivial on/off)
tfp410 (DVI encoder only part of the video pipeline)

and there are components on the board which are not described at
all but work out of the box: audio connectors, usb/ethernet hub

> 
>>> I have missed virtual-gpio UART DTR discussion and assume, that the
>>> regulator is about the regulator on the GPS chip?
>> 
>> Well, it was introduced in platform device kernels that it was possible
>> to define a dtr-gpio for the uart. And there was a driver for the w2sg0004
>> that presented itself as a gpio-controller with a single gpio. This “virtual”
>> gpio was used to power on the chip as soon as DTR was asserted.
>> 
>> Parts of this had been in mainline but have been removed some months
>> ago.
> 
> I can't find any w2sg0004 reference in the mainline kernel's commit
> messages.

Well, the DTR-gpio patch was in mainline, but removed before we did submit
the w2sg0004. Therefore this submission was rejected and you can only find
in on LKML history.

> 
>>> I don't think the regulator is not acceptable. I simply think its
>>> not useful. Basically the structure would be
>>> 
>>> uart {
>>>   /* stuff */
>>>   gps {
>>>       vdd-supply = <&gpsreg>;
>>>       /* stuff */
>>> 
>>>       gpsreg: regulator {
>>>           enable-gpio = <GPIO 42>;
>>>           /* stuff */
>>>       }
>>>   }
>>> }
>> 
>> Except that the gpsreg is a subnode of /
> 
> I obviously disagree with that ;)
> But even then the regulator is useless.

In the meantime, I have proposed an IMHO even better approach.

It is not to make the gps a regulator or a subnode of some “primary interface”,
but give it a reference to the uart it is connected to.

And make it an independent node on DT root level.

Then we are completely independent on how the gps driver presents
data to any user space on any OS.

> 
>>> 
>>> and could simply be
>>> 
>>> uart {
>>>   /* stuff */
>>>   gps {
>>>       enable-gpio = <GPIO 42>;
>>>       /* stuff */
>>>   }
>>> }
>>> 
>>> Without loosing important information.
>> 
>> Only if you assume that the gpsreg must be a subnode of the uart.
> 
> DT means device tree and not device net. I sure can follow your
> argument, but from my POV its trying to create a net from the tree.

What is bad with having a net? Why must we squeeze everything into a tree structure
just because it is called such? DT language provides the syntax for references
and that allows to make nets. And it is heavily used.

> 
>>> The regulator would only be
>>> interesting if it is also used by other devices. Other devices also
>>> do not expose their internal clocks etc.
>>> 
>>>>>> The reason is there no well defined protocol to make multiple clients and
>>>>>> you can’t specify a <reg>.
>>>>>> 
>>>>>> So you are either abusing the notion of a bus or the gps chip must be a separate
>>>>>> DT node (child of something else).
>>>>>> 
>>>>>> I hope my gut feeling that we are trying to do something fundamentally wrong
>>>>>> with making the gps chip a subode of serial is now argued a little better.
>>>>>> 
>>>>>> For making the serial device control some regulator through a reference to
>>>>>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
>>>>> 
>>>>> NAK about referencing the regulator from the UART node. It should be
>>>>> referenced from the Bluetooth / GPS node. The UART port works
>>>>> without the regulator. It's the remote side, that does not work.
>>>>> We also do not add the regulators of I2C clients to the I2C host.
>>>> 
>>>> I think Pavel made a very good comment:
>>>> 
>>>> The uart node should be able to power a rs232 converter/level shifter directly
>>>> connected to it (through a regulator or gpio-regulator).
>>> 
>>> Yes and this may belong to the UART node.
>>> 
>>>> And there must be a separate mechanism to power the remote rs232 converter
>>>> and the remote device.
>>> 
>>> Yes and I think this goes to the remote device's node.
>>> 
>>>> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
>>>> UART is not only RX+TX.
>>> 
>>> so?
>> 
>> You said NAK about referencing a regulator from the UART node and
>> now?
> 
> No. I said NAK about referencing *the* regulator from the BT/GPS
> node. My NAK was about referencing a regulator in the UART node
> (local side), which is actually needed by the GPS/BT module (remote
> side).

Ah, now I understand your argument, and agree to it.

My comment was on a slightly different topic that the DTR line from the
UART (node) can be used to signal the remote regulator to be turned on.

But I learned yesterday that we can even hide this explicit signalling
mechanism (being regulator, gpio or whatever) by:

bt {
	compatible = “vendor,btchip”;
	regulator = <&regulator to power the btchip>;
	uart = <&uart1>;
	gpio = <&gpio to enable the chip>;
};

uart1 {
	/* no reference to bt */
	regulator = <&optional regulator to make the local side work>;
};

You have two nodes. One with all properties for the local uart side.
And one for the remote side. With a link so that the kernel code can
find the uart the device is connected to.

And then kernel A can use one signalling mechanism between the uart
driver and the bt driver and kernel B another. This is the level of abstracion
we should get to.

> 
>>>>> If you want to talk with an I2C device you enable the I2C device
>>>>> *and* its parent (aka the I2C host controller). I guess the same
>>>>> should be done for the UART.
>>>>> 
>>>>>>>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>>>>>>>> divided out into a separate driver.
>>>>>>>>>> 
>>>>>>>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>>>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>>>>>>>> specific and present itself as a regulator (because that is its main purpose:
>>>>>>>>>> control the LDO regulator inside the w2sg0004 chip).
>>>>>>>>> 
>>>>>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>>>>>>>> 
>>>>>>>> It has a regulator that can be controlled by a gpio…
>>>>>>> 
>>>>>>> Does it?  I guess may it does.
>>>>>>> Maybe it also has an ARM core and some memory and assorted other bits and
>>>>>>> pieces.  But we don’t really need to describe them to device tree.
>>>>>> 
>>>>>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
>>>>>> 
>>>>>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
>>>>>> connected to a GPIO - would tell if the module is really active or not. Using this would
>>>>>> make monitoring the RX line through different pinmux states obsolete.
>>>>>> 
>>>>>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
>>>>>> not wired the WAKEUP line to a  GPIO.
>>>>>> 
>>>>>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
>>>>>>> devices tree description.  If there are subcomponents that can usefully be
>>>>>>> described as well then there could be a place to describe those subcomponents.
>>>>>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
>>>>>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
>>>>>>> useful to describe the regulator inside the GPS so it could be declare that
>>>>>>> some other device which needed 1V8 made use of that regulator….
>>>>>> 
>>>>>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
>>>>>> difficult for others to do by enforcing the wrong description.
>>>>> 
>>>>> well this has nothing to do with the parent-child discussion, since
>>>>> you can obviously reference a regulator independently of its
>>>>> position in the DT.
>>>>> 
>>>>>>>> Another example to think about: the twl4030 is also not a regulator.
>>>>>>>> Nevertheless they present some regulator nodes.
>>>>>>> 
>>>>>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
>>>>>>> audio codec and  USB PHY etc etc etc.
>>>>>>> 
>>>>>>> So in device-tree there is a device-node for the TWL4030, and it has
>>>>>>> child-nodes for each sub-device.   They in turn can provide services to other
>>>>>>> devices on the board.
>>>>>> 
>>>>>> Exactly as discussed above. And there, the parent>child relation for the twl4030
>>>>>> and its subdevices is right.
>>>>>> 
>>>>>>> These sub-devices are much more independent of the whole than the regulator
>>>>>>> inside the w2sg0004 is.
>>>>>> 
>>>>>> Hm. That is probably argueable as well. At least a vague ciriterion.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>>>>>>>> but has an internal pbias_regulator that needs to be controlled.
>>>>>>> 
>>>>>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
>>>>>>> device which contains a CPU and multiple other controllers and  communicators
>>>>>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
>>>>>>> it has a device-node which is a child of the 'ocp' node - which is the main
>>>>>>> interconnect in the OMAP3 I think.
>>>>>>> 
>>>>>>> So I'm not against describing the regulator in the w2sg0004, but for
>>>>>>> consistency with everything else, it would need to be child-node of a
>>>>>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
>>>>>>> that would gain anything.
>>>>>> 
>>>>>> Well, it would gain consistency how chips with multiple components inside
>>>>>> are described.
>>>>> 
>>>>> I don't think so. Many devices do not expose all of their
>>>>> subdevices. e.g. they do not expose their internal clocks.
>>>>> Apart from that there are a few devices in the kernel, which
>>>>> do use enable-gpio(s).
>>>> 
>>>> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
>>>> revise my formulation a little.
>>>> 
>>>> It is not that parent>child is used for describing “busses or grouping subdevices".
>>>> 
>>>> It is only for “grouping addressable components”, which implies some bus.
>>>> 
>>>> This still explains the ocp component of the OMAP3 - which represents the
>>>> whole internal “interconnect” bus (see comment in omap3.dtsi).
>>>> 
>>>> Therefore you are right. It is not correct to split up a device into arbitrary
>>>> components and group them again by the parent>child pattern.
>>>> 
>>>> Although the structure of twl4030.dtsi appears to simply list and group
>>>> subcomponents without telling explicitly how to address them.
>>> 
>>> Yes and this style is not only used for twl4030, but also for other
>>> multi function devices. I do not have a problem with splitting up a
>>> device into components as long as they are referenced by other
>>> components. There is no point in exposing all internal information.
>>> For the system its not relevant, that the GPS chip has a 30MHz
>>> clock if its part of the chip and nobody else is using it.
>>> 
>>>>>> And would make it easier to see the whole w2sg0004 a child of /.
>>>>> 
>>>>> Even with the regulator subdevice I would still make the w2sg0004 a
>>>>> child of the UART port.
>>>> 
>>>> This would mean that a tty / uart is able to address multiple clients. How
>>>> could it do that?
>>> 
>>> In theory it's possible:
>>> 
>>> ? -> uart -> multiplexer -> { device1, device2 }
>>> 
>>> I hope nobody will build such a device, though :)
>>> 
>>> I don't think addressability is important for a parent > child
>>> connection, though. It is important for a reg node, of course.
>> 
>> That is the key question I am trying to get founded answers, not
>> opinions :)
>> 
>>> 
>>>>> Main reason is, that I would need to go
>>>>> through the UART to “communicate" with the w2sg0004.
>>>> 
>>>> You can always "communicate” through the UART. Even without DT. As
>>>> long as the connected chip is powered up by any means (could be
>>>> some fixed-regulator or hard wired).
>>>> 
>>>> Power control for open()/close() did even work with the DT based
>>>> DTR->virtual-gpio approach.
>>>> 
>>>> We just do not described in the DT that there is a data connection
>>>> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
>>>> 
>>>> Thus, describing a relation between the uart node and the GPS chip
>>>> in the DT is not even a requirement.
>>> 
>>> It is when the kernel should be able to handle the GPS. The DT is
>>> supposed to be independent from Linux and other operating systems
>>> may want to hide the tty if a GPS is attached to it and instead
>>> provide something like /dev/gps, which could automatically be picked
>>> up by userspace software.
>> 
>> Well, it is difficult to cover all future use cases.
>> 
>> But then you can still add a uart = <&uart1> reference to the DT node
>> of the driver. Because I understand that then the driver is the master
>> (and needs access to a hidden UART) and not the GPS chip a slave of
>> an exposed UART.
> 
> Ok. It seems we are still talk past each other. All use cases can be
> implemented using both ways - putting the node to / or putting it
> below the UART node. It simply does not matter, since kernel code
> can interpret it as needed. You just asked at some time why we need
> to know about the remote side.

Agreed. Kernel code can identify the relationship in both cases.

I asked because we have to decide between three options:
a) no relation at all
b) uart is parent node of connected device node
c) connected device node references the uart

a) would have been the least problematic. With the given use case
it is ruled out.

> 
> From my POV putting it below the UART node is more logical and from
> your POV putting it below / is more logical.

Another aspect just came to my mind:

IMHO / is the better solution because it also allows to override the
uart property in an overlay. For example board variant 1 connects to
uart1 and a hardware changeconnects the bt chip to uart2 in variant 2.

You can easily rearrange this link by including the dts of variant 1 and 
just overwriting uart = <&uart2>.

But you can’t do that with a child node. I.e. you have to overwrite the whole
uart1 and uart2 nodes to “remove” the relation between uart1 and the bt/gps chip.

This is probably the reason why gpio controllers are referenced and
not the parents of all connected chips.

> 
>>>> Probably the main problem we have is that we want to describe this
>>>> data connection but the device tree is about describing how to
>>>> address components and data flow is left to internal APIs. Or
>>>> “ports” like in the video pipelines.
>>> 
>>> As I wrote the tree structure shows how to "reach" a component for
>>> accessing its configuration/data from the system.
>> 
>> Yes, you wrote and I already pointed out that I disagree. It
>> contradicts what
>> 
>> http://www.devicetree.org/Device_Tree_Usage#Devices
>> 
>> appears to tell me. So who is right?
> 
> From my POV the page is simply focused on standard bindings, which
> have already been established.

Well, new bindings should have very good reasons not to follow these
principles.

> If I understand you right, your POV
> does not allow child nodes (which are not directly under /) without
> reg property / address.

Yes, I read it like that.

Slides 22 and 27 of

http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf

also appear to suggest to put busses and devices on root level.

Well, he says “typically”, because he just describes the status quo and is
not wanting to set a standard.

> Just have a look at the DT binding
> documentation directory in the kernel - we already have them.

Maybe, todays Linux bidings and DTs are not general enough in such cases
and should be revisited? But that goes far beyond our discussion and problem.

> 
>>>> Let me raise the question:
>>>> 
>>>> Why do we need to describe in the DT (independently of Linux power
>>>> control structures and drivers!) that the GPS data interface is
>>>> connected to a specific UART?
>>>> Who needs this information and for which purpose?
>>> 
>>> Because an operating system can provide drivers, which completly
>>> hide away the UART connection. Example:
>>> 
>>> Let's assume we have an UART attached Bluetooth chip connected to
>>> the second UART.
>>> 
>>> In Linux, userspace currently must know, that the BT module is
>>> connected to this port and correctly setup the port for BT usage.
>>> Once this has been done the port is completly handled in the kernel
>>> and userspace can ignore the UART.
>> 
>> Ok, this is a reasonable example. But I still don’ see that it
>> requires that the bt chip must be a subnode of the uart.
> 
> It doesn't. I just answered your question, which was independent
> of the actual node position.
> 
>>> So why must the user configure the port? Because the kernel does not
>>> know, that a BT chip is connected to the port.
>> 
>> Then, I would suggest to write it like you have done:
>> 
>> “the BT chip is connected to the port uart1”
>> 
>> This can be easily translated into DT language:
>> 
>> / {
>> 	bt {
>> 		compatible = “vendor,chip”;
>> 		uart = <&uart1>;	/* this chip is connected to uart1 */
>> 		enable-gpio = <&gpio3 17 0>;
>> 	};
>> };
>> 
>> This also resembles the “port” mechanism (just simplified because it is not
>> a backwards forward linkage).
>> 
>> Or exactly follows the pattern that a driver that wants to use
>> some gpio simply links to the gpio controller. Or a driver wants
>> to control a gpio.
>> 
>> What I don’t understand is what is here so special to not use this
>> DT pattern.
>> 
>> But It could also open a different solution for the tty open() ->
>> w2sg power on problem.
>> 
>> / {
>> 	gps {
>> 		compatible = “wi2wi,w2sg0004”;
>> 		uart = <&uart1>;	/* this chip is connected to uart1 */
>> 		enable-gpio = <&gpio3 17 0>;
>> 	};
>> };
>> 
>> Here, the w2sg0004 probe function could register with uart1 to get notified
>> about open/close events and then do what it has to do.
>> 
>> In that case the w2sg0004 driver would not even need to present itself
>> as a virtual gpio (for DTR) or a regulator because it has a kernel internal
>> API to apply to tell the uart what it wants to do.
> 
> Again the same can be done if its a child-node of the UART. It is
> simply a question of reading the "uart" property vs loading the
> driver from the UART and access the parent device.

Ok.

> 
>>> If the kernel gets
>>> this information from DT it can do all the UART handling itself and
>>> provide a bluetooth device without any user interaction.
>> 
>> I think we should get a better understanding of the DT design patterns.
>> 
>> IMHO (or IMPoV):
>> 
>> * parent>child is not for describing “control” or “primary interface” but addressability
> 
> We obviously disagree here :)

Exactly. This is why I am trying to find a concise definition how it should be.

And to be honest I am quite worried that it does not appear to exist but DT
should be stable and well defined and even OS agnostic. How can that
work?

> 
>> * if a driver needs access to another component, a reference property is used
> 
> Here we also disagree. The kernel also makes use of parent > child
> connections (e.g. the driver for an i2c client node will request
> data via its parent)

That is in my view strictly following because i2c is a bus and therefore
there is a parent>child relation and it is ok to use it to request the parent.

But in my words the bus is not “another component”. Another component
in my example means the “other" between BT chip and SoC with UART.

> and sometimes even sibling relationships (in
> MFD devices).

I am not at all against using the information that is present in the DT :)
I just want to have the DT the information encoded in the right way.

> 
> So let me summarize:
> 
> * Option A: Do not encode remote side information
>   Rationale: UART port can be opened in userspace without that info
>   Counterargument: This information is needed if the OS should be
>   able to hide away the tty and provide support for the connected
>   remote device (e.g. provide a bluetooth device instead of a tty)

Agreed. I think we can drop this option since there are good use cases.

A second one for the records: if we want to provide data from an UART
connected GPS chip through an iio interface.

> 
> * Option B: Put UART remote side node to / and add a reference to the UART port
>   Rationale: DT wiki page indicates, that child nodes must be addressable
and UART is not per se a “bus”.

> 
> * Option C: Put UART remote side node below the UART node
>   Rationale: Remote device is accessed through the UART
and treat serial connections as single-client busses

> 
> Since this is about a subsystem binding DT maintainers ACK is
> definitely needed, so maybe we should just wait for their decision.

Good summary! 

So let’s wait for questions / clarifications / comments / decisions by DT maintainers.

Thanks,
NIkolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 19:08 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Wed, Mar 25, 2015 at 05:44:42PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Am 25.03.2015 um 16:21 schrieb Sebastian Reichel <sre@kernel.org>:
>>> On Wed, Mar 25, 2015 at 08:59:14AM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> Am 25.03.2015 um 02:45 schrieb Sebastian Reichel <sre@kernel.org>:
>>>>> On Tue, Mar 24, 2015 at 06:58:15PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>>> So you propose that the parent->child relationship is “control”? I.e. some
>>>>>> channel which allows to address some bus client (through <reg>) and
>>>>>> control that devices.
>>>>>> 
>>>>>> Makes sense. This is how i2c and spi clients are specified.
>>>>>> 
>>>>>>> In the case of our GPS, it receives control over the serial connection from
>>>>>>> the UART,
>>>>>> 
>>>>>> Ahem - does it?
>>>>>> 
>>>>>> AFAIK the chip simply starts to emit NMEA records if powered on.
>>>>>> There is no command going over the serial interface to address it
>>>>>> or control it.
>>>>> 
>>>>> Right, since GPS basically doesn't need any configuration/control.
>>>>> That’s not true for other UART attached devices, though.
>>>> 
>>>> Do you have an example? Usually an UART data stream is transparently
>>>> presented to a /dev/tty - and user-space daemon can configure/control the
>>>> attached device. In most cases it can mix payload data and control command
>>>> by some AT command and escape sequences.
>>> 
>>> Yes, but the configuration is minimal. Anyways as you said there
>>> *is* some kind of control happening over the UART.
>> 
>> Control is happening on a higher network stack level than UART. It
>> control is done through AT commands.
> 
> Yes, obviously UART is only the physical layer. The same is true for
> busses and does not really matter.

Fine that we agree on that. I just mentioned it because we discussed about line
disciplines and tty which are higher level.

> 
>>>>>>> also receives control via a GPIO to the on/off pin, and also needs
>>>>>>> a regulator to power the antenna.
>>>>>>> 
>>>>>>> So should the parent be the uart, the on/off GPIO, or the regulator?
>>>>>>> 
>>>>>>> I would much rather there wasn't a parent, and that each of these were listed
>>>>>>> as ad-hoc attribute assignments.  But device-tree says there must be a parent
>>>>>>> (where possible), and the parent is the thing that is “primarily" in control.
>>>>>> 
>>>>>> Well, IMHO the “parent” could also be the root. Representing the
>>>>>> whole board.
>>>>>> 
>>>>>> Nevertheless, I doubt your rule that “ability to control” defines
>>>>>> the parent>child relation (see below).
>>>>>> 
>>>>>>> 
>>>>>>> I think the GPS is “primarily" a uart-attached device.
>>>>>> 
>>>>>> But not in the same way as an I2C device.
>>>>>> 
>>>>>> Especially the serial interface is not a bus and not used for
>>>>>> signalling and power control. It is payload data (only).
>>>>> 
>>>>> Actually many I2C devices are also powered on/off via a GPIO and
>>>>> even use additional GPIOs for sending interrupts. Nevertheless they
>>>>> are normally identified as an I2C device.
>>>> 
>>>> Because I2C is a bus that can address multiple clients and gpio isn’t
>>>> a bus and a point-to-point connection.
>>>> 
>>>> But IMHO it is not because they (can) send payload data over i2c.
>>> 
>>> From my POV it's not because I2C is a bus, but because the primary
>>> function is happening via I2C (e.g. configuring sensor, gettings its
>>> data). The GPIOs are only needed to compensate some I2C shortcomings
>>> (missing irq feature in I2C) or reduce the complexity of the client
>>> (power GPIO). The actual system interaction with the I2C chip is
>>> going via I2C, though.
>> 
>> Yes, but this is in my new understanding irrelevant for proper DT
>> description.
> 
> And for my understanding it is. We are arguing in a circle…

Yes, and that is the reason why I try to go to a higher level of discussion. I.e.
find out the principles behind. If we can agree on those, it becomes easy
to decide the details.

> 
>>>>>> If you assume that parent>child relationship is about control (only). But if it
>>>>>> is about data flow, there is a different concept in DT. For example the CSI/DSI
>>>>>> (OMAP DSS) use the “port” concept.
>>>>> 
>>>>> Yes, this is about data not going to the cpu / system memory.
>>>> 
>>>> Really? The frame buffer data is in system memory and gets to the panel. Or a
>>>> camera image ends up in system memory.
>>> 
>>> Really? So the panel accesses the system memory? Check again. The
>>> panel is simply connected via DSI/SDI/... and does not access the
>>> system memory at all. The display controller OTH does. So let's have
>>> a look at the DT structure (simplified):
>>> 
>>> ocp -> dss -> { port = <&panel>; }
>>> ... -> spi -> panel { port = <&dss>; }
>>> 
>>> So the port models a device-to-device connection, which works
>>> independent of the remaining system. No system memory is involved.
>> 
>> Sorry, but I can’t exactly follow what you want to show.
>> 
>> Yes, the port mechanism describes a device to device connection.
>> 
>> But it does not describe system memory. Although it is the source of
>> the video (i.e. the framebuffer).
>> 
>> This shows that the DT does not necessarily describe data flow.
>> 
>> So why do you want to describe data flow from tty to uart to some
>> connected device?
> 
> It shows, that the tree models system memory flow and adds
> references for stuff not being about the system memory flow.
> 
> So let's say I want to configure the panel - I can simply walk
> through the parent structure to know how to access it. The same
> is true for the display controller.

Ok, I see. Someone has introduced the word “system memory” in this
discussion about addressing devices.

> 
>>>>>> This means that indeed parent>child is used for control, e.g. I2C
>>>>>> or SPI to tell the panel controller to switch on.
>>>>> 
>>>>> well parent > child is not about power control, but about "primary"
>>>>> control.
>>>> 
>>>> Can you clearly and precisely define what “primary” control is? I think
>>>> two people will have three opinions about that.
>>>> 
>>>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>>>> which makes the light (NMES records) turned on.
>>>> 
>>>> Therefore we should make it the subnode of some gpio-controller, shouldn’t we?
>>> 
>>> I never thing of enable gpios to be the main interface, since it can
>>> simply be connected to some voltage and be enabled constantly. It's
>>> just some kind of helper for the device. It does not really exchange
>>> data between the system and the device, though. (Note: This is
>>> not true, if the GPIOs are used for bitbanging some high-level
>>> protocol, in which case a virtual controller (like i2c-gpio) is
>>> modelled in DT).
>>> 
>>> So let's have a look at the UART link again. It is transporting
>>> non-trivial data from the UART to the system and it is handling
>>> the data I actually want. It's providing access to the device's
>>> “registers".
>> 
>> Well, this view can be followed, but is as strange and bent to fit
>> like my view of the w2sg0004 as a “regulator”.
>> 
>>> 
>>> For me its clear, that one would expect the GPS under the UART
>>> port, since when speaking with other developers I would describe
>>> the GPS as being a "UART attached GPS chip". From me the
>>> differences between a UART port and a SPI port from a system
>>> software’s POV can be reduced to missing multi-device support.
>> 
>> DT does not necessarily have to describe data flow as we have seen
>> in the video pipeline example.
> 
> sure, it shows how to access the device. This link may not
> necessarily be the same as the one, which takes care of the
> data.

Ok, fine that we agree on this.

> 
>>> so show me some non-bus connections, which are actually used to
>>> exchange non-trivial data (with on/off being trivial). We currently
>>> do not really have them.
>> 
>> Are we talking about DT or data flow from user space through the
>> kernel?
> 
> /me is not sure why you are regularly introducing userspace.

Because I am under the impression that some arguments in this discussion
are driven by a user-space view.

> It's
> completly irrelevant when its assumed, that the kernel should
> abstract devices. DT is about giving the kernel knowledge about
> the *hardware*, so that it can implement this abstraction without
> any user interaction.

Agreed.

> 
> Coming back at my sentence: I asked about a non-trivial, non-bus
> connected HW, which has a DT binding.

from omap3-beagle-xm.dts:
hsusb2_phy (connected through ULPI)
sound/codec (connected through McBSPs)
gpio-keys (it is not a trivial on/off)
tfp410 (DVI encoder only part of the video pipeline)

and there are components on the board which are not described at
all but work out of the box: audio connectors, usb/ethernet hub

> 
>>> I have missed virtual-gpio UART DTR discussion and assume, that the
>>> regulator is about the regulator on the GPS chip?
>> 
>> Well, it was introduced in platform device kernels that it was possible
>> to define a dtr-gpio for the uart. And there was a driver for the w2sg0004
>> that presented itself as a gpio-controller with a single gpio. This “virtual”
>> gpio was used to power on the chip as soon as DTR was asserted.
>> 
>> Parts of this had been in mainline but have been removed some months
>> ago.
> 
> I can't find any w2sg0004 reference in the mainline kernel's commit
> messages.

Well, the DTR-gpio patch was in mainline, but removed before we did submit
the w2sg0004. Therefore this submission was rejected and you can only find
in on LKML history.

> 
>>> I don't think the regulator is not acceptable. I simply think its
>>> not useful. Basically the structure would be
>>> 
>>> uart {
>>>   /* stuff */
>>>   gps {
>>>       vdd-supply = <&gpsreg>;
>>>       /* stuff */
>>> 
>>>       gpsreg: regulator {
>>>           enable-gpio = <GPIO 42>;
>>>           /* stuff */
>>>       }
>>>   }
>>> }
>> 
>> Except that the gpsreg is a subnode of /
> 
> I obviously disagree with that ;)
> But even then the regulator is useless.

In the meantime, I have proposed an IMHO even better approach.

It is not to make the gps a regulator or a subnode of some “primary interface”,
but give it a reference to the uart it is connected to.

And make it an independent node on DT root level.

Then we are completely independent on how the gps driver presents
data to any user space on any OS.

> 
>>> 
>>> and could simply be
>>> 
>>> uart {
>>>   /* stuff */
>>>   gps {
>>>       enable-gpio = <GPIO 42>;
>>>       /* stuff */
>>>   }
>>> }
>>> 
>>> Without loosing important information.
>> 
>> Only if you assume that the gpsreg must be a subnode of the uart.
> 
> DT means device tree and not device net. I sure can follow your
> argument, but from my POV its trying to create a net from the tree.

What is bad with having a net? Why must we squeeze everything into a tree structure
just because it is called such? DT language provides the syntax for references
and that allows to make nets. And it is heavily used.

> 
>>> The regulator would only be
>>> interesting if it is also used by other devices. Other devices also
>>> do not expose their internal clocks etc.
>>> 
>>>>>> The reason is there no well defined protocol to make multiple clients and
>>>>>> you can’t specify a <reg>.
>>>>>> 
>>>>>> So you are either abusing the notion of a bus or the gps chip must be a separate
>>>>>> DT node (child of something else).
>>>>>> 
>>>>>> I hope my gut feeling that we are trying to do something fundamentally wrong
>>>>>> with making the gps chip a subode of serial is now argued a little better.
>>>>>> 
>>>>>> For making the serial device control some regulator through a reference to
>>>>>> a regulator, I am very fine. It is what you do for the W2CBW bluetooth part.
>>>>> 
>>>>> NAK about referencing the regulator from the UART node. It should be
>>>>> referenced from the Bluetooth / GPS node. The UART port works
>>>>> without the regulator. It's the remote side, that does not work.
>>>>> We also do not add the regulators of I2C clients to the I2C host.
>>>> 
>>>> I think Pavel made a very good comment:
>>>> 
>>>> The uart node should be able to power a rs232 converter/level shifter directly
>>>> connected to it (through a regulator or gpio-regulator).
>>> 
>>> Yes and this may belong to the UART node.
>>> 
>>>> And there must be a separate mechanism to power the remote rs232 converter
>>>> and the remote device.
>>> 
>>> Yes and I think this goes to the remote device's node.
>>> 
>>>> The standard signalling for this are the RTS/DTR lines of an UART/RS232.
>>>> UART is not only RX+TX.
>>> 
>>> so?
>> 
>> You said NAK about referencing a regulator from the UART node and
>> now?
> 
> No. I said NAK about referencing *the* regulator from the BT/GPS
> node. My NAK was about referencing a regulator in the UART node
> (local side), which is actually needed by the GPS/BT module (remote
> side).

Ah, now I understand your argument, and agree to it.

My comment was on a slightly different topic that the DTR line from the
UART (node) can be used to signal the remote regulator to be turned on.

But I learned yesterday that we can even hide this explicit signalling
mechanism (being regulator, gpio or whatever) by:

bt {
	compatible = “vendor,btchip”;
	regulator = <&regulator to power the btchip>;
	uart = <&uart1>;
	gpio = <&gpio to enable the chip>;
};

uart1 {
	/* no reference to bt */
	regulator = <&optional regulator to make the local side work>;
};

You have two nodes. One with all properties for the local uart side.
And one for the remote side. With a link so that the kernel code can
find the uart the device is connected to.

And then kernel A can use one signalling mechanism between the uart
driver and the bt driver and kernel B another. This is the level of abstracion
we should get to.

> 
>>>>> If you want to talk with an I2C device you enable the I2C device
>>>>> *and* its parent (aka the I2C host controller). I guess the same
>>>>> should be done for the UART.
>>>>> 
>>>>>>>>>> All the following is very special logic for the w2sg0004 chip which should be
>>>>>>>>>> divided out into a separate driver.
>>>>>>>>>> 
>>>>>>>>>> Marek and me already had proposed such a chip specific driver (to be located
>>>>>>>>>> in drivers/misc) some months ago. It would encapsulate everything w2sg0004
>>>>>>>>>> specific and present itself as a regulator (because that is its main purpose:
>>>>>>>>>> control the LDO regulator inside the w2sg0004 chip).
>>>>>>>>> 
>>>>>>>>> Presenting itself as a regulator would be wrong because it isn’t a regulator.
>>>>>>>> 
>>>>>>>> It has a regulator that can be controlled by a gpio…
>>>>>>> 
>>>>>>> Does it?  I guess may it does.
>>>>>>> Maybe it also has an ARM core and some memory and assorted other bits and
>>>>>>> pieces.  But we don’t really need to describe them to device tree.
>>>>>> 
>>>>>> Well, if I look into the data sheet, it has indeed an LDO from 3.3V to 1.8V.
>>>>>> 
>>>>>> Not to make you confused: the w2sg0084 would have a WAKEUP output which - if
>>>>>> connected to a GPIO - would tell if the module is really active or not. Using this would
>>>>>> make monitoring the RX line through different pinmux states obsolete.
>>>>>> 
>>>>>> But the only Linux board using the w2sg00x4 appears to be the GTA04 and it has
>>>>>> not wired the WAKEUP line to a  GPIO.
>>>>>> 
>>>>>>> The w2sg0004 is primarily a GPS device, so that needs to be stated in the
>>>>>>> devices tree description.  If there are subcomponents that can usefully be
>>>>>>> described as well then there could be a place to describe those subcomponents.
>>>>>>> I notice that there is a "1V8-out" pin, so presumable the chip can deliver a
>>>>>>> 1V8 source based on its 3V3 input.  If a board made use of that, it could be
>>>>>>> useful to describe the regulator inside the GPS so it could be declare that
>>>>>>> some other device which needed 1V8 made use of that regulator….
>>>>>> 
>>>>>> Yes. Well, even if *we* do not use it in this way yet, we should not make it
>>>>>> difficult for others to do by enforcing the wrong description.
>>>>> 
>>>>> well this has nothing to do with the parent-child discussion, since
>>>>> you can obviously reference a regulator independently of its
>>>>> position in the DT.
>>>>> 
>>>>>>>> Another example to think about: the twl4030 is also not a regulator.
>>>>>>>> Nevertheless they present some regulator nodes.
>>>>>>> 
>>>>>>> The TWL4030 is a multifunction device which contains regulators and GPIOs and
>>>>>>> audio codec and  USB PHY etc etc etc.
>>>>>>> 
>>>>>>> So in device-tree there is a device-node for the TWL4030, and it has
>>>>>>> child-nodes for each sub-device.   They in turn can provide services to other
>>>>>>> devices on the board.
>>>>>> 
>>>>>> Exactly as discussed above. And there, the parent>child relation for the twl4030
>>>>>> and its subdevices is right.
>>>>>> 
>>>>>>> These sub-devices are much more independent of the whole than the regulator
>>>>>>> inside the w2sg0004 is.
>>>>>> 
>>>>>> Hm. That is probably argueable as well. At least a vague ciriterion.
>>>>>>> 
>>>>>>>> 
>>>>>>>> Or take the OMAP3 pbias_regulator. The OMAP3 isn’t a regulator as well
>>>>>>>> but has an internal pbias_regulator that needs to be controlled.
>>>>>>> 
>>>>>>> I don't know much about a "pbias_regulator", but the OMAP3 is a multifunction
>>>>>>> device which contains a CPU and multiple other controllers and  communicators
>>>>>>> and stuff.  One of the components in the OMAP3 is this pbias_regulator, and
>>>>>>> it has a device-node which is a child of the 'ocp' node - which is the main
>>>>>>> interconnect in the OMAP3 I think.
>>>>>>> 
>>>>>>> So I'm not against describing the regulator in the w2sg0004, but for
>>>>>>> consistency with everything else, it would need to be child-node of a
>>>>>>> device-node which describes the w2sg0004 as a whole.  I'm not sure that doing
>>>>>>> that would gain anything.
>>>>>> 
>>>>>> Well, it would gain consistency how chips with multiple components inside
>>>>>> are described.
>>>>> 
>>>>> I don't think so. Many devices do not expose all of their
>>>>> subdevices. e.g. they do not expose their internal clocks.
>>>>> Apart from that there are a few devices in the kernel, which
>>>>> do use enable-gpio(s).
>>>> 
>>>> After reading http://www.devicetree.org/Device_Tree_Usage#Devices I must
>>>> revise my formulation a little.
>>>> 
>>>> It is not that parent>child is used for describing “busses or grouping subdevices".
>>>> 
>>>> It is only for “grouping addressable components”, which implies some bus.
>>>> 
>>>> This still explains the ocp component of the OMAP3 - which represents the
>>>> whole internal “interconnect” bus (see comment in omap3.dtsi).
>>>> 
>>>> Therefore you are right. It is not correct to split up a device into arbitrary
>>>> components and group them again by the parent>child pattern.
>>>> 
>>>> Although the structure of twl4030.dtsi appears to simply list and group
>>>> subcomponents without telling explicitly how to address them.
>>> 
>>> Yes and this style is not only used for twl4030, but also for other
>>> multi function devices. I do not have a problem with splitting up a
>>> device into components as long as they are referenced by other
>>> components. There is no point in exposing all internal information.
>>> For the system its not relevant, that the GPS chip has a 30MHz
>>> clock if its part of the chip and nobody else is using it.
>>> 
>>>>>> And would make it easier to see the whole w2sg0004 a child of /.
>>>>> 
>>>>> Even with the regulator subdevice I would still make the w2sg0004 a
>>>>> child of the UART port.
>>>> 
>>>> This would mean that a tty / uart is able to address multiple clients. How
>>>> could it do that?
>>> 
>>> In theory it's possible:
>>> 
>>> ? -> uart -> multiplexer -> { device1, device2 }
>>> 
>>> I hope nobody will build such a device, though :)
>>> 
>>> I don't think addressability is important for a parent > child
>>> connection, though. It is important for a reg node, of course.
>> 
>> That is the key question I am trying to get founded answers, not
>> opinions :)
>> 
>>> 
>>>>> Main reason is, that I would need to go
>>>>> through the UART to “communicate" with the w2sg0004.
>>>> 
>>>> You can always "communicate” through the UART. Even without DT. As
>>>> long as the connected chip is powered up by any means (could be
>>>> some fixed-regulator or hard wired).
>>>> 
>>>> Power control for open()/close() did even work with the DT based
>>>> DTR->virtual-gpio approach.
>>>> 
>>>> We just do not described in the DT that there is a data connection
>>>> from uart1 to the RX/TX pins. But you just open /dev/ttyO1.
>>>> 
>>>> Thus, describing a relation between the uart node and the GPS chip
>>>> in the DT is not even a requirement.
>>> 
>>> It is when the kernel should be able to handle the GPS. The DT is
>>> supposed to be independent from Linux and other operating systems
>>> may want to hide the tty if a GPS is attached to it and instead
>>> provide something like /dev/gps, which could automatically be picked
>>> up by userspace software.
>> 
>> Well, it is difficult to cover all future use cases.
>> 
>> But then you can still add a uart = <&uart1> reference to the DT node
>> of the driver. Because I understand that then the driver is the master
>> (and needs access to a hidden UART) and not the GPS chip a slave of
>> an exposed UART.
> 
> Ok. It seems we are still talk past each other. All use cases can be
> implemented using both ways - putting the node to / or putting it
> below the UART node. It simply does not matter, since kernel code
> can interpret it as needed. You just asked at some time why we need
> to know about the remote side.

Agreed. Kernel code can identify the relationship in both cases.

I asked because we have to decide between three options:
a) no relation at all
b) uart is parent node of connected device node
c) connected device node references the uart

a) would have been the least problematic. With the given use case
it is ruled out.

> 
> From my POV putting it below the UART node is more logical and from
> your POV putting it below / is more logical.

Another aspect just came to my mind:

IMHO / is the better solution because it also allows to override the
uart property in an overlay. For example board variant 1 connects to
uart1 and a hardware changeconnects the bt chip to uart2 in variant 2.

You can easily rearrange this link by including the dts of variant 1 and 
just overwriting uart = <&uart2>.

But you can’t do that with a child node. I.e. you have to overwrite the whole
uart1 and uart2 nodes to “remove” the relation between uart1 and the bt/gps chip.

This is probably the reason why gpio controllers are referenced and
not the parents of all connected chips.

> 
>>>> Probably the main problem we have is that we want to describe this
>>>> data connection but the device tree is about describing how to
>>>> address components and data flow is left to internal APIs. Or
>>>> “ports” like in the video pipelines.
>>> 
>>> As I wrote the tree structure shows how to "reach" a component for
>>> accessing its configuration/data from the system.
>> 
>> Yes, you wrote and I already pointed out that I disagree. It
>> contradicts what
>> 
>> http://www.devicetree.org/Device_Tree_Usage#Devices
>> 
>> appears to tell me. So who is right?
> 
> From my POV the page is simply focused on standard bindings, which
> have already been established.

Well, new bindings should have very good reasons not to follow these
principles.

> If I understand you right, your POV
> does not allow child nodes (which are not directly under /) without
> reg property / address.

Yes, I read it like that.

Slides 22 and 27 of

http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf

also appear to suggest to put busses and devices on root level.

Well, he says “typically”, because he just describes the status quo and is
not wanting to set a standard.

> Just have a look at the DT binding
> documentation directory in the kernel - we already have them.

Maybe, todays Linux bidings and DTs are not general enough in such cases
and should be revisited? But that goes far beyond our discussion and problem.

> 
>>>> Let me raise the question:
>>>> 
>>>> Why do we need to describe in the DT (independently of Linux power
>>>> control structures and drivers!) that the GPS data interface is
>>>> connected to a specific UART?
>>>> Who needs this information and for which purpose?
>>> 
>>> Because an operating system can provide drivers, which completly
>>> hide away the UART connection. Example:
>>> 
>>> Let's assume we have an UART attached Bluetooth chip connected to
>>> the second UART.
>>> 
>>> In Linux, userspace currently must know, that the BT module is
>>> connected to this port and correctly setup the port for BT usage.
>>> Once this has been done the port is completly handled in the kernel
>>> and userspace can ignore the UART.
>> 
>> Ok, this is a reasonable example. But I still don’ see that it
>> requires that the bt chip must be a subnode of the uart.
> 
> It doesn't. I just answered your question, which was independent
> of the actual node position.
> 
>>> So why must the user configure the port? Because the kernel does not
>>> know, that a BT chip is connected to the port.
>> 
>> Then, I would suggest to write it like you have done:
>> 
>> “the BT chip is connected to the port uart1”
>> 
>> This can be easily translated into DT language:
>> 
>> / {
>> 	bt {
>> 		compatible = “vendor,chip”;
>> 		uart = <&uart1>;	/* this chip is connected to uart1 */
>> 		enable-gpio = <&gpio3 17 0>;
>> 	};
>> };
>> 
>> This also resembles the “port” mechanism (just simplified because it is not
>> a backwards forward linkage).
>> 
>> Or exactly follows the pattern that a driver that wants to use
>> some gpio simply links to the gpio controller. Or a driver wants
>> to control a gpio.
>> 
>> What I don’t understand is what is here so special to not use this
>> DT pattern.
>> 
>> But It could also open a different solution for the tty open() ->
>> w2sg power on problem.
>> 
>> / {
>> 	gps {
>> 		compatible = “wi2wi,w2sg0004”;
>> 		uart = <&uart1>;	/* this chip is connected to uart1 */
>> 		enable-gpio = <&gpio3 17 0>;
>> 	};
>> };
>> 
>> Here, the w2sg0004 probe function could register with uart1 to get notified
>> about open/close events and then do what it has to do.
>> 
>> In that case the w2sg0004 driver would not even need to present itself
>> as a virtual gpio (for DTR) or a regulator because it has a kernel internal
>> API to apply to tell the uart what it wants to do.
> 
> Again the same can be done if its a child-node of the UART. It is
> simply a question of reading the "uart" property vs loading the
> driver from the UART and access the parent device.

Ok.

> 
>>> If the kernel gets
>>> this information from DT it can do all the UART handling itself and
>>> provide a bluetooth device without any user interaction.
>> 
>> I think we should get a better understanding of the DT design patterns.
>> 
>> IMHO (or IMPoV):
>> 
>> * parent>child is not for describing “control” or “primary interface” but addressability
> 
> We obviously disagree here :)

Exactly. This is why I am trying to find a concise definition how it should be.

And to be honest I am quite worried that it does not appear to exist but DT
should be stable and well defined and even OS agnostic. How can that
work?

> 
>> * if a driver needs access to another component, a reference property is used
> 
> Here we also disagree. The kernel also makes use of parent > child
> connections (e.g. the driver for an i2c client node will request
> data via its parent)

That is in my view strictly following because i2c is a bus and therefore
there is a parent>child relation and it is ok to use it to request the parent.

But in my words the bus is not “another component”. Another component
in my example means the “other" between BT chip and SoC with UART.

> and sometimes even sibling relationships (in
> MFD devices).

I am not at all against using the information that is present in the DT :)
I just want to have the DT the information encoded in the right way.

> 
> So let me summarize:
> 
> * Option A: Do not encode remote side information
>   Rationale: UART port can be opened in userspace without that info
>   Counterargument: This information is needed if the OS should be
>   able to hide away the tty and provide support for the connected
>   remote device (e.g. provide a bluetooth device instead of a tty)

Agreed. I think we can drop this option since there are good use cases.

A second one for the records: if we want to provide data from an UART
connected GPS chip through an iio interface.

> 
> * Option B: Put UART remote side node to / and add a reference to the UART port
>   Rationale: DT wiki page indicates, that child nodes must be addressable
and UART is not per se a “bus”.

> 
> * Option C: Put UART remote side node below the UART node
>   Rationale: Remote device is accessed through the UART
and treat serial connections as single-client busses

> 
> Since this is about a subsystem binding DT maintainers ACK is
> definitely needed, so maybe we should just wait for their decision.

Good summary! 

So let’s wait for questions / clarifications / comments / decisions by DT maintainers.

Thanks,
NIkolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 12131 bytes --]

Hi,

On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote:
> > Coming back at my sentence: I asked about a non-trivial, non-bus
> > connected HW, which has a DT binding.
> 
> from omap3-beagle-xm.dts:
> hsusb2_phy (connected through ULPI)
> gpio-keys (it is not a trivial on/off)
> tfp410 (DVI encoder only part of the video pipeline)

These just need a couple of gpios. For me that's trivial compared to
an interface as complex as UART. Since they do not have any complex
interface they could be a child of, they must land in /.

> sound/codec (connected through McBSPs)

The audio codec is a child device of the TWL. The node you are
talking about is a ***virtual*** device. See also

http://devicetree.org/SoC_Audio

Note that the audio binding of many devices is not that "clean",
since quite some relationships are hidden away behind kernel quirks
and very specific compatible strings.

> and there are components on the board which are not described at
> all but work out of the box: audio connectors, usb/ethernet hub

Sure. Everything that can be identified automatically (USB/Ethernet
stuff) is not encoded into DT. DT has been created to provide a
description for devices, which can *not* be identified automatically.

And passive components like audio connectors are normally not
encoded into DT, since no configuration is needed and no information
is gained. Before you argument with video connectors: Yes they are
different, but IMHO for good reasons:

1. The user can see "DVI" label for DVI output and "HDMI" label
   for HDMI output. This is not known by the display controller.
2. The display data channel is i2c and the connector may use a
   system i2c controller together with the data wires provided by
   the display controller. The display subsystem must know which
   i2c controller takes care of the port.

> In the meantime, I have proposed an IMHO even better approach.
> 
> It is not to make the gps a regulator or a subnode of some “primary interface”,
> but give it a reference to the uart it is connected to.
> 
> And make it an independent node on DT root level.
> 
> Then we are completely independent on how the gps driver presents
> data to any user space on any OS.

IMHO that approach is not better per se. The child variant is more
generic it contains information without the kernel even knowing
about uart specific stuff.

Note, that we could always use references in DT. The tree structure
is not needed at all, since references make it possible to describe
a graph. Obviously that would defeat the purpose of the tree
structure. In my opinion making something a node in / is always the
last resort and in my perspective it has been handled in such a way
so far.

> What is bad with having a net? Why must we squeeze everything into
> a tree structure just because it is called such? DT language
> provides the syntax for references and that allows to make nets.
> And it is heavily used.

I think so far references were mainly used when tree structure was
too limited to describe something.

> >> You said NAK about referencing a regulator from the UART node and
> >> now?
> > 
> > No. I said NAK about referencing *the* regulator from the BT/GPS
> > node. My NAK was about referencing a regulator in the UART node
> > (local side), which is actually needed by the GPS/BT module (remote
> > side).
> 
> Ah, now I understand your argument, and agree to it.
> 
> My comment was on a slightly different topic that the DTR line from the
> UART (node) can be used to signal the remote regulator to be turned on.
> 
> But I learned yesterday that we can even hide this explicit signalling
> mechanism (being regulator, gpio or whatever) by:
> 
> bt {
> 	compatible = “vendor,btchip”;
> 	regulator = <&regulator to power the btchip>;
> 	uart = <&uart1>;
> 	gpio = <&gpio to enable the chip>;
> };
> 
> uart1 {
> 	/* no reference to bt */
> 	regulator = <&optional regulator to make the local side work>;
> };
> 
> You have two nodes. One with all properties for the local uart side.
> And one for the remote side. With a link so that the kernel code can
> find the uart the device is connected to.
> 
> And then kernel A can use one signalling mechanism between the uart
> driver and the bt driver and kernel B another. This is the level of abstracion
> we should get to.

Since this part of the argumentation is about the regulator VS
enable gpio let's leave out the child VS uart-reference here.

So first note about the regulators: they are normally referenced
using something like "vcc-supply = <&regulator>;". This makes it
possible to request more than one regulator. It also shows, what
they are normally used for (you have a module, which has a vcc-pin
and you need some regulator (which can be a fixed-regulator) to
drive it.

So now if the module has an enable-gpio one has two options:

1) add "enable-gpio" to the module's node

2) break up the module into subcomponents, which expose its
   internal structure

Normally in DT option 1) is used, if 2) is not needed. If
some *other* component also makes use of the regulator enabled
by the enable-gpio you would choose option 2), otherwise you
would choose option 1) to keep everything simpler.

> > From my POV putting it below the UART node is more logical and from
> > your POV putting it below / is more logical.
> 
> Another aspect just came to my mind:
> 
> IMHO / is the better solution because it also allows to override the
> uart property in an overlay. For example board variant 1 connects to
> uart1 and a hardware changeconnects the bt chip to uart2 in variant 2.
> 
> You can easily rearrange this link by including the dts of variant 1 and 
> just overwriting uart = <&uart2>.
> 
> But you can’t do that with a child node. I.e. you have to overwrite the whole
> uart1 and uart2 nodes to “remove” the relation between uart1 and the bt/gps chip.
> 
> This is probably the reason why gpio controllers are referenced and
> not the parents of all connected chips.

The main problem with making gpio controllers parents is, that you
can have only one parent. Since most chips already have a parent
gpios are referenced. Then in opposite to high-level interfaces
many devices need multiple GPIOs. So it will be hard to find a
single parent.

So let's assume there is 20% of devices, which need only one GPIO
and have no other "more important" interface. Surely you could add
them as a child of a gpio-controller, but adding another binding
method for the system subsystem is obviously not a good idea.

> > From my POV the page is simply focused on standard bindings, which
> > have already been established.
> 
> Well, new bindings should have very good reasons not to follow these
> principles.

Sure, but the standard bindings are very focused on bus connected
devices (esp. since the page is from 2010). So obviously the page is
heavily influenced. As I already mentioned I don't think we have
something comparable to a UART attached device with DT binding so far.

(except of mentioned HSI)

> > If I understand you right, your POV does not allow child nodes
> > (which are not directly under /) without reg property / address.
> 
> Yes, I read it like that.
> 
> Slides 22 and 27 of
> 
> http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
> 
> also appear to suggest to put busses and devices on root level.
> 
> Well, he says “typically”, because he just describes the status quo and is
> not wanting to set a standard.

The text merely tells you, that these kind of nodes can be found
below the / node. It does not tell you, that all of them are there.
Simple Counterexample:

/ -> ocp -> i2c@xxxx -> i2c-dev

The i2c bus is not at /, so not all busses are at /.

> > Just have a look at the DT binding
> > documentation directory in the kernel - we already have them.
> 
> Maybe, todays Linux bidings and DTs are not general enough in such cases
> and should be revisited? But that goes far beyond our discussion and problem.

Well, I'm against moving all MFD submodules to / and that is what
you suggest by disallowing child nodes without an address. It will
just clutter the / node with lots of stuff.

> > We obviously disagree here :)
> 
> Exactly. This is why I am trying to find a concise definition how
> it should be.
> 
> And to be honest I am quite worried that it does not appear to
> exist but DT should be stable and well defined and even OS
> agnostic. How can that work?

By having people, who review new subsystem bindings. I guess
once the UART binding has been done we have a reference case
anyway.

> >> * if a driver needs access to another component, a reference property is used
> > 
> > Here we also disagree. The kernel also makes use of parent > child
> > connections (e.g. the driver for an i2c client node will request
> > data via its parent)
> 
> That is in my view strictly following because i2c is a bus and therefore
> there is a parent>child relation and it is ok to use it to request the parent.
> 
> But in my words the bus is not “another component”. Another component
> in my example means the “other" between BT chip and SoC with UART.

The same argumentation can be used with BT node below UART node.

> > and sometimes even sibling relationships (in
> > MFD devices).
> 
> I am not at all against using the information that is present in
> the DT :) I just want to have the DT the information encoded in
> the right way.

Needless to point out, that's why we are having this discussion.

> > So let me summarize:
> > 
> > * Option A: Do not encode remote side information
> >   Rationale: UART port can be opened in userspace without that info
> >   Counterargument: This information is needed if the OS should be
> >   able to hide away the tty and provide support for the connected
> >   remote device (e.g. provide a bluetooth device instead of a tty)
> 
> Agreed. I think we can drop this option since there are good use cases.
> 
> A second one for the records: if we want to provide data from an UART
> connected GPS chip through an iio interface.

All examples can be summarized as "device abstraction".

The UART interface is no different from an SPI bus in this regard.
We could just provide the SPI bus node and let the user cope with
the rest. Instead most users do not even need to know, that their
fancy wifi module is connected via SPI. The same is true for UART
attached devices.

Note, that in my opinion UART is mostly the same as an SPI bus with
only one device (yes, I'm aware, that there is an addtional clock
line etc.). The only difference from DT perspective is the
addressability, which is not important from my POV.

> > * Option B: Put UART remote side node to / and add a reference to the UART port
> >   Rationale: DT wiki page indicates, that child nodes must be addressable
> and UART is not per se a “bus”.
> 
> > 
> > * Option C: Put UART remote side node below the UART node
> >   Rationale: Remote device is accessed through the UART
> and treat serial connections as single-client busses

Note, that for me child device does not imply a bus, since other
devices certainly do not use it that way - e.g. most (all?) MFD
devices use child nodes. One can argue of course, that there are
two rules for child devices:

 1. addressable bus clients
 2. device subfunctionalities

> > Since this is about a subsystem binding DT maintainers ACK is
> > definitely needed, so maybe we should just wait for their decision.
> 
> Good summary! 
> 
> So let’s wait for questions / clarifications / comments /
> decisions by DT maintainers.

Since DT maintainers are typically heavily overloaded with work it's
probably a good idea to write up a summarized text in a separate
thread with a obvious hint, that DT binding maintainer feedback is
requested.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 12131 bytes --]

Hi,

On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote:
> > Coming back at my sentence: I asked about a non-trivial, non-bus
> > connected HW, which has a DT binding.
> 
> from omap3-beagle-xm.dts:
> hsusb2_phy (connected through ULPI)
> gpio-keys (it is not a trivial on/off)
> tfp410 (DVI encoder only part of the video pipeline)

These just need a couple of gpios. For me that's trivial compared to
an interface as complex as UART. Since they do not have any complex
interface they could be a child of, they must land in /.

> sound/codec (connected through McBSPs)

The audio codec is a child device of the TWL. The node you are
talking about is a ***virtual*** device. See also

http://devicetree.org/SoC_Audio

Note that the audio binding of many devices is not that "clean",
since quite some relationships are hidden away behind kernel quirks
and very specific compatible strings.

> and there are components on the board which are not described at
> all but work out of the box: audio connectors, usb/ethernet hub

Sure. Everything that can be identified automatically (USB/Ethernet
stuff) is not encoded into DT. DT has been created to provide a
description for devices, which can *not* be identified automatically.

And passive components like audio connectors are normally not
encoded into DT, since no configuration is needed and no information
is gained. Before you argument with video connectors: Yes they are
different, but IMHO for good reasons:

1. The user can see "DVI" label for DVI output and "HDMI" label
   for HDMI output. This is not known by the display controller.
2. The display data channel is i2c and the connector may use a
   system i2c controller together with the data wires provided by
   the display controller. The display subsystem must know which
   i2c controller takes care of the port.

> In the meantime, I have proposed an IMHO even better approach.
> 
> It is not to make the gps a regulator or a subnode of some “primary interface”,
> but give it a reference to the uart it is connected to.
> 
> And make it an independent node on DT root level.
> 
> Then we are completely independent on how the gps driver presents
> data to any user space on any OS.

IMHO that approach is not better per se. The child variant is more
generic it contains information without the kernel even knowing
about uart specific stuff.

Note, that we could always use references in DT. The tree structure
is not needed at all, since references make it possible to describe
a graph. Obviously that would defeat the purpose of the tree
structure. In my opinion making something a node in / is always the
last resort and in my perspective it has been handled in such a way
so far.

> What is bad with having a net? Why must we squeeze everything into
> a tree structure just because it is called such? DT language
> provides the syntax for references and that allows to make nets.
> And it is heavily used.

I think so far references were mainly used when tree structure was
too limited to describe something.

> >> You said NAK about referencing a regulator from the UART node and
> >> now?
> > 
> > No. I said NAK about referencing *the* regulator from the BT/GPS
> > node. My NAK was about referencing a regulator in the UART node
> > (local side), which is actually needed by the GPS/BT module (remote
> > side).
> 
> Ah, now I understand your argument, and agree to it.
> 
> My comment was on a slightly different topic that the DTR line from the
> UART (node) can be used to signal the remote regulator to be turned on.
> 
> But I learned yesterday that we can even hide this explicit signalling
> mechanism (being regulator, gpio or whatever) by:
> 
> bt {
> 	compatible = “vendor,btchip”;
> 	regulator = <&regulator to power the btchip>;
> 	uart = <&uart1>;
> 	gpio = <&gpio to enable the chip>;
> };
> 
> uart1 {
> 	/* no reference to bt */
> 	regulator = <&optional regulator to make the local side work>;
> };
> 
> You have two nodes. One with all properties for the local uart side.
> And one for the remote side. With a link so that the kernel code can
> find the uart the device is connected to.
> 
> And then kernel A can use one signalling mechanism between the uart
> driver and the bt driver and kernel B another. This is the level of abstracion
> we should get to.

Since this part of the argumentation is about the regulator VS
enable gpio let's leave out the child VS uart-reference here.

So first note about the regulators: they are normally referenced
using something like "vcc-supply = <&regulator>;". This makes it
possible to request more than one regulator. It also shows, what
they are normally used for (you have a module, which has a vcc-pin
and you need some regulator (which can be a fixed-regulator) to
drive it.

So now if the module has an enable-gpio one has two options:

1) add "enable-gpio" to the module's node

2) break up the module into subcomponents, which expose its
   internal structure

Normally in DT option 1) is used, if 2) is not needed. If
some *other* component also makes use of the regulator enabled
by the enable-gpio you would choose option 2), otherwise you
would choose option 1) to keep everything simpler.

> > From my POV putting it below the UART node is more logical and from
> > your POV putting it below / is more logical.
> 
> Another aspect just came to my mind:
> 
> IMHO / is the better solution because it also allows to override the
> uart property in an overlay. For example board variant 1 connects to
> uart1 and a hardware changeconnects the bt chip to uart2 in variant 2.
> 
> You can easily rearrange this link by including the dts of variant 1 and 
> just overwriting uart = <&uart2>.
> 
> But you can’t do that with a child node. I.e. you have to overwrite the whole
> uart1 and uart2 nodes to “remove” the relation between uart1 and the bt/gps chip.
> 
> This is probably the reason why gpio controllers are referenced and
> not the parents of all connected chips.

The main problem with making gpio controllers parents is, that you
can have only one parent. Since most chips already have a parent
gpios are referenced. Then in opposite to high-level interfaces
many devices need multiple GPIOs. So it will be hard to find a
single parent.

So let's assume there is 20% of devices, which need only one GPIO
and have no other "more important" interface. Surely you could add
them as a child of a gpio-controller, but adding another binding
method for the system subsystem is obviously not a good idea.

> > From my POV the page is simply focused on standard bindings, which
> > have already been established.
> 
> Well, new bindings should have very good reasons not to follow these
> principles.

Sure, but the standard bindings are very focused on bus connected
devices (esp. since the page is from 2010). So obviously the page is
heavily influenced. As I already mentioned I don't think we have
something comparable to a UART attached device with DT binding so far.

(except of mentioned HSI)

> > If I understand you right, your POV does not allow child nodes
> > (which are not directly under /) without reg property / address.
> 
> Yes, I read it like that.
> 
> Slides 22 and 27 of
> 
> http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
> 
> also appear to suggest to put busses and devices on root level.
> 
> Well, he says “typically”, because he just describes the status quo and is
> not wanting to set a standard.

The text merely tells you, that these kind of nodes can be found
below the / node. It does not tell you, that all of them are there.
Simple Counterexample:

/ -> ocp -> i2c@xxxx -> i2c-dev

The i2c bus is not at /, so not all busses are at /.

> > Just have a look at the DT binding
> > documentation directory in the kernel - we already have them.
> 
> Maybe, todays Linux bidings and DTs are not general enough in such cases
> and should be revisited? But that goes far beyond our discussion and problem.

Well, I'm against moving all MFD submodules to / and that is what
you suggest by disallowing child nodes without an address. It will
just clutter the / node with lots of stuff.

> > We obviously disagree here :)
> 
> Exactly. This is why I am trying to find a concise definition how
> it should be.
> 
> And to be honest I am quite worried that it does not appear to
> exist but DT should be stable and well defined and even OS
> agnostic. How can that work?

By having people, who review new subsystem bindings. I guess
once the UART binding has been done we have a reference case
anyway.

> >> * if a driver needs access to another component, a reference property is used
> > 
> > Here we also disagree. The kernel also makes use of parent > child
> > connections (e.g. the driver for an i2c client node will request
> > data via its parent)
> 
> That is in my view strictly following because i2c is a bus and therefore
> there is a parent>child relation and it is ok to use it to request the parent.
> 
> But in my words the bus is not “another component”. Another component
> in my example means the “other" between BT chip and SoC with UART.

The same argumentation can be used with BT node below UART node.

> > and sometimes even sibling relationships (in
> > MFD devices).
> 
> I am not at all against using the information that is present in
> the DT :) I just want to have the DT the information encoded in
> the right way.

Needless to point out, that's why we are having this discussion.

> > So let me summarize:
> > 
> > * Option A: Do not encode remote side information
> >   Rationale: UART port can be opened in userspace without that info
> >   Counterargument: This information is needed if the OS should be
> >   able to hide away the tty and provide support for the connected
> >   remote device (e.g. provide a bluetooth device instead of a tty)
> 
> Agreed. I think we can drop this option since there are good use cases.
> 
> A second one for the records: if we want to provide data from an UART
> connected GPS chip through an iio interface.

All examples can be summarized as "device abstraction".

The UART interface is no different from an SPI bus in this regard.
We could just provide the SPI bus node and let the user cope with
the rest. Instead most users do not even need to know, that their
fancy wifi module is connected via SPI. The same is true for UART
attached devices.

Note, that in my opinion UART is mostly the same as an SPI bus with
only one device (yes, I'm aware, that there is an addtional clock
line etc.). The only difference from DT perspective is the
addressability, which is not important from my POV.

> > * Option B: Put UART remote side node to / and add a reference to the UART port
> >   Rationale: DT wiki page indicates, that child nodes must be addressable
> and UART is not per se a “bus”.
> 
> > 
> > * Option C: Put UART remote side node below the UART node
> >   Rationale: Remote device is accessed through the UART
> and treat serial connections as single-client busses

Note, that for me child device does not imply a bus, since other
devices certainly do not use it that way - e.g. most (all?) MFD
devices use child nodes. One can argue of course, that there are
two rules for child devices:

 1. addressable bus clients
 2. device subfunctionalities

> > Since this is about a subsystem binding DT maintainers ACK is
> > definitely needed, so maybe we should just wait for their decision.
> 
> Good summary! 
> 
> So let’s wait for questions / clarifications / comments /
> decisions by DT maintainers.

Since DT maintainers are typically heavily overloaded with work it's
probably a good idea to write up a summarized text in a separate
thread with a obvious hint, that DT binding maintainer feedback is
requested.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 27.03.2015 um 17:31 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote:
>>> Coming back at my sentence: I asked about a non-trivial, non-bus
>>> connected HW, which has a DT binding.
>> 
>> from omap3-beagle-xm.dts:
>> hsusb2_phy (connected through ULPI)
>> gpio-keys (it is not a trivial on/off)
>> tfp410 (DVI encoder only part of the video pipeline)
> 
> These just need a couple of gpios. For me that's trivial compared to
> an interface as complex as UART. Since they do not have any complex
> interface they could be a child of, they must land in /.

ULPI-PHY is not at all “just a couple of GPIOs”. It is a 60 MHz 8 bit wide
parallel protocol with handshake… Sort of 8 UARTs or SPI with common clock.

But still no bus. The bus driven by the ULPI-PHY is “USB2” which is known
not to be a physical bus but a tree. It just becomes a bus by higher level
protocols.

I must admit that I lost the goal that you want to demonstrate with this
question/examples.

> 
>> sound/codec (connected through McBSPs)
> 
> The audio codec is a child device of the TWL. The node you are
> talking about is a ***virtual*** device.

Ah interesting that they exist! A virtual gpio was not acceptable…

> See also
> 
> http://devicetree.org/SoC_Audio
> 
> Note that the audio binding of many devices is not that "clean",
> since quite some relationships are hidden away behind kernel quirks
> and very specific compatible strings.
> 
>> and there are components on the board which are not described at
>> all but work out of the box: audio connectors, usb/ethernet hub
> 
> Sure. Everything that can be identified automatically (USB/Ethernet
> stuff) is not encoded into DT. DT has been created to provide a
> description for devices, which can *not* be identified automatically.

Exactly.

> 
> And passive components like audio connectors are normally not
> encoded into DT, since no configuration is needed and no information
> is gained. Before you argument with video connectors: Yes they are
> different, but IMHO for good reasons:
> 
> 1. The user can see "DVI" label for DVI output and "HDMI" label
>   for HDMI output. This is not known by the display controller.
> 2. The display data channel is i2c and the connector may use a
>   system i2c controller together with the data wires provided by
>   the display controller. The display subsystem must know which
>   i2c controller takes care of the port.

Yes. Indeed.

> 
>> In the meantime, I have proposed an IMHO even better approach.
>> 
>> It is not to make the gps a regulator or a subnode of some “primary interface”,
>> but give it a reference to the uart it is connected to.
>> 
>> And make it an independent node on DT root level.
>> 
>> Then we are completely independent on how the gps driver presents
>> data to any user space on any OS.
> 
> IMHO that approach is not better per se. The child variant is more
> generic it contains information without the kernel even knowing
> about uart specific stuff.
> 
> Note, that we could always use references in DT. The tree structure
> is not needed at all, since references make it possible to describe
> a graph.

Right.

> Obviously that would defeat the purpose of the tree
> structure.

Which might be there for completeness if something wants to be
better described in a tree structure. Multiple clients of a single bus controller
that can be selected (addressed) are obviously better described by
a parent>child relationship (which includes some sort of “address”
to describe how this addressing works).

> In my opinion making something a node in / is always the
> last resort and in my perspective it has been handled in such a way
> so far.

But that contradicts some documents I have found and linked. Please
show me a document about DT that supports your view.

I agree that both views can be valid, but in lack of some “official” guideline
we can’t decide ourselves.

> 
>> What is bad with having a net? Why must we squeeze everything into
>> a tree structure just because it is called such? DT language
>> provides the syntax for references and that allows to make nets.
>> And it is heavily used.
> 
> I think so far references were mainly used when tree structure was
> too limited to describe something.
> 
>>>> You said NAK about referencing a regulator from the UART node and
>>>> now?
>>> 
>>> No. I said NAK about referencing *the* regulator from the BT/GPS
>>> node. My NAK was about referencing a regulator in the UART node
>>> (local side), which is actually needed by the GPS/BT module (remote
>>> side).
>> 
>> Ah, now I understand your argument, and agree to it.
>> 
>> My comment was on a slightly different topic that the DTR line from the
>> UART (node) can be used to signal the remote regulator to be turned on.
>> 
>> But I learned yesterday that we can even hide this explicit signalling
>> mechanism (being regulator, gpio or whatever) by:
>> 
>> bt {
>> 	compatible = “vendor,btchip”;
>> 	regulator = <&regulator to power the btchip>;
>> 	uart = <&uart1>;
>> 	gpio = <&gpio to enable the chip>;
>> };
>> 
>> uart1 {
>> 	/* no reference to bt */
>> 	regulator = <&optional regulator to make the local side work>;
>> };
>> 
>> You have two nodes. One with all properties for the local uart side.
>> And one for the remote side. With a link so that the kernel code can
>> find the uart the device is connected to.
>> 
>> And then kernel A can use one signalling mechanism between the uart
>> driver and the bt driver and kernel B another. This is the level of abstracion
>> we should get to.
> 
> Since this part of the argumentation is about the regulator VS
> enable gpio let's leave out the child VS uart-reference here.
> 
> So first note about the regulators: they are normally referenced
> using something like “vcc-supply = <&regulator>;".

s/regulator/vcc-supply/ myexample.dts

> This makes it
> possible to request more than one regulator. It also shows, what
> they are normally used for (you have a module, which has a vcc-pin
> and you need some regulator (which can be a fixed-regulator) to
> drive it.
> 
> So now if the module has an enable-gpio one has two options:
> 
> 1) add “enable-gpio" to the module's node
> 

s/gpio/enable-gpio/ myexample.dts

> 2) break up the module into subcomponents, which expose its
>   internal structure
> 
> Normally in DT option 1) is used, if 2) is not needed. If
> some *other* component also makes use of the regulator enabled
> by the enable-gpio you would choose option 2), otherwise you
> would choose option 1) to keep everything simpler.

Sorry, but what do you want to explain here which helps to answer
where to locate the bt node?

> 
>>> From my POV putting it below the UART node is more logical and from
>>> your POV putting it below / is more logical.
>> 
>> Another aspect just came to my mind:
>> 
>> IMHO / is the better solution because it also allows to override the
>> uart property in an overlay. For example board variant 1 connects to
>> uart1 and a hardware changeconnects the bt chip to uart2 in variant 2.
>> 
>> You can easily rearrange this link by including the dts of variant 1 and 
>> just overwriting uart = <&uart2>.
>> 
>> But you can’t do that with a child node. I.e. you have to overwrite the whole
>> uart1 and uart2 nodes to “remove” the relation between uart1 and the bt/gps chip.
>> 
>> This is probably the reason why gpio controllers are referenced and
>> not the parents of all connected chips.
> 
> The main problem with making gpio controllers parents is, that you
> can have only one parent. Since most chips already have a parent
> gpios are referenced. Then in opposite to high-level interfaces
> many devices need multiple GPIOs. So it will be hard to find a
> single parent.
> 
> So let's assume there is 20% of devices, which need only one GPIO
> and have no other "more important" interface. Surely you could add
> them as a child of a gpio-controller, but adding another binding
> method for the system subsystem is obviously not a good idea.

Yes, this is exactly why I assume that gpio controllers are referenced.

Now, replace gpio with one uart for a mfd. And the same argument
leads that a mfd can’t have multiple parents. Therefore it should not
have the uart as parent as well.

> 
>>> From my POV the page is simply focused on standard bindings, which
>>> have already been established.
>> 
>> Well, new bindings should have very good reasons not to follow these
>> principles.
> 
> Sure, but the standard bindings are very focused on bus connected
> devices (esp. since the page is from 2010). So obviously the page is
> heavily influenced. As I already mentioned I don't think we have
> something comparable to a UART attached device with DT binding so far.
> 
> (except of mentioned HSI)

McBSP?

> 
>>> If I understand you right, your POV does not allow child nodes
>>> (which are not directly under /) without reg property / address.
>> 
>> Yes, I read it like that.
>> 
>> Slides 22 and 27 of
>> 
>> http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
>> 
>> also appear to suggest to put busses and devices on root level.
>> 
>> Well, he says “typically”, because he just describes the status quo and is
>> not wanting to set a standard.
> 
> The text merely tells you, that these kind of nodes can be found
> below the / node. It does not tell you, that all of them are there.
> Simple Counterexample:
> 
> / -> ocp -> i2c@xxxx -> i2c-dev
> 
> The i2c bus is not at /, so not all busses are at /.

ocp is itself a bus. So i2c is just a second level bus. Both are
adressable (@xxxx for the controller’s address and the i2c dev
has a reg property).

> 
>>> Just have a look at the DT binding
>>> documentation directory in the kernel - we already have them.
>> 
>> Maybe, todays Linux bidings and DTs are not general enough in such cases
>> and should be revisited? But that goes far beyond our discussion and problem.
> 
> Well, I'm against moving all MFD submodules to / and that is what
> you suggest by disallowing child nodes without an address. It will
> just clutter the / node with lots of stuff.

Clutter? IMHO not.

> 
>>> We obviously disagree here :)
>> 
>> Exactly. This is why I am trying to find a concise definition how
>> it should be.
>> 
>> And to be honest I am quite worried that it does not appear to
>> exist but DT should be stable and well defined and even OS
>> agnostic. How can that work?
> 
> By having people, who review new subsystem bindings. I guess
> once the UART binding has been done we have a reference case
> anyway.
> 
>>>> * if a driver needs access to another component, a reference property is used
>>> 
>>> Here we also disagree. The kernel also makes use of parent > child
>>> connections (e.g. the driver for an i2c client node will request
>>> data via its parent)
>> 
>> That is in my view strictly following because i2c is a bus and therefore
>> there is a parent>child relation and it is ok to use it to request the parent.
>> 
>> But in my words the bus is not “another component”. Another component
>> in my example means the “other" between BT chip and SoC with UART.
> 
> The same argumentation can be used with BT node below UART node.
> 
>>> and sometimes even sibling relationships (in
>>> MFD devices).
>> 
>> I am not at all against using the information that is present in
>> the DT :) I just want to have the DT the information encoded in
>> the right way.
> 
> Needless to point out, that's why we are having this discussion.
> 
>>> So let me summarize:
>>> 
>>> * Option A: Do not encode remote side information
>>>  Rationale: UART port can be opened in userspace without that info
>>>  Counterargument: This information is needed if the OS should be
>>>  able to hide away the tty and provide support for the connected
>>>  remote device (e.g. provide a bluetooth device instead of a tty)
>> 
>> Agreed. I think we can drop this option since there are good use cases.
>> 
>> A second one for the records: if we want to provide data from an UART
>> connected GPS chip through an iio interface.
> 
> All examples can be summarized as "device abstraction".
> 
> The UART interface is no different from an SPI bus in this regard.
> We could just provide the SPI bus node and let the user cope with
> the rest. Instead most users do not even need to know, that their
> fancy wifi module is connected via SPI. The same is true for UART
> attached devices.
> 
> Note, that in my opinion UART is mostly the same as an SPI bus with
> only one device

Any interface is mostly the same as an SPI bus. It may just have faster
or slower clocks, have more or less parallel data lines sharing the same
clock. Different logic levels (binary / ternatry / self-clocking etc.) as well.

The question is how far we want to strech these similarities into the DT.

> (yes, I'm aware, that there is an addtional clock
> line etc.). The only difference from DT perspective is the
> addressability, which is not important from my POV.

Well, by declaring something as not important you can argue for everything :)

> 
>>> * Option B: Put UART remote side node to / and add a reference to the UART port
>>>  Rationale: DT wiki page indicates, that child nodes must be addressable
>> and UART is not per se a “bus”.
>> 
>>> 
>>> * Option C: Put UART remote side node below the UART node
>>>  Rationale: Remote device is accessed through the UART
>> and treat serial connections as single-client busses
> 
> Note, that for me child device does not imply a bus, since other
> devices certainly do not use it that way - e.g. most (all?) MFD
> devices use child nodes. One can argue of course, that there are
> two rules for child devices:
> 
> 1. addressable bus clients
> 2. device subfunctionalities

Yes!

I think I had written that before but it might have been lost in the growing
discussion.

> 
>>> Since this is about a subsystem binding DT maintainers ACK is
>>> definitely needed, so maybe we should just wait for their decision.
>> 
>> Good summary! 
>> 
>> So let’s wait for questions / clarifications / comments /
>> decisions by DT maintainers.
> 
> Since DT maintainers are typically heavily overloaded with work it's
> probably a good idea to write up a summarized text in a separate
> thread with a obvious hint, that DT binding maintainer feedback is
> requested.

Agreed. Should be limited to Option B and C since we agree that A
does not provide all information that could be useful for future kernels.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 27.03.2015 um 17:31 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Fri, Mar 27, 2015 at 10:22:11AM +0100, Dr. H. Nikolaus Schaller wrote:
>>> Coming back at my sentence: I asked about a non-trivial, non-bus
>>> connected HW, which has a DT binding.
>> 
>> from omap3-beagle-xm.dts:
>> hsusb2_phy (connected through ULPI)
>> gpio-keys (it is not a trivial on/off)
>> tfp410 (DVI encoder only part of the video pipeline)
> 
> These just need a couple of gpios. For me that's trivial compared to
> an interface as complex as UART. Since they do not have any complex
> interface they could be a child of, they must land in /.

ULPI-PHY is not at all “just a couple of GPIOs”. It is a 60 MHz 8 bit wide
parallel protocol with handshake… Sort of 8 UARTs or SPI with common clock.

But still no bus. The bus driven by the ULPI-PHY is “USB2” which is known
not to be a physical bus but a tree. It just becomes a bus by higher level
protocols.

I must admit that I lost the goal that you want to demonstrate with this
question/examples.

> 
>> sound/codec (connected through McBSPs)
> 
> The audio codec is a child device of the TWL. The node you are
> talking about is a ***virtual*** device.

Ah interesting that they exist! A virtual gpio was not acceptable…

> See also
> 
> http://devicetree.org/SoC_Audio
> 
> Note that the audio binding of many devices is not that "clean",
> since quite some relationships are hidden away behind kernel quirks
> and very specific compatible strings.
> 
>> and there are components on the board which are not described at
>> all but work out of the box: audio connectors, usb/ethernet hub
> 
> Sure. Everything that can be identified automatically (USB/Ethernet
> stuff) is not encoded into DT. DT has been created to provide a
> description for devices, which can *not* be identified automatically.

Exactly.

> 
> And passive components like audio connectors are normally not
> encoded into DT, since no configuration is needed and no information
> is gained. Before you argument with video connectors: Yes they are
> different, but IMHO for good reasons:
> 
> 1. The user can see "DVI" label for DVI output and "HDMI" label
>   for HDMI output. This is not known by the display controller.
> 2. The display data channel is i2c and the connector may use a
>   system i2c controller together with the data wires provided by
>   the display controller. The display subsystem must know which
>   i2c controller takes care of the port.

Yes. Indeed.

> 
>> In the meantime, I have proposed an IMHO even better approach.
>> 
>> It is not to make the gps a regulator or a subnode of some “primary interface”,
>> but give it a reference to the uart it is connected to.
>> 
>> And make it an independent node on DT root level.
>> 
>> Then we are completely independent on how the gps driver presents
>> data to any user space on any OS.
> 
> IMHO that approach is not better per se. The child variant is more
> generic it contains information without the kernel even knowing
> about uart specific stuff.
> 
> Note, that we could always use references in DT. The tree structure
> is not needed at all, since references make it possible to describe
> a graph.

Right.

> Obviously that would defeat the purpose of the tree
> structure.

Which might be there for completeness if something wants to be
better described in a tree structure. Multiple clients of a single bus controller
that can be selected (addressed) are obviously better described by
a parent>child relationship (which includes some sort of “address”
to describe how this addressing works).

> In my opinion making something a node in / is always the
> last resort and in my perspective it has been handled in such a way
> so far.

But that contradicts some documents I have found and linked. Please
show me a document about DT that supports your view.

I agree that both views can be valid, but in lack of some “official” guideline
we can’t decide ourselves.

> 
>> What is bad with having a net? Why must we squeeze everything into
>> a tree structure just because it is called such? DT language
>> provides the syntax for references and that allows to make nets.
>> And it is heavily used.
> 
> I think so far references were mainly used when tree structure was
> too limited to describe something.
> 
>>>> You said NAK about referencing a regulator from the UART node and
>>>> now?
>>> 
>>> No. I said NAK about referencing *the* regulator from the BT/GPS
>>> node. My NAK was about referencing a regulator in the UART node
>>> (local side), which is actually needed by the GPS/BT module (remote
>>> side).
>> 
>> Ah, now I understand your argument, and agree to it.
>> 
>> My comment was on a slightly different topic that the DTR line from the
>> UART (node) can be used to signal the remote regulator to be turned on.
>> 
>> But I learned yesterday that we can even hide this explicit signalling
>> mechanism (being regulator, gpio or whatever) by:
>> 
>> bt {
>> 	compatible = “vendor,btchip”;
>> 	regulator = <&regulator to power the btchip>;
>> 	uart = <&uart1>;
>> 	gpio = <&gpio to enable the chip>;
>> };
>> 
>> uart1 {
>> 	/* no reference to bt */
>> 	regulator = <&optional regulator to make the local side work>;
>> };
>> 
>> You have two nodes. One with all properties for the local uart side.
>> And one for the remote side. With a link so that the kernel code can
>> find the uart the device is connected to.
>> 
>> And then kernel A can use one signalling mechanism between the uart
>> driver and the bt driver and kernel B another. This is the level of abstracion
>> we should get to.
> 
> Since this part of the argumentation is about the regulator VS
> enable gpio let's leave out the child VS uart-reference here.
> 
> So first note about the regulators: they are normally referenced
> using something like “vcc-supply = <&regulator>;".

s/regulator/vcc-supply/ myexample.dts

> This makes it
> possible to request more than one regulator. It also shows, what
> they are normally used for (you have a module, which has a vcc-pin
> and you need some regulator (which can be a fixed-regulator) to
> drive it.
> 
> So now if the module has an enable-gpio one has two options:
> 
> 1) add “enable-gpio" to the module's node
> 

s/gpio/enable-gpio/ myexample.dts

> 2) break up the module into subcomponents, which expose its
>   internal structure
> 
> Normally in DT option 1) is used, if 2) is not needed. If
> some *other* component also makes use of the regulator enabled
> by the enable-gpio you would choose option 2), otherwise you
> would choose option 1) to keep everything simpler.

Sorry, but what do you want to explain here which helps to answer
where to locate the bt node?

> 
>>> From my POV putting it below the UART node is more logical and from
>>> your POV putting it below / is more logical.
>> 
>> Another aspect just came to my mind:
>> 
>> IMHO / is the better solution because it also allows to override the
>> uart property in an overlay. For example board variant 1 connects to
>> uart1 and a hardware changeconnects the bt chip to uart2 in variant 2.
>> 
>> You can easily rearrange this link by including the dts of variant 1 and 
>> just overwriting uart = <&uart2>.
>> 
>> But you can’t do that with a child node. I.e. you have to overwrite the whole
>> uart1 and uart2 nodes to “remove” the relation between uart1 and the bt/gps chip.
>> 
>> This is probably the reason why gpio controllers are referenced and
>> not the parents of all connected chips.
> 
> The main problem with making gpio controllers parents is, that you
> can have only one parent. Since most chips already have a parent
> gpios are referenced. Then in opposite to high-level interfaces
> many devices need multiple GPIOs. So it will be hard to find a
> single parent.
> 
> So let's assume there is 20% of devices, which need only one GPIO
> and have no other "more important" interface. Surely you could add
> them as a child of a gpio-controller, but adding another binding
> method for the system subsystem is obviously not a good idea.

Yes, this is exactly why I assume that gpio controllers are referenced.

Now, replace gpio with one uart for a mfd. And the same argument
leads that a mfd can’t have multiple parents. Therefore it should not
have the uart as parent as well.

> 
>>> From my POV the page is simply focused on standard bindings, which
>>> have already been established.
>> 
>> Well, new bindings should have very good reasons not to follow these
>> principles.
> 
> Sure, but the standard bindings are very focused on bus connected
> devices (esp. since the page is from 2010). So obviously the page is
> heavily influenced. As I already mentioned I don't think we have
> something comparable to a UART attached device with DT binding so far.
> 
> (except of mentioned HSI)

McBSP?

> 
>>> If I understand you right, your POV does not allow child nodes
>>> (which are not directly under /) without reg property / address.
>> 
>> Yes, I read it like that.
>> 
>> Slides 22 and 27 of
>> 
>> http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
>> 
>> also appear to suggest to put busses and devices on root level.
>> 
>> Well, he says “typically”, because he just describes the status quo and is
>> not wanting to set a standard.
> 
> The text merely tells you, that these kind of nodes can be found
> below the / node. It does not tell you, that all of them are there.
> Simple Counterexample:
> 
> / -> ocp -> i2c@xxxx -> i2c-dev
> 
> The i2c bus is not at /, so not all busses are at /.

ocp is itself a bus. So i2c is just a second level bus. Both are
adressable (@xxxx for the controller’s address and the i2c dev
has a reg property).

> 
>>> Just have a look at the DT binding
>>> documentation directory in the kernel - we already have them.
>> 
>> Maybe, todays Linux bidings and DTs are not general enough in such cases
>> and should be revisited? But that goes far beyond our discussion and problem.
> 
> Well, I'm against moving all MFD submodules to / and that is what
> you suggest by disallowing child nodes without an address. It will
> just clutter the / node with lots of stuff.

Clutter? IMHO not.

> 
>>> We obviously disagree here :)
>> 
>> Exactly. This is why I am trying to find a concise definition how
>> it should be.
>> 
>> And to be honest I am quite worried that it does not appear to
>> exist but DT should be stable and well defined and even OS
>> agnostic. How can that work?
> 
> By having people, who review new subsystem bindings. I guess
> once the UART binding has been done we have a reference case
> anyway.
> 
>>>> * if a driver needs access to another component, a reference property is used
>>> 
>>> Here we also disagree. The kernel also makes use of parent > child
>>> connections (e.g. the driver for an i2c client node will request
>>> data via its parent)
>> 
>> That is in my view strictly following because i2c is a bus and therefore
>> there is a parent>child relation and it is ok to use it to request the parent.
>> 
>> But in my words the bus is not “another component”. Another component
>> in my example means the “other" between BT chip and SoC with UART.
> 
> The same argumentation can be used with BT node below UART node.
> 
>>> and sometimes even sibling relationships (in
>>> MFD devices).
>> 
>> I am not at all against using the information that is present in
>> the DT :) I just want to have the DT the information encoded in
>> the right way.
> 
> Needless to point out, that's why we are having this discussion.
> 
>>> So let me summarize:
>>> 
>>> * Option A: Do not encode remote side information
>>>  Rationale: UART port can be opened in userspace without that info
>>>  Counterargument: This information is needed if the OS should be
>>>  able to hide away the tty and provide support for the connected
>>>  remote device (e.g. provide a bluetooth device instead of a tty)
>> 
>> Agreed. I think we can drop this option since there are good use cases.
>> 
>> A second one for the records: if we want to provide data from an UART
>> connected GPS chip through an iio interface.
> 
> All examples can be summarized as "device abstraction".
> 
> The UART interface is no different from an SPI bus in this regard.
> We could just provide the SPI bus node and let the user cope with
> the rest. Instead most users do not even need to know, that their
> fancy wifi module is connected via SPI. The same is true for UART
> attached devices.
> 
> Note, that in my opinion UART is mostly the same as an SPI bus with
> only one device

Any interface is mostly the same as an SPI bus. It may just have faster
or slower clocks, have more or less parallel data lines sharing the same
clock. Different logic levels (binary / ternatry / self-clocking etc.) as well.

The question is how far we want to strech these similarities into the DT.

> (yes, I'm aware, that there is an addtional clock
> line etc.). The only difference from DT perspective is the
> addressability, which is not important from my POV.

Well, by declaring something as not important you can argue for everything :)

> 
>>> * Option B: Put UART remote side node to / and add a reference to the UART port
>>>  Rationale: DT wiki page indicates, that child nodes must be addressable
>> and UART is not per se a “bus”.
>> 
>>> 
>>> * Option C: Put UART remote side node below the UART node
>>>  Rationale: Remote device is accessed through the UART
>> and treat serial connections as single-client busses
> 
> Note, that for me child device does not imply a bus, since other
> devices certainly do not use it that way - e.g. most (all?) MFD
> devices use child nodes. One can argue of course, that there are
> two rules for child devices:
> 
> 1. addressable bus clients
> 2. device subfunctionalities

Yes!

I think I had written that before but it might have been lost in the growing
discussion.

> 
>>> Since this is about a subsystem binding DT maintainers ACK is
>>> definitely needed, so maybe we should just wait for their decision.
>> 
>> Good summary! 
>> 
>> So let’s wait for questions / clarifications / comments /
>> decisions by DT maintainers.
> 
> Since DT maintainers are typically heavily overloaded with work it's
> probably a good idea to write up a summarized text in a separate
> thread with a obvious hint, that DT binding maintainer feedback is
> requested.

Agreed. Should be limited to Option B and C since we agree that A
does not provide all information that could be useful for future kernels.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> > In my opinion making something a node in / is always the
> > last resort and in my perspective it has been handled in such a way
> > so far.
> 
> But that contradicts some documents I have found and linked. Please
> show me a document about DT that supports your view.
> 
> I agree that both views can be valid, but in lack of some ?official? guideline
> we can?t decide ourselves.

This is not how kernel development works.

We can decide ourselves, and DT people will swear at us if we decide wrongly,
and then Linus swears at them if they do too obvious mistakes.

Lets KISS.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> > In my opinion making something a node in / is always the
> > last resort and in my perspective it has been handled in such a way
> > so far.
> 
> But that contradicts some documents I have found and linked. Please
> show me a document about DT that supports your view.
> 
> I agree that both views can be valid, but in lack of some ?official? guideline
> we can?t decide ourselves.

This is not how kernel development works.

We can decide ourselves, and DT people will swear at us if we decide wrongly,
and then Linus swears at them if they do too obvious mistakes.

Lets KISS.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 27.04.2015 um 22:35 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>> In my opinion making something a node in / is always the
>>> last resort and in my perspective it has been handled in such a way
>>> so far.
>> 
>> But that contradicts some documents I have found and linked. Please
>> show me a document about DT that supports your view.
>> 
>> I agree that both views can be valid, but in lack of some ?official? guideline
>> we can?t decide ourselves.
> 
> This is not how kernel development works.
> 
> We can decide ourselves, and DT people will swear at us if we decide wrongly,
> and then Linus swears at them if they do too obvious mistakes.
> 
> Lets KISS.

some time ago you also wrote in this thread:

> Device tree is not operating system specific. 

In other words: this is a discussion about compatibility with the world outside of Linux.
And compatibility can not be achieved by decisions about Linux implementation details,
even if Linus is deciding. He can just decide to stay incompatible (but then it should
IMHO be a general decision and not case specific).

So I think we should follow some basic design principles, if they exist (which I don’t know),
to have this compatibility. And then adapt the Linux implementation (using the KISS principle).

Anyways I have not yet seen any comment from the DT people or did I miss them?

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 27.04.2015 um 22:35 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>> In my opinion making something a node in / is always the
>>> last resort and in my perspective it has been handled in such a way
>>> so far.
>> 
>> But that contradicts some documents I have found and linked. Please
>> show me a document about DT that supports your view.
>> 
>> I agree that both views can be valid, but in lack of some ?official? guideline
>> we can?t decide ourselves.
> 
> This is not how kernel development works.
> 
> We can decide ourselves, and DT people will swear at us if we decide wrongly,
> and then Linus swears at them if they do too obvious mistakes.
> 
> Lets KISS.

some time ago you also wrote in this thread:

> Device tree is not operating system specific. 

In other words: this is a discussion about compatibility with the world outside of Linux.
And compatibility can not be achieved by decisions about Linux implementation details,
even if Linus is deciding. He can just decide to stay incompatible (but then it should
IMHO be a general decision and not case specific).

So I think we should follow some basic design principles, if they exist (which I don’t know),
to have this compatibility. And then adapt the Linux implementation (using the KISS principle).

Anyways I have not yet seen any comment from the DT people or did I miss them?

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> AFAIK the chip simply starts to emit NMEA records if powered on.
> >> There is no command going over the serial interface to address it
> >> or control it.
> > 
> > Right, since GPS basically doesn't need any configuration/control.
> > That’s not true for other UART attached devices, though.
> 
> Do you have an example? Usually an UART data stream is transparently
> presented to a /dev/tty - and user-space daemon can configure/control the
> attached device. In most cases it can mix payload data and control command
> by some AT command and escape sequences.

Bluetooth H4P protocol is one example.

> > well parent > child is not about power control, but about "primary"
> > control.
> 
> Can you clearly and precisely define what “primary” control is? I think
> two people will have three opinions about that.

This has not be a problem so far...

> For example I would see the w2sg0004 on/off gpio as the primary “control”
> which makes the light (NMES records) turned on.

...and I don't think it is a problem now.

> > Main reason is, that I would need to go
> > through the UART to “communicate" with the w2sg0004.
> 
> You can always "communicate” through the UART. Even without DT. As long as
> the connected chip is powered up by any means (could be some fixed-regulator
> or hard wired).

But you don't know "how" to communicate through the uart.

> Let me raise the question:
> 
> Why do we need to describe in the DT (independently of Linux power control
> structures and drivers!) that the GPS data interface is connected to a specific UART?

Because we want the phone to boot knowing "I have a bluetooth" or "I
have a GPS", as it would if it was connected using USB, and not having
user figure out what commands he needs to do to enable reasonable
hardware support (and getting it wrong, because you need to specify
_many_ critical parameters to hciattach).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> AFAIK the chip simply starts to emit NMEA records if powered on.
> >> There is no command going over the serial interface to address it
> >> or control it.
> > 
> > Right, since GPS basically doesn't need any configuration/control.
> > That’s not true for other UART attached devices, though.
> 
> Do you have an example? Usually an UART data stream is transparently
> presented to a /dev/tty - and user-space daemon can configure/control the
> attached device. In most cases it can mix payload data and control command
> by some AT command and escape sequences.

Bluetooth H4P protocol is one example.

> > well parent > child is not about power control, but about "primary"
> > control.
> 
> Can you clearly and precisely define what “primary” control is? I think
> two people will have three opinions about that.

This has not be a problem so far...

> For example I would see the w2sg0004 on/off gpio as the primary “control”
> which makes the light (NMES records) turned on.

...and I don't think it is a problem now.

> > Main reason is, that I would need to go
> > through the UART to “communicate" with the w2sg0004.
> 
> You can always "communicate” through the UART. Even without DT. As long as
> the connected chip is powered up by any means (could be some fixed-regulator
> or hard wired).

But you don't know "how" to communicate through the uart.

> Let me raise the question:
> 
> Why do we need to describe in the DT (independently of Linux power control
> structures and drivers!) that the GPS data interface is connected to a specific UART?

Because we want the phone to boot knowing "I have a bluetooth" or "I
have a GPS", as it would if it was connected using USB, and not having
user figure out what commands he needs to do to enable reasonable
hardware support (and getting it wrong, because you need to specify
_many_ critical parameters to hciattach).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 25.03.2015 um 21:53 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> AFAIK the chip simply starts to emit NMEA records if powered on.
>>>> There is no command going over the serial interface to address it
>>>> or control it.
>>> 
>>> Right, since GPS basically doesn't need any configuration/control.
>>> That’s not true for other UART attached devices, though.
>> 
>> Do you have an example? Usually an UART data stream is transparently
>> presented to a /dev/tty - and user-space daemon can configure/control the
>> attached device. In most cases it can mix payload data and control command
>> by some AT command and escape sequences.
> 
> Bluetooth H4P protocol is one example.
> 
>>> well parent > child is not about power control, but about "primary"
>>> control.
>> 
>> Can you clearly and precisely define what “primary” control is? I think
>> two people will have three opinions about that.
> 
> This has not be a problem so far...
> 
>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>> which makes the light (NMES records) turned on.
> 
> ...and I don't think it is a problem now.
> 
>>> Main reason is, that I would need to go
>>> through the UART to “communicate" with the w2sg0004.
>> 
>> You can always "communicate” through the UART. Even without DT. As long as
>> the connected chip is powered up by any means (could be some fixed-regulator
>> or hard wired).
> 
> But you don't know "how" to communicate through the uart.

Maybe we are talking using different assumptions. As long as you have a user space
gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
line disciplines) pass the data to the uart.

For that there is no need to describe anything in DT.

> 
>> Let me raise the question:
>> 
>> Why do we need to describe in the DT (independently of Linux power control
>> structures and drivers!) that the GPS data interface is connected to a specific UART?
> 
> Because we want the phone to boot knowing "I have a bluetooth" or "I
> have a GPS", as it would if it was connected using USB, and not having
> user figure out what commands he needs to do to enable reasonable
> hardware support (and getting it wrong, because you need to specify
> _many_ critical parameters to hciattach).

Yes, this is indeed something I also would like to see for the GTA04 (and other)
devices.

So the reason is that some kernel driver wants to use the tty/uart to communicate
directly with the chip. This is very similar to a gpio that some driver wants to use.

Thus please consider the

/ {
	bt {
		compatible = "vendor,product“;
		uart = <&uart1>;
		enable = <&gpio17 34 0>;
	};
};

approach.

And if you want to hide uart1 from the user-space, that should be a property
of the uart1 node (whereever it is defined).

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Am 25.03.2015 um 21:53 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>> AFAIK the chip simply starts to emit NMEA records if powered on.
>>>> There is no command going over the serial interface to address it
>>>> or control it.
>>> 
>>> Right, since GPS basically doesn't need any configuration/control.
>>> That’s not true for other UART attached devices, though.
>> 
>> Do you have an example? Usually an UART data stream is transparently
>> presented to a /dev/tty - and user-space daemon can configure/control the
>> attached device. In most cases it can mix payload data and control command
>> by some AT command and escape sequences.
> 
> Bluetooth H4P protocol is one example.
> 
>>> well parent > child is not about power control, but about "primary"
>>> control.
>> 
>> Can you clearly and precisely define what “primary” control is? I think
>> two people will have three opinions about that.
> 
> This has not be a problem so far...
> 
>> For example I would see the w2sg0004 on/off gpio as the primary “control”
>> which makes the light (NMES records) turned on.
> 
> ...and I don't think it is a problem now.
> 
>>> Main reason is, that I would need to go
>>> through the UART to “communicate" with the w2sg0004.
>> 
>> You can always "communicate” through the UART. Even without DT. As long as
>> the connected chip is powered up by any means (could be some fixed-regulator
>> or hard wired).
> 
> But you don't know "how" to communicate through the uart.

Maybe we are talking using different assumptions. As long as you have a user space
gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
line disciplines) pass the data to the uart.

For that there is no need to describe anything in DT.

> 
>> Let me raise the question:
>> 
>> Why do we need to describe in the DT (independently of Linux power control
>> structures and drivers!) that the GPS data interface is connected to a specific UART?
> 
> Because we want the phone to boot knowing "I have a bluetooth" or "I
> have a GPS", as it would if it was connected using USB, and not having
> user figure out what commands he needs to do to enable reasonable
> hardware support (and getting it wrong, because you need to specify
> _many_ critical parameters to hciattach).

Yes, this is indeed something I also would like to see for the GTA04 (and other)
devices.

So the reason is that some kernel driver wants to use the tty/uart to communicate
directly with the chip. This is very similar to a gpio that some driver wants to use.

Thus please consider the

/ {
	bt {
		compatible = "vendor,product“;
		uart = <&uart1>;
		enable = <&gpio17 34 0>;
	};
};

approach.

And if you want to hide uart1 from the user-space, that should be a property
of the uart1 node (whereever it is defined).

BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >>> Main reason is, that I would need to go
> >>> through the UART to “communicate" with the w2sg0004.
> >> 
> >> You can always "communicate” through the UART. Even without DT. As long as
> >> the connected chip is powered up by any means (could be some fixed-regulator
> >> or hard wired).
> > 
> > But you don't know "how" to communicate through the uart.
> 
> Maybe we are talking using different assumptions. As long as you have a user space
> gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
> line disciplines) pass the data to the uart.

Forget userspace, some other operating system (or future linux) may
want to put gps handling into the kernel. (To hide differences between
different GPSes).

> > Because we want the phone to boot knowing "I have a bluetooth" or "I
> > have a GPS", as it would if it was connected using USB, and not having
> > user figure out what commands he needs to do to enable reasonable
> > hardware support (and getting it wrong, because you need to specify
> > _many_ critical parameters to hciattach).
> 
> Yes, this is indeed something I also would like to see for the GTA04 (and other)
> devices.
> 
> So the reason is that some kernel driver wants to use the tty/uart to communicate
> directly with the chip. This is very similar to a gpio that some driver wants to use.
> 
> Thus please consider the
> 
> / {
> 	bt {
> 		compatible = "vendor,product“;
> 		uart = <&uart1>;
> 		enable = <&gpio17 34 0>;
> 	};
> };

Would work, too, but I and everyone knows that subnode is better,
easier solution.

> approach.
> 
> And if you want to hide uart1 from the user-space, that should be a property
> of the uart1 node (whereever it is defined).

Sorry? That would be one heck of layering violation.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >>> Main reason is, that I would need to go
> >>> through the UART to “communicate" with the w2sg0004.
> >> 
> >> You can always "communicate” through the UART. Even without DT. As long as
> >> the connected chip is powered up by any means (could be some fixed-regulator
> >> or hard wired).
> > 
> > But you don't know "how" to communicate through the uart.
> 
> Maybe we are talking using different assumptions. As long as you have a user space
> gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
> line disciplines) pass the data to the uart.

Forget userspace, some other operating system (or future linux) may
want to put gps handling into the kernel. (To hide differences between
different GPSes).

> > Because we want the phone to boot knowing "I have a bluetooth" or "I
> > have a GPS", as it would if it was connected using USB, and not having
> > user figure out what commands he needs to do to enable reasonable
> > hardware support (and getting it wrong, because you need to specify
> > _many_ critical parameters to hciattach).
> 
> Yes, this is indeed something I also would like to see for the GTA04 (and other)
> devices.
> 
> So the reason is that some kernel driver wants to use the tty/uart to communicate
> directly with the chip. This is very similar to a gpio that some driver wants to use.
> 
> Thus please consider the
> 
> / {
> 	bt {
> 		compatible = "vendor,product“;
> 		uart = <&uart1>;
> 		enable = <&gpio17 34 0>;
> 	};
> };

Would work, too, but I and everyone knows that subnode is better,
easier solution.

> approach.
> 
> And if you want to hide uart1 from the user-space, that should be a property
> of the uart1 node (whereever it is defined).

Sorry? That would be one heck of layering violation.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 06:56 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>> Main reason is, that I would need to go
>>>>> through the UART to “communicate" with the w2sg0004.
>>>> 
>>>> You can always "communicate” through the UART. Even without DT. As long as
>>>> the connected chip is powered up by any means (could be some fixed-regulator
>>>> or hard wired).
>>> 
>>> But you don't know "how" to communicate through the uart.
>> 
>> Maybe we are talking using different assumptions. As long as you have a user space
>> gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
>> line disciplines) pass the data to the uart.
> 
> Forget userspace, some other operating system (or future linux) may
> want to put gps handling into the kernel. (To hide differences between
> different GPSes).
> 
>>> Because we want the phone to boot knowing "I have a bluetooth" or "I
>>> have a GPS", as it would if it was connected using USB, and not having
>>> user figure out what commands he needs to do to enable reasonable
>>> hardware support (and getting it wrong, because you need to specify
>>> _many_ critical parameters to hciattach).
>> 
>> Yes, this is indeed something I also would like to see for the GTA04 (and other)
>> devices.
>> 
>> So the reason is that some kernel driver wants to use the tty/uart to communicate
>> directly with the chip. This is very similar to a gpio that some driver wants to use.
>> 
>> Thus please consider the
>> 
>> / {
>> 	bt {
>> 		compatible = "vendor,product“;
>> 		uart = <&uart1>;
>> 		enable = <&gpio17 34 0>;
>> 	};
>> };
> 
> Would work, too, but I and everyone knows that subnode is better,
> easier solution.

“Everyone” could be wrong and ignorant.

And I thought we are not looking for the easiest solution but the right one.
Especially if we define something that is for other operating systems as well.

About easier: the one given above allows to modify the driver to present e.g. an iio
interface to user space (and no /dev/tty) *without changing the DT*. Because the
driver code decides which interface it presents. And not where it is a subnode in DT.

This is the level of abstraction DT nodes should have.


It may be that you did not read my previous argumentation completely.

In short, please see:

	http://www.devicetree.org/Device_Tree_Usage#Devices

And check of there is anything that mandates useage of a subnode in this case.
I simply don’t find it.

Rather, although it is also not explicitly excluded, I read hints that it should *not* be
done the subnode way.

The reason is that it appears to me that the DT hierarchy is intended to describe
how kernel drivers can *address* different components. Nothing less and nothing more.

Especially there is no hint that layering in DT has anything to do with data flow
hierarchies or a “primary” interface as Sebastian calls it.

> 
>> approach.
>> 
>> And if you want to hide uart1 from the user-space, that should be a property
>> of the uart1 node (whereever it is defined).
> 
> Sorry? That would be one heck of layering violation.

Which layering?

I think you still mix the software/kernel driver/data flow layers with DT layers.

DT can and must be independent on that.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 26.03.2015 um 06:56 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>>>> Main reason is, that I would need to go
>>>>> through the UART to “communicate" with the w2sg0004.
>>>> 
>>>> You can always "communicate” through the UART. Even without DT. As long as
>>>> the connected chip is powered up by any means (could be some fixed-regulator
>>>> or hard wired).
>>> 
>>> But you don't know "how" to communicate through the uart.
>> 
>> Maybe we are talking using different assumptions. As long as you have a user space
>> gpsd daemon that talks to the gps chip the kernel simply has to transparently (except
>> line disciplines) pass the data to the uart.
> 
> Forget userspace, some other operating system (or future linux) may
> want to put gps handling into the kernel. (To hide differences between
> different GPSes).
> 
>>> Because we want the phone to boot knowing "I have a bluetooth" or "I
>>> have a GPS", as it would if it was connected using USB, and not having
>>> user figure out what commands he needs to do to enable reasonable
>>> hardware support (and getting it wrong, because you need to specify
>>> _many_ critical parameters to hciattach).
>> 
>> Yes, this is indeed something I also would like to see for the GTA04 (and other)
>> devices.
>> 
>> So the reason is that some kernel driver wants to use the tty/uart to communicate
>> directly with the chip. This is very similar to a gpio that some driver wants to use.
>> 
>> Thus please consider the
>> 
>> / {
>> 	bt {
>> 		compatible = "vendor,product“;
>> 		uart = <&uart1>;
>> 		enable = <&gpio17 34 0>;
>> 	};
>> };
> 
> Would work, too, but I and everyone knows that subnode is better,
> easier solution.

“Everyone” could be wrong and ignorant.

And I thought we are not looking for the easiest solution but the right one.
Especially if we define something that is for other operating systems as well.

About easier: the one given above allows to modify the driver to present e.g. an iio
interface to user space (and no /dev/tty) *without changing the DT*. Because the
driver code decides which interface it presents. And not where it is a subnode in DT.

This is the level of abstraction DT nodes should have.


It may be that you did not read my previous argumentation completely.

In short, please see:

	http://www.devicetree.org/Device_Tree_Usage#Devices

And check of there is anything that mandates useage of a subnode in this case.
I simply don’t find it.

Rather, although it is also not explicitly excluded, I read hints that it should *not* be
done the subnode way.

The reason is that it appears to me that the DT hierarchy is intended to describe
how kernel drivers can *address* different components. Nothing less and nothing more.

Especially there is no hint that layering in DT has anything to do with data flow
hierarchies or a “primary” interface as Sebastian calls it.

> 
>> approach.
>> 
>> And if you want to hide uart1 from the user-space, that should be a property
>> of the uart1 node (whereever it is defined).
> 
> Sorry? That would be one heck of layering violation.

Which layering?

I think you still mix the software/kernel driver/data flow layers with DT layers.

DT can and must be independent on that.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> And if you want to hide uart1 from the user-space, that should be a property
> >> of the uart1 node (whereever it is defined).
> > 
> > Sorry? That would be one heck of layering violation.
> 
> Which layering?

Device tree is not operating system specific. It does not know what
"user space" is, and can't assume we have uart nodes in
/dev. Therefore it can't contain information that it should be hidden.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> >> And if you want to hide uart1 from the user-space, that should be a property
> >> of the uart1 node (whereever it is defined).
> > 
> > Sorry? That would be one heck of layering violation.
> 
> Which layering?

Device tree is not operating system specific. It does not know what
"user space" is, and can't assume we have uart nodes in
/dev. Therefore it can't contain information that it should be hidden.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> > In the case of our GPS, it receives control over the serial connection from
> > the UART,
> 
> Ahem - does it?
> 
> AFAIK the chip simply starts to emit NMEA records if powered on. There is no
> command going over the serial interface to address it or control it.

Well _most_ GPSes enable you to control them over the serial
line. (Things like sampling rate, AGPS data upload, ...)

> > I think the GPS is “primarily" a uart-attached device.
> 
> But not in the same way as an I2C device.
> 
> Especially the serial interface is not a bus and not used for signalling and
> power control. It is payload data (only).

Serial interface looks a lot like a (point-to-point) bus to
me. Similar to SATA, for example.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Pavel Machek]

Hi!

> > In the case of our GPS, it receives control over the serial connection from
> > the UART,
> 
> Ahem - does it?
> 
> AFAIK the chip simply starts to emit NMEA records if powered on. There is no
> command going over the serial interface to address it or control it.

Well _most_ GPSes enable you to control them over the serial
line. (Things like sampling rate, AGPS data upload, ...)

> > I think the GPS is “primarily" a uart-attached device.
> 
> But not in the same way as an I2C device.
> 
> Especially the serial interface is not a bus and not used for signalling and
> power control. It is payload data (only).

Serial interface looks a lot like a (point-to-point) bus to
me. Similar to SATA, for example.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 21:42 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>> In the case of our GPS, it receives control over the serial connection from
>>> the UART,
>> 
>> Ahem - does it?
>> 
>> AFAIK the chip simply starts to emit NMEA records if powered on. There is no
>> command going over the serial interface to address it or control it.
> 
> Well _most_ GPSes enable you to control them over the serial
> line. (Things like sampling rate, AGPS data upload, …)

Yes, I know.

But is this something the kernel is/must be aware? And
must it be represented by the DT? Or does it have to influence
the way the DT is structured?

Well, if GPS data is presented through iio, these commands must
be handled by some driver.

> 
>>> I think the GPS is “primarily" a uart-attached device.
>> 
>> But not in the same way as an I2C device.
>> 
>> Especially the serial interface is not a bus and not used for signalling and
>> power control. It is payload data (only).
> 
> Serial interface looks a lot like a (point-to-point) bus to
> me. Similar to SATA, for example.

In that sense a gpio looks also a lot like a 1-bit bus...

Anyways, there are no subnodes (clients) of a gpio but the
<&gpiocontroller> pattern is used.

In other words: a driver that wants to control a gpio asks for a
reference of the gpio controller and uses the gpiolib to control it.

In the same way, a driver that wants to use an uart could ask
for a reference to the tty/uart driver and use some functions to
control it (and send commands). So a hypothetical gps-iio
driver could set sampling rate etc.

And it can also ask the tty/uart: „please register me and notify if
some syscall wants you to open() or close() so that I (the driver of
the GPS chip) can turn on power of the GPS chip (and only I know
how to do that - nobody else has to care)“.

I am just playing the Devil's advocate to find out what the really
common principle is and how the DT for clients of a serial interface
should really be represented in a DT in a way that is agnostic to
a specific driver structure, driver functions and user space.

And to find out if we need tty/slaves (as proposed in the title of this
patch series) at all. Or if there is a better way to describe the relation
of the gps chip driver and the tty/uart.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 3/3] tty/slaves: add a driver to power on/off UART attached devices.

[Dr. H. Nikolaus Schaller]

Hi,

Am 25.03.2015 um 21:42 schrieb Pavel Machek <pavel@ucw.cz>:

> Hi!
> 
>>> In the case of our GPS, it receives control over the serial connection from
>>> the UART,
>> 
>> Ahem - does it?
>> 
>> AFAIK the chip simply starts to emit NMEA records if powered on. There is no
>> command going over the serial interface to address it or control it.
> 
> Well _most_ GPSes enable you to control them over the serial
> line. (Things like sampling rate, AGPS data upload, …)

Yes, I know.

But is this something the kernel is/must be aware? And
must it be represented by the DT? Or does it have to influence
the way the DT is structured?

Well, if GPS data is presented through iio, these commands must
be handled by some driver.

> 
>>> I think the GPS is “primarily" a uart-attached device.
>> 
>> But not in the same way as an I2C device.
>> 
>> Especially the serial interface is not a bus and not used for signalling and
>> power control. It is payload data (only).
> 
> Serial interface looks a lot like a (point-to-point) bus to
> me. Similar to SATA, for example.

In that sense a gpio looks also a lot like a 1-bit bus...

Anyways, there are no subnodes (clients) of a gpio but the
<&gpiocontroller> pattern is used.

In other words: a driver that wants to control a gpio asks for a
reference of the gpio controller and uses the gpiolib to control it.

In the same way, a driver that wants to use an uart could ask
for a reference to the tty/uart driver and use some functions to
control it (and send commands). So a hypothetical gps-iio
driver could set sampling rate etc.

And it can also ask the tty/uart: „please register me and notify if
some syscall wants you to open() or close() so that I (the driver of
the GPS chip) can turn on power of the GPS chip (and only I know
how to do that - nobody else has to care)“.

I am just playing the Devil's advocate to find out what the really
common principle is and how the DT for clients of a serial interface
should really be represented in a DT in a way that is agnostic to
a specific driver structure, driver functions and user space.

And to find out if we need tty/slaves (as proposed in the title of this
patch series) at all. Or if there is a better way to describe the relation
of the gps chip driver and the tty/uart.

BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] TTY: use class_find_device to find port in uart_suspend/resume.

[NeilBrown]

uart_{suspend,resume}_port seach the children of a uart device
to find a particular tty device.
This requires all the ttys to be direct children of the uart.

A future patch will allow a 'tty_slave' to intervene between
the port and the uart, voiding this requirement.

So change to use class_find_device.  This is made possibly by
exporting a "tty_find_device" from tty_io.c

Signed-off-by: NeilBrown <neil@brown.name>
---
 drivers/tty/serial/serial_core.c |   21 ++++++++-------------
 drivers/tty/tty_io.c             |    6 ++++++
 include/linux/tty.h              |    1 +
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 6a1055ae3437..7abb7474870a 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1960,26 +1960,19 @@ struct uart_match {
 	struct uart_driver *driver;
 };
 
-static int serial_match_port(struct device *dev, void *data)
-{
-	struct uart_match *match = data;
-	struct tty_driver *tty_drv = match->driver->tty_driver;
-	dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
-		match->port->line;
-
-	return dev->devt == devt; /* Actually, only one tty per port */
-}
 
 int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
 {
 	struct uart_state *state = drv->state + uport->line;
 	struct tty_port *port = &state->port;
 	struct device *tty_dev;
-	struct uart_match match = {uport, drv};
+	dev_t devt = MKDEV(drv->tty_driver->major,
+			   drv->tty_driver->minor_start) +
+		uport->line;
 
 	mutex_lock(&port->mutex);
 
-	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
+	tty_dev = tty_find_device(devt);
 	if (device_may_wakeup(tty_dev)) {
 		if (!enable_irq_wake(uport->irq))
 			uport->irq_wake = 1;
@@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
 	struct uart_state *state = drv->state + uport->line;
 	struct tty_port *port = &state->port;
 	struct device *tty_dev;
-	struct uart_match match = {uport, drv};
 	struct ktermios termios;
+	dev_t devt = MKDEV(drv->tty_driver->major,
+			   drv->tty_driver->minor_start) +
+		uport->line;
 
 	mutex_lock(&port->mutex);
 
-	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
+	tty_dev = tty_find_device(devt);
 	if (!uport->suspended && device_may_wakeup(tty_dev)) {
 		if (uport->irq_wake) {
 			disable_irq_wake(uport->irq);
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index 51f066aa375e..27632ad17d6f 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct tty_struct *tty)
 	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
 }
 
+struct device *tty_find_device(dev_t devt)
+{
+	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
+}
+EXPORT_SYMBOL(tty_find_device);
+
 
 /**
  *	alloc_tty_struct
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 358a337af598..04d5f1213700 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -461,6 +461,7 @@ extern void tty_vhangup(struct tty_struct *tty);
 extern int tty_hung_up_p(struct file *filp);
 extern void do_SAK(struct tty_struct *tty);
 extern void __do_SAK(struct tty_struct *tty);
+extern struct device *tty_find_device(dev_t devt);
 extern void no_tty(void);
 extern void tty_flush_to_ldisc(struct tty_struct *tty);
 extern void tty_buffer_free_all(struct tty_port *port);

Re: [PATCH 1/3] TTY: use class_find_device to find port in uart_suspend/resume.

[Peter Hurley]

Hi Neil,

On 03/18/2015 01:58 AM, NeilBrown wrote:
> uart_{suspend,resume}_port seach the children of a uart device
> to find a particular tty device.
> This requires all the ttys to be direct children of the uart.
> 
> A future patch will allow a 'tty_slave' to intervene between
> the port and the uart, voiding this requirement.
> 
> So change to use class_find_device.  This is made possibly by
> exporting a "tty_find_device" from tty_io.c

Comments below.

> Signed-off-by: NeilBrown <neil@brown.name>
> ---
>  drivers/tty/serial/serial_core.c |   21 ++++++++-------------
>  drivers/tty/tty_io.c             |    6 ++++++
>  include/linux/tty.h              |    1 +
>  3 files changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 6a1055ae3437..7abb7474870a 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1960,26 +1960,19 @@ struct uart_match {
>  	struct uart_driver *driver;
>  };
>  
> -static int serial_match_port(struct device *dev, void *data)
> -{
> -	struct uart_match *match = data;
> -	struct tty_driver *tty_drv = match->driver->tty_driver;
> -	dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
> -		match->port->line;
> -
> -	return dev->devt == devt; /* Actually, only one tty per port */
> -}
>  
>  int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
>  {
>  	struct uart_state *state = drv->state + uport->line;
>  	struct tty_port *port = &state->port;
>  	struct device *tty_dev;
> -	struct uart_match match = {uport, drv};
> +	dev_t devt = MKDEV(drv->tty_driver->major,
> +			   drv->tty_driver->minor_start) +
> +		uport->line;
>  
>  	mutex_lock(&port->mutex);
>  
> -	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
> +	tty_dev = tty_find_device(devt);
>  	if (device_may_wakeup(tty_dev)) {
>  		if (!enable_irq_wake(uport->irq))
>  			uport->irq_wake = 1;
> @@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
>  	struct uart_state *state = drv->state + uport->line;
>  	struct tty_port *port = &state->port;
>  	struct device *tty_dev;
> -	struct uart_match match = {uport, drv};
>  	struct ktermios termios;
> +	dev_t devt = MKDEV(drv->tty_driver->major,
> +			   drv->tty_driver->minor_start) +
> +		uport->line;
>  
>  	mutex_lock(&port->mutex);
>  
> -	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
> +	tty_dev = tty_find_device(devt);
>  	if (!uport->suspended && device_may_wakeup(tty_dev)) {
>  		if (uport->irq_wake) {
>  			disable_irq_wake(uport->irq);
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 51f066aa375e..27632ad17d6f 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct tty_struct *tty)
>  	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
>  }
>
> +struct device *tty_find_device(dev_t devt)
> +{
> +	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
> +}
> +EXPORT_SYMBOL(tty_find_device);
> +

Would you please replace tty_get_device() usage with tty_find_device()
(and keep the function comment from tty_get_device())?

Regards,
Peter Hurley

>  
>  /**
>   *	alloc_tty_struct
> diff --git a/include/linux/tty.h b/include/linux/tty.h
> index 358a337af598..04d5f1213700 100644
> --- a/include/linux/tty.h
> +++ b/include/linux/tty.h
> @@ -461,6 +461,7 @@ extern void tty_vhangup(struct tty_struct *tty);
>  extern int tty_hung_up_p(struct file *filp);
>  extern void do_SAK(struct tty_struct *tty);
>  extern void __do_SAK(struct tty_struct *tty);
> +extern struct device *tty_find_device(dev_t devt);
>  extern void no_tty(void);
>  extern void tty_flush_to_ldisc(struct tty_struct *tty);
>  extern void tty_buffer_free_all(struct tty_port *port);
> 
> 

Re: [PATCH 1/3] TTY: use class_find_device to find port in uart_suspend/resume.

[Peter Hurley]

Hi Neil,

On 03/18/2015 01:58 AM, NeilBrown wrote:
> uart_{suspend,resume}_port seach the children of a uart device
> to find a particular tty device.
> This requires all the ttys to be direct children of the uart.
> 
> A future patch will allow a 'tty_slave' to intervene between
> the port and the uart, voiding this requirement.
> 
> So change to use class_find_device.  This is made possibly by
> exporting a "tty_find_device" from tty_io.c

Comments below.

> Signed-off-by: NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>
> ---
>  drivers/tty/serial/serial_core.c |   21 ++++++++-------------
>  drivers/tty/tty_io.c             |    6 ++++++
>  include/linux/tty.h              |    1 +
>  3 files changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 6a1055ae3437..7abb7474870a 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -1960,26 +1960,19 @@ struct uart_match {
>  	struct uart_driver *driver;
>  };
>  
> -static int serial_match_port(struct device *dev, void *data)
> -{
> -	struct uart_match *match = data;
> -	struct tty_driver *tty_drv = match->driver->tty_driver;
> -	dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
> -		match->port->line;
> -
> -	return dev->devt == devt; /* Actually, only one tty per port */
> -}
>  
>  int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
>  {
>  	struct uart_state *state = drv->state + uport->line;
>  	struct tty_port *port = &state->port;
>  	struct device *tty_dev;
> -	struct uart_match match = {uport, drv};
> +	dev_t devt = MKDEV(drv->tty_driver->major,
> +			   drv->tty_driver->minor_start) +
> +		uport->line;
>  
>  	mutex_lock(&port->mutex);
>  
> -	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
> +	tty_dev = tty_find_device(devt);
>  	if (device_may_wakeup(tty_dev)) {
>  		if (!enable_irq_wake(uport->irq))
>  			uport->irq_wake = 1;
> @@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
>  	struct uart_state *state = drv->state + uport->line;
>  	struct tty_port *port = &state->port;
>  	struct device *tty_dev;
> -	struct uart_match match = {uport, drv};
>  	struct ktermios termios;
> +	dev_t devt = MKDEV(drv->tty_driver->major,
> +			   drv->tty_driver->minor_start) +
> +		uport->line;
>  
>  	mutex_lock(&port->mutex);
>  
> -	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
> +	tty_dev = tty_find_device(devt);
>  	if (!uport->suspended && device_may_wakeup(tty_dev)) {
>  		if (uport->irq_wake) {
>  			disable_irq_wake(uport->irq);
> diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> index 51f066aa375e..27632ad17d6f 100644
> --- a/drivers/tty/tty_io.c
> +++ b/drivers/tty/tty_io.c
> @@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct tty_struct *tty)
>  	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
>  }
>
> +struct device *tty_find_device(dev_t devt)
> +{
> +	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
> +}
> +EXPORT_SYMBOL(tty_find_device);
> +

Would you please replace tty_get_device() usage with tty_find_device()
(and keep the function comment from tty_get_device())?

Regards,
Peter Hurley

>  
>  /**
>   *	alloc_tty_struct
> diff --git a/include/linux/tty.h b/include/linux/tty.h
> index 358a337af598..04d5f1213700 100644
> --- a/include/linux/tty.h
> +++ b/include/linux/tty.h
> @@ -461,6 +461,7 @@ extern void tty_vhangup(struct tty_struct *tty);
>  extern int tty_hung_up_p(struct file *filp);
>  extern void do_SAK(struct tty_struct *tty);
>  extern void __do_SAK(struct tty_struct *tty);
> +extern struct device *tty_find_device(dev_t devt);
>  extern void no_tty(void);
>  extern void tty_flush_to_ldisc(struct tty_struct *tty);
>  extern void tty_buffer_free_all(struct tty_port *port);
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 1/3] TTY: use class_find_device to find port in uart_suspend/resume.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

On Wed, 25 Mar 2015 12:20:20 -0400 Peter Hurley <peter@hurleysoftware.com>
wrote:

> Hi Neil,
> 
> On 03/18/2015 01:58 AM, NeilBrown wrote:
> > uart_{suspend,resume}_port seach the children of a uart device
> > to find a particular tty device.
> > This requires all the ttys to be direct children of the uart.
> > 
> > A future patch will allow a 'tty_slave' to intervene between
> > the port and the uart, voiding this requirement.
> > 
> > So change to use class_find_device.  This is made possibly by
> > exporting a "tty_find_device" from tty_io.c
> 
> Comments below.
> 
> > Signed-off-by: NeilBrown <neil@brown.name>
> > ---
> >  drivers/tty/serial/serial_core.c |   21 ++++++++-------------
> >  drivers/tty/tty_io.c             |    6 ++++++
> >  include/linux/tty.h              |    1 +
> >  3 files changed, 15 insertions(+), 13 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index 6a1055ae3437..7abb7474870a 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -1960,26 +1960,19 @@ struct uart_match {
> >  	struct uart_driver *driver;
> >  };
> >  
> > -static int serial_match_port(struct device *dev, void *data)
> > -{
> > -	struct uart_match *match = data;
> > -	struct tty_driver *tty_drv = match->driver->tty_driver;
> > -	dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
> > -		match->port->line;
> > -
> > -	return dev->devt == devt; /* Actually, only one tty per port */
> > -}
> >  
> >  int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
> >  {
> >  	struct uart_state *state = drv->state + uport->line;
> >  	struct tty_port *port = &state->port;
> >  	struct device *tty_dev;
> > -	struct uart_match match = {uport, drv};
> > +	dev_t devt = MKDEV(drv->tty_driver->major,
> > +			   drv->tty_driver->minor_start) +
> > +		uport->line;
> >  
> >  	mutex_lock(&port->mutex);
> >  
> > -	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
> > +	tty_dev = tty_find_device(devt);
> >  	if (device_may_wakeup(tty_dev)) {
> >  		if (!enable_irq_wake(uport->irq))
> >  			uport->irq_wake = 1;
> > @@ -2039,12 +2032,14 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
> >  	struct uart_state *state = drv->state + uport->line;
> >  	struct tty_port *port = &state->port;
> >  	struct device *tty_dev;
> > -	struct uart_match match = {uport, drv};
> >  	struct ktermios termios;
> > +	dev_t devt = MKDEV(drv->tty_driver->major,
> > +			   drv->tty_driver->minor_start) +
> > +		uport->line;
> >  
> >  	mutex_lock(&port->mutex);
> >  
> > -	tty_dev = device_find_child(uport->dev, &match, serial_match_port);
> > +	tty_dev = tty_find_device(devt);
> >  	if (!uport->suspended && device_may_wakeup(tty_dev)) {
> >  		if (uport->irq_wake) {
> >  			disable_irq_wake(uport->irq);
> > diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
> > index 51f066aa375e..27632ad17d6f 100644
> > --- a/drivers/tty/tty_io.c
> > +++ b/drivers/tty/tty_io.c
> > @@ -3077,6 +3077,12 @@ static struct device *tty_get_device(struct tty_struct *tty)
> >  	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
> >  }
> >
> > +struct device *tty_find_device(dev_t devt)
> > +{
> > +	return class_find_device(tty_class, NULL, &devt, dev_match_devt);
> > +}
> > +EXPORT_SYMBOL(tty_find_device);
> > +
> 
> Would you please replace tty_get_device() usage with tty_find_device()
> (and keep the function comment from tty_get_device())?
> 

I was wondering what would be the best thing to do to tty_get_device.
As there is only one caller, replacing at you suggest seems best.
I've done that - thanks.

NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Neil,

Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:

> Hi again,
> here is version 3 of support for tty-slaves.
> 
> This version introduces a new bus-type for tty-slaves,

Hm. I am still not convinced that a tty is a „bus“ and 
that this is a solution for a wide-spread problem.

> and causes
> a tty-slave device to appear in /sys/devices between the uart and the
> tty.
> It effectively intercepts and calls from the tty to the uart (i.e. any
> tty_operations) and applies extra functionality at that point.

> 
> Currently the only driver intercepts open and close.
> It powers on the device on open, and powers off at last-close.

That is what the missing piece in Linux is to make the w2sg0004
chip work.

> 
> Power can be controlled by a regulator or by toggling a GPIO.

I think such a GPIO logic has nothing to do with serial and
should be left over to the regulator logic, i.e. we need a special
regulator-w2sg0004 driver.

So I suggest to remove the GPIO logic from your 

drivers/tty/slave/serial-power-manager.c

And then you can even get rid of adding a chip specific „compatible“
entry for the subnodes.

> 
> I think I've incorporated most of the feed back I received from
> previous versions, but if I missed something - I apologize.  If
> this approach is structurally acceptable then I can fix up all the
> smaller issues.

As said I would prefer that the w2sg0004 driver is just a separate
„regulator“ driver as we had proposed before.

Nikolaus



> 
> Thanks for your review,
> NeilBrown
> 
> 
> ---
> 
> NeilBrown (3):
>      TTY: use class_find_device to find port in uart_suspend/resume.
>      TTY: add support for tty_slave devices.
>      tty/slaves: add a driver to power on/off UART attached devices.
> 
> 
> .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
> .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
> .../devicetree/bindings/vendor-prefixes.txt        |    1 
> drivers/tty/Kconfig                                |    1 
> drivers/tty/Makefile                               |    1 
> drivers/tty/serial/serial_core.c                   |   21 -
> drivers/tty/slave/Kconfig                          |   21 +
> drivers/tty/slave/Makefile                         |    4 
> drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
> drivers/tty/slave/tty_slave_core.c                 |  136 +++++
> drivers/tty/tty_io.c                               |   60 ++
> include/linux/tty.h                                |    2 
> include/linux/tty_slave.h                          |   26 +
> 13 files changed, 813 insertions(+), 26 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> create mode 100644 drivers/tty/slave/Kconfig
> create mode 100644 drivers/tty/slave/Makefile
> create mode 100644 drivers/tty/slave/serial-power-manager.c
> create mode 100644 drivers/tty/slave/tty_slave_core.c
> create mode 100644 include/linux/tty_slave.h
> 
> --
> Signature
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Neil,

Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:

> Hi again,
> here is version 3 of support for tty-slaves.
> 
> This version introduces a new bus-type for tty-slaves,

Hm. I am still not convinced that a tty is a „bus“ and 
that this is a solution for a wide-spread problem.

> and causes
> a tty-slave device to appear in /sys/devices between the uart and the
> tty.
> It effectively intercepts and calls from the tty to the uart (i.e. any
> tty_operations) and applies extra functionality at that point.

> 
> Currently the only driver intercepts open and close.
> It powers on the device on open, and powers off at last-close.

That is what the missing piece in Linux is to make the w2sg0004
chip work.

> 
> Power can be controlled by a regulator or by toggling a GPIO.

I think such a GPIO logic has nothing to do with serial and
should be left over to the regulator logic, i.e. we need a special
regulator-w2sg0004 driver.

So I suggest to remove the GPIO logic from your 

drivers/tty/slave/serial-power-manager.c

And then you can even get rid of adding a chip specific „compatible“
entry for the subnodes.

> 
> I think I've incorporated most of the feed back I received from
> previous versions, but if I missed something - I apologize.  If
> this approach is structurally acceptable then I can fix up all the
> smaller issues.

As said I would prefer that the w2sg0004 driver is just a separate
„regulator“ driver as we had proposed before.

Nikolaus



> 
> Thanks for your review,
> NeilBrown
> 
> 
> ---
> 
> NeilBrown (3):
>      TTY: use class_find_device to find port in uart_suspend/resume.
>      TTY: add support for tty_slave devices.
>      tty/slaves: add a driver to power on/off UART attached devices.
> 
> 
> .../bindings/tty_slave/wi2wi,w2cbw003.txt          |   19 +
> .../bindings/tty_slave/wi2wi,w2sg0004.txt          |   37 +
> .../devicetree/bindings/vendor-prefixes.txt        |    1 
> drivers/tty/Kconfig                                |    1 
> drivers/tty/Makefile                               |    1 
> drivers/tty/serial/serial_core.c                   |   21 -
> drivers/tty/slave/Kconfig                          |   21 +
> drivers/tty/slave/Makefile                         |    4 
> drivers/tty/slave/serial-power-manager.c           |  510 ++++++++++++++++++++
> drivers/tty/slave/tty_slave_core.c                 |  136 +++++
> drivers/tty/tty_io.c                               |   60 ++
> include/linux/tty.h                                |    2 
> include/linux/tty_slave.h                          |   26 +
> 13 files changed, 813 insertions(+), 26 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2cbw003.txt
> create mode 100644 Documentation/devicetree/bindings/tty_slave/wi2wi,w2sg0004.txt
> create mode 100644 drivers/tty/slave/Kconfig
> create mode 100644 drivers/tty/slave/Makefile
> create mode 100644 drivers/tty/slave/serial-power-manager.c
> create mode 100644 drivers/tty/slave/tty_slave_core.c
> create mode 100644 include/linux/tty_slave.h
> 
> --
> Signature
> 
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller"
<hns@goldelico.com> wrote:

> Hi Neil,
> 
> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:
> 
> > Hi again,
> > here is version 3 of support for tty-slaves.
> > 
> > This version introduces a new bus-type for tty-slaves,
> 
> Hm. I am still not convinced that a tty is a „bus“ and 
> that this is a solution for a wide-spread problem.

Don't read too much into the word "bus".  It is really just a mechanism for
grouping drivers together - with maybe a hint of a suggestions that it helps
communicate with the devices which the drivers drive.

And I'm not particularly interested in solving wide-spread problems, just in
solving my problem in a suitably idiomatic way.


> 
> > and causes
> > a tty-slave device to appear in /sys/devices between the uart and the
> > tty.
> > It effectively intercepts and calls from the tty to the uart (i.e. any
> > tty_operations) and applies extra functionality at that point.
> 
> > 
> > Currently the only driver intercepts open and close.
> > It powers on the device on open, and powers off at last-close.
> 
> That is what the missing piece in Linux is to make the w2sg0004
> chip work.
> 
> > 
> > Power can be controlled by a regulator or by toggling a GPIO.
> 
> I think such a GPIO logic has nothing to do with serial and
> should be left over to the regulator logic, i.e. we need a special
> regulator-w2sg0004 driver.
> 
> So I suggest to remove the GPIO logic from your 
> 
> drivers/tty/slave/serial-power-manager.c
> 
> And then you can even get rid of adding a chip specific „compatible“
> entry for the subnodes.

But (nearly) every node has a "compatible" entry.
Each node describes a device, and the "compatible" string tells us what sort
of device.
Surely you agree that there is a particular device that needs to be
controlled?  In that case there needs to be a node representing it and a
"compatible" string describing it.  That is how "devicetree" works.


> 
> > 
> > I think I've incorporated most of the feed back I received from
> > previous versions, but if I missed something - I apologize.  If
> > this approach is structurally acceptable then I can fix up all the
> > smaller issues.
> 
> As said I would prefer that the w2sg0004 driver is just a separate
> „regulator“ driver as we had proposed before.

You can prefer that if you wish.  But given that the w2sg0004 is not in fact
a regulator, but is in fact a GPS device, I doubt you will find a lot of
support for your approach (as indeed I didn't when I tried it...)

Thanks,
NeilBrown


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller"
<hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:

> Hi Neil,
> 
> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil-+NVA1uvv1dVBDLzU/O5InQ@public.gmane.org>:
> 
> > Hi again,
> > here is version 3 of support for tty-slaves.
> > 
> > This version introduces a new bus-type for tty-slaves,
> 
> Hm. I am still not convinced that a tty is a „bus“ and 
> that this is a solution for a wide-spread problem.

Don't read too much into the word "bus".  It is really just a mechanism for
grouping drivers together - with maybe a hint of a suggestions that it helps
communicate with the devices which the drivers drive.

And I'm not particularly interested in solving wide-spread problems, just in
solving my problem in a suitably idiomatic way.


> 
> > and causes
> > a tty-slave device to appear in /sys/devices between the uart and the
> > tty.
> > It effectively intercepts and calls from the tty to the uart (i.e. any
> > tty_operations) and applies extra functionality at that point.
> 
> > 
> > Currently the only driver intercepts open and close.
> > It powers on the device on open, and powers off at last-close.
> 
> That is what the missing piece in Linux is to make the w2sg0004
> chip work.
> 
> > 
> > Power can be controlled by a regulator or by toggling a GPIO.
> 
> I think such a GPIO logic has nothing to do with serial and
> should be left over to the regulator logic, i.e. we need a special
> regulator-w2sg0004 driver.
> 
> So I suggest to remove the GPIO logic from your 
> 
> drivers/tty/slave/serial-power-manager.c
> 
> And then you can even get rid of adding a chip specific „compatible“
> entry for the subnodes.

But (nearly) every node has a "compatible" entry.
Each node describes a device, and the "compatible" string tells us what sort
of device.
Surely you agree that there is a particular device that needs to be
controlled?  In that case there needs to be a node representing it and a
"compatible" string describing it.  That is how "devicetree" works.


> 
> > 
> > I think I've incorporated most of the feed back I received from
> > previous versions, but if I missed something - I apologize.  If
> > this approach is structurally acceptable then I can fix up all the
> > smaller issues.
> 
> As said I would prefer that the w2sg0004 driver is just a separate
> „regulator“ driver as we had proposed before.

You can prefer that if you wish.  But given that the w2sg0004 is not in fact
a regulator, but is in fact a GPS device, I doubt you will find a lot of
support for your approach (as indeed I didn't when I tried it...)

Thanks,
NeilBrown


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 20.03.2015 um 09:43 schrieb NeilBrown <neilb@suse.de>:

> On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller"
> <hns@goldelico.com> wrote:
> 
>> Hi Neil,
>> 
>> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:
>> 
>>> Hi again,
>>> here is version 3 of support for tty-slaves.
>>> 
>>> This version introduces a new bus-type for tty-slaves,
>> 
>> Hm. I am still not convinced that a tty is a „bus“ and 
>> that this is a solution for a wide-spread problem.
> 
> Don’t read too much into the word "bus".  

Then we should find a different word.

> It is really just a mechanism for
> grouping drivers together - with maybe a hint of a suggestions that it helps
> communicate with the devices which the drivers drive.
> 
> And I'm not particularly interested in solving wide-spread problems, just in
> solving my problem in a suitably idiomatic way.
> 
> 
>> 
>>> and causes
>>> a tty-slave device to appear in /sys/devices between the uart and the
>>> tty.
>>> It effectively intercepts and calls from the tty to the uart (i.e. any
>>> tty_operations) and applies extra functionality at that point.
>> 
>>> 
>>> Currently the only driver intercepts open and close.
>>> It powers on the device on open, and powers off at last-close.
>> 
>> That is what the missing piece in Linux is to make the w2sg0004
>> chip work.
>> 
>>> 
>>> Power can be controlled by a regulator or by toggling a GPIO.
>> 
>> I think such a GPIO logic has nothing to do with serial and
>> should be left over to the regulator logic, i.e. we need a special
>> regulator-w2sg0004 driver.
>> 
>> So I suggest to remove the GPIO logic from your 
>> 
>> drivers/tty/slave/serial-power-manager.c
>> 
>> And then you can even get rid of adding a chip specific „compatible“
>> entry for the subnodes.
> 
> But (nearly) every node has a "compatible" entry.
> Each node describes a device, and the "compatible" string tells us what sort
> of device.

Yes, it should - if necessary.

> Surely you agree that there is a particular device that needs to be
> controlled?

No, my opinion is that a specific regulator should be controlled.

>  In that case there needs to be a node representing it and a
> "compatible" string describing it.  That is how “devicetree" works.

For this there is the vdd-regulator = <&regulator> idiom and that is
how “devicetree” works as well.

> 
> 
>> 
>>> 
>>> I think I've incorporated most of the feed back I received from
>>> previous versions, but if I missed something - I apologize.  If
>>> this approach is structurally acceptable then I can fix up all the
>>> smaller issues.
>> 
>> As said I would prefer that the w2sg0004 driver is just a separate
>> „regulator“ driver as we had proposed before.
> 
> You can prefer that if you wish.  But given that the w2sg0004 is not in fact
> a regulator,

therefore our proposal is to make it a drivers/misc and not a drivers/regulator.
But it has a regulator inside that can obviously be turned on or off. So I want to
keep close to the logical energy flow.

> but is in fact a GPS device, I doubt you will find a lot of
> support for your approach (as indeed I didn’t when I tried it...)

We got a lot of support. The main opposition was about using a “virtual”
gpio controller instead of a regulator API to turn the chip on and off as
directed by the tty driver.

And we do not write a driver for the w2sg0004 but the regulator inside that
chip. You also won’t expect that the omap3 driver hides everything. You
expect that the twl4030 provides some regulators that can be enabled
by subsystems inside the omap3. And if I remember correctly there are
regulators inside the omap3 which have explicit regulator nodes in the DT.

The w2sg0004-regulator approach just follows this principle. Anyone willing
to control the power of the w2sg0004 can use this regulator interface.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 20.03.2015 um 09:43 schrieb NeilBrown <neilb@suse.de>:

> On Fri, 20 Mar 2015 08:54:35 +0100 "Dr. H. Nikolaus Schaller"
> <hns@goldelico.com> wrote:
> 
>> Hi Neil,
>> 
>> Am 18.03.2015 um 06:58 schrieb NeilBrown <neil@brown.name>:
>> 
>>> Hi again,
>>> here is version 3 of support for tty-slaves.
>>> 
>>> This version introduces a new bus-type for tty-slaves,
>> 
>> Hm. I am still not convinced that a tty is a „bus“ and 
>> that this is a solution for a wide-spread problem.
> 
> Don’t read too much into the word "bus".  

Then we should find a different word.

> It is really just a mechanism for
> grouping drivers together - with maybe a hint of a suggestions that it helps
> communicate with the devices which the drivers drive.
> 
> And I'm not particularly interested in solving wide-spread problems, just in
> solving my problem in a suitably idiomatic way.
> 
> 
>> 
>>> and causes
>>> a tty-slave device to appear in /sys/devices between the uart and the
>>> tty.
>>> It effectively intercepts and calls from the tty to the uart (i.e. any
>>> tty_operations) and applies extra functionality at that point.
>> 
>>> 
>>> Currently the only driver intercepts open and close.
>>> It powers on the device on open, and powers off at last-close.
>> 
>> That is what the missing piece in Linux is to make the w2sg0004
>> chip work.
>> 
>>> 
>>> Power can be controlled by a regulator or by toggling a GPIO.
>> 
>> I think such a GPIO logic has nothing to do with serial and
>> should be left over to the regulator logic, i.e. we need a special
>> regulator-w2sg0004 driver.
>> 
>> So I suggest to remove the GPIO logic from your 
>> 
>> drivers/tty/slave/serial-power-manager.c
>> 
>> And then you can even get rid of adding a chip specific „compatible“
>> entry for the subnodes.
> 
> But (nearly) every node has a "compatible" entry.
> Each node describes a device, and the "compatible" string tells us what sort
> of device.

Yes, it should - if necessary.

> Surely you agree that there is a particular device that needs to be
> controlled?

No, my opinion is that a specific regulator should be controlled.

>  In that case there needs to be a node representing it and a
> "compatible" string describing it.  That is how “devicetree" works.

For this there is the vdd-regulator = <&regulator> idiom and that is
how “devicetree” works as well.

> 
> 
>> 
>>> 
>>> I think I've incorporated most of the feed back I received from
>>> previous versions, but if I missed something - I apologize.  If
>>> this approach is structurally acceptable then I can fix up all the
>>> smaller issues.
>> 
>> As said I would prefer that the w2sg0004 driver is just a separate
>> „regulator“ driver as we had proposed before.
> 
> You can prefer that if you wish.  But given that the w2sg0004 is not in fact
> a regulator,

therefore our proposal is to make it a drivers/misc and not a drivers/regulator.
But it has a regulator inside that can obviously be turned on or off. So I want to
keep close to the logical energy flow.

> but is in fact a GPS device, I doubt you will find a lot of
> support for your approach (as indeed I didn’t when I tried it...)

We got a lot of support. The main opposition was about using a “virtual”
gpio controller instead of a regulator API to turn the chip on and off as
directed by the tty driver.

And we do not write a driver for the w2sg0004 but the regulator inside that
chip. You also won’t expect that the omap3 driver hides everything. You
expect that the twl4030 provides some regulators that can be enabled
by subsystems inside the omap3. And if I remember correctly there are
regulators inside the omap3 which have explicit regulator nodes in the DT.

The w2sg0004-regulator approach just follows this principle. Anyone willing
to control the power of the w2sg0004 can use this regulator interface.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

Hi,

On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
> [...]
> And we do not write a driver for the w2sg0004 but the regulator inside that
> chip.

DT describes the hardware structure and not the Linux driver
structure.

> You also won’t expect that the omap3 driver hides everything. You
> expect that the twl4030 provides some regulators that can be enabled
> by subsystems inside the omap3. And if I remember correctly there are
> regulators inside the omap3 which have explicit regulator nodes in the DT.

so let's have a look at twl regulators. They can be found below
the twl node, so they will look similar to

/ -> omap3 -> i2c -> twl -> regulator

So properly mapped to the w2sg0004 device this would put your
regulator to

/ -> omap3 -> serial -> w2sg0004 -> regulator

This will gain you nothing as far as I can tell.

Please note that subdevices under the serial node are pretty useful,
since then the kernel can e.g. automatically setup correct line
disciplines for serial attached bluetooth chips and make bluetooth
work out of the box.

I am aware, that the Linux kernel has no such thing for serial
attached GPS devices, but that's Linux specific and irrelevant
for the DT description.

> The w2sg0004-regulator approach just follows this principle.
> Anyone willing to control the power of the w2sg0004 can use this
> regulator interface.

From a HW perspective your regulator "hides" the information, that
there is a device attached to the serial port and instead claims,
that a regulator is needed to make the serial port work.

Apart from that this interface is limited in its features. I'm
currently working on N900's bluetooth chip. This one needs to set a
gpio before data is sent data to the chip, has a reset gpio and
a gpio to wakeup the OMAP SoC from idle states to avoid data loss
on the UART.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

Hi,

On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
> [...]
> And we do not write a driver for the w2sg0004 but the regulator inside that
> chip.

DT describes the hardware structure and not the Linux driver
structure.

> You also won’t expect that the omap3 driver hides everything. You
> expect that the twl4030 provides some regulators that can be enabled
> by subsystems inside the omap3. And if I remember correctly there are
> regulators inside the omap3 which have explicit regulator nodes in the DT.

so let's have a look at twl regulators. They can be found below
the twl node, so they will look similar to

/ -> omap3 -> i2c -> twl -> regulator

So properly mapped to the w2sg0004 device this would put your
regulator to

/ -> omap3 -> serial -> w2sg0004 -> regulator

This will gain you nothing as far as I can tell.

Please note that subdevices under the serial node are pretty useful,
since then the kernel can e.g. automatically setup correct line
disciplines for serial attached bluetooth chips and make bluetooth
work out of the box.

I am aware, that the Linux kernel has no such thing for serial
attached GPS devices, but that's Linux specific and irrelevant
for the DT description.

> The w2sg0004-regulator approach just follows this principle.
> Anyone willing to control the power of the w2sg0004 can use this
> regulator interface.

From a HW perspective your regulator "hides" the information, that
there is a device attached to the serial port and instead claims,
that a regulator is needed to make the serial port work.

Apart from that this interface is limited in its features. I'm
currently working on N900's bluetooth chip. This one needs to set a
gpio before data is sent data to the chip, has a reset gpio and
a gpio to wakeup the OMAP SoC from idle states to avoid data loss
on the UART.

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 20.03.2015 um 14:08 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
>> [...]
>> And we do not write a driver for the w2sg0004 but the regulator inside that
>> chip.
> 
> DT describes the hardware structure and not the Linux driver
> structure.

I am not advocating for describing the Linux driver structure in DT.
Rather I suggest that the DT should describe hardware and there
is a regulator inside that chip… Linux drivers can follow that or mix
everything into a single driver if that is better.

> 
>> You also won’t expect that the omap3 driver hides everything. You
>> expect that the twl4030 provides some regulators that can be enabled
>> by subsystems inside the omap3. And if I remember correctly there are
>> regulators inside the omap3 which have explicit regulator nodes in the DT.
> 
> so let's have a look at twl regulators. They can be found below
> the twl node, so they will look similar to
> 
> / -> omap3 -> i2c -> twl -> regulator
> 
> So properly mapped to the w2sg0004 device this would put your
> regulator to
> 
> / -> omap3 -> serial -> w2sg0004 -> regulator

Yes. Indeed.

Currently it is

omap3 -> serial -> serial-power-manager (trying to cover a multitude
of different chips).

> 
> This will gain you nothing as far as I can tell.

And because of that I think Neil’s argument isn’t for or against
anything.

> 
> Please note that subdevices under the serial node are pretty useful,
> since then the kernel can e.g. automatically setup correct line
> disciplines for serial attached bluetooth chips and make bluetooth
> work out of the box.

I don’t doubt that such subnodes are useful. I just object mixing
different chips and controls into a single subnode driver.

And as soon as you want to control line disciplines from such
a subnode, you indeed need a driver for each variant.

So a GPS chip needing some line discipline could be

> / -> omap3 -> serial -> w2sg0004 -> line-discipline
> / -> omap3 -> serial -> w2sg0004 -> regulator

And if omap3 -> serial can directly control a regulator, it can
easily be the w2sg0004 -> regulator

> 
> I am aware, that the Linux kernel has no such thing for serial
> attached GPS devices, but that's Linux specific and irrelevant
> for the DT description.
> 
>> The w2sg0004-regulator approach just follows this principle.
>> Anyone willing to control the power of the w2sg0004 can use this
>> regulator interface.
> 
> From a HW perspective your regulator "hides" the information, that
> there is a device attached to the serial port and instead claims,
> that a regulator is needed to make the serial port work.

Yes, without this regulator the serial port does not work. It is IMHO
more important than stating the obvious that a serial device is
connected to a serial port.

And if there is nothing to hide (the obvious serial interface wiring), why
describe it at all?

Anyways, in my proposal there will be a subnode of the uart, the
one where it is specified that it should control the regulator of the
w2sg.

Basically, Neil’s proposal already covers this case. His bluetooth
subnode just controls &vaux4 which turns on power for the w2cbw003
chip.

So for my view it is not really understandable why one uart subnode
can control a regulator, and the other can’t or shouldn’t and why
this regulator function can’t be divided from the serial management
into a regulator driver.

> 
> Apart from that this interface is limited in its features. I'm
> currently working on N900's bluetooth chip. This one needs to set a
> gpio before data is sent data to the chip, has a reset gpio and
> a gpio to wakeup the OMAP SoC from idle states to avoid data loss
> on the UART.

Yes, that looks equally complicated to solve if not even more than
the w2sg chip.

But what would you prefer:

* extend the drivers/tty/slave/serial-power-manager.c to also cover your
  special case

* instantiate a drivers/misc/n900-bluetooth-regulator.c and hook it up
  exactly like the vaux4 of the gta04 bluetooth chip? Just referencing
  a different regulator node?

And as said I don’t mind if the regulator is a subnode of the omap3 serial.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 20.03.2015 um 14:08 schrieb Sebastian Reichel <sre@kernel.org>:

> Hi,
> 
> On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
>> [...]
>> And we do not write a driver for the w2sg0004 but the regulator inside that
>> chip.
> 
> DT describes the hardware structure and not the Linux driver
> structure.

I am not advocating for describing the Linux driver structure in DT.
Rather I suggest that the DT should describe hardware and there
is a regulator inside that chip… Linux drivers can follow that or mix
everything into a single driver if that is better.

> 
>> You also won’t expect that the omap3 driver hides everything. You
>> expect that the twl4030 provides some regulators that can be enabled
>> by subsystems inside the omap3. And if I remember correctly there are
>> regulators inside the omap3 which have explicit regulator nodes in the DT.
> 
> so let's have a look at twl regulators. They can be found below
> the twl node, so they will look similar to
> 
> / -> omap3 -> i2c -> twl -> regulator
> 
> So properly mapped to the w2sg0004 device this would put your
> regulator to
> 
> / -> omap3 -> serial -> w2sg0004 -> regulator

Yes. Indeed.

Currently it is

omap3 -> serial -> serial-power-manager (trying to cover a multitude
of different chips).

> 
> This will gain you nothing as far as I can tell.

And because of that I think Neil’s argument isn’t for or against
anything.

> 
> Please note that subdevices under the serial node are pretty useful,
> since then the kernel can e.g. automatically setup correct line
> disciplines for serial attached bluetooth chips and make bluetooth
> work out of the box.

I don’t doubt that such subnodes are useful. I just object mixing
different chips and controls into a single subnode driver.

And as soon as you want to control line disciplines from such
a subnode, you indeed need a driver for each variant.

So a GPS chip needing some line discipline could be

> / -> omap3 -> serial -> w2sg0004 -> line-discipline
> / -> omap3 -> serial -> w2sg0004 -> regulator

And if omap3 -> serial can directly control a regulator, it can
easily be the w2sg0004 -> regulator

> 
> I am aware, that the Linux kernel has no such thing for serial
> attached GPS devices, but that's Linux specific and irrelevant
> for the DT description.
> 
>> The w2sg0004-regulator approach just follows this principle.
>> Anyone willing to control the power of the w2sg0004 can use this
>> regulator interface.
> 
> From a HW perspective your regulator "hides" the information, that
> there is a device attached to the serial port and instead claims,
> that a regulator is needed to make the serial port work.

Yes, without this regulator the serial port does not work. It is IMHO
more important than stating the obvious that a serial device is
connected to a serial port.

And if there is nothing to hide (the obvious serial interface wiring), why
describe it at all?

Anyways, in my proposal there will be a subnode of the uart, the
one where it is specified that it should control the regulator of the
w2sg.

Basically, Neil’s proposal already covers this case. His bluetooth
subnode just controls &vaux4 which turns on power for the w2cbw003
chip.

So for my view it is not really understandable why one uart subnode
can control a regulator, and the other can’t or shouldn’t and why
this regulator function can’t be divided from the serial management
into a regulator driver.

> 
> Apart from that this interface is limited in its features. I'm
> currently working on N900's bluetooth chip. This one needs to set a
> gpio before data is sent data to the chip, has a reset gpio and
> a gpio to wakeup the OMAP SoC from idle states to avoid data loss
> on the UART.

Yes, that looks equally complicated to solve if not even more than
the w2sg chip.

But what would you prefer:

* extend the drivers/tty/slave/serial-power-manager.c to also cover your
  special case

* instantiate a drivers/misc/n900-bluetooth-regulator.c and hook it up
  exactly like the vaux4 of the gta04 bluetooth chip? Just referencing
  a different regulator node?

And as said I don’t mind if the regulator is a subnode of the omap3 serial.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 6269 bytes --]

Hi,

On Fri, Mar 20, 2015 at 02:57:12PM +0100, Dr. H. Nikolaus Schaller wrote:
> > On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> [...]
> >> And we do not write a driver for the w2sg0004 but the regulator inside that
> >> chip.
> > 
> > DT describes the hardware structure and not the Linux driver
> > structure.
> 
> I am not advocating for describing the Linux driver structure in DT.
> Rather I suggest that the DT should describe hardware and there
> is a regulator inside that chip…

some drivers also have embedded clocks, which are not described,
since they are only useful for the device itself. Exposing them
is not useful.

> Linux drivers can follow that or mix everything into a single
> driver if that is better.

The DT binding is completly independent of drivers.

> >> You also won’t expect that the omap3 driver hides everything. You
> >> expect that the twl4030 provides some regulators that can be enabled
> >> by subsystems inside the omap3. And if I remember correctly there are
> >> regulators inside the omap3 which have explicit regulator nodes in the DT.
> > 
> > so let's have a look at twl regulators. They can be found below
> > the twl node, so they will look similar to
> > 
> > / -> omap3 -> i2c -> twl -> regulator
> > 
> > So properly mapped to the w2sg0004 device this would put your
> > regulator to
> > 
> > / -> omap3 -> serial -> w2sg0004 -> regulator
> 
> Yes. Indeed.
> 
> Currently it is
> 
> omap3 -> serial -> serial-power-manager (trying to cover a multitude
> of different chips).

No. The DT is omap3 -> serial -> w2sg0004 and w2sg0004 is
handled by a generic driver. If the kernel ever gets more
specific support for UART attached gps you can simply remove
the compatible value from the generic driver and create a
specific one.

> > This will gain you nothing as far as I can tell.
> 
> And because of that I think Neil’s argument isn’t for or against
> anything.
> 
> > 
> > Please note that subdevices under the serial node are pretty useful,
> > since then the kernel can e.g. automatically setup correct line
> > disciplines for serial attached bluetooth chips and make bluetooth
> > work out of the box.
> 
> I don’t doubt that such subnodes are useful. I just object mixing
> different chips and controls into a single subnode driver.

Well the binding allows to split this into multiple drivers
in the future (if needed).

> And as soon as you want to control line disciplines from such
> a subnode, you indeed need a driver for each variant.

Obviously I do not use the generic driver, but a specific one for
this task. Very simple devices (from kernel's point of view) can
still be handled by a generic driver (as Neil does).

> So a GPS chip needing some line discipline could be
> 
> > / -> omap3 -> serial -> w2sg0004 -> line-discipline
> > / -> omap3 -> serial -> w2sg0004 -> regulator

Actually no. The line discipline does not describe HW, but just
how linux handles the device. It should not be part of DT at all.
The kernel will see compatible string for w2sg0004 and load the
correct line discipline.

> And if omap3 -> serial can directly control a regulator, it can
> easily be the w2sg0004 -> regulator

sure.

> > I am aware, that the Linux kernel has no such thing for serial
> > attached GPS devices, but that's Linux specific and irrelevant
> > for the DT description.
> > 
> >> The w2sg0004-regulator approach just follows this principle.
> >> Anyone willing to control the power of the w2sg0004 can use this
> >> regulator interface.
> > 
> > From a HW perspective your regulator "hides" the information, that
> > there is a device attached to the serial port and instead claims,
> > that a regulator is needed to make the serial port work.
> 
> Yes, without this regulator the serial port does not work. It is IMHO
> more important than stating the obvious that a serial device is
> connected to a serial port.

This is actually not correct though. The serial port does work
without the regulator. The remote side does not work without the
regulator. So the regulator should be referenced by the w2sg0004
node, so it would be

serial-port {
    w2sg0004 {
        w2sg_vdd: gpio-regulator { enable-gpio = <&some_gpio> };
        vdd-supply = <&w2sg_vdd>;
    }
}

And at this point you can simply drop the regulator stuff from DT,
since its device internal (and only adds complexity). For other
devices these kind of ressources are also not exposed in DT (e.g.
internal clocks).

> And if there is nothing to hide (the obvious serial interface
> wiring), why describe it at all?
> 
> Anyways, in my proposal there will be a subnode of the uart, the
> one where it is specified that it should control the regulator of the
> w2sg.
> 
> Basically, Neil’s proposal already covers this case. His bluetooth
> subnode just controls &vaux4 which turns on power for the w2cbw003
> chip.
> 
> So for my view it is not really understandable why one uart subnode
> can control a regulator, and the other can’t or shouldn’t and why
> this regulator function can’t be divided from the serial management
> into a regulator driver.
>
> > 
> > Apart from that this interface is limited in its features. I'm
> > currently working on N900's bluetooth chip. This one needs to set a
> > gpio before data is sent data to the chip, has a reset gpio and
> > a gpio to wakeup the OMAP SoC from idle states to avoid data loss
> > on the UART.
> 
> Yes, that looks equally complicated to solve if not even more than
> the w2sg chip.
> 
> But what would you prefer:
> 
> * extend the drivers/tty/slave/serial-power-manager.c to also cover your
>   special case

I would simply create a new slave driver, which takes care of the
gpios and setups the line discipline.

> * instantiate a drivers/misc/n900-bluetooth-regulator.c and hook it up
>   exactly like the vaux4 of the gta04 bluetooth chip? Just referencing
>   a different regulator node?

The gpios in the n900's case are definitely not regulators. They are
used for waking up a device, not for supplying them with energy.

> [...]

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 6269 bytes --]

Hi,

On Fri, Mar 20, 2015 at 02:57:12PM +0100, Dr. H. Nikolaus Schaller wrote:
> > On Fri, Mar 20, 2015 at 09:54:21AM +0100, Dr. H. Nikolaus Schaller wrote:
> >> [...]
> >> And we do not write a driver for the w2sg0004 but the regulator inside that
> >> chip.
> > 
> > DT describes the hardware structure and not the Linux driver
> > structure.
> 
> I am not advocating for describing the Linux driver structure in DT.
> Rather I suggest that the DT should describe hardware and there
> is a regulator inside that chip…

some drivers also have embedded clocks, which are not described,
since they are only useful for the device itself. Exposing them
is not useful.

> Linux drivers can follow that or mix everything into a single
> driver if that is better.

The DT binding is completly independent of drivers.

> >> You also won’t expect that the omap3 driver hides everything. You
> >> expect that the twl4030 provides some regulators that can be enabled
> >> by subsystems inside the omap3. And if I remember correctly there are
> >> regulators inside the omap3 which have explicit regulator nodes in the DT.
> > 
> > so let's have a look at twl regulators. They can be found below
> > the twl node, so they will look similar to
> > 
> > / -> omap3 -> i2c -> twl -> regulator
> > 
> > So properly mapped to the w2sg0004 device this would put your
> > regulator to
> > 
> > / -> omap3 -> serial -> w2sg0004 -> regulator
> 
> Yes. Indeed.
> 
> Currently it is
> 
> omap3 -> serial -> serial-power-manager (trying to cover a multitude
> of different chips).

No. The DT is omap3 -> serial -> w2sg0004 and w2sg0004 is
handled by a generic driver. If the kernel ever gets more
specific support for UART attached gps you can simply remove
the compatible value from the generic driver and create a
specific one.

> > This will gain you nothing as far as I can tell.
> 
> And because of that I think Neil’s argument isn’t for or against
> anything.
> 
> > 
> > Please note that subdevices under the serial node are pretty useful,
> > since then the kernel can e.g. automatically setup correct line
> > disciplines for serial attached bluetooth chips and make bluetooth
> > work out of the box.
> 
> I don’t doubt that such subnodes are useful. I just object mixing
> different chips and controls into a single subnode driver.

Well the binding allows to split this into multiple drivers
in the future (if needed).

> And as soon as you want to control line disciplines from such
> a subnode, you indeed need a driver for each variant.

Obviously I do not use the generic driver, but a specific one for
this task. Very simple devices (from kernel's point of view) can
still be handled by a generic driver (as Neil does).

> So a GPS chip needing some line discipline could be
> 
> > / -> omap3 -> serial -> w2sg0004 -> line-discipline
> > / -> omap3 -> serial -> w2sg0004 -> regulator

Actually no. The line discipline does not describe HW, but just
how linux handles the device. It should not be part of DT at all.
The kernel will see compatible string for w2sg0004 and load the
correct line discipline.

> And if omap3 -> serial can directly control a regulator, it can
> easily be the w2sg0004 -> regulator

sure.

> > I am aware, that the Linux kernel has no such thing for serial
> > attached GPS devices, but that's Linux specific and irrelevant
> > for the DT description.
> > 
> >> The w2sg0004-regulator approach just follows this principle.
> >> Anyone willing to control the power of the w2sg0004 can use this
> >> regulator interface.
> > 
> > From a HW perspective your regulator "hides" the information, that
> > there is a device attached to the serial port and instead claims,
> > that a regulator is needed to make the serial port work.
> 
> Yes, without this regulator the serial port does not work. It is IMHO
> more important than stating the obvious that a serial device is
> connected to a serial port.

This is actually not correct though. The serial port does work
without the regulator. The remote side does not work without the
regulator. So the regulator should be referenced by the w2sg0004
node, so it would be

serial-port {
    w2sg0004 {
        w2sg_vdd: gpio-regulator { enable-gpio = <&some_gpio> };
        vdd-supply = <&w2sg_vdd>;
    }
}

And at this point you can simply drop the regulator stuff from DT,
since its device internal (and only adds complexity). For other
devices these kind of ressources are also not exposed in DT (e.g.
internal clocks).

> And if there is nothing to hide (the obvious serial interface
> wiring), why describe it at all?
> 
> Anyways, in my proposal there will be a subnode of the uart, the
> one where it is specified that it should control the regulator of the
> w2sg.
> 
> Basically, Neil’s proposal already covers this case. His bluetooth
> subnode just controls &vaux4 which turns on power for the w2cbw003
> chip.
> 
> So for my view it is not really understandable why one uart subnode
> can control a regulator, and the other can’t or shouldn’t and why
> this regulator function can’t be divided from the serial management
> into a regulator driver.
>
> > 
> > Apart from that this interface is limited in its features. I'm
> > currently working on N900's bluetooth chip. This one needs to set a
> > gpio before data is sent data to the chip, has a reset gpio and
> > a gpio to wakeup the OMAP SoC from idle states to avoid data loss
> > on the UART.
> 
> Yes, that looks equally complicated to solve if not even more than
> the w2sg chip.
> 
> But what would you prefer:
> 
> * extend the drivers/tty/slave/serial-power-manager.c to also cover your
>   special case

I would simply create a new slave driver, which takes care of the
gpios and setups the line discipline.

> * instantiate a drivers/misc/n900-bluetooth-regulator.c and hook it up
>   exactly like the vaux4 of the gta04 bluetooth chip? Just referencing
>   a different regulator node?

The gpios in the n900's case are definitely not regulators. They are
used for waking up a device, not for supplying them with energy.

> [...]

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

Hi!

>  here is version 3 of support for tty-slaves.
> 
>  This version introduces a new bus-type for tty-slaves, and causes
>  a tty-slave device to appear in /sys/devices between the uart and the
>  tty.
>  It effectively intercepts and calls from the tty to the uart (i.e. any
>  tty_operations) and applies extra functionality at that point.
> 
>  Currently the only driver intercepts open and close.
>  It powers on the device on open, and powers off at last-close.
> 
>  Power can be controlled by a regulator or by toggling a GPIO.
> 
>  I think I've incorporated most of the feed back I received from
>  previous versions, but if I missed something - I apologize.  If
>  this approach is structurally acceptable then I can fix up all the
>  smaller issues.

Do you have dts example? Anyway, we'll need something similar for
bluetooth on N900. But we'd like the /dev/ttyXX not to be visible to
the userspace in that case.

Thanks,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

Hi Neil,

On 03/18/2015 01:58 AM, NeilBrown wrote:
>  here is version 3 of support for tty-slaves.

Is there a v4 of this that I missed?

Regards,
Peter Hurley

Re: [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

Hi Neil,

On 03/18/2015 01:58 AM, NeilBrown wrote:
>  here is version 3 of support for tty-slaves.

Is there a v4 of this that I missed?

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] tty slave device support - version 3.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Tue, 05 May 2015 15:54:41 -0400 Peter Hurley <peter@hurleysoftware.com>
wrote:

> Hi Neil,
> 
> On 03/18/2015 01:58 AM, NeilBrown wrote:
> >  here is version 3 of support for tty-slaves.
> 
> Is there a v4 of this that I missed?
> 

No there isn't sorry.  This is part of a side-project that I get enthusiastic
about for a while, and then get distracted and lose interest :-)

However, getting this sort of query is a big help - I'll try to make a V4
within a week.

Thanks,
NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:

> Hi Neil,
> 
> On 03/18/2015 01:58 AM, NeilBrown wrote:
>> here is version 3 of support for tty-slaves.
> 
> Is there a v4 of this that I missed?

We did have a lengthy discussion about [PATCH 3/3] how to best (1)
represent the slave device in the device tree but as far as I am concerned,
I do not see that we have a consensus (2) and the device tree maintainers
have no comments or clear guidelines so far.

BR,
Nikolaus

(1) best with respect to maintainability, flexibility, common design patterns,
compatibility and some other factors I don’t know the correct english words for
(2) basically the slave can be described as a subnode like for I2C bus slaves
or the slave device can reference the uart it is connected to like for GPIOs
and regulators

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>:

> Hi Neil,
> 
> On 03/18/2015 01:58 AM, NeilBrown wrote:
>> here is version 3 of support for tty-slaves.
> 
> Is there a v4 of this that I missed?

We did have a lengthy discussion about [PATCH 3/3] how to best (1)
represent the slave device in the device tree but as far as I am concerned,
I do not see that we have a consensus (2) and the device tree maintainers
have no comments or clear guidelines so far.

BR,
Nikolaus

(1) best with respect to maintainability, flexibility, common design patterns,
compatibility and some other factors I don’t know the correct english words for
(2) basically the slave can be described as a subnode like for I2C bus slaves
or the slave device can reference the uart it is connected to like for GPIOs
and regulators--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
> Hi Peter,
> 
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
> > Hi Neil,
> > 
> > On 03/18/2015 01:58 AM, NeilBrown wrote:
> >> here is version 3 of support for tty-slaves.
> > 
> > Is there a v4 of this that I missed?
> 
> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> represent the slave device in the device tree but as far as I am concerned,
> I do not see that we have a consensus (2) and the device tree maintainers
> have no comments or clear guidelines so far.

Yes. Everyone and their dog disagrees with Nikolaus, who is playing
devil's advocate here, so we clearly have to get confirmation from
device tree maintainers. And when they disagree with him, we'll need
to get concensus from Linus, too...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
> Hi Peter,
> 
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>:
> 
> > Hi Neil,
> > 
> > On 03/18/2015 01:58 AM, NeilBrown wrote:
> >> here is version 3 of support for tty-slaves.
> > 
> > Is there a v4 of this that I missed?
> 
> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> represent the slave device in the device tree but as far as I am concerned,
> I do not see that we have a consensus (2) and the device tree maintainers
> have no comments or clear guidelines so far.

Yes. Everyone and their dog disagrees with Nikolaus, who is playing
devil's advocate here, so we clearly have to get confirmation from
device tree maintainers. And when they disagree with him, we'll need
to get concensus from Linus, too...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 06.05.2015 um 11:27 schrieb Pavel Machek <pavel@ucw.cz>:

> On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
>> Hi Peter,
>> 
>> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> Hi Neil,
>>> 
>>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>>> here is version 3 of support for tty-slaves.
>>> 
>>> Is there a v4 of this that I missed?
>> 
>> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
>> represent the slave device in the device tree but as far as I am concerned,
>> I do not see that we have a consensus (2) and the device tree maintainers
>> have no comments or clear guidelines so far.
> 
> Yes. Everyone and their dog disagrees

What a wonderful argument…
I still ask myself who the dog is.

> with Nikolaus, who is playing
> devil's advocate

I hope you don't think that Linux users are devils…

No, I am not playing devil’s advocate (which would imply that I am doing this
for fun to tease the dog), but I feel I have to be the advocate of future board
designers who want to easily import an existing board DT and overwrite device
tree nodes to describe design changes, i.e. what slave device is connected to
which uart.

At least in this regard, the alternatives are really differently easy to handle.

And, the alternatives have some influence how a tty driver and a slave device
driver is designed. So that is for me the root question, before discussing (some)
implementation details.

Because it is not resolved in a way that convinces me (and future board DT
designers), I bring it up again and again. Even if you and some dog apparently
disagree.

> here, so we clearly have to get confirmation from
> device tree maintainers. And when they disagree with him, we'll need
> to get concensus from Linus, too...
> 									Pavel

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 06.05.2015 um 11:27 schrieb Pavel Machek <pavel@ucw.cz>:

> On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
>> Hi Peter,
>> 
>> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> Hi Neil,
>>> 
>>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>>> here is version 3 of support for tty-slaves.
>>> 
>>> Is there a v4 of this that I missed?
>> 
>> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
>> represent the slave device in the device tree but as far as I am concerned,
>> I do not see that we have a consensus (2) and the device tree maintainers
>> have no comments or clear guidelines so far.
> 
> Yes. Everyone and their dog disagrees

What a wonderful argument…
I still ask myself who the dog is.

> with Nikolaus, who is playing
> devil's advocate

I hope you don't think that Linux users are devils…

No, I am not playing devil’s advocate (which would imply that I am doing this
for fun to tease the dog), but I feel I have to be the advocate of future board
designers who want to easily import an existing board DT and overwrite device
tree nodes to describe design changes, i.e. what slave device is connected to
which uart.

At least in this regard, the alternatives are really differently easy to handle.

And, the alternatives have some influence how a tty driver and a slave device
driver is designed. So that is for me the root question, before discussing (some)
implementation details.

Because it is not resolved in a way that convinces me (and future board DT
designers), I bring it up again and again. Even if you and some dog apparently
disagree.

> here, so we clearly have to get confirmation from
> device tree maintainers. And when they disagree with him, we'll need
> to get concensus from Linus, too...
> 									Pavel

BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
> No, I am not playing devil’s advocate (which would imply that I am doing this
> for fun to tease the dog), but I feel I have to be the advocate of future board
> designers who want to easily import an existing board DT and overwrite device
> tree nodes to describe design changes, i.e. what slave device is connected to
> which uart.

I dont' see a big distinction at the DTS source level, so your concern is wrt
binary dtbs?

> At least in this regard, the alternatives are really differently easy to handle.
> 
> And, the alternatives have some influence how a tty driver and a slave device
> driver is designed. So that is for me the root question, before discussing (some)
> implementation details.

I would expect _no_ impact on the tty driver; have I overlooked something?

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
> No, I am not playing devil’s advocate (which would imply that I am doing this
> for fun to tease the dog), but I feel I have to be the advocate of future board
> designers who want to easily import an existing board DT and overwrite device
> tree nodes to describe design changes, i.e. what slave device is connected to
> which uart.

I dont' see a big distinction at the DTS source level, so your concern is wrt
binary dtbs?

> At least in this regard, the alternatives are really differently easy to handle.
> 
> And, the alternatives have some influence how a tty driver and a slave device
> driver is designed. So that is for me the root question, before discussing (some)
> implementation details.

I would expect _no_ impact on the tty driver; have I overlooked something?

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 06.05.2015 um 14:05 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
>> No, I am not playing devil’s advocate (which would imply that I am doing this
>> for fun to tease the dog), but I feel I have to be the advocate of future board
>> designers who want to easily import an existing board DT and overwrite device
>> tree nodes to describe design changes, i.e. what slave device is connected to
>> which uart.
> 
> I dont' see a big distinction at the DTS source level, so your concern is wrt
> binary dtbs?

No. My concern is wrt including existing board files and making small modifications
on source level (or overlays).

We discuss:

board1.dts:

uart3 {	// subnode of some SoC
	slave {	// slave connected to uart3
		compatible = „…“;
		gpio = <&gpio5 12 0>
	};
};

vs.

board1.dts:

/ {
	slave {
		compatible = „…“;
		gpio = <&gpio5 12 0>
		uart = &uart3;	// slave connected to uart3
	};
};

uart3 {	// subnode of some SoC
};

now let’s have a spin of the board design which just rewires the
slave to uart4 (somtimes hardware engineers do such things).

board2.dts:

#include <board-variant1.dts>

// reconnect device to uart4

uart4 {	// subnode of some SoC
	slave {	// slave connected to uart4
		compatible = „…“;
		gpio = <&gpio5 12 0>
	};
};

uart3 {	// subnode of some SoC
	slave {	// slave connected to uart3
		compatible = „none“		// we can’t delete imported subnodes
	};
};

/// add another device to uart5?

uart5 {	// subnode of some SoC
	slave2 {	// slave connected to uart5
		compatible = „…“;
		gpio = <&gpio5 13 0>
	};
};


vs. 

board2.dts:

#include <board-variant1.dts>

// reconnect device to uart4

	&slave {
		uart = &uart3;
	};

// add another device to uart5?

	slave2 {
		compatible = „…“;
		gpio = <&gpio5 13 0>
		uart = &uart5;
	};

So the main difference is if the slave device tells to which uart it is connected
or the uart which slave device it is connected to.

And I think the second approach is easier and more straightforward (on DT level).

> 
>> At least in this regard, the alternatives are really differently easy to handle.
>> 
>> And, the alternatives have some influence how a tty driver and a slave device
>> driver is designed. So that is for me the root question, before discussing (some)
>> implementation details.
> 
> I would expect _no_ impact on the tty driver; have I overlooked something?

The way a tty driver finds the slave or the slave finds the tty driver instance.

In my proposal, the slave device has to look up the uart instance it is connected
to and must register itself as a power management client to get notifications. It
can also receive other notifications or change the line discipline to its needs.

In Neil’s original proposal the tty driver simply imposes some special power
management methods (control gpio or a regulator) over the slave driver which
does not encapsulate it’s power management methods.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 06.05.2015 um 14:05 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
>> No, I am not playing devil’s advocate (which would imply that I am doing this
>> for fun to tease the dog), but I feel I have to be the advocate of future board
>> designers who want to easily import an existing board DT and overwrite device
>> tree nodes to describe design changes, i.e. what slave device is connected to
>> which uart.
> 
> I dont' see a big distinction at the DTS source level, so your concern is wrt
> binary dtbs?

No. My concern is wrt including existing board files and making small modifications
on source level (or overlays).

We discuss:

board1.dts:

uart3 {	// subnode of some SoC
	slave {	// slave connected to uart3
		compatible = „…“;
		gpio = <&gpio5 12 0>
	};
};

vs.

board1.dts:

/ {
	slave {
		compatible = „…“;
		gpio = <&gpio5 12 0>
		uart = &uart3;	// slave connected to uart3
	};
};

uart3 {	// subnode of some SoC
};

now let’s have a spin of the board design which just rewires the
slave to uart4 (somtimes hardware engineers do such things).

board2.dts:

#include <board-variant1.dts>

// reconnect device to uart4

uart4 {	// subnode of some SoC
	slave {	// slave connected to uart4
		compatible = „…“;
		gpio = <&gpio5 12 0>
	};
};

uart3 {	// subnode of some SoC
	slave {	// slave connected to uart3
		compatible = „none“		// we can’t delete imported subnodes
	};
};

/// add another device to uart5?

uart5 {	// subnode of some SoC
	slave2 {	// slave connected to uart5
		compatible = „…“;
		gpio = <&gpio5 13 0>
	};
};


vs. 

board2.dts:

#include <board-variant1.dts>

// reconnect device to uart4

	&slave {
		uart = &uart3;
	};

// add another device to uart5?

	slave2 {
		compatible = „…“;
		gpio = <&gpio5 13 0>
		uart = &uart5;
	};

So the main difference is if the slave device tells to which uart it is connected
or the uart which slave device it is connected to.

And I think the second approach is easier and more straightforward (on DT level).

> 
>> At least in this regard, the alternatives are really differently easy to handle.
>> 
>> And, the alternatives have some influence how a tty driver and a slave device
>> driver is designed. So that is for me the root question, before discussing (some)
>> implementation details.
> 
> I would expect _no_ impact on the tty driver; have I overlooked something?

The way a tty driver finds the slave or the slave finds the tty driver instance.

In my proposal, the slave device has to look up the uart instance it is connected
to and must register itself as a power management client to get notifications. It
can also receive other notifications or change the line discipline to its needs.

In Neil’s original proposal the tty driver simply imposes some special power
management methods (control gpio or a regulator) over the slave driver which
does not encapsulate it’s power management methods.

BR,
Nikolaus--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Mark Rutland]

On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
> Hi Peter,
> 
> Am 06.05.2015 um 14:05 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
> > On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
> >> No, I am not playing devil’s advocate (which would imply that I am doing this
> >> for fun to tease the dog), but I feel I have to be the advocate of future board
> >> designers who want to easily import an existing board DT and overwrite device
> >> tree nodes to describe design changes, i.e. what slave device is connected to
> >> which uart.
> > 
> > I dont' see a big distinction at the DTS source level, so your concern is wrt
> > binary dtbs?
> 
> No. My concern is wrt including existing board files and making small modifications
> on source level (or overlays).
> 
> We discuss:
> 
> board1.dts:
> 
> uart3 {	// subnode of some SoC
> 	slave {	// slave connected to uart3
> 		compatible = „…“;
> 		gpio = <&gpio5 12 0>
> 	};
> };
> 
> vs.
> 
> board1.dts:
> 
> / {
> 	slave {
> 		compatible = „…“;
> 		gpio = <&gpio5 12 0>
> 		uart = &uart3;	// slave connected to uart3
> 	};
> };
> 
> uart3 {	// subnode of some SoC
> };
> 
> now let’s have a spin of the board design which just rewires the
> slave to uart4 (somtimes hardware engineers do such things).
> 
> board2.dts:
> 
> #include <board-variant1.dts>
> 
> // reconnect device to uart4
> 
> uart4 {	// subnode of some SoC
> 	slave {	// slave connected to uart4
> 		compatible = „…“;
> 		gpio = <&gpio5 12 0>
> 	};
> };
> 
> uart3 {	// subnode of some SoC
> 	slave {	// slave connected to uart3
> 		compatible = „none“		// we can’t delete imported subnodes
> 	};
> };
> 
> /// add another device to uart5?
> 
> uart5 {	// subnode of some SoC
> 	slave2 {	// slave connected to uart5
> 		compatible = „…“;
> 		gpio = <&gpio5 13 0>
> 	};
> };

If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.

If you have a large amount of variation within a given platform, that is
a problem with your platform.

> So the main difference is if the slave device tells to which uart it is connected
> or the uart which slave device it is connected to.
> 
> And I think the second approach is easier and more straightforward (on DT level).

We already place child nodes under their respective busses for other
interfaces like SPI and I2C. I do not see a compelling reason to do
otherwise for devices hanging off of UARTs -- doing so would make things
less straightforward because you have a fundamentally different idiom.

Having the slave live under the UART node also gives you sane probe
ordering -- you must probe the parent before the slave as the parent
driver (perhaps via common code) will trigger the scan of children.

Mark.

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Mark Rutland]

On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
> Hi Peter,
> 
> Am 06.05.2015 um 14:05 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
> > On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
> >> No, I am not playing devil’s advocate (which would imply that I am doing this
> >> for fun to tease the dog), but I feel I have to be the advocate of future board
> >> designers who want to easily import an existing board DT and overwrite device
> >> tree nodes to describe design changes, i.e. what slave device is connected to
> >> which uart.
> > 
> > I dont' see a big distinction at the DTS source level, so your concern is wrt
> > binary dtbs?
> 
> No. My concern is wrt including existing board files and making small modifications
> on source level (or overlays).
> 
> We discuss:
> 
> board1.dts:
> 
> uart3 {	// subnode of some SoC
> 	slave {	// slave connected to uart3
> 		compatible = „…“;
> 		gpio = <&gpio5 12 0>
> 	};
> };
> 
> vs.
> 
> board1.dts:
> 
> / {
> 	slave {
> 		compatible = „…“;
> 		gpio = <&gpio5 12 0>
> 		uart = &uart3;	// slave connected to uart3
> 	};
> };
> 
> uart3 {	// subnode of some SoC
> };
> 
> now let’s have a spin of the board design which just rewires the
> slave to uart4 (somtimes hardware engineers do such things).
> 
> board2.dts:
> 
> #include <board-variant1.dts>
> 
> // reconnect device to uart4
> 
> uart4 {	// subnode of some SoC
> 	slave {	// slave connected to uart4
> 		compatible = „…“;
> 		gpio = <&gpio5 12 0>
> 	};
> };
> 
> uart3 {	// subnode of some SoC
> 	slave {	// slave connected to uart3
> 		compatible = „none“		// we can’t delete imported subnodes
> 	};
> };
> 
> /// add another device to uart5?
> 
> uart5 {	// subnode of some SoC
> 	slave2 {	// slave connected to uart5
> 		compatible = „…“;
> 		gpio = <&gpio5 13 0>
> 	};
> };

If this happens, you can move the slave device into a fragment that you
can include under the correct node. That's trivial.

If you have a large amount of variation within a given platform, that is
a problem with your platform.

> So the main difference is if the slave device tells to which uart it is connected
> or the uart which slave device it is connected to.
> 
> And I think the second approach is easier and more straightforward (on DT level).

We already place child nodes under their respective busses for other
interfaces like SPI and I2C. I do not see a compelling reason to do
otherwise for devices hanging off of UARTs -- doing so would make things
less straightforward because you have a fundamentally different idiom.

Having the slave live under the UART node also gives you sane probe
ordering -- you must probe the parent before the slave as the parent
driver (perhaps via common code) will trigger the scan of children.

Mark.

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Mark,

Am 06.05.2015 um 14:36 schrieb Mark Rutland <mark.rutland@arm.com>:

> On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Peter,
>> 
>> Am 06.05.2015 um 14:05 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>> designers who want to easily import an existing board DT and overwrite device
>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>> which uart.
>>> 
>>> I dont' see a big distinction at the DTS source level, so your concern is wrt
>>> binary dtbs?
>> 
>> No. My concern is wrt including existing board files and making small modifications
>> on source level (or overlays).
>> 
>> We discuss:
>> 
>> board1.dts:
>> 
>> uart3 {	// subnode of some SoC
>> 	slave {	// slave connected to uart3
>> 		compatible = „…“;
>> 		gpio = <&gpio5 12 0>
>> 	};
>> };
>> 
>> vs.
>> 
>> board1.dts:
>> 
>> / {
>> 	slave {
>> 		compatible = „…“;
>> 		gpio = <&gpio5 12 0>
>> 		uart = &uart3;	// slave connected to uart3
>> 	};
>> };
>> 
>> uart3 {	// subnode of some SoC
>> };
>> 
>> now let’s have a spin of the board design which just rewires the
>> slave to uart4 (somtimes hardware engineers do such things).
>> 
>> board2.dts:
>> 
>> #include <board-variant1.dts>
>> 
>> // reconnect device to uart4
>> 
>> uart4 {	// subnode of some SoC
>> 	slave {	// slave connected to uart4
>> 		compatible = „…“;
>> 		gpio = <&gpio5 12 0>
>> 	};
>> };
>> 
>> uart3 {	// subnode of some SoC
>> 	slave {	// slave connected to uart3
>> 		compatible = „none“		// we can’t delete imported subnodes
>> 	};
>> };
>> 
>> /// add another device to uart5?
>> 
>> uart5 {	// subnode of some SoC
>> 	slave2 {	// slave connected to uart5
>> 		compatible = „…“;
>> 		gpio = <&gpio5 13 0>
>> 	};
>> };
> 
> If this happens, you can move the slave device into a fragment that you
> can include under the correct node. That's trivial.

But less readable. And that is important as well.

> 
> If you have a large amount of variation within a given platform, that is
> a problem with your platform.

Agreed.

> 
>> So the main difference is if the slave device tells to which uart it is connected
>> or the uart which slave device it is connected to.
>> 
>> And I think the second approach is easier and more straightforward (on DT level).
> 
> We already place child nodes under their respective busses

I still wonder why UART is considered as a bus?

For me it is a point-to-point interface, and not a bus.
I assume that a majority of engineers outside of our discussion tend to agree.

[random pick: http://www.avrfreaks.net/comment/473738#comment-473738
"So basically, UART is not a bus. If you really want to connect N devices together,
use I2C maybe, it too has two wires and anyone can be master.“]

Even some ISO standards define a „bus“ as something with addressable clients
(and UART has no addresses since it has no protocol by itself).

> for other
> interfaces like SPI and I2C. I do not see a compelling reason to do
> otherwise for devices

why the plural? Is there a practical example where multiple devices are
connected to a single UART and how is addressing solved?

> hanging off of UARTs -- doing so would make things
> less straightforward because you have a fundamentally different idiom.

Yes, my proposal is fundamentally different from I2C and SPI practice, but
it is the same that is heavily used for e.g. GPIOs and Regulators.

So it is not at all a „different“ idiom. Just one that IMHO better fits for
point-to-point connections (like power distribution or GPIOs). Therefore
I have a reason to use a different idiom for a technically different
task.

> 
> Having the slave live under the UART node also gives you sane probe
> ordering -- you must probe the parent before the slave as the parent
> driver (perhaps via common code) will trigger the scan of children.

This is a good and interesting argument in favour of the subnodes approach.

I know there was (is?) a problem with GPIO controllers not probed before
they are referenced. That made some problems for OMAP around release
3.14. But AFAIK it is solved now (don’t know the details how it is solved).

Anyways, I wonder why probing and probe order should be implicitly reflected
by the DT? If DT is really a hardware description (and not a tool for kernel code
optimisation), then it should not matter and other aspects should have a higher
priority. E.g. which information is to be provided by the slave node and which
by the uart node.

The key point appears to be how we want to see the serial connection. Is the
device connected to the uart or the uart to a device?

In OO terminology: „device connects to uart“ vs. „uart has device connected“.
"d -> u“ vs. "u <- d“.

For a bus like I2C or SPI it is „controller has device connected“ but for a good
reason (somehow the address must be specified - and addressing belongs to
the master side).

>From my DT designer PoV I would say the UART exists in some SoC
(independently of a device being connected) and then, a device is connected
to the UART. Hence the proposal of adding this connection link to the device’s
node and not making the device a subnode. And having the device driver do
power management and only ask the uart/tty driver to be notified about open()
and close() events. How power is managed in detail is then not any part of the
tty/serial drivers.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Mark,

Am 06.05.2015 um 14:36 schrieb Mark Rutland <mark.rutland@arm.com>:

> On Wed, May 06, 2015 at 01:27:03PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Peter,
>> 
>> Am 06.05.2015 um 14:05 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> On 05/06/2015 07:50 AM, Dr. H. Nikolaus Schaller wrote:
>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>> designers who want to easily import an existing board DT and overwrite device
>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>> which uart.
>>> 
>>> I dont' see a big distinction at the DTS source level, so your concern is wrt
>>> binary dtbs?
>> 
>> No. My concern is wrt including existing board files and making small modifications
>> on source level (or overlays).
>> 
>> We discuss:
>> 
>> board1.dts:
>> 
>> uart3 {	// subnode of some SoC
>> 	slave {	// slave connected to uart3
>> 		compatible = „…“;
>> 		gpio = <&gpio5 12 0>
>> 	};
>> };
>> 
>> vs.
>> 
>> board1.dts:
>> 
>> / {
>> 	slave {
>> 		compatible = „…“;
>> 		gpio = <&gpio5 12 0>
>> 		uart = &uart3;	// slave connected to uart3
>> 	};
>> };
>> 
>> uart3 {	// subnode of some SoC
>> };
>> 
>> now let’s have a spin of the board design which just rewires the
>> slave to uart4 (somtimes hardware engineers do such things).
>> 
>> board2.dts:
>> 
>> #include <board-variant1.dts>
>> 
>> // reconnect device to uart4
>> 
>> uart4 {	// subnode of some SoC
>> 	slave {	// slave connected to uart4
>> 		compatible = „…“;
>> 		gpio = <&gpio5 12 0>
>> 	};
>> };
>> 
>> uart3 {	// subnode of some SoC
>> 	slave {	// slave connected to uart3
>> 		compatible = „none“		// we can’t delete imported subnodes
>> 	};
>> };
>> 
>> /// add another device to uart5?
>> 
>> uart5 {	// subnode of some SoC
>> 	slave2 {	// slave connected to uart5
>> 		compatible = „…“;
>> 		gpio = <&gpio5 13 0>
>> 	};
>> };
> 
> If this happens, you can move the slave device into a fragment that you
> can include under the correct node. That's trivial.

But less readable. And that is important as well.

> 
> If you have a large amount of variation within a given platform, that is
> a problem with your platform.

Agreed.

> 
>> So the main difference is if the slave device tells to which uart it is connected
>> or the uart which slave device it is connected to.
>> 
>> And I think the second approach is easier and more straightforward (on DT level).
> 
> We already place child nodes under their respective busses

I still wonder why UART is considered as a bus?

For me it is a point-to-point interface, and not a bus.
I assume that a majority of engineers outside of our discussion tend to agree.

[random pick: http://www.avrfreaks.net/comment/473738#comment-473738
"So basically, UART is not a bus. If you really want to connect N devices together,
use I2C maybe, it too has two wires and anyone can be master.“]

Even some ISO standards define a „bus“ as something with addressable clients
(and UART has no addresses since it has no protocol by itself).

> for other
> interfaces like SPI and I2C. I do not see a compelling reason to do
> otherwise for devices

why the plural? Is there a practical example where multiple devices are
connected to a single UART and how is addressing solved?

> hanging off of UARTs -- doing so would make things
> less straightforward because you have a fundamentally different idiom.

Yes, my proposal is fundamentally different from I2C and SPI practice, but
it is the same that is heavily used for e.g. GPIOs and Regulators.

So it is not at all a „different“ idiom. Just one that IMHO better fits for
point-to-point connections (like power distribution or GPIOs). Therefore
I have a reason to use a different idiom for a technically different
task.

> 
> Having the slave live under the UART node also gives you sane probe
> ordering -- you must probe the parent before the slave as the parent
> driver (perhaps via common code) will trigger the scan of children.

This is a good and interesting argument in favour of the subnodes approach.

I know there was (is?) a problem with GPIO controllers not probed before
they are referenced. That made some problems for OMAP around release
3.14. But AFAIK it is solved now (don’t know the details how it is solved).

Anyways, I wonder why probing and probe order should be implicitly reflected
by the DT? If DT is really a hardware description (and not a tool for kernel code
optimisation), then it should not matter and other aspects should have a higher
priority. E.g. which information is to be provided by the slave node and which
by the uart node.

The key point appears to be how we want to see the serial connection. Is the
device connected to the uart or the uart to a device?

In OO terminology: „device connects to uart“ vs. „uart has device connected“.
"d -> u“ vs. "u <- d“.

For a bus like I2C or SPI it is „controller has device connected“ but for a good
reason (somehow the address must be specified - and addressing belongs to
the master side).

From my DT designer PoV I would say the UART exists in some SoC
(independently of a device being connected) and then, a device is connected
to the UART. Hence the proposal of adding this connection link to the device’s
node and not making the device a subnode. And having the device driver do
power management and only ask the uart/tty driver to be notified about open()
and close() events. How power is managed in detail is then not any part of the
tty/serial drivers.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Mark Rutland]

> >>>> No, I am not playing devil’s advocate (which would imply that I am doing this
> >>>> for fun to tease the dog), but I feel I have to be the advocate of future board
> >>>> designers who want to easily import an existing board DT and overwrite device
> >>>> tree nodes to describe design changes, i.e. what slave device is connected to
> >>>> which uart.

[...]

> > If this happens, you can move the slave device into a fragment that you
> > can include under the correct node. That's trivial.
> 
> But less readable. And that is important as well.

I disagree. The manipulation you have to perform to override properties
is at least as bad as including a file.

> >> So the main difference is if the slave device tells to which uart it is connected
> >> or the uart which slave device it is connected to.
> >> 
> >> And I think the second approach is easier and more straightforward (on DT level).
> > 
> > We already place child nodes under their respective busses
> 
> I still wonder why UART is considered as a bus?

As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
connection between master (UART) and slave (device), and it happens that
in most other cases the master is actually a bus, so that's how things
happen to be named.

> > for other
> > interfaces like SPI and I2C. I do not see a compelling reason to do
> > otherwise for devices
> 
> why the plural? Is there a practical example where multiple devices are
> connected to a single UART and how is addressing solved?

I'm talking about UART slaves in abstract rather than multiple slaves
attached to the same UART.

> > hanging off of UARTs -- doing so would make things
> > less straightforward because you have a fundamentally different idiom.
> 
> Yes, my proposal is fundamentally different from I2C and SPI practice, but
> it is the same that is heavily used for e.g. GPIOs and Regulators.

Well, those cases are somewhat distinct, and I'd say that UART slaves
are much closer to SPI/I2C devices than GPIOs or regulators.

Let's say I have a GPIO described via a phandle. That GPIO is actually
owned by some GPIO controller whose control interface is sat on an MMIO
bus. What we're describing with the phandle is use of the GPIO, but not
the main interface for interactive with the GPIO, which is the MMIO
interface of the controller.

In the case of UART slave devices the control interface is attached to
the UART, and effectively the slave sits on the UART's "bus". We could
refer to it from elsewhere by phandle, but its canonical parent should
be the UART, as that's what its main interface is attached to.

> From my DT designer PoV I would say the UART exists in some SoC
> (independently of a device being connected) and then, a device is connected
> to the UART. Hence the proposal of adding this connection link to the device’s
> node and not making the device a subnode. And having the device driver do
> power management and only ask the uart/tty driver to be notified about open()
> and close() events. How power is managed in detail is then not any part of the
> tty/serial drivers.

The way that the power management interfaces are organised within Linux
is orthogonal to the way we describe things in the DT.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Mark Rutland]

> >>>> No, I am not playing devil’s advocate (which would imply that I am doing this
> >>>> for fun to tease the dog), but I feel I have to be the advocate of future board
> >>>> designers who want to easily import an existing board DT and overwrite device
> >>>> tree nodes to describe design changes, i.e. what slave device is connected to
> >>>> which uart.

[...]

> > If this happens, you can move the slave device into a fragment that you
> > can include under the correct node. That's trivial.
> 
> But less readable. And that is important as well.

I disagree. The manipulation you have to perform to override properties
is at least as bad as including a file.

> >> So the main difference is if the slave device tells to which uart it is connected
> >> or the uart which slave device it is connected to.
> >> 
> >> And I think the second approach is easier and more straightforward (on DT level).
> > 
> > We already place child nodes under their respective busses
> 
> I still wonder why UART is considered as a bus?

As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
connection between master (UART) and slave (device), and it happens that
in most other cases the master is actually a bus, so that's how things
happen to be named.

> > for other
> > interfaces like SPI and I2C. I do not see a compelling reason to do
> > otherwise for devices
> 
> why the plural? Is there a practical example where multiple devices are
> connected to a single UART and how is addressing solved?

I'm talking about UART slaves in abstract rather than multiple slaves
attached to the same UART.

> > hanging off of UARTs -- doing so would make things
> > less straightforward because you have a fundamentally different idiom.
> 
> Yes, my proposal is fundamentally different from I2C and SPI practice, but
> it is the same that is heavily used for e.g. GPIOs and Regulators.

Well, those cases are somewhat distinct, and I'd say that UART slaves
are much closer to SPI/I2C devices than GPIOs or regulators.

Let's say I have a GPIO described via a phandle. That GPIO is actually
owned by some GPIO controller whose control interface is sat on an MMIO
bus. What we're describing with the phandle is use of the GPIO, but not
the main interface for interactive with the GPIO, which is the MMIO
interface of the controller.

In the case of UART slave devices the control interface is attached to
the UART, and effectively the slave sits on the UART's "bus". We could
refer to it from elsewhere by phandle, but its canonical parent should
be the UART, as that's what its main interface is attached to.

> From my DT designer PoV I would say the UART exists in some SoC
> (independently of a device being connected) and then, a device is connected
> to the UART. Hence the proposal of adding this connection link to the device’s
> node and not making the device a subnode. And having the device driver do
> power management and only ask the uart/tty driver to be notified about open()
> and close() events. How power is managed in detail is then not any part of the
> tty/serial drivers.

The way that the power management interfaces are organised within Linux
is orthogonal to the way we describe things in the DT.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Mark,

Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:

>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>> which uart.
> 
> [...]
> 
>>> If this happens, you can move the slave device into a fragment that you
>>> can include under the correct node. That's trivial.
>> 
>> But less readable. And that is important as well.
> 
> I disagree. The manipulation you have to perform to override properties
> is at least as bad as including a file.

What about:

#include "omap3-beagle-xm.dts"

/ {
	/* HS USB Port 2 Power enable was inverted with the xM C */
	hsusb2_power: hsusb2_power_reg {
		enable-active-high;
	};
};

compared to 

#include “board1.dts”

/ {
	/* slave was reconnected to uart4 */
	slave {
		uart = <&uart4>;
	};
};

> 
>>>> So the main difference is if the slave device tells to which uart it is connected
>>>> or the uart which slave device it is connected to.
>>>> 
>>>> And I think the second approach is easier and more straightforward (on DT level).
>>> 
>>> We already place child nodes under their respective busses
>> 
>> I still wonder why UART is considered as a bus?
> 
> As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
> connection between master (UART) and slave (device), and it happens that
> in most other cases the master is actually a bus, so that's how things
> happen to be named.

So you also mean that all master-slave connections must be represented
by DT subnodes and everything else is not acceptable?

What about:

	sound {
		compatible = "ti,omap-twl4030";
		ti,model = "omap3beagle";

		ti,mcbsp = <&mcbsp2>;
	};

Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the “twl4030”
is the slave (codec)?

&usb_otg_hs {
	interface-type = <0>;
	usb-phy = <&usb2_phy>;
	phys = <&usb2_phy>;
	phy-names = "usb2-phy";
	mode = <3>;
	power = <50>;
};

Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI “bus” as well?

At least in this two areas everything done so far appears to contradict your argument.

This is for me the blueprint how it should be done for UART slaves like any point-to-point
multi-wire interfaces (question not even discussed: does UART-to-UART have clear master
and slave roles? Isn’t the connected device the “master”? but I don’t want to broaden the
discussion again).

This is basically why I keep this discussion open, because it is not that obvious
that Neil’s proposal is right and mine is wrong.

> 
>>> for other
>>> interfaces like SPI and I2C. I do not see a compelling reason to do
>>> otherwise for devices
>> 
>> why the plural? Is there a practical example where multiple devices are
>> connected to a single UART and how is addressing solved?
> 
> I'm talking about UART slaves in abstract rather than multiple slaves
> attached to the same UART.

Ok, I did misunderstand. Thanks.

> 
>>> hanging off of UARTs -- doing so would make things
>>> less straightforward because you have a fundamentally different idiom.
>> 
>> Yes, my proposal is fundamentally different from I2C and SPI practice, but
>> it is the same that is heavily used for e.g. GPIOs and Regulators.
> 
> Well, those cases are somewhat distinct, and I'd say that UART slaves
> are much closer to SPI/I2C devices than GPIOs or regulators.

As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
other interfaces).

> 
> Let's say I have a GPIO described via a phandle. That GPIO is actually
> owned by some GPIO controller whose control interface is sat on an MMIO
> bus. What we're describing with the phandle is use of the GPIO, but not
> the main interface for interactive with the GPIO, which is the MMIO
> interface of the controller.

Right. For the UART we do the same: the UART controller is connected
to the MMIO and (in my proposal) the phandle describes the use of the UART
(to connect to some slave device). Exactly the same situation.

> 
> In the case of UART slave devices the control interface is attached to
> the UART, and effectively the slave sits on the UART's "bus". We could
> refer to it from elsewhere by phandle, but its canonical parent should
> be the UART, as that’s what its main interface is attached to.

What is the “main interface” of some device? Why should it have a special
role in DT? I have doubts that it is useful to declare some interface as “main”,
unless it is a MMIO bus connection.

There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C busses, 2 PCM
“busses”, an ULIP-PHY and some GPIOs. Or some 3G/4G modems which have
USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.
Which interface is “main”? For the twl4030 it happens that one of the I2C interfaces
is chosen (because it allows to access the registers inside the chip).

Now you might say: yes, the registers of some uart connected device can
be accessed through the uart as well. But usually there is a higher level
protocol (AT commands) that give some sort of “register addressing”. But
that is a different level than using I2C to access e.g. the gpio controller in the twl4030.

I just want to say that requiring and focussing on a “main” interface of a peripheral
chip may lead to troubles.

> 
>> From my DT designer PoV I would say the UART exists in some SoC
>> (independently of a device being connected) and then, a device is connected
>> to the UART. Hence the proposal of adding this connection link to the device’s
>> node and not making the device a subnode. And having the device driver do
>> power management and only ask the uart/tty driver to be notified about open()
>> and close() events. How power is managed in detail is then not any part of the
>> tty/serial drivers.
> 
> The way that the power management interfaces are organised within Linux
> is orthogonal to the way we describe things in the DT.

Agreed. And therefore power management registration, notifications etc.
are to be hidden by the drivers and should not be an argument to say “with
subnodes it is easier to implement and probing is done in the right order”.


I think I have laid down all arguments why I think my proposal is superior.

So unless there are still questions for understanding details of my PoV, it is
IMHO up for a decision.

May it be wise and future-proof.

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Mark,

Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:

>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>> which uart.
> 
> [...]
> 
>>> If this happens, you can move the slave device into a fragment that you
>>> can include under the correct node. That's trivial.
>> 
>> But less readable. And that is important as well.
> 
> I disagree. The manipulation you have to perform to override properties
> is at least as bad as including a file.

What about:

#include "omap3-beagle-xm.dts"

/ {
	/* HS USB Port 2 Power enable was inverted with the xM C */
	hsusb2_power: hsusb2_power_reg {
		enable-active-high;
	};
};

compared to 

#include “board1.dts”

/ {
	/* slave was reconnected to uart4 */
	slave {
		uart = <&uart4>;
	};
};

> 
>>>> So the main difference is if the slave device tells to which uart it is connected
>>>> or the uart which slave device it is connected to.
>>>> 
>>>> And I think the second approach is easier and more straightforward (on DT level).
>>> 
>>> We already place child nodes under their respective busses
>> 
>> I still wonder why UART is considered as a bus?
> 
> As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
> connection between master (UART) and slave (device), and it happens that
> in most other cases the master is actually a bus, so that's how things
> happen to be named.

So you also mean that all master-slave connections must be represented
by DT subnodes and everything else is not acceptable?

What about:

	sound {
		compatible = "ti,omap-twl4030";
		ti,model = "omap3beagle";

		ti,mcbsp = <&mcbsp2>;
	};

Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the “twl4030”
is the slave (codec)?

&usb_otg_hs {
	interface-type = <0>;
	usb-phy = <&usb2_phy>;
	phys = <&usb2_phy>;
	phy-names = "usb2-phy";
	mode = <3>;
	power = <50>;
};

Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI “bus” as well?

At least in this two areas everything done so far appears to contradict your argument.

This is for me the blueprint how it should be done for UART slaves like any point-to-point
multi-wire interfaces (question not even discussed: does UART-to-UART have clear master
and slave roles? Isn’t the connected device the “master”? but I don’t want to broaden the
discussion again).

This is basically why I keep this discussion open, because it is not that obvious
that Neil’s proposal is right and mine is wrong.

> 
>>> for other
>>> interfaces like SPI and I2C. I do not see a compelling reason to do
>>> otherwise for devices
>> 
>> why the plural? Is there a practical example where multiple devices are
>> connected to a single UART and how is addressing solved?
> 
> I'm talking about UART slaves in abstract rather than multiple slaves
> attached to the same UART.

Ok, I did misunderstand. Thanks.

> 
>>> hanging off of UARTs -- doing so would make things
>>> less straightforward because you have a fundamentally different idiom.
>> 
>> Yes, my proposal is fundamentally different from I2C and SPI practice, but
>> it is the same that is heavily used for e.g. GPIOs and Regulators.
> 
> Well, those cases are somewhat distinct, and I'd say that UART slaves
> are much closer to SPI/I2C devices than GPIOs or regulators.

As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
other interfaces).

> 
> Let's say I have a GPIO described via a phandle. That GPIO is actually
> owned by some GPIO controller whose control interface is sat on an MMIO
> bus. What we're describing with the phandle is use of the GPIO, but not
> the main interface for interactive with the GPIO, which is the MMIO
> interface of the controller.

Right. For the UART we do the same: the UART controller is connected
to the MMIO and (in my proposal) the phandle describes the use of the UART
(to connect to some slave device). Exactly the same situation.

> 
> In the case of UART slave devices the control interface is attached to
> the UART, and effectively the slave sits on the UART's "bus". We could
> refer to it from elsewhere by phandle, but its canonical parent should
> be the UART, as that’s what its main interface is attached to.

What is the “main interface” of some device? Why should it have a special
role in DT? I have doubts that it is useful to declare some interface as “main”,
unless it is a MMIO bus connection.

There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C busses, 2 PCM
“busses”, an ULIP-PHY and some GPIOs. Or some 3G/4G modems which have
USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.
Which interface is “main”? For the twl4030 it happens that one of the I2C interfaces
is chosen (because it allows to access the registers inside the chip).

Now you might say: yes, the registers of some uart connected device can
be accessed through the uart as well. But usually there is a higher level
protocol (AT commands) that give some sort of “register addressing”. But
that is a different level than using I2C to access e.g. the gpio controller in the twl4030.

I just want to say that requiring and focussing on a “main” interface of a peripheral
chip may lead to troubles.

> 
>> From my DT designer PoV I would say the UART exists in some SoC
>> (independently of a device being connected) and then, a device is connected
>> to the UART. Hence the proposal of adding this connection link to the device’s
>> node and not making the device a subnode. And having the device driver do
>> power management and only ask the uart/tty driver to be notified about open()
>> and close() events. How power is managed in detail is then not any part of the
>> tty/serial drivers.
> 
> The way that the power management interfaces are organised within Linux
> is orthogonal to the way we describe things in the DT.

Agreed. And therefore power management registration, notifications etc.
are to be hidden by the drivers and should not be an argument to say “with
subnodes it is easier to implement and probing is done in the right order”.


I think I have laid down all arguments why I think my proposal is superior.

So unless there are still questions for understanding details of my PoV, it is
IMHO up for a decision.

May it be wise and future-proof.

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Mark Rutland]

On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
> Hi Mark,
> 
> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
> 
> >>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
> >>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
> >>>>>> designers who want to easily import an existing board DT and overwrite device
> >>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
> >>>>>> which uart.
> > 
> > [...]
> > 
> >>> If this happens, you can move the slave device into a fragment that you
> >>> can include under the correct node. That's trivial.
> >> 
> >> But less readable. And that is important as well.
> > 
> > I disagree. The manipulation you have to perform to override properties
> > is at least as bad as including a file.
> 
> What about:
> 
> #include "omap3-beagle-xm.dts"
> 
> / {
> 	/* HS USB Port 2 Power enable was inverted with the xM C */
> 	hsusb2_power: hsusb2_power_reg {
> 		enable-active-high;
> 	};
> };
> 
> compared to 
> 
> #include “board1.dts”
> 
> / {
> 	/* slave was reconnected to uart4 */
> 	slave {
> 		uart = <&uart4>;
> 	};
> };

As I mentioned, you can easily carve up your DTS to make that work with
includes if you really must:

/* UART0 board variant */
#include "board.dtsi"
&uart0 {
	#include "some-uart-slave.dtsi"
};

/* UART1 board variant */
#include "board.dtsi"
&uart1 {
	#include "some-uart-slave.dtsi"
};

If you happen to find includes ugly then you can say it's ugly, but it's
functionally equivalent, and also means you can avoid having
disabled/partial nodes all over the place.

If you really wanted you could macro the label instead and have the
slaved node in full.

[...]

> > As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
> > connection between master (UART) and slave (device), and it happens that
> > in most other cases the master is actually a bus, so that's how things
> > happen to be named.
> 
> So you also mean that all master-slave connections must be represented
> by DT subnodes and everything else is not acceptable?
> 
> What about:
> 
> 	sound {
> 		compatible = "ti,omap-twl4030";
> 		ti,model = "omap3beagle";
> 
> 		ti,mcbsp = <&mcbsp2>;
> 	};
> 
> Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the “twl4030”
> is the slave (codec)?

I'm nowhere near familiar enough with the audio hardware nor their
bindings to comment on that, I'm afraid. My rough understanding was that
the twl4030 node here was referring to the logical subsystem as a whole,
with the mcbsp being a physical component, but that's almost certainly
somewhat wrong.

> &usb_otg_hs {
> 	interface-type = <0>;
> 	usb-phy = <&usb2_phy>;
> 	phys = <&usb2_phy>;
> 	phy-names = "usb2-phy";
> 	mode = <3>;
> 	power = <50>;
> };
> 
> Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI “bus” as well?

Not necessarily. If you took a look at the bindings you'd notice that
many PHYs have MMIO interfaces for configuration which we have to poke.
Those MMIO interfaces live on an MMIO bus so we describe those and link
to the phy by phandle reference.

A given device could operate as a PHY to multiple controllers, hence
phy-cells, and hence in general a PHY cannot be considered a slave
device.

> At least in this two areas everything done so far appears to contradict your argument.

Not really. You've found bindings with a different idiom, but those seem
to be organised as they are for reasons which don't appear to apply to
UART slave devices as you describe them.

> This is for me the blueprint how it should be done for UART slaves like any point-to-point
> multi-wire interfaces (question not even discussed: does UART-to-UART have clear master
> and slave roles? Isn’t the connected device the “master”? but I don’t want to broaden the
> discussion again).
> 
> This is basically why I keep this discussion open, because it is not that obvious
> that Neil’s proposal is right and mine is wrong.
> 
> > 
> >>> for other
> >>> interfaces like SPI and I2C. I do not see a compelling reason to do
> >>> otherwise for devices

[...]

> >>> hanging off of UARTs -- doing so would make things
> >>> less straightforward because you have a fundamentally different idiom.
> >> 
> >> Yes, my proposal is fundamentally different from I2C and SPI practice, but
> >> it is the same that is heavily used for e.g. GPIOs and Regulators.
> > 
> > Well, those cases are somewhat distinct, and I'd say that UART slaves
> > are much closer to SPI/I2C devices than GPIOs or regulators.
> 
> As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
> other interfaces).

As above, I disagree.

> > Let's say I have a GPIO described via a phandle. That GPIO is actually
> > owned by some GPIO controller whose control interface is sat on an MMIO
> > bus. What we're describing with the phandle is use of the GPIO, but not
> > the main interface for interactive with the GPIO, which is the MMIO
> > interface of the controller.
> 
> Right. For the UART we do the same: the UART controller is connected
> to the MMIO and (in my proposal) the phandle describes the use of the UART
> (to connect to some slave device). Exactly the same situation.

Except that your fundamental interface to the device is via the UART,
which is not typically the case for things like regulators and/or GPIOs.
If I want a regulator to do something, I ask it to do so via the
controller's MMIO interface. If you want the device to do something, you
ask it to do so via the UART. 

> > In the case of UART slave devices the control interface is attached to
> > the UART, and effectively the slave sits on the UART's "bus". We could
> > refer to it from elsewhere by phandle, but its canonical parent should
> > be the UART, as that’s what its main interface is attached to.
> 
> What is the “main interface” of some device? Why should it have a special
> role in DT? I have doubts that it is useful to declare some interface as “main”,
> unless it is a MMIO bus connection.
> 
> There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C busses, 2 PCM
> “busses”, an ULIP-PHY and some GPIOs.

I think that would already be covered as an I2C device with two I2C IDs,
much like we would cater for an MMIO-interfaced PHY with two MMIO
control register regions

> Or some 3G/4G modems which have
> USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.

Of these I would expect that the USB or UART inerfaces would be the main
ones, though I would expect that we'd require two separate nodes which
we would have to link up.

> Which interface is “main”? For the twl4030 it happens that one of the I2C interfaces
> is chosen (because it allows to access the registers inside the chip).

Because it happens to be the "main" interface ;)

> Now you might say: yes, the registers of some uart connected device can
> be accessed through the uart as well. But usually there is a higher level
> protocol (AT commands) that give some sort of “register addressing”. But
> that is a different level than using I2C to access e.g. the gpio controller in the twl4030.
> 
> I just want to say that requiring and focussing on a “main” interface of a peripheral
> chip may lead to troubles.

I don't disagree that it falls apart in some cases. However, that's not
the general case, and it applies to other interface types too, so I
don't think it should matter in the context of this discussions.

> >> From my DT designer PoV I would say the UART exists in some SoC
> >> (independently of a device being connected) and then, a device is connected
> >> to the UART. Hence the proposal of adding this connection link to the device’s
> >> node and not making the device a subnode. And having the device driver do
> >> power management and only ask the uart/tty driver to be notified about open()
> >> and close() events. How power is managed in detail is then not any part of the
> >> tty/serial drivers.
> > 
> > The way that the power management interfaces are organised within Linux
> > is orthogonal to the way we describe things in the DT.
> 
> Agreed. And therefore power management registration, notifications etc.
> are to be hidden by the drivers and should not be an argument to say “with
> subnodes it is easier to implement and probing is done in the right order”.

While generally we shouldn't treat OS internals as an argument for DT
organisation, laying things out in a sensible manner for
discoverabilitiy is somewhat different from stating that the run-time
use of a device is fundamentally tied to its description in the DT.

We _could_ list all nodes in a flat list with cross references instead
of having a tree. But it would be horrible for _any_ OS to deal with, so
we don't do that.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Mark Rutland]

On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
> Hi Mark,
> 
> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
> 
> >>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
> >>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
> >>>>>> designers who want to easily import an existing board DT and overwrite device
> >>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
> >>>>>> which uart.
> > 
> > [...]
> > 
> >>> If this happens, you can move the slave device into a fragment that you
> >>> can include under the correct node. That's trivial.
> >> 
> >> But less readable. And that is important as well.
> > 
> > I disagree. The manipulation you have to perform to override properties
> > is at least as bad as including a file.
> 
> What about:
> 
> #include "omap3-beagle-xm.dts"
> 
> / {
> 	/* HS USB Port 2 Power enable was inverted with the xM C */
> 	hsusb2_power: hsusb2_power_reg {
> 		enable-active-high;
> 	};
> };
> 
> compared to 
> 
> #include “board1.dts”
> 
> / {
> 	/* slave was reconnected to uart4 */
> 	slave {
> 		uart = <&uart4>;
> 	};
> };

As I mentioned, you can easily carve up your DTS to make that work with
includes if you really must:

/* UART0 board variant */
#include "board.dtsi"
&uart0 {
	#include "some-uart-slave.dtsi"
};

/* UART1 board variant */
#include "board.dtsi"
&uart1 {
	#include "some-uart-slave.dtsi"
};

If you happen to find includes ugly then you can say it's ugly, but it's
functionally equivalent, and also means you can avoid having
disabled/partial nodes all over the place.

If you really wanted you could macro the label instead and have the
slaved node in full.

[...]

> > As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
> > connection between master (UART) and slave (device), and it happens that
> > in most other cases the master is actually a bus, so that's how things
> > happen to be named.
> 
> So you also mean that all master-slave connections must be represented
> by DT subnodes and everything else is not acceptable?
> 
> What about:
> 
> 	sound {
> 		compatible = "ti,omap-twl4030";
> 		ti,model = "omap3beagle";
> 
> 		ti,mcbsp = <&mcbsp2>;
> 	};
> 
> Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the “twl4030”
> is the slave (codec)?

I'm nowhere near familiar enough with the audio hardware nor their
bindings to comment on that, I'm afraid. My rough understanding was that
the twl4030 node here was referring to the logical subsystem as a whole,
with the mcbsp being a physical component, but that's almost certainly
somewhat wrong.

> &usb_otg_hs {
> 	interface-type = <0>;
> 	usb-phy = <&usb2_phy>;
> 	phys = <&usb2_phy>;
> 	phy-names = "usb2-phy";
> 	mode = <3>;
> 	power = <50>;
> };
> 
> Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI “bus” as well?

Not necessarily. If you took a look at the bindings you'd notice that
many PHYs have MMIO interfaces for configuration which we have to poke.
Those MMIO interfaces live on an MMIO bus so we describe those and link
to the phy by phandle reference.

A given device could operate as a PHY to multiple controllers, hence
phy-cells, and hence in general a PHY cannot be considered a slave
device.

> At least in this two areas everything done so far appears to contradict your argument.

Not really. You've found bindings with a different idiom, but those seem
to be organised as they are for reasons which don't appear to apply to
UART slave devices as you describe them.

> This is for me the blueprint how it should be done for UART slaves like any point-to-point
> multi-wire interfaces (question not even discussed: does UART-to-UART have clear master
> and slave roles? Isn’t the connected device the “master”? but I don’t want to broaden the
> discussion again).
> 
> This is basically why I keep this discussion open, because it is not that obvious
> that Neil’s proposal is right and mine is wrong.
> 
> > 
> >>> for other
> >>> interfaces like SPI and I2C. I do not see a compelling reason to do
> >>> otherwise for devices

[...]

> >>> hanging off of UARTs -- doing so would make things
> >>> less straightforward because you have a fundamentally different idiom.
> >> 
> >> Yes, my proposal is fundamentally different from I2C and SPI practice, but
> >> it is the same that is heavily used for e.g. GPIOs and Regulators.
> > 
> > Well, those cases are somewhat distinct, and I'd say that UART slaves
> > are much closer to SPI/I2C devices than GPIOs or regulators.
> 
> As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
> other interfaces).

As above, I disagree.

> > Let's say I have a GPIO described via a phandle. That GPIO is actually
> > owned by some GPIO controller whose control interface is sat on an MMIO
> > bus. What we're describing with the phandle is use of the GPIO, but not
> > the main interface for interactive with the GPIO, which is the MMIO
> > interface of the controller.
> 
> Right. For the UART we do the same: the UART controller is connected
> to the MMIO and (in my proposal) the phandle describes the use of the UART
> (to connect to some slave device). Exactly the same situation.

Except that your fundamental interface to the device is via the UART,
which is not typically the case for things like regulators and/or GPIOs.
If I want a regulator to do something, I ask it to do so via the
controller's MMIO interface. If you want the device to do something, you
ask it to do so via the UART. 

> > In the case of UART slave devices the control interface is attached to
> > the UART, and effectively the slave sits on the UART's "bus". We could
> > refer to it from elsewhere by phandle, but its canonical parent should
> > be the UART, as that’s what its main interface is attached to.
> 
> What is the “main interface” of some device? Why should it have a special
> role in DT? I have doubts that it is useful to declare some interface as “main”,
> unless it is a MMIO bus connection.
> 
> There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C busses, 2 PCM
> “busses”, an ULIP-PHY and some GPIOs.

I think that would already be covered as an I2C device with two I2C IDs,
much like we would cater for an MMIO-interfaced PHY with two MMIO
control register regions

> Or some 3G/4G modems which have
> USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.

Of these I would expect that the USB or UART inerfaces would be the main
ones, though I would expect that we'd require two separate nodes which
we would have to link up.

> Which interface is “main”? For the twl4030 it happens that one of the I2C interfaces
> is chosen (because it allows to access the registers inside the chip).

Because it happens to be the "main" interface ;)

> Now you might say: yes, the registers of some uart connected device can
> be accessed through the uart as well. But usually there is a higher level
> protocol (AT commands) that give some sort of “register addressing”. But
> that is a different level than using I2C to access e.g. the gpio controller in the twl4030.
> 
> I just want to say that requiring and focussing on a “main” interface of a peripheral
> chip may lead to troubles.

I don't disagree that it falls apart in some cases. However, that's not
the general case, and it applies to other interface types too, so I
don't think it should matter in the context of this discussions.

> >> From my DT designer PoV I would say the UART exists in some SoC
> >> (independently of a device being connected) and then, a device is connected
> >> to the UART. Hence the proposal of adding this connection link to the device’s
> >> node and not making the device a subnode. And having the device driver do
> >> power management and only ask the uart/tty driver to be notified about open()
> >> and close() events. How power is managed in detail is then not any part of the
> >> tty/serial drivers.
> > 
> > The way that the power management interfaces are organised within Linux
> > is orthogonal to the way we describe things in the DT.
> 
> Agreed. And therefore power management registration, notifications etc.
> are to be hidden by the drivers and should not be an argument to say “with
> subnodes it is easier to implement and probing is done in the right order”.

While generally we shouldn't treat OS internals as an argument for DT
organisation, laying things out in a sensible manner for
discoverabilitiy is somewhat different from stating that the run-time
use of a device is fundamentally tied to its description in the DT.

We _could_ list all nodes in a flat list with cross references instead
of having a tree. But it would be horrible for _any_ OS to deal with, so
we don't do that.

Thanks,
Mark.

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Mark,

Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:

> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Mark,
>> 
>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>> 
>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>> which uart.
>>> 
>>> [...]
>>> 
>>>>> If this happens, you can move the slave device into a fragment that you
>>>>> can include under the correct node. That's trivial.
>>>> 
>>>> But less readable. And that is important as well.
>>> 
>>> I disagree. The manipulation you have to perform to override properties
>>> is at least as bad as including a file.
>> 
>> What about:
>> 
>> #include "omap3-beagle-xm.dts"
>> 
>> / {
>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>> 	hsusb2_power: hsusb2_power_reg {
>> 		enable-active-high;
>> 	};
>> };
>> 
>> compared to 
>> 
>> #include “board1.dts”
>> 
>> / {
>> 	/* slave was reconnected to uart4 */
>> 	slave {
>> 		uart = <&uart4>;
>> 	};
>> };
> 
> As I mentioned, you can easily carve up your DTS to make that work with
> includes if you really must:
> 
> /* UART0 board variant */
> #include "board.dtsi"
> &uart0 {
> 	#include "some-uart-slave.dtsi"
> };
> 
> /* UART1 board variant */
> #include "board.dtsi"
> &uart1 {
> 	#include "some-uart-slave.dtsi"
> };
> 
> If you happen to find includes ugly then you can say it's ugly, but it's
> functionally equivalent, and also means you can avoid having
> disabled/partial nodes all over the place.

Functionally equivalent would also be to copy the whole source file and
s/&uart0/&uart1/.

But this is not the best solution for the DT programmer since there is no
automatic *reuse* of common parts.

And your proposal requires 3 source files instead of 2 which deteriorates
readibility and understanding what is really going on. And if you need to
change the some-uart-slave, you have to touch a different file than for
changing some other slave.

Yes, it works, but IMHO other factors for a good design are also important.

Maybe our main difference in PoV is that I specifically want to avoid that
we force future DT programmers into “ugly” solutions (even if they work).

If you think that DT programmers have to live with what they are
given and do the best with it, we can end the discussion.

> 
> If you really wanted you could macro the label instead and have the
> slaved node in full.

Hm. I have tried to find a single example where a DT source file has an
#include *not* on top level. Or a macro that defines multiple properties
or a complete subnode.

Maybe it is a commonly used DT design pattern and I just didn’t find it
in the device trees I have checked.

> 
> [...]
> 
>>> As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
>>> connection between master (UART) and slave (device), and it happens that
>>> in most other cases the master is actually a bus, so that's how things
>>> happen to be named.
>> 
>> So you also mean that all master-slave connections must be represented
>> by DT subnodes and everything else is not acceptable?
>> 
>> What about:
>> 
>> 	sound {
>> 		compatible = "ti,omap-twl4030";
>> 		ti,model = "omap3beagle";
>> 
>> 		ti,mcbsp = <&mcbsp2>;
>> 	};
>> 
>> Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the “twl4030”
>> is the slave (codec)?
> 
> I'm nowhere near familiar enough with the audio hardware nor their
> bindings to comment on that, I'm afraid. My rough understanding was that
> the twl4030 node here was referring to the logical subsystem as a whole,
> with the mcbsp being a physical component, but that's almost certainly
> somewhat wrong.

The McBSP is a 4-wire serial interface controller sitting on the OMAP chip.
It is accessed by MMIO and DMA. The twl4030 is the other end and the data
that is transferred is PCM audio to/from speakers/microphone.

So this node defines: there is a sound slave that is a twl4030 and the PCM interface
is the mcbsp2 of the OMAP SoC. Exactly the same pattern as I want to describe
a GPS slave that is connected to uart1 of the OMAP SoC.

> 
>> &usb_otg_hs {
>> 	interface-type = <0>;
>> 	usb-phy = <&usb2_phy>;
>> 	phys = <&usb2_phy>;
>> 	phy-names = "usb2-phy";
>> 	mode = <3>;
>> 	power = <50>;
>> };
>> 
>> Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI “bus” as well?
> 
> Not necessarily. If you took a look at the bindings you'd notice that
> many PHYs have MMIO interfaces for configuration which we have to poke.
> Those MMIO interfaces live on an MMIO bus so we describe those and link
> to the phy by phandle reference.

Yes, that is the reason why it can only be solved by a phandle, because the “main interface”
of the PHY chip is sometimes the MMIO bus, but could also be I2C or SPI.

In the case of osb_otg_hs I have copied, it is not. The PHY is *only* connected through
the ULPI wires and all register programming goes through that interface. It is not connected to
the MMIO bus at all.

> 
> A given device could operate as a PHY to multiple controllers, hence
> phy-cells, and hence in general a PHY cannot be considered a slave
> device.
> 
>> At least in this two areas everything done so far appears to contradict your argument.
> 
> Not really. You've found bindings with a different idiom, but those seem
> to be organised as they are for reasons which don't appear to apply to
> UART slave devices as you describe them.

In my view I2C and SPI also follow a different idiom (addressable, multiple slaves)
which does not appear to apply for an UART slave device.

> 
>> This is for me the blueprint how it should be done for UART slaves like any point-to-point
>> multi-wire interfaces (question not even discussed: does UART-to-UART have clear master
>> and slave roles? Isn’t the connected device the “master”? but I don’t want to broaden the
>> discussion again).
>> 
>> This is basically why I keep this discussion open, because it is not that obvious
>> that Neil’s proposal is right and mine is wrong.
>> 
>>> 
>>>>> for other
>>>>> interfaces like SPI and I2C. I do not see a compelling reason to do
>>>>> otherwise for devices
> 
> [...]
> 
>>>>> hanging off of UARTs -- doing so would make things
>>>>> less straightforward because you have a fundamentally different idiom.
>>>> 
>>>> Yes, my proposal is fundamentally different from I2C and SPI practice, but
>>>> it is the same that is heavily used for e.g. GPIOs and Regulators.
>>> 
>>> Well, those cases are somewhat distinct, and I'd say that UART slaves
>>> are much closer to SPI/I2C devices than GPIOs or regulators.
>> 
>> As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
>> other interfaces).
> 
> As above, I disagree.
> 
>>> Let's say I have a GPIO described via a phandle. That GPIO is actually
>>> owned by some GPIO controller whose control interface is sat on an MMIO
>>> bus. What we're describing with the phandle is use of the GPIO, but not
>>> the main interface for interactive with the GPIO, which is the MMIO
>>> interface of the controller.
>> 
>> Right. For the UART we do the same: the UART controller is connected
>> to the MMIO and (in my proposal) the phandle describes the use of the UART
>> (to connect to some slave device). Exactly the same situation.
> 
> Except that your fundamental interface to the device is via the UART,
> which is not typically the case for things like regulators and/or GPIOs.
> If I want a regulator to do something, I ask it to do so via the
> controller's MMIO interface. If you want the device to do something, you
> ask it to do so via the UART. 

I also ask the UART controller through the MMIO to send bytes to the device.
For a GPIO it is just a single bit that is “sent” or “received”.

And, I do not ask the device to do something through UART. I exchange
data. And only if the specific device has it I use some escape mechanisms
(like AT commands) to do control. If a vt52 is connected I only send characters
and receive keyboard codes.

So I don’t think that being able to control the slave is a common property
of all UART-slave connections.

BTW: the GPS chip we use is doing something without any instructions. It starts
to send NMEA records right after power on. It would even be useful with a unidirectional
connection from GPS to UART. Hence there are no commands that need to be
sent through UART. Rather it just needs some GPIO to be activated or powered down
when /dev/tty is opened/closed.

So one could argue that in this real case (which we try to solve in an acceptable way
since 2 years) the fundamental/main interface (control command interface) of this chip
is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”.

But that is on the lowest detail level.

> 
>>> In the case of UART slave devices the control interface is attached to
>>> the UART, and effectively the slave sits on the UART's "bus". We could
>>> refer to it from elsewhere by phandle, but its canonical parent should
>>> be the UART, as that’s what its main interface is attached to.
>> 
>> What is the “main interface” of some device? Why should it have a special
>> role in DT? I have doubts that it is useful to declare some interface as “main”,
>> unless it is a MMIO bus connection.
>> 
>> There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C busses, 2 PCM
>> “busses”, an ULIP-PHY and some GPIOs.
> 
> I think that would already be covered as an I2C device with two I2C IDs,
> much like we would cater for an MMIO-interfaced PHY with two MMIO
> control register regions

Yes, as long as multiple interfaces fall into the same category.

> 
>> Or some 3G/4G modems which have
>> USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.
> 
> Of these I would expect that the USB or UART inerfaces would be the main
> ones,

Both are equally valid to be the “main" interface (because you can use both to send
AT commands).

> though I would expect that we'd require two separate nodes which
> we would have to link up.

And how would you do that without phandles?

Fortunately this is an easy to solve problem since USB has enumeration and the
USB interface does not need to be described in DT.

> 
>> Which interface is “main”? For the twl4030 it happens that one of the I2C interfaces
>> is chosen (because it allows to access the registers inside the chip).
> 
> Because it happens to be the “main” interface ;)

It depends on the angle of viewing onto the chip components, to see it as the main interface.

If you look from “how can the kernel access registers”, it is. If you look from a
sound (PCM payload) perspective the PCM interface would be “main”.

But I agree that a “main interface” should be defined as the interface that allows
the most broad control the chip. I.e. it should not be defined by “biggest payload
bandwidth” or similar.

> 
>> Now you might say: yes, the registers of some uart connected device can
>> be accessed through the uart as well. But usually there is a higher level
>> protocol (AT commands) that give some sort of “register addressing”. But
>> that is a different level than using I2C to access e.g. the gpio controller in the twl4030.
>> 
>> I just want to say that requiring and focussing on a “main” interface of a peripheral
>> chip may lead to troubles.
> 
> I don't disagree that it falls apart in some cases. However, that's not
> the general case, and it applies to other interface types too, so I
> don't think it should matter in the context of this discussions.
> 
>>>> From my DT designer PoV I would say the UART exists in some SoC
>>>> (independently of a device being connected) and then, a device is connected
>>>> to the UART. Hence the proposal of adding this connection link to the device’s
>>>> node and not making the device a subnode. And having the device driver do
>>>> power management and only ask the uart/tty driver to be notified about open()
>>>> and close() events. How power is managed in detail is then not any part of the
>>>> tty/serial drivers.
>>> 
>>> The way that the power management interfaces are organised within Linux
>>> is orthogonal to the way we describe things in the DT.
>> 
>> Agreed. And therefore power management registration, notifications etc.
>> are to be hidden by the drivers and should not be an argument to say “with
>> subnodes it is easier to implement and probing is done in the right order”.
> 
> While generally we shouldn't treat OS internals as an argument for DT
> organisation, laying things out in a sensible manner for
> discoverabilitiy is somewhat different from stating that the run-time
> use of a device is fundamentally tied to its description in the DT.
> 
> We _could_ list all nodes in a flat list with cross references instead
> of having a tree. But it would be horrible for _any_ OS to deal with, so
> we don’t do that.

Agreed.

“Discoverability” is something I have not yet thought about. For I2C it is
important to tell the I2C controller at which address to look for devices
(so that it does not have to scan all of them). This is most easily achieved
by making the (potential) slaves subnodes of the i2c bus controller and
nicely fits with the <reg> property subnodes usually have.

UART slaves are static. Or simply respond/don’t respond. So there is
no well defined discovery mechanism involved and therefore the slave
does not require to be a subnode of the uart to support descovery.

BTW: there is a solution to the probe sequence issue:
1. each UART registers itself in some uart map (phandle -> driver instance)
    as soon as probed successfully
2. a slave driver checks if it can find its attached uart in the list
3. if not -> -EPROBE_DEFER
4. if yes, it can register with the uart driver to receive tty open/close notifications


But mainly we do not agree on priority and importance of criteria when evaluating
the two solutions that are on the table.

We can continue with examples and counter examples to identify the implications
(for Driver developers and for DT developers) of choosing either one.

It is a very complex problem without a single criterion that makes one solution
better than the other. Hence I think the discussion is necessary.

So should we continue or does someone decide?

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Mark,

Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>:

> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>> Hi Mark,
>> 
>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>:
>> 
>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>> which uart.
>>> 
>>> [...]
>>> 
>>>>> If this happens, you can move the slave device into a fragment that you
>>>>> can include under the correct node. That's trivial.
>>>> 
>>>> But less readable. And that is important as well.
>>> 
>>> I disagree. The manipulation you have to perform to override properties
>>> is at least as bad as including a file.
>> 
>> What about:
>> 
>> #include "omap3-beagle-xm.dts"
>> 
>> / {
>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>> 	hsusb2_power: hsusb2_power_reg {
>> 		enable-active-high;
>> 	};
>> };
>> 
>> compared to 
>> 
>> #include “board1.dts”
>> 
>> / {
>> 	/* slave was reconnected to uart4 */
>> 	slave {
>> 		uart = <&uart4>;
>> 	};
>> };
> 
> As I mentioned, you can easily carve up your DTS to make that work with
> includes if you really must:
> 
> /* UART0 board variant */
> #include "board.dtsi"
> &uart0 {
> 	#include "some-uart-slave.dtsi"
> };
> 
> /* UART1 board variant */
> #include "board.dtsi"
> &uart1 {
> 	#include "some-uart-slave.dtsi"
> };
> 
> If you happen to find includes ugly then you can say it's ugly, but it's
> functionally equivalent, and also means you can avoid having
> disabled/partial nodes all over the place.

Functionally equivalent would also be to copy the whole source file and
s/&uart0/&uart1/.

But this is not the best solution for the DT programmer since there is no
automatic *reuse* of common parts.

And your proposal requires 3 source files instead of 2 which deteriorates
readibility and understanding what is really going on. And if you need to
change the some-uart-slave, you have to touch a different file than for
changing some other slave.

Yes, it works, but IMHO other factors for a good design are also important.

Maybe our main difference in PoV is that I specifically want to avoid that
we force future DT programmers into “ugly” solutions (even if they work).

If you think that DT programmers have to live with what they are
given and do the best with it, we can end the discussion.

> 
> If you really wanted you could macro the label instead and have the
> slaved node in full.

Hm. I have tried to find a single example where a DT source file has an
#include *not* on top level. Or a macro that defines multiple properties
or a complete subnode.

Maybe it is a commonly used DT design pattern and I just didn’t find it
in the device trees I have checked.

> 
> [...]
> 
>>> As Neil mentioned earlier, ignore "bus". Here we're caring about a 1-1
>>> connection between master (UART) and slave (device), and it happens that
>>> in most other cases the master is actually a bus, so that's how things
>>> happen to be named.
>> 
>> So you also mean that all master-slave connections must be represented
>> by DT subnodes and everything else is not acceptable?
>> 
>> What about:
>> 
>> 	sound {
>> 		compatible = "ti,omap-twl4030";
>> 		ti,model = "omap3beagle";
>> 
>> 		ti,mcbsp = <&mcbsp2>;
>> 	};
>> 
>> Isn’t McBSP a “bus” with your definition as well? Like a “master”. And the “twl4030”
>> is the slave (codec)?
> 
> I'm nowhere near familiar enough with the audio hardware nor their
> bindings to comment on that, I'm afraid. My rough understanding was that
> the twl4030 node here was referring to the logical subsystem as a whole,
> with the mcbsp being a physical component, but that's almost certainly
> somewhat wrong.

The McBSP is a 4-wire serial interface controller sitting on the OMAP chip.
It is accessed by MMIO and DMA. The twl4030 is the other end and the data
that is transferred is PCM audio to/from speakers/microphone.

So this node defines: there is a sound slave that is a twl4030 and the PCM interface
is the mcbsp2 of the OMAP SoC. Exactly the same pattern as I want to describe
a GPS slave that is connected to uart1 of the OMAP SoC.

> 
>> &usb_otg_hs {
>> 	interface-type = <0>;
>> 	usb-phy = <&usb2_phy>;
>> 	phys = <&usb2_phy>;
>> 	phy-names = "usb2-phy";
>> 	mode = <3>;
>> 	power = <50>;
>> };
>> 
>> Isn’t a PHY interface (e.g. ULPI-PHY) a “slave” connected to a 12 wire ULPI “bus” as well?
> 
> Not necessarily. If you took a look at the bindings you'd notice that
> many PHYs have MMIO interfaces for configuration which we have to poke.
> Those MMIO interfaces live on an MMIO bus so we describe those and link
> to the phy by phandle reference.

Yes, that is the reason why it can only be solved by a phandle, because the “main interface”
of the PHY chip is sometimes the MMIO bus, but could also be I2C or SPI.

In the case of osb_otg_hs I have copied, it is not. The PHY is *only* connected through
the ULPI wires and all register programming goes through that interface. It is not connected to
the MMIO bus at all.

> 
> A given device could operate as a PHY to multiple controllers, hence
> phy-cells, and hence in general a PHY cannot be considered a slave
> device.
> 
>> At least in this two areas everything done so far appears to contradict your argument.
> 
> Not really. You've found bindings with a different idiom, but those seem
> to be organised as they are for reasons which don't appear to apply to
> UART slave devices as you describe them.

In my view I2C and SPI also follow a different idiom (addressable, multiple slaves)
which does not appear to apply for an UART slave device.

> 
>> This is for me the blueprint how it should be done for UART slaves like any point-to-point
>> multi-wire interfaces (question not even discussed: does UART-to-UART have clear master
>> and slave roles? Isn’t the connected device the “master”? but I don’t want to broaden the
>> discussion again).
>> 
>> This is basically why I keep this discussion open, because it is not that obvious
>> that Neil’s proposal is right and mine is wrong.
>> 
>>> 
>>>>> for other
>>>>> interfaces like SPI and I2C. I do not see a compelling reason to do
>>>>> otherwise for devices
> 
> [...]
> 
>>>>> hanging off of UARTs -- doing so would make things
>>>>> less straightforward because you have a fundamentally different idiom.
>>>> 
>>>> Yes, my proposal is fundamentally different from I2C and SPI practice, but
>>>> it is the same that is heavily used for e.g. GPIOs and Regulators.
>>> 
>>> Well, those cases are somewhat distinct, and I'd say that UART slaves
>>> are much closer to SPI/I2C devices than GPIOs or regulators.
>> 
>> As shown above they are IMHO closer to McBSP and ULPI-PHY (and some
>> other interfaces).
> 
> As above, I disagree.
> 
>>> Let's say I have a GPIO described via a phandle. That GPIO is actually
>>> owned by some GPIO controller whose control interface is sat on an MMIO
>>> bus. What we're describing with the phandle is use of the GPIO, but not
>>> the main interface for interactive with the GPIO, which is the MMIO
>>> interface of the controller.
>> 
>> Right. For the UART we do the same: the UART controller is connected
>> to the MMIO and (in my proposal) the phandle describes the use of the UART
>> (to connect to some slave device). Exactly the same situation.
> 
> Except that your fundamental interface to the device is via the UART,
> which is not typically the case for things like regulators and/or GPIOs.
> If I want a regulator to do something, I ask it to do so via the
> controller's MMIO interface. If you want the device to do something, you
> ask it to do so via the UART. 

I also ask the UART controller through the MMIO to send bytes to the device.
For a GPIO it is just a single bit that is “sent” or “received”.

And, I do not ask the device to do something through UART. I exchange
data. And only if the specific device has it I use some escape mechanisms
(like AT commands) to do control. If a vt52 is connected I only send characters
and receive keyboard codes.

So I don’t think that being able to control the slave is a common property
of all UART-slave connections.

BTW: the GPS chip we use is doing something without any instructions. It starts
to send NMEA records right after power on. It would even be useful with a unidirectional
connection from GPS to UART. Hence there are no commands that need to be
sent through UART. Rather it just needs some GPIO to be activated or powered down
when /dev/tty is opened/closed.

So one could argue that in this real case (which we try to solve in an acceptable way
since 2 years) the fundamental/main interface (control command interface) of this chip
is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”.

But that is on the lowest detail level.

> 
>>> In the case of UART slave devices the control interface is attached to
>>> the UART, and effectively the slave sits on the UART's "bus". We could
>>> refer to it from elsewhere by phandle, but its canonical parent should
>>> be the UART, as that’s what its main interface is attached to.
>> 
>> What is the “main interface” of some device? Why should it have a special
>> role in DT? I have doubts that it is useful to declare some interface as “main”,
>> unless it is a MMIO bus connection.
>> 
>> There are e.g. chips with multi-interfaces like a twl4030. They have 2 I2C busses, 2 PCM
>> “busses”, an ULIP-PHY and some GPIOs.
> 
> I think that would already be covered as an I2C device with two I2C IDs,
> much like we would cater for an MMIO-interfaced PHY with two MMIO
> control register regions

Yes, as long as multiple interfaces fall into the same category.

> 
>> Or some 3G/4G modems which have
>> USB, UART (both useable for AT commands in parallel!), PCM and some GPIOs.
> 
> Of these I would expect that the USB or UART inerfaces would be the main
> ones,

Both are equally valid to be the “main" interface (because you can use both to send
AT commands).

> though I would expect that we'd require two separate nodes which
> we would have to link up.

And how would you do that without phandles?

Fortunately this is an easy to solve problem since USB has enumeration and the
USB interface does not need to be described in DT.

> 
>> Which interface is “main”? For the twl4030 it happens that one of the I2C interfaces
>> is chosen (because it allows to access the registers inside the chip).
> 
> Because it happens to be the “main” interface ;)

It depends on the angle of viewing onto the chip components, to see it as the main interface.

If you look from “how can the kernel access registers”, it is. If you look from a
sound (PCM payload) perspective the PCM interface would be “main”.

But I agree that a “main interface” should be defined as the interface that allows
the most broad control the chip. I.e. it should not be defined by “biggest payload
bandwidth” or similar.

> 
>> Now you might say: yes, the registers of some uart connected device can
>> be accessed through the uart as well. But usually there is a higher level
>> protocol (AT commands) that give some sort of “register addressing”. But
>> that is a different level than using I2C to access e.g. the gpio controller in the twl4030.
>> 
>> I just want to say that requiring and focussing on a “main” interface of a peripheral
>> chip may lead to troubles.
> 
> I don't disagree that it falls apart in some cases. However, that's not
> the general case, and it applies to other interface types too, so I
> don't think it should matter in the context of this discussions.
> 
>>>> From my DT designer PoV I would say the UART exists in some SoC
>>>> (independently of a device being connected) and then, a device is connected
>>>> to the UART. Hence the proposal of adding this connection link to the device’s
>>>> node and not making the device a subnode. And having the device driver do
>>>> power management and only ask the uart/tty driver to be notified about open()
>>>> and close() events. How power is managed in detail is then not any part of the
>>>> tty/serial drivers.
>>> 
>>> The way that the power management interfaces are organised within Linux
>>> is orthogonal to the way we describe things in the DT.
>> 
>> Agreed. And therefore power management registration, notifications etc.
>> are to be hidden by the drivers and should not be an argument to say “with
>> subnodes it is easier to implement and probing is done in the right order”.
> 
> While generally we shouldn't treat OS internals as an argument for DT
> organisation, laying things out in a sensible manner for
> discoverabilitiy is somewhat different from stating that the run-time
> use of a device is fundamentally tied to its description in the DT.
> 
> We _could_ list all nodes in a flat list with cross references instead
> of having a tree. But it would be horrible for _any_ OS to deal with, so
> we don’t do that.

Agreed.

“Discoverability” is something I have not yet thought about. For I2C it is
important to tell the I2C controller at which address to look for devices
(so that it does not have to scan all of them). This is most easily achieved
by making the (potential) slaves subnodes of the i2c bus controller and
nicely fits with the <reg> property subnodes usually have.

UART slaves are static. Or simply respond/don’t respond. So there is
no well defined discovery mechanism involved and therefore the slave
does not require to be a subnode of the uart to support descovery.

BTW: there is a solution to the probe sequence issue:
1. each UART registers itself in some uart map (phandle -> driver instance)
    as soon as probed successfully
2. a slave driver checks if it can find its attached uart in the list
3. if not -> -EPROBE_DEFER
4. if yes, it can register with the uart driver to receive tty open/close notifications


But mainly we do not agree on priority and importance of criteria when evaluating
the two solutions that are on the table.

We can continue with examples and counter examples to identify the implications
(for Driver developers and for DT developers) of choosing either one.

It is a very complex problem without a single criterion that makes one solution
better than the other. Hence I think the discussion is necessary.

So should we continue or does someone decide?

BR and thanks,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>
>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>> which uart.
>>>>
>>>> [...]
>>>>
>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>> can include under the correct node. That's trivial.
>>>>>
>>>>> But less readable. And that is important as well.
>>>>
>>>> I disagree. The manipulation you have to perform to override properties
>>>> is at least as bad as including a file.
>>>
>>> What about:
>>>
>>> #include "omap3-beagle-xm.dts"
>>>
>>> / {
>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>> 	hsusb2_power: hsusb2_power_reg {
>>> 		enable-active-high;
>>> 	};
>>> };
>>>
>>> compared to 
>>>
>>> #include “board1.dts”
>>>
>>> / {
>>> 	/* slave was reconnected to uart4 */
>>> 	slave {
>>> 		uart = <&uart4>;
>>> 	};
>>> };
>>
>> As I mentioned, you can easily carve up your DTS to make that work with
>> includes if you really must:
>>
>> /* UART0 board variant */
>> #include "board.dtsi"
>> &uart0 {
>> 	#include "some-uart-slave.dtsi"
>> };
>>
>> /* UART1 board variant */
>> #include "board.dtsi"
>> &uart1 {
>> 	#include "some-uart-slave.dtsi"
>> };
>>
>> If you happen to find includes ugly then you can say it's ugly, but it's
>> functionally equivalent, and also means you can avoid having
>> disabled/partial nodes all over the place.
> 
> Functionally equivalent would also be to copy the whole source file and
> s/&uart0/&uart1/.
> 
> But this is not the best solution for the DT programmer since there is no
> automatic *reuse* of common parts.
> 
> And your proposal requires 3 source files instead of 2 which deteriorates
> readibility and understanding what is really going on. And if you need to
> change the some-uart-slave, you have to touch a different file than for
> changing some other slave.
> 
> Yes, it works, but IMHO other factors for a good design are also important.
> 
> Maybe our main difference in PoV is that I specifically want to avoid that
> we force future DT programmers into “ugly” solutions (even if they work).
> 
> If you think that DT programmers have to live with what they are
> given and do the best with it, we can end the discussion.

The question of syntax is orthogonal to the discussion of the proper
devicetree representation.

The awkwardness of expressing variants has nothing to do with the
appropriate device hierarchy (or whether there should be a hierarchy).
Describing variants is just as awkward when the parent-child relationship
is indisputable.

There was a recent discussion on devicetree ML regarding how best to
express and represent variance. Feel free to revive that discussion.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>
>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>> which uart.
>>>>
>>>> [...]
>>>>
>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>> can include under the correct node. That's trivial.
>>>>>
>>>>> But less readable. And that is important as well.
>>>>
>>>> I disagree. The manipulation you have to perform to override properties
>>>> is at least as bad as including a file.
>>>
>>> What about:
>>>
>>> #include "omap3-beagle-xm.dts"
>>>
>>> / {
>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>> 	hsusb2_power: hsusb2_power_reg {
>>> 		enable-active-high;
>>> 	};
>>> };
>>>
>>> compared to 
>>>
>>> #include “board1.dts”
>>>
>>> / {
>>> 	/* slave was reconnected to uart4 */
>>> 	slave {
>>> 		uart = <&uart4>;
>>> 	};
>>> };
>>
>> As I mentioned, you can easily carve up your DTS to make that work with
>> includes if you really must:
>>
>> /* UART0 board variant */
>> #include "board.dtsi"
>> &uart0 {
>> 	#include "some-uart-slave.dtsi"
>> };
>>
>> /* UART1 board variant */
>> #include "board.dtsi"
>> &uart1 {
>> 	#include "some-uart-slave.dtsi"
>> };
>>
>> If you happen to find includes ugly then you can say it's ugly, but it's
>> functionally equivalent, and also means you can avoid having
>> disabled/partial nodes all over the place.
> 
> Functionally equivalent would also be to copy the whole source file and
> s/&uart0/&uart1/.
> 
> But this is not the best solution for the DT programmer since there is no
> automatic *reuse* of common parts.
> 
> And your proposal requires 3 source files instead of 2 which deteriorates
> readibility and understanding what is really going on. And if you need to
> change the some-uart-slave, you have to touch a different file than for
> changing some other slave.
> 
> Yes, it works, but IMHO other factors for a good design are also important.
> 
> Maybe our main difference in PoV is that I specifically want to avoid that
> we force future DT programmers into “ugly” solutions (even if they work).
> 
> If you think that DT programmers have to live with what they are
> given and do the best with it, we can end the discussion.

The question of syntax is orthogonal to the discussion of the proper
devicetree representation.

The awkwardness of expressing variants has nothing to do with the
appropriate device hierarchy (or whether there should be a hierarchy).
Describing variants is just as awkward when the parent-child relationship
is indisputable.

There was a recent discussion on devicetree ML regarding how best to
express and represent variance. Feel free to revive that discussion.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>> 
>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>>> which uart.
>>>>> 
>>>>> [...]
>>>>> 
>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>> can include under the correct node. That's trivial.
>>>>>> 
>>>>>> But less readable. And that is important as well.
>>>>> 
>>>>> I disagree. The manipulation you have to perform to override properties
>>>>> is at least as bad as including a file.
>>>> 
>>>> What about:
>>>> 
>>>> #include "omap3-beagle-xm.dts"
>>>> 
>>>> / {
>>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>>> 	hsusb2_power: hsusb2_power_reg {
>>>> 		enable-active-high;
>>>> 	};
>>>> };
>>>> 
>>>> compared to 
>>>> 
>>>> #include “board1.dts”
>>>> 
>>>> / {
>>>> 	/* slave was reconnected to uart4 */
>>>> 	slave {
>>>> 		uart = <&uart4>;
>>>> 	};
>>>> };
>>> 
>>> As I mentioned, you can easily carve up your DTS to make that work with
>>> includes if you really must:
>>> 
>>> /* UART0 board variant */
>>> #include "board.dtsi"
>>> &uart0 {
>>> 	#include "some-uart-slave.dtsi"
>>> };
>>> 
>>> /* UART1 board variant */
>>> #include "board.dtsi"
>>> &uart1 {
>>> 	#include "some-uart-slave.dtsi"
>>> };
>>> 
>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>> functionally equivalent, and also means you can avoid having
>>> disabled/partial nodes all over the place.
>> 
>> Functionally equivalent would also be to copy the whole source file and
>> s/&uart0/&uart1/.
>> 
>> But this is not the best solution for the DT programmer since there is no
>> automatic *reuse* of common parts.
>> 
>> And your proposal requires 3 source files instead of 2 which deteriorates
>> readibility and understanding what is really going on. And if you need to
>> change the some-uart-slave, you have to touch a different file than for
>> changing some other slave.
>> 
>> Yes, it works, but IMHO other factors for a good design are also important.
>> 
>> Maybe our main difference in PoV is that I specifically want to avoid that
>> we force future DT programmers into “ugly” solutions (even if they work).
>> 
>> If you think that DT programmers have to live with what they are
>> given and do the best with it, we can end the discussion.
> 
> The question of syntax is orthogonal to the discussion of the proper
> devicetree representation.
> 
> The awkwardness of expressing variants has nothing to do with the
> appropriate device hierarchy (or whether there should be a hierarchy).
> Describing variants is just as awkward when the parent-child relationship
> is indisputable.

That is ok. But I still have not found the key rule when a parent-child relationship
is indisputable. Candidates so far are “main interface” (which is still disputable)
or “bus” (where we can dispute if a point-to-point connection is a “bus”).

But if both options are equally valid (maybe because there is no rule
making either indisputable), I would chose the one with easier syntax.

> 
> There was a recent discussion on devicetree ML regarding how best to
> express and represent variance. Feel free to revive that discussion.

Does it help? Our core issue is not the syntax and variance per se. This are
just examples to demonstrate differences in syntax of parent-child vs. phandle.

If we decide for either one, we have to live with syntactical and other
implcationd.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>> 
>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>>> which uart.
>>>>> 
>>>>> [...]
>>>>> 
>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>> can include under the correct node. That's trivial.
>>>>>> 
>>>>>> But less readable. And that is important as well.
>>>>> 
>>>>> I disagree. The manipulation you have to perform to override properties
>>>>> is at least as bad as including a file.
>>>> 
>>>> What about:
>>>> 
>>>> #include "omap3-beagle-xm.dts"
>>>> 
>>>> / {
>>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>>> 	hsusb2_power: hsusb2_power_reg {
>>>> 		enable-active-high;
>>>> 	};
>>>> };
>>>> 
>>>> compared to 
>>>> 
>>>> #include “board1.dts”
>>>> 
>>>> / {
>>>> 	/* slave was reconnected to uart4 */
>>>> 	slave {
>>>> 		uart = <&uart4>;
>>>> 	};
>>>> };
>>> 
>>> As I mentioned, you can easily carve up your DTS to make that work with
>>> includes if you really must:
>>> 
>>> /* UART0 board variant */
>>> #include "board.dtsi"
>>> &uart0 {
>>> 	#include "some-uart-slave.dtsi"
>>> };
>>> 
>>> /* UART1 board variant */
>>> #include "board.dtsi"
>>> &uart1 {
>>> 	#include "some-uart-slave.dtsi"
>>> };
>>> 
>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>> functionally equivalent, and also means you can avoid having
>>> disabled/partial nodes all over the place.
>> 
>> Functionally equivalent would also be to copy the whole source file and
>> s/&uart0/&uart1/.
>> 
>> But this is not the best solution for the DT programmer since there is no
>> automatic *reuse* of common parts.
>> 
>> And your proposal requires 3 source files instead of 2 which deteriorates
>> readibility and understanding what is really going on. And if you need to
>> change the some-uart-slave, you have to touch a different file than for
>> changing some other slave.
>> 
>> Yes, it works, but IMHO other factors for a good design are also important.
>> 
>> Maybe our main difference in PoV is that I specifically want to avoid that
>> we force future DT programmers into “ugly” solutions (even if they work).
>> 
>> If you think that DT programmers have to live with what they are
>> given and do the best with it, we can end the discussion.
> 
> The question of syntax is orthogonal to the discussion of the proper
> devicetree representation.
> 
> The awkwardness of expressing variants has nothing to do with the
> appropriate device hierarchy (or whether there should be a hierarchy).
> Describing variants is just as awkward when the parent-child relationship
> is indisputable.

That is ok. But I still have not found the key rule when a parent-child relationship
is indisputable. Candidates so far are “main interface” (which is still disputable)
or “bus” (where we can dispute if a point-to-point connection is a “bus”).

But if both options are equally valid (maybe because there is no rule
making either indisputable), I would chose the one with easier syntax.

> 
> There was a recent discussion on devicetree ML regarding how best to
> express and represent variance. Feel free to revive that discussion.

Does it help? Our core issue is not the syntax and variance per se. This are
just examples to demonstrate differences in syntax of parent-child vs. phandle.

If we decide for either one, we have to live with syntactical and other
implcationd.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
> 
> Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>>
>>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>>>> which uart.
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>>> can include under the correct node. That's trivial.
>>>>>>>
>>>>>>> But less readable. And that is important as well.
>>>>>>
>>>>>> I disagree. The manipulation you have to perform to override properties
>>>>>> is at least as bad as including a file.
>>>>>
>>>>> What about:
>>>>>
>>>>> #include "omap3-beagle-xm.dts"
>>>>>
>>>>> / {
>>>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>>>> 	hsusb2_power: hsusb2_power_reg {
>>>>> 		enable-active-high;
>>>>> 	};
>>>>> };
>>>>>
>>>>> compared to 
>>>>>
>>>>> #include “board1.dts”
>>>>>
>>>>> / {
>>>>> 	/* slave was reconnected to uart4 */
>>>>> 	slave {
>>>>> 		uart = <&uart4>;
>>>>> 	};
>>>>> };
>>>>
>>>> As I mentioned, you can easily carve up your DTS to make that work with
>>>> includes if you really must:
>>>>
>>>> /* UART0 board variant */
>>>> #include "board.dtsi"
>>>> &uart0 {
>>>> 	#include "some-uart-slave.dtsi"
>>>> };
>>>>
>>>> /* UART1 board variant */
>>>> #include "board.dtsi"
>>>> &uart1 {
>>>> 	#include "some-uart-slave.dtsi"
>>>> };
>>>>
>>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>>> functionally equivalent, and also means you can avoid having
>>>> disabled/partial nodes all over the place.
>>>
>>> Functionally equivalent would also be to copy the whole source file and
>>> s/&uart0/&uart1/.
>>>
>>> But this is not the best solution for the DT programmer since there is no
>>> automatic *reuse* of common parts.
>>>
>>> And your proposal requires 3 source files instead of 2 which deteriorates
>>> readibility and understanding what is really going on. And if you need to
>>> change the some-uart-slave, you have to touch a different file than for
>>> changing some other slave.
>>>
>>> Yes, it works, but IMHO other factors for a good design are also important.
>>>
>>> Maybe our main difference in PoV is that I specifically want to avoid that
>>> we force future DT programmers into “ugly” solutions (even if they work).
>>>
>>> If you think that DT programmers have to live with what they are
>>> given and do the best with it, we can end the discussion.
>>
>> The question of syntax is orthogonal to the discussion of the proper
>> devicetree representation.
>>
>> The awkwardness of expressing variants has nothing to do with the
>> appropriate device hierarchy (or whether there should be a hierarchy).
>> Describing variants is just as awkward when the parent-child relationship
>> is indisputable.
> 
> That is ok. But I still have not found the key rule when a parent-child relationship
> is indisputable. Candidates so far are “main interface” (which is still disputable)
> or “bus” (where we can dispute if a point-to-point connection is a “bus”).

Actually, at this point there is only one candidate, and that is the code
under review.


> But if both options are equally valid (maybe because there is no rule
> making either indisputable), I would chose the one with easier syntax.

There are many important criteria here.

1. Code complexity
2. Ease of adoption
3. Quality of abstraction
4. Extensibility

>> There was a recent discussion on devicetree ML regarding how best to
>> express and represent variance. Feel free to revive that discussion.
> 
> Does it help? Our core issue is not the syntax and variance per se. This are
> just examples to demonstrate differences in syntax of parent-child vs. phandle.
> 
> If we decide for either one, we have to live with syntactical and other
> implcationd.

The future implications of both the design and implementation need
careful consideration. That's why I'd like to see a v4.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
> 
> Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>>
>>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>>>> which uart.
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>>> can include under the correct node. That's trivial.
>>>>>>>
>>>>>>> But less readable. And that is important as well.
>>>>>>
>>>>>> I disagree. The manipulation you have to perform to override properties
>>>>>> is at least as bad as including a file.
>>>>>
>>>>> What about:
>>>>>
>>>>> #include "omap3-beagle-xm.dts"
>>>>>
>>>>> / {
>>>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>>>> 	hsusb2_power: hsusb2_power_reg {
>>>>> 		enable-active-high;
>>>>> 	};
>>>>> };
>>>>>
>>>>> compared to 
>>>>>
>>>>> #include “board1.dts”
>>>>>
>>>>> / {
>>>>> 	/* slave was reconnected to uart4 */
>>>>> 	slave {
>>>>> 		uart = <&uart4>;
>>>>> 	};
>>>>> };
>>>>
>>>> As I mentioned, you can easily carve up your DTS to make that work with
>>>> includes if you really must:
>>>>
>>>> /* UART0 board variant */
>>>> #include "board.dtsi"
>>>> &uart0 {
>>>> 	#include "some-uart-slave.dtsi"
>>>> };
>>>>
>>>> /* UART1 board variant */
>>>> #include "board.dtsi"
>>>> &uart1 {
>>>> 	#include "some-uart-slave.dtsi"
>>>> };
>>>>
>>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>>> functionally equivalent, and also means you can avoid having
>>>> disabled/partial nodes all over the place.
>>>
>>> Functionally equivalent would also be to copy the whole source file and
>>> s/&uart0/&uart1/.
>>>
>>> But this is not the best solution for the DT programmer since there is no
>>> automatic *reuse* of common parts.
>>>
>>> And your proposal requires 3 source files instead of 2 which deteriorates
>>> readibility and understanding what is really going on. And if you need to
>>> change the some-uart-slave, you have to touch a different file than for
>>> changing some other slave.
>>>
>>> Yes, it works, but IMHO other factors for a good design are also important.
>>>
>>> Maybe our main difference in PoV is that I specifically want to avoid that
>>> we force future DT programmers into “ugly” solutions (even if they work).
>>>
>>> If you think that DT programmers have to live with what they are
>>> given and do the best with it, we can end the discussion.
>>
>> The question of syntax is orthogonal to the discussion of the proper
>> devicetree representation.
>>
>> The awkwardness of expressing variants has nothing to do with the
>> appropriate device hierarchy (or whether there should be a hierarchy).
>> Describing variants is just as awkward when the parent-child relationship
>> is indisputable.
> 
> That is ok. But I still have not found the key rule when a parent-child relationship
> is indisputable. Candidates so far are “main interface” (which is still disputable)
> or “bus” (where we can dispute if a point-to-point connection is a “bus”).

Actually, at this point there is only one candidate, and that is the code
under review.


> But if both options are equally valid (maybe because there is no rule
> making either indisputable), I would chose the one with easier syntax.

There are many important criteria here.

1. Code complexity
2. Ease of adoption
3. Quality of abstraction
4. Extensibility

>> There was a recent discussion on devicetree ML regarding how best to
>> express and represent variance. Feel free to revive that discussion.
> 
> Does it help? Our core issue is not the syntax and variance per se. This are
> just examples to demonstrate differences in syntax of parent-child vs. phandle.
> 
> If we decide for either one, we have to live with syntactical and other
> implcationd.

The future implications of both the design and implementation need
careful consideration. That's why I'd like to see a v4.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 07.05.2015 um 18:18 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
>> 
>> Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>>> 
>>>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>>>>> which uart.
>>>>>>> 
>>>>>>> [...]
>>>>>>> 
>>>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>>>> can include under the correct node. That's trivial.
>>>>>>>> 
>>>>>>>> But less readable. And that is important as well.
>>>>>>> 
>>>>>>> I disagree. The manipulation you have to perform to override properties
>>>>>>> is at least as bad as including a file.
>>>>>> 
>>>>>> What about:
>>>>>> 
>>>>>> #include "omap3-beagle-xm.dts"
>>>>>> 
>>>>>> / {
>>>>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>>>>> 	hsusb2_power: hsusb2_power_reg {
>>>>>> 		enable-active-high;
>>>>>> 	};
>>>>>> };
>>>>>> 
>>>>>> compared to 
>>>>>> 
>>>>>> #include “board1.dts”
>>>>>> 
>>>>>> / {
>>>>>> 	/* slave was reconnected to uart4 */
>>>>>> 	slave {
>>>>>> 		uart = <&uart4>;
>>>>>> 	};
>>>>>> };
>>>>> 
>>>>> As I mentioned, you can easily carve up your DTS to make that work with
>>>>> includes if you really must:
>>>>> 
>>>>> /* UART0 board variant */
>>>>> #include "board.dtsi"
>>>>> &uart0 {
>>>>> 	#include "some-uart-slave.dtsi"
>>>>> };
>>>>> 
>>>>> /* UART1 board variant */
>>>>> #include "board.dtsi"
>>>>> &uart1 {
>>>>> 	#include "some-uart-slave.dtsi"
>>>>> };
>>>>> 
>>>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>>>> functionally equivalent, and also means you can avoid having
>>>>> disabled/partial nodes all over the place.
>>>> 
>>>> Functionally equivalent would also be to copy the whole source file and
>>>> s/&uart0/&uart1/.
>>>> 
>>>> But this is not the best solution for the DT programmer since there is no
>>>> automatic *reuse* of common parts.
>>>> 
>>>> And your proposal requires 3 source files instead of 2 which deteriorates
>>>> readibility and understanding what is really going on. And if you need to
>>>> change the some-uart-slave, you have to touch a different file than for
>>>> changing some other slave.
>>>> 
>>>> Yes, it works, but IMHO other factors for a good design are also important.
>>>> 
>>>> Maybe our main difference in PoV is that I specifically want to avoid that
>>>> we force future DT programmers into “ugly” solutions (even if they work).
>>>> 
>>>> If you think that DT programmers have to live with what they are
>>>> given and do the best with it, we can end the discussion.
>>> 
>>> The question of syntax is orthogonal to the discussion of the proper
>>> devicetree representation.
>>> 
>>> The awkwardness of expressing variants has nothing to do with the
>>> appropriate device hierarchy (or whether there should be a hierarchy).
>>> Describing variants is just as awkward when the parent-child relationship
>>> is indisputable.
>> 
>> That is ok. But I still have not found the key rule when a parent-child relationship
>> is indisputable. Candidates so far are “main interface” (which is still disputable)
>> or “bus” (where we can dispute if a point-to-point connection is a “bus”).
> 
> Actually, at this point there is only one candidate, and that is the code
> under review.

I meant two different candiates for DT bindings [PATCH 3/3]. Yes, the code
exists only for Neil’s proposal.

> 
>> But if both options are equally valid (maybe because there is no rule
>> making either indisputable), I would chose the one with easier syntax.
> 
> There are many important criteria here.
> 
> 1. Code complexity
> 2. Ease of adoption
> 3. Quality of abstraction
> 4. Extensibility

Yes. That is why I insist on discussing alternatives to show how good they
are wrt to such criteria and so far the discussion wasn’t that well structured
to have clear criteria in the beginning. Thanks.

> 
>>> There was a recent discussion on devicetree ML regarding how best to
>>> express and represent variance. Feel free to revive that discussion.
>> 
>> Does it help? Our core issue is not the syntax and variance per se. This are
>> just examples to demonstrate differences in syntax of parent-child vs. phandle.
>> 
>> If we decide for either one, we have to live with syntactical and other
>> implcationd.
> 
> The future implications of both the design and implementation need
> careful consideration. That's why I'd like to see a v4.

Yes, I appreciate that!

And if I find time, I will propose a v4-alternative.

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi,

Am 07.05.2015 um 18:18 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
>> 
>> Am 07.05.2015 um 16:30 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> 
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>> On Wed, May 06, 2015 at 05:09:20PM +0100, Dr. H. Nikolaus Schaller wrote:
>>>>>> Am 06.05.2015 um 16:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>>> 
>>>>>>>>>>>> No, I am not playing devil’s advocate (which would imply that I am doing this
>>>>>>>>>>>> for fun to tease the dog), but I feel I have to be the advocate of future board
>>>>>>>>>>>> designers who want to easily import an existing board DT and overwrite device
>>>>>>>>>>>> tree nodes to describe design changes, i.e. what slave device is connected to
>>>>>>>>>>>> which uart.
>>>>>>> 
>>>>>>> [...]
>>>>>>> 
>>>>>>>>> If this happens, you can move the slave device into a fragment that you
>>>>>>>>> can include under the correct node. That's trivial.
>>>>>>>> 
>>>>>>>> But less readable. And that is important as well.
>>>>>>> 
>>>>>>> I disagree. The manipulation you have to perform to override properties
>>>>>>> is at least as bad as including a file.
>>>>>> 
>>>>>> What about:
>>>>>> 
>>>>>> #include "omap3-beagle-xm.dts"
>>>>>> 
>>>>>> / {
>>>>>> 	/* HS USB Port 2 Power enable was inverted with the xM C */
>>>>>> 	hsusb2_power: hsusb2_power_reg {
>>>>>> 		enable-active-high;
>>>>>> 	};
>>>>>> };
>>>>>> 
>>>>>> compared to 
>>>>>> 
>>>>>> #include “board1.dts”
>>>>>> 
>>>>>> / {
>>>>>> 	/* slave was reconnected to uart4 */
>>>>>> 	slave {
>>>>>> 		uart = <&uart4>;
>>>>>> 	};
>>>>>> };
>>>>> 
>>>>> As I mentioned, you can easily carve up your DTS to make that work with
>>>>> includes if you really must:
>>>>> 
>>>>> /* UART0 board variant */
>>>>> #include "board.dtsi"
>>>>> &uart0 {
>>>>> 	#include "some-uart-slave.dtsi"
>>>>> };
>>>>> 
>>>>> /* UART1 board variant */
>>>>> #include "board.dtsi"
>>>>> &uart1 {
>>>>> 	#include "some-uart-slave.dtsi"
>>>>> };
>>>>> 
>>>>> If you happen to find includes ugly then you can say it's ugly, but it's
>>>>> functionally equivalent, and also means you can avoid having
>>>>> disabled/partial nodes all over the place.
>>>> 
>>>> Functionally equivalent would also be to copy the whole source file and
>>>> s/&uart0/&uart1/.
>>>> 
>>>> But this is not the best solution for the DT programmer since there is no
>>>> automatic *reuse* of common parts.
>>>> 
>>>> And your proposal requires 3 source files instead of 2 which deteriorates
>>>> readibility and understanding what is really going on. And if you need to
>>>> change the some-uart-slave, you have to touch a different file than for
>>>> changing some other slave.
>>>> 
>>>> Yes, it works, but IMHO other factors for a good design are also important.
>>>> 
>>>> Maybe our main difference in PoV is that I specifically want to avoid that
>>>> we force future DT programmers into “ugly” solutions (even if they work).
>>>> 
>>>> If you think that DT programmers have to live with what they are
>>>> given and do the best with it, we can end the discussion.
>>> 
>>> The question of syntax is orthogonal to the discussion of the proper
>>> devicetree representation.
>>> 
>>> The awkwardness of expressing variants has nothing to do with the
>>> appropriate device hierarchy (or whether there should be a hierarchy).
>>> Describing variants is just as awkward when the parent-child relationship
>>> is indisputable.
>> 
>> That is ok. But I still have not found the key rule when a parent-child relationship
>> is indisputable. Candidates so far are “main interface” (which is still disputable)
>> or “bus” (where we can dispute if a point-to-point connection is a “bus”).
> 
> Actually, at this point there is only one candidate, and that is the code
> under review.

I meant two different candiates for DT bindings [PATCH 3/3]. Yes, the code
exists only for Neil’s proposal.

> 
>> But if both options are equally valid (maybe because there is no rule
>> making either indisputable), I would chose the one with easier syntax.
> 
> There are many important criteria here.
> 
> 1. Code complexity
> 2. Ease of adoption
> 3. Quality of abstraction
> 4. Extensibility

Yes. That is why I insist on discussing alternatives to show how good they
are wrt to such criteria and so far the discussion wasn’t that well structured
to have clear criteria in the beginning. Thanks.

> 
>>> There was a recent discussion on devicetree ML regarding how best to
>>> express and represent variance. Feel free to revive that discussion.
>> 
>> Does it help? Our core issue is not the syntax and variance per se. This are
>> just examples to demonstrate differences in syntax of parent-child vs. phandle.
>> 
>> If we decide for either one, we have to live with syntactical and other
>> implcationd.
> 
> The future implications of both the design and implementation need
> careful consideration. That's why I'd like to see a v4.

Yes, I appreciate that!

And if I find time, I will propose a v4-alternative.

BR and thanks,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:

> So I don’t think that being able to control the slave is a common property
> of all UART-slave connections.
> 
> BTW: the GPS chip we use is doing something without any instructions. It starts
> to send NMEA records right after power on. It would even be useful with a unidirectional
> connection from GPS to UART. Hence there are no commands that need to be
> sent through UART. Rather it just needs some GPIO to be activated or powered down
> when /dev/tty is opened/closed.

In this example, the GPIO is a workaround for the lack of DTR.


> So one could argue that in this real case (which we try to solve in an acceptable way
> since 2 years) the fundamental/main interface (control command interface) of this chip
> is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”.

The indirect nature of control in this case only reflects the workaround,
not the underlying concept. Control is still derived from the UART status.

Both devicetree and tty/serial can already represent independent control;
what is proposed is a way to express dependent control, and in all cases,
that control stems directly from either the UART state itself or via
commands sent over that interface.

Any target not requiring UART involvement doesn't (and probably, shouldn't)
be expressed as a slave device.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:

> So I don’t think that being able to control the slave is a common property
> of all UART-slave connections.
> 
> BTW: the GPS chip we use is doing something without any instructions. It starts
> to send NMEA records right after power on. It would even be useful with a unidirectional
> connection from GPS to UART. Hence there are no commands that need to be
> sent through UART. Rather it just needs some GPIO to be activated or powered down
> when /dev/tty is opened/closed.

In this example, the GPIO is a workaround for the lack of DTR.


> So one could argue that in this real case (which we try to solve in an acceptable way
> since 2 years) the fundamental/main interface (control command interface) of this chip
> is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”.

The indirect nature of control in this case only reflects the workaround,
not the underlying concept. Control is still derived from the UART status.

Both devicetree and tty/serial can already represent independent control;
what is proposed is a way to express dependent control, and in all cases,
that control stems directly from either the UART state itself or via
commands sent over that interface.

Any target not requiring UART involvement doesn't (and probably, shouldn't)
be expressed as a slave device.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> 
>> So I don’t think that being able to control the slave is a common property
>> of all UART-slave connections.
>> 
>> BTW: the GPS chip we use is doing something without any instructions. It starts
>> to send NMEA records right after power on. It would even be useful with a unidirectional
>> connection from GPS to UART. Hence there are no commands that need to be
>> sent through UART. Rather it just needs some GPIO to be activated or powered down
>> when /dev/tty is opened/closed.
> 
> In this example, the GPIO is a workaround for the lack of DTR.

Yes.

Our long ago proposal was to use DTR - but this did lead to make the GPS driver
present a “virtual gpio”, that could have been plumbed to a dtr-gpio phandle of the uart
driver. The only reason is that some piece of code must pulse-shape the DTR
to be fed into the real GPS control pin.0

But I agree that we should not have such “virtual gpios”, since they are not needed
(in either approach we discuss now).

> 
> 
>> So one could argue that in this real case (which we try to solve in an acceptable way
>> since 2 years) the fundamental/main interface (control command interface) of this chip
>> is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”.
> 
> The indirect nature of control in this case only reflects the workaround,
> not the underlying concept. Control is still derived from the UART status.

> 
> Both devicetree and tty/serial can already represent independent control;
> what is proposed is a way to express dependent control, and in all cases,
> that control stems directly from either the UART state itself or via
> commands sent over that interface.

Yes. This is why I propose that the tty/uart driver can send an internal notification
to the device driver. And the device driver can register to be notified by the UART
that is identified by the phandle of the slave DT entry.

> 
> Any target not requiring UART involvement doesn't (and probably, shouldn't)
> be expressed as a slave device.

IMHO it is not obligatory to represent the direction of control by a parent>child
relation in DT. DT just needs to describe that there is a relation/connection.

The driver code already must “know” the direction of notifications.

BTW, there can even be control in reverse direction in some cases. E.g. the slave
driver wants to automatically set the baud rate of the uart, i.e. the slave controls
the uart on /dev/tty side.

If I have monitored some other discussion right, this is exactly done by a Codec
driver to tell its mcbsp counterpart about clock rates and data formats it should
expect. Maybe this is the reason why McBSP use (or are just happy with) the
phandle approach.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>:

> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> 
>> So I don’t think that being able to control the slave is a common property
>> of all UART-slave connections.
>> 
>> BTW: the GPS chip we use is doing something without any instructions. It starts
>> to send NMEA records right after power on. It would even be useful with a unidirectional
>> connection from GPS to UART. Hence there are no commands that need to be
>> sent through UART. Rather it just needs some GPIO to be activated or powered down
>> when /dev/tty is opened/closed.
> 
> In this example, the GPIO is a workaround for the lack of DTR.

Yes.

Our long ago proposal was to use DTR - but this did lead to make the GPS driver
present a “virtual gpio”, that could have been plumbed to a dtr-gpio phandle of the uart
driver. The only reason is that some piece of code must pulse-shape the DTR
to be fed into the real GPS control pin.0

But I agree that we should not have such “virtual gpios”, since they are not needed
(in either approach we discuss now).

> 
> 
>> So one could argue that in this real case (which we try to solve in an acceptable way
>> since 2 years) the fundamental/main interface (control command interface) of this chip
>> is the power on/off line. And UART isn’t involved at all. Or just as an “activity detector”.
> 
> The indirect nature of control in this case only reflects the workaround,
> not the underlying concept. Control is still derived from the UART status.

> 
> Both devicetree and tty/serial can already represent independent control;
> what is proposed is a way to express dependent control, and in all cases,
> that control stems directly from either the UART state itself or via
> commands sent over that interface.

Yes. This is why I propose that the tty/uart driver can send an internal notification
to the device driver. And the device driver can register to be notified by the UART
that is identified by the phandle of the slave DT entry.

> 
> Any target not requiring UART involvement doesn't (and probably, shouldn't)
> be expressed as a slave device.

IMHO it is not obligatory to represent the direction of control by a parent>child
relation in DT. DT just needs to describe that there is a relation/connection.

The driver code already must “know” the direction of notifications.

BTW, there can even be control in reverse direction in some cases. E.g. the slave
driver wants to automatically set the baud rate of the uart, i.e. the slave controls
the uart on /dev/tty side.

If I have monitored some other discussion right, this is exactly done by a Codec
driver to tell its mcbsp counterpart about clock rates and data formats it should
expect. Maybe this is the reason why McBSP use (or are just happy with) the
phandle approach.

BR,
Nikolaus

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:

>> Both devicetree and tty/serial can already represent independent control;
>> what is proposed is a way to express dependent control, and in all cases,
>> that control stems directly from either the UART state itself or via
>> commands sent over that interface.
> 
> Yes. This is why I propose that the tty/uart driver can send an internal notification
> to the device driver. And the device driver can register to be notified by the UART
> that is identified by the phandle of the slave DT entry.

I've not seen any code with your proposal, so that makes it impossible to
compare competing solutions.


>> Any target not requiring UART involvement doesn't (and probably, shouldn't)
>> be expressed as a slave device.
> 
> IMHO it is not obligatory to represent the direction of control by a parent>child
> relation in DT. DT just needs to describe that there is a relation/connection.

Devicetree usage in the linux kernel is for representing the host view, not an
abstract machine. I have yet to see an example of a proposed tty slave where the
host interface is not a UART.

> The driver code already must “know” the direction of notifications.
> 
> BTW, there can even be control in reverse direction in some cases. E.g. the slave
> driver wants to automatically set the baud rate of the uart, i.e. the slave controls
> the uart on /dev/tty side.
> 
> If I have monitored some other discussion right, this is exactly done by a Codec
> driver to tell its mcbsp counterpart about clock rates and data formats it should
> expect. Maybe this is the reason why McBSP use (or are just happy with) the
> phandle approach.

Parameters are not control.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:
>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:

>> Both devicetree and tty/serial can already represent independent control;
>> what is proposed is a way to express dependent control, and in all cases,
>> that control stems directly from either the UART state itself or via
>> commands sent over that interface.
> 
> Yes. This is why I propose that the tty/uart driver can send an internal notification
> to the device driver. And the device driver can register to be notified by the UART
> that is identified by the phandle of the slave DT entry.

I've not seen any code with your proposal, so that makes it impossible to
compare competing solutions.


>> Any target not requiring UART involvement doesn't (and probably, shouldn't)
>> be expressed as a slave device.
> 
> IMHO it is not obligatory to represent the direction of control by a parent>child
> relation in DT. DT just needs to describe that there is a relation/connection.

Devicetree usage in the linux kernel is for representing the host view, not an
abstract machine. I have yet to see an example of a proposed tty slave where the
host interface is not a UART.

> The driver code already must “know” the direction of notifications.
> 
> BTW, there can even be control in reverse direction in some cases. E.g. the slave
> driver wants to automatically set the baud rate of the uart, i.e. the slave controls
> the uart on /dev/tty side.
> 
> If I have monitored some other discussion right, this is exactly done by a Codec
> driver to tell its mcbsp counterpart about clock rates and data formats it should
> expect. Maybe this is the reason why McBSP use (or are just happy with) the
> phandle approach.

Parameters are not control.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 07.05.2015 um 17:51 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> 
>>> Both devicetree and tty/serial can already represent independent control;
>>> what is proposed is a way to express dependent control, and in all cases,
>>> that control stems directly from either the UART state itself or via
>>> commands sent over that interface.
>> 
>> Yes. This is why I propose that the tty/uart driver can send an internal notification
>> to the device driver. And the device driver can register to be notified by the UART
>> that is identified by the phandle of the slave DT entry.
> 
> I've not seen any code with your proposal, so that makes it impossible to
> compare competing solutions.

If you can give me some (unspecified) time to do it, I can write (simplified) patches
to demonstrate the idea.

I just hesitate to work out and submit a counter proposal to what Neil has submitted,
because it will become wasted effort if it is rejected before I am finished.

> 
> 
>>> Any target not requiring UART involvement doesn't (and probably, shouldn't)
>>> be expressed as a slave device.
>> 
>> IMHO it is not obligatory to represent the direction of control by a parent>child
>> relation in DT. DT just needs to describe that there is a relation/connection.
> 
> Devicetree usage in the linux kernel is for representing the host view, not an
> abstract machine. I have yet to see an example of a proposed tty slave where the
> host interface is not a UART.

So far, I am only aware of two devices proposed to be tty power controlled slaves:
* our GPS chip and
* several Bluetooth modules (using HCI).

It is difficult to predict future use cases and systems.

With some phantasy there could be some I2C controlled serial level shifter that
translates uart RX/TX/RTS/CTS to RS232 levels but allows for pin swapping (null modem).
Power control of that chip is done through I2C. Similar chips exist for headset pinout
detection ans automatic swapping, e.g. TS3A225E.

Or some Infrared (IrDA) transceiver with mode and power control over I2C.

Such a device should probably be described as a child node of the I2C bus it is
connected to. And the driver must become an i2c device driver. So this would be
in conflict with tty slave child nodes - but no problem with a phandle to the uart.

> 
>> The driver code already must “know” the direction of notifications.
>> 
>> BTW, there can even be control in reverse direction in some cases. E.g. the slave
>> driver wants to automatically set the baud rate of the uart, i.e. the slave controls
>> the uart on /dev/tty side.
>> 
>> If I have monitored some other discussion right, this is exactly done by a Codec
>> driver to tell its mcbsp counterpart about clock rates and data formats it should
>> expect. Maybe this is the reason why McBSP use (or are just happy with) the
>> phandle approach.
> 
> Parameters are not control.

Agreed. Especially if you mean power control.

But does it change the necessity to describe the control direction in the DT as parent>child?

In many other situations power control is described by regulator phandles and the regulators
are not children of the controlling DT node.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 07.05.2015 um 17:51 schrieb Peter Hurley <peter@hurleysoftware.com>:

> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> 
>>> Both devicetree and tty/serial can already represent independent control;
>>> what is proposed is a way to express dependent control, and in all cases,
>>> that control stems directly from either the UART state itself or via
>>> commands sent over that interface.
>> 
>> Yes. This is why I propose that the tty/uart driver can send an internal notification
>> to the device driver. And the device driver can register to be notified by the UART
>> that is identified by the phandle of the slave DT entry.
> 
> I've not seen any code with your proposal, so that makes it impossible to
> compare competing solutions.

If you can give me some (unspecified) time to do it, I can write (simplified) patches
to demonstrate the idea.

I just hesitate to work out and submit a counter proposal to what Neil has submitted,
because it will become wasted effort if it is rejected before I am finished.

> 
> 
>>> Any target not requiring UART involvement doesn't (and probably, shouldn't)
>>> be expressed as a slave device.
>> 
>> IMHO it is not obligatory to represent the direction of control by a parent>child
>> relation in DT. DT just needs to describe that there is a relation/connection.
> 
> Devicetree usage in the linux kernel is for representing the host view, not an
> abstract machine. I have yet to see an example of a proposed tty slave where the
> host interface is not a UART.

So far, I am only aware of two devices proposed to be tty power controlled slaves:
* our GPS chip and
* several Bluetooth modules (using HCI).

It is difficult to predict future use cases and systems.

With some phantasy there could be some I2C controlled serial level shifter that
translates uart RX/TX/RTS/CTS to RS232 levels but allows for pin swapping (null modem).
Power control of that chip is done through I2C. Similar chips exist for headset pinout
detection ans automatic swapping, e.g. TS3A225E.

Or some Infrared (IrDA) transceiver with mode and power control over I2C.

Such a device should probably be described as a child node of the I2C bus it is
connected to. And the driver must become an i2c device driver. So this would be
in conflict with tty slave child nodes - but no problem with a phandle to the uart.

> 
>> The driver code already must “know” the direction of notifications.
>> 
>> BTW, there can even be control in reverse direction in some cases. E.g. the slave
>> driver wants to automatically set the baud rate of the uart, i.e. the slave controls
>> the uart on /dev/tty side.
>> 
>> If I have monitored some other discussion right, this is exactly done by a Codec
>> driver to tell its mcbsp counterpart about clock rates and data formats it should
>> expect. Maybe this is the reason why McBSP use (or are just happy with) the
>> phandle approach.
> 
> Parameters are not control.

Agreed. Especially if you mean power control.

But does it change the necessity to describe the control direction in the DT as parent>child?

In many other situations power control is described by regulator phandles and the regulators
are not children of the controlling DT node.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 07.05.2015 um 18:46 schrieb Dr. H. Nikolaus Schaller <hns@goldelico.com>:

> Hi Peter,
> 
> Am 07.05.2015 um 17:51 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>> 
>>>> Both devicetree and tty/serial can already represent independent control;
>>>> what is proposed is a way to express dependent control, and in all cases,
>>>> that control stems directly from either the UART state itself or via
>>>> commands sent over that interface.
>>> 
>>> Yes. This is why I propose that the tty/uart driver can send an internal notification
>>> to the device driver. And the device driver can register to be notified by the UART
>>> that is identified by the phandle of the slave DT entry.
>> 
>> I've not seen any code with your proposal, so that makes it impossible to
>> compare competing solutions.
> 
> If you can give me some (unspecified) time to do it, I can write (simplified) patches
> to demonstrate the idea.
> 
> I just hesitate to work out and submit a counter proposal to what Neil has submitted,
> because it will become wasted effort if it is rejected before I am finished.

We have progress and some code on our workbench that identifies the uart_port by
phandle, resolves probing sequence and intercepts uart_update_mctrl calls. So we
can let the attached slave driver know that the DTR line has changed, which is
typically the power-on/off signal on UART/RS232. The driver can then power manage
the device as needed (GPIO state, GPIO pulses, regulator, I2C or whatever).

What we have not yet solved is the issue that a slave driver might want to know
that the controlled slave device is active (i.e. is autonomously sending data to the
UART). Even if the tty is not open. But we have an rough idea how we want to solve
that.

Patches will come asap.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Peter,

Am 07.05.2015 um 18:46 schrieb Dr. H. Nikolaus Schaller <hns@goldelico.com>:

> Hi Peter,
> 
> Am 07.05.2015 um 17:51 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 07.05.2015 um 16:56 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>> 
>>>> Both devicetree and tty/serial can already represent independent control;
>>>> what is proposed is a way to express dependent control, and in all cases,
>>>> that control stems directly from either the UART state itself or via
>>>> commands sent over that interface.
>>> 
>>> Yes. This is why I propose that the tty/uart driver can send an internal notification
>>> to the device driver. And the device driver can register to be notified by the UART
>>> that is identified by the phandle of the slave DT entry.
>> 
>> I've not seen any code with your proposal, so that makes it impossible to
>> compare competing solutions.
> 
> If you can give me some (unspecified) time to do it, I can write (simplified) patches
> to demonstrate the idea.
> 
> I just hesitate to work out and submit a counter proposal to what Neil has submitted,
> because it will become wasted effort if it is rejected before I am finished.

We have progress and some code on our workbench that identifies the uart_port by
phandle, resolves probing sequence and intercepts uart_update_mctrl calls. So we
can let the attached slave driver know that the DTR line has changed, which is
typically the power-on/off signal on UART/RS232. The driver can then power manage
the device as needed (GPIO state, GPIO pulses, regulator, I2C or whatever).

What we have not yet solved is the issue that a slave driver might want to know
that the controlled slave device is active (i.e. is autonomously sending data to the
UART). Even if the tty is not open. But we have an rough idea how we want to solve
that.

Patches will come asap.

BR,
Nikolaus

[PATCH RFC 0/3] UART slave device support

[Dr. H. Nikolaus Schaller]

Hi all,
this patch series is our proposal to add hooks so that the driver for a device connected to an UART can
monitor modem control lines and data activity of the connected chip.

It contains an example for such a device driver which needs such sophisticated power control: wi2wi,w2sg0004

A remote device connected to a RS232 interface is usually power controlled by the DTR line.
The DTR line is managed automatically by the UART driver for open() and close() syscalls
and on demand by tcsetattr().

With embedded devices, the serial peripheral might be directly and always connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to be done by some
chip specific device driver (which we call "UART slave") through some mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state except by sending
or not sending data to the UART. In such a case the device driver must be able to monitor data
activity. The role of the device driver is to encapsulate such power control in a single place.

This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART

A slave device tree entry simply adds a phandle reference to the UART it is connected to, e.g.

	gps {
		compatible = "wi2wi,w2sg0004";
		uart = <&uart1>;
	};

The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart driver.
devm_serial_get_uart_by_phandle() follows the concept of devm_usb_get_phy_by_phandle().

A slave device driver registers itself with serial_register_slave() to receive notifications.
Notification handlers can be registered by serial_register_mctrl_notification() and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL handler registered,
no notifications are sent.

RX notification handlers can define a ktermios setup and modify or decide to throw away the
character that is passed upwards.

This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself as a "virtual
GPIO". The idea of a "virtual GPIO"  is not compatible with the concept that DT must
describe hardware (and not virtual hardware). So in this new solution DT only describes that
the w2sg0004 is connected to some UART and how the power state signalling works is left
to the driver implementations.

The rx data notification also removes the concept of having two different pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might even be
extensible that the chip driver could filter or consume the rx data before it is passed
to the tty layer.

This patch works on linux-next as intended except one major weakness: we have to call 
uart_change_speed() each time we open the tty. This is the opposite of what we would like
to have: that the slave initializes the uart speed through some termios and the tty level just uses
this setting. We have not yet completely understood how to make this work and are happy
about help in this area.

And of course we would like to see general comments about the whole implementation
approach.


Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>

[PATCH RFC 0/3] UART slave device support

[Dr. H. Nikolaus Schaller]

Hi all,
this patch series is our proposal to add hooks so that the driver for a device connected to an UART can
monitor modem control lines and data activity of the connected chip.

It contains an example for such a device driver which needs such sophisticated power control: wi2wi,w2sg0004

A remote device connected to a RS232 interface is usually power controlled by the DTR line.
The DTR line is managed automatically by the UART driver for open() and close() syscalls
and on demand by tcsetattr().

With embedded devices, the serial peripheral might be directly and always connected to the UART
and there might be no physical DTR line involved. Power control (on/off) has to be done by some
chip specific device driver (which we call "UART slave") through some mechanisms (I2C, GPIOs etc.)
not related to the serial interface. Some devices do not tell their power state except by sending
or not sending data to the UART. In such a case the device driver must be able to monitor data
activity. The role of the device driver is to encapsulate such power control in a single place.

This patch series allows to support such UART slave drivers by providing:
* a mechanism that a slave driver can identify the UART instance it is connected to
* a mechanism that UART slave drivers can register to be notified
* notfications for DTR (and other modem control) state changes
* notifications that the device has sent some data to the UART

A slave device tree entry simply adds a phandle reference to the UART it is connected to, e.g.

	gps {
		compatible = "wi2wi,w2sg0004";
		uart = <&uart1>;
	};

The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart driver.
devm_serial_get_uart_by_phandle() follows the concept of devm_usb_get_phy_by_phandle().

A slave device driver registers itself with serial_register_slave() to receive notifications.
Notification handlers can be registered by serial_register_mctrl_notification() and
serial_register_rx_notification(). If an UART has a NULL slave or a NULL handler registered,
no notifications are sent.

RX notification handlers can define a ktermios setup and modify or decide to throw away the
character that is passed upwards.

This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want to add an optional
GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself as a "virtual
GPIO". The idea of a "virtual GPIO"  is not compatible with the concept that DT must
describe hardware (and not virtual hardware). So in this new solution DT only describes that
the w2sg0004 is connected to some UART and how the power state signalling works is left
to the driver implementations.

The rx data notification also removes the concept of having two different pinmux states
and make the w2sg0004 driver intercept rx activities by switching the rx line to a GPIO
interrupt. This was very OMAP3 specific. The new solution is generic and might even be
extensible that the chip driver could filter or consume the rx data before it is passed
to the tty layer.

This patch works on linux-next as intended except one major weakness: we have to call 
uart_change_speed() each time we open the tty. This is the opposite of what we would like
to have: that the slave initializes the uart speed through some termios and the tty level just uses
this setting. We have not yet completely understood how to make this work and are happy
about help in this area.

And of course we would like to see general comments about the whole implementation
approach.


Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>

Re: [PATCH RFC 0/3] UART slave device support

[Pavel Machek]

On Wed 2015-06-03 13:49:30, Dr. H. Nikolaus Schaller wrote:
> Hi all,
> this patch series is our proposal to add hooks so that the driver for a device connected to an UART can
> monitor modem control lines and data activity of the connected chip.
> 
> It contains an example for such a device driver which needs such sophisticated power control: wi2wi,w2sg0004
> 
> A remote device connected to a RS232 interface is usually power controlled by the DTR line.
> The DTR line is managed automatically by the UART driver for open() and close() syscalls
> and on demand by tcsetattr().
> 
> With embedded devices, the serial peripheral might be directly and always connected to the UART
> and there might be no physical DTR line involved. Power control (on/off) has to be done by some
> chip specific device driver (which we call "UART slave") through some mechanisms (I2C, GPIOs etc.)
> not related to the serial interface. Some devices do not tell their power state except by sending
> or not sending data to the UART. In such a case the device driver must be able to monitor data
> activity. The role of the device driver is to encapsulate such power control in a single place.
> 
> This patch series allows to support such UART slave drivers by providing:
> * a mechanism that a slave driver can identify the UART instance it is connected to
> * a mechanism that UART slave drivers can register to be notified
> * notfications for DTR (and other modem control) state changes
> * notifications that the device has sent some data to the UART
> 
> A slave device tree entry simply adds a phandle reference to the UART it is connected to, e.g.
> 
> 	gps {
> 		compatible = "wi2wi,w2sg0004";
> 		uart = <&uart1>;
> 	};

Device tree maintainers repeatedly pointed out this is not a way to go.

NAK.

										Pavel

> 
> The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart driver.
> devm_serial_get_uart_by_phandle() follows the concept of devm_usb_get_phy_by_phandle().
> 
> A slave device driver registers itself with serial_register_slave() to receive notifications.
> Notification handlers can be registered by serial_register_mctrl_notification() and
> serial_register_rx_notification(). If an UART has a NULL slave or a NULL handler registered,
> no notifications are sent.
> 
> RX notification handlers can define a ktermios setup and modify or decide to throw away the
> character that is passed upwards.
> 
> This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want to add an optional
> GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself as a "virtual
> GPIO". The idea of a "virtual GPIO"  is not compatible with the concept that DT must
> describe hardware (and not virtual hardware). So in this new solution DT only describes that
> the w2sg0004 is connected to some UART and how the power state signalling works is left
> to the driver implementations.
> 
> The rx data notification also removes the concept of having two different pinmux states
> and make the w2sg0004 driver intercept rx activities by switching the rx line to a GPIO
> interrupt. This was very OMAP3 specific. The new solution is generic and might even be
> extensible that the chip driver could filter or consume the rx data before it is passed
> to the tty layer.
> 
> This patch works on linux-next as intended except one major weakness: we have to call 
> uart_change_speed() each time we open the tty. This is the opposite of what we would like
> to have: that the slave initializes the uart speed through some termios and the tty level just uses
> this setting. We have not yet completely understood how to make this work and are happy
> about help in this area.
> 
> And of course we would like to see general comments about the whole implementation
> approach.
> 
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH RFC 0/3] UART slave device support

[Pavel Machek]

On Wed 2015-06-03 13:49:30, Dr. H. Nikolaus Schaller wrote:
> Hi all,
> this patch series is our proposal to add hooks so that the driver for a device connected to an UART can
> monitor modem control lines and data activity of the connected chip.
> 
> It contains an example for such a device driver which needs such sophisticated power control: wi2wi,w2sg0004
> 
> A remote device connected to a RS232 interface is usually power controlled by the DTR line.
> The DTR line is managed automatically by the UART driver for open() and close() syscalls
> and on demand by tcsetattr().
> 
> With embedded devices, the serial peripheral might be directly and always connected to the UART
> and there might be no physical DTR line involved. Power control (on/off) has to be done by some
> chip specific device driver (which we call "UART slave") through some mechanisms (I2C, GPIOs etc.)
> not related to the serial interface. Some devices do not tell their power state except by sending
> or not sending data to the UART. In such a case the device driver must be able to monitor data
> activity. The role of the device driver is to encapsulate such power control in a single place.
> 
> This patch series allows to support such UART slave drivers by providing:
> * a mechanism that a slave driver can identify the UART instance it is connected to
> * a mechanism that UART slave drivers can register to be notified
> * notfications for DTR (and other modem control) state changes
> * notifications that the device has sent some data to the UART
> 
> A slave device tree entry simply adds a phandle reference to the UART it is connected to, e.g.
> 
> 	gps {
> 		compatible = "wi2wi,w2sg0004";
> 		uart = <&uart1>;
> 	};

Device tree maintainers repeatedly pointed out this is not a way to go.

NAK.

										Pavel

> 
> The slave driver calls devm_serial_get_uart_by_phandle() to identify the uart driver.
> devm_serial_get_uart_by_phandle() follows the concept of devm_usb_get_phy_by_phandle().
> 
> A slave device driver registers itself with serial_register_slave() to receive notifications.
> Notification handlers can be registered by serial_register_mctrl_notification() and
> serial_register_rx_notification(). If an UART has a NULL slave or a NULL handler registered,
> no notifications are sent.
> 
> RX notification handlers can define a ktermios setup and modify or decide to throw away the
> character that is passed upwards.
> 
> This all is a follow-up to the w2sg0004 driver submitted in 2014 that did want to add an optional
> GPIO to DTR in omap-serial.c and required the w2sg0004 driver to present itself as a "virtual
> GPIO". The idea of a "virtual GPIO"  is not compatible with the concept that DT must
> describe hardware (and not virtual hardware). So in this new solution DT only describes that
> the w2sg0004 is connected to some UART and how the power state signalling works is left
> to the driver implementations.
> 
> The rx data notification also removes the concept of having two different pinmux states
> and make the w2sg0004 driver intercept rx activities by switching the rx line to a GPIO
> interrupt. This was very OMAP3 specific. The new solution is generic and might even be
> extensible that the chip driver could filter or consume the rx data before it is passed
> to the tty layer.
> 
> This patch works on linux-next as intended except one major weakness: we have to call 
> uart_change_speed() each time we open the tty. This is the opposite of what we would like
> to have: that the slave initializes the uart speed through some termios and the tty level just uses
> this setting. We have not yet completely understood how to make this work and are happy
> about help in this area.
> 
> And of course we would like to see general comments about the whole implementation
> approach.
> 
> 
> Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH RFC 3/3] misc: Add w2g0004 gps receiver driver

[Christ van Willegen]

Hi all,

On Wed, Jun 3, 2015 at 1:51 PM, Dr. H. Nikolaus Schaller
<hns@goldelico.com> wrote:
> Add driver for Wi2Wi w2g004 GPS module connected through  uart. Use uart
> slave + notification hooks to glue with tty.

Just a _very_ minor documentation nit-pick here:

> +config W2SG0004
> +       tristate "W2SG0004 on/off control"
> +       depends on GPIOLIB
> +       help
> +         Enable on/off control of W2SG0004 GPS using a tty slave to
> +         to allow powering up if the /dev/tty$n is opened.

The 'to' at the start of the 2nd line here is better removed.

Christ van Willegen

Re: [Gta04-owner] [PATCH RFC 3/3] misc: Add w2g0004 gps receiver driver

[Christ van Willegen]

Hi all,

On Wed, Jun 3, 2015 at 1:51 PM, Dr. H. Nikolaus Schaller
<hns@goldelico.com> wrote:
> Add driver for Wi2Wi w2g004 GPS module connected through  uart. Use uart
> slave + notification hooks to glue with tty.

Just a _very_ minor documentation nit-pick here:

> +config W2SG0004
> +       tristate "W2SG0004 on/off control"
> +       depends on GPIOLIB
> +       help
> +         Enable on/off control of W2SG0004 GPS using a tty slave to
> +         to allow powering up if the /dev/tty$n is opened.

The 'to' at the start of the 2nd line here is better removed.

Christ van Willegen

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/06/2015 09:28 AM, Dr. H. Nikolaus Schaller wrote:

> The key point appears to be how we want to see the serial connection. Is the
> device connected to the uart or the uart to a device?
> 
> In OO terminology: „device connects to uart“ vs. „uart has device connected“.
> "d -> u“ vs. "u <- d“.

This is not a very good analogy because both relationships need to be
represented.

The practical consideration is the lifetime of the target device.
If the target device should/must have a lifetime (as viewed from the host)
outside that of the uart, then the target device should not be a slave device.

Object lifetime is controlled by expressions of ownership or scope.
Since devicetree offers no expression of ownership, scope is the
obvious and natural way to control lifetime.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

On 05/06/2015 09:28 AM, Dr. H. Nikolaus Schaller wrote:

> The key point appears to be how we want to see the serial connection. Is the
> device connected to the uart or the uart to a device?
> 
> In OO terminology: „device connects to uart“ vs. „uart has device connected“.
> "d -> u“ vs. "u <- d“.

This is not a very good analogy because both relationships need to be
represented.

The practical consideration is the lifetime of the target device.
If the target device should/must have a lifetime (as viewed from the host)
outside that of the uart, then the target device should not be a slave device.

Object lifetime is controlled by expressions of ownership or scope.
Since devicetree offers no expression of ownership, scope is the
obvious and natural way to control lifetime.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

On Wed 2015-05-06 13:50:29, Dr. H. Nikolaus Schaller wrote:
> Hi Pavel,
> 
> Am 06.05.2015 um 11:27 schrieb Pavel Machek <pavel@ucw.cz>:
> 
> > On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
> >> Hi Peter,
> >> 
> >> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
> >> 
> >>> Hi Neil,
> >>> 
> >>> On 03/18/2015 01:58 AM, NeilBrown wrote:
> >>>> here is version 3 of support for tty-slaves.
> >>> 
> >>> Is there a v4 of this that I missed?
> >> 
> >> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> >> represent the slave device in the device tree but as far as I am concerned,
> >> I do not see that we have a consensus (2) and the device tree maintainers
> >> have no comments or clear guidelines so far.
> > 
> > Yes. Everyone and their dog disagrees
> 
> What a wonderful argument…
> I still ask myself who the dog is.

Ok, so now device tree maintainers spoke and told you, you are wrong,
and you still argue? You'll only attrack more "wonderful" arguments
that way.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

On Wed 2015-05-06 13:50:29, Dr. H. Nikolaus Schaller wrote:
> Hi Pavel,
> 
> Am 06.05.2015 um 11:27 schrieb Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>:
> 
> > On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
> >> Hi Peter,
> >> 
> >> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
> >> 
> >>> Hi Neil,
> >>> 
> >>> On 03/18/2015 01:58 AM, NeilBrown wrote:
> >>>> here is version 3 of support for tty-slaves.
> >>> 
> >>> Is there a v4 of this that I missed?
> >> 
> >> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> >> represent the slave device in the device tree but as far as I am concerned,
> >> I do not see that we have a consensus (2) and the device tree maintainers
> >> have no comments or clear guidelines so far.
> > 
> > Yes. Everyone and their dog disagrees
> 
> What a wonderful argument…
> I still ask myself who the dog is.

Ok, so now device tree maintainers spoke and told you, you are wrong,
and you still argue? You'll only attrack more "wonderful" arguments
that way.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 06.05.2015 um 16:28 schrieb Pavel Machek <pavel@ucw.cz>:

> On Wed 2015-05-06 13:50:29, Dr. H. Nikolaus Schaller wrote:
>> Hi Pavel,
>> 
>> Am 06.05.2015 um 11:27 schrieb Pavel Machek <pavel@ucw.cz>:
>> 
>>> On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
>>>> Hi Peter,
>>>> 
>>>> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>>> 
>>>>> Hi Neil,
>>>>> 
>>>>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>>>>> here is version 3 of support for tty-slaves.
>>>>> 
>>>>> Is there a v4 of this that I missed?
>>>> 
>>>> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
>>>> represent the slave device in the device tree but as far as I am concerned,
>>>> I do not see that we have a consensus (2) and the device tree maintainers
>>>> have no comments or clear guidelines so far.
>>> 
>>> Yes. Everyone and their dog disagrees
>> 
>> What a wonderful argument…
>> I still ask myself who the dog is.
> 
> Ok, so now device tree maintainers spoke and told you, you are wrong,

did they already say that and have more convincing arguments? So far I have
always identified a flaw in the argumentation or a contradiction with practice
(e.g. busses are usually addressable, McBSP and PHY do uses phandle and
not subnodes).

> and you still argue?

And as long as I think the others are still wrong (focussed to see and model
UART like a “bus”), I tell them and explain my arguments where and why I
disagree with what they say or propose.

Especially if I feel that their arguments are not technically convincing (me).

Although all this is less about technical solutions but design principles:
what makes a good DT design.

Well, Linux will survive with any solution, but what are you interested in?

Users/contributors who keep quiet and accept a bad solution or those
who argue for a (initially in their opinion) better one?

Or stop as soon as Pavel says to do so?


> You'll only attrack more "wonderful" arguments
> that way.

None was “wonderful”. They were valid concerns about my proposal
and I have replied to them how I see it.

Generally, if you are not interested in people dedicated and committed to
fight for the better solution with (technical) arguments and concrete proposals
how it should be in their opinion, then please just tell and I will shut up.
But only then.

Or if some DT maintainer makes a decision and says: I have listened and
understood all arguments pro and con and I decide this or that way (preferrably
with giving reasons of decision as a guidance for similar problems in the future).

Then we all can go to implementation.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Dr. H. Nikolaus Schaller]

Hi Pavel,

Am 06.05.2015 um 16:28 schrieb Pavel Machek <pavel@ucw.cz>:

> On Wed 2015-05-06 13:50:29, Dr. H. Nikolaus Schaller wrote:
>> Hi Pavel,
>> 
>> Am 06.05.2015 um 11:27 schrieb Pavel Machek <pavel@ucw.cz>:
>> 
>>> On Wed 2015-05-06 07:19:31, Dr. H. Nikolaus Schaller wrote:
>>>> Hi Peter,
>>>> 
>>>> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
>>>> 
>>>>> Hi Neil,
>>>>> 
>>>>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>>>>> here is version 3 of support for tty-slaves.
>>>>> 
>>>>> Is there a v4 of this that I missed?
>>>> 
>>>> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
>>>> represent the slave device in the device tree but as far as I am concerned,
>>>> I do not see that we have a consensus (2) and the device tree maintainers
>>>> have no comments or clear guidelines so far.
>>> 
>>> Yes. Everyone and their dog disagrees
>> 
>> What a wonderful argument…
>> I still ask myself who the dog is.
> 
> Ok, so now device tree maintainers spoke and told you, you are wrong,

did they already say that and have more convincing arguments? So far I have
always identified a flaw in the argumentation or a contradiction with practice
(e.g. busses are usually addressable, McBSP and PHY do uses phandle and
not subnodes).

> and you still argue?

And as long as I think the others are still wrong (focussed to see and model
UART like a “bus”), I tell them and explain my arguments where and why I
disagree with what they say or propose.

Especially if I feel that their arguments are not technically convincing (me).

Although all this is less about technical solutions but design principles:
what makes a good DT design.

Well, Linux will survive with any solution, but what are you interested in?

Users/contributors who keep quiet and accept a bad solution or those
who argue for a (initially in their opinion) better one?

Or stop as soon as Pavel says to do so?


> You'll only attrack more "wonderful" arguments
> that way.

None was “wonderful”. They were valid concerns about my proposal
and I have replied to them how I see it.

Generally, if you are not interested in people dedicated and committed to
fight for the better solution with (technical) arguments and concrete proposals
how it should be in their opinion, then please just tell and I will shut up.
But only then.

Or if some DT maintainer makes a decision and says: I have listened and
understood all arguments pro and con and I decide this or that way (preferrably
with giving reasons of decision as a guidance for similar problems in the future).

Then we all can go to implementation.

BR,
Nikolaus

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

Hi!

> None was ?wonderful?. They were valid concerns about my proposal
> and I have replied to them how I see it.
> 
> Generally, if you are not interested in people dedicated and committed to
> fight for the better solution with (technical) arguments and concrete proposals
> how it should be in their opinion, then please just tell and I will shut up.
> But only then.

Whatever, if it makes you shut up:

I'm not interested in <fill in the blanks here>.

> Or if some DT maintainer makes a decision and says: I have listened and
> understood all arguments pro and con and I decide this or that way (preferrably
> with giving reasons of decision as a guidance for similar problems in the future).

The DT maintainers are saying just that for 10 mails now, as anybody who understands
english will agree.

You are behaving like a troll. Go away.

										Pavel 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Pavel Machek]

Hi!

> None was ?wonderful?. They were valid concerns about my proposal
> and I have replied to them how I see it.
> 
> Generally, if you are not interested in people dedicated and committed to
> fight for the better solution with (technical) arguments and concrete proposals
> how it should be in their opinion, then please just tell and I will shut up.
> But only then.

Whatever, if it makes you shut up:

I'm not interested in <fill in the blanks here>.

> Or if some DT maintainer makes a decision and says: I have listened and
> understood all arguments pro and con and I decide this or that way (preferrably
> with giving reasons of decision as a guidance for similar problems in the future).

The DT maintainers are saying just that for 10 mails now, as anybody who understands
english will agree.

You are behaving like a troll. Go away.

										Pavel 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Belisko Marek]

On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> None was ?wonderful?. They were valid concerns about my proposal
>> and I have replied to them how I see it.
>>
>> Generally, if you are not interested in people dedicated and committed to
>> fight for the better solution with (technical) arguments and concrete proposals
>> how it should be in their opinion, then please just tell and I will shut up.
>> But only then.
>
> Whatever, if it makes you shut up:
>
> I'm not interested in <fill in the blanks here>.
>
>> Or if some DT maintainer makes a decision and says: I have listened and
>> understood all arguments pro and con and I decide this or that way (preferrably
>> with giving reasons of decision as a guidance for similar problems in the future).
>
> The DT maintainers are saying just that for 10 mails now, as anybody who understands
> english will agree.
>
> You are behaving like a troll. Go away.
Please stop this non constructive emails. You don't need to reply with
reply like this. Nikolaus
post his version and wait for conclusion and feedback from maintainers.
I suggest you to read : Documentation/CodeOfConflict. Thanks.
>
>                                                                                 Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Belisko Marek]

On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> None was ?wonderful?. They were valid concerns about my proposal
>> and I have replied to them how I see it.
>>
>> Generally, if you are not interested in people dedicated and committed to
>> fight for the better solution with (technical) arguments and concrete proposals
>> how it should be in their opinion, then please just tell and I will shut up.
>> But only then.
>
> Whatever, if it makes you shut up:
>
> I'm not interested in <fill in the blanks here>.
>
>> Or if some DT maintainer makes a decision and says: I have listened and
>> understood all arguments pro and con and I decide this or that way (preferrably
>> with giving reasons of decision as a guidance for similar problems in the future).
>
> The DT maintainers are saying just that for 10 mails now, as anybody who understands
> english will agree.
>
> You are behaving like a troll. Go away.
Please stop this non constructive emails. You don't need to reply with
reply like this. Nikolaus
post his version and wait for conclusion and feedback from maintainers.
I suggest you to read : Documentation/CodeOfConflict. Thanks.
>
>                                                                                 Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> _______________________________________________
> Gta04-owner mailing list
> Gta04-owner@goldelico.com
> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Belisko Marek]

CC-ing author of below reply

On Sat, Jun 6, 2015 at 8:53 PM, Belisko Marek <marek.belisko@gmail.com> wrote:
> On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>> None was ?wonderful?. They were valid concerns about my proposal
>>> and I have replied to them how I see it.
>>>
>>> Generally, if you are not interested in people dedicated and committed to
>>> fight for the better solution with (technical) arguments and concrete proposals
>>> how it should be in their opinion, then please just tell and I will shut up.
>>> But only then.
>>
>> Whatever, if it makes you shut up:
>>
>> I'm not interested in <fill in the blanks here>.
>>
>>> Or if some DT maintainer makes a decision and says: I have listened and
>>> understood all arguments pro and con and I decide this or that way (preferrably
>>> with giving reasons of decision as a guidance for similar problems in the future).
>>
>> The DT maintainers are saying just that for 10 mails now, as anybody who understands
>> english will agree.
>>
>> You are behaving like a troll. Go away.
> Please stop this non constructive emails. You don't need to reply with
> reply like this. Nikolaus
> post his version and wait for conclusion and feedback from maintainers.
> I suggest you to read : Documentation/CodeOfConflict. Thanks.
>>
>>                                                                                 Pavel
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>> _______________________________________________
>> Gta04-owner mailing list
>> Gta04-owner@goldelico.com
>> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Belisko Marek]

CC-ing author of below reply

On Sat, Jun 6, 2015 at 8:53 PM, Belisko Marek <marek.belisko@gmail.com> wrote:
> On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>> None was ?wonderful?. They were valid concerns about my proposal
>>> and I have replied to them how I see it.
>>>
>>> Generally, if you are not interested in people dedicated and committed to
>>> fight for the better solution with (technical) arguments and concrete proposals
>>> how it should be in their opinion, then please just tell and I will shut up.
>>> But only then.
>>
>> Whatever, if it makes you shut up:
>>
>> I'm not interested in <fill in the blanks here>.
>>
>>> Or if some DT maintainer makes a decision and says: I have listened and
>>> understood all arguments pro and con and I decide this or that way (preferrably
>>> with giving reasons of decision as a guidance for similar problems in the future).
>>
>> The DT maintainers are saying just that for 10 mails now, as anybody who understands
>> english will agree.
>>
>> You are behaving like a troll. Go away.
> Please stop this non constructive emails. You don't need to reply with
> reply like this. Nikolaus
> post his version and wait for conclusion and feedback from maintainers.
> I suggest you to read : Documentation/CodeOfConflict. Thanks.
>>
>>                                                                                 Pavel
>>
>> --
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>> _______________________________________________
>> Gta04-owner mailing list
>> Gta04-owner@goldelico.com
>> http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -------------------------------------------------
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

Hi Nikolaus,

On 05/06/2015 01:19 AM, Dr. H. Nikolaus Schaller wrote:
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> Hi Neil,
>>
>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>> here is version 3 of support for tty-slaves.
>>
>> Is there a v4 of this that I missed?
> 
> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> represent the slave device in the device tree but as far as I am concerned,
> I do not see that we have a consensus (2) and the device tree maintainers
> have no comments or clear guidelines so far.

I understand there are some design considerations still apparently
unresolved wrt devicetree representation.

However, there were significant lifetime issues in v3 and I'd like some
time to review v4 to understand how those were resolved, and study the
implications.

Maintainers are busy people and often don't provide design steering
until the other pieces are ack'd.

I'd like to see _a_ solution eventually, so let's move this process along.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Peter Hurley]

Hi Nikolaus,

On 05/06/2015 01:19 AM, Dr. H. Nikolaus Schaller wrote:
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
> 
>> Hi Neil,
>>
>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>> here is version 3 of support for tty-slaves.
>>
>> Is there a v4 of this that I missed?
> 
> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> represent the slave device in the device tree but as far as I am concerned,
> I do not see that we have a consensus (2) and the device tree maintainers
> have no comments or clear guidelines so far.

I understand there are some design considerations still apparently
unresolved wrt devicetree representation.

However, there were significant lifetime issues in v3 and I'd like some
time to review v4 to understand how those were resolved, and study the
implications.

Maintainers are busy people and often don't provide design steering
until the other pieces are ack'd.

I'd like to see _a_ solution eventually, so let's move this process along.

Regards,
Peter Hurley

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Rob Herring]

On Wed, May 6, 2015 at 12:19 AM, Dr. H. Nikolaus Schaller
<hns@goldelico.com> wrote:
> Hi Peter,
>
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter@hurleysoftware.com>:
>
>> Hi Neil,
>>
>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>> here is version 3 of support for tty-slaves.
>>
>> Is there a v4 of this that I missed?

I'm interested in seeing this to completion as well.

> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> represent the slave device in the device tree but as far as I am concerned,
> I do not see that we have a consensus (2) and the device tree maintainers
> have no comments or clear guidelines so far.

I'm just catching up on the thread, but I agree with what Sebastian
has said at least on regulators.

>
> BR,
> Nikolaus
>
> (1) best with respect to maintainability, flexibility, common design patterns,
> compatibility and some other factors I don’t know the correct english words for
> (2) basically the slave can be described as a subnode like for I2C bus slaves
> or the slave device can reference the uart it is connected to like for GPIOs
> and regulators--

I'm not sure I follow the debate on sub-nodes, but it is a pretty well
defined pattern that sub-nodes are describing a connection to parent
nodes. Usually it follows the main/data connection and not some
side-band connections like regulators or gpios.

Rob

> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

[Rob Herring]

On Wed, May 6, 2015 at 12:19 AM, Dr. H. Nikolaus Schaller
<hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> wrote:
> Hi Peter,
>
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>:
>
>> Hi Neil,
>>
>> On 03/18/2015 01:58 AM, NeilBrown wrote:
>>> here is version 3 of support for tty-slaves.
>>
>> Is there a v4 of this that I missed?

I'm interested in seeing this to completion as well.

> We did have a lengthy discussion about [PATCH 3/3] how to best (1)
> represent the slave device in the device tree but as far as I am concerned,
> I do not see that we have a consensus (2) and the device tree maintainers
> have no comments or clear guidelines so far.

I'm just catching up on the thread, but I agree with what Sebastian
has said at least on regulators.

>
> BR,
> Nikolaus
>
> (1) best with respect to maintainability, flexibility, common design patterns,
> compatibility and some other factors I don’t know the correct english words for
> (2) basically the slave can be described as a subnode like for I2C bus slaves
> or the slave device can reference the uart it is connected to like for GPIOs
> and regulators--

I'm not sure I follow the debate on sub-nodes, but it is a pretty well
defined pattern that sub-nodes are describing a connection to parent
nodes. Usually it follows the main/data connection and not some
side-band connections like regulators or gpios.

Rob

> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html