On 04/16/2013 03:36 AM, Wolfram Sang wrote:
> Doug,
>
> On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
>> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
>> where masters need to claim the bus with a GPIO before they can start
>> a transcation. This should g
On Tue, Apr 16, 2013 at 11:36:33AM +0200, Wolfram Sang wrote:
> Doug,
>
[ ... ]
>
> "callenge & response"?
>
> ...
>
> > diff --git a/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> > b/drivers/i2c/muxes/i2c-arb-gpio-challenge.c
> > new file mode 100644
> > index 000..bda020a
> > --- /dev/nul
> "Wolfram" == Wolfram Sang writes:
Hi,
>> +- their-claim-gpios: The GPIOs that the other sides use the claim the bus.
>> + Note that some implementations may only support a single other master.
Wolfram> Stronger? "Currently, only one other master is supported"?
Also there's a typo: s/
Doug,
On Tue, Apr 09, 2013 at 02:34:28PM -0700, Doug Anderson wrote:
> The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
> where masters need to claim the bus with a GPIO before they can start
> a transcation. This should generally only be used when standard I2C
> multimaster
The i2c-arb-gpio-challenge driver implements an I2C arbitration scheme
where masters need to claim the bus with a GPIO before they can start
a transcation. This should generally only be used when standard I2C
multimaster isn't appropriate for some reason (errata/bugs).
This driver is based on cod
