dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Arnaud Vrac <rawoul@gmail.com>
Cc: freedreno@lists.freedesktop.org,
	Jonathan Marek <jonathan@marek.ca>,
	Stephen Boyd <sboyd@kernel.org>,
	MSM <linux-arm-msm@vger.kernel.org>,
	Abhinav Kumar <abhinavk@codeaurora.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org, Sean Paul <sean@poorly.run>
Subject: Re: [Freedreno] [PATCH v2 5/6] drm/msm/dpu: drop unused lm_max_width from RM
Date: Thu, 3 Jun 2021 00:44:20 +0300	[thread overview]
Message-ID: <7b9aa146-3cb3-8164-5f26-388171230100@linaro.org> (raw)
In-Reply-To: <CAN5H-g7hWgyqtFbUpzesyKXmWr=FtFtXBKDSbCKx+1dUjxP10w@mail.gmail.com>

On 16/05/2021 04:21, Arnaud Vrac wrote:
> Hi Dmitry,
> 
> Le dim. 16 mai 2021 à 00:58, Dmitry Baryshkov
> <dmitry.baryshkov@linaro.org> a écrit :
>>
>> No code uses lm_max_width from resource manager, so drop it.
> 
> I have a pending patch which uses this value to properly determine the
> number of LMs to use in the topology. Currently the code uses a
> hardcoded value of MAX_HDISPLAY_SPLIT (1080), but in reality I believe
> it should be the lm max width (typically 2560). This will avoid using
> two LMs to render resolutions like 1280x720 or 1920x1080.

As a second thought, I think we better have this value in the hw_catalog 
itself rather than calculating it in the dpu_rm. WDYT?

> 
> I haven't managed to make hdmi work yet on DPU (testing on MSM8998) so
> I'm not ready to send the patch yet, but it doesn't seem to trigger
> any error.
> 
> -Arnaud
> 
> 
>>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> ---
>>   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12 ------------
>>   drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h |  4 ----
>>   2 files changed, 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>> index c36700a06ff2..ec4387ad1182 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
>> @@ -88,18 +88,6 @@ int dpu_rm_init(struct dpu_rm *rm,
>>                          goto fail;
>>                  }
>>                  rm->mixer_blks[lm->id - LM_0] = &hw->base;
>> -
>> -               if (!rm->lm_max_width) {
>> -                       rm->lm_max_width = lm->sblk->maxwidth;
>> -               } else if (rm->lm_max_width != lm->sblk->maxwidth) {
>> -                       /*
>> -                        * Don't expect to have hw where lm max widths differ.
>> -                        * If found, take the min.
>> -                        */
>> -                       DPU_ERROR("unsupported: lm maxwidth differs\n");
>> -                       if (rm->lm_max_width > lm->sblk->maxwidth)
>> -                               rm->lm_max_width = lm->sblk->maxwidth;
>> -               }
>>          }
>>
>>          for (i = 0; i < cat->ctl_count; i++) {
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
>> index ee90b1233430..0c9113581d71 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
>> @@ -17,14 +17,10 @@ struct dpu_global_state;
>>    * struct dpu_rm - DPU dynamic hardware resource manager
>>    * @mixer_blks: array of layer mixer hardware resources
>>    * @ctl_blks: array of ctl hardware resources
>> - * @lm_max_width: cached layer mixer maximum width
>> - * @rm_lock: resource manager mutex
>>    */
>>   struct dpu_rm {
>>          struct dpu_hw_blk *mixer_blks[LM_MAX - LM_0];
>>          struct dpu_hw_blk *ctl_blks[CTL_MAX - CTL_0];
>> -
>> -       uint32_t lm_max_width;
>>   };
>>
>>   struct dpu_kms;
>> --
>> 2.30.2
>>
>> _______________________________________________
>> Freedreno mailing list
>> Freedreno@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/freedreno


-- 
With best wishes
Dmitry

  reply	other threads:[~2021-06-02 21:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 22:57 Dmitry Baryshkov
2021-05-15 22:57 ` [PATCH v2 1/6] drm/msm/dpu: get DSPP blocks directly rather than through RM Dmitry Baryshkov
2021-05-15 22:57 ` [PATCH v2 2/6] drm/msm/dpu: get MERGE_3D " Dmitry Baryshkov
2021-05-15 22:57 ` [PATCH v2 3/6] drm/msm/dpu: get PINGPONG " Dmitry Baryshkov
2021-05-15 22:57 ` [PATCH v2 4/6] drm/msm/dpu: get INTF " Dmitry Baryshkov
2021-05-15 22:57 ` [PATCH v2 5/6] drm/msm/dpu: drop unused lm_max_width from RM Dmitry Baryshkov
2021-05-16  1:21   ` [Freedreno] " Arnaud Vrac
2021-06-02 21:44     ` Dmitry Baryshkov [this message]
2021-05-15 22:57 ` [PATCH v2 6/6] drm/msm/dpu: simplify peer LM handling Dmitry Baryshkov
2021-06-02 21:45 ` Dmitry Baryshkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7b9aa146-3cb3-8164-5f26-388171230100@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=abhinavk@codeaurora.org \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=jonathan@marek.ca \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=rawoul@gmail.com \
    --cc=sboyd@kernel.org \
    --cc=sean@poorly.run \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).