Re: [PATCH RFC 0/3] UART slave device support
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 = <>;
> };
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
>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/3] UART slave device support
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 h...@goldelico.com
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/3] UART slave device support
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 = <>;
};
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC 0/3] UART slave device support
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 h...@goldelico.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
