Re: [Gta04-owner] [PATCH 0/3] tty slave device support - version 3.

Hi Mark,

Am 06.05.2015 um 16:15 schrieb Mark Rutland [off-list ref]:

quoted

quoted

quoted

quoted

quoted

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.

[...]

quoted

quoted

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>;
	};
};

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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.

quoted

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