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 ju...@diku.dk 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/) // smpl @@ expression e,e1,e2; @@ *e = of_parse_phandle(...) ... when != of_node_put(e) when != true e == NULL when != e2 = e e = e1 // /smpl Signed-off-by: Julia Lawall ju...@diku.dk --- 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 l...@ti.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 ju...@diku.dk Signed-off-by: Timur Tabi ti...@freescale.com Acked-by: Liam Girdwood l...@ti.com --- 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: [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 ti...@freescale.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com 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 ti...@freescale.com Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Acked-by: Kumar Gala ga...@kernel.crashing.org - 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 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 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/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 grant.lik...@secretlab.ca
Very minor coding style thing below otherwise all get my Ack.
Acked-by: Liam Girdwood l...@slimlogic.co.uk
---
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 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 linux/init.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include linux/dma-mapping.h
+
+#include sound/core.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/initval.h
+#include sound/soc.h
+#include sound/soc-of.h
+
+#include sysdev/bestcomm/bestcomm.h
+#include sysdev/bestcomm/gen_bd.h
+#include asm/mpc52xx_psc.h
+
+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 */
+
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 linux/module.h +#include linux/moduleparam.h +#include linux/init.h +#include linux/delay.h +#include linux/pm.h +#include linux/device.h +#include linux/sysfs.h +#include linux/spi/spi.h +#include sound/core.h +#include sound/pcm.h +#include sound/pcm_params.h +#include sound/soc.h +#include sound/soc-dapm.h +#include sound/soc-of.h +#include sound/initval.h + +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
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 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] 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] [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 asm/mpic.h
+#include linux/of_platform.h
#include sysdev/fsl_pci.h
#include sysdev/fsl_soc.h
+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: [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: [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
