[RFC] GPIO-based flow control in the cpm_uart driver

[RFC] GPIO-based flow control in the cpm_uart driver

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

Hi everybody,

I'm implementing flow control and modem control lines support in the cpm_uart 
driver.

The implementation is based on the GPIO lib. Modem control lines are described 
in the device tree as GPIO resources and accessed through the OF GPIO 
bindings. The I/O ports have to be initialized as GPIOs in the 
platform-specific code.

Reading and writing the modem control lines isn't an issue, but activating 
hardware flow control is more complex. The driver needs to turn dedicated 
functions on and off for the RTS and CTS signals, and the GPIO API doesn't 
provide a way to access the PPAR* registers (which does make sense - although 
arguably - as PPAR* control specific functions, not GPIOs).

Hardcoding RTS and CTS lines control in the driver is not an option I want to 
consider. Extending the GPIO API to handled special functions has been nacked 
in the past (see 
http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An 
option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use 
cpm1/2_set_pin in the cpm_uart driver.

Can anyone think of a better solution ?

Best regards,

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Anton Vorontsov]

On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
> Hi everybody,
> 
> I'm implementing flow control and modem control lines support in the cpm_uart 
> driver.
> 
> The implementation is based on the GPIO lib. Modem control lines are described 
> in the device tree as GPIO resources and accessed through the OF GPIO 
> bindings. The I/O ports have to be initialized as GPIOs in the 
> platform-specific code.
> 
> Reading and writing the modem control lines isn't an issue, but activating 
> hardware flow control is more complex. The driver needs to turn dedicated 
> functions on and off for the RTS and CTS signals, and the GPIO API doesn't 
> provide a way to access the PPAR* registers (which does make sense - although 
> arguably - as PPAR* control specific functions, not GPIOs).
> 
> Hardcoding RTS and CTS lines control in the driver is not an option I want to 
> consider. Extending the GPIO API to handled special functions has been nacked 
> in the past (see 
> http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An 
> option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use 
> cpm1/2_set_pin in the cpm_uart driver.

Since you have successfuly ported QE USB controller onto CPM USB
hardware, now it's obvious that we will need generic gpio_set_dedicated()
function. So I would rather beg David to accept gpio_set_dedicated()
approach instead of exporting gpio_to_chip(). That way we'll kill two
birds with one stone.

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Tuesday 15 April 2008 15:40, Anton Vorontsov wrote:
> On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
> > Hi everybody,
> > 
> > I'm implementing flow control and modem control lines support in the
> > cpm_uart driver.
> > 
> > The implementation is based on the GPIO lib. Modem control lines are
> > described in the device tree as GPIO resources and accessed through the OF
> > GPIO bindings. The I/O ports have to be initialized as GPIOs in the 
> > platform-specific code.
> > 
> > Reading and writing the modem control lines isn't an issue, but activating 
> > hardware flow control is more complex. The driver needs to turn dedicated 
> > functions on and off for the RTS and CTS signals, and the GPIO API doesn't 
> > provide a way to access the PPAR* registers (which does make sense -
> > although arguably - as PPAR* control specific functions, not GPIOs).
> > 
> > Hardcoding RTS and CTS lines control in the driver is not an option I want
> > to consider. Extending the GPIO API to handled special functions has been
> > nacked in the past (see 
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An 
> > option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use 
> > cpm1/2_set_pin in the cpm_uart driver.
> 
> Since you have successfuly ported QE USB controller onto CPM USB
> hardware, now it's obvious that we will need generic gpio_set_dedicated()
> function. So I would rather beg David to accept gpio_set_dedicated()
> approach instead of exporting gpio_to_chip(). That way we'll kill two
> birds with one stone.

Or maybe some kind of gpio_set_option() with flags specific to the 
controller ? This could be used to enable open-drain outputs or internal 
pull-ups for instance.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Anton Vorontsov]

On Tue, Apr 15, 2008 at 03:47:41PM +0200, Laurent Pinchart wrote:
> On Tuesday 15 April 2008 15:40, Anton Vorontsov wrote:
> > On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
> > > Hi everybody,
> > > 
> > > I'm implementing flow control and modem control lines support in the
> > > cpm_uart driver.
> > > 
> > > The implementation is based on the GPIO lib. Modem control lines are
> > > described in the device tree as GPIO resources and accessed through the OF
> > > GPIO bindings. The I/O ports have to be initialized as GPIOs in the 
> > > platform-specific code.
> > > 
> > > Reading and writing the modem control lines isn't an issue, but activating 
> > > hardware flow control is more complex. The driver needs to turn dedicated 
> > > functions on and off for the RTS and CTS signals, and the GPIO API doesn't 
> > > provide a way to access the PPAR* registers (which does make sense -
> > > although arguably - as PPAR* control specific functions, not GPIOs).
> > > 
> > > Hardcoding RTS and CTS lines control in the driver is not an option I want
> > > to consider. Extending the GPIO API to handled special functions has been
> > > nacked in the past (see 
> > > http://ozlabs.org/pipermail/linuxppc-dev/2008-February/051241.html). An 
> > > option would be to export gpio_to_chip from drivers/gpio/gpiolib.c and use 
> > > cpm1/2_set_pin in the cpm_uart driver.
> > 
> > Since you have successfuly ported QE USB controller onto CPM USB
> > hardware, now it's obvious that we will need generic gpio_set_dedicated()
> > function. So I would rather beg David to accept gpio_set_dedicated()
> > approach instead of exporting gpio_to_chip(). That way we'll kill two
> > birds with one stone.
> 
> Or maybe some kind of gpio_set_option() with flags specific to the 
> controller ? This could be used to enable open-drain outputs or internal 
> pull-ups for instance.

Yes, probably this name. The purpose will be the same anyway. ;-)

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[David Brownell]

On Tuesday 15 April 2008, Laurent Pinchart wrote:
> I'm implementing flow control and modem control lines support in the
> cpm_uart driver.
>
> The implementation is based on the GPIO lib. Modem control lines are
> described in the device tree as GPIO resources and accessed through the OF
> GPIO bindings. The I/O ports have to be initialized as GPIOs in the
> platform-specific code.

I don't follow the "have to be" ... why couldn't the platform
setup code know that if a given UART is being used with hardware
handshaking, that means a particular pin mux config should be used?

Are there maybe some on-chip routing options, so that for example
RTS2 could come out on any of three different balls?  (In which
case that setup code could just be told *which* config to use...)

In this case I'm asking specifically about the normal all-works-ok
situation ... no errata or similar complications I mention below.


>  An option would be to export gpio_to_chip from drivers/gpio/gpiolib.c
>  and use cpm1/2_set_pin in the cpm_uart driver.

Help me to understand this a bit.  UARTs are a fair example of places
where I've seen such pin reconfiguration be useful, but it's never
seemed to be generalizable except possibly as callbacks to SOC-specific
code (which don't imply updating generic programming interfaces).


I've seen examples where the hardware flow control normally works, so
that board setup sets up those pins in "hardware flow control" mode
when it's told the board has them wired up that way ... but then, some
chip revisions have errata forcing the driver to use a particular
port's handshake pins as GPIOs in some cases.  (Obviously troublesome
except at low data rates, so one hopes the board designers just avoid
using those UARTs in that mode.)

I've also seen examples where the UART clock needs to be disabled in
deeper sleep states, but the system still wants the UART to be a wake
event source ... by having either the START bit, or maybe BREAK (it
gives a longer latch period), kick in a gpio-based pin change IRQ on
the UARTn.RX line.


Now in *both* of those examples I've seen before, the solution could
not be generic.  When the pin was used as GPIO, a particular pinmux
configuration was needed.  (Bitfield X of register Y has value Z ...
or maybe a couple registers needed to change.)  And when used as a
UART signal, a different one was used.  (Same setup.  Maybe value Z
became value W.  Or again, maybe a few registers needed changing.)

And for different chips in the family, sometimes even different
revisions of one chip, the W/X/Y/Z/etc values differed even for UART1.
For other UARTs, the same was true.


So given that ... how would knowing the GPIO chip help, when I'd
still need to find out the W/X/Y/Z/etc values?  And if I've got a
way to convey W/X/Y/Z/etc -- canonical example being a callback to
the relevant SOC-specific code --  why shouldn't that obviate the
need for any scheme to look up the gpio chip?

- Dave

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[David Brownell]

On Tuesday 15 April 2008, Laurent Pinchart wrote:
> Or maybe some kind of gpio_set_option() with flags specific to the 
> controller ? This could be used to enable open-drain outputs or internal 
> pull-ups for instance.

That presumes that the pin config is associated with the GPIO
controller, rather than being an independent modules...

In the cases that a platform has such an association, there
should be no problem just using a platform-specific code to
do the relevant magic.

- Dave

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 6084 bytes --]

