From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752689AbbHQD7s (ORCPT ); Sun, 16 Aug 2015 23:59:48 -0400 Received: from mail-bn1bn0101.outbound.protection.outlook.com ([157.56.110.101]:45812 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751440AbbHQD7p (ORCPT ); Sun, 16 Aug 2015 23:59:45 -0400 From: Yao Yuan To: 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+AIADWdZg Date: Mon, 17 Aug 2015 03:59:41 +0000 Message-ID: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> In-Reply-To: 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;CY1PR0301MB0729;5:r4VeYoXcKjx8hqQkbEHs8cJd2c4SNVOFKdcR89s6jGghvxJSy+GICnO6RpsXHc1juExoi+cBHPCVkWqULSFWZGmlK/1e9fWXGmOiogaTS+3UVKDb0ueY6RQVlLk7Y1DvrIMvw0lSGlVrPlu88CbtYw==;24:9ZqE46KAhmtYfIDZ//owv9yzpxzor0cvqwz9ozdd23TMofp5lk2DckbnzCYWMqfRLZ546N/64CFJHW4Qfxuqt/gI0wOycYwlUQrDAsZfGRc=;20:D/7SlN4YTsrHjmevBrZRajf0ew3W4E0hLRr7OgvhgKZrfsb2FpMO7zz3nnlK+F8RmV1AZ2bdqPKFgwk1mmwxHA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0729; 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:CY1PR0301MB0729;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0729; x-forefront-prvs: 0671F32598 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(199003)(13464003)(24454002)(377454003)(189002)(10400500002)(2900100001)(86362001)(105586002)(106356001)(4001540100001)(2950100001)(46102003)(97736004)(81156007)(5001860100001)(77156002)(62966003)(5002640100001)(19580395003)(76576001)(101416001)(40100003)(19580405001)(5001960100002)(5003600100002)(122556002)(110136002)(106116001)(66066001)(92566002)(102836002)(4001450100002)(50986999)(68736005)(5001830100001)(77096005)(54356999)(87936001)(74316001)(76176999)(2656002)(189998001)(99286002)(33656002)(93886004)(64706001)(15975445007);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0301MB0729;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 03:59:41.8524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0729 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 t7H3xr9i008140 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? > > > > Once the DMA in late_suspend is not be idle, we think some driver haven't > canceled the DMA transmission. So maybe something is error when other > driver in suspend. > > > > In the case, we should return failed to stop PM. DMA should not make a > choice for other drivers(which used DMA) to force stop DMA transmission. > > The suspend entrance should be terminated by wakeup events and only critical > issues. I don't think we should just terminate the suspend entrance just > because having on-going I/O without even try to stop it. The graceful behavior would be to for client to PAUSE or terminate and then suspend followed by DMA suspend. 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'm not sure my description is clear. So we may refer the discussion about the DMA PM support before. Such as "DMA: Freescale: add suspend resume functions for DMA driver" Like:https://lkml.org/lkml/2014/5/21/1 > > > > Thanks. > > > > Best Regards, > > Yuan Yao > > > >> -----Original Message----- > >> From: pku.leo@gmail.com [mailto:pku.leo@gmail.com] On Behalf Of Li > >> Yang > >> Sent: Friday, August 14, 2015 4:58 AM > >> To: Yuan Yao-B46683 > >> 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 > >> > >> On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao wrote: > >> > This add power management suspend/resume support for the fsl-edma > >> > driver. > >> > > >> > eDMA acted as a basic function used by others. What it needs to do > >> > is the two steps below to support power management. > >> > > >> > In fsl_edma_suspend_late: > >> > Check whether the DMA chan is idle and if it is not idle, stop PM > >> > operation. > >> > >> You should try to quiesce the device on suspend instead of depending > >> on itself to be happen in idle and failing if it is not. > >> > >> Regards, > >> Leo > > > > -- > - Leo {.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 03:59:41 +0000 Message-ID: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-bn1bn0101.outbound.protection.outlook.com ([157.56.110.101]:45812 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751440AbbHQD7p (ORCPT ); Sun, 16 Aug 2015 23:59:45 -0400 In-Reply-To: Content-Language: en-US Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: 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" T24gU2F0LCBBdWcgMTUsIDIwMTUgYXQgNzo0OCBBTSwgcGt1LmxlbyA8IHBrdS5sZW9AZ21haWwu Y29tID4gd3JvdGU6DQo+IE9uIEZyaSwgQXVnIDE0LCAyMDE1IGF0IDE6MjQgQU0sIFlhbyBZdWFu IDx5YW8ueXVhbkBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4gPiBIaSBMZW8sDQo+ID4NCj4gPiBU aGFua3MgZm9yIHlvdXIgcmV2aWV3Lg0KPiA+IEFib3V0IHRob3NlIHR3byBtZXRob2RzIGZvciBE TUEgc3VzcGVuZCB0aGF0IHlvdSBoYXZlIG1lbnRpb25lZC4gV2UNCj4gaGF2ZSBhIGxvdCBvZiB0 aGUgZGlzY3Vzc2lvbnMgaW4gb3RoZXIgRE1BIGRyaXZlciBsaWtlIERNQSBmb3IgRnJlZXNjYWxl DQo+IFBvd2VyUEMuDQo+ID4NCj4gPiBGaW5hbGx5LCB3ZSB0aGluayB0aGUgZGV2aWNlIHdoaWNo IHVzZWQgdGhlIERNQSB0cmFuc21pc3Npb24gc2VydmljZSBzaG91bGQNCj4gY2FuY2VsIHRoZSB0 cmFuc21pc3Npb24gc2VydmljZSBpbiBpdHMgc3VzcGVuZC4NCj4gPiBTbyBETUEgaW4gc3VzcGVu ZCBzaG91bGQgYmUgaWRsZS4NCj4gDQo+IElmIHRoYXQncyB0aGUgY2FzZSB5b3Ugc2hvdWxkIGNs ZWFybHkgc3RhdGUgdGhpcyBpbiB0aGUgY29tbWl0IG1lc3NhZ2UgYW5kIGluDQo+IGNvZGUsIGFs dGhvdWdoIEkgZG9uJ3Qga25vdyBpZiBpdCBpcyBzYWZlIHRvIG1ha2Ugc3VjaCBhc3N1bXB0aW9u LiAgVGhlcmUgY291bGQNCj4gYmUgdXNlciBvZiB0aGUgRE1BIHRoYXQgZG9lc24ndCB0cmFjayB0 aGUgY29tcGxldGlvbiBvZiB0cmFuc2ZlcnMuDQoNCkkgdGhpbmsgaXQgc2hvdWxkIGJlIHNhZmUu IEluIG15IG9waW5pb24sIGV2ZW4gc29tZSBjbGllbnQodGhlIHVzZXIgb2YgdGhlIERNQSkgZm9y Z2V0IHRvIGNhbmNlbCBpdHMgRE1BIHRyYW5zbWlzc2lvbiwNCkl0IHdpbGwganVzdCBsZWFkIHRv IFBNIGZhaWxlZCBidXQgbm8gb3RoZXIgc3lzdGVtIGFuZCBkYXRhIHJpc2suDQpBbHRob3VnaCB3 ZSBzaG91bGQgZmlyc3QgZml4IHRoZSBiZWhhdmlvciBvZiB0aGUgY2xpZW50Lg0KT25jZSB5b3Ug YXJlIG5vIG5lZWQgdGhlIERNQSB0cmFuc21pc3Npb24sIHdoeSBub3Qgc3RvcCBpdD8NCg0KSXMg aXQgcmlnaHQ/DQoNCj4gPg0KPiA+IE9uY2UgdGhlIERNQSBpbiBsYXRlX3N1c3BlbmQgaXMgbm90 IGJlIGlkbGUsIHdlIHRoaW5rIHNvbWUgZHJpdmVyIGhhdmVuJ3QNCj4gY2FuY2VsZWQgdGhlIERN QSB0cmFuc21pc3Npb24uIFNvIG1heWJlIHNvbWV0aGluZyBpcyBlcnJvciB3aGVuIG90aGVyDQo+ IGRyaXZlciBpbiBzdXNwZW5kLg0KPiA+DQo+ID4gSW4gdGhlIGNhc2UsIHdlIHNob3VsZCByZXR1 cm4gZmFpbGVkIHRvIHN0b3AgUE0uIERNQSBzaG91bGQgbm90IG1ha2UgYQ0KPiBjaG9pY2UgZm9y IG90aGVyIGRyaXZlcnMod2hpY2ggdXNlZCBETUEpIHRvIGZvcmNlIHN0b3AgRE1BIHRyYW5zbWlz c2lvbi4NCj4gDQo+IFRoZSBzdXNwZW5kIGVudHJhbmNlIHNob3VsZCBiZSB0ZXJtaW5hdGVkIGJ5 IHdha2V1cCBldmVudHMgYW5kIG9ubHkgY3JpdGljYWwNCj4gaXNzdWVzLiAgSSBkb24ndCB0aGlu ayB3ZSBzaG91bGQganVzdCB0ZXJtaW5hdGUgdGhlIHN1c3BlbmQgZW50cmFuY2UganVzdA0KPiBi ZWNhdXNlIGhhdmluZyBvbi1nb2luZyBJL08gd2l0aG91dCBldmVuIHRyeSB0byBzdG9wIGl0Lg0K DQpUaGUgZ3JhY2VmdWwgYmVoYXZpb3Igd291bGQgYmUgdG8gZm9yIGNsaWVudCB0byBQQVVTRSBv ciB0ZXJtaW5hdGUgYW5kIHRoZW4gc3VzcGVuZA0KZm9sbG93ZWQgYnkgRE1BIHN1c3BlbmQuDQpX ZSBuZWVkIHRvIHJlbHkgb24gY2xpZW50IGRvaW5nIHRoZSByaWdodCB0aGluZyBoZXJlLiANClRo ZSBETUEgc2hvdWxkIG5vdCBtYWtlIGEgZGVjaXNpb24gaW5zdGVhZCBvZiBjbGllbnQuDQpJZiB0 aGUgRE1BIGlzIG5vdCBpZGxlIGluIERNQSBzdXNwZW5kLCBpdCBzaG91bGQgYmUgdGhlIGNsaWVu dCdzIGlzc3VlLg0KV2UgZG9uJ3Qga25vdyB3aGF0IHRoZSBjbGllbnQgcmVhbGx5IHdhbnQgdG8g ZG8sIHNvIGp1c3QgcmV0dXJuIHRoZSBub24tc3VjY2VzcyB2YWx1ZS4NCg0KSSdtIG5vdCBzdXJl IG15IGRlc2NyaXB0aW9uIGlzIGNsZWFyLiAgU28gd2UgbWF5IHJlZmVyIHRoZSBkaXNjdXNzaW9u IGFib3V0IHRoZSBETUEgUE0gc3VwcG9ydCBiZWZvcmUuDQpTdWNoIGFzICJETUE6IEZyZWVzY2Fs ZTogYWRkIHN1c3BlbmQgcmVzdW1lIGZ1bmN0aW9ucyBmb3IgRE1BIGRyaXZlciINCg0KTGlrZTpo dHRwczovL2xrbWwub3JnL2xrbWwvMjAxNC81LzIxLzENCg0KPiA+DQo+ID4gVGhhbmtzLg0KPiA+ DQo+ID4gQmVzdCBSZWdhcmRzLA0KPiA+IFl1YW4gWWFvDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogcGt1Lmxlb0BnbWFpbC5jb20gW21haWx0bzpwa3Uu bGVvQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIExpDQo+ID4+IFlhbmcNCj4gPj4gU2VudDogRnJp ZGF5LCBBdWd1c3QgMTQsIDIwMTUgNDo1OCBBTQ0KPiA+PiBUbzogWXVhbiBZYW8tQjQ2NjgzDQo+ ID4+IENjOiBWaW5vZCBLb3VsOyBzdGVmYW5AYWduZXIuY2g7IEFybmQgQmVyZ21hbm47IERhbiBX aWxsaWFtczsNCj4gPj4gZG1hZW5naW5lQHZnZXIua2VybmVsLm9yZzsgbGttbDsNCj4gPj4gbGlu dXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC0gcG1Admdlci5rZXJuZWwu b3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjJdIGRtYWVuZ2luZTogZnNsLWVkbWE6IGFk ZCBQTSBzdXNwZW5kL3Jlc3VtZQ0KPiA+PiBzdXBwb3J0DQo+ID4+DQo+ID4+IE9uIFR1ZSwgSnVs IDIxLCAyMDE1IGF0IDM6NTYgQU0sIFl1YW4gWWFvIDx5YW8ueXVhbkBmcmVlc2NhbGUuY29tPiB3 cm90ZToNCj4gPj4gPiBUaGlzIGFkZCBwb3dlciBtYW5hZ2VtZW50IHN1c3BlbmQvcmVzdW1lIHN1 cHBvcnQgZm9yIHRoZSBmc2wtZWRtYQ0KPiA+PiA+IGRyaXZlci4NCj4gPj4gPg0KPiA+PiA+IGVE TUEgYWN0ZWQgYXMgYSBiYXNpYyBmdW5jdGlvbiB1c2VkIGJ5IG90aGVycy4gV2hhdCBpdCBuZWVk cyB0byBkbw0KPiA+PiA+IGlzIHRoZSB0d28gc3RlcHMgYmVsb3cgdG8gc3VwcG9ydCBwb3dlciBt YW5hZ2VtZW50Lg0KPiA+PiA+DQo+ID4+ID4gSW4gZnNsX2VkbWFfc3VzcGVuZF9sYXRlOg0KPiA+ PiA+IENoZWNrIHdoZXRoZXIgdGhlIERNQSBjaGFuIGlzIGlkbGUgYW5kIGlmIGl0IGlzIG5vdCBp ZGxlLCBzdG9wIFBNDQo+ID4+ID4gb3BlcmF0aW9uLg0KPiA+Pg0KPiA+PiBZb3Ugc2hvdWxkIHRy eSB0byBxdWllc2NlIHRoZSBkZXZpY2Ugb24gc3VzcGVuZCBpbnN0ZWFkIG9mIGRlcGVuZGluZw0K PiA+PiBvbiBpdHNlbGYgdG8gYmUgaGFwcGVuIGluIGlkbGUgYW5kIGZhaWxpbmcgaWYgaXQgaXMg bm90Lg0KPiA+Pg0KPiA+PiBSZWdhcmRzLA0KPiA+PiBMZW8NCj4gDQo+IA0KPiANCj4gLS0NCj4g LSBMZW8NCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: yao.yuan@freescale.com (Yao Yuan) Date: Mon, 17 Aug 2015 03:59:41 +0000 Subject: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support In-Reply-To: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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? > > > > Once the DMA in late_suspend is not be idle, we think some driver haven't > canceled the DMA transmission. So maybe something is error when other > driver in suspend. > > > > In the case, we should return failed to stop PM. DMA should not make a > choice for other drivers(which used DMA) to force stop DMA transmission. > > The suspend entrance should be terminated by wakeup events and only critical > issues. I don't think we should just terminate the suspend entrance just > because having on-going I/O without even try to stop it. The graceful behavior would be to for client to PAUSE or terminate and then suspend followed by DMA suspend. 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'm not sure my description is clear. So we may refer the discussion about the DMA PM support before. Such as "DMA: Freescale: add suspend resume functions for DMA driver" Like:https://lkml.org/lkml/2014/5/21/1 > > > > Thanks. > > > > Best Regards, > > Yuan Yao > > > >> -----Original Message----- > >> From: pku.leo at gmail.com [mailto:pku.leo at gmail.com] On Behalf Of Li > >> Yang > >> Sent: Friday, August 14, 2015 4:58 AM > >> To: Yuan Yao-B46683 > >> Cc: Vinod Koul; stefan at agner.ch; Arnd Bergmann; Dan Williams; > >> dmaengine at vger.kernel.org; lkml; > >> linux-arm-kernel at lists.infradead.org; linux- pm at vger.kernel.org > >> Subject: Re: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume > >> support > >> > >> On Tue, Jul 21, 2015 at 3:56 AM, Yuan Yao wrote: > >> > This add power management suspend/resume support for the fsl-edma > >> > driver. > >> > > >> > eDMA acted as a basic function used by others. What it needs to do > >> > is the two steps below to support power management. > >> > > >> > In fsl_edma_suspend_late: > >> > Check whether the DMA chan is idle and if it is not idle, stop PM > >> > operation. > >> > >> You should try to quiesce the device on suspend instead of depending > >> on itself to be happen in idle and failing if it is not. > >> > >> Regards, > >> Leo > > > > -- > - Leo