[Intel-gfx] [PATCH v3 3/5] drm/i915: Make cursor plane registers unlocked
Ville Syrjälä
ville.syrjala at linux.intel.com
Thu Feb 24 17:00:01 UTC 2022
On Thu, Feb 24, 2022 at 04:37:03PM +0200, Lisovskiy, Stanislav wrote:
> On Fri, Feb 11, 2022 at 11:26:04AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >
> > Drop the locks around cursor plane register writes. The
> > lock isn't needed since each plane's register are neatly
> > contained on their own cachelines.
> >
> > The locking did have a secondary effect of disabling
> > interrupts around the cursor registers writes though.
> > If we drop that then we open outselves up for sceduling
> > delays and whatnot while on the middle of the register
> > writes. That increases the chance of not all the register
> > writes land during the same frame. For normal atomic
> > commits this is not a concern as the vblank evade mechanism
> > anyway disables interrupts around the update, but the legacy
> > cursor codepath does not. Technically we should do a vblank
> > evade there as well, but so far no one has bothered to hook
> > that up. So in the meantime let's put an explicit local irq
> > disable/enable around the legacy cursor update to keep the
> > race window minimal.
> >
> > v2: local_irq_{disable,enable}() for legacy cursor ioctl
>
> Guess, this will help our infamous atomic update evasion time exceeeded.
> I think I've even checked with similar patch.
> Good that its finally will make its way into kernel.
Yeah. I also sent a new series that split color management
to noarm+arm and drops some more usless locks.
After those I think the TODO list is down to:
- cursor noarm+arm split
- scaler/pfit noarm+arm split
- random locked register accesses during fastsea,
and maybe a few are still left in pure plane commits as well
> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy at intel.com>
Thanks.
--
Ville Syrjälä
Intel
More information about the Intel-gfx
mailing list