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
next prev parent 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.