[RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support
Shawn Guo
shawn.guo at freescale.com
Tue Dec 6 03:00:06 EST 2011
On Tue, Dec 06, 2011 at 08:33:28AM +0100, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
> > On Mon, Dec 05, 2011 at 10:18:38PM +0100, Sascha Hauer wrote:
> > > Freescale has named the pins after their primary function which is quite
> > > confusing.
> > >
> > > The above means:
> > >
> > > MX53_PATA_DATA8 -> mux mode 4
> > > MX53_PATA_DATA9 -> mux mode 4
> > > ...
> > >
> > > This brings me to the point that currently we have the pins described as
> > >
> > > #define MX53_PAD_<name>__<function>
> > >
> > But that's also the reason why we have so many lengthy iomux-mx*.h on
> > imx. Taking iomux-mx53.h for example, it's a 109K header with 1219
> > LOC, but probably only 10% of the definitions will actually be used.
> >
> Which has the benefit of having correct pin definitions for everyone
> to use. If developers who need to use currently unused pindefs have to
> create them on their own, there will always be a good chance in
> getting them wrong.
If the configuration is not working, they will notice it's wrong anyway.
>
> > > which means that you don't have to look into the datasheet to get the
> > > different options for a pin
> >
> > Looking at the datasheet when we write code is a pretty natural thing
> > to me.
> >
> The pindefs are like interrupt numbers or IO addresses for which there
> also is a complete list of definitions in the kernel no matter whether
> they are actually all in use.
>
The interrupt list is much shorter than iomux list here, which enumerate
every single function for every single pad. Also, most interrupts stand
a pretty good chance to be used, while most of the pad functions do not.
--
Regards,
Shawn
More information about the linux-arm-kernel
mailing list