[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180205083235.okfm2rjk3uskdbrh@pengutronix.de>
Date: Mon, 5 Feb 2018 09:32:35 +0100
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Shawn Guo <shawnguo@...nel.org>
Cc: Benoît Thébaudeau
<benoit.thebaudeau.dev@...il.com>,
Mark Rutland <mark.rutland@....com>,
devicetree@...r.kernel.org, Russell King <linux@...linux.org.uk>,
linux-kernel <linux-kernel@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Sascha Hauer <kernel@...gutronix.de>,
Fabio Estevam <fabio.estevam@....com>,
Michael Nazzareno Trimarchi <michael@...rulasolutions.com>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: dts: imx25-pinfunc: Always set SION for SD CMD
On Mon, Feb 05, 2018 at 04:10:20PM +0800, Shawn Guo wrote:
> On Sat, Jan 27, 2018 at 09:37:11PM +0100, Benoît Thébaudeau wrote:
> > On Sat, Jan 27, 2018 at 4:37 PM, Uwe Kleine-König
> > <u.kleine-koenig@...gutronix.de> wrote:
> > > On Sat, Jan 27, 2018 at 01:07:52AM +0100, Benoît Thébaudeau wrote:
> > >> The eSDHC does not work properly if the SION bit is not set for the
> > >> bidirectional CMD signal, whatever the eSDHC instance and the selected
> > >> pad. Therefore, setting SION is mandatory for all eSDHC CMD ports. Do
> > >> this for MX25_PAD_*__SD*_CMD in imx25-pinfunc.h in order to enforce this
> > >> behavior for all boards.
> > >>
> > >> This had already been done for eSDHC1, but not for eSDHC2. Also, define
> > >> MX25_PAD_FEC_MDC__SDHC2_CMD so that all the possible cases are covered
> > >> from now on.
> > >
> > > There is an inconsistency in the naming. The eSDHC1 CMD constants are
> > > named:
> > >
> > > MX25_PAD_SD1_CMD__SD1_CMD
> > >
> > > The reference calls this:
> > >
> > > CMD of instance: esdhc1.
> > >
> > > The register name is correct though. Not sure it's worth to fix this to
> > > use consistent naming (which would result in:
> > >
> > > MX25_PAD_SD1_CMD__ESDHC1_CMD
> > >
> > > which looks ugly, too).
> >
> > Indeed. I had also noticed this. I can send a patch to apply before
> > this one. But that would break the out-of-tree DT files using these
> > definitions. Would that be OK?
>
> That's OK, I would say. It could be a reminder of that they should
> upstream their files.
I assume you saw v2 which introduced some defines to give those guys a
bit of time, which IMHO is still better. Then we can remove these compat
defines in (say) a year and so trigger this reminder.
Also one of the advantages of dt that was advertised when ARM was
converted to dt was, that upstreaming the dt isn't necessary any more. I
personally like this and still consider not upstreaming the dtb part of
a machine a sane approach.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Powered by blists - more mailing lists