i2c encoder slaves on platform i2c buses

[Matt Sealey]

Hi all,

I have a curious situation here whereby I have an SoC with an external
transmitter for the HDMI port. Actually I doubt it's so curious, just
the raft of ARM SoC KMS drivers so far have all been for very highly
integrated SoCs with internal HDMI or LVDS transmitters with fixed
display paths and no need to "dynamically" pick out which one would be
the relevant one.

Currently the i2c encoder slave system operates in quite a
card-specific manner, as far as I see we have a DRM driver which has
intimate knowledge of what could possibly be attached to it - nouveau
for example knows that when it initializes a card and the
configuration data tells it that it has a TV encoder attached, it
knows it is attached directly to the nVidia chip via a custom i2c bus,
it goes ahead and picks out that encoder and calls a function like
nv04_tv_create which registers an i2c device on top such that it would
probe and initialize this driver.

This works in my understanding because of the very specific setup and
the highly common number of cards with absolutely identical TV encoder
solutions (recommended by nVidia no doubt). You can predict with
absolute certainty that one configuration item and combination of
chipset has this specific encoder installed and probe for the driver
on an i2c bus specifically set up within the DRM driver. Since most of
the buses DRM traditionally supports are basically hotpluggable
(therefore the i2c bus is not there at boot, but only when the
cold/hotplugging is done and the driver is halfway through
initialization) or fundamentally encapsulated (a display interface
which has a fixed transmitter and connector pins on the SoC or
Northbridge and therefore only has a very specific this is fine for
those situations.

What I have here is an SoC (Freescale i.MX51 but it could be any i.MX
series to be honest) where my transmitter is connected to an i2c bus
with other devices on it (audio codec, battery controller etc.) which
is registered and all devices are registered as platform data. Given
any particular board with these SoCs on, any particular transmitter
included would probably be best set up in platform data by the board
and passed to the DRM driver concerned. What I don't want really is to
make every single combination of display interface vs. i2c encoder
specifically mentioned in the DRM driver as it makes no sense - that
is to say, I cannot really bring myself in initializing the IPU then
spooling over a raft of possible combinations of encoder attachment.
They need to communicate some data between them too - the IPU needs to
tell the SII9022 or MTL017 or any other connected transmitter what
display interface pixel format it is outputting over the data lines,
be it RGB565 (for a panel) or RGB24, or even direct YUV data (I can
output whatever data I like over the pins as I have full control over
the signal waveform going out defined by a DMA controller parameter
set and any number of muxed I/O pins). I'm currently looking at the
possibility that I may have to supply exactly the same value in
platform data twice, once for the IPU platform data to define that,
and once for the SII9022 or MTL017 platform data to make sure it knows
the same thing.

I also see a problem in that if I was to provide some kind of
"encoder_init" function via platform data (i.e do the nouveau method
but put that little init portion in the board data) so the DRM driver
could simply run a callback to get the encoder data, this would imply
that the encoder itself was built in to the kernel and not a module
(since platform data gets initialized fairly early in boot, obviously
before any of the drivers are turned on in response to a platform
device registration.. if I defined this function in the encoder
driver, exported it, the board file would need to be able to reference
that data before the module was loaded). I'm also worried about module
order; what if my drm/i2c/sii9022.ko module is meant to be probed by
udev, but the IPU driver is built-in and therefore has already looked
for an encoder and failed out? What if they are both modules, how are
they meant to interdepend on each other and load in the correct order
(encoder first, I would hope)?

So what I am wondering here is, without any way of "searching" for i2c
devices (i2c doesn't have any kind of public list of devices, neither
does the standard device abstraction) below attaching a specific
encoder with a very specific bus init code, and with no real way of
passing data back and forth, do we kind of need a new system for
registering and attaching connectors and encoders for platform
devices?

ALSA hit this problem and came up with ASoC - is anyone thinking of
working on a DRMSoC where I can have an encoder, connector, crtc as
normal but imply some sort of digital video interface between crtc and
encoder such that it can carry a list of possible encoders registered
and pass data between themselves? That way we have a DRM driver
(crtc/kms portions), encoder/connector as normal but what could be a
board-specific or SoC-version specific driver which depends on the
CRTC and encoder enforcing some kind of order? I actually think DRM is
almost there in this regard, but every DRM driver has too intimate,
driver-level knowledge of what could possibly be connected and I am
trying to avoid that to keep the transmitter and display driver
fundamentally separate.

-- 
Matt Sealey <matt at genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.