From: u.kleine-koenig@pengutronix.de (Uwe Kleine-König)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs
Date: Fri, 9 Dec 2011 14:01:09 +0100 [thread overview]
Message-ID: <20111209130109.GT4585@pengutronix.de> (raw)
In-Reply-To: <20111209110807.GG27267@pengutronix.de>
On Fri, Dec 09, 2011 at 12:08:07PM +0100, Sascha Hauer wrote:
> On Fri, Dec 09, 2011 at 01:14:14PM +0800, Shawn Guo wrote:
> > On Thu, Dec 08, 2011 at 09:47:24PM -0700, Stephen Warren wrote:
> > >
> > > pin X: function = UART A TX
> > > pin Y: function = UART A RX
> > >
> >
> > We really do not expect per pin function mapping but per block function
> > mapping. That said, the UART driver is going to tell pinctrl subsystem
> > "I'm UARTA, please set all my pins up for me".
>
> I still think it should be "I'm board Y, please set all my pins up for me"
>
> Drivers should not be bothered with pin muxing *at all*. When we add
> pinmux_request to drivers all SoCs using this driver are doomed to
> implement pinmux support regardless if they have any pinmux support in
> hardware or not.
> Where this leads we can currently see in current next branch with the
> smc91x driver where one single board has a regulator for. Suddenly all
> other boards using this driver stopped working because they have no
> regulator provided for the driver.
It's the same problem with clks. IMHO that's OK.
> There is this CONFIG_REGULATOR_DUMMY option which will cause *all*
> regulator_request to succeed on all regulators in this binary which
> disqualifies this option for multiboard/SoC Kernels.
> A pin setup is board specific and not driver specific. There are only
An upside of making drivers pinctrl-aware is that it might solve the
hardware conflicts on development boards. And the way pinctrl works it's
still the board that sets up the connection between device and how which
pins are configured.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2011-12-09 13:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 22:40 [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs Uwe Kleine-König
2011-12-08 22:55 ` Arnd Bergmann
2011-12-09 9:23 ` Uwe Kleine-König
2011-12-09 13:55 ` Arnd Bergmann
2011-12-09 14:15 ` Uwe Kleine-König
2011-12-08 23:14 ` Stephen Warren
2011-12-09 1:01 ` Shawn Guo
2011-12-09 3:44 ` Stephen Warren
2011-12-09 4:32 ` Shawn Guo
2011-12-09 4:47 ` Stephen Warren
2011-12-09 5:14 ` Shawn Guo
2011-12-09 11:08 ` Sascha Hauer
2011-12-09 13:01 ` Uwe Kleine-König [this message]
2011-12-10 0:18 ` Linus Walleij
2011-12-12 14:37 ` Sascha Hauer
2011-12-12 15:29 ` Uwe Kleine-König
2011-12-13 0:41 ` Linus Walleij
2011-12-09 16:53 ` Stephen Warren
2011-12-09 15:03 ` Dong Aisheng
2011-12-09 16:49 ` Stephen Warren
2011-12-09 17:24 ` Tony Lindgren
2011-12-09 17:53 ` Tony Lindgren
2011-12-10 0:14 ` Stephen Warren
2011-12-11 19:34 ` Tony Lindgren
2011-12-09 9:31 ` Uwe Kleine-König
2011-12-10 0:04 ` Linus Walleij
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=20111209130109.GT4585@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--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).