Re: [PATCH v2] arm: omap3: cm-t35: add support for cm-t3730

2011-06-14 Thread Tony Lindgren 
* Igor Grinberg grinb...@compulab.co.il [110613 12:30]:
 On 06/13/11 16:33, Tony Lindgren wrote:
  * Igor Grinberg grinb...@compulab.co.il [110603 06:33]:
  I'm not sure I understand what are you trying to propose here...
  If you look once again on the code, there is currently only one if 
  (cpu_is_..) {} else {}
  statement currently present.
  (I can remove the if (cpu_is_omap3630()) - it indeed has no value)
 
  Indeed, there will be some other differences...
  Each time I submit a patch, I try to be as optimal as I can,
  but again I'm open for suggestions...
  (though I think it is optimal, e.g. 33 lines for a new running board...)
  What I meant is that maybe you should do the detection first in some
  get_revision function and populate the gpio pins there. Sort of like
  this recent beagle patch:
 
  https://patchwork.kernel.org/patch/859662/
 
 Yes I've seen this patch (actually, I was one of the people who reviewed it).
 
  That way adding support for other differences will be easier.
 
 OK, now I understand what you mean.
 I think currently this is not optimal for cm-t35/3730 and will just complicate
 things and introduce more l-o-c.
 
 The situation on beagle board is much more complicated then on cm-t3x.
 Beagle has quite a large number of revisions,
 while cm-t35 has only one and cm-t3730 has only one.
 Moreover, there is no difference in gpios - same numbers are used
 for the same functionality.
 
 In particular the only two differences (that s/w cares about) between the 
 boards are:
 1) mux of the DSS pins
 2) no NAND on cm-t3730 (still not introduced by the patch in subj)
 
 Nevertheless, I will try to come up with something,
 so we can see and decide what is a better option.

OK if the differences are minimal, then it's up to you to which way
you want to patch it: )
 
 I will base it on your devel-board branch
 (correct me if you want it some other way).

That's good thanks.

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] arm: omap3: cm-t35: add support for cm-t3730

2011-06-13 Thread Tony Lindgren 
* Igor Grinberg grinb...@compulab.co.il [110603 06:33]:
 
 I'm not sure I understand what are you trying to propose here...
 If you look once again on the code, there is currently only one if 
 (cpu_is_..) {} else {}
 statement currently present.
 (I can remove the if (cpu_is_omap3630()) - it indeed has no value)

 Indeed, there will be some other differences...
 Each time I submit a patch, I try to be as optimal as I can,
 but again I'm open for suggestions...
 (though I think it is optimal, e.g. 33 lines for a new running board...)

What I meant is that maybe you should do the detection first in some
get_revision function and populate the gpio pins there. Sort of like
this recent beagle patch:

https://patchwork.kernel.org/patch/859662/

That way adding support for other differences will be easier.

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] arm: omap3: cm-t35: add support for cm-t3730

2011-06-13 Thread Igor Grinberg 
On 06/13/11 16:33, Tony Lindgren wrote:
 * Igor Grinberg grinb...@compulab.co.il [110603 06:33]:
 I'm not sure I understand what are you trying to propose here...
 If you look once again on the code, there is currently only one if 
 (cpu_is_..) {} else {}
 statement currently present.
 (I can remove the if (cpu_is_omap3630()) - it indeed has no value)

 Indeed, there will be some other differences...
 Each time I submit a patch, I try to be as optimal as I can,
 but again I'm open for suggestions...
 (though I think it is optimal, e.g. 33 lines for a new running board...)
 What I meant is that maybe you should do the detection first in some
 get_revision function and populate the gpio pins there. Sort of like
 this recent beagle patch:

 https://patchwork.kernel.org/patch/859662/

Yes I've seen this patch (actually, I was one of the people who reviewed it).

 That way adding support for other differences will be easier.

OK, now I understand what you mean.
I think currently this is not optimal for cm-t35/3730 and will just complicate
things and introduce more l-o-c.

The situation on beagle board is much more complicated then on cm-t3x.
Beagle has quite a large number of revisions,
while cm-t35 has only one and cm-t3730 has only one.
Moreover, there is no difference in gpios - same numbers are used
for the same functionality.

In particular the only two differences (that s/w cares about) between the 
boards are:
1) mux of the DSS pins
2) no NAND on cm-t3730 (still not introduced by the patch in subj)

Nevertheless, I will try to come up with something,
so we can see and decide what is a better option.

