pinctrl: imx5: start numbering pad from 0

Unlike imx6q pinctrl driver that starts nubmering pad from 0, imx5 pinctrl drivers number pad from 1. It causes problem/confusion when driver accesses imx51_pinctrl_pads array using pin ID as the index.

Change imx51_pads and imx53_pads numbering start from 0.

Signed-off-by Shawn Guo <[email protected]>

---
 drivers/pinctrl/pinctrl-imx51.c |  490 +++++++++++++++++++-------------------
 drivers/pinctrl/pinctrl-imx53.c |  402 ++++++++++++++++----------------
 2 files changed, 446 insertions(+), 446 deletions(-)

drivers/pinctrl/pinctrl-imx51.c +245 -245

index 9fd0216..fb84689 100644
@@ -23,251 +23,251 @@
 #include "pinctrl-imx.h"
 
 enum imx51_pads {
-       MX51_PAD_EIM_D16 = 1,
-       MX51_PAD_EIM_D17 = 2,
-       MX51_PAD_EIM_D18 = 3,
-       MX51_PAD_EIM_D19 = 4,
-       MX51_PAD_EIM_D20 = 5,
-       MX51_PAD_EIM_D21 = 6,
-       MX51_PAD_EIM_D22 = 7,
-       MX51_PAD_EIM_D23 = 8,
-       MX51_PAD_EIM_D24 = 9,
-       MX51_PAD_EIM_D25 = 10,
-       MX51_PAD_EIM_D26 = 11,
-       MX51_PAD_EIM_D27 = 12,
-       MX51_PAD_EIM_D28 = 13,
-       MX51_PAD_EIM_D29 = 14,
-       MX51_PAD_EIM_D30 = 15,
-       MX51_PAD_EIM_D31 = 16,
-       MX51_PAD_EIM_A16 = 17,
-       MX51_PAD_EIM_A17 = 18,
-       MX51_PAD_EIM_A18 = 19,
-       MX51_PAD_EIM_A19 = 20,
-       MX51_PAD_EIM_A20 = 21,
-       MX51_PAD_EIM_A21 = 22,
-       MX51_PAD_EIM_A22 = 23,
-       MX51_PAD_EIM_A23 = 24,
-       MX51_PAD_EIM_A24 = 25,
-       MX51_PAD_EIM_A25 = 26,
-       MX51_PAD_EIM_A26 = 27,
-       MX51_PAD_EIM_A27 = 28,
-       MX51_PAD_EIM_EB0 = 29,
-       MX51_PAD_EIM_EB1 = 30,
-       MX51_PAD_EIM_EB2 = 31,
-       MX51_PAD_EIM_EB3 = 32,
-       MX51_PAD_EIM_OE = 33,
-       MX51_PAD_EIM_CS0 = 34,
-       MX51_PAD_EIM_CS1 = 35,
-       MX51_PAD_EIM_CS2 = 36,
-       MX51_PAD_EIM_CS3 = 37,
-       MX51_PAD_EIM_CS4 = 38,
-       MX51_PAD_EIM_CS5 = 39,
-       MX51_PAD_EIM_DTACK = 40,
-       MX51_PAD_EIM_LBA = 41,
-       MX51_PAD_EIM_CRE = 42,
-       MX51_PAD_DRAM_CS1 = 43,
-       MX51_PAD_NANDF_WE_B = 44,
-       MX51_PAD_NANDF_RE_B = 45,
-       MX51_PAD_NANDF_ALE = 46,
-       MX51_PAD_NANDF_CLE = 47,
-       MX51_PAD_NANDF_WP_B = 48,
-       MX51_PAD_NANDF_RB0 = 49,
-       MX51_PAD_NANDF_RB1 = 50,
-       MX51_PAD_NANDF_RB2 = 51,
-       MX51_PAD_NANDF_RB3 = 52,
-       MX51_PAD_GPIO_NAND = 53,
-       MX51_PAD_NANDF_CS0 = 54,
-       MX51_PAD_NANDF_CS1 = 55,
-       MX51_PAD_NANDF_CS2 = 56,
-       MX51_PAD_NANDF_CS3 = 57,
-       MX51_PAD_NANDF_CS4 = 58,
-       MX51_PAD_NANDF_CS5 = 59,
-       MX51_PAD_NANDF_CS6 = 60,
-       MX51_PAD_NANDF_CS7 = 61,
-       MX51_PAD_NANDF_RDY_INT = 62,
-       MX51_PAD_NANDF_D15 = 63,
-       MX51_PAD_NANDF_D14 = 64,
-       MX51_PAD_NANDF_D13 = 65,
-       MX51_PAD_NANDF_D12 = 66,
-       MX51_PAD_NANDF_D11 = 67,
-       MX51_PAD_NANDF_D10 = 68,
-       MX51_PAD_NANDF_D9 = 69,
-       MX51_PAD_NANDF_D8 = 70,
-       MX51_PAD_NANDF_D7 = 71,
-       MX51_PAD_NANDF_D6 = 72,
-       MX51_PAD_NANDF_D5 = 73,
-       MX51_PAD_NANDF_D4 = 74,
-       MX51_PAD_NANDF_D3 = 75,
-       MX51_PAD_NANDF_D2 = 76,
-       MX51_PAD_NANDF_D1 = 77,
-       MX51_PAD_NANDF_D0 = 78,
-       MX51_PAD_CSI1_D8 = 79,
-       MX51_PAD_CSI1_D9 = 80,
-       MX51_PAD_CSI1_D10 = 81,
-       MX51_PAD_CSI1_D11 = 82,
-       MX51_PAD_CSI1_D12 = 83,
-       MX51_PAD_CSI1_D13 = 84,
-       MX51_PAD_CSI1_D14 = 85,
-       MX51_PAD_CSI1_D15 = 86,
-       MX51_PAD_CSI1_D16 = 87,
-       MX51_PAD_CSI1_D17 = 88,
-       MX51_PAD_CSI1_D18 = 89,
-       MX51_PAD_CSI1_D19 = 90,
-       MX51_PAD_CSI1_VSYNC = 91,
-       MX51_PAD_CSI1_HSYNC = 92,
-       MX51_PAD_CSI1_PIXCLK = 93,
-       MX51_PAD_CSI1_MCLK = 94,
-       MX51_PAD_CSI2_D12 = 95,
-       MX51_PAD_CSI2_D13 = 96,
-       MX51_PAD_CSI2_D14 = 97,
-       MX51_PAD_CSI2_D15 = 98,
-       MX51_PAD_CSI2_D16 = 99,
-       MX51_PAD_CSI2_D17 = 100,
-       MX51_PAD_CSI2_D18 = 101,
-       MX51_PAD_CSI2_D19 = 102,
-       MX51_PAD_CSI2_VSYNC = 103,
-       MX51_PAD_CSI2_HSYNC = 104,
-       MX51_PAD_CSI2_PIXCLK = 105,
-       MX51_PAD_I2C1_CLK = 106,
-       MX51_PAD_I2C1_DAT = 107,
-       MX51_PAD_AUD3_BB_TXD = 108,
-       MX51_PAD_AUD3_BB_RXD = 109,
-       MX51_PAD_AUD3_BB_CK = 110,
-       MX51_PAD_AUD3_BB_FS = 111,
-       MX51_PAD_CSPI1_MOSI = 112,
-       MX51_PAD_CSPI1_MISO = 113,
-       MX51_PAD_CSPI1_SS0 = 114,
-       MX51_PAD_CSPI1_SS1 = 115,
-       MX51_PAD_CSPI1_RDY = 116,
-       MX51_PAD_CSPI1_SCLK = 117,
-       MX51_PAD_UART1_RXD = 118,
-       MX51_PAD_UART1_TXD = 119,
-       MX51_PAD_UART1_RTS = 120,
-       MX51_PAD_UART1_CTS = 121,
-       MX51_PAD_UART2_RXD = 122,
-       MX51_PAD_UART2_TXD = 123,
-       MX51_PAD_UART3_RXD = 124,
-       MX51_PAD_UART3_TXD = 125,
-       MX51_PAD_OWIRE_LINE = 126,
-       MX51_PAD_KEY_ROW0 = 127,
-       MX51_PAD_KEY_ROW1 = 128,
-       MX51_PAD_KEY_ROW2 = 129,
-       MX51_PAD_KEY_ROW3 = 130,
-       MX51_PAD_KEY_COL0 = 131,
-       MX51_PAD_KEY_COL1 = 132,
-       MX51_PAD_KEY_COL2 = 133,
-       MX51_PAD_KEY_COL3 = 134,
-       MX51_PAD_KEY_COL4 = 135,
-       MX51_PAD_KEY_COL5 = 136,
-       MX51_PAD_USBH1_CLK = 137,
-       MX51_PAD_USBH1_DIR = 138,
-       MX51_PAD_USBH1_STP = 139,
-       MX51_PAD_USBH1_NXT = 140,
-       MX51_PAD_USBH1_DATA0 = 141,
-       MX51_PAD_USBH1_DATA1 = 142,
-       MX51_PAD_USBH1_DATA2 = 143,
-       MX51_PAD_USBH1_DATA3 = 144,
-       MX51_PAD_USBH1_DATA4 = 145,
-       MX51_PAD_USBH1_DATA5 = 146,
-       MX51_PAD_USBH1_DATA6 = 147,
-       MX51_PAD_USBH1_DATA7 = 148,
-       MX51_PAD_DI1_PIN11 = 149,
-       MX51_PAD_DI1_PIN12 = 150,
-       MX51_PAD_DI1_PIN13 = 151,
-       MX51_PAD_DI1_D0_CS = 152,
-       MX51_PAD_DI1_D1_CS = 153,
-       MX51_PAD_DISPB2_SER_DIN = 154,
-       MX51_PAD_DISPB2_SER_DIO = 155,
-       MX51_PAD_DISPB2_SER_CLK = 156,
-       MX51_PAD_DISPB2_SER_RS = 157,
-       MX51_PAD_DISP1_DAT0 = 158,
-       MX51_PAD_DISP1_DAT1 = 159,
-       MX51_PAD_DISP1_DAT2 = 160,
-       MX51_PAD_DISP1_DAT3 = 161,
-       MX51_PAD_DISP1_DAT4 = 162,
-       MX51_PAD_DISP1_DAT5 = 163,
-       MX51_PAD_DISP1_DAT6 = 164,
-       MX51_PAD_DISP1_DAT7 = 165,
-       MX51_PAD_DISP1_DAT8 = 166,
-       MX51_PAD_DISP1_DAT9 = 167,
-       MX51_PAD_DISP1_DAT10 = 168,
-       MX51_PAD_DISP1_DAT11 = 169,
-       MX51_PAD_DISP1_DAT12 = 170,
-       MX51_PAD_DISP1_DAT13 = 171,
-       MX51_PAD_DISP1_DAT14 = 172,
-       MX51_PAD_DISP1_DAT15 = 173,
-       MX51_PAD_DISP1_DAT16 = 174,
-       MX51_PAD_DISP1_DAT17 = 175,
-       MX51_PAD_DISP1_DAT18 = 176,
-       MX51_PAD_DISP1_DAT19 = 177,
-       MX51_PAD_DISP1_DAT20 = 178,
-       MX51_PAD_DISP1_DAT21 = 179,
-       MX51_PAD_DISP1_DAT22 = 180,
-       MX51_PAD_DISP1_DAT23 = 181,
-       MX51_PAD_DI1_PIN3 = 182,
-       MX51_PAD_DI1_PIN2 = 183,
-       MX51_PAD_DI_GP2 = 184,
-       MX51_PAD_DI_GP3 = 185,
-       MX51_PAD_DI2_PIN4 = 186,
-       MX51_PAD_DI2_PIN2 = 187,
-       MX51_PAD_DI2_PIN3 = 188,
-       MX51_PAD_DI2_DISP_CLK = 189,
-       MX51_PAD_DI_GP4 = 190,
-       MX51_PAD_DISP2_DAT0 = 191,
-       MX51_PAD_DISP2_DAT1 = 192,
-       MX51_PAD_DISP2_DAT2 = 193,
-       MX51_PAD_DISP2_DAT3 = 194,
-       MX51_PAD_DISP2_DAT4 = 195,
-       MX51_PAD_DISP2_DAT5 = 196,
-       MX51_PAD_DISP2_DAT6 = 197,
-       MX51_PAD_DISP2_DAT7 = 198,
-       MX51_PAD_DISP2_DAT8 = 199,
-       MX51_PAD_DISP2_DAT9 = 200,
-       MX51_PAD_DISP2_DAT10 = 201,
-       MX51_PAD_DISP2_DAT11 = 202,
-       MX51_PAD_DISP2_DAT12 = 203,
-       MX51_PAD_DISP2_DAT13 = 204,
-       MX51_PAD_DISP2_DAT14 = 205,
-       MX51_PAD_DISP2_DAT15 = 206,
-       MX51_PAD_SD1_CMD = 207,
-       MX51_PAD_SD1_CLK = 208,
-       MX51_PAD_SD1_DATA0 = 209,
-       MX51_PAD_EIM_DA0 = 210,
-       MX51_PAD_EIM_DA1 = 211,
-       MX51_PAD_EIM_DA2 = 212,
-       MX51_PAD_EIM_DA3 = 213,
-       MX51_PAD_SD1_DATA1 = 214,
-       MX51_PAD_EIM_DA4 = 215,
-       MX51_PAD_EIM_DA5 = 216,
-       MX51_PAD_EIM_DA6 = 217,
-       MX51_PAD_EIM_DA7 = 218,
-       MX51_PAD_SD1_DATA2 = 219,
-       MX51_PAD_EIM_DA10 = 220,
-       MX51_PAD_EIM_DA11 = 221,
-       MX51_PAD_EIM_DA8 = 222,
-       MX51_PAD_EIM_DA9 = 223,
-       MX51_PAD_SD1_DATA3 = 224,
-       MX51_PAD_GPIO1_0 = 225,
-       MX51_PAD_GPIO1_1 = 226,
-       MX51_PAD_EIM_DA12 = 227,
-       MX51_PAD_EIM_DA13 = 228,
-       MX51_PAD_EIM_DA14 = 229,
-       MX51_PAD_EIM_DA15 = 230,
-       MX51_PAD_SD2_CMD = 231,
-       MX51_PAD_SD2_CLK = 232,
-       MX51_PAD_SD2_DATA0 = 233,
-       MX51_PAD_SD2_DATA1 = 234,
-       MX51_PAD_SD2_DATA2 = 235,
-       MX51_PAD_SD2_DATA3 = 236,
-       MX51_PAD_GPIO1_2 = 237,
-       MX51_PAD_GPIO1_3 = 238,
-       MX51_PAD_PMIC_INT_REQ = 239,
-       MX51_PAD_GPIO1_4 = 240,
-       MX51_PAD_GPIO1_5 = 241,
-       MX51_PAD_GPIO1_6 = 242,
-       MX51_PAD_GPIO1_7 = 243,
-       MX51_PAD_GPIO1_8 = 244,
-       MX51_PAD_GPIO1_9 = 245,
+       MX51_PAD_EIM_D16 = 0,
+       MX51_PAD_EIM_D17 = 1,
+       MX51_PAD_EIM_D18 = 2,
+       MX51_PAD_EIM_D19 = 3,
+       MX51_PAD_EIM_D20 = 4,
+       MX51_PAD_EIM_D21 = 5,
+       MX51_PAD_EIM_D22 = 6,
+       MX51_PAD_EIM_D23 = 7,
+       MX51_PAD_EIM_D24 = 8,
+       MX51_PAD_EIM_D25 = 9,
+       MX51_PAD_EIM_D26 = 10,
+       MX51_PAD_EIM_D27 = 11,
+       MX51_PAD_EIM_D28 = 12,
+       MX51_PAD_EIM_D29 = 13,
+       MX51_PAD_EIM_D30 = 14,
+       MX51_PAD_EIM_D31 = 15,
+       MX51_PAD_EIM_A16 = 16,
+       MX51_PAD_EIM_A17 = 17,
+       MX51_PAD_EIM_A18 = 18,
+       MX51_PAD_EIM_A19 = 19,
+       MX51_PAD_EIM_A20 = 20,
+       MX51_PAD_EIM_A21 = 21,
+       MX51_PAD_EIM_A22 = 22,
+       MX51_PAD_EIM_A23 = 23,
+       MX51_PAD_EIM_A24 = 24,
+       MX51_PAD_EIM_A25 = 25,
+       MX51_PAD_EIM_A26 = 26,
+       MX51_PAD_EIM_A27 = 27,
+       MX51_PAD_EIM_EB0 = 28,
+       MX51_PAD_EIM_EB1 = 29,
+       MX51_PAD_EIM_EB2 = 30,
+       MX51_PAD_EIM_EB3 = 31,
+       MX51_PAD_EIM_OE = 32,
+       MX51_PAD_EIM_CS0 = 33,
+       MX51_PAD_EIM_CS1 = 34,
+       MX51_PAD_EIM_CS2 = 35,
+       MX51_PAD_EIM_CS3 = 36,
+       MX51_PAD_EIM_CS4 = 37,
+       MX51_PAD_EIM_CS5 = 38,
+       MX51_PAD_EIM_DTACK = 39,
+       MX51_PAD_EIM_LBA = 40,
+       MX51_PAD_EIM_CRE = 41,
+       MX51_PAD_DRAM_CS1 = 42,
+       MX51_PAD_NANDF_WE_B = 43,
+       MX51_PAD_NANDF_RE_B = 44,
+       MX51_PAD_NANDF_ALE = 45,
+       MX51_PAD_NANDF_CLE = 46,
+       MX51_PAD_NANDF_WP_B = 47,
+       MX51_PAD_NANDF_RB0 = 48,
+       MX51_PAD_NANDF_RB1 = 49,
+       MX51_PAD_NANDF_RB2 = 50,
+       MX51_PAD_NANDF_RB3 = 51,
+       MX51_PAD_GPIO_NAND = 52,
+       MX51_PAD_NANDF_CS0 = 53,
+       MX51_PAD_NANDF_CS1 = 54,
+       MX51_PAD_NANDF_CS2 = 55,
+       MX51_PAD_NANDF_CS3 = 56,
+       MX51_PAD_NANDF_CS4 = 57,
+       MX51_PAD_NANDF_CS5 = 58,
+       MX51_PAD_NANDF_CS6 = 59,
+       MX51_PAD_NANDF_CS7 = 60,
+       MX51_PAD_NANDF_RDY_INT = 61,
+       MX51_PAD_NANDF_D15 = 62,
+       MX51_PAD_NANDF_D14 = 63,
+       MX51_PAD_NANDF_D13 = 64,
+       MX51_PAD_NANDF_D12 = 65,
+       MX51_PAD_NANDF_D11 = 66,
+       MX51_PAD_NANDF_D10 = 67,
+       MX51_PAD_NANDF_D9 = 68,
+       MX51_PAD_NANDF_D8 = 69,
+       MX51_PAD_NANDF_D7 = 70,
+       MX51_PAD_NANDF_D6 = 71,
+       MX51_PAD_NANDF_D5 = 72,
+       MX51_PAD_NANDF_D4 = 73,
+       MX51_PAD_NANDF_D3 = 74,
+       MX51_PAD_NANDF_D2 = 75,
+       MX51_PAD_NANDF_D1 = 76,
+       MX51_PAD_NANDF_D0 = 77,
+       MX51_PAD_CSI1_D8 = 78,
+       MX51_PAD_CSI1_D9 = 79,
+       MX51_PAD_CSI1_D10 = 80,
+       MX51_PAD_CSI1_D11 = 81,
+       MX51_PAD_CSI1_D12 = 82,
+       MX51_PAD_CSI1_D13 = 83,
+       MX51_PAD_CSI1_D14 = 84,
+       MX51_PAD_CSI1_D15 = 85,
+       MX51_PAD_CSI1_D16 = 86,
+       MX51_PAD_CSI1_D17 = 87,
+       MX51_PAD_CSI1_D18 = 88,
+       MX51_PAD_CSI1_D19 = 89,
+       MX51_PAD_CSI1_VSYNC = 90,
+       MX51_PAD_CSI1_HSYNC = 91,
+       MX51_PAD_CSI1_PIXCLK = 92,
+       MX51_PAD_CSI1_MCLK = 93,
+       MX51_PAD_CSI2_D12 = 94,
+       MX51_PAD_CSI2_D13 = 95,
+       MX51_PAD_CSI2_D14 = 96,
+       MX51_PAD_CSI2_D15 = 97,
+       MX51_PAD_CSI2_D16 = 98,
+       MX51_PAD_CSI2_D17 = 99,
+       MX51_PAD_CSI2_D18 = 100,
+       MX51_PAD_CSI2_D19 = 101,
+       MX51_PAD_CSI2_VSYNC = 102,
+       MX51_PAD_CSI2_HSYNC = 103,
+       MX51_PAD_CSI2_PIXCLK = 104,
+       MX51_PAD_I2C1_CLK = 105,
+       MX51_PAD_I2C1_DAT = 106,
+       MX51_PAD_AUD3_BB_TXD = 107,
+       MX51_PAD_AUD3_BB_RXD = 108,
+       MX51_PAD_AUD3_BB_CK = 109,
+       MX51_PAD_AUD3_BB_FS = 110,
+       MX51_PAD_CSPI1_MOSI = 111,
+       MX51_PAD_CSPI1_MISO = 112,
+       MX51_PAD_CSPI1_SS0 = 113,
+       MX51_PAD_CSPI1_SS1 = 114,
+       MX51_PAD_CSPI1_RDY = 115,
+       MX51_PAD_CSPI1_SCLK = 116,
+       MX51_PAD_UART1_RXD = 117,
+       MX51_PAD_UART1_TXD = 118,
+       MX51_PAD_UART1_RTS = 119,
+       MX51_PAD_UART1_CTS = 120,
+       MX51_PAD_UART2_RXD = 121,
+       MX51_PAD_UART2_TXD = 122,
+       MX51_PAD_UART3_RXD = 123,
+       MX51_PAD_UART3_TXD = 124,
+       MX51_PAD_OWIRE_LINE = 125,
+       MX51_PAD_KEY_ROW0 = 126,
+       MX51_PAD_KEY_ROW1 = 127,
+       MX51_PAD_KEY_ROW2 = 128,
+       MX51_PAD_KEY_ROW3 = 129,
+       MX51_PAD_KEY_COL0 = 130,
+       MX51_PAD_KEY_COL1 = 131,
+       MX51_PAD_KEY_COL2 = 132,
+       MX51_PAD_KEY_COL3 = 133,
+       MX51_PAD_KEY_COL4 = 134,
+       MX51_PAD_KEY_COL5 = 135,
+       MX51_PAD_USBH1_CLK = 136,
+       MX51_PAD_USBH1_DIR = 137,
+       MX51_PAD_USBH1_STP = 138,
+       MX51_PAD_USBH1_NXT = 139,
+       MX51_PAD_USBH1_DATA0 = 140,
+       MX51_PAD_USBH1_DATA1 = 141,
+       MX51_PAD_USBH1_DATA2 = 142,
+       MX51_PAD_USBH1_DATA3 = 143,
+       MX51_PAD_USBH1_DATA4 = 144,
+       MX51_PAD_USBH1_DATA5 = 145,
+       MX51_PAD_USBH1_DATA6 = 146,
+       MX51_PAD_USBH1_DATA7 = 147,
+       MX51_PAD_DI1_PIN11 = 148,
+       MX51_PAD_DI1_PIN12 = 149,
+       MX51_PAD_DI1_PIN13 = 150,
+       MX51_PAD_DI1_D0_CS = 151,
+       MX51_PAD_DI1_D1_CS = 152,
+       MX51_PAD_DISPB2_SER_DIN = 153,
+       MX51_PAD_DISPB2_SER_DIO = 154,
+       MX51_PAD_DISPB2_SER_CLK = 155,
+       MX51_PAD_DISPB2_SER_RS = 156,
+       MX51_PAD_DISP1_DAT0 = 157,
+       MX51_PAD_DISP1_DAT1 = 158,
+       MX51_PAD_DISP1_DAT2 = 159,
+       MX51_PAD_DISP1_DAT3 = 160,
+       MX51_PAD_DISP1_DAT4 = 161,
+       MX51_PAD_DISP1_DAT5 = 162,
+       MX51_PAD_DISP1_DAT6 = 163,
+       MX51_PAD_DISP1_DAT7 = 164,
+       MX51_PAD_DISP1_DAT8 = 165,
+       MX51_PAD_DISP1_DAT9 = 166,
+       MX51_PAD_DISP1_DAT10 = 167,
+       MX51_PAD_DISP1_DAT11 = 168,
+       MX51_PAD_DISP1_DAT12 = 169,
+       MX51_PAD_DISP1_DAT13 = 170,
+       MX51_PAD_DISP1_DAT14 = 171,
+       MX51_PAD_DISP1_DAT15 = 172,
+       MX51_PAD_DISP1_DAT16 = 173,
+       MX51_PAD_DISP1_DAT17 = 174,
+       MX51_PAD_DISP1_DAT18 = 175,
+       MX51_PAD_DISP1_DAT19 = 176,
+       MX51_PAD_DISP1_DAT20 = 177,
+       MX51_PAD_DISP1_DAT21 = 178,
+       MX51_PAD_DISP1_DAT22 = 179,
+       MX51_PAD_DISP1_DAT23 = 180,
+       MX51_PAD_DI1_PIN3 = 181,
+       MX51_PAD_DI1_PIN2 = 182,
+       MX51_PAD_DI_GP2 = 183,
+       MX51_PAD_DI_GP3 = 184,
+       MX51_PAD_DI2_PIN4 = 185,
+       MX51_PAD_DI2_PIN2 = 186,
+       MX51_PAD_DI2_PIN3 = 187,
+       MX51_PAD_DI2_DISP_CLK = 188,
+       MX51_PAD_DI_GP4 = 189,
+       MX51_PAD_DISP2_DAT0 = 190,
+       MX51_PAD_DISP2_DAT1 = 191,
+       MX51_PAD_DISP2_DAT2 = 192,
+       MX51_PAD_DISP2_DAT3 = 193,
+       MX51_PAD_DISP2_DAT4 = 194,
+       MX51_PAD_DISP2_DAT5 = 195,
+       MX51_PAD_DISP2_DAT6 = 196,
+       MX51_PAD_DISP2_DAT7 = 197,
+       MX51_PAD_DISP2_DAT8 = 198,
+       MX51_PAD_DISP2_DAT9 = 199,
+       MX51_PAD_DISP2_DAT10 = 200,
+       MX51_PAD_DISP2_DAT11 = 201,
+       MX51_PAD_DISP2_DAT12 = 202,
+       MX51_PAD_DISP2_DAT13 = 203,
+       MX51_PAD_DISP2_DAT14 = 204,
+       MX51_PAD_DISP2_DAT15 = 205,
+       MX51_PAD_SD1_CMD = 206,
+       MX51_PAD_SD1_CLK = 207,
+       MX51_PAD_SD1_DATA0 = 208,
+       MX51_PAD_EIM_DA0 = 209,
+       MX51_PAD_EIM_DA1 = 210,
+       MX51_PAD_EIM_DA2 = 211,
+       MX51_PAD_EIM_DA3 = 212,
+       MX51_PAD_SD1_DATA1 = 213,
+       MX51_PAD_EIM_DA4 = 214,
+       MX51_PAD_EIM_DA5 = 215,
+       MX51_PAD_EIM_DA6 = 216,
+       MX51_PAD_EIM_DA7 = 217,
+       MX51_PAD_SD1_DATA2 = 218,
+       MX51_PAD_EIM_DA10 = 219,
+       MX51_PAD_EIM_DA11 = 220,
+       MX51_PAD_EIM_DA8 = 221,
+       MX51_PAD_EIM_DA9 = 222,
+       MX51_PAD_SD1_DATA3 = 223,
+       MX51_PAD_GPIO1_0 = 224,
+       MX51_PAD_GPIO1_1 = 225,
+       MX51_PAD_EIM_DA12 = 226,
+       MX51_PAD_EIM_DA13 = 227,
+       MX51_PAD_EIM_DA14 = 228,
+       MX51_PAD_EIM_DA15 = 229,
+       MX51_PAD_SD2_CMD = 230,
+       MX51_PAD_SD2_CLK = 231,
+       MX51_PAD_SD2_DATA0 = 232,
+       MX51_PAD_SD2_DATA1 = 233,
+       MX51_PAD_SD2_DATA2 = 234,
+       MX51_PAD_SD2_DATA3 = 235,
+       MX51_PAD_GPIO1_2 = 236,
+       MX51_PAD_GPIO1_3 = 237,
+       MX51_PAD_PMIC_INT_REQ = 238,
+       MX51_PAD_GPIO1_4 = 239,
+       MX51_PAD_GPIO1_5 = 240,
+       MX51_PAD_GPIO1_6 = 241,
+       MX51_PAD_GPIO1_7 = 242,
+       MX51_PAD_GPIO1_8 = 243,
+       MX51_PAD_GPIO1_9 = 244,
 };
 
 /* imx51 register maps */

