Hi,
On Wed, Jan 11 2012, S, Venkatraman wrote:
> On Thu, Jan 5, 2012 at 6:25 AM, Jaehoon Chung <jh80.chung@xxxxxxxxxxx> wrote:
>>
>> Enable eMMC background operations (BKOPS) feature.
>>
>> If URGENT_BKOPS is set after a response, note that BKOPS
>> are required. After all I/O requests are finished, run
>> BKOPS if required. Should read/write operations be requested
>> during BKOPS, first issue HPI to interrupt the ongoing BKOPS
>> and then service the request.
>>
>> If you want to enable this feature, set MMC_CAP2_BKOPS.
>>
>> Future considerations
>> * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
>> * Interrupt ongoing BKOPS before powering off the card.
>> * How get BKOPS_STATUS value.(periodically send ext_csd command?)
>>
>> Signed-off-by: Jaehoon Chung <jh80.chung@xxxxxxxxxxx>
>> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
>> ---
>> Changelog V5:
>> - Rebase based on the latest mmc-next.
>> - modify codes based-on Chris's comment
>> Changelog V4:
>> - Add mmc_read_bkops_status
>> - When URGENT_BKOPS(level2-3), didn't use HPI command.
>> - In mmc_switch(), use R1B/R1 according to level.
>> Changelog V3:
>> - move the bkops setting's location in mmc_blk_issue_rw_rq
>> - modify condition checking
>> - bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of "1"
>> - remove the unused code
>> - change pr_debug instead of pr_warn in mmc_send_hpi_cmd
>> - Add the Future consideration suggested by Per
>> Changelog V2:
>> - Use EXCEPTION_STATUS instead of URGENT_BKOPS
>> - Add function to check Exception_status(for eMMC4.5)
>>
>> drivers/mmc/card/block.c | 11 +++++
>> drivers/mmc/card/queue.c | 3 +
>> drivers/mmc/core/core.c | 105
>> ++++++++++++++++++++++++++++++++++++++++++++
>> drivers/mmc/core/mmc.c | 8 +++
>> drivers/mmc/core/mmc_ops.c | 12 +++++-
>> include/linux/mmc/card.h | 13 +++++
>> include/linux/mmc/core.h | 4 ++
>> include/linux/mmc/host.h | 1 +
>> include/linux/mmc/mmc.h | 19 ++++++++
>> 9 files changed, 175 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index 0cad48a..5e3c580 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -1273,6 +1273,17 @@ static int mmc_blk_issue_rw_rq(struct
>> mmc_queue *mq, struct request *rqc)
>> type = rq_data_dir(req) == READ ? MMC_BLK_READ : MMC_BLK_WRITE;
>> mmc_queue_bounce_post(mq_rq);
>>
>> + /*
>> + * Check BKOPS urgency from each R1 response
>> + */
>> + if (mmc_card_mmc(card) &&
>> + (brq->cmd.flags == MMC_RSP_R1B ||
>> + brq->cmd.flags == MMC_RSP_R1) &&
>
> I tested this patch on my setup and this condition never hit, as other
> flags are also set in cmd.flags
> It should have been
> (brq->cmd.flags & MMC_RSP_R1B ||
> brq->cmd.flags & MMC_RSP_R1)
>
>
>> + (brq->cmd.resp[0] & R1_EXCEPTION_EVENT)) {
>> + if (mmc_is_exception_event(card,
>> EXT_CSD_URGENT_BKOPS))
>
> This causes a crash on my test setup. The next req is already given to
> the controller (see the mmc_start_req call a few lines above) and a
> parallel request to read BKOPS_STATUS is interfering with it. This
> won't work with any host controller driver which implements async_req
> functions.
>
> But there is no need to read BKOPS_STATUS at this stage anyway. By
> checking R1_EXCEPTION_EVENT and the BKOPS bit inside the response, the
> need to do BKOPS can be determined (as only a urgen_bkops state would
> trigger a R1_EXCEPTION_EVENT in the first place)
Thanks very much for testing! I'll drop this from my 3.3 queue --
we can try it again for 3.4.
- Chris.
--
Chris Ball <cjb@xxxxxxxxxx> <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
