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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2018-01-25 18:31, Lucas Stach wrote:
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb aisheng.dong@xxxxxxxxxxxxxx:
On 2018-01-23 18:39, Shawn Guo wrote:
> On Wed, Jan 17, 2018 at 07:32:43PM +0100, Lucas Stach wrote:
>
> > > > > +	pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
> > > > > +		fsl,pins = <
> > > > > > > > +			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
>
> > +
> > > > > +	pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
> > > > > +		fsl,pins = <
> > > > > > > > +			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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux