All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Barry Song <21cnbao@gmail.com>
Cc: uclinux-dist-devel@blackfin.uclinux.org, alsa-devel@alsa-project.org
Subject: Re: [PATCH] soc-core: let suspend/resume not called if the card is not instantiated
Date: Fri, 13 Nov 2009 13:38:24 +0000	[thread overview]
Message-ID: <20091113133824.GD21516@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <1258087878-18679-1-git-send-email-21cnbao@gmail.com>

On Fri, Nov 13, 2009 at 12:51:18PM +0800, Barry Song wrote:
> It doesn't make sense to call suspend/resume of all cpu/codec dais even
> they are not initialized and registered. This will cause many problems
> foraudio PM.
> The condition card is not instantiated covers codec is null, so delete
> the check that codec is null.

Hrm.  It's not clear that this is the best approach here - it'd mean
that things like the CODEC drivers would need to have two suspend and
resume paths, one for use before the card comes up and one for use
afterwards.  As things stand this will fix whatever problem you are
seeing but will create problems for other systems where we'll stop
suspending devices that need it.

As with your TDM port issue pm_link is going to be really helpful here
once it hits mainline.  Let me have a think about what (if anything) we
can do in the meantime, this area is a little fragile.

  reply	other threads:[~2009-11-13 13:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-13  4:51 [PATCH] soc-core: let suspend/resume not called if the card is not instantiated Barry Song
2009-11-13 13:38 ` Mark Brown [this message]
2009-11-13 14:56   ` Barry Song
2009-11-13 15:02     ` Mark Brown
2009-11-13 15:29       ` Barry Song
2009-11-13 17:04         ` Mark Brown
2009-11-14  0:46           ` Barry Song
2009-11-16 17:04             ` Mark Brown

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=20091113133824.GD21516@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=21cnbao@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    /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.