diff mbox

[v3,5/9] ASoC: simple-card: Support setting mclk via a fixed factor

Message ID 1400772710-23523-1-git-send-email-andrew@lunn.ch (mailing list archive)
State New, archived
Headers show

Commit Message

Andrew Lunn May 22, 2014, 3:31 p.m. UTC
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(+)

Comments

Mark Brown May 22, 2014, 5:39 p.m. UTC | #1
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?
Andrew Lunn May 22, 2014, 5:52 p.m. UTC | #2
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
Mark Brown May 22, 2014, 6:30 p.m. UTC | #3
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.
Andrew Lunn May 22, 2014, 7:10 p.m. UTC | #4
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
Mark Brown May 22, 2014, 7:23 p.m. UTC | #5
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.
Mark Brown May 26, 2014, 1:29 p.m. UTC | #6
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 mbox

Patch

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 : "");