Re: [PATCH v1 1/2] iio: imu: inv_mpu6050: Add i2c mux for by pass

[Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>]

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


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-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]