Hi Andrey,
ah that is fine to learn about another project that needs some solution (however it will look like).
Am 15.01.2016 um 16:43 schrieb Andrey Vostrikov <andrey.vostrikov@xxxxxxxxxxxxxxxxxx>:
> Hi Nikolaus,
>
> H. Nikolaus Schaller wrote:
>> And IMHO nobody has described that he/she needs a solution to model the*data* relationship
>> for devices connected behind a tty port.
>
> I am not sure if my case fits *data* relationship or not in this case. Some time ago I asked about state of your patches.
> In my case I have supervising microcontroller unit (MCU) that is connected to one of UARTs on SoC.
>
> This MCU implements several functions that will be implemented as MFD driver:
> - watchdog and system reset
> - NVMEM EEPROM
> - HWMON sensors
> - Input/power button
> - and similar low level functions
>
> So in my case DTS binding looks like:
>
> &uart3 {
> mcu {
> line-speed = <baud rate>;
> watchdog {
> timeout = <ms>;
> ...other params...
> };
> eeprom {
> #address-cells
> #size-cells
> cell1 : cell@1 {
> reg = <1 2>;
> };
> cell2 : cell@2 {
> reg = <2 1>;
> };
> };
> hwmon {
> sensors-list = "voltage", "current", etc...;
> }
> }
> }
With my proposal it would just become
/ {
themcu: mcu {
uart = <&uart3>;
line-speed = <baud rate>;
watchdog {
timeout = <ms>;
...other params...
};
eeprom {
#address-cells
#size-cells
cell1 : cell@1 {
reg = <1 2>;
};
cell2 : cell@2 {
reg = <2 1>;
};
};
hwmon {
sensors-list = "voltage", "current", etc...;
}
}
};
Which is almost the same. Except that it allows to move your mcu node whereever you like and easily allows to change the interface to connect to a different device by
&themcu {
uart = <&uart1>;
};
With the subnode style you would need some tricks to get the driver instance for uart3 disabled, although it is possible (everything is possible - just easier or more difficult).
>
> This MCU receives commands and notifies MFD driver about events via UART protocol.
> It looks like not really a slave though, more like a partnership from data flow point of view.
Yes!. That is why I started to question the term "slave".
And yes, this is the second use case I am aware of: a device that just *uses" the UART to do its works and there is no /dev/tty involved.
>
> There is no user space code involved in this case as whole interactions are between drivers (just a kick to open /dev/ttyXXX using sys_open, as there is no way to start probe on uart_slave bus and assign line discipline).
Exactly this is what we want to provide as API for the drivers by our patches to serial-core.c.
We want to allow such a "partner" device to take a line-speed property e.g. from its DT node (or a 9600 constant as for our GPS chip) and ask the UART driver to set the required clocks. Or to get the driver notified that someone has opened the /dev/tty* etc. So make it possible to use some UART from another driver.
In the long run it should be possible to use the UART even if there is no /dev/tty client or interface in user-space but that is something not perfectly working (there is some initialization race in the tty/serial subsystem we have not yet understood).
As you see, I have a driver-specific standpoint (and not coming from user space).
Thanks for sharing this example.
BR,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
