[U-Boot] [PATCH u-boot git] there are non-DM6446 DaVinci chips
From: David Brownell
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
---
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
#include
-#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;
+#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) = 0x0c1f;
- 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) = 0x0c1f;
- 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 perip
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 > > 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 > --- > 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 > #include > > -#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
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 Thu, 16 Apr 2009 23:31:12 -0700 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.) 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
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 ___ 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, 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
