[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