From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Laurent Pinchart <laurentp@cse-semaphore.com>
Cc: David Brownell <david-b@pacbell.net>, linuxppc-dev@ozlabs.org
Subject: Re: [RFC] GPIO-based flow control in the cpm_uart driver
Date: Tue, 15 Apr 2008 18:30:37 +0400 [thread overview]
Message-ID: <20080415143037.GA18931@polina.dev.rtsoft.ru> (raw)
In-Reply-To: <200804151547.44052.laurentp@cse-semaphore.com>
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
next prev parent reply other threads:[~2008-04-15 14:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-15 13:22 [RFC] GPIO-based flow control in the cpm_uart driver Laurent Pinchart
2008-04-15 13:40 ` Anton Vorontsov
2008-04-15 13:47 ` Laurent Pinchart
2008-04-15 14:30 ` Anton Vorontsov [this message]
2008-05-20 0:31 ` David Brownell
2008-05-20 13:00 ` Laurent Pinchart
2008-05-20 0:25 ` David Brownell
2008-05-20 12:50 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080415143037.GA18931@polina.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=david-b@pacbell.net \
--cc=laurentp@cse-semaphore.com \
--cc=linuxppc-dev@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.