linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>,
	Stephen Boyd <swboyd@chromium.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Bjorn Andersson <andersson@kernel.org>,
	linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
	freedreno@lists.freedesktop.org
Subject: Re: [PATCH v2 12/27] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_pipe_cfg
Date: Fri, 3 Feb 2023 16:09:50 +0200	[thread overview]
Message-ID: <fbdab5e4-4f48-f18f-561d-442d493724e5@linaro.org> (raw)
In-Reply-To: <a4af7146-126f-cd6e-4c65-dbdffe6cca82@quicinc.com>

On 02/02/2023 22:14, Abhinav Kumar wrote:
> 
> 
> On 2/2/2023 12:10 PM, Dmitry Baryshkov wrote:
>> On 02/02/2023 21:54, Abhinav Kumar wrote:
>>>
>>>
>>> On 2/2/2023 11:45 AM, Dmitry Baryshkov wrote:
>>>> On Thu, 2 Feb 2023 at 21:38, Abhinav Kumar 
>>>> <quic_abhinavk@quicinc.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
>>>>>> Remove dpu_hw_fmt_layout instance from struct dpu_hw_pipe_cfg, 
>>>>>> leaving
>>>>>> only src_rect and dst_rect. This way right and left pipes will have
>>>>>> separate dpu_hw_pipe_cfg isntances, while the layout is common to 
>>>>>> both
>>>>>> of them.
>>>>>>
>>>>>
>>>>> Sorry for not responding to this comment earlier.
>>>>>
>>>>> https://patchwork.freedesktop.org/patch/473168/?series=99909&rev=1#comment_875370
>>>>>
>>>>>   From the perspective of wide planes you are right that the layout is
>>>>> common but not true from smart DMA point of view.
>>>>>
>>>>> For wide planes, yes, its usually the same buffer with just the src_x
>>>>> being different but conceptually and even HW wise each rectangle of 
>>>>> the
>>>>> smart DMA is capable of fetching from a different buffer.
>>>>>
>>>>>   From the pov, this decision of not having the dpu_hw_fmt_layout 
>>>>> as part
>>>>> of dpu_hw_pipe_cfg seems incorrect to me.
>>>>
>>>> Yes, each rectangle/pipe can fetch from a different buffer. However in
>>>> our use case the layout is not defined for each pipe. It is defined
>>>> for a plane, no matter how many pipes are used for the plane, since
>>>> the buffer is also defined per plane.
>>>>
>>> Even if the layout is defined per plane.
>>>
>>> So lets say
>>>
>>> plane A with layout A maps to rect 1 of DMA0
>>> plane B with layout B maps to rect 2 of DMA0
>>>
>>> How can layout be assumed to be duplicated in this case?
>>>
>>> This is not a wide plane use-case but just smartDMA case of two 
>>> different layers.
>>>
>>> Maybe I am missing something but this is the example i am interested 
>>> about.
>>
>> PlaneA has layoutA. So dpu_plane_sspp_update_pipe() will program 
>> layoutA using (DMA0, rect1)->setup_sourceaddress(layoutA).
>>
>> PlaneB has layoutB, so (DMA0, rect2)->setup_sourceaddress(layoutB).
>>
>> Maybe the commit message is misleading. The layout is not common to 
>> rect1 and rect2. It is common to all pipes/rectangles driving a single 
>> plane.
>>
> 
> Ack, Its clear now.
> 
> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>

I have rephrased the last sentence of the commit message in the 
following way. Hopefully it will be cleaner now:

This way all the pipes used by the plane
will have a common layout instance (as the framebuffer is shared between
them), while still keeping a separate src/dst rectangle configuration
for each pipe.

-- 
With best wishes
Dmitry


  reply	other threads:[~2023-02-03 14:12 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-29 19:18 [PATCH v2 00/27] drm/msm/dpu: wide planes support Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 01/27] drm/msm/dpu: set pdpu->is_rt_pipe early in dpu_plane_sspp_atomic_update() Dmitry Baryshkov
2023-01-26 19:26   ` Abhinav Kumar
2022-12-29 19:18 ` [PATCH v2 02/27] drm/msm/dpu: rename struct dpu_hw_pipe to dpu_hw_sspp Dmitry Baryshkov
2023-01-26 22:55   ` Abhinav Kumar
2023-01-31 11:19     ` Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 03/27] drm/msm/dpu: move SSPP allocation to the RM Dmitry Baryshkov
2023-01-26 23:29   ` Abhinav Kumar
2023-01-27  5:56     ` Dmitry Baryshkov
2023-01-27 22:59       ` Abhinav Kumar
2022-12-29 19:18 ` [PATCH v2 04/27] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 05/27] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout Dmitry Baryshkov
2023-01-27  0:52   ` Abhinav Kumar
2023-01-27  6:05     ` Dmitry Baryshkov
2023-01-27 23:59       ` Abhinav Kumar
2023-02-03 14:16         ` Dmitry Baryshkov
2023-02-03 17:32           ` Abhinav Kumar
2022-12-29 19:18 ` [PATCH v2 06/27] drm/msm/dpu: move pipe_hw to dpu_plane_state Dmitry Baryshkov
2023-01-30 21:51   ` Abhinav Kumar
2023-01-31 11:51     ` Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 07/27] drm/msm/dpu: drop dpu_plane_pipe function Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 08/27] drm/msm/dpu: introduce struct dpu_sw_pipe Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 09/27] drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 10/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3() Dmitry Baryshkov
2023-01-31  5:13   ` Abhinav Kumar
2023-01-31 12:10     ` Dmitry Baryshkov
2023-01-31 12:15       ` Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 11/27] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress Dmitry Baryshkov
2023-02-02 18:41   ` Abhinav Kumar
2023-02-02 18:55     ` Dmitry Baryshkov
2023-02-02 19:15       ` Abhinav Kumar
2023-02-03 14:12         ` Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 12/27] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_pipe_cfg Dmitry Baryshkov
2023-02-02 19:38   ` Abhinav Kumar
2023-02-02 19:45     ` Dmitry Baryshkov
2023-02-02 19:54       ` Abhinav Kumar
2023-02-02 20:10         ` Dmitry Baryshkov
2023-02-02 20:14           ` Abhinav Kumar
2023-02-03 14:09             ` Dmitry Baryshkov [this message]
2023-02-03 17:47               ` Abhinav Kumar
2022-12-29 19:18 ` [PATCH v2 13/27] drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 14/27] drm/msm/dpu: don't use unsupported blend stages Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check() Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 16/27] drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check() Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 17/27] drm/msm/dpu: add dpu_hw_pipe_cfg to dpu_plane_state Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 18/27] drm/msm/dpu: simplify dpu_plane_validate_src() Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 19/27] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 20/27] drm/msm/dpu: populate SmartDMA features in hw catalog Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 21/27] drm/msm/dpu: make _dpu_plane_calc_clk accept mode directly Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 22/27] drm/msm/dpu: rework dpu_plane_sspp_atomic_update() Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 23/27] drm/msm/dpu: rework dpu_plane_atomic_check() Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 24/27] drm/msm/dpu: rework plane CSC setting Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 25/27] drm/msm/dpu: rework static color fill code Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 26/27] drm/msm/dpu: split pipe handling from _dpu_crtc_blend_setup_mixer Dmitry Baryshkov
2022-12-29 19:18 ` [PATCH v2 27/27] drm/msm/dpu: add support for wide planes 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=fbdab5e4-4f48-f18f-561d-442d493724e5@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=airlied@gmail.com \
    --cc=andersson@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.org \
    /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).