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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
