From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752059AbcFVOX2 (ORCPT ); Wed, 22 Jun 2016 10:23:28 -0400 Received: from mail-bn1on0096.outbound.protection.outlook.com ([157.56.110.96]:16726 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751453AbcFVOX0 (ORCPT ); Wed, 22 Jun 2016 10:23:26 -0400 From: Alex Lemberg To: Shawn Lin , Ulf Hansson CC: Adrian Hunter , Jaehoon Chung , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Doug Anderson , "linux-rockchip@lists.infradead.org" Subject: Re: [PATCH] mmc: core: add auto bkops support Thread-Topic: [PATCH] mmc: core: add auto bkops support Thread-Index: AQHRv6CfUecJptXFn0uOY9vptpBOzJ/f3B8AgAUz6ICADZOsAIAAmf6AgAKUcoA= Date: Wed, 22 Jun 2016 14:08:32 +0000 Message-ID: References: <1465182439-27963-1-git-send-email-shawn.lin@rock-chips.com> <7078F2B9-63B6-4170-BFA1-5AC370F0D4DD@sandisk.com> <29966a6f-eb14-0307-08cc-f91a97f50382@rock-chips.com> In-Reply-To: <29966a6f-eb14-0307-08cc-f91a97f50382@rock-chips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alex.Lemberg@sandisk.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [212.25.79.133] x-ms-office365-filtering-correlation-id: a389431a-625f-4be0-aa17-08d39aa6b1c0 x-microsoft-exchange-diagnostics: 1;BL2PR02MB2017;20:X4JO9y8nJ0q5ttfQkXLG+vhYlaBZYzNGiJuKXZc6DSqVTMUCSkutB0HKEZgB3+YqhrA3775tdZoQw5WFslcYjsS/kOT2rtJ1Yk4R+DKjhlOoLjMrGLgcJKqlHaZ7n8WVvk44NeHrxY2YNqAXqrg5Awzu+YAzzrRlmvLgI3AlUeuscPbdVMnTfTG7s0ZiL8MVuIz3/PVRHJAy2MEUtqNna40/qLR/2oYCqkT7CsbFfkkNnvvymWlN2xgNHwgJKBSr x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR02MB2017; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:BL2PR02MB2017;BCL:0;PCL:0;RULEID:;SRVR:BL2PR02MB2017; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(377454003)(199003)(189002)(52314003)(24454002)(102836003)(6116002)(3846002)(86362001)(586003)(92566002)(97736004)(4001350100001)(5001770100001)(2900100001)(2906002)(99286002)(4326007)(10400500002)(106356001)(2950100001)(3660700001)(105586002)(87936001)(3280700002)(81166006)(81156014)(106116001)(33656002)(8676002)(83506001)(5002640100001)(83716003)(50986999)(77096005)(93886004)(66066001)(122556002)(189998001)(82746002)(8936002)(7846002)(11100500001)(76176999)(19580395003)(19580405001)(101416001)(68736007)(36756003)(7736002)(54356999)(104396002);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2PR02MB2017;H:BL2PR02MB2020.namprd02.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <289A7F2C1EDA7045AE3248601B04E486@namprd02.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: sandisk.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 14:08:32.3561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcd9ea9c-ae8c-460c-ab3c-3db42d7ac64d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR02MB2017 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u5MENXGM010359 HI Shawn, On 6/21/16, 4:44 AM, "Shawn Lin" wrote: >On 2016/6/20 21:33, Alex Lemberg wrote: >> Hi Shawn, >> >> […] >> >>>>> + >>>>> +static int mmc_stop_auto_bkops(struct mmc_card *card) >>>>> +{ >>>>> + int err = 0; >>>>> + >>>>> + if (!card->ext_csd.auto_bkops_en) >>>>> + return 0; >>>>> + >>>> >>>> Shouldn’t the BKOPS_STATUS be checked prior to disabling the BKOPS activity of the device? >>>> >>> >>> Hrmm.. I read the whole section of spec for it, and I did find this >>> requirement for manul bkops but not for the auto one. So what should we >>> do if using the auto one? >>> >> >> In case of AUTO BKOPS, the eMMC Device should perform internal GC >> in the same way as in case of MANUAL BKOPS. >> The only difference is a host awareness. > >agree. > >> Although there is no requirement in the spec, I think the driver can >> give some time to the device to perform/complete its internal GC during the idle time. >> Thus I think we can check the BKOPS_STATUS on Runtime suspend. > >We shouldn't diable bkops on *runtime* suspend as it's just the right >time for firmware to do GC. We could consider to check and wait for >the status when doing poweroff, although it seems firmware should be >able to accept the disable cmd and deal the on-going work perfectly >when doing bkops without host's awareness, just the same way as suddent >power loss cases. If I am not wrong, in current implementation of runtime suspend, the driver stops BKOPS (send HPI) just before sending sleep command, see _mmc_suspend(), depends on “MMC_CAP_AGGRESSIVE_PM” flag. In this case, the eMMC device will not have enough time to perform internal BKOPS in both – Manual and Auto BKOPS configurations. For the poweroff, it should be OK with a current implementation of PON (mmc_poweroff_notify()) > >Also I don't know whether the firmware will reflect its status on >BKOPS_STATUS or not when enabling the auto one. I will do more test. > >Anyway, thanks for sharing your thought. >Also Adrian point out that currently we trigger manual bkosp from >userspace via mmc-utils, and I agreed we shouldn't force kernel stack >to enable it defaultly. So I'm prone not to update this $SUBJECT and >migrate it to mmc-utils later. > >> >> […] >> >> Thanks, >> Alex >> > > >-- >Best Regards >Shawn Lin >