On Wed, Apr 23, 2014 at 3:02 PM, Ajay kumar <ajayn...@gmail.com> wrote:
> Sorry for the previous reply,
>
> Here goes the full explaination:
>
>> Rob,
>>
>> On Tue, Apr 22, 2014 at 5:04 PM, Rob Clark <robdcl...@gmail.com> wrote:
>>> So what about, rather than adding drm_panel support to each bridge
>>> individually, we introduce a drm_panel_bridge (with a form of
>>> chaining).. ie:
>>>
>>> struct drm_panel_bridge {
>>> struct drm_bridge base;
>>> struct drm_panel *panel;
>>> struct drm_bridge *bridge; /* optional */
>>> };
>>>
>>> static void drm_panel_bridge_enable(struct drm_bridge *bridge)
>>> {
>>> struct drm_panel_bridge *pb = to_panel_bridge(bridge);
>>> if (pb->bridge)
>>> pb->bridge->funcs->enable(pb->bridge);
>>> pb->panel->funcs->enable(pb->panel);
>>> }
>>>
> We cannot call them like this from crtc helpers in the order you mentioned,
> since each individual bridge chip expects the panel controls at
> different places.
> I mean,
> -- sometimes panel controls needs to be done before bridge
> controls(ptn3460: before RST_N and PD_N)
well, this is why bridge has pre-enable/enable/disable/post-disable
hooks, so you can choose before or after..
> -- sometimes in between the bridge controls (ps8622: one panel control
> before SLP_N and one after SLP_N)
> -- sometimes panel controls needs to be done after bridge controls.
I am not convinced that a generic panel/bridge adapter is not
possible. Maybe we need more fine grained fxn ptr callbacks, although
seems like pre+post should give you enough. It would certainly be
easier than having to add panel support in each individual bridge
driver (which seems like it will certainly result that only certain
combinations of panel+bridge actually work as intended)
> So, putting these drm_panel controls inside individual bridge drivers will
> work,
> but keeping them in crtc_helpers might break stuff.
I'm not talking about crtc changing helpers.
BR,
-R
> Thanks and regards,
> Ajay Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
