All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: "Chew, Chiau Ee" <chiau.ee.chew@intel.com>
Cc: "Shevchenko, Andriy" <andriy.shevchenko@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: Wed, 18 Dec 2013 21:19:55 +0530	[thread overview]
Message-ID: <20131218154955.GF16227@intel.com> (raw)
In-Reply-To: <604BF5F4C5D71041942BC7E84ED659EA01520785@PGSMSX103.gar.corp.intel.com>

On Mon, Dec 16, 2013 at 01:51:47PM +0530, Chew, Chiau Ee wrote:
> Vinod,
Please do *NOT* top post

Please fix your MUA to wrap lines with 80chars. I have fix below to make it
readble...

> 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

--
~Vinod

> 
> Thanks,
> Chiau Ee
> 
> -----Original Message-----
> From: Shevchenko, Andriy 
> Sent: Tuesday, December 10, 2013 7:57 PM
> To: Koul, Vinod
> Cc: Chew, Chiau Ee; Viresh Kumar; Andy Shevchenko; Williams, Dan J; dmaengine@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] dma: dw: Add suspend and resume handling for PCI mode DW_DMAC.
> 
> On Tue, 2013-12-10 at 15:40 +0530, Vinod Koul wrote:
> > On Tue, Dec 10, 2013 at 10:06:13PM +0800, Chew Chiau Ee wrote:
> > > From: Chew, Chiau Ee <chiau.ee.chew@intel.com>
> > > 
> > > This is to disable/enable DW_DMAC hw during suspend/resume.
> > > 
> > > Signed-off-by: Chew, Chiau Ee <chiau.ee.chew@intel.com>
> > > Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > >  drivers/dma/dw/pci.c |   33 +++++++++++++++++++++++++++++++++
> > >  1 files changed, 33 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/drivers/dma/dw/pci.c b/drivers/dma/dw/pci.c index 
> > > e89fc24..97bc3a2 100644
> > > --- a/drivers/dma/dw/pci.c
> > > +++ b/drivers/dma/dw/pci.c
> > > @@ -75,6 +75,36 @@ static void dw_pci_remove(struct pci_dev *pdev)
> > >  		dev_warn(&pdev->dev, "can't remove device properly: %d\n", ret);  
> > > }
> > >  
> > > +#ifdef CONFIG_PM_SLEEP
> > > +
> > > +static int dw_pci_suspend_noirq(struct device *dev) {
> > > +	struct pci_dev *pci = to_pci_dev(dev);
> > > +	struct dw_dma_chip *chip = pci_get_drvdata(pci);
> > > +
> > > +	return dw_dma_suspend(chip);
> > > +};
> > > +
> > > +static int dw_pci_resume_noirq(struct device *dev) {
> > > +	struct pci_dev *pci = to_pci_dev(dev);
> > > +	struct dw_dma_chip *chip = pci_get_drvdata(pci);
> > > +
> > > +	return dw_dma_resume(chip);
> > > +};
> > > +
> > > +#else /* !CONFIG_PM_SLEEP */
> > > +
> > > +#define dw_pci_suspend_noirq	NULL
> > > +#define dw_pci_resume_noirq	NULL
> > > +
> > > +#endif /* !CONFIG_PM_SLEEP */
> > 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?
> 
> > 
> > --
> > ~Vinod
> > > +
> > > +static const struct dev_pm_ops dw_pci_dev_pm_ops = {
> > > +	.suspend_noirq = dw_pci_suspend_noirq,
> > > +	.resume_noirq = dw_pci_resume_noirq, };
> > > +
> > >  static DEFINE_PCI_DEVICE_TABLE(dw_pci_id_table) = {
> > >  	/* Medfield */
> > >  	{ PCI_VDEVICE(INTEL, 0x0827), (kernel_ulong_t)&dw_pci_pdata }, @@ 
> > > -92,6 +122,9 @@ static struct pci_driver dw_pci_driver = {
> > >  	.id_table	= dw_pci_id_table,
> > >  	.probe		= dw_pci_probe,
> > >  	.remove		= dw_pci_remove,
> > > +	.driver	= {
> > > +		.pm	= &dw_pci_dev_pm_ops,
> > > +	},
> > >  };
> > >  
> > >  module_pci_driver(dw_pci_driver);
> > > --
> > > 1.7.4.4
> > > 
> > 
> 
> --
> Andy Shevchenko <andriy.shevchenko@intel.com> Intel Finland Oy

-- 

  reply	other threads:[~2013-12-18 16:49 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 [this message]
2013-12-19 10:51         ` Andy Shevchenko
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=20131218154955.GF16227@intel.com \
    --to=vinod.koul@intel.com \
    --cc=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=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.