Hello, On Tue, 16 Sep 2014 12:46:50 +0200 Manuel Bouyer <[email protected]> wrote:
> Hello, > I'm looking for advice about the design for a new driver. > > the AM335x arm SoC includes a framebuffer, which outputs a parallel > digital video signal. A HDMI transmitter which will serialize this > video signal can be connected to the SoC, which then allows to > connect external monitors. The beaglebone black includes a TDA19988 > HDMI transmitter. > > A driver is needed for the TDA19988, to get the EDID from the > monitor, and also configure the transmitter appropriately. So, in > addition to the video output lines, the TDA19988 is connected to one > of the I2C controller of the AM335x (one the beaglebone black it's > the I2C0 controller, but other boards could use any of the AM335x's > I2C controllers). In addition, the TDA19988 can transmit a digital > audio signal, which it gets from the SoC's "multichannel audio serial > port". > > Now my question is how should the TDA19988 appears in the device > tree ? I could make it a child of the I2C controller, with the > framebuffer and audio drivers using ad-hoc callbacks to the TDA19988 > driver. Or I could make it a child of the framebuffer, the > framebuffer driver redirecting I2C requests to the I2C controller > driver. > > I think the second solution is less hackish and more flexible; > but I'd like to hear from people more familiar than I am with > video hardware and drivers. I had a similar problem with the valkyriefb driver on macppc - the pixel clock generator is hooked to an i2c port controlled by cuda, nowhere near the actual fb's control registers. Got around it ( kinda ) by having a driver attach to the clock generator ( videopll at iic ... ) and let valkyriefb look for it by name, assuming that there's only one since it's an onboard device. Maybe some MD, board-specific code should 'know' the wiring and pass the required info as device properties? have fun Michael
