From: Rob Clark
dpu_crtc_atomic_flush() was directly poking it's attached planes in a
code path that ended up in dpu_plane_atomic_update(), even if the plane
was not involved in the current atomic update. While a bit dubious,
this worked before because plane->state would always point to somethin
Hi,
On Fri, Apr 30, 2021 at 10:44:53AM -0700, Stephen Boyd wrote:
> Quoting Rob Clark (2021-04-30 10:17:39)
> > From: Rob Clark
> >
> > dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> > code path that ended up in dpu_plane_atomic_update(), even if the plane
> > was not inv
Quoting Rob Clark (2021-04-30 10:17:39)
> From: Rob Clark
>
> dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> code path that ended up in dpu_plane_atomic_update(), even if the plane
> was not involved in the current atomic update. While a bit dubious,
> this worked before
On Fri, Apr 30, 2021 at 10:14 AM Rob Clark wrote:
>
> From: Rob Clark
>
> dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> code path that ended up in dpu_plane_atomic_update(), even if the plane
> was not involved in the current atomic update. While a bit dubious,
> this w
From: Rob Clark
dpu_crtc_atomic_flush() was directly poking it's attached planes in a
code path that ended up in dpu_plane_atomic_update(), even if the plane
was not involved in the current atomic update. While a bit dubious,
this worked before because plane->state would always point to somethin
