All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>
Cc: 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 v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
Date: Sat, 4 Feb 2023 23:08:10 +0200	[thread overview]
Message-ID: <5d482d65-858f-7c6c-1f93-dabc6e2f4be9@linaro.org> (raw)
In-Reply-To: <edc1aab6-b38f-c0ec-9339-01117d037ebf@quicinc.com>

On 04/02/2023 20:35, Abhinav Kumar wrote:
> 
> 
> On 2/4/2023 2:43 AM, Dmitry Baryshkov wrote:
>> On 04/02/2023 07:10, Abhinav Kumar wrote:
>>>
>>>
>>> On 2/3/2023 8:10 PM, Dmitry Baryshkov wrote:
>>>> On 04/02/2023 04:43, Abhinav Kumar wrote:
>>>>>
>>>>>
>>>>> On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
>>>>>> On 04/02/2023 01:35, Abhinav Kumar wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
>>>>>>>> Downstream driver uses dpu->caps->smart_dma_rev to update
>>>>>>>> sspp->cap->features with the bit corresponding to the supported 
>>>>>>>> SmartDMA
>>>>>>>> version. Upstream driver does not do this, resulting in SSPP 
>>>>>>>> subdriver
>>>>>>>> not enbaling setup_multirect callback. Add corresponding 
>>>>>>>> SmartDMA SSPP
>>>>>>>> feature bits to dpu hw catalog.
>>>>>>>>
>>>>>>>
>>>>>>> While reviewing this patch, I had a first hand experience of how 
>>>>>>> we are reusing SSPP bitmasks for so many chipsets but I think 
>>>>>>> overall you got them right here :)
>>>>>>>
>>>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>>>>> ---
>>>>>>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++++++---
>>>>>>>>   1 file changed, 7 insertions(+), 3 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
>>>>>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>>>> index cf053e8f081e..fc818b0273e7 100644
>>>>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>>>> @@ -21,13 +21,16 @@
>>>>>>>>       (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3))
>>>>>>>>   #define VIG_SDM845_MASK \
>>>>>>>> -    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3))
>>>>>>>> +    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2))
>>>>>>>>   #define VIG_SC7180_MASK \
>>>>>>>> -    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED4))
>>>>>>>> +    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED4) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2))
>>>>>>>>   #define VIG_SM8250_MASK \
>>>>>>>> -    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3LITE))
>>>>>>>> +    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3LITE) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2))
>>>>>>>>   #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL))
>>>>>>>> @@ -42,6 +45,7 @@
>>>>>>>>   #define DMA_SDM845_MASK \
>>>>>>>>       (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | 
>>>>>>>> BIT(DPU_SSPP_QOS_8LVL) |\
>>>>>>>>       BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2) |\
>>>>>>>>       BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>>>>>>>>   #define DMA_CURSOR_SDM845_MASK \
>>>>>>>
>>>>>>> VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other 
>>>>>>> chipsets like 8250, 8450, 8550.
>>>>>>>
>>>>>>> At the moment, for visual validation of this series, I only have 
>>>>>>> sc7180/sc7280. We are leaving the rest for CI.
>>>>>>>
>>>>>>> Was that an intentional approach?
>>>>>>>
>>>>>>> If so, we will need tested-by tags from folks having 
>>>>>>> 8350/8450/8550/sc8280x,qcm2290?
>>>>>>>
>>>>>>> I am only owning the visual validation on sc7280 atm.
>>>>>>
>>>>>> I'm not quite sure what is your intent here. Are there any SoCs 
>>>>>> after 845 that do not have SmartDMA 2.5? Or do you propose to 
>>>>>> enable SmartDMA only for the chipsets that we can visually test? 
>>>>>> That sounds strange.
>>>>>>
>>>>>
>>>>> Yes I was thinking to enable smartDMA at the moment on chipsets 
>>>>> which we can validate visually that display comes up. But I am not 
>>>>> sure if thats entirely practical.
>>>>>
>>>>> But the intent was I just want to make sure basic display does come 
>>>>> up with smartDMA enabled if we are enabling it for all chipsets.
>>>>
>>>> I don't think it is practical or logical. We don't require 
>>>> validating other changes on all possible chipsets, so what is so 
>>>> different with this one?
>>>>
>>>
>>> Thats because with smartDMA if the programming of stages goes wrong 
>>> we could potentially just see a blank screen. Its not about other 
>>> changes, this change in particular controls enabling a feature.
>>>
>>> But thats just my thought. I am not going to request to ensure this 
>>> or block this for this.
>>>
>>> You can still have my
>>>
>>> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
>>>
>>> But think of the validations that have to be done before we merge it.
>>
>> The usual way: verify as much as feasible and let anybody else 
>> complain during the development cycle.
>>
> 
> Well, our perspective is to enable the feature on devices on which you 
> are able to test and not enable then wait for others to complain.

This would not be really practical. There are plenty of people who can 
test things on obscure platforms, but unfortunately far less amount of 
people who tightly follow the development and can track which new 
feature applies to a particular platform. I hope to be able to fix that 
slightly with the hw catalog rework. However enabling features on other 
platforms definitely requires more knowledge than simply testing the kernel.

> 
> I did not say test all devices. My point was to enable smartDMA on 
> devices which we are able to test.
> 
> There are other examples of this, like inline rotation, writeback etc. 
> which are at the moment enabled only on devices which QC or others have 
> tested on.

But at the time it was added, inline rotation 2.0 could only be 
supported on sc7280. Probably we should expand it not to sc8280xp and 
sm8[345]50.

For WB I don't remember which platforms were supported at the moment it 
was added. But it's also worth expanding support to new platforms.

And, as we speak about testing, is there an easy way to setup the plane 
with UBWC format modifier? Also, did the WB support patches land into 
libdrm?

> So when i said my suggestion was not practical, yes because if you want 
> to go ahead with this change in the current form, you would have to 
> validate all the chipsets as you are enabling smartDMA on all of them.
> 
> If you enable smartDMA only on the chipsets you OR others can validate 
> and give Tested-by for like I was planning to do for sc7280, then I am 
> not sure why it doesnt sound logical.
> 
> But like I said, thats my perspective. I will let you decide as you 
> would know how confident you are with this getting enabled for all 
> chipsets upstream.

I'd say, that once tested on some of the platforms and granted that even 
smalled (qcm2290, sm6115) platforms support smartdma, it will be safe to 
enable smart DMA globablly for every SoC >= sdm845. If I remember 
correctly, msm8998 (and sdm660/630) support smartdma/rect only on DMA 
planes. Is it correct?


-- 
With best wishes
Dmitry


WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>,
	Rob Clark <robdclark@gmail.com>, Sean Paul <sean@poorly.run>
Cc: freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <andersson@kernel.org>,
	dri-devel@lists.freedesktop.org,
	Stephen Boyd <swboyd@chromium.org>
Subject: Re: [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog
Date: Sat, 4 Feb 2023 23:08:10 +0200	[thread overview]
Message-ID: <5d482d65-858f-7c6c-1f93-dabc6e2f4be9@linaro.org> (raw)
In-Reply-To: <edc1aab6-b38f-c0ec-9339-01117d037ebf@quicinc.com>

On 04/02/2023 20:35, Abhinav Kumar wrote:
> 
> 
> On 2/4/2023 2:43 AM, Dmitry Baryshkov wrote:
>> On 04/02/2023 07:10, Abhinav Kumar wrote:
>>>
>>>
>>> On 2/3/2023 8:10 PM, Dmitry Baryshkov wrote:
>>>> On 04/02/2023 04:43, Abhinav Kumar wrote:
>>>>>
>>>>>
>>>>> On 2/3/2023 6:29 PM, Dmitry Baryshkov wrote:
>>>>>> On 04/02/2023 01:35, Abhinav Kumar wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
>>>>>>>> Downstream driver uses dpu->caps->smart_dma_rev to update
>>>>>>>> sspp->cap->features with the bit corresponding to the supported 
>>>>>>>> SmartDMA
>>>>>>>> version. Upstream driver does not do this, resulting in SSPP 
>>>>>>>> subdriver
>>>>>>>> not enbaling setup_multirect callback. Add corresponding 
>>>>>>>> SmartDMA SSPP
>>>>>>>> feature bits to dpu hw catalog.
>>>>>>>>
>>>>>>>
>>>>>>> While reviewing this patch, I had a first hand experience of how 
>>>>>>> we are reusing SSPP bitmasks for so many chipsets but I think 
>>>>>>> overall you got them right here :)
>>>>>>>
>>>>>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>>>>>> ---
>>>>>>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 10 +++++++---
>>>>>>>>   1 file changed, 7 insertions(+), 3 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
>>>>>>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>>>> index cf053e8f081e..fc818b0273e7 100644
>>>>>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>>>>>>> @@ -21,13 +21,16 @@
>>>>>>>>       (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3))
>>>>>>>>   #define VIG_SDM845_MASK \
>>>>>>>> -    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3))
>>>>>>>> +    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2))
>>>>>>>>   #define VIG_SC7180_MASK \
>>>>>>>> -    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED4))
>>>>>>>> +    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED4) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2))
>>>>>>>>   #define VIG_SM8250_MASK \
>>>>>>>> -    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3LITE))
>>>>>>>> +    (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | 
>>>>>>>> BIT(DPU_SSPP_SCALER_QSEED3LITE) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2))
>>>>>>>>   #define VIG_QCM2290_MASK (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL))
>>>>>>>> @@ -42,6 +45,7 @@
>>>>>>>>   #define DMA_SDM845_MASK \
>>>>>>>>       (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | 
>>>>>>>> BIT(DPU_SSPP_QOS_8LVL) |\
>>>>>>>>       BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
>>>>>>>> +    BIT(DPU_SSPP_SMART_DMA_V2) |\
>>>>>>>>       BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>>>>>>>>   #define DMA_CURSOR_SDM845_MASK \
>>>>>>>
>>>>>>> VIG_SDM845_MASK and DMA_SDM845_MASK are used for many other 
>>>>>>> chipsets like 8250, 8450, 8550.
>>>>>>>
>>>>>>> At the moment, for visual validation of this series, I only have 
>>>>>>> sc7180/sc7280. We are leaving the rest for CI.
>>>>>>>
>>>>>>> Was that an intentional approach?
>>>>>>>
>>>>>>> If so, we will need tested-by tags from folks having 
>>>>>>> 8350/8450/8550/sc8280x,qcm2290?
>>>>>>>
>>>>>>> I am only owning the visual validation on sc7280 atm.
>>>>>>
>>>>>> I'm not quite sure what is your intent here. Are there any SoCs 
>>>>>> after 845 that do not have SmartDMA 2.5? Or do you propose to 
>>>>>> enable SmartDMA only for the chipsets that we can visually test? 
>>>>>> That sounds strange.
>>>>>>
>>>>>
>>>>> Yes I was thinking to enable smartDMA at the moment on chipsets 
>>>>> which we can validate visually that display comes up. But I am not 
>>>>> sure if thats entirely practical.
>>>>>
>>>>> But the intent was I just want to make sure basic display does come 
>>>>> up with smartDMA enabled if we are enabling it for all chipsets.
>>>>
>>>> I don't think it is practical or logical. We don't require 
>>>> validating other changes on all possible chipsets, so what is so 
>>>> different with this one?
>>>>
>>>
>>> Thats because with smartDMA if the programming of stages goes wrong 
>>> we could potentially just see a blank screen. Its not about other 
>>> changes, this change in particular controls enabling a feature.
>>>
>>> But thats just my thought. I am not going to request to ensure this 
>>> or block this for this.
>>>
>>> You can still have my
>>>
>>> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
>>>
>>> But think of the validations that have to be done before we merge it.
>>
>> The usual way: verify as much as feasible and let anybody else 
>> complain during the development cycle.
>>
> 
> Well, our perspective is to enable the feature on devices on which you 
> are able to test and not enable then wait for others to complain.

This would not be really practical. There are plenty of people who can 
test things on obscure platforms, but unfortunately far less amount of 
people who tightly follow the development and can track which new 
feature applies to a particular platform. I hope to be able to fix that 
slightly with the hw catalog rework. However enabling features on other 
platforms definitely requires more knowledge than simply testing the kernel.

> 
> I did not say test all devices. My point was to enable smartDMA on 
> devices which we are able to test.
> 
> There are other examples of this, like inline rotation, writeback etc. 
> which are at the moment enabled only on devices which QC or others have 
> tested on.

But at the time it was added, inline rotation 2.0 could only be 
supported on sc7280. Probably we should expand it not to sc8280xp and 
sm8[345]50.

For WB I don't remember which platforms were supported at the moment it 
was added. But it's also worth expanding support to new platforms.

And, as we speak about testing, is there an easy way to setup the plane 
with UBWC format modifier? Also, did the WB support patches land into 
libdrm?

> So when i said my suggestion was not practical, yes because if you want 
> to go ahead with this change in the current form, you would have to 
> validate all the chipsets as you are enabling smartDMA on all of them.
> 
> If you enable smartDMA only on the chipsets you OR others can validate 
> and give Tested-by for like I was planning to do for sc7280, then I am 
> not sure why it doesnt sound logical.
> 
> But like I said, thats my perspective. I will let you decide as you 
> would know how confident you are with this getting enabled for all 
> chipsets upstream.

I'd say, that once tested on some of the platforms and granted that even 
smalled (qcm2290, sm6115) platforms support smartdma, it will be safe to 
enable smart DMA globablly for every SoC >= sdm845. If I remember 
correctly, msm8998 (and sdm660/630) support smartdma/rect only on DMA 
planes. Is it correct?


-- 
With best wishes
Dmitry


  reply	other threads:[~2023-02-04 21:08 UTC|newest]

Thread overview: 176+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-03 18:21 [PATCH v3 00/27] drm/msm/dpu: wide planes support Dmitry Baryshkov
2023-02-03 18:21 ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 01/27] drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg) Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 19:31   ` Abhinav Kumar
2023-02-03 19:31     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 02/27] drm/msm/dpu: move SSPP allocation to the RM Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 03/27] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 04/27] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 05/27] drm/msm/dpu: move pipe_hw to dpu_plane_state Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 19:34   ` Abhinav Kumar
2023-02-03 19:34     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 06/27] drm/msm/dpu: drop dpu_plane_pipe function Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 07/27] drm/msm/dpu: introduce struct dpu_sw_pipe Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 08/27] drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 09/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3() Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 19:36   ` Abhinav Kumar
2023-02-03 19:36     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 10/27] drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 20:36   ` Abhinav Kumar
2023-02-03 20:36     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 11/27] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 20:37   ` Abhinav Kumar
2023-02-03 20:37     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 12/27] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_sspp_cfg Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 13/27] drm/msm/dpu: drop src_split and multirect check from dpu_crtc_atomic_check Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 14/27] drm/msm/dpu: don't use unsupported blend stages Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 20:42   ` Abhinav Kumar
2023-02-03 20:42     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 15/27] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check() Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 22:44   ` Abhinav Kumar
2023-02-03 22:44     ` Abhinav Kumar
2023-02-03 22:55     ` Dmitry Baryshkov
2023-02-03 22:55       ` Dmitry Baryshkov
2023-02-14 23:25       ` Abhinav Kumar
2023-02-14 23:25         ` Abhinav Kumar
2023-02-15  0:08         ` Dmitry Baryshkov
2023-02-15  0:08           ` Dmitry Baryshkov
2023-03-03 11:43           ` Dmitry Baryshkov
2023-03-03 11:43             ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 16/27] drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check() Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 22:57   ` Abhinav Kumar
2023-02-03 22:57     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 17/27] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe and dpu_format Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 23:07   ` Abhinav Kumar
2023-02-03 23:07     ` Abhinav Kumar
2023-02-03 23:20     ` Dmitry Baryshkov
2023-02-03 23:20       ` Dmitry Baryshkov
2023-02-08 23:09       ` Abhinav Kumar
2023-02-08 23:09         ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 18/27] drm/msm/dpu: populate SmartDMA features in hw catalog Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-03 23:35   ` Abhinav Kumar
2023-02-03 23:35     ` Abhinav Kumar
2023-02-04  2:29     ` Dmitry Baryshkov
2023-02-04  2:29       ` Dmitry Baryshkov
2023-02-04  2:43       ` Abhinav Kumar
2023-02-04  2:43         ` Abhinav Kumar
2023-02-04  4:10         ` Dmitry Baryshkov
2023-02-04  4:10           ` Dmitry Baryshkov
2023-02-04  5:10           ` Abhinav Kumar
2023-02-04  5:10             ` Abhinav Kumar
2023-02-04 10:43             ` Dmitry Baryshkov
2023-02-04 10:43               ` Dmitry Baryshkov
2023-02-04 18:35               ` Abhinav Kumar
2023-02-04 18:35                 ` Abhinav Kumar
2023-02-04 21:08                 ` Dmitry Baryshkov [this message]
2023-02-04 21:08                   ` Dmitry Baryshkov
2023-02-04 23:20                   ` Abhinav Kumar
2023-02-04 23:20                     ` Abhinav Kumar
2023-02-05  0:29                     ` Dmitry Baryshkov
2023-02-05  0:29                       ` Dmitry Baryshkov
2023-02-05  0:36                       ` Abhinav Kumar
2023-02-05  0:36                         ` Abhinav Kumar
2023-02-08 23:53                         ` Dmitry Baryshkov
2023-02-08 23:53                           ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 19/27] drm/msm/dpu: make _dpu_plane_calc_clk accept mode directly Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-06 18:48   ` Abhinav Kumar
2023-02-06 18:48     ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 20/27] drm/msm/dpu: add dpu_hw_pipe_cfg to dpu_plane_state Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-06 19:07   ` Abhinav Kumar
2023-02-06 19:07     ` Abhinav Kumar
2023-02-16 16:49     ` Dmitry Baryshkov
2023-02-16 16:49       ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 21/27] drm/msm/dpu: simplify dpu_plane_validate_src() Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-06 22:40   ` Abhinav Kumar
2023-02-06 22:40     ` Abhinav Kumar
2023-02-07  0:27     ` Dmitry Baryshkov
2023-02-07  0:27       ` Dmitry Baryshkov
2023-02-07  0:42       ` Abhinav Kumar
2023-02-07  0:42         ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 22/27] drm/msm/dpu: rework dpu_plane_sspp_atomic_update() Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-07  0:22   ` Abhinav Kumar
2023-02-07  0:22     ` Abhinav Kumar
2023-02-09  0:49     ` Dmitry Baryshkov
2023-02-09  0:49       ` Dmitry Baryshkov
2023-02-09  0:51     ` Dmitry Baryshkov
2023-02-09  0:51       ` Dmitry Baryshkov
2023-02-09 11:46     ` Dmitry Baryshkov
2023-02-09 11:46       ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 23/27] drm/msm/dpu: rework dpu_plane_atomic_check() Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-07 17:49   ` Abhinav Kumar
2023-02-07 17:49     ` Abhinav Kumar
2023-02-07 17:51     ` Dmitry Baryshkov
2023-02-07 17:51       ` Dmitry Baryshkov
2023-02-07 17:57       ` Abhinav Kumar
2023-02-07 17:57         ` Abhinav Kumar
2023-02-07 17:59         ` Dmitry Baryshkov
2023-02-07 17:59           ` Dmitry Baryshkov
2023-02-07 18:08           ` Abhinav Kumar
2023-02-07 18:08             ` Abhinav Kumar
2023-02-07 19:51             ` Dmitry Baryshkov
2023-02-07 19:51               ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 24/27] drm/msm/dpu: rework plane CSC setting Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-07 20:05   ` Abhinav Kumar
2023-02-07 20:05     ` Abhinav Kumar
2023-02-07 20:44     ` Dmitry Baryshkov
2023-02-07 20:44       ` Dmitry Baryshkov
2023-02-07 20:57       ` Abhinav Kumar
2023-02-07 20:57         ` Abhinav Kumar
2023-02-03 18:21 ` [PATCH v3 25/27] drm/msm/dpu: rework static color fill code Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-08 22:34   ` Abhinav Kumar
2023-02-08 22:34     ` Abhinav Kumar
2023-02-09  0:53     ` Dmitry Baryshkov
2023-02-09  0:53       ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 26/27] drm/msm/dpu: split pipe handling from _dpu_crtc_blend_setup_mixer Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-08 23:44   ` Abhinav Kumar
2023-02-08 23:44     ` Abhinav Kumar
2023-02-08 23:47     ` Dmitry Baryshkov
2023-02-08 23:47       ` Dmitry Baryshkov
2023-03-03 12:18     ` Dmitry Baryshkov
2023-03-03 12:18       ` Dmitry Baryshkov
2023-02-03 18:21 ` [PATCH v3 27/27] drm/msm/dpu: add support for wide planes Dmitry Baryshkov
2023-02-03 18:21   ` Dmitry Baryshkov
2023-02-09  2:19   ` Abhinav Kumar
2023-02-09  2:19     ` Abhinav Kumar
2023-02-09 11:45     ` Dmitry Baryshkov
2023-02-09 11:45       ` Dmitry Baryshkov
2023-02-09 19:25       ` Abhinav Kumar
2023-02-09 19:25         ` Abhinav Kumar
2023-02-09 21:23         ` Dmitry Baryshkov
2023-02-09 21:23           ` Dmitry Baryshkov
2023-02-09 22:12           ` [Freedreno] " Abhinav Kumar
2023-02-09 22:12             ` Abhinav Kumar
2023-02-10  0:09             ` Dmitry Baryshkov
2023-02-10  0:09               ` Dmitry Baryshkov
2023-02-10  1:12               ` Abhinav Kumar
2023-02-10  1:12                 ` Abhinav Kumar
2023-02-10  2:46                 ` Dmitry Baryshkov
2023-02-10  2:46                   ` Dmitry Baryshkov
2023-02-03 18:24 ` [PATCH v3 00/27] drm/msm/dpu: wide planes support Dmitry Baryshkov
2023-02-03 18:24   ` 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=5d482d65-858f-7c6c-1f93-dabc6e2f4be9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.