[...] >> >> However, as a simple fix, I would try to add a ->prepare() callback >> >> and call pm_runtime_get_sync() from it and then in a new corresponding >> >> ->complete() callback, call pm_runtime_put(). >> >> >> >> This means that the device will stay runtime resumed until the >> >> suspend_noirq phase. It would also means the pm_runtime_force_resume() >> >> will resume the device at resume_noirq phase. Would that work? >> > >> > Yes, this will work, but it will unnecessarily wake all instances of >> > exynos5433 cmu and their power domains during the system suspend/resume >> > cycle, what I would like to avoid. >> >> I guess what you are saying is that it's not at every suspend sequence >> that the client's needs to runtime resume the exynos5433 cmu device - >> and in those cases when not needed, runtime resuming it becomes a >> waste in regards to both time and energy. Right? >> >> Anyway, I fully agree that this isn't very nice, but unfortunate >> that's the best I can think of as a simple solution. > > Resuming in ->prepare() is a bit wasteful, because they are run sequentially, > so the times of all of the resumes add up. It is slightly more efficient to > do it in ->suspend() in general. Good point! > > However, in this particular case, is there any reason why the clients cannot > resume their providers in ->suspend()? They also might drop references to > them on the way out, in ->resume() to balance the usage counters. I think the problem is that the clients don't know their providers. If they did, I rather think using device links should be the preferred solution. To make a client aware of its providers, for the general case, we would need to invent some DT bindings to describe the dependencies. Kind regards Uffe
