linux-kernel - Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200611202045.09760.david-b@pacbell.net>
Date:	Mon, 20 Nov 2006 20:45:07 -0800
From:	David Brownell <david-b@...bell.net>
To:	Bill Gatliff <bgat@...lgatliff.com>
Cc:	Paul Mundt <lethal@...ux-sh.org>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>,
	Andrew Victor <andrew@...people.com>,
	Haavard Skinnemoen <hskinnemoen@...el.com>, jamey.hicks@...com,
	Kevin Hilman <khilman@...sta.com>,
	Nicolas Pitre <nico@....org>,
	Russell King <rmk@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>
Subject: Re: [patch/rfc 2.6.19-rc5] arch-neutral GPIO calls

On Monday 20 November 2006 7:44 pm, Bill Gatliff wrote:
> David Brownell wrote:
> 
> >A fine example of two platform-specific notions.  First, that GPIO signals
> >are muxed in that way ... they could easily have dedicated pins!!  Second,
> >that there's even a one-to-one association between pins and GPIOs ... I'll
> >repeat the previous example of OMAP1, where certain GPIOs could come out on
> >any of several pins.  And where some pins can be muxed to work with more
> >than one GPIO (but only one at a time, of course).  Clearly, neither pin
> >refcounting nor GPIO claiming can be sufficient to prevent such problems ...
> >
> 
> 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.

Have a look at table 2-5 starting on page 81 of the OMAP 5912 datasheet
("Rev E", omap5912.pdf) linked at the top of

   http://focus.ti.com/docs/prod/folders/print/omap5912.html

GPIOs start at p. 91; there are four banks of GPIO controllers, 16 gpios
each, and also a bank of MPUIOs starting at p. 95 ... half the MPUIO pins
can come out on two different balls, some of the GPIOs can be routed to any
of three different balls.  (A omap5912 is more or less an omap1611, fyi.)

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).

And if you consult table 2-2 on pg. 33 you'll be able to notice things
like ball R13 working for either MPUIO_0 or GPIO_36, ball V10 working
for MPUIO_10 or MPUIO_7, and so on.

- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/