Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751106AbbHTEGO (ORCPT ); Thu, 20 Aug 2015 00:06:14 -0400 Received: from mga02.intel.com ([134.134.136.20]:62777 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750736AbbHTEGM (ORCPT ); Thu, 20 Aug 2015 00:06:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,713,1432623600"; d="scan'208";a="628806302" Date: Thu, 20 Aug 2015 09:38:01 +0530 From: Vinod Koul To: Li Yang Cc: Yao Yuan , 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 Message-ID: <20150820040801.GS13546@localhost> 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=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1856 Lines: 36 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 -- ~Vinod -- 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/