On Mon, Nov 7, 2016 at 5:38 AM, Archit Taneja <architt@xxxxxxxxxxxxxx> 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@xxxxxxxxx>
>> ---
>> 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@xxxxxxxxxxxxxx>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
