Re: [PATCH] drm/i915: Upgrade execbuffer fail after resume failure to EIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 25, 2014 at 10:33 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
>> That, or fix the mess called ring init code ...
>
> So if we fixed resume to avoid reallocating the ringbuffers across
> resume, g45 would still fail to restart, but now we still have valid
> objects (or would we tear them down because of the failure?) and so this
> check passes and we later hit the EIO checks?

Yeah that's my idea: We always set up the objects for all valid rings
and never tear them down. Upon failure we just set wedged and execbuf
would fall through until it notices the wedged states and returns
-EIO. Gives us tidy unified code and no special-casing for the ring
init failures. And if we do the split in ring init correctly the
ring_hw_init could unconditionally set wedged internally if it fails
and our code would dtrt no matter whether it's driver load, resume or
failure to resurrect the hw after reset. So callers wouldn't need to
care. Of course the ring_init functions which allocates the structures
in driver load still needs to be able to bail out in case that fails.
I can dream ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux