* Kevin Hilman <[email protected]> [110504 17:33]: > Tony, > > Tony Lindgren <[email protected]> writes: > > > * [email protected] <[email protected]> [110504 06:32]: > >> > >> +int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t) > > ... > > > >> +int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device > >> *dev, > > ... > > > >> +int omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r) > > ... > > > > You should implement this as a Linux generic framework, we don't > > want to add more omap specific frameworks. > > This series isn't adding any new OMAP-specific frameworks. The OMAP PM > layer is already in place, and has been there for awhile. OMAP PM is a > layer which can have "plugins" so we can experiment with ways of > handling constraints without changing the driver interface, and this > series is just implementing a new plugin.
But in this case the plugin is just stubs. The only function that does something is omap_pm_get_dev_context_loss_count. And then patch 8 in this series starts adding a new omap specific features for constraints. So the problem is patches 1 & 8 in this series. The rest is just fine as it's the necessary omap hardware specific implementation. > Once we are happy with a constraint layer, and can prove it will work, > the plan is to get rid of the (existing) OMAP-specific APIs and propose > a generic interface. Well I don't think we should start building new omap specific layer on an omap specific framework. Instead, the constraint layer should be made generic to start with, even if it's just a minimal implementation initially. Maybe it could be just a generic header file to start with? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
