On Fri, Jan 15, 2016 at 04:05:45PM +0100, H. Nikolaus Schaller wrote:

Hi Mark,

Am 15.01.2016 um 12:01 schrieb Mark Rutland [off-list ref]:

quoted

On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:

quoted

Hi Mark,

Am 13.01.2016 um 20:15 schrieb Mark Rutland [off-list ref]:

quoted

On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:

quoted

There is one point still to be solved: the exact style of the DT bindings.

We have an idea how a driver can implement two different styles (child node AND phandle)
so that it is up to the DTS developer to use the one that best fits into the existing DTS.

From my perspective as a binding maintainer, and as I stated before, the
child node approach made the most sense and was most consistent with the

quoted

way we handle other devices.

I simply don't see that this is the most common way other devices are handled.

I find many counter-examples which use phandles:
* gpios
* regulators
* iio channels used by other drivers (e.g. iio-hwmon)
* phy devices
* timers
* pwms
* interrupts
* dma

As was previously described to you, in these cases phandles are used
when these are _resources_ used by another device, not for the main
programmer-visible interface to the device.

Ah, I think I finally begin to understand the rule you are following:

	If a device's data interface can be seen in user space, this interface
	is sort of a "main interface" and must be modelled in DT by a
	parent-child relationship.

No, you have misunderstood. This has _nothing_ to do with userspace.

This has everything to do with the "programmer's interface" as you would
find documented in a TRM -- effectively where a driver would communicate
with the device (e.g. MMIO/SPI/I2C registers).

[...]

Now I also think I better understand what you meant by "main interface"
a while ago.

For me, when looking into a chip data sheet, the main interface is a sometimes
arbitrary. Or when viewing it through device driver implementors glasses
I may end up with a different main interface.

From the hardware schematics, I can't read which interface is "main". I can
only read which components and signals are connected. So the information
what is "main" must come from somewhere else, but not the hardware.

You appear to have a definition based on Linux user space interfaces
which is distinct from mine and at least explains why the discussion takes
so long and we don't come to a common view.

This is nothing to do with userspace.

Admittedly, on a device which has multiple slave interfaces, "main" is
arbitrary. If I've followed correctly, that's not the cae here.

quoted

Conceptually, A UART slave is far closer to SPI or I2C, where the slave
is represented as a sub-node.

Only if you have the goal to describe the data/command path ("main interface")
in DT.

This is the way devices are described in DT -- walking from the root to
a leaf you follow the path from the CPU to a slave interface.

Some things don't have slave interfaces (e.g. fixed-clocks), but still
need to be referred to, so those still get placed in the DT. There are
arguments to be had w.r.t. their placement, but that's another
discussion entirely.

I mentioned it several times: USB-PHYs use the phandle approach to attach
a single PHY to the usb controller, although there is usually some ULPI-"bus"
interface (12 parallel wires) between. And the PHY is clearly more "slave" than
the usb controller, isn't it?

Some PHYs have additional interfaces, so their CPU-visible slave
interface is described. This necessitates the phandle reference in the
general case.

But with phandle, the usb controller is a _resource_ for the PHY. So would
you say this is wrong?

Not entirely.

This is the design pattern (for DT and drivers) we have copied for our tty-slave
proposal.

We have plenty of other ways of describing relationships today. The
existence of one style (and its continued support for ABI reasons) does
not mean that it's a style we want to proliferate.

quoted

I wasn't aware of any instances of timers being referred to by phandle
by other devices -- that seems distinctly odd. Where do you see that
happening.

I found it in connection with dmtimer / pwm on OMAP3. May be a rare exception
and that may be a special type of OMAP timers.

I took a quick look and couldn't spot where that happened. I take it
the timer was a "ti,omap3430-timer"? Or have I misunderstood?

What referenced it by phandle? In which dt?

quoted

quoted

* mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)

Subsystem type bindings are more of a special case, and regardless the
components have nodes in the relevant portions of the DT.

quoted

quoted

* mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)

If this is so different, how is it relevant?

It could as well be subnode of the affected mmc interface or mmc-slave, but obviously it
isn't grouped there, and uses a phandle to refer to its &mmc "master".

Its function is quite similar what we need for our GPS chip: control power sequences
of a remote device.

That may fit your one particular use-case, but for UART slaves generally
we should have a kernel driver (which can do more than a trivial
power-up), at which point you need a node, and the separate sequence
node is useless.

quoted

quoted

All of them define the provider in one node. And refer to it by a phandle in another node
where they are used.

So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.

I agree that provider-consumer type relationships are typically
described in this manner.

Ok.

quoted

However, master-slave relationships are not.

It looks as if you see a significant difference between provider-consumer and master-slave
relationship which I was not sure of which applies to what and where you make the distinction.

By the way: what exactly makes the UART on the SoC side "master" and the UART on the connected
device a "slave" (except the user-space view)?

Typically a "slave" accepts commands, and won't send commands of its own
accord. This case is admittedly fuzzier given that a UART slave could
send a stream of bytes at any point, but that's data.

The distinction is really that the UART slave won't control other
devices -- you can think of the entire path of the CPU to the UART as
the master.

UARTs per se have no master-slave roles and are symmetrical (contrary to SPI and I2C where it
is well defined). Rather, both are formally DTE connected by a null-modem.

This is another substantial difference between UART and I2C/SPI besides addressability.

Sure, except for the fact that the device attached to the UART logically
follows a "slave" role. The rest of the system would be usable without
it, and it assert no control over anything else.

Thanks,
Mark.