Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753480AbbKZSLQ (ORCPT ); Thu, 26 Nov 2015 13:11:16 -0500 Received: from mga03.intel.com ([134.134.136.65]:57478 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753328AbbKZSLN (ORCPT ); Thu, 26 Nov 2015 13:11:13 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,347,1444719600"; d="scan'208";a="2745641" From: "Shevchenko, Andriy" To: "Koul, Vinod" CC: "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "rjw@rjwysocki.net" , "dmaengine@vger.kernel.org" , "mika.westerberg@linux.intel.com" , "jarkko.nikula@linux.intel.com" , "gregkh@linuxfoundation.org" , "linux-acpi@vger.kernel.org" Subject: Re: [PATCH v2 5/7] dmaengine: dw: platform: power on device on shutdown Thread-Topic: [PATCH v2 5/7] dmaengine: dw: platform: power on device on shutdown Thread-Index: AQHRKHXTVAfySJwiY0Wenh0jTBZh6A== Date: Thu, 26 Nov 2015 18:11:09 +0000 Message-ID: <1448561479.15393.95.camel@intel.com> 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> <20151126174157.GI2309@localhost> <1448560712.15393.93.camel@linux.intel.com> In-Reply-To: <1448560712.15393.93.camel@linux.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.237.72.86] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 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 tAQIBKtV004797 Content-Length: 3498 Lines: 104 On Thu, 2015-11-26 at 19:58 +0200, Andy Shevchenko wrote: > On Thu, 2015-11-26 at 23:11 +0530, Vinod Koul wrote: > > 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. > > It can't, but the problem is we can't distinguish that in this > routine! > We simple do *not* know the actual power state of DMA. > > These calls *ensures* that DMA is powered on. Yes, the call to > dw_dma_off() when it used to be powered off sounds silly, I agree, > though I see no upstreamable (non-hackish) solution for that. > > Previously I proposed to remove .shutdown hook completely, you were > objecting. And second approach with PMC involved was also rejected by you since it was too hackish, which I completely agree with. > > > Is this on GP DMA on BYT/CHT or > > something else? > > Correct. Affected platforms are BYT-T and some or all of BSW/CHT > depending on firmware in use. > > >   > > > 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 > > There is not the case for few drivers. At least for us it's spi- > pxa2xx > one. It requires channels on its ->probe() stage. Jarkko is Cc'ed > here, > you may ask him as he is our maintainer for the SPI. > -- Andy Shevchenko Intel Finland Oy --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?