[PATCH 1/4 v4] drivers: create a pin control subsystem
Linus Walleij
linus.walleij at linaro.org
Thu Aug 25 07:58:12 EDT 2011
On Thu, Aug 25, 2011 at 1:04 PM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> Not really. UART2_CTS can't be routed to arbitrary pads, but it can be
> routed to more than one pad:
>
> #define _MX51_PAD_EIM_D16__UART2_CTS IOMUX_PAD(0x3f0, 0x5c, 3, 0x0000, 0, 0)
> #define _MX51_PAD_EIM_D25__UART2_CTS IOMUX_PAD(0x414, 0x80, 4, 0x0000, 0, 0)
> #define _MX51_PAD_USBH1_DATA0__UART2_CTS IOMUX_PAD(0x688, 0x288, 1, 0x0000, 0, 0)
Aha!
Is it typically a few pads like this, say 2,3,4 alternatives,
sometimes just one?
So the actual relation is not 1..1 nor 1...* but 1..<a few>?
> This is why there can't be a setup_iomux(uart2) function without
> being able to specify *which* pads in a board specific way.
In the current design it is the pinmux driver that
keeps track of that. Not the subsystem.
I think the question then is how the pinctrl subsystem
can help out in keeping that information together.
I'll try to think of something ...
Thanks,
Linus Walleij
More information about the linux-arm-kernel
mailing list