HDMI transmitter attachement

[Manuel Bouyer]

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.

[Manuel Bouyer]

Does it have you appear in the device tree at all? I had a similar situation
with the DTV host controller drivers, and I ended up not attaching them to
the device tree at all.
So e.g. sys/dev/usb/auvitek_i2c.c implements struct i2c_controller but
doesn't appear in the device tree. There are separate "drivers" for the
different tuners and demodulators but they are used directly by the host
controller drivers (au8522, lg3303, xc3028, xc5k, tvpll, nxt2k, mt2131,
cx24227).

How do you say which driver you want in the kernel config file then ?

[Jared McNeill]

Post by Manuel Bouyer
How do you say which driver you want in the kernel config file then ?

In my case I have vendor / product IDs to help determine the board type.

Interesting problem though -- and I missed the part where you were using
an external i2c controller the first time through. I'm working on a
similar driver for the Cubieboard2 at the moment but the i2c controller is
part of the HDMI module, so I can simply use dev/i2c/ddc.c from there.

Do you plan on running the HDMI output and framebuffer at the same
resolution? The reason I ask is that for cubie I was thinking to run the
framebuffer at a fixed resolution, let HDMI configure itself
automatically, and use the scaler to make it all work. Then to get a
native mode right mode for X, expose the display info with
WSDISPLAYIO_GET_EDID and have the X driver pick a new mode to use. I'm
not confident in wsdisplay's ability to handle hotplug / mode changes for
the console device. Maybe someone can prove me wrong :)

[Manuel Bouyer]

Post by Jared McNeill

Post by Manuel Bouyer
How do you say which driver you want in the kernel config file then ?

In my case I have vendor / product IDs to help determine the board type.

that's what I don't have here. As it's 2 different and independant chips,
you can have various mixes.

Post by Jared McNeill
Interesting problem though -- and I missed the part where you were using an
external i2c controller the first time through. I'm working on a similar
driver for the Cubieboard2 at the moment but the i2c controller is part of
the HDMI module, so I can simply use dev/i2c/ddc.c from there.

I hope to use the existing ddc too, of course :)
The framebuffer driver can export an I2C bus, which just redirects to the
right controller.

Post by Jared McNeill
Do you plan on running the HDMI output and framebuffer at the same
resolution?

For now that's my plan, yes. Unless wsdisplay makes it really too hard :)

[Jared McNeill]

Post by Manuel Bouyer
that's what I don't have here. As it's 2 different and independant chips,
you can have various mixes.

You could pass down the info with device_register maybe? In
beagle_machdep.c you can detect the board type:

For BeagleBone the board type is in an EEPROM on I2C0 (see BeagleBone SRM
7.11 EEPROM for format).

For BeagleBoard you can detect the board type by reading a
couple of GPIO pins -- http://elinux.org/BeagleBoardPinMux#Board_IDs

[Manuel Bouyer]

Post by Manuel Bouyer
that's what I don't have here. As it's 2 different and independant chips,
you can have various mixes.

You could pass down the info with device_register maybe? In beagle_machdep.c

And what about other boards ? Or beaglebone capes using a different
wiring, or a different video driver (e.g. VGA output).

[Jared McNeill]

Post by Manuel Bouyer
And what about other boards ? Or beaglebone capes using a different
wiring, or a different video driver (e.g. VGA output).

I would leave that as a problem for other boards :)

Capes have their own EEPROM I think for detecting them.

[Manuel Bouyer]

Post by Jared McNeill

Post by Manuel Bouyer
And what about other boards ? Or beaglebone capes using a different
wiring, or a different video driver (e.g. VGA output).

I would leave that as a problem for other boards :)

Actually I'd like to see my work reusable for other boards ...

Post by Jared McNeill
Capes have their own EEPROM I think for detecting them.

Not all of them (I have one which did came with an empty prom).
And when I proposed to use the a device tree to drive the kernel's autoconf
(among other things to be able to reuse the beablebone's eprom contents)
it was rejected ...

[Jared McNeill]

Post by Manuel Bouyer
Actually I'd like to see my work reusable for other boards ...

Doesn't mean that it's not reusable, just that other boards
device_register have to specify the tranceiver type.

Post by Manuel Bouyer

Post by Jared McNeill
Capes have their own EEPROM I think for detecting them.

Not all of them (I have one which did came with an empty prom).
And when I proposed to use the a device tree to drive the kernel's autoconf
(among other things to be able to reuse the beablebone's eprom contents)
it was rejected ...

Device tree would be great! Or at least fixing uboot to pass uenv
variables.

[Jared McNeill]

Does it have you appear in the device tree at all? I had a similar
situation with the DTV host controller drivers, and I ended up not
attaching them to the device tree at all.

So e.g. sys/dev/usb/auvitek_i2c.c implements struct i2c_controller but
doesn't appear in the device tree. There are separate "drivers" for the
different tuners and demodulators but they are used directly by the host
controller drivers (au8522, lg3303, xc3028, xc5k, tvpll, nxt2k, mt2131,
cx24227).

Hope this helps
Jared

Post by Manuel Bouyer
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.
--
NetBSD: 26 ans d'experience feront toujours la difference
--

[Michael]

Hello,

On Tue, 16 Sep 2014 12:46:50 +0200

Post by Manuel Bouyer
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

[Manuel Bouyer]

Post by Michael
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?

Yes, that's probably what I'll end up to do (I hope to be able to do it
from kernel config file, via options). In my case I noticed that the
tda19988 is not the only thing on this I2C bus, there's also the power
controller and an eeprom at last (and probablty more via capes).
So I ended up attaching it to iic, and I'll have a way for tifb to find
it and callback to it.