[PATCH] [RFC] pinctrl: mvebu: reset pins to an UNKNOWN state on startup

Thomas Petazzoni thomas.petazzoni at free-electrons.com
Wed Oct 24 16:21:39 EDT 2012

Dear Andrew Lunn,

On Wed, 24 Oct 2012 22:15:45 +0200, Andrew Lunn wrote:
> On Wed, Oct 24, 2012 at 09:18:01PM +0200, 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.
> You can get a lot of information from /debug. eg,
> # cat /debug/pinctrl/f1010000.pinctrl/pinconf-groups 

Yes, I was using that one...

> # cat /debug/pinctrl/f1010000.pinctrl/pinmux-pins 
> Pinmux settings per pin
> Format: pin (name): mux_owner gpio_owner hog?

... but not that one.

> If you compare the two, you can see that pin 6 has probably been set by
> uboot, but not by DT.

Indeed, by correlating the two files, you can get a good view of which
pins are configured even though no driver has claimed them. I don't
think it's as clear as having a non-functional device due to the pin
not being muxed at all, but if it is thought as being sufficient, then
fair enough.

Best regards,

Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.

More information about the linux-arm-kernel mailing list