Thread (1 message) 1 message, 1 author, 2018-01-25

Re: [PATCH 3/4] arm64: add support for i.MX8M EVK board

From: Dong Aisheng <hidden>
Date: 2018-01-25 10:49:19
Also in: linux-arm-kernel

On 2018-01-25 18:31, Lucas Stach wrote:
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb 
aisheng.dong-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org:
quoted
On 2018-01-23 18:39, Shawn Guo wrote:
quoted
On Wed, Jan 17, 2018 at 07:32:43PM +0100, Lucas Stach wrote:
quoted
quoted
quoted
quoted
+	pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+		fsl,pins = <
quoted
quoted
quoted
+			MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK			0x85
+			MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD			0xc5
+			MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0		0xc5
+			MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1		0xc5
+			MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2		0xc5
+			MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3		0xc5
+			MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xc1
+		>;
+		};
Bad indentation.

Shawn
quoted
+
quoted
quoted
quoted
+	pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+		fsl,pins = <
quoted
quoted
quoted
+			MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK			0x87
+			MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD			0xc7
+			MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0		0xc7
+			MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1		0xc7
+			MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2		0xc7
+			MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3		0xc7
+			MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT		0xc1
+		>;
+	};
AFAIK we switched to generic pinconfig since MX7ULP as maintainer 
won't
access old binding pinctrl drivers.
I'm not convinced that the generic pinconf is good fit. For pingroups
with different configs for some of the pins, like the example above, we
would need to split things into multiple DT nodes. This really hurts
readability, so I'm not going to switch to the generic stuff without
some really convincing arguments.
Per my understanding, based on the last discussion with Linus W, we 
actually
did this in order to increase the readability that 1) user does not need 
to
see the 'ugly' unreadable raw data and refer to reference manual 2) 
unified
generic binding format which already exist in kernel and used by many
platforms.

Actually MXS platform already used it for many years in a similar way.

So IMHO a little hurt to add another node for different pad setting in 
the
same group won't be enough reason to stop switching to generic config.

Does it make sense?

Regards
Dong Aisheng
Regards,
Lucas
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help