From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84F26C433E0 for ; Thu, 14 May 2020 14:49:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1022120727 for ; Thu, 14 May 2020 14:49:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="asseTBgV" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727098AbgENOti (ORCPT ); Thu, 14 May 2020 10:49:38 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:14943 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726176AbgENOti (ORCPT ); Thu, 14 May 2020 10:49:38 -0400 X-UUID: f327d38d8c614d92b655f7f41ce458d1-20200514 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=uTJlwni3Pyu0Wbuq7O34MNOI0GdhWDymx/mWX/Hdhgg=; b=asseTBgVOYdMFIYoaAJFVhAnJ+oZ7vYlIOPdkz8Ld0LmDnGsm7R46lnq4it5Ylpo01q6dSM02yJW1w+DD5bjnU+PpjsB6eGRp6IX9RJ/3EkPOPmmPPvcA+wZNkMBFJcZf8aFkXuWYHC6Eu79rBJNjSAHxYHttLuHSAQAkSkLg90=; X-UUID: f327d38d8c614d92b655f7f41ce458d1-20200514 Received: from mtkcas07.mediatek.inc [(172.21.101.84)] by mailgw01.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 1727512619; Thu, 14 May 2020 22:49:31 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 22:49:23 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 14 May 2020 22:49:23 +0800 Message-ID: <1589467766.3197.100.camel@mtkswgap22> Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend From: Stanley Chu To: "Asutosh Das (asd)" CC: "linux-scsi@vger.kernel.org" , "martin.petersen@oracle.com" , "Andy Teng ( =?ISO-8859-1?Q?=1B$B{}G!9(=1B(B?=)" , "jejb@linux.ibm.com" , Chun-Hung Wu =?UTF-8?Q?=28=E5=B7=AB=E9=A7=BF=E5=AE=8F=29?= , Kuohong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=9C=8B=E9=B4=BB=29?= , "linux-kernel@vger.kernel.org" , "avri.altman@wdc.com" , "cang@codeaurora.org" , "linux-mediatek@lists.infradead.org" , Peter Wang =?UTF-8?Q?=28=E7=8E=8B=E4=BF=A1=E5=8F=8B=29?= , "alim.akhtar@samsung.com" , "matthias.bgg@gmail.com" , "bvanassche@acm.org" , "linux-arm-kernel@lists.infradead.org" , "beanhuo@micron.com" Date: Thu, 14 May 2020 22:49:26 +0800 In-Reply-To: <1589423030.3197.94.camel@mtkswgap22> References: <20200512104750.8711-1-stanley.chu@mediatek.com> <20200512104750.8711-5-stanley.chu@mediatek.com> <725d057c-2379-710e-287f-ac11a59c08bc@codeaurora.org> <1589423030.3197.94.camel@mtkswgap22> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: 4780976ACDCE7F1FDB5960240E507B019A505AEB464268F722DFBF7EFC13B6632000:8 X-MTK: N Content-Transfer-Encoding: base64 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org SGkgQXN1dG9zaCwNCg0KT24gVGh1LCAyMDIwLTA1LTE0IGF0IDEwOjIzICswODAwLCBTdGFubGV5 IENodSB3cm90ZToNCj4gSGkgQXN1dG9zaCwNCj4gDQo+IE9uIFdlZCwgMjAyMC0wNS0xMyBhdCAx MjozMSAtMDcwMCwgQXN1dG9zaCBEYXMgKGFzZCkgd3JvdGU6DQo+ID4gT24gNS8xMi8yMDIwIDM6 NDcgQU0sIFN0YW5sZXkgQ2h1IHdyb3RlOg0KPiA+ID4gQ3VycmVudGx5IFVGUyBob3N0IGRyaXZl ciBwcm9taXNlcyBWQ0Mgc3VwcGx5IGlmIFVGUyBkZXZpY2UNCj4gPiA+IG5lZWRzIHRvIGRvIFdy aXRlQm9vc3RlciBmbHVzaCBkdXJpbmcgcnVudGltZSBzdXNwZW5kLg0KPiA+ID4gDQo+ID4gPiBI b3dldmVyIHRoZSBVRlMgc3BlY2lmaWNhdGlvbiBtZW50aW9ucywNCj4gPiA+IA0KPiA+ID4gIldo aWxlIHRoZSBmbHVzaGluZyBvcGVyYXRpb24gaXMgaW4gcHJvZ3Jlc3MsIHRoZSBkZXZpY2UgaXMN Cj4gPiA+IGluIEFjdGl2ZSBwb3dlciBtb2RlLiINCj4gPiA+IA0KPiA+ID4gVGhlcmVmb3JlIFVG UyBob3N0IGRyaXZlciBuZWVkcyB0byBwcm9taXNlIG1vcmU6IEtlZXAgVUZTDQo+ID4gPiBkZXZp Y2UgYXMgIkFjdGl2ZSBwb3dlciBtb2RlIiwgb3RoZXJ3aXNlIFVGUyBkZXZpY2Ugc2hhbGwgbm90 DQo+ID4gPiBkbyBhbnkgZmx1c2ggaWYgZGV2aWNlIGVudGVycyBTbGVlcCBvciBQb3dlckRvd24g cG93ZXIgbW9kZS4NCj4gPiA+IA0KPiA+ID4gRml4IHRoaXMgYnkgbm90IGNoYW5naW5nIGRldmlj ZSBwb3dlciBtb2RlIGlmIFdyaXRlQm9vc3Rlcg0KPiA+ID4gZmx1c2ggaXMgcmVxdWlyZWQgaW4g dWZzaGNkX3N1c3BlbmQoKS4NCj4gPiA+IA0KPiA+ID4gU2lnbmVkLW9mZi1ieTogU3RhbmxleSBD aHUgPHN0YW5sZXkuY2h1QG1lZGlhdGVrLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gICBkcml2ZXJz L3Njc2kvdWZzL3Vmcy5oICAgIHwgIDEgLQ0KPiA+ID4gICBkcml2ZXJzL3Njc2kvdWZzL3Vmc2hj ZC5jIHwgMzkgKysrKysrKysrKysrKysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiAg IDIgZmlsZXMgY2hhbmdlZCwgMTkgaW5zZXJ0aW9ucygrKSwgMjEgZGVsZXRpb25zKC0pDQo+ID4g PiANCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3Njc2kvdWZzL3Vmcy5oIGIvZHJpdmVycy9z Y3NpL3Vmcy91ZnMuaA0KPiA+ID4gaW5kZXggYjMxMzUzNDRhYjNmLi45ZTRiYzJlOTdhZGEgMTAw NjQ0DQo+ID4gPiAtLS0gYS9kcml2ZXJzL3Njc2kvdWZzL3Vmcy5oDQo+ID4gPiArKysgYi9kcml2 ZXJzL3Njc2kvdWZzL3Vmcy5oDQo+ID4gPiBAQCAtNTc3LDcgKzU3Nyw2IEBAIHN0cnVjdCB1ZnNf ZGV2X2luZm8gew0KPiA+ID4gICAJdTMyIGRfZXh0X3Vmc19mZWF0dXJlX3N1cDsNCj4gPiA+ICAg CXU4IGJfd2JfYnVmZmVyX3R5cGU7DQo+ID4gPiAgIAl1MzIgZF93Yl9hbGxvY191bml0czsNCj4g PiA+IC0JYm9vbCBrZWVwX3ZjY19vbjsNCj4gPiA+ICAgCXU4IGJfcHJlc3J2X3VzcGNfZW47DQo+ ID4gPiAgIH07DQo+ID4gPiAgIA0KPiA+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc2NzaS91ZnMv dWZzaGNkLmMgYi9kcml2ZXJzL3Njc2kvdWZzL3Vmc2hjZC5jDQo+ID4gPiBpbmRleCAxNjlhMzM3 OWU0NjguLjJkMGFmZjhhYzI2MCAxMDA2NDQNCj4gPiA+IC0tLSBhL2RyaXZlcnMvc2NzaS91ZnMv dWZzaGNkLmMNCj4gPiA+ICsrKyBiL2RyaXZlcnMvc2NzaS91ZnMvdWZzaGNkLmMNCj4gPiA+IEBA IC04MTAxLDggKzgxMDEsNyBAQCBzdGF0aWMgdm9pZCB1ZnNoY2RfdnJlZ19zZXRfbHBtKHN0cnVj dCB1ZnNfaGJhICpoYmEpDQo+ID4gPiAgIAkgICAgIWhiYS0+ZGV2X2luZm8uaXNfbHVfcG93ZXJf b25fd3ApIHsNCj4gPiA+ICAgCQl1ZnNoY2Rfc2V0dXBfdnJlZyhoYmEsIGZhbHNlKTsNCj4gPiA+ ICAgCX0gZWxzZSBpZiAoIXVmc2hjZF9pc191ZnNfZGV2X2FjdGl2ZShoYmEpKSB7DQo+ID4gPiAt CQlpZiAoIWhiYS0+ZGV2X2luZm8ua2VlcF92Y2Nfb24pDQo+ID4gPiAtCQkJdWZzaGNkX3RvZ2ds ZV92cmVnKGhiYS0+ZGV2LCBoYmEtPnZyZWdfaW5mby52Y2MsIGZhbHNlKTsNCj4gPiA+ICsJCXVm c2hjZF90b2dnbGVfdnJlZyhoYmEtPmRldiwgaGJhLT52cmVnX2luZm8udmNjLCBmYWxzZSk7DQo+ ID4gPiAgIAkJaWYgKCF1ZnNoY2RfaXNfbGlua19hY3RpdmUoaGJhKSkgew0KPiA+ID4gICAJCQl1 ZnNoY2RfY29uZmlnX3ZyZWdfbHBtKGhiYSwgaGJhLT52cmVnX2luZm8udmNjcSk7DQo+ID4gPiAg IAkJCXVmc2hjZF9jb25maWdfdnJlZ19scG0oaGJhLCBoYmEtPnZyZWdfaW5mby52Y2NxMik7DQo+ ID4gPiBAQCAtODE3Miw2ICs4MTcxLDcgQEAgc3RhdGljIGludCB1ZnNoY2Rfc3VzcGVuZChzdHJ1 Y3QgdWZzX2hiYSAqaGJhLCBlbnVtIHVmc19wbV9vcCBwbV9vcCkNCj4gPiA+ICAgCWVudW0gdWZz X3BtX2xldmVsIHBtX2x2bDsNCj4gPiA+ICAgCWVudW0gdWZzX2Rldl9wd3JfbW9kZSByZXFfZGV2 X3B3cl9tb2RlOw0KPiA+ID4gICAJZW51bSB1aWNfbGlua19zdGF0ZSByZXFfbGlua19zdGF0ZTsN Cj4gPiA+ICsJYm9vbCBrZWVwX2N1cnJfZGV2X3B3cl9tb2RlID0gZmFsc2U7DQo+ID4gPiAgIA0K PiA+ID4gICAJaGJhLT5wbV9vcF9pbl9wcm9ncmVzcyA9IDE7DQo+ID4gPiAgIAlpZiAoIXVmc2hj ZF9pc19zaHV0ZG93bl9wbShwbV9vcCkpIHsNCj4gPiA+IEBAIC04MjI2LDI4ICs4MjI2LDI3IEBA IHN0YXRpYyBpbnQgdWZzaGNkX3N1c3BlbmQoc3RydWN0IHVmc19oYmEgKmhiYSwgZW51bSB1ZnNf cG1fb3AgcG1fb3ApDQo+ID4gPiAgIAkJCS8qIG1ha2Ugc3VyZSB0aGF0IGF1dG8gYmtvcHMgaXMg ZGlzYWJsZWQgKi8NCj4gPiA+ICAgCQkJdWZzaGNkX2Rpc2FibGVfYXV0b19ia29wcyhoYmEpOw0K PiA+ID4gICAJCX0NCj4gPiA+ICsNCj4gPiBVbm5lY2Vzc2FyeSBuZXdsaW5lLCBwZXJoYXBzPw0K PiANCj4gWWFwLCBJIHdpbGwgcmVtb3ZlIGl0IGluIG5leHQgdmVyc2lvbi4NCj4gDQo+ID4gPiAg IAkJLyoNCj4gPiA+IC0JCSAqIFdpdGggd2IgZW5hYmxlZCwgaWYgdGhlIGJrb3BzIGlzIGVuYWJs ZWQgb3IgaWYgdGhlDQo+ID4gPiAtCQkgKiBjb25maWd1cmVkIFdCIHR5cGUgaXMgNzAlIGZ1bGws IGtlZXAgdmNjIE9ODQo+ID4gPiAtCQkgKiBmb3IgdGhlIGRldmljZSB0byBmbHVzaCB0aGUgd2Ig YnVmZmVyDQo+ID4gPiArCQkgKiBJZiBkZXZpY2UgbmVlZHMgdG8gZG8gQktPUCBvciBXQiBidWZm ZXIgZmx1c2gsIGtlZXAgZGV2aWNlDQo+ID4gPiArCQkgKiBwb3dlciBtb2RlIGFzICJhY3RpdmUg cG93ZXIgbW9kZSIgYW5kIGl0cyBWQ0Mgc3VwcGx5Lg0KPiA+ID4gICAJCSAqLw0KPiA+ID4gLQkJ aWYgKChoYmEtPmF1dG9fYmtvcHNfZW5hYmxlZCAmJiB1ZnNoY2RfaXNfd2JfYWxsb3dlZChoYmEp KSB8fA0KPiA+ID4gLQkJICAgIHVmc2hjZF93Yl9rZWVwX3ZjY19vbihoYmEpKQ0KPiA+ID4gLQkJ CWhiYS0+ZGV2X2luZm8ua2VlcF92Y2Nfb24gPSB0cnVlOw0KPiA+ID4gLQkJZWxzZQ0KPiA+ID4g LQkJCWhiYS0+ZGV2X2luZm8ua2VlcF92Y2Nfb24gPSBmYWxzZTsNCj4gPiA+IC0JfSBlbHNlIHsN Cj4gPiA+IC0JCWhiYS0+ZGV2X2luZm8ua2VlcF92Y2Nfb24gPSBmYWxzZTsNCj4gPiA+ICsJCWtl ZXBfY3Vycl9kZXZfcHdyX21vZGUgPSBoYmEtPmF1dG9fYmtvcHNfZW5hYmxlZCB8fA0KPiA+ID4g KwkJCXVmc2hjZF93Yl9rZWVwX3ZjY19vbihoYmEpOw0KPiA+IFNob3VsZCB0aGUgZGV2aWNlIGJl IGluIFVGU19BQ1RJVkVfUFdSX01PREUgdG8gcGVyZm9ybSBhdXRvLWJrb3BzPw0KPiA+IA0KPiA+ IEFsc28sIGlzIGl0IG5lZWRlZCB0byBrZWVwIHRoZSBkZXZpY2UgaW4gVUZTX0FDVElWRV9QV1Jf TU9ERSAsIGlmIGZsdXNoIA0KPiA+IG9uIGhpYmVybjggaXMgZW5hYmxlZCBhbmQgdGhlIGxpbmsg aXMgYmVpbmcgcHV0IHRvIGhpYmVybjggbW9kZSBkdXJpbmcgDQo+ID4gcnVudGltZS1zdXNwZW5k PyBQZXJoYXBzIHRoYXQgc2hvdWxkIGFsc28gYmUgZmFjdG9yZWQgaW4gaGVyZT8NCj4gDQo+IEJv dGggYXV0by1ia29wcyBhbmQgV3JpdGVCb29zdGVyIGZsdXNoIGR1cmluZyBIaWJlcm44IG5lZWQg ZGV2aWNlIHBvd2VyDQo+IG1vZGUgdG8gYmUgIkFjdGl2ZSBQb3dlciBNb2RlIi4NCj4gDQo+IEZv ciBhdXRvLWJrb3BzLCB0aGUgc3BlYyBtZW50aW9ucywNCj4gDQo+ICJJZiB0aGUgYmFja2dyb3Vu ZCBvcGVyYXRpb25zIGVuYWJsZSBiaXQgaXMgc2V0IGFuZCB0aGUgZGV2aWNlIGlzIGluDQo+IEFj dGl2ZSBwb3dlciBtb2RlIG9yIElkbGUgcG93ZXIgbW9kZSwgdGhlbiB0aGUgZGV2aWNlIGlzIGFs bG93ZWQgdG8NCj4gZXhlY3V0ZSBhbnkgaW50ZXJuYWwgb3BlcmF0aW9ucy4iDQo+IA0KPiBGb3Ig V3JpdGVCb29zdGVyIGZsdXNoIGR1cmluZyBIaWJlcm44LCB0aGUgc3BlYyBtZW50aW9ucywNCj4g DQo+ICJXaGlsZSB0aGUgZmx1c2hpbmcgb3BlcmF0aW9uIGlzIGluIHByb2dyZXNzLCB0aGUgZGV2 aWNlIGlzIGluIEFjdGl2ZQ0KPiBwb3dlciBtb2RlLiINCj4gDQo+IFRoZXJlZm9yZSBoZXJlIHdl IGNhbiB1c2UgYW4gdW5pZmllZCAia2VlcF9jdXJyX2Rldl9wd3JfbW9kZSIgdG8NCj4gaW5kaWNh dGUgdGhlIHNhbWUgcmVxdWlyZW1lbnRzIG9mIGFib3ZlIGJvdGggZmVhdHVyZXMuDQo+IA0KPiBC ZXNpZGVzLCBib3RoIG9wZXJhdGlvbnMgbWF5IGFjY2VzcyBmbGFzaCBhcnJheSBpbnNpZGUgVUZT IGRldmljZSB0aHVzDQo+IFZDQyBzdXBwbHkgc2hhbGwgYmUgYWxzbyBrZXB0Lg0KPiANCj4gQmVm b3JlIHRoaXMgcGF0Y2gsIHRoZSBvcmlnaW5hbCBjb2RlIHdpbGwga2VlcCBkZXZpY2UgcG93ZXIg bW9kZSAoc3RheQ0KPiBpbiBBY3RpdmUgUG93ZXIgTW9kZSkgaWYgaGJhLT5hdXRvX2Jrb3BzX2Vu YWJsZWQgaXMgc2V0IGFzIHRydWUgZHVyaW5nDQo+IHJ1bnRpbWUtc3VzcGVuZCB3aXRoIFVGU0hD RF9DQVBfQVVUT19CS09QU19TVVNQRU5EIGNhcGFiaWxpdHkgaXMNCj4gZW5hYmxlZC4gVGhpcyBw YXRjaCB3aWxsIG5vdCBjaGFuZ2UgdGhpcyBkZWNpc2lvbiwganVzdCBhZGQNCj4gIldyaXRlQm9v c3RlciBmbHVzaCBkdXJpbmcgSGliZXJuOCIgZmVhdHVyZSBhcyBhbm90aGVyIGNvbmRpdGlvbiB0 byBkbw0KPiBzby4NCj4gDQo+IFRoYW5rIHlvdSBzbyBtdWNoIHRvIHJlbWluZCBtZSB0aGF0ICJM aW5rIHNoYWxsIGJlIHB1dCBpbiBIaWJlcm44IiBpcyBhDQo+IG5lY2Vzc2FyeSBjb25kaXRpb24g Zm9yICJXcml0ZUJvb3N0ZXIgZmx1c2ggZHVyaW5nIEhpYmVybjgiLiBJIHdpbGwgYWRkDQo+IG1v cmUgY2hlY2tpbmcgZm9yIGtlZXBfY3Vycl9kZXZfcHdyX21vZGUgdG8gcHJldmVudCB1bm5lY2Vz c2FyeSBwb3dlcg0KPiBkcmFpbi4gIA0KPiANCj4gPiA+ICAgCX0NCj4gPiA+ICAgDQo+ID4gPiAt CWlmICgocmVxX2Rldl9wd3JfbW9kZSAhPSBoYmEtPmN1cnJfZGV2X3B3cl9tb2RlKSAmJg0KPiA+ ID4gLQkgICAgKCh1ZnNoY2RfaXNfcnVudGltZV9wbShwbV9vcCkgJiYgIWhiYS0+YXV0b19ia29w c19lbmFibGVkKSB8fA0KPiA+ID4gLQkgICAgIXVmc2hjZF9pc19ydW50aW1lX3BtKHBtX29wKSkp IHsNCj4gPiA+IC0JCS8qIGVuc3VyZSB0aGF0IGJrb3BzIGlzIGRpc2FibGVkICovDQo+ID4gPiAt CQl1ZnNoY2RfZGlzYWJsZV9hdXRvX2Jrb3BzKGhiYSk7DQo+ID4gPiAtCQlyZXQgPSB1ZnNoY2Rf c2V0X2Rldl9wd3JfbW9kZShoYmEsIHJlcV9kZXZfcHdyX21vZGUpOw0KPiA+ID4gLQkJaWYgKHJl dCkNCj4gPiA+IC0JCQlnb3RvIGVuYWJsZV9nYXRpbmc7DQo+ID4gPiArCWlmIChyZXFfZGV2X3B3 cl9tb2RlICE9IGhiYS0+Y3Vycl9kZXZfcHdyX21vZGUpIHsNCj4gPiA+ICsJCWlmICgodWZzaGNk X2lzX3J1bnRpbWVfcG0ocG1fb3ApICYmICFoYmEtPmF1dG9fYmtvcHNfZW5hYmxlZCkgfHwNCj4g PiA+ICsJCSAgICAhdWZzaGNkX2lzX3J1bnRpbWVfcG0ocG1fb3ApKSB7DQo+ID4gPiArCQkJLyog ZW5zdXJlIHRoYXQgYmtvcHMgaXMgZGlzYWJsZWQgKi8NCj4gPiA+ICsJCQl1ZnNoY2RfZGlzYWJs ZV9hdXRvX2Jrb3BzKGhiYSk7DQo+ID4gPiArCQl9DQo+ID4gPiArDQo+ID4gPiArCQlpZiAoIWtl ZXBfY3Vycl9kZXZfcHdyX21vZGUpIHsNCj4gPiA+ICsJCQlyZXQgPSB1ZnNoY2Rfc2V0X2Rldl9w d3JfbW9kZShoYmEsIHJlcV9kZXZfcHdyX21vZGUpOw0KPiA+IA0KPiA+IE5vdywgd2hlbiB0aGUg V0IgYnVmZmVyIGlzIGNvbXBsZXRlbHkgZmx1c2hlZCBvdXQsIHRoZSBkZXZpY2Ugc2hvdWxkIGJl IA0KPiA+IHB1dCBiYWNrIGludG8gVUZTX1NMRUVQX1BXUl9NT0RFIG9yIFVGU19QT1dFUkRPV05f UFdSX01PREUuIFNheSwgdGhlIA0KPiA+IGRldmljZSBidWZmZXIgaGFzIHRvIGJlIGZsdXNoZWQg YW5kIGR1cmluZyBydW50aW1lLXN1c3BlbmQsIHRoZSBkZXZpY2UgDQo+ID4gaXMgcHV0IHRvIFVG U19BQ1RJVkVfUFdSX01PREUgYW5kIFZjYyBpcyBrZXB0IE9OOyB0aGUgZGV2aWNlIGRvZXNuJ3Qg DQo+ID4gcmVzdW1lIG5vciBkb2VzIHRoZSBzeXN0ZW0gZW50ZXJzIHN1c3BlbmQgZm9yIGEgdmVy eSBsb25nIHRpbWUsIGFuZCB3aXRoIA0KPiA+IEFIOCBhbmQgaGliZXJuOCBkaXNhYmxlZCwgdGhl cmUgd2lsbCBiZSBhbiB1bm5lY2Vzc2FyeSBwb3dlciBkcmFpbiBmb3IgDQo+ID4gdGhhdCBtdWNo IHRpbWUuDQoNCkFub3RoZXIgdGhvdWdodCBpcyB0aGF0IGlmIGtlZXBfY3Vycl9kZXZfcHdyX21v ZGUgd2lsbCBiZSBzZXQgYXMgdHJ1ZQ0Kb25seSBpZiBsaW5rIGlzIHB1dCBpbiBIaWJlcm44IG9y IEF1dG8tSGliZXJuOCBpcyBlbmFibGVkLiBCeSB0aGlzIHdheSwNCnRoZSBwb3dlciBjb25zdW1w dGlvbiBzaGFsbCBiZSB2ZXJ5IHNtYWxsIGFmdGVyIGZsdXNoIG9yIGF1dG8tYmtvcCBpcw0KZmlu aXNoZWQuDQoNClRoZW4gdGhlIGNoZWNraW5nIG9mIGZsdXNoIHN0YXR1cyBkdXJpbmcgcnVudGlt ZS1zdXNwZW5kIG1heSBiZSBub3QNCm5lY2Vzc2FyeS4NCg0KPiA+IA0KPiA+IEhvdyBhYm91dCBh IHBlcmlvZGljIGludGVydmFsIGNoZWNraW5nIG9mIGZsdXNoIHN0YXR1cyBpZiANCj4gPiBrZWVw X2N1cnJfZGV2X3B3cl9tb2RlIGV2YWx1YXRlcyB0byBiZSB0cnVlPw0KPiANCj4gVGhpcyBpcyBh IGdvb2QgcG9pbnQhDQo+IA0KPiBUaGUgc2FtZSB0aGluZyBhbHNvIGhhcHBlbnMgZm9yIGF1dG8t YmtvcHMuIEhvdyBhYm91dCBhZGQgYSB0aW1lciB0bw0KPiBsZWF2ZSBydW50aW1lIHN1c3BlbmQg aWYga2VlcF9jdXJyX2Rldl9wd3JfbW9kZSBpcyBzZXQgYXMgdHJ1ZT8gVGhpcyBpcw0KPiBzaW1w bGUgYW5kIGFsc28gZmF2b3JzIHBvd2VyLiBUaGUgdGltZW91dCB2YWx1ZSBjb3VsZCBiZSBhZGp1 c3RhYmxlDQo+IGFjY29yZGluZyB0byB0aGUgYXZhaWxhYmxlIFdyaXRlQm9vc3RlciBidWZmZXIg c2l6ZS4NCj4gDQo+IEEgcGVyaW9kaWMgaW50ZXJ2YWwgY2hlY2tpbmcgb2YgZmx1c2ggc3RhdHVz IG5lZWRzIHRvIHJlLWFjdGl2YXRlIGxpbmsNCj4gdG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgZGV2 aWNlLiBUaGlzIHdvdWxkIGJlIHRyaWNreSBhbmQgdGhlDQo+IHJlLWFjdGl2YXRpb24gZmxvdyBp cyBqdXN0IGxpa2UgcnVudGltZS1yZXN1bWUuDQo+IA0KPiBXaGF0IHdvdWxkIHlvdSB0aGluaz8N Cj4gDQo+IFRoYW5rcy4NCj4gU3RhbmxleSBDaHUNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMaW51eC1tZWRpYXRlayBtYWlsaW5n IGxpc3QNCj4gTGludXgtbWVkaWF0ZWtAbGlzdHMuaW5mcmFkZWFkLm9yZw0KPiBodHRwOi8vbGlz dHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW1lZGlhdGVrDQoNCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6533AC433E0 for ; Thu, 14 May 2020 14:59:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 31F05205CB for ; Thu, 14 May 2020 14:59:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VSAw6Qjt"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="asseTBgV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 31F05205CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lvOok6m9DOtd6SLcQfWnW0Q2M68CUw/L0IsF/p10y1I=; b=VSAw6QjtMAH4qt Y5P/IZrusCWAGLpZ7ymWDv84SZwTldlpceHHpUuv3jJOyiekmf4TIPtszl5DmXUZ3ziRbAP/ga9Ai rIqDpBh2rQ6lVB0pZKQDoDHL5ErMjFsLuFUbNo1jMLaQXnPk3Co9QXcANSKlPgN4ZyeuyayiCT/rz /T4taNzG8zydbI7sbyeEsOPD2kZcLyu/EHlVYZ91QQFM0G/ooLSEXbZlKu2kJCbSWjGdC8mamBku/ XVVJZYc3kRCQVj3C9oW5qzdYdLzDYJYAhLBZJskRGSdSRiR7QHHHvmKINrYpleLtuB3rZYUT91lGe kOZCEKQY8bUC96YSP+kw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZFKt-0003Pl-JM; Thu, 14 May 2020 14:59:47 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZFKp-0003ME-DK; Thu, 14 May 2020 14:59:47 +0000 X-UUID: c9d63fa0fc8146e2b2432f1cd24697ae-20200514 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=uTJlwni3Pyu0Wbuq7O34MNOI0GdhWDymx/mWX/Hdhgg=; b=asseTBgVOYdMFIYoaAJFVhAnJ+oZ7vYlIOPdkz8Ld0LmDnGsm7R46lnq4it5Ylpo01q6dSM02yJW1w+DD5bjnU+PpjsB6eGRp6IX9RJ/3EkPOPmmPPvcA+wZNkMBFJcZf8aFkXuWYHC6Eu79rBJNjSAHxYHttLuHSAQAkSkLg90=; X-UUID: c9d63fa0fc8146e2b2432f1cd24697ae-20200514 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 506614466; Thu, 14 May 2020 06:59:40 -0800 Received: from MTKMBS02N2.mediatek.inc (172.21.101.101) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 07:49:35 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 22:49:23 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 14 May 2020 22:49:23 +0800 Message-ID: <1589467766.3197.100.camel@mtkswgap22> Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend From: Stanley Chu To: "Asutosh Das (asd)" Date: Thu, 14 May 2020 22:49:26 +0800 In-Reply-To: <1589423030.3197.94.camel@mtkswgap22> References: <20200512104750.8711-1-stanley.chu@mediatek.com> <20200512104750.8711-5-stanley.chu@mediatek.com> <725d057c-2379-710e-287f-ac11a59c08bc@codeaurora.org> <1589423030.3197.94.camel@mtkswgap22> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: 4780976ACDCE7F1FDB5960240E507B019A505AEB464268F722DFBF7EFC13B6632000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200514_075943_459627_27E7268B X-CRM114-Status: GOOD ( 31.97 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-scsi@vger.kernel.org" , "martin.petersen@oracle.com" , "Andy Teng \($B{}G!9\(\(B\)" , "jejb@linux.ibm.com" , Chun-Hung Wu =?UTF-8?Q?=28=E5=B7=AB=E9=A7=BF=E5=AE=8F=29?= , Kuohong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=9C=8B=E9=B4=BB=29?= , "linux-kernel@vger.kernel.org" , "avri.altman@wdc.com" , "cang@codeaurora.org" , "linux-mediatek@lists.infradead.org" , Peter Wang =?UTF-8?Q?=28=E7=8E=8B=E4=BF=A1=E5=8F=8B=29?= , "alim.akhtar@samsung.com" , "matthias.bgg@gmail.com" , "beanhuo@micron.com" , "linux-arm-kernel@lists.infradead.org" , "bvanassche@acm.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi Asutosh, On Thu, 2020-05-14 at 10:23 +0800, Stanley Chu wrote: > Hi Asutosh, > > On Wed, 2020-05-13 at 12:31 -0700, Asutosh Das (asd) wrote: > > On 5/12/2020 3:47 AM, Stanley Chu wrote: > > > Currently UFS host driver promises VCC supply if UFS device > > > needs to do WriteBooster flush during runtime suspend. > > > > > > However the UFS specification mentions, > > > > > > "While the flushing operation is in progress, the device is > > > in Active power mode." > > > > > > Therefore UFS host driver needs to promise more: Keep UFS > > > device as "Active power mode", otherwise UFS device shall not > > > do any flush if device enters Sleep or PowerDown power mode. > > > > > > Fix this by not changing device power mode if WriteBooster > > > flush is required in ufshcd_suspend(). > > > > > > Signed-off-by: Stanley Chu > > > --- > > > drivers/scsi/ufs/ufs.h | 1 - > > > drivers/scsi/ufs/ufshcd.c | 39 +++++++++++++++++++-------------------- > > > 2 files changed, 19 insertions(+), 21 deletions(-) > > > > > > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h > > > index b3135344ab3f..9e4bc2e97ada 100644 > > > --- a/drivers/scsi/ufs/ufs.h > > > +++ b/drivers/scsi/ufs/ufs.h > > > @@ -577,7 +577,6 @@ struct ufs_dev_info { > > > u32 d_ext_ufs_feature_sup; > > > u8 b_wb_buffer_type; > > > u32 d_wb_alloc_units; > > > - bool keep_vcc_on; > > > u8 b_presrv_uspc_en; > > > }; > > > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > > index 169a3379e468..2d0aff8ac260 100644 > > > --- a/drivers/scsi/ufs/ufshcd.c > > > +++ b/drivers/scsi/ufs/ufshcd.c > > > @@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba) > > > !hba->dev_info.is_lu_power_on_wp) { > > > ufshcd_setup_vreg(hba, false); > > > } else if (!ufshcd_is_ufs_dev_active(hba)) { > > > - if (!hba->dev_info.keep_vcc_on) > > > - ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false); > > > + ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false); > > > if (!ufshcd_is_link_active(hba)) { > > > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq); > > > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2); > > > @@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) > > > enum ufs_pm_level pm_lvl; > > > enum ufs_dev_pwr_mode req_dev_pwr_mode; > > > enum uic_link_state req_link_state; > > > + bool keep_curr_dev_pwr_mode = false; > > > > > > hba->pm_op_in_progress = 1; > > > if (!ufshcd_is_shutdown_pm(pm_op)) { > > > @@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) > > > /* make sure that auto bkops is disabled */ > > > ufshcd_disable_auto_bkops(hba); > > > } > > > + > > Unnecessary newline, perhaps? > > Yap, I will remove it in next version. > > > > /* > > > - * With wb enabled, if the bkops is enabled or if the > > > - * configured WB type is 70% full, keep vcc ON > > > - * for the device to flush the wb buffer > > > + * If device needs to do BKOP or WB buffer flush, keep device > > > + * power mode as "active power mode" and its VCC supply. > > > */ > > > - if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) || > > > - ufshcd_wb_keep_vcc_on(hba)) > > > - hba->dev_info.keep_vcc_on = true; > > > - else > > > - hba->dev_info.keep_vcc_on = false; > > > - } else { > > > - hba->dev_info.keep_vcc_on = false; > > > + keep_curr_dev_pwr_mode = hba->auto_bkops_enabled || > > > + ufshcd_wb_keep_vcc_on(hba); > > Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops? > > > > Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush > > on hibern8 is enabled and the link is being put to hibern8 mode during > > runtime-suspend? Perhaps that should also be factored in here? > > Both auto-bkops and WriteBooster flush during Hibern8 need device power > mode to be "Active Power Mode". > > For auto-bkops, the spec mentions, > > "If the background operations enable bit is set and the device is in > Active power mode or Idle power mode, then the device is allowed to > execute any internal operations." > > For WriteBooster flush during Hibern8, the spec mentions, > > "While the flushing operation is in progress, the device is in Active > power mode." > > Therefore here we can use an unified "keep_curr_dev_pwr_mode" to > indicate the same requirements of above both features. > > Besides, both operations may access flash array inside UFS device thus > VCC supply shall be also kept. > > Before this patch, the original code will keep device power mode (stay > in Active Power Mode) if hba->auto_bkops_enabled is set as true during > runtime-suspend with UFSHCD_CAP_AUTO_BKOPS_SUSPEND capability is > enabled. This patch will not change this decision, just add > "WriteBooster flush during Hibern8" feature as another condition to do > so. > > Thank you so much to remind me that "Link shall be put in Hibern8" is a > necessary condition for "WriteBooster flush during Hibern8". I will add > more checking for keep_curr_dev_pwr_mode to prevent unnecessary power > drain. > > > > } > > > > > > - if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) && > > > - ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) || > > > - !ufshcd_is_runtime_pm(pm_op))) { > > > - /* ensure that bkops is disabled */ > > > - ufshcd_disable_auto_bkops(hba); > > > - ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode); > > > - if (ret) > > > - goto enable_gating; > > > + if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) { > > > + if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) || > > > + !ufshcd_is_runtime_pm(pm_op)) { > > > + /* ensure that bkops is disabled */ > > > + ufshcd_disable_auto_bkops(hba); > > > + } > > > + > > > + if (!keep_curr_dev_pwr_mode) { > > > + ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode); > > > > Now, when the WB buffer is completely flushed out, the device should be > > put back into UFS_SLEEP_PWR_MODE or UFS_POWERDOWN_PWR_MODE. Say, the > > device buffer has to be flushed and during runtime-suspend, the device > > is put to UFS_ACTIVE_PWR_MODE and Vcc is kept ON; the device doesn't > > resume nor does the system enters suspend for a very long time, and with > > AH8 and hibern8 disabled, there will be an unnecessary power drain for > > that much time. Another thought is that if keep_curr_dev_pwr_mode will be set as true only if link is put in Hibern8 or Auto-Hibern8 is enabled. By this way, the power consumption shall be very small after flush or auto-bkop is finished. Then the checking of flush status during runtime-suspend may be not necessary. > > > > How about a periodic interval checking of flush status if > > keep_curr_dev_pwr_mode evaluates to be true? > > This is a good point! > > The same thing also happens for auto-bkops. How about add a timer to > leave runtime suspend if keep_curr_dev_pwr_mode is set as true? This is > simple and also favors power. The timeout value could be adjustable > according to the available WriteBooster buffer size. > > A periodic interval checking of flush status needs to re-activate link > to communicate with the device. This would be tricky and the > re-activation flow is just like runtime-resume. > > What would you think? > > Thanks. > Stanley Chu > > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ Linux-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED, USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B32CC433DF for ; Thu, 14 May 2020 14:59:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EC4A0205CB for ; Thu, 14 May 2020 14:59:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="SyFOPD/e"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="asseTBgV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EC4A0205CB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=WKeQQgrsAzw8H7rHkeGLzNE1AvQr4GR9LB9V8JwkSKs=; b=SyFOPD/egOVoaJ Mk3tl/rd3AjZsB3AMfMkgPodcceC5aZOnc1zZHtrTAcotTF/ibk1XAF5Eg9xNl+JIF//t3r/h7pq/ uAd+kh3rEiBTfZ3WY32kW78KF2SBdK08z1Ed6g358Av2slnspMbH4x/lQbXOv0/TBacFnf0uOxAt1 TJMMstm1wQzViBVadXnOKltFaEUWQVnFk5ghuEbcPVY5ynm4MKqBG5z5IkP8KYTs/zNNQ1uEotfkJ Hojgd9fxMOCKITBOIR9QzyK63zOz4q6y8gKEhP22AIblhKo5OdGUtiitza3wXF+js/8oxnkOXlXOv vvX1/5kBUSq79t136y2Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZFKu-0003Qw-Hk; Thu, 14 May 2020 14:59:48 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZFKp-0003ME-DK; Thu, 14 May 2020 14:59:47 +0000 X-UUID: c9d63fa0fc8146e2b2432f1cd24697ae-20200514 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Transfer-Encoding:MIME-Version:Content-Type:References:In-Reply-To:Date:CC:To:From:Subject:Message-ID; bh=uTJlwni3Pyu0Wbuq7O34MNOI0GdhWDymx/mWX/Hdhgg=; b=asseTBgVOYdMFIYoaAJFVhAnJ+oZ7vYlIOPdkz8Ld0LmDnGsm7R46lnq4it5Ylpo01q6dSM02yJW1w+DD5bjnU+PpjsB6eGRp6IX9RJ/3EkPOPmmPPvcA+wZNkMBFJcZf8aFkXuWYHC6Eu79rBJNjSAHxYHttLuHSAQAkSkLg90=; X-UUID: c9d63fa0fc8146e2b2432f1cd24697ae-20200514 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 506614466; Thu, 14 May 2020 06:59:40 -0800 Received: from MTKMBS02N2.mediatek.inc (172.21.101.101) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 07:49:35 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 22:49:23 +0800 Received: from [172.21.77.33] (172.21.77.33) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Thu, 14 May 2020 22:49:23 +0800 Message-ID: <1589467766.3197.100.camel@mtkswgap22> Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend From: Stanley Chu To: "Asutosh Das (asd)" Date: Thu, 14 May 2020 22:49:26 +0800 In-Reply-To: <1589423030.3197.94.camel@mtkswgap22> References: <20200512104750.8711-1-stanley.chu@mediatek.com> <20200512104750.8711-5-stanley.chu@mediatek.com> <725d057c-2379-710e-287f-ac11a59c08bc@codeaurora.org> <1589423030.3197.94.camel@mtkswgap22> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: 4780976ACDCE7F1FDB5960240E507B019A505AEB464268F722DFBF7EFC13B6632000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200514_075943_459627_27E7268B X-CRM114-Status: GOOD ( 31.97 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-scsi@vger.kernel.org" , "martin.petersen@oracle.com" , "Andy Teng \($B{}G!9\(\(B\)" , "jejb@linux.ibm.com" , Chun-Hung Wu =?UTF-8?Q?=28=E5=B7=AB=E9=A7=BF=E5=AE=8F=29?= , Kuohong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=9C=8B=E9=B4=BB=29?= , "linux-kernel@vger.kernel.org" , "avri.altman@wdc.com" , "cang@codeaurora.org" , "linux-mediatek@lists.infradead.org" , Peter Wang =?UTF-8?Q?=28=E7=8E=8B=E4=BF=A1=E5=8F=8B=29?= , "alim.akhtar@samsung.com" , "matthias.bgg@gmail.com" , "beanhuo@micron.com" , "linux-arm-kernel@lists.infradead.org" , "bvanassche@acm.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Asutosh, On Thu, 2020-05-14 at 10:23 +0800, Stanley Chu wrote: > Hi Asutosh, > > On Wed, 2020-05-13 at 12:31 -0700, Asutosh Das (asd) wrote: > > On 5/12/2020 3:47 AM, Stanley Chu wrote: > > > Currently UFS host driver promises VCC supply if UFS device > > > needs to do WriteBooster flush during runtime suspend. > > > > > > However the UFS specification mentions, > > > > > > "While the flushing operation is in progress, the device is > > > in Active power mode." > > > > > > Therefore UFS host driver needs to promise more: Keep UFS > > > device as "Active power mode", otherwise UFS device shall not > > > do any flush if device enters Sleep or PowerDown power mode. > > > > > > Fix this by not changing device power mode if WriteBooster > > > flush is required in ufshcd_suspend(). > > > > > > Signed-off-by: Stanley Chu > > > --- > > > drivers/scsi/ufs/ufs.h | 1 - > > > drivers/scsi/ufs/ufshcd.c | 39 +++++++++++++++++++-------------------- > > > 2 files changed, 19 insertions(+), 21 deletions(-) > > > > > > diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h > > > index b3135344ab3f..9e4bc2e97ada 100644 > > > --- a/drivers/scsi/ufs/ufs.h > > > +++ b/drivers/scsi/ufs/ufs.h > > > @@ -577,7 +577,6 @@ struct ufs_dev_info { > > > u32 d_ext_ufs_feature_sup; > > > u8 b_wb_buffer_type; > > > u32 d_wb_alloc_units; > > > - bool keep_vcc_on; > > > u8 b_presrv_uspc_en; > > > }; > > > > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c > > > index 169a3379e468..2d0aff8ac260 100644 > > > --- a/drivers/scsi/ufs/ufshcd.c > > > +++ b/drivers/scsi/ufs/ufshcd.c > > > @@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba) > > > !hba->dev_info.is_lu_power_on_wp) { > > > ufshcd_setup_vreg(hba, false); > > > } else if (!ufshcd_is_ufs_dev_active(hba)) { > > > - if (!hba->dev_info.keep_vcc_on) > > > - ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false); > > > + ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false); > > > if (!ufshcd_is_link_active(hba)) { > > > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq); > > > ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2); > > > @@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) > > > enum ufs_pm_level pm_lvl; > > > enum ufs_dev_pwr_mode req_dev_pwr_mode; > > > enum uic_link_state req_link_state; > > > + bool keep_curr_dev_pwr_mode = false; > > > > > > hba->pm_op_in_progress = 1; > > > if (!ufshcd_is_shutdown_pm(pm_op)) { > > > @@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum ufs_pm_op pm_op) > > > /* make sure that auto bkops is disabled */ > > > ufshcd_disable_auto_bkops(hba); > > > } > > > + > > Unnecessary newline, perhaps? > > Yap, I will remove it in next version. > > > > /* > > > - * With wb enabled, if the bkops is enabled or if the > > > - * configured WB type is 70% full, keep vcc ON > > > - * for the device to flush the wb buffer > > > + * If device needs to do BKOP or WB buffer flush, keep device > > > + * power mode as "active power mode" and its VCC supply. > > > */ > > > - if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) || > > > - ufshcd_wb_keep_vcc_on(hba)) > > > - hba->dev_info.keep_vcc_on = true; > > > - else > > > - hba->dev_info.keep_vcc_on = false; > > > - } else { > > > - hba->dev_info.keep_vcc_on = false; > > > + keep_curr_dev_pwr_mode = hba->auto_bkops_enabled || > > > + ufshcd_wb_keep_vcc_on(hba); > > Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops? > > > > Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush > > on hibern8 is enabled and the link is being put to hibern8 mode during > > runtime-suspend? Perhaps that should also be factored in here? > > Both auto-bkops and WriteBooster flush during Hibern8 need device power > mode to be "Active Power Mode". > > For auto-bkops, the spec mentions, > > "If the background operations enable bit is set and the device is in > Active power mode or Idle power mode, then the device is allowed to > execute any internal operations." > > For WriteBooster flush during Hibern8, the spec mentions, > > "While the flushing operation is in progress, the device is in Active > power mode." > > Therefore here we can use an unified "keep_curr_dev_pwr_mode" to > indicate the same requirements of above both features. > > Besides, both operations may access flash array inside UFS device thus > VCC supply shall be also kept. > > Before this patch, the original code will keep device power mode (stay > in Active Power Mode) if hba->auto_bkops_enabled is set as true during > runtime-suspend with UFSHCD_CAP_AUTO_BKOPS_SUSPEND capability is > enabled. This patch will not change this decision, just add > "WriteBooster flush during Hibern8" feature as another condition to do > so. > > Thank you so much to remind me that "Link shall be put in Hibern8" is a > necessary condition for "WriteBooster flush during Hibern8". I will add > more checking for keep_curr_dev_pwr_mode to prevent unnecessary power > drain. > > > > } > > > > > > - if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) && > > > - ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) || > > > - !ufshcd_is_runtime_pm(pm_op))) { > > > - /* ensure that bkops is disabled */ > > > - ufshcd_disable_auto_bkops(hba); > > > - ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode); > > > - if (ret) > > > - goto enable_gating; > > > + if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) { > > > + if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) || > > > + !ufshcd_is_runtime_pm(pm_op)) { > > > + /* ensure that bkops is disabled */ > > > + ufshcd_disable_auto_bkops(hba); > > > + } > > > + > > > + if (!keep_curr_dev_pwr_mode) { > > > + ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode); > > > > Now, when the WB buffer is completely flushed out, the device should be > > put back into UFS_SLEEP_PWR_MODE or UFS_POWERDOWN_PWR_MODE. Say, the > > device buffer has to be flushed and during runtime-suspend, the device > > is put to UFS_ACTIVE_PWR_MODE and Vcc is kept ON; the device doesn't > > resume nor does the system enters suspend for a very long time, and with > > AH8 and hibern8 disabled, there will be an unnecessary power drain for > > that much time. Another thought is that if keep_curr_dev_pwr_mode will be set as true only if link is put in Hibern8 or Auto-Hibern8 is enabled. By this way, the power consumption shall be very small after flush or auto-bkop is finished. Then the checking of flush status during runtime-suspend may be not necessary. > > > > How about a periodic interval checking of flush status if > > keep_curr_dev_pwr_mode evaluates to be true? > > This is a good point! > > The same thing also happens for auto-bkops. How about add a timer to > leave runtime suspend if keep_curr_dev_pwr_mode is set as true? This is > simple and also favors power. The timeout value could be adjustable > according to the available WriteBooster buffer size. > > A periodic interval checking of flush status needs to re-activate link > to communicate with the device. This would be tricky and the > re-activation flow is just like runtime-resume. > > What would you think? > > Thanks. > Stanley Chu > > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel