[Intel-gfx] drm/i915: Watchdog timeout: IRQ handler for gen8+

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Mon Jan 7 13:12:32 UTC 2019


On 07/01/2019 13:02, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2019-01-07 12:58:39)
>>
>> On 07/01/2019 12:16, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2019-01-07 11:58:13)
>>>> On 05/01/2019 02:39, Carlos Santa wrote:
>>>>> +static void gen8_watchdog_irq_handler(unsigned long data)
>>>>> +{
>>>>> +     struct intel_engine_cs *engine = (struct intel_engine_cs *)data;
>>>>> +     struct drm_i915_private *dev_priv = engine->i915;
>>>>> +     enum forcewake_domains fw_domains;
>>>>> +     u32 current_seqno;
>>>>> +
>>>>> +     switch (engine->id) {
>>>>> +     default:
>>>>> +             MISSING_CASE(engine->id);
>>>>> +             /* fall through */
>>>>> +     case RCS:
>>>>> +             fw_domains = FORCEWAKE_RENDER;
>>>>> +             break;
>>>>> +     case VCS:
>>>>> +     case VCS2:
>>>>> +     case VECS:
>>>>> +             fw_domains = FORCEWAKE_MEDIA;
>>>>> +             break;
>>>>> +     }
>>>>> +
>>>>> +     intel_uncore_forcewake_get(dev_priv, fw_domains);
>>>>
>>>> I'd be tempted to drop this and just use I915_WRITE. It doesn't feel
>>>> like there is any performance to be gained with it and it embeds too
>>>> much knowledge here.
>>>
>>> No, no, no. Let's not reintroduce a fw inside irq context on a frequent
>>> timer again.
>>
>> Tasklet and hopefully watchdog timeouts are not frequent. :)
> 
> I thought the typical value mentioned elsewhere was a 1ms watchdog. Some

Commit message to a patch from this series says 60ms is recommended.

> might say why even use a watchdog for longer than that as a hrtimer will
> be more efficient (coupling in with other timer activity) ;)

For the normal case (longish batches, very few timeouts) it feels more 
efficient to have ten or so extra dwords with each request than to 
fiddle with hrtimers, no?

But interactions with preemption and future time-slicing yeah don't 
know. Maybe a single solution will be simpler at that point.

Regards,

Tvrtko


More information about the Intel-gfx mailing list