[U-Boot] [PATCH] OMAP3 pandora: update pin mux for rev3 boards
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
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.
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@lists.denx.de http://lists.denx.de/mailman/listinfo/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 NACKI 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-bootWhy 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.
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 NACKI 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-bootWhy 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
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 NACKI 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-bootWhy 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.
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 NACKI 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-bootWhy 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
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.
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
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?
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.
On Fri, Jun 26, 2009 at 12:59 AM, Jean-Christophe PLAGNIOL-VILLARDplagnioj@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.
On 11:43 Fri 26 Jun , Grazvydas Ignotas wrote:
On Fri, Jun 26, 2009 at 12:59 AM, Jean-Christophe PLAGNIOL-VILLARDplagnioj@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.
participants (4)
-
Dirk Behme -
Grazvydas Ignotas -
Jason Kridner -
Jean-Christophe PLAGNIOL-VILLARD