public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Shevchenko, Andriy" <andriy.shevchenko@intel.com>
To: "Koul, Vinod" <vinod.koul@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.jf.intel.com>,
	"Chew, Chiau Ee" <chiau.ee.chew@intel.com>,
	Viresh Kumar <viresh.linux@gmail.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dma: dw: Add suspend and resume handling for PCI mode DW_DMAC.
Date: Mon, 20 Jan 2014 12:47:56 +0000	[thread overview]
Message-ID: <1390222075.7619.29.camel@smile> (raw)
In-Reply-To: <20140120092501.GS26823@intel.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3001 bytes --]

On Mon, 2014-01-20 at 14:55 +0530, Vinod Koul wrote:
> On Thu, Dec 19, 2013 at 12:51:29PM +0200, Andy Shevchenko wrote:
> > On Wed, 2013-12-18 at 21:19 +0530, Vinod Koul wrote:
> > > On Mon, Dec 16, 2013 at 01:51:47PM +0530, Chew, Chiau Ee wrote:
> > 
> > > > As mentioned by Andy, we are using *_noirq  verion of suspend/resume PM
> > > > callback whereby the callbacks would be executed after IRQ handlers have been
> > > > disabled. If using SET_SYSTEM_SLEEP_PM_OPS, it would be the normal
> > > > suspend/resume PM callback. Looking at the Desginware DMAC platform code
> > > > (drivers/dma/dw/platform.c), it is using the *_noirq suspend/resume PM
> > > > callback. Is it advisable to use the normal suspend/resume PM callback instead
> > > > of *_noirq suspend/PM callback? 
> > > 
> > > i dont see a reason why we need the noirq versions
> > 
> > Okay. I imagine the following use case.
> > 
> > For example we have compiled in DMA driver (dw_dmac) along with, for
> > example, SPI driver.
> > 
> > System was scheduled to go sleep.
> > 
> > An order of calling IIUC might be DMA first, then SPI (since they are
> > not in parent / child relations).
> > 
> > What was happened when SPI would like to do a DMA transfer and DMA is
> > going to sleep? I'm trying to understand if this is a case.
> In that case how does no irq version help us?

It guarantees that we have no user of DMA anymore, since there is no
interrupt going on.

> For these cases, I have been using suspend_late. Since the dmaengine driver is
> providing service to other clients (SPI), it needs to esnure that it suspends
> after SPI using suspend_late and resume using resume_early. That way dma is
> availble whenever the client is active

suspend_late is working in context that interrupt handler may be
invoked. Thus, to have DMA driver be properly shut down we have to
wait / terminate possible ongoing transfer.

It seems for me all DMA drivers that are using
system .suspend()/.resume() are potentially buggy.

> 
> --
> ~Vinod
> 
> > 
> > > > > How about SET_SYSTEM_SLEEP_PM_OPS instead?
> > > > 
> > > > So, we are using *_noirq versions of the functions here. What happened when we switch to normal ones? Any side effects?
> > 
> > 
> > 
> > -- 
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Intel Finland Oy
> > 
> 

-- 
Andy Shevchenko <andriy.shevchenko@intel.com>
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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  reply	other threads:[~2014-01-20 12:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-10 14:06 [PATCH] dma: dw: Add suspend and resume handling for PCI mode DW_DMAC Chew Chiau Ee
2013-12-10 10:10 ` Vinod Koul
2013-12-10 11:56   ` Shevchenko, Andriy
2013-12-16  8:21     ` Chew, Chiau Ee
2013-12-18 15:49       ` Vinod Koul
2013-12-19 10:51         ` Andy Shevchenko
2014-01-20  9:25           ` Vinod Koul
2014-01-20 12:47             ` Shevchenko, Andriy [this message]
2014-01-20 12:07               ` Vinod Koul
2014-01-20 14:08                 ` Shevchenko, Andriy
2014-01-26 11:17                   ` Vinod Koul
2014-01-27 10:17                     ` Andy Shevchenko
2014-01-28  7:21                       ` Chew, Chiau Ee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1390222075.7619.29.camel@smile \
    --to=andriy.shevchenko@intel.com \
    --cc=andriy.shevchenko@linux.jf.intel.com \
    --cc=chiau.ee.chew@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vinod.koul@intel.com \
    --cc=viresh.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox