On 11/24/2014 09:01 PM, Dave Airlie wrote: > On 25 November 2014 at 00:18, Lars-Peter Clausen <lars at metafoo.de> wrote: >> On 11/24/2014 03:00 PM, Laurent Pinchart wrote: >>> >>> Hi Daniel, >>> >>> (CC'ing Rob Clark and Lars-Peter. As a reminder we're discussing the "drm: >>> Decouple EDID parsing from I2C adapter" patch available at >>> git://linuxtv.org/pinchartl/fbdev.git drm/next/du) >>> >>> On Monday 24 November 2014 14:09:39 Daniel Vetter wrote: >>>> >>>> On Mon, Nov 24, 2014 at 11:46:18AM +0200, Laurent Pinchart wrote: >>>>>> >>>>>> - the interface looks rather backwards: Either this still does i2c >>>>>> reads, and then you'd just need a i2c-over-whatever adapter to make >>>>>> it >>>>>> work. Or you have other magic means to optain an edid block, in >>>>>> which >>>>>> case just do that and then feed the edid drm_add_edid_modes. >>>>> >>>>> >>>>> I have a magic way to get EDID over I2C :-) Basically the ADV7511 >>>>> controls >>>>> the DDC bus, and exposes EDID data over I2C using vendor commands. To >>>>> read an EDID block I have to write an ADV7511 register over I2C with the >>>>> block number, wait for an interrupt, read a status register to check >>>>> whether EDID data is available or whether an error occurred, and then >>>>> read EDID data from the ADV7511 over I2C in 64-bytes chunks. This needs >>>>> to be repeated for every block. I thus can't use drm_get_edid() >>>>> directly. >>>> >>>> >>>> Sounds familiar. See the special ddc-over-sdvo i2c bus we register in >>>> intel_sdvo.c, specifically look at intel_sdvo_init_ddc_proxy. It is a bit >>>> of boilerplate, but in the end just amounts to 3 small functions and one >>>> tiny vtable to wire it all up cleanly. >>> >>> >>> That's what I would have done as well if I had a device-specific I2C >>> adapter >>> connected to the DDC bus, but in this case the interface exposed by the >>> ADV7511 to the SoC over I2C consists of higher level device-specific I2C >>> commands to read EDID data. There is no low-level I2C read/write >>> primitives >>> available. I would thus need to expose a fake adapter that would receive >>> I2C >>> commands, parse them to detect an EDID block read, retrieve the EDID data >>> and >>> return them from the fake read. That doesn't make much sense to me. >> >> >> The intel sdvo looks just like a simple I2C mux which will just pass-through >> messages from the master to the EDID EEPROM. The ADV7511 is unfortunately a >> bit different. You tell it to fetch the EDID information, then it will do >> some magic and then you can read the EDID back. Abstracting this as a this >> as a I2C controller will, while possible, result in a fair amount of boiler >> plate code that will not look particularly pretty. > > It sounds also a bit like DP auxch also, or even how on UDL we get the edid > over USB. > > I'd rather see not pretty code that only one person had to look at though :-) > with lots of comments on the hw design that demands ugly.
I'd rather not see that if I'm the person who has to look at it ;) But looking around it appears as if this is a more common thing among external HDMI encoders though. E.g. the tda998x has the exact same issue and the current driver just copy&pastes drm_do_get_edid() and plugs in its own EDID block retrieval method. On the other hand the patch that makes it possible to use a different backend then a raw I2C adapter to fetch the EDID is extremely trivial and doesn't make the existing code more complex in any way.
