| Message ID | 20120820113427.GN8450@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Aug 20, 2012 at 12:34:31PM +0100, Lee Jones wrote: > From: Lee Jones <lee.jones@linaro.org> > Date: Fri, 27 Jul 2012 08:50:05 +0100 > Subject: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree > > We continue to allow the AB8500 CODEC to be registered via the AB8500 > Multi Functional Device API, only this time we extract its configuration > from the Device Tree binary. Please resend this series with all the acks you've got rather than mixing incremental updates in like this. Please also send patches in the format documented in SubmittingPatches.
On Mon, Aug 20, 2012 at 03:36:53PM +0100, Mark Brown wrote: > On Mon, Aug 20, 2012 at 12:34:31PM +0100, Lee Jones wrote: > > From: Lee Jones <lee.jones@linaro.org> > > Date: Fri, 27 Jul 2012 08:50:05 +0100 > > Subject: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree > > > > We continue to allow the AB8500 CODEC to be registered via the AB8500 > > Multi Functional Device API, only this time we extract its configuration > > from the Device Tree binary. > > Please resend this series with all the acks you've got rather than > mixing incremental updates in like this. I'm waiting until I have a few more Acks before I resend the entire patch-set again. Actually it's you and one other that I'm waiting for to review (and Ack as necessary) the ones requested by Linus, then resend with the corrections. > Please also send patches in > the format documented in SubmittingPatches. That's a big document, most of which I guess I'm adhering to. Care to be a little more specific?
On Tue, Aug 21, 2012 at 12:51:24PM +0100, Lee Jones wrote: > On Mon, Aug 20, 2012 at 03:36:53PM +0100, Mark Brown wrote: > > > From: Lee Jones <lee.jones@linaro.org> > > > Date: Fri, 27 Jul 2012 08:50:05 +0100 > > Please resend this series with all the acks you've got rather than > > mixing incremental updates in like this. > I'm waiting until I have a few more Acks before I resend the entire > patch-set again. Actually it's you and one other that I'm waiting for > to review (and Ack as necessary) the ones requested by Linus, then > resend with the corrections. Well, I'm the person who's going to apply the patches so I'm unlikely to ack them... I was waiting for arch/arm review before I looked at them due to the number of resends. > > Please also send patches in > > the format documented in SubmittingPatches. > That's a big document, most of which I guess I'm adhering to. Care to > be a little more specific? The bit I quoted is the main example, you're including random mail headers in the body of the mail.
On Tue, Aug 21, 2012 at 01:39:51PM +0100, Mark Brown wrote: > On Tue, Aug 21, 2012 at 12:51:24PM +0100, Lee Jones wrote: > > On Mon, Aug 20, 2012 at 03:36:53PM +0100, Mark Brown wrote: > > > > > From: Lee Jones <lee.jones@linaro.org> > > > > Date: Fri, 27 Jul 2012 08:50:05 +0100 > > > > Please resend this series with all the acks you've got rather than > > > mixing incremental updates in like this. > > > I'm waiting until I have a few more Acks before I resend the entire > > patch-set again. Actually it's you and one other that I'm waiting for > > to review (and Ack as necessary) the ones requested by Linus, then > > resend with the corrections. > > Well, I'm the person who's going to apply the patches so I'm unlikely > to ack them... I was waiting for arch/arm review before I looked at I have all of Linus' Acks. The only ones missing are yours and Ola's, but I think Ola is on vacation still, so he's asked Roger to do it. I don't know if you saw, but Linus has placed lots of Acked-by's which are dependent on your say-so, hence why I was waiting for your response. > them due to the number of resends. Bingo, thus why I was dubious about resending the entire patch-set too prematurely. > > > Please also send patches in > > > the format documented in SubmittingPatches. > > > That's a big document, most of which I guess I'm adhering to. Care to > > be a little more specific? > > The bit I quoted is the main example, you're including random mail > headers in the body of the mail. They're not mail headers per-say, they're `git format-patch` headers. I thought this was acceptable for single patches, hence why I've done it lots of times and had no complaints (until now). If there are some changes required in a single patch, I usually fix it up, create a patch with `git format-patch` and send it as a reply to either the original patch in the series or the mail containing the suggestion. If this is wrong please educate me as I thought this was acceptable, as I thought it would be less pain than sending the entire patch-set again for just one change?
On Tue, Aug 21, 2012 at 01:58:12PM +0100, Lee Jones wrote: > On Tue, Aug 21, 2012 at 01:39:51PM +0100, Mark Brown wrote: > > The bit I quoted is the main example, you're including random mail > > headers in the body of the mail. > They're not mail headers per-say, they're `git format-patch` headers. > I thought this was acceptable for single patches, hence why I've done > it lots of times and had no complaints (until now). > If there are some changes required in a single patch, I usually fix > it up, create a patch with `git format-patch` and send it as a reply > to either the original patch in the series or the mail containing the > suggestion. If this is wrong please educate me as I thought this was If you're going to do this send the patch properly in the same way patches are normally sent. Take a step back and think about this for a minute - why would it be a good idea to send these incremental patches in a different format which requires the person applying the patch to hand edit things to strip out the noise? > acceptable, as I thought it would be less pain than sending the > entire patch-set again for just one change? It makes it harder to work out which versions of things to apply and causes issues for tools when doing things like applying from a mailbox.
diff --git a/include/linux/mfd/abx500/ab8500-codec.h b/include/linux/mfd/abx500/ab8500-codec.h index dc65292..d707941 100644 --- a/include/linux/mfd/abx500/ab8500-codec.h +++ b/include/linux/mfd/abx500/ab8500-codec.h @@ -23,7 +23,8 @@ enum amic_type { /* Mic-biases */ enum amic_micbias { AMIC_MICBIAS_VAMIC1, - AMIC_MICBIAS_VAMIC2 + AMIC_MICBIAS_VAMIC2, + AMIC_MICBIAS_UNKNOWN }; /* Bias-voltage */ @@ -31,7 +32,8 @@ enum ear_cm_voltage { EAR_CMV_0_95V, EAR_CMV_1_10V, EAR_CMV_1_27V, - EAR_CMV_1_58V + EAR_CMV_1_58V, + EAR_CMV_UNKNOWN }; /* Analog microphone settings */ diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c index 23b4018..99dffcf 100644 --- a/sound/soc/codecs/ab8500-codec.c +++ b/sound/soc/codecs/ab8500-codec.c @@ -34,6 +34,7 @@ #include <linux/mfd/abx500/ab8500-sysctrl.h> #include <linux/mfd/abx500/ab8500-codec.h> #include <linux/regulator/consumer.h> +#include <linux/of.h> #include <sound/core.h> #include <sound/pcm.h> @@ -2394,9 +2395,65 @@ struct snd_soc_dai_driver ab8500_codec_dai[] = { } }; +static void ab8500_codec_of_probe(struct device *dev, struct device_node *np, + struct ab8500_codec_platform_data *codec) +{ + u32 value; + + if (of_get_property(np, "stericsson,amic1-type-single-ended", NULL)) + codec->amics.mic1_type = AMIC_TYPE_SINGLE_ENDED; + else + codec->amics.mic1_type = AMIC_TYPE_DIFFERENTIAL; + + if (of_get_property(np, "stericsson,amic2-type-single-ended", NULL)) + codec->amics.mic2_type = AMIC_TYPE_SINGLE_ENDED; + else + codec->amics.mic2_type = AMIC_TYPE_DIFFERENTIAL; + + /* Has a non-standard Vamic been requested? */ + if (of_get_property(np, "stericsson,amic1a-bias-vamic2", NULL)) + codec->amics.mic1a_micbias = AMIC_MICBIAS_VAMIC2; + else + codec->amics.mic1a_micbias = AMIC_MICBIAS_VAMIC1; + + if (of_get_property(np, "stericsson,amic1b-bias-vamic2", NULL)) + codec->amics.mic1b_micbias = AMIC_MICBIAS_VAMIC2; + else + codec->amics.mic1b_micbias = AMIC_MICBIAS_VAMIC1; + + if (of_get_property(np, "stericsson,amic2-bias-vamic1", NULL)) + codec->amics.mic2_micbias = AMIC_MICBIAS_VAMIC1; + else + codec->amics.mic2_micbias = AMIC_MICBIAS_VAMIC2; + + if (!of_property_read_u32(np, "stericsson,earpeice-cmv", &value)) { + switch (value) { + case 950 : + codec->ear_cmv = EAR_CMV_0_95V; + break; + case 1100 : + codec->ear_cmv = EAR_CMV_1_10V; + break; + case 1270 : + codec->ear_cmv = EAR_CMV_1_27V; + break; + case 1580 : + codec->ear_cmv = EAR_CMV_1_58V; + break; + default : + codec->ear_cmv = EAR_CMV_UNKNOWN; + dev_err(dev, "Unsuitable earpiece voltage found in DT\n"); + } + } else { + dev_warn(dev, "No earpiece voltage found in DT - using default\n"); + codec->ear_cmv = EAR_CMV_0_95V; + } +} + static int ab8500_codec_probe(struct snd_soc_codec *codec) { struct device *dev = codec->dev; + struct device_node *np = dev->of_node; struct ab8500_codec_drvdata *drvdata = dev_get_drvdata(dev); struct ab8500_platform_data *pdata; struct filter_control *fc; @@ -2407,6 +2464,30 @@ static int ab8500_codec_probe(struct snd_soc_codec *codec) /* Setup AB8500 according to board-settings */ pdata = (struct ab8500_platform_data *)dev_get_platdata(dev->parent); + if (np) { + if (!pdata) + pdata = devm_kzalloc(dev, + sizeof(struct ab8500_platform_data), + GFP_KERNEL); + + if (pdata && !pdata->codec) + pdata->codec + = devm_kzalloc(dev, + sizeof(struct ab8500_codec_platform_data), + GFP_KERNEL); + + if (!(pdata && pdata->codec)) + return -ENOMEM; + + ab8500_codec_of_probe(dev, np, pdata->codec); + + } else { + if (!(pdata && pdata->codec)) { + dev_err(dev, "No codec platform data or DT found\n"); + return -EINVAL; + } + } + /* Inform SoC Core that we have our own I/O arrangements. */ codec->control_data = (void *)true;