[PATCH v4 1/3] i2c: mux: Add i2c-arbitrator-cros-ec 'mux' driver

[Doug Anderson]

Wolfram,

On Fri, Mar 29, 2013 at 4:58 AM, Wolfram Sang <wsa at the-dreams.de> wrote:
> I can't recall the reason standard I2C bus arbitration is not working
> and why this is needed. I need the feeling this is a solution and not a
> workaround. I mean driver bugs can be fixed and I am unsure if it is a
> good idea to open the i2c-arbitration-*.c namespace.

Thanks for the feedback!

Separately from a discussion of the technical merits, I'd say that
this patch is needed because the Embedded Controller (EC) on the ARM
Chromebook shipped expecting to communicate with this scheme.  While
it is technically possible to update the read-write copy of the
software on the EC, it would be prohibitively difficult to ship an
update that changed the communication method.  Specifically we'd still
require fallback to the old scheme in cases where we need to talk to
the read-only copy of the software on the EC.

...but we can also talk technical merits.  One person on our team
spent a bit of time thinking about this and decided that traditional
i2c arbitration can't actually be used in this case (aside from the
general experience about multimaster being buggy).  Specifically, our
bus is setup with these devices on it:

* AP (running Linux) - Master only.  Only talks when awake.
* EC (running custom code) - Acts as a master and _also_ a slave.
* Battery (smart battery) - Only a slave
* Power Management Unit (PMU - tps65090) - Only a slave

Both the AP and the EC would like to talk to the battery and PMU.  The
AP needs to be able to talk to the EC.

The problem here is that the EC is both a master and a slave.  It's my
understanding that if the AP tries to talk EC on the bus at the same
time that the EC is trying to talk to the battery of PMU that we can
get into trouble.  Specifically the EC needs to be switched to "master
mode" to talk to the battery/PMU and thus has a period of time where
it won't be listening for the AP's messages.  The arbitration lines
make it very clear that the EC has gained mastery of the bus and is
free to switch into "master mode" without worrying that the AP may
talk to it.

I will freely admit that I am not an expert on multimater I2C so if
the above is incorrect then let me know.  As I said, though, it's
still useful to get this patch in because that's simply how the
shipping EC expects to communicate.

Thanks!  :)

-Doug