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@xxxxxxxxxxx>
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@xxxxxxxxxx>
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
