On Tue, Aug 06, 2013 at 04:19:00PM +0200, Daniel Vetter wrote:
> Thinking about this some more we already cancel the rps work items
> (with the exception of the vlv_work) in intel_disable_gt_powersave,
> which is called already from i915_save_state. So I think we just need
> to add the cancel_work
On Tue, Aug 6, 2013 at 3:47 PM, Chris Wilson wrote:
> On Tue, Aug 06, 2013 at 03:01:09PM +0200, Daniel Vetter wrote:
>> On Tue, Aug 06, 2013 at 01:24:02PM +0100, Chris Wilson wrote:
>> > Upon resume we will do a complete restoration of the mode and so reset
>> > all tasks, but during suspend (and
On Tue, Aug 06, 2013 at 03:01:09PM +0200, Daniel Vetter wrote:
> On Tue, Aug 06, 2013 at 01:24:02PM +0100, Chris Wilson wrote:
> > Upon resume we will do a complete restoration of the mode and so reset
> > all tasks, but during suspend (and unload) we need to make sure that no
> > workers run concu
On Tue, Aug 06, 2013 at 01:24:02PM +0100, Chris Wilson wrote:
> Upon resume we will do a complete restoration of the mode and so reset
> all tasks, but during suspend (and unload) we need to make sure that no
> workers run concurrently with our suspend code. Or worse just after.
>
> The issue was
At Tue, 6 Aug 2013 13:24:02 +0100,
Chris Wilson wrote:
>
> Upon resume we will do a complete restoration of the mode and so reset
> all tasks, but during suspend (and unload) we need to make sure that no
> workers run concurrently with our suspend code. Or worse just after.
>
> The issue was fir
Upon resume we will do a complete restoration of the mode and so reset
all tasks, but during suspend (and unload) we need to make sure that no
workers run concurrently with our suspend code. Or worse just after.
The issue was first raised whilst tackling a suspend issue with Takashi
Iwai (http://l
