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 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 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 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. -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 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. -- 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 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. 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 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)? IMO chip 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, 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. -- 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:35:34 +0400 Anton Vorontsov avoront...@ru.mvista.com 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 chip 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, 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
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 avoront...@ru.mvista.com 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 chip 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
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
avoront...@ru.mvista.com 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 avoront...@ru.mvista.com
---
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 malloc.h
#include mmc.h
#include fsl_esdhc.h
+#include fsl_can_use.h
+#include fdt_support.h
#include asm/io.h
@@ -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-chip, fsl,device-first-chip-in-a-family;
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,CHIP-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,chip-esdhc, fsl,mpc8379-esdhc for MPC83xx processors.
fsl,chip-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
avoront...@ru.mvista.com 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 avoront...@ru.mvista.com
---
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 malloc.h
#include mmc.h
#include fsl_esdhc.h
+#include fsl_can_use.h
+#include fdt_support.h
#include asm/io.h
@@ -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
