[PATCH] ARM: vexpress: initial device tree support

Stephen Warren swarren at nvidia.com
Thu Jan 12 11:52:05 EST 2012


Jamie Lokier wrote at Thursday, January 12, 2012 5:09 AM:
> Stephen Warren wrote:
> > Mitch Bradley wrote at Wednesday, January 11, 2012 4:16 PM:
> > > Perhaps I'm missing something, but it appears to me that the model is to
> > > set the correct GPIO state before each use, instead of a
> > > save-set-use-restore model.
> >
> > That's true, but the select action happens implicitly inside the I2C
> > core for any and all transactions, AIUI, so the two modes are equivalent.
> 
> If there is some reason why it would be desirable to deselect
> the DDC I2C bus after transactions, that could be added as an option
> to the GPIO I2C mux, but I can't think of a reason.

The feature is already in the GPIO I2C mux driver.

> > For an I2C mux that is controlled via I2C, you can just add the mux
> > node as a child of the I2C controller, since it has an I2C address,
> > and so putting it there makes sense.
> 
> Only if the mux's I2C slave is on the near side of the mux so that
> it's always addressable regardless of mux state, and if it's on the
> same I2C.

True. Do any I2C I2C muxes not work like that though?

> > But for an I2C mux that's controlled using GPIOs or pinmux, there's no
> > I2C address so I guess the mux shouldn't be directly underneath the I2C
> > controller.
> 
> It's connected to: (a) an I2C, and (b) a GPIO.
> 
> It can't be child of both, but I don't see why the GPIO can't be
> referred by phandle and the I2C it's muxing be the direct parent.
> That seems more natural to me.

That'd be nice, bus a GPIO I2C mux isn't an addressable device on the
I2C bus; it has no I2C accessible registers or functionality. Since
there's no I2C address, I don't think we can make it a child of the I2C
bus without breaking existing semantics of the reg property for I2C
child nodes.

-- 
nvpublic




More information about the linux-arm-kernel mailing list