All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: "Chew, Chiau Ee" <chiau.ee.chew@intel.com>,
	Viresh Kumar <viresh.linux@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.jf.intel.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: Thu, 19 Dec 2013 12:51:29 +0200	[thread overview]
Message-ID: <1387450289.1871.240.camel@smile> (raw)
In-Reply-To: <20131218154955.GF16227@intel.com>

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.

> > > 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


  reply	other threads:[~2013-12-19 10:52 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 [this message]
2014-01-20  9:25           ` Vinod Koul
2014-01-20 12:47             ` Shevchenko, Andriy
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=1387450289.1871.240.camel@smile \
    --to=andriy.shevchenko@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.