Re: [PATCH] RFC: mmc: dw_mmc: Always go to STATE_DATA_BUSY from STATE_DATA_ERROR

Looks good to me. Reviewed-by: Jaehoon Chung Best Regards, Jaehoon Chung On 04/05/2013 05:18 PM, Jaehoon Chung wrote: > Hi Doug, > > You're right..it's something wrong. > Actually i didn't test with your patch, but your commit message is reasonable. > > I will check until next week after test

Re: FLUSH mechanism implementation in block layer

Hi Tejun, Thank you for the prompt response. Which version of kernel are you looking at? The barrier / flush implementation went through several iterations and in the current iteration ordering of requests around the flush request is the responsibility of higher layer - ie. filesystems are req

[PATCH 2/5 V2] mmc: core: call pm_runtime_put_noidle in pm_runtime_get_sync failed case

Even in failed case of pm_runtime_get_sync, the usage_count is incremented. In order to keep the usage_count with correct value and runtime power management to behave correctly, call pm_runtime_put_noidle in such case. Signed-off-by Liu Chuansheng Signed-off-by: Li Fei --- drivers/mmc/core/sdi

RE: [PATCH 2/5] mmc: core: call pm_runtime_put_sync in pm_runtime_get_sync failed case

> > Hi Li, > > On Thu, Feb 28, 2013 at 9:44 AM, Li Fei wrote: > > Even in failed case of pm_runtime_get_sync, the usage_count > > is incremented. In order to keep the usage_count with correct > > value and runtime power management to behave correctly, call > > pm_runtime_put(_sync) in such case.

Re: FLUSH mechanism implementation in block layer

Hey, On Sun, Apr 07, 2013 at 04:15:30PM +0300, Tanya Brokhman wrote: > I've been looking into the flush implementation, trying to > understand how it works. FLUSH command can be used for two purposes: > 1. Flush the data to the non-volatile memory from the card cache > 2. Keep an order of requests

FLUSH mechanism implementation in block layer

Hello Tejun, I'm writing to you since you're signed on the blk-flush.c file, hoping you could answer a flush-related question for me. Please excuse me if you're not the right person to address this to. I've been looking into the flush implementation, trying to understand how it works. FLUSH

Re: [PATCH 2/5] mmc: core: call pm_runtime_put_sync in pm_runtime_get_sync failed case

Hi Li, On Thu, Feb 28, 2013 at 9:44 AM, Li Fei wrote: > Even in failed case of pm_runtime_get_sync, the usage_count > is incremented. In order to keep the usage_count with correct > value and runtime power management to behave correctly, call > pm_runtime_put(_sync) in such case. As with the rem

[PATCH] mmc:host: Correct the Register bit in eSDHCI_HOST_CONTROL

Avoid writting to SDHCI_HOST_CONTROL[DTW] bit by mistake. Signed-off-by: Haijun Zhang CC: Anton Vorontsov --- drivers/mmc/host/sdhci-esdhc.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h index d25f9ab..d

[PATCH] mmc:host eSDHC: mmc:host host need long time to generate command complete interrupt

According to Spec 2.0, command complete interrupt will generate within 150 SD-CLK. But this was not enough on T4240 board. So give it sufficient time to detect command timeout. 1000 * HZ will be enough, this value was test on all T4 board, all worked well. Signed-off-by: Haijun Zhang CC: Anton Vo

[PATCH] mmc:block Add Fixup of BROKEN CMD23 for SANDISK card

Some sandisk card can't support CMD23, cmd timeout will generate. SO add FIX-UP for two type of these Sandisk cards. "SDMB-32" and "SDM032" Error log: mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400900 m

[PATCH] mmc:host eSDHC: Remove duplicate code of enable_dma

Remove duplicate code "enable_dma()" in platform_resume. Enable_dma was invoked already in sdhci_resume_host before ops->platform_resume was executed Signed-off-by: Haijun Zhang CC: Anton Vorontsov --- drivers/mmc/host/sdhci-of-esdhc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-)