All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: 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 16:00:53 +0200	[thread overview]
Message-ID: <3351453.APbVAvprkg@avalon> (raw)
In-Reply-To: <20141124130939.GO25711@phenom.ffwll.local>

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.

-- 
Regards,

Laurent Pinchart

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

  reply	other threads:[~2014-11-24 14:00 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 [this message]
2014-11-24 14:18         ` Lars-Peter Clausen
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=3351453.APbVAvprkg@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=horms@verge.net.au \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.