Re: [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks

On Wed, Jan 31, 2024 at 12:26:45PM +0200, Dmitry Baryshkov wrote:

On Wed, 31 Jan 2024 at 11:11, Daniel Vetter [off-list ref] wrote:

quoted

On Wed, Jan 31, 2024 at 05:17:08AM +0000, Jason-JH Lin (林睿祥) wrote:

quoted

On Thu, 2024-01-25 at 19:17 +0100, Daniel Vetter wrote:

quoted

External email : Please do not click links or open attachments until
you have verified the sender or the content.
 On Tue, Jan 23, 2024 at 06:09:05AM +0000, Jason-JH Lin (林睿祥) wrote:

quoted

Hi Maxime, Daniel,

We encountered similar issue with mediatek SoCs.

We have found that in drm_atomic_helper_commit_rpm(), when

disabling

quoted

the cursor plane, the old_state->legacy_cursor_update in
drm_atomic_wait_for_vblank() is set to true.
As the result, we are not actually waiting for a vlbank to wait for

our

quoted

hardware to close the cursor plane. Subsequently, the execution
proceeds to drm_atomic_helper_cleanup_planes() to  free the cursor
buffer. This can lead to use-after-free issues with our hardware.

Could you please apply this patch to fix our problem?
Or are there any considerations for not applying this patch?

Mostly it needs someone to collect a pile of acks/tested-by and then
land
it.

Got it. I would add tested-by tag for mediatek SoC.

quoted

I'd be _very_ happy if someone else can take care of that ...

There's also the potential issue that it might slow down some of the
legacy X11 use-cases that really needed a non-blocking cursor, but I
think
all the drivers where this matters have switched over to the async
plane
update stuff meanwhile. So hopefully that's good.

I think all the drivers should have switched to async plane update.

Can we add the checking condition to see if atomic_async_update/check
function are implemented?

Pretty sure not all have done that, so really it boils down to whether we
break a real user's use-case. Which pretty much can only be checked by
merging the patch (hence the requirement to get as many acks as possible
from display drivers) and then being willing to handle any fallout that's
reported as regressions for a specific driver.

It's a pile of work, at least when it goes south, that's why I'm looking
for volunteers.

I can check this on all sensible msm generations, including mdp4, but
it will be next week, after the FOSDEM.

BTW, for technical reasons one of the msm platforms still has the
legacy cursor implementation might it be related?

Yeah, msm is one of the drivers I had to change with some hacks to avoid
really bad fallout. It should still work like before, but that's one that
definitely needs testing.
-Sima

quoted

Note that handling the fallout doesn't mean you have to fix that specific
driver, the only realistic option might be to reinstate the legacy cursor
behaviour, but as an explicit opt-in that only that specific driver
enables.

So maybe for next round of that patch it might be good to have a 2nd patch
which implements this fallback plan in the shared atomic modeset code?

Cheers, Sima

-- 
With best wishes
Dmitry

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel