Tony,
Tony Lindgren [off-list ref] writes:
* jean.pihet at newoldbits.com [off-list ref] [110504 06:32]:
quoted
+int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
...
quoted
+int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
...
quoted
+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.
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.
Kevin
* Kevin Hilman [off-list ref] [110504 17:33]:
Tony,
Tony Lindgren [off-list ref] writes:
quoted
* jean.pihet at newoldbits.com [off-list ref] [110504 06:32]:
quoted
+int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)
...
quoted
+int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev,
...
quoted
+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
* Tony Lindgren [off-list ref] [110505 08:56]:
So the problem is patches 1 & 8 in this series. The rest is just fine
as it's the necessary omap hardware specific implementation.
Sorry, patches 1 & 7 I mean.
Tony