Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


lee.jones at linaro

Aug 20, 2012, 4:34 AM

Post #1 of 6 (62 views)
Permalink
[PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree

From: Lee Jones <lee.jones [at] linaro>
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.

CC: alsa-devel [at] alsa-project
Acked-by: Ola Lilja <ola.o.lilja [at] stericsson>
Acked-by: Linus Walleij <linus.walleij [at] linaro>
Signed-off-by: Lee Jones <lee.jones [at] linaro>
---
include/linux/mfd/abx500/ab8500-codec.h | 6 ++-
sound/soc/codecs/ab8500-codec.c | 81 +++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+), 2 deletions(-)

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;

--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


broonie at opensource

Aug 20, 2012, 7:36 AM

Post #2 of 6 (50 views)
Permalink
Re: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree [In reply to]

On Mon, Aug 20, 2012 at 12:34:31PM +0100, Lee Jones wrote:
> From: Lee Jones <lee.jones [at] linaro>
> 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.
Attachments: signature.asc (0.82 KB)


lee.jones at linaro

Aug 21, 2012, 4:51 AM

Post #3 of 6 (49 views)
Permalink
Re: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree [In reply to]

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 [at] linaro>
> > 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?

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


broonie at opensource

Aug 21, 2012, 5:39 AM

Post #4 of 6 (49 views)
Permalink
Re: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree [In reply to]

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 [at] linaro>
> > > 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.
Attachments: signature.asc (0.82 KB)


lee.jones at linaro

Aug 21, 2012, 5:58 AM

Post #5 of 6 (51 views)
Permalink
Re: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree [In reply to]

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 [at] linaro>
> > > > 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?

--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


broonie at opensource

Aug 21, 2012, 6:40 AM

Post #6 of 6 (49 views)
Permalink
Re: [PATCH 1/1] ASoC: codecs: Enable AB8500 CODEC for Device Tree [In reply to]

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.
Attachments: signature.asc (0.82 KB)

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.