* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-13 14:47 Shawn Guo
2012-08-13 15:12 ` Matt Sealey
` (3 more replies)
0 siblings, 4 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-13 14:47 UTC (permalink / raw)
To: linux-arm-kernel
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,
+ MX53_PAD_KEY_ROW0 = 2,
+ MX53_PAD_KEY_COL1 = 3,
+ MX53_PAD_KEY_ROW1 = 4,
+ MX53_PAD_KEY_COL2 = 5,
+ MX53_PAD_KEY_ROW2 = 6,
+ MX53_PAD_KEY_COL3 = 7,
+ MX53_PAD_KEY_ROW3 = 8,
+ MX53_PAD_KEY_COL4 = 9,
+ MX53_PAD_KEY_ROW4 = 10,
+ MX53_PAD_DI0_DISP_CLK = 11,
+ MX53_PAD_DI0_PIN15 = 12,
+ MX53_PAD_DI0_PIN2 = 13,
+ MX53_PAD_DI0_PIN3 = 14,
+ MX53_PAD_DI0_PIN4 = 15,
+ MX53_PAD_DISP0_DAT0 = 16,
+ MX53_PAD_DISP0_DAT1 = 17,
+ MX53_PAD_DISP0_DAT2 = 18,
+ MX53_PAD_DISP0_DAT3 = 19,
+ MX53_PAD_DISP0_DAT4 = 20,
+ MX53_PAD_DISP0_DAT5 = 21,
+ MX53_PAD_DISP0_DAT6 = 22,
+ MX53_PAD_DISP0_DAT7 = 23,
+ MX53_PAD_DISP0_DAT8 = 24,
+ MX53_PAD_DISP0_DAT9 = 25,
+ MX53_PAD_DISP0_DAT10 = 26,
+ MX53_PAD_DISP0_DAT11 = 27,
+ MX53_PAD_DISP0_DAT12 = 28,
+ MX53_PAD_DISP0_DAT13 = 29,
+ MX53_PAD_DISP0_DAT14 = 30,
+ MX53_PAD_DISP0_DAT15 = 31,
+ MX53_PAD_DISP0_DAT16 = 32,
+ MX53_PAD_DISP0_DAT17 = 33,
+ MX53_PAD_DISP0_DAT18 = 34,
+ MX53_PAD_DISP0_DAT19 = 35,
+ MX53_PAD_DISP0_DAT20 = 36,
+ MX53_PAD_DISP0_DAT21 = 37,
+ MX53_PAD_DISP0_DAT22 = 38,
+ MX53_PAD_DISP0_DAT23 = 39,
+ MX53_PAD_CSI0_PIXCLK = 40,
+ MX53_PAD_CSI0_MCLK = 41,
+ MX53_PAD_CSI0_DATA_EN = 42,
+ MX53_PAD_CSI0_VSYNC = 43,
+ MX53_PAD_CSI0_DAT4 = 44,
+ MX53_PAD_CSI0_DAT5 = 45,
+ MX53_PAD_CSI0_DAT6 = 46,
+ MX53_PAD_CSI0_DAT7 = 47,
+ MX53_PAD_CSI0_DAT8 = 48,
+ MX53_PAD_CSI0_DAT9 = 49,
+ MX53_PAD_CSI0_DAT10 = 50,
+ MX53_PAD_CSI0_DAT11 = 51,
+ MX53_PAD_CSI0_DAT12 = 52,
+ MX53_PAD_CSI0_DAT13 = 53,
+ MX53_PAD_CSI0_DAT14 = 54,
+ MX53_PAD_CSI0_DAT15 = 55,
+ MX53_PAD_CSI0_DAT16 = 56,
+ MX53_PAD_CSI0_DAT17 = 57,
+ MX53_PAD_CSI0_DAT18 = 58,
+ MX53_PAD_CSI0_DAT19 = 59,
+ MX53_PAD_EIM_A25 = 60,
+ MX53_PAD_EIM_EB2 = 61,
+ MX53_PAD_EIM_D16 = 62,
+ MX53_PAD_EIM_D17 = 63,
+ MX53_PAD_EIM_D18 = 64,
+ MX53_PAD_EIM_D19 = 65,
+ MX53_PAD_EIM_D20 = 66,
+ MX53_PAD_EIM_D21 = 67,
+ MX53_PAD_EIM_D22 = 68,
+ MX53_PAD_EIM_D23 = 69,
+ MX53_PAD_EIM_EB3 = 70,
+ MX53_PAD_EIM_D24 = 71,
+ MX53_PAD_EIM_D25 = 72,
+ MX53_PAD_EIM_D26 = 73,
+ MX53_PAD_EIM_D27 = 74,
+ MX53_PAD_EIM_D28 = 75,
+ MX53_PAD_EIM_D29 = 76,
+ MX53_PAD_EIM_D30 = 77,
+ MX53_PAD_EIM_D31 = 78,
+ MX53_PAD_EIM_A24 = 79,
+ MX53_PAD_EIM_A23 = 80,
+ MX53_PAD_EIM_A22 = 81,
+ MX53_PAD_EIM_A21 = 82,
+ MX53_PAD_EIM_A20 = 83,
+ MX53_PAD_EIM_A19 = 84,
+ MX53_PAD_EIM_A18 = 85,
+ MX53_PAD_EIM_A17 = 86,
+ MX53_PAD_EIM_A16 = 87,
+ MX53_PAD_EIM_CS0 = 88,
+ MX53_PAD_EIM_CS1 = 89,
+ MX53_PAD_EIM_OE = 90,
+ MX53_PAD_EIM_RW = 91,
+ MX53_PAD_EIM_LBA = 92,
+ MX53_PAD_EIM_EB0 = 93,
+ MX53_PAD_EIM_EB1 = 94,
+ MX53_PAD_EIM_DA0 = 95,
+ MX53_PAD_EIM_DA1 = 96,
+ MX53_PAD_EIM_DA2 = 97,
+ MX53_PAD_EIM_DA3 = 98,
+ MX53_PAD_EIM_DA4 = 99,
+ MX53_PAD_EIM_DA5 = 100,
+ MX53_PAD_EIM_DA6 = 101,
+ MX53_PAD_EIM_DA7 = 102,
+ MX53_PAD_EIM_DA8 = 103,
+ MX53_PAD_EIM_DA9 = 104,
+ MX53_PAD_EIM_DA10 = 105,
+ MX53_PAD_EIM_DA11 = 106,
+ MX53_PAD_EIM_DA12 = 107,
+ MX53_PAD_EIM_DA13 = 108,
+ MX53_PAD_EIM_DA14 = 109,
+ MX53_PAD_EIM_DA15 = 110,
+ MX53_PAD_NANDF_WE_B = 111,
+ MX53_PAD_NANDF_RE_B = 112,
+ MX53_PAD_EIM_WAIT = 113,
+ MX53_PAD_LVDS1_TX3_P = 114,
+ MX53_PAD_LVDS1_TX2_P = 115,
+ MX53_PAD_LVDS1_CLK_P = 116,
+ MX53_PAD_LVDS1_TX1_P = 117,
+ MX53_PAD_LVDS1_TX0_P = 118,
+ MX53_PAD_LVDS0_TX3_P = 119,
+ MX53_PAD_LVDS0_CLK_P = 120,
+ MX53_PAD_LVDS0_TX2_P = 121,
+ MX53_PAD_LVDS0_TX1_P = 122,
+ MX53_PAD_LVDS0_TX0_P = 123,
+ MX53_PAD_GPIO_10 = 124,
+ MX53_PAD_GPIO_11 = 125,
+ MX53_PAD_GPIO_12 = 126,
+ MX53_PAD_GPIO_13 = 127,
+ MX53_PAD_GPIO_14 = 128,
+ MX53_PAD_NANDF_CLE = 129,
+ MX53_PAD_NANDF_ALE = 130,
+ MX53_PAD_NANDF_WP_B = 131,
+ MX53_PAD_NANDF_RB0 = 132,
+ MX53_PAD_NANDF_CS0 = 133,
+ MX53_PAD_NANDF_CS1 = 134,
+ MX53_PAD_NANDF_CS2 = 135,
+ MX53_PAD_NANDF_CS3 = 136,
+ MX53_PAD_FEC_MDIO = 137,
+ MX53_PAD_FEC_REF_CLK = 138,
+ MX53_PAD_FEC_RX_ER = 139,
+ MX53_PAD_FEC_CRS_DV = 140,
+ MX53_PAD_FEC_RXD1 = 141,
+ MX53_PAD_FEC_RXD0 = 142,
+ MX53_PAD_FEC_TX_EN = 143,
+ MX53_PAD_FEC_TXD1 = 144,
+ MX53_PAD_FEC_TXD0 = 145,
+ MX53_PAD_FEC_MDC = 146,
+ MX53_PAD_PATA_DIOW = 147,
+ MX53_PAD_PATA_DMACK = 148,
+ MX53_PAD_PATA_DMARQ = 149,
+ MX53_PAD_PATA_BUFFER_EN = 150,
+ MX53_PAD_PATA_INTRQ = 151,
+ MX53_PAD_PATA_DIOR = 152,
+ MX53_PAD_PATA_RESET_B = 153,
+ MX53_PAD_PATA_IORDY = 154,
+ MX53_PAD_PATA_DA_0 = 155,
+ MX53_PAD_PATA_DA_1 = 156,
+ MX53_PAD_PATA_DA_2 = 157,
+ MX53_PAD_PATA_CS_0 = 158,
+ MX53_PAD_PATA_CS_1 = 159,
+ MX53_PAD_PATA_DATA0 = 160,
+ MX53_PAD_PATA_DATA1 = 161,
+ MX53_PAD_PATA_DATA2 = 162,
+ MX53_PAD_PATA_DATA3 = 163,
+ MX53_PAD_PATA_DATA4 = 164,
+ MX53_PAD_PATA_DATA5 = 165,
+ MX53_PAD_PATA_DATA6 = 166,
+ MX53_PAD_PATA_DATA7 = 167,
+ MX53_PAD_PATA_DATA8 = 168,
+ MX53_PAD_PATA_DATA9 = 169,
+ MX53_PAD_PATA_DATA10 = 170,
+ MX53_PAD_PATA_DATA11 = 171,
+ MX53_PAD_PATA_DATA12 = 172,
+ MX53_PAD_PATA_DATA13 = 173,
+ MX53_PAD_PATA_DATA14 = 174,
+ MX53_PAD_PATA_DATA15 = 175,
+ MX53_PAD_SD1_DATA0 = 176,
+ MX53_PAD_SD1_DATA1 = 177,
+ MX53_PAD_SD1_CMD = 178,
+ MX53_PAD_SD1_DATA2 = 179,
+ MX53_PAD_SD1_CLK = 180,
+ MX53_PAD_SD1_DATA3 = 181,
+ MX53_PAD_SD2_CLK = 182,
+ MX53_PAD_SD2_CMD = 183,
+ MX53_PAD_SD2_DATA3 = 184,
+ MX53_PAD_SD2_DATA2 = 185,
+ MX53_PAD_SD2_DATA1 = 186,
+ MX53_PAD_SD2_DATA0 = 187,
+ MX53_PAD_GPIO_0 = 188,
+ MX53_PAD_GPIO_1 = 189,
+ MX53_PAD_GPIO_9 = 190,
+ MX53_PAD_GPIO_3 = 191,
+ MX53_PAD_GPIO_6 = 192,
+ MX53_PAD_GPIO_2 = 193,
+ MX53_PAD_GPIO_4 = 194,
+ MX53_PAD_GPIO_5 = 195,
+ MX53_PAD_GPIO_7 = 196,
+ MX53_PAD_GPIO_8 = 197,
+ MX53_PAD_GPIO_16 = 198,
+ MX53_PAD_GPIO_17 = 199,
+ MX53_PAD_GPIO_18 = 200,
};
/* imx53 register maps */
--
1.7.5.4
^ permalink raw reply related [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-13 14:47 [PATCH] pinctrl: imx5: start numbering pad from 0 Shawn Guo
@ 2012-08-13 15:12 ` Matt Sealey
2012-08-14 7:20 ` Dong Aisheng
2012-08-13 19:26 ` Troy Kisky
` (2 subsequent siblings)
3 siblings, 1 reply; 45+ messages in thread
From: Matt Sealey @ 2012-08-13 15:12 UTC (permalink / raw)
To: linux-arm-kernel
I have a minor nit; while renumbering the pinctrl definitions is
laudable and device trees can match, there are 16 other pin controls
below EIM_D16 - this makes the start of the IOMUXC pin definitions
actually be the value calculated by (iomuxc_base + 0x300 + (4*16) +
(pin_id*4)).
While this works, it's fine, but it would be more reasonable/correct
to number pin indices from the first configurable pad and not by a
hardcoded magic offset into the base. The EIM_DA* pins below the
current EIM_D16 are only configurable as CoreSight trace signals but
it would save trouble later if anyone wanted to use these for example
on a prototype board configured as those trace pads if they didn't
have to renumber all the pins again. Nobody currently uses them in the
tree but it makes more sense to me to count from the first
configurable pad, than the first currently-used-in-the-tree
configurable pad.
Therefore I propose;
* add MX51_PAD_EIM_DA0 through DA15 as index 0-15 (same for any
differences in other i.MX etc.)
* move all the pin indices currently defined up by 16 for MX51 (same for above)
* _then_ renumber the current device trees..
That way churn is minimized in the future and we don't end up changing
trees and definitions again in the future in the event that someone
DOES want to use those pads in a shippable product with mainline Linux
support (and sees fit to enable TPIU_TRACE_EN for some reason and has
the hardware to use it).
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
On Mon, Aug 13, 2012 at 9:47 AM, 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>
> ---
> 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,
> + MX53_PAD_KEY_ROW0 = 2,
> + MX53_PAD_KEY_COL1 = 3,
> + MX53_PAD_KEY_ROW1 = 4,
> + MX53_PAD_KEY_COL2 = 5,
> + MX53_PAD_KEY_ROW2 = 6,
> + MX53_PAD_KEY_COL3 = 7,
> + MX53_PAD_KEY_ROW3 = 8,
> + MX53_PAD_KEY_COL4 = 9,
> + MX53_PAD_KEY_ROW4 = 10,
> + MX53_PAD_DI0_DISP_CLK = 11,
> + MX53_PAD_DI0_PIN15 = 12,
> + MX53_PAD_DI0_PIN2 = 13,
> + MX53_PAD_DI0_PIN3 = 14,
> + MX53_PAD_DI0_PIN4 = 15,
> + MX53_PAD_DISP0_DAT0 = 16,
> + MX53_PAD_DISP0_DAT1 = 17,
> + MX53_PAD_DISP0_DAT2 = 18,
> + MX53_PAD_DISP0_DAT3 = 19,
> + MX53_PAD_DISP0_DAT4 = 20,
> + MX53_PAD_DISP0_DAT5 = 21,
> + MX53_PAD_DISP0_DAT6 = 22,
> + MX53_PAD_DISP0_DAT7 = 23,
> + MX53_PAD_DISP0_DAT8 = 24,
> + MX53_PAD_DISP0_DAT9 = 25,
> + MX53_PAD_DISP0_DAT10 = 26,
> + MX53_PAD_DISP0_DAT11 = 27,
> + MX53_PAD_DISP0_DAT12 = 28,
> + MX53_PAD_DISP0_DAT13 = 29,
> + MX53_PAD_DISP0_DAT14 = 30,
> + MX53_PAD_DISP0_DAT15 = 31,
> + MX53_PAD_DISP0_DAT16 = 32,
> + MX53_PAD_DISP0_DAT17 = 33,
> + MX53_PAD_DISP0_DAT18 = 34,
> + MX53_PAD_DISP0_DAT19 = 35,
> + MX53_PAD_DISP0_DAT20 = 36,
> + MX53_PAD_DISP0_DAT21 = 37,
> + MX53_PAD_DISP0_DAT22 = 38,
> + MX53_PAD_DISP0_DAT23 = 39,
> + MX53_PAD_CSI0_PIXCLK = 40,
> + MX53_PAD_CSI0_MCLK = 41,
> + MX53_PAD_CSI0_DATA_EN = 42,
> + MX53_PAD_CSI0_VSYNC = 43,
> + MX53_PAD_CSI0_DAT4 = 44,
> + MX53_PAD_CSI0_DAT5 = 45,
> + MX53_PAD_CSI0_DAT6 = 46,
> + MX53_PAD_CSI0_DAT7 = 47,
> + MX53_PAD_CSI0_DAT8 = 48,
> + MX53_PAD_CSI0_DAT9 = 49,
> + MX53_PAD_CSI0_DAT10 = 50,
> + MX53_PAD_CSI0_DAT11 = 51,
> + MX53_PAD_CSI0_DAT12 = 52,
> + MX53_PAD_CSI0_DAT13 = 53,
> + MX53_PAD_CSI0_DAT14 = 54,
> + MX53_PAD_CSI0_DAT15 = 55,
> + MX53_PAD_CSI0_DAT16 = 56,
> + MX53_PAD_CSI0_DAT17 = 57,
> + MX53_PAD_CSI0_DAT18 = 58,
> + MX53_PAD_CSI0_DAT19 = 59,
> + MX53_PAD_EIM_A25 = 60,
> + MX53_PAD_EIM_EB2 = 61,
> + MX53_PAD_EIM_D16 = 62,
> + MX53_PAD_EIM_D17 = 63,
> + MX53_PAD_EIM_D18 = 64,
> + MX53_PAD_EIM_D19 = 65,
> + MX53_PAD_EIM_D20 = 66,
> + MX53_PAD_EIM_D21 = 67,
> + MX53_PAD_EIM_D22 = 68,
> + MX53_PAD_EIM_D23 = 69,
> + MX53_PAD_EIM_EB3 = 70,
> + MX53_PAD_EIM_D24 = 71,
> + MX53_PAD_EIM_D25 = 72,
> + MX53_PAD_EIM_D26 = 73,
> + MX53_PAD_EIM_D27 = 74,
> + MX53_PAD_EIM_D28 = 75,
> + MX53_PAD_EIM_D29 = 76,
> + MX53_PAD_EIM_D30 = 77,
> + MX53_PAD_EIM_D31 = 78,
> + MX53_PAD_EIM_A24 = 79,
> + MX53_PAD_EIM_A23 = 80,
> + MX53_PAD_EIM_A22 = 81,
> + MX53_PAD_EIM_A21 = 82,
> + MX53_PAD_EIM_A20 = 83,
> + MX53_PAD_EIM_A19 = 84,
> + MX53_PAD_EIM_A18 = 85,
> + MX53_PAD_EIM_A17 = 86,
> + MX53_PAD_EIM_A16 = 87,
> + MX53_PAD_EIM_CS0 = 88,
> + MX53_PAD_EIM_CS1 = 89,
> + MX53_PAD_EIM_OE = 90,
> + MX53_PAD_EIM_RW = 91,
> + MX53_PAD_EIM_LBA = 92,
> + MX53_PAD_EIM_EB0 = 93,
> + MX53_PAD_EIM_EB1 = 94,
> + MX53_PAD_EIM_DA0 = 95,
> + MX53_PAD_EIM_DA1 = 96,
> + MX53_PAD_EIM_DA2 = 97,
> + MX53_PAD_EIM_DA3 = 98,
> + MX53_PAD_EIM_DA4 = 99,
> + MX53_PAD_EIM_DA5 = 100,
> + MX53_PAD_EIM_DA6 = 101,
> + MX53_PAD_EIM_DA7 = 102,
> + MX53_PAD_EIM_DA8 = 103,
> + MX53_PAD_EIM_DA9 = 104,
> + MX53_PAD_EIM_DA10 = 105,
> + MX53_PAD_EIM_DA11 = 106,
> + MX53_PAD_EIM_DA12 = 107,
> + MX53_PAD_EIM_DA13 = 108,
> + MX53_PAD_EIM_DA14 = 109,
> + MX53_PAD_EIM_DA15 = 110,
> + MX53_PAD_NANDF_WE_B = 111,
> + MX53_PAD_NANDF_RE_B = 112,
> + MX53_PAD_EIM_WAIT = 113,
> + MX53_PAD_LVDS1_TX3_P = 114,
> + MX53_PAD_LVDS1_TX2_P = 115,
> + MX53_PAD_LVDS1_CLK_P = 116,
> + MX53_PAD_LVDS1_TX1_P = 117,
> + MX53_PAD_LVDS1_TX0_P = 118,
> + MX53_PAD_LVDS0_TX3_P = 119,
> + MX53_PAD_LVDS0_CLK_P = 120,
> + MX53_PAD_LVDS0_TX2_P = 121,
> + MX53_PAD_LVDS0_TX1_P = 122,
> + MX53_PAD_LVDS0_TX0_P = 123,
> + MX53_PAD_GPIO_10 = 124,
> + MX53_PAD_GPIO_11 = 125,
> + MX53_PAD_GPIO_12 = 126,
> + MX53_PAD_GPIO_13 = 127,
> + MX53_PAD_GPIO_14 = 128,
> + MX53_PAD_NANDF_CLE = 129,
> + MX53_PAD_NANDF_ALE = 130,
> + MX53_PAD_NANDF_WP_B = 131,
> + MX53_PAD_NANDF_RB0 = 132,
> + MX53_PAD_NANDF_CS0 = 133,
> + MX53_PAD_NANDF_CS1 = 134,
> + MX53_PAD_NANDF_CS2 = 135,
> + MX53_PAD_NANDF_CS3 = 136,
> + MX53_PAD_FEC_MDIO = 137,
> + MX53_PAD_FEC_REF_CLK = 138,
> + MX53_PAD_FEC_RX_ER = 139,
> + MX53_PAD_FEC_CRS_DV = 140,
> + MX53_PAD_FEC_RXD1 = 141,
> + MX53_PAD_FEC_RXD0 = 142,
> + MX53_PAD_FEC_TX_EN = 143,
> + MX53_PAD_FEC_TXD1 = 144,
> + MX53_PAD_FEC_TXD0 = 145,
> + MX53_PAD_FEC_MDC = 146,
> + MX53_PAD_PATA_DIOW = 147,
> + MX53_PAD_PATA_DMACK = 148,
> + MX53_PAD_PATA_DMARQ = 149,
> + MX53_PAD_PATA_BUFFER_EN = 150,
> + MX53_PAD_PATA_INTRQ = 151,
> + MX53_PAD_PATA_DIOR = 152,
> + MX53_PAD_PATA_RESET_B = 153,
> + MX53_PAD_PATA_IORDY = 154,
> + MX53_PAD_PATA_DA_0 = 155,
> + MX53_PAD_PATA_DA_1 = 156,
> + MX53_PAD_PATA_DA_2 = 157,
> + MX53_PAD_PATA_CS_0 = 158,
> + MX53_PAD_PATA_CS_1 = 159,
> + MX53_PAD_PATA_DATA0 = 160,
> + MX53_PAD_PATA_DATA1 = 161,
> + MX53_PAD_PATA_DATA2 = 162,
> + MX53_PAD_PATA_DATA3 = 163,
> + MX53_PAD_PATA_DATA4 = 164,
> + MX53_PAD_PATA_DATA5 = 165,
> + MX53_PAD_PATA_DATA6 = 166,
> + MX53_PAD_PATA_DATA7 = 167,
> + MX53_PAD_PATA_DATA8 = 168,
> + MX53_PAD_PATA_DATA9 = 169,
> + MX53_PAD_PATA_DATA10 = 170,
> + MX53_PAD_PATA_DATA11 = 171,
> + MX53_PAD_PATA_DATA12 = 172,
> + MX53_PAD_PATA_DATA13 = 173,
> + MX53_PAD_PATA_DATA14 = 174,
> + MX53_PAD_PATA_DATA15 = 175,
> + MX53_PAD_SD1_DATA0 = 176,
> + MX53_PAD_SD1_DATA1 = 177,
> + MX53_PAD_SD1_CMD = 178,
> + MX53_PAD_SD1_DATA2 = 179,
> + MX53_PAD_SD1_CLK = 180,
> + MX53_PAD_SD1_DATA3 = 181,
> + MX53_PAD_SD2_CLK = 182,
> + MX53_PAD_SD2_CMD = 183,
> + MX53_PAD_SD2_DATA3 = 184,
> + MX53_PAD_SD2_DATA2 = 185,
> + MX53_PAD_SD2_DATA1 = 186,
> + MX53_PAD_SD2_DATA0 = 187,
> + MX53_PAD_GPIO_0 = 188,
> + MX53_PAD_GPIO_1 = 189,
> + MX53_PAD_GPIO_9 = 190,
> + MX53_PAD_GPIO_3 = 191,
> + MX53_PAD_GPIO_6 = 192,
> + MX53_PAD_GPIO_2 = 193,
> + MX53_PAD_GPIO_4 = 194,
> + MX53_PAD_GPIO_5 = 195,
> + MX53_PAD_GPIO_7 = 196,
> + MX53_PAD_GPIO_8 = 197,
> + MX53_PAD_GPIO_16 = 198,
> + MX53_PAD_GPIO_17 = 199,
> + MX53_PAD_GPIO_18 = 200,
> };
>
> /* imx53 register maps */
> --
> 1.7.5.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-13 14:47 [PATCH] pinctrl: imx5: start numbering pad from 0 Shawn Guo
2012-08-13 15:12 ` Matt Sealey
@ 2012-08-13 19:26 ` Troy Kisky
2012-08-14 7:30 ` Dong Aisheng
2012-08-14 8:13 ` Linus Walleij
2012-08-14 9:50 ` Linus Walleij
3 siblings, 1 reply; 45+ messages in thread
From: Troy Kisky @ 2012-08-13 19:26 UTC (permalink / raw)
To: linux-arm-kernel
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 */
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-13 15:12 ` Matt Sealey
@ 2012-08-14 7:20 ` Dong Aisheng
2012-08-14 19:37 ` Matt Sealey
0 siblings, 1 reply; 45+ messages in thread
From: Dong Aisheng @ 2012-08-14 7:20 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-13 19:26 ` Troy Kisky
@ 2012-08-14 7:30 ` Dong Aisheng
2012-08-14 18:09 ` Troy Kisky
0 siblings, 1 reply; 45+ messages in thread
From: Dong Aisheng @ 2012-08-14 7:30 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-13 14:47 [PATCH] pinctrl: imx5: start numbering pad from 0 Shawn Guo
2012-08-13 15:12 ` Matt Sealey
2012-08-13 19:26 ` Troy Kisky
@ 2012-08-14 8:13 ` Linus Walleij
2012-08-14 8:22 ` Shawn Guo
2012-08-14 9:50 ` Linus Walleij
3 siblings, 1 reply; 45+ messages in thread
From: Linus Walleij @ 2012-08-14 8:13 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-14 8:13 ` Linus Walleij
@ 2012-08-14 8:22 ` Shawn Guo
2012-08-14 9:48 ` Linus Walleij
0 siblings, 1 reply; 45+ messages in thread
From: Shawn Guo @ 2012-08-14 8:22 UTC (permalink / raw)
To: linux-arm-kernel
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?
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-14 8:22 ` Shawn Guo
@ 2012-08-14 9:48 ` Linus Walleij
0 siblings, 0 replies; 45+ messages in thread
From: Linus Walleij @ 2012-08-14 9:48 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-13 14:47 [PATCH] pinctrl: imx5: start numbering pad from 0 Shawn Guo
` (2 preceding siblings ...)
2012-08-14 8:13 ` Linus Walleij
@ 2012-08-14 9:50 ` Linus Walleij
3 siblings, 0 replies; 45+ messages in thread
From: Linus Walleij @ 2012-08-14 9:50 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-14 7:30 ` Dong Aisheng
@ 2012-08-14 18:09 ` Troy Kisky
2012-08-15 4:00 ` Dong Aisheng
0 siblings, 1 reply; 45+ messages in thread
From: Troy Kisky @ 2012-08-14 18:09 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-14 7:20 ` Dong Aisheng
@ 2012-08-14 19:37 ` Matt Sealey
2012-08-15 3:59 ` Dong Aisheng
0 siblings, 1 reply; 45+ messages in thread
From: Matt Sealey @ 2012-08-14 19:37 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-14 19:37 ` Matt Sealey
@ 2012-08-15 3:59 ` Dong Aisheng
[not found] ` <CAP1dx+x0_j_f3Pj+9+YHcwoTqjGLXouf7t+SoCCMVGKJNOHCPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 3:59 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-14 18:09 ` Troy Kisky
@ 2012-08-15 4:00 ` Dong Aisheng
0 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 4:00 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 3:59 ` Dong Aisheng
@ 2012-08-15 5:44 ` Uwe Kleine-König
0 siblings, 0 replies; 45+ messages in thread
From: Uwe Kleine-König @ 2012-08-15 5:44 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello,
(Cc += devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)
On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote:
> On 15 August 2012 03:37, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> >> On 13 August 2012 23:12, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 5:44 ` Uwe Kleine-König
0 siblings, 0 replies; 45+ messages in thread
From: Uwe Kleine-König @ 2012-08-15 5:44 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
(Cc += devicetree-discuss at 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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 5:44 ` Uwe Kleine-König
@ 2012-08-15 6:55 ` Dong Aisheng
-1 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 6:55 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Aug 15, 2012 at 07:44:36AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> (Cc += devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)
>
> On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote:
> > On 15 August 2012 03:37, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> wrote:
> > > On Tue, Aug 14, 2012 at 2:20 AM, Dong Aisheng <dong.aisheng-QSEj5FYQhm5QFI55V6+gNQ@public.gmane.orgg> wrote:
> > >> On 13 August 2012 23:12, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 6:55 ` Dong Aisheng
0 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 6:55 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Aug 15, 2012 at 07:44:36AM +0200, Uwe Kleine-K?nig wrote:
> Hello,
>
> (Cc += devicetree-discuss at 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 6:55 ` Dong Aisheng
@ 2012-08-15 7:51 ` Uwe Kleine-König
-1 siblings, 0 replies; 45+ messages in thread
From: Uwe Kleine-König @ 2012-08-15 7:51 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)
> >
> > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote:
> > > On 15 August 2012 03:37, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 7:51 ` Uwe Kleine-König
0 siblings, 0 replies; 45+ messages in thread
From: Uwe Kleine-König @ 2012-08-15 7:51 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 7:51 ` Uwe Kleine-König
@ 2012-08-15 9:25 ` Dong Aisheng
-1 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 9:25 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)
> > >
> > > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote:
> > > > On 15 August 2012 03:37, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 9:25 ` Dong Aisheng
0 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 9:25 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 9:25 ` Dong Aisheng
@ 2012-08-15 10:33 ` Dong Aisheng
-1 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 10:33 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
On 15 August 2012 17:25, Dong Aisheng <b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org> 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-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org)
>> > >
>> > > On Wed, Aug 15, 2012 at 11:59:18AM +0800, Dong Aisheng wrote:
>> > > > On 15 August 2012 03:37, Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org> 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
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 10:33 ` Dong Aisheng
0 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-15 10:33 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
>
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 9:25 ` Dong Aisheng
@ 2012-08-15 13:59 ` Shawn Guo
-1 siblings, 0 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-15 13:59 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
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.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 13:59 ` Shawn Guo
0 siblings, 0 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-15 13:59 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 13:59 ` Shawn Guo
@ 2012-08-15 15:31 ` Shawn Guo
-1 siblings, 0 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-15 15:31 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
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?
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 15:31 ` Shawn Guo
0 siblings, 0 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-15 15:31 UTC (permalink / raw)
To: linux-arm-kernel
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?
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 13:59 ` Shawn Guo
@ 2012-08-15 15:39 ` Stephen Warren
-1 siblings, 0 replies; 45+ messages in thread
From: Stephen Warren @ 2012-08-15 15:39 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 15:39 ` Stephen Warren
0 siblings, 0 replies; 45+ messages in thread
From: Stephen Warren @ 2012-08-15 15:39 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 15:31 ` Shawn Guo
@ 2012-08-15 16:49 ` Matt Sealey
-1 siblings, 0 replies; 45+ messages in thread
From: Matt Sealey @ 2012-08-15 16:49 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
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>"
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-15 16:49 ` Matt Sealey
0 siblings, 0 replies; 45+ messages in thread
From: Matt Sealey @ 2012-08-15 16:49 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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>"
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 13:59 ` Shawn Guo
@ 2012-08-16 3:30 ` Dong Aisheng
-1 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-16 3:30 UTC (permalink / raw)
To: Shawn Guo
Cc: u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ, Dong Aisheng,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-16 3:30 ` Dong Aisheng
0 siblings, 0 replies; 45+ messages in thread
From: Dong Aisheng @ 2012-08-16 3:30 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-15 16:49 ` Matt Sealey
@ 2012-08-16 3:45 ` Shawn Guo
-1 siblings, 0 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-16 3:45 UTC (permalink / raw)
To: Matt Sealey
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
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.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-16 3:45 ` Shawn Guo
0 siblings, 0 replies; 45+ messages in thread
From: Shawn Guo @ 2012-08-16 3:45 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0x73f08000 {
> fsl,iomux-pins = <mux value ctrl value ipp value
> /* MX53_PIN_SD4_CMD__SD4_CMD */
> mux value ctrl value ipp value
> /* etc. */
> ...>;
>
I do not see problem with this approach either. But, this is nothing
IMX specific. Essentially, this becomes a common binding for
configuring a pin with arbitrary number of register/value pairs.
--
Regards,
Shawn
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-16 3:45 ` Shawn Guo
@ 2012-08-16 17:39 ` Matt Sealey
-1 siblings, 0 replies; 45+ messages in thread
From: Matt Sealey @ 2012-08-16 17:39 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Dong Aisheng,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Uwe Kleine-König
On Wed, Aug 15, 2012 at 10:45 PM, Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.
--
Matt Sealey <matt-sEEEE4iEDtaXzmuOJsdVMQ@public.gmane.org>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-16 17:39 ` Matt Sealey
0 siblings, 0 replies; 45+ messages in thread
From: Matt Sealey @ 2012-08-16 17:39 UTC (permalink / raw)
To: linux-arm-kernel
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 at 0x73f08000 {
>> fsl,iomux-pins = <mux value ctrl value ipp value
>> /* MX53_PIN_SD4_CMD__SD4_CMD */
>> mux value ctrl value ipp value
>> /* etc. */
>> ...>;
>
> I do not see problem with this approach either. But, this is nothing
> IMX specific. Essentially, this becomes a common binding for
> configuring a pin with arbitrary number of register/value pairs.
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 at 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.
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-16 3:30 ` Dong Aisheng
@ 2012-08-16 18:51 ` Matt Sealey
-1 siblings, 0 replies; 45+ messages in thread
From: Matt Sealey @ 2012-08-16 18:51 UTC (permalink / raw)
To: Dong Aisheng
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Dong Aisheng,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ
On Wed, Aug 15, 2012 at 10:30 PM, Dong Aisheng <b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org> 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.
--
Matt
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-16 18:51 ` Matt Sealey
0 siblings, 0 replies; 45+ messages in thread
From: Matt Sealey @ 2012-08-16 18:51 UTC (permalink / raw)
To: linux-arm-kernel
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.
--
Matt
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-16 3:30 ` Dong Aisheng
@ 2012-08-16 21:12 ` Stephen Warren
-1 siblings, 0 replies; 45+ messages in thread
From: Stephen Warren @ 2012-08-16 21:12 UTC (permalink / raw)
To: Dong Aisheng
Cc: Dong Aisheng, u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-16 21:12 ` Stephen Warren
0 siblings, 0 replies; 45+ messages in thread
From: Stephen Warren @ 2012-08-16 21:12 UTC (permalink / raw)
To: linux-arm-kernel
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.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-16 3:30 ` Dong Aisheng
@ 2012-08-21 12:46 ` Linus Walleij
-1 siblings, 0 replies; 45+ messages in thread
From: Linus Walleij @ 2012-08-21 12:46 UTC (permalink / raw)
To: Dong Aisheng
Cc: Dong Aisheng, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Aug 16, 2012 at 5:30 AM, Dong Aisheng <b29396-KZfg59tc24xl57MIdRCFDg@public.gmane.org> 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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-21 12:46 ` Linus Walleij
0 siblings, 0 replies; 45+ messages in thread
From: Linus Walleij @ 2012-08-21 12:46 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] pinctrl: imx5: start numbering pad from 0
2012-08-16 21:12 ` Stephen Warren
@ 2012-08-21 12:52 ` Linus Walleij
-1 siblings, 0 replies; 45+ messages in thread
From: Linus Walleij @ 2012-08-21 12:52 UTC (permalink / raw)
To: Stephen Warren
Cc: Dong Aisheng, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Aug 16, 2012 at 11:12 PM, Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.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
^ permalink raw reply [flat|nested] 45+ messages in thread
* [PATCH] pinctrl: imx5: start numbering pad from 0
@ 2012-08-21 12:52 ` Linus Walleij
0 siblings, 0 replies; 45+ messages in thread
From: Linus Walleij @ 2012-08-21 12:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2012-08-21 12:52 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-13 14:47 [PATCH] pinctrl: imx5: start numbering pad from 0 Shawn Guo
2012-08-13 15:12 ` Matt Sealey
2012-08-14 7:20 ` Dong Aisheng
2012-08-14 19:37 ` Matt Sealey
2012-08-15 3:59 ` Dong Aisheng
[not found] ` <CAP1dx+x0_j_f3Pj+9+YHcwoTqjGLXouf7t+SoCCMVGKJNOHCPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-15 5:44 ` Uwe Kleine-König
2012-08-15 5:44 ` Uwe Kleine-König
[not found] ` <20120815054436.GK2232-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-08-15 6:55 ` Dong Aisheng
2012-08-15 6:55 ` Dong Aisheng
[not found] ` <20120815065526.GG19681-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-08-15 7:51 ` Uwe Kleine-König
2012-08-15 7:51 ` Uwe Kleine-König
[not found] ` <20120815075117.GL2232-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2012-08-15 9:25 ` Dong Aisheng
2012-08-15 9:25 ` Dong Aisheng
[not found] ` <20120815092539.GH19681-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-08-15 10:33 ` Dong Aisheng
2012-08-15 10:33 ` Dong Aisheng
2012-08-15 13:59 ` Shawn Guo
2012-08-15 13:59 ` Shawn Guo
[not found] ` <20120815135947.GC2258-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-08-15 15:31 ` Shawn Guo
2012-08-15 15:31 ` Shawn Guo
[not found] ` <20120815153107.GG2258-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-08-15 16:49 ` Matt Sealey
2012-08-15 16:49 ` Matt Sealey
[not found] ` <CAKGA1bkNEJbQgwcdZs8PozCgVyOfUE=bDCGkRkKV3VMfbvRMgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-08-16 3:45 ` Shawn Guo
2012-08-16 3:45 ` Shawn Guo
[not found] ` <20120816034506.GI2258-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-08-16 17:39 ` Matt Sealey
2012-08-16 17:39 ` Matt Sealey
2012-08-15 15:39 ` Stephen Warren
2012-08-15 15:39 ` Stephen Warren
2012-08-16 3:30 ` Dong Aisheng
2012-08-16 3:30 ` Dong Aisheng
[not found] ` <20120816033006.GA11999-Fb7DQEYuewWctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2012-08-16 18:51 ` Matt Sealey
2012-08-16 18:51 ` Matt Sealey
2012-08-16 21:12 ` Stephen Warren
2012-08-16 21:12 ` Stephen Warren
[not found] ` <502D622A.1030104-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-08-21 12:52 ` Linus Walleij
2012-08-21 12:52 ` Linus Walleij
2012-08-21 12:46 ` Linus Walleij
2012-08-21 12:46 ` Linus Walleij
2012-08-13 19:26 ` Troy Kisky
2012-08-14 7:30 ` Dong Aisheng
2012-08-14 18:09 ` Troy Kisky
2012-08-15 4:00 ` Dong Aisheng
2012-08-14 8:13 ` Linus Walleij
2012-08-14 8:22 ` Shawn Guo
2012-08-14 9:48 ` Linus Walleij
2012-08-14 9:50 ` Linus Walleij
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.