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

[Ajay kumar]

On Mon, Jul 21, 2014 at 6:10 PM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> 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
Going with Thierry's opinion, if the bridge is allowed to do panel integration,
there is no need for a bridge_chain. I mean a bridge_chain doesn't exist in
my case at all. I have just one bridge which integrates a panel.
Is it really necessary to keep next_bridge pointer and other helpers?

Ajay