[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups

[Anton Vorontsov]

On Thu, Apr 30, 2009 at 11:35:34PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> > On Thu, 30 Apr 2009 22:59:59 +0400
> > Anton Vorontsov <avorontsov at ru.mvista.com> wrote:
> > 
> > > On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > > > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > > > Isn't there a more global means of doing this?  I don't like having
> > > > > > the 8536/8379 in the driver, itself.
> > > > > 
> > > > > But that's how we prefer bindings nowadays.
> > > > 
> > > > Block version numbers are better, if available.
> > > > 
> > > > > > Actually, there is.  Move these to the config file.  But there should
> > > > > > be a compatible property that works for all esdhc devices.
> > > > > 
> > > > > Starting from MPC83xx/MPC85xx GPIO controllers, we try to differentiate
> > > > > 85xx and 83xx parts.  I.e. 85xx family doesn't specify 83xx family's
> > > > > compatible entries, even if the controllers are compatible. I'm just
> > > > > following the trend.
> > > > 
> > > > I must have missed that memo...
> > > > 
> > > > Why would we not recognize the compatibility if it exists?
> > > > 
> > > > > So the current scheme is:
> > > > > "fsl,device-<chip>", "fsl,device-<first-chip-in-a-family>;
> > > > > 
> > > > > See this discussion:
> > > > > 
> > > > > http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
> > > > 
> > > > Bah.  I don't see how it's any more "confusing to show 8610 and 8349 in
> > > > the same dev tree" than in is to show, say, 8313 and 8349 in the same
> > > > device tree.  The concept of component A being compatible with component
> > > > B doesn't somehow get mysterious when the systems involved have a
> > > > different type of core.
> > > 
> > > I feel a bit dizzy.
> > > 
> > > For a year I thought that we should specify first compatible chip
> > > in the last compatible entry, then I've been told that the first
> > > compatible chip _in a family_ should be specified and we used
> > > this during, say, another six months. And now you're saying that a
> > > block version number is preferred.
> > > 
> > > Now all possible compatible naming schemes are used in various
> > > device trees for various devices.
> > > 
> > > Can we have a guideline set in a stone that we all agree with?
> > > 
> > > In general, I follow maintainer's opinion, so I'm waiting for
> > > Kumar's decision on that matter, and depending on the results
> > > I'll modify the bindings and/or patches.
> > 
> > I, for one, have disagreed with the superfluous <CHIP> prefix for quite
> > some time now - see the SEC node description and/or
> > http://ozlabs.org/pipermail/linuxppc-dev/2008-July/058867.html.
> > 
> > fyi block version number is available for the eSDHC block.  It's
> > version is at v0.9 for the 8379, 1.0 for the mpc8536rev1, and 1.0.1 for
> > the mpc8536rev1.1.  I'm not familiar with it enough to know whether the
> > 3rd degree of precision is needed though.
> 
> What if there is some errata in 8377 chip (with 1.0 revision), and
> not in 8378 chip (also 1.0 revision)?

Oh, and btw, reference manual for 8379 specify that it has eSDHC
version 1.0. Is v0.9 some internal FSL numbering scheme? Then
it's also not a good idea to use it in the public device tree.

-- 
Anton Vorontsov
email: cbouatmailru at gmail.com
irc://irc.freenode.net/bd2