I will base it on your devel-board branch
(correct me if you want it some other way).


-- 
Regards,
Igor.

--
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] arm: omap3: cm-t35: add support for cm-t3730

2011-06-03 Thread Igor Grinberg 
Hi Tony,


On 05/31/11 16:04, Tony Lindgren wrote:

 * Igor Grinberg grinb...@compulab.co.il [110508 00:17]:
 cm-t3730 is basically the same board as cm-t35, but has DM3730 SoC
 assembled and therefore some changes are required.
 +static void cm_t35_mux_init(void)
 +{
 +int mux_mode = OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT;
 +
 +omap3_mux_init(cm_t35_common_board_mux, OMAP_PACKAGE_CUS);
 +
 +if (cpu_is_omap34xx()) {
 +omap_mux_init_signal(gpio_70, mux_mode);
 +omap_mux_init_signal(gpio_71, mux_mode);
 +omap_mux_init_signal(gpio_72, mux_mode);
 +omap_mux_init_signal(gpio_73, mux_mode);
 +omap_mux_init_signal(gpio_74, mux_mode);
 +omap_mux_init_signal(gpio_75, mux_mode);
 +} else if (cpu_is_omap3630()) {
 +mux_mode = OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT;
 +omap_mux_init_signal(sys_boot0, mux_mode);
 +omap_mux_init_signal(sys_boot1, mux_mode);
 +omap_mux_init_signal(sys_boot3, mux_mode);
 +omap_mux_init_signal(sys_boot4, mux_mode);
 +omap_mux_init_signal(sys_boot5, mux_mode);
 +omap_mux_init_signal(sys_boot6, mux_mode);
 +}
 +
 +omap_mux_init_signal(dss_data18, mux_mode);
 +omap_mux_init_signal(dss_data19, mux_mode);
 +omap_mux_init_signal(dss_data20, mux_mode);
 +omap_mux_init_signal(dss_data21, mux_mode);
 +omap_mux_init_signal(dss_data22, mux_mode);
 +omap_mux_init_signal(dss_data23, mux_mode);
 +}
 +#else
 +static inline void cm_t35_mux_init(void) {}
  #endif
 Should this cpu_is_omap if else done once and then set
 some data based on it? That would be better if you need to
 use it for detection for other things later on as it will
 avoid multiple cpu_is/machine_is if else lines of code.

I'm not sure I understand what are you trying to propose here...
If you look once again on the code, there is currently only one if (cpu_is_..) 
{} else {}
statement currently present.
(I can remove the if (cpu_is_omap3630()) - it indeed has no value)

Indeed, there will be some other differences...
Each time I submit a patch, I try to be as optimal as I can,
but again I'm open for suggestions...
(though I think it is optimal, e.g. 33 lines for a new running board...)

-- 
Regards,
Igor.

--
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] arm: omap3: cm-t35: add support for cm-t3730

2011-05-31 Thread Tony Lindgren 
* Igor Grinberg grinb...@compulab.co.il [110508 00:17]:
 cm-t3730 is basically the same board as cm-t35, but has DM3730 SoC
 assembled and therefore some changes are required.

 +static void cm_t35_mux_init(void)
 +{
 + int mux_mode = OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT;
 +
 + omap3_mux_init(cm_t35_common_board_mux, OMAP_PACKAGE_CUS);
 +
 + if (cpu_is_omap34xx()) {
 + omap_mux_init_signal(gpio_70, mux_mode);
 + omap_mux_init_signal(gpio_71, mux_mode);
 + omap_mux_init_signal(gpio_72, mux_mode);
 + omap_mux_init_signal(gpio_73, mux_mode);
 + omap_mux_init_signal(gpio_74, mux_mode);
 + omap_mux_init_signal(gpio_75, mux_mode);
 + } else if (cpu_is_omap3630()) {
 + mux_mode = OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT;
 + omap_mux_init_signal(sys_boot0, mux_mode);
 + omap_mux_init_signal(sys_boot1, mux_mode);
 + omap_mux_init_signal(sys_boot3, mux_mode);
 + omap_mux_init_signal(sys_boot4, mux_mode);
 + omap_mux_init_signal(sys_boot5, mux_mode);
 + omap_mux_init_signal(sys_boot6, mux_mode);
 + }
 +
 + omap_mux_init_signal(dss_data18, mux_mode);
 + omap_mux_init_signal(dss_data19, mux_mode);
 + omap_mux_init_signal(dss_data20, mux_mode);
 + omap_mux_init_signal(dss_data21, mux_mode);
 + omap_mux_init_signal(dss_data22, mux_mode);
 + omap_mux_init_signal(dss_data23, mux_mode);
 +}
 +#else
 +static inline void cm_t35_mux_init(void) {}
  #endif

