Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752541AbbKZRiG (ORCPT ); Thu, 26 Nov 2015 12:38:06 -0500 Received: from mga14.intel.com ([192.55.52.115]:64919 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbbKZRiD (ORCPT ); Thu, 26 Nov 2015 12:38:03 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,347,1444719600"; d="scan'208";a="847713880" Date: Thu, 26 Nov 2015 23:11:57 +0530 From: Vinod Koul To: Andy Shevchenko Cc: "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, dmaengine@vger.kernel.org, Thomas Gleixner , Greg Kroah-Hartman , Jarkko Nikula , linux-kernel@vger.kernel.org, Mika Westerberg Subject: Re: [PATCH v2 5/7] dmaengine: dw: platform: power on device on shutdown Message-ID: <20151126174157.GI2309@localhost> References: <1448551153-84719-1-git-send-email-andriy.shevchenko@linux.intel.com> <1448551153-84719-6-git-send-email-andriy.shevchenko@linux.intel.com> <20151126170105.GE2309@localhost> <1448558688.15393.85.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1448558688.15393.85.camel@linux.intel.com> 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: 3286 Lines: 106 On Thu, Nov 26, 2015 at 07:24:48PM +0200, Andy Shevchenko wrote: > On Thu, 2015-11-26 at 22:31 +0530, Vinod Koul wrote: > > On Thu, Nov 26, 2015 at 05:19:11PM +0200, Andy Shevchenko wrote: > > > We have to call dw_dma_disable() to stop any ongoing transfer. > > > > Ok > > > > > On some platforms we can't do that since DMA device is powered off. > > > > Umm, you said we have ongoing transfer which means DMA should be > > on..!! > > Yes, that's true for HSW/BDW and non-affected BYT/CHT. Can you please explain even when DMA is in use how can device be powered off? That does not sound right to me. Is this on GP DMA on BYT/CHT or something else? > > Like I mentioned here is no possibility to know which platform we run > on. > > Would you like to test this on a real device? We can provide you a > login. > > > > > > Moreover we have no > > > possibility at that point to check if the platform is affected or > > > not. That's > > > why we call pm_runtime_get_sync() / pm_runtime_put() > > > unconditionally. On the > > > other hand we can't use pm_runtime_suspended() because runtime PM > > > framework is > > > not fully used by the driver. > > > > Shouldn't that be fixed? > > Do you have any solution how? > > Rough approach is to turn on it on channel allocation and turn off on > freeing resources. The obvious downside of this solution is power > consumption of idling device. But in that case, the clients should not hold ref of dma chan when idle and allocate only when required which is a resonable expectation > > In any case it might be done in the future and it's not a scope of this > series. Sounds fine to me > > > > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > ?drivers/dma/dw/platform.c | 12 ++++++++++++ > > > ?1 file changed, 12 insertions(+) > > > > > > diff --git a/drivers/dma/dw/platform.c b/drivers/dma/dw/platform.c > > > index 68a4815..d0734e9 100644 > > > --- a/drivers/dma/dw/platform.c > > > +++ b/drivers/dma/dw/platform.c > > > @@ -239,7 +239,19 @@ static void dw_shutdown(struct platform_device > > > *pdev) > > > ?{ > > > ? struct dw_dma_chip *chip = platform_get_drvdata(pdev); > > > ? > > > + /* > > > + ?* We have to call dw_dma_disable() to stop any ongoing > > > transfer. On > > > + ?* some platforms we can't do that since DMA device is > > > powered off. > > > + ?* Moreover we have no possibility to check if the > > > platform is affected > > > + ?* or not. That's why we call pm_runtime_get_sync() / > > > pm_runtime_put() > > > + ?* unconditionally. On the other hand we can't use > > > + ?* pm_runtime_suspended() because runtime PM framework is > > > not fully > > > + ?* used by the driver. > > > + ?*/ > > > + pm_runtime_get_sync(chip->dev); > > > ? dw_dma_disable(chip); > > > + pm_runtime_put_sync_suspend(chip->dev); > > > + > > > ? clk_disable_unprepare(chip->clk); > > > ?} > > > ? > > > -- > > > 2.6.2 > > > > > > > -- > Andy Shevchenko > Intel Finland Oy > -- ~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/