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:

quoted

On Fri, 15 Jun 2012, Magnus Damm wrote:

[snip]

quoted

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