All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jarkko Nikula <jhnikula@gmail.com>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs
Date: Sun, 28 Nov 2010 11:50:04 +0000	[thread overview]
Message-ID: <20101128115004.GB28950@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1290700058-9270-1-git-send-email-jhnikula@gmail.com>

On Thu, Nov 25, 2010 at 05:47:38PM +0200, Jarkko Nikula wrote:

> I'm not entirely sure of reusing struct snd_soc_pcm_runtime but having some
> common struct on top of it for registering the sysfs nodes and passing to
> snd_soc_dapm_sys_add didn't sound clear either.
> Anyway suspend/resume is working with this version and doesn't need any other
> modifications to soc_suspend/soc_resume than traversing through the registered
> codecs instead of doing bunch of rtd->dailess etc hacks there.

So, the reason we're doing this is that the sysfs nodes for DAPM and
regular CODEC stuff are using the device node in the PCM runtime data to
look up the data structures they need to do things.  The CODEC probably
isn't an ideal place for the PCM runtime data anyway, it feels like a
card thing (as it spans multiple devices within the card except in the
most baroque designs).

Since we appear to be abusing sysfs here anyway (we've got an empty
release function) I think we should just look into fixing this properly,
probably by having a device directly on the CODEC and using that for the
CODEC-specific sysfs files.

That said, this shouldn't affect the external interfaces here - it
should only have any material impact on the core - so probably shouldn't
be a blocker for adding this feature.  Liam, does this analysis all
sound sane to you?

  parent reply	other threads:[~2010-11-28 11:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 15:47 [RFC don't apply] ASoC: Add support for optional auxiliary dailess codecs Jarkko Nikula
2010-11-25 19:18 ` Liam Girdwood
2010-11-25 21:32   ` Mark Brown
2010-11-26  7:25     ` Jarkko Nikula
2010-11-26 12:19       ` Peter Ujfalusi
2010-11-26 13:35         ` Jarkko Nikula
2010-11-26 13:41           ` Mark Brown
2010-11-26 13:55             ` Peter Ujfalusi
2010-11-26 13:59               ` Mark Brown
2010-11-26 14:14               ` Jarkko Nikula
2010-11-28 11:50 ` Mark Brown [this message]
2010-11-30 14:43   ` 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=20101128115004.GB28950@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=jhnikula@gmail.com \
    --cc=lrg@slimlogic.co.uk \
    /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.