Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753509AbbHQG4S (ORCPT ); Mon, 17 Aug 2015 02:56:18 -0400 Received: from nigelcunningham.com.au ([139.162.22.9]:43211 "EHLO nigelcunningham.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394AbbHQG4Q (ORCPT ); Mon, 17 Aug 2015 02:56:16 -0400 X-Greylist: delayed 435 seconds by postgrey-1.27 at vger.kernel.org; Mon, 17 Aug 2015 02:56:15 EDT Message-ID: <55D183D1.9020401@nigelcunningham.com.au> Date: Mon, 17 Aug 2015 16:48:49 +1000 From: Nigel Cunningham User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Yao Yuan , 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 References: <1437469005-3162-1-git-send-email-yao.yuan@freescale.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1968 Lines: 35 Hi Yao. 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. 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. Regards, Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/