Messages in this thread | | | Date | Wed, 7 Dec 2011 10:01:13 +0100 | Subject | Re: [RFC PATCH 2/3] pinctrl: imx: add pinmux-imx53 support | From | Linus Walleij <> |
| |
On Tue, Dec 6, 2011 at 8:33 AM, Lothar Waßmann <LW@karo-electronics.de> wrote: > Shawn Guo writes: >> On Mon, Dec 05, 2011 at 10:18:38PM +0100, Sascha Hauer wrote:
>> > 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. > >> > 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.
In both cases I'd say it's not the business of the pin control implementation to worry about size of .h files in arch/arm/*
Getting rid of such defines and board data is the business of the device tree and nothing else, if I understand the way people are thinking about this.
So I would prefer to keep these two concepts separate: 1) get something in place that integrates nicely with pinctrl 2) get device tree in place 3) get rid of old board files and huge .h define lists including I/O, irqs, pinmux lists... 4) ... 5) profit
So don't try to solve all things at once or you'll end up trying to drink the ocean.
Yours, Linus Walleij -- 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/
| |