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

[Rob Clark]

On Thu, Dec 3, 2015 at 10:28 AM, Laurent Pinchart
<laurent.pinchart at ideasonboard.com> 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..
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>

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.

BR,
-R

> --
> Regards,
>
> Laurent Pinchart
>