On Thu, 30 Apr 2009 23:39:11 +0400 Anton Vorontsov <avoront...@ru.mvista.com> wrote:
> 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 <avoront...@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. sure, I may be wrong/out of date here. But since the data is publicly available, this is even more reason for me to want to use it. Kim _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot