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
