[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Work around compiler warnings on some kernel configs

Arnd Bergmann arnd at arndb.de
Wed Mar 14 20:08:49 UTC 2018


On Wed, Mar 14, 2018 at 6:57 PM, Tvrtko Ursulin
<tvrtko.ursulin at linux.intel.com> wrote:
> On 14/03/2018 08:31, Patchwork wrote:

>
> Pushed it, thanks for the review!
>
> (And I forgot to copy Arnd on the patch..)
>
> So Arnd, sorry, I forgot Reported-by does not add Cc from git send-email.
> https://patchwork.freedesktop.org/series/39939/ is my version of the fix for
> this. (Now merged.) Hopefully it works for your randconfigs as well and
> thanks for sending a patch in the first place!

The patch looks good to me, thanks for the follow-up

Acked-by: Arnd Bergmann <arnd at arndb.de>

I didn't test it, but you'll hear from me if it breaks again.

One comment about the use of spin_lock_irqsave(), you wrote:

"Slight penalty we now pay is an additional irqsave spin lock/unlock cycle
on the event enable path. But since enable is not a fast path, that is
preferrable to the alternative solution which was doing MMIO under irqsave
spinlock."

While I don't know about the exact cost on x86, on many architectures
spin_lock_irqsave()/spin_unlock_irqrestore() is much more expensive
than a plain spin_lock()/spin_unlock() or spin_lock_irq()/spin_unlock_irq()
pair that doesn't have to store the disabled-state.

I see you already removed the inner irqsave()/irqrestore() pair that
is now useless (I failed to notice that in my original patch), but in my
experience, it's usually possible to do the same for many others
as well after proving that a function is always called with IRQs enabled
or always disabled.

     Arnd


More information about the Intel-gfx mailing list