* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
@ 2009-06-08 11:57 Grazvydas Ignotas
2009-06-25 21:59 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 13+ messages in thread
From: Grazvydas Ignotas @ 2009-06-08 11:57 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 13+ messages in thread* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-08 11:57 [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards Grazvydas Ignotas
@ 2009-06-25 21:59 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-26 0:12 ` Jason Kridner
2009-06-26 8:43 ` Grazvydas Ignotas
0 siblings, 2 replies; 13+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-25 21:59 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-25 21:59 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-06-26 0:12 ` Jason Kridner
2009-06-27 21:58 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-26 8:43 ` Grazvydas Ignotas
1 sibling, 1 reply; 13+ messages in thread
From: Jason Kridner @ 2009-06-26 0:12 UTC (permalink / raw)
To: u-boot
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-26 0:12 ` Jason Kridner
@ 2009-06-27 21:58 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 5:40 ` Dirk Behme
0 siblings, 1 reply; 13+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-27 21:58 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-27 21:58 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-06-28 5:40 ` Dirk Behme
2009-06-28 9:13 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 13+ messages in thread
From: Dirk Behme @ 2009-06-28 5:40 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-28 5:40 ` Dirk Behme
@ 2009-06-28 9:13 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 11:11 ` Dirk Behme
2009-06-28 20:07 ` Grazvydas Ignotas
0 siblings, 2 replies; 13+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-28 9:13 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-28 9:13 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-06-28 11:11 ` Dirk Behme
2009-06-28 11:50 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 20:07 ` Grazvydas Ignotas
1 sibling, 1 reply; 13+ messages in thread
From: Dirk Behme @ 2009-06-28 11:11 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-28 11:11 ` Dirk Behme
@ 2009-06-28 11:50 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 12:17 ` Dirk Behme
0 siblings, 1 reply; 13+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-28 11:50 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-28 11:50 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2009-06-28 12:17 ` Dirk Behme
0 siblings, 0 replies; 13+ messages in thread
From: Dirk Behme @ 2009-06-28 12:17 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-28 9:13 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 11:11 ` Dirk Behme
@ 2009-06-28 20:07 ` Grazvydas Ignotas
2009-06-28 21:21 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 1 reply; 13+ messages in thread
From: Grazvydas Ignotas @ 2009-06-28 20:07 UTC (permalink / raw)
To: 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
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-28 20:07 ` Grazvydas Ignotas
@ 2009-06-28 21:21 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 13+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-28 21:21 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-25 21:59 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-26 0:12 ` Jason Kridner
@ 2009-06-26 8:43 ` Grazvydas Ignotas
2009-06-27 21:55 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 1 reply; 13+ messages in thread
From: Grazvydas Ignotas @ 2009-06-26 8:43 UTC (permalink / raw)
To: u-boot
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.
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
2009-06-26 8:43 ` Grazvydas Ignotas
@ 2009-06-27 21:55 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 13+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2009-06-27 21:55 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-06-28 21:21 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-08 11:57 [U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards Grazvydas Ignotas
2009-06-25 21:59 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-26 0:12 ` Jason Kridner
2009-06-27 21:58 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 5:40 ` Dirk Behme
2009-06-28 9:13 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 11:11 ` Dirk Behme
2009-06-28 11:50 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-28 12:17 ` Dirk Behme
2009-06-28 20:07 ` Grazvydas Ignotas
2009-06-28 21:21 ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-26 8:43 ` Grazvydas Ignotas
2009-06-27 21:55 ` Jean-Christophe PLAGNIOL-VILLARD
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox