| Message ID | 1402935191-18398-6-git-send-email-lars@metafoo.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 68f831c2724ab72c0088471b2ed1dc99e81948ef |
| Headers | show |
On Mon, Jun 16, 2014 at 06:13:05PM +0200, Lars-Peter Clausen wrote: > CODEC specific set_bias_level callback(). Not looking directly at the CODEC > driver struct will allow non CODEC DAPM contexts to implement a set_bias_level() > callback. It will indeed, but do we want them to? set_bias_level() is partly legacy and partly there for the benefit of analogue devices which can have more complex needs than digital ones which can mostly just use runtime PM. On the other hand there's a consistency thing going on here, but that applies both within ASoC and throughout the kernel.
On Mon, Jun 16, 2014 at 06:13:05PM +0200, Lars-Peter Clausen wrote: > Currently the DAPM code directly looks at the CODEC driver struct to get a > handle to the set_bias_level() callback. This patch adds a new set_bias_level() > callback to the DAPM context struct. The DAPM code will use this new callback > instead of the CODEC callback. For CODECs the new callback is set up to call the > CODEC specific set_bias_level callback(). Not looking directly at the CODEC > driver struct will allow non CODEC DAPM contexts to implement a set_bias_level() > callback. Applied, thanks.
On Sat, Jun 21, 2014 at 09:14:37PM +0100, Mark Brown wrote: > On Mon, Jun 16, 2014 at 06:13:05PM +0200, Lars-Peter Clausen wrote: > > > CODEC specific set_bias_level callback(). Not looking directly at the CODEC > > driver struct will allow non CODEC DAPM contexts to implement a set_bias_level() > > callback. > > It will indeed, but do we want them to? set_bias_level() is partly > legacy and partly there for the benefit of analogue devices which can > have more complex needs than digital ones which can mostly just use > runtime PM. On the other hand there's a consistency thing going on > here, but that applies both within ASoC and throughout the kernel. I think it would help :) Even on DSPs loading firmware and power sequencing the DSP can get some help using these functions I think I might find some use of this for my work!
On Sun, Jun 22, 2014 at 10:56:00AM +0530, Vinod Koul wrote: > Even on DSPs loading firmware and power sequencing the DSP can get some help > using these functions > I think I might find some use of this for my work! Please be more specific about this - what do they offer that runtime PM and widgets don't offer?
On Sun, Jun 22, 2014 at 11:12:36AM +0100, Mark Brown wrote: > On Sun, Jun 22, 2014 at 10:56:00AM +0530, Vinod Koul wrote: > > > Even on DSPs loading firmware and power sequencing the DSP can get some help > > using these functions > > > I think I might find some use of this for my work! > > Please be more specific about this - what do they offer that runtime PM > and widgets don't offer? Well you are assuming that folks writing DSP FW will not have some wiered sequence! Neverthless, i can think of two scenarios to control fw loading and sequences: 1. DMICs attached to DSP doing record but data getting consumed by DSP. No data goes to host cpu. No PCM/parameters here, so we can do a simple Input-Output loop. Somthing reverse of what we can do with Codec vibra. Widgets will not tell me when to load DSP FW. Since no device handle, no runtime here! 2. SoC DSP generating clock for codec and audio ICs even when no data is generated by SoC. This is not true for I2S but for other bus prtocols like Slimbus. Thanks
On Mon, Jun 23, 2014 at 10:04:05AM +0530, Vinod Koul wrote: > On Sun, Jun 22, 2014 at 11:12:36AM +0100, Mark Brown wrote: > > Please be more specific about this - what do they offer that runtime PM > > and widgets don't offer? > Well you are assuming that folks writing DSP FW will not have some wiered > sequence! > Neverthless, i can think of two scenarios to control fw loading and sequences: > 1. DMICs attached to DSP doing record but data getting consumed by DSP. No data > goes to host cpu. No PCM/parameters here, so we can do a simple Input-Output > loop. Somthing reverse of what we can do with Codec vibra. Widgets will not tell > me when to load DSP FW. Since no device handle, no runtime here! Why not? If there's a DAPM context there must be a struct device for it and if there's an audio path there should be widgets on it. > 2. SoC DSP generating clock for codec and audio ICs even when no data is > generated by SoC. This is not true for I2S but for other bus prtocols like > Slimbus. This sounds like something runtime PM would work fine for?
diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index 8db627c..3a5c4f9 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -601,6 +601,8 @@ struct snd_soc_dapm_context { struct list_head list; int (*stream_event)(struct snd_soc_dapm_context *dapm, int event); + int (*set_bias_level)(struct snd_soc_dapm_context *dapm, + enum snd_soc_bias_level level); #ifdef CONFIG_DEBUG_FS struct dentry *debugfs_dapm; diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index bca8a71..10e13c4 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -4285,6 +4285,14 @@ static int snd_soc_codec_drv_read(struct snd_soc_component *component, return 0; } +static int snd_soc_codec_set_bias_level(struct snd_soc_dapm_context *dapm, + enum snd_soc_bias_level level) +{ + struct snd_soc_codec *codec = snd_soc_dapm_to_codec(dapm); + + return codec->driver->set_bias_level(codec, level); +} + /** * snd_soc_register_codec - Register a codec with the ASoC core * @@ -4322,6 +4330,8 @@ int snd_soc_register_codec(struct device *dev, codec->dapm.component = &codec->component; codec->dapm.seq_notifier = codec_drv->seq_notifier; codec->dapm.stream_event = codec_drv->stream_event; + if (codec_drv->set_bias_level) + codec->dapm.set_bias_level = snd_soc_codec_set_bias_level; codec->dev = dev; codec->driver = codec_drv; codec->component.val_bytes = codec_drv->reg_word_size; diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index fab1a88..6c94a6b 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -427,15 +427,10 @@ static int snd_soc_dapm_set_bias_level(struct snd_soc_dapm_context *dapm, if (ret != 0) goto out; - if (dapm->codec) { - if (dapm->codec->driver->set_bias_level) - ret = dapm->codec->driver->set_bias_level(dapm->codec, - level); - else - dapm->bias_level = level; - } else if (!card || dapm != &card->dapm) { + if (dapm->set_bias_level) + ret = dapm->set_bias_level(dapm, level); + else if (!card || dapm != &card->dapm) dapm->bias_level = level; - } if (ret != 0) goto out;
Currently the DAPM code directly looks at the CODEC driver struct to get a handle to the set_bias_level() callback. This patch adds a new set_bias_level() callback to the DAPM context struct. The DAPM code will use this new callback instead of the CODEC callback. For CODECs the new callback is set up to call the CODEC specific set_bias_level callback(). Not looking directly at the CODEC driver struct will allow non CODEC DAPM contexts to implement a set_bias_level() callback. This is also similar to how the seq_notifier() and stream_event() callbacks are currently handled. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> --- include/sound/soc-dapm.h | 2 ++ sound/soc/soc-core.c | 10 ++++++++++ sound/soc/soc-dapm.c | 11 +++-------- 3 files changed, 15 insertions(+), 8 deletions(-)