On Thu 2014-06-05 14:51:41, Wang, Yalin wrote:
> Hi  
> 
> 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 .

Android phones pretty much want to sleep very very often. But if you
think there's coding bug in there, let us know..
                                                                Pavel

> Thanks
> 
> 
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org] 
> Sent: Wednesday, June 04, 2014 5:53 AM
> To: Pavel Machek
> Cc: Wang, Yalin; len.br...@intel.com; r...@sisk.pl; linux...@vger.kernel.org; 
> linux-ker...@vger.kernel.org; linux-mmc
> Subject: Re: autosleep suspend too frquent problem
> 
> On 3 June 2014 14:01, Pavel Machek <pa...@ucw.cz> 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) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) 
> > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe 
> > linux-kernel" in the body of a message to majord...@vger.kernel.org 
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to