Daniel,
On Sun, Apr 27, 2014 at 6:25 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
> On Fri, Apr 25, 2014 at 8:17 AM, Ajay kumar <ajaynumb@xxxxxxxxx> wrote:
>> We can call panel_enable/disable at the right point. Even the bridge chips
>> expect the same. So, I am not ok with combining the bridge and panel and
>> calling the fxn pointers from crtc_helpers.
>> So, either we leave it the way it is in this patch (call drm_panel
>> functions at right points) or
>> we don't use drm_panel to control the panel sequence and instead use few DT
>> properties and regulators, inside the bridge chip driver.
>
> That wasn't really suggested, but instead the idea was to provide a
> default drm_bridge which wraps the drm_panel so that you could more
> easily chain them up.
What do you mean by "default" drm_bridge?
I just want to clear few things. Let me explain what I have understood:
What I understand is that Rob wants me to create a common
structure which wraps up drm_panel and drm_bridge into a single structure:
struct drm_panel_bridge {
struct drm_bridge base;
struct drm_panel *panel;
struct drm_bridge *bridge; /* optional */ ==> Really not sure why
this is needed!
};
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);
}
And now, the above function becomes a common function
(also with an ordering issue btw panel and bridge).
Where do we keep it? And, where do we call it from?
> Also I'm not really happy that the bridge callbacks have been added to
> the drm helpers (I'd prefer if driver callbacks would bear that
> responsibility). But you can always create your own drm_bridge
> integration.
Do you mean, the bridge calls should be moved out of common drm_helper
functions and called from platform specific drivers instead?
> In any case your concern that drivers need to control
> when certain callbacks are called is shared by everyone here afaics.
> And I also don't see any issues with Rob's proposal in this regard.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Please let me know if my understanding is correct and correct me if
there is a misconception.
Regards,
Ajay Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