drivers/pinctrl/pinctrl-imx53.c +201 -202

index 1f49e16..783feb1 100644
@@ -23,207 +23,207 @@
 #include "pinctrl-imx.h"
 
 enum imx53_pads {
-       MX53_PAD_GPIO_19 = 1,
-       MX53_PAD_KEY_COL0 = 2,
-       MX53_PAD_KEY_ROW0 = 3,
-       MX53_PAD_KEY_COL1 = 4,
-       MX53_PAD_KEY_ROW1 = 5,
-       MX53_PAD_KEY_COL2 = 6,
-       MX53_PAD_KEY_ROW2 = 7,
-       MX53_PAD_KEY_COL3 = 8,
-       MX53_PAD_KEY_ROW3 = 9,
-       MX53_PAD_KEY_COL4 = 10,
-       MX53_PAD_KEY_ROW4 = 11,
-       MX53_PAD_DI0_DISP_CLK = 12,
-       MX53_PAD_DI0_PIN15 = 13,
-       MX53_PAD_DI0_PIN2 = 14,
-       MX53_PAD_DI0_PIN3 = 15,
-       MX53_PAD_DI0_PIN4 = 16,
-       MX53_PAD_DISP0_DAT0 = 17,
-       MX53_PAD_DISP0_DAT1 = 18,
-       MX53_PAD_DISP0_DAT2 = 19,
-       MX53_PAD_DISP0_DAT3 = 20,
-       MX53_PAD_DISP0_DAT4 = 21,
-       MX53_PAD_DISP0_DAT5 = 22,
-       MX53_PAD_DISP0_DAT6 = 23,
-       MX53_PAD_DISP0_DAT7 = 24,
-       MX53_PAD_DISP0_DAT8 = 25,
-       MX53_PAD_DISP0_DAT9 = 26,
-       MX53_PAD_DISP0_DAT10 = 27,
-       MX53_PAD_DISP0_DAT11 = 28,
-       MX53_PAD_DISP0_DAT12 = 29,
-       MX53_PAD_DISP0_DAT13 = 30,
-       MX53_PAD_DISP0_DAT14 = 31,
-       MX53_PAD_DISP0_DAT15 = 32,
-       MX53_PAD_DISP0_DAT16 = 33,
-       MX53_PAD_DISP0_DAT17 = 34,
-       MX53_PAD_DISP0_DAT18 = 35,
-       MX53_PAD_DISP0_DAT19 = 36,
-       MX53_PAD_DISP0_DAT20 = 37,
-       MX53_PAD_DISP0_DAT21 = 38,
-       MX53_PAD_DISP0_DAT22 = 39,
-       MX53_PAD_DISP0_DAT23 = 40,
-       MX53_PAD_CSI0_PIXCLK = 41,
-       MX53_PAD_CSI0_MCLK = 42,
-       MX53_PAD_CSI0_DATA_EN = 43,
-       MX53_PAD_CSI0_VSYNC = 44,
-       MX53_PAD_CSI0_DAT4 = 45,
-       MX53_PAD_CSI0_DAT5 = 46,
-       MX53_PAD_CSI0_DAT6 = 47,
-       MX53_PAD_CSI0_DAT7 = 48,
-       MX53_PAD_CSI0_DAT8 = 49,
-       MX53_PAD_CSI0_DAT9 = 50,
-       MX53_PAD_CSI0_DAT10 = 51,
-       MX53_PAD_CSI0_DAT11 = 52,
-       MX53_PAD_CSI0_DAT12 = 53,
-       MX53_PAD_CSI0_DAT13 = 54,
-       MX53_PAD_CSI0_DAT14 = 55,
-       MX53_PAD_CSI0_DAT15 = 56,
-       MX53_PAD_CSI0_DAT16 = 57,
-       MX53_PAD_CSI0_DAT17 = 58,
-       MX53_PAD_CSI0_DAT18 = 59,
-       MX53_PAD_CSI0_DAT19 = 60,
-       MX53_PAD_EIM_A25 = 61,
-       MX53_PAD_EIM_EB2 = 62,
-       MX53_PAD_EIM_D16 = 63,
-       MX53_PAD_EIM_D17 = 64,
-       MX53_PAD_EIM_D18 = 65,
-       MX53_PAD_EIM_D19 = 66,
-       MX53_PAD_EIM_D20 = 67,
-       MX53_PAD_EIM_D21 = 68,
-       MX53_PAD_EIM_D22 = 69,
-       MX53_PAD_EIM_D23 = 70,
-       MX53_PAD_EIM_EB3 = 71,
-       MX53_PAD_EIM_D24 = 72,
-       MX53_PAD_EIM_D25 = 73,
-       MX53_PAD_EIM_D26 = 74,
-       MX53_PAD_EIM_D27 = 75,
-       MX53_PAD_EIM_D28 = 76,
-       MX53_PAD_EIM_D29 = 77,
-       MX53_PAD_EIM_D30 = 78,
-       MX53_PAD_EIM_D31 = 79,
-       MX53_PAD_EIM_A24 = 80,
-       MX53_PAD_EIM_A23 = 81,
-       MX53_PAD_EIM_A22 = 82,
-       MX53_PAD_EIM_A21 = 83,
-       MX53_PAD_EIM_A20 = 84,
-       MX53_PAD_EIM_A19 = 85,
-       MX53_PAD_EIM_A18 = 86,
-       MX53_PAD_EIM_A17 = 87,
-       MX53_PAD_EIM_A16 = 88,
-       MX53_PAD_EIM_CS0 = 89,
-       MX53_PAD_EIM_CS1 = 90,
-       MX53_PAD_EIM_OE = 91,
-       MX53_PAD_EIM_RW = 92,
-       MX53_PAD_EIM_LBA = 93,
-       MX53_PAD_EIM_EB0 = 94,
-       MX53_PAD_EIM_EB1 = 95,
-       MX53_PAD_EIM_DA0 = 96,
-       MX53_PAD_EIM_DA1 = 97,
-       MX53_PAD_EIM_DA2 = 98,
-       MX53_PAD_EIM_DA3 = 99,
-       MX53_PAD_EIM_DA4 = 100,
-       MX53_PAD_EIM_DA5 = 101,
-       MX53_PAD_EIM_DA6 = 102,
-       MX53_PAD_EIM_DA7 = 103,
-       MX53_PAD_EIM_DA8 = 104,
-       MX53_PAD_EIM_DA9 = 105,
-       MX53_PAD_EIM_DA10 = 106,
-       MX53_PAD_EIM_DA11 = 107,
-       MX53_PAD_EIM_DA12 = 108,
-       MX53_PAD_EIM_DA13 = 109,
-       MX53_PAD_EIM_DA14 = 110,
-       MX53_PAD_EIM_DA15 = 111,
-       MX53_PAD_NANDF_WE_B = 112,
-       MX53_PAD_NANDF_RE_B = 113,
-       MX53_PAD_EIM_WAIT = 114,
-       MX53_PAD_LVDS1_TX3_P = 115,
-       MX53_PAD_LVDS1_TX2_P = 116,
-       MX53_PAD_LVDS1_CLK_P = 117,
-       MX53_PAD_LVDS1_TX1_P = 118,
-       MX53_PAD_LVDS1_TX0_P = 119,
-       MX53_PAD_LVDS0_TX3_P = 120,
-       MX53_PAD_LVDS0_CLK_P = 121,
-       MX53_PAD_LVDS0_TX2_P = 122,
-       MX53_PAD_LVDS0_TX1_P = 123,
-       MX53_PAD_LVDS0_TX0_P = 124,
-       MX53_PAD_GPIO_10 = 125,
-       MX53_PAD_GPIO_11 = 126,
-       MX53_PAD_GPIO_12 = 127,
-       MX53_PAD_GPIO_13 = 128,
-       MX53_PAD_GPIO_14 = 129,
-       MX53_PAD_NANDF_CLE = 130,
-       MX53_PAD_NANDF_ALE = 131,
-       MX53_PAD_NANDF_WP_B = 132,
-       MX53_PAD_NANDF_RB0 = 133,
-       MX53_PAD_NANDF_CS0 = 134,
-       MX53_PAD_NANDF_CS1 = 135,
-       MX53_PAD_NANDF_CS2 = 136,
-       MX53_PAD_NANDF_CS3 = 137,
-       MX53_PAD_FEC_MDIO = 138,
-       MX53_PAD_FEC_REF_CLK = 139,
-       MX53_PAD_FEC_RX_ER = 140,
-       MX53_PAD_FEC_CRS_DV = 141,
-       MX53_PAD_FEC_RXD1 = 142,
-       MX53_PAD_FEC_RXD0 = 143,
-       MX53_PAD_FEC_TX_EN = 144,
-       MX53_PAD_FEC_TXD1 = 145,
-       MX53_PAD_FEC_TXD0 = 146,
-       MX53_PAD_FEC_MDC = 147,
-       MX53_PAD_PATA_DIOW = 148,
-       MX53_PAD_PATA_DMACK = 149,
-       MX53_PAD_PATA_DMARQ = 150,
-       MX53_PAD_PATA_BUFFER_EN = 151,
-       MX53_PAD_PATA_INTRQ = 152,
-       MX53_PAD_PATA_DIOR = 153,
-       MX53_PAD_PATA_RESET_B = 154,
-       MX53_PAD_PATA_IORDY = 155,
-       MX53_PAD_PATA_DA_0 = 156,
-       MX53_PAD_PATA_DA_1 = 157,
-       MX53_PAD_PATA_DA_2 = 158,
-       MX53_PAD_PATA_CS_0 = 159,
-       MX53_PAD_PATA_CS_1 = 160,
-       MX53_PAD_PATA_DATA0 = 161,
-       MX53_PAD_PATA_DATA1 = 162,
-       MX53_PAD_PATA_DATA2 = 163,
-       MX53_PAD_PATA_DATA3 = 164,
-       MX53_PAD_PATA_DATA4 = 165,
-       MX53_PAD_PATA_DATA5 = 166,
-       MX53_PAD_PATA_DATA6 = 167,
-       MX53_PAD_PATA_DATA7 = 168,
-       MX53_PAD_PATA_DATA8 = 169,
-       MX53_PAD_PATA_DATA9 = 170,
-       MX53_PAD_PATA_DATA10 = 171,
-       MX53_PAD_PATA_DATA11 = 172,
-       MX53_PAD_PATA_DATA12 = 173,
-       MX53_PAD_PATA_DATA13 = 174,
-       MX53_PAD_PATA_DATA14 = 175,
-       MX53_PAD_PATA_DATA15 = 176,
-       MX53_PAD_SD1_DATA0 = 177,
-       MX53_PAD_SD1_DATA1 = 178,
-       MX53_PAD_SD1_CMD = 179,
-       MX53_PAD_SD1_DATA2 = 180,
-       MX53_PAD_SD1_CLK = 181,
-       MX53_PAD_SD1_DATA3 = 182,
-       MX53_PAD_SD2_CLK = 183,
-       MX53_PAD_SD2_CMD = 184,
-       MX53_PAD_SD2_DATA3 = 185,
-       MX53_PAD_SD2_DATA2 = 186,
-       MX53_PAD_SD2_DATA1 = 187,
-       MX53_PAD_SD2_DATA0 = 188,
-       MX53_PAD_GPIO_0 = 189,
-       MX53_PAD_GPIO_1 = 190,
-       MX53_PAD_GPIO_9 = 191,
-       MX53_PAD_GPIO_3 = 192,
-       MX53_PAD_GPIO_6 = 193,
-       MX53_PAD_GPIO_2 = 194,
-       MX53_PAD_GPIO_4 = 195,
-       MX53_PAD_GPIO_5 = 196,
-       MX53_PAD_GPIO_7 = 197,
-       MX53_PAD_GPIO_8 = 198,
-       MX53_PAD_GPIO_16 = 199,
-       MX53_PAD_GPIO_17 = 200,
-       MX53_PAD_GPIO_18 = 201,
+       MX53_PAD_GPIO_19 = 0,
+       MX53_PAD_KEY_COL0 = 1,
+       MX53_PAD_KEY_ROW0 = 2,
+       MX53_PAD_KEY_COL1 = 3,
+       MX53_PAD_KEY_ROW1 = 4,
+       MX53_PAD_KEY_COL2 = 5,
+       MX53_PAD_KEY_ROW2 = 6,
+       MX53_PAD_KEY_COL3 = 7,
+       MX53_PAD_KEY_ROW3 = 8,
+       MX53_PAD_KEY_COL4 = 9,
+       MX53_PAD_KEY_ROW4 = 10,
+       MX53_PAD_DI0_DISP_CLK = 11,
+       MX53_PAD_DI0_PIN15 = 12,
+       MX53_PAD_DI0_PIN2 = 13,
+       MX53_PAD_DI0_PIN3 = 14,
+       MX53_PAD_DI0_PIN4 = 15,
+       MX53_PAD_DISP0_DAT0 = 16,
+       MX53_PAD_DISP0_DAT1 = 17,
+       MX53_PAD_DISP0_DAT2 = 18,
+       MX53_PAD_DISP0_DAT3 = 19,
+       MX53_PAD_DISP0_DAT4 = 20,
+       MX53_PAD_DISP0_DAT5 = 21,
+       MX53_PAD_DISP0_DAT6 = 22,
+       MX53_PAD_DISP0_DAT7 = 23,
+       MX53_PAD_DISP0_DAT8 = 24,
+       MX53_PAD_DISP0_DAT9 = 25,
+       MX53_PAD_DISP0_DAT10 = 26,
+       MX53_PAD_DISP0_DAT11 = 27,
+       MX53_PAD_DISP0_DAT12 = 28,
+       MX53_PAD_DISP0_DAT13 = 29,
+       MX53_PAD_DISP0_DAT14 = 30,
+       MX53_PAD_DISP0_DAT15 = 31,
+       MX53_PAD_DISP0_DAT16 = 32,
+       MX53_PAD_DISP0_DAT17 = 33,
+       MX53_PAD_DISP0_DAT18 = 34,
+       MX53_PAD_DISP0_DAT19 = 35,
+       MX53_PAD_DISP0_DAT20 = 36,
+       MX53_PAD_DISP0_DAT21 = 37,
+       MX53_PAD_DISP0_DAT22 = 38,
+       MX53_PAD_DISP0_DAT23 = 39,
+       MX53_PAD_CSI0_PIXCLK = 40,
+       MX53_PAD_CSI0_MCLK = 41,
+       MX53_PAD_CSI0_DATA_EN = 42,
+       MX53_PAD_CSI0_VSYNC = 43,
+       MX53_PAD_CSI0_DAT4 = 44,
+       MX53_PAD_CSI0_DAT5 = 45,
+       MX53_PAD_CSI0_DAT6 = 46,
+       MX53_PAD_CSI0_DAT7 = 47,
+       MX53_PAD_CSI0_DAT8 = 48,
+       MX53_PAD_CSI0_DAT9 = 49,
+       MX53_PAD_CSI0_DAT10 = 50,
+       MX53_PAD_CSI0_DAT11 = 51,
+       MX53_PAD_CSI0_DAT12 = 52,
+       MX53_PAD_CSI0_DAT13 = 53,
+       MX53_PAD_CSI0_DAT14 = 54,
+       MX53_PAD_CSI0_DAT15 = 55,
+       MX53_PAD_CSI0_DAT16 = 56,
+       MX53_PAD_CSI0_DAT17 = 57,
+       MX53_PAD_CSI0_DAT18 = 58,
+       MX53_PAD_CSI0_DAT19 = 59,
+       MX53_PAD_EIM_A25 = 60,
+       MX53_PAD_EIM_EB2 = 61,
+       MX53_PAD_EIM_D16 = 62,
+       MX53_PAD_EIM_D17 = 63,
+       MX53_PAD_EIM_D18 = 64,
+       MX53_PAD_EIM_D19 = 65,
+       MX53_PAD_EIM_D20 = 66,
+       MX53_PAD_EIM_D21 = 67,
+       MX53_PAD_EIM_D22 = 68,
+       MX53_PAD_EIM_D23 = 69,
+       MX53_PAD_EIM_EB3 = 70,
+       MX53_PAD_EIM_D24 = 71,
+       MX53_PAD_EIM_D25 = 72,
+       MX53_PAD_EIM_D26 = 73,
+       MX53_PAD_EIM_D27 = 74,
+       MX53_PAD_EIM_D28 = 75,
+       MX53_PAD_EIM_D29 = 76,
+       MX53_PAD_EIM_D30 = 77,
+       MX53_PAD_EIM_D31 = 78,
+       MX53_PAD_EIM_A24 = 79,
+       MX53_PAD_EIM_A23 = 80,
+       MX53_PAD_EIM_A22 = 81,
+       MX53_PAD_EIM_A21 = 82,
+       MX53_PAD_EIM_A20 = 83,
+       MX53_PAD_EIM_A19 = 84,
+       MX53_PAD_EIM_A18 = 85,
+       MX53_PAD_EIM_A17 = 86,
+       MX53_PAD_EIM_A16 = 87,
+       MX53_PAD_EIM_CS0 = 88,
+       MX53_PAD_EIM_CS1 = 89,
+       MX53_PAD_EIM_OE = 90,
+       MX53_PAD_EIM_RW = 91,
+       MX53_PAD_EIM_LBA = 92,
+       MX53_PAD_EIM_EB0 = 93,
+       MX53_PAD_EIM_EB1 = 94,
+       MX53_PAD_EIM_DA0 = 95,
+       MX53_PAD_EIM_DA1 = 96,
+       MX53_PAD_EIM_DA2 = 97,
+       MX53_PAD_EIM_DA3 = 98,
+       MX53_PAD_EIM_DA4 = 99,
+       MX53_PAD_EIM_DA5 = 100,
+       MX53_PAD_EIM_DA6 = 101,
+       MX53_PAD_EIM_DA7 = 102,
+       MX53_PAD_EIM_DA8 = 103,
+       MX53_PAD_EIM_DA9 = 104,
+       MX53_PAD_EIM_DA10 = 105,
+       MX53_PAD_EIM_DA11 = 106,
+       MX53_PAD_EIM_DA12 = 107,
+       MX53_PAD_EIM_DA13 = 108,
+       MX53_PAD_EIM_DA14 = 109,
+       MX53_PAD_EIM_DA15 = 110,
+       MX53_PAD_NANDF_WE_B = 111,
+       MX53_PAD_NANDF_RE_B = 112,
+       MX53_PAD_EIM_WAIT = 113,
+       MX53_PAD_LVDS1_TX3_P = 114,
+       MX53_PAD_LVDS1_TX2_P = 115,
+       MX53_PAD_LVDS1_CLK_P = 116,
+       MX53_PAD_LVDS1_TX1_P = 117,
+       MX53_PAD_LVDS1_TX0_P = 118,
+       MX53_PAD_LVDS0_TX3_P = 119,
+       MX53_PAD_LVDS0_CLK_P = 120,
+       MX53_PAD_LVDS0_TX2_P = 121,
+       MX53_PAD_LVDS0_TX1_P = 122,
+       MX53_PAD_LVDS0_TX0_P = 123,
+       MX53_PAD_GPIO_10 = 124,
+       MX53_PAD_GPIO_11 = 125,
+       MX53_PAD_GPIO_12 = 126,
+       MX53_PAD_GPIO_13 = 127,
+       MX53_PAD_GPIO_14 = 128,
+       MX53_PAD_NANDF_CLE = 129,
+       MX53_PAD_NANDF_ALE = 130,
+       MX53_PAD_NANDF_WP_B = 131,
+       MX53_PAD_NANDF_RB0 = 132,
+       MX53_PAD_NANDF_CS0 = 133,
+       MX53_PAD_NANDF_CS1 = 134,
+       MX53_PAD_NANDF_CS2 = 135,
+       MX53_PAD_NANDF_CS3 = 136,
+       MX53_PAD_FEC_MDIO = 137,
+       MX53_PAD_FEC_REF_CLK = 138,
+       MX53_PAD_FEC_RX_ER = 139,
+       MX53_PAD_FEC_CRS_DV = 140,
+       MX53_PAD_FEC_RXD1 = 141,
+       MX53_PAD_FEC_RXD0 = 142,
+       MX53_PAD_FEC_TX_EN = 143,
+       MX53_PAD_FEC_TXD1 = 144,
+       MX53_PAD_FEC_TXD0 = 145,
+       MX53_PAD_FEC_MDC = 146,
+       MX53_PAD_PATA_DIOW = 147,
+       MX53_PAD_PATA_DMACK = 148,
+       MX53_PAD_PATA_DMARQ = 149,
+       MX53_PAD_PATA_BUFFER_EN = 150,
+       MX53_PAD_PATA_INTRQ = 151,
+       MX53_PAD_PATA_DIOR = 152,
+       MX53_PAD_PATA_RESET_B = 153,
+       MX53_PAD_PATA_IORDY = 154,
+       MX53_PAD_PATA_DA_0 = 155,
+       MX53_PAD_PATA_DA_1 = 156,
+       MX53_PAD_PATA_DA_2 = 157,
+       MX53_PAD_PATA_CS_0 = 158,
+       MX53_PAD_PATA_CS_1 = 159,
+       MX53_PAD_PATA_DATA0 = 160,
+       MX53_PAD_PATA_DATA1 = 161,
+       MX53_PAD_PATA_DATA2 = 162,
+       MX53_PAD_PATA_DATA3 = 163,
+       MX53_PAD_PATA_DATA4 = 164,
+       MX53_PAD_PATA_DATA5 = 165,
+       MX53_PAD_PATA_DATA6 = 166,
+       MX53_PAD_PATA_DATA7 = 167,
+       MX53_PAD_PATA_DATA8 = 168,
+       MX53_PAD_PATA_DATA9 = 169,
+       MX53_PAD_PATA_DATA10 = 170,
+       MX53_PAD_PATA_DATA11 = 171,
+       MX53_PAD_PATA_DATA12 = 172,
+       MX53_PAD_PATA_DATA13 = 173,
+       MX53_PAD_PATA_DATA14 = 174,
+       MX53_PAD_PATA_DATA15 = 175,
+       MX53_PAD_SD1_DATA0 = 176,
+       MX53_PAD_SD1_DATA1 = 177,
+       MX53_PAD_SD1_CMD = 178,
+       MX53_PAD_SD1_DATA2 = 179,
+       MX53_PAD_SD1_CLK = 180,
+       MX53_PAD_SD1_DATA3 = 181,
+       MX53_PAD_SD2_CLK = 182,
+       MX53_PAD_SD2_CMD = 183,
+       MX53_PAD_SD2_DATA3 = 184,
+       MX53_PAD_SD2_DATA2 = 185,
+       MX53_PAD_SD2_DATA1 = 186,
+       MX53_PAD_SD2_DATA0 = 187,
+       MX53_PAD_GPIO_0 = 188,
+       MX53_PAD_GPIO_1 = 189,
+       MX53_PAD_GPIO_9 = 190,
+       MX53_PAD_GPIO_3 = 191,
+       MX53_PAD_GPIO_6 = 192,
+       MX53_PAD_GPIO_2 = 193,
+       MX53_PAD_GPIO_4 = 194,
+       MX53_PAD_GPIO_5 = 195,
+       MX53_PAD_GPIO_7 = 196,
+       MX53_PAD_GPIO_8 = 197,
+       MX53_PAD_GPIO_16 = 198,
+       MX53_PAD_GPIO_17 = 199,
+       MX53_PAD_GPIO_18 = 200,
 };
 
 /* imx53 register maps */
--

1.7.5.4

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

While this works, it's fine, but it would be more reasonable/correct to number pin indices from the first configurable pad and not by a

hardcoded magic offset into the base. The EIM_DA* pins below the current EIM_D16 are only configurable as CoreSight trace signals but it would save trouble later if anyone wanted to use these for example on a prototype board configured as those trace pads if they didn't have to renumber all the pins again. Nobody currently uses them in the tree but it makes more sense to me to count from the first configurable pad, than the first currently-used-in-the-tree configurable pad.

Therefore I propose;

* add MX51_PAD_EIM_DA0 through DA15 as index 0-15 (same for any differences in other i.MX etc.)

* move all the pin indices currently defined up by 16 for MX51 (same for above)
* _then_ renumber the current device trees..

That way churn is minimized in the future and we don't end up changing trees and definitions again in the future in the event that someone DOES want to use those pads in a shippable product with mainline Linux support (and sees fit to enable TPIU_TRACE_EN for some reason and has the hardware to use it).

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

What trouble do you mean?
Those pins, EIM_DA*, are already defined but just on a different pin id. Can't user use it in this way?

Quoted 4 lines

Therefore I propose;

* add MX51_PAD_EIM_DA0 through DA15 as index 0-15 (same for any differences in other i.MX etc.)

