From: Bill Gatliff <bgat@billgatliff.com>
To: David Brownell <david-b@pacbell.net>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Andrew Victor <andrew@sanpeople.com>,
jamey.hicks@hp.com, Kevin Hilman <khilman@mvista.com>,
Nicolas Pitre <nico@cam.org>, Russell King <rmk@arm.linux.org.uk>,
Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation
Date: Mon, 20 Nov 2006 23:51:16 -0600 [thread overview]
Message-ID: <456293D4.2030103@billgatliff.com> (raw)
In-Reply-To: <200611202107.00754.david-b@pacbell.net>
David Brownell wrote:
>But in general, no ... the general case is that GPIO controller(s)
>and pin muxing are two separate units in the silicon, and there's
>no one-to-one coupling possible.
>
>
Not sure I believe that there's "no one-to-one coupling possible"
anymore. :)
In OMAP, as far as I can tell after skimming the datasheet (and being
reminded why I avoid TI's microcontrollers!), someone has to set up the
MUX so that a given GPIO can get to a specified pin. And practically
speaking, what's soldered to a pin is nearly immutable for a given board
(or at least a particular revision; you won't change it in software
anyway!). So for sanity's sake the GPIO "resource manager" would have
to refuse a request for a GPIO line assigned to a pin that had already
been committed to something else, be it another GPIO line or a
peripheral function. So I think having the notion of a resource manager
_at all_ implies that you're into some amount of MUX analysis/management
on machines that have them.
Aside: You state that there are many-to-many possibilities. In theory
yes, but for OMAP and any other practical machine, no. You never have
an infinite number of pins or GPIOs, so even with some kind of radical
"switch fabric" the number of unique combinations of GPIO+pin still
would be bounded. In the case of OMAP, it looks like most of the GPIOs
can be assigned to one of two pins, and each pin can be assigned to one
of two GPIOs. So, "some-to-some". :)
The "multiplexing" that I was wishing to leave out of the GPIO API was
the part where you assign pins to peripheral functions *or* GPIO, a'la
AT91. The existing kernel code for that chip provides a number of
functions to help board authors get all the routing and configuration
right for each pin ("peripheral A function, or peripheral B, or GPIO?
Input, or output? Pullup resistor, or no? Input filtering, or no?")
(*). I'm ok with not trying to consolidate that functionality in an
arch-neutral GPIO-only API right now, since machines do that so differently.
But I was assuming all along that we were overloading the notion of a
"gpio number" enumeration, such that each enumeration ultimately
referred to a unique combination of GPIO+pin for the instant machine.
And once you've got that, there's no reason why the underlying
implementation couldn't assert the proper routing at the time a specific
GPIO+pin was requested. Maybe that's up to the individual authors as to
whether they want to provide this in their implementations, or choose
instead to leave out the MUX configuration and just map GPIO
enumerations to physical GPIO line numbers (and hope for the best at
runtime). But I still don't see a reason why they shouldn't if they're
willing to do the code.
Sorry to recycle on all of this again. Maybe I'm just a slow learner,
maybe I just was misunderstanding some of the terminology we were
throwing around. Maybe it's something else entirely.
* - Most of which was written by Dave Brownell. Thanks!
b.g.
--
Bill Gatliff
bgat@billgatliff.com
next prev parent reply other threads:[~2006-11-21 5:51 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-11 23:41 [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls David Brownell
2006-11-12 1:27 ` H. Peter Anvin
2006-11-12 3:04 ` David Brownell
2006-11-12 3:15 ` H. Peter Anvin
2006-11-13 3:30 ` Bill Gatliff
2006-11-13 17:38 ` Paul Mundt
2006-11-13 17:56 ` Thiago Galesi
2006-11-13 19:25 ` David Brownell
2006-11-13 19:50 ` Bill Gatliff
2006-11-13 18:19 ` Bill Gatliff
2006-11-13 18:38 ` Paul Mundt
2006-11-13 19:29 ` Bill Gatliff
2006-11-13 20:15 ` Paul Mundt
2006-11-20 21:49 ` David Brownell
2006-11-21 3:44 ` Bill Gatliff
2006-11-21 4:45 ` David Brownell
2006-11-21 5:09 ` Bill Gatliff
2006-11-21 5:35 ` David Brownell
2006-11-21 6:09 ` Paul Mundt
2006-11-21 18:13 ` David Brownell
2006-11-22 3:36 ` Bill Gatliff
2006-11-22 3:55 ` Paul Mundt
2006-11-22 4:45 ` [Bulk] " David Brownell
2006-11-22 4:47 ` Bill Gatliff
2006-11-21 15:57 ` Bill Gatliff
2006-11-23 0:40 ` David Brownell
2006-11-30 6:57 ` pHilipp Zabel
2006-11-30 7:29 ` pHilipp Zabel
2006-11-30 22:24 ` David Brownell
2006-11-20 22:15 ` David Brownell
2006-11-21 2:56 ` Bill Gatliff
2006-11-13 20:00 ` David Brownell
2006-11-13 21:30 ` Paul Mundt
2006-11-14 3:21 ` David Brownell
2006-11-13 19:21 ` David Brownell
2006-11-13 19:43 ` Bill Gatliff
2006-11-13 20:15 ` David Brownell
2006-11-13 20:26 ` Bill Gatliff
2006-11-13 20:53 ` David Brownell
2006-11-13 20:58 ` Bill Gatliff
2006-11-13 20:29 ` Bill Gatliff
2006-11-16 14:54 ` [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation Haavard Skinnemoen
2006-11-20 21:47 ` David Brownell
2006-11-21 3:11 ` Bill Gatliff
2006-11-21 5:06 ` David Brownell
2006-11-21 5:51 ` Bill Gatliff [this message]
2006-11-21 18:19 ` David Brownell
2006-11-21 9:11 ` Haavard Skinnemoen
2006-11-21 19:03 ` David Brownell
2006-11-28 12:36 ` [RFC/PATCH] arch-neutral GPIO calls: AVR32 implementation [take 2] Haavard Skinnemoen
2006-11-30 19:05 ` David Brownell
2006-12-01 9:51 ` Haavard Skinnemoen
2006-12-20 21:04 ` [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls David Brownell
2006-12-20 21:08 ` [patch 2.6.20-rc1 1/6] GPIO core David Brownell
2006-12-27 17:49 ` Pavel Machek
2006-12-28 22:05 ` David Brownell
2006-12-29 0:27 ` Pavel Machek
2006-12-30 1:18 ` David Brownell
2007-01-01 20:55 ` Pavel Machek
2007-01-01 21:27 ` David Brownell
2007-01-02 14:18 ` Pavel Machek
2006-12-20 21:09 ` [patch 2.6.20-rc1 2/6] OMAP GPIO wrappers David Brownell
2006-12-20 21:11 ` [patch 2.6.20-rc1 3/6] AT91 " David Brownell
2006-12-21 6:10 ` Andrew Morton
2006-12-21 6:45 ` David Brownell
2006-12-20 21:12 ` [patch 2.6.20-rc1 4/6] PXA " David Brownell
2006-12-21 6:12 ` Andrew Morton
2006-12-21 6:44 ` David Brownell
2006-12-21 14:27 ` Nicolas Pitre
2006-12-21 15:03 ` pHilipp Zabel
2006-12-21 17:25 ` Nicolas Pitre
2006-12-21 19:32 ` pHilipp Zabel
2006-12-21 20:10 ` Nicolas Pitre
2006-12-21 20:32 ` Bill Gatliff
2006-12-22 6:53 ` pHilipp Zabel
2006-12-28 20:47 ` David Brownell
2006-12-30 2:15 ` Nicolas Pitre
2006-12-30 2:38 ` David Brownell
2007-01-01 19:43 ` David Brownell
2006-12-30 1:13 ` David Brownell
2006-12-21 19:25 ` David Brownell
2006-12-27 17:53 ` Pavel Machek
2006-12-28 20:48 ` David Brownell
2006-12-28 20:50 ` Pavel Machek
2006-12-28 20:53 ` Pavel Machek
2006-12-20 21:13 ` [patch 2.6.20-rc1 5/6] SA1100 " David Brownell
2006-12-21 6:13 ` Andrew Morton
2006-12-22 7:16 ` pHilipp Zabel
2006-12-22 15:05 ` Nicolas Pitre
2006-12-30 2:21 ` David Brownell
2006-12-30 3:15 ` Nicolas Pitre
2006-12-30 6:01 ` David Brownell
2006-12-30 13:59 ` pHilipp Zabel
2006-12-30 15:08 ` Russell King
2006-12-23 11:37 ` Russell King
2006-12-23 20:39 ` David Brownell
2006-12-27 18:24 ` Pavel Machek
2006-12-20 21:14 ` [patch 2.6.20-rc1 6/6] S3C2410 " David Brownell
2006-12-21 10:33 ` Arnaud Patard
2006-12-21 15:29 ` pHilipp Zabel
2006-12-23 11:40 ` Russell King
2006-12-20 23:30 ` [patch 2.6.20-rc1 0/6] arch-neutral GPIO calls Håvard Skinnemoen
2006-12-20 23:46 ` David Brownell
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=456293D4.2030103@billgatliff.com \
--to=bgat@billgatliff.com \
--cc=akpm@osdl.org \
--cc=andrew@sanpeople.com \
--cc=david-b@pacbell.net \
--cc=hskinnemoen@atmel.com \
--cc=jamey.hicks@hp.com \
--cc=khilman@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@cam.org \
--cc=rmk@arm.linux.org.uk \
--cc=tony@atomide.com \
/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.