[RESEND PATCH V5 08/12] drm/bridge: ptn3460: Support bridge chaining

Thierry Reding thierry.reding at gmail.com
Mon Jul 21 05:40:54 PDT 2014


On Mon, Jul 21, 2014 at 05:28:13PM +0530, Ajay kumar wrote:
> Hi Thierry,
> 
> On Mon, Jul 21, 2014 at 1:52 PM, Thierry Reding
> <thierry.reding at gmail.com> wrote:
> > On Fri, Jul 18, 2014 at 02:13:54AM +0530, Ajay Kumar wrote:
> > [...]
> >> Also, remove the drm_connector implementation from ptn3460,
> >> since the same is implemented using panel_binder.
> >
> > I think that's a step backwards. In fact I think the panel-bridge binder
> > driver shouldn't be needed at all. At least not for now. We have a very
> > limited number of bridge drivers, so it shouldn't hurt at this stage to
> > implement the connector instantiation within each driver. Once we have
> > more bridge drivers, and therefore a better understanding of what they
> > need, we can always add something like the panel-binder (though I think
> > it should be library code, similar to the drm_encoder_helper_add() API,
> > rather than this kind of self-contained object).
> panel_binder was needed to wrap around panel as a bridge, and this was in turn
> needed because people wanted to represent a bridge+panel combo as a chain
> of bridges.
> So, if we choose to drop panel_binder, we choose to drop the idea of chaining
> the bridges, and end up calling drm_panel functions directly from
> individual bridges.
> And, the bridge will implement the connector functions as you suggested.
> I am okay with this, if Daniel/Rob don't have an issue with this.

I think bridge chaining and panel handling are separate issues. That's
why I think we shouldn't mix them like this. From earlier discussion[0]
the conclusion was that the final element in the chain should implement
a connector (with the appropriate type). Often that last element would
be an encoder (when there are no bridges). Sometimes the last element
would be a bridge. It's logical for that same element to also implement
the panel integration since it's closely tied to the connector.

Thierry

[0]: http://lists.freedesktop.org/archives/dri-devel/2014-May/059685.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140721/6a685afb/attachment.sig>


More information about the dri-devel mailing list