[GIT PULL FOR v3.19] R-Car DU changes

[Dave Airlie]

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.

Dave.