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

[Daniel Vetter]

On Mon, Nov 24, 2014 at 04:00:53PM +0200, 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.

Yeah that's a bit annoying indeed. So if you capture that in the commit
message + kerneldoc (stating clearly what the other options are and when
to use this) the I'm ok with this patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch