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

Rob Clark robdclark at gmail.com
Mon Nov 7 14:48:08 UTC 2016


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?

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


More information about the Freedreno mailing list