ARM: DRA7xx: Update support for DRA7xx Soc's

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
 arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
 drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
 drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
 include/configs/omap5_common.h         |    4 ++++
 include/configs/omap5_uevm.h           |    5 -----
 include/palmas.h                       |    6 +++++-
 6 files changed, 49 insertions(+), 20 deletions(-)

drivers/power/palmas.c +1 -1

index 09c832d..1bcff52 100644
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
 	return;
 }
 
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
 {
 	u8 val = 0;
 

drivers/power/palmas.c +6 -0

+
+	if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_CTRL, val)) {
+		printf("tps659038: could not turn on LDO1\n");
+		return 1;
+	}
+

/* I2C chip addresses */
#define PALMAS_CHIP_ADDR 0x48
+#define TPS659038_CHIP_ADDR 0x58

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 16 lines

drivers/power/palmas.c +1 -1

index 09c832d..1bcff52 100644
@@ -28,7 +28,7 @@ void palmas_init_settings(void)
  	return;
  }
 
-int palmas_mmc1_poweron_ldo(void)
+int palmas_mmc1_poweron_ldo9(void)
  {
  	u8 val = 0;
 

@@ -50,3 +50,26 @@ int palmas_mmc1_poweron_ldo(void)
 

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 8 lines

drivers/power/palmas.c +6 -0

  	return 0;
  }
+
+int palmas_mmc1_poweron_ldo1(void)
+{
+	u8 val = 0;
+
+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 66

Quoted 8 lines

drivers/power/palmas.c +7 -0

+
+	if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+		printf("tps659038: could not set LDO1 voltage\n");
+		return 1;
+	}
+
+	/* TURN ON LDO9 */

LDO9?

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 67

Quoted 1 line

drivers/power/palmas.c +1 -0

+	val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;

Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the current status of the LDO). While it makes no harm to try writing to it, this may be misleading about actual LDO operation, and anyway has no sense.

Quoted 7 lines

drivers/power/palmas.c +6 -0

+
+	if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_CTRL, val)) {
+		printf("tps659038: could not turn on LDO1\n");
+		return 1;
+	}
+

[snip]

Quoted 3 lines

/* I2C chip addresses */
#define PALMAS_CHIP_ADDR 0x48
+#define TPS659038_CHIP_ADDR 0x58

Now we have a mess again. The files were recently renamed from twl6035.x to palmas.x, implying that palmas is the generic family name of a series of PMICs. Having TPS659038_CHIP_ADDR above is OK, but then we should have TWL603X_CHIP_ADDR instead of PALMAS_CHIP_ADDR.

Best regards,
Lubomir

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

Quoted 3 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 1 line

drivers/power/palmas.c +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Quoted 10 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 66

Quoted 8 lines

drivers/power/palmas.c +7 -0

+
+	if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+		printf("tps659038: could not set LDO1 voltage\n");
+		return 1;
+	}
+
+	/* TURN ON LDO9 */

LDO9?

Quoted 4 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 67

Quoted 1 line

drivers/power/palmas.c +1 -0

+	val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;

Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the current status of the LDO). While it makes no harm to try writing to it, this may be misleading about actual LDO operation, and anyway has no sense.

Yes, I see a similar update in your patch for LDO9. ll do the same for LDO1 also.

Thanks
Lokesh

Quoted 1 line

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
   arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
   drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
   drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
   include/configs/omap5_common.h         |    4 ++++
   include/configs/omap5_uevm.h           |    5 -----
   include/palmas.h                       |    6 +++++-
   6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 1 line

drivers/power/palmas.c +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Tom, your opinion?

Quoted 14 lines

Quoted 14 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 66

Quoted 8 lines

drivers/power/palmas.c +7 -0

+
+	if (palmas_i2c_write_u8(TPS659038_CHIP_ADDR, LDO1_VOLTAGE, val)) {
+		printf("tps659038: could not set LDO1 voltage\n");
+		return 1;
+	}
+
+	/* TURN ON LDO9 */

LDO9?

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 67

Quoted 1 line

drivers/power/palmas.c +1 -0

+	val = LDO_ON | LDO_MODE_SLEEP | LDO_MODE_ACTIVE;

Bit LDO_ON in all LDOx_CTRL Palmas registers is Read-Only (and reflects the current status of the LDO). While it makes no harm to try writing to it, this may be misleading about actual LDO operation, and anyway has no sense.

Quoted 2 lines

Yes, I see a similar update in your patch for LDO9. ll do the same for LDO1 also.

But are you sure that the TPS659038 has the same LDOx_CTRL register layout as the TWL6035/37? It belongs to the family, yes, but I don't have a Register Manual for this chip... Hope you have checked.

Quoted 4 lines

Thanks
Lokesh

Quoted 1 line

[snip]

Best regards,
Lubo

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 1 line

drivers/power/palmas.c +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Tom, your opinion?

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
   arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
   drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
   drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
   include/configs/omap5_common.h         |    4 ++++
   include/configs/omap5_uevm.h           |    5 -----
   include/palmas.h                       |    6 +++++-
   6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 1 line

drivers/power/palmas.c +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 1 line

drivers/power/palmas.c +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 58

Quoted 1 line

drivers/power/palmas.c +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

drivers/power/palmas.c int palmas_mmc1_poweron_ldo(void) · line 59

Quoted 2 lines

drivers/power/palmas.c +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

Quoted 51 lines · Lubomir Popov

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

Review

Quoted 1 line

(quoted diff) +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

Review

Quoted 2 lines

(quoted diff) +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Quoted 12 lines

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to.

Hi Tom,

Quoted 66 lines · Tom Rini

Quoted 51 lines · Lubomir Popov

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
   arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
   drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
   drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
   include/configs/omap5_common.h         |    4 ++++
   include/configs/omap5_uevm.h           |    5 -----
   include/palmas.h                       |    6 +++++-
   6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

Review

Quoted 1 line

(quoted diff) +1 -0

+	/* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

Review

Quoted 2 lines

(quoted diff) +1 -0

+	val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Quoted 12 lines

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

Quoted 4 lines

OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to.

OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming:

- Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions;

or, alternatively:

- Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs.
Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code.

And this generic palmas_mmc1_poweron_ldo() function would be called by another generic function, e.g. omap_sdmmc_poweron(), located in the board file, only if needed by the particular hardware. omap_sdmmc_poweron(), on its hand, is the function that is to be called from within the pbias routines in omap_hsmmc.c, and not the hardware- dependant functions directly. So we get the abstraction.

What do you think? Lokesh, your opinion?

Regards,
Lubo

Hi Lubomir,

Quoted 5 lines · Lubomir Popov

Hi Tom,

Quoted 2 lines · Tom Rini

On Wed, Jun 05, 2013 at 11:03:26AM +0300, Lubomir Popov wrote:

Quoted 17 lines

Quoted 5 lines

OK, lets see. That so lets keep your patch as-is, since we've now got -ffunction-sections/-fdata-sections/--gc-sections on ARM for main U-Boot, these small things won't hurt like they used to.

OK, but then I would like to do some cleanup first - remove the audio power stuff (shall have it in my board file), as well as either sort out the function naming:

- Those functions that are specific to a SoC+PMIC combination are named e.g. twl603x_... or tps659038_... so that they explicitly indicate the hardware that they are working with (actually almost all functions are such). This is however sort of regression, and requires fixes in the files calling these functions;

or, alternatively:

Quoted 7 lines

- Introduce generic functions with fixed names, palmas_bla_bla(), sort of wrappers, which in their bodies perform the appropriate action based on the #ifdefs defining the platform hardware (where we could also define the particular LDO which for example a palmas_mmc1_poweron_ldo() generic function would manipulate). Drawback: again #ifdefs.
Advantage: single place where this stuff is located, and where other PMIC/LDO combinations can be added without affecting other code.

I think, we can have function pointers for and can populate data in the beginning or from board file based on Soc, similarly what we did for prcm structure.
Regards,
Lokesh

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

Quoted 1 line

+ /* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

Quoted 2 lines

+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

Quoted 51 lines · Lubomir Popov

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

Quoted 1 line

+ /* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

Quoted 2 lines

+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Quoted 13 lines

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

I hate this code for many reasons -
a) hsmmc is used on many OMAP and DM platforms to my knowledge.
b) what is being done here is to power on the LDO supplying MMC.

The implementation *should* be board specific! not an #ifdef madness which works only on TI platforms.

Regards,
Nishanth Menon

Hi Nishanth,

Quoted 66 lines · Nishanth Menon

Quoted 51 lines · Lubomir Popov

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

Quoted 1 line

+ /* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

Quoted 2 lines

+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Quoted 13 lines

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

Quoted 3 lines

I hate this code for many reasons -
a) hsmmc is used on many OMAP and DM platforms to my knowledge.
b) what is being done here is to power on the LDO supplying MMC.

Sorry, but I can't get if hsmmc is discussed here, or power.

For OMAP5+TWL603x the LDO powering MMC (actually the removable card interface only; eMMC is another story) is turned on automatically at power-on by the PMIC sequencer, with a default voltage and mode -- otherwise we would not be able to boot from a card (ROM code does not touch the PMIC at all). We are talking here about the possibility to have additional control over this LDO, which should be board-specific, I agree. On the OMAP5 boards, for example, the call to palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not turn on LDO9 - it is on at this moment anyway. The call just makes it switch from the default bypass mode (with Vout = Vin = 3.3 V) to regulation mode and Vout = 3.0 V. Why is this done is yet another question; to me it seems useless (and possibly wrong) when the card is powered with a fixed voltage of 3.3 V.
Therefore it seems reasonable to count on the PMIC defaults and remove this call from omap_hsmmc altogether, thus disengaging the PMIC driver from hsmmc, at least for OMAP5.

For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers both the OMAP interface and the card socket, and in addition can automatically power off the MMC LDO upon detecting card removal. ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V (it starts by default at 1.8 V), but only if booting from a card. So here the call to PMIC driver should stay.

Other OMAPs and derivatives - other scenarios.

Anyway, omap_hsmmc.c is built for TI platforms only. If you mean the #ifdefs here, yes, things could be cleaned up by moving the SoC- specific pbias stuff to the corresponding board files (with the expense of redundancy), but this is quite an amount of work... I'm not volunteering... ;) Moreover, this particular patch is not mine.

Quoted 98 lines

Hi Nishanth,

Quoted 66 lines · Nishanth Menon

Quoted 51 lines · Lubomir Popov

Hi Tom,

Quoted 43 lines · Tom Rini

Quoted 42 lines · Lubomir Popov

Hi Lokesh,

Quoted 20 lines

Hi Lubomir,

Quoted 18 lines · Lubomir Popov

Hi Lokesh,

Quoted 15 lines · Lokesh Vutla

From: Balaji T K <[email protected]>

add dra mmc pbias support and ldo1 power on

Signed-off-by Balaji T K <[email protected]>

Signed-off-by Lokesh Vutla <[email protected]>

---
  arch/arm/include/asm/arch-omap5/omap.h |    3 ++-
  drivers/mmc/omap_hsmmc.c               |   26 ++++++++++++++------------
  drivers/power/palmas.c                 |   25 ++++++++++++++++++++++++-
  include/configs/omap5_common.h         |    4 ++++
  include/configs/omap5_uevm.h           |    5 -----
  include/palmas.h                       |    6 +++++-
  6 files changed, 49 insertions(+), 20 deletions(-)

[snip]

Quoted 10 lines

Quoted 3 lines

Quoted 1 line

+ /* set LDO9 TWL6035 to 3V */

LDO9? TWL6035? If this function is used on the DRA7xx boards only (with TPS659038), you should add some comment above.

Ok ll add the comment.

Quoted 5 lines

Quoted 2 lines

+ val = 0x2b; /* (3 - 0.9) * 20 + 1 */

Why not use definitions for the voltage? You could take them from
http://patchwork.ozlabs.org/patch/244103/ where some values are defined.

Yes, Ill rebase this patch on top of your patch and use those defines.

Please be aware that my above mentioned patch has not been reviewed/ tested/acked/nacked/whatever by nobody (except possibly a quick look by Nishanth Menon, who had some objections). I wrote it when bringing up a custom OMAP5 board, and most probably it shall not go into mainline in its current form, if ever. I gave it only as an example of how things could be done cleaner. Feel free to use the code as you wish, but I'm afraid that applying it as a patch to your tree and basing upon it might run you into problems when you later sync with mainline.

Quoted 5 lines

Quoted 1 line

Tom, your opinion?

OK, so at the time it was "nothing will really use this code except test functions". Looks like we have a use for mmc1_ldo9 code at least, so lets rework the first patch for adding that + cleanups wrt constants.

Quoted 13 lines

Well, I'm not quite sure that this LDO9 function would be the only one used (or LDO1 on the DRA7xx board). Judging from omapboot for the OMAP5 boards for example, SMPS7 (it delivers the common 1.8 V I/O supply) is set to 'Forced PWM' mode in order to reduce board noise - there sure has been a reason to do so and sacrifice converter efficiency. Therefore I added similar functionality in my patch to the Palmas driver (and am explicitly calling it in my board init).
The option to bypass LDO9 on OMAP5+TWL603x boards seems quite mandatory as well, if hardware is designed such that the SD card socket has a separate fixed 3.3 V supply which also powers the LDO9 input (the uEVM for example). On the DRA7xx+TPS659038 board the power scheme is different and this does not apply.

Quoted 3 lines

I hate this code for many reasons -
a) hsmmc is used on many OMAP and DM platforms to my knowledge.
b) what is being done here is to power on the LDO supplying MMC.

Sorry, but I can't get if hsmmc is discussed here, or power.

For OMAP5+TWL603x the LDO powering MMC (actually the removable card interface only; eMMC is another story) is turned on automatically at power-on by the PMIC sequencer, with a default voltage and mode -- otherwise we would not be able to boot from a card (ROM code does not touch the PMIC at all). We are talking here about the possibility to have additional control over this LDO, which should be board-specific, I agree. On the OMAP5 boards, for example, the call to palmas_mmc1_poweron_ldo() from within omap_hsmmc actually does not turn on LDO9 - it is on at this moment anyway. The call just makes it switch from the default bypass mode (with Vout = Vin = 3.3 V) to regulation mode and Vout = 3.0 V. Why is this done is yet another question; to me it seems useless (and possibly wrong) when the card is powered with a fixed voltage of 3.3 V.
Therefore it seems reasonable to count on the PMIC defaults and remove this call from omap_hsmmc altogether, thus disengaging the PMIC driver from hsmmc, at least for OMAP5.

For OMAP4 things are somewhat different. Here the TWL6030 PMIC powers both the OMAP interface and the card socket, and in addition can automatically power off the MMC LDO upon detecting card removal. ROM code *does* access the MMC LDO to turn it on and set it to 3.0 V (it starts by default at 1.8 V), but only if booting from a card. So here the call to PMIC driver should stay.

Quoted 8 lines

Other OMAPs and derivatives - other scenarios.

Anyway, omap_hsmmc.c is built for TI platforms only. If you mean the #ifdefs here, yes, things could be cleaned up by moving the SoC- specific pbias stuff to the corresponding board files (with the expense of redundancy), but this is quite an amount of work... I'm not volunteering... ;) Moreover, this particular patch is not mine.

I understand approximately why we do this, but there are more than a single MMC on OMAP, in general. and different platforms use different PMICs
I am just looking at http://patchwork.ozlabs.org/patch/248928/
and I am like - wait a minute, how many #ifdef #else is one going to add per MMC/board? switching on LDOx meant for MMC1 will work for MMC2?
makes no sense to me.

is'nt better for struct mmc to have a function pointer which is populated by the board(depending on PMIC) to setup voltage necessary?

the trouble I have is not that omap_hsmmc is meant for TI SoCs. I get that. but the fact that the code is starting to look so convoluted that it will ONLY work on TI boards!!! I dont get that!

Regards,
Nishanth Menon

This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html

Testing:
Boot tested on DRA752 ES1.0, OMAP5432 ES2.0, OMAP4460 PANDA Verified MAKEALL for armv7 and omap boards.

Changes from v1:
* Addressed comments from Tom Rini

Balaji T K (1):
mmc: omap_hsmmc: add mmc1 pbias, ldo1

Lokesh Vutla (6):
ARM: DRA7xx: Add control id code for DRA7xx
ARM: DRA7xx: power Add support for tps659038 PMIC
ARM: DRA7xx: clocks: Fixing i2c_init for PMIC
ARM: DRA7xx: Do not enable srcomp for DRA7xx Soc's
ARM: DRA7xx: Update pinmux data
ARM: DRA7xx: clocks: Update PLL values

Nishanth Menon (1):
ARM: OMAP5: DRA7xx: support class 0 optimized voltages

Sricharan R (4):
ARM: DRA7xx: Change the Debug UART to UART1
ARM: DRA7xx: Correct the SYS_CLK to 20MHZ
ARM: DRA7xx: Correct SRAM END address
ARM: DRA7xx: EMIF: Change settings required for EVM board

  arch/arm/cpu/armv7/omap-common/clocks-common.c |   86 +++++++++---
  arch/arm/cpu/armv7/omap-common/emif-common.c   |   26 +++-
  arch/arm/cpu/armv7/omap-common/hwinit-common.c |    2 -
  arch/arm/cpu/armv7/omap-common/timer.c         |    1 +
  arch/arm/cpu/armv7/omap5/hw_data.c             |  156 ++++++++++++++++------
  arch/arm/cpu/armv7/omap5/hwinit.c              |   22 ++-
  arch/arm/cpu/armv7/omap5/prcm-regs.c           |    2 +
  arch/arm/cpu/armv7/omap5/sdram.c               |  170 ++++++++++++++++++++++--
  arch/arm/include/asm/arch-omap4/clock.h        |    6 +-
  arch/arm/include/asm/arch-omap4/sys_proto.h    |    1 +
  arch/arm/include/asm/arch-omap5/clock.h        |   61 ++++++++-
  arch/arm/include/asm/arch-omap5/mux_dra7xx.h   |    7 +-
  arch/arm/include/asm/arch-omap5/omap.h         |   26 ++--
  arch/arm/include/asm/arch-omap5/sys_proto.h    |    1 +
  arch/arm/include/asm/emif.h                    |   12 +-
  arch/arm/include/asm/omap_common.h             |   26 +++-
  board/ti/dra7xx/mux_data.h                     |   38 ++++--
  drivers/mmc/omap_hsmmc.c                       |   26 ++--
  drivers/power/palmas.c                         |   25 +++-
  include/configs/dra7xx_evm.h                   |    8 +-
  include/configs/omap4_common.h                 |    4 -
  include/configs/omap5_common.h                 |   12 +-
  include/configs/omap5_uevm.h                   |    7 +-
  include/palmas.h                               |    6 +-
  24 files changed, 590 insertions(+), 141 deletions(-)

Hi Tom,

Quoted 4 lines · Lokesh Vutla

This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html

Do you have any further comments on this series ?

Quoted 6 lines · Lokesh Vutla

Hi Tom,

Quoted 4 lines · Lokesh Vutla

This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html

Quoted 1 line

Do you have any further comments on this series ?

Sorry, everything looks good, and I think Lubomir's patch for MMC stuff (which means we drop 9/12 here, right?) should settle everything else out.

Hi Tom,

Quoted 7 lines · Tom Rini

Quoted 6 lines · Lokesh Vutla

Hi Tom,

Quoted 4 lines · Lokesh Vutla

This series update support for DRA7xx family Socs and the data for DRA752 ES1.0 soc.
This is on top of my recent Misc cleanup series:
http://u-boot.10912.n7.nabble.com/PATCH-V2-0-4-ARM-OMAP2-Misc-Cleanup-tt155949.html

Quoted 5 lines

Quoted 1 line

Do you have any further comments on this series ?

Sorry, everything looks good, and I think Lubomir's patch for MMC stuff (which means we drop 9/12 here, right?) should settle everything else out.

Please be aware that my patch (latest in http://patchwork.ozlabs.org/patch/249405/)
fixes the two palmas.* files only, while Lokesh's patch 9/12 affected 6 files in total (including these two).

Lokesh, unfortunately you shall have to repost 9/12 after rebasing over my stuff, if it is applied.

Regards,
Lubo