[PATCH] ARM: vexpress: initial device tree support

Jamie Lokier wrote at Thursday, January 12, 2012 5:09 AM:

Stephen Warren wrote:

quoted

Mitch Bradley wrote at Wednesday, January 11, 2012 4:16 PM:

quoted

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.

quoted

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?

quoted

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