Message ID | 1344869278-27334-1-git-send-email-shawn.guo@linaro.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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).
On 8/13/2012 7:47 AM, Shawn Guo wrote: > 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 <shawn.guo@linaro.org> > --- > drivers/pinctrl/pinctrl-imx51.c | 490 +++++++++++++++++++------------------- > drivers/pinctrl/pinctrl-imx53.c | 402 ++++++++++++++++---------------- > 2 files changed, 446 insertions(+), 446 deletions(-) > > diff --git a/drivers/pinctrl/pinctrl-imx51.c b/drivers/pinctrl/pinctrl-imx51.c > index 9fd0216..fb84689 100644 > --- a/drivers/pinctrl/pinctrl-imx51.c > +++ b/drivers/pinctrl/pinctrl-imx51.c > @@ -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 */ > diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c > index 1f49e16..783feb1 100644 > --- a/drivers/pinctrl/pinctrl-imx53.c > +++ b/drivers/pinctrl/pinctrl-imx53.c > @@ -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, Why not skip the = xx altogether?? The enum will auto-increment. > + 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 */
On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: > 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? Pin id or pin register(mux or config) offset? This is for mx51, right? then why 0x300? > 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 Yes, the data is originally get from: arch/arm/plat-mxc/include/mach/iomux-mx51.h So i just followed that sequence to index pin id and currently it seems i didn't see any big problem using this way. > 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. 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? > > 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, > * move all the pin indices currently defined up by 16 for MX51 (same for above) > * _then_ renumber the current device trees.. > I did not quite understand, remove other pin ids up by 16? why? > 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). > 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 it, the only difference is the id is different, i still can't see any trouble to use it Can you help detail a bit more if any trouble? Regards Dong Aisheng
On 14 August 2012 03:26, Troy Kisky <troy.kisky@boundarydevices.com> wrote: > On 8/13/2012 7:47 AM, Shawn Guo wrote: >> >> 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 <shawn.guo@linaro.org> >> --- >> drivers/pinctrl/pinctrl-imx51.c | 490 >> +++++++++++++++++++------------------- >> drivers/pinctrl/pinctrl-imx53.c | 402 ++++++++++++++++---------------- >> 2 files changed, 446 insertions(+), 446 deletions(-) >> >> diff --git a/drivers/pinctrl/pinctrl-imx51.c >> b/drivers/pinctrl/pinctrl-imx51.c >> index 9fd0216..fb84689 100644 >> --- a/drivers/pinctrl/pinctrl-imx51.c >> +++ b/drivers/pinctrl/pinctrl-imx51.c >> @@ -23,251 +23,251 @@ >> #include "pinctrl-imx.h" >> enum imx51_pads { >> - MX51_PAD_EIM_D16 = 1, >> - MX51_PAD_EIM_D17 = 2, ... >> + MX53_PAD_GPIO_19 = 0, >> + MX53_PAD_KEY_COL0 = 1, > > > Why not skip the = xx altogether?? The enum will auto-increment. Personally i'd like to keep it. The reason is that pin id is basic property of a pin per pinctrl subsystem's design so explicitly define it looks more clear to me and i'm not sure but it's possible that the pin id may be used in device tree in the future(maybe some other soc already uses it), And defining it has no big harming. Regards Dong Aisheng
On Mon, Aug 13, 2012 at 4:47 PM, Shawn Guo <shawn.guo@linaro.org> wrote: > 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 <shawn.guo@linaro.org> Looks like a good idea. Since I just merged the imx53 driver which *again* start numbering on 1, can I have a patch that fixes that driver also? Uwe, you OK with this? Yours, Linus Walleij
On 14 August 2012 16:13, Linus Walleij <linus.walleij@linaro.org> wrote: > Since I just merged the imx53 driver which *again* start numbering on > 1, can I have a patch that fixes that driver also? > What Uwe added is imx35 (vs. imx53 :) driver, which already numbers pad from 0. Regards, Shawn > Uwe, you OK with this? >
On Tue, Aug 14, 2012 at 10:22 AM, Shawn Guo <shawn.guo@linaro.org> wrote: > On 14 August 2012 16:13, Linus Walleij <linus.walleij@linaro.org> wrote: >> Since I just merged the imx53 driver which *again* start numbering on >> 1, can I have a patch that fixes that driver also? >> > What Uwe added is imx35 (vs. imx53 :) driver, which already numbers pad from 0. Yes I was confused... I mixed up imx35 and imx53 again. Yours, Linus Walleij
On Mon, Aug 13, 2012 at 4:47 PM, Shawn Guo <shawn.guo@linaro.org> wrote: > 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 <shawn.guo@linaro.org> Applied. Yours, Linus Walleij
On 8/14/2012 12:30 AM, Dong Aisheng wrote: > On 14 August 2012 03:26, Troy Kisky <troy.kisky@boundarydevices.com> wrote: >> On 8/13/2012 7:47 AM, Shawn Guo wrote: >>> 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 <shawn.guo@linaro.org> >>> --- >>> drivers/pinctrl/pinctrl-imx51.c | 490 >>> +++++++++++++++++++------------------- >>> drivers/pinctrl/pinctrl-imx53.c | 402 ++++++++++++++++---------------- >>> 2 files changed, 446 insertions(+), 446 deletions(-) >>> >>> diff --git a/drivers/pinctrl/pinctrl-imx51.c >>> b/drivers/pinctrl/pinctrl-imx51.c >>> index 9fd0216..fb84689 100644 >>> --- a/drivers/pinctrl/pinctrl-imx51.c >>> +++ b/drivers/pinctrl/pinctrl-imx51.c >>> @@ -23,251 +23,251 @@ >>> #include "pinctrl-imx.h" >>> enum imx51_pads { >>> - MX51_PAD_EIM_D16 = 1, >>> - MX51_PAD_EIM_D17 = 2, > ... >>> + MX53_PAD_GPIO_19 = 0, >>> + MX53_PAD_KEY_COL0 = 1, >> >> Why not skip the = xx altogether?? The enum will auto-increment. > Personally i'd like to keep it. > The reason is that pin id is basic property of a pin per pinctrl > subsystem's design > so explicitly define it looks more clear to me and i'm not sure but > it's possible that > the pin id may be used in device tree in the future(maybe some other > soc already uses it), > And defining it has no big harming. > > Regards > Dong Aisheng > . > Then maybe #defines should be used, so that device tree can include this file and be run through C pre-processor? Thanks Troy
On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: > On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: >> 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? > 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. >> 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? > I did not quite understand, remove other pin ids up by 16? why? See above. > 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? > 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.
On 15 August 2012 03:37, Matt Sealey <matt@genesi-usa.com> wrote: > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: >> On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: >>> 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*. > 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. > 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. > 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. > 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. > 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? If really in that way, i feel like it's pure register write and does not require any subsystem or driver. > 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 No, like every device else, you should refer to the binding doc for the detailed binding details rather than assuming ourselves. > 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. They're different things. The enum imx51_pads is the pin id definitions. The 'MX6Q_PAD_SD4_CMD__USDHC4_CMD' is the pin func id definition. See binding doc: fsl,mxs-pinctrl.txt > Change > the array, change the binding. This is terrible, terrible design. No, the binding is driver independant. The array you said here is implementation and should not affect binding. > There should be one point of reference, and if possible, the binding > should be totally obvious without cross-reference. I agree. Can you point out the exist one? > > 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? > >> 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. > >>> 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? > b29396@shlinux2:~/upstream/linux-2.6-linus-imx$ grep -rn MX51_PAD_EIM_DA drivers/pinctrl/pinctrl-imx51.c 235: MX51_PAD_EIM_DA0 = 210, 236: MX51_PAD_EIM_DA1 = 211, 237: MX51_PAD_EIM_DA2 = 212, 238: MX51_PAD_EIM_DA3 = 213, 240: MX51_PAD_EIM_DA4 = 215, 241: MX51_PAD_EIM_DA5 = 216, 242: MX51_PAD_EIM_DA6 = 217, 243: MX51_PAD_EIM_DA7 = 218, 245: MX51_PAD_EIM_DA10 = 220, 246: MX51_PAD_EIM_DA11 = 221, 247: MX51_PAD_EIM_DA8 = 222, 248: MX51_PAD_EIM_DA9 = 223, 252: MX51_PAD_EIM_DA12 = 227, 253: MX51_PAD_EIM_DA13 = 228, 254: MX51_PAD_EIM_DA14 = 229, 255: MX51_PAD_EIM_DA15 = 230, >> I did not quite understand, remove other pin ids up by 16? why? > > See above. > >> 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? > I think the binding imx pinctrl used is not pin id dependent since it only tells the pin func id(which hw pin used in which function, pin id is linux abstract), how to define the pin id or how to parse the pin id from pin func id is driver specific. That means you can define pin id in a arbitrary number as you want. Anyway, i could double check it later. >> 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, Can you point out the exact missing pins you found? > but the implementation as a whole is too arbitrary > and too abstract. You do not need to implement indirection in the > device tree. > I just chose a better way to use. Current i did not see any big issue, anyway, i will think a bit more according to your comments. Regards Dong Aisheng
On 15 August 2012 02:09, Troy Kisky <troy.kisky@boundarydevices.com> wrote: > On 8/14/2012 12:30 AM, Dong Aisheng wrote: >> >> On 14 August 2012 03:26, Troy Kisky <troy.kisky@boundarydevices.com> >> wrote: >>> >>> On 8/13/2012 7:47 AM, Shawn Guo wrote: >>>> >>>> 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 <shawn.guo@linaro.org> >>>> --- >>>> drivers/pinctrl/pinctrl-imx51.c | 490 >>>> +++++++++++++++++++------------------- >>>> drivers/pinctrl/pinctrl-imx53.c | 402 >>>> ++++++++++++++++---------------- >>>> 2 files changed, 446 insertions(+), 446 deletions(-) >>>> >>>> diff --git a/drivers/pinctrl/pinctrl-imx51.c >>>> b/drivers/pinctrl/pinctrl-imx51.c >>>> index 9fd0216..fb84689 100644 >>>> --- a/drivers/pinctrl/pinctrl-imx51.c >>>> +++ b/drivers/pinctrl/pinctrl-imx51.c >>>> @@ -23,251 +23,251 @@ >>>> #include "pinctrl-imx.h" >>>> enum imx51_pads { >>>> - MX51_PAD_EIM_D16 = 1, >>>> - MX51_PAD_EIM_D17 = 2, >> >> ... >>>> >>>> + MX53_PAD_GPIO_19 = 0, >>>> + MX53_PAD_KEY_COL0 = 1, >>> >>> >>> Why not skip the = xx altogether?? The enum will auto-increment. >> >> Personally i'd like to keep it. >> The reason is that pin id is basic property of a pin per pinctrl >> subsystem's design >> so explicitly define it looks more clear to me and i'm not sure but >> it's possible that >> the pin id may be used in device tree in the future(maybe some other >> soc already uses it), >> And defining it has no big harming. >> >> Regards >> Dong Aisheng >> . >> > Then maybe #defines should be used, so that device tree can include this > file and be run through C pre-processor? > Maybe one day device tree supports include c headfile, we can do like that. Regards Dong Aisheng
Hello, (Cc += devicetree-discuss@lists.ozlabs.org) On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote: > On 15 August 2012 03:37, Matt Sealey <matt@genesi-usa.com> wrote: > > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: > >> On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: > >>> 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*. > > > 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. > > > 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. > > > 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. > > > 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. > > > 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. Best regards Uwe
On Wed, Aug 15, 2012 at 07:44:36AM +0200, Uwe Kleine-König wrote: > Hello, > > (Cc += devicetree-discuss@lists.ozlabs.org) > > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote: > > On 15 August 2012 03:37, Matt Sealey <matt@genesi-usa.com> wrote: > > > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: > > >> On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: > > >>> 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*. > > > > > 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. > > > > > 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. > > > > > 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. > > > > > 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. > > > > > 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. > 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. > 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. Regards Dong Aisheng
Hello, On Wed, Aug 15, 2012 at 02:55:27PM +0800, Dong Aisheng wrote: > On Wed, Aug 15, 2012 at 07:44:36AM +0200, Uwe Kleine-König wrote: > > Hello, > > > > (Cc += devicetree-discuss@lists.ozlabs.org) > > > > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote: > > > On 15 August 2012 03:37, Matt Sealey <matt@genesi-usa.com> wrote: > > > > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: > > > >> On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: > > > >>> 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*. > > > > > > > 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. > > > > > > > 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. > > > > > > > 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. > > > > > > > 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. > > > > > > > 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. > > > 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. > > 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. > 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. > 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.) Best regards Uwe
On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-König wrote: > Hello, > > On Wed, Aug 15, 2012 at 02:55:27PM +0800, Dong Aisheng wrote: > > On Wed, Aug 15, 2012 at 07:44:36AM +0200, Uwe Kleine-König wrote: > > > Hello, > > > > > > (Cc += devicetree-discuss@lists.ozlabs.org) > > > > > > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote: > > > > On 15 August 2012 03:37, Matt Sealey <matt@genesi-usa.com> wrote: > > > > > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: > > > > >> On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: > > > > >>> 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*. > > > > > > > > > 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. > > > > > > > > > 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. > > > > > > > > > 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. > > > > > > > > > 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. > > > > > > > > > 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. > > > > > 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. > For such case, we should add it to the end since the exist ids are already taken. It will not break any user. > > > 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. > > > 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. > > > 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.) > 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
On 15 August 2012 17:25, Dong Aisheng <b29396@freescale.com> wrote: > On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-König wrote: >> Hello, >> >> On Wed, Aug 15, 2012 at 02:55:27PM +0800, Dong Aisheng wrote: >> > On Wed, Aug 15, 2012 at 07:44:36AM +0200, Uwe Kleine-König wrote: >> > > Hello, >> > > >> > > (Cc += devicetree-discuss@lists.ozlabs.org) >> > > >> > > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote: >> > > > On 15 August 2012 03:37, Matt Sealey <matt@genesi-usa.com> wrote: >> > > > > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng@linaro.org> wrote: >> > > > >> On 13 August 2012 23:12, Matt Sealey <matt@genesi-usa.com> wrote: >> > > > >>> 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*. >> > > > > >> > > > 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. >> > > > >> > > > > 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. >> > > > >> > > > > 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. >> > > > >> > > > > 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. >> > > > > >> > > > 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. >> > > >> > 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. >> > For such case, we should add it to the end since the exist ids are already > taken. It will not break any user. > >> > > 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. >> >> > 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. >> >> > 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.) >> > 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? > Sorry, forget to add Grant. Cc Grant. Regards Dong Aisheng > 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 >
On Wed, Aug 15, 2012 at 05:25:40PM +0800, Dong Aisheng wrote: > On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-König wrote: > > 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.) > > > 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. > 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? > 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. > 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: > On Wed, Aug 15, 2012 at 05:25:40PM +0800, Dong Aisheng wrote: > > On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-König wrote: > > > 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.) > > > > > 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. > Rather than betting how DTC will implement macro, we'd better make the the safest assumption - it will not support that syntax. But we can 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. > > 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? > So PIN_NO_MUX_ID_BASE will be: the largest mux_reg_offset / 4 + 1, right?
On 08/15/2012 07:59 AM, Shawn Guo wrote: > On Wed, Aug 15, 2012 at 05:25:40PM +0800, Dong Aisheng wrote: >> On Wed, Aug 15, 2012 at 03:51:17PM +0800, Uwe Kleine-König wrote: >>> 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.) >>> >> 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. You mean like C pre-processor on .dts files? There's currently no support for anything like that at all, with either syntax above. I honestly don't know if/when there will be.
On Wed, Aug 15, 2012 at 10:31 AM, Shawn Guo <shawn.guo@linaro.org> wrote: > On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote: >> On Wed, Aug 15, 2012 at 05:25:40PM +0800, Dong Aisheng wrote: >> > 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, >> > >> > 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. 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. > 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. Absolutely! > 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. Or 3 pairs of values can encode them. Don't needlessly encode data in the device tree that can just exist in a cell of a property. > That said, the line below in binding doc > > MX35_PAD_COMPARE__SDMA_EXTDMA_2 11 > > becomes > > MX35_PAD_COMPARE__SDMA_EXTDMA_2 0x032c000807000000 I can only give a quick example on MX51, MX53 or MX6 since that's my experience, but essentially.. you're overthinking it. What it becomes is iomuxc@0x73f08000 { fsl,iomux-pins = <mux value ctrl value ipp value /* MX53_PIN_SD4_CMD__SD4_CMD */ mux value ctrl value ipp value /* etc. */ ...>; You can encode those values *in the driver* as a hash or lookup to get names for them if you like in the driver.. or build them at runtime for truly odd combinations or not-usual pin configurations. In any case, those reg can be "valid" 0 since 0 is IOMUXC_GPR0.. which you do not want to set. That said, setting IOMUXC_GPR can be useful! Ethernet may need (on MX6 examples) ENET_CLK_SEL set, IPU may need to select MIPI gasket or IOMUX. Usually though I would assume that you would have properties for these though as you do not want to "trash" bootloader configuration of any clock or mux settings, just update them (so, fsl,ethernet-clock-sel =1 or fsl,ipu-iomux = <1 0>) That said, the usual thing is to set them to "-1" explicitly in the tree and let the DT code sort out what -1 actually means (usually 0xffffffff since by default OF cells are 32-bit, but it's the same difference if it's a 64-bit device tree binding) since this is totally invalid. That way a pin with no ctrl or ipp, or ctrl but no ipp or mux would be fsl,iomux-pin = <-1 -1 0x05c 0x85 -1 -1 ...>; > 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. As above. Please do not encode the data. Don't assume you can encode a 64-bit integer either.. that's not in any core binding. What you need here is a multi-cell property as above. That way it can be expanded if MX7 has an extra iomux register set for something else ("enable awesome mode" or so). >> 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? Nope. It should be -1. Do it properly, please. Do not "hack" numbers, as this can mean the driver has to intimately know the hardware when it is needless to do so. The driver MAY however assume that IOMUXC_BASE_ADDR + 0xffffffff is not really possible - check the offset generated and if it goes beyond the reg = <start length> range, it is obviously invalid. Or just check the offset against the length.. walking into unmapped memory invalid is invalid across the board. One thing though, I don't understand why Dong thinks it would be more difficult to look up a register number in the docs (PDF search, Dong, it's easy!) versus looking up the binding number in the binding document. These pairs are ALREADY encoded in older kernels too in that 64 bit integer. Just split them back out again (there's code in iomux-v3.h to do this still in the kernel) and you can encode your device tree. Including headers, macros is unecessary. You may want to petition Freescale to create a plugin for their IOMUX tool though that not only spits out the reg/pair values in C source format (this is very useful, though, since you can paste it into anything that can use writel() to set up all pins exactly as your board designer dictated), but also does it in device-tree binding pairs as above. That would make it a lot easier all round, too.. nobody needs to look up a binding, the binding is "fsl,iomux-pins defines pairs of offsets and values inside the IOMUXC unit. These offsets and values are defined in the manual. <some examples here>"
On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote: ... > > 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? Linus, Stephen, Any comment on it? 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. Regards Dong Aisheng
On Wed, Aug 15, 2012 at 11:49:01AM -0500, Matt Sealey wrote: > > 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. > 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. <snip> > iomuxc@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.
On Wed, Aug 15, 2012 at 10:45 PM, Shawn Guo <shawn.guo@linaro.org> wrote: > On Wed, Aug 15, 2012 at 11:49:01AM -0500, Matt Sealey wrote: >> > 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. I'm not sure you'd want a "programmable" device tree that expanded itself out using macros. Just imagine what one tiny mistake in syntax could do - stop a board from booting, for example. You never ran into this on real OF, you never needed it, why would precompiled DTs need it? >> iomuxc@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. And indeed, I don't see how this could possibly be a bad thing when multiple boards can share such a binding and ease device tree generation by making it a task of "cross reference the manual" or "read the automated tool output and copy it to the device tree". So the name changes to something non-fsl-specific or something and all the boards that support it this way can enable it this way, job done, common binding for multiple systems? Side nit: how do you propose in the device tree to enable certain bits in certain IOMUXC registers on MX6 or so? The current solution where pinctrl holds IOMUXC to ransom (it ioremaps the register set until _remove) is fine for now, but what if I want to change my ENET_CLK_CTL or MIPI_IPU1_MUX or USB_OTG_ID or OCRAM pipeline control bits in IOMUXC_GPRn for correct board operation? Is this a bootloader responsibility or device tree? It seems odd to make pad mux and control a device tree job, but internal path or unit setup a bootloader job. If we're doing this to configure the correct internal paths in the SoC, the "correct" place might be in the ethernet@ node, or ipu-csi@ node as they define the operation and paths of these units, but they would be better served to be defined at the pinctrl level and not at the unit, since pinctrl "owns" IOMUXC. But having iomuxc@foo contain a lot of very strange internal path definitions seems too odd and cluttered. In this case, pinctrl-imx implementation is too generic in claiming this entire unit for the purpose. Probably what needs to be done is fsl,imx6q-iomuxc gets claimed by an MFD which allows setting these feature bits, and pinctrl simply depends on it to implement a pinctrl@ node underneath it (like regulators are done now). As for requiring drivers to fetch and use pinctrl data without possibility of dummies to allow it to "fail gracefully", I would say pinctrl in i.MX drivers at least should not be a requirement - by all means, search for the pin definitions, instruct pinctrl to perform these operations, but if it does not find a compatible property.. carry on regardless, maybe with a warning that you MUST have trusted your bootloader. Or define a linux,pinctrl-already-done property (this would be useful for MX51 uart1 which is muxed to ALT0 by default, so pinctrl needn't bother doing anything - it was always there and always correctly configured from mask rom time up to Linux anyway..) and as such we can omit the warning and just carry on regardless.
On Wed, Aug 15, 2012 at 10:30 PM, Dong Aisheng <b29396@freescale.com> wrote: > On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote: > ... >> > 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. Why not? It only needs to "manage" the ones the DT defines or the ones you specify. The rest of the data is there as a convenience for debug and naming of pins, a cross-reference that could be compiled out for non-debug kernels since there's not a lot of point wasting 64kb or possibly more of memory on naming every pin on the chip statically. The name of the pad is in pin_desc and can be marked dynamic (a small function at get_pin_desc can work out the string and vsprintf the correct string, and put_pin_desc can free it again). The name of the groups/configs etc. is also dynamic, no? > Because for the way proposed, all the pin's basic properties like mux_reg, config_reg > are parsed from device tree at runtime. The ones you want to perform anyway. > If a pin is not used in device tree, the driver can not know this pin's > corresponding registers. It would. I'm not saying get rid of the table, just remove the redundancy - if you don't reference pins by "arbitrary id" anymore, why include an arbitrary id? At the moment you've got a redundant list of enums to define offsets into an array which is.. an array anyway. You can always work out the position in the array from it's address and the structure size (offsetof or some clever math). If you're not referencing the pin by index into the array anyway which is bad behavior, the other data serves as cross-reference - the register offsets defined are unique to the pin in question. So the enums go away, and the first element of imx_pin_reg goes away. The rest is just debug data. The static pinctrl_pin_desc array can go away as well. As it stands it's a waste of memory - MX6Q_PAD_ in every string cannot be merged by the compiler, that's 329 multiplied 9 bytes you're compiling into the kernel redundantly. The name can be referenced - I'm gonna use MX6Q_PAD_SD4_CMD__SD4_CMD as an example here to reduce confusion. > Then imx_pinconf_dbg_show in current driver may need change since it does not > support show all pins's config value. You will need the huge static array to cross-reference the pins canonical name and generated configuration, sure, I don't want to remove it, just.. not use array index to reference it from the device tree. If you imagine building a string like "MX6Q_PAD_" "SD4_CMD" "__" "SD4_CMD" - this is defined by the SoC in use and the DT binding, the default pad name from the docs, a couple underscores to match the old iomux-v3 definition which we are still clinging on to (and should since this is what's used in U-Boot right now) and the ALT mode from the MUX_MODE bits. The enum id can be replaced with a pin name string pointer "SD4_CMD" which is static per pin. The imx_pin_reg struct would become struct imx_pin_reg { const char *pad_name; u32 mux_reg; u32 ctl_reg; u32 ipp_reg; const char *mux_modes; u32 nmodes; }; This can be used to build strings for debug. You're not using much more space than the existing model, and the array contains strings defining the last part of the debug string representing the alt mode - saving a little bit of memory besides. And of course, it's not needed to actually perform the muxing since that's just adding register offsets to bases and writel() a value direct from the DT (although, imx_pin_reg could be used to verify that the 3 pairs correspond to each other...) And you'd need strings to define the CTL settings like HYS, ODE, PKE, PUE settings from the registers and give them human readable names as per the device tree binding, as they were set, but this is not in the imx_pin_regs array (or maybe it is, someone should put all the default pad settings in there?). Build the string like you want and you reproduce the naming in the comments. Some other debug data needs to be exposed to define the bits in the register as above, which isn't done right now. As such the debug currently isn't so useful - it only describes the pad itself, the MUX_MODE in an i.MX IOMUXC and the rest of the information is lost since it does not take into account the pad control itself. This is lucky as it's less work for now. > If it supports, will imx driver also support config unused pins in devicetree > via sysfs? Setting up the stuff from the device tree wouldn't involve the imx_pin_reg array so you could compile the whole thing out if you didn't want the space usage or the chattiness of debug logs. > Probably it may be rarely used and imx just does not support it. > Then we can get register data from devicetree.
On 08/15/2012 09:30 PM, Dong Aisheng wrote: > On Wed, Aug 15, 2012 at 09:59:50PM +0800, Shawn Guo wrote: > ... >>> 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. Hmmm. Given we support all pin mux/config options from the mapping table, I'd question whether that API should even exist any more... > Then imx_pinconf_dbg_show in current driver may need change since it does not > support show all pins's config value. The pinctrl core assumes that the pin numbering space could be sparse. For example, see that pinconf.c:pinconf_pins_show() "continues" the loop if pin_desc_get() fails for a particular pin number. So just based on what I've read in this one email, I think this is fine. > 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.
On Thu, Aug 16, 2012 at 5:30 AM, Dong Aisheng <b29396@freescale.com> wrote: > 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. The U300 driver has *lots* of pins it cannot manage. I have no strong opinions on this, often if there are lots of pins and say some ranges here and there are controllable, you may want to register them all (with names) just so that you can get something intuitive out of the pin numbers. But the descriptors are actually sparse, so you don't have to have a consecutive pin range and can actually just register the pins you want with the names you want. It's your pick... > 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? Not sysfs. For GPIO this ended up in a bad place. Maybe /dev/pinctrl0, /dev/pinctrl1 But I don't think we want to expose individual pin configs to userspace. Maybe pinctrl states. Dunno, has to be designed, and surely pins can be totally numb and unconfigurable as well.... > If it supports, will imx driver also support config unused pins in devicetree > via sysfs? DT *or* /dev/foo I guess. Yours, Linus Walleij
On Thu, Aug 16, 2012 at 11:12 PM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 08/15/2012 09:30 PM, Dong Aisheng wrote: >> 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... If there are no in-kernel users we can delete it. But I can surely see things like PCI lab boards etc wanting to have full control over pins from userspace, just like they can hammer GPIO's on/off today from userspace (i.e. embedded SoCs is not the only use case) so I wouldn't rule it out. I think this use case is quite real for automatic control, robotics, factory lines... those guys do use GPIO sysfs like that already today. >> 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. sysfs over my dead body ... but exposing pin names to userspace is another thing, and might be interesting, in case we want to just sort of list all pins on the system from some command line tool or HW-info control panel. But that requires designing the userspace device interface first, so no need to haste. Yours, Linus Walleij
diff --git a/drivers/pinctrl/pinctrl-imx51.c b/drivers/pinctrl/pinctrl-imx51.c index 9fd0216..fb84689 100644 --- a/drivers/pinctrl/pinctrl-imx51.c +++ b/drivers/pinctrl/pinctrl-imx51.c @@ -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 */ diff --git a/drivers/pinctrl/pinctrl-imx53.c b/drivers/pinctrl/pinctrl-imx53.c index 1f49e16..783feb1 100644 --- a/drivers/pinctrl/pinctrl-imx53.c +++ b/drivers/pinctrl/pinctrl-imx53.c @@ -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 */
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 <shawn.guo@linaro.org> --- drivers/pinctrl/pinctrl-imx51.c | 490 +++++++++++++++++++------------------- drivers/pinctrl/pinctrl-imx53.c | 402 ++++++++++++++++---------------- 2 files changed, 446 insertions(+), 446 deletions(-)