| Message ID | 1400772710-23523-1-git-send-email-andrew@lunn.ch |
|---|---|
| State | Accepted, archived |
| Commit | 2942a0e285c46587a1025f12597df63ec04d08c6 |
| Headers | show |
On Thu, May 22, 2014 at 05:31:49PM +0200, Andrew Lunn wrote: > Some platforms require that the codecs mclk is a fixed multiplication > factor of the audio stream rate. Add a optional property to the > binding to hold this factor and implement a hw_params() function to > make use of it. > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> I'm missing the rest of this series - what's the context, are there any interdependencies?
On Thu, May 22, 2014 at 06:39:19PM +0100, Mark Brown wrote: > On Thu, May 22, 2014 at 05:31:49PM +0200, Andrew Lunn wrote: > > Some platforms require that the codecs mclk is a fixed multiplication > > factor of the audio stream rate. Add a optional property to the > > binding to hold this factor and implement a hw_params() function to > > make use of it. > > > > Signed-off-by: Andrew Lunn <andrew@lunn.ch> > > I'm missing the rest of this series - what's the context, are there any > interdependencies? I threaded the patch to your request to respin this patch: http://patchwork.ozlabs.org/patch/345353/ and the whole the v2 series is here: http://www.spinics.net/linux/lists/arm-kernel/msg328068.html You have already accepted patch 1, and Jason Cooper has taken 2, 3, 4, 6, 7, 8, & 9. There are no build interdependences. Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 22, 2014 at 07:52:06PM +0200, Andrew Lunn wrote: > On Thu, May 22, 2014 at 06:39:19PM +0100, Mark Brown wrote: > > I'm missing the rest of this series - what's the context, are there any > > interdependencies? > I threaded the patch to your request to respin this patch: > http://patchwork.ozlabs.org/patch/345353/ Ugh, no - don't do this. It's just confusing. Patch series numbering is used for ordering within a posting of a patch series, the fact that a given patch might have previously been posted along with some others isn't relevant if you send it out again in a different form. People will hopefully expect to see the rest of the series so they can check for interdependencies and so on, if the subject says there are 9 patches in what you're posting then there should be 9 patches. Similarly threading individual modifications to patches into the middle of prior postings makes it hard to track what's going on if things aren't applied - "I want version 1 of this patch, version 2 of that one" and so on gets hard to follow especially if there's a thread around them. You get problems like some revisions getting missed in the middle of the thread.
On Thu, May 22, 2014 at 07:30:54PM +0100, Mark Brown wrote: > On Thu, May 22, 2014 at 07:52:06PM +0200, Andrew Lunn wrote: > > On Thu, May 22, 2014 at 06:39:19PM +0100, Mark Brown wrote: > > > > I'm missing the rest of this series - what's the context, are there any > > > interdependencies? > > > I threaded the patch to your request to respin this patch: > > > http://patchwork.ozlabs.org/patch/345353/ > > Ugh, no - don't do this. It's just confusing. O.K, i will try to remember this as your way of doing things, when submitting to you. The usb-serial maintainer does want replies threading to his messages, etc. Takes a while to learn each maintainers ways. What you failed to say is if they will accept this one patch as is, or if you want me to post a v4 containing all the patches? Thanks Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 22, 2014 at 09:10:13PM +0200, Andrew Lunn wrote: > O.K, i will try to remember this as your way of doing things, when > submitting to you. The usb-serial maintainer does want replies > threading to his messages, etc. Takes a while to learn each > maintainers ways. I suspect you might find that's for things with an active thread. I disagree on that one still but if you're sending new stuff it's a fairly standard rule to just send new things. > What you failed to say is if they will accept this one patch as is, or > if you want me to post a v4 containing all the patches? I've not looked at it yet, I got as far as seeing that it was patch 3 and I didn't have patches 1 or 2 - I hadn't even registered what the patch was about. Assuming it's just a rebase it should be fine.
On Thu, May 22, 2014 at 05:31:49PM +0200, Andrew Lunn wrote: > Some platforms require that the codecs mclk is a fixed multiplication > factor of the audio stream rate. Add a optional property to the > binding to hold this factor and implement a hw_params() function to > make use of it. Applied, thanks.
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index 9b9df146fd1a..c2e9841dfce4 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -15,6 +15,9 @@ Optional properties: Each entry is a pair of strings, the first being the connection's sink, the second being the connection's source. +- simple-audio-card,mclk-fs : Multiplication factor between stream rate and codec + mclk. + Optional subnodes: - simple-audio-card,dai-link : Container for dai-link level diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c index 98f97e543c29..e97459f1424a 100644 --- a/sound/soc/generic/simple-card.c +++ b/sound/soc/generic/simple-card.c @@ -24,9 +24,32 @@ struct simple_card_data { struct asoc_simple_dai cpu_dai; struct asoc_simple_dai codec_dai; } *dai_props; + unsigned int mclk_fs; struct snd_soc_dai_link dai_link[]; /* dynamically allocated */ }; +static int asoc_simple_card_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *params) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_dai *codec_dai = rtd->codec_dai; + struct simple_card_data *priv = snd_soc_card_get_drvdata(rtd->card); + unsigned int mclk; + int ret = 0; + + if (priv->mclk_fs) { + mclk = params_rate(params) * priv->mclk_fs; + ret = snd_soc_dai_set_sysclk(codec_dai, 0, mclk, + SND_SOC_CLOCK_IN); + } + + return ret; +} + +static struct snd_soc_ops asoc_simple_card_ops = { + .hw_params = asoc_simple_card_hw_params, +}; + static int __asoc_simple_card_dai_init(struct snd_soc_dai *dai, struct asoc_simple_dai *set) { @@ -249,6 +272,7 @@ static int simple_card_dai_link_of(struct device_node *node, sprintf(name, "%s-%s", dai_link->cpu_dai_name, dai_link->codec_dai_name); dai_link->name = dai_link->stream_name = name; + dai_link->ops = &asoc_simple_card_ops; dev_dbg(dev, "\tname : %s\n", dai_link->stream_name); dev_dbg(dev, "\tcpu : %s / %04x / %d\n", @@ -298,6 +322,10 @@ static int asoc_simple_card_parse_of(struct device_node *node, return ret; } + /* Factor to mclk, used in hw_params() */ + of_property_read_u32(node, "simple-audio-card,mclk-fs", + &priv->mclk_fs); + dev_dbg(dev, "New simple-card: %s\n", priv->snd_card.name ? priv->snd_card.name : "");
Some platforms require that the codecs mclk is a fixed multiplication factor of the audio stream rate. Add a optional property to the binding to hold this factor and implement a hw_params() function to make use of it. Signed-off-by: Andrew Lunn <andrew@lunn.ch> --- v1->v2: s/factor/fs/g v2->v3: rebase on asoc/for-next --- .../devicetree/bindings/sound/simple-card.txt | 3 +++ sound/soc/generic/simple-card.c | 28 ++++++++++++++++++++++ 2 files changed, 31 insertions(+)