On Thu, 15 Dec 2011 20:39:28 -0800 Bing Zhao wrote:
> Hi Neil,
>
> > In the other case where I do let it suspend early (And it never recovers
> > without the reset line being toggled) I see:
> >
> > [ 2170.100982] mmc_wait_for_cmd 52 -> -110
> > [ 2170.105407] mmc_wait_for_cmd 52 -> -110
> > [
Hi Neil,
> In the other case where I do let it suspend early (And it never recovers
> without the reset line being toggled) I see:
>
> [ 2170.100982] mmc_wait_for_cmd 52 -> -110
> [ 2170.105407] mmc_wait_for_cmd 52 -> -110
> [ 2170.110260] mmc_wait_for_cmd 0 -> 0
> [ 2170.115509] mmc_wait_for_cmd
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Jaehoon Chung
> Sent: Friday, December 16, 2011 12:06 PM
> To: Huang Changming-R66093
> Cc: Jaehoon Chung; Philip Rakity; linux-mmc@vger.kernel.org; Chris Ball
> Subject:
On Sun, 11 Dec 2011 09:30:48 +0200 Ohad Ben-Cohen wrote:
> On Sat, Dec 10, 2011 at 9:15 AM, NeilBrown wrote:
> > When I force it to hold off suspend for a little while I see (starting at
> > the
> > same place):
> >
> > [ 656.189697] bus: 'sdio': driver_probe_device: matched device mmc1:0001:1
On 12/16/2011 12:25 PM, Huang Changming-R66093 wrote:
>>> I am very confused, why do we read the present state register on every
>> request?
>>
>> How long time read the present state register?
> Even if one line code is performed, I think it need time to complete.
>
>>> My codes are added to the
> > I am very confused, why do we read the present state register on every
> request?
>
> How long time read the present state register?
Even if one line code is performed, I think it need time to complete.
> > My codes are added to the function mmc_sd_detect in file core/sd.c
> > Function mmc_re
Hi Eric and Jason,
On Thu, Dec 01 2011, Chris Ball wrote:
> Hi Eric, Jason,
>
> Please could you ACK this patch if you agree with it, and I'll take it
> and the rest of the series via the MMC tree? Thanks.
Ping?
Thanks,
- Chris.
> On Sun, Nov 20 2011, Tanmay Upadhyay wrote:
>> v2 - clock regi
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Ulf Hansson
> Sent: Thursday, December 15, 2011 3:06 PM
> To: linux-mmc@vger.kernel.org; Chris Ball
> Cc: Per Forlin; Ulf Hansson; Johan Rudholm; Lee Jones
> Subject: [PAT
> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
> ow...@vger.kernel.org] On Behalf Of Girish K S
> Sent: Thursday, December 15, 2011 5:28 PM
> To: linux-mmc@vger.kernel.org
> Cc: patc...@linaro.org; linux-samsung-...@vger.kernel.org; Girish K S;
> Philip Ra
Hi Chris
On 12/13/2011 5:35 PM, Chris Ball wrote:
> Hi Peppe,
>
> On Tue, Dec 06 2011, Giuseppe CAVALLARO wrote:
>>> I'm all for this patch so it gets visible in debugfs atleast,
>>> since people seem to need to know these things, so take that as an
>>> Acked-by: Linus Walleij
>>>
>>> Those who
On 15 December 2011 16:22, Girish K S wrote:
> On 15 December 2011 15:34, Saugata Das wrote:
>> On 15 December 2011 09:28, Girish K S
>> wrote:
>>> This patch adds a check whether the host supports maximum current value
>>> obtained from the device's extended csd register for a selected interfa
This patch fixes the wrong comparison before setting the interface
voltage in DDR mode.
The assignment to the variable ddr before comaprison is either
ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison
is done wth the extended csd value if (ddr == EXT_CSD_CARD_TYPE_DDR_1_2V)
On 15 December 2011 15:34, Saugata Das wrote:
> On 15 December 2011 09:28, Girish K S wrote:
>> This patch adds a check whether the host supports maximum current value
>> obtained from the device's extended csd register for a selected interface
>> voltage and frequency.
>>
>> cc: Chris Ball
>> S
On 12/15/2011 2:03 PM, amit kachhap wrote:
> On Thu, Dec 15, 2011 at 9:28 AM, Girish K S
> wrote:
>> This patch adds a check whether the host supports maximum current value
>> obtained from the device's extended csd register for a selected interface
>> voltage and frequency.
>>
>> cc: Chris Ball
On 14 December 2011 10:04, Seungwon Jeon wrote:
> Saugata Das wrote:
>> On 13 December 2011 11:57, Seungwon Jeon wrote:
>> > Hi Saugata,
>> >
>> > Saugata Das wrote:
>> >> Hi Seungwon Jeon
>> >>
>> >> I see a small issue with the implementation mmc_suspend_host,
>> >>
>> >> int mmc_suspend_host(s
On 15 December 2011 09:28, Girish K S wrote:
> This patch adds a check whether the host supports maximum current value
> obtained from the device's extended csd register for a selected interface
> voltage and frequency.
>
> cc: Chris Ball
> Signed-off-by: Girish K S
> ---
> Changes in v2:
>
On 12/15/2011 03:56 PM, Huang Changming-R66093 wrote:
>
>
>> -Original Message-
>> From: Philip Rakity [mailto:prak...@marvell.com]
>> Sent: Thursday, December 15, 2011 2:42 PM
>> To: Huang Changming-R66093
>> Cc: linux-mmc@vger.kernel.org; Chris Ball
>> Subject: Re: [PATCH 3/4 v5] SDHCI
Host may now use MMC_CAP2_NOSLEEP to disable the use of
eMMC sleep/awake command.
This option can be used when you platform have a buggy
kernel crash dump software, which is supposed to store
the dump on the eMMC, but is not able to wake up the eMMC
from sleep state.
Signed-off-by: Ulf Hansson
R
Hi Vitaly,
Vitaly Wool wrote:
On Wed, Dec 14, 2011 at 5:43 PM, Ulf Hansson
mailto:ulf.hans...@stericsson.com>>
wrote:
So in fact instead of decreasing time-to-userspace for resume, you
are rather going to increase it in this case.
Nope, not true. :-)
Somewhere you need to handle the resume.
19 matches
Mail list logo
