[PATCH] ARM: vexpress: initial device tree support

[wmb@firmworks.com (Mitch Bradley)]

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.
>
>