[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