Messages in this thread | | | Date | Tue, 6 Dec 2011 16:00:06 +0800 | From | Shawn Guo <> | Subject | Re: [RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support |
| |
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
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |