Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
On Thu, 16 Apr 2009 23:31:12 -0700 David Brownell davi...@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) = 0xe003; + REG(UART0_PWREMU_MGMT) = 0x6001; +#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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
On 15:44 Sun 12 Apr , David Brownell wrote: From: David Brownell dbrown...@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 dbrown...@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) = 0xe003; + REG(UART0_PWREMU_MGMT) = 0x6001; +#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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
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) = 0xe003; + REG(UART0_PWREMU_MGMT) = 0x6001; +#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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
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) = 0xe003; + REG(UART0_PWREMU_MGMT) = 0x6001; +#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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
