linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: tegra: rely on bootloader pinmux programming on Tegra124
Date: Fri, 05 Sep 2014 11:07:42 -0600	[thread overview]
Message-ID: <5409EDDE.6060305@wwwdotorg.org> (raw)
In-Reply-To: <1409758926-22966-1-git-send-email-swarren@wwwdotorg.org>

On 09/03/2014 09:42 AM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> The defined mechanism for programming the Tegra pinmux is to perform all
> of the following at once in order, before using any I/O controller that
> is affected by the pinmux:
>
> - Set the CLAMP_INPUTS_WHEN_TRISTATED PMC register bit.
> - Set up any GPIO pins to their "initial" state.
> - Program all pinmux settings in one go.
>
> Other methods such as:
>
> - Not setting CLAMP_INPUTS_WHEN_TRISTATED.
> - Not setting GPIOs to their "initial" state before programming the
>    pinmux settings of the related pin, in particular the mux function.
> - Not programming the entire pinmux at once, in order to avoid
>    possible conflicting settings.
>
> ... are not qualified or supported by NVIDIA ASIC/syseng. They could
> cause glitches or undesired output levels on some pins, or controller
> malfunction.
>
> While we've been getting away with doing something different on many
> Tegra boards without issue, I believe we've just been getting lucky.
> I'd like to switch all Tegra124 systems to the correct scheme now so
> they provide the right example to follow, and require that any new
> boards we support upstream work in the same fashion.
>
> While it would be nice to update boards containing older SoCs for
> consistency, I don't anticipate doing so. It's too much churn to change
> at this time. At least with all Tegra124 boards converted, the most
> recent boards provide the correct example.
>
> Since the bootloader needs to reprogram the pinmux to access certain
> peripherals, it must program the entire pinmux due to the supported
> rules above. As such, there is no need to program any part of the pinmux
> from the kernel, unless dynamic pinmuxing is used. Given this, we couuld
> simply remove the pinmux "default" state from the DT entirely. However,
> some bootloaders parse the DT to perform their initial pinmux setup, so
> it's useful to keep the pinmux data in DT. To allow this while avoiding
> redundant work in the kernel, rename the "default" state to "boot". The
> kernel won't apply this, but bootloaders can still look for this state
> name and apply it. Note however that the DT provides zero information
> about the required initial GPIO setup, so bootloaders using this approach
> are not likely to operate correctly without an additional GPIO
> initialization table somewhere. Previous discussions on the DT mailing
> list have rejected adding such a table to DT...
>
> The following U-Boot commits fully initialize the pinmux:
>
> Jetson TK1: 4ff213b8e478 ARM: tegra: clamp inputs on Jetson TK1
> Venice2: 3365479ce78a ARM: tegra: Venice2 pinmux spreadsheet updates
> Both are part of U-Boot v2014.07 and later.
>
> Without those commits, the only fallout I see from this change is that
> HDMI on Venice2 no longer works. Given the very small user-base of this
> platform, I feel that requiring a bootloader update is reasonable.

I've applied this to Tegra's for-3.18/dt branch.

      reply	other threads:[~2014-09-05 17:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-03 15:42 [PATCH] ARM: tegra: rely on bootloader pinmux programming on Tegra124 Stephen Warren
2014-09-05 17:07 ` Stephen Warren [this message]

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=5409EDDE.6060305@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).