On to, 2016-08-18 at 19:17 +0530, Goel, Akash wrote: > [...] > Thanks for the inputs. Sorry not familiar with freezable WQ semantics. > But after looking at code, this is what I understood :- > 1. freezable Workqueues will be frozen before the system suspend > callbacks are invoked for the devices. Yes. > 2. Any work item queued after the WQ is marked frozen will be scheduled > later, on resume. Yes. > 3. But if a work item was already present in the freezable Workqueue, > before it was frozen and it did not complete, then system suspend > itself will be aborted. System suspend will be aborted only if any kernel thread didn't complete within a reasonable amount of time (freeze_timeout_msecs, 20 sec by default). Otherwise already queued items will be properly waited upon and suspend will proceed. > 4. So if the log.flush_wq is marked as freezable, then flush of > work item will not be required for the system suspend case. > And runtime suspend case is already covered with rpm get/put > around register access in work item function. Yes. > > It seems there are 2 config options CONFIG_SUSPEND_FREEZER This is set whenever system suspend is enabled. > and > CONFIG_FREEZER This is set except for one platform (powerpc), where I assume freezing of the tasks is achieved in a different way. In any case it doesn't matter for us. --Imre > which have to be enabled for all the above to happen. > If these config options will always be enabled then probably marking > log.flush_wq would work. > > Please kindly confirm whether I understood correctly or not, accordingly > will proceed further. > > Best regards > Akash > > > > > --Imre > > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
