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
