[PATCH v2 11/27] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress

[Dmitry Baryshkov]

On 02/02/2023 21:15, Abhinav Kumar wrote:
> 
> 
> On 2/2/2023 10:55 AM, Dmitry Baryshkov wrote:
>> Hi Abhinav,
>>
>> On Thu, 2 Feb 2023 at 20:41, Abhinav Kumar <quic_abhinavk at quicinc.com> 
>> wrote:
>>>
>>>
>>>
>>> On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
>>>> Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
>>>> dpu_hw_sspp_setup_rects() programs only source and destination
>>>> rectangles.
>>>>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov at linaro.org>
>>>
>>> Sorry but once again, I dont see a response to my comment
>>>
>>> https://patchwork.freedesktop.org/patch/473166/?series=99909&rev=1#comment_875313
>>>
>>> So let me repeat that here:
>>>
>>> "This separation is logically correct, but there is another codepath
>>> using this.
>>>
>>> _dpu_plane_color_fill() calls pdpu->pipe_hw->ops.setup_rects.
>>>
>>> So for solid fill, I presume that stride getting programmed is 0 as
>>> there is no buffer to fetch from.
>>
>> Could you please verify with the HW team what should be the correct
>> stride programming for the solid fill? I'll have to check what is
>> being programmed ATM.
>>
> 
> Sure, I can check but in the _dpu_plane_color_fill() method the 
> pipe_cfg->layout is not filled up so it should be a 0 stride.

Actually I think we should call setup_sourceaddress for the color-filled 
planes too. Otherwise the SSPP's adddress registers can point to the 
memory regions which are no longer mapped/available.

-- 
With best wishes
Dmitry