From patchwork Wed Jul 18 06:16:07 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adrian Hunter X-Patchwork-Id: 1208701 Return-Path: X-Original-To: patchwork-linux-mmc@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id 0B71CDFFFD for ; Wed, 18 Jul 2012 06:15:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750833Ab2GRGPQ (ORCPT ); Wed, 18 Jul 2012 02:15:16 -0400 Received: from mga11.intel.com ([192.55.52.93]:39727 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750764Ab2GRGPP (ORCPT ); Wed, 18 Jul 2012 02:15:15 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 17 Jul 2012 23:15:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="179367784" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.68]) ([10.237.72.68]) by fmsmga001.fm.intel.com with ESMTP; 17 Jul 2012 23:15:07 -0700 Message-ID: <500654A7.8010501@intel.com> Date: Wed, 18 Jul 2012 09:16:07 +0300 From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jaehoon Chung CC: linux-mmc , Chris Ball , Kyungmin Park , Hanumath Prasad , Per FORLIN , Sebastian Rasmussen , "Dong, Chuanxiao" , "svenkatr@ti.com" , Saugata Das , Konstantin Dorfman , Maya Erez , Ulf Hansson Subject: Re: [PATCH v10] mmc: support BKOPS feature for eMMC References: <5004D176.7090306@samsung.com> <50055AED.4000709@intel.com> <50056176.5010502@samsung.com> In-Reply-To: <50056176.5010502@samsung.com> Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org On 17/07/12 15:58, Jaehoon Chung wrote: > On 07/17/2012 09:30 PM, Adrian Hunter wrote: >> On 17/07/12 05:44, Jaehoon Chung wrote: >> >> >> >>> +/** >>> + * mmc_start_bkops - start BKOPS for supported cards >>> + * @card: MMC card to start BKOPS >>> + * >>> + * Start background operations whenever requested. >>> + * when the urgent BKOPS bit is set in a R1 command response >>> + * then background operations should be started immediately. >>> +*/ >>> +void mmc_start_bkops(struct mmc_card *card) >>> +{ >>> + int err; >>> + int timeout; >>> + u8 use_busy_signal; >>> + >>> + BUG_ON(!card); >>> + if (!card->ext_csd.bkops_en || !(card->host->caps2 & MMC_CAP2_BKOPS)) >>> + return; >>> + >>> + if (mmc_is_exception_event(card, EXT_CSD_URGENT_BKOPS)) >>> + if (card->ext_csd.raw_bkops_status) >>> + mmc_card_set_need_bkops(card); >>> + >>> + /* >>> + * If card is already doing bkops or need for >>> + * bkops flag is not set, then do nothing just >>> + * return >>> + */ >>> + if (mmc_card_doing_bkops(card) || !mmc_card_need_bkops(card)) >>> + return; >>> + >>> + mmc_claim_host(card->host); >>> + if (card->ext_csd.raw_bkops_status >= EXT_CSD_BKOPS_LEVEL_2) { >>> + timeout = MMC_BKOPS_MAX_TIMEOUT; >>> + use_busy_signal = 0; >>> + } else { >>> + timeout = 0; >>> + use_busy_signal = 1; >>> + } >> >> Is this the right way around? > > use the mmc_switch() with R1B.. > this case is no problem, because after sending bkops, repeat the checking card status until prg-done. > But, at sdhci controller, be occurred data timeout error. > Because response type is r1b, and timeout value is too large. > (Actually, i think that is controller's problem..but just its my test environment.) > > if other sdhci controller working well with R1b, use_busy_signal need not. > Just use the mmc_switch(). > > But When running bkops level2/3 use with R1 type, also no problem. > Because the also checking status in mmc_switch() until prg-done. You added: + /* + * For urgent bkops status (LEVEL_2 and more) + * bkops executed synchronously, otherwise + * the operation is in progress + */ + if (card->ext_csd.raw_bkops_status < EXT_CSD_BKOPS_LEVEL_2) + mmc_card_set_doing_bkops(card); But: status < 2 => use_busy_signal = 1 use_busy_signal = 1 => waiting waiting => the operation is NOT in progress Hence my question: Is this the right way around? Also this change is needed for the addition of 'use_busy_signal' to mmc_switch: --- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/mmc/core/mmc_ops.c b/drivers/mmc/core/mmc_ops.c index baf90e0..e202a5e 100644 --- a/drivers/mmc/core/mmc_ops.c +++ b/drivers/mmc/core/mmc_ops.c @@ -417,7 +417,7 @@ int __mmc_switch(struct mmc_card *card, u8 set, u8 index, u8 value, err = mmc_send_status(card, &status); if (err) return err; - if (card->host->caps & MMC_CAP_WAIT_WHILE_BUSY) + if (use_busy_signal && (card->host->caps & MMC_CAP_WAIT_WHILE_BUSY)) break; if (mmc_host_is_spi(card->host)) break;