[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Grazvydas Ignotas]

The update consists of following changes:
- remove configuration of not connected pins, effectively
  leaving them in safe mode.
- remove unused GPIOs, setup newly added ones.
- setup pulls for various GPIOs. Disable pulls for game
  buttons, as they have external pulls.
- SDRC CS change based on recent patch for
  Beagle and Overo.

Old boards are no longer supported, but there was only
small number of test boards made. Updated configuration
is expected to be used for mass production.

CC: Dirk Behme <dirk.behme@googlemail.com>
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
 board/omap3/pandora/pandora.h |   92 +++++++++++++++++------------------------
 1 files changed, 38 insertions(+), 54 deletions(-)

diff --git a/board/omap3/pandora/pandora.h b/board/omap3/pandora/pandora.h
index 8f0838c..5bb190c 100644
--- a/board/omap3/pandora/pandora.h
+++ b/board/omap3/pandora/pandora.h
@@ -107,15 +107,6 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(GPMC_D15),		(IEN  | PTD | DIS | M0)) /*GPMC_D15*/\
  MUX_VAL(CP(GPMC_NCS0),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS0*/\
  MUX_VAL(CP(GPMC_NCS1),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS1*/\
- MUX_VAL(CP(GPMC_NCS2),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS2*/\
- MUX_VAL(CP(GPMC_NCS3),		(IDIS | PTU | EN  | M0)) /*GPMC_nCS3*/\
- MUX_VAL(CP(GPMC_NCS4),		(IDIS | PTU | EN  | M0))\
- MUX_VAL(CP(GPMC_NCS5),		(IDIS | PTD | DIS | M0))\
- MUX_VAL(CP(GPMC_NCS6),		(IEN  | PTD | DIS | M1))\
- MUX_VAL(CP(GPMC_NCS7),		(IEN  | PTU | EN  | M1))\
- MUX_VAL(CP(GPMC_NBE1),		(IEN  | PTD | DIS | M0))\
- MUX_VAL(CP(GPMC_WAIT2),	(IEN  | PTU | EN  | M0))\
- MUX_VAL(CP(GPMC_WAIT3),	(IEN  | PTU | EN  | M0))\
  MUX_VAL(CP(GPMC_CLK),		(IDIS | PTD | DIS | M0)) /*GPMC_CLK*/\
  MUX_VAL(CP(GPMC_NADV_ALE),	(IDIS | PTD | DIS | M0)) /*GPMC_nADV_ALE*/\
  MUX_VAL(CP(GPMC_NOE),		(IDIS | PTD | DIS | M0)) /*GPMC_nOE*/\
@@ -154,21 +145,22 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(DSS_DATA22),	(IDIS | PTD | DIS | M0)) /*DSS_DATA22*/\
  MUX_VAL(CP(DSS_DATA23),	(IDIS | PTD | DIS | M0)) /*DSS_DATA23*/\
  /*GPIO based game buttons*/\
- MUX_VAL(CP(CAM_XCLKA),		(IEN  | PTU | DIS | M4)) /*GPIO_96 - LEFT*/\
- MUX_VAL(CP(CAM_PCLK),		(IEN  | PTU | DIS | M4)) /*GPIO_97 - L2*/\
- MUX_VAL(CP(CAM_FLD),		(IEN  | PTU | DIS | M4)) /*GPIO_98 - RIGHT*/\
- MUX_VAL(CP(CAM_D0),		(IEN  | PTU | DIS | M4)) /*GPIO_99 - MENU*/\
- MUX_VAL(CP(CAM_D1),		(IEN  | PTU | DIS | M4)) /*GPIO_100 - START*/\
- MUX_VAL(CP(CAM_D2),		(IEN  | PTU | DIS | M4)) /*GPIO_101 - Y*/\
- MUX_VAL(CP(CAM_D3),		(IEN  | PTU | DIS | M4)) /*GPIO_102 - L1*/\
- MUX_VAL(CP(CAM_D4),		(IEN  | PTU | DIS | M4)) /*GPIO_103 - DOWN*/\
- MUX_VAL(CP(CAM_D5),		(IEN  | PTU | DIS | M4)) /*GPIO_104 - SELECT*/\
- MUX_VAL(CP(CAM_D6),		(IEN  | PTU | DIS | M4)) /*GPIO_105 - R1*/\
- MUX_VAL(CP(CAM_D7),		(IEN  | PTU | DIS | M4)) /*GPIO_106 - B*/\
- MUX_VAL(CP(CAM_D8),		(IEN  | PTU | DIS | M4)) /*GPIO_107 - R2*/\
- MUX_VAL(CP(CAM_D10),		(IEN  | PTU | DIS | M4)) /*GPIO_109 - X*/\
- MUX_VAL(CP(CAM_D11),		(IEN  | PTU | DIS | M4)) /*GPIO_110 - UP*/\
- MUX_VAL(CP(CAM_XCLKB),		(IEN  | PTU | DIS | M4)) /*GPIO_111 - A*/\
+ MUX_VAL(CP(SYS_BOOT5),		(IEN  | PTD | DIS | M4)) /*GPIO_7 - START*/\
+ MUX_VAL(CP(CAM_XCLKA),		(IEN  | PTD | DIS | M4)) /*GPIO_96 - LEFT*/\
+ MUX_VAL(CP(CAM_PCLK),		(IEN  | PTD | DIS | M4)) /*GPIO_97 - L2*/\
+ MUX_VAL(CP(CAM_FLD),		(IEN  | PTD | DIS | M4)) /*GPIO_98 - RIGHT*/\
+ MUX_VAL(CP(CAM_D0),		(IEN  | PTD | DIS | M4)) /*GPIO_99 - MENU*/\
+ MUX_VAL(CP(CAM_D1),		(IEN  | PTD | DIS | M4)) /*GPIO_100 - START*/\
+ MUX_VAL(CP(CAM_D2),		(IEN  | PTD | DIS | M4)) /*GPIO_101 - Y*/\
+ MUX_VAL(CP(CAM_D3),		(IEN  | PTD | DIS | M4)) /*GPIO_102 - L1*/\
+ MUX_VAL(CP(CAM_D4),		(IEN  | PTD | DIS | M4)) /*GPIO_103 - DOWN*/\
+ MUX_VAL(CP(CAM_D5),		(IEN  | PTD | DIS | M4)) /*GPIO_104 - SELECT*/\
+ MUX_VAL(CP(CAM_D6),		(IEN  | PTD | DIS | M4)) /*GPIO_105 - R1*/\
+ MUX_VAL(CP(CAM_D7),		(IEN  | PTD | DIS | M4)) /*GPIO_106 - B*/\
+ MUX_VAL(CP(CAM_D8),		(IEN  | PTD | DIS | M4)) /*GPIO_107 - R2*/\
+ MUX_VAL(CP(CAM_D10),		(IEN  | PTD | DIS | M4)) /*GPIO_109 - X*/\
+ MUX_VAL(CP(CAM_D11),		(IEN  | PTD | DIS | M4)) /*GPIO_110 - UP*/\
+ MUX_VAL(CP(CAM_XCLKB),		(IEN  | PTD | DIS | M4)) /*GPIO_111 - A*/\
  /*Audio Interface To External DAC (Headphone, Speakers)*/\
  MUX_VAL(CP(MCBSP2_FSX),	(IDIS | PTD | DIS | M0)) /*McBSP2_FSX*/\
  MUX_VAL(CP(MCBSP2_CLKX),	(IDIS | PTD | DIS | M0)) /*McBSP2_CLKX*/\
@@ -183,7 +175,7 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(MMC1_DAT1),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT1*/\
  MUX_VAL(CP(MMC1_DAT2),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT2*/\
  MUX_VAL(CP(MMC1_DAT3),		(IEN  | PTU | EN  | M0)) /*MMC1_DAT3*/\
- MUX_VAL(CP(MMC1_DAT4),		(IEN  | PTD | DIS | M4)) /*GPIO_126 - MMC1_WP*/\
+ MUX_VAL(CP(MMC1_DAT4),		(IEN  | PTU | EN  | M4)) /*GPIO_126 - MMC1_WP*/\
  /*Expansion card 2*/\
  MUX_VAL(CP(MMC2_CLK),		(IDIS | PTD | DIS | M0)) /*MMC2_CLK*/\
  MUX_VAL(CP(MMC2_CMD),		(IEN  | PTU | EN  | M0)) /*MMC2_CMD*/\
@@ -219,13 +211,13 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(MCBSP4_DX),		(IDIS | PTD | DIS | M0)) /*McBSP4_DX*/\
  MUX_VAL(CP(MCBSP4_FSX),	(IEN  | PTD | DIS | M0)) /*McBSP4_FSX*/\
  /*GPIO definitions for muxed pins on AV connector*/\
- MUX_VAL(CP(UART2_CTS),		(IEN  | PTU | EN  | M4)) /*GPIO_144,*/\
+ MUX_VAL(CP(UART2_CTS),		(IEN  | PTD | EN  | M4)) /*GPIO_144,*/\
 							 /*UART2_CTS*/\
- MUX_VAL(CP(UART2_RTS),		(IEN  | PTU | DIS | M4)) /*GPIO_145,*/\
+ MUX_VAL(CP(UART2_RTS),		(IEN  | PTD | EN  | M4)) /*GPIO_145,*/\
 							 /*UART2_RTS*/\
- MUX_VAL(CP(UART2_TX),		(IEN  | PTU | EN  | M4)) /*GPIO_146,*/\
+ MUX_VAL(CP(UART2_TX),		(IEN  | PTD | EN  | M4)) /*GPIO_146,*/\
 							 /*UART2_TX*/\
- MUX_VAL(CP(UART2_RX),		(IEN  | PTD | DIS | M4)) /*GPIO_147,*/\
+ MUX_VAL(CP(UART2_RX),		(IEN  | PTD | EN  | M4)) /*GPIO_147,*/\
 							 /*UART2_RX*/\
  /*Serial Interface (Peripheral boot, Linux console, on AV connector)*/\
  MUX_VAL(CP(UART3_RX_IRRX),	(IEN  | PTD | DIS | M0)) /*UART3_RX*/\
@@ -240,30 +232,26 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(MCBSP1_DR),		(IDIS | PTD | DIS | M4)) /*GPIO_159*/\
 							 /* - LED_WIFI*/\
  /*Switches*/\
- MUX_VAL(CP(MCSPI1_CS2),	(IEN  | PTU | DIS | M4)) /*GPIO_176*/\
+ MUX_VAL(CP(MCSPI1_CS2),	(IEN  | PTU | EN  | M4)) /*GPIO_176*/\
 							 /* - nHOLD_SWITCH*/\
- MUX_VAL(CP(CAM_D9),		(IEN  | PTU | DIS | M4)) /*GPIO_108*/\
+ MUX_VAL(CP(CAM_D9),		(IEN  | PTU | EN  | M4)) /*GPIO_108*/\
 							 /* - nLID_SWITCH*/\
  /*External IRQs*/\
- MUX_VAL(CP(CAM_HS),		(IEN  | PTU | DIS | M4)) /*GPIO_94*/\
+ MUX_VAL(CP(CAM_HS),		(IEN  | PTU | EN  | M4)) /*GPIO_94*/\
 							 /* - nTOUCH_IRQ*/\
  MUX_VAL(CP(ETK_D7_ES2),	(IEN  | PTD | DIS | M4)) /*GPIO_21*/\
 							 /* - WIFI_IRQ*/\
- MUX_VAL(CP(MCBSP1_FSX),	(IEN  | PTD | DIS | M4)) /*GPIO_161*/\
+ MUX_VAL(CP(MCBSP1_FSX),	(IEN  | PTU | EN  | M4)) /*GPIO_161*/\
 							 /* - nIRQ_NUB1*/\
- MUX_VAL(CP(CAM_WEN),		(IEN  | PTU | DIS | M4)) /*GPIO_167*/\
+ MUX_VAL(CP(MCBSP1_CLKX),	(IEN  | PTU | EN  | M4)) /*GPIO_162*/\
 							 /* - nIRQ_NUB2*/\
  /*Various other stuff*/\
- MUX_VAL(CP(CAM_VS),		(IEN  | PTU | DIS | M4)) /*GPIO_95*/\
-							 /* - nTOUCH_BUSY*/\
- MUX_VAL(CP(UART3_CTS_RCTX),	(IEN  | PTD | DIS | M4)) /*GPIO_163*/\
+ MUX_VAL(CP(UART3_CTS_RCTX),	(IEN  | PTU | EN  | M4)) /*GPIO_163*/\
 							 /* - nOC_USB5*/\
- MUX_VAL(CP(MCBSP1_CLKX),	(IDIS | PTD | DIS | M4)) /*GPIO_162*/\
-							 /* - START_ADC*/\
- MUX_VAL(CP(ETK_D8_ES2),	(IEN  | PTD | DIS | M4)) /*GPIO_22*/\
+ MUX_VAL(CP(ETK_D8_ES2),	(IEN  | PTU | EN  | M4)) /*GPIO_22*/\
 							 /* - MSECURE*/\
- MUX_VAL(CP(CAM_STROBE),	(IEN  | PTU | DIS | M4)) /*GPIO_126*/\
-							 /* - HP_DETECT*/\
+ MUX_VAL(CP(CSI2_DY1),		(IEN  | PTD | DIS | M4)) /*GPIO_115*/\
+							 /* - POP_OVERHEAT*/\
  /*External Resets and Enables*/\
  MUX_VAL(CP(ETK_D0_ES2),	(IDIS | PTD | DIS | M4)) /*GPIO_14*/\
 							 /* - nHDPHN_SHUTDOWN*/\
@@ -277,14 +265,13 @@ const omap3_sysinfo sysinfo = {
 							 /* - RESET_NUBS*/\
  MUX_VAL(CP(UART3_RTS_SD),	(IDIS | PTU | EN  | M4)) /*GPIO_164*/\
 							 /* - EN_USB_5V*/\
- /*Unused*/\
- MUX_VAL(CP(HDQ_SIO),		(IEN  | PTU | EN  | M0)) /*HDQ_SIO - NC*/\
- MUX_VAL(CP(CSI2_DX0),		(IEN  | PTD | DIS | M0)) /*CSI2_DX0 - NC*/\
- MUX_VAL(CP(CSI2_DY0),		(IEN  | PTD | DIS | M0)) /*CSI2_DY0 - NC*/\
- MUX_VAL(CP(CSI2_DX1),		(IEN  | PTD | DIS | M0)) /*CSI2_DX1 - NC*/\
- MUX_VAL(CP(CSI2_DY1),		(IEN  | PTD | DIS | M0)) /*CSI2_DY1 - NC*/\
- MUX_VAL(CP(I2C2_SCL),		(IEN  | PTU | EN  | M0)) /*I2C2_SCL - NC*/\
- MUX_VAL(CP(I2C2_SDA),		(IEN  | PTU | EN  | M0)) /*I2C2_SDA - NC*/\
+ /*Spare GPIOs*/\
+ MUX_VAL(CP(GPMC_NCS7),		(IEN  | PTD | EN  | M4)) /*GPIO_58*/\
+ MUX_VAL(CP(GPMC_WAIT2),	(IEN  | PTD | EN  | M4)) /*GPIO_64*/\
+ MUX_VAL(CP(GPMC_WAIT3),	(IEN  | PTD | EN  | M4)) /*GPIO_65*/\
+ MUX_VAL(CP(CAM_VS),		(IEN  | PTU | EN  | M4)) /*GPIO_95*/\
+ MUX_VAL(CP(CAM_WEN),		(IEN  | PTD | EN  | M4)) /*GPIO_167*/\
+ MUX_VAL(CP(HDQ_SIO),		(IEN  | PTD | EN  | M4)) /*GPIO_170*/\
  /*HS USB OTG Port (connects to HSUSB0)*/\
  MUX_VAL(CP(HSUSB0_CLK),	(IEN  | PTD | DIS | M0)) /*HSUSB0_CLK*/\
  MUX_VAL(CP(HSUSB0_STP),	(IDIS | PTU | EN  | M0)) /*HSUSB0_STP*/\
@@ -335,11 +322,8 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(SYS_BOOT2),		(IEN  | PTD | DIS | M4)) /*GPIO_4*/\
  MUX_VAL(CP(SYS_BOOT3),		(IEN  | PTD | DIS | M4)) /*GPIO_5*/\
  MUX_VAL(CP(SYS_BOOT4),		(IEN  | PTD | DIS | M4)) /*GPIO_6*/\
- MUX_VAL(CP(SYS_BOOT5),		(IEN  | PTD | DIS | M4)) /*GPIO_7*/\
  MUX_VAL(CP(SYS_BOOT6),		(IEN  | PTD | DIS | M4)) /*GPIO_8*/\
  MUX_VAL(CP(SYS_OFF_MODE),	(IEN  | PTD | DIS | M0)) /*SYS_OFF_MODE*/\
- MUX_VAL(CP(SYS_CLKOUT1),	(IEN  | PTD | DIS | M4)) /*SYS_CLKOUT1 - NC*/\
- MUX_VAL(CP(SYS_CLKOUT2),	(IEN  | PTD | DIS | M4)) /*SYS_CLKOUT2 - NC*/\
  /*JTAG*/\
  MUX_VAL(CP(JTAG_nTRST),	(IEN  | PTD | DIS | M0)) /*JTAG_nTRST*/\
  MUX_VAL(CP(JTAG_TCK),		(IEN  | PTD | DIS | M0)) /*JTAG_TCK*/\
@@ -412,6 +396,6 @@ const omap3_sysinfo sysinfo = {
  MUX_VAL(CP(D2D_MBUSFLAG),	(IEN  | PTD | DIS | M0)) /*d2d_mbusflag*/\
  MUX_VAL(CP(D2D_SBUSFLAG),	(IEN  | PTD | DIS | M0)) /*d2d_sbusflag*/\
  MUX_VAL(CP(SDRC_CKE0),		(IDIS | PTU | EN  | M0)) /*sdrc_cke0*/\
- MUX_VAL(CP(SDRC_CKE1),		(IDIS | PTD | DIS | M7)) /*sdrc_cke1*/
+ MUX_VAL(CP(SDRC_CKE1),		(IDIS | PTU | EN  | M0)) /*sdrc_cke1*/
 
 #endif
-- 
1.5.6.3

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
> The update consists of following changes:
> - remove configuration of not connected pins, effectively
>   leaving them in safe mode.
> - remove unused GPIOs, setup newly added ones.
> - setup pulls for various GPIOs. Disable pulls for game
>   buttons, as they have external pulls.
> - SDRC CS change based on recent patch for
>   Beagle and Overo.
> 
> Old boards are no longer supported, but there was only
> small number of test boards made. Updated configuration
> is expected to be used for mass production.
If user have old version in possession NACK

this kind of huge update is non bisectable so we do need to use a true mux api
as the kernel lot's of other arch in u-boot

Best Regards,
J.

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jason Kridner]

On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD <
plagnioj@jcrosoft.com> wrote:

> On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
> > The update consists of following changes:
> > - remove configuration of not connected pins, effectively
> >   leaving them in safe mode.
> > - remove unused GPIOs, setup newly added ones.
> > - setup pulls for various GPIOs. Disable pulls for game
> >   buttons, as they have external pulls.
> > - SDRC CS change based on recent patch for
> >   Beagle and Overo.
> >
> > Old boards are no longer supported, but there was only
> > small number of test boards made. Updated configuration
> > is expected to be used for mass production.
> If user have old version in possession NACK


I believe no users who would possibly object have the old version (or any
version) in possession.  Only the core developers ever got these boards.  Is
the expectation to create #ifdef or some sort of auto-detection (unlikely
possible)?


>
>
> this kind of huge update is non bisectable so we do need to use a true mux
> api
> as the kernel lot's of other arch in u-boot


Why is it not bisectable?

Do you have a "true mux api" to suggest?


>
>
> Best Regards,
> J.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Grazvydas Ignotas]

On Fri, Jun 26, 2009 at 12:59 AM, Jean-Christophe
PLAGNIOL-VILLARD<plagnioj@jcrosoft.com> wrote:
> On 14:57 Mon 08 Jun ? ? , Grazvydas Ignotas wrote:
>> The update consists of following changes:
>> - remove configuration of not connected pins, effectively
>> ? leaving them in safe mode.
>> - remove unused GPIOs, setup newly added ones.
>> - setup pulls for various GPIOs. Disable pulls for game
>> ? buttons, as they have external pulls.
>> - SDRC CS change based on recent patch for
>> ? Beagle and Overo.
>>
>> Old boards are no longer supported, but there was only
>> small number of test boards made. Updated configuration
>> is expected to be used for mass production.
> If user have old version in possession NACK

There are only several old prototypes some developers have, there is
really no need to complicate code to support those boards. The old
boards will be replaced anyway as they don't fit into the case.

> this kind of huge update is non bisectable

Yes but current boards don't even work with what is in mainline, so it
doesn't make much sense to bisect anyway.

> so we do need to use a true mux api
> as the kernel lot's of other arch in u-boot

You could be right, but I don't think I can contribute this at the
moment. Current mux api is good enough for single configuration we
need.

First mass production run should start soon, so we need this patch to
enter during this merge window, else all users will have to patch or
use our u-boot fork.

>
> Best Regards,
> J.
>

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:43 Fri 26 Jun     , Grazvydas Ignotas wrote:
> On Fri, Jun 26, 2009 at 12:59 AM, Jean-Christophe
> PLAGNIOL-VILLARD<plagnioj@jcrosoft.com> wrote:
> > On 14:57 Mon 08 Jun ? ? , Grazvydas Ignotas wrote:
> >> The update consists of following changes:
> >> - remove configuration of not connected pins, effectively
> >> ? leaving them in safe mode.
> >> - remove unused GPIOs, setup newly added ones.
> >> - setup pulls for various GPIOs. Disable pulls for game
> >> ? buttons, as they have external pulls.
> >> - SDRC CS change based on recent patch for
> >> ? Beagle and Overo.
> >>
> >> Old boards are no longer supported, but there was only
> >> small number of test boards made. Updated configuration
> >> is expected to be used for mass production.
> > If user have old version in possession NACK
> 
> There are only several old prototypes some developers have, there is
> really no need to complicate code to support those boards. The old
> boards will be replaced anyway as they don't fit into the case.
If only one active user have the board we need to support it
> 
> > this kind of huge update is non bisectable
> 
> Yes but current boards don't even work with what is in mainline, so it
> doesn't make much sense to bisect anyway.
> 
> > so we do need to use a true mux api
> > as the kernel lot's of other arch in u-boot
> 
> You could be right, but I don't think I can contribute this at the
> moment. Current mux api is good enough for single configuration we
> need.
no it's a mess to use and manage and duplicate code

Best Regards,
J.

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:12 Thu 25 Jun     , Jason Kridner wrote:
>    On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
>    <plagnioj@jcrosoft.com> wrote:
> 
>      On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
>      > The update consists of following changes:
>      > - remove configuration of not connected pins, effectively
>      >   leaving them in safe mode.
>      > - remove unused GPIOs, setup newly added ones.
>      > - setup pulls for various GPIOs. Disable pulls for game
>      >   buttons, as they have external pulls.
>      > - SDRC CS change based on recent patch for
>      >   Beagle and Overo.
>      >
>      > Old boards are no longer supported, but there was only
>      > small number of test boards made. Updated configuration
>      > is expected to be used for mass production.
>      If user have old version in possession NACK
> 
>    I believe no users who would possibly object have the old version (or any
>    version) in possession.  Only the core developers ever got these boards. 
>    Is the expectation to create #ifdef or some sort of auto-detection
>    (unlikely possible)?
untill the hardware will be really not anymore use yes please
>     
> 
>      this kind of huge update is non bisectable so we do need to use a true
>      mux api
>      as the kernel lot's of other arch in u-boot
> 
>    Why is it not bisectable?
because your mix cleanup, fixup and new board support
> 
>    Do you have a "true mux api" to suggest?
the same as the kernel one is the best for code sharing

Best Regards,
J.

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Dirk Behme]

Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 19:12 Thu 25 Jun     , Jason Kridner wrote:
>>    On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
>>    <plagnioj@jcrosoft.com> wrote:
>>
>>      On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
>>      > The update consists of following changes:
>>      > - remove configuration of not connected pins, effectively
>>      >   leaving them in safe mode.
>>      > - remove unused GPIOs, setup newly added ones.
>>      > - setup pulls for various GPIOs. Disable pulls for game
>>      >   buttons, as they have external pulls.
>>      > - SDRC CS change based on recent patch for
>>      >   Beagle and Overo.
>>      >
>>      > Old boards are no longer supported, but there was only
>>      > small number of test boards made. Updated configuration
>>      > is expected to be used for mass production.
>>      If user have old version in possession NACK
>>
>>    I believe no users who would possibly object have the old version (or any
>>    version) in possession.  Only the core developers ever got these boards. 
>>    Is the expectation to create #ifdef or some sort of auto-detection
>>    (unlikely possible)?
> untill the hardware will be really not anymore use yes please

If two or three people (from the board manufacturer?) which are more 
familiar with the development board situation than you say "we don't 
need it" then this should be accepted. If nobody uses the older boards 
any more (and this is what I understood they said: "There were only 
few older boards, we know where they are and they are replaced by new 
ones") then there is absolutely no reason to pollute U-Boot with 
support for it. There is no need to add dead code to U-Boot.

We should trust the board maintainers somehow.

>>      this kind of huge update is non bisectable so we do need to use a true
>>      mux api
>>      as the kernel lot's of other arch in u-boot
>>
>>    Why is it not bisectable?
> because your mix cleanup, fixup and new board support
>>    Do you have a "true mux api" to suggest?
> the same as the kernel one is the best for code sharing

OMAP3 pin mux in kernel is totally broken.

Best regards

Dirk

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 07:40 Sun 28 Jun     , Dirk Behme wrote:
> Dear Jean-Christophe,
> 
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 19:12 Thu 25 Jun     , Jason Kridner wrote:
> >>   On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
> >>   <plagnioj@jcrosoft.com> wrote:
> >>
> >>     On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
> >>     > The update consists of following changes:
> >>     > - remove configuration of not connected pins, effectively
> >>     >   leaving them in safe mode.
> >>     > - remove unused GPIOs, setup newly added ones.
> >>     > - setup pulls for various GPIOs. Disable pulls for game
> >>     >   buttons, as they have external pulls.
> >>     > - SDRC CS change based on recent patch for
> >>     >   Beagle and Overo.
> >>     >
> >>     > Old boards are no longer supported, but there was only
> >>     > small number of test boards made. Updated configuration
> >>     > is expected to be used for mass production.
> >>     If user have old version in possession NACK
> >>
> >>   I believe no users who would possibly object have the old version (or any
> >>   version) in possession.  Only the core developers ever got
> >>these boards.    Is the expectation to create #ifdef or some
> >>sort of auto-detection
> >>   (unlikely possible)?
> >untill the hardware will be really not anymore use yes please
> 
> If two or three people (from the board manufacturer?) which are more
> familiar with the development board situation than you say "we don't
> need it" then this should be accepted. If nobody uses the older
> boards any more (and this is what I understood they said: "There
> were only few older boards, we know where they are and they are
> replaced by new ones") then there is absolutely no reason to pollute
> U-Boot with support for it. There is no need to add dead code to
> U-Boot.
No, it's different no people have a board and some people have a board
> 
> We should trust the board maintainers somehow.
It's not me who tell that some people have the board

when you will be in possession of the old version of a board and just because
few people have the board is remove from the mainline you will not be happy.
So no we will support the both
> 
> >>     this kind of huge update is non bisectable so we do need to use a true
> >>     mux api
> >>     as the kernel lot's of other arch in u-boot
> >>
> >>   Why is it not bisectable?
> >because your mix cleanup, fixup and new board support
> >>   Do you have a "true mux api" to suggest?
> >the same as the kernel one is the best for code sharing
> 
> OMAP3 pin mux in kernel is totally broken.
do you really think it's a good reason to have copy & paster everywhere and
not a simple api as at91, davinic and others?
I do not

Best Regards,
J.

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Dirk Behme]

Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 07:40 Sun 28 Jun     , Dirk Behme wrote:
>> Dear Jean-Christophe,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 19:12 Thu 25 Jun     , Jason Kridner wrote:
>>>>   On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
>>>>   <plagnioj@jcrosoft.com> wrote:
>>>>
>>>>     On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
>>>>     > The update consists of following changes:
>>>>     > - remove configuration of not connected pins, effectively
>>>>     >   leaving them in safe mode.
>>>>     > - remove unused GPIOs, setup newly added ones.
>>>>     > - setup pulls for various GPIOs. Disable pulls for game
>>>>     >   buttons, as they have external pulls.
>>>>     > - SDRC CS change based on recent patch for
>>>>     >   Beagle and Overo.
>>>>     >
>>>>     > Old boards are no longer supported, but there was only
>>>>     > small number of test boards made. Updated configuration
>>>>     > is expected to be used for mass production.
>>>>     If user have old version in possession NACK
>>>>
>>>>   I believe no users who would possibly object have the old version (or any
>>>>   version) in possession.  Only the core developers ever got
>>>> these boards.    Is the expectation to create #ifdef or some
>>>> sort of auto-detection
>>>>   (unlikely possible)?
>>> untill the hardware will be really not anymore use yes please
>> If two or three people (from the board manufacturer?) which are more
>> familiar with the development board situation than you say "we don't
>> need it" then this should be accepted. If nobody uses the older
>> boards any more (and this is what I understood they said: "There
>> were only few older boards, we know where they are and they are
>> replaced by new ones") then there is absolutely no reason to pollute
>> U-Boot with support for it. There is no need to add dead code to
>> U-Boot.
> No, it's different no people have a board and some people have a board

What I read is

"no users ... ever got these boards"

I would bet that you have some early (broken?) alpha boards not being 
supported by U-Boot and never used because replaced by fixed 
revisions, too.

>> We should trust the board maintainers somehow.
> It's not me who tell that some people have the board

What I read is

"some internal developers have these boards and they have no problem 
that they are not supported by U-Boot"

> when you will be in possession of the old version of a board and just because
> few people have the board is remove from the mainline you will not be happy.
> So no we will support the both
>>>>     this kind of huge update is non bisectable so we do need to use a true
>>>>     mux api
>>>>     as the kernel lot's of other arch in u-boot
>>>>
>>>>   Why is it not bisectable?
>>> because your mix cleanup, fixup and new board support
>>>>   Do you have a "true mux api" to suggest?
>>> the same as the kernel one is the best for code sharing
>> OMAP3 pin mux in kernel is totally broken.
> do you really think it's a good reason to have copy & paster 

I can't see any copy & paste. What I can see is individual consistent 
pin mux for each board. And that's fine due to different mux 
*necessary* for each board. Not having board specific pin mux in 
kernel is the main reason for broken pin mux in kernel. So what you 
complain about here is the main advantage of U-Boot.

> not a simple api as at91, davinic and others?

I doubt that at91 pin mux api can be used efficiently for OMAP3. But 
I'm happy to be proven the opposite by you :)

What I really think it's not a good reason to make lot of users of a 
final board to depend on an U-Boot fork instead of mainline just 
because of not merging this simple patch.

Best regards

Dirk

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 13:11 Sun 28 Jun     , Dirk Behme wrote:
> Dear Jean-Christophe,
> 
> Jean-Christophe PLAGNIOL-VILLARD wrote:
> >On 07:40 Sun 28 Jun     , Dirk Behme wrote:
> >>Dear Jean-Christophe,
> >>
> >>Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>>On 19:12 Thu 25 Jun     , Jason Kridner wrote:
> >>>>  On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
> >>>>  <plagnioj@jcrosoft.com> wrote:
> >>>>
> >>>>    On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
> >>>>    > The update consists of following changes:
> >>>>    > - remove configuration of not connected pins, effectively
> >>>>    >   leaving them in safe mode.
> >>>>    > - remove unused GPIOs, setup newly added ones.
> >>>>    > - setup pulls for various GPIOs. Disable pulls for game
> >>>>    >   buttons, as they have external pulls.
> >>>>    > - SDRC CS change based on recent patch for
> >>>>    >   Beagle and Overo.
> >>>>    >
> >>>>    > Old boards are no longer supported, but there was only
> >>>>    > small number of test boards made. Updated configuration
> >>>>    > is expected to be used for mass production.
> >>>>    If user have old version in possession NACK
> >>>>
> >>>>  I believe no users who would possibly object have the old version (or any
> >>>>  version) in possession.  Only the core developers ever got
> >>>>these boards.    Is the expectation to create #ifdef or some
> >>>>sort of auto-detection
> >>>>  (unlikely possible)?
> >>>untill the hardware will be really not anymore use yes please
> >>If two or three people (from the board manufacturer?) which are more
> >>familiar with the development board situation than you say "we don't
> >>need it" then this should be accepted. If nobody uses the older
> >>boards any more (and this is what I understood they said: "There
> >>were only few older boards, we know where they are and they are
> >>replaced by new ones") then there is absolutely no reason to pollute
> >>U-Boot with support for it. There is no need to add dead code to
> >>U-Boot.
> >No, it's different no people have a board and some people have a board
> 
> What I read is
> 
> "no users ... ever got these boards"
> 
> I would bet that you have some early (broken?) alpha boards not
> being supported by U-Boot and never used because replaced by fixed
> revisions, too.
They will not have to be mainline until the hardware will be stablized
or you need to understand board revision support
as we need to consider this patch as adding a new board not fixing some pio
mux. It must be clear for anyone that want to bisect code and/or understand what
you have done
> 
> >>We should trust the board maintainers somehow.
> >It's not me who tell that some people have the board
> 
> What I read is
> 
> "some internal developers have these boards and they have no problem
> that they are not supported by U-Boot"
> 
> >when you will be in possession of the old version of a board and just because
> >few people have the board is remove from the mainline you will not be happy.
> >So no we will support the both
> >>>>    this kind of huge update is non bisectable so we do need to use a true
> >>>>    mux api
> >>>>    as the kernel lot's of other arch in u-boot
> >>>>
> >>>>  Why is it not bisectable?
> >>>because your mix cleanup, fixup and new board support
> >>>>  Do you have a "true mux api" to suggest?
> >>>the same as the kernel one is the best for code sharing
> >>OMAP3 pin mux in kernel is totally broken.
> >do you really think it's a good reason to have copy & paster
> 
> I can't see any copy & paste. What I can see is individual
> consistent pin mux for each board. And that's fine due to different
> mux *necessary* for each board. Not having board specific pin mux in
> kernel is the main reason for broken pin mux in kernel. So what you
> complain about here is the main advantage of U-Boot.
> 
> >not a simple api as at91, davinic and others?
> 
> I doubt that at91 pin mux api can be used efficiently for OMAP3. But
> I'm happy to be proven the opposite by you :)
I work on complex pin mux system for other soc and arch for years and you can
simplify it

You can look in U-Boot or in the kernel you do have this kind of
implementation. I do not care of wich api we will have but I do want a
simplest one and one that need to respect these requierements
 - Human readable
 - code sharing
 - only init what is used by U-Boot

> 
> What I really think it's not a good reason to make lot of users of a
> final board to depend on an U-Boot fork instead of mainline just
> because of not merging this simple patch.
please do not mix mainline requirement and production requirement

Best Regards,
J.

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Dirk Behme]

Dear Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 13:11 Sun 28 Jun     , Dirk Behme wrote:
>> Dear Jean-Christophe,
>>
>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 07:40 Sun 28 Jun     , Dirk Behme wrote:
>>>> Dear Jean-Christophe,
>>>>
>>>> Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>> On 19:12 Thu 25 Jun     , Jason Kridner wrote:
>>>>>>  On Thu, Jun 25, 2009 at 4:59 PM, Jean-Christophe PLAGNIOL-VILLARD
>>>>>>  <plagnioj@jcrosoft.com> wrote:
>>>>>>
>>>>>>    On 14:57 Mon 08 Jun     , Grazvydas Ignotas wrote:
>>>>>>    > The update consists of following changes:
>>>>>>    > - remove configuration of not connected pins, effectively
>>>>>>    >   leaving them in safe mode.
>>>>>>    > - remove unused GPIOs, setup newly added ones.
>>>>>>    > - setup pulls for various GPIOs. Disable pulls for game
>>>>>>    >   buttons, as they have external pulls.
>>>>>>    > - SDRC CS change based on recent patch for
>>>>>>    >   Beagle and Overo.
>>>>>>    >
>>>>>>    > Old boards are no longer supported, but there was only
>>>>>>    > small number of test boards made. Updated configuration
>>>>>>    > is expected to be used for mass production.
>>>>>>    If user have old version in possession NACK
>>>>>>
>>>>>>  I believe no users who would possibly object have the old version (or any
>>>>>>  version) in possession.  Only the core developers ever got
>>>>>> these boards.    Is the expectation to create #ifdef or some
>>>>>> sort of auto-detection
>>>>>>  (unlikely possible)?
>>>>> untill the hardware will be really not anymore use yes please
>>>> If two or three people (from the board manufacturer?) which are more
>>>> familiar with the development board situation than you say "we don't
>>>> need it" then this should be accepted. If nobody uses the older
>>>> boards any more (and this is what I understood they said: "There
>>>> were only few older boards, we know where they are and they are
>>>> replaced by new ones") then there is absolutely no reason to pollute
>>>> U-Boot with support for it. There is no need to add dead code to
>>>> U-Boot.
>>> No, it's different no people have a board and some people have a board
>> What I read is
>>
>> "no users ... ever got these boards"
>>
>> I would bet that you have some early (broken?) alpha boards not
>> being supported by U-Boot and never used because replaced by fixed
>> revisions, too.
> They will not have to be mainline until the hardware will be stablized
> or you need to understand board revision support
> as we need to consider this patch as adding a new board not fixing some pio
> mux. It must be clear for anyone that want to bisect code and/or understand what
> you have done
>>>> We should trust the board maintainers somehow.
>>> It's not me who tell that some people have the board
>> What I read is
>>
>> "some internal developers have these boards and they have no problem
>> that they are not supported by U-Boot"
>>
>>> when you will be in possession of the old version of a board and just because
>>> few people have the board is remove from the mainline you will not be happy.
>>> So no we will support the both
>>>>>>    this kind of huge update is non bisectable so we do need to use a true
>>>>>>    mux api
>>>>>>    as the kernel lot's of other arch in u-boot
>>>>>>
>>>>>>  Why is it not bisectable?
>>>>> because your mix cleanup, fixup and new board support
>>>>>>  Do you have a "true mux api" to suggest?
>>>>> the same as the kernel one is the best for code sharing
>>>> OMAP3 pin mux in kernel is totally broken.
>>> do you really think it's a good reason to have copy & paster
>> I can't see any copy & paste. What I can see is individual
>> consistent pin mux for each board. And that's fine due to different
>> mux *necessary* for each board. Not having board specific pin mux in
>> kernel is the main reason for broken pin mux in kernel. So what you
>> complain about here is the main advantage of U-Boot.
>>
>>> not a simple api as at91, davinic and others?
>> I doubt that at91 pin mux api can be used efficiently for OMAP3. But
>> I'm happy to be proven the opposite by you :)
> I work on complex pin mux system for other soc and arch for years and you can
> simplify it
> 
> You can look in U-Boot or in the kernel you do have this kind of
> implementation. I do not care of wich api we will have but I do want a
> simplest one and one that need to respect these requierements
>  - Human readable
>  - code sharing
>  - only init what is used by U-Boot
> 
>> What I really think it's not a good reason to make lot of users of a
>> final board to depend on an U-Boot fork instead of mainline just
>> because of not merging this simple patch.
> please do not mix mainline requirement and production requirement

No, I do mix. Especially if it so simple as here. The main mainline 
requirement is to solve the problems of our users. By providing them a 
good and flexible boot loader.

If we can serve U-Boot users for a production board with mainline as 
easy as here, we should do it. It doesn't help U-Boot (and open source 
in general?) if we don't care about our users. They want working code 
from mainline, and don't care if the same functionality might be done 
with some even more perfect code. And in this special case, we can 
easily support our users with merging this patch in mainline now and 
improve pin mux silently in the next step.

Best regards

Dirk

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Grazvydas Ignotas]

> when you will be in possession of the old version of a board and just because
> few people have the board is remove from the mainline you will not be happy.
> So no we will support the both

Well old boards *do* actually work after these changes, except one
game button and one analog controller (because of changed GPIOs). But
all old boards don't have the analog controllers soldered to them,
except one that I have (there were more but they were disassembled).
Game buttons can't be used with old boards anyway because they don't
fit into the case. So after considering these points I can say my "old
boards are no longer supported" statement is not really valid.

>> What I read is
>>
>> "no users ... ever got these boards"
>>
>> I would bet that you have some early (broken?) alpha boards not
>> being supported by U-Boot and never used because replaced by fixed
>> revisions, too.
> They will not have to be mainline until the hardware will be stablized

It's true, I sent initial patches before hardware was stabilized, but
I thought it would be no problem sending patches like this later,
after all hardware updates. Sorry if I was wrong.

So now I'm going to split this patch and resend, is that ok with you?

[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards

[Jean-Christophe PLAGNIOL-VILLARD]

On 23:07 Sun 28 Jun     , Grazvydas Ignotas wrote:
> > when you will be in possession of the old version of a board and just because
> > few people have the board is remove from the mainline you will not be happy.
> > So no we will support the both
> 
> Well old boards *do* actually work after these changes, except one
> game button and one analog controller (because of changed GPIOs). But
> all old boards don't have the analog controllers soldered to them,
> except one that I have (there were more but they were disassembled).
> Game buttons can't be used with old boards anyway because they don't
> fit into the case. So after considering these points I can say my "old
> boards are no longer supported" statement is not really valid.
> 
> >> What I read is
> >>
> >> "no users ... ever got these boards"
> >>
> >> I would bet that you have some early (broken?) alpha boards not
> >> being supported by U-Boot and never used because replaced by fixed
> >> revisions, too.
> > They will not have to be mainline until the hardware will be stablized
> 
> It's true, I sent initial patches before hardware was stabilized, but
> I thought it would be no problem sending patches like this later,
> after all hardware updates. Sorry if I was wrong.
you was not wrong, you just need to be carefull when you add new hardware revision
support as the code was add for precedent hardware and you will need it to bisect it.

I've seen this kind of problem too much to not be carefull as you can have to
pass hours maybe days to debug it
> 
> So now I'm going to split this patch and resend, is that ok with you?
as you confirm you do not brake the old hardware support
just take a look to not loose the "game button" as the analog controller is
not even availlable

otherwise fine

Best Regards,
J.