Skip to contentSkip to conversation

spl/Makefile: Add drivers/power/pmic/libpmic to CONFIG_SPL_POWER_SUPPORT

PATCH New Tom Rini 3 participants 14 messages Aug 14, 2013 – Aug 28, 2013 Arm (32-bit)

lore
Share & tools
lore

Tom Rini

author
#0 lore raw

PATCH v2 1/6 spl/Makefile: Add drivers/power/pmic/libpmic to CONFIG_SPL_POWER_SUPPORT

We may need to access the PMIC code in SPL, when we have power set.

---
 spl/Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
spl/Makefile +2 -1
index 6e5299b..dff1345 100644
@@ -72,7 +72,8 @@ LIBS-$(CONFIG_SPL_SPI_FLASH_SUPPORT) += drivers/mtd/spi/libspi_flash.o
 LIBS-$(CONFIG_SPL_SPI_SUPPORT) += drivers/spi/libspi.o
 LIBS-$(CONFIG_SPL_FAT_SUPPORT) += fs/fat/libfat.o
 LIBS-$(CONFIG_SPL_LIBGENERIC_SUPPORT) += lib/libgeneric.o
-LIBS-$(CONFIG_SPL_POWER_SUPPORT) += drivers/power/libpower.o
+LIBS-$(CONFIG_SPL_POWER_SUPPORT) += drivers/power/libpower.o \
+	drivers/power/pmic/libpmic.o
 LIBS-$(CONFIG_SPL_NAND_SUPPORT) += drivers/mtd/nand/libnand.o
 LIBS-$(CONFIG_SPL_ONENAND_SUPPORT) += drivers/mtd/onenand/libonenand.o
 LIBS-$(CONFIG_SPL_DMA_SUPPORT) += drivers/dma/libdma.o
Signature · 1 line
1.7.9.5
author
#1 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109 ++++++++++++++++++++++++++++++++++++
 include/power/tps65217.h           |   79 ++++++++++++++++++++++++++
 3 files changed, 189 insertions(+)
 create mode 100644 drivers/power/pmic/pmic_tps65217.c
 create mode 100644 include/power/tps65217.h
drivers/power/pmic/Makefile +1 -0
index f054470..ac2b625 100644
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
drivers/power/pmic/pmic_tps65217.c new file +109 -0

109 lines not on this page · raw message

include/power/tps65217.h new file +79 -0

79 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#2 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

Hi Tom, Greg

Quoted 62 lines

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109
++++++++++++++++++++++++++++++++++++
include/power/tps65217.h           |   79 ++++++++++++++++++++++++++
3 files changed, 189 insertions(+) create mode 100644

drivers/power/pmic/pmic_tps65217.c create mode 100644 include/power/tps65217.h

drivers/power/pmic/Makefile +1 -0
index f054470..ac2b625 100644
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65217.c new file mode 100644 index 0000000..36e9024

drivers/power/pmic/pmic_tps65217.c new file +13 -0
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65217.h>
+
+/**
+ * tps65217_reg_read() - Generic function that can read a TPS65217

register
+ * @src_reg: Source register address
+ * @src_val: Address of destination variable
+ * @return: 0 for success, not 0 on failure.
+ */

drivers/power/pmic/pmic_tps65217.c line 20

Quoted 3 lines
drivers/power/pmic/pmic_tps65217.c new file +3 -0
+int tps65217_reg_read(uchar src_reg, uchar *src_val)
+{
+	return i2c_read(TPS65217_CHIP_PM, src_reg, 1, src_val, 1);

Would it be possible to comply with pmic driver model? It can be found at ./drivers/power/power_core.c

Moreover the generic function for reading/writing data to/from pmic is already defined at ./drivers/power/power_{i2c|spi}.c

Maybe it would be possible to use/modify the already available code?

Quoted 16 lines
drivers/power/pmic/pmic_tps65217.c new file +4 -0
+}
+
+/**
+ *  tps65217_reg_write() - Generic function that can write a

TPS65217 PMIC
+ * register or bit field regardless of
protection
+ * level.
+ *
+ * @prot_level: Register password protection. Use
+ * TPS65217_PROT_LEVEL_NONE,
+ * TPS65217_PROT_LEVEL_1 or
TPS65217_PROT_LEVEL_2

+ *  @dest_reg:		   Register address to write.
+ *  @dest_val:		   Value to write.
+ *  @mask:		   Bit mask (8 bits) to be applied.
Quoted 9 lines

Function will only
+ * change bits that are set in the bit
mask.
+ *
+ * @return: 0 for success, not 0 on failure, as
per the i2c API
+ */
+int tps65217_reg_write(uchar prot_level, uchar dest_reg, uchar dest_val,

The same as above.

Quoted 53 lines
drivers/power/pmic/pmic_tps65217.c new file +8 -0
+		       uchar mask)
+{
+	uchar read_val;
+	uchar xor_reg;
+	int ret;
+
+	/*
+	 * If we are affecting only a bit field, read dest_reg and

apply the

drivers/power/pmic/pmic_tps65217.c new file +4 -0
+	 * mask
+	 */
+	if (mask != TPS65217_MASK_ALL_BITS) {
+		ret = i2c_read(TPS65217_CHIP_PM, dest_reg, 1,

&read_val, 1);

drivers/power/pmic/pmic_tps65217.c new file +10 -0
+		if (ret)
+			return ret;
+		read_val &= (~mask);
+		read_val |= (dest_val & mask);
+		dest_val = read_val;
+	}
+
+	if (prot_level > 0) {
+		xor_reg = dest_reg ^ TPS65217_PASSWORD_UNLOCK;
+		ret = i2c_write(TPS65217_CHIP_PM, TPS65217_PASSWORD,

1,

drivers/power/pmic/pmic_tps65217.c new file +11 -0
+				&xor_reg, 1);
+		if (ret)
+			return ret;
+	}
+
+	ret = i2c_write(TPS65217_CHIP_PM, dest_reg, 1, &dest_val, 1);
+	if (ret)
+		return ret;
+
+	if (prot_level == TPS65217_PROT_LEVEL_2) {
+		ret = i2c_write(TPS65217_CHIP_PM, TPS65217_PASSWORD,

1,

drivers/power/pmic/pmic_tps65217.c new file +5 -0
+				&xor_reg, 1);
+		if (ret)
+			return ret;
+
+		ret = i2c_write(TPS65217_CHIP_PM, dest_reg, 1,

&dest_val, 1);

drivers/power/pmic/pmic_tps65217.c new file +9 -0
+		if (ret)
+			return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * tps65217_voltage_update() - Function to change a voltage level,

as this

Quoted 8 lines

+ * is a multi-step process.
+ * @dc_cntrl_reg: DC voltage control register to
change.
+ * @volt_sel: New value for the voltage
register
+ * @return: 0 for success, not 0 on failure.
+ */
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel)

Maybe pmic_set_output() method from ./drivers/power/power_core.c can be reused?

Quoted 64 lines
drivers/power/pmic/pmic_tps65217.c new file +8 -0
+{
+	if ((dc_cntrl_reg != TPS65217_DEFDCDC1) &&
+	    (dc_cntrl_reg != TPS65217_DEFDCDC2) &&
+	    (dc_cntrl_reg != TPS65217_DEFDCDC3))
+		return 1;
+
+	/* set voltage level */
+	if (tps65217_reg_write(TPS65217_PROT_LEVEL_2, dc_cntrl_reg,

volt_sel,

drivers/power/pmic/pmic_tps65217.c new file +5 -0
+			       TPS65217_MASK_ALL_BITS))
+		return 1;
+
+	/* set GO bit to initiate voltage transition */
+	if (tps65217_reg_write(TPS65217_PROT_LEVEL_2,

TPS65217_DEFSLEW,

drivers/power/pmic/pmic_tps65217.c new file +5 -0
+			       TPS65217_DCDC_GO, TPS65217_DCDC_GO))
+		return 1;
+
+	return 0;
+}
include/power/tps65217.h new file +7 -0
new file mode 100644
index 0000000..f4c7a2b
@@ -0,0 +1,79 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ *
+ * For more details, please see the TRM at

http://www.ti.com/product/tps65217a
+ */

include/power/tps65217.h new file +29 -0
+
+#ifndef __POWER_TPS65217_H__
+#define __POWER_TPS65217_H__
+
+/* I2C chip address */
+#define TPS65217_CHIP_PM			0x24
+
+/* Registers */
+#define TPS65217_CHIPID				0x00
+#define TPS65217_POWER_PATH			0x01
+#define TPS65217_INTERRUPT			0x02
+#define TPS65217_CHGCONFIG0			0x03
+#define TPS65217_CHGCONFIG1			0x04
+#define TPS65217_CHGCONFIG2			0x05
+#define TPS65217_CHGCONFIG3			0x06
+#define TPS65217_WLEDCTRL1			0x07
+#define TPS65217_WLEDCTRL2			0x08
+#define TPS65217_MUXCTRL			0x09
+#define TPS65217_STATUS				0x0A
+#define TPS65217_PASSWORD			0x0B
+#define TPS65217_PGOOD				0x0C
+#define TPS65217_DEFPG				0x0D
+#define TPS65217_DEFDCDC1			0x0E
+#define TPS65217_DEFDCDC2			0x0F
+#define TPS65217_DEFDCDC3			0x10
+#define TPS65217_DEFSLEW			0x11
+#define TPS65217_DEFLDO1			0x12
+#define TPS65217_DEFLDO2			0x13
+#define TPS65217_DEFLS1				0x14

include/power/tps65217.h line 47

Quoted 10 lines
include/power/tps65217.h new file +10 -0
+#define TPS65217_DEFLS2				0x15
+#define TPS65217_ENABLE				0x16
+#define TPS65217_DEFUVLO			0x18
+#define TPS65217_SEQ1				0x19
+#define TPS65217_SEQ2				0x1A
+#define TPS65217_SEQ3				0x1B
+#define TPS65217_SEQ4				0x1C
+#define TPS65217_SEQ5				0x1D
+#define TPS65217_SEQ6				0x1E
+

Shouldn't the above registers be defined as enum?

For example at ./include/power/max8997_pmic.h
/* MAX 8997 registers */

enum {
	MAX8997_REG_PMIC_ID0	= 0x00,
	MAX8997_REG_PMIC_ID1	= 0x01,
	MAX8997_REG_INTSRC	= 0x02,
	....
	PMIC_NUM_OF_REGS
}
Quoted 33 lines
include/power/tps65217.h new file +29 -0
+#define TPS65217_PROT_LEVEL_NONE		0x00
+#define TPS65217_PROT_LEVEL_1			0x01
+#define TPS65217_PROT_LEVEL_2			0x02
+
+#define TPS65217_PASSWORD_LOCK_FOR_WRITE	0x00
+#define TPS65217_PASSWORD_UNLOCK		0x7D
+
+#define TPS65217_DCDC_GO			0x80
+
+#define TPS65217_MASK_ALL_BITS			0xFF
+
+#define TPS65217_USB_INPUT_CUR_LIMIT_MASK	0x03
+#define TPS65217_USB_INPUT_CUR_LIMIT_100MA	0x00
+#define TPS65217_USB_INPUT_CUR_LIMIT_500MA	0x01
+#define TPS65217_USB_INPUT_CUR_LIMIT_1300MA	0x02
+#define TPS65217_USB_INPUT_CUR_LIMIT_1800MA	0x03
+
+#define TPS65217_DCDC_VOLT_SEL_1275MV		0x0F
+#define TPS65217_DCDC_VOLT_SEL_1325MV		0x11
+
+#define TPS65217_LDO_MASK			0x1F
+#define TPS65217_LDO_VOLTAGE_OUT_1_8		0x06
+#define TPS65217_LDO_VOLTAGE_OUT_3_3		0x1F
+
+#define TPS65217_PWR_SRC_USB_BITMASK		0x4
+#define TPS65217_PWR_SRC_AC_BITMASK		0x8
+
+int tps65217_reg_read(uchar src_reg, uchar *src_val);
+int tps65217_reg_write(uchar prot_level, uchar dest_reg, uchar

dest_val,

include/power/tps65217.h new file +3 -0
+		       uchar mask);
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel);
+#endif	/* __POWER_TPS65217_H__ */
Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
author
#3 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

Quoted 62 lines · Lukasz Majewski

Hi Tom, Greg

Quoted 60 lines

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109
++++++++++++++++++++++++++++++++++++
include/power/tps65217.h           |   79 ++++++++++++++++++++++++++
3 files changed, 189 insertions(+) create mode 100644

drivers/power/pmic/pmic_tps65217.c create mode 100644 include/power/tps65217.h

drivers/power/pmic/Makefile +1 -0
index f054470..ac2b625 100644
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65217.c new file mode 100644 index 0000000..36e9024

drivers/power/pmic/pmic_tps65217.c new file +13 -0
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65217.h>
+
+/**
+ * tps65217_reg_read() - Generic function that can read a TPS65217

register
+ * @src_reg: Source register address
+ * @src_val: Address of destination variable

Quoted 8 lines

drivers/power/pmic/pmic_tps65217.c line 20

Quoted 5 lines

+ * @return: 0 for success, not 0 on failure.
+ */

drivers/power/pmic/pmic_tps65217.c new file +3 -0
+int tps65217_reg_read(uchar src_reg, uchar *src_val)
+{
+	return i2c_read(TPS65217_CHIP_PM, src_reg, 1, src_val, 1);

Would it be possible to comply with pmic driver model? It can be found at ./drivers/power/power_core.c

At the high level, not yet. We don't have battery support (but fixing that to be optional in the core wouldn't be hard) but the general pmic code assumes one pmic charger per binary. We need both in the same binary (since we decide at run-time if it's one of the boards with 65910 or 65217).

Quoted 4 lines

Moreover the generic function for reading/writing data to/from pmic is already defined at ./drivers/power/power_{i2c|spi}.c

Maybe it would be possible to use/modify the already available code?

Without the MAX family datasheets handy, I'm not sure how exactly the tx_num stuff maps to the password concept the TI parts have. Skimming the kernel mfd drivers implies to me that logic ends up being per-chip (or at least vendor).

[snip]

Quoted 6 lines
Quoted 6 lines

+/**
+ * tps65217_voltage_update() - Function to change a voltage level, as this
+ * is a multi-step process.
+ * @dc_cntrl_reg: DC voltage control register to
change.

Quoted 8 lines
Quoted 5 lines

+ * @volt_sel: New value for the voltage
register
+ * @return: 0 for success, not 0 on failure.
+ */
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel)

Maybe pmic_set_output() method from ./drivers/power/power_core.c can be reused?

I'm not sure.

[snip]

Quoted 4 lines
Quoted 1 line

+#define TPS65217_SEQ6 0x1E

Shouldn't the above registers be defined as enum?

Quoted 8 lines

For example at ./include/power/max8997_pmic.h
/* MAX 8997 registers */

enum {
	MAX8997_REG_PMIC_ID0	= 0x00,
	MAX8997_REG_PMIC_ID1	= 0x01,
	MAX8997_REG_INTSRC	= 0x02,
	....
	PMIC_NUM_OF_REGS

I assume it's a style thing I've overlooked, so sure, not a problem in general.

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130814/8f9dff65/attachment.pgp>
#4 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

Quoted 73 lines · On Wed, 14 Aug 2013 11:57:06 -0400 Tom Rini <[email protected]> wrote:
Quoted 63 lines · Lukasz Majewski

Hi Tom, Greg

Quoted 61 lines

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109

++++++++++++++++++++++++++++++++++++
include/power/tps65217.h | 79
++++++++++++++++++++++++++ 3 files changed, 189 insertions(+) create mode 100644 drivers/power/pmic/pmic_tps65217.c create mode 100644 include/power/tps65217.h

(quoted diff) +0 -0

b/drivers/power/pmic/Makefile index f054470..ac2b625 100644

drivers/power/pmic/Makefile +1 -0
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65217.c new file mode 100644 index 0000000..36e9024

drivers/power/pmic/pmic_tps65217.c new file +13 -0
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65217.h>
+
+/**
+ * tps65217_reg_read() - Generic function that can read a

TPS65217 register
+ * @src_reg: Source register address
+ * @src_val: Address of destination variable
+ * @return: 0 for success, not 0 on failure.

Quoted 8 lines
Quoted 5 lines

+ */

drivers/power/pmic/pmic_tps65217.c new file +3 -0
+int tps65217_reg_read(uchar src_reg, uchar *src_val)
+{
+	return i2c_read(TPS65217_CHIP_PM, src_reg, 1, src_val,

1);

Would it be possible to comply with pmic driver model? It can be found at ./drivers/power/power_core.c

Quoted 3 lines

At the high level, not yet. We don't have battery support (but fixing that to be optional in the core wouldn't be hard) but the general pmic code assumes one pmic charger per binary.

As fair as I remember, there is no such assumption. The pmic driver allocates each pmic object separately (which can be distinguished by unique name - also many instances of the same devices are possible). Each power device is treated in the same way (described by struct pmic), no matter if it is a battery, charger, PMIC or MUIC.

Then each reference is done via struct pmic *p pointer. The charger is not needed to use the generic pmic_reg_write().

The tps65217_reg_read() method is used at board/ti/am335x/board.c - [PATCH v2 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency

It is a similar use to pmic_init_max8997(void) defined at board/samsung/trats/trats.c

Quoted 3 lines

We need both in the same
binary (since we decide at run-time if it's one of the boards with 65910 or 65217).

The pmic core can register both devices, then with OF decide to which one refer with e.g. p->name field.

Quoted 10 lines
Quoted 5 lines

Moreover the generic function for reading/writing data to/from pmic is already defined at ./drivers/power/power_{i2c|spi}.c

Maybe it would be possible to use/modify the already available code?

Without the MAX family datasheets handy, I'm not sure how exactly the tx_num stuff maps to the password concept the TI parts have. Skimming the kernel mfd drivers implies to me that logic ends up being per-chip (or at least vendor).

We have spent some time with Stefano to provide correct read/write for the following:

- 1,2,3 bytes transfers
- little + big endian data format support
- support for SPI and I2C.

This is already implemented at pmic_reg_write().

Quoted 18 lines

[snip]

Quoted 7 lines
Quoted 7 lines

+/**
+ * tps65217_voltage_update() - Function to change a voltage level, as this
+ * is a multi-step process.
+ * @dc_cntrl_reg: DC voltage control register to
change.
+ * @volt_sel: New value for the voltage

Quoted 8 lines
Quoted 5 lines

register
+ * @return: 0 for success, not 0 on
failure.
+ */
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel)

Maybe pmic_set_output() method from ./drivers/power/power_core.c can be reused?

Quoted 1 line

I'm not sure.

At least we shall give it a try.

Quoted 15 lines

[snip]

Quoted 4 lines
Quoted 1 line

+#define TPS65217_SEQ6 0x1E

Shouldn't the above registers be defined as enum?

Quoted 8 lines

For example at ./include/power/max8997_pmic.h
/* MAX 8997 registers */

enum {
	MAX8997_REG_PMIC_ID0	= 0x00,
	MAX8997_REG_PMIC_ID1	= 0x01,
	MAX8997_REG_INTSRC	= 0x02,
	....
	PMIC_NUM_OF_REGS
Quoted 3 lines

I assume it's a style thing I've overlooked, so sure, not a problem in general.

Ok, thanks.

I'm aware, that current pmic framework has some shortcomings, but I also believe that it can be developed to serve as a unified power management framework for u-boot users.

Regards,
Lukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130814/512ff1aa/attachment.pgp>

author
#5 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

Quoted 78 lines · Lukasz Majewski
Quoted 73 lines · On Wed, 14 Aug 2013 11:57:06 -0400 Tom Rini <[email protected]> wrote:
Quoted 63 lines · Lukasz Majewski

Hi Tom, Greg

Quoted 61 lines

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109

++++++++++++++++++++++++++++++++++++
include/power/tps65217.h | 79
++++++++++++++++++++++++++ 3 files changed, 189 insertions(+) create mode 100644 drivers/power/pmic/pmic_tps65217.c create mode 100644 include/power/tps65217.h

(quoted diff) +0 -0

b/drivers/power/pmic/Makefile index f054470..ac2b625 100644

drivers/power/pmic/Makefile +1 -0
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
 COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS := $(COBJS-y)
 SRCS := $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65217.c new file mode 100644 index 0000000..36e9024

drivers/power/pmic/pmic_tps65217.c new file +13 -0
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65217.h>
+
+/**
+ * tps65217_reg_read() - Generic function that can read a

TPS65217 register
+ * @src_reg: Source register address
+ * @src_val: Address of destination variable
+ * @return: 0 for success, not 0 on failure.

Quoted 8 lines
Quoted 5 lines

+ */

drivers/power/pmic/pmic_tps65217.c new file +3 -0
+int tps65217_reg_read(uchar src_reg, uchar *src_val)
+{
+ return i2c_read(TPS65217_CHIP_PM, src_reg, 1, src_val,

1);

Would it be possible to comply with pmic driver model? It can be found at ./drivers/power/power_core.c

Quoted 3 lines

At the high level, not yet. We don't have battery support (but fixing that to be optional in the core wouldn't be hard) but the general pmic code assumes one pmic charger per binary.

Quoted 5 lines

As fair as I remember, there is no such assumption. The pmic driver allocates each pmic object separately (which can be distinguished by unique name - also many instances of the same devices are possible). Each power device is treated in the same way (described by struct pmic), no matter if it is a battery, charger, PMIC or MUIC.

Getting back to this thread again, sorry, drivers/power/pmic/pmic_max* each has 'pmic_init' as a function meaning that only one each may be built at a time.

Quoted 6 lines

The tps65217_reg_read() method is used at board/ti/am335x/board.c - [PATCH v2 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency

It is a similar use to pmic_init_max8997(void) defined at board/samsung/trats/trats.c

In concept, yes, except we might have either a tps65910 or a tps65217 and we won't know which until run-time, so we need to build in both.

Quoted 6 lines
Quoted 3 lines

We need both in the same
binary (since we decide at run-time if it's one of the boards with 65910 or 65217).

The pmic core can register both devices, then with OF decide to which one refer with e.g. p->name field.

Except for the function problem above, yes :)

Quoted 10 lines
Quoted 9 lines
Quoted 4 lines

Moreover the generic function for reading/writing data to/from pmic is already defined at ./drivers/power/power_{i2c|spi}.c

Maybe it would be possible to use/modify the already available code?

Without the MAX family datasheets handy, I'm not sure how exactly the tx_num stuff maps to the password concept the TI parts have. Skimming the kernel mfd drivers implies to me that logic ends up being per-chip (or at least vendor).

Quoted 8 lines

We have spent some time with Stefano to provide correct read/write for the following:

- 1,2,3 bytes transfers
- little + big endian data format support
- support for SPI and I2C.

This is already implemented at pmic_reg_write().

Right, but it won't buy us anything when we have to wrap our call around that with calls to do the password logic. That's actually the "hard" part of these writes.

Quoted 17 lines
Quoted 17 lines

[snip]

Quoted 15 lines
Quoted 4 lines

+/**
+ * tps65217_voltage_update() - Function to change a voltage level, as this
+ * is a multi-step process.

Quoted 8 lines

+ * @dc_cntrl_reg: DC voltage control register to
change.
+ * @volt_sel: New value for the voltage
register
+ * @return: 0 for success, not 0 on
failure.
+ */
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel)

Maybe pmic_set_output() method from ./drivers/power/power_core.c can be reused?

Quoted 3 lines
Quoted 1 line

I'm not sure.

At least we shall give it a try.

If we make pmic_reg_write be per-chip or so, yes, we could make use of a general "do something" function.

Quoted 18 lines
Quoted 14 lines

[snip]

Quoted 4 lines
Quoted 1 line

+#define TPS65217_SEQ6 0x1E

Shouldn't the above registers be defined as enum?

Quoted 8 lines

For example at ./include/power/max8997_pmic.h
/* MAX 8997 registers */
enum {
MAX8997_REG_PMIC_ID0 = 0x00,
MAX8997_REG_PMIC_ID1 = 0x01,
MAX8997_REG_INTSRC = 0x02,
....
PMIC_NUM_OF_REGS

Quoted 3 lines

I assume it's a style thing I've overlooked, so sure, not a problem in general.

Quoted 5 lines

Ok, thanks.

I'm aware, that current pmic framework has some shortcomings, but I also believe that it can be developed to serve as a unified power management framework for u-boot users.

Right, but we need to think about it a bit more and the first step is getting some non-Maxim chips in the area so people see them. Then we can adapt everyone as a follow-up.

Signature · 1 line
Tom
#6 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

Hi Tom,

Quoted 85 lines · Lukasz Majewski
Quoted 78 lines · On Wed, 14 Aug 2013 11:57:06 -0400 Tom Rini <[email protected]> wrote:
Quoted 73 lines · Lukasz Majewski
Quoted 63 lines

Hi Tom, Greg

Quoted 61 lines

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109

++++++++++++++++++++++++++++++++++++
include/power/tps65217.h | 79
++++++++++++++++++++++++++ 3 files changed, 189 insertions(+) create mode 100644 drivers/power/pmic/pmic_tps65217.c create mode 100644 include/power/tps65217.h

(quoted diff) +0 -0

b/drivers/power/pmic/Makefile index f054470..ac2b625 100644

drivers/power/pmic/Makefile +0 -0
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) +=

pmic_max8998.o COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o

drivers/power/pmic/Makefile +1 -0
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS := $(COBJS-y)
 SRCS := $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65217.c new file mode 100644 index 0000000..36e9024

drivers/power/pmic/pmic_tps65217.c new file +13 -0
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65217.h>
+
+/**
+ * tps65217_reg_read() - Generic function that can read a

TPS65217 register
+ * @src_reg: Source register address
+ * @src_val: Address of destination variable
+ * @return: 0 for success, not 0 on failure.

Quoted 8 lines
Quoted 5 lines

+ */

drivers/power/pmic/pmic_tps65217.c new file +3 -0
+int tps65217_reg_read(uchar src_reg, uchar *src_val)
+{
+ return i2c_read(TPS65217_CHIP_PM, src_reg, 1, src_val,

1);

Would it be possible to comply with pmic driver model? It can be found at ./drivers/power/power_core.c

Quoted 3 lines

At the high level, not yet. We don't have battery support (but fixing that to be optional in the core wouldn't be hard) but the general pmic code assumes one pmic charger per binary.

Quoted 5 lines

As fair as I remember, there is no such assumption. The pmic driver allocates each pmic object separately (which can be distinguished by unique name - also many instances of the same devices are possible). Each power device is treated in the same way (described by struct pmic), no matter if it is a battery, charger, PMIC or MUIC.

Quoted 3 lines

Getting back to this thread again, sorry, drivers/power/pmic/pmic_max* each has 'pmic_init' as a function meaning that only one each may be built at a time.

Good point.... :/

Quoted 11 lines
Quoted 7 lines

The tps65217_reg_read() method is used at board/ti/am335x/board.c - [PATCH v2 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency

It is a similar use to pmic_init_max8997(void) defined at board/samsung/trats/trats.c

In concept, yes, except we might have either a tps65910 or a tps65217 and we won't know which until run-time, so we need to build in both.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

We need both in the same
binary (since we decide at run-time if it's one of the boards with 65910 or 65217).

The pmic core can register both devices, then with OF decide to which one refer with e.g. p->name field.

Except for the function problem above, yes :)

I think that {pmic}_init function shall be moved from per device file to ./drivers/power/power_core.c

Only then we can provide support for many "pmics" compiled in with run time initialization and per name (e.g. "MAX8998_PMIC0", "MAX8998_PMIC1", "MAX8998_PMICn" ....) selection.

This shall facilitate usage of one u-boot binary supporting many boards/chip versions.

Quoted 19 lines
Quoted 19 lines
Quoted 11 lines
Quoted 6 lines

Moreover the generic function for reading/writing data to/from pmic is already defined at ./drivers/power/power_{i2c|spi}.c

Maybe it would be possible to use/modify the already available code?

Without the MAX family datasheets handy, I'm not sure how exactly the tx_num stuff maps to the password concept the TI parts have. Skimming the kernel mfd drivers implies to me that logic ends up being per-chip (or at least vendor).

We have spent some time with Stefano to provide correct read/write for the following:

- 1,2,3 bytes transfers
- little + big endian data format support
- support for SPI and I2C.

Quoted 5 lines
Quoted 1 line

This is already implemented at pmic_reg_write().

Right, but it won't buy us anything when we have to wrap our call around that with calls to do the password logic. That's actually the "hard" part of these writes.

I must check what the "password logic" with TI chips mean.

Quoted 19 lines
Quoted 19 lines
Quoted 19 lines

[snip]

Quoted 16 lines
Quoted 5 lines

+/**
+ * tps65217_voltage_update() - Function to change a voltage level, as this
+ * is a multi-step process.
+ * @dc_cntrl_reg: DC voltage control register to

Quoted 8 lines

change.
+ * @volt_sel: New value for the voltage
register
+ * @return: 0 for success, not 0 on
failure.
+ */
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel)

Maybe pmic_set_output() method from ./drivers/power/power_core.c can be reused?

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

I'm not sure.

At least we shall give it a try.

If we make pmic_reg_write be per-chip or so, yes, we could make use of a general "do something" function.

One of possible solutions. Good idea.

Quoted 21 lines
Quoted 21 lines
Quoted 15 lines

[snip]

Quoted 4 lines
Quoted 1 line

+#define TPS65217_SEQ6 0x1E

Shouldn't the above registers be defined as enum?

Quoted 8 lines

For example at ./include/power/max8997_pmic.h
/* MAX 8997 registers */
enum {
MAX8997_REG_PMIC_ID0 = 0x00,
MAX8997_REG_PMIC_ID1 = 0x01,
MAX8997_REG_INTSRC = 0x02,
....
PMIC_NUM_OF_REGS

Quoted 3 lines

I assume it's a style thing I've overlooked, so sure, not a problem in general.

Ok, thanks.

Quoted 7 lines
Quoted 3 lines

I'm aware, that current pmic framework has some shortcomings, but I also believe that it can be developed to serve as a unified power management framework for u-boot users.

Right, but we need to think about it a bit more and the first step is getting some non-Maxim chips in the area so people see them. Then we can adapt everyone as a follow-up.

As a starting point - we need to support compiled in pmic (or any other) devices of the same kind (like many pmics) as you pointed out with TI chips.

Then we can adjust the pmic_reg_write definition

What do you think?

Quoted 1 line

Regards,
Lukasz Majewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130828/ab3dd799/attachment.pgp>

author
#7 lore raw

PATCH v2 2/6 drivers/power/pmic: Add tps65217 driver

Quoted 116 lines · Lukasz Majewski

Hi Tom,

Quoted 85 lines · Lukasz Majewski
Quoted 78 lines · On Wed, 14 Aug 2013 11:57:06 -0400 Tom Rini <[email protected]> wrote:
Quoted 73 lines · Lukasz Majewski
Quoted 63 lines

Hi Tom, Greg

Quoted 61 lines

From: Greg Guyotte <[email protected]>

Add a driver for the TPS65217 PMIC that is found in the Beaglebone family of boards.

[trini: Split and rework Greg's changes into new drivers/power framework]

---
Changes in v2:
- Address Dan's comments
- Change to SPDX license tag
- Add TRM link in the header

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65217.c |  109

++++++++++++++++++++++++++++++++++++
include/power/tps65217.h | 79
++++++++++++++++++++++++++ 3 files changed, 189 insertions(+) create mode 100644 drivers/power/pmic/pmic_tps65217.c create mode 100644 include/power/tps65217.h

(quoted diff) +0 -0

b/drivers/power/pmic/Makefile index f054470..ac2b625 100644

drivers/power/pmic/Makefile +0 -0
@@ -13,6 +13,7 @@ COBJS-$(CONFIG_POWER_MAX8998) +=

pmic_max8998.o COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o

drivers/power/pmic/Makefile +1 -0
+COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
 
 COBJS := $(COBJS-y)
 SRCS := $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65217.c new file mode 100644 index 0000000..36e9024

drivers/power/pmic/pmic_tps65217.c new file +13 -0
@@ -0,0 +1,109 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65217.h>
+
+/**
+ * tps65217_reg_read() - Generic function that can read a

TPS65217 register
+ * @src_reg: Source register address
+ * @src_val: Address of destination variable
+ * @return: 0 for success, not 0 on failure.

Quoted 8 lines
Quoted 5 lines

+ */

drivers/power/pmic/pmic_tps65217.c new file +3 -0
+int tps65217_reg_read(uchar src_reg, uchar *src_val)
+{
+ return i2c_read(TPS65217_CHIP_PM, src_reg, 1, src_val,

1);

Would it be possible to comply with pmic driver model? It can be found at ./drivers/power/power_core.c

Quoted 3 lines

At the high level, not yet. We don't have battery support (but fixing that to be optional in the core wouldn't be hard) but the general pmic code assumes one pmic charger per binary.

Quoted 5 lines

As fair as I remember, there is no such assumption. The pmic driver allocates each pmic object separately (which can be distinguished by unique name - also many instances of the same devices are possible). Each power device is treated in the same way (described by struct pmic), no matter if it is a battery, charger, PMIC or MUIC.

Quoted 3 lines

Getting back to this thread again, sorry, drivers/power/pmic/pmic_max* each has 'pmic_init' as a function meaning that only one each may be built at a time.

Good point.... :/

Quoted 11 lines
Quoted 7 lines

The tps65217_reg_read() method is used at board/ti/am335x/board.c - [PATCH v2 6/6] am335x_evm: am33xx_spl_board_init function and scale core frequency

It is a similar use to pmic_init_max8997(void) defined at board/samsung/trats/trats.c

In concept, yes, except we might have either a tps65910 or a tps65217 and we won't know which until run-time, so we need to build in both.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

We need both in the same
binary (since we decide at run-time if it's one of the boards with 65910 or 65217).

The pmic core can register both devices, then with OF decide to which one refer with e.g. p->name field.

Except for the function problem above, yes :)

I think that {pmic}_init function shall be moved from per device file to ./drivers/power/power_core.c

Quoted 6 lines

Only then we can provide support for many "pmics" compiled in with run time initialization and per name (e.g. "MAX8998_PMIC0", "MAX8998_PMIC1", "MAX8998_PMICn" ....) selection.

This shall facilitate usage of one u-boot binary supporting many boards/chip versions.

Right, sounds workable.

Quoted 83 lines
Quoted 18 lines
Quoted 18 lines
Quoted 10 lines
Quoted 5 lines

Moreover the generic function for reading/writing data to/from pmic is already defined at ./drivers/power/power_{i2c|spi}.c

Maybe it would be possible to use/modify the already available code?

Without the MAX family datasheets handy, I'm not sure how exactly the tx_num stuff maps to the password concept the TI parts have. Skimming the kernel mfd drivers implies to me that logic ends up being per-chip (or at least vendor).

We have spent some time with Stefano to provide correct read/write for the following:

- 1,2,3 bytes transfers
- little + big endian data format support
- support for SPI and I2C.

Quoted 5 lines
Quoted 1 line

This is already implemented at pmic_reg_write().

Right, but it won't buy us anything when we have to wrap our call around that with calls to do the password logic. That's actually the "hard" part of these writes.

I must check what the "password logic" with TI chips mean.

Quoted 19 lines
Quoted 19 lines
Quoted 19 lines

[snip]

Quoted 16 lines
Quoted 5 lines

+/**
+ * tps65217_voltage_update() - Function to change a voltage level, as this
+ * is a multi-step process.
+ * @dc_cntrl_reg: DC voltage control register to

Quoted 8 lines

change.
+ * @volt_sel: New value for the voltage
register
+ * @return: 0 for success, not 0 on
failure.
+ */
+int tps65217_voltage_update(uchar dc_cntrl_reg, uchar volt_sel)

Maybe pmic_set_output() method from ./drivers/power/power_core.c can be reused?

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

I'm not sure.

At least we shall give it a try.

If we make pmic_reg_write be per-chip or so, yes, we could make use of a general "do something" function.

One of possible solutions. Good idea.

Quoted 21 lines
Quoted 21 lines
Quoted 15 lines

[snip]

Quoted 4 lines
Quoted 1 line

+#define TPS65217_SEQ6 0x1E

Shouldn't the above registers be defined as enum?

Quoted 8 lines

For example at ./include/power/max8997_pmic.h
/* MAX 8997 registers */
enum {
MAX8997_REG_PMIC_ID0 = 0x00,
MAX8997_REG_PMIC_ID1 = 0x01,
MAX8997_REG_INTSRC = 0x02,
....
PMIC_NUM_OF_REGS

Quoted 3 lines

I assume it's a style thing I've overlooked, so sure, not a problem in general.

Ok, thanks.

Quoted 7 lines
Quoted 3 lines

I'm aware, that current pmic framework has some shortcomings, but I also believe that it can be developed to serve as a unified power management framework for u-boot users.

Right, but we need to think about it a bit more and the first step is getting some non-Maxim chips in the area so people see them. Then we can adapt everyone as a follow-up.

Quoted 7 lines

As a starting point - we need to support compiled in pmic (or any other) devices of the same kind (like many pmics) as you pointed out with TI chips.

Then we can adjust the pmic_reg_write definition

What do you think?

I think we're getting there, and it will be easier with other PMICs in tree ;)

Signature · 8 lines
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130828/71817ec7/attachment-0001.pgp>
author
#8 lore raw

PATCH v2 3/6 drivers/power/pmic: Add tps65910 driver

In reply to Tom Rini

From: "Philip, Avinash" <[email protected]>

Add a driver for the TPS65910 PMIC that is found in the AM335x GP EVM, AM335x EVM SK and others.

[trini: Split and rework Avinash's changes into new drivers/power framework]

---
Changes in v2:
- Change to SPDX license tag
- Add TRM link in the header
- Add tps65910_set_i2c_control()

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65910.c |   83 ++++++++++++++++++++++++++++++++++++
 include/power/tps65910.h           |   75 ++++++++++++++++++++++++++++++++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/power/pmic/pmic_tps65910.c
 create mode 100644 include/power/tps65910.h
drivers/power/pmic/Makefile +1 -0
index ac2b625..11b3d03 100644
@@ -14,6 +14,7 @@ COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
 COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
+COBJS-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
drivers/power/pmic/pmic_tps65910.c new file +83 -0

83 lines not on this page · raw message

include/power/tps65910.h new file +75 -0

75 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#9 lore raw

PATCH v2 3/6 drivers/power/pmic: Add tps65910 driver

Hi Tom, Philip,

I have the same comments as with:
[PATCH v2 2/6] drivers/power/pmic: Add tps65217 driver

Quoted 217 lines

From: "Philip, Avinash" <[email protected]>

Add a driver for the TPS65910 PMIC that is found in the AM335x GP EVM, AM335x EVM SK and others.

[trini: Split and rework Avinash's changes into new drivers/power framework]

---
Changes in v2:
- Change to SPDX license tag
- Add TRM link in the header
- Add tps65910_set_i2c_control()

---
 drivers/power/pmic/Makefile        |    1 +
 drivers/power/pmic/pmic_tps65910.c |   83

++++++++++++++++++++++++++++++++++++
include/power/tps65910.h | 75
++++++++++++++++++++++++++++++++ 3 files changed, 159 insertions(+) create mode 100644 drivers/power/pmic/pmic_tps65910.c create mode 100644 include/power/tps65910.h

drivers/power/pmic/Makefile +1 -0
index ac2b625..11b3d03 100644
@@ -14,6 +14,7 @@ COBJS-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
 COBJS-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
 COBJS-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
 COBJS-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
+COBJS-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
 
 COBJS	:= $(COBJS-y)
 SRCS	:= $(COBJS:.o=.c)
(quoted diff) +0 -0

b/drivers/power/pmic/pmic_tps65910.c new file mode 100644 index 0000000..7ee1160

drivers/power/pmic/pmic_tps65910.c new file +13 -0
@@ -0,0 +1,83 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <i2c.h>
+#include <power/tps65910.h>
+
+/*
+ * tps65910_set_i2c_control() - Set the TPS65910 to be controlled

via the I2C
+ * interface.
+ * @return: 0 on success, not 0 on failure
+ */

drivers/power/pmic/pmic_tps65910.c new file +7 -0
+int tps65910_set_i2c_control(void)
+{
+	int ret;
+	uchar buf;
+
+	/* VDD1/2 voltage selection register access by control i/f */
+	ret = i2c_read(TPS65910_CTRL_I2C_ADDR, TPS65910_DEVCTRL_REG,

1,

drivers/power/pmic/pmic_tps65910.c new file +8 -0
+		       &buf, 1);
+
+	if (ret)
+		return ret;
+
+	buf |= TPS65910_DEVCTRL_REG_SR_CTL_I2C_SEL_CTL_I2C;
+
+	return i2c_write(TPS65910_CTRL_I2C_ADDR,

TPS65910_DEVCTRL_REG, 1,

drivers/power/pmic/pmic_tps65910.c new file +5 -0
+			 &buf, 1);
+}
+
+/*
+ * tps65910_voltage_update() - Voltage switching for MPU frequency

switching.
+ * @module: mpu - 0, core - 1
+ * @vddx_op_vol_sel: vdd voltage to set
+ * @return: 0 on success, not 0 on failure
+ */
+int tps65910_voltage_update(unsigned int module, unsigned char vddx_op_vol_sel) +{

drivers/power/pmic/pmic_tps65910.c new file +11 -0
+	uchar buf;
+	unsigned int reg_offset;
+	int ret;
+
+	if (module == MPU)
+		reg_offset = TPS65910_VDD1_OP_REG;
+	else
+		reg_offset = TPS65910_VDD2_OP_REG;
+
+	/* Select VDDx OP   */
+	ret = i2c_read(TPS65910_CTRL_I2C_ADDR, reg_offset, 1, &buf,

1);

drivers/power/pmic/pmic_tps65910.c new file +6 -0
+	if (ret)
+		return ret;
+
+	buf &= ~TPS65910_OP_REG_CMD_MASK;
+
+	ret = i2c_write(TPS65910_CTRL_I2C_ADDR, reg_offset, 1, &buf,

1);

drivers/power/pmic/pmic_tps65910.c new file +5 -0
+	if (ret)
+		return ret;
+
+	/* Configure VDDx OP  Voltage */
+	ret = i2c_read(TPS65910_CTRL_I2C_ADDR, reg_offset, 1, &buf,

1);

drivers/power/pmic/pmic_tps65910.c new file +7 -0
+	if (ret)
+		return ret;
+
+	buf &= ~TPS65910_OP_REG_SEL_MASK;
+	buf |= vddx_op_vol_sel;
+
+	ret = i2c_write(TPS65910_CTRL_I2C_ADDR, reg_offset, 1, &buf,

1);

drivers/power/pmic/pmic_tps65910.c new file +4 -0
+	if (ret)
+		return ret;
+
+	ret = i2c_read(TPS65910_CTRL_I2C_ADDR, reg_offset, 1, &buf,

1);

drivers/power/pmic/pmic_tps65910.c new file +8 -0
+	if (ret)
+		return ret;
+
+	if ((buf & TPS65910_OP_REG_SEL_MASK) != vddx_op_vol_sel)
+		return 1;
+
+	return 0;
+}
include/power/tps65910.h new file +7 -0
new file mode 100644
index 0000000..9600e9f
@@ -0,0 +1,75 @@
+/*
+ * (C) Copyright 2011-2013
+ * Texas Instruments, <www.ti.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ *
+ * For more details, please see the TRM at

http://www.ti.com/product/tps65910
+ */

include/power/tps65910.h new file +18 -0
+#ifndef __POWER_TPS65910_H__
+#define __POWER_TPS65910_H__
+
+#define MPU     0
+#define CORE    1
+
+#define TPS65910_SR_I2C_ADDR				0x12
+#define TPS65910_CTRL_I2C_ADDR				0x2D
+
+/* PMIC Register offsets */
+#define TPS65910_VDD1_REG				0x21
+#define TPS65910_VDD1_OP_REG				0x22
+#define TPS65910_VDD2_REG				0x24
+#define TPS65910_VDD2_OP_REG				0x25
+#define TPS65910_DEVCTRL_REG				0x3F
+
+/* VDD2 & VDD1 control register (VDD2_REG & VDD1_REG) */
+#define TPS65910_VGAIN_SEL_MASK				(0x3

<< 6) +#define TPS65910_ILMAX_MASK
(0x1 << 5) +#define
TPS65910_TSTEP_MASK (0x7 << 2)

include/power/tps65910.h new file +11 -0
+#define TPS65910_ST_MASK				(0x3) +
+#define TPS65910_REG_VGAIN_SEL_X1			(0x0 << 6)
+#define TPS65910_REG_VGAIN_SEL_X1_0			(0x1 << 6)
+#define TPS65910_REG_VGAIN_SEL_X3			(0x2 << 6)
+#define TPS65910_REG_VGAIN_SEL_X4			(0x3 << 6)
+
+#define TPS65910_REG_ILMAX_1_0_A			(0x0 << 5)
+#define TPS65910_REG_ILMAX_1_5_A			(0x1 << 5)
+
+#define TPS65910_REG_TSTEP_				(0x0 << 2)
+#define TPS65910_REG_TSTEP_12_5				(0x1

<< 2) +#define TPS65910_REG_TSTEP_9_4
(0x2 << 2) +#define
TPS65910_REG_TSTEP_7_5 (0x3 << 2)
+#define TPS65910_REG_TSTEP_6_25 (0x4
<< 2) +#define TPS65910_REG_TSTEP_4_7
(0x5 << 2) +#define
TPS65910_REG_TSTEP_3_12 (0x6 << 2)
+#define TPS65910_REG_TSTEP_2_5 (0x7
<< 2) + +#define TPS65910_REG_ST_OFF
(0x0) +#define TPS65910_REG_ST_ON_HI_POW (0x1)

include/power/tps65910.h new file +4 -0
+#define TPS65910_REG_ST_OFF_1				(0x2)
+#define TPS65910_REG_ST_ON_LOW_POW			(0x3) +
+
+/* VDD2 & VDD1 voltage selection register. (VDD2_OP_REG &

VDD1_OP_REG) */ +#define
TPS65910_OP_REG_SEL (0x7F) +

include/power/tps65910.h new file +2 -0
+#define TPS65910_OP_REG_CMD_MASK			(0x1 << 7)
+#define TPS65910_OP_REG_CMD_OP				(0x0

<< 7) +#define TPS65910_OP_REG_CMD_SR
(0x1 << 7) +

include/power/tps65910.h new file +2 -0
+#define TPS65910_OP_REG_SEL_MASK			(0x7F)
+#define TPS65910_OP_REG_SEL_0_9_5

(0x1F) /* 0.9500 V */ +#define
TPS65910_OP_REG_SEL_1_1_3 (0x2E) /*
1.1375 V */ +#define TPS65910_OP_REG_SEL_1_2_0
(0x33) /* 1.2000 V */ +#define
TPS65910_OP_REG_SEL_1_2_6 (0x38) /*
1.2625 V */ +#define
TPS65910_OP_REG_SEL_1_3_2_5 (0x3D) /*
1.3250 V */ + +/* Device control register . (DEVCTRL_REG) */ +#define
TPS65910_DEVCTRL_REG_SR_CTL_I2C_MASK (0x1 << 4)

include/power/tps65910.h new file +2 -0
+#define TPS65910_DEVCTRL_REG_SR_CTL_I2C_SEL_SR_I2C	(0x0 << 4)
+#define TPS65910_DEVCTRL_REG_SR_CTL_I2C_SEL_CTL_I2C	(0x1 <<

4) + +int tps65910_set_i2c_control(void); +int tps65910_voltage_update(unsigned int module, unsigned char
vddx_op_vol_sel); +#endif /* __POWER_TPS65910_H__ */

Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
author
#10 lore raw

PATCH v2 4/6 am33xx: Add am33xx_spl_board_init function, call

In reply to Tom Rini

We need to allow for a further call-out in spl_board_init. Call this am33xx_spl_board_init and add a __weak version. This function may be used to scale the MPU frequency up, depending on board needs.

---
Changes in v2:
- Move am33xx_spl_board_init to am33xx/board.c from omap-common/boot-common.c

---
 arch/arm/cpu/armv7/am33xx/board.c            |    9 +++++++++
 arch/arm/cpu/armv7/omap-common/boot-common.c |    3 +++
 arch/arm/include/asm/arch-am33xx/sys_proto.h |    1 +
 3 files changed, 13 insertions(+)
arch/arm/cpu/armv7/am33xx/board.c +9 -0
index 07ab91c..88e2093 100644
@@ -27,6 +27,7 @@
 #include <miiphy.h>
 #include <cpsw.h>
 #include <asm/errno.h>
+#include <linux/compiler.h>
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>
 #include <linux/usb/musb.h>
@@ -143,6 +144,14 @@ int arch_misc_init(void)
 }
 
 #ifdef CONFIG_SPL_BUILD
+/*
+ * This function is the place to do per-board things such as ramp up the
+ * MPU clock frequency.
+ */
+__weak void am33xx_spl_board_init(void)
+{
+}
+
 void rtc32k_enable(void)
 {
 	struct rtc_regs *rtc = (struct rtc_regs *)RTC_BASE;
arch/arm/cpu/armv7/omap-common/boot-common.c +3 -0
index 6b9ce36..32293a1 100644
@@ -75,6 +75,9 @@ void spl_board_init(void)
 #if defined(CONFIG_AM33XX) && defined(CONFIG_SPL_MUSB_NEW_SUPPORT)
 	arch_misc_init();
 #endif
+#ifdef CONFIG_AM33XX
+	am33xx_spl_board_init();
+#endif
 }
 
 int board_mmc_init(bd_t *bis)
arch/arm/include/asm/arch-am33xx/sys_proto.h +1 -0
index 1424f90..5a42efc 100644
@@ -37,4 +37,5 @@ void omap_nand_switch_ecc(uint32_t, uint32_t);
 
 void rtc32k_enable(void);
 void uart_soft_reset(void);
+void am33xx_spl_board_init(void);
 #endif
Signature · 1 line
1.7.9.5
author
#11 lore raw

PATCH v2 5/6 am33xx: Add the efuse_sma CONTROL_MODULE register

In reply to Tom Rini

Starting with PG2.1 we have a register in the CONTROL_MODULE that is set with the package type and maximum supported frequency. Add this, and the relevant mask/values.

---
 arch/arm/include/asm/arch-am33xx/cpu.h |   12 ++++++++++++
 1 file changed, 12 insertions(+)
arch/arm/include/asm/arch-am33xx/cpu.h +12 -0
index bcb4c50..1021767 100644
@@ -38,6 +38,16 @@
 #define AM335X				0xB944
 #define TI81XX				0xB81E
 #define DEVICE_ID			(CTRL_BASE + 0x0600)
+#define DEVICE_ID_MASK			0x1FFF
+
+/* MPU max frequencies */
+#define AM335X_ZCZ_300			0x1FEF
+#define AM335X_ZCZ_600			0x1FAF
+#define AM335X_ZCZ_720			0x1F2F
+#define AM335X_ZCZ_800			0x1E2F
+#define AM335X_ZCZ_1000			0x1C2F
+#define AM335X_ZCE_300			0x1FDF
+#define AM335X_ZCE_600			0x1F9F
 
 /* This gives the status of the boot mode pins on the evm */
 #define SYSBOOT_MASK			(BIT(0) | BIT(1) | BIT(2)\
@@ -335,6 +345,8 @@ struct ctrl_dev {
 	unsigned int macid1h;		/* offset 0x3c */
 	unsigned int resv4[4];
 	unsigned int miisel;		/* offset 0x50 */
+	unsigned int resv5[106];
+	unsigned int efuse_sma;		/* offset 0x1FC */
 };
 #endif /* __ASSEMBLY__ */
 #endif /* __KERNEL_STRICT_NAMES */
Signature · 1 line
1.7.9.5
author
#12 lore raw

PATCH v2 6/6 am335x_evm: am33xx_spl_board_init function and scale core frequency

In reply to Tom Rini

Add a am33xx_spl_board_init (and enable the PMICs) that we may see, depending on the board we are running on. In all cases, we see if we can rely on the efuse_sma register to tell us the maximum speed. In the case of Beaglebone White, we need to make sure we are on AC power, and are on later than rev A1, and then we can ramp up to the PG1.0 maximum of 720Mhz. In the case of Beaglebone Black, we are either on PG2.0 that supports 1GHz or PG2.1. As PG2.0 may or may not have efuse_sma set, we cannot rely on this probe. In the case of the GP EVM, EVM SK and IDK we need to rely on the efuse_sma if we are on PG2.1, and the defaults for PG1.0/2.0.

---
Changes in v2:
- Re-work into helper functions to determine max clock frequency, move tps65910 probe / update into pmic_tps65910.c

---
 arch/arm/cpu/armv7/am33xx/sys_info.c             |   57 ++++++++++
 arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |    8 ++
 arch/arm/include/asm/arch-am33xx/sys_proto.h     |    3 +
 board/ti/am335x/board.c                          |  126 ++++++++++++++++++++++
 include/configs/am335x_evm.h                     |    4 +
 5 files changed, 198 insertions(+)
arch/arm/cpu/armv7/am33xx/sys_info.c +57 -0
index 63afaaa..fbc01ac 100644
@@ -17,6 +17,7 @@
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/cpu.h>
 #include <asm/arch/clock.h>
+#include <power/tps65910.h>
 
 struct ctrl_stat *cstat = (struct ctrl_stat *)CTRL_BASE;
 
@@ -119,3 +120,59 @@ int print_cpuinfo(void)
 	return 0;
 }
 #endif	/* CONFIG_DISPLAY_CPUINFO */
+
+#ifdef CONFIG_AM33XX
+int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev)
+{
+	int sil_rev;
+
+	sil_rev = readl(cdev->deviceid) >> 28;
+
+	if (sil_rev == 1)
+		/* PG 2.0, efuse may not be set. */
+		return MPUPLL_M_800;
+	else if (sil_rev >= 2) {
+		/* Check what the efuse says our max speed is. */
+		int efuse_arm_mpu_max_freq;
+		efuse_arm_mpu_max_freq = readl(cdev->efuse_sma);
+		switch ((efuse_arm_mpu_max_freq & DEVICE_ID_MASK)) {
+		case AM335X_ZCZ_1000:
+			return MPUPLL_M_1000;
+		case AM335X_ZCZ_800:
+			return MPUPLL_M_800;
+		case AM335X_ZCZ_720:
+			return MPUPLL_M_720;
+		case AM335X_ZCZ_600:
+		case AM335X_ZCE_600:
+			return MPUPLL_M_600;
+		case AM335X_ZCZ_300:
+		case AM335X_ZCE_300:
+			return MPUPLL_M_300;
+		}
+	}
+
+	/* PG 1.0 or otherwise unknown, use the PG1.0 max */
+	return MPUPLL_M_720;
+}
+
+int am335x_get_tps65910_mpu_vdd(int sil_rev, int frequency)
+{
+	/* For PG2.1 and later, we have one set of values. */
+	if (sil_rev >= 2) {
+		switch (frequency) {
+		case MPUPLL_M_1000:
+			return TPS65910_OP_REG_SEL_1_3_2_5;
+		case MPUPLL_M_800:
+			return TPS65910_OP_REG_SEL_1_2_6;
+		case MPUPLL_M_720:
+			return TPS65910_OP_REG_SEL_1_2_0;
+		case MPUPLL_M_600:
+		case MPUPLL_M_300:
+			return TPS65910_OP_REG_SEL_1_1_3;
+		}
+	}
+
+	/* Default to PG1.0/PG2.0 values. */
+	return TPS65910_OP_REG_SEL_1_1_3;
+}
+#endif
arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +8 -0
index 80e1899..789188b 100644
@@ -16,6 +16,14 @@
 #define CONFIG_SYS_MPUCLK	550
 #endif
 
+/* MAIN PLL Fdll supported frequencies */
+#define MPUPLL_M_1000	1000
+#define MPUPLL_M_800	800
+#define MPUPLL_M_720	720
+#define MPUPLL_M_600	600
+#define MPUPLL_M_550	550
+#define MPUPLL_M_300	300
+
 extern void pll_init(void);
 extern void enable_emif_clocks(void);
 extern void enable_dmm_clocks(void);
arch/arm/include/asm/arch-am33xx/sys_proto.h +3 -0
index 5a42efc..1340f83 100644
@@ -10,6 +10,7 @@
 
 #ifndef _SYS_PROTO_H_
 #define _SYS_PROTO_H_
+#include <asm/arch/cpu.h>
 
 #define BOARD_REV_ID	0x0
 
@@ -38,4 +39,6 @@ void omap_nand_switch_ecc(uint32_t, uint32_t);
 void rtc32k_enable(void);
 void uart_soft_reset(void);
 void am33xx_spl_board_init(void);
+int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev);
+int am335x_get_tps65910_mpu_vdd(int sil_rev, int frequency);
 #endif
board/ti/am335x/board.c +126 -0

138 lines not on this page · raw message

include/configs/am335x_evm.h +4 -0
index c5a6d4b..60c87a3 100644
@@ -289,6 +289,9 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN	2
 #define CONFIG_SYS_I2C_MULTI_EEPROMS
 
+#define CONFIG_POWER_TPS65217
+#define CONFIG_POWER_TPS65910
+
 #define CONFIG_OMAP_GPIO
 
 #define CONFIG_BAUDRATE		115200
@@ -352,6 +355,7 @@
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_LIBDISK_SUPPORT
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_POWER_SUPPORT
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_GPIO_SUPPORT
 #define CONFIG_SPL_YMODEM_SUPPORT
Signature · 1 line
1.7.9.5
author
#13 lore raw

PATCH v3 6/6 am335x_evm: am33xx_spl_board_init function and scale core frequency

Add a am33xx_spl_board_init (and enable the PMICs) that we may see, depending on the board we are running on. In all cases, we see if we can rely on the efuse_sma register to tell us the maximum speed. In the case of Beaglebone White, we need to make sure we are on AC power, and are on later than rev A1, and then we can ramp up to the PG1.0 maximum of 720Mhz. In the case of Beaglebone Black, we are either on PG2.0 that supports 1GHz or PG2.1. As PG2.0 may or may not have efuse_sma set, we cannot rely on this probe. In the case of the GP EVM, EVM SK and IDK we need to rely on the efuse_sma if we are on PG2.1, and the defaults for PG1.0/2.0.

---
Changes in v3:
- Set sil_rev in tps65910 case

Changes in v2:
- Re-work into helper functions to determine max clock frequency, move tps65910 probe / update into pmic_tps65910.c

---
 arch/arm/cpu/armv7/am33xx/sys_info.c             |   57 ++++++++++
 arch/arm/include/asm/arch-am33xx/clocks_am33xx.h |    8 ++
 arch/arm/include/asm/arch-am33xx/sys_proto.h     |    3 +
 board/ti/am335x/board.c                          |  127 ++++++++++++++++++++++
 include/configs/am335x_evm.h                     |    4 +
 5 files changed, 199 insertions(+)
arch/arm/cpu/armv7/am33xx/sys_info.c +57 -0
index 63afaaa..fbc01ac 100644
@@ -17,6 +17,7 @@
 #include <asm/arch/sys_proto.h>
 #include <asm/arch/cpu.h>
 #include <asm/arch/clock.h>
+#include <power/tps65910.h>
 
 struct ctrl_stat *cstat = (struct ctrl_stat *)CTRL_BASE;
 
@@ -119,3 +120,59 @@ int print_cpuinfo(void)
 	return 0;
 }
 #endif	/* CONFIG_DISPLAY_CPUINFO */
+
+#ifdef CONFIG_AM33XX
+int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev)
+{
+	int sil_rev;
+
+	sil_rev = readl(cdev->deviceid) >> 28;
+
+	if (sil_rev == 1)
+		/* PG 2.0, efuse may not be set. */
+		return MPUPLL_M_800;
+	else if (sil_rev >= 2) {
+		/* Check what the efuse says our max speed is. */
+		int efuse_arm_mpu_max_freq;
+		efuse_arm_mpu_max_freq = readl(cdev->efuse_sma);
+		switch ((efuse_arm_mpu_max_freq & DEVICE_ID_MASK)) {
+		case AM335X_ZCZ_1000:
+			return MPUPLL_M_1000;
+		case AM335X_ZCZ_800:
+			return MPUPLL_M_800;
+		case AM335X_ZCZ_720:
+			return MPUPLL_M_720;
+		case AM335X_ZCZ_600:
+		case AM335X_ZCE_600:
+			return MPUPLL_M_600;
+		case AM335X_ZCZ_300:
+		case AM335X_ZCE_300:
+			return MPUPLL_M_300;
+		}
+	}
+
+	/* PG 1.0 or otherwise unknown, use the PG1.0 max */
+	return MPUPLL_M_720;
+}
+
+int am335x_get_tps65910_mpu_vdd(int sil_rev, int frequency)
+{
+	/* For PG2.1 and later, we have one set of values. */
+	if (sil_rev >= 2) {
+		switch (frequency) {
+		case MPUPLL_M_1000:
+			return TPS65910_OP_REG_SEL_1_3_2_5;
+		case MPUPLL_M_800:
+			return TPS65910_OP_REG_SEL_1_2_6;
+		case MPUPLL_M_720:
+			return TPS65910_OP_REG_SEL_1_2_0;
+		case MPUPLL_M_600:
+		case MPUPLL_M_300:
+			return TPS65910_OP_REG_SEL_1_1_3;
+		}
+	}
+
+	/* Default to PG1.0/PG2.0 values. */
+	return TPS65910_OP_REG_SEL_1_1_3;
+}
+#endif
arch/arm/include/asm/arch-am33xx/clocks_am33xx.h +8 -0
index 80e1899..789188b 100644
@@ -16,6 +16,14 @@
 #define CONFIG_SYS_MPUCLK	550
 #endif
 
+/* MAIN PLL Fdll supported frequencies */
+#define MPUPLL_M_1000	1000
+#define MPUPLL_M_800	800
+#define MPUPLL_M_720	720
+#define MPUPLL_M_600	600
+#define MPUPLL_M_550	550
+#define MPUPLL_M_300	300
+
 extern void pll_init(void);
 extern void enable_emif_clocks(void);
 extern void enable_dmm_clocks(void);
arch/arm/include/asm/arch-am33xx/sys_proto.h +3 -0
index 5a42efc..1340f83 100644
@@ -10,6 +10,7 @@
 
 #ifndef _SYS_PROTO_H_
 #define _SYS_PROTO_H_
+#include <asm/arch/cpu.h>
 
 #define BOARD_REV_ID	0x0
 
@@ -38,4 +39,6 @@ void omap_nand_switch_ecc(uint32_t, uint32_t);
 void rtc32k_enable(void);
 void uart_soft_reset(void);
 void am33xx_spl_board_init(void);
+int am335x_get_efuse_mpu_max_freq(struct ctrl_dev *cdev);
+int am335x_get_tps65910_mpu_vdd(int sil_rev, int frequency);
 #endif
board/ti/am335x/board.c +127 -0

139 lines not on this page · raw message

include/configs/am335x_evm.h +4 -0
index c5a6d4b..60c87a3 100644
@@ -289,6 +289,9 @@
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN	2
 #define CONFIG_SYS_I2C_MULTI_EEPROMS
 
+#define CONFIG_POWER_TPS65217
+#define CONFIG_POWER_TPS65910
+
 #define CONFIG_OMAP_GPIO
 
 #define CONFIG_BAUDRATE		115200
@@ -352,6 +355,7 @@
 #define CONFIG_SPL_LIBCOMMON_SUPPORT
 #define CONFIG_SPL_LIBDISK_SUPPORT
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_POWER_SUPPORT
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_GPIO_SUPPORT
 #define CONFIG_SPL_YMODEM_SUPPORT
Signature · 1 line
1.7.9.5