RE: autosleep suspend too frquent problem

From: Wang, Yalin
Date: Thu Jun 05 2014 - 02:51:53 EST


Thanks for your clarification.

One problem is the sd card driver itself .

In addition, I also think kernel's autosleep.c module
Have problem too.
It just test wake up count ,if the count is zero, then enter suspend.

This will result in frequent suspend / resume problems sometimes,
It is not acceptable, I think also need to be fixed to
Avoid this special scenario .


-----Original Message-----
From: Ulf Hansson [mailto:ulf.hansson@xxxxxxxxxx]
Sent: Wednesday, June 04, 2014 5:53 AM
To: Pavel Machek
Cc: Wang, Yalin; len.brown@xxxxxxxxx; rjw@xxxxxxx; linux-pm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-mmc
Subject: Re: autosleep suspend too frquent problem

On 3 June 2014 14:01, Pavel Machek <pavel@xxxxxx> wrote:
> Hi!
>> I found sd card sometimes are damaged/ destroyed On our devices .
>> And seems it is caused by kernel's frequently suspend/resume, Because
>> during suspend/resume, the driver will suspend/resume sdcard Very
>> frequently, this will damaged the sdcard sometimes, and the damage is
>> not recoverable ..
>> Sometimes kernel will enter suspend and exit suspend very frequently,
>> Especially when the system is in idle, but some driver is not idle,
>> And it will wake up the system by irq frequently.
>> By our power test result, if system enter suspend /resume very
>> frequently, Will consume more power , because it will enable /disable
>> many devices During a short time .
>> I make a patch to prevent the system to enter suspend/resume state
>> More than one time during 2 secondsï
> It is good you managed to diagnose the problem, but this si not the
> right solution.
> Either:
> 1) don't power down SD card during system suspend

NAK. The amount of power a card (even if there are good behaving cards as well) may utilize, in powered but idle state could be significant.
I have seen cases of constant power consumption of several mA here.

> or maybe even better
> 2) don't power _up_ SD card during system resume. Let it be powered
> down until the first access.

Good news! This is "almost" supported already by the mmc subsystem.

If your mmc host has set the capability flag MMC_CAP_RUNTIME_RESUME, that means the card won't be powered up (and initialized) until the next request.

However, for removable cards (!MMC_CAP_NONREMOVABLE), during system resume phase, the mmc core will trigger a "rescan" of the card, to verify it has not been removed. Thus, unfortunate for this use case, the first request (for removable cards) will be triggered during the system resume phase.

I suppose we should add some extra conditions/flags which makes the mmc core to handle the above scenario. Actually I have been thinking of putting together a patch for this, but it never pops up on the top of my TODO list. :-)

Additionally, I wonder if this bouncing up and down from suspend to resume, could have other negative impact for other subsystems? Is it just a mmc subsystem problem? I am not so sure.

Kind regards
Ulf Hansson

> Thanks,
> Pavel
> --
> (english)
> (cesky, pictures)
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at
> Please read the FAQ at