From: sebastian.hesselbarth@gmail.com (Sebastian Hesselbarth)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [RFC] pinctrl: mvebu: reset pins to an UNKNOWN state on startup
Date: Wed, 24 Oct 2012 21:38:23 +0200 [thread overview]
Message-ID: <508843AF.7060803@gmail.com> (raw)
In-Reply-To: <1351106281-31288-1-git-send-email-thomas.petazzoni@free-electrons.com>
On 10/24/2012 09:18 PM, Thomas Petazzoni wrote:
> Note: this patch is a *RFC*, it is not intended for merging, only to
> get a discussion started. The code is horrible, makes terrible
> assumptions and so on.
>
> On many platforms, most of the pinmux initialization is done in the
> bootloader, and therefore persists when we boot the Linux kernel. This
> prevents us from making sure that the pinmux configuration in the
> board device trees is correct.
Thomas,
how you make sure something you don't know about? The bootloader sets
these pinmux settings for a reason and if the DT doesn't tell the kernel
it should make no assumptions at all.
> One idea to make sure our device trees are correct in terms of
> pinmuxing is to set the state of each pin to an unavailable function
> during the initialization of the pinctrl driver. This way, only pins
> that are explicitly configured through proper device tree attributes
> will actually be functional.
>
> Remaining questions to solve:
>
> * Is this useful?
IMHO it isn't - but maybe I am missing the point here. What is it that
you don't like in the bootloaders choice of configuring pinmux?
> * Maybe some pins should be excluded for this, especially if the
> console serial port pins are muxed. On Armada XP, it's not the
> case: UART0 RX/UART0 TX pins are not part of MPPs, so we can clear
> all pins. But on other mvebu platforms, it may be the case.
That's why you don't touch pins that you don't know about. The mvebu
pinctrl is written to overwrite pinctrl settings only if someone
requests a special function. Usually this is done by a developer that
knows about the board.
Sebastian
next prev parent reply other threads:[~2012-10-24 19:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 19:18 [PATCH] [RFC] pinctrl: mvebu: reset pins to an UNKNOWN state on startup Thomas Petazzoni
2012-10-24 19:38 ` Sebastian Hesselbarth [this message]
2012-10-24 19:51 ` Thomas Petazzoni
2012-10-24 20:15 ` Andrew Lunn
2012-10-24 20:21 ` Thomas Petazzoni
2012-10-25 6:51 ` Linus Walleij
2012-10-25 6:46 ` Linus Walleij
2012-10-25 10:27 ` Mark Brown
2012-10-25 15:47 ` Stephen Warren
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=508843AF.7060803@gmail.com \
--to=sebastian.hesselbarth@gmail.com \
--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).