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
On Tue, 05 May 2015 15:54:41 -0400 Peter Hurley <[email protected]>
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
Hi Peter,
Am 05.05.2015 um 21:54 schrieb Peter Hurley <[email protected]>:
> 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-
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 <[email protected]>:
>
> > 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
Hi Nikolaus,
On 05/06/2015 01:19 AM, Dr. H. Nikolaus Schaller wrote:
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <[email protected]>:
>
>> 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
Hi Pavel,
Am 06.05.2015 um 11:27 schrieb Pavel Machek <[email protected]>:
> 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 <[email protected]>:
>>
>>> 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-
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
Hi Peter,
Am 06.05.2015 um 14:05 schrieb Peter Hurley <[email protected]>:
> 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-
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 <[email protected]>:
>
> > 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.
Hi Mark,
Am 06.05.2015 um 14:36 schrieb Mark Rutland <[email protected]>:
> 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 <[email protected]>:
>>
>>> 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
> >>>> 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.
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 <[email protected]>:
>
> > 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 <[email protected]>:
> >>
> >>> 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
Hi Mark,
Am 06.05.2015 um 16:15 schrieb Mark Rutland <[email protected]>:
>>>>>> 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
Hi Pavel,
Am 06.05.2015 um 16:28 schrieb Pavel Machek <[email protected]>:
> 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 <[email protected]>:
>>
>>> 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 <[email protected]>:
>>>>
>>>>> 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
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 <[email protected]>:
>
> >>>>>> 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.
Hi Mark,
Am 06.05.2015 um 19:18 schrieb Mark Rutland <[email protected]>:
> 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 <[email protected]>:
>>
>>>>>>>> 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
On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
> Am 06.05.2015 um 19:18 schrieb Mark Rutland <[email protected]>:
>> 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 <[email protected]>:
>>>
>>>>>>>>> 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
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
Am 07.05.2015 um 16:30 schrieb Peter Hurley <[email protected]>:
> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <[email protected]>:
>>> 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 <[email protected]>:
>>>>
>>>>>>>>>> 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
Am 07.05.2015 um 16:56 schrieb Peter Hurley <[email protected]>:
> 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
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
On Wed, May 6, 2015 at 12:19 AM, Dr. H. Nikolaus Schaller
<[email protected]> wrote:
> Hi Peter,
>
> Am 05.05.2015 um 21:54 schrieb Peter Hurley <[email protected]>:
>
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
> Am 07.05.2015 um 16:56 schrieb Peter Hurley <[email protected]>:
>> 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
On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
>
> Am 07.05.2015 um 16:30 schrieb Peter Hurley <[email protected]>:
>
>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <[email protected]>:
>>>> 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 <[email protected]>:
>>>>>
>>>>>>>>>>> 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
Hi Peter,
Am 07.05.2015 um 17:51 schrieb Peter Hurley <[email protected]>:
> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
>> Am 07.05.2015 um 16:56 schrieb Peter Hurley <[email protected]>:
>>> 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
Hi,
Am 07.05.2015 um 18:18 schrieb Peter Hurley <[email protected]>:
> On 05/07/2015 11:11 AM, Dr. H. Nikolaus Schaller wrote:
>>
>> Am 07.05.2015 um 16:30 schrieb Peter Hurley <[email protected]>:
>>
>>> On 05/07/2015 08:46 AM, Dr. H. Nikolaus Schaller wrote:
>>>> Am 06.05.2015 um 19:18 schrieb Mark Rutland <[email protected]>:
>>>>> 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 <[email protected]>:
>>>>>>
>>>>>>>>>>>> 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
Hi Peter,
Am 07.05.2015 um 18:46 schrieb Dr. H. Nikolaus Schaller <[email protected]>:
> Hi Peter,
>
> Am 07.05.2015 um 17:51 schrieb Peter Hurley <[email protected]>:
>
>> On 05/07/2015 11:34 AM, Dr. H. Nikolaus Schaller wrote:
>>> Am 07.05.2015 um 16:56 schrieb Peter Hurley <[email protected]>:
>>>> 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
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 <[email protected]>
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 <[email protected]>
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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
On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek <[email protected]> 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
> [email protected]
> 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
CC-ing author of below reply
On Sat, Jun 6, 2015 at 8:53 PM, Belisko Marek <[email protected]> wrote:
> On Sat, Jun 6, 2015 at 3:09 PM, Pavel Machek <[email protected]> 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
>> [email protected]
>> 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