On Wed, Jul 09, 2014 at 02:57:53PM +0530, Vinod Koul wrote:
+static int sst_save_dsp_context_v2(struct intel_sst_drv *sst)
_v2?
+static int intel_sst_runtime_suspend(struct device *dev) +{
- int ret = 0;
- struct intel_sst_drv *ctx = dev_get_drvdata(dev);
- pr_info("runtime_suspend called\n");
This is way too noisy.
- if (ctx->sst_state == SST_RESET) {
pr_debug("LPE is already in RESET state, No action");return 0;- }
- /*save fw context*/
- if (ctx->ops->save_dsp_context(ctx))
return -EBUSY;- /* Move the SST state to Reset */
- sst_set_fw_state_locked(ctx, SST_RESET);
- flush_workqueue(ctx->post_msg_wq);
- synchronize_irq(ctx->irq_num);
This is very strange - we're flushing the work *after* resetting the DSP which suggests there might be something else trying to access the DSP while it is being put into reset. Presumably that'd be bad.
- /* When fw_clear_cache is set, clear the cached firmware copy */
- /* fw_clear_cache is set through debugfs support */
- if (atomic_read(&ctx->fw_clear_cache) && ctx->fw_in_mem) {
Why? It'd seem more direct to just have the debugfs write trigger trashing of the firmware on demand...
+static int intel_sst_suspend(struct device *dev) +{
- return intel_sst_runtime_suspend(dev);
+}
You currently need to check that the device isn't runtime suspended before you try to reuse runtime PM ops in suspend.
+static int intel_sst_runtime_idle(struct device *dev) +{
- struct intel_sst_drv *ctx = dev_get_drvdata(dev);
- pr_info("runtime_idle called\n");
- if (ctx->sst_state != SST_RESET) {
pm_schedule_suspend(dev, SST_SUSPEND_DELAY);return -EBUSY;- } else {
return 0;- }
- return -EBUSY;
+}
This is very strange, what is going on?