[PATCH 1/3] drm/i915: Handle GEN6_PMINTRMSK for proper masking of RPS interrupts with GuC submission

Kamble, Sagar A sagar.a.kamble at intel.com
Tue Jan 17 08:02:30 UTC 2017



On 1/16/2017 4:18 PM, Chris Wilson wrote:
> On Mon, Jan 16, 2017 at 04:08:39PM +0530, Kamble, Sagar A wrote:
>>
>> On 1/16/2017 3:43 PM, Chris Wilson wrote:
>>> WARN_ON(dev_priv->gt.awake);
>> Could you please clarify why this check is needed.
>> During reset, when GuC is getting loaded, GT.awake can be true.
>>> WARN_ON(I915_READ(GEN6_PMINTRMSK) != ~dev_priv->rps.pm_intr_keep);
>> GEN6_PMINTRMSK will have varying bitmasks based on freq request so
>> very likely this WARN will be hit.
> Hmm, this was paranoia to try and assert that we knew when we where
> fiddling with registers, and in particular that no one else was also
> fiddling with them - we don't hold the rps.mutex for example.
>
> I think we need to hold rps.mutex then.
>
>>> I915_WRITE(GEN6_PMINTRMSK, ~GEN8_PMINTR_REDIRECT_TO_GUC); /* clear for guc_interrupts capture() */
>>> ...
>>> I915_WRITE(GEN6_PMINTRMSK, ~dev_priv->rps.pm_intr_keep);
>> Agree with above two writes logic.
> Apart from that we can be here with gt.awake, and so we need the save
> and (restore & mask). More craziness now with reset triggering new hw
> state and trying to replay the existing requests. :|
> -Chris
>
Initializing pm_intr_keep to a needed value with GUC in intel_irq_init 
seems proper solution.
Tying this with GuC load is conflicting with other RPS setup. Will float 
new patch set.



More information about the Intel-gfx-trybot mailing list