Re: [PATCH] [v2] sound/soc/fsl/fsl_dma.c: add missing of_node_put
On 22/08/11 15:22, Timur Tabi wrote: > of_parse_phandle increments the reference count of np, so this should be > decremented before trying the next possibility. > > Since we don't actually use np, we can decrement the reference count > immediately. > > Reported-by: Julia Lawall > Signed-off-by: Timur Tabi Acked-by: Liam Girdwood > --- > sound/soc/fsl/fsl_dma.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c > index 6680c0b..b300f4b 100644 > --- a/sound/soc/fsl/fsl_dma.c > +++ b/sound/soc/fsl/fsl_dma.c > @@ -877,10 +877,12 @@ static struct device_node *find_ssi_node(struct > device_node *dma_channel_np) >* assume that device_node pointers are a valid comparison. >*/ > np = of_parse_phandle(ssi_np, "fsl,playback-dma", 0); > + of_node_put(np); > if (np == dma_channel_np) > return ssi_np; > > np = of_parse_phandle(ssi_np, "fsl,capture-dma", 0); > + of_node_put(np); > if (np == dma_channel_np) > return ssi_np; > } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] sound/soc/fsl/fsl_dma.c: add missing of_node_put
On 20/08/11 08:23, Julia Lawall wrote: > From: Julia Lawall > > of_parse_phandle increments the reference count of np, so this should be > decremented before trying the next possibility. > > The semantic match that finds this problem is as follows: > (http://coccinelle.lip6.fr/) > > // > @@ > expression e,e1,e2; > @@ > > *e = of_parse_phandle(...) > ... when != of_node_put(e) > when != true e == NULL > when != e2 = e > e = e1 > // > > Signed-off-by: Julia Lawall > > --- > sound/soc/fsl/fsl_dma.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c > index 0efc04a..b33271b 100644 > --- a/sound/soc/fsl/fsl_dma.c > +++ b/sound/soc/fsl/fsl_dma.c > @@ -880,10 +880,12 @@ static struct device_node *find_ssi_node(struct > device_node *dma_channel_np) > np = of_parse_phandle(ssi_np, "fsl,playback-dma", 0); > if (np == dma_channel_np) > return ssi_np; > + of_node_put(np); > > np = of_parse_phandle(ssi_np, "fsl,capture-dma", 0); > if (np == dma_channel_np) > return ssi_np; > + of_node_put(np); > } > > return NULL; > Acked-by: Liam Girdwood ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] asoc/multi-component: fsl: add support for disabled SSI nodes
On Thu, 2010-08-05 at 12:42 +0100, Mark Brown wrote: > On Wed, Aug 04, 2010 at 05:51:08PM -0500, Timur Tabi wrote: > > Add support for adding "status = disabled" to an SSI node to incidate that > > it > > is not wired on the board. This replaces the not-so-intuitive previous > > method > > of omitting a codec-handle property. > > > > Signed-off-by: Timur Tabi > > Acked-by: Mark Brown Applied. Thanks Liam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH][v2] powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support
On Thu, 2010-07-22 at 13:43 -0500, Kumar Gala wrote: > On Jul 22, 2010, at 11:49 AM, Mark Brown wrote: > > > On Thu, Jul 22, 2010 at 11:33:30AM -0500, Timur Tabi wrote: > >> The immap_86xx.h header file only defines one data structure: the "global > >> utilities" register set found on Freescale PowerPC SOCs. Rename this file > >> to fsl_guts.h to reflect its true purpose, and extend it to cover the > >> "GUTS" > >> register set on 85xx chips. > >> > >> Signed-off-by: Timur Tabi > > > > Acked-by: Mark Brown > > Acked-by: Kumar Gala > > - k Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 14:27 -0600, Grant Likely wrote: > > Unfortunately, I'm in the same boat. :-( However, I'll be at UDS in > 2 weeks time, and I know audio is a big concern for the Ubuntu folks. > A bunch of the ARM vendors will be there too. I'll schedule a session > to talk about audio bindings and hopefully that way make some headway > on defining a binding that makes sense and is actually useful. It's not clear if I'm going to UDS atm, but I'll join via IRC. Graeme is going to UDS so he will probably pop in to the discussion if he's free. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 10:28 -0500, Timur Tabi wrote: > Liam Girdwood wrote: > > > Iirc, the SSI and DMA controllers on your SoC mean that each DMA device > > can only do one direction (either Playback or Capture). So I'm thinking > > we create two DAI link entries for your sound card (one for playback and > > the other for capture) and they both use the same SSI device but each > > would have it's own DMA device. > > Do you mean here: > > machine_data->card.probe = mpc8610_hpcd_machine_probe; > machine_data->card.remove = mpc8610_hpcd_machine_remove; > machine_data->card.name = "MPC8610 HPCD"; > machine_data->card.num_links = 1; > machine_data->card.dai_link = &machine_data->dai; > > So that num_links would be 2 instead of 1? > Yes. > I would need some way for fsl_dma_open() to get a pointer to private, > DMA-specific data. I'm not sure how I can do that. > In multi-component we now have platform_data and device private data (from the regular driver model). We also have stream snd_soc_dai_set_dma_data() for runtime DMA config. So it depends on who is setting your DMA data. If it's DTS then it would be the of_ platform equivalent, if it's your DMA probe() then dev data otherwise you can use the snd_soc_dai_set_dma_data(). > > This would result in two separate pcm devices being exported to > > userspace i.e one for playback only and the other for capture only. I > > think this is also a more accurate representation of your hardware too > > (since we have different DMA devices for each pcm stream direction). > > I can say for certain whether that will actually work. My gut tells > me that I might run into problems trying to implement that. The only > way to know for sure is to start hacking. Unfortunately, my window of > opportunity to work on this just closed, and it may not open for a > while. I know my current patch is less-than-ideal, but it does > restore functionality to the 8610, and without needing any U-Boot or > device-tree changes. So unless there are any real objections, I'd > like it to be merged. Otherwise, 8610 audio will be broken in the > next release. Ok, I can live with this providing we can mark it as a TODO: and have a PPC Ack. It may be easier to fix in the future too as the ASoC card registration clean-up should be complete/in-progress (i.e. card platform_data and private_data will be available for passing in anything you like). Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 09:52 -0500, Timur Tabi wrote: > Liam Girdwood wrote: > > > Now I don't know the mechanics of adding an ASoC sound card to the > > device tree, but the device tree should be able to define an ASoC sound > > card and also represent the relationships between the sound card and the > > SSI/Codec/DMA components. The components should also be represented in > > the device tree. Parsing the device tree should probe() all the ASoC > > components and sound card. The ASoC core would then instantiated them as > > a sound device. > > Another problem is that ASoC won't let me probe the DMA channels > independently. That is, I cannot tell ASoC that I have a playback DMA > and a capture DMA. ASoC does not recognize two DMA devices for a > single SSI. If you can fix that, then I can turn the DMA driver into > an OF driver. > Iirc, the SSI and DMA controllers on your SoC mean that each DMA device can only do one direction (either Playback or Capture). So I'm thinking we create two DAI link entries for your sound card (one for playback and the other for capture) and they both use the same SSI device but each would have it's own DMA device. This would result in two separate pcm devices being exported to userspace i.e one for playback only and the other for capture only. I think this is also a more accurate representation of your hardware too (since we have different DMA devices for each pcm stream direction). Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
On Tue, 2010-04-27 at 16:36 +1000, Benjamin Herrenschmidt wrote: > On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote: > > An upcoming change in the architecture of ALSA SoC (ASoC) will require the > > MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver. > > Therefore, we need to call platform_device_register_simple() from the > > board's > > platform code. > > > > Signed-off-by: Timur Tabi > > --- > > Gross. Loses the linkage to device-tree etc... which is useful for audio > especially. You should at least make sure the device node follows for > the target driver to be able to use it :-) I'd like you to sync with > Grant work on that matter if you are going to convert of_devices into > platform_devices. Timur, please correct my device tree understanding form our IRC conversation if I'm wrong here. I think one of the difficulties encountered here is that the device tree root for sound in this case is the SSI (Digital Audio Interface) controller and not the sound card as in ASoC. So maybe the problem is how do we represent an ASoC sound card in the device tree ? The sound card within ASoC is a compound device that is made up of the SSI, Codec and audio DMA engine components. The SSI/Codec/DMA components do not have to be the sound cards child devices wrt the driver model but do register with the ASoC core and are 'joined' with each other and the sound card driver to form a working audio device. Now I don't know the mechanics of adding an ASoC sound card to the device tree, but the device tree should be able to define an ASoC sound card and also represent the relationships between the sound card and the SSI/Codec/DMA components. The components should also be represented in the device tree. Parsing the device tree should probe() all the ASoC components and sound card. The ASoC core would then instantiated them as a sound device. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/6] ASoC/mpc5200: Track DMA position by period number instead of bytes
On Sat, 2009-11-07 at 01:33 -0700, Grant Likely wrote:
> All DMA blocks are lined up to period boundaries, but the DMA
> handling code tracks bytes instead. This patch reworks the code
> to track the period index into the DMA buffer instead of the
> physical address pointer. Doing so makes the code simpler and
> easier to understand.
>
> Signed-off-by: Grant Likely
Very minor coding style thing below otherwise all get my Ack.
Acked-by: Liam Girdwood
> ---
>
> sound/soc/fsl/mpc5200_dma.c | 28 +---
> sound/soc/fsl/mpc5200_dma.h |8 ++--
> 2 files changed, 11 insertions(+), 25 deletions(-)
>
> diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c
> index 6096d22..986d3c8 100644
> --- a/sound/soc/fsl/mpc5200_dma.c
> +++ b/sound/soc/fsl/mpc5200_dma.c
> @@ -58,13 +58,11 @@ static void psc_dma_bcom_enqueue_next_buffer(struct
> psc_dma_stream *s)
> /* Prepare and enqueue the next buffer descriptor */
> bd = bcom_prepare_next_buffer(s->bcom_task);
> bd->status = s->period_bytes;
> - bd->data[0] = s->period_next_pt;
> + bd->data[0] = s->runtime->dma_addr + (s->period_next * s->period_bytes);
> bcom_submit_next_buffer(s->bcom_task, NULL);
>
> /* Update for next period */
> - s->period_next_pt += s->period_bytes;
> - if (s->period_next_pt >= s->period_end)
> - s->period_next_pt = s->period_start;
> + s->period_next = (s->period_next + 1) % s->runtime->periods;
> }
>
> static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream *s)
> @@ -79,7 +77,7 @@ static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream
> *s)
> if (bcom_queue_full(s->bcom_task))
> return;
>
> - s->appl_ptr += s->period_size;
> + s->appl_ptr += s->runtime->period_size;
>
> psc_dma_bcom_enqueue_next_buffer(s);
> }
> @@ -91,7 +89,7 @@ static void psc_dma_bcom_enqueue_tx(struct psc_dma_stream
> *s)
> if (bcom_queue_full(s->bcom_task))
> return;
>
> - s->appl_ptr += s->period_size;
> + s->appl_ptr += s->runtime->period_size;
>
> psc_dma_bcom_enqueue_next_buffer(s);
> }
> @@ -108,9 +106,7 @@ static irqreturn_t psc_dma_bcom_irq_tx(int irq, void
> *_psc_dma_stream)
> while (bcom_buffer_done(s->bcom_task)) {
> bcom_retrieve_buffer(s->bcom_task, NULL, NULL);
>
> - s->period_current_pt += s->period_bytes;
> - if (s->period_current_pt >= s->period_end)
> - s->period_current_pt = s->period_start;
> + s->period_current = (s->period_current+1) % s->runtime->periods;
I prefer a space around operators.
s->period_current = (s->period_current + 1) % s->runtime->periods;
Liam
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
On Wed, 2008-07-02 at 09:52 -0400, Jon Smirl wrote: > > I've been using asoc-v2 so it may not be possible to make this arch > independent in asoc-v1. Maybe try porting this to asoc-v2 and see if > a bunch of the registration complexity disappears. Most of soc-of.c > should be unnecessary. > > Liam, when is asoc-v2 going into mainline? Hopefully over the next 2 merge windows. I'm about to start queueing patches This also assumes Mark and I remain at our current work load levels. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers
On Wed, 2008-07-02 at 09:48 -0600, Grant Likely wrote: > On Wed, Jul 02, 2008 at 11:50:43AM +0200, Takashi Iwai wrote: > > > > This is a helper module and not necessarily manually selectable. > > Better to make the other driver selecting this. > > Yes, you're right. I hadn't put too much thought into the Kconfig stuff > for this patch because, at the moment, I'm viewing this as a temporary > solution until ASoCv2 is merged. > > Which raises another question: Liam and Mark, what is your opinion on > merging this driver? Is it something that you would merge with the v1 > API and then rework it when v2 is merged? Or would you rather it be > kept out until v2 is ready? I haven't even looked at the v2 API yet, so > I don't know how much rework is involved. > I'm happy with this atm for v1. We can then rework for V2. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver
On Tue, 2008-07-01 at 17:53 -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> ASoC Codec driver for the TLV320AIC26 device. This driver uses the ASoC
> v1 API, so I don't expect it to get merged as-is, but I want to get it
> out there for review.
> ---
>
> sound/soc/codecs/Kconfig |4
> sound/soc/codecs/Makefile |2
> sound/soc/codecs/tlv320aic26.c | 630
>
> 3 files changed, 636 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
> index 3903ab7..96c7bfe 100644
> --- a/sound/soc/codecs/Kconfig
> +++ b/sound/soc/codecs/Kconfig
> @@ -41,6 +41,10 @@ config SND_SOC_CS4270_VD33_ERRATA
> bool
> depends on SND_SOC_CS4270
>
> +config SND_SOC_TLV320AIC26
> + tristate "TI TLB320AIC26 Codec support"
> + depends on SND_SOC && SPI
> +
> config SND_SOC_TLV320AIC3X
> tristate
> depends on SND_SOC && I2C
> diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
> index 4e1314c..ec0cd93 100644
> --- a/sound/soc/codecs/Makefile
> +++ b/sound/soc/codecs/Makefile
> @@ -5,6 +5,7 @@ snd-soc-wm8753-objs := wm8753.o
> snd-soc-wm9712-objs := wm9712.o
> snd-soc-wm9713-objs := wm9713.o
> snd-soc-cs4270-objs := cs4270.o
> +snd-soc-tlv320aic26-objs := tlv320aic26.o
> snd-soc-tlv320aic3x-objs := tlv320aic3x.o
>
> obj-$(CONFIG_SND_SOC_AC97_CODEC) += snd-soc-ac97.o
> @@ -14,4 +15,5 @@ obj-$(CONFIG_SND_SOC_WM8753)+= snd-soc-wm8753.o
> obj-$(CONFIG_SND_SOC_WM9712) += snd-soc-wm9712.o
> obj-$(CONFIG_SND_SOC_WM9713) += snd-soc-wm9713.o
> obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o
> +obj-$(CONFIG_SND_SOC_TLV320AIC26)+= snd-soc-tlv320aic26.o
> obj-$(CONFIG_SND_SOC_TLV320AIC3X)+= snd-soc-tlv320aic3x.o
> diff --git a/sound/soc/codecs/tlv320aic26.c b/sound/soc/codecs/tlv320aic26.c
> new file mode 100644
> index 000..aee1dbc
> --- /dev/null
> +++ b/sound/soc/codecs/tlv320aic26.c
> @@ -0,0 +1,630 @@
> +/*
> + * Texas Instruments TLV320AIC26 low power audio CODEC
> + * ALSA SoC CODEC driver
> + *
> + * Copyright (C) 2008 Secret Lab Technologies Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +MODULE_DESCRIPTION("ASoC TLV320AIC26 codec driver");
> +MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>");
> +MODULE_LICENSE("GPL");
> +
> +/* AIC26 Registers */
> +#define AIC26_READ_COMMAND_WORD(addr)((1 << 15) | (addr << 5))
> +#define AIC26_WRITE_COMMAND_WORD(addr) ((0 << 15) | (addr << 5))
> +#define AIC26_PAGE_ADDR(page, offset)((page << 6) | offset)
> +#define AIC26_NUM_REGS AIC26_PAGE_ADDR(3, 0)
> +#define AIC26_REG_CACHE_SIZE (0x20) /* only page 2 cached */
> +#define AIC26_REG_IS_CACHED(addr)((addr & ~0x1f) == (2 << 6))
> +#define AIC26_REG_CACHE_ADDR(addr) (addr & 0x1f)
> +
> +/* Page 0: Auxillary data registers */
> +#define AIC26_REG_BAT1 AIC26_PAGE_ADDR(0, 0x05)
> +#define AIC26_REG_BAT2 AIC26_PAGE_ADDR(0, 0x06)
> +#define AIC26_REG_AUXAIC26_PAGE_ADDR(0, 0x07)
> +#define AIC26_REG_TEMP1 AIC26_PAGE_ADDR(0, 0x09)
> +#define AIC26_REG_TEMP2 AIC26_PAGE_ADDR(0, 0x0A)
> +
> +/* Page 1: Auxillary control registers */
> +#define AIC26_REG_AUX_ADCAIC26_PAGE_ADDR(1, 0x00)
> +#define AIC26_REG_STATUS AIC26_PAGE_ADDR(1, 0x01)
> +#define AIC26_REG_REFERENCE AIC26_PAGE_ADDR(1, 0x03)
> +#define AIC26_REG_RESET AIC26_PAGE_ADDR(1, 0x04)
> +
> +/* Page 2: Audio control registers */
> +#define AIC26_REG_AUDIO_CTRL1AIC26_PAGE_ADDR(2, 0x00)
> +#define AIC26_REG_ADC_GAIN AIC26_PAGE_ADDR(2, 0x01)
> +#define AIC26_REG_DAC_GAIN AIC26_PAGE_ADDR(2, 0x02)
> +#define AIC26_REG_SIDETONE AIC26_PAGE_ADDR(2, 0x03)
> +#define AIC26_REG_AUDIO_CTRL2AIC26_PAGE_ADDR(2, 0x04)
> +#define AIC26_REG_POWER_CTRL AIC26_PAGE_ADDR(2, 0x05)
> +#define AIC26_REG_AUDIO_CTRL3AIC26_PAGE_ADDR(2, 0x06)
> +
> +#define AIC26_REG_FILTER_COEFF_L_N0 AIC26_PAGE_ADDR(2, 0x07)
> +#define AIC26_REG_FILTER_COEFF_L_N1 AIC26_PAGE_ADDR(2, 0x08)
> +#define AIC26_REG_FILTER_COEFF_L_N2 AIC26_PAGE_ADDR(2, 0x09)
> +#define AIC26_REG_FILTER_COEFF_L_N3 AIC26_PAGE_ADDR(2, 0x0A)
> +#define AIC26_REG_FILTER_COEFF_L_N4 AIC26_PAGE_ADDR(2, 0x0B)
> +#define AIC26_REG_FILTER_COEFF_L_N5 AIC26_PAGE_ADDR(2, 0x0C)
> +#define AIC26_REG_FILTER_COEFF_L_D1 AIC26_PAGE_ADDR(2, 0x0D)
> +#define AIC26_REG_FILTER_COEFF_L_D2 AIC26_PAGE_ADDR(2, 0x0E)
> +#define AIC26_REG_FILTER_COEFF_L_D4 AIC26_PAGE_ADDR(2, 0x0F)
> +#define AIC26_REG_FILTER_COEFF_L_D5 AIC26_PAGE_ADDR(2, 0x10)
> +#define AIC26_REG_FILTER_COEFF_R_N0 AIC26_PAGE_ADDR(2, 0x11)
> +
Re: [alsa-devel] [PATCH 2/3] ALSA SoC: Add mpc5200-psc I2S driver
On Tue, 2008-07-01 at 17:53 -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> This is an I2S bus driver for the MPC5200 PSC device. It is probably
> will not be merged as-is because it uses v1 of the ASoC API, but I want
> to get it out there for comments.
Looks good, just minor comments.
> ---
>
> sound/soc/fsl/Kconfig |6
> sound/soc/fsl/Makefile |2
> sound/soc/fsl/mpc5200_psc_i2s.c | 899
> +++
> 3 files changed, 907 insertions(+), 0 deletions(-)
>
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index 257101f..5daa8d3 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -17,4 +17,10 @@ config SND_SOC_MPC8610_HPCD
> help
> Say Y if you want to enable audio on the Freescale MPC8610 HPCD.
>
> +config SND_SOC_MPC5200_I2S
> + bool "Freescale MPC5200 PSC in I2S mode driver"
Is this built-in only ?
> + depends on SND_SOC && PPC_MPC52xx
> + help
> + Say Y here to support the MPC5200 PSCs in I2S mode.
> +
> endmenu
> diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile
> index 62f680a..98729a1 100644
> --- a/sound/soc/fsl/Makefile
> +++ b/sound/soc/fsl/Makefile
> @@ -4,3 +4,5 @@ obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o
> # MPC8610 Platform Support
> obj-$(CONFIG_SND_SOC_MPC8610) += fsl_ssi.o fsl_dma.o
>
> +obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o
> +
> diff --git a/sound/soc/fsl/mpc5200_psc_i2s.c b/sound/soc/fsl/mpc5200_psc_i2s.c
> new file mode 100644
> index 000..81d0933
> --- /dev/null
> +++ b/sound/soc/fsl/mpc5200_psc_i2s.c
> @@ -0,0 +1,899 @@
> +/*
> + * Freescale MPC5200 PSC in I2S mode
> + * ALSA SoC Digital Audio Interface (DAI) driver
> + *
> + * Copyright (C) 2008 Secret Lab Technologies Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +MODULE_AUTHOR("Grant Likely <[EMAIL PROTECTED]>");
> +MODULE_DESCRIPTION("Freescale MPC5200 PSC in I2S mode ASoC Driver");
> +MODULE_LICENSE("GPL");
> +
> +/**
> + * PSC_I2S_RATES: sample rates supported by the I2S
> + *
> + * This driver currently only supports the PSC running in I2S slave mode,
> + * which means the codec determines the sample rate. Therefore, we tell
> + * ALSA that we support all rates and let the codec driver decide what rates
> + * are really supported.
> + */
> +#define PSC_I2S_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \
> + SNDRV_PCM_RATE_CONTINUOUS)
> +
> +/**
> + * PSC_I2S_FORMATS: audio formats supported by the PSC I2S mode
> + */
> +#define PSC_I2S_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | \
> + SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE | \
> + SNDRV_PCM_FMTBIT_S32_BE)
> +
> +/**
> + * psc_i2s_stream - Data specific to a single stream (playback or capture)
> + * @active: flag indicating if the stream is active
> + * @psc_i2s: pointer back to parent psc_i2s data structure
> + * @bcom_task: bestcomm task structure
> + * @irq: irq number for bestcomm task
> + * @period_start:physical address of start of DMA region
> + * @period_end: physical address of end of DMA region
> + * @period_next_pt: physical address of next DMA buffer to enqueue
> + * @period_bytes:size of DMA period in bytes
> + */
> +struct psc_i2s_stream {
> + int active;
> + struct psc_i2s *psc_i2s;
> + struct bcom_task *bcom_task;
> + int irq;
> + struct snd_pcm_substream *stream;
> + dma_addr_t period_start;
> + dma_addr_t period_end;
> + dma_addr_t period_next_pt;
> + dma_addr_t period_current_pt;
> + int period_bytes;
> +};
> +
> +/**
> + * psc_i2s - Private driver data
> + * @name: short name for this device ("PSC0", "PSC1", etc)
> + * @psc_regs: pointer to the PSC's registers
> + * @fifo_regs: pointer to the PSC's FIFO registers
> + * @irq: IRQ of this PSC
> + * @dev: struct device pointer
> + * @playback: the number of playback streams opened
> + * @capture: the number of capture streams opened
> + * @dai: the CPU DAI for this device
> + * @playback_stream: Playback stream context data
> + * @capture_stream: Capture stream context data
> + */
> +struct psc_i2s {
> + char name[32];
> + struct mpc52xx_psc __iomem *psc_regs;
> + struct mpc52xx_psc_fifo __iomem *fifo_regs;
> + unsigned int irq;
> + struct device *dev;
> + struct snd_soc_cpu_dai dai;
> + spinlock_t lock;
> +
> + /* per-stream data */
> + struct psc_i2s_stream playback_stream;
> + struct psc_i2s_stream capture_stream;
> +
> + /* Statistics */
> + struct {
> + int overrun_count;
> + int underrun_count;
> + } stats;
> +};
> +
> +/*
>
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Thu, 2008-01-10 at 00:41 -0500, Jon Smirl wrote: > ASOC v2 is sitting on a Wolfson server out of tree. I have been using > it for several months without problem. The pace of it being merged > could probably be sped up. I think we are probably looking at submission in the next 8 - 10 weeks. Currently most of the core code is complete, however some platforms and codecs still need porting. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [ALSA] Add ASoC drivers for the Freescale MPC8610 SoC
On Mon, 2008-01-07 at 12:56 -0600, Timur Tabi wrote: > Add the ASoC drivers for the Freescale MPC8610 SoC and the MPC8610 HPCD > reference board. > > Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> Acked-by: Liam Girdwood <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] [POWERPC] Update MPC8610 HPCD to support audio drivers
On Tue, 2008-01-08 at 11:56 +1100, Stephen Rothwell wrote:
> Hi Timur,
>
> On Mon, 7 Jan 2008 12:56:43 -0600 Timur Tabi <[EMAIL PROTECTED]> wrote:
> >
> > +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
> > @@ -34,9 +34,27 @@
> >
> > #include
> >
> > +#include
> > #include
> > #include
> >
> > +static struct of_device_id mpc8610_ids[] = {
>
> __initdata
>
> > + { .compatible = "fsl,mpc8610", },
> > + {}
> > +};
> > +
> > +static int __init mpc8610_declare_of_platform_devices(void)
> > +{
> > + if (!machine_is(mpc86xx_hpcd))
> > + return 0;
> > +
> > + /* Without this call, the SSI device driver won't get probed. */
> > + of_platform_bus_probe(NULL, mpc8610_ids, NULL);
> > +
> > + return 0;
> > +}
> > +device_initcall(mpc8610_declare_of_platform_devices);
>
> We have machine_device_initcall for this now.
>
Now changed in ASoC dev branch.
Liam
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/2] ASoC drivers for the Freescale MPC8610 SoC
On Mon, 2008-01-07 at 12:56 -0600, Timur Tabi wrote: > These patches add ALSA SoC device drivers for the Freescale MPC8610 SoC > and the MPC8610-HPCD reference board. > > The first patch updates some files in arch/powerpc and booting-without-of.txt. > > The second patch adds the new audio driver files to sound/soc. > > Both must be applied in order to avoid a build break. > Both applied to the dev branch. This should let others use them atm and allow us to port to ASoC v2. I'll make a start on the port now. Liam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Mon, 2008-01-07 at 09:52 -0600, Timur Tabi wrote: > > So all I'm trying to do now is get my driver, with warts and all, into the > tree > so that I can focus with Liam et al to get a real ASoC V2 up and running. > I'll commit the MPC8610 into the ASoC (v1) dev tree soon (hopefully tonight). This will allow folks to use it in the meantime whilst we sort out any changes. I'll then port (what I can) to V2, although I may need some assistance with some of the PPC sections. Fwiw we are looking at submitting V2 in March/April time. Liam PS. Sorry for the silence lately. We've just moved to a new opensource server over the holidays and have been without some services i.e. mail. Privacy & Confidentiality Notice - This message and any attachments contain privileged and confidential information that is intended solely for the person(s) to whom it is addressed. If you are not an intended recipient you must not: read; copy; distribute; discuss; take any action in or make any reliance upon the contents of this message; nor open or read any attachment. If you have received this message in error, please notify us as soon as possible on the following telephone number and destroy this message including any attachments. Thank you. - Wolfson Microelectronics plc Tel: +44 (0)131 272 7000 Fax: +44 (0)131 272 7001 Web: www.wolfsonmicro.com Registered in Scotland Company number SC089839 Registered office: Westfield House, 26 Westfield Road, Edinburgh, EH11 2QB, UK ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