Hmm, as i said above, those pins are already defined. See:

        MX51_PAD_SD1_DATA0 = 209,
        MX51_PAD_EIM_DA0 = 210,
        MX51_PAD_EIM_DA1 = 211,
        MX51_PAD_EIM_DA2 = 212,
        MX51_PAD_EIM_DA3 = 213,

I did not quite understand, remove other pin ids up by 16? why?

Why we may want to change the definitions again?

Since we already have those pins EIM_DA* defined, it looks to me user could use

Quoted 8 lines · Dong Aisheng

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

Well, it just seems the datasheet has been read from the point of view of the SW_CTRL settings (pad pullups, drive strength etc.) to define the enums; every pin setting in order from IOMUXC_BASE + 0x3f0 (sorry I mistyped) has been entered as an enum into this list. Then a table has been generated using these enums to supply a pin id. Then this pin id is not relevant anymore; it actually gets referenced by it's *offset into the table*.

In this case, basically the code misses a few pins which have ALT settings but perhaps not always the ability to change pad control - EIM_DA5 to 15 are a good example.

Probably better would be to define the binding almost exactly as it was done in the old method; iomux_v3_cfg_t took into account the three register offsets possible for the pin (SW_MUX_CTL, SW_PAD_CTL and IPP) and the three values to be put into those registers.

This has been reduced down in pinctrl to what I find quite strange, which is a completely arbitrary pin "id" mapping, which indirectly references an entry in a table by index which is why pin 1 as a start looks odd.

If the binding is entirely i.MX-specific or even i.MX51-specific then why not define the pins in the device tree the "old" iomux_v3_cfg_t way, which is the way they are in the table of imx_pin_regs;

      IMX_PIN_REG(MX51_PAD_EIM_D16, 0x3f0, 0x05c, 5, 0x000, 0), /*

MX51_PAD_EIM_D16__AUD4_RXFS */

0x3f0 is the SW_PAD_CTL, 0x05c is the SW_MUX_CTL, 5 is the ALT mode, 0x000 is the IPP reg, and 0 the IPP value.

So fsl,iomux-pins = <0x3f0 0x85 0x05c 5 0 0 ... > (PAD, settings, MUX, mode/sion, IPP, select - in that order) would be a valid pin definition and require no table. Sure, the offsets are device specific but then the arbitrary numbering is too.
This way old iomux controls
can be re-derived for people who use the old method in old kernels, or use U-Boot with iomux-v3.h taken from Linux (MX6 got ported, I am porting the Efika to it on MX5 for U-Boot right now). Also that huge table goes away - it can be built at runtime, along with the PAD_NAME__ALT_MODE_NAME description.

It would also remove any arbitrary indexes, and allow lookup based on an actual documented value (which is listed at the top of every page of Appendix A register definitions), cross-referencing with the manual on the actual register settings etc. It is certainly less confusing than <0 0x17058> or so, which says nothing without a comment, and the value listed is entirely arbitrary encoding of the PAD_CTL values.

For a different way of explaining and another example of what is wrong, in the current binding doc for example;

        1386 0x17059    /* MX6Q_PAD_SD4_CMD__USDHC4_CMD */

1386 is a pin index, correct? But it's a pin index into the

imx_pin_regs array. It has no relation to the enums at the top of pinctrl-imx6q.c, which is only used to refer to the pin_desc structure.

        IMX_PIN_REG(MX6Q_PAD_SD4_CMD, 0x06DC, 0x02F4, 0, 0x0000, 0),

/* MX6Q_PAD_SD4_CMD__USDHC4_CMD */

So the enums at the top of the file don't even define the pin number. You have to COUNT inside this file, or look at the binding which someone has written by doing the counting by hand or script.

Change
the array, change the binding. This is terrible, terrible design.

There should be one point of reference, and if possible, the binding should be totally obvious without cross-reference.

The docs then say 0x17059 defines the pin control settings (hysteresis etc.) - MUX_MODE (ALT) is inferred from this database inside the kernel.

If you need to add more items in the list (for instance if MX7 gains an extra set of configuration registers for each pin), this is what #size-cells property is for in the device tree, or better yet why not walk the tree to find the machine compatible?

Quoted 3 lines

What trouble do you mean?
Those pins, EIM_DA*, are already defined but just on a different pin id. Can't user use it in this way?

Yuck.

Quoted 11 lines

Quoted 4 lines

Therefore I propose;

* add MX51_PAD_EIM_DA0 through DA15 as index 0-15 (same for any differences in other i.MX etc.)

Hmm, as i said above, those pins are already defined. See:

        MX51_PAD_SD1_DATA0 = 209,
        MX51_PAD_EIM_DA0 = 210,
        MX51_PAD_EIM_DA1 = 211,
        MX51_PAD_EIM_DA2 = 212,
        MX51_PAD_EIM_DA3 = 213,

Where are 4 through 15?

Quoted 1 line

I did not quite understand, remove other pin ids up by 16? why?

See above.

Quoted 1 line

Why we may want to change the definitions again?

If you got ANYTHING at all wrong. Shawn already sent a patch to change a definition. What if the order in the table changes? Where is the note above the table that says the order of the table is tied directly to the binding and no order changes or inserts-in-the-middle should be made?

Quoted 1 line

Since we already have those pins EIM_DA* defined, it looks to me user could use

No.. because there are 12 pins missing. I don't know how many others might be missing,

but the implementation as a whole is too arbitrary
and too abstract. You do not need to implement indirection in the device tree.

Quoted 10 lines · Matt Sealey

Quoted 8 lines · Dong Aisheng

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

Quoted 8 lines

Well, it just seems the datasheet has been read from the point of view of the SW_CTRL settings (pad pullups, drive strength etc.) to define the enums; every pin setting in order from IOMUXC_BASE + 0x3f0 (sorry I mistyped) has been entered as an enum into this list. Then a table has been generated using these enums to supply a pin id. Then this pin id is not relevant anymore; it actually gets referenced by it's *offset into the table*.

Not exactly, probably.
Basically we follow the mux reigster offset to define pin id, however, there're also some pads may not have mux function but only config which also has a pin id
and vice versa.
Those pins are not ordered by it's mux regsiter offset.

Actually I did not manually search all those pins, instead, i just using the exist ones:
arch/arm/plat-mxc/include/mach/iomux-mx51.h
Since this exist headfile already covers this case.

Quoted 4 lines

In this case, basically the code misses a few pins which have ALT settings but perhaps not always the ability to change pad control - EIM_DA5 to 15 are a good example.

As i said, we already defined those pin ids.

Quoted 10 lines

Probably better would be to define the binding almost exactly as it was done in the old method; iomux_v3_cfg_t took into account the three register offsets possible for the pin (SW_MUX_CTL, SW_PAD_CTL and IPP) and the three values to be put into those registers.

This has been reduced down in pinctrl to what I find quite strange, which is a completely arbitrary pin "id" mapping, which indirectly references an entry in a table by index which is why pin 1 as a start looks odd.

Start with pin 1 is a bug which caused by my mistake during the early data conversion.

Quoted 10 lines

If the binding is entirely i.MX-specific or even i.MX51-specific then why not define the pins in the device tree the "old" iomux_v3_cfg_t way, which is the way they are in the table of imx_pin_regs;

      IMX_PIN_REG(MX51_PAD_EIM_D16, 0x3f0, 0x05c, 5, 0x000, 0), /*

MX51_PAD_EIM_D16__AUD4_RXFS */

0x3f0 is the SW_PAD_CTL, 0x05c is the SW_MUX_CTL, 5 is the ALT mode, 0x000 is the IPP reg, and 0 the IPP value.

Quoted 11 lines

So fsl,iomux-pins = <0x3f0 0x85 0x05c 5 0 0 ... > (PAD, settings, MUX, mode/sion, IPP, select - in that order) would be a valid pin definition and require no table. Sure, the offsets are device specific but then the arbitrary numbering is too.
This way old iomux controls
can be re-derived for people who use the old method in old kernels, or use U-Boot with iomux-v3.h taken from Linux (MX6 got ported, I am porting the Efika to it on MX5 for U-Boot right now). Also that huge table goes away - it can be built at runtime, along with the PAD_NAME__ALT_MODE_NAME description.

I can't agree this is better than the exist one now. It's hard to use in device tree.
And how would you parse the pin id from this data array?

Hello,

(Cc += devicetree-discuss at lists.ozlabs.org)

Quoted 71 lines · Dong Aisheng

Quoted 10 lines · Matt Sealey

Quoted 8 lines · Dong Aisheng

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

Quoted 8 lines

Well, it just seems the datasheet has been read from the point of view of the SW_CTRL settings (pad pullups, drive strength etc.) to define the enums; every pin setting in order from IOMUXC_BASE + 0x3f0 (sorry I mistyped) has been entered as an enum into this list. Then a table has been generated using these enums to supply a pin id. Then this pin id is not relevant anymore; it actually gets referenced by it's *offset into the table*.

Not exactly, probably.
Basically we follow the mux reigster offset to define pin id, however, there're also some pads may not have mux function but only config which also has a pin id
and vice versa.
Those pins are not ordered by it's mux regsiter offset.

Actually I did not manually search all those pins, instead, i just using the exist ones:
arch/arm/plat-mxc/include/mach/iomux-mx51.h
Since this exist headfile already covers this case.

Quoted 4 lines

In this case, basically the code misses a few pins which have ALT settings but perhaps not always the ability to change pad control - EIM_DA5 to 15 are a good example.

As i said, we already defined those pin ids.

Quoted 10 lines

Probably better would be to define the binding almost exactly as it was done in the old method; iomux_v3_cfg_t took into account the three register offsets possible for the pin (SW_MUX_CTL, SW_PAD_CTL and IPP) and the three values to be put into those registers.

This has been reduced down in pinctrl to what I find quite strange, which is a completely arbitrary pin "id" mapping, which indirectly references an entry in a table by index which is why pin 1 as a start looks odd.

Start with pin 1 is a bug which caused by my mistake during the early data conversion.

Quoted 10 lines

If the binding is entirely i.MX-specific or even i.MX51-specific then why not define the pins in the device tree the "old" iomux_v3_cfg_t way, which is the way they are in the table of imx_pin_regs;

      IMX_PIN_REG(MX51_PAD_EIM_D16, 0x3f0, 0x05c, 5, 0x000, 0), /*

MX51_PAD_EIM_D16__AUD4_RXFS */

0x3f0 is the SW_PAD_CTL, 0x05c is the SW_MUX_CTL, 5 is the ALT mode, 0x000 is the IPP reg, and 0 the IPP value.

Quoted 11 lines

So fsl,iomux-pins = <0x3f0 0x85 0x05c 5 0 0 ... > (PAD, settings, MUX, mode/sion, IPP, select - in that order) would be a valid pin definition and require no table. Sure, the offsets are device specific but then the arbitrary numbering is too.
This way old iomux controls
can be re-derived for people who use the old method in old kernels, or use U-Boot with iomux-v3.h taken from Linux (MX6 got ported, I am porting the Efika to it on MX5 for U-Boot right now). Also that huge table goes away - it can be built at runtime, along with the PAD_NAME__ALT_MODE_NAME description.

Quoted 3 lines

I can't agree this is better than the exist one now. It's hard to use in device tree.
And how would you parse the pin id from this data array?

I admit I didn't follow completely the calculation suggestion by Matt, but I think in general he has a point. This is more or less what I thought when I built the imx35 pinctrl driver.

With the current approach (i.e. put the pinfuncs in some order that seems sensible today and then referencing them by index according to that ordering) you really get into troubles if you have to add a new function. You have to add it to the end to not break existing device trees and so the ordering is broken.

Also "11" has no obvious relation to MX35_PAD_COMPARE__SDMA_EXTDMA_2 other than a match if you grep over the binding docs (or the driver). While "0x32c, 0x008, 7, 0x0, 0" is longer and looks more ugly the mapping is obvious and so IMHO preferable.

Quoted 83 lines · Uwe Kleine-K?nig

Hello,

(Cc += devicetree-discuss at lists.ozlabs.org)

Quoted 71 lines · Dong Aisheng

Quoted 10 lines · Matt Sealey

Quoted 8 lines · Dong Aisheng

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

Quoted 8 lines

Well, it just seems the datasheet has been read from the point of view of the SW_CTRL settings (pad pullups, drive strength etc.) to define the enums; every pin setting in order from IOMUXC_BASE + 0x3f0 (sorry I mistyped) has been entered as an enum into this list. Then a table has been generated using these enums to supply a pin id. Then this pin id is not relevant anymore; it actually gets referenced by it's *offset into the table*.

Not exactly, probably.
Basically we follow the mux reigster offset to define pin id, however, there're also some pads may not have mux function but only config which also has a pin id
and vice versa.
Those pins are not ordered by it's mux regsiter offset.

Actually I did not manually search all those pins, instead, i just using the exist ones:
arch/arm/plat-mxc/include/mach/iomux-mx51.h
Since this exist headfile already covers this case.

Quoted 4 lines

In this case, basically the code misses a few pins which have ALT settings but perhaps not always the ability to change pad control - EIM_DA5 to 15 are a good example.

As i said, we already defined those pin ids.

Quoted 10 lines

Probably better would be to define the binding almost exactly as it was done in the old method; iomux_v3_cfg_t took into account the three register offsets possible for the pin (SW_MUX_CTL, SW_PAD_CTL and IPP) and the three values to be put into those registers.

This has been reduced down in pinctrl to what I find quite strange, which is a completely arbitrary pin "id" mapping, which indirectly references an entry in a table by index which is why pin 1 as a start looks odd.

Start with pin 1 is a bug which caused by my mistake during the early data conversion.

Quoted 10 lines

If the binding is entirely i.MX-specific or even i.MX51-specific then why not define the pins in the device tree the "old" iomux_v3_cfg_t way, which is the way they are in the table of imx_pin_regs;

      IMX_PIN_REG(MX51_PAD_EIM_D16, 0x3f0, 0x05c, 5, 0x000, 0), /*

MX51_PAD_EIM_D16__AUD4_RXFS */

0x3f0 is the SW_PAD_CTL, 0x05c is the SW_MUX_CTL, 5 is the ALT mode, 0x000 is the IPP reg, and 0 the IPP value.

Quoted 11 lines

So fsl,iomux-pins = <0x3f0 0x85 0x05c 5 0 0 ... > (PAD, settings, MUX, mode/sion, IPP, select - in that order) would be a valid pin definition and require no table. Sure, the offsets are device specific but then the arbitrary numbering is too.
This way old iomux controls
can be re-derived for people who use the old method in old kernels, or use U-Boot with iomux-v3.h taken from Linux (MX6 got ported, I am porting the Efika to it on MX5 for U-Boot right now). Also that huge table goes away - it can be built at runtime, along with the PAD_NAME__ALT_MODE_NAME description.

Quoted 3 lines

I can't agree this is better than the exist one now. It's hard to use in device tree.
And how would you parse the pin id from this data array?

I admit I didn't follow completely the calculation suggestion by Matt, but I think in general he has a point. This is more or less what I thought when I built the imx35 pinctrl driver.

Quoted 6 lines

With the current approach (i.e. put the pinfuncs in some order that seems sensible today and then referencing them by index according to that ordering) you really get into troubles if you have to add a new function. You have to add it to the end to not break existing device trees and so the ordering is broken.

Actually, we do not mean to maintain the ordering in driver. It just needs to be align with the pin func ids definitions in binding doc. So the ordering broken in driver is not an issue, it just looks not so better if we really have to add a new pin function to the end due to mistake but this does not break anything to work.

Quoted 5 lines

Also "11" has no obvious relation to MX35_PAD_COMPARE__SDMA_EXTDMA_2 other than a match if you grep over the binding docs (or the driver). While "0x32c, 0x008, 7, 0x0, 0" is longer and looks more ugly the mapping is obvious and so IMHO preferable.

Also, don't you think this is hard to use for devicetree?

And we need to reference datasheet to fill these values.

I just keep using as the old way at best and i remember Sascha also suggested before that we don't want to lose using the macro way as MX35_PAD_COMPARE__SDMA_EXTDMA_2 to make easy use.
In the future, we will switch to macro when dt supports.
For the way "0x32c, 0x008, 7, 0x0, 0", it's very unconveniently to use macro.

Hello,

Quoted 90 lines · Dong Aisheng

Quoted 83 lines · Uwe Kleine-K?nig

Hello,

(Cc += devicetree-discuss at lists.ozlabs.org)

Quoted 71 lines · Dong Aisheng

Quoted 10 lines · Matt Sealey

Quoted 8 lines · Dong Aisheng

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

Quoted 8 lines

Well, it just seems the datasheet has been read from the point of view of the SW_CTRL settings (pad pullups, drive strength etc.) to define the enums; every pin setting in order from IOMUXC_BASE + 0x3f0 (sorry I mistyped) has been entered as an enum into this list. Then a table has been generated using these enums to supply a pin id. Then this pin id is not relevant anymore; it actually gets referenced by it's *offset into the table*.

Not exactly, probably.
Basically we follow the mux reigster offset to define pin id, however, there're also some pads may not have mux function but only config which also has a pin id
and vice versa.
Those pins are not ordered by it's mux regsiter offset.

Actually I did not manually search all those pins, instead, i just using the exist ones:
arch/arm/plat-mxc/include/mach/iomux-mx51.h
Since this exist headfile already covers this case.

Quoted 4 lines

In this case, basically the code misses a few pins which have ALT settings but perhaps not always the ability to change pad control - EIM_DA5 to 15 are a good example.

As i said, we already defined those pin ids.

Quoted 10 lines

Probably better would be to define the binding almost exactly as it was done in the old method; iomux_v3_cfg_t took into account the three register offsets possible for the pin (SW_MUX_CTL, SW_PAD_CTL and IPP) and the three values to be put into those registers.

This has been reduced down in pinctrl to what I find quite strange, which is a completely arbitrary pin "id" mapping, which indirectly references an entry in a table by index which is why pin 1 as a start looks odd.

Start with pin 1 is a bug which caused by my mistake during the early data conversion.

Quoted 10 lines

If the binding is entirely i.MX-specific or even i.MX51-specific then why not define the pins in the device tree the "old" iomux_v3_cfg_t way, which is the way they are in the table of imx_pin_regs;

      IMX_PIN_REG(MX51_PAD_EIM_D16, 0x3f0, 0x05c, 5, 0x000, 0), /*

MX51_PAD_EIM_D16__AUD4_RXFS */

0x3f0 is the SW_PAD_CTL, 0x05c is the SW_MUX_CTL, 5 is the ALT mode, 0x000 is the IPP reg, and 0 the IPP value.

Quoted 11 lines

So fsl,iomux-pins = <0x3f0 0x85 0x05c 5 0 0 ... > (PAD, settings, MUX, mode/sion, IPP, select - in that order) would be a valid pin definition and require no table. Sure, the offsets are device specific but then the arbitrary numbering is too.
This way old iomux controls
can be re-derived for people who use the old method in old kernels, or use U-Boot with iomux-v3.h taken from Linux (MX6 got ported, I am porting the Efika to it on MX5 for U-Boot right now). Also that huge table goes away - it can be built at runtime, along with the PAD_NAME__ALT_MODE_NAME description.

Quoted 3 lines

I can't agree this is better than the exist one now. It's hard to use in device tree.
And how would you parse the pin id from this data array?

I admit I didn't follow completely the calculation suggestion by Matt, but I think in general he has a point. This is more or less what I thought when I built the imx35 pinctrl driver.

Quoted 6 lines

With the current approach (i.e. put the pinfuncs in some order that seems sensible today and then referencing them by index according to that ordering) you really get into troubles if you have to add a new function. You have to add it to the end to not break existing device trees and so the ordering is broken.

Quoted 5 lines

Actually, we do not mean to maintain the ordering in driver. It just needs to be align with the pin func ids definitions in binding doc. So the ordering broken in driver is not an issue, it just looks not so better if we really have to add a new pin function to the end due to mistake but this does not break anything to work.

Well, if you add a function between say current function 11 and 12 all device trees need fixing, i.e. increase all function ids >= 12 by one. You obviously cannot fix out-of-tree users and even fixing the in-tree users is ugly.

Quoted 6 lines

Quoted 5 lines

Also "11" has no obvious relation to MX35_PAD_COMPARE__SDMA_EXTDMA_2 other than a match if you grep over the binding docs (or the driver). While "0x32c, 0x008, 7, 0x0, 0" is longer and looks more ugly the mapping is obvious and so IMHO preferable.

Also, don't you think this is hard to use for devicetree?

Not harder than the current approach. Obviously macro support would be nice, but this applies to both approaches.

Quoted 1 line

And we need to reference datasheet to fill these values.

I'd list the explicit values in the binding docs as the indexes are documented there now. So the difference for a device-tree writer is just the content that is copy-and-pasted.

Quoted 5 lines

I just keep using as the old way at best and i remember Sascha also suggested before that we don't want to lose using the macro way as MX35_PAD_COMPARE__SDMA_EXTDMA_2 to make easy use.
In the future, we will switch to macro when dt supports.
For the way "0x32c, 0x008, 7, 0x0, 0", it's very unconveniently to use macro.

That is just

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 11

vs.

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x32c, 0x008, 7, 0x0, 0

isn't it? (Actually I'd not go for cpp as preprocessor, but that's a different story.)

Quoted 98 lines · Uwe Kleine-K?nig

Hello,

Quoted 90 lines · Dong Aisheng

Quoted 83 lines · Uwe Kleine-K?nig

Hello,

(Cc += devicetree-discuss at lists.ozlabs.org)

Quoted 71 lines · Dong Aisheng

Quoted 10 lines · Matt Sealey

Quoted 8 lines · Dong Aisheng

Quoted 5 lines · Matt Sealey

I have a minor nit; while renumbering the pinctrl definitions is laudable and device trees can match, there are 16 other pin controls below EIM_D16 - this makes the start of the IOMUXC pin definitions actually be the value calculated by (iomuxc_base + 0x300 + (4*16) + (pin_id*4)).

What do you mean of this value calculated?

Quoted 8 lines

Well, it just seems the datasheet has been read from the point of view of the SW_CTRL settings (pad pullups, drive strength etc.) to define the enums; every pin setting in order from IOMUXC_BASE + 0x3f0 (sorry I mistyped) has been entered as an enum into this list. Then a table has been generated using these enums to supply a pin id. Then this pin id is not relevant anymore; it actually gets referenced by it's *offset into the table*.

Not exactly, probably.
Basically we follow the mux reigster offset to define pin id, however, there're also some pads may not have mux function but only config which also has a pin id
and vice versa.
Those pins are not ordered by it's mux regsiter offset.

Actually I did not manually search all those pins, instead, i just using the exist ones:
arch/arm/plat-mxc/include/mach/iomux-mx51.h
Since this exist headfile already covers this case.

Quoted 4 lines

In this case, basically the code misses a few pins which have ALT settings but perhaps not always the ability to change pad control - EIM_DA5 to 15 are a good example.

As i said, we already defined those pin ids.

Quoted 10 lines

Probably better would be to define the binding almost exactly as it was done in the old method; iomux_v3_cfg_t took into account the three register offsets possible for the pin (SW_MUX_CTL, SW_PAD_CTL and IPP) and the three values to be put into those registers.

This has been reduced down in pinctrl to what I find quite strange, which is a completely arbitrary pin "id" mapping, which indirectly references an entry in a table by index which is why pin 1 as a start looks odd.

Start with pin 1 is a bug which caused by my mistake during the early data conversion.

Quoted 10 lines

If the binding is entirely i.MX-specific or even i.MX51-specific then why not define the pins in the device tree the "old" iomux_v3_cfg_t way, which is the way they are in the table of imx_pin_regs;

      IMX_PIN_REG(MX51_PAD_EIM_D16, 0x3f0, 0x05c, 5, 0x000, 0), /*

MX51_PAD_EIM_D16__AUD4_RXFS */

0x3f0 is the SW_PAD_CTL, 0x05c is the SW_MUX_CTL, 5 is the ALT mode, 0x000 is the IPP reg, and 0 the IPP value.

Quoted 11 lines

So fsl,iomux-pins = <0x3f0 0x85 0x05c 5 0 0 ... > (PAD, settings, MUX, mode/sion, IPP, select - in that order) would be a valid pin definition and require no table. Sure, the offsets are device specific but then the arbitrary numbering is too.
This way old iomux controls
can be re-derived for people who use the old method in old kernels, or use U-Boot with iomux-v3.h taken from Linux (MX6 got ported, I am porting the Efika to it on MX5 for U-Boot right now). Also that huge table goes away - it can be built at runtime, along with the PAD_NAME__ALT_MODE_NAME description.

Quoted 3 lines

I can't agree this is better than the exist one now. It's hard to use in device tree.
And how would you parse the pin id from this data array?

I admit I didn't follow completely the calculation suggestion by Matt, but I think in general he has a point. This is more or less what I thought when I built the imx35 pinctrl driver.

Quoted 6 lines

With the current approach (i.e. put the pinfuncs in some order that seems sensible today and then referencing them by index according to that ordering) you really get into troubles if you have to add a new function. You have to add it to the end to not break existing device trees and so the ordering is broken.

Quoted 5 lines

Actually, we do not mean to maintain the ordering in driver. It just needs to be align with the pin func ids definitions in binding doc. So the ordering broken in driver is not an issue, it just looks not so better if we really have to add a new pin function to the end due to mistake but this does not break anything to work.

Quoted 5 lines

Well, if you add a function between say current function 11 and 12 all device trees need fixing, i.e. increase all function ids >= 12 by one. You obviously cannot fix out-of-tree users and even fixing the in-tree users is ugly.

For such case, we should add it to the end since the exist ids are already taken. It will not break any user.

Quoted 25 lines

Quoted 6 lines

Quoted 5 lines

Also "11" has no obvious relation to MX35_PAD_COMPARE__SDMA_EXTDMA_2 other than a match if you grep over the binding docs (or the driver). While "0x32c, 0x008, 7, 0x0, 0" is longer and looks more ugly the mapping is obvious and so IMHO preferable.

Also, don't you think this is hard to use for devicetree?

Not harder than the current approach. Obviously macro support would be nice, but this applies to both approaches.

Quoted 1 line

And we need to reference datasheet to fill these values.

I'd list the explicit values in the binding docs as the indexes are documented there now. So the difference for a device-tree writer is just the content that is copy-and-pasted.

Quoted 5 lines

I just keep using as the old way at best and i remember Sascha also suggested before that we don't want to lose using the macro way as MX35_PAD_COMPARE__SDMA_EXTDMA_2 to make easy use.
In the future, we will switch to macro when dt supports.
For the way "0x32c, 0x008, 7, 0x0, 0", it's very unconveniently to use macro.

That is just

      #define MX35_PAD_COMPARE__SDMA_EXTDMA_2 11

vs.

Quoted 5 lines

      #define MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x32c, 0x008, 7, 0x0, 0

isn't it? (Actually I'd not go for cpp as preprocessor, but that's a different story.)

Hmm, not sure if dt macro may support this kind of syntax but yes if it supports. Grant,
Do you know if dt macro can support it?

Now I'm a bit intend to admit that we probably could do like that if it supports. The benefit i see is that it could save much code lines in driver while having no using experience downgrade.

The left question is that how do we get the pin id from this kind of format data (0x32c, 0x008, 7, 0x0, 0), probably one way may be:
For normal pads and NO_CONFIG pads, we could get it via:
mux_reg_offset / 4
for NO_MUX pads but have CONFIG pads, we may get it via:
mux_reg_offset / 4 + PIN_NO_MUX_ID_BASE + config_reg_offset /4
That may fix getting pin id issue from dt.

Another known issue is that via this way, that means the pinctrl subsystem can only see the using pads, this is a bit not align with the pinctrl subsystem design. No sure if Linus would like to see it.

Regards
Dong Aisheng

Quoted 6 lines · Uwe Kleine-K?nig

That is just

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 11

vs.

Quoted 5 lines

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x32c, 0x008, 7, 0x0, 0

isn't it? (Actually I'd not go for cpp as preprocessor, but that's a different story.)

Hmm, not sure if dt macro may support this kind of syntax but yes if it supports. Grant,
Do you know if dt macro can support it?

Now I'm a bit intend to admit that we probably could do like that if it supports. The benefit i see is that it could save much code lines in driver while having no using experience downgrade.

The left question is that how do we get the pin id from this kind of format data (0x32c, 0x008, 7, 0x0, 0), probably one way may be:
For normal pads and NO_CONFIG pads, we could get it via:
mux_reg_offset / 4
for NO_MUX pads but have CONFIG pads, we may get it via:
mux_reg_offset / 4 + PIN_NO_MUX_ID_BASE + config_reg_offset /4

That may fix getting pin id issue from dt.

Another known issue is that via this way, that means the pinctrl subsystem can only see the using pads, this is a bit not align with the pinctrl subsystem design. No sure if Linus would like to see it.

Quoted 12 lines · Dong Aisheng

Quoted 11 lines · Uwe Kleine-K?nig

That is just

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 11

vs.

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x32c, 0x008, 7, 0x0, 0

isn't it? (Actually I'd not go for cpp as preprocessor, but that's a different story.)

Quoted 4 lines

Hmm, not sure if dt macro may support this kind of syntax but yes if it supports. Grant,
Do you know if dt macro can support it?

I have the same doubt there. Copied Stephen who might have a better insight on this.

Quoted 10 lines

Now I'm a bit intend to admit that we probably could do like that if it supports. The benefit i see is that it could save much code lines in driver while having no using experience downgrade.

The left question is that how do we get the pin id from this kind of format data (0x32c, 0x008, 7, 0x0, 0), probably one way may be:
For normal pads and NO_CONFIG pads, we could get it via:
mux_reg_offset / 4
for NO_MUX pads but have CONFIG pads, we may get it via:
mux_reg_offset / 4 + PIN_NO_MUX_ID_BASE + config_reg_offset /4

In case of NO_MUX, mux_reg_offset is 0, so the formula becomes:

PIN_NO_MUX_ID_BASE + config_reg_offset / 4

The question comes to how PIN_NO_MUX_ID_BASE gets determined?

Quoted 5 lines · Shawn Guo

Quoted 4 lines · Dong Aisheng

On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-K?nig wrote:
Hmm, not sure if dt macro may support this kind of syntax but yes if it supports. Grant,

Quoted 5 lines

Quoted 1 line

Do you know if dt macro can support it?

I have the same doubt there. Copied Stephen who might have a better insight on this.

Rather than betting how DTC will implement macro, we'd better make the the safest assumption - it will not support that syntax.

still work our issue, I guess. Actually, the goal is all about encoding the data that is currently defined in driver as a big array of struct imx_pin_reg in device tree.

struct imx_pin_reg {
        u16 pid;
        u16 mux_reg;
        u16 conf_reg;
        u8 mux_mode;
        u16 input_reg;
        u8 input_val;
};

As we will figure out the pid from the mux_reg and conf_reg as below, it becomes how we encode other fields. An u64 can just cover them.

That said, the line below in binding doc

MX35_PAD_COMPARE__SDMA_EXTDMA_2 11

becomes

MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x032c000807000000

We should probably have it be mux_reg + mux_mode + conf_reg + input_reg + input_val or something to have the offset and value coupled. Anyway, we will still have fsl,pins formatted as <PIN_FUNC_ID CONFIG>, and only difference is PIN_FUNC_ID becomes an u64 integer. But it can save us that big array from the driver.

Quoted 2 lines

The question comes to how PIN_NO_MUX_ID_BASE gets determined?

So PIN_NO_MUX_ID_BASE will be: the largest mux_reg_offset / 4 + 1, right?

Quoted 2 lines

Rather than betting how DTC will implement macro, we'd better make the the safest assumption - it will not support that syntax.

It won't.

DT is defined by properties and those properties have cells. Properties
that have more than one cell or multiple definitions in them have to have a #size-cells property to go with it somehow.

I don't see what the problem would be here; you want to define pin properties, sure, they are intrinsically defined by 3 possible registers and value pairs. In actual fact if you drill down to this, what happens is you get a pin property which defines offsets into the unit, and values to stuff into those registers, so
you could either dictate a size-cell of 6 (3 pairs of reg-value) or 2 (reg, value).
It would be more convenient for a driver to know what those pairs are maybe, so 6 is better.

