[Gta04-owner] [PATCH RFC 0/3] UART slave device support

Dr. H. Nikolaus Schaller hns at goldelico.com
Sun Jun 7 12:54:40 CEST 2015

Am 06.06.2015 um 15:09 schrieb Pavel Machek <pavel at ucw.cz>:

> 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.

Perter Hurley asked me a while ago to present code to demonstrate what this
approach really means. I promised to work out something. And here it is.

> NAK.

I think the maintainers affected by this patch set can formulate their statements
themselves (after evaluating the whole proposal) and do not need your premature
summary judgement.

So I am awaiting technical comments or suggestions for improvement.

And a honest technical evaluation without prejudice against it.

Needless to say that I think this proposal is easier to maintain and broader
to use than the alternatives I am aware of. And it follows a DT design pattern
that is already in use (USB PHY).

Finally it feels (at least for me as device driver and device tree implementor)
more like „a natural extension“ rather than forcing UART to be a bus without
any urgent need.

> 										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 <hns at goldelico.com>
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

More information about the Gta04-owner mailing list