[PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-12 Thread Rajendra Nayak 
Add omap mmc related device tree data for OMAP3.
Currenly limited to only omap3-beagle board.

Signed-off-by: Rajendra Nayak rna...@ti.com
---
 arch/arm/boot/dts/omap3-beagle.dts |   14 ++
 arch/arm/boot/dts/omap3.dtsi   |   16 
 2 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 714ba5d..5cf67d1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -47,3 +47,17 @@
reg = 0x50;
};
 };
+
+mmc1 {
+   vmmc-supply = vmmc1;
+   vmmc_aux-supply = vsim;
+   ti,bus-width = 8;
+};
+
+mmc2 {
+   status = disable;
+};
+
+mmc3 {
+   status = disable;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index ca37ba5..3892e34 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,21 @@
#size-cells = 0;
ti,hwmods = i2c3;
};
+
+   mmc1: mmc@1 {
+   compatible = ti,omap3-hsmmc;
+   ti,hwmods = mmc1;
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = ti,omap3-hsmmc;
+   ti,hwmods = mmc2;
+   };
+
+   mmc3: mmc@3 {
+   compatible = ti,omap3-hsmmc;
+   ti,hwmods = mmc3;
+   };
};
 };
-- 
1.7.1

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-09 Thread Rajendra Nayak 

On Friday 09 March 2012 11:16 AM, Grant Likely wrote:

On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgrent...@atomide.com  wrote:

* Rajendra Nayakrna...@ti.com  [120223 19:29]:

On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:

--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+   mmc1: mmc@1 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc1;
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc2;
+   };
+
+   mmc3: mmc@3 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc3;
+   };
+
+   mmc4: mmc@4 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc4;
+   };
+
+   mmc5: mmc@5 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc5;
+   };
};
  };


These all should all be ti,omap3-hsmmc I guess?


Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.


Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..


Yes, absolutely use separate compatible values.  It is always important
to be specific as to the silicon implementing the IP.  The omap3 instance
can also carry the omap2 string in its compatible list:

compatible = ti,omap3-hsmmc, ti,omap2-hsmmc;


Sure, will repost with seperate compatible strings. Also missed adding
the 'status = disable;' for unused mmc blocks in the board .dts file
causing unused mmc modules to get probed too. Will fix that as well.

thanks,
Rajendra



g.


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-09 Thread Rajendra Nayak 

Hi Paul,

On Friday 09 March 2012 12:21 PM, Paul Walmsley wrote:

On Thu, 8 Mar 2012, Grant Likely wrote:


Yes, absolutely use separate compatible values.  It is always important
to be specific as to the silicon implementing the IP.


In that case, it is probably best to use the full chip name in the
compatible string, e.g., omap2420 or omap2430 rather than just omap2.


Since omap2420 and omap2430 have different MMC controllers (and these
bindings only cover the hsmmc controller used in 2430 and beyond, I
haven't done the bindings for the legacy one yet), the idea was
to differentiate between omap2420 and omap2430 by using
compatible of ti,omap2-hsmmc for the High-Speed controller used in
OMAP2 (2430) and ti,omap2-mmc for the legacy one used in OMAP2 (2420).
Does that sound good to you?


Particularly in the case of OMAP3, which is a largely meaningless group
these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are
quite different from each other...


But these bindings are specific and limited to HSMMC module which is
not quite different in the different SoC variants. There is a single
driver to handle hsmmc module on all the SoCs which does not need to
differentiate which SoC it is on.

regards,
Rajendra




- Paul


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-08 Thread Grant Likely 
On Fri, 24 Feb 2012 10:49:00 -0800, Tony Lindgren t...@atomide.com wrote:
 * Rajendra Nayak rna...@ti.com [120223 19:29]:
  On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
  --- a/arch/arm/boot/dts/omap3.dtsi
  +++ b/arch/arm/boot/dts/omap3.dtsi
  @@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
  +
  + mmc1: mmc@1 {
  + compatible = ti,omap2-hsmmc;
  + ti,hwmods = mmc1;
  + ti,dual-volt;
  + };
  +
  + mmc2: mmc@2 {
  + compatible = ti,omap2-hsmmc;
  + ti,hwmods = mmc2;
  + };
  +
  + mmc3: mmc@3 {
  + compatible = ti,omap2-hsmmc;
  + ti,hwmods = mmc3;
  + };
  +
  + mmc4: mmc@4 {
  + compatible = ti,omap2-hsmmc;
  + ti,hwmods = mmc4;
  + };
  +
  + mmc5: mmc@5 {
  + compatible = ti,omap2-hsmmc;
  + ti,hwmods = mmc5;
  + };
};
};
  
  These all should all be ti,omap3-hsmmc I guess?
  
  Well, I defined the binding such that both omap2 and omap3
  can use the same compatible ti,omap2-hsmmc since there is
  no difference in the way they are defined or handled. If thats
  confusing, I can have separate compatibles.
  Btw, I guess we do the same with a few other re-used IPs as well,
  I just checked and mcpsi does the same.
 
 Yeah let's use separate compatibles to avoid confusion.
 For omap2 we also have the ti,omap2-mmc in addition to
 ti,omap2-hsmmc..

