Hi Magnus, On Tuesday 19 June 2012 15:53:30 Magnus Damm wrote: > On Fri, Jun 15, 2012 at 4:09 PM, Guennadi Liakhovetski wrote: > > On Fri, 15 Jun 2012, Magnus Damm wrote: > > > > [snip] > > > >> Guennadi, does this trigger on sh7372 as well? If not, why is that? > > > > No. That message is produced by the sh_mobile_sdhi_wait_idle() function, > > which is only used, if the TMIO_MMC_HAS_IDLE_WAIT flag is set, which is > > not set on mackerel (or ap4evb). > > Ok, thanks for checking this. It seems that we are "lucky" to find > this breakage... > > In the future, please take care to make sure this does not happen > again. This goes without saying, but the driver should not access the > hardware when it is Runtime PM suspended. I believe it should be > possible to verify the code paths by manual code inspection. Also, to > make the behavior more consistent you may want to make use of > "pm_runtime_put_sync()" instead of "pm_runtime_put()".
For testing that's a good idea. That makes me wonder whether we should have a Kconfig option to turn all pm_runtime_put() into pm_runtime_put_sync() for stress-testing. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
