dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>
Cc: Simon Horman <horms@verge.net.au>,
	magnus.damm@gmail.com, dri-devel@lists.freedesktop.org
Subject: Re: [GIT PULL FOR v3.19] R-Car DU changes
Date: Mon, 24 Nov 2014 15:18:17 +0100	[thread overview]
Message-ID: <54733E29.8000701@metafoo.de> (raw)
In-Reply-To: <3351453.APbVAvprkg@avalon>

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.

- Lars



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2014-11-24 14:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07  6:25 [GIT PULL FOR v3.19] R-Car DU changes Laurent Pinchart
2014-11-07  9:19 ` Daniel Vetter
2014-11-24  9:46   ` Laurent Pinchart
2014-11-24 13:09     ` Daniel Vetter
2014-11-24 14:00       ` Laurent Pinchart
2014-11-24 14:18         ` Lars-Peter Clausen [this message]
2014-11-24 20:01           ` Dave Airlie
2014-11-24 20:29             ` Lars-Peter Clausen
2014-11-24 21:35               ` Rob Clark
2014-11-24 15:18         ` Daniel Vetter
2014-11-25  0:11     ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54733E29.8000701@metafoo.de \
    --to=lars@metafoo.de \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=horms@verge.net.au \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=magnus.damm@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox