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.
