linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <oss@buserror.net>
To: Leo Li <pku.leo@gmail.com>, Raghav Dogra <raghav.dogra@nxp.com>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Subject: Re: [PATCH][v3] drivers/memory: Add deep sleep support for IFC
Date: Wed, 17 Feb 2016 19:11:29 -0600	[thread overview]
Message-ID: <1455757889.2463.88.camel@buserror.net> (raw)
In-Reply-To: <CADRPPNQpCv7xJEXE98xQExw2R_hE_YWj6T49WfB2NhW22UHEYA@mail.gmail.com>

On Wed, 2016-02-17 at 17:19 -0600, Leo Li wrote:
> On Wed, Feb 17, 2016 at 8:40 AM, Raghav Dogra <raghav.dogra@nxp.com> wrote:
> > 
> > > Is it really necessary to spin here rather than waiting for an interrupt
> > > like
> > > normal?
> > > 
> > 
> > Aren't the global interrupts disabled at this stage? Can we use the
> > interrupt based
> > waits in the deep sleep code? We used it based on the assumption that
> > interrupts
> > cannot be used here.
> 
> At the resume() stage, interrupts are already enabled.  But the
> problem of using interrupt based wait here is that we cannot give a
> correct return value at this point.  And it can also defeat the
> ordering of resume() callbacks for dependent devices.

I didn't say to return from the resume() function before the operation is
done, just to have the resume() function wait for the interrupt.  At the very
least it would make it easier to reuse existing code once this is moved to the
NAND driver, if we don't need a special way of waiting for this operation.

-Scott

  reply	other threads:[~2016-02-18  1:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-15  6:14 [PATCH][v3] drivers/memory: Add deep sleep support for IFC Raghav Dogra
2016-02-16  8:34 ` Scott Wood
2016-02-17 14:40   ` Raghav Dogra
2016-02-17 23:19     ` Leo Li
2016-02-18  1:11       ` Scott Wood [this message]
2016-02-18  1:19     ` Scott Wood
2016-04-14 23:07       ` Leo Li

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=1455757889.2463.88.camel@buserror.net \
    --to=oss@buserror.net \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=pku.leo@gmail.com \
    --cc=prabhakar.kushwaha@nxp.com \
    --cc=raghav.dogra@nxp.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;
as well as URLs for NNTP newsgroup(s).