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

[Laurent Pinchart]

Hi Rob,

On Thursday 03 December 2015 10:55:12 Rob Clark wrote:
> On Thu, Dec 3, 2015 at 10:28 AM, Laurent Pinchart wrote:
> > 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).
>
> I don't know that we can blame this on the desktop folks like that..

To be clear I'm not blaming anyone here, just pointing out that the grass 
isn't all green on the other side ;-)

> after all i2c-slave was sufficient for embedded devices for some time,
> and it was an improvement over what came before when it comes to
> sharing external encoder support (ie. nothing)
>
> But, as was the case with atomic, the framework evolves.  And as
> atomic roll-out has shown, it doesn't require a flag-day if you accept
> some duplication.
> 
> >> 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.
> 
> As opposed to a change everything at once approach, and corresponding
> updates to drivers for hw you don't have.  That sounds like a *much*
> saner plan</sarcasm>

There's a single driver using the adv7511 I2C slave encoder, that's the rcar-
du driver. I will make sure to update and test the driver.

> Seriously, the cost of duplicating a bit of code is low.  Especially
> when the code you are duplicating is low churn.  Duplicating lets
> other drivers that use adv75xx via slave-encoder migrate over at their
> own pace.  Similar to how atomic was rolled out.  To me that sounds
> like the much more practical way forward.
> 
> > The path forward is pretty clear, the issue is to find someone who can do
> > the work.
> 
> Maybe the end goal is clear.  But apparently the path forward less so.

-- 
Regards,

Laurent Pinchart