Mitch Bradley wrote at Tuesday, January 10, 2012 3:36 PM: > On 1/10/2012 11:58 AM, Timur Tabi wrote: > > Jamie Lokier wrote: > > > >> It still needs to know *which* I2C bus master is connected to the > >> display. Some graphics hardware has multiple, e.g. one to talk with > >> the DVI/HDMI transmitter, another connected by cable to the display. > > > > Yes, this is my problem. I have multiple I2C busses on my system, and > > there's no way to guess which > one is connected to the DVI port. A phandle in the device tree is the only > way I can figure out which > I2C bus to use. But there's another problem. I can use > of_find_i2c_device_by_node() to determine the > i2c_client (and therefore, the i2c_adapter) to use for fb_ddc_read(). > However, that function only > works if the I2C device was probed. That typically is done by the I2C driver > for the device, but > there is no "edid" device driver. So my framebuffer driver is going to have > to pretend to be one. > > It seems to me that having the framebuffer driver handle the EDID > "driver" function is exactly the right thing. The framebuffer driver is > the only thing that cares about EDID information. Given a phandle > reference to an I2C interface, the "driver" is just "call the I2C read > routine" - plus, in your case, toggling the GPIO pin. > > That GPIO pin thing is annoying, but not sufficiently complex or common > that it warrants having a separate EDID driver. You could define a > platform-specific property to tell your framebuffer driver that it needs > to do that GPIO thing. It's a hack, but the GPIO thing is inherently a > hack, so there will be some ugliness somewhere as a result.
Shouldn't there be an I2C bus mux driver to handle this? The kernel already has support for bus muxes controller over I2C. I think here you just need to implement the same thing, but with the control via a GPIO. In the future I hope to implement something similar but controller using an SoC's pinmux HW (where a single controller's I2C signals can be routed to different sets of pins on the SoC using its pinmux) - a feature which at least some Tegra boards use for sharing DDC and something else. Such a mux can be explicitly represented in DT, with multiple I2C child bus nodes, I think. > > I wish there were some way to obtain the i2c_adapter struct more easily. > > > >> I have worked with devices that shared the same I2C for DDC and > >> talking with on-board devices. (That was a bad idea, as some monitors > >> clamp the lines high or low excessively even when switched off.) Point > >> here is sometimes there's a dedicated one for DDC; sometimes there isn't. > > > > I also have this problem. I need to toggle a GPIO in order to get the I2C > > bus connected to the DVI > port. The same I2C bus is used for the audio codec and a bunch of other > devices. Our SOC has four > I2C busses, so I don't understand why the board designed didn't dedicate one > for the DDC. But I can > easily work around this issue. -- nvpublic _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
