Re: I2C adapters protocol deviation

[Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2914 bytes --]

On Sun, Apr 06, 2014 at 05:37:29PM +0200, Wolfram Sang wrote:
> On Sun, Apr 06, 2014 at 04:01:52PM +0200, Hans de Goede wrote:
> > Hi,
> > 
> > On 04/04/2014 02:26 PM, Wolfram Sang wrote:
> > > 
> > >> 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.
> > > 
> > > I'd think we need a new message flag like I2C_M_PUSHPULL which says that
> > > this message has only the direction bit instead of the address and needs
> > > a parity bit afterwards. In addition to that, we need a new
> > > functionality flag I2C_FUNC_PUSHPULL which means the host driver can
> > > handle those messages. So, the PMIC driver could query support for
> > > I2C_FUNC_SMBUS_BYTE | I2C_FUNC_PUSHPULL and if successful send messages
> > > using smbus functions with the new flag set.
> > 
> > Thanks for the input this sounds good, I guess we'll give this a shot
> > when we get around to coding up support for the p2wi block in the A31.
> 
> On a second thought, maybe more granularity is better. Like using
> I2C_M_DROP_ADDRESS and I2C_M_ADD_PARITY and then make
> I2C_CLIENT_PUSHPULL involve I2C_M_DROP_ADDRESS | I2C_M_ADD_PARITY.

I'd agree with that. Other clients/adapters might need only one of
these. Note that you'd probably need a I2C_M_DELAYED_ACK or something.

> > > Not sure about the I2C-to-PushPull switch: Is it 100% host configuration
> > > or does it also depend on the one slave attached? 
> > 
> > The datasheet we've suggests that it actually influences the one slave
> > attached. Note that u-boot on this machines will likely already have made
> > the switch, but I guess we don't want to count on that.
> 
> Can we detect if this switching was already made?

None that we're aware of. Since the PMIC is already most likely
initialised, I think we can just use it as if it was already in P2WI
mode.

> > > Are there some datasheets available?
> > 
> > The AXP221 is documented here:
> > http://linux-sunxi.org/AXP221
> > This is translated by one of our community members from a Chinese datasheet.
> > 
> > The P2WI interface is (somewhat) documented in the A31 datasheet, but we cannot
> > share that in public.
> 
> Any chance for me to get it if I sign something?

Let me see what I can do.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]