[...] > 2) There are no requirements for arch/platforms/drivers to work in both cases > CONFIG_PM_RUNTIME=y/n. But they must be built without errors/warning for both > cases. For cross SoC drivers this statement is not correct! Driver _must_ support the various combinations of CONFIG_PM*. Therefore, I think it's better to strive towards a common solution and to get the building blocks in place. > > For example, for Keystone 2 only CONFIG_PM_RUNTIME=y is going to be supported > and if some one decided to disable it - it can be perfectly done from sys_fs/ > user space. I can't see why the sysfs option to disable runtime PM should affect this discussion. That's done at runtime and after the device has been probed. > > 3) pm_runtime_get_sync()(or similar) is good not only because i's waking up device, but also > because: > - it can wake up chain of devices (dev->parent->parent->...) That's right. But that's not what this patchset aims to do. I realize that the header of the cover letter isn't describing the problem I am trying to solve very well. I guess the below header would have been better: "PM / Domains: Power up PM domains prior drivers starts to probe their devices" > - it can wake up power domain Yes, but it requires CONFIG_PM_RUNTIME to be set. Thus, to solve the problem during driver ->probe() we need another solution which don't require CONFIG_PM_RUNTIME to be set. As this patchset proposes. > - it connects device to domain/class/type/bus and so allow to add additional PM layer on top > of Platform bus (for example arch/arm/mach-omap2/omap_device.c). > > So, it will do all needed things, and if it doesn't that problem is in platfrom/bus/driver > code and not in Runtime PM. > if pm_runtime_get_sync() will be dropped - than all above will need to be implemented > around the ->probe(). I am not sure what you mean about dropping pm_runtime_get_sync()? All I am saying is that we can't use it to power on PM domains during the probe sequence. Of course, you may still use pm_runtime_get_sync() from anywhere it's needed, to for example handle device's parent/child relationships. > > 4) I've copied here comment from Rafael: > >>>> Of course, if ->probe() is to call pm_runtime_resume() for this purpose, > >>>> it must take the fact that the driver's own ->runtime_resume() may be called > >>>> as a result of this into account. > Agree, that's a little bit annoying, but we are living with that for more then > 5 years already (I'm 3 years) - so, I am, as driver developer, expecting above behavior > (just walk through the drivers and you will see how many drivers expecting the same). > > So, any volunteers to check and fix ~500 drivers. We don't have to change these drivers. An certainly they are not 500. :-) They will still work as is! Though we need this fix to comply with them, which is supposed to go in for 3.18 rc[n]. "PM / Domains: Fix initial default state of the need_restore flag" [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |