Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Fri, May 01, 2009 at 07:32:12PM -0500, Andy Fleming wrote:
>
> On Apr 29, 2009, at 4:20 PM, Anton Vorontsov wrote:
>
>> Hi Andy,
>>
>> Sorry for the late response,
>>
>> On Fri, Mar 06, 2009 at 07:25:55PM -0600, Andy Fleming wrote:
@@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
 {
    return esdhc_initialize(bis);
 }
+
+#ifdef CONFIG_MPC85xx
+#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
+#else
+#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
+#endif
>>>
>>> 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.
>>
>>> 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'm not strongly interested in arguing about what the compatible should
> be. Don't specify it here. Put it in the config file.
Will do, thanks.
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Apr 29, 2009, at 4:20 PM, Anton Vorontsov wrote:
Hi Andy,
Sorry for the late response,
On Fri, Mar 06, 2009 at 07:25:55PM -0600, Andy Fleming wrote:
@@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
 {
    return esdhc_initialize(bis);
 }
+
+#ifdef CONFIG_MPC85xx
+#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
+#else
+#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
+#endif
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.
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'm not strongly interested in arguing about what the compatible
should be. Don't specify it here. Put it in the config file.___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Fri, May 01, 2009 at 10:59:13AM -0500, Scott Wood wrote: > It's possible -- but not likely enough to warrant using the chip name if > a usable block number is available (it's more likely that a future rev of > the same chip number will have a different logic block version). PVR or > information elsewhere in the device tree could be used in such cases. I meant SVR, not PVR, of course. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Fri, May 01, 2009 at 12:20:51AM +0400, Anton Vorontsov wrote: > Sometimes errors happen even during copy-paste procedure. Or > for example HW designers have made some minor (they thought) change, > and didn't bother to bump the revision. Later we observe that the > change is the cause of some errata, but we can't deal with it > because device-tree isn't specific enough. > > Of course this is just my imagination, but theoretically possible? It's possible -- but not likely enough to warrant using the chip name if a usable block number is available (it's more likely that a future rev of the same chip number will have a different logic block version). PVR or information elsewhere in the device tree could be used in such cases. Note that it can even happen at board level. Accessing power management controller registers (which are SoC-internal) on early revs of the 8313erdb would lock the board (unless JTAG is plugged in or a resistor modification is made), at no fault of the 8313e chip itself. But we don't put the board name in all of the compatibles... -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, Apr 30, 2009 at 02:59:37PM -0500, Kim Phillips wrote: > On Thu, 30 Apr 2009 23:35:34 +0400 > Anton Vorontsov wrote: > > > What if there is some errata in 8377 chip (with 1.0 revision), and > > not in 8378 chip (also 1.0 revision)? > > I believe they are in fact the same chip, just with different fuses > blown. Sure, that was just a what-if, an imaginary example. > > IMO prefix is more specific than a block revision. > > It's a waste IMO. H/w designers do just like us; they copy-n-paste IP > blocks into chips. Sometimes errors happen even during copy-paste procedure. Or for example HW designers have made some minor (they thought) change, and didn't bother to bump the revision. Later we observe that the change is the cause of some errata, but we can't deal with it because device-tree isn't specific enough. Of course this is just my imagination, but theoretically possible? Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, 30 Apr 2009 23:39:11 +0400 Anton Vorontsov 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 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-", "fsl,device-; > > > > > > > > > > > > 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 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
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, 30 Apr 2009 23:35:34 +0400 Anton Vorontsov wrote: > What if there is some errata in 8377 chip (with 1.0 revision), and > not in 8378 chip (also 1.0 revision)? I believe they are in fact the same chip, just with different fuses blown. > IMO prefix is more specific than a block revision. It's a waste IMO. H/w designers do just like us; they copy-n-paste IP blocks into chips. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
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 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-", "fsl,device-; > > > > > > > > > > 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 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: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote: > On Thu, 30 Apr 2009 22:59:59 +0400 > Anton Vorontsov 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-", "fsl,device-; > > > > > > > > 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 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)? IMO prefix is more specific than a block revision. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, 30 Apr 2009 22:59:59 +0400 Anton Vorontsov 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-", "fsl,device-; > > > > > > 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 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. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
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-", "fsl,device-; > > > > 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. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
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-", "fsl,device-; > > 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. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
Hi Andy,
Sorry for the late response,
On Fri, Mar 06, 2009 at 07:25:55PM -0600, Andy Fleming wrote:
> On Thu, Feb 19, 2009 at 9:45 AM, Anton Vorontsov
> wrote:
> > This patch implements fdt_fixup_esdhc() function that is used to fixup
> > the device tree.
> >
> > The function adds status = "disabled" propery if esdhc pins muxed away,
> > otherwise it fixups clock-frequency for esdhc nodes.
> >
> > Signed-off-by: Anton Vorontsov
> > ---
> > drivers/mmc/fsl_esdhc.c | 22 ++
> > include/fsl_esdhc.h | 8
> > 2 files changed, 30 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > index 0ba45cd..fe8bd86 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -33,6 +33,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> > #include
> >
> >
> > @@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
> > {
> > return esdhc_initialize(bis);
> > }
> > +
> > +#ifdef CONFIG_MPC85xx
> > +#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
> > +#else
> > +#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
> > +#endif
>
> 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.
> 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.
So the current scheme is:
"fsl,device-", "fsl,device-;
See this discussion:
http://ozlabs.org/pipermail/linuxppc-dev/2008-September/062934.html
And some quotes from accepted bindings:
Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt:
- compatible : "fsl,-gpio" followed by "fsl,mpc8349-gpio" for
83xx, "fsl,mpc8572-gpio" for 85xx and "fsl,mpc8610-gpio" for 86xx.
Documentation/powerpc/dts-bindings/fsl/esdhc.txt:
- compatible : should be
"fsl,-esdhc", "fsl,mpc8379-esdhc" for MPC83xx processors.
"fsl,-esdhc", "fsl,mpc8536-esdhc" for MPC85xx processors.
Thanks,
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
On Thu, Feb 19, 2009 at 9:45 AM, Anton Vorontsov
wrote:
> This patch implements fdt_fixup_esdhc() function that is used to fixup
> the device tree.
>
> The function adds status = "disabled" propery if esdhc pins muxed away,
> otherwise it fixups clock-frequency for esdhc nodes.
>
> Signed-off-by: Anton Vorontsov
> ---
> drivers/mmc/fsl_esdhc.c | 22 ++
> include/fsl_esdhc.h | 8
> 2 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 0ba45cd..fe8bd86 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -33,6 +33,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
>
>
> @@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
> {
> return esdhc_initialize(bis);
> }
> +
> +#ifdef CONFIG_MPC85xx
> +#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
> +#else
> +#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
> +#endif
Isn't there a more global means of doing this? I don't like having
the 8536/8379 in the driver, itself. Actually, there is. Move these
to the config file. But there should be a compatible property that
works for all esdhc devices.
Andy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/6] fsl_esdhc: Add device tree fixups
This patch implements fdt_fixup_esdhc() function that is used to fixup
the device tree.
The function adds status = "disabled" propery if esdhc pins muxed away,
otherwise it fixups clock-frequency for esdhc nodes.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/fsl_esdhc.c | 22 ++
include/fsl_esdhc.h |8
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 0ba45cd..fe8bd86 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -33,6 +33,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -346,3 +348,23 @@ int fsl_esdhc_mmc_init(bd_t *bis)
{
return esdhc_initialize(bis);
}
+
+#ifdef CONFIG_MPC85xx
+#define ESDHC_COMPATIBLE "fsl,mpc8536-esdhc"
+#else
+#define ESDHC_COMPATIBLE "fsl,mpc8379-esdhc"
+#endif
+
+void fdt_fixup_esdhc(void *blob, bd_t *bd)
+{
+ if (!fsl_can_use_esdhc()) {
+ const char *reason = "disabled";
+
+ do_fixup_by_compat(blob, ESDHC_COMPATIBLE, "status", reason,
+ strlen(reason) + 1, 1);
+ return;
+ }
+
+ do_fixup_by_compat_u32(blob, ESDHC_COMPATIBLE, "clock-frequency",
+ gd->sdhc_clk, 1);
+}
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc.h
index 0a5c5d6..89b8304 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc.h
@@ -26,6 +26,8 @@
#ifndef __FSL_ESDHC_H__
#define__FSL_ESDHC_H__
+#include
+
/* FSL eSDHC-specific constants */
#define SYSCTL 0x0002e02c
#define SYSCTL_INITA 0x0800
@@ -140,6 +142,12 @@
#define ESDHC_HOSTCAPBLT_DMAS 0x0040
#define ESDHC_HOSTCAPBLT_HSS 0x0020
+#ifdef CONFIG_FSL_ESDHC
int fsl_esdhc_mmc_init(bd_t *bis);
+void fdt_fixup_esdhc(void *blob, bd_t *bd);
+#else
+static inline int fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }
+static inline void fdt_fixup_esdhc(void *blob, bd_t *bd) {}
+#endif /* CONFIG_FSL_ESDHC */
#endif /* __FSL_ESDHC_H__ */
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
