[PATCH] ARM: vexpress: initial device tree support

Mitch Bradley wrote at Tuesday, January 10, 2012 3:36 PM:

On 1/10/2012 11:58 AM, Timur Tabi wrote:

quoted

Jamie Lokier wrote:

quoted

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.

quoted

I wish there were some way to obtain the i2c_adapter struct more easily.

quoted

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