I2C adapters protocol deviation

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

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

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.

Since it's quite similar to and starts as an I2C bus, I'd go for the
former, but I'm really not definitive about it, and wanted to have
your feedback.

Thanks,
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 --]