Am 15.01.2016 um 18:43 schrieb Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>:
> On 01/15/2016 09:32 AM, H. Nikolaus Schaller wrote:
>> Hi Peter,
>>
>> Am 15.01.2016 um 18:16 schrieb Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>:
>>
>>> On 01/15/2016 08:08 AM, H. Nikolaus Schaller wrote:
>>>> 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.
>>>
>>>
>>> I'd like to see the exemplar slave driver be something more complicated than
>>> trivial on-off, before hacking in junk into the serial core.
>>>
>>> As it stands, this gps could be supported on any uart driver that implements
>>> mctrl gpios (which is trivial with the serial mctrl gpio helpers).
>>
>> in the GPS case basic mctrl is not enough because the "partner" driver must get meta-data
>> that there is data activity. This is something mctrl can't provide.
>
> A binary state is hardly "meta-data". What is the purpose of the rx notification?
the GPS chip can send data when it is not expected.
The bit tells that there is data activity on the data line (RX). Hence I call this "meta-data"
because it is condensed information about other data..
>
>
>> And the GPS chip does not need a simple gpio state to power on/off but an on/off toggle impulse.
>
> Genericity. If this chip needs such a state mechanism, then that should be reflected
> generically in gpio support, and we're back to trivial mctrl.
Argh... Sorry.
Should a swiss army knife GPIO driver be the solution for everything that a driver can do by simply
*using* a GPIO?
BTW: we did have a proposal back tree years that made the GPS driver present itself as
a gpio controller with a single gpio.
We called that "virtual gpio". Then we would simply connect the gps driver's
virtual power control gpio to a gpio-mctrl (or dtr-gpio).
This was rejected because a virtual gpio is not a piece of hardware. And the device/driver
is *not* a gpio.
>
>
>> In our case there are no mctrl gpios (omap) but part of our driver proposal is just to
>> forward changes of the mctrl bits to the partner driver.
>
> Please feel free to submit patches for mctrl gpios for the omap-serial driver.
Well, I don't necessarily need mctrl gpios. I need to get RX data activity notifications in addition.
BTW: with our patch you can easily add a generic mctrl driver that works for all serial
drivers. A sketch implementation (tied to a specific gpio based RS232 device) is here:
<http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=Documentation/devicetree/bindings/misc/ti%2Ctrs3386.txt;h=0e39ed1a47df9bb7bc747fca66548ff982b19cc5>
Then it is not necessary to implement mctrl for different uart drivers.
>
>
>>> Not that I'm against uart slave device support, just that I don't think hacks
>>> is the way to go about it.
>>>
>>> What I'd like to see is a split of the serial core into a tty driver and a
>>> standalone device abstraction. Anything else is just workarounds.
>
> I think you misunderstand what I mean by "standalone device abstraction"; let me
> be clearer: "standalone UART device abstraction".
Hm. Sorry, but I still don't understand what you mean and don't know what I should
abstract. Can you please give an example?
>
> Regards,
> Peter Hurley
>
>> Here (was rebased from what I had submitted to LKML a while ago):
>>
>> 1. serial core (two patches add API for any such partner drivers)
>>
>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=c75ab51483e56afe08f56de104b5ed3fa1d6b0e8
>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=f910d951fcf816fce3261814d7f8c46ac6b35e68
>>
>> 2. standalone driver example (using the new API)
>>
>> http://git.goldelico.com/?p=gta04-kernel.git;a=commit;h=4fd1dbd4e915d741dddd264d6f87396e72351b3a
>>
>> BR and thanks,
>> Nikolaus
>>
>
Did you look into these patches to understand what we propose?
Best Regards and thanks,
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
