From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Brownell <david-b@pacbell.net>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine
Date: Fri, 15 Feb 2008 14:40:29 +0300 [thread overview]
Message-ID: <20080215114029.GA16810@localhost.localdomain> (raw)
In-Reply-To: <200802142036.40770.david-b@pacbell.net>
On Thu, Feb 14, 2008 at 08:36:40PM -0800, David Brownell wrote:
[...]
> > The point was: GPIOs could be "input only" but you still have
> > "output" callback, and that doesn't troubles anybody. Not sure
> > why set_dedicated() such a big issue then, it could fail too! :-)
>
> See above: you're equating pin and gpio ... and while GPIOs
> have (by definition) standardized boolean input and output
> functionality, the rest of what can be done with a pin isn't.
There is nothing much left to do with a "pin", IMO. Pin can be GPIO
or abstract "dedicated function". Am I missing anything else here?
> > We're talking about General Purpose IOs, right? They're general
> > enough to support not only input/output stuff. And we want some
> > API for these General Purpose IOs. GPIO LIB is the best candidate
> > and we can implement such API at almost no cost, few lines of code.
>
> GPIOs are not intended to be a kitchen sink though; and that's
> the sense in which you seem to mean "best candidate": it's a
> clean lightweight interface, not gummed up with all kinds of
> unrelated stuff.
Just one more callback won't bloat lightweight interface... Later
I'll ask to add another one, and someone will ask for another. Yes, I
see the pattern. Surely, if you want to keep it clean and lightweight,
you should resist to additions -- I fully understand that. :-)
> Take your ideas and use them to create a pin configuration
> interface. On some platforms, configurable pins will map
> onto GPIOs, one-to-one. On others, there will be configurable
> pins that aren't GPIOs ... GPIOs that can be mapped to any of
> several pins ... pins that can be used with several GPIOs ...
> pins that can only be used with GPIOs ... and so on.
Sure, that's doable. But IMO this idea is about overcomplicating
the trivial task. Let's call it pinlib, with:
1. pin_request
2. pin_configure(pin, integer-representing-configuration)
3. pin_free
Hm... 2 auxiliary functions with the full-fledged subsystem just to
configure some pins? Plus count here that drivers would have to deal
with the two separate subsystems. Both GPIO/Pin-providers and
drivers that would use these GPIOs/Pins.
> > > The way it's usually done: platform-specific code to handle those
> > > platform-specific pin configuration issues.
> >
> > There is a problem. Driver could be cross-platform. For example,
> > we have platforms with "CPM1", "CPM2" and "QE" on-chip gpio
> > controllers.
>
> So "platform" isn't exactly the right word. "Hardware-specific"
> is more to the point. You know you're using <Brand-X-SOC-27> and
> that means you must reconfigure <this-way> because <reason>; or
> likewise, <Vendor-Y-ASIC-2> must be reconfigured <that-way> etc.
<this-way> or <that-way> is passed through platform data,
platform code knowns "hardware-specific" details.
> > And despite special _set_dedicated() function, this driver
> > actually does _use_ pins as GPIOs. And as dedicated functions.
> > And as GPIOs. The same pins, but at the different times.
>
> But you're assuming that GPIO identifiers can be used as pin/ball
> identifiers ... and as I pointed out, that's chip-specific.
Heh. I did re-read Documentation/gpio.txt once again, and still don't
get it, where are the differences between GPIOs and Pins? Yes, some
pins can't be GPIOs, but any GPIO must have associated Pin (internal
or external doesn't matter, it's "logical Pin").
For pins that can not be "GPIOs", we can just return errors from
output/input callbacks. Is it violation of the current GPIO API
conventions? Yes, but this is extension that will not break anything,
neither we contradict the "GPIO" term here, btw.
> > {
> > qe_chip = container_of(gpio_to_chip(...), struct qe_chip, chip);
> > ...
>
> You know, you can write all this yourself, without needing any
> support from the GPIO framework whatsoever. The QE stuff that
> registered a gpio_chip interface to its hardware probably keeps
> some records itself, sufficient for such (infrequent) mappings.
Yes, surely. And as I've said already, I do know how to workaround
that, without GPIOLIB support. The thing is that I don't like the
way I'm going to do it.
[...]
> > > Of course, the "function" codes are extremely chip-specific ... and
> > > some platforms would want to include things like pullups, pulldowns,
> > > and so forth as part of pin configuration.
> > >
> > > If you want to pursue this problem, don't couple it to GPIOs.
> >
> > Um... couple it to what then?..
>
> An abstraction of "pin", where pins don't correspond to GPIOs in a
> one-to-one manner.
Keeping in mind that GPIOLIB was brewing a year (?), I think another
GPIOLIB-alike subsystem not worth powder and shot, pins and GPIOs
will be obsolete at that time. :-)
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2008-02-15 11:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 17:08 [RFC PATCH 0/11] Patches needed to support QE USB Host Controller Anton Vorontsov
2008-02-03 17:09 ` [PATCH 01/11] [POWERPC] Implement support for the GPIO LIB API Anton Vorontsov
2008-02-03 21:17 ` David Brownell
2008-02-04 13:19 ` Anton Vorontsov
2008-02-03 17:09 ` [PATCH 02/11] [POWERPC] QE: split par_io_config_pin() Anton Vorontsov
2008-02-03 17:10 ` [PATCH 03/11] [POWERPC] QE: implement GPIO LIB API Anton Vorontsov
2008-02-03 17:10 ` [PATCH 04/11] [RFC][GPIOLIB] add gpio_set_dedicated() routine Anton Vorontsov
2008-02-03 21:22 ` David Brownell
2008-02-03 23:32 ` Anton Vorontsov
2008-02-15 4:36 ` David Brownell
2008-02-15 11:40 ` Anton Vorontsov [this message]
2008-02-29 20:55 ` Anton Vorontsov
2008-02-03 17:10 ` [PATCH 05/11] [POWERPC] qe_lib: support for gpio_set_dedicated Anton Vorontsov
2008-02-04 17:38 ` Timur Tabi
2008-02-03 17:10 ` [PATCH 06/11] [POWERPC] qe_lib: implement qe_muram_offset Anton Vorontsov
2008-02-03 17:10 ` [PATCH 07/11] [POWERPC] qe_lib: export qe_get_brg_clk Anton Vorontsov
2008-02-03 17:10 ` [PATCH 08/11] [POWERPC] qe_lib: implement QE GTM support Anton Vorontsov
2008-02-04 20:30 ` Scott Wood
2008-02-04 20:56 ` Anton Vorontsov
2008-02-03 17:10 ` [PATCH 09/11] [POWERPC] qe_lib: add support for QE USB Anton Vorontsov
2008-02-03 17:10 ` [PATCH 10/11] [POWERPC] mpc8360erdk: add FHCI USB support Anton Vorontsov
2008-02-03 17:11 ` [PATCH 11/11] [RFC USB POWERPC] Freescale QUICC Engine USB Host Controller Anton Vorontsov
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=20080215114029.GA16810@localhost.localdomain \
--to=avorontsov@ru.mvista.com \
--cc=david-b@pacbell.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).