[PATCH 1/5] drm/msm/mdp5: introduce mdp5_hw_pipe

[Archit Taneja]

On 11/7/2016 8:18 PM, Rob Clark wrote:
> On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja <architt at codeaurora.org> wrote:
>>
>>
>> On 11/05/2016 09:55 PM, Rob Clark wrote:
>>>
>>> Split out the hardware pipe specifics from mdp5_plane.  To start, the hw
>>> pipes are statically assigned to planes, but next step is to assign the
>>> hw pipes during plane->atomic_check() based on requested caps (scaling,
>>> YUV, etc).  And then hw pipe re-assignment if required if required SMP
>>> blocks changes.
>>>
>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>> ---
>>>  drivers/gpu/drm/msm/Makefile              |   1 +
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 126
>>> +++++++++++++++++++-----------
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |   7 +-
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c  |  43 ++++++++++
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.h  |  39 +++++++++
>>>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  66 +++++++---------
>>>  6 files changed, 197 insertions(+), 85 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.c
>>>  create mode 100644 drivers/gpu/drm/msm/mdp/mdp5/mdp5_pipe.h
>>>
>>> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
>>> index fb5be3e..90f66c4 100644
>>> --- a/drivers/gpu/drm/msm/Makefile
>>> +++ b/drivers/gpu/drm/msm/Makefile
>>> @@ -37,6 +37,7 @@ msm-y := \
>>>         mdp/mdp5/mdp5_irq.o \
>>>         mdp/mdp5/mdp5_mdss.o \
>>>         mdp/mdp5/mdp5_kms.o \
>>> +       mdp/mdp5/mdp5_pipe.o \
>>>         mdp/mdp5/mdp5_plane.o \
>>>         mdp/mdp5/mdp5_smp.o \
>>>         msm_atomic.o \
>>> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> index f1288c7..d3d45ed 100644
>>> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
>>> @@ -119,6 +119,10 @@ static void mdp5_kms_destroy(struct msm_kms *kms)
>>>  {
>>>         struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
>>>         struct msm_gem_address_space *aspace = mdp5_kms->aspace;
>>> +       int i;
>>> +
>>> +       for (i = 0; i < mdp5_kms->num_hwpipes; i++)
>>> +               mdp5_pipe_destroy(mdp5_kms->hwpipes[i]);
>>>
>>>         if (aspace) {
>>>                 aspace->mmu->funcs->detach(aspace->mmu,
>>> @@ -323,15 +327,6 @@ static int modeset_init_intf(struct mdp5_kms
>>> *mdp5_kms, int intf_num)
>>>
>>>  static int modeset_init(struct mdp5_kms *mdp5_kms)
>>>  {
>>> -       static const enum mdp5_pipe rgb_planes[] = {
>>> -                       SSPP_RGB0, SSPP_RGB1, SSPP_RGB2, SSPP_RGB3,
>>> -       };
>>> -       static const enum mdp5_pipe vig_planes[] = {
>>> -                       SSPP_VIG0, SSPP_VIG1, SSPP_VIG2, SSPP_VIG3,
>>> -       };
>>> -       static const enum mdp5_pipe dma_planes[] = {
>>> -                       SSPP_DMA0, SSPP_DMA1,
>>> -       };
>>>         struct drm_device *dev = mdp5_kms->dev;
>>>         struct msm_drm_private *priv = dev->dev_private;
>>>         const struct mdp5_cfg_hw *hw_cfg;
>>> @@ -339,58 +334,34 @@ static int modeset_init(struct mdp5_kms *mdp5_kms)
>>>
>>>         hw_cfg = mdp5_cfg_get_hw_config(mdp5_kms->cfg);
>>>
>>> -       /* construct CRTCs and their private planes: */
>>> -       for (i = 0; i < hw_cfg->pipe_rgb.count; i++) {
>>> +       /* Construct planes equaling the number of hw pipes, and CRTCs
>>> +        * for the N layer-mixers (LM).  The first N planes become primary
>>> +        * planes for the CRTCs, with the remainder as overlay planes:
>>> +        */
>>
>>
>> Jfyi, we might need to change this a bit in the future. It'll be better to
>> get the max number of displays connected on our platform via parsing DT,
>> etc, and calculate CRTCs based on that, and not number of layermixers. Maybe
>> add a couple for writeback too. This way, we get the right number of
>> CRTCs, and we don't rely on #LMs, since we can have 2 per crtc
>> in the future.
>
> I *guess* when we get to that stage, we'll dynamically assign LM's
> too, in a similar way as hwpipe.  And I suppose we could also put a
> cap on # of crtc's based on # of encoders?

Yeah. Currently, we end up creating 2 encoders for each DSI instance,
i.e, 1 for command mode, and another for video mode. Only one can be
used at a time. If we adjust for that, then I guess # of crtcs should
equal to # of encoders.

Archit

>
> BR,
> -R
>
>> Reviewed-by: Archit Taneja <architt at codeaurora.org>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project