Mitch Bradley wrote: > 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.
Do you think I should have the I2C probe function read the EDID data, and then store it in some global variable? 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. > 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. I have two platform-specific functions, "enabled_edid" and "disable_edid", that I call before/after calling fb_ddc_read(). This seems to work well, and I already have a mechanism for calling platform-specific functions from the framebuffer driver. However, Stephen Warren said I should be using the I2C mux feature instead. -- Timur Tabi Linux kernel developer at Freescale _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
