[RFCv2 06/10] drm: Specify primary plane at CRTC initialization

Rob Clark robdclark at gmail.com
Mon Mar 10 08:25:06 PDT 2014


On Mon, Mar 10, 2014 at 10:54 AM, Matt Roper <matthew.d.roper at intel.com> wrote:
> On Sun, Mar 09, 2014 at 05:12:31PM -0400, Rob Clark wrote:
>> On Fri, Mar 7, 2014 at 7:03 PM, Matt Roper <matthew.d.roper at intel.com> wrote:
>> > Add primary plane as a parameter to drm_crtc_init() and update all
>> > existing DRM drivers to use a helper-provided primary plane.
>> >
>> > Signed-off-by: Matt Roper <matthew.d.roper at intel.com>
>> > ---
[snip]
>> > diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > index 84c5b13..372670e 100644
>> > --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
>> > @@ -753,6 +753,7 @@ struct drm_crtc *mdp4_crtc_init(struct drm_device *dev,
>> >                 enum mdp4_dma dma_id)
>> >  {
>> >         struct drm_crtc *crtc = NULL;
>> > +       struct drm_plane *primary;
>> >         struct mdp4_crtc *mdp4_crtc;
>> >         int ret;
>> >
>> > @@ -791,7 +792,8 @@ struct drm_crtc *mdp4_crtc_init(struct drm_device *dev,
>> >
>> >         INIT_FENCE_CB(&mdp4_crtc->pageflip_cb, pageflip_cb);
>> >
>> > -       drm_crtc_init(dev, crtc, &mdp4_crtc_funcs);
>> > +       primary = drm_primary_helper_create_plane(dev);
>> > +       drm_crtc_init(dev, crtc, primary, &mdp4_crtc_funcs);
>>
>> note that msm, omap, and iirc exynos (and maybe even some others)
>> already have their own private (now primary) planes.  I suspect they
>> should be using their existing plane, rather than creating a helper
>> plane.
>>
>> BR,
>> -R
>
> Yep, agreed.  This is one of the items I called out as a TODO in the
> patch set cover letter.  I just haven't had enough time to look at those
> drivers in detail yet to figure out how they work.  Right now I believe
> they all register the same set of plane handler functions at
> drm_plane_init() that they do for their other overlay planes; I need to
> figure out whether those handler functions will actually operate
> properly on the private/primary planes, or whether the drivers were
> previously just assuming that the handlers would never get called on
> private planes and something different is needed.
>

ahh, I should have paid more attention to your cover letter.  Well,
omapdrm and msm are safe to convert (same set of plane handler fxns).
I'll update and test msm when I rebase atomic, so their will be a
patch that you can squash back in for that one.

BR,
-R

>
> Matt
>


More information about the dri-devel mailing list