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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux