GPIO input / function analysis (was: No GPIO pulldowns)

Andy Green andy at
Sun Feb 24 10:47:11 CET 2008

Hash: SHA1

Somebody in the thread at some point said:

>>  It can be fine... if that's what we intended...
> I think the unused GPIOs want a closer look. There's actually a lot
> of them, also on the Glamo. I think I should have a look at these
> next week, perhaps along with Matt who's recently been playing with
> GPIOs already.

Those are good points.  We talked thismorning about confirming the
current measurement procedure used and the suspicion about the
(relatively minor, but inexplicable) variation in current in suspend
meaning there is floating.

I added support in the suspend dump patch for the GPA[] GPIO bus after I
saw we had some open pins from it, but they are output-only if not
special function selected so they don't make any trouble.  Here they are

[   92.270000] GPA00: ADDR0       0
[   92.270000] GPA01: ADDR16      0
[   92.270000] GPA02: ADDR17      0
[   92.270000] GPA03: ADDR18      0
[   92.270000] GPA04: ADDR19      0
[   92.270000] GPA05: ADDR20      0
[   92.270000] GPA06: ADDR21      0
[   92.270000] GPA07: ADDR22      0
[   92.270000] GPA08: ADDR23      0
[   92.270000] GPA09: ADDR24      0
[   92.270000] GPA10: ADDR25      0
[   92.270000] GPA11: ADDR26      0
[   92.270000] GPA12: nGCS[1]     0
[   92.270000] GPA13: OUTPUT      0
[   92.270000] GPA14: nGCS[3]     0
[   92.270000] GPA15: OUTPUT      0
[   92.270000] GPA16: OUTPUT      1
[   92.270000] GPA17: CLE         0
[   92.270000] GPA18: ALE         0
[   92.270000] GPA19: nFWE        0
[   92.270000] GPA20: nFRE        0
[   92.270000] GPA21: nRSTOUT     0
[   92.270000] GPA22: nFCE        0
[   92.270000] GPA23: OUTPUT      0
[   92.270000] GPA24: OUTPUT      0

It seems most GPIO on all the busses (covering the large number of NCs
we have) are explicit output which is fine.  These are the rest together
with an examination of what they connect to and the implications:


GPE00: I2SLRCK     1  probably we drive ok
GPE01: I2SSCLK     0  probably we drive ok
GPE02: CDCLK       1  we drive ok
GPE03: I2SDI       1  "IIS_OUT" *** confirm level when codec pwr dn ***
GPE04: I2SDO       0  we drive ok
GPE05: SDCLK       0  SDIO CLK we drive ok
GPE06: SDCMD       1  pullup + we drive high / WLAN ok
GPE07: SDDAT0      1  pullup + we drive high / WLAN ok
GPE08: SDDAT1      1  pullup + we drive high / WLAN ok
GPE09: SDDAT2      1  pullup + we drive high / WLAN ok
GPE10: SDDAT3      1  pullup + we drive high / WLAN ok
GPE12: SPIMOSI0    1  we drive ok debug brd
GPE13: SPICLK0     1  we drive ok debug brd
GPE14: IICSCL      1  pullup open drain ok
GPE15: IICSDA      1  pullup open drain ok
GPG01: EINT[9]     1  nPWR_IRQ 100K pullup IO_3V3 OK
GPG02: nSS0        1  master SPI, we drive, debug conn OK
GPG04: EINT[12]    1  Glamo INT# pullup IO_3V3 OK
GPG09: EINT[17]    1  nUSB_OC  100K pullup IO_3V3 ok
GPG10: EINT[18]    1  nUSB_FLT  10K pullup IO_3V3 ok
GPG11: EINT[19]    0  nGSM_OC  100K pullup IO_3V3 via 10K ok
GPG13: input       1  Pullup/pulldown matrix ok
GPG14: input       1  Pullup/pulldown matrix ok
GPG15: input       0  Pullup/pulldown matrix ok
GPH07: RXD[2]      1  Debug RX in 100K pullup IO_3V3 OK
GPJ02: input       1 "HP_IN" headphone 100K pullup ok

Not OK or suspicious:

GPC05: input       1  "PIO_5" BT module *float* *bad* when BT off
GPE11: SPIMISO0    1  *float* Debug brd no pullup! *bad*
GPF00: EINT[0]     1  Motion 1 INT# A5=ok A6 = *float* *bad*
GPG05: input       1  *float* *bad* Motion Sensors OFF!
GPG08: EINT[16]    1  <=== copy of GPG0 !?! *bad*
GPH00: nCTS0       0  RTS_MODEM cpu inp *float* when GSM off *bad*
GPH01: nRTS0       1  CTS_MODEM we drive -- HIGH when GSM off *bad*
GPH03: RXD[0]      1  TX_MODEM cpu inp *float* when GSM off *bad*
GPH05: RXD[1]      1  GPS_TX_M cpu inp *float* when GPS off *bad*
GPH08: UEXTCLK     1 *NC* *FLOAT* *bad* *bad* *bad*
GPJ00: input       1 *NC* *FLOAT* *bad* *bad* *bad*
GPJ07: input       1  WLAN_GPIO0 *** is it driven? no ext pullup

Lots of bad boys in there we can do something about.  They may be
responsible for some of the suspend current variation but it probably
won't be a huge obvious difference when they get fixed.  But it will
definitely assist stability.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list