From: Bill Gatliff <bgat@billgatliff.com>
To: David Brownell <david-b@pacbell.net>
Cc: Paul Mundt <lethal@linux-sh.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
Andrew Victor <andrew@sanpeople.com>,
Haavard Skinnemoen <hskinnemoen@atmel.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: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls
Date: Mon, 20 Nov 2006 23:09:46 -0600 [thread overview]
Message-ID: <45628A1A.8060101@billgatliff.com> (raw)
In-Reply-To: <200611202045.09760.david-b@pacbell.net>
David Brownell wrote:
>On Monday 20 November 2006 7:44 pm, Bill Gatliff wrote:
>
>
>>So, you're saying that if GPIOA1 can come out on pins ZZ1 and BB6, then
>>there would be two unique "GPIO numbers", one for each possibility?
>>
>>
>
>No; one number, since it's controlled by the same set of bits in the GPIO
>controller (e.g. bit 12 in the registers of bank 3) regardless of how the
>signals are routed out through pins. That's my point: GPIO number need
>not imply a particular pin, and vice versa.
>
>
Ok, thanks for the OMAP stuff. I think I can understand now.
Why not have GPIO numbers refer to unique combinations of GPIO+pin? If
the GPIO line is tied to a piece of external hardware, that connection
is surely through a specific pin. So it seems like you'd need GPIO+pin
every time there was an option.
>So regardless of whether GPIO_62 is routed to ball M7 or G20, it's still
>going to use number 62, which is bit 14 in various registers of the GPIO4
>module, starting at 0xfffbb400 ... and for good fun, the muxing API will
>refer to the balls on the (smaller) ZZG package even if your board uses
>the larger ZDY package (so your schematics might say J5 not M7, that table
>is very handy in such cases).
>
>
Yikes! :)
Explain to me why having GPIO enumerations map to unique GPIO+pin
combinations would be a bad idea in this case? It seems like the point
here is to help a driver find and assert their GPIO _pin_ so that the
driver can can talk to the attached external hardware. Having an
enumeration "GPIO62M7" would be a handy way to do that. Maybe the
enumeration is actually defined as ((0x400 << 16) | (14 << 8) | 4), or
some other encoding that makes it easy in the implementation of
gpio_XXX() to find the right registers and get the routing set up
correctly. It's just an opaque, magic number to the driver after all.
And since GPIOs are arch/mach/board-specific anyway, who would care if
OMAP was the only system that had an enumeration called "GPIO62M7"?
When other boards set up their platform_struct, they'd use the
enumerations available for that platform. "GPIOA1" in systems where
that GPIO line could only go to one pin per the datasheet, for example.
b.g.
--
Bill Gatliff
bgat@billgatliff.com
next prev parent reply other threads:[~2006-11-21 5:09 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 [this message]
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
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=45628A1A.8060101@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=lethal@linux-sh.org \
--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.