On Sat, Nov 22, 2014 at 11:58:56AM +0000, Jonathan Cameron wrote:
> On 18/11/14 17:53, Srinivas Pandruvada wrote:
> > This chip has a mode in which this chipset can be i2c master. But
I don't think it is a master...
> > the current upstream driver doesn't support such mode as there is
> > some limited support of clients, which can be connected.
> >
> > To attach such clients to main i2c bus chip has to be set up in
> > bypass mode. Creates an i2c mux, which will enable/disable this mode.
> > This was discussed for a while in mailing list, this was the decision.
... but more a by-pass? What is the advantage of putting slaves behind
the by-pass instead of directly connecting it to the bus?
> > This change also provides an API, which allows clients to be created for
> > this mux adapter.
> >
> > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@xxxxxxxxxxxxxxx>
> Still wants to go to Wolfram and linux-i2c, given we are adding an i2c mux
> deep in an IIO driver.
>
> Whilst Wolfram was happy (iirc) with the approach he might want to take
> a look at the implementation (and I'd rather have his ack before taking this).
Thanks! Please notice my new email address.
> > +static struct i2c_adapter *inv_mux_adapter;
static??? And if I have multiple mpu6050 on the bus?
...
> > +struct i2c_client *inv_mpu6050_add_mux_client(char *name, unsigned short addr,
> > + int irq, void *plat_data)
> > +{
Huh? Why do we need that? Why can't we use the instantiation methods we
already have?
Rest looks okay from a first glimpse.
Wolfram
Attachment:
signature.asc
Description: Digital signature