Yes, absolutely use separate compatible values.  It is always important
to be specific as to the silicon implementing the IP.  The omap3 instance
can also carry the omap2 string in its compatible list:

compatible = ti,omap3-hsmmc, ti,omap2-hsmmc;

g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-03-08 Thread Paul Walmsley 
On Thu, 8 Mar 2012, Grant Likely wrote:

 Yes, absolutely use separate compatible values.  It is always important
 to be specific as to the silicon implementing the IP.

In that case, it is probably best to use the full chip name in the 
compatible string, e.g., omap2420 or omap2430 rather than just omap2.  
Particularly in the case of OMAP3, which is a largely meaningless group 
these days with AM33xx, OMAP34xx, OMAP36xx, and AM3517, many of which are 
quite different from each other...


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-02-24 Thread Cousson, Benoit 

On 2/24/2012 5:00 AM, Rajendra Nayak wrote:

On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:

--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc2;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc3;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc4;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap2-hsmmc;
+ ti,hwmods = mmc5;
+ };
};
};


These all should all be ti,omap3-hsmmc I guess?


Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.


Yes, the goal is mainly to identify the IP version, so since OMAP3 is 
using OMAP2 IP, I do not think there is a need to add a new compatible 
string for OMAP3. The should only be documented in the binding potentially.
The advantage is that that will avoid adding an extra compatible string 
in the driver as well whereas there is no change in the IP.


Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-02-24 Thread Tony Lindgren 
* Rajendra Nayak rna...@ti.com [120223 19:29]:
 On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -113,5 +113,31 @@
 #size-cells =0;
 ti,hwmods = i2c3;
 };
 +
 +   mmc1: mmc@1 {
 +   compatible = ti,omap2-hsmmc;
 +   ti,hwmods = mmc1;
 +   ti,dual-volt;
 +   };
 +
 +   mmc2: mmc@2 {
 +   compatible = ti,omap2-hsmmc;
 +   ti,hwmods = mmc2;
 +   };
 +
 +   mmc3: mmc@3 {
 +   compatible = ti,omap2-hsmmc;
 +   ti,hwmods = mmc3;
 +   };
 +
 +   mmc4: mmc@4 {
 +   compatible = ti,omap2-hsmmc;
 +   ti,hwmods = mmc4;
 +   };
 +
 +   mmc5: mmc@5 {
 +   compatible = ti,omap2-hsmmc;
 +   ti,hwmods = mmc5;
 +   };
 };
   };
 
 These all should all be ti,omap3-hsmmc I guess?
 
 Well, I defined the binding such that both omap2 and omap3
 can use the same compatible ti,omap2-hsmmc since there is
 no difference in the way they are defined or handled. If thats
 confusing, I can have separate compatibles.
 Btw, I guess we do the same with a few other re-used IPs as well,
 I just checked and mcpsi does the same.

Yeah let's use separate compatibles to avoid confusion.
For omap2 we also have the ti,omap2-mmc in addition to
ti,omap2-hsmmc..

Regards,

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-02-23 Thread Tony Lindgren 
 --- a/arch/arm/boot/dts/omap3.dtsi
 +++ b/arch/arm/boot/dts/omap3.dtsi
 @@ -113,5 +113,31 @@
   #size-cells = 0;
   ti,hwmods = i2c3;
   };
 +
 + mmc1: mmc@1 {
 + compatible = ti,omap2-hsmmc;
 + ti,hwmods = mmc1;
 + ti,dual-volt;
 + };
 +
 + mmc2: mmc@2 {
 + compatible = ti,omap2-hsmmc;
 + ti,hwmods = mmc2;
 + };
 +
 + mmc3: mmc@3 {
 + compatible = ti,omap2-hsmmc;
 + ti,hwmods = mmc3;
 + };
 +
 + mmc4: mmc@4 {
 + compatible = ti,omap2-hsmmc;
 + ti,hwmods = mmc4;
 + };
 +
 + mmc5: mmc@5 {
 + compatible = ti,omap2-hsmmc;
 + ti,hwmods = mmc5;
 + };
   };
  };

These all should all be ti,omap3-hsmmc I guess?

Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 4/4] arm/dts: OMAP3: Add mmc controller nodes and board data

2012-02-23 Thread Rajendra Nayak 

On Friday 24 February 2012 12:27 AM, Tony Lindgren wrote:

--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -113,5 +113,31 @@
#size-cells =0;
ti,hwmods = i2c3;
};
+
+   mmc1: mmc@1 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc1;
+   ti,dual-volt;
+   };
+
+   mmc2: mmc@2 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc2;
+   };
+
+   mmc3: mmc@3 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc3;
+   };
+
+   mmc4: mmc@4 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc4;
+   };
+
+   mmc5: mmc@5 {
+   compatible = ti,omap2-hsmmc;
+   ti,hwmods = mmc5;
+   };
};
  };


These all should all be ti,omap3-hsmmc I guess?


Well, I defined the binding such that both omap2 and omap3
can use the same compatible ti,omap2-hsmmc since there is
no difference in the way they are defined or handled. If thats
confusing, I can have separate compatibles.
Btw, I guess we do the same with a few other re-used IPs as well,
I just checked and mcpsi does the same.



Tony


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html