[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
From: David Brownell dbrownell@users.sourceforge.net
Start updating DaVinci board support to reduce dependencies on dm644x chips and EVM-like boards ... beginning with "psc.c", which hosts a bunch of those dependencies:
- Pinmux registers and their contents are SoC-specific, and are also unrelated to the Power and Sleep Controller.
* Declare more of the pinmux registers; * Move their bitfield decls to a public header; * Renaming thse bitfields to be clearly SoC-specific.
- Rename the errata workarounds to be clearly SoC-specific.
- Add a CONFIG_SOC_DM6446; use it to prevent some mux goofs.
- Don't include the I2C support if the I2C driver is not enabled.
Plus two minor bugfixes:
- Correct the PSC_MDSTAT mask ... it's six bits, not five. (Original DM6446 doces said five, FWIW.)
- Correct the PWREMU_MGT mask ... don't set must-be-zero bits.
The simplest always-correct way to handle pinmux is in board_init() calls; or possibly in SoC-specific device setup code. Currently these chips don't have such SoC-specific support.
Signed-off-by: David Brownell dbrownell@users.sourceforge.net --- board/davinci/common/psc.c | 29 ++++++++++++++++------------- board/davinci/common/psc.h | 2 +- board/davinci/dvevm/dvevm.c | 2 +- board/davinci/schmoogie/schmoogie.c | 2 +- board/davinci/sffsdr/sffsdr.c | 2 +- board/davinci/sonata/sonata.c | 2 +- include/asm-arm/arch-davinci/hardware.h | 23 +++++++++++++++++++++-- include/configs/davinci_dvevm.h | 1 + include/configs/davinci_schmoogie.h | 1 + include/configs/davinci_sffsdr.h | 1 + include/configs/davinci_sonata.h | 1 + 11 files changed, 46 insertions(+), 20 deletions(-)
--- a/board/davinci/common/psc.c +++ b/board/davinci/common/psc.c @@ -26,13 +26,6 @@ #include <common.h> #include <asm/arch/hardware.h>
-#define PINMUX0_EMACEN (1 << 31) -#define PINMUX0_AECS5 (1 << 11) -#define PINMUX0_AECS4 (1 << 10) - -#define PINMUX1_I2C (1 << 7) -#define PINMUX1_UART1 (1 << 1) -#define PINMUX1_UART0 (1 << 0)
/* * The DM6446 includes two separate power domains: "Always On" and "DSP". The @@ -57,7 +50,7 @@ void lpsc_on(unsigned int id)
while (REG(PSC_PTSTAT) & 0x01);
- if ((*mdstat & 0x1f) == 0x03) + if ((*mdstat & 0x3f) == 0x03) return; /* Already on and enabled */
*mdctl |= 0x03; @@ -129,10 +122,12 @@ void davinci_enable_uart0(void) lpsc_on(DAVINCI_LPSC_UART0);
/* Bringup UART0 out of reset */ - REG(UART0_PWREMU_MGMT) = 0x0000e003; + REG(UART0_PWREMU_MGMT) = 0x00006001;
+#ifdef CONFIG_SOC_DM6446 /* Enable UART0 MUX lines */ - REG(PINMUX1) |= PINMUX1_UART0; + REG(PINMUX1) |= DM644X_PINMUX1_UART0; +#endif }
#ifdef CONFIG_DRIVER_TI_EMAC @@ -145,20 +140,27 @@ void davinci_enable_emac(void) /* Enable GIO3.3V cells used for EMAC */ REG(VDD3P3V_PWDN) = 0;
+#ifdef CONFIG_SOC_DM6446 /* Enable EMAC. */ - REG(PINMUX0) |= PINMUX0_EMACEN; + REG(PINMUX0) |= DM644X_PINMUX0_EMACEN; +#endif } #endif
+#ifdef CONFIG_DRIVER_DAVINCI_I2C void davinci_enable_i2c(void) { lpsc_on(DAVINCI_LPSC_I2C);
+#ifdef CONFIG_SOC_DM6446 /* Enable I2C pin Mux */ - REG(PINMUX1) |= PINMUX1_I2C; + REG(PINMUX1) |= DM644X_PINMUX1_I2C; +#endif } +#endif
-void davinci_errata_workarounds(void) +#ifdef CONFIG_SOC_DM6446 +void dm6446_errata_workarounds(void) { /* * Workaround for TMS320DM6446 errata 1.3.22: @@ -180,3 +182,4 @@ void davinci_errata_workarounds(void) */ REG(VBPR) = 0x20; } +#endif --- a/board/davinci/common/psc.h +++ b/board/davinci/common/psc.h @@ -27,6 +27,6 @@ void dsp_on(void); void davinci_enable_uart0(void); void davinci_enable_emac(void); void davinci_enable_i2c(void); -void davinci_errata_workarounds(void); +void dm6446_errata_workarounds(void);
#endif /* __PSC_H */ --- a/board/davinci/dvevm/dvevm.c +++ b/board/davinci/dvevm/dvevm.c @@ -44,7 +44,7 @@ int board_init(void) * with pull-up/pull-down resistors) */ REG(PINMUX0) = 0x00000c1f;
- davinci_errata_workarounds(); + dm6446_errata_workarounds();
/* Power on required peripherals */ lpsc_on(DAVINCI_LPSC_GPIO); --- a/board/davinci/schmoogie/schmoogie.c +++ b/board/davinci/schmoogie/schmoogie.c @@ -44,7 +44,7 @@ int board_init(void) * with pull-up/pull-down resistors) */ REG(PINMUX0) = 0x00000c1f;
- davinci_errata_workarounds(); + dm6446_errata_workarounds();
/* Power on required peripherals */ lpsc_on(DAVINCI_LPSC_GPIO); --- a/board/davinci/sffsdr/sffsdr.c +++ b/board/davinci/sffsdr/sffsdr.c @@ -50,7 +50,7 @@ int board_init(void) /* address of boot parameters */ gd->bd->bi_boot_params = LINUX_BOOT_PARAM_ADDR;
- davinci_errata_workarounds(); + dm6446_errata_workarounds();
/* Power on required peripherals */ lpsc_on(DAVINCI_LPSC_GPIO); --- a/board/davinci/sonata/sonata.c +++ b/board/davinci/sonata/sonata.c @@ -43,7 +43,7 @@ int board_init(void) * with pull-up/pull-down resistors) */ REG(PINMUX0) = 0x00000c1f;
- davinci_errata_workarounds(); + dm6446_errata_workarounds();
/* Power on required peripherals */ lpsc_on(DAVINCI_LPSC_GPIO); --- a/include/asm-arm/arch-davinci/hardware.h +++ b/include/asm-arm/arch-davinci/hardware.h @@ -44,6 +44,10 @@ typedef volatile unsigned int * dv_reg_p
/* * Base register addresses + * + * NOTE: some of these DM6446-specific addresses DO NOT WORK + * on other DaVinci chips. Double check them before you try + * using the addresses ... or PSC module identifiers, etc. */ #define DAVINCI_DMA_3PCC_BASE (0x01c00000) #define DAVINCI_DMA_3PTC0_BASE (0x01c10000) @@ -160,7 +164,22 @@ typedef volatile unsigned int * dv_reg_p
/* Miscellania... */ #define VBPR (0x20000020) -#define PINMUX0 (0x01c40000) -#define PINMUX1 (0x01c40004) + +/* NOTE: system control modules are *highly* chip-specific, both + * as to register content (e.g. for muxing) and which registers exist. + */ +#define PINMUX0 0x01c40000 +#define DM644X_PINMUX0_EMACEN (1 << 31) +#define DM644X_PINMUX0_AECS5 (1 << 11) +#define DM644X_PINMUX0_AECS4 (1 << 10) + +#define PINMUX1 0x01c40004 +#define DM644X_PINMUX1_I2C (1 << 7) +#define DM644X_PINMUX1_UART1 (1 << 1) +#define DM644X_PINMUX1_UART0 (1 << 0) + +#define PINMUX2 0x01c40008 +#define PINMUX3 0x01c4000c +#define PINMUX4 0x01c40010
#endif /* __ASM_ARCH_HARDWARE_H */ --- a/include/configs/davinci_dvevm.h +++ b/include/configs/davinci_dvevm.h @@ -59,6 +59,7 @@ #define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 */ #define CONFIG_SYS_HZ_CLOCK 27000000 /* Timer Input clock freq */ #define CONFIG_SYS_HZ 1000 +#define CONFIG_SOC_DM6446 /*====================================================*/ /* EEPROM definitions for Atmel 24C256BN SEEPROM chip */ /* on Sonata/DV_EVM board. No EEPROM on schmoogie. */ --- a/include/configs/davinci_schmoogie.h +++ b/include/configs/davinci_schmoogie.h @@ -34,6 +34,7 @@ #define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 */ #define CONFIG_SYS_HZ_CLOCK 27000000 /* Timer Input clock freq */ #define CONFIG_SYS_HZ 1000 +#define CONFIG_SOC_DM6446 /*=============*/ /* Memory Info */ /*=============*/ --- a/include/configs/davinci_sffsdr.h +++ b/include/configs/davinci_sffsdr.h @@ -35,6 +35,7 @@ #define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 */ #define CONFIG_SYS_HZ_CLOCK 27000000 /* Timer Input clock freq */ #define CONFIG_SYS_HZ 1000 +#define CONFIG_SOC_DM6446 /* EEPROM definitions for Atmel 24LC64 EEPROM chip */ #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2 #define CONFIG_SYS_I2C_EEPROM_ADDR 0x50 --- a/include/configs/davinci_sonata.h +++ b/include/configs/davinci_sonata.h @@ -59,6 +59,7 @@ #define CONFIG_SYS_TIMERBASE 0x01c21400 /* use timer 0 */ #define CONFIG_SYS_HZ_CLOCK 27000000 /* Timer Input clock freq */ #define CONFIG_SYS_HZ 1000 +#define CONFIG_SOC_DM6446 /*====================================================*/ /* EEPROM definitions for Atmel 24C256BN SEEPROM chip */ /* on Sonata/DV_EVM board. No EEPROM on schmoogie. */
On 15:44 Sun 12 Apr , David Brownell wrote:
From: David Brownell dbrownell@users.sourceforge.net
Start updating DaVinci board support to reduce dependencies on dm644x chips and EVM-like boards ... beginning with "psc.c", which hosts a bunch of those dependencies:
Pinmux registers and their contents are SoC-specific, and are also unrelated to the Power and Sleep Controller.
- Declare more of the pinmux registers;
- Move their bitfield decls to a public header;
- Renaming thse bitfields to be clearly SoC-specific.
Rename the errata workarounds to be clearly SoC-specific.
Add a CONFIG_SOC_DM6446; use it to prevent some mux goofs.
Don't include the I2C support if the I2C driver is not enabled.
Plus two minor bugfixes:
Correct the PSC_MDSTAT mask ... it's six bits, not five. (Original DM6446 doces said five, FWIW.)
Correct the PWREMU_MGT mask ... don't set must-be-zero bits.
The simplest always-correct way to handle pinmux is in board_init() calls; or possibly in SoC-specific device setup code. Currently these chips don't have such SoC-specific support.
could you split it in more logical change please
Signed-off-by: David Brownell dbrownell@users.sourceforge.net
board/davinci/common/psc.c | 29 ++++++++++++++++------------- board/davinci/common/psc.h | 2 +- board/davinci/dvevm/dvevm.c | 2 +- board/davinci/schmoogie/schmoogie.c | 2 +- board/davinci/sffsdr/sffsdr.c | 2 +- board/davinci/sonata/sonata.c | 2 +- include/asm-arm/arch-davinci/hardware.h | 23 +++++++++++++++++++++-- include/configs/davinci_dvevm.h | 1 + include/configs/davinci_schmoogie.h | 1 + include/configs/davinci_sffsdr.h | 1 + include/configs/davinci_sonata.h | 1 + 11 files changed, 46 insertions(+), 20 deletions(-)
--- a/board/davinci/common/psc.c +++ b/board/davinci/common/psc.c @@ -26,13 +26,6 @@ #include <common.h> #include <asm/arch/hardware.h>
-#define PINMUX0_EMACEN (1 << 31) -#define PINMUX0_AECS5 (1 << 11) -#define PINMUX0_AECS4 (1 << 10)
-#define PINMUX1_I2C (1 << 7) -#define PINMUX1_UART1 (1 << 1) -#define PINMUX1_UART0 (1 << 0)
/*
- The DM6446 includes two separate power domains: "Always On" and "DSP". The
@@ -57,7 +50,7 @@ void lpsc_on(unsigned int id)
while (REG(PSC_PTSTAT) & 0x01);
- if ((*mdstat & 0x1f) == 0x03)
if ((*mdstat & 0x3f) == 0x03) return; /* Already on and enabled */
*mdctl |= 0x03;
@@ -129,10 +122,12 @@ void davinci_enable_uart0(void) lpsc_on(DAVINCI_LPSC_UART0);
/* Bringup UART0 out of reset */
- REG(UART0_PWREMU_MGMT) = 0x0000e003;
- REG(UART0_PWREMU_MGMT) = 0x00006001;
+#ifdef CONFIG_SOC_DM6446 /* Enable UART0 MUX lines */
- REG(PINMUX1) |= PINMUX1_UART0;
- REG(PINMUX1) |= DM644X_PINMUX1_UART0;
is this the same for all DM6446? and the same question for the I2C and EMAC
it will be better to init pio/mux in devices file without redefined it in the board as done for the at91
Best Regards, J.
On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:44 Sun 12 Apr , David Brownell wrote:
could you split it in more logical change please
I'll fragment it a bit more, ok. later.
@@ -129,10 +122,12 @@ void davinci_enable_uart0(void) lpsc_on(DAVINCI_LPSC_UART0);
/* Bringup UART0 out of reset */
- REG(UART0_PWREMU_MGMT) = 0x0000e003;
- REG(UART0_PWREMU_MGMT) = 0x00006001;
+#ifdef CONFIG_SOC_DM6446 /* Enable UART0 MUX lines */
- REG(PINMUX1) |= PINMUX1_UART0;
- REG(PINMUX1) |= DM644X_PINMUX1_UART0;
is this the same for all DM6446? and the same question for the I2C and EMAC
Yes, that's why I did it that way. PINMUX1 is part of the DM6446 SoC itself, not an FPGA or CPLD, and on other SoCs the bits in that register have different meanings assigned. UART0 might be in PINMUX4, etc.
(Or, if by "this" you meant the PWREMU_MGMT register, that's also a yes ... plus, I looked at docs for other DaVinci chips, and they all have the same definition for that register.)
it will be better to init pio/mux in devices file without redefined it in the board as done for the at91
Agreed, but there's a limit to how much rewriting I can donate. There *are* no dm6446-specific "devices" files in cpu/arm926ejs/davinci yet ... and in fact, most of that "common" code seems more like it belongs over in cpu/.../davinci, not board/davinci/common.
(Re the AT91 code, having one file per device type and SoC member seems absurd to me. One per SoC seems about right.)
My DM355 patches won't need such #ifdeffery.
- Dave
Best Regards, J.
On 23:31 Thu 16 Apr , David Brownell wrote:
On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:44 Sun 12 Apr , David Brownell wrote:
could you split it in more logical change please
I'll fragment it a bit more, ok. later.
@@ -129,10 +122,12 @@ void davinci_enable_uart0(void) lpsc_on(DAVINCI_LPSC_UART0);
/* Bringup UART0 out of reset */
- REG(UART0_PWREMU_MGMT) = 0x0000e003;
- REG(UART0_PWREMU_MGMT) = 0x00006001;
+#ifdef CONFIG_SOC_DM6446 /* Enable UART0 MUX lines */
- REG(PINMUX1) |= PINMUX1_UART0;
- REG(PINMUX1) |= DM644X_PINMUX1_UART0;
is this the same for all DM6446? and the same question for the I2C and EMAC
Yes, that's why I did it that way. PINMUX1 is part of the DM6446 SoC itself, not an FPGA or CPLD, and on other SoCs the bits in that register have different meanings assigned. UART0 might be in PINMUX4, etc.
(Or, if by "this" you meant the PWREMU_MGMT register, that's also a yes ... plus, I looked at docs for other DaVinci chips, and they all have the same definition for that register.)
it will be better to init pio/mux in devices file without redefined it in the board as done for the at91
Agreed, but there's a limit to how much rewriting I can donate. There *are* no dm6446-specific "devices" files in cpu/arm926ejs/davinci yet ... and in fact, most of that "common" code seems more like it belongs over in cpu/.../davinci, not board/davinci/common.
yes but as it's soc specifc it's not the correct location of the code we need to move it to cpu/.../davinci
(Re the AT91 code, having one file per device type and SoC member seems absurd to me. One per SoC seems about right.)
If you prefer in one file is fine too
Best Regards, J.
On Friday 17 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
could you split it in more logical change please
I'll fragment it a bit more, ok. later.
Re-worked version coming in X parts, which also include a patch changing the cpu/arm926ejs/davinci directory to use the conditional build syntax you asked to see:
1 - move psc support from board --> cpu 2 - use conditional syntax, starting with EMAC helpers 3 - split dm644x-specific bits out from "psc" glue 4 - fix two dm644x buglets 5 - add some dm355-specific bits
I'll send a dm335evm patch at some point too, likely after some of the NAND driver updates implied.
On Thu, 16 Apr 2009 23:31:12 -0700 David Brownell david-b@pacbell.net wrote:
On Thursday 16 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 15:44 Sun 12 Apr , David Brownell wrote:
could you split it in more logical change please
I'll fragment it a bit more, ok. later.
@@ -129,10 +122,12 @@ void davinci_enable_uart0(void) lpsc_on(DAVINCI_LPSC_UART0);
/* Bringup UART0 out of reset */
- REG(UART0_PWREMU_MGMT) = 0x0000e003;
- REG(UART0_PWREMU_MGMT) = 0x00006001;
+#ifdef CONFIG_SOC_DM6446 /* Enable UART0 MUX lines */
- REG(PINMUX1) |= PINMUX1_UART0;
- REG(PINMUX1) |= DM644X_PINMUX1_UART0;
is this the same for all DM6446? and the same question for the I2C and EMAC
Yes, that's why I did it that way. PINMUX1 is part of the DM6446 SoC itself, not an FPGA or CPLD, and on other SoCs the bits in that register have different meanings assigned. UART0 might be in PINMUX4, etc.
(Or, if by "this" you meant the PWREMU_MGMT register, that's also a yes ... plus, I looked at docs for other DaVinci chips, and they all have the same definition for that register.)
Hi David, I would suggest renaming (or adding) CONFIG_SOC_DM6446 to CONFIG_SOC_DM644x and also introducing CONFIG_SOC_DM35x, so that we don't have to add a switch statement with all the variants inside one family.
Hugo V.
On Friday 24 April 2009, Hugo Villeneuve wrote:
I would suggest renaming (or adding) CONFIG_SOC_DM6446 to CONFIG_SOC_DM644x
The updated patchset I sent includes CONFIG_SOC_DM644X:
http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
I decided to keep the "X" uppercase for consistency with other CONFIG_* symbols, and Linux.
(Note: that series of five patches goes with two patches which seem not to have merged yet:
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
Given those, the GIT tree would be one patch away from basic dm355 evm support.)
and also introducing CONFIG_SOC_DM35x,
As explained in
http://lists.denx.de/pipermail/u-boot/2009-April/051052.html
That's not a good idea. DM357 is *very* different, while DM335 is just a DM355 without the MPEG/JPEG coprocessor. So again I decided to do exactly what Linux is doing there: use a DM355 conditional, and cope with other chips in that family later, if/when needed.
so that we don't have to add a switch statement with all the variants inside one family.
You mean, inside the "psc.c" code which is really not generic PSC stuff but is really SoC-specific device setup code? That's why I took the approach you see in those two patches above: dm644x.c has the SoC-specific bits (and dm355.c), while psc.c keeps the generic bits.
On 12:33 Fri 24 Apr , David Brownell wrote:
On Friday 24 April 2009, Hugo Villeneuve wrote:
I would suggest renaming (or adding) CONFIG_SOC_DM6446 to CONFIG_SOC_DM644x
The updated patchset I sent includes CONFIG_SOC_DM644X:
http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
I decided to keep the "X" uppercase for consistency with other CONFIG_* symbols, and Linux.
Ack
(Note: that series of five patches goes with two patches which seem not to have merged yet:
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
this is throw Ben tree
Best Regards, J.
On Friday 24 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:33 Fri 24 Apr , David Brownell wrote:
(Note: that series of five patches goes with two patches which seem not to have merged yet:
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
You can expect a basic dm355 evm board patch soonish, then. No NAND support enabled.
Could you clarify the current merge cycle for me, by the way? I know u-boot has switched to 2009.{01,03,05,...} releases, which is a big win from where I sit!, with "rc" tags.
What I'm unclear on is what gets merged for 2009.05 versus later. Are these "next" branches for the '05 release (which hasn't yet hit rc1)? Or for '07 instead?
http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
this is throw Ben tree
Actually Ben just acked it ... I think he was expecting that to go through your ARM tree, since it only affects DaVinci chips (like dm644x, dm646x, dm365) that integrate that 10/100 Ethernet controller.
- Dave
Dear Jean-Christophe,
David Brownell wrote: ...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
....
Could you clarify the current merge cycle for me, by the way? I know u-boot has switched to 2009.{01,03,05,...} releases, which is a big win from where I sit!, with "rc" tags.
What I'm unclear on is what gets merged for 2009.05 versus later. Are these "next" branches for the '05 release (which hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.behme@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote: ...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
....
Could you clarify the current merge cycle for me, by the way? I know u-boot has switched to 2009.{01,03,05,...} releases, which is a big win from where I sit!, with "rc" tags.
What I'm unclear on is what gets merged for 2009.05 versus later. Are these "next" branches for the '05 release (which hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). When the merge window opens again, next goes to master and the fun starts again. I can't say for sure if this is how all branches are handled, though.
regards, Ben
On Friday 24 April 2009, Ben Warren wrote:
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07).
Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged?
My question on that one is how it ever happened in the first place! My thought was that only four boards in the tree seem to use that driver. The AT91sam9 board (whichever) explicitly disables the EEPROM access, as if maybe it were observed to be broken. Two of the other boards are kind of old, maybe not used much. And ISTR counting the fourth board as the one I was poking at, on which the bugfix was developed.
When the merge window opens again, next goes to master and the fun starts again. I can't say for sure if this is how all branches are handled, though.
Hi David,
David Brownell wrote:
On Friday 24 April 2009, Ben Warren wrote:
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07).
Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged?
In this case a pretty good argument could be made that it's a bug fix and not a feature, so can go in 2009.05. Obviously bugs that break builds get more attention than ones that have been in code for a while and nobody noticed. I'll ask Wolfgang to pick it up directly. As you're noticing, how and when patches are picked up is open to many interpretations.
regards, Ben
On Saturday 25 April 2009, Ben Warren wrote:
Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged?
In this case a pretty good argument could be made that it's a bug fix and not a feature, so can go in 2009.05.
Right. It was one of a handful of bugfixes I've sent; I think only one minor one remains (adjusting columns for "mtdpart" output).
Obviously bugs that break builds get more attention than ones that have been in code for a while and nobody noticed. I'll ask Wolfgang to pick it up directly.
Saw that; thanks.
As you're noticing, how and when patches are picked up is open to many interpretations.
Yes. The issue is needing to guess what's up ... so for example, I seem to observe that "merge window closed" must not be the same as "first RC is out", which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work...
- Dave
Dear David Brownell,
In message 200904250105.41050.david-b@pacbell.net you wrote:
Yes. The issue is needing to guess what's up ... so for example, I seem to observe that "merge window closed" must not be the same as "first RC is out", which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work...
Maybe I pout a little more meaning in the words "release candiate". After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a "release candiate".
That's why we still have no "rc" in the current release cycle.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear David Brownell,
In message 200904250105.41050.david-b@pacbell.net you wrote:
Yes. The issue is needing to guess what's up ... so for example, I seem to observe that "merge window closed" must not be the same as "first RC is out", which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work...
Maybe I pout a little more meaning in the words "release candiate". After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a "release candiate".
That's why we still have no "rc" in the current release cycle.
Thanks for this info!
This is *exactly* what I meant in the previous mail with "actively keep people informed what is going on by posting status info to the mailing list".
Thanks and best regards
Dirk
On Saturday 25 April 2009, Wolfgang Denk wrote:
Yes. The issue is needing to guess what's up ... so for example, I seem to observe that "merge window closed" must not be the same as "first RC is out", which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work...
... although that wiki page you referenced does seem to have been updated, on 3-April, to say that the next release got renamed (to 2009.06) and its merge window closed.
I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.)
Maybe I pout a little more meaning in the words "release candiate".
ISTR that Linus has said on occasion that "RC" doesn't mean "release candidate"!
After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a "release candiate".
A Linux RC1 just means "end of merge window, now let's start fixing all the bugs we've just let in."
You're not actually running the "merge window" quite like Linux does; that "backlog" is one differentiator.
That's why we still have no "rc" in the current release cycle.
May be worth reconsidering that, if for no other reason than to make intermedite milestones less opaque ... example, there was no suitably titled announcement in the list archives that the 2009.05 release got re-labeled, but I did eventually find
http://lists.denx.de/pipermail/u-boot/2009-April/050339.html
When the RC label just means "we only integrate bugfixes now", that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know.
- Dave
Dear David,
in message 200904250555.17450.david-b@pacbell.net you wrote:
I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.)
I'm not going to push this information down people's throats. I love living free. Those who want that information can pick it up, those who don't will not get bothered.
Is it really too much to ask that people have a look at the U-Boot web page every now and then? Is it really so difficult to find our when the merge window ends? Just type "u-boot merge window" at google and click on the very first link.
Maybe I pout a little more meaning in the words "release candiate".
ISTR that Linus has said on occasion that "RC" doesn't mean "release candidate"!
He. This is his interpretation, then. I take the freedom to use a different one :-)
You're not actually running the "merge window" quite like Linux does; that "backlog" is one differentiator.
Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former.
That's why we still have no "rc" in the current release cycle.
May be worth reconsidering that, if for no other reason than to make intermedite milestones less opaque ... example, there was no suitably titled announcement in the list archives that the 2009.05 release got re-labeled, but I did eventually find
http://lists.denx.de/pipermail/u-boot/2009-April/050339.html
Yes, that was when we discussed the change.
I edited the web page within the same hour, IIRC.
When the RC label just means "we only integrate bugfixes now", that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know.
Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included.
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de A quarrel is quickly settled when deserted by one party; there is no battle unless there be two. - Seneca
Hi Wolfgang,
On Saturday 25 April 2009, Wolfgang Denk wrote:
in message 200904250555.17450.david-b@pacbell.net you wrote:
I think the questions on this topic reflect a reality that such status updates aren't yet visible enough. (The original question was generic, not ARM-specific.)
I'm not going to push this information down people's throats. I love living free. Those who want that information can pick it up, those who don't will not get bothered.
Is it really too much to ask that people have a look at the U-Boot web page every now and then?
It's not on the front page, which is where for example you'll see status for Linux (www.kernel.org) or GCC (gcc.gnu.org). And it's not visible in the source tree either.
Is it really so difficult to find our when the merge window ends?
By observation: yes.
But also, when you *do* find the Official Statment it does so in reference to Linux processes ... which make that state very easy to find, via the "rc1" git tags.
Just type "u-boot merge window" at google and click on the very first link.
Several other key infrastructure projects make it easy to find that info even without using a search engine.
As a developer, I'd be more likely to look at the GIT summary for status of the GIT tree; its normally the first place to look for such things.
Maybe I pout a little more meaning in the words "release candiate".
ISTR that Linus has said on occasion that "RC" doesn't mean "release candidate"!
He. This is his interpretation, then. I take the freedom to use a different one :-)
You won't find SuSE, RedHat, or Canonical using an rc1 kernel for even a beta distribution ... ;)
You're not actually running the "merge window" quite like Linux does; that "backlog" is one differentiator.
Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former.
And Linux has had years to develop -- and motivate! -- its merge procedures ... it's a different team and process.
Processes need constant tweaking though. And your process page strongly suggests you're using the Linux processes. Hence surprise and confusion when you aren't quite doing so, from folk who use those processes daily.
Easily addressed though ... that web page can point out some differences. Make a few small things *obviously* different, and people will assume that other things may also differ.
When the RC label just means "we only integrate bugfixes now", that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know.
Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included.
I couldn't stop you, of course. All I'm doing is pointing out what others have also pointed out: that the current process is a bit opaque about some key points. And I'm trying to help with some small suggestions.
Since you don't want to use an "rc" tag -- even "rc0"? -- maybe some other git tag could be used to flag "merge window ended". A "-pre", maybe. If there's some obvious indicator there, you wouldn't need to update the wiki except maybe to summarize key points of the process you want to publicize. And contributors wouldn't be scratching their heads, or starting long discussions on the list. ;)
- Dave
Dear David,
In message 200904251153.51380.david-b@pacbell.net you wrote:
Just type "u-boot merge window" at google and click on the very first link.
Several other key infrastructure projects make it easy to find that info even without using a search engine.
Come on and be reasonable. Yes, the current release state is not on the front page. But it is just one click away.
And my reference to google was just because of the argument "difficult to find".
As a developer, I'd be more likely to look at the GIT summary for status of the GIT tree; its normally the first place to look for such things.
I agree fully with this statement. But at the same time I have to point out that this is exactly where our opinions differ:
- You expect that the U-Boot git repository mirrors the current state in the release process, ideally in the same way as Linux handles this.
- For me, the current phase of the release process is not necessarily reflected by a specific tag on the git tree.
This is a (as I think unavoidable) consequence of the existing differences in the prcedures:
* In Linux, top-level maintainers will collect patches in their trees and send pull requests to Linus as soon as the merge window opens.
So far, most U-Boot custodians do not work like that; they send pull requests only at (or even after) the end of the merge window.
* In Linux, the closing of the merge window is maked by the release of the next ="-rc1"
In U-Boot, "-rc1" will only be released after all (or at least most of the) patches that were submitted during the merge window have been applied.
Well, yes, I know. The tiome when I get the pull requests from the custodians is another one - being a major contribution to the former.
And Linux has had years to develop -- and motivate! -- its merge procedures ... it's a different team and process.
Processes need constant tweaking though. And your process page strongly suggests you're using the Linux processes. Hence surprise and confusion when you aren't quite doing so, from folk who use those processes daily.
Well, it's exactly my intention to do things differnetly or to cause confusion :-(
But the thing is, that we (the custodians and me) are not working (yet?) as the Linux maintainers do. I hope we can improve.
I am really thankful for this discussion - IIRC this is the first time ever that suchtopics have been discussed here.
Easily addressed though ... that web page can point out some differences. Make a few small things *obviously* different, and people will assume that other things may also differ.
I tried to make things a bit clearer. Please have a look at http://www.denx.de/wiki/U-Boot/ReleaseCycle and http://www.denx.de/wiki/U-Boot/DevelopmentProcess and let me know what's unclear or missing or needs improvement (or, even better, edit it yourself -it's a wiki after all, where everybody can contribute).
When the RC label just means "we only integrate bugfixes now", that communicates such status with very little work. If folk miss some webpage, or mailing list post, they'll still know.
Please allow me to stick with RC = release candidate, i. e. something that is at least reasonably compile tested and has at least the majority of patches included.
I couldn't stop you, of course. All I'm doing is pointing out what others have also pointed out: that the current process is a bit opaque about some key points. And I'm trying to help with some small suggestions.
I've tried to explain the reasons for the differences on the web page.
Since you don't want to use an "rc" tag -- even "rc0"? -- maybe some other git tag could be used to flag "merge window ended".
Please see above - I feel it would be wrong, as the "merge window closed" state is nothing that has a direct representation in our git tree.
A "-pre", maybe. If there's some obvious indicator there, you wouldn't need to update the wiki except maybe to summarize key points of the process you want to publicize. And contributors wouldn't be scratching their heads, or starting long discussions on the list. ;)
But this discussion is/was a good thing to have!
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
Dear David Brownell,
In message 200904250105.41050.david-b@pacbell.net you wrote:
Yes. The issue is needing to guess what's up ... so for example, I seem to observe that "merge window closed" must not be the same as "first RC is out", which isn't how the Linux process works. But that's the only example I've seen for how the new u-boot cycles should work...
Maybe I pout a little more meaning in the words "release candiate". After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a "release candiate".
That's why we still have no "rc" in the current release cycle.
Best regards,
Wolfgang Denk
Make sense on "rc" not really being a release candidate. How about tagging "mc" for "Merge Closed"?
gvb
Dear Jerry Van Baren,
In message 49F5B6AF.5060606@ge.com you wrote:
Maybe I pout a little more meaning in the words "release candiate". After the end of a merge window, there is usually still a long backlog of patches that has not been merged, and after that there are several rounds of debugging / bug fixing needed. IMO it makes little sense to call anything in this state a "release candiate".
That's why we still have no "rc" in the current release cycle.
...
Make sense on "rc" not really being a release candidate. How about tagging "mc" for "Merge Closed"?
OK - but we have not reached that state either yet, I think. As mentioned before, I have a problem to relate a deadline thing without any direct impact on the code (as the closing of the merge window) to a git tag which represents a certain state. "Merge Closed" definitely represents such a state, but then we could issue "-rc1" as well (using the same free interpretation as in Linux), and it would not indicate what has been asked for: the closinf of the MW.
Best regards,
Wolfgang Denk
Dear David Brownell,
In message 200904250003.51845.david-b@pacbell.net you wrote:
Then I'm curious how that dm9000 EEPROM reading bugfix landed in net/next ... or is the point that the merge window for 2009.05 is still open, since RC1 hasn't yet been tagged?
No. End of merge window and release of -rc1 are completely unrelated.
The merge window for 2009.06 (6, not 5!) was closed on Fri Apr 03, 2009, 23:59:59 CET. We're in bug fixing mode. See also: http://www.denx.de/wiki/view/U-Boot/ReleaseCycle
Best regards,
Wolfgang Denk
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.behme@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote: ...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
....
Could you clarify the current merge cycle for me, by the way? I know u-boot has switched to 2009.{01,03,05,...} releases, which is a big win from where I sit!, with "rc" tags.
What I'm unclear on is what gets merged for 2009.05 versus later. Are these "next" branches for the '05 release (which hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). When the merge window opens again, next goes to master and the fun starts again.
Yes, this is my basic understanding, too.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO they can be handled like bug fixes and applied while rc?
- What's about patches that are sent while open merge window or before, but need some update cycles and are finalized while rc?
- What about patches which are sent immediately after merge window closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
What I personally find essential for patch submitters is the patch dealing by custodian. It should be consistent and by this somehow predictable. This helps patch submitters to get a feeling for 'this patch has only a chance while merge window is open' or 'it's worth sending this patch immediately, it will have a chance to be merge now'.
What confuses me is something like patch A is applied short time after sent, patch B will be eventually applied later to next, patch C gets no comments. With A and B doing the same stuff, and maybe C sent before A.
I can't say for sure if this is how all branches are handled, though.
Let's wait for Jean-Christophe opinion.
Best regards
Dirk
Hi Dirk,
Dirk Behme wrote:
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.behme@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote: ...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
....
Could you clarify the current merge cycle for me, by the way? I know u-boot has switched to 2009.{01,03,05,...} releases, which is a big win from where I sit!, with "rc" tags.
What I'm unclear on is what gets merged for 2009.05 versus later. Are these "next" branches for the '05 release (which hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). When the merge window opens again, next goes to master and the fun starts again.
Yes, this is my basic understanding, too.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO
they can be handled like bug fixes and applied while rc?
I agree that cleanup patches should have more flexibility.
- What's about patches that are sent while open merge window or
before, but need some update cycles and are finalized while rc?
My policy is to look at the timestamp of the first revision. If it's during the merge window, follow-on versions are OK too.
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
Well, since communication about the window state is rare at best, a good argument can be made for flexibility here.
What I personally find essential for patch submitters is the patch dealing by custodian. It should be consistent and by this somehow predictable. This helps patch submitters to get a feeling for 'this patch has only a chance while merge window is open' or 'it's worth sending this patch immediately, it will have a chance to be merge now'.
Sure - consistency would be great. Unfortunately every custodian has his own approach and it's a volunteer workforce. Definitely a goal worth pursuing, though.
What confuses me is something like patch A is applied short time after sent, patch B will be eventually applied later to next, patch C gets no comments. With A and B doing the same stuff, and maybe C sent before A.
Yeah, better and quicker feedback is a goal we should all be working towards. Obviously small, trivial patches are easier to review than new drivers, and so are typically applied more quickly.
I can't say for sure if this is how all branches are handled, though.
Let's wait for Jean-Christophe opinion.
Best regards
Dirk
regards, Ben
Dear Ben Warren,
In message 49F2BED7.9070600@gmail.com you wrote:
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
Well, since communication about the window state is rare at best, a good argument can be made for flexibility here.
While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and then tell me what exactly is not clear enough.
Best regards,
Wolfgang Denk
Dear Wolfgang,
Wolfgang Denk wrote:
Dear Ben Warren,
In message 49F2BED7.9070600@gmail.com you wrote:
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
Well, since communication about the window state is rare at best, a good argument can be made for flexibility here.
While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle
Ups, this link is new to me. Thanks for it :)
and then tell me what exactly is not clear enough.
Yes, you are right, above link is quite clear.
While I didn't know above link, my way to get the recent merge window info was to join IRC and to check the recent topic.
Now, talking above about wiki and IRC above, someone might get the feeling 'and what's about the mailing list'? Maybe we can help people by pushing the available info from IRC/wiki more actively into their inboxes? (*)
I could imagine to have 4 or 5 points were an additional mail (besides IRC/wiki update) would make sense:
- Some days before merge window opens "merge window opens in t days, become ready" - Version z created. Merge window is open. Will be open until ... - Merge window will close in some days, please become ready - Merge window closed now. Next merge window is planned for x, first -rc is planned for y.
And if we want to make it perfect, each -rc could get a similar announcement, too.
Please note that I don't want to say that this didn't happen in the past. I just want to say that there might be the _feeling_ that the info isn't there and that people are too lazy to search for it. And with this more info on the mailing list could help.
Best regards
Dirk
(*) Well, most probably we should do it less often than RMK does post his FAQs on arm-linux-kernel mailing list ;)
Dear Dirk,
In message 49F2F59A.80509@googlemail.com you wrote:
While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle
Ups, this link is new to me. Thanks for it :)
Well, I thought it is easy to find. Even google for "u-boot merge window" lists it as first link.
Now, talking above about wiki and IRC above, someone might get the feeling 'and what's about the mailing list'? Maybe we can help people by pushing the available info from IRC/wiki more actively into their inboxes? (*)
So what about
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/56294
?
I could imagine to have 4 or 5 points were an additional mail (besides IRC/wiki update) would make sense:
- Some days before merge window opens "merge window opens in t days,
become ready"
- Version z created. Merge window is open. Will be open until ...
- Merge window will close in some days, please become ready
- Merge window closed now. Next merge window is planned for x, first
-rc is planned for y.
I think that would be serious overkill. If you are interested in the U-Boot development cycle you can get the information easily - see above. If you need fine-grained reminders, set up a local reminder program.
And if we want to make it perfect, each -rc could get a similar announcement, too.
Would ne not just add a lot of noise to the ML, without any real new information?
If you want detailed information about each action, please feel free and register a RSS feed on the git repository.
Please note that I don't want to say that this didn't happen in the past. I just want to say that there might be the _feeling_ that the info isn't there and that people are too lazy to search for it. And with this more info on the mailing list could help.
Sorry, but I cannot really follow you. All the information you request for seems to be present to me. I have posted this on the ML, and I update the web page pretty promptly.
I don;t know why you missed the information.
(*) Well, most probably we should do it less often than RMK does post his FAQs on arm-linux-kernel mailing list ;)
He. At least his "You disturb me. Go away!" message add some spice ;-)
Best regards,
Wolfgang Denk
Hi Wolfgang,
And if we want to make it perfect, each -rc could get a similar announcement, too.
Would ne not just add a lot of noise to the ML, without any real new information?
If you want detailed information about each action, please feel free and register a RSS feed on the git repository.
I think you mean the RSS feeds of the TWiki, right?
Cheers Detlev
Dear Detlev,
In message m2hc0aqetd.fsf@ohwell.denx.de you wrote:
And if we want to make it perfect, each -rc could get a similar announcement, too.
Would ne not just add a lot of noise to the ML, without any real new information?
If you want detailed information about each action, please feel free and register a RSS feed on the git repository.
I think you mean the RSS feeds of the TWiki, right?
No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in.
Best regards,
Wolfgang Denk
Hi Wolfgang,
And if we want to make it perfect, each -rc could get a similar announcement, too.
Would ne not just add a lot of noise to the ML, without any real new information?
If you want detailed information about each action, please feel free and register a RSS feed on the git repository.
I think you mean the RSS feeds of the TWiki, right?
No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in.
Ok, then I simply fail to understand you, as we all agreed that the state of the project is not to be found in the source repository but on a TWiki web page.
However, let's move on.
Cheers Detlev
Dear Detlev,
In message m2iqkpp49c.fsf@ohwell.denx.de you wrote:
And if we want to make it perfect, each -rc could get a similar announcement, too.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
No, I meant exactly what I wrote - the RSS feed on the git repo (http://git.denx.de/?p=u-boot.git;a=rss , see bottom right corner of the web page) so you get informed when new stuff gets in.
Ok, then I simply fail to understand you, as we all agreed that the state of the project is not to be found in the source repository but on a TWiki web page.
The OP's question was about notification of a "rc" commit in the git repository. This is something you can find out through the git repo's RSS.
Best regards,
Wolfgang Denk
Hi Wolfgang,
Wolfgang Denk wrote:
Dear Ben Warren,
In message 49F2BED7.9070600@gmail.com you wrote:
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
Well, since communication about the window state is rare at best, a good argument can be made for flexibility here.
While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and then tell me what exactly is not clear enough.
I agree that the web site clearly tells the release cycle timeline, and apparently there's lots of chatter on IRC about it, but since the ML is supposedly the primary medium for U-boot information it probably wouldn't hurt to send an e-mail or two. I imagine the technology exists to make such a thing automatic. OTOH I know you're a busy guy and periodically checking a website should be reasonable.
I'm not trying to be a dick - just expressing my point of view. I should probably make more of an effort to use the IRC channel, since it seems that that's where the real action happens.
Best regards,
Wolfgang Denk
cheers, Ben
Wolfgang Denk wrote:
Dear Ben Warren,
In message 49F2BED7.9070600@gmail.com you wrote:
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
Well, since communication about the window state is rare at best, a good argument can be made for flexibility here.
While I agree on your comment on flexibility, I strongly repudiate the statement that the MW state is not clearly communicated. Please have a look at http://www.denx.de/wiki/view/U-Boot/ReleaseCycle and then tell me what exactly is not clear enough.
With the discussion I think we can answer this question now with a short summary:
a) All information is there
b) Some people feel that copying this already available info to mailing list would
" ... just add a lot of noise to the ML, without any real new information .."
c) On the other hand, some people seem to have the feeling that
"status updates aren't yet visible enough"
"that the current process is a bit opaque about some key points"
"... IRC channel ... it seems that that's where the real action happens"
While my feeling tends to (c), too (this is why I e.g. asked for an IRC log), I accept (b) and agree with (a).
Many thanks for this discussion, it already helped a lot, and best regards
Dirk
P.S.: Sorry if I didn't cite your argument or missed an essential one ;)
Dear Dirk,
In message 49F2B6B9.7040300@googlemail.com you wrote:
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). When the merge window opens again, next goes to master and the fun starts again.
Yes, this is my basic understanding, too.
Mine, too. Note however that I will not always and not automatically and not exactly at the end of the merge window create a next branch, but I'm in a somewhat specialposition anyway.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO
they can be handled like bug fixes and applied while rc?
They can, if the custodian accepts it, and.or if there is consensus on the ML.
- What's about patches that are sent while open merge window or
before, but need some update cycles and are finalized while rc?
These should go in. People who put a lot of effort in their planning should not suffer from the fact that a custodian is slow on answering or reviewing their patches. Everything that has been sent to the list before the end of the MW should go in.
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
Patch acceptance is not as critical as a financial transaction, or such. So if there is a slight delay, the custodian is free to turn a blind eye and accept it anyway. The idea of the development process is to make it foreseeable and plannable, but not to become a PITA or to slow down development.
It makes much more sense if an engineer spends another day on testing and cleanup and submits the patch a couple of hours late, instead of submitting a green patch which will waste efforts from several prople during several rounds of review and reposts.
What I personally find essential for patch submitters is the patch dealing by custodian. It should be consistent and by this somehow predictable. This helps patch submitters to get a feeling for 'this patch has only a chance while merge window is open' or 'it's worth sending this patch immediately, it will have a chance to be merge now'.
But this should be clear: if sent while the merge indow is open, new stuff can go in. If the MW is closed, new stuff may go into next (if the respective custodian runs a next branch), otherwise it has to wait until the next MW. Bug fixes can go in any time.
What confuses me is something like patch A is applied short time after sent, patch B will be eventually applied later to next, patch C gets no comments. With A and B doing the same stuff, and maybe C sent before A.
I agree that this is not nice.
In any case, there should be some comment from the respective custodian which makes *clear* what the patch state is. Even a "I have no time now, will look into it later" is better than nothing. Also, if there are remarks to a patch, these should leave no doubt if they were just comments and the patch will be accepted anyway, or if the patch should be reworked/resubmitted, or if the patch was rejected without chance to be included at all.
I can't say for sure if this is how all branches are handled, though.
Let's wait for Jean-Christophe opinion.
Well, his opinion is one thing. But I think we can also expect from Jean-Christophe as ARM custodian that he delivers clear and under- standable feedback to all patch submitters.
Best regards,
Wolfgang Denk
On 09:07 Sat 25 Apr , Dirk Behme wrote:
Hi Ben,
Ben Warren wrote:
Hi Dirk,
On Fri, Apr 24, 2009 at 10:17 PM, Dirk Behme dirk.behme@googlemail.comwrote:
Dear Jean-Christophe,
David Brownell wrote: ...
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
I see that branch now exists ... thanks! :)
....
Could you clarify the current merge cycle for me, by the way? I know u-boot has switched to 2009.{01,03,05,...} releases, which is a big win from where I sit!, with "rc" tags.
What I'm unclear on is what gets merged for 2009.05 versus later. Are these "next" branches for the '05 release (which hasn't yet hit rc1)? Or for '07 instead?
Yes, I have the same questions. I already tried to ask similar, but didn't get an answer.
http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
Maybe my wording was a little unclear?
Dirk
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
My approach is that once the merge window closes, new patches that are not bug fixes go into 'next', which is for the release after the current one (in this case 07). When the merge window opens again, next goes to master and the fun starts again.
Yes, this is my basic understanding, too.
But there are always these ugly details ;)
- What's about patches that remove dead code, unused macros etc. IMHO
they can be handled like bug fixes and applied while rc?
- What's about patches that are sent while open merge window or before,
but need some update cycles and are finalized while rc?
Depends, if the patch is send just before the merge just to have time to finish it during the fix window NO If the patch is really risky it will depends on it Otherwise ok
- What about patches which are sent immediately after merge window
closed (hours - 1 or 2 days)? I already heard something like 'no problem if it comes some hours later, if it is fine then I will still apply it'.
For me when the first version of a is send after the close of the merge and it's not a bug fix, then it will go to the next MW. The only exception will be if the patch come from an announce or a thread discussion and/or really improve U-Boot. Otherwise no exception.
For next branch, it will depend if you have big change announce or big patch series I will create one. Otherwise patch will simply wait until the MW.
For other branch, I'm not really a fan expect if it will help people to work together an a specific task
Best Regards, J.
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090425170829.GA30476@game.jcrosoft.org you wrote:
- What's about patches that are sent while open merge window or before,
but need some update cycles and are finalized while rc?
Depends, if the patch is send just before the merge just to have time to finish it during the fix window NO
How do you reliably find out that this is the case?
Best regards,
Wolfgang Denk
On 19:30 Sat 25 Apr , Wolfgang Denk wrote:
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message 20090425170829.GA30476@game.jcrosoft.org you wrote:
- What's about patches that are sent while open merge window or before,
but need some update cycles and are finalized while rc?
Depends, if the patch is send just before the merge just to have time to finish it during the fix window NO
How do you reliably find out that this is the case?
the patch is not finish and will clearly not work on the hard I've no example except a patch will is more a RFC than a really patch I've in mind
Best Regards, J.
On Saturday 25 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
For me when the first version of a [patch] is send after the close of the merge and it's not a bug fix, then it will go to the next MW. The only exception will be if the patch come from an announce or a thread discussion and/or really improve U-Boot. Otherwise no exception.
Wiki might usefully include this as part of that release cycle page that Wolfgang pointed out:
* Bug fixes coming in after a merge window closes may still be included in the upcoming release if they are high enough priority.
* Other patches coming in after the merge window will be held until the next merge window, possibly in a -next branch of a custodian tree.
* Maintainers may, infrequently, make exceptions to those merge policies.
It'd still be good to make the "merge window ended" state more visible, e.g. through *some* GIT tag. IMNSHO.
- Dave
On Friday 24 April 2009, Dirk Behme wrote:
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
shows it ... "respects SKIP_LOWLEVEL_INIT". Make sure to look at the "next" branch there; you can start from
http://git.denx.de/?p=u-boot/u-boot-arm.git
Then page to the bottom, "heads" --> next, then shortlog. They're all there, except the dm9000 eeprom bugfix.
- Dave
David Brownell wrote:
On Friday 24 April 2009, Dirk Behme wrote:
Btw.: Now that -next exists, I can't find patch linked above in it, though :(
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
shows it ... "respects SKIP_LOWLEVEL_INIT". Make sure to look at the "next" branch there; you can start from
http://git.denx.de/?p=u-boot/u-boot-arm.git
Then page to the bottom, "heads" --> next, then shortlog. They're all there, except the dm9000 eeprom bugfix.
Sorry for being unclear. Yes, your Davinci patches are there. With 'patch linked above' I meant
OMAP3: Remove legacy NAND defines http://lists.denx.de/pipermail/u-boot/2009-April/051111.html
which Jean-Christophe mentioned to apply against -next: "will be apply on the next".
Or did I miss it in
http://git.denx.de/?p=u-boot/u-boot-arm.git;a=shortlog;h=refs/heads/next
again? Please correct me then (and send me some more coffee) ;)
Best regards
Dirk
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 12:33 Fri 24 Apr , David Brownell wrote:
On Friday 24 April 2009, Hugo Villeneuve wrote:
I would suggest renaming (or adding) CONFIG_SOC_DM6446 to CONFIG_SOC_DM644x
The updated patchset I sent includes CONFIG_SOC_DM644X:
http://lists.denx.de/pipermail/u-boot/2009-April/051051.html
I decided to keep the "X" uppercase for consistency with other CONFIG_* symbols, and Linux.
Ack
(Note: that series of five patches goes with two patches which seem not to have merged yet:
http://lists.denx.de/pipermail/u-boot/2009-April/050802.html
the Patch series and this has been apply in the u-boot-arm/next
http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
this is throw Ben tree
Actually, I asked you to pick it up:
http://lists.denx.de/pipermail/u-boot/2009-April/051076.html
If that's a problem let me know.
regards, Ben
On Friday 24 April 2009, Ben Warren wrote:
http://lists.denx.de/pipermail/u-boot/2009-April/050800.html
this is throw Ben tree
Actually, I asked you to pick it up:
http://lists.denx.de/pipermail/u-boot/2009-April/051076.html
If that's a problem let me know.
... and in fact this discussion branch is moot, since I now see that patch got merged into the ARM/next branch.
It's missing your (Ben's) ack though. ;)
- Dave
participants (8)
-
Ben Warren -
David Brownell -
Detlev Zundel -
Dirk Behme -
Hugo Villeneuve -
Jean-Christophe PLAGNIOL-VILLARD -
Jerry Van Baren -
Wolfgang Denk