BBB pull contention

GoogleGroups
1

Speaking of contention, I reported one in the BBB four months ago:
http://bugs.elinux.org/issues/155

Does anybody actually read the bug tracker?

Matthijs

2

Nah, that one is my fault.. That bug report must be bad luck, as
every time i started looking at it, something at the day job pulled me
away..

I know Jason's been trying to get more software developers involved,
Mark's been hacking on bonescript and Drew (who's started a new job)
has been helping out too..

Otherwise, the org's a little undermanned. :wink:

Regards,

3

OK, thing is, although it didn't seem particularly important to me when I
first found it since the pull current isn't much and the input is
smith-triggered, the am572x erratum makes it clear that keeping an input at
intermediate level for extended time is nevertheless harmful. It seems
likely to me the same thing will apply to the am335x.

Matthijs

4

So, P9.15, gpmc_a0 is setup as:

{OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */

so, gpmc_csn3 (which is also used by the bbgw as mmc2_cmd)

{OFFSET(gpmc_csn3), (MODE(3) | RXACTIVE | PULLUP_EN)},

So i'm thinking:

http://paste.debian.net/381383/

Regards,

5

So, P9.15, gpmc_a0 is setup as:

{OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */

Those are different pins. The only useful purpose of pin 16 ("gpmc_a0") on
a BBB is as pwm 1 tripzone input.

mmc1 pins are obviously not double-mapped with anything.

so, gpmc_csn3 (which is also used by the bbgw as mmc2_cmd)

mmc2 cmd is indeed the only useful use of the other pin of the pair.

I'm thinking just disable the pull of pin 16 ("gpmc_a0"). The pull of the
other pin should already take care of things.

In general in DTs I would also recommend disabling (gpio input, rx
disabled, no pull) the "other pin" of any pin-pair whenever one is in use,
but at a minimum they should avoid a pull conflict. There are three such
pairs, see P9 tab of my pins spreadsheet -> https://goo.gl/Jkcg0w

Matthijs

6

So, P9.15, gpmc_a0 is setup as:

{OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */

Those are different pins. The only useful purpose of pin 16 ("gpmc_a0") on a
BBB is as pwm 1 tripzone input.

mmc1 pins are obviously not double-mapped with anything.

/* P9.15 */
{OFFSET(gpmc_a0), MODE(0) | PULLUDDIS},
{OFFSET(gpmc_csn3), (MODE(3) | RXACTIVE | PULLUP_EN)},

so, gpmc_csn3 (which is also used by the bbgw as mmc2_cmd)

mmc2 cmd is indeed the only useful use of the other pin of the pair.

I'm thinking just disable the pull of pin 16 ("gpmc_a0"). The pull of the
other pin should already take care of things.

In general in DTs I would also recommend disabling (gpio input, rx disabled,
no pull) the "other pin" of any pin-pair whenever one is in use, but at a
minimum they should avoid a pull conflict. There are three such pairs, see
P9 tab of my pins spreadsheet -> https://goo.gl/Jkcg0w

Yeah, P9.41/42..

We do separate them out:

I'll have to fix up:

bone_eqep0-00A0.dts

as it uses: BONE_P9_41B

But doesn't unset P9_41A

Regards,