Should this cpu_is_omap if else done once and then set
some data based on it? That would be better if you need to
use it for detection for other things later on as it will
avoid multiple cpu_is/machine_is if else lines of code.

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

[PATCH v2] arm: omap3: cm-t35: add support for cm-t3730

2011-05-08 Thread Igor Grinberg 
cm-t3730 is basically the same board as cm-t35, but has DM3730 SoC
assembled and therefore some changes are required.

Signed-off-by: Igor Grinberg grinb...@compulab.co.il
Acked-by: Mike Rapoport m...@compulab.co.il
---
v2: Add debug uart entry

 arch/arm/mach-omap2/Kconfig  |2 +-
 arch/arm/mach-omap2/board-cm-t35.c   |   62 +++--
 arch/arm/plat-omap/include/plat/uncompress.h |1 +
 3 files changed, 49 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..920b6bc 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -266,7 +266,7 @@ config MACH_OMAP_ZOOM3
select REGULATOR_FIXED_VOLTAGE
 
 config MACH_CM_T35
-   bool CompuLab CM-T35 module
+   bool CompuLab CM-T35/CM-T3730 modules
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CUS
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 6063be8..c0f6ce0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -524,7 +524,7 @@ static void __init cm_t35_init_early(void)
 }
 
 #ifdef CONFIG_OMAP_MUX
-static struct omap_board_mux board_mux[] __initdata = {
+static struct omap_board_mux cm_t35_common_board_mux[] __initdata = {
/* nCS and IRQ for CM-T35 ethernet */
OMAP3_MUX(GPMC_NCS5, OMAP_MUX_MODE0),
OMAP3_MUX(UART3_CTS_RCTX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
@@ -580,17 +580,12 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(UART1_TX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(UART1_RX, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
 
-   /* DSS */
+   /* common DSS */
OMAP3_MUX(DSS_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_HSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_VSYNC, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_ACBIAS, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA0, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA1, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA2, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA3, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA4, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA5, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
OMAP3_MUX(DSS_DATA6, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA7, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA8, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
@@ -603,12 +598,6 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(DSS_DATA15, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA18, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA19, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA20, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA21, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA22, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
-   OMAP3_MUX(DSS_DATA23, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
 
/* display controls */
OMAP3_MUX(MCBSP1_FSR, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
@@ -621,6 +610,39 @@ static struct omap_board_mux board_mux[] __initdata = {
 
{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
+
+static void cm_t35_mux_init(void)
+{
+   int mux_mode = OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT;
+
+   omap3_mux_init(cm_t35_common_board_mux, OMAP_PACKAGE_CUS);
+
+   if (cpu_is_omap34xx()) {
+   omap_mux_init_signal(gpio_70, mux_mode);
+   omap_mux_init_signal(gpio_71, mux_mode);
+   omap_mux_init_signal(gpio_72, mux_mode);
+   omap_mux_init_signal(gpio_73, mux_mode);
+   omap_mux_init_signal(gpio_74, mux_mode);
+   omap_mux_init_signal(gpio_75, mux_mode);
+   } else if (cpu_is_omap3630()) {
+   mux_mode = OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT;
+   omap_mux_init_signal(sys_boot0, mux_mode);
+   omap_mux_init_signal(sys_boot1, mux_mode);
+   omap_mux_init_signal(sys_boot3, mux_mode);
+   omap_mux_init_signal(sys_boot4, mux_mode);
+   omap_mux_init_signal(sys_boot5, mux_mode);
+   omap_mux_init_signal(sys_boot6, mux_mode);
+   }
+
+   omap_mux_init_signal(dss_data18, mux_mode);
+   omap_mux_init_signal(dss_data19, mux_mode);
+   omap_mux_init_signal(dss_data20, mux_mode);
+   omap_mux_init_signal(dss_data21, mux_mode);
+   omap_mux_init_signal(dss_data22, mux_mode);
+   omap_mux_init_signal(dss_data23, mux_mode);
+}
+#else
+static inline void cm_t35_mux_init(void) {}
 #endif
 
 static struct omap_board_config_kernel cm_t35_config[] __initdata = {
@@ -630,7 +652,7 @@ static void __init