Hi David,

On Tuesday 20 May 2008 02:25, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > I'm implementing flow control and modem control lines support in the
> > cpm_uart driver.
> >
> > The implementation is based on the GPIO lib. Modem control lines are
> > described in the device tree as GPIO resources and accessed through the OF
> > GPIO bindings. The I/O ports have to be initialized as GPIOs in the
> > platform-specific code.
> 
> I don't follow the "have to be" ... why couldn't the platform
> setup code know that if a given UART is being used with hardware
> handshaking, that means a particular pin mux config should be used?

Flow control and modem control lines are two different beasts (although flow 
control uses a subset of the modem control lines).

The UART driver needs to get and set the modem control lines state. This is 
easily handled by the GPIO library without requiring any change to GPIO lib. 
The only requirement, as stated above, is that platform-specific code 
initializes the corresponding pins as GPIOs. I'm not sure to understand what 
you don't get, as my point is that the platform setup code must configure the 
pins appropriately, exactly as you mention in your comment.

> Are there maybe some on-chip routing options, so that for example
> RTS2 could come out on any of three different balls?  (In which
> case that setup code could just be told *which* config to use...)

That's possible yes, but that's not really an issue. Platform setup code is by 
definition platform-specific and has knowledge of the hardware, so it can 
setup pins correctly.

> In this case I'm asking specifically about the normal all-works-ok
> situation ... no errata or similar complications I mention below.
> 
> >  An option would be to export gpio_to_chip from drivers/gpio/gpiolib.c
> >  and use cpm1/2_set_pin in the cpm_uart driver.
> 
> Help me to understand this a bit.  UARTs are a fair example of places
> where I've seen such pin reconfiguration be useful, but it's never
> seemed to be generalizable except possibly as callbacks to SOC-specific
> code (which don't imply updating generic programming interfaces).

Callbacks worked fine on ppc but are now more difficult to implement in 
powerpc. This is why I'm looking for a generic solution based on the device 
tree.

> I've seen examples where the hardware flow control normally works, so
> that board setup sets up those pins in "hardware flow control" mode
> when it's told the board has them wired up that way ... but then, some
> chip revisions have errata forcing the driver to use a particular
> port's handshake pins as GPIOs in some cases.  (Obviously troublesome
> except at low data rates, so one hopes the board designers just avoid
> using those UARTs in that mode.)

The issue is that flow control must be configurable. Userspace software can 
turn it on or off. To handle that on CPM2-based platforms, the pins connected 
to CTS and RTS must be switched between GPIO mode (no flow control) and 
dedicated function mode (hard flow control) at runtime in the UART driver.

> I've also seen examples where the UART clock needs to be disabled in
> deeper sleep states, but the system still wants the UART to be a wake
> event source ... by having either the START bit, or maybe BREAK (it
> gives a longer latch period), kick in a gpio-based pin change IRQ on
> the UARTn.RX line.
> 
> Now in *both* of those examples I've seen before, the solution could
> not be generic.  When the pin was used as GPIO, a particular pinmux
> configuration was needed.  (Bitfield X of register Y has value Z ...
> or maybe a couple registers needed to change.)  And when used as a
> UART signal, a different one was used.  (Same setup.  Maybe value Z
> became value W.  Or again, maybe a few registers needed changing.)
> 
> And for different chips in the family, sometimes even different
> revisions of one chip, the W/X/Y/Z/etc values differed even for UART1.
> For other UARTs, the same was true.
> 
> So given that ... how would knowing the GPIO chip help, when I'd
> still need to find out the W/X/Y/Z/etc values?  And if I've got a
> way to convey W/X/Y/Z/etc -- canonical example being a callback to
> the relevant SOC-specific code --  why shouldn't that obviate the
> need for any scheme to look up the gpio chip?

On Freescale PowerPC hardware (specifically CPM2-based, but CPM1 and QE are 
quite similar), pins can either have a dedicated functionality or be used as 
a GPIO. This is handled through a group of registers, which are

- the data register, used in GPIO mode only
- the direction register, used in both GPIO and dedicated modes
- the pin assignment register, used to switch between GPIO and dedicated mode
- the open-drain register, used to switch between push-pull and open drain 
configurations

Let's take the UART CTS signal as an example, connected to port C, pin 15. The 
pin is always a push-pull output, so that configuration can be set in 
platform setup code. Let's assume that hard flow control is disabled as 
startup, so platform setup code configures PC15 as a GPIO (pin assignment 
register cleared).

The data register can then be used to set or clear CTS in response to the 
TIOCMSET ioctl. The UART driver just calls gpio_set_value() and everybody is 
happy.

Now, when enabling hard flow control, the CTS pin has to be switched to 
dedicated mode. The GPIO lib has no API for that, and abstract GPIO numbers 
can't be mapped to platform-specific pins as there is no API for that.

To switch hard flow control on and off, the UART driver will need either an 
extension to the GPIO API to set and clear the pin assignment register, or a 
way to retrieve a reference to the GPIO chip to call platform-specific GPIO 
functions, not exported through the generic GPIO API.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] GPIO-based flow control in the cpm_uart driver

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Tuesday 20 May 2008 02:31, David Brownell wrote:
> On Tuesday 15 April 2008, Laurent Pinchart wrote:
> > Or maybe some kind of gpio_set_option() with flags specific to the 
> > controller ? This could be used to enable open-drain outputs or internal 
> > pull-ups for instance.
> 
> That presumes that the pin config is associated with the GPIO
> controller, rather than being an independent modules...
> 
> In the cases that a platform has such an association, there
> should be no problem just using a platform-specific code to
> do the relevant magic.

To call GPIO chip specific functions, the driver needs a way to get the GPIO 
chip associated with the GPIO.

-- 
Laurent Pinchart
CSE Semaphore Belgium

Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium

T +32 (2) 387 42 59
F +32 (2) 387 42 75

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]