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.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 9CBB9C2D0F6 for ; Wed, 13 May 2020 02:21:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6C4C720714 for ; Wed, 13 May 2020 02:21:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="MofD5KKp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728740AbgEMCVQ (ORCPT ); Tue, 12 May 2020 22:21:16 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:15849 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1728056AbgEMCVQ (ORCPT ); Tue, 12 May 2020 22:21:16 -0400 X-UUID: 05b6ab5c543b4fe6b82e34aafd627e20-20200513 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=FEa8S57yUP1uBt7sF+Iuhy7qLD+6bZVqAcdAPC8F9JE=; b=MofD5KKpO/m36BxdJRtjBzFkVHXb10wjpOslr9htC/NJWkvKVnPxstr/NMHx1QQyZstkHJ6vrNnLLJbsI9xXEwU81tlcEMmeGf8AlA4Tm+Rq7ynThQR/0wtp2gtWsshF2uOdPC3ZvSK8sOknIW9FGMpNifr1QpbN1tSpMcgPaig=; X-UUID: 05b6ab5c543b4fe6b82e34aafd627e20-20200513 Received: from mtkcas06.mediatek.inc [(172.21.101.30)] by mailgw02.mediatek.com (envelope-from ) (Cellopoint E-mail Firewall v4.1.10 Build 0809 with TLS) with ESMTP id 2030145763; Wed, 13 May 2020 10:21:10 +0800 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 10:21:03 +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; Wed, 13 May 2020 10:21:03 +0800 Message-ID: <1589336464.3197.68.camel@mtkswgap22> Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend From: Stanley Chu To: "Asutosh Das (asd)" CC: , , , , , , , , , , , , , , , Date: Wed, 13 May 2020 10:21:04 +0800 In-Reply-To: <3740c6fa-77f1-53eb-ec8e-8f9d09f2646f@codeaurora.org> References: <20200512104750.8711-1-stanley.chu@mediatek.com> <20200512104750.8711-5-stanley.chu@mediatek.com> <3740c6fa-77f1-53eb-ec8e-8f9d09f2646f@codeaurora.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 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 SGkgQXN1dG9zaCwNCg0KT24gVHVlLCAyMDIwLTA1LTEyIGF0IDEwOjA0IC0wNzAwLCBBc3V0b3No IERhcyAoYXNkKSB3cm90ZToNCj4gSGkgU3RhbmxleSwNCj4gDQo+IE9uIDUvMTIvMjAyMCAzOjQ3 IEFNLCBTdGFubGV5IENodSB3cm90ZToNCj4gPiBDdXJyZW50bHkgVUZTIGhvc3QgZHJpdmVyIHBy b21pc2VzIFZDQyBzdXBwbHkgaWYgVUZTIGRldmljZQ0KPiA+IG5lZWRzIHRvIGRvIFdyaXRlQm9v c3RlciBmbHVzaCBkdXJpbmcgcnVudGltZSBzdXNwZW5kLg0KPiA+IA0KPiA+IEhvd2V2ZXIgdGhl IFVGUyBzcGVjaWZpY2F0aW9uIG1lbnRpb25zLA0KPiA+IA0KPiA+ICJXaGlsZSB0aGUgZmx1c2hp bmcgb3BlcmF0aW9uIGlzIGluIHByb2dyZXNzLCB0aGUgZGV2aWNlIGlzDQo+ID4gaW4gQWN0aXZl IHBvd2VyIG1vZGUuIg0KPiA+IA0KPiA+IFRoZXJlZm9yZSBVRlMgaG9zdCBkcml2ZXIgbmVlZHMg dG8gcHJvbWlzZSBtb3JlOiBLZWVwIFVGUw0KPiA+IGRldmljZSBhcyAiQWN0aXZlIHBvd2VyIG1v ZGUiLCBvdGhlcndpc2UgVUZTIGRldmljZSBzaGFsbCBub3QNCj4gPiBkbyBhbnkgZmx1c2ggaWYg ZGV2aWNlIGVudGVycyBTbGVlcCBvciBQb3dlckRvd24gcG93ZXIgbW9kZS4NCj4gPiANCj4gPiBG aXggdGhpcyBieSBub3QgY2hhbmdpbmcgZGV2aWNlIHBvd2VyIG1vZGUgaWYgV3JpdGVCb29zdGVy DQo+ID4gZmx1c2ggaXMgcmVxdWlyZWQgaW4gdWZzaGNkX3N1c3BlbmQoKS4NCj4gPiANCj4gPiBT aWduZWQtb2ZmLWJ5OiBTdGFubGV5IENodSA8c3RhbmxleS5jaHVAbWVkaWF0ZWsuY29tPg0KPiA+ IC0tLQ0KPiA+ICAgZHJpdmVycy9zY3NpL3Vmcy91ZnMuaCAgICB8ICAxIC0NCj4gPiAgIGRyaXZl cnMvc2NzaS91ZnMvdWZzaGNkLmMgfCAzOSArKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPiAgIDIgZmlsZXMgY2hhbmdlZCwgMTkgaW5zZXJ0aW9ucygrKSwgMjEgZGVs ZXRpb25zKC0pDQo+ID4gDQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvc2NzaS91ZnMvdWZzLmgg Yi9kcml2ZXJzL3Njc2kvdWZzL3Vmcy5oDQo+ID4gaW5kZXggYjMxMzUzNDRhYjNmLi45ZTRiYzJl OTdhZGEgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9zY3NpL3Vmcy91ZnMuaA0KPiA+ICsrKyBi L2RyaXZlcnMvc2NzaS91ZnMvdWZzLmgNCj4gPiBAQCAtNTc3LDcgKzU3Nyw2IEBAIHN0cnVjdCB1 ZnNfZGV2X2luZm8gew0KPiA+ICAgCXUzMiBkX2V4dF91ZnNfZmVhdHVyZV9zdXA7DQo+ID4gICAJ dTggYl93Yl9idWZmZXJfdHlwZTsNCj4gPiAgIAl1MzIgZF93Yl9hbGxvY191bml0czsNCj4gPiAt CWJvb2wga2VlcF92Y2Nfb247DQo+ID4gICAJdTggYl9wcmVzcnZfdXNwY19lbjsNCj4gPiAgIH07 DQo+ID4gICANCj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9zY3NpL3Vmcy91ZnNoY2QuYyBiL2Ry aXZlcnMvc2NzaS91ZnMvdWZzaGNkLmMNCj4gPiBpbmRleCAxNjlhMzM3OWU0NjguLjJkMGFmZjhh YzI2MCAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL3Njc2kvdWZzL3Vmc2hjZC5jDQo+ID4gKysr IGIvZHJpdmVycy9zY3NpL3Vmcy91ZnNoY2QuYw0KPiA+IEBAIC04MTAxLDggKzgxMDEsNyBAQCBz dGF0aWMgdm9pZCB1ZnNoY2RfdnJlZ19zZXRfbHBtKHN0cnVjdCB1ZnNfaGJhICpoYmEpDQo+ID4g ICAJICAgICFoYmEtPmRldl9pbmZvLmlzX2x1X3Bvd2VyX29uX3dwKSB7DQo+ID4gICAJCXVmc2hj ZF9zZXR1cF92cmVnKGhiYSwgZmFsc2UpOw0KPiA+ICAgCX0gZWxzZSBpZiAoIXVmc2hjZF9pc191 ZnNfZGV2X2FjdGl2ZShoYmEpKSB7DQo+ID4gLQkJaWYgKCFoYmEtPmRldl9pbmZvLmtlZXBfdmNj X29uKQ0KPiA+IC0JCQl1ZnNoY2RfdG9nZ2xlX3ZyZWcoaGJhLT5kZXYsIGhiYS0+dnJlZ19pbmZv LnZjYywgZmFsc2UpOw0KPiA+ICsJCXVmc2hjZF90b2dnbGVfdnJlZyhoYmEtPmRldiwgaGJhLT52 cmVnX2luZm8udmNjLCBmYWxzZSk7DQo+ID4gICAJCWlmICghdWZzaGNkX2lzX2xpbmtfYWN0aXZl KGhiYSkpIHsNCj4gPiAgIAkJCXVmc2hjZF9jb25maWdfdnJlZ19scG0oaGJhLCBoYmEtPnZyZWdf aW5mby52Y2NxKTsNCj4gPiAgIAkJCXVmc2hjZF9jb25maWdfdnJlZ19scG0oaGJhLCBoYmEtPnZy ZWdfaW5mby52Y2NxMik7DQo+ID4gQEAgLTgxNzIsNiArODE3MSw3IEBAIHN0YXRpYyBpbnQgdWZz aGNkX3N1c3BlbmQoc3RydWN0IHVmc19oYmEgKmhiYSwgZW51bSB1ZnNfcG1fb3AgcG1fb3ApDQo+ ID4gICAJZW51bSB1ZnNfcG1fbGV2ZWwgcG1fbHZsOw0KPiA+ICAgCWVudW0gdWZzX2Rldl9wd3Jf bW9kZSByZXFfZGV2X3B3cl9tb2RlOw0KPiA+ICAgCWVudW0gdWljX2xpbmtfc3RhdGUgcmVxX2xp bmtfc3RhdGU7DQo+ID4gKwlib29sIGtlZXBfY3Vycl9kZXZfcHdyX21vZGUgPSBmYWxzZTsNCj4g PiAgIA0KPiA+ICAgCWhiYS0+cG1fb3BfaW5fcHJvZ3Jlc3MgPSAxOw0KPiA+ICAgCWlmICghdWZz aGNkX2lzX3NodXRkb3duX3BtKHBtX29wKSkgew0KPiA+IEBAIC04MjI2LDI4ICs4MjI2LDI3IEBA IHN0YXRpYyBpbnQgdWZzaGNkX3N1c3BlbmQoc3RydWN0IHVmc19oYmEgKmhiYSwgZW51bSB1ZnNf cG1fb3AgcG1fb3ApDQo+ID4gICAJCQkvKiBtYWtlIHN1cmUgdGhhdCBhdXRvIGJrb3BzIGlzIGRp c2FibGVkICovDQo+ID4gICAJCQl1ZnNoY2RfZGlzYWJsZV9hdXRvX2Jrb3BzKGhiYSk7DQo+ID4g ICAJCX0NCj4gPiArDQo+ID4gICAJCS8qDQo+ID4gLQkJICogV2l0aCB3YiBlbmFibGVkLCBpZiB0 aGUgYmtvcHMgaXMgZW5hYmxlZCBvciBpZiB0aGUNCj4gPiAtCQkgKiBjb25maWd1cmVkIFdCIHR5 cGUgaXMgNzAlIGZ1bGwsIGtlZXAgdmNjIE9ODQo+ID4gLQkJICogZm9yIHRoZSBkZXZpY2UgdG8g Zmx1c2ggdGhlIHdiIGJ1ZmZlcg0KPiA+ICsJCSAqIElmIGRldmljZSBuZWVkcyB0byBkbyBCS09Q IG9yIFdCIGJ1ZmZlciBmbHVzaCwga2VlcCBkZXZpY2UNCj4gPiArCQkgKiBwb3dlciBtb2RlIGFz ICJhY3RpdmUgcG93ZXIgbW9kZSIgYW5kIGl0cyBWQ0Mgc3VwcGx5Lg0KPiA+ICAgCQkgKi8NCj4g PiAtCQlpZiAoKGhiYS0+YXV0b19ia29wc19lbmFibGVkICYmIHVmc2hjZF9pc193Yl9hbGxvd2Vk KGhiYSkpIHx8DQo+ID4gLQkJICAgIHVmc2hjZF93Yl9rZWVwX3ZjY19vbihoYmEpKQ0KPiA+IC0J CQloYmEtPmRldl9pbmZvLmtlZXBfdmNjX29uID0gdHJ1ZTsNCj4gPiAtCQllbHNlDQo+ID4gLQkJ CWhiYS0+ZGV2X2luZm8ua2VlcF92Y2Nfb24gPSBmYWxzZTsNCj4gPiAtCX0gZWxzZSB7DQo+ID4g LQkJaGJhLT5kZXZfaW5mby5rZWVwX3ZjY19vbiA9IGZhbHNlOw0KPiA+ICsJCWtlZXBfY3Vycl9k ZXZfcHdyX21vZGUgPSBoYmEtPmF1dG9fYmtvcHNfZW5hYmxlZCB8fA0KPiA+ICsJCQl1ZnNoY2Rf d2Jfa2VlcF92Y2Nfb24oaGJhKTsNCj4gPiAgIAl9DQo+ID4gICANCj4gPiAtCWlmICgocmVxX2Rl dl9wd3JfbW9kZSAhPSBoYmEtPmN1cnJfZGV2X3B3cl9tb2RlKSAmJg0KPiA+IC0JICAgICgodWZz aGNkX2lzX3J1bnRpbWVfcG0ocG1fb3ApICYmICFoYmEtPmF1dG9fYmtvcHNfZW5hYmxlZCkgfHwN Cj4gPiAtCSAgICAhdWZzaGNkX2lzX3J1bnRpbWVfcG0ocG1fb3ApKSkgew0KPiA+IC0JCS8qIGVu c3VyZSB0aGF0IGJrb3BzIGlzIGRpc2FibGVkICovDQo+ID4gLQkJdWZzaGNkX2Rpc2FibGVfYXV0 b19ia29wcyhoYmEpOw0KPiA+IC0JCXJldCA9IHVmc2hjZF9zZXRfZGV2X3B3cl9tb2RlKGhiYSwg cmVxX2Rldl9wd3JfbW9kZSk7DQo+ID4gLQkJaWYgKHJldCkNCj4gPiAtCQkJZ290byBlbmFibGVf Z2F0aW5nOw0KPiA+ICsJaWYgKHJlcV9kZXZfcHdyX21vZGUgIT0gaGJhLT5jdXJyX2Rldl9wd3Jf bW9kZSkgew0KPiA+ICsJCWlmICgodWZzaGNkX2lzX3J1bnRpbWVfcG0ocG1fb3ApICYmICFoYmEt PmF1dG9fYmtvcHNfZW5hYmxlZCkgfHwNCj4gPiArCQkgICAgIXVmc2hjZF9pc19ydW50aW1lX3Bt KHBtX29wKSkgew0KPiA+ICsJCQkvKiBlbnN1cmUgdGhhdCBia29wcyBpcyBkaXNhYmxlZCAqLw0K PiA+ICsJCQl1ZnNoY2RfZGlzYWJsZV9hdXRvX2Jrb3BzKGhiYSk7DQo+ID4gKwkJfQ0KPiA+ICsN Cj4gPiArCQlpZiAoIWtlZXBfY3Vycl9kZXZfcHdyX21vZGUpIHsNCj4gPiArCQkJcmV0ID0gdWZz aGNkX3NldF9kZXZfcHdyX21vZGUoaGJhLCByZXFfZGV2X3B3cl9tb2RlKTsNCj4gPiArCQkJaWYg KHJldCkNCj4gPiArCQkJCWdvdG8gZW5hYmxlX2dhdGluZzsNCj4gPiArCQl9DQo+ID4gICAJfQ0K PiA+ICAgDQo+ID4gICAJZmx1c2hfd29yaygmaGJhLT5lZWhfd29yayk7DQo+ID4gDQo+IA0KPiBD YW4geW91IHBsZWFzZSBjb25maXJtIHRoYXQgeW91J3ZlIHRlc3RlZCBhbmQgZm91bmQgdGhhdCB3 aXRoIHRoZSANCj4gcHJldmlvdXMgY29kZSwgdGhlIGZsdXNoIG9wZXJhdGlvbiBpbiB0aGUgZGV2 aWNlIHdhcyBub3QgaGFwcGVuaW5nLg0KPiANCj4gSWYgc28sIHBsZWFzZSBjYW4geW91IGxldCBt ZSBrbm93IHRoZSB0ZXN0LWNhc2UgdGhhdCB5b3UgcmFuIHRvIGZpZ3VyZSANCj4gdGhpcyBvdXQu DQo+IA0KPiBJJ2QgbGlrZSB0byB2ZXJpZnkgdGhpcyBhdCBteSBlbmQuDQoNClNvcnJ5IGN1cnJl bnRseSBJIGhhdmUgbm8gZWFzeSB0ZXN0IGNhc2VzIG9yIHNjcmlwdHMgYXZhaWxhYmxlLg0KDQpU byBwcmVjaXNlbHkgY29uZmlybSB0aGUgZmx1c2ggYmVoYXZpb3IgYnkgbG9ncywgSSBhZGRlZCBz b21lIGNvZGVzIHRvDQpxdWVyeSAiYXZhaWxhYmxlIFdyaXRlQm9vc3RlciBidWZmZXIiIGJlZm9y ZSBlbnRlcmluZyBydW50aW1lIHN1c3BlbmQNCmFuZCBhZnRlciBsZWF2aW5nIHJ1bnRpbWUgcmVz dW1lLCBhbmQgb2JzZXJ2ZSB0aGUgdHJlbmQgb2YgYXZhaWxhYmxlDQpXcml0ZUJvb3N0ZXIgYnVm ZmVyLg0KDQpNeSB0ZXN0IHN0ZXBzIGFyZSBhcyBiZWxvdywNCg0KMS4gQ3JlYXRlIGEgd3JpdGVy IHRvIHdyaXRlIGxhcmdlIGRhdGEgaW4gYSBzaG9ydCB0aW1lIHRvIGZpbGwtaW4NCldyaXRlQm9v c3RlciBidWZmZXIuDQoNCjIuIERvIHNvbWV0aGluZyB0byBwcmV2ZW50IHN5c3RlbSBzdXNwZW5k DQoNCjMuIERvIHNvbWV0aGluZyB0byBwcmV2ZW50IGxpbmsgZW50ZXJpbmcgSGliZXJuOCwgZm9y IGV4YW1wbGUsIGRpc2FibGUNCkF1dG8tSGliZXJuOCBhbmQgZGlzYWJsZSBIaWJlcm44IGR1cmlu ZyBjbG9jayBnYXRpbmcuIEJlY2F1c2UgdGhlDQpIaWJlcm44IHBlcmlvZCBiZWZvcmUgcnVudGlt ZS1zdXNwZW5kIGlzIGtub3duIHRoYXQgVkNDIGlzIHByb3ZpZGVkIGFuZA0KZGV2aWNlIGNhbiBm bHVzaCBXcml0ZUJvb3N0ZXIgYnVmZmVyIGlmICJGbHVzaCBEdXJpbmcgSDgiIGlzIGVuYWJsZWQg YXMNCnVwc3RyZWFtIGtlcm5lbCBjdXJyZW50bHkuDQoNCjQuIFNocmluayB0aGUgcnVudGltZSBz dXNwZW5kIGRlbGF5IChtYXliZSAxMDBtcyB+IDIwMG1zKSB0byBtYWtlDQpydW50aW1lIHN1c3Bl bmQgaGFwcGVuIGVhcmxpZXIuDQoNCjUuIEFmdGVyICJhdmFpbGFibGUgV3JpdGVCb3NvdGVyIGJ1 ZmZlciIgcmVhY2hlcyBsb3dlci1sZXZlbCwgZm9yDQpleGFtcGxlLCAxMCUsIHN0b3AgdGhlIHdy aXRlci4NCg0KNi4gT2JzZXJ2ZSB0aGUgdHJlbmQgb2YgV3JpdGVCb29zdGVyIGF2YWlsYWJsZSBi dWZmZXIuDQoNCg0KSW4gdGhlIHByZXZpb3VzIGNvZGUsIHRoZSBhdmFpbGFibGUgV3JpdGVCb29z dGVyIGJ1ZmZlciBpcyBpbmNyZWFzZWQNCnZlcnkgdmVyeSBzbG93bHkuIEVzcGVjaWFsbHkgbm8g aW5jcmVhc2luZyBpcyBvYnNlcnZlZCBkdXJpbmcNCnJ1bnRpbWUtc3VzcGVuZC4NCg0KQWZ0ZXIg YXBwbHlpbmcgdGhpcyBmaXgsIHRoZSBhdmFpbGFibGUgV3JpdGVCb29zdGVyIGJ1ZmZlciBpcyBp bmNyZWFzZWQNCm11Y2ggZmFzdGVyIGFuZCB0aGUgaW5jcmVhc2luZyBjYW4gYmUgZWFzaWx5IG9i c2VydmVkIGR1cmluZw0KcnVudGltZS1zdXNwZW5kLg0KDQpUaGFua3MsDQpTdGFubGV5IENodQ0K DQo+IA0KPiAtLQ0KPiBUaGFua3MsDQo+IC1hc2QNCj4gDQoNCg== 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.4 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 5D33AC2D0F6 for ; Wed, 13 May 2020 02:31:34 +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 2E072206F5 for ; Wed, 13 May 2020 02:31:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mXmsrcmt"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="MofD5KKp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2E072206F5 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=o3zVRixJhE/RBLc2Nj0F+IyPne+tNP+EiE3+MgJzshs=; b=mXmsrcmt3LKYcF FNdWdnMzJwE9QgpMOVxq7lhyYVvx036JGXogKUIgHtpmso/N5PYqb6Zl5kQE4ePr5nip7sFN5t5ay f5gTPDA9NKUfKhQ9PyJLxlIU9LYqzI0JcLgJBk1YwvMSBAbOjSedV4GVFehGVughzCENn1l81UKyY cYdrxZOc3JEIzjVy2NORyNknVaGraBNO7Qoxp+OtX5BGP4x3HhBJMAMAqxSFJL6RXwnXVSoz2gXQ0 PA/NUrwkhBDKyerI9VKX5QdKvc+EDWn9hAkNyq6A9NCkJ233CJ6/aWGCJHwz1B2BH5EKFUePX7GjS s1wLWdr0S6smSfzraSEA==; 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 1jYhB3-0007mf-FW; Wed, 13 May 2020 02:31:21 +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 1jYhAu-0007f4-GA; Wed, 13 May 2020 02:31:14 +0000 X-UUID: 88141e78cbf8460eab5af47c368b7656-20200512 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=FEa8S57yUP1uBt7sF+Iuhy7qLD+6bZVqAcdAPC8F9JE=; b=MofD5KKpO/m36BxdJRtjBzFkVHXb10wjpOslr9htC/NJWkvKVnPxstr/NMHx1QQyZstkHJ6vrNnLLJbsI9xXEwU81tlcEMmeGf8AlA4Tm+Rq7ynThQR/0wtp2gtWsshF2uOdPC3ZvSK8sOknIW9FGMpNifr1QpbN1tSpMcgPaig=; X-UUID: 88141e78cbf8460eab5af47c368b7656-20200512 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 336705563; Tue, 12 May 2020 18:31:03 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 19:21:01 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 10:21:03 +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; Wed, 13 May 2020 10:21:03 +0800 Message-ID: <1589336464.3197.68.camel@mtkswgap22> Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend From: Stanley Chu To: "Asutosh Das (asd)" Date: Wed, 13 May 2020 10:21:04 +0800 In-Reply-To: <3740c6fa-77f1-53eb-ec8e-8f9d09f2646f@codeaurora.org> References: <20200512104750.8711-1-stanley.chu@mediatek.com> <20200512104750.8711-5-stanley.chu@mediatek.com> <3740c6fa-77f1-53eb-ec8e-8f9d09f2646f@codeaurora.org> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200512_193112_547519_3E9AC80C X-CRM114-Status: GOOD ( 25.68 ) 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@mediatek.com, jejb@linux.ibm.com, chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com, linux-kernel@vger.kernel.org, avri.altman@wdc.com, cang@codeaurora.org, linux-mediatek@lists.infradead.org, peter.wang@mediatek.com, alim.akhtar@samsung.com, matthias.bgg@gmail.com, bvanassche@acm.org, linux-arm-kernel@lists.infradead.org, beanhuo@micron.com 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 Tue, 2020-05-12 at 10:04 -0700, Asutosh Das (asd) wrote: > Hi Stanley, > > 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); > > } > > + > > /* > > - * 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); > > } > > > > - 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); > > + if (ret) > > + goto enable_gating; > > + } > > } > > > > flush_work(&hba->eeh_work); > > > > Can you please confirm that you've tested and found that with the > previous code, the flush operation in the device was not happening. > > If so, please can you let me know the test-case that you ran to figure > this out. > > I'd like to verify this at my end. Sorry currently I have no easy test cases or scripts available. To precisely confirm the flush behavior by logs, I added some codes to query "available WriteBooster buffer" before entering runtime suspend and after leaving runtime resume, and observe the trend of available WriteBooster buffer. My test steps are as below, 1. Create a writer to write large data in a short time to fill-in WriteBooster buffer. 2. Do something to prevent system suspend 3. Do something to prevent link entering Hibern8, for example, disable Auto-Hibern8 and disable Hibern8 during clock gating. Because the Hibern8 period before runtime-suspend is known that VCC is provided and device can flush WriteBooster buffer if "Flush During H8" is enabled as upstream kernel currently. 4. Shrink the runtime suspend delay (maybe 100ms ~ 200ms) to make runtime suspend happen earlier. 5. After "available WriteBosoter buffer" reaches lower-level, for example, 10%, stop the writer. 6. Observe the trend of WriteBooster available buffer. In the previous code, the available WriteBooster buffer is increased very very slowly. Especially no increasing is observed during runtime-suspend. After applying this fix, the available WriteBooster buffer is increased much faster and the increasing can be easily observed during runtime-suspend. Thanks, Stanley Chu > > -- > Thanks, > -asd > _______________________________________________ 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.4 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 4EEC3C2D0F6 for ; Wed, 13 May 2020 02:31:17 +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 1224C207BC for ; Wed, 13 May 2020 02:31:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="YH5+sp0z"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=mediatek.com header.i=@mediatek.com header.b="MofD5KKp" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1224C207BC 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=H3rKG20szoP8JDk11oc/Wjo5+K5lfoD5YOZFm8CBfik=; b=YH5+sp0zTFtl/I y8qMu36vcwEMVPaqdlG8/cihvD+6mPNfn222PDY1ovGwNpwsxjrSl9NcvZYm1RGhyzWDl11RaWGhc QI7b+1UsLsc7MOiaqjtlTM7v19PkJ5+pB5fr/wRmbHiry8vww+HJllCZKRwj7Q4sQAlaFS/H8CVrU 6nfBiEgfbpMAZMCzHmMgoNKG6GxnSQxh9IXowelvXyQNOkio2zzYRtVKALMa4b2AOKykyhOX25eS0 9vGVHjHbtcVIkWNRHAfvku81wCHGX4KsSoSy6q2XRyYcHTTxZ0cxQRXaqgLFfTkdKgiz57oKxAXBl 4IN6p9I3Ut2OHxtnfmmQ==; 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 1jYhAy-0007g0-A1; Wed, 13 May 2020 02:31:16 +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 1jYhAu-0007f4-GA; Wed, 13 May 2020 02:31:14 +0000 X-UUID: 88141e78cbf8460eab5af47c368b7656-20200512 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=FEa8S57yUP1uBt7sF+Iuhy7qLD+6bZVqAcdAPC8F9JE=; b=MofD5KKpO/m36BxdJRtjBzFkVHXb10wjpOslr9htC/NJWkvKVnPxstr/NMHx1QQyZstkHJ6vrNnLLJbsI9xXEwU81tlcEMmeGf8AlA4Tm+Rq7ynThQR/0wtp2gtWsshF2uOdPC3ZvSK8sOknIW9FGMpNifr1QpbN1tSpMcgPaig=; X-UUID: 88141e78cbf8460eab5af47c368b7656-20200512 Received: from mtkcas66.mediatek.inc [(172.29.193.44)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 336705563; Tue, 12 May 2020 18:31:03 -0800 Received: from MTKMBS02N1.mediatek.inc (172.21.101.77) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 19:21:01 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs02n1.mediatek.inc (172.21.101.77) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 13 May 2020 10:21:03 +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; Wed, 13 May 2020 10:21:03 +0800 Message-ID: <1589336464.3197.68.camel@mtkswgap22> Subject: Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend From: Stanley Chu To: "Asutosh Das (asd)" Date: Wed, 13 May 2020 10:21:04 +0800 In-Reply-To: <3740c6fa-77f1-53eb-ec8e-8f9d09f2646f@codeaurora.org> References: <20200512104750.8711-1-stanley.chu@mediatek.com> <20200512104750.8711-5-stanley.chu@mediatek.com> <3740c6fa-77f1-53eb-ec8e-8f9d09f2646f@codeaurora.org> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200512_193112_547519_3E9AC80C X-CRM114-Status: GOOD ( 25.68 ) 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@mediatek.com, jejb@linux.ibm.com, chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com, linux-kernel@vger.kernel.org, avri.altman@wdc.com, cang@codeaurora.org, linux-mediatek@lists.infradead.org, peter.wang@mediatek.com, alim.akhtar@samsung.com, matthias.bgg@gmail.com, bvanassche@acm.org, linux-arm-kernel@lists.infradead.org, beanhuo@micron.com 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 Tue, 2020-05-12 at 10:04 -0700, Asutosh Das (asd) wrote: > Hi Stanley, > > 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); > > } > > + > > /* > > - * 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); > > } > > > > - 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); > > + if (ret) > > + goto enable_gating; > > + } > > } > > > > flush_work(&hba->eeh_work); > > > > Can you please confirm that you've tested and found that with the > previous code, the flush operation in the device was not happening. > > If so, please can you let me know the test-case that you ran to figure > this out. > > I'd like to verify this at my end. Sorry currently I have no easy test cases or scripts available. To precisely confirm the flush behavior by logs, I added some codes to query "available WriteBooster buffer" before entering runtime suspend and after leaving runtime resume, and observe the trend of available WriteBooster buffer. My test steps are as below, 1. Create a writer to write large data in a short time to fill-in WriteBooster buffer. 2. Do something to prevent system suspend 3. Do something to prevent link entering Hibern8, for example, disable Auto-Hibern8 and disable Hibern8 during clock gating. Because the Hibern8 period before runtime-suspend is known that VCC is provided and device can flush WriteBooster buffer if "Flush During H8" is enabled as upstream kernel currently. 4. Shrink the runtime suspend delay (maybe 100ms ~ 200ms) to make runtime suspend happen earlier. 5. After "available WriteBosoter buffer" reaches lower-level, for example, 10%, stop the writer. 6. Observe the trend of WriteBooster available buffer. In the previous code, the available WriteBooster buffer is increased very very slowly. Especially no increasing is observed during runtime-suspend. After applying this fix, the available WriteBooster buffer is increased much faster and the increasing can be easily observed during runtime-suspend. Thanks, Stanley Chu > > -- > Thanks, > -asd > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel