[PATCH 3/5] drm/i2c: adv7511: Refactor encoder slave functions

Laurent Pinchart laurent.pinchart at ideasonboard.com
Thu Dec 3 07:28:45 PST 2015


On Thursday 03 December 2015 10:02:02 Rob Clark wrote:
> On Mon, Jul 27, 2015 at 4:59 AM, Laurent Pinchart wrote:
> > On Monday 27 July 2015 11:46:57 Archit Taneja wrote:
> >> ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on
> >> the other hand, is going be a normal i2c client device creating bridge
> >> and connector entities.
> > 
> > Please, no. It's really time to stop piling hacks and fix the problem
> > properly. There's no reason to have separate APIs for I2C slave encoders
> > and DRM bridges. Those two APIs need to be merged, and then you'll find
> > it much easier to implement ADV7533 support.
> 
> btw, what is the status here?  I'd kind of lost track of the
> discussion, but I'm getting impatient that it is somehow taking
> ridiculously long to get adv7533 support merged.  (It's good thing the
> x86/desktop folks don't bikeshed so much..  I'd hate to wait a year
> for my new laptop to be supported..)

I'd hardly call the overall architecture on which drivers rely a bikeshed (and 
maybe if x86/desktop folks cared more about embedded there would be more 
willingness to make the framework evolve in an embedded-friendly way).

> Anyways, if needed, just copy/paste the adv7511/7533 code into a
> separate bridge-only driver, and we'll use that.  Once the
> i2c-slave-encoder users for adv7511 are converted over, we can delete
> the original slave encoder driver.  That seems like a sane transition
> plan to a bridge-only world.

It's a very sane way to make sure nobody will do the work and keep two copies 
of the same code for a long time, yes.

The path forward is pretty clear, the issue is to find someone who can do the 
work.

-- 
Regards,

Laurent Pinchart



More information about the dri-devel mailing list