[PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs

Uwe Kleine-König u.kleine-koenig at pengutronix.de
Fri Dec 9 08:01:09 EST 2011

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

Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

More information about the linux-arm-kernel mailing list