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@xxxxxxxxxxxxxxxxxx>:

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/