iomuxc at 0x73f08000 {
fsl,iomux-pins = <mux value ctrl value ipp value
/* MX53_PIN_SD4_CMD__SD4_CMD */

                            mux value ctrl value ipp value
       /* etc. */
                            ...>;

Quoted 4 lines · Matt Sealey

Quoted 2 lines

Rather than betting how DTC will implement macro, we'd better make the the safest assumption - it will not support that syntax.

It won't.

There were a lot of pushing on macro support for DTC. Though it's going to be very slow, I guess someday we will have it at least for those simple and straight-forward syntax.

But right, we shouldn't make any assumption on that.

Quoted 6 lines

iomuxc at 0x73f08000 {
fsl,iomux-pins = <mux value ctrl value ipp value
/* MX53_PIN_SD4_CMD__SD4_CMD */

                            mux value ctrl value ipp value
       /* etc. */
                            ...>;

I do not see problem with this approach either. But, this is nothing IMX specific. Essentially, this becomes a common binding for configuring a pin with arbitrary number of register/value pairs.

Quoted 12 lines · Dong Aisheng

Quoted 11 lines · Uwe Kleine-K?nig

That is just

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 11

vs.

	#define MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x32c, 0x008, 7, 0x0, 0

isn't it? (Actually I'd not go for cpp as preprocessor, but that's a different story.)

Quoted 4 lines

Hmm, not sure if dt macro may support this kind of syntax but yes if it supports. Grant,
Do you know if dt macro can support it?

I have the same doubt there. Copied Stephen who might have a better insight on this.

Quoted 4 lines

Another known issue is that via this way, that means the pinctrl subsystem can only see the using pads, this is a bit not align with the pinctrl subsystem design. No sure if Linus would like to see it.

I do not quite follow on this. The "enum imx51_pads" will still be there, so all the pads will still be visible to the pinctrl system.

On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
...

Quoted 4 lines

Quoted 4 lines

Another known issue is that via this way, that means the pinctrl subsystem can only see the using pads, this is a bit not align with the pinctrl subsystem design. No sure if Linus would like to see it.

Quoted 2 lines

I do not quite follow on this. The "enum imx51_pads" will still be there, so all the pads will still be visible to the pinctrl system.

Sorry, i did not describe it accurately.
The problem is that those pins are visible to pinctrl subystem, but the pinctrl subsystem can not manage them all.

Because for the way proposed, all the pin's basic properties like mux_reg, config_reg are parsed from device tree at runtime.

If a pin is not used in device tree, the driver can not know this pin's corresponding registers.

Then imx_pinconf_dbg_show in current driver may need change since it does not support show all pins's config value.

If it supports, will imx driver also support config unused pins in devicetree via sysfs?

Probably it may be rarely used and imx just does not support it. Then we can get register data from devicetree.

On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote:
...

Quoted 7 lines

Quoted 4 lines

Another known issue is that via this way, that means the pinctrl subsystem can only see the using pads, this is a bit not align with the pinctrl subsystem design. No sure if Linus would like to see it.

I do not quite follow on this. The "enum imx51_pads" will still be there, so all the pads will still be visible to the pinctrl system.

Sorry, i did not describe it accurately.
The problem is that those pins are visible to pinctrl subystem, but the pinctrl subsystem can not manage them all.
Not sure this meet Linus's original design purpose.
Because for the way proposed, all the pin's basic properties like mux_reg, config_reg are parsed from device tree at runtime.
If a pin is not used in device tree, the driver can not know this pin's corresponding registers.
Thus, for those unused pins, we can not manage it on mux or config in pinctrl subsystem and driver.

For example, the pin_config_get/pin_config_set API in include/linux/pinctrl/consumer.h can not work for such pins.

Then imx_pinconf_dbg_show in current driver may need change since it does not support show all pins's config value.

It looks like not a big issue currently since i did not see any client driver using this API.
But i'm not sure if we may have this requirement in the future. For example, is it possible that pinctrl subsystem may support configure pins via sysfs dynamically?

Quoted 2 lines · Dong Aisheng

For example, the pin_config_get/pin_config_set API in include/linux/pinctrl/consumer.h can not work for such pins.

Hmmm. Given we support all pin mux/config options from the mapping table, I'd question whether that API should even exist any more...

Quoted 5 lines

It looks like not a big issue currently since i did not see any client driver using this API.
But i'm not sure if we may have this requirement in the future. For example, is it possible that pinctrl subsystem may support configure pins via sysfs dynamically?

I can't comment on sysfs specifically, but I believe it would be generally true that a pin that isn't know to the pinctrl subsystem can't be manipulated in any way.

The problem is that those pins are visible to pinctrl subystem, but the pinctrl subsystem can not manage them all.
Not sure this meet Linus's original design purpose.

But i'm not sure if we may have this requirement in the future. For example, is it possible that pinctrl subsystem may support configure pins via sysfs dynamically?

If it supports, will imx driver also support config unused pins in devicetree via sysfs?

Unlike imx6q pinctrl driver that starts nubmering pad from 0, imx5 pinctrl drivers number pad from 1. It causes problem/confusion when driver accesses imx51_pinctrl_pads array using pin ID as the index.

Change imx51_pads and imx53_pads numbering start from 0.

Signed-off-by Shawn Guo <[email protected]>

---
  drivers/pinctrl/pinctrl-imx51.c |  490 +++++++++++++++++++-------------------
  drivers/pinctrl/pinctrl-imx53.c |  402 ++++++++++++++++----------------
  2 files changed, 446 insertions(+), 446 deletions(-)

drivers/pinctrl/pinctrl-imx51.c +245 -245

index 9fd0216..fb84689 100644
@@ -23,251 +23,251 @@
  #include "pinctrl-imx.h"
 
  enum imx51_pads {
-	MX51_PAD_EIM_D16 = 1,
-	MX51_PAD_EIM_D17 = 2,
-	MX51_PAD_EIM_D18 = 3,
-	MX51_PAD_EIM_D19 = 4,
-	MX51_PAD_EIM_D20 = 5,
-	MX51_PAD_EIM_D21 = 6,
-	MX51_PAD_EIM_D22 = 7,
-	MX51_PAD_EIM_D23 = 8,
-	MX51_PAD_EIM_D24 = 9,
-	MX51_PAD_EIM_D25 = 10,
-	MX51_PAD_EIM_D26 = 11,
-	MX51_PAD_EIM_D27 = 12,
-	MX51_PAD_EIM_D28 = 13,
-	MX51_PAD_EIM_D29 = 14,
-	MX51_PAD_EIM_D30 = 15,
-	MX51_PAD_EIM_D31 = 16,
-	MX51_PAD_EIM_A16 = 17,
-	MX51_PAD_EIM_A17 = 18,
-	MX51_PAD_EIM_A18 = 19,
-	MX51_PAD_EIM_A19 = 20,
-	MX51_PAD_EIM_A20 = 21,
-	MX51_PAD_EIM_A21 = 22,
-	MX51_PAD_EIM_A22 = 23,
-	MX51_PAD_EIM_A23 = 24,
-	MX51_PAD_EIM_A24 = 25,
-	MX51_PAD_EIM_A25 = 26,
-	MX51_PAD_EIM_A26 = 27,
-	MX51_PAD_EIM_A27 = 28,
-	MX51_PAD_EIM_EB0 = 29,
-	MX51_PAD_EIM_EB1 = 30,
-	MX51_PAD_EIM_EB2 = 31,
-	MX51_PAD_EIM_EB3 = 32,
-	MX51_PAD_EIM_OE = 33,
-	MX51_PAD_EIM_CS0 = 34,
-	MX51_PAD_EIM_CS1 = 35,
-	MX51_PAD_EIM_CS2 = 36,
-	MX51_PAD_EIM_CS3 = 37,
-	MX51_PAD_EIM_CS4 = 38,
-	MX51_PAD_EIM_CS5 = 39,
-	MX51_PAD_EIM_DTACK = 40,
-	MX51_PAD_EIM_LBA = 41,
-	MX51_PAD_EIM_CRE = 42,
-	MX51_PAD_DRAM_CS1 = 43,
-	MX51_PAD_NANDF_WE_B = 44,
-	MX51_PAD_NANDF_RE_B = 45,
-	MX51_PAD_NANDF_ALE = 46,
-	MX51_PAD_NANDF_CLE = 47,
-	MX51_PAD_NANDF_WP_B = 48,
-	MX51_PAD_NANDF_RB0 = 49,
-	MX51_PAD_NANDF_RB1 = 50,
-	MX51_PAD_NANDF_RB2 = 51,
-	MX51_PAD_NANDF_RB3 = 52,
-	MX51_PAD_GPIO_NAND = 53,
-	MX51_PAD_NANDF_CS0 = 54,
-	MX51_PAD_NANDF_CS1 = 55,
-	MX51_PAD_NANDF_CS2 = 56,
-	MX51_PAD_NANDF_CS3 = 57,
-	MX51_PAD_NANDF_CS4 = 58,
-	MX51_PAD_NANDF_CS5 = 59,
-	MX51_PAD_NANDF_CS6 = 60,
-	MX51_PAD_NANDF_CS7 = 61,
-	MX51_PAD_NANDF_RDY_INT = 62,
-	MX51_PAD_NANDF_D15 = 63,
-	MX51_PAD_NANDF_D14 = 64,
-	MX51_PAD_NANDF_D13 = 65,
-	MX51_PAD_NANDF_D12 = 66,
-	MX51_PAD_NANDF_D11 = 67,
-	MX51_PAD_NANDF_D10 = 68,
-	MX51_PAD_NANDF_D9 = 69,
-	MX51_PAD_NANDF_D8 = 70,
-	MX51_PAD_NANDF_D7 = 71,
-	MX51_PAD_NANDF_D6 = 72,
-	MX51_PAD_NANDF_D5 = 73,
-	MX51_PAD_NANDF_D4 = 74,
-	MX51_PAD_NANDF_D3 = 75,
-	MX51_PAD_NANDF_D2 = 76,
-	MX51_PAD_NANDF_D1 = 77,
-	MX51_PAD_NANDF_D0 = 78,
-	MX51_PAD_CSI1_D8 = 79,
-	MX51_PAD_CSI1_D9 = 80,
-	MX51_PAD_CSI1_D10 = 81,
-	MX51_PAD_CSI1_D11 = 82,
-	MX51_PAD_CSI1_D12 = 83,
-	MX51_PAD_CSI1_D13 = 84,
-	MX51_PAD_CSI1_D14 = 85,
-	MX51_PAD_CSI1_D15 = 86,
-	MX51_PAD_CSI1_D16 = 87,
-	MX51_PAD_CSI1_D17 = 88,
-	MX51_PAD_CSI1_D18 = 89,
-	MX51_PAD_CSI1_D19 = 90,
-	MX51_PAD_CSI1_VSYNC = 91,
-	MX51_PAD_CSI1_HSYNC = 92,
-	MX51_PAD_CSI1_PIXCLK = 93,
-	MX51_PAD_CSI1_MCLK = 94,
-	MX51_PAD_CSI2_D12 = 95,
-	MX51_PAD_CSI2_D13 = 96,
-	MX51_PAD_CSI2_D14 = 97,
-	MX51_PAD_CSI2_D15 = 98,
-	MX51_PAD_CSI2_D16 = 99,
-	MX51_PAD_CSI2_D17 = 100,
-	MX51_PAD_CSI2_D18 = 101,
-	MX51_PAD_CSI2_D19 = 102,
-	MX51_PAD_CSI2_VSYNC = 103,
-	MX51_PAD_CSI2_HSYNC = 104,
-	MX51_PAD_CSI2_PIXCLK = 105,
-	MX51_PAD_I2C1_CLK = 106,
-	MX51_PAD_I2C1_DAT = 107,
-	MX51_PAD_AUD3_BB_TXD = 108,
-	MX51_PAD_AUD3_BB_RXD = 109,
-	MX51_PAD_AUD3_BB_CK = 110,
-	MX51_PAD_AUD3_BB_FS = 111,
-	MX51_PAD_CSPI1_MOSI = 112,
-	MX51_PAD_CSPI1_MISO = 113,
-	MX51_PAD_CSPI1_SS0 = 114,
-	MX51_PAD_CSPI1_SS1 = 115,
-	MX51_PAD_CSPI1_RDY = 116,
-	MX51_PAD_CSPI1_SCLK = 117,
-	MX51_PAD_UART1_RXD = 118,
-	MX51_PAD_UART1_TXD = 119,
-	MX51_PAD_UART1_RTS = 120,
-	MX51_PAD_UART1_CTS = 121,
-	MX51_PAD_UART2_RXD = 122,
-	MX51_PAD_UART2_TXD = 123,
-	MX51_PAD_UART3_RXD = 124,
-	MX51_PAD_UART3_TXD = 125,
-	MX51_PAD_OWIRE_LINE = 126,
-	MX51_PAD_KEY_ROW0 = 127,
-	MX51_PAD_KEY_ROW1 = 128,
-	MX51_PAD_KEY_ROW2 = 129,
-	MX51_PAD_KEY_ROW3 = 130,
-	MX51_PAD_KEY_COL0 = 131,
-	MX51_PAD_KEY_COL1 = 132,
-	MX51_PAD_KEY_COL2 = 133,
-	MX51_PAD_KEY_COL3 = 134,
-	MX51_PAD_KEY_COL4 = 135,
-	MX51_PAD_KEY_COL5 = 136,
-	MX51_PAD_USBH1_CLK = 137,
-	MX51_PAD_USBH1_DIR = 138,
-	MX51_PAD_USBH1_STP = 139,
-	MX51_PAD_USBH1_NXT = 140,
-	MX51_PAD_USBH1_DATA0 = 141,
-	MX51_PAD_USBH1_DATA1 = 142,
-	MX51_PAD_USBH1_DATA2 = 143,
-	MX51_PAD_USBH1_DATA3 = 144,
-	MX51_PAD_USBH1_DATA4 = 145,
-	MX51_PAD_USBH1_DATA5 = 146,
-	MX51_PAD_USBH1_DATA6 = 147,
-	MX51_PAD_USBH1_DATA7 = 148,
-	MX51_PAD_DI1_PIN11 = 149,
-	MX51_PAD_DI1_PIN12 = 150,
-	MX51_PAD_DI1_PIN13 = 151,
-	MX51_PAD_DI1_D0_CS = 152,
-	MX51_PAD_DI1_D1_CS = 153,
-	MX51_PAD_DISPB2_SER_DIN = 154,
-	MX51_PAD_DISPB2_SER_DIO = 155,
-	MX51_PAD_DISPB2_SER_CLK = 156,
-	MX51_PAD_DISPB2_SER_RS = 157,
-	MX51_PAD_DISP1_DAT0 = 158,
-	MX51_PAD_DISP1_DAT1 = 159,
-	MX51_PAD_DISP1_DAT2 = 160,
-	MX51_PAD_DISP1_DAT3 = 161,
-	MX51_PAD_DISP1_DAT4 = 162,
-	MX51_PAD_DISP1_DAT5 = 163,
-	MX51_PAD_DISP1_DAT6 = 164,
-	MX51_PAD_DISP1_DAT7 = 165,
-	MX51_PAD_DISP1_DAT8 = 166,
-	MX51_PAD_DISP1_DAT9 = 167,
-	MX51_PAD_DISP1_DAT10 = 168,
-	MX51_PAD_DISP1_DAT11 = 169,
-	MX51_PAD_DISP1_DAT12 = 170,
-	MX51_PAD_DISP1_DAT13 = 171,
-	MX51_PAD_DISP1_DAT14 = 172,
-	MX51_PAD_DISP1_DAT15 = 173,
-	MX51_PAD_DISP1_DAT16 = 174,
-	MX51_PAD_DISP1_DAT17 = 175,
-	MX51_PAD_DISP1_DAT18 = 176,
-	MX51_PAD_DISP1_DAT19 = 177,
-	MX51_PAD_DISP1_DAT20 = 178,
-	MX51_PAD_DISP1_DAT21 = 179,
-	MX51_PAD_DISP1_DAT22 = 180,
-	MX51_PAD_DISP1_DAT23 = 181,
-	MX51_PAD_DI1_PIN3 = 182,
-	MX51_PAD_DI1_PIN2 = 183,
-	MX51_PAD_DI_GP2 = 184,
-	MX51_PAD_DI_GP3 = 185,
-	MX51_PAD_DI2_PIN4 = 186,
-	MX51_PAD_DI2_PIN2 = 187,
-	MX51_PAD_DI2_PIN3 = 188,
-	MX51_PAD_DI2_DISP_CLK = 189,
-	MX51_PAD_DI_GP4 = 190,
-	MX51_PAD_DISP2_DAT0 = 191,
-	MX51_PAD_DISP2_DAT1 = 192,
-	MX51_PAD_DISP2_DAT2 = 193,
-	MX51_PAD_DISP2_DAT3 = 194,
-	MX51_PAD_DISP2_DAT4 = 195,
-	MX51_PAD_DISP2_DAT5 = 196,
-	MX51_PAD_DISP2_DAT6 = 197,
-	MX51_PAD_DISP2_DAT7 = 198,
-	MX51_PAD_DISP2_DAT8 = 199,
-	MX51_PAD_DISP2_DAT9 = 200,
-	MX51_PAD_DISP2_DAT10 = 201,
-	MX51_PAD_DISP2_DAT11 = 202,
-	MX51_PAD_DISP2_DAT12 = 203,
-	MX51_PAD_DISP2_DAT13 = 204,
-	MX51_PAD_DISP2_DAT14 = 205,
-	MX51_PAD_DISP2_DAT15 = 206,
-	MX51_PAD_SD1_CMD = 207,
-	MX51_PAD_SD1_CLK = 208,
-	MX51_PAD_SD1_DATA0 = 209,
-	MX51_PAD_EIM_DA0 = 210,
-	MX51_PAD_EIM_DA1 = 211,
-	MX51_PAD_EIM_DA2 = 212,
-	MX51_PAD_EIM_DA3 = 213,
-	MX51_PAD_SD1_DATA1 = 214,
-	MX51_PAD_EIM_DA4 = 215,
-	MX51_PAD_EIM_DA5 = 216,
-	MX51_PAD_EIM_DA6 = 217,
-	MX51_PAD_EIM_DA7 = 218,
-	MX51_PAD_SD1_DATA2 = 219,
-	MX51_PAD_EIM_DA10 = 220,
-	MX51_PAD_EIM_DA11 = 221,
-	MX51_PAD_EIM_DA8 = 222,
-	MX51_PAD_EIM_DA9 = 223,
-	MX51_PAD_SD1_DATA3 = 224,
-	MX51_PAD_GPIO1_0 = 225,
-	MX51_PAD_GPIO1_1 = 226,
-	MX51_PAD_EIM_DA12 = 227,
-	MX51_PAD_EIM_DA13 = 228,
-	MX51_PAD_EIM_DA14 = 229,
-	MX51_PAD_EIM_DA15 = 230,
-	MX51_PAD_SD2_CMD = 231,
-	MX51_PAD_SD2_CLK = 232,
-	MX51_PAD_SD2_DATA0 = 233,
-	MX51_PAD_SD2_DATA1 = 234,
-	MX51_PAD_SD2_DATA2 = 235,
-	MX51_PAD_SD2_DATA3 = 236,
-	MX51_PAD_GPIO1_2 = 237,
-	MX51_PAD_GPIO1_3 = 238,
-	MX51_PAD_PMIC_INT_REQ = 239,
-	MX51_PAD_GPIO1_4 = 240,
-	MX51_PAD_GPIO1_5 = 241,
-	MX51_PAD_GPIO1_6 = 242,
-	MX51_PAD_GPIO1_7 = 243,
-	MX51_PAD_GPIO1_8 = 244,
-	MX51_PAD_GPIO1_9 = 245,
+	MX51_PAD_EIM_D16 = 0,
+	MX51_PAD_EIM_D17 = 1,
+	MX51_PAD_EIM_D18 = 2,
+	MX51_PAD_EIM_D19 = 3,
+	MX51_PAD_EIM_D20 = 4,
+	MX51_PAD_EIM_D21 = 5,
+	MX51_PAD_EIM_D22 = 6,
+	MX51_PAD_EIM_D23 = 7,
+	MX51_PAD_EIM_D24 = 8,
+	MX51_PAD_EIM_D25 = 9,
+	MX51_PAD_EIM_D26 = 10,
+	MX51_PAD_EIM_D27 = 11,
+	MX51_PAD_EIM_D28 = 12,
+	MX51_PAD_EIM_D29 = 13,
+	MX51_PAD_EIM_D30 = 14,
+	MX51_PAD_EIM_D31 = 15,
+	MX51_PAD_EIM_A16 = 16,
+	MX51_PAD_EIM_A17 = 17,
+	MX51_PAD_EIM_A18 = 18,
+	MX51_PAD_EIM_A19 = 19,
+	MX51_PAD_EIM_A20 = 20,
+	MX51_PAD_EIM_A21 = 21,
+	MX51_PAD_EIM_A22 = 22,
+	MX51_PAD_EIM_A23 = 23,
+	MX51_PAD_EIM_A24 = 24,
+	MX51_PAD_EIM_A25 = 25,
+	MX51_PAD_EIM_A26 = 26,
+	MX51_PAD_EIM_A27 = 27,
+	MX51_PAD_EIM_EB0 = 28,
+	MX51_PAD_EIM_EB1 = 29,
+	MX51_PAD_EIM_EB2 = 30,
+	MX51_PAD_EIM_EB3 = 31,
+	MX51_PAD_EIM_OE = 32,
+	MX51_PAD_EIM_CS0 = 33,
+	MX51_PAD_EIM_CS1 = 34,
+	MX51_PAD_EIM_CS2 = 35,
+	MX51_PAD_EIM_CS3 = 36,
+	MX51_PAD_EIM_CS4 = 37,
+	MX51_PAD_EIM_CS5 = 38,
+	MX51_PAD_EIM_DTACK = 39,
+	MX51_PAD_EIM_LBA = 40,
+	MX51_PAD_EIM_CRE = 41,
+	MX51_PAD_DRAM_CS1 = 42,
+	MX51_PAD_NANDF_WE_B = 43,
+	MX51_PAD_NANDF_RE_B = 44,
+	MX51_PAD_NANDF_ALE = 45,
+	MX51_PAD_NANDF_CLE = 46,
+	MX51_PAD_NANDF_WP_B = 47,
+	MX51_PAD_NANDF_RB0 = 48,
+	MX51_PAD_NANDF_RB1 = 49,
+	MX51_PAD_NANDF_RB2 = 50,
+	MX51_PAD_NANDF_RB3 = 51,
+	MX51_PAD_GPIO_NAND = 52,
+	MX51_PAD_NANDF_CS0 = 53,
+	MX51_PAD_NANDF_CS1 = 54,
+	MX51_PAD_NANDF_CS2 = 55,
+	MX51_PAD_NANDF_CS3 = 56,
+	MX51_PAD_NANDF_CS4 = 57,
+	MX51_PAD_NANDF_CS5 = 58,
+	MX51_PAD_NANDF_CS6 = 59,
+	MX51_PAD_NANDF_CS7 = 60,
+	MX51_PAD_NANDF_RDY_INT = 61,
+	MX51_PAD_NANDF_D15 = 62,
+	MX51_PAD_NANDF_D14 = 63,
+	MX51_PAD_NANDF_D13 = 64,
+	MX51_PAD_NANDF_D12 = 65,
+	MX51_PAD_NANDF_D11 = 66,
+	MX51_PAD_NANDF_D10 = 67,
+	MX51_PAD_NANDF_D9 = 68,
+	MX51_PAD_NANDF_D8 = 69,
+	MX51_PAD_NANDF_D7 = 70,
+	MX51_PAD_NANDF_D6 = 71,
+	MX51_PAD_NANDF_D5 = 72,
+	MX51_PAD_NANDF_D4 = 73,
+	MX51_PAD_NANDF_D3 = 74,
+	MX51_PAD_NANDF_D2 = 75,
+	MX51_PAD_NANDF_D1 = 76,
+	MX51_PAD_NANDF_D0 = 77,
+	MX51_PAD_CSI1_D8 = 78,
+	MX51_PAD_CSI1_D9 = 79,
+	MX51_PAD_CSI1_D10 = 80,
+	MX51_PAD_CSI1_D11 = 81,
+	MX51_PAD_CSI1_D12 = 82,
+	MX51_PAD_CSI1_D13 = 83,
+	MX51_PAD_CSI1_D14 = 84,
+	MX51_PAD_CSI1_D15 = 85,
+	MX51_PAD_CSI1_D16 = 86,
+	MX51_PAD_CSI1_D17 = 87,
+	MX51_PAD_CSI1_D18 = 88,
+	MX51_PAD_CSI1_D19 = 89,
+	MX51_PAD_CSI1_VSYNC = 90,
+	MX51_PAD_CSI1_HSYNC = 91,
+	MX51_PAD_CSI1_PIXCLK = 92,
+	MX51_PAD_CSI1_MCLK = 93,
+	MX51_PAD_CSI2_D12 = 94,
+	MX51_PAD_CSI2_D13 = 95,
+	MX51_PAD_CSI2_D14 = 96,
+	MX51_PAD_CSI2_D15 = 97,
+	MX51_PAD_CSI2_D16 = 98,
+	MX51_PAD_CSI2_D17 = 99,
+	MX51_PAD_CSI2_D18 = 100,
+	MX51_PAD_CSI2_D19 = 101,
+	MX51_PAD_CSI2_VSYNC = 102,
+	MX51_PAD_CSI2_HSYNC = 103,
+	MX51_PAD_CSI2_PIXCLK = 104,
+	MX51_PAD_I2C1_CLK = 105,
+	MX51_PAD_I2C1_DAT = 106,
+	MX51_PAD_AUD3_BB_TXD = 107,
+	MX51_PAD_AUD3_BB_RXD = 108,
+	MX51_PAD_AUD3_BB_CK = 109,
+	MX51_PAD_AUD3_BB_FS = 110,
+	MX51_PAD_CSPI1_MOSI = 111,
+	MX51_PAD_CSPI1_MISO = 112,
+	MX51_PAD_CSPI1_SS0 = 113,
+	MX51_PAD_CSPI1_SS1 = 114,
+	MX51_PAD_CSPI1_RDY = 115,
+	MX51_PAD_CSPI1_SCLK = 116,
+	MX51_PAD_UART1_RXD = 117,
+	MX51_PAD_UART1_TXD = 118,
+	MX51_PAD_UART1_RTS = 119,
+	MX51_PAD_UART1_CTS = 120,
+	MX51_PAD_UART2_RXD = 121,
+	MX51_PAD_UART2_TXD = 122,
+	MX51_PAD_UART3_RXD = 123,
+	MX51_PAD_UART3_TXD = 124,
+	MX51_PAD_OWIRE_LINE = 125,
+	MX51_PAD_KEY_ROW0 = 126,
+	MX51_PAD_KEY_ROW1 = 127,
+	MX51_PAD_KEY_ROW2 = 128,
+	MX51_PAD_KEY_ROW3 = 129,
+	MX51_PAD_KEY_COL0 = 130,
+	MX51_PAD_KEY_COL1 = 131,
+	MX51_PAD_KEY_COL2 = 132,
+	MX51_PAD_KEY_COL3 = 133,
+	MX51_PAD_KEY_COL4 = 134,
+	MX51_PAD_KEY_COL5 = 135,
+	MX51_PAD_USBH1_CLK = 136,
+	MX51_PAD_USBH1_DIR = 137,
+	MX51_PAD_USBH1_STP = 138,
+	MX51_PAD_USBH1_NXT = 139,
+	MX51_PAD_USBH1_DATA0 = 140,
+	MX51_PAD_USBH1_DATA1 = 141,
+	MX51_PAD_USBH1_DATA2 = 142,
+	MX51_PAD_USBH1_DATA3 = 143,
+	MX51_PAD_USBH1_DATA4 = 144,
+	MX51_PAD_USBH1_DATA5 = 145,
+	MX51_PAD_USBH1_DATA6 = 146,
+	MX51_PAD_USBH1_DATA7 = 147,
+	MX51_PAD_DI1_PIN11 = 148,
+	MX51_PAD_DI1_PIN12 = 149,
+	MX51_PAD_DI1_PIN13 = 150,
+	MX51_PAD_DI1_D0_CS = 151,
+	MX51_PAD_DI1_D1_CS = 152,
+	MX51_PAD_DISPB2_SER_DIN = 153,
+	MX51_PAD_DISPB2_SER_DIO = 154,
+	MX51_PAD_DISPB2_SER_CLK = 155,
+	MX51_PAD_DISPB2_SER_RS = 156,
+	MX51_PAD_DISP1_DAT0 = 157,
+	MX51_PAD_DISP1_DAT1 = 158,
+	MX51_PAD_DISP1_DAT2 = 159,
+	MX51_PAD_DISP1_DAT3 = 160,
+	MX51_PAD_DISP1_DAT4 = 161,
+	MX51_PAD_DISP1_DAT5 = 162,
+	MX51_PAD_DISP1_DAT6 = 163,
+	MX51_PAD_DISP1_DAT7 = 164,
+	MX51_PAD_DISP1_DAT8 = 165,
+	MX51_PAD_DISP1_DAT9 = 166,
+	MX51_PAD_DISP1_DAT10 = 167,
+	MX51_PAD_DISP1_DAT11 = 168,
+	MX51_PAD_DISP1_DAT12 = 169,
+	MX51_PAD_DISP1_DAT13 = 170,
+	MX51_PAD_DISP1_DAT14 = 171,
+	MX51_PAD_DISP1_DAT15 = 172,
+	MX51_PAD_DISP1_DAT16 = 173,
+	MX51_PAD_DISP1_DAT17 = 174,
+	MX51_PAD_DISP1_DAT18 = 175,
+	MX51_PAD_DISP1_DAT19 = 176,
+	MX51_PAD_DISP1_DAT20 = 177,
+	MX51_PAD_DISP1_DAT21 = 178,
+	MX51_PAD_DISP1_DAT22 = 179,
+	MX51_PAD_DISP1_DAT23 = 180,
+	MX51_PAD_DI1_PIN3 = 181,
+	MX51_PAD_DI1_PIN2 = 182,
+	MX51_PAD_DI_GP2 = 183,
+	MX51_PAD_DI_GP3 = 184,
+	MX51_PAD_DI2_PIN4 = 185,
+	MX51_PAD_DI2_PIN2 = 186,
+	MX51_PAD_DI2_PIN3 = 187,
+	MX51_PAD_DI2_DISP_CLK = 188,
+	MX51_PAD_DI_GP4 = 189,
+	MX51_PAD_DISP2_DAT0 = 190,
+	MX51_PAD_DISP2_DAT1 = 191,
+	MX51_PAD_DISP2_DAT2 = 192,
+	MX51_PAD_DISP2_DAT3 = 193,
+	MX51_PAD_DISP2_DAT4 = 194,
+	MX51_PAD_DISP2_DAT5 = 195,
+	MX51_PAD_DISP2_DAT6 = 196,
+	MX51_PAD_DISP2_DAT7 = 197,
+	MX51_PAD_DISP2_DAT8 = 198,
+	MX51_PAD_DISP2_DAT9 = 199,
+	MX51_PAD_DISP2_DAT10 = 200,
+	MX51_PAD_DISP2_DAT11 = 201,
+	MX51_PAD_DISP2_DAT12 = 202,
+	MX51_PAD_DISP2_DAT13 = 203,
+	MX51_PAD_DISP2_DAT14 = 204,
+	MX51_PAD_DISP2_DAT15 = 205,
+	MX51_PAD_SD1_CMD = 206,
+	MX51_PAD_SD1_CLK = 207,
+	MX51_PAD_SD1_DATA0 = 208,
+	MX51_PAD_EIM_DA0 = 209,
+	MX51_PAD_EIM_DA1 = 210,
+	MX51_PAD_EIM_DA2 = 211,
+	MX51_PAD_EIM_DA3 = 212,
+	MX51_PAD_SD1_DATA1 = 213,
+	MX51_PAD_EIM_DA4 = 214,
+	MX51_PAD_EIM_DA5 = 215,
+	MX51_PAD_EIM_DA6 = 216,
+	MX51_PAD_EIM_DA7 = 217,
+	MX51_PAD_SD1_DATA2 = 218,
+	MX51_PAD_EIM_DA10 = 219,
+	MX51_PAD_EIM_DA11 = 220,
+	MX51_PAD_EIM_DA8 = 221,
+	MX51_PAD_EIM_DA9 = 222,
+	MX51_PAD_SD1_DATA3 = 223,
+	MX51_PAD_GPIO1_0 = 224,
+	MX51_PAD_GPIO1_1 = 225,
+	MX51_PAD_EIM_DA12 = 226,
+	MX51_PAD_EIM_DA13 = 227,
+	MX51_PAD_EIM_DA14 = 228,
+	MX51_PAD_EIM_DA15 = 229,
+	MX51_PAD_SD2_CMD = 230,
+	MX51_PAD_SD2_CLK = 231,
+	MX51_PAD_SD2_DATA0 = 232,
+	MX51_PAD_SD2_DATA1 = 233,
+	MX51_PAD_SD2_DATA2 = 234,
+	MX51_PAD_SD2_DATA3 = 235,
+	MX51_PAD_GPIO1_2 = 236,
+	MX51_PAD_GPIO1_3 = 237,
+	MX51_PAD_PMIC_INT_REQ = 238,
+	MX51_PAD_GPIO1_4 = 239,
+	MX51_PAD_GPIO1_5 = 240,
+	MX51_PAD_GPIO1_6 = 241,
+	MX51_PAD_GPIO1_7 = 242,
+	MX51_PAD_GPIO1_8 = 243,
+	MX51_PAD_GPIO1_9 = 244,
  };
 
  /* imx51 register maps */

drivers/pinctrl/pinctrl-imx53.c +0 -193

index 1f49e16..783feb1 100644
@@ -23,207 +23,207 @@
  #include "pinctrl-imx.h"
 
  enum imx53_pads {
-	MX53_PAD_GPIO_19 = 1,
-	MX53_PAD_KEY_COL0 = 2,
-	MX53_PAD_KEY_ROW0 = 3,
-	MX53_PAD_KEY_COL1 = 4,
-	MX53_PAD_KEY_ROW1 = 5,
-	MX53_PAD_KEY_COL2 = 6,
-	MX53_PAD_KEY_ROW2 = 7,
-	MX53_PAD_KEY_COL3 = 8,
-	MX53_PAD_KEY_ROW3 = 9,
-	MX53_PAD_KEY_COL4 = 10,
-	MX53_PAD_KEY_ROW4 = 11,
-	MX53_PAD_DI0_DISP_CLK = 12,
-	MX53_PAD_DI0_PIN15 = 13,
-	MX53_PAD_DI0_PIN2 = 14,
-	MX53_PAD_DI0_PIN3 = 15,
-	MX53_PAD_DI0_PIN4 = 16,
-	MX53_PAD_DISP0_DAT0 = 17,
-	MX53_PAD_DISP0_DAT1 = 18,
-	MX53_PAD_DISP0_DAT2 = 19,
-	MX53_PAD_DISP0_DAT3 = 20,
-	MX53_PAD_DISP0_DAT4 = 21,
-	MX53_PAD_DISP0_DAT5 = 22,
-	MX53_PAD_DISP0_DAT6 = 23,
-	MX53_PAD_DISP0_DAT7 = 24,
-	MX53_PAD_DISP0_DAT8 = 25,
-	MX53_PAD_DISP0_DAT9 = 26,
-	MX53_PAD_DISP0_DAT10 = 27,
-	MX53_PAD_DISP0_DAT11 = 28,
-	MX53_PAD_DISP0_DAT12 = 29,
-	MX53_PAD_DISP0_DAT13 = 30,
-	MX53_PAD_DISP0_DAT14 = 31,
-	MX53_PAD_DISP0_DAT15 = 32,
-	MX53_PAD_DISP0_DAT16 = 33,
-	MX53_PAD_DISP0_DAT17 = 34,
-	MX53_PAD_DISP0_DAT18 = 35,
-	MX53_PAD_DISP0_DAT19 = 36,
-	MX53_PAD_DISP0_DAT20 = 37,
-	MX53_PAD_DISP0_DAT21 = 38,
-	MX53_PAD_DISP0_DAT22 = 39,
-	MX53_PAD_DISP0_DAT23 = 40,
-	MX53_PAD_CSI0_PIXCLK = 41,
-	MX53_PAD_CSI0_MCLK = 42,
-	MX53_PAD_CSI0_DATA_EN = 43,
-	MX53_PAD_CSI0_VSYNC = 44,
-	MX53_PAD_CSI0_DAT4 = 45,
-	MX53_PAD_CSI0_DAT5 = 46,
-	MX53_PAD_CSI0_DAT6 = 47,
-	MX53_PAD_CSI0_DAT7 = 48,
-	MX53_PAD_CSI0_DAT8 = 49,
-	MX53_PAD_CSI0_DAT9 = 50,
-	MX53_PAD_CSI0_DAT10 = 51,
-	MX53_PAD_CSI0_DAT11 = 52,
-	MX53_PAD_CSI0_DAT12 = 53,
-	MX53_PAD_CSI0_DAT13 = 54,
-	MX53_PAD_CSI0_DAT14 = 55,
-	MX53_PAD_CSI0_DAT15 = 56,
-	MX53_PAD_CSI0_DAT16 = 57,
-	MX53_PAD_CSI0_DAT17 = 58,
-	MX53_PAD_CSI0_DAT18 = 59,
-	MX53_PAD_CSI0_DAT19 = 60,
-	MX53_PAD_EIM_A25 = 61,
-	MX53_PAD_EIM_EB2 = 62,
-	MX53_PAD_EIM_D16 = 63,
-	MX53_PAD_EIM_D17 = 64,
-	MX53_PAD_EIM_D18 = 65,
-	MX53_PAD_EIM_D19 = 66,
-	MX53_PAD_EIM_D20 = 67,
-	MX53_PAD_EIM_D21 = 68,
-	MX53_PAD_EIM_D22 = 69,
-	MX53_PAD_EIM_D23 = 70,
-	MX53_PAD_EIM_EB3 = 71,
-	MX53_PAD_EIM_D24 = 72,
-	MX53_PAD_EIM_D25 = 73,
-	MX53_PAD_EIM_D26 = 74,
-	MX53_PAD_EIM_D27 = 75,
-	MX53_PAD_EIM_D28 = 76,
-	MX53_PAD_EIM_D29 = 77,
-	MX53_PAD_EIM_D30 = 78,
-	MX53_PAD_EIM_D31 = 79,
-	MX53_PAD_EIM_A24 = 80,
-	MX53_PAD_EIM_A23 = 81,
-	MX53_PAD_EIM_A22 = 82,
-	MX53_PAD_EIM_A21 = 83,
-	MX53_PAD_EIM_A20 = 84,
-	MX53_PAD_EIM_A19 = 85,
-	MX53_PAD_EIM_A18 = 86,
-	MX53_PAD_EIM_A17 = 87,
-	MX53_PAD_EIM_A16 = 88,
-	MX53_PAD_EIM_CS0 = 89,
-	MX53_PAD_EIM_CS1 = 90,
-	MX53_PAD_EIM_OE = 91,
-	MX53_PAD_EIM_RW = 92,
-	MX53_PAD_EIM_LBA = 93,
-	MX53_PAD_EIM_EB0 = 94,
-	MX53_PAD_EIM_EB1 = 95,
-	MX53_PAD_EIM_DA0 = 96,
-	MX53_PAD_EIM_DA1 = 97,
-	MX53_PAD_EIM_DA2 = 98,
-	MX53_PAD_EIM_DA3 = 99,
-	MX53_PAD_EIM_DA4 = 100,
-	MX53_PAD_EIM_DA5 = 101,
-	MX53_PAD_EIM_DA6 = 102,
-	MX53_PAD_EIM_DA7 = 103,
-	MX53_PAD_EIM_DA8 = 104,
-	MX53_PAD_EIM_DA9 = 105,
-	MX53_PAD_EIM_DA10 = 106,
-	MX53_PAD_EIM_DA11 = 107,
-	MX53_PAD_EIM_DA12 = 108,
-	MX53_PAD_EIM_DA13 = 109,
-	MX53_PAD_EIM_DA14 = 110,
-	MX53_PAD_EIM_DA15 = 111,
-	MX53_PAD_NANDF_WE_B = 112,
-	MX53_PAD_NANDF_RE_B = 113,
-	MX53_PAD_EIM_WAIT = 114,
-	MX53_PAD_LVDS1_TX3_P = 115,
-	MX53_PAD_LVDS1_TX2_P = 116,
-	MX53_PAD_LVDS1_CLK_P = 117,
-	MX53_PAD_LVDS1_TX1_P = 118,
-	MX53_PAD_LVDS1_TX0_P = 119,
-	MX53_PAD_LVDS0_TX3_P = 120,
-	MX53_PAD_LVDS0_CLK_P = 121,
-	MX53_PAD_LVDS0_TX2_P = 122,
-	MX53_PAD_LVDS0_TX1_P = 123,
-	MX53_PAD_LVDS0_TX0_P = 124,
-	MX53_PAD_GPIO_10 = 125,
-	MX53_PAD_GPIO_11 = 126,
-	MX53_PAD_GPIO_12 = 127,
-	MX53_PAD_GPIO_13 = 128,
-	MX53_PAD_GPIO_14 = 129,
-	MX53_PAD_NANDF_CLE = 130,
-	MX53_PAD_NANDF_ALE = 131,
-	MX53_PAD_NANDF_WP_B = 132,
-	MX53_PAD_NANDF_RB0 = 133,
-	MX53_PAD_NANDF_CS0 = 134,
-	MX53_PAD_NANDF_CS1 = 135,
-	MX53_PAD_NANDF_CS2 = 136,
-	MX53_PAD_NANDF_CS3 = 137,
-	MX53_PAD_FEC_MDIO = 138,
-	MX53_PAD_FEC_REF_CLK = 139,
-	MX53_PAD_FEC_RX_ER = 140,
-	MX53_PAD_FEC_CRS_DV = 141,
-	MX53_PAD_FEC_RXD1 = 142,
-	MX53_PAD_FEC_RXD0 = 143,
-	MX53_PAD_FEC_TX_EN = 144,
-	MX53_PAD_FEC_TXD1 = 145,
-	MX53_PAD_FEC_TXD0 = 146,
-	MX53_PAD_FEC_MDC = 147,
-	MX53_PAD_PATA_DIOW = 148,
-	MX53_PAD_PATA_DMACK = 149,
-	MX53_PAD_PATA_DMARQ = 150,
-	MX53_PAD_PATA_BUFFER_EN = 151,
-	MX53_PAD_PATA_INTRQ = 152,
-	MX53_PAD_PATA_DIOR = 153,
-	MX53_PAD_PATA_RESET_B = 154,
-	MX53_PAD_PATA_IORDY = 155,
-	MX53_PAD_PATA_DA_0 = 156,
-	MX53_PAD_PATA_DA_1 = 157,
-	MX53_PAD_PATA_DA_2 = 158,
-	MX53_PAD_PATA_CS_0 = 159,
-	MX53_PAD_PATA_CS_1 = 160,
-	MX53_PAD_PATA_DATA0 = 161,
-	MX53_PAD_PATA_DATA1 = 162,
-	MX53_PAD_PATA_DATA2 = 163,
-	MX53_PAD_PATA_DATA3 = 164,
-	MX53_PAD_PATA_DATA4 = 165,
-	MX53_PAD_PATA_DATA5 = 166,
-	MX53_PAD_PATA_DATA6 = 167,
-	MX53_PAD_PATA_DATA7 = 168,
-	MX53_PAD_PATA_DATA8 = 169,
-	MX53_PAD_PATA_DATA9 = 170,
-	MX53_PAD_PATA_DATA10 = 171,
-	MX53_PAD_PATA_DATA11 = 172,
-	MX53_PAD_PATA_DATA12 = 173,
-	MX53_PAD_PATA_DATA13 = 174,
-	MX53_PAD_PATA_DATA14 = 175,
-	MX53_PAD_PATA_DATA15 = 176,
-	MX53_PAD_SD1_DATA0 = 177,
-	MX53_PAD_SD1_DATA1 = 178,
-	MX53_PAD_SD1_CMD = 179,
-	MX53_PAD_SD1_DATA2 = 180,
-	MX53_PAD_SD1_CLK = 181,
-	MX53_PAD_SD1_DATA3 = 182,
-	MX53_PAD_SD2_CLK = 183,
-	MX53_PAD_SD2_CMD = 184,
-	MX53_PAD_SD2_DATA3 = 185,
-	MX53_PAD_SD2_DATA2 = 186,
-	MX53_PAD_SD2_DATA1 = 187,
-	MX53_PAD_SD2_DATA0 = 188,
-	MX53_PAD_GPIO_0 = 189,
-	MX53_PAD_GPIO_1 = 190,
-	MX53_PAD_GPIO_9 = 191,
-	MX53_PAD_GPIO_3 = 192,
-	MX53_PAD_GPIO_6 = 193,