On Thu, Apr 03, 2014 at 05:30:09PM +0200, Hans de Goede wrote: > Hi, > > On 04/03/2014 04:55 PM, Maxime Ripard wrote: > > Hi Wolfram, > > > > On the Allwinner A31, the PMIC communicates with the SoC through a bus > > looking quite similar to I2C, while being pretty different. > > > > The communication starts with the PMIC through the regular I2C > > protocol, but it's only used to initialize the PMIC, and switch to a > > mode called "Push/Pull 2 Wire Interface". > > > > That bus is using SDA and SCL, with the start and stop conditions > > exactly like I2C does, but: > > - Once the start condition has been issued, the address isn't sent, > > only a direction bit. Hence, it does not support multiple devices > > anymore. > > - Once that direction bit has been sent, the master sends the > > register it wants to read from/write to, over 8 bits, followed by > > one parity bit. > > - Whenever you're writing, the master then sends the data over 8 > > bits, followed once again by a parity bit. Then, and only then, an > > ACK is issued by the slave. > > - Whenever you're reading, the master then clocks SDL and the slave > > drives SDA for 8 bits plus 1 parity bit. If there was some kind of > > error, the slave will pull SDA up for 9 cycles, resulting in a > > parity error. Like with I2C though, since it is the only and last > > byte it's receiving, the master won't issue an ACK. > > > > Obviously, to go ahead with the PMIC support, we need to support this > > controller and bus first. I can't really decide whether it's within > > the scope of the allowed protocol deviations of I2C or if we should > > create a whole new bus for it. > > I've been thinking about this too. In the mean time I have slept quite a > few nights on this now and swung my opinion from use i2c subsys to do our > own bus and back again. But since I've actually added support for this > to u-boot and I now know the device better I believe using the i2c > subsys is the best solution for this. > > The PMIC does seem to start in i2c, and then gets switched to this new > push-pull 2 wire i2c-ish protocol on init. So it does have a slave address, > but that is used only once, and then the bus is for a single device only. > > Note there seems to be no way to use the host in a regular i2c mode. It has > a setup mode where it does a single regular i2c write (or so I believe) and > then it is in its own custom mode from there on. Well, in theory, you could. It has a register where you can control the levels of SDA and SCL, so you could bitbang the bus using them. But I'm not sure we want to do that :) > So what we really have is a single slave i2c host sort of. At least > we could model it like that. The host could be told which address to > listen to (and which single i2c write to do to init the pmic) through > devicetree and then all the differences would be hidden in the host > driver, ie we would check the slave-address and if it is not the single > one we support, we just return the appropriate error for a device not > acking, and everything should work as a regular i2c host which > only supports i2c_smbus_read_byte and i2c_smbus_write_byte. > > IOW the i2c_algorithm struct for the host would not set master_xfer, > only smbus_xfer and its functionality function would return > I2C_FUNC_SMBUS_BYTE Yep, it would make sense. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Attachment:
signature.asc
Description: Digital signature
