[v2,0/4] ARM: dts: meson: set pinmux bias

Message

Jerome Brunet Nov. 9, 2018, 2:04 p.m. UTC

On Amlogic chipsets, the bias set through pinconf applies to the pad
itself, not only the GPIO function. This means that even when we change
the function of the pad from GPIO to anything else, the bias previously
set still applies.

While trying to boot from SPI, I noticed the eMMC was not working anymore.
Even if the related eMMC pad are not used by the SPI, the ROM code sets a
pull-down on the eMMC pad and leaves it that way. This breaks the eMMC
later on, in both u-boot and Linux.

The underlying issue is that we inherit whatever was left by previous user
of the pad (pinconf, u-boot or the ROM code). As a consequence, the actual
setup we get is undefined.

There is nothing mentioned in the documentation about pad bias and pinmux
function, however leaving it undefined is not an option.

This patchset consistently disable the pad bias for every pinmux functions.
It seems to work well, we can only assume that the necessary bias (if any)
is already provided by the pin function itself.

I can't really test every pinmux configuration and it is fairly possible
I missed something so it would be nice if more people could confirm if
nothing (new) is broken after applying this series.

One things could be the i2c. Usually the i2c pull-ups are physically
present on the board but, if they are missing on platform, we may define
a special pinmux setting with pull-up enabled.

One last gotcha, I recently posted fixups around bias setting to pinctrl
which have been merged: [0] [1]. These must be applied before applying this
series, otherwise when requesting 'bias-disable' you'll probably get a
pull-down instead.

Changes since v1 [2]:
 * Fix wrongly placed bias-disable on meson8

[0]: https://lkml.kernel.org/r/[e-mail]
[1]: https://lkml.kernel.org/r/[e-mail]
[2]: https://lkml.kernel.org/r/[e-mail]

Jerome Brunet (4):
  arm64: dts: meson: remove extra subnode in mmc clk_gate pinmux
  arm64: dts: meson: disable pad bias for mmc pinmuxes
  arm64: dts: meson: consistently disable pin bias
  ARM: dts: meson: consistently disable pin bias

 arch/arm/boot/dts/meson8.dtsi               |  12 +++
 arch/arm/boot/dts/meson8b.dtsi              |   9 ++
 arch/arm/boot/dts/meson8m2.dtsi             |   1 +
 arch/arm64/boot/dts/amlogic/meson-axg.dtsi  | 111 ++++++++++++++++++--
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi |  60 +++++++++--
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  |  62 +++++++++--
 6 files changed, 231 insertions(+), 24 deletions(-)

Comments

Kevin Hilman Nov. 15, 2018, 8:22 p.m. UTC | #1

Jerome Brunet <[e-mail]> writes:

> On Amlogic chipsets, the bias set through pinconf applies to the pad
> itself, not only the GPIO function. This means that even when we change
> the function of the pad from GPIO to anything else, the bias previously
> set still applies.
>
> While trying to boot from SPI, I noticed the eMMC was not working anymore.
> Even if the related eMMC pad are not used by the SPI, the ROM code sets a
> pull-down on the eMMC pad and leaves it that way. This breaks the eMMC
> later on, in both u-boot and Linux.
>
> The underlying issue is that we inherit whatever was left by previous user
> of the pad (pinconf, u-boot or the ROM code). As a consequence, the actual
> setup we get is undefined.
>
> There is nothing mentioned in the documentation about pad bias and pinmux
> function, however leaving it undefined is not an option.
>
> This patchset consistently disable the pad bias for every pinmux functions.
> It seems to work well, we can only assume that the necessary bias (if any)
> is already provided by the pin function itself.
>
> I can't really test every pinmux configuration and it is fairly possible
> I missed something so it would be nice if more people could confirm if
> nothing (new) is broken after applying this series.

I'll queue this up for v4.21/dt64 branch for a bit broader testing.

> One things could be the i2c. Usually the i2c pull-ups are physically
> present on the board but, if they are missing on platform, we may define
> a special pinmux setting with pull-up enabled.
>
> One last gotcha, I recently posted fixups around bias setting to pinctrl
> which have been merged: [0] [1]. These must be applied before applying this
> series, otherwise when requesting 'bias-disable' you'll probably get a
> pull-down instead.

OK, I'll include pinctrl/for-next branch in my 'integ' branch.

Kevin