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@xxxxxxxxx> 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
Attachment:
pgpptj8RiI135.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
