TPS40400: I2C getting ack at wrong address

Vishnu PR 

The TPS40400 is ACKing Address 0x0C because it supports the Alert Response Address (ARA) feature of SMBus.  A device with an ALERT for the system will ACK the Alert Response Address (ARA, 0x0C) and respond with it's address as a data byte.  Once it has responded with its address, it will clear the alert, which is why it is only responding once to address 0x0C

If you need more information about SMBus or PMBus go to:

http://www.smbus.org

http://www.pmbus.org 

The response address is in the bits [7:1] position, with bit zero being a read/write bit, so address 0x38 will produce an address byte of 0x70 or 0x71 depending on read versus write.

Read out the STATUS_BYTE (0x78) and STATUS_WORD (0x79, two bytes) values to see what warning has been set.

Then you can check the associated STATUS_BYTE to see what warning or fault has been triggered in registers 0x7A - 0x80 for specific details.  Most likely the warning is in STATUS_CML - which is 0x7E

Vishnu PR 

Invalid or Unsupported data is flagged when there is a write attempt to a read only command value, or there is an attempt to write data to a command outside of it's programmable range.

Check to see if you are sending any other Commands / Write Attempts to the part prior to reading address 0x0C that might be generating the invalid data warning.

It only occurs a single time because reading from the Alert Response Address clears the Alert until a new Alert is generated.  Once the Alert is cleared, the TPS40400 no longer responds to address 0x0C until it has a new alert.

Vishnu PR 

That is what it is.  The routine is using receive byte, which starts a transaction with the device address followed by a Read Bit, which is an invalid transaction type per the PMBus standard.  That is creating the invalid data flag.

You can clear the flag by sending a "Clear Faults" to the TPS40400 device.  Clear Faults is a Send Byte (Device Address + Write Bit, Command Code = 0x03, no data bytes) to clear the warning from STATUS_CML.

Vishnu PR 

The -r option in your root command is using the "Read Byte" protocol instead of the receive byte protocol.

Receive Byte sends Address + Rd and expects immediate data returned from the part.

Read Byte sends Address + Wr followed by a Command Code or I2C register address and a repeated start, then Address + Rd 

The prior instance, receive byte, is a PMBus transaction error

The laster instance, Read Byte, is not a PMBus transaction error 

If you try running i2cdetect without the -r option from kernel, I think you will see the same issue.  If you can run the i2cdetect with the -r option in U-boot, you likely wont see the problem.