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 <[email protected]>: > 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 _______________________________________________ Gta04-owner mailing list [email protected] http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
