From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753577AbbIGHmA (ORCPT ); Mon, 7 Sep 2015 03:42:00 -0400 Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:10709 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751224AbbIGHl5 convert rfc822-to-8bit (ORCPT ); Mon, 7 Sep 2015 03:41:57 -0400 From: Yao Yuan To: Vinod Koul , Li Leo CC: Nigel Cunningham , "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+AIADWdZggABAUYCAAANXAIAAy/YAgAO6xICAGxo00A== Date: Mon, 7 Sep 2015 07:41:53 +0000 Message-ID: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> <55D183D1.9020401@nigelcunningham.com.au> <20150820040801.GS13546@localhost> In-Reply-To: <20150820040801.GS13546@localhost> 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: [199.59.230.102] x-microsoft-exchange-diagnostics: 1;CY1PR0301MB0729;5:GzotuPE/tcuPHXTXAsboWT1QcaROMgn7m4XYATpXKNo4XPKc0BJ0F9KMsVJQTZCjhl0X3H2IGhVM0cn4qHqWg7OBnAgbCFrEc5Rs5wLTcRWx+y6mb1BnuVEP7UbIDsBGSIWhLSlsz6ewUcObH2QKOg==;24:crB11TVH6LNFrRgJdve8GP9rKjnpHOkpBU2Jf0bScqHlnOJBq6yHPN4B7iIL6xznKHjwrwFIY4/XYVtpUswfliMr2+lj+wIbssyFXwqwl5c=;20:8L2PdY32Fvyp6H7iFIoIHB2yI0q8YSzhXxnkcFYqc4zkAv9yYbKgKsQvyGmfWEq1YnpmJ71VPFkcGpONKF/Yvg== 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: 069255B8B8 x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(24454002)(199003)(189002)(62966003)(5007970100001)(74316001)(68736005)(40100003)(97736004)(76176999)(105586002)(10400500002)(66066001)(5004730100002)(4001540100001)(81156007)(4001450100002)(122556002)(2950100001)(2900100001)(76576001)(106356001)(64706001)(92566002)(5001770100001)(77156002)(87936001)(5001830100001)(46102003)(5003600100002)(85806002)(106116001)(54356999)(86362001)(99286002)(189998001)(93886004)(5001860100001)(5002640100001)(101416001)(33656002)(50986999)(5001960100002)(102836002);DIR:OUT;SFP:1102;SCL:1;SRVR:CY1PR0301MB0729;H:BLUPR03MB134.namprd03.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2015 07:41:53.7984 (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 On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote: > On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote: > > >> 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. > > > > The problem here is that neither the client nor the DMA controller > > driver should easily decide to stop the suspend entrance and rollback. > > I don't think the non-idle situation is serious enough to cause a > > rollback. You should do whatever can be done with the DMA > > controller(such as stop the controller and leave whatever to be done > > to the wake up) and continue with the suspend. > > Ideally yes client should suspend first and dmaengine driver then being idle > when suspend is invoked. But we know we are in idle world! > So, driver should ensure it suspends the active channels and then goes to > suspend and restores that on resume > Hi Vinod, Hi Leo, Is there any other discussions? I think we can have the following solutions for DMA driver: 1, Force terminate the active channels in its suspend and then return. 2, DMA have to wait until the active channels idle. 3, Don't care about the active channels and direct return. 4, Return BUS BUSY error and stop PM progress. I prefer the last one, because I think client should make sure the channel is idle. But also the first one should be works. Can we have a conclusion and suggestion for which one is better? Thanks. 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, 7 Sep 2015 07:41:53 +0000 Message-ID: References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> <55D183D1.9020401@nigelcunningham.com.au> <20150820040801.GS13546@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT Return-path: Received: from mail-bl2on0107.outbound.protection.outlook.com ([65.55.169.107]:10709 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751224AbbIGHl5 convert rfc822-to-8bit (ORCPT ); Mon, 7 Sep 2015 03:41:57 -0400 In-Reply-To: <20150820040801.GS13546@localhost> Content-Language: en-US Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Vinod Koul , Li Leo Cc: Nigel Cunningham , "stefan@agner.ch" , Arnd Bergmann , Dan Williams , "dmaengine@vger.kernel.org" , lkml , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote: > On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote: > > >> 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. > > > > The problem here is that neither the client nor the DMA controller > > driver should easily decide to stop the suspend entrance and rollback. > > I don't think the non-idle situation is serious enough to cause a > > rollback. You should do whatever can be done with the DMA > > controller(such as stop the controller and leave whatever to be done > > to the wake up) and continue with the suspend. > > Ideally yes client should suspend first and dmaengine driver then being idle > when suspend is invoked. But we know we are in idle world! > So, driver should ensure it suspends the active channels and then goes to > suspend and restores that on resume > Hi Vinod, Hi Leo, Is there any other discussions? I think we can have the following solutions for DMA driver: 1, Force terminate the active channels in its suspend and then return. 2, DMA have to wait until the active channels idle. 3, Don't care about the active channels and direct return. 4, Return BUS BUSY error and stop PM progress. I prefer the last one, because I think client should make sure the channel is idle. But also the first one should be works. Can we have a conclusion and suggestion for which one is better? Thanks. From mboxrd@z Thu Jan 1 00:00:00 1970 From: yao.yuan@freescale.com (Yao Yuan) Date: Mon, 7 Sep 2015 07:41:53 +0000 Subject: [PATCH v2] dmaengine: fsl-edma: add PM suspend/resume support In-Reply-To: <20150820040801.GS13546@localhost> References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> <55D183D1.9020401@nigelcunningham.com.au> <20150820040801.GS13546@localhost> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Aug 20, 2015 at 12:08:00PM +0800, Vinod Koul wrote: > On Mon, Aug 17, 2015 at 02:10:46PM -0500, Li Yang wrote: > > >> 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. > > > > The problem here is that neither the client nor the DMA controller > > driver should easily decide to stop the suspend entrance and rollback. > > I don't think the non-idle situation is serious enough to cause a > > rollback. You should do whatever can be done with the DMA > > controller(such as stop the controller and leave whatever to be done > > to the wake up) and continue with the suspend. > > Ideally yes client should suspend first and dmaengine driver then being idle > when suspend is invoked. But we know we are in idle world! > So, driver should ensure it suspends the active channels and then goes to > suspend and restores that on resume > Hi Vinod, Hi Leo, Is there any other discussions? I think we can have the following solutions for DMA driver: 1, Force terminate the active channels in its suspend and then return. 2, DMA have to wait until the active channels idle. 3, Don't care about the active channels and direct return. 4, Return BUS BUSY error and stop PM progress. I prefer the last one, because I think client should make sure the channel is idle. But also the first one should be works. Can we have a conclusion and suggestion for which one is better? Thanks.