Message-Id: <BD3D34DD-2FC8-44A2-89FA-35843065F50F@goldelico.com>
Date:	Wed, 6 May 2015 15:28:58 +0200
From:	"Dr. H. Nikolaus Schaller" <hns@...delico.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Peter Hurley <peter@...leysoftware.com>,
	Pavel Machek <pavel@....cz>,
	List for communicating with real GTA04 owners 
	<gta04-owner@...delico.com>, NeilBrown <neil@...wn.name>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Sebastian Reichel <sre@...nel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	Jiri Slaby <jslaby@...e.cz>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

Hi Mark,

Am 06.05.2015 um 14:36 schrieb Mark Rutland <mark.rutland@....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@...leysoftware.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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists