[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
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the linux-arm-kernel
mailing list