From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754244AbbHQHWy (ORCPT ); Mon, 17 Aug 2015 03:22:54 -0400 Received: from mail-bn1bon0132.outbound.protection.outlook.com ([157.56.111.132]:58434 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751664AbbHQHWs (ORCPT ); Mon, 17 Aug 2015 03:22:48 -0400 From: Yao Yuan To: Nigel Cunningham , Li Leo CC: Vinod Koul , "stefan@agner.ch" , Arnd Bergmann , Dan Williams , "dmaengine@vger.kernel.org" , lkml , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" Subject: RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support Thread-Topic: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support Thread-Index: AQHQw5QETahgv8214E+kkRhxNaGB9p4KjlKAgABu6+CAAVL+AIADWdZggABAUYCAAANXAA== Date: Mon, 17 Aug 2015 07:22:45 +0000 Message-ID: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> <55D183D1.9020401@nigelcunningham.com.au> In-Reply-To: <55D183D1.9020401@nigelcunningham.com.au> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yao.yuan@freescale.com; x-originating-ip: [192.158.241.86] x-microsoft-exchange-diagnostics: 1;CY1PR0301MB0730;5:pXuhsJZWG74XY341XLrpOeVp3R907UdU1uZWVKbh6IxeLMQcLzCtIuKrcnMoVippqc5EHl8ML9GvvBmBMxelrOcvClB/U4aWB/B8U/A4chXv8CDJDSzoqImDzagDwmmr6jGH5ucRxXoaiPAs3CA1iw==;24:95Cxut0U4RE4jj3qj0+ISsGeRMsO+7YBxxzaQXDhN5PEyBicYk3oHCBNvl0scBi00qyHaE03bWXvRIz9VDM1TzDvldQ9EDyN08/fP9sYna8=;20:BxEFYB2qOnFruiyHbnje3ehYG8ZHWA4lMAqGtZz1miA8QPVgwzVVij+gzSv2sSYf5HmTIll8ffi0Uq0A7Fzimg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0730; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5005006)(8121501046)(3002001);SRVR:CY1PR0301MB0730;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0730; x-forefront-prvs: 0671F32598 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(199003)(377454003)(24454002)(479174004)(189002)(66066001)(50986999)(93886004)(99286002)(76176999)(189998001)(101416001)(10400500002)(5001830100001)(87936001)(77096005)(106356001)(5001770100001)(4001540100001)(5002640100001)(81156007)(97736004)(2950100001)(2900100001)(106116001)(76576001)(102836002)(68736005)(54356999)(105586002)(122556002)(5001960100002)(19580405001)(92566002)(5001860100001)(74316001)(19580395003)(4001450100002)(2656002)(33656002)(86362001)(77156002)(64706001)(40100003)(62966003)(5003600100002)(46102003);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0301MB0730;H:CY1PR0301MB1562.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2015 07:22:45.3105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0730 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 t7H7MwKo008797 Hi Nigel, On Mon, Aug 17, 2015 at 2:49 PM, Nigel Cunningham < nigel@nigelcunningham.com.au > wrote: > On 17/08/15 13:59, Yao Yuan wrote: > > On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku.leo@gmail.com > wrote: > >> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan wrote: > >>> Hi Leo, > >>> > >>> Thanks for your review. > >>> About those two methods for DMA suspend that you have mentioned. > We > >> have a lot of the discussions in other DMA driver like DMA for > >> Freescale PowerPC. > >>> Finally, we think the device which used the DMA transmission service > >>> should > >> cancel the transmission service in its suspend. > >>> So DMA in suspend should be idle. > >> If that's the case you should clearly state this in the commit > >> message and in code, although I don't know if it is safe to make such > >> assumption. There could be user of the DMA that doesn't track the > completion of transfers. > > I think it should be safe. In my opinion, even some client(the user of > > the DMA) forget to cancel its DMA transmission, It will just lead to PM failed > but no other system and data risk. > > Although we should first fix the behavior of the client. > > Once you are no need the DMA transmission, why not stop it? > > > > Is it right? > Think of it from the end user perspective. Would you like your laptop (or > whatever) to refuse to suspend because of this condition? The user may well > expect that closing the lid on their laptop will reliably lead to it suspending to > ram. Returning a failure here could result in a loss of data if the condition is not > detected and the machine subsequently runs out of power. > Yes, the user may well expect that closing the lid on their laptop will reliably lead to it suspending to ram. So the client(the user of the DMA) must to PAUSE or terminate the DMA transmission. We need to rely on client doing the right thing here. The DMA should not make a decision instead of client. If the DMA is not idle in DMA suspend, it should be the client's issue. We don't know what the client really want to do, so just return the non-success value. > I do agree that whatever is submitting DMA should be stopped first; ideally this > driver would always be idle because whatever producers of work exist would > already have been quiesced and output flushed. > {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yao Yuan Subject: RE: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support Date: Mon, 17 Aug 2015 07:22:45 +0000 Message-ID: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> <55D183D1.9020401@nigelcunningham.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <55D183D1.9020401@nigelcunningham.com.au> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Nigel Cunningham , Li Leo Cc: Vinod Koul , "stefan@agner.ch" , Arnd Bergmann , Dan Williams , "dmaengine@vger.kernel.org" , lkml , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" List-Id: linux-pm@vger.kernel.org SGkgTmlnZWwsDQoNCk9uIE1vbiwgQXVnIDE3LCAyMDE1IGF0IDI6NDkgUE0sIE5pZ2VsIEN1bm5p bmdoYW0gPCBuaWdlbEBuaWdlbGN1bm5pbmdoYW0uY29tLmF1ID4gd3JvdGU6DQo+IE9uIDE3LzA4 LzE1IDEzOjU5LCBZYW8gWXVhbiB3cm90ZToNCj4gPiBPbiBTYXQsIEF1ZyAxNSwgMjAxNSBhdCA3 OjQ4IEFNLCBwa3UubGVvIDwgcGt1Lmxlb0BnbWFpbC5jb20gPiB3cm90ZToNCj4gPj4gT24gRnJp LCBBdWcgMTQsIDIwMTUgYXQgMToyNCBBTSwgWWFvIFl1YW4gPHlhby55dWFuQGZyZWVzY2FsZS5j b20+IHdyb3RlOg0KPiA+Pj4gSGkgTGVvLA0KPiA+Pj4NCj4gPj4+IFRoYW5rcyBmb3IgeW91ciBy ZXZpZXcuDQo+ID4+PiBBYm91dCB0aG9zZSB0d28gbWV0aG9kcyBmb3IgRE1BIHN1c3BlbmQgdGhh dCB5b3UgaGF2ZSBtZW50aW9uZWQuDQo+IFdlDQo+ID4+IGhhdmUgYSBsb3Qgb2YgdGhlIGRpc2N1 c3Npb25zIGluIG90aGVyIERNQSBkcml2ZXIgbGlrZSBETUEgZm9yDQo+ID4+IEZyZWVzY2FsZSBQ b3dlclBDLg0KPiA+Pj4gRmluYWxseSwgd2UgdGhpbmsgdGhlIGRldmljZSB3aGljaCB1c2VkIHRo ZSBETUEgdHJhbnNtaXNzaW9uIHNlcnZpY2UNCj4gPj4+IHNob3VsZA0KPiA+PiBjYW5jZWwgdGhl IHRyYW5zbWlzc2lvbiBzZXJ2aWNlIGluIGl0cyBzdXNwZW5kLg0KPiA+Pj4gU28gRE1BIGluIHN1 c3BlbmQgc2hvdWxkIGJlIGlkbGUuDQo+ID4+IElmIHRoYXQncyB0aGUgY2FzZSB5b3Ugc2hvdWxk IGNsZWFybHkgc3RhdGUgdGhpcyBpbiB0aGUgY29tbWl0DQo+ID4+IG1lc3NhZ2UgYW5kIGluIGNv ZGUsIGFsdGhvdWdoIEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBzYWZlIHRvIG1ha2Ugc3VjaA0KPiA+ PiBhc3N1bXB0aW9uLiAgVGhlcmUgY291bGQgYmUgdXNlciBvZiB0aGUgRE1BIHRoYXQgZG9lc24n dCB0cmFjayB0aGUNCj4gY29tcGxldGlvbiBvZiB0cmFuc2ZlcnMuDQo+ID4gSSB0aGluayBpdCBz aG91bGQgYmUgc2FmZS4gSW4gbXkgb3BpbmlvbiwgZXZlbiBzb21lIGNsaWVudCh0aGUgdXNlciBv Zg0KPiA+IHRoZSBETUEpIGZvcmdldCB0byBjYW5jZWwgaXRzIERNQSB0cmFuc21pc3Npb24sIEl0 IHdpbGwganVzdCBsZWFkIHRvIFBNIGZhaWxlZA0KPiBidXQgbm8gb3RoZXIgc3lzdGVtIGFuZCBk YXRhIHJpc2suDQo+ID4gQWx0aG91Z2ggd2Ugc2hvdWxkIGZpcnN0IGZpeCB0aGUgYmVoYXZpb3Ig b2YgdGhlIGNsaWVudC4NCj4gPiBPbmNlIHlvdSBhcmUgbm8gbmVlZCB0aGUgRE1BIHRyYW5zbWlz c2lvbiwgd2h5IG5vdCBzdG9wIGl0Pw0KPiA+DQo+ID4gSXMgaXQgcmlnaHQ/DQo+IFRoaW5rIG9m IGl0IGZyb20gdGhlIGVuZCB1c2VyIHBlcnNwZWN0aXZlLiBXb3VsZCB5b3UgbGlrZSB5b3VyIGxh cHRvcCAob3INCj4gd2hhdGV2ZXIpIHRvIHJlZnVzZSB0byBzdXNwZW5kIGJlY2F1c2Ugb2YgdGhp cyBjb25kaXRpb24/IFRoZSB1c2VyIG1heSB3ZWxsDQo+IGV4cGVjdCB0aGF0IGNsb3NpbmcgdGhl IGxpZCBvbiB0aGVpciBsYXB0b3Agd2lsbCByZWxpYWJseSBsZWFkIHRvIGl0IHN1c3BlbmRpbmcg dG8NCj4gcmFtLiBSZXR1cm5pbmcgYSBmYWlsdXJlIGhlcmUgY291bGQgcmVzdWx0IGluIGEgbG9z cyBvZiBkYXRhIGlmIHRoZSBjb25kaXRpb24gaXMgbm90DQo+IGRldGVjdGVkIGFuZCB0aGUgbWFj aGluZSBzdWJzZXF1ZW50bHkgcnVucyBvdXQgb2YgcG93ZXIuDQo+IA0KDQpZZXMsIHRoZSB1c2Vy IG1heSB3ZWxsIGV4cGVjdCB0aGF0IGNsb3NpbmcgdGhlIGxpZCBvbiB0aGVpciBsYXB0b3Agd2ls bCByZWxpYWJseSBsZWFkIHRvIGl0IHN1c3BlbmRpbmcgdG8gcmFtLg0KU28gdGhlIGNsaWVudCh0 aGUgdXNlciBvZiB0aGUgRE1BKSBtdXN0ICB0byBQQVVTRSBvciB0ZXJtaW5hdGUgdGhlIERNQSB0 cmFuc21pc3Npb24uDQoNCldlIG5lZWQgdG8gcmVseSBvbiBjbGllbnQgZG9pbmcgdGhlIHJpZ2h0 IHRoaW5nIGhlcmUuIA0KVGhlIERNQSBzaG91bGQgbm90IG1ha2UgYSBkZWNpc2lvbiBpbnN0ZWFk IG9mIGNsaWVudC4NCklmIHRoZSBETUEgaXMgbm90IGlkbGUgaW4gRE1BIHN1c3BlbmQsIGl0IHNo b3VsZCBiZSB0aGUgY2xpZW50J3MgaXNzdWUuDQpXZSBkb24ndCBrbm93IHdoYXQgdGhlIGNsaWVu dCByZWFsbHkgd2FudCB0byBkbywgc28ganVzdCByZXR1cm4gdGhlIG5vbi1zdWNjZXNzIHZhbHVl Lg0KDQo+IEkgZG8gYWdyZWUgdGhhdCB3aGF0ZXZlciBpcyBzdWJtaXR0aW5nIERNQSBzaG91bGQg YmUgc3RvcHBlZCBmaXJzdDsgaWRlYWxseSB0aGlzDQo+IGRyaXZlciB3b3VsZCBhbHdheXMgYmUg aWRsZSBiZWNhdXNlIHdoYXRldmVyIHByb2R1Y2VycyBvZiB3b3JrIGV4aXN0IHdvdWxkDQo+IGFs cmVhZHkgaGF2ZSBiZWVuIHF1aWVzY2VkIGFuZCBvdXRwdXQgZmx1c2hlZC4NCj4gDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 From: yao.yuan@freescale.com (Yao Yuan) Date: Mon, 17 Aug 2015 07:22:45 +0000 Subject: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support In-Reply-To: <55D183D1.9020401@nigelcunningham.com.au> References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> <55D183D1.9020401@nigelcunningham.com.au> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Nigel, On Mon, Aug 17, 2015 at 2:49 PM, Nigel Cunningham < nigel@nigelcunningham.com.au > wrote: > On 17/08/15 13:59, Yao Yuan wrote: > > On Sat, Aug 15, 2015 at 7:48 AM, pku.leo < pku.leo@gmail.com > wrote: > >> On Fri, Aug 14, 2015 at 1:24 AM, Yao Yuan wrote: > >>> Hi Leo, > >>> > >>> Thanks for your review. > >>> About those two methods for DMA suspend that you have mentioned. > We > >> have a lot of the discussions in other DMA driver like DMA for > >> Freescale PowerPC. > >>> Finally, we think the device which used the DMA transmission service > >>> should > >> cancel the transmission service in its suspend. > >>> So DMA in suspend should be idle. > >> If that's the case you should clearly state this in the commit > >> message and in code, although I don't know if it is safe to make such > >> assumption. There could be user of the DMA that doesn't track the > completion of transfers. > > I think it should be safe. In my opinion, even some client(the user of > > the DMA) forget to cancel its DMA transmission, It will just lead to PM failed > but no other system and data risk. > > Although we should first fix the behavior of the client. > > Once you are no need the DMA transmission, why not stop it? > > > > Is it right? > Think of it from the end user perspective. Would you like your laptop (or > whatever) to refuse to suspend because of this condition? The user may well > expect that closing the lid on their laptop will reliably lead to it suspending to > ram. Returning a failure here could result in a loss of data if the condition is not > detected and the machine subsequently runs out of power. > Yes, the user may well expect that closing the lid on their laptop will reliably lead to it suspending to ram. So the client(the user of the DMA) must to PAUSE or terminate the DMA transmission. We need to rely on client doing the right thing here. The DMA should not make a decision instead of client. If the DMA is not idle in DMA suspend, it should be the client's issue. We don't know what the client really want to do, so just return the non-success value. > I do agree that whatever is submitting DMA should be stopped first; ideally this > driver would always be idle because whatever producers of work exist would > already have been quiesced and output flushed. >