Thank you for the confirmation! I have one more comment for those who see the following during Linux boot:
[ 1.343170] Compensating OPP0 for 0mV Orig nvalue:0x999888 New nvalue:0x999888
[ 1.350830] Compensating OPP1 for 0mV Orig nvalue:0x9a8efd New nvalue:0x9a8efd
[ 1.359985] Compensating OPP0 for 0mV Orig nvalue:0x99a696 New nvalue:0x99a696
[ 1.367645] Compensating OPP1 for 0mV Orig nvalue:0x999a88 New nvalue:0x999a88
[ 1.375274] Compensating OPP2 for 0mV Orig nvalue:0x9a85ee New nvalue:0x9a85ee
In our design, this seems to not related be to lack of smartreflex values. It appears to be related to the I2C access of the tps65910 regulator driver. (drivers/regulator/tps65910-regulator.c) In our platform file, the devices on I2C0 were:
static struct i2c_board_info __initdata am335x_i2c0_boardinfo[] = { { /* Baseboard board EEPROM */ I2C_BOARD_INFO("24c256", BASEBOARD_I2C_ADDR), .platform_data = &am335x_baseboard_eeprom_info, }, { I2C_BOARD_INFO("cpld_reg", 0x35), }, { I2C_BOARD_INFO("tps65910", TPS65910_I2C_ID1), .platform_data = &am335x_tps65910_info, }, }; Our design doesn't have the eeprom & cpld, but these devices are in am335x_i2c0_boardinfo[] so that if this kernel is accidentally used on the GP EVM, custom code stops the kernel if there is a successful read from the eeprom.
By trial & error, it seems that having these devices in the list interferes with I2C access to the tps65910. If the tps65910 I2C access is ok, the following appears during boot:
[ 0.140899] tps65910 1-002d: JTAGREVNUM 0x0
[ 0.143280] print_constraints: VRTC:
[ 0.144714] print_constraints: VIO: at 1800 mV
[ 0.147033] print_constraints: VDD1: 600 <--> 1500 mV at 1262 mV normal
[ 0.149322] print_constraints: VDD2: 600 <--> 1500 mV at 1137 mV normal
[ 0.150329] print_constraints: VDD3: 5000 mV
[ 0.151763] print_constraints: VDIG1: at 1800 mV
[ 0.153198] print_constraints: VDIG2: at 1800 mV
[ 0.154602] print_constraints: VPLL: at 1800 mV
[ 0.156036] print_constraints: VDAC: at 1800 mV
[ 0.157440] print_constraints: VAUX1: at 1800 mV
[ 0.158874] print_constraints: VAUX2: at 3300 mV
[ 0.160339] print_constraints: VAUX33: at 3300 mV
[ 0.161743] print_constraints: VMMC: at 3300 mV
In my case, if the eeprom & cpld devices are in am335x_i2c0_boardinfo[], I don't see the 'print_constraints' messages and see the 'Compensating OPP#' during boot. After I removed the eeprom & cpld entries, I saw the 'print_constraints' messages and no more 'Compensating OPP#'.
This leads me to believe that having non-existent devices in am335x_i2c0_boardinfo[] may put the bus in a strange state which interferes with I2C access to the tps65910. So designs which have other devices on the same bus as the tps659__ should take care to finish their I2C transactions properly to avoid interfering with the tps659__.
Additionally, I suggest initializing the tps659__ first, then other devices after:
static struct i2c_board_info __initdata am335x_i2c0_boardinfo[] = { { I2C_BOARD_INFO("tps65910", TPS65910_I2C_ID1), .platform_data = &am335x_tps65910_info, }, { // 2nd device }, { // 3rd device }, };