Wolfram, On Fri, Mar 29, 2013 at 4:58 AM, Wolfram Sang <w...@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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss