On 1/11/2012 10:17 AM, Timur Tabi wrote:
Mitch Bradley wrote:
I think that would not be a good design. Presence and location of EDID
data is not something that a generic I2C driver should know. It's the
video controller that knows that EDID exists, where it is located
(device ID 0x50 and addresses within that device), and what it means.
But the video driver does not know what I2C *bus* it's on. I have been unable
to come up with a way to obtain the proper i2c_adapter object to use when
looking for EDID data.
You make device nodes for each of the i2c adapters (possibly with a GPIO
I2C mux node underneath the EDID one), then you point to the correct
adapter (or mux) node with a phandle-valued property in the video node.
Of course, you need the deferral patch cited in another message.
That won't work if I have multiple video controllers, since I won't know
which EDID data goes with which video controller. I tried adding a call to
i2c_add_driver() in my framebuffer driver, but the I2C probe function was
called *after* the framebuffer's probe function, so that doesn't help me.
Then there needs to be some sort of ordering or dependency to ensure
that the I2C driver is activated before the framebuffer driver tries to
use it.
I don't know how to do that, either.
Either way, you need platform-dependent functions to do the switching,
and you need to select the appropriate channel. Personally, I don't see
the advantage of using the mux device in this case. It's just adding
complexity with no payback.
I'm always in favor of doing things the simpler way.
_______________________________________________
devicetree-discuss mailing list
[email protected]
https://lists.ozlabs.org/listinfo/devicetree-discuss
