[alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
This patch adds ALSA SoC device drivers for the Freescale MPC8610 SoC and the MPC8610-HPCD reference board.
Signed-off-by: Timur Tabi timur@freescale.com ---
This patch applies on top of git://git.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git.
Documentation/powerpc/booting-without-of.txt | 40 ++ arch/powerpc/boot/dts/mpc8610_hpcd.dts | 107 ++++ arch/powerpc/configs/mpc8610_hpcd_defconfig | 171 ++++++- arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 18 + sound/soc/Kconfig | 1 + sound/soc/Makefile | 2 +- sound/soc/fsl/Kconfig | 21 + sound/soc/fsl/Makefile | 6 + sound/soc/fsl/fsl_dma.c | 819 ++++++++++++++++++++++++++ sound/soc/fsl/fsl_dma.h | 149 +++++ sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++ sound/soc/fsl/fsl_ssi.h | 224 +++++++ sound/soc/fsl/mpc8610_hpcd.c | 621 +++++++++++++++++++ 13 files changed, 2789 insertions(+), 4 deletions(-) create mode 100644 sound/soc/fsl/Kconfig create mode 100644 sound/soc/fsl/Makefile create mode 100644 sound/soc/fsl/fsl_dma.c create mode 100644 sound/soc/fsl/fsl_dma.h create mode 100644 sound/soc/fsl/fsl_ssi.c create mode 100644 sound/soc/fsl/fsl_ssi.h create mode 100644 sound/soc/fsl/mpc8610_hpcd.c
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index e9a3cb1..826af91 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -53,6 +53,7 @@ Table of Contents j) CFI or JEDEC memory-mapped NOR flash k) Global Utilities Block l) Xilinx IP cores + p) Freescale Synchronous Serial Interface
VII - Specifying interrupt information for devices 1) interrupts property @@ -2514,6 +2515,45 @@ platforms are moved over to use the flattened-device-tree model. Requred properties: - current-speed : Baud rate of uartlite
+ p) Freescale Synchronous Serial Interface + + The SSI is a serial device that communicates with audio codecs. It can + be programmed in AC97, I2S, left-justified, or right-justified modes. + + Required properties: + - compatible : compatible list, containing "fsl,ssi" + - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on + - reg : offset and length of the register set for the device + - interrupts : <a b> where a is the interrupt number and b is a + field that represents an encoding of the sense and + level information for the interrupt. This should be + encoded based on the information in section 2) + depending on the type of interrupt controller you + have. + - interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + - fsl,mode : the operating mode for the SSI interface + "i2s-slave" - I2S mode, SSI is clock slave + "i2s-master" - I2S mode, SSI is clock master + "lj-slave" - left-justified mode, SSI is clock slave + "lj-master" - l.j. mode, SSI is clock master + "rj-slave" - right-justified mode, SSI is clock slave + "rj-master" - r.j., SSI is clock master + "ac97-slave" - AC97 mode, SSI is clock slave + "ac97-master" - AC97 mode, SSI is clock master + + Optional properties: + - codec : child node that defines an audio codec connected + to this SSI + + Child 'codec' node required properties: + - compatible : compatible list, contains the name of the codec + + Child 'codec' node optional properties: + - bus-frequency : The frequency of the input clock, which typically + comes from an on-board dedicated oscillator. + + More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts index 966edf1..4f12ede 100644 --- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts +++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts @@ -103,6 +103,113 @@ reg = <e0000 1000>; fsl,has-rstcr; }; + + ssi@16000 { + compatible = "fsl,ssi"; + cell-index = <0>; + reg = <16000 100>; + interrupt-parent = <&mpic>; + interrupts = <3e 2>; + fsl,mode = "i2s-slave"; + codec { + compatible = "cirrus,cs4270"; + /* MCLK source is a stand-alone oscillator */ + bus-frequency = <bb8000>; + }; + }; + + ssi@16100 { + compatible = "fsl,ssi"; + cell-index = <1>; + reg = <16100 100>; + interrupt-parent = <&mpic>; + interrupts = <3f 2>; + }; + + dma@21300 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma"; + cell-index = <0>; + reg = <21300 4>; /* DMA general status register */ + ranges = <0 21100 200>; + + dma-channel@0 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <0>; + reg = <0 80>; + interrupt-parent = <&mpic>; + interrupts = <14 2>; + }; + dma-channel@1 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <1>; + reg = <80 80>; + interrupt-parent = <&mpic>; + interrupts = <15 2>; + }; + dma-channel@2 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <2>; + reg = <100 80>; + interrupt-parent = <&mpic>; + interrupts = <16 2>; + }; + dma-channel@3 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <3>; + reg = <180 80>; + interrupt-parent = <&mpic>; + interrupts = <17 2>; + }; + }; + + dma@c300 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,mpc8610-dma", "fsl,mpc8540-dma"; + cell-index = <1>; + reg = <c300 4>; /* DMA general status register */ + ranges = <0 c100 200>; + + dma-channel@0 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <0>; + reg = <0 80>; + interrupt-parent = <&mpic>; + interrupts = <3c 2>; + }; + dma-channel@1 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <1>; + reg = <80 80>; + interrupt-parent = <&mpic>; + interrupts = <3d 2>; + }; + dma-channel@2 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <2>; + reg = <100 80>; + interrupt-parent = <&mpic>; + interrupts = <3e 2>; + }; + dma-channel@3 { + compatible = "fsl,mpc8610-dma-channel", + "fsl,mpc8540-dma-channel"; + cell-index = <3>; + reg = <180 80>; + interrupt-parent = <&mpic>; + interrupts = <3f 2>; + }; + }; + };
pci@e0008000 { diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig b/arch/powerpc/configs/mpc8610_hpcd_defconfig index 0483211..fb68886 100644 --- a/arch/powerpc/configs/mpc8610_hpcd_defconfig +++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig @@ -684,7 +684,7 @@ CONFIG_SERIAL_8250_RSA=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set -CONFIG_SERIAL_OF_PLATFORM=y +# CONFIG_SERIAL_OF_PLATFORM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set @@ -699,7 +699,60 @@ CONFIG_UNIX98_PTYS=y # CONFIG_RAW_DRIVER is not set # CONFIG_TCG_TPM is not set CONFIG_DEVPORT=y -# CONFIG_I2C is not set +CONFIG_I2C=y +CONFIG_I2C_BOARDINFO=y +# CONFIG_I2C_CHARDEV is not set + +# +# I2C Algorithms +# +# CONFIG_I2C_ALGOBIT is not set +# CONFIG_I2C_ALGOPCF is not set +# CONFIG_I2C_ALGOPCA is not set + +# +# I2C Hardware Bus support +# +# CONFIG_I2C_ALI1535 is not set +# CONFIG_I2C_ALI1563 is not set +# CONFIG_I2C_ALI15X3 is not set +# CONFIG_I2C_AMD756 is not set +# CONFIG_I2C_AMD8111 is not set +# CONFIG_I2C_I801 is not set +# CONFIG_I2C_I810 is not set +# CONFIG_I2C_PIIX4 is not set +CONFIG_I2C_MPC=y +# CONFIG_I2C_NFORCE2 is not set +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_PROSAVAGE is not set +# CONFIG_I2C_SAVAGE4 is not set +# CONFIG_I2C_SIMTEC is not set +# CONFIG_I2C_SIS5595 is not set +# CONFIG_I2C_SIS630 is not set +# CONFIG_I2C_SIS96X is not set +# CONFIG_I2C_TAOS_EVM is not set +# CONFIG_I2C_VIA is not set +# CONFIG_I2C_VIAPRO is not set +# CONFIG_I2C_VOODOO3 is not set + +# +# Miscellaneous I2C Chip support +# +# CONFIG_SENSORS_DS1337 is not set +# CONFIG_SENSORS_DS1374 is not set +# CONFIG_DS1682 is not set +# CONFIG_SENSORS_EEPROM is not set +# CONFIG_SENSORS_PCF8574 is not set +# CONFIG_SENSORS_PCA9539 is not set +# CONFIG_SENSORS_PCF8591 is not set +# CONFIG_SENSORS_M41T00 is not set +# CONFIG_SENSORS_MAX6875 is not set +# CONFIG_SENSORS_TSL2550 is not set +# CONFIG_I2C_DEBUG_CORE is not set +# CONFIG_I2C_DEBUG_ALGO is not set +# CONFIG_I2C_DEBUG_BUS is not set +# CONFIG_I2C_DEBUG_CHIP is not set
# # SPI support @@ -746,7 +799,119 @@ CONFIG_DUMMY_CONSOLE=y # # Sound # -# CONFIG_SOUND is not set +CONFIG_SOUND=y + +# +# Advanced Linux Sound Architecture +# +CONFIG_SND=y +CONFIG_SND_TIMER=y +CONFIG_SND_PCM=y +# CONFIG_SND_SEQUENCER is not set +CONFIG_SND_OSSEMUL=y +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y +# CONFIG_SND_PCM_OSS_PLUGINS is not set +# CONFIG_SND_DYNAMIC_MINORS is not set +# CONFIG_SND_SUPPORT_OLD_API is not set +CONFIG_SND_VERBOSE_PROCFS=y +# CONFIG_SND_VERBOSE_PRINTK is not set +# CONFIG_SND_DEBUG is not set + +# +# Generic devices +# +# CONFIG_SND_DUMMY is not set +# CONFIG_SND_MTPAV is not set +# CONFIG_SND_SERIAL_U16550 is not set +# CONFIG_SND_MPU401 is not set + +# +# PCI devices +# +# CONFIG_SND_AD1889 is not set +# CONFIG_SND_ALS300 is not set +# CONFIG_SND_ALS4000 is not set +# CONFIG_SND_ALI5451 is not set +# CONFIG_SND_ATIIXP is not set +# CONFIG_SND_ATIIXP_MODEM is not set +# CONFIG_SND_AU8810 is not set +# CONFIG_SND_AU8820 is not set +# CONFIG_SND_AU8830 is not set +# CONFIG_SND_AZT3328 is not set +# CONFIG_SND_BT87X is not set +# CONFIG_SND_CA0106 is not set +# CONFIG_SND_CMIPCI is not set +# CONFIG_SND_CS4281 is not set +# CONFIG_SND_CS46XX is not set +# CONFIG_SND_CS5530 is not set +# CONFIG_SND_DARLA20 is not set +# CONFIG_SND_GINA20 is not set +# CONFIG_SND_LAYLA20 is not set +# CONFIG_SND_DARLA24 is not set +# CONFIG_SND_GINA24 is not set +# CONFIG_SND_LAYLA24 is not set +# CONFIG_SND_MONA is not set +# CONFIG_SND_MIA is not set +# CONFIG_SND_ECHO3G is not set +# CONFIG_SND_INDIGO is not set +# CONFIG_SND_INDIGOIO is not set +# CONFIG_SND_INDIGODJ is not set +# CONFIG_SND_EMU10K1 is not set +# CONFIG_SND_EMU10K1X is not set +# CONFIG_SND_ENS1370 is not set +# CONFIG_SND_ENS1371 is not set +# CONFIG_SND_ES1938 is not set +# CONFIG_SND_ES1968 is not set +# CONFIG_SND_FM801 is not set +# CONFIG_SND_HDA_INTEL is not set +# CONFIG_SND_HDSP is not set +# CONFIG_SND_HDSPM is not set +# CONFIG_SND_ICE1712 is not set +# CONFIG_SND_ICE1724 is not set +# CONFIG_SND_INTEL8X0 is not set +# CONFIG_SND_INTEL8X0M is not set +# CONFIG_SND_KORG1212 is not set +# CONFIG_SND_MAESTRO3 is not set +# CONFIG_SND_MIXART is not set +# CONFIG_SND_NM256 is not set +# CONFIG_SND_PCXHR is not set +# CONFIG_SND_RIPTIDE is not set +# CONFIG_SND_RME32 is not set +# CONFIG_SND_RME96 is not set +# CONFIG_SND_RME9652 is not set +# CONFIG_SND_SONICVIBES is not set +# CONFIG_SND_TRIDENT is not set +# CONFIG_SND_VIA82XX is not set +# CONFIG_SND_VIA82XX_MODEM is not set +# CONFIG_SND_VX222 is not set +# CONFIG_SND_YMFPCI is not set + +# +# ALSA PowerMac devices +# + +# +# ALSA PowerPC devices +# + +# +# System on Chip audio support +# +CONFIG_SND_SOC=y + +# +# SoC Audio support for SuperH +# + +# +# ALSA SoC audio for Freescale SOCs +# +CONFIG_SND_SOC_MPC8610=y +CONFIG_SND_SOC_MPC8610_HPCD=y +CONFIG_SND_SOC_CS4270=y +CONFIG_SND_SOC_CS4270_VD33_ERRATA=y + CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 6390895..6e1bde3 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -34,9 +34,27 @@
#include <asm/mpic.h>
+#include <asm/of_platform.h> #include <sysdev/fsl_pci.h> #include <sysdev/fsl_soc.h>
+static struct of_device_id mpc8610_ids[] = { + { .type = "soc", }, + {} +}; + +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); + void __init mpc86xx_hpcd_init_irq(void) { diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig index 97b2552..43bbc60 100644 --- a/sound/soc/Kconfig +++ b/sound/soc/Kconfig @@ -28,6 +28,7 @@ source "sound/soc/at91/Kconfig" source "sound/soc/pxa/Kconfig" source "sound/soc/s3c24xx/Kconfig" source "sound/soc/sh/Kconfig" +source "sound/soc/fsl/Kconfig"
# Supported codecs source "sound/soc/codecs/Kconfig" diff --git a/sound/soc/Makefile b/sound/soc/Makefile index 3041403..4869c9a 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -1,4 +1,4 @@ snd-soc-core-objs := soc-core.o soc-dapm.o
obj-$(CONFIG_SND_SOC) += snd-soc-core.o -obj-$(CONFIG_SND_SOC) += codecs/ at91/ pxa/ s3c24xx/ sh/ +obj-$(CONFIG_SND_SOC) += codecs/ at91/ pxa/ s3c24xx/ sh/ fsl/ diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig new file mode 100644 index 0000000..4a5bbd2 --- /dev/null +++ b/sound/soc/fsl/Kconfig @@ -0,0 +1,21 @@ +menu "ALSA SoC audio for Freescale SOCs" + +config SND_SOC_MPC8610 + bool "ALSA SoC support for the MPC8610 SOC" + depends on SND_SOC #&& MPC8610_HPCD + default y #if MPC8610 + help + Say Y if you want to add support for codecs attached to the SSI + device on an MPC8610. + +config SND_SOC_MPC8610_HPCD + # ALSA SoC support for Freescale MPC8610HPCD + bool "ALSA SoC support for the Freescale MPC8610 HPCD board" + depends on SND_SOC_MPC8610 + select SND_SOC_CS4270 + select SND_SOC_CS4270_VD33_ERRATA + default y #if MPC8610_HPCD + help + Say Y if you want to enable audio on the Freescale MPC8610 HPCD. + +endmenu diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile new file mode 100644 index 0000000..62f680a --- /dev/null +++ b/sound/soc/fsl/Makefile @@ -0,0 +1,6 @@ +# MPC8610 HPCD Machine Support +obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += mpc8610_hpcd.o + +# MPC8610 Platform Support +obj-$(CONFIG_SND_SOC_MPC8610) += fsl_ssi.o fsl_dma.o + diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c new file mode 100644 index 0000000..6b86be0 --- /dev/null +++ b/sound/soc/fsl/fsl_dma.c @@ -0,0 +1,819 @@ +/* + * Freescale DMA ALSA SoC PCM driver + * + * Author: Timur Tabi <timur@freescale.com> + * + * Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + * + * This driver implements ASoC support for the Elo DMA controller, which is + * the DMA controller on Freescale 83xx, 85xx, and 86xx SOCs. In ALSA terms, + * the PCM driver is what handles the DMA buffer. + */ + +#include <linux/module.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/dma-mapping.h> +#include <linux/interrupt.h> +#include <linux/delay.h> + +#include <sound/driver.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> + +#include <asm/io.h> + +#include "fsl_dma.h" + +/* + * The formats that the DMA controller supports, which is anything + * that is 8, 16, or 32 bits. + */ +#define FSLDMA_PCM_FORMATS (SNDRV_PCM_FMTBIT_S8 | \ + SNDRV_PCM_FMTBIT_U8 | \ + SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S16_BE | \ + SNDRV_PCM_FMTBIT_U16_LE | \ + SNDRV_PCM_FMTBIT_U16_BE | \ + SNDRV_PCM_FMTBIT_S24_LE | \ + SNDRV_PCM_FMTBIT_S24_BE | \ + SNDRV_PCM_FMTBIT_U24_LE | \ + SNDRV_PCM_FMTBIT_U24_BE | \ + SNDRV_PCM_FMTBIT_S32_LE | \ + SNDRV_PCM_FMTBIT_S32_BE | \ + SNDRV_PCM_FMTBIT_U32_LE | \ + SNDRV_PCM_FMTBIT_U32_BE) + +#define FSLDMA_PCM_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \ + SNDRV_PCM_RATE_CONTINUOUS) + +/* DMA global data. This structure is used by fsl_dma_open() to determine + * which DMA channels to assign to a substream. Unfortunately, ASoC V1 does + * not allow the machine driver to provide this information to the PCM + * driver in advance, and there's no way to differentiate between the two + * DMA controllers. So for now, this driver only supports one SSI device + * using two DMA channels. We cannot support multiple DMA devices. + * + * ssi_stx_phys: bus address of SSI STX register + * ssi_srx_phys: bus address of SSI SRX register + * dma_channel: pointer to the DMA channel's registers + * irq: IRQ for this DMA channel + * assigned: set to 1 if that DMA channel is assigned to a substream + */ +static struct { + dma_addr_t ssi_stx_phys; + dma_addr_t ssi_srx_phys; + struct ccsr_dma_channel __iomem *dma_channel[2]; + unsigned int irq[2]; + unsigned int assigned[2]; +} dma_global_data; + +/* + * The number of DMA links to use. Two is the bare minimum, but if you + * have really small links you might need more. + */ +#define NUM_DMA_LINKS 2 + +/* Per-substream DMA data + * + * Each substream has a 1-to-1 association with a DMA channel. + * + * The link[] array is first because it needs to be aligned on a 32-byte + * boundary, so putting it first will ensure alignment without padding the + * structure. + * + * link[]: array of link descriptors + * controller_id: which DMA controller (0, 1, ...) + * channel_id: which DMA channel on the controller (0, 1, 2, ...) + * dma_channel: pointer to the DMA channel's registers + * irq: IRQ for this DMA channel + * substream: pointer to the substream object, needed by the ISR + * ssi_sxx_phys: bus address of the STX or SRX register to use + * ld_buf_phys: physical address of the LD buffer + * current_link: index into link[] of the link currently being processed + * dma_buf_phys: physical address of the DMA buffer + * dma_buf_next: physical address of the next period to process + * dma_buf_end: physical address of the byte after the end of the DMA buffer + * period_size: the size of a single period + */ +struct fsl_dma_private { + struct fsl_dma_link_descriptor link[NUM_DMA_LINKS]; + unsigned int controller_id; + unsigned int channel_id; + struct ccsr_dma_channel __iomem *dma_channel; + unsigned int irq; + struct snd_pcm_substream *substream; + dma_addr_t ssi_sxx_phys; + dma_addr_t ld_buf_phys; + unsigned int current_link; + dma_addr_t dma_buf_phys; + dma_addr_t dma_buf_next; + dma_addr_t dma_buf_end; + size_t period_size; + unsigned int num_periods; +}; + +/* + * Define the hardware characteristics for the PCM hardware. + * + * The PCM hardware is the Freescale DMA controller. This structure defines + * the capabilities of that hardware. + * + * Since the sampling rate and data format are not controlled by the DMA + * controller, we specify no limits for those values. The only exception is + * period_bytes_min, which is set to a reasonably low value to prevent the + * DMA controller from generating too many interrupts per second. + * + * Since each link descriptor has a 32-bit byte count field, we set + * period_bytes_max to the largest 32-bit number. We also have no maximum + * number of periods. + */ +static const struct snd_pcm_hardware fsl_dma_hardware = { + + .info = SNDRV_PCM_INFO_INTERLEAVED, + .formats = FSLDMA_PCM_FORMATS, + .rates = FSLDMA_PCM_RATES, + .rate_min = 5512, + .rate_max = 192000, + .period_bytes_min = 512, /* A reasonable limit */ + .period_bytes_max = (u32) -1, + .periods_min = NUM_DMA_LINKS, + .periods_max = (unsigned int) -1, + .buffer_bytes_max = 128 * 1024, /* A reasonable limit */ +}; + +/* + * Tell ALSA that the DMA transfer has aborted + * + * This function should be called by the ISR whenever the DMA controller + * halts data transfer. + */ +static void fsl_dma_abort_stream(struct snd_pcm_substream *substream) +{ + unsigned long flags; + + snd_pcm_stream_lock_irqsave(substream, flags); + + if (snd_pcm_running(substream)) + snd_pcm_stop(substream, SNDRV_PCM_STATE_XRUN); + + snd_pcm_stream_unlock_irqrestore(substream, flags); +} + +/* + * Update the link descriptor pointers to point to the next period buffer. +*/ +static void fsl_dma_update_pointers(struct fsl_dma_private *dma_private) +{ + struct fsl_dma_link_descriptor *link = + &dma_private->link[dma_private->current_link]; + + /* Update our link descriptors to point to the next period */ + if (dma_private->substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + link->source_addr = + cpu_to_be32(dma_private->dma_buf_next); + else + link->dest_addr = + cpu_to_be32(dma_private->dma_buf_next); + + /* Update our variables for next time */ + dma_private->dma_buf_next += dma_private->period_size; + + if (dma_private->dma_buf_next >= dma_private->dma_buf_end) + dma_private->dma_buf_next = dma_private->dma_buf_phys; + + if (++dma_private->current_link >= NUM_DMA_LINKS) + dma_private->current_link = 0; +} + +/* + * Interrupt handler for the DMA controller + */ +static irqreturn_t fsl_dma_isr(int irq, void *dev_id) +{ + struct fsl_dma_private *dma_private = dev_id; + struct ccsr_dma_channel __iomem *dma_channel = dma_private->dma_channel; + irqreturn_t ret = IRQ_NONE; + u32 sr, sr2 = 0; + + /* We got an interrupt, so read the status register to see what we + were interrupted for. + */ + sr = in_be32(&dma_channel->sr); + + if (sr & CCSR_DMA_SR_TE) { + dev_err(dma_private->substream->pcm->card->dev, + "DMA transmit error (controller=%u channel=%u irq=%u\n", + dma_private->controller_id, + dma_private->channel_id, irq); + fsl_dma_abort_stream(dma_private->substream); + sr2 |= CCSR_DMA_SR_TE; + ret = IRQ_HANDLED; + } + + if (sr & CCSR_DMA_SR_CH) + ret = IRQ_HANDLED; + + if (sr & CCSR_DMA_SR_PE) { + dev_err(dma_private->substream->pcm->card->dev, + "DMA%u programming error (channel=%u irq=%u)\n", + dma_private->controller_id, + dma_private->channel_id, irq); + fsl_dma_abort_stream(dma_private->substream); + sr2 |= CCSR_DMA_SR_PE; + ret = IRQ_HANDLED; + } + + if (sr & CCSR_DMA_SR_EOLNI) { + sr2 |= CCSR_DMA_SR_EOLNI; + ret = IRQ_HANDLED; + } + + if (sr & CCSR_DMA_SR_CB) + ret = IRQ_HANDLED; + + if (sr & CCSR_DMA_SR_EOSI) { + struct snd_pcm_substream *substream = dma_private->substream; + + /* Tell ALSA we completed a period. */ + snd_pcm_period_elapsed(substream); + + /* + * Update our link descriptors to point to the next period. We + * only need to do this if the number of periods is not equal to + * the number of links. + */ + if (dma_private->num_periods != NUM_DMA_LINKS) + fsl_dma_update_pointers(dma_private); + + sr2 |= CCSR_DMA_SR_EOSI; + ret = IRQ_HANDLED; + } + + if (sr & CCSR_DMA_SR_EOLSI) { + sr2 |= CCSR_DMA_SR_EOLSI; + ret = IRQ_HANDLED; + } + + /* Clear the bits that we set */ + if (sr2) + out_be32(&dma_channel->sr, sr2); + + return ret; +} + +/* + * Initialize this PCM driver. + * + * This function is called when the codec driver calls snd_soc_new_pcms(), + * once for each .dai_link in the machine driver's snd_soc_machine + * structure. + */ +static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai *dai, + struct snd_pcm *pcm) +{ + static u64 fsl_dma_dmamask = 0xffffffff; + int ret; + + if (!card->dev->dma_mask) + card->dev->dma_mask = &fsl_dma_dmamask; + + if (!card->dev->coherent_dma_mask) + card->dev->coherent_dma_mask = fsl_dma_dmamask; + + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev, + fsl_dma_hardware.buffer_bytes_max, + &pcm->streams[0].substream->dma_buffer); + if (ret) { + dev_err(card->dev, + "Can't allocate playback DMA buffer (size=%u)\n", + fsl_dma_hardware.buffer_bytes_max); + return -ENOMEM; + } + + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV, pcm->dev, + fsl_dma_hardware.buffer_bytes_max, + &pcm->streams[1].substream->dma_buffer); + if (ret) { + snd_dma_free_pages(&pcm->streams[0].substream->dma_buffer); + dev_err(card->dev, + "Can't allocate capture DMA buffer (size=%u)\n", + fsl_dma_hardware.buffer_bytes_max); + return -ENOMEM; + } + + return 0; +} + +/* + * Open a new stream. + * + * Each stream has its own DMA buffer. + */ +static int fsl_dma_open(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct fsl_dma_private *dma_private; + dma_addr_t ld_buf_phys; + unsigned int channel; + int ret = 0; + + /* + * Reject any DMA buffer whose size is not a multiple of the period + * size. We need to make sure that the DMA buffer can be evenly divided + * into periods. + */ + ret = snd_pcm_hw_constraint_integer(runtime, + SNDRV_PCM_HW_PARAM_PERIODS); + if (ret < 0) { + dev_err(substream->pcm->card->dev, "invalid buffer size\n"); + return ret; + } + + channel = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ? 0 : 1; + + if (dma_global_data.assigned[channel]) { + dev_err(substream->pcm->card->dev, + "DMA channel already assigned\n"); + return -EBUSY; + } + + dma_private = dma_alloc_coherent(substream->pcm->dev, + sizeof(struct fsl_dma_private), &ld_buf_phys, GFP_KERNEL); + if (!dma_private) { + dev_err(substream->pcm->card->dev, + "can't allocate DMA private data\n"); + return -ENOMEM; + } + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + dma_private->ssi_sxx_phys = dma_global_data.ssi_stx_phys; + else + dma_private->ssi_sxx_phys = dma_global_data.ssi_srx_phys; + + dma_private->dma_channel = dma_global_data.dma_channel[channel]; + dma_private->irq = dma_global_data.irq[channel]; + dma_private->substream = substream; + dma_private->ld_buf_phys = ld_buf_phys; + dma_private->dma_buf_phys = substream->dma_buffer.addr; + + /* We only support one DMA controller for now */ + dma_private->controller_id = 0; + dma_private->channel_id = channel; + + ret = request_irq(dma_private->irq, fsl_dma_isr, 0, "DMA", dma_private); + if (ret) { + dev_err(substream->pcm->card->dev, + "can't register ISR for IRQ %u (ret=%i)\n", + dma_private->irq, ret); + dma_free_coherent(substream->pcm->dev, + sizeof(struct fsl_dma_private), + dma_private, dma_private->ld_buf_phys); + return ret; + } + + dma_global_data.assigned[channel] = 1; + + snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer); + snd_soc_set_runtime_hwparams(substream, &fsl_dma_hardware); + runtime->private_data = dma_private; + + return 0; +} + +/* + * Allocate the DMA buffer and the DMA link descriptors. + * + * ALSA divides the DMA buffer into N periods. We create NUM_DMA_LINKS link + * descriptors that ping-pong from one period to the next. For example, if + * there are six periods and two link descriptors, this is how they look + * before playback starts: + * + * The last link descriptor + * ____________ points back to the first + * | | + * V | + * ___ ___ | + * | |->| |->| + * |___| |___| + * | | + * | | + * V V + * _________________________________________ + * | | | | | | | The DMA buffer is + * | | | | | | | divided into 6 parts + * |______|______|______|______|______|______| + * + * and here's how they look after the first period is finished playing: + * + * ____________ + * | | + * V | + * ___ ___ | + * | |->| |->| + * |___| |___| + * | | + * |______________ + * | | + * V V + * _________________________________________ + * | | | | | | | + * | | | | | | | + * |______|______|______|______|______|______| + * + * The first link descriptor now points to the third period. The DMA + * controller is currently playing the second period. When it finishes, it + * will jump back to the first descriptor and play the third period. + * + * There are four reasons we do this: + * + * 1. The only way to get the DMA controller to automatically restart the + * transfer when it gets to the end of the buffer is to use chaining + * mode. Basic direct mode doesn't offer that feature. + * 2. We need to receive an interrupt at the end of every period. The DMA + * controller can generate an interrupt at the end of every link transfer + * (aka segment). Making each period into a DMA segment will give us the + * interrupts we need. + * 3. By creating only two link descriptors, regardless of the number of + * periods, we do not need to reallocate the link descriptors if the + * number of periods changes. + * 4. All of the audio data is still stored in a single, contiguous DMA + * buffer, which is what ALSA expects. We're just dividing it into + * contiguous parts, and creating a link descriptor for each one. + * + * Note that due to a quirk of the SSI's STX register, the target address + * for the DMA operations depends on the sample size. So we don't program + * the dest_addr (for playback -- source_addr for capture) fields in the + * link descriptors here. We do that in fsl_dma_prepare() + */ +static int fsl_dma_hw_params(struct snd_pcm_substream *substream, + struct snd_pcm_hw_params *hw_params) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct fsl_dma_private *dma_private = runtime->private_data; + struct ccsr_dma_channel __iomem *dma_channel = dma_private->dma_channel; + + dma_addr_t temp_addr; /* Pointer to next period */ + u64 temp_link; /* Pointer to next link descriptor */ + u32 mr; /* Temporary variable for MR register */ + + unsigned int i; + + /* Get all the parameters we need */ + size_t buffer_size = params_buffer_bytes(hw_params); + size_t period_size = params_period_bytes(hw_params); + + /* Initialize our DMA tracking variables */ + dma_private->period_size = period_size; + dma_private->num_periods = params_periods(hw_params); + dma_private->dma_buf_end = dma_private->dma_buf_phys + buffer_size; + dma_private->dma_buf_next = dma_private->dma_buf_phys + + (NUM_DMA_LINKS * period_size); + if (dma_private->dma_buf_next >= dma_private->dma_buf_end) + dma_private->dma_buf_next = dma_private->dma_buf_phys; + + /* + * Initialize each link descriptor. + * + * The actual address in STX0 (destination for playback, source for + * capture) is based on the sample size, but we don't know the sample + * size in this function, so we'll have to adjust that later. See + * comments in fsl_dma_prepare(). + * + * The DMA controller does not have a cache, so the CPU does not + * need to tell it to flush its cache. However, the DMA + * controller does need to tell the CPU to flush its cache. + * That's what the SNOOP bit does. + * + * Also, even though the DMA controller supports 36-bit addressing, for + * simplicity we currently support only 32-bit addresses for the audio + * buffer itself. + */ + temp_addr = substream->dma_buffer.addr; + temp_link = dma_private->ld_buf_phys + + sizeof(struct fsl_dma_link_descriptor); + + for (i = 0; i < NUM_DMA_LINKS; i++) { + struct fsl_dma_link_descriptor *link = &dma_private->link[i]; + + link->count = cpu_to_be32(period_size); + link->source_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP); + link->dest_attr = cpu_to_be32(CCSR_DMA_ATR_SNOOP); + link->next = cpu_to_be64(temp_link); + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + link->source_addr = cpu_to_be32(temp_addr); + else + link->dest_addr = cpu_to_be32(temp_addr); + + temp_addr += period_size; + temp_link += sizeof(struct fsl_dma_link_descriptor); + } + /* The last link descriptor points to the first */ + dma_private->link[i - 1].next = cpu_to_be64(dma_private->ld_buf_phys); + + /* Tell the DMA controller where the first link descriptor is */ + out_be32(&dma_channel->clndar, + CCSR_DMA_CLNDAR_ADDR(dma_private->ld_buf_phys)); + out_be32(&dma_channel->eclndar, + CCSR_DMA_ECLNDAR_ADDR(dma_private->ld_buf_phys)); + + /* The manual says the BCR must be clear before enabling EMP */ + out_be32(&dma_channel->bcr, 0); + + /* Program the mode register for interrupts, external master control, + and source/destination hold. Also clear the Channel Abort bit. + */ + mr = in_be32(&dma_channel->mr) & + ~(CCSR_DMA_MR_CA | CCSR_DMA_MR_DAHE | CCSR_DMA_MR_SAHE); + + /* + * We want External Master Start and External Master Pause enabled, + * because the SSI is controlling the DMA controller. We want the DMA + * controller to be set up in advance, and then we signal only the SSI + * to start transfering. + * + * We want End-Of-Segment Interrupts enabled, because this will generate + * an interrupt at the end of each segment (each link descriptor + * represents one segment). Each DMA segment is the same thing as an + * ALSA period, so this is how we get an interrupt at the end of every + * period. + * + * We want Error Interrupt enabled, so that we can get an error if + * the DMA controller is mis-programmed somehow. + */ + mr |= CCSR_DMA_MR_EOSIE | CCSR_DMA_MR_EIE | CCSR_DMA_MR_EMP_EN | + CCSR_DMA_MR_EMS_EN; + + /* For playback, we want the destination address to be held. For + capture, set the source address to be held. */ + mr |= (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ? + CCSR_DMA_MR_DAHE : CCSR_DMA_MR_SAHE; + + out_be32(&dma_channel->mr, mr); + + return 0; +} + +/* + * Prepare the DMA registers for playback. + * + * This function is called after the specifics of the audio data are known, + * i.e. snd_pcm_runtime is initialized. + * + * In this function, we finish programming the registers of the DMA + * controller that are dependent on the sample size. + * + * One of the drawbacks with big-endian is that when copying integers of + * different sizes to a fixed-sized register, the address to which the + * integer must be copied is dependent on the size of the integer. + * + * For example, if P is the address of a 32-bit register, and X is a 32-bit + * integer, then X should be copied to address P. However, if X is a 16-bit + * integer, then it should be copied to P+2. If X is an 8-bit register, + * then it should be copied to P+3. + * + * So for playback of 8-bit samples, the DMA controller must transfer single + * bytes from the DMA buffer to the last byte of the STX0 register, i.e. + * offset by 3 bytes. For 16-bit samples, the offset is two bytes. + * + * For 24-bit samples, the offset is 1 byte. However, the DMA controller + * does not support 3-byte copies (the DAHTS register supports only 1, 2, 4, + * and 8 bytes at a time). So we do not support packed 24-bit samples. + * 24-bit data must be padded to 32 bits. + */ +static int fsl_dma_prepare(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct fsl_dma_private *dma_private = runtime->private_data; + struct ccsr_dma_channel __iomem *dma_channel = dma_private->dma_channel; + u32 mr; + unsigned int i; + dma_addr_t ssi_sxx_phys; /* Bus address of SSI STX register */ + unsigned int frame_size; /* Number of bytes per frame */ + + ssi_sxx_phys = dma_private->ssi_sxx_phys; + + mr = in_be32(&dma_channel->mr) & ~(CCSR_DMA_MR_BWC_MASK | + CCSR_DMA_MR_SAHTS_MASK | CCSR_DMA_MR_DAHTS_MASK); + + switch (runtime->sample_bits) { + case 8: + mr |= CCSR_DMA_MR_DAHTS_1 | CCSR_DMA_MR_SAHTS_1; + ssi_sxx_phys += 3; + break; + case 16: + mr |= CCSR_DMA_MR_DAHTS_2 | CCSR_DMA_MR_SAHTS_2; + ssi_sxx_phys += 2; + break; + case 32: + mr |= CCSR_DMA_MR_DAHTS_4 | CCSR_DMA_MR_SAHTS_4; + break; + default: + dev_err(substream->pcm->card->dev, + "unsupported sample size %u\n", runtime->sample_bits); + return -EINVAL; + } + + frame_size = runtime->frame_bits / 8; + /* + * BWC should always be a multiple of the frame size. BWC determines + * how many bytes are sent/received before the DMA controller checks the + * SSI to see if it needs to stop. For playback, the transmit FIFO can + * hold three frames, so we want to send two frames at a time. For + * capture, the receive FIFO is triggered when it contains one frame, so + * we want to receive one frame at a time. + */ + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + mr |= CCSR_DMA_MR_BWC(2 * frame_size); + else + mr |= CCSR_DMA_MR_BWC(frame_size); + + out_be32(&dma_channel->mr, mr); + + /* + * Program the address of the DMA transfer to/from the SSI. + */ + for (i = 0; i < NUM_DMA_LINKS; i++) { + struct fsl_dma_link_descriptor *link = &dma_private->link[i]; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + link->dest_addr = cpu_to_be32(ssi_sxx_phys); + else + link->source_addr = cpu_to_be32(ssi_sxx_phys); + } + + return 0; +} + +/* + * fsl_dma_pointer - 'pointer' PCM operation callback function + * + * This function is called by ALSA when ALSA wants to know where in the + * stream buffer the hardware currently is. + * + * For playback, the SAR register contains the physical address of the most + * recent DMA transfer. For capture, the value is in the DAR register. + * + * The base address of the buffer is stored in the source_addr field of the + * first link descriptor. + */ +static snd_pcm_uframes_t fsl_dma_pointer(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct fsl_dma_private *dma_private = runtime->private_data; + struct ccsr_dma_channel __iomem *dma_channel = dma_private->dma_channel; + dma_addr_t position; + snd_pcm_uframes_t frames; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + position = in_be32(&dma_channel->sar); + else + position = in_be32(&dma_channel->dar); + + frames = bytes_to_frames(runtime, position - dma_private->dma_buf_phys); + + /* + * If the current address is just past the end of the buffer, wrap it + * around. + */ + if (frames == runtime->buffer_size) + frames = 0; + + return frames; +} + +/* + * Release the resources allocated in fsl_dma_hw_params() and + * de-program the registers. This function can be called multiple times. + */ +static int fsl_dma_hw_free(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct fsl_dma_private *dma_private = runtime->private_data; + + if (dma_private) { + struct ccsr_dma_channel __iomem *dma_channel; + + dma_channel = dma_private->dma_channel; + + dump_dma_regs(__FUNCTION__, __LINE__, dma_channel); + dump_lds(dma_private); + + /* Stop the DMA */ + out_be32(&dma_channel->mr, CCSR_DMA_MR_CA); + out_be32(&dma_channel->mr, 0); + + /* Reset all the other registers */ + out_be32(&dma_channel->sr, -1); + out_be32(&dma_channel->clndar, 0); + out_be32(&dma_channel->eclndar, 0); + out_be32(&dma_channel->satr, 0); + out_be32(&dma_channel->sar, 0); + out_be32(&dma_channel->datr, 0); + out_be32(&dma_channel->dar, 0); + out_be32(&dma_channel->bcr, 0); + out_be32(&dma_channel->nlndar, 0); + out_be32(&dma_channel->enlndar, 0); + } + + return 0; +} + +/* + * Close the stream. + */ +static int fsl_dma_close(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct fsl_dma_private *dma_private = runtime->private_data; + int dir = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ? 0 : 1; + + if (dma_private) { + if (dma_private->irq) + free_irq(dma_private->irq, dma_private); + + if (dma_private->ld_buf_phys) { + dma_unmap_single(substream->pcm->dev, + dma_private->ld_buf_phys, + sizeof(dma_private->link), DMA_TO_DEVICE); + } + + /* Deallocate the fsl_dma_private structure */ + dma_free_coherent(substream->pcm->dev, + sizeof(struct fsl_dma_private), + dma_private, dma_private->ld_buf_phys); + substream->runtime->private_data = NULL; + } + + dma_global_data.assigned[dir] = 0; + + return 0; +} + +/* + * Remove this PCM driver. + */ +static void fsl_dma_free_dma_buffers(struct snd_pcm *pcm) +{ + struct snd_pcm_substream *substream; + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(pcm->streams); i++) { + substream = pcm->streams[i].substream; + if (substream) { + snd_dma_free_pages(&substream->dma_buffer); + substream->dma_buffer.area = NULL; + substream->dma_buffer.addr = 0; + } + } +} + +static struct snd_pcm_ops fsl_dma_ops = { + .open = fsl_dma_open, + .close = fsl_dma_close, + .ioctl = snd_pcm_lib_ioctl, + .hw_params = fsl_dma_hw_params, + .hw_free = fsl_dma_hw_free, + .prepare = fsl_dma_prepare, + .pointer = fsl_dma_pointer, +}; + +struct snd_soc_platform fsl_soc_platform = { + .name = "fsl-dma", + .pcm_ops = &fsl_dma_ops, + .pcm_new = fsl_dma_new, + .pcm_free = fsl_dma_free_dma_buffers, +}; +EXPORT_SYMBOL_GPL(fsl_soc_platform); + +int fsl_dma_configure(struct fsl_dma_info *dma_info) +{ + static int initialized; + + /* We only support one DMA controller for now */ + if (initialized) + return 0; + + dma_global_data.ssi_stx_phys = dma_info->ssi_stx_phys; + dma_global_data.ssi_srx_phys = dma_info->ssi_srx_phys; + dma_global_data.dma_channel[0] = dma_info->dma_channel[0]; + dma_global_data.dma_channel[1] = dma_info->dma_channel[1]; + dma_global_data.irq[0] = dma_info->dma_irq[0]; + dma_global_data.irq[1] = dma_info->dma_irq[1]; + dma_global_data.assigned[0] = 0; + dma_global_data.assigned[1] = 0; + + initialized = 1; + return 1; +} +EXPORT_SYMBOL_GPL(fsl_dma_configure); + +MODULE_AUTHOR("Timur Tabi <timur@freescale.com>"); +MODULE_DESCRIPTION("Freescale FSL Elo DMA ASoC PCM module"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/fsl/fsl_dma.h b/sound/soc/fsl/fsl_dma.h new file mode 100644 index 0000000..430a6ce --- /dev/null +++ b/sound/soc/fsl/fsl_dma.h @@ -0,0 +1,149 @@ +/* + * mpc8610-pcm.h - ALSA PCM interface for the Freescale MPC8610 SoC + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef _MPC8610_PCM_H +#define _MPC8610_PCM_H + +struct ccsr_dma { + u8 res0[0x100]; + struct ccsr_dma_channel { + __be32 mr; /* Mode register */ + __be32 sr; /* Status register */ + __be32 eclndar; /* Current link descriptor extended addr reg */ + __be32 clndar; /* Current link descriptor address register */ + __be32 satr; /* Source attributes register */ + __be32 sar; /* Source address register */ + __be32 datr; /* Destination attributes register */ + __be32 dar; /* Destination address register */ + __be32 bcr; /* Byte count register */ + __be32 enlndar; /* Next link descriptor extended address reg */ + __be32 nlndar; /* Next link descriptor address register */ + u8 res1[4]; + __be32 eclsdar; /* Current list descriptor extended addr reg */ + __be32 clsdar; /* Current list descriptor address register */ + __be32 enlsdar; /* Next list descriptor extended address reg */ + __be32 nlsdar; /* Next list descriptor address register */ + __be32 ssr; /* Source stride register */ + __be32 dsr; /* Destination stride register */ + u8 res2[0x38]; + } channel[4]; + __be32 dgsr; +}; + +#define CCSR_DMA_MR_BWC_DISABLED 0x0F000000 +#define CCSR_DMA_MR_BWC_SHIFT 24 +#define CCSR_DMA_MR_BWC_MASK 0x0F000000 +#define CCSR_DMA_MR_BWC(x) \ + ((ilog2(x) << CCSR_DMA_MR_BWC_SHIFT) & CCSR_DMA_MR_BWC_MASK) +#define CCSR_DMA_MR_EMP_EN 0x00200000 +#define CCSR_DMA_MR_EMS_EN 0x00040000 +#define CCSR_DMA_MR_DAHTS_MASK 0x00030000 +#define CCSR_DMA_MR_DAHTS_1 0x00000000 +#define CCSR_DMA_MR_DAHTS_2 0x00010000 +#define CCSR_DMA_MR_DAHTS_4 0x00020000 +#define CCSR_DMA_MR_DAHTS_8 0x00030000 +#define CCSR_DMA_MR_SAHTS_MASK 0x0000C000 +#define CCSR_DMA_MR_SAHTS_1 0x00000000 +#define CCSR_DMA_MR_SAHTS_2 0x00004000 +#define CCSR_DMA_MR_SAHTS_4 0x00008000 +#define CCSR_DMA_MR_SAHTS_8 0x0000C000 +#define CCSR_DMA_MR_DAHE 0x00002000 +#define CCSR_DMA_MR_SAHE 0x00001000 +#define CCSR_DMA_MR_SRW 0x00000400 +#define CCSR_DMA_MR_EOSIE 0x00000200 +#define CCSR_DMA_MR_EOLNIE 0x00000100 +#define CCSR_DMA_MR_EOLSIE 0x00000080 +#define CCSR_DMA_MR_EIE 0x00000040 +#define CCSR_DMA_MR_XFE 0x00000020 +#define CCSR_DMA_MR_CDSM_SWSM 0x00000010 +#define CCSR_DMA_MR_CA 0x00000008 +#define CCSR_DMA_MR_CTM 0x00000004 +#define CCSR_DMA_MR_CC 0x00000002 +#define CCSR_DMA_MR_CS 0x00000001 + +#define CCSR_DMA_SR_TE 0x00000080 +#define CCSR_DMA_SR_CH 0x00000020 +#define CCSR_DMA_SR_PE 0x00000010 +#define CCSR_DMA_SR_EOLNI 0x00000008 +#define CCSR_DMA_SR_CB 0x00000004 +#define CCSR_DMA_SR_EOSI 0x00000002 +#define CCSR_DMA_SR_EOLSI 0x00000001 + +/* ECLNDAR takes bits 32-36 of the CLNDAR register */ +static inline u32 CCSR_DMA_ECLNDAR_ADDR(u64 x) +{ + return (x >> 32) & 0xf; +} + +#define CCSR_DMA_CLNDAR_ADDR(x) ((x) & 0xFFFFFFFE) +#define CCSR_DMA_CLNDAR_EOSIE 0x00000008 + +/* SATR and DATR, combined */ +#define CCSR_DMA_ATR_PBATMU 0x20000000 +#define CCSR_DMA_ATR_TFLOWLVL_0 0x00000000 +#define CCSR_DMA_ATR_TFLOWLVL_1 0x06000000 +#define CCSR_DMA_ATR_TFLOWLVL_2 0x08000000 +#define CCSR_DMA_ATR_TFLOWLVL_3 0x0C000000 +#define CCSR_DMA_ATR_PCIORDER 0x02000000 +#define CCSR_DMA_ATR_SME 0x01000000 +#define CCSR_DMA_ATR_NOSNOOP 0x00040000 +#define CCSR_DMA_ATR_SNOOP 0x00050000 +#define CCSR_DMA_ATR_ESAD_MASK 0x0000000F + +/** + * List Descriptor for extended chaining mode DMA operations. + * + * The CLSDAR register points to the first (in a linked-list) List + * Descriptor. Each object must be aligned on a 32-byte boundary. Each + * list descriptor points to a linked-list of link Descriptors. + */ +struct fsl_dma_list_descriptor { + __be64 next; /* Address of next list descriptor */ + __be64 first_link; /* Address of first link descriptor */ + __be32 source; /* Source stride */ + __be32 dest; /* Destination stride */ + u8 res[8]; /* Reserved */ +} __attribute__ ((aligned(32), packed)); + +/** + * Link Descriptor for basic and extended chaining mode DMA operations. + * + * A Link Descriptor points to a single DMA buffer. Each link descriptor + * must be aligned on a 32-byte boundary. + */ +struct fsl_dma_link_descriptor { + __be32 source_attr; /* Programmed into SATR register */ + __be32 source_addr; /* Programmed into SAR register */ + __be32 dest_attr; /* Programmed into DATR register */ + __be32 dest_addr; /* Programmed into DAR register */ + __be64 next; /* Address of next link descriptor */ + __be32 count; /* Byte count */ + u8 res[4]; /* Reserved */ +} __attribute__ ((aligned(32), packed)); + +/* DMA information needed to create a snd_soc_cpu_dai object + * + * ssi_stx_phys: bus address of SSI STX register to use + * ssi_srx_phys: bus address of SSI SRX register to use + * dma[0]: points to the DMA channel to use for playback + * dma[1]: points to the DMA channel to use for capture + * dma_irq[0]: IRQ of the DMA channel to use for playback + * dma_irq[1]: IRQ of the DMA channel to use for capture + */ +struct fsl_dma_info { + dma_addr_t ssi_stx_phys; + dma_addr_t ssi_srx_phys; + struct ccsr_dma_channel __iomem *dma_channel[2]; + unsigned int dma_irq[2]; +}; + +extern struct snd_soc_platform fsl_soc_platform; + +int fsl_dma_configure(struct fsl_dma_info *dma_info); + +#endif diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c new file mode 100644 index 0000000..a219e58 --- /dev/null +++ b/sound/soc/fsl/fsl_ssi.c @@ -0,0 +1,614 @@ +/* + * Freescale SSI ALSA SoC Digital Audio Interface (DAI) driver + * + * Author: Timur Tabi <timur@freescale.com> + * + * Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ + +#include <linux/init.h> +#include <linux/module.h> +#include <linux/interrupt.h> +#include <linux/device.h> +#include <linux/delay.h> + +#include <sound/driver.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/initval.h> +#include <sound/soc.h> + +#include <asm/immap_86xx.h> + +#include "fsl_ssi.h" + +/* + * The sample rates supported by the I2S + * + * This driver currently only supports the SSI 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 FSLSSI_I2S_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \ + SNDRV_PCM_RATE_CONTINUOUS) + +/* + * The audio formats supported by the SSI + * + * This driver currently only supports the SSI running in I2S slave mode. + * + * The SSI has a limitation in that the samples must be in the same byte + * order as the host CPU. This is because when multiple bytes are written + * to the STX register, the bytes and bits must be written in the same + * order. The STX is a shift register, so all the bits need to be aligned + * (bit-endianness must match byte-endianness). Processors typically write + * the bits within a byte in the same order that the bytes of a word are + * written in. So if the host CPU is big-endian, then only big-endian + * samples will be written to STX properly. + */ +#ifdef __BIG_ENDIAN +#define FSLSSI_I2S_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | \ + SNDRV_PCM_FMTBIT_S18_3BE | SNDRV_PCM_FMTBIT_S20_3BE | \ + SNDRV_PCM_FMTBIT_S24_3BE | SNDRV_PCM_FMTBIT_S24_BE) +#else +#define FSLSSI_I2S_FORMATS (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | \ + SNDRV_PCM_FMTBIT_S18_3LE | SNDRV_PCM_FMTBIT_S20_3LE | \ + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S24_LE) +#endif + +/* SSI information. + * + * name: short name for this device ("SSI0", "SSI1", etc) + * ssi: pointer to the SSI's registers + * ssi_phys: physical address of the SSI registers + * irq: IRQ of this SSI + * dev: struct device pointer + * playback: the number of playback streams opened + * capture: the number of capture streams opened + */ +struct fsl_ssi_private { + char name[8]; + struct ccsr_ssi __iomem *ssi; + dma_addr_t ssi_phys; + unsigned int irq; + struct device *dev; + unsigned int playback; + unsigned int capture; + struct snd_soc_cpu_dai cpu_dai; + struct device_attribute dev_attr; + + struct { + unsigned int rfrc; + unsigned int tfrc; + unsigned int cmdau; + unsigned int cmddu; + unsigned int rxt; + unsigned int rdr1; + unsigned int rdr0; + unsigned int tde1; + unsigned int tde0; + unsigned int roe1; + unsigned int roe0; + unsigned int tue1; + unsigned int tue0; + unsigned int tfs; + unsigned int rfs; + unsigned int tls; + unsigned int rls; + unsigned int rff1; + unsigned int rff0; + unsigned int tfe1; + unsigned int tfe0; + } stats; +}; + +/* + * SSI interrupt handler. + * + * Do we even want an SSI interrupt handler? Maybe for error handling, but + * buffer processing is handled via DMA interrupts. + */ +static irqreturn_t fsl_ssi_isr(int irq, void *dev_id) +{ + struct fsl_ssi_private *ssi_private = dev_id; + struct ccsr_ssi __iomem *ssi = ssi_private->ssi; + irqreturn_t ret = IRQ_NONE; + __be32 sisr; + __be32 sisr2 = 0; + + /* We got an interrupt, so read the status register to see what we + were interrupted for. We mask it with the Interrupt Enable register + so that we only check for events that we're interested in. + */ + sisr = in_be32(&ssi->sisr) & in_be32(&ssi->sier); + + if (sisr & CCSR_SSI_SISR_RFRC) { + ssi_private->stats.rfrc++; + sisr2 |= CCSR_SSI_SISR_RFRC; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TFRC) { + ssi_private->stats.tfrc++; + sisr2 |= CCSR_SSI_SISR_TFRC; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_CMDAU) { + ssi_private->stats.cmdau++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_CMDDU) { + ssi_private->stats.cmddu++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RXT) { + ssi_private->stats.rxt++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RDR1) { + ssi_private->stats.rdr1++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RDR0) { + ssi_private->stats.rdr0++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TDE1) { + ssi_private->stats.tde1++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TDE0) { + ssi_private->stats.tde0++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_ROE1) { + ssi_private->stats.roe1++; + sisr2 |= CCSR_SSI_SISR_ROE1; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_ROE0) { + ssi_private->stats.roe0++; + sisr2 |= CCSR_SSI_SISR_ROE0; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TUE1) { + ssi_private->stats.tue1++; + sisr2 |= CCSR_SSI_SISR_TUE1; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TUE0) { + ssi_private->stats.tue0++; + sisr2 |= CCSR_SSI_SISR_TUE0; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TFS) { + ssi_private->stats.tfs++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RFS) { + ssi_private->stats.rfs++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TLS) { + ssi_private->stats.tls++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RLS) { + ssi_private->stats.rls++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RFF1) { + ssi_private->stats.rff1++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_RFF0) { + ssi_private->stats.rff0++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TFE1) { + ssi_private->stats.tfe1++; + ret = IRQ_HANDLED; + } + + if (sisr & CCSR_SSI_SISR_TFE0) { + ssi_private->stats.tfe0++; + ret = IRQ_HANDLED; + } + + /* Clear the bits that we set */ + if (sisr2) + out_be32(&ssi->sisr, sisr2); + + return ret; +} + +/* + * Startup + * + * This is the first function called when a stream is opened. + * + * If this is the first stream open, then grab the IRQ and program most of + * the SSI registers. + */ +static int fsl_ssi_startup(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct fsl_ssi_private *ssi_private = rtd->dai->cpu_dai->private_data; + + /* + * If this is the first stream opened, then request the IRQ + * and initialize the SSI registers. + */ + if (!ssi_private->playback && !ssi_private->capture) { + struct ccsr_ssi __iomem *ssi = ssi_private->ssi; + int ret; + + ret = request_irq(ssi_private->irq, fsl_ssi_isr, 0, + ssi_private->name, ssi_private); + if (ret < 0) { + dev_err(substream->pcm->card->dev, + "could not claim irq %u\n", ssi_private->irq); + return ret; + } + + /* + * Section 16.5 of the MPC8610 reference manual says that the + * SSI needs to be disabled before updating the registers we set + * here. + */ + clrbits32(&ssi->scr, CCSR_SSI_SCR_SSIEN); + + /* + * Program the SSI into I2S Slave Non-Network Synchronous mode. + * Also enable the transmit and receive FIFO. + * + * FIXME: Little-endian samples require a different shift dir + */ + clrsetbits_be32(&ssi->scr, CCSR_SSI_SCR_I2S_MODE_MASK, + CCSR_SSI_SCR_TFR_CLK_DIS | + CCSR_SSI_SCR_I2S_MODE_SLAVE | CCSR_SSI_SCR_SYN); + + out_be32(&ssi->stcr, + CCSR_SSI_STCR_TXBIT0 | CCSR_SSI_STCR_TFEN0 | + CCSR_SSI_STCR_TFSI | CCSR_SSI_STCR_TEFS | + CCSR_SSI_STCR_TSCKP); + + out_be32(&ssi->srcr, + CCSR_SSI_SRCR_RXBIT0 | CCSR_SSI_SRCR_RFEN0 | + CCSR_SSI_SRCR_RFSI | CCSR_SSI_SRCR_REFS | + CCSR_SSI_SRCR_RSCKP); + + /* + * The DC and PM bits are only used if the SSI is the clock + * master. + */ + + /* 4. Enable the interrupts and DMA requests */ + out_be32(&ssi->sier, + CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_TDMAE | + CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TUE0_EN | + CCSR_SSI_SIER_TUE1_EN | CCSR_SSI_SIER_RFRC_EN | + CCSR_SSI_SIER_RDMAE | CCSR_SSI_SIER_RIE | + CCSR_SSI_SIER_ROE0_EN | CCSR_SSI_SIER_ROE1_EN); + + /* + * Set the watermark for transmit FIFI 0 and receive FIFO 0. We + * don't use FIFO 1. Since the SSI only supports stereo, the + * watermark should never be an odd number. + */ + out_be32(&ssi->sfcsr, + CCSR_SSI_SFCSR_TFWM0(6) | CCSR_SSI_SFCSR_RFWM0(2)); + + /* + * We keep the SSI disabled because if we enable it, then the + * DMA controller will start. It's not supposed to start until + * the SCR.TE (or SCR.RE) bit is set, but it does anyway. The + * DMA controller will transfer one "BWC" of data (i.e. the + * amount of data that the MR.BWC bits are set to). The reason + * this is bad is because at this point, the PCM driver has not + * finished initializing the DMA controller. + */ + } + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + ssi_private->playback++; + + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) + ssi_private->capture++; + + return 0; +} + +/* + * Prepare the SSI. + * + * Most of the SSI registers have been programmed in the startup function, + * but the word length must be programmed here. Unfortunately, programming + * the SxCCR.WL bits requires the SSI to be temporarily disabled. This can + * cause a problem with supporting simultaneous playback and capture. If + * the SSI is already playing a stream, then that stream may be temporarily + * stopped when you start capture. + * + * Note: The SxCCR.DC and SxCCR.PM bits are only used if the SSI is the + * clock master. + */ +static int fsl_ssi_prepare(struct snd_pcm_substream *substream) +{ + struct snd_pcm_runtime *runtime = substream->runtime; + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct fsl_ssi_private *ssi_private = rtd->dai->cpu_dai->private_data; + + struct ccsr_ssi __iomem *ssi = ssi_private->ssi; + u32 wl; + + wl = CCSR_SSI_SxCCR_WL(snd_pcm_format_width(runtime->format)); + + clrbits32(&ssi->scr, CCSR_SSI_SCR_SSIEN); + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + clrsetbits_be32(&ssi->stccr, CCSR_SSI_SxCCR_WL_MASK, wl); + else + clrsetbits_be32(&ssi->srccr, CCSR_SSI_SxCCR_WL_MASK, wl); + + setbits32(&ssi->scr, CCSR_SSI_SCR_SSIEN); + + return 0; +} + +/* + * Start and stop the DMA transfer. + * + * This function is called by ALSA to start, stop, pause, and resume the DMA + * transfer of data. + * + * The SSI has put the DMA in external master start and pause mode, which + * means the SSI completely controls the flow of data. + */ +static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct fsl_ssi_private *ssi_private = rtd->dai->cpu_dai->private_data; + struct ccsr_ssi __iomem *ssi = ssi_private->ssi; + + switch (cmd) { + case SNDRV_PCM_TRIGGER_START: + case SNDRV_PCM_TRIGGER_RESUME: + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { + setbits32(&ssi->scr, CCSR_SSI_SCR_TE); + } else { + setbits32(&ssi->scr, CCSR_SSI_SCR_RE); + + /* + * I have no idea why we need a delay here. Without it, + * the DMA won't start (or the SSI won't tell the DMA to + * start). + */ + msleep(1); + } + break; + + case SNDRV_PCM_TRIGGER_STOP: + case SNDRV_PCM_TRIGGER_SUSPEND: + case SNDRV_PCM_TRIGGER_PAUSE_PUSH: + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + clrbits32(&ssi->scr, CCSR_SSI_SCR_TE); + else + clrbits32(&ssi->scr, CCSR_SSI_SCR_RE); + break; + + default: + return -EINVAL; + } + + return 0; +} + +/* + * Shutdown. Clear DMA parameters and shutdown the SSI if there + * are no other substreams open. + */ +static void fsl_ssi_shutdown(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct fsl_ssi_private *ssi_private = rtd->dai->cpu_dai->private_data; + + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + ssi_private->playback--; + + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) + ssi_private->capture--; + + /* + * If this is the last active substream, disable the SSI and release + * the IRQ. + */ + if (!ssi_private->playback && !ssi_private->capture) { + struct ccsr_ssi __iomem *ssi = ssi_private->ssi; + + clrbits32(&ssi->scr, CCSR_SSI_SCR_SSIEN); + + free_irq(ssi_private->irq, ssi_private); + } +} + +/* Set the clock frequency and direction + * + * This function is called by the machine driver to tell us what the clock + * frequency and direction are. + * + * Currently, we only support operating as a clock slave (SND_SOC_CLOCK_IN), + * and we don't care about the frequency. Return an error if the direction + * is not SND_SOC_CLOCK_IN. + */ +static int fsl_ssi_set_sysclk(struct snd_soc_cpu_dai *cpu_dai, + int clk_id, unsigned int freq, int dir) +{ + + return (dir == SND_SOC_CLOCK_IN) ? 0 : -EINVAL; +} + +/* Set the serial format. + * + * This function is called by the machine driver to tell us what serial + * format to use. + * + * Currently, we only support I2S mode. Return an error if the format is + * not SND_SOC_DAIFMT_I2S. + */ +static int fsl_ssi_set_fmt(struct snd_soc_cpu_dai *cpu_dai, unsigned int format) +{ + return (format == SND_SOC_DAIFMT_I2S) ? 0 : -EINVAL; +} + +/* + * Template CPU DAI for the SSI + */ +static struct snd_soc_cpu_dai fsl_ssi_dai_template = { + .playback = { + /* The SSI does not support monaural audio. */ + .channels_min = 2, + .channels_max = 2, + .rates = FSLSSI_I2S_RATES, + .formats = FSLSSI_I2S_FORMATS, + }, + .capture = { + .channels_min = 2, + .channels_max = 2, + .rates = FSLSSI_I2S_RATES, + .formats = FSLSSI_I2S_FORMATS, + }, + .ops = { + .startup = fsl_ssi_startup, + .prepare = fsl_ssi_prepare, + .shutdown = fsl_ssi_shutdown, + .trigger = fsl_ssi_trigger, + }, + .dai_ops = { + .set_sysclk = fsl_ssi_set_sysclk, + .set_fmt = fsl_ssi_set_fmt, + }, +}; + +static ssize_t fsl_sysfs_ssi_show(struct device *dev, + struct device_attribute *attr, char *buf) +{ + struct fsl_ssi_private *ssi_private = + container_of(attr, struct fsl_ssi_private, dev_attr); + ssize_t length; + + length = sprintf(buf, "rfrc=%u", ssi_private->stats.rfrc); + length += sprintf(buf + length, "\ttfrc=%u", ssi_private->stats.tfrc); + length += sprintf(buf + length, "\tcmdau=%u", ssi_private->stats.cmdau); + length += sprintf(buf + length, "\tcmddu=%u", ssi_private->stats.cmddu); + length += sprintf(buf + length, "\trxt=%u", ssi_private->stats.rxt); + length += sprintf(buf + length, "\trdr1=%u", ssi_private->stats.rdr1); + length += sprintf(buf + length, "\trdr0=%u", ssi_private->stats.rdr0); + length += sprintf(buf + length, "\ttde1=%u", ssi_private->stats.tde1); + length += sprintf(buf + length, "\ttde0=%u", ssi_private->stats.tde0); + length += sprintf(buf + length, "\troe1=%u", ssi_private->stats.roe1); + length += sprintf(buf + length, "\troe0=%u", ssi_private->stats.roe0); + length += sprintf(buf + length, "\ttue1=%u", ssi_private->stats.tue1); + length += sprintf(buf + length, "\ttue0=%u", ssi_private->stats.tue0); + length += sprintf(buf + length, "\ttfs=%u", ssi_private->stats.tfs); + length += sprintf(buf + length, "\trfs=%u", ssi_private->stats.rfs); + length += sprintf(buf + length, "\ttls=%u", ssi_private->stats.tls); + length += sprintf(buf + length, "\trls=%u", ssi_private->stats.rls); + length += sprintf(buf + length, "\trff1=%u", ssi_private->stats.rff1); + length += sprintf(buf + length, "\trff0=%u", ssi_private->stats.rff0); + length += sprintf(buf + length, "\ttfe1=%u", ssi_private->stats.tfe1); + length += sprintf(buf + length, "\ttfe0=%u\n", ssi_private->stats.tfe0); + + return length; +} + +/* Create a snd_soc_cpu_dai structure + * + * This function is called by the machine driver to create a snd_soc_cpu_dai + * structure. A private data structure, with SSI hardware information, is + * appended to it. + */ +struct snd_soc_cpu_dai *fsl_ssi_create_dai(struct fsl_ssi_info *ssi_info) +{ + struct snd_soc_cpu_dai *fsl_ssi_dai; + struct fsl_ssi_private *ssi_private; + int ret = 0; + struct device_attribute *dev_attr; + + ssi_private = kzalloc(sizeof(struct fsl_ssi_private), GFP_KERNEL); + if (!ssi_private) { + dev_err(ssi_info->dev, "could not allocate DAI object\n"); + return NULL; + } + memcpy(&ssi_private->cpu_dai, &fsl_ssi_dai_template, + sizeof(struct snd_soc_cpu_dai)); + + fsl_ssi_dai = &ssi_private->cpu_dai; + dev_attr = &ssi_private->dev_attr; + + sprintf(ssi_private->name, "ssi%u", (u8) ssi_info->id); + ssi_private->ssi = ssi_info->ssi; + ssi_private->ssi_phys = ssi_info->ssi_phys; + ssi_private->irq = ssi_info->irq; + ssi_private->dev = ssi_info->dev; + + ssi_private->dev->driver_data = fsl_ssi_dai; + + /* Initialize the the device_attribute structure */ + dev_attr->attr.name = "ssi-stats"; + dev_attr->attr.mode = S_IRUGO; + dev_attr->show = fsl_sysfs_ssi_show; + + ret = device_create_file(ssi_private->dev, dev_attr); + if (ret) { + dev_err(ssi_info->dev, "could not create sysfs %s file\n", + ssi_private->dev_attr.attr.name); + kfree(fsl_ssi_dai); + return NULL; + } + + fsl_ssi_dai->private_data = ssi_private; + fsl_ssi_dai->name = ssi_private->name; + fsl_ssi_dai->id = ssi_info->id; + + return fsl_ssi_dai; +} +EXPORT_SYMBOL_GPL(fsl_ssi_create_dai); + +void fsl_ssi_destroy_dai(struct snd_soc_cpu_dai *fsl_ssi_dai) +{ + struct fsl_ssi_private *ssi_private = + container_of(fsl_ssi_dai, struct fsl_ssi_private, cpu_dai); + + device_remove_file(ssi_private->dev, &ssi_private->dev_attr); + + kfree(ssi_private); +} +EXPORT_SYMBOL_GPL(fsl_ssi_destroy_dai); + +MODULE_AUTHOR("Timur Tabi <timur@freescale.com>"); +MODULE_DESCRIPTION("Freescale Synchronous Serial Interface (SSI) ASoC Driver"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/fsl/fsl_ssi.h b/sound/soc/fsl/fsl_ssi.h new file mode 100644 index 0000000..f6e33af --- /dev/null +++ b/sound/soc/fsl/fsl_ssi.h @@ -0,0 +1,224 @@ +/* + * fsl_ssi.h - ALSA SSI interface for the Freescale MPC8610 SoC + * + * Author: Timur Tabi <timur@freescale.com> + * + * Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ + +#ifndef _MPC8610_I2S_H +#define _MPC8610_I2S_H + +/* SSI Register Map */ +struct ccsr_ssi { + __be32 stx0; /* 0x.0000 - SSI Transmit Data Register 0 */ + __be32 stx1; /* 0x.0004 - SSI Transmit Data Register 1 */ + __be32 srx0; /* 0x.0008 - SSI Receive Data Register 0 */ + __be32 srx1; /* 0x.000C - SSI Receive Data Register 1 */ + __be32 scr; /* 0x.0010 - SSI Control Register */ + __be32 sisr; /* 0x.0014 - SSI Interrupt Status Register Mixed */ + __be32 sier; /* 0x.0018 - SSI Interrupt Enable Register */ + __be32 stcr; /* 0x.001C - SSI Transmit Configuration Register */ + __be32 srcr; /* 0x.0020 - SSI Receive Configuration Register */ + __be32 stccr; /* 0x.0024 - SSI Transmit Clock Control Register */ + __be32 srccr; /* 0x.0028 - SSI Receive Clock Control Register */ + __be32 sfcsr; /* 0x.002C - SSI FIFO Control/Status Register */ + __be32 str; /* 0x.0030 - SSI Test Register */ + __be32 sor; /* 0x.0034 - SSI Option Register */ + __be32 sacnt; /* 0x.0038 - SSI AC97 Control Register */ + __be32 sacadd; /* 0x.003C - SSI AC97 Command Address Register */ + __be32 sacdat; /* 0x.0040 - SSI AC97 Command Data Register */ + __be32 satag; /* 0x.0044 - SSI AC97 Tag Register */ + __be32 stmsk; /* 0x.0048 - SSI Transmit Time Slot Mask Register */ + __be32 srmsk; /* 0x.004C - SSI Receive Time Slot Mask Register */ + __be32 saccst; /* 0x.0050 - SSI AC97 Channel Status Register */ + __be32 saccen; /* 0x.0054 - SSI AC97 Channel Enable Register */ + __be32 saccdis; /* 0x.0058 - SSI AC97 Channel Disable Register */ +}; + +#define CCSR_SSI_SCR_RFR_CLK_DIS 0x00000800 +#define CCSR_SSI_SCR_TFR_CLK_DIS 0x00000400 +#define CCSR_SSI_SCR_TCH_EN 0x00000100 +#define CCSR_SSI_SCR_SYS_CLK_EN 0x00000080 +#define CCSR_SSI_SCR_I2S_MODE_MASK 0x00000060 +#define CCSR_SSI_SCR_I2S_MODE_NORMAL 0x00000000 +#define CCSR_SSI_SCR_I2S_MODE_MASTER 0x00000020 +#define CCSR_SSI_SCR_I2S_MODE_SLAVE 0x00000040 +#define CCSR_SSI_SCR_SYN 0x00000010 +#define CCSR_SSI_SCR_NET 0x00000008 +#define CCSR_SSI_SCR_RE 0x00000004 +#define CCSR_SSI_SCR_TE 0x00000002 +#define CCSR_SSI_SCR_SSIEN 0x00000001 + +#define CCSR_SSI_SISR_RFRC 0x01000000 +#define CCSR_SSI_SISR_TFRC 0x00800000 +#define CCSR_SSI_SISR_CMDAU 0x00040000 +#define CCSR_SSI_SISR_CMDDU 0x00020000 +#define CCSR_SSI_SISR_RXT 0x00010000 +#define CCSR_SSI_SISR_RDR1 0x00008000 +#define CCSR_SSI_SISR_RDR0 0x00004000 +#define CCSR_SSI_SISR_TDE1 0x00002000 +#define CCSR_SSI_SISR_TDE0 0x00001000 +#define CCSR_SSI_SISR_ROE1 0x00000800 +#define CCSR_SSI_SISR_ROE0 0x00000400 +#define CCSR_SSI_SISR_TUE1 0x00000200 +#define CCSR_SSI_SISR_TUE0 0x00000100 +#define CCSR_SSI_SISR_TFS 0x00000080 +#define CCSR_SSI_SISR_RFS 0x00000040 +#define CCSR_SSI_SISR_TLS 0x00000020 +#define CCSR_SSI_SISR_RLS 0x00000010 +#define CCSR_SSI_SISR_RFF1 0x00000008 +#define CCSR_SSI_SISR_RFF0 0x00000004 +#define CCSR_SSI_SISR_TFE1 0x00000002 +#define CCSR_SSI_SISR_TFE0 0x00000001 + +#define CCSR_SSI_SIER_RFRC_EN 0x01000000 +#define CCSR_SSI_SIER_TFRC_EN 0x00800000 +#define CCSR_SSI_SIER_RDMAE 0x00400000 +#define CCSR_SSI_SIER_RIE 0x00200000 +#define CCSR_SSI_SIER_TDMAE 0x00100000 +#define CCSR_SSI_SIER_TIE 0x00080000 +#define CCSR_SSI_SIER_CMDAU_EN 0x00040000 +#define CCSR_SSI_SIER_CMDDU_EN 0x00020000 +#define CCSR_SSI_SIER_RXT_EN 0x00010000 +#define CCSR_SSI_SIER_RDR1_EN 0x00008000 +#define CCSR_SSI_SIER_RDR0_EN 0x00004000 +#define CCSR_SSI_SIER_TDE1_EN 0x00002000 +#define CCSR_SSI_SIER_TDE0_EN 0x00001000 +#define CCSR_SSI_SIER_ROE1_EN 0x00000800 +#define CCSR_SSI_SIER_ROE0_EN 0x00000400 +#define CCSR_SSI_SIER_TUE1_EN 0x00000200 +#define CCSR_SSI_SIER_TUE0_EN 0x00000100 +#define CCSR_SSI_SIER_TFS_EN 0x00000080 +#define CCSR_SSI_SIER_RFS_EN 0x00000040 +#define CCSR_SSI_SIER_TLS_EN 0x00000020 +#define CCSR_SSI_SIER_RLS_EN 0x00000010 +#define CCSR_SSI_SIER_RFF1_EN 0x00000008 +#define CCSR_SSI_SIER_RFF0_EN 0x00000004 +#define CCSR_SSI_SIER_TFE1_EN 0x00000002 +#define CCSR_SSI_SIER_TFE0_EN 0x00000001 + +#define CCSR_SSI_STCR_TXBIT0 0x00000200 +#define CCSR_SSI_STCR_TFEN1 0x00000100 +#define CCSR_SSI_STCR_TFEN0 0x00000080 +#define CCSR_SSI_STCR_TFDIR 0x00000040 +#define CCSR_SSI_STCR_TXDIR 0x00000020 +#define CCSR_SSI_STCR_TSHFD 0x00000010 +#define CCSR_SSI_STCR_TSCKP 0x00000008 +#define CCSR_SSI_STCR_TFSI 0x00000004 +#define CCSR_SSI_STCR_TFSL 0x00000002 +#define CCSR_SSI_STCR_TEFS 0x00000001 + +#define CCSR_SSI_SRCR_RXEXT 0x00000400 +#define CCSR_SSI_SRCR_RXBIT0 0x00000200 +#define CCSR_SSI_SRCR_RFEN1 0x00000100 +#define CCSR_SSI_SRCR_RFEN0 0x00000080 +#define CCSR_SSI_SRCR_RFDIR 0x00000040 +#define CCSR_SSI_SRCR_RXDIR 0x00000020 +#define CCSR_SSI_SRCR_RSHFD 0x00000010 +#define CCSR_SSI_SRCR_RSCKP 0x00000008 +#define CCSR_SSI_SRCR_RFSI 0x00000004 +#define CCSR_SSI_SRCR_RFSL 0x00000002 +#define CCSR_SSI_SRCR_REFS 0x00000001 + +/* STCCR and SRCCR */ +#define CCSR_SSI_SxCCR_DIV2 0x00040000 +#define CCSR_SSI_SxCCR_PSR 0x00020000 +#define CCSR_SSI_SxCCR_WL_SHIFT 13 +#define CCSR_SSI_SxCCR_WL_MASK 0x0001E000 +#define CCSR_SSI_SxCCR_WL(x) \ + (((((x) / 2) - 1) << CCSR_SSI_SxCCR_WL_SHIFT) & CCSR_SSI_SxCCR_WL_MASK) +#define CCSR_SSI_SxCCR_DC_SHIFT 8 +#define CCSR_SSI_SxCCR_DC_MASK 0x00001F00 +#define CCSR_SSI_SxCCR_DC(x) \ + ((((x) - 1) << CCSR_SSI_SxCCR_DC_SHIFT) & CCSR_SSI_SxCCR_DC_MASK) +#define CCSR_SSI_SxCCR_PM_SHIFT 0 +#define CCSR_SSI_SxCCR_PM_MASK 0x000000FF +#define CCSR_SSI_SxCCR_PM(x) \ + ((((x) - 1) << CCSR_SSI_SxCCR_PM_SHIFT) & CCSR_SSI_SxCCR_PM_MASK) + +/* + * The xFCNT bits are read-only, and the xFWM bits are read/write. Use the + * CCSR_SSI_SFCSR_xFCNTy() macros to read the FIFO counters, and use the + * CCSR_SSI_SFCSR_xFWMy() macros to set the watermarks. + */ +#define CCSR_SSI_SFCSR_RFCNT1_SHIFT 28 +#define CCSR_SSI_SFCSR_RFCNT1_MASK 0xF0000000 +#define CCSR_SSI_SFCSR_RFCNT1(x) \ + (((x) & CCSR_SSI_SFCSR_RFCNT1_MASK) >> CCSR_SSI_SFCSR_RFCNT1_SHIFT) +#define CCSR_SSI_SFCSR_TFCNT1_SHIFT 24 +#define CCSR_SSI_SFCSR_TFCNT1_MASK 0x0F000000 +#define CCSR_SSI_SFCSR_TFCNT1(x) \ + (((x) & CCSR_SSI_SFCSR_TFCNT1_MASK) >> CCSR_SSI_SFCSR_TFCNT1_SHIFT) +#define CCSR_SSI_SFCSR_RFWM1_SHIFT 20 +#define CCSR_SSI_SFCSR_RFWM1_MASK 0x00F00000 +#define CCSR_SSI_SFCSR_RFWM1(x) \ + (((x) << CCSR_SSI_SFCSR_RFWM1_SHIFT) & CCSR_SSI_SFCSR_RFWM1_MASK) +#define CCSR_SSI_SFCSR_TFWM1_SHIFT 16 +#define CCSR_SSI_SFCSR_TFWM1_MASK 0x000F0000 +#define CCSR_SSI_SFCSR_TFWM1(x) \ + (((x) << CCSR_SSI_SFCSR_TFWM1_SHIFT) & CCSR_SSI_SFCSR_TFWM1_MASK) +#define CCSR_SSI_SFCSR_RFCNT0_SHIFT 12 +#define CCSR_SSI_SFCSR_RFCNT0_MASK 0x0000F000 +#define CCSR_SSI_SFCSR_RFCNT0(x) \ + (((x) & CCSR_SSI_SFCSR_RFCNT0_MASK) >> CCSR_SSI_SFCSR_RFCNT0_SHIFT) +#define CCSR_SSI_SFCSR_TFCNT0_SHIFT 8 +#define CCSR_SSI_SFCSR_TFCNT0_MASK 0x00000F00 +#define CCSR_SSI_SFCSR_TFCNT0(x) \ + (((x) & CCSR_SSI_SFCSR_TFCNT0_MASK) >> CCSR_SSI_SFCSR_TFCNT0_SHIFT) +#define CCSR_SSI_SFCSR_RFWM0_SHIFT 4 +#define CCSR_SSI_SFCSR_RFWM0_MASK 0x000000F0 +#define CCSR_SSI_SFCSR_RFWM0(x) \ + (((x) << CCSR_SSI_SFCSR_RFWM0_SHIFT) & CCSR_SSI_SFCSR_RFWM0_MASK) +#define CCSR_SSI_SFCSR_TFWM0_SHIFT 0 +#define CCSR_SSI_SFCSR_TFWM0_MASK 0x0000000F +#define CCSR_SSI_SFCSR_TFWM0(x) \ + (((x) << CCSR_SSI_SFCSR_TFWM0_SHIFT) & CCSR_SSI_SFCSR_TFWM0_MASK) + +#define CCSR_SSI_STR_TEST 0x00008000 +#define CCSR_SSI_STR_RCK2TCK 0x00004000 +#define CCSR_SSI_STR_RFS2TFS 0x00002000 +#define CCSR_SSI_STR_RXSTATE(x) (((x) >> 8) & 0x1F) +#define CCSR_SSI_STR_TXD2RXD 0x00000080 +#define CCSR_SSI_STR_TCK2RCK 0x00000040 +#define CCSR_SSI_STR_TFS2RFS 0x00000020 +#define CCSR_SSI_STR_TXSTATE(x) ((x) & 0x1F) + +#define CCSR_SSI_SOR_CLKOFF 0x00000040 +#define CCSR_SSI_SOR_RX_CLR 0x00000020 +#define CCSR_SSI_SOR_TX_CLR 0x00000010 +#define CCSR_SSI_SOR_INIT 0x00000008 +#define CCSR_SSI_SOR_WAIT_SHIFT 1 +#define CCSR_SSI_SOR_WAIT_MASK 0x00000006 +#define CCSR_SSI_SOR_WAIT(x) (((x) & 3) << CCSR_SSI_SOR_WAIT_SHIFT) +#define CCSR_SSI_SOR_SYNRST 0x00000001 + +/* Instantiation data for an SSI interface + * + * This structure contains all the information that the the SSI driver needs + * to instantiate an SSI interface with ALSA. The machine driver should + * create this structure, fill it in, call fsl_ssi_create_dai(), and then + * delete the structure. + * + * id: which SSI this is (0, 1, etc. ) + * ssi: pointer to the SSI's registers + * ssi_phys: physical address of the SSI registers + * irq: IRQ of this SSI + * dev: struct device, used to create the sysfs statistics file +*/ +struct fsl_ssi_info { + unsigned int id; + struct ccsr_ssi __iomem *ssi; + dma_addr_t ssi_phys; + unsigned int irq; + struct device *dev; +}; + +struct snd_soc_cpu_dai *fsl_ssi_create_dai(struct fsl_ssi_info *ssi_info); +void fsl_ssi_destroy_dai(struct snd_soc_cpu_dai *fsl_ssi_dai); + +#endif + diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c new file mode 100644 index 0000000..5421a5c --- /dev/null +++ b/sound/soc/fsl/mpc8610_hpcd.c @@ -0,0 +1,621 @@ +/** + * Freescale MPC8610HPCD ALSA SoC Fabric driver + * + * Author: Timur Tabi <timur@freescale.com> + * + * Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under + * the terms of the GNU General Public License version 2. This program + * is licensed "as is" without any warranty of any kind, whether express + * or implied. + */ + +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/version.h> +#include <linux/kernel.h> +#include <linux/interrupt.h> +#include <linux/platform_device.h> +#include <asm/of_device.h> +#include <asm/of_platform.h> +#include <sound/driver.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/soc.h> +#include <sound/initval.h> +#include <asm/immap_86xx.h> + +#include "../codecs/cs4270.h" +#include "fsl_dma.h" +#include "fsl_ssi.h" + +/* + * Fabric-specific ASoC device data + * + * This structure contains data for a single sound platform device on an + * MPC8610 HPCD. Some of the data is taken from the device tree. + */ +struct mpc8610hpcd_data { + struct snd_soc_device sound_devdata; + struct snd_soc_dai_link dai; + struct snd_soc_machine machine; + unsigned int dai_format; + unsigned int codec_clk_direction; + unsigned int cpu_clk_direction; + unsigned int clk_frequency; + struct ccsr_guts __iomem *guts; + struct ccsr_ssi __iomem *ssi; + unsigned int ssi_id; /* 0 = SSI1, 1 = SSI2, etc */ + unsigned int ssi_irq; + unsigned int dma_id; /* 0 = DMA1, 1 = DMA2, etc */ + unsigned int dma_irq[2]; + struct ccsr_dma_channel __iomem *dma[2]; + unsigned int dma_channel_id[2]; /* 0 = ch 0, 1 = ch 1, etc*/ +}; + +/* + * Initalize the board + * + * This function is called when platform_device_add() is called. It is used + * to initialize the board-specific hardware. + * + * Here we program the DMACR and PMUXCR registers. + */ +int mpc8610_hpcd_machine_probe(struct platform_device *sound_device) +{ + struct mpc8610hpcd_data *machine_data = sound_device->dev.platform_data; + + /* Program the signal routing between the SSI and the DMA */ + guts_set_dmacr(machine_data->guts, machine_data->dma_id + 1, + machine_data->dma_channel_id[0], CCSR_GUTS_DMACR_DEV_SSI); + guts_set_dmacr(machine_data->guts, machine_data->dma_id + 1, + machine_data->dma_channel_id[1], CCSR_GUTS_DMACR_DEV_SSI); + + guts_set_pmuxcr_dma(machine_data->guts, machine_data->dma_id, + machine_data->dma_channel_id[0], 0); + guts_set_pmuxcr_dma(machine_data->guts, machine_data->dma_id, + machine_data->dma_channel_id[1], 0); + + guts_set_pmuxcr_dma(machine_data->guts, 1, 0, 0); + guts_set_pmuxcr_dma(machine_data->guts, 1, 3, 0); + guts_set_pmuxcr_dma(machine_data->guts, 0, 3, 0); + + switch (machine_data->ssi_id) { + case 0: + clrsetbits_be32(&machine_data->guts->pmuxcr, + CCSR_GUTS_PMUXCR_SSI1_MASK, CCSR_GUTS_PMUXCR_SSI1_SSI); + break; + case 1: + clrsetbits_be32(&machine_data->guts->pmuxcr, + CCSR_GUTS_PMUXCR_SSI2_MASK, CCSR_GUTS_PMUXCR_SSI2_SSI); + break; + } + + return 0; +} + +/* + * Program the board based on various hardware parameters + */ +static int mpc8610hpcd_startup(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct snd_soc_codec_dai *codec_dai = rtd->dai->codec_dai; + struct snd_soc_cpu_dai *cpu_dai = rtd->dai->cpu_dai; + struct mpc8610hpcd_data *machine_data = rtd->socdev->dev->platform_data; + int ret = 0; + + /* Tell the CPU driver what the serial protocol is. */ + if (cpu_dai->dai_ops.set_fmt) { + ret = cpu_dai->dai_ops.set_fmt(cpu_dai, + machine_data->dai_format); + if (ret < 0) { + dev_err(substream->pcm->card->dev, + "could not set CPU driver audio format\n"); + return ret; + } + } + + /* Tell the codec driver what the serial protocol is. */ + if (codec_dai->dai_ops.set_fmt) { + ret = codec_dai->dai_ops.set_fmt(codec_dai, + machine_data->dai_format); + if (ret < 0) { + dev_err(substream->pcm->card->dev, + "could not set codec driver audio format\n"); + return ret; + } + } + + /* + * Tell the CPU driver what the clock frequency is, and whether it's a + * slave or master. + */ + if (cpu_dai->dai_ops.set_sysclk) { + ret = cpu_dai->dai_ops.set_sysclk(cpu_dai, 0, + machine_data->clk_frequency, + machine_data->cpu_clk_direction); + if (ret < 0) { + dev_err(substream->pcm->card->dev, + "could not set CPU driver clock parameters\n"); + return ret; + } + } + + /* + * Tell the codec driver what the MCLK frequency is, and whether it's + * a slave or master. + */ + if (codec_dai->dai_ops.set_sysclk) { + ret = codec_dai->dai_ops.set_sysclk(codec_dai, 0, + machine_data->clk_frequency, + machine_data->codec_clk_direction); + if (ret < 0) { + dev_err(substream->pcm->card->dev, + "could not set codec driver clock params\n"); + return ret; + } + } + + return 0; +} + +/* + * Remove the sound device + * + * This function is called to remove the sound device for one SSI. We + * de-program the DMACR and PMUXCR register. + */ +int mpc8610_hpcd_machine_remove(struct platform_device *sound_device) +{ + struct mpc8610hpcd_data *machine_data = sound_device->dev.platform_data; + + /* Restore the signal routing */ + + guts_set_dmacr(machine_data->guts, machine_data->dma_id + 1, + machine_data->dma_channel_id[0], 0); + guts_set_dmacr(machine_data->guts, machine_data->dma_id + 1, + machine_data->dma_channel_id[1], 0); + + switch (machine_data->ssi_id) { + case 0: + clrsetbits_be32(&machine_data->guts->pmuxcr, + CCSR_GUTS_PMUXCR_SSI1_MASK, CCSR_GUTS_PMUXCR_SSI1_LA); + break; + case 1: + clrsetbits_be32(&machine_data->guts->pmuxcr, + CCSR_GUTS_PMUXCR_SSI2_MASK, CCSR_GUTS_PMUXCR_SSI1_LA); + break; + } + + return 0; +} + +/* + * ASoC fabric driver operations + */ +static struct snd_soc_ops mpc8610hpcd_ops = { + .startup = mpc8610hpcd_startup, +}; + +/* + * ASoC machine + */ +static struct snd_soc_machine mpc8610_hpcd_machine = { + .probe = mpc8610_hpcd_machine_probe, + .remove = mpc8610_hpcd_machine_remove, + .name = "MPC8610 HPCD", + .num_links = 1, +}; + +/* + * Probe function for the fabric driver driver. + * + * This function gets called when an SSI node is found in the device tree. + * + * Although this is a fabric driver, the SSI node is the "master" node with + * respect to audio hardware connections. Therefore, we create a new ASoC + * device for each new SSI node that has a codec attached. + * + * FIXME: Currently, we only support one DMA controller, so if there are + * multiple SSI nodes with codecs, only the first will be supported. + * + * FIXME: Even if we did support multiple DMA controllers, we have no + * mechanism for assigning DMA controllers and channels to the individual + * SSI devices. We also probably aren't compatible with the generic Elo DMA + * device driver. + */ +static int mpc8610_hpcd_probe(struct of_device *ofdev, + const struct of_device_id *match) +{ + struct device_node *np = ofdev->node; + struct device_node *codec_np = NULL; + struct device_node *guts_np = NULL; + struct device_node *dma_np = NULL; + struct device_node *dma_channel_np = NULL; + const char *sprop; + const u32 *iprop; + struct resource res; + struct platform_device *sound_device = NULL; + struct mpc8610hpcd_data *machine_data; + struct fsl_ssi_info ssi_info; + struct fsl_dma_info dma_info; + int ret = -ENODEV; + + machine_data = kzalloc(sizeof(struct mpc8610hpcd_data), GFP_KERNEL); + if (!machine_data) + return -ENOMEM; + + memset(&ssi_info, 0, sizeof(ssi_info)); + memset(&dma_info, 0, sizeof(dma_info)); + + ssi_info.dev = &ofdev->dev; + + /* + * We are only interested in SSIs with a codec child node in them, so + * let's make sure this SSI has one. + */ + while ((codec_np = of_get_next_child(np, codec_np)) != NULL) { + if (strcmp(codec_np->name, "codec") == 0) { + /* Most drivers forget the final of_node_put() call */ + of_node_put(codec_np); + break; + } + } + + if (!codec_np) + goto error; + + /* The MPC8610 HPCD only knows about the CS4270 codec, so reject + anything else. */ + if (!of_device_is_compatible(codec_np, "cirrus,cs4270")) + goto error; + + /* Get the device ID */ + iprop = of_get_property(np, "cell-index", NULL); + if (!iprop) { + dev_err(&ofdev->dev, "cell-index property not found\n"); + ret = -EINVAL; + goto error; + } + machine_data->ssi_id = *iprop; + ssi_info.id = *iprop; + + /* Get the serial format and clock direction. */ + sprop = of_get_property(np, "fsl,mode", NULL); + if (!sprop) { + dev_err(&ofdev->dev, "fsl,mode property not found\n"); + ret = -EINVAL; + goto error; + } + + if (strcasecmp(sprop, "i2s-slave") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_I2S; + machine_data->codec_clk_direction = SND_SOC_CLOCK_OUT; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_IN; + + /* In i2s-slave mode, the codec has its own clock source, so + we need to get the frequency from the device tree and pass + it to the codec driver. */ + iprop = of_get_property(codec_np, "bus-frequency", NULL); + if (!iprop || !*iprop) { + dev_err(&ofdev->dev, "codec bus-frequency property " + "is missing or invalid\n"); + ret = -EINVAL; + goto error; + } + machine_data->clk_frequency = *iprop; + } else if (strcasecmp(sprop, "i2s-master") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_I2S; + machine_data->codec_clk_direction = SND_SOC_CLOCK_IN; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_OUT; + } else if (strcasecmp(sprop, "lj-slave") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_LEFT_J; + machine_data->codec_clk_direction = SND_SOC_CLOCK_OUT; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_IN; + } else if (strcasecmp(sprop, "lj-master") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_LEFT_J; + machine_data->codec_clk_direction = SND_SOC_CLOCK_IN; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_OUT; + } else if (strcasecmp(sprop, "rj-master") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_RIGHT_J; + machine_data->codec_clk_direction = SND_SOC_CLOCK_OUT; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_IN; + } else if (strcasecmp(sprop, "rj-master") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_RIGHT_J; + machine_data->codec_clk_direction = SND_SOC_CLOCK_IN; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_OUT; + } else if (strcasecmp(sprop, "ac97-slave") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_AC97; + machine_data->codec_clk_direction = SND_SOC_CLOCK_OUT; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_IN; + } else if (strcasecmp(sprop, "ac97-master") == 0) { + machine_data->dai_format = SND_SOC_DAIFMT_AC97; + machine_data->codec_clk_direction = SND_SOC_CLOCK_IN; + machine_data->cpu_clk_direction = SND_SOC_CLOCK_OUT; + } else { + dev_err(&ofdev->dev, + "unrecognized fsl,mode property "%s"\n", sprop); + ret = -EINVAL; + goto error; + } + + if (!machine_data->clk_frequency) { + dev_err(&ofdev->dev, "unknown clock frequency\n"); + ret = -EINVAL; + goto error; + } + + /* Read the SSI information from the device tree */ + ret = of_address_to_resource(np, 0, &res); + if (ret) { + dev_err(&ofdev->dev, "could not obtain SSI address\n"); + goto error; + } + if (!res.start) { + dev_err(&ofdev->dev, "invalid SSI address\n"); + goto error; + } + ssi_info.ssi_phys = res.start; + + machine_data->ssi = ioremap(ssi_info.ssi_phys, sizeof(struct ccsr_ssi)); + if (!machine_data->ssi) { + dev_err(&ofdev->dev, "could not map SSI address %x\n", + ssi_info.ssi_phys); + ret = -EINVAL; + goto error; + } + ssi_info.ssi = machine_data->ssi; + + + /* Get the IRQ of the SSI */ + machine_data->ssi_irq = irq_of_parse_and_map(np, 0); + if (!machine_data->ssi_irq) { + dev_err(&ofdev->dev, "could not get SSI IRQ\n"); + ret = -EINVAL; + goto error; + } + ssi_info.irq = machine_data->ssi_irq; + + + /* Map the global utilities registers. */ + guts_np = of_find_compatible_node(NULL, NULL, "fsl,mpc8610-guts"); + if (!guts_np) { + dev_err(&ofdev->dev, "could not obtain address of GUTS\n"); + ret = -EINVAL; + goto error; + } + machine_data->guts = of_iomap(guts_np, 0); + of_node_put(guts_np); + if (!machine_data->guts) { + dev_err(&ofdev->dev, "could not map GUTS\n"); + ret = -EINVAL; + goto error; + } + + /* Find the DMA channels to use. For now, we always use the first DMA + controller. */ + for_each_compatible_node(dma_np, NULL, "fsl,mpc8610-dma") { + iprop = of_get_property(dma_np, "cell-index", NULL); + if (iprop && (*iprop == 0)) { + of_node_put(dma_np); + break; + } + } + if (!dma_np) { + dev_err(&ofdev->dev, "could not find DMA node\n"); + ret = -EINVAL; + goto error; + } + machine_data->dma_id = *iprop; + + /* + * Find the DMA channels to use. For now, we always use DMA channel 0 + * for playback, and DMA channel 1 for capture. + */ + while ((dma_channel_np = of_get_next_child(dma_np, dma_channel_np))) { + iprop = of_get_property(dma_channel_np, "cell-index", NULL); + /* Is it DMA channel 0? */ + if (iprop && (*iprop == 0)) { + /* dma_channel[0] and dma_irq[0] are for playback */ + dma_info.dma_channel[0] = of_iomap(dma_channel_np, 0); + dma_info.dma_irq[0] = + irq_of_parse_and_map(dma_channel_np, 0); + machine_data->dma_channel_id[0] = *iprop; + continue; + } + if (iprop && (*iprop == 1)) { + /* dma_channel[1] and dma_irq[1] are for capture */ + dma_info.dma_channel[1] = of_iomap(dma_channel_np, 0); + dma_info.dma_irq[1] = + irq_of_parse_and_map(dma_channel_np, 0); + machine_data->dma_channel_id[1] = *iprop; + continue; + } + } + if (!dma_info.dma_channel[0] || !dma_info.dma_channel[1] || + !dma_info.dma_irq[0] || !dma_info.dma_irq[1]) { + dev_err(&ofdev->dev, "could not find DMA channels\n"); + ret = -EINVAL; + goto error; + } + + dma_info.ssi_stx_phys = ssi_info.ssi_phys + + offsetof(struct ccsr_ssi, stx0); + dma_info.ssi_srx_phys = ssi_info.ssi_phys + + offsetof(struct ccsr_ssi, srx0); + + /* We have the DMA information, so tell the DMA driver what it is */ + if (!fsl_dma_configure(&dma_info)) { + dev_err(&ofdev->dev, "could not instantiate DMA device\n"); + ret = -EBUSY; + goto error; + } + + /* + * Initialize our DAI data structure. We should probably get this + * information from the device tree. + */ + machine_data->dai.name = "CS4270"; + machine_data->dai.stream_name = "CS4270"; + + machine_data->dai.cpu_dai = fsl_ssi_create_dai(&ssi_info); + machine_data->dai.codec_dai = &cs4270_dai; /* The codec_dai we want */ + machine_data->dai.ops = &mpc8610hpcd_ops; + + mpc8610_hpcd_machine.dai_link = &machine_data->dai; + + /* Allocate a new audio platform device structure */ + sound_device = platform_device_alloc("soc-audio", -1); + if (!sound_device) { + dev_err(&ofdev->dev, "platform device allocation failed\n"); + ret = -ENOMEM; + goto error; + } + + machine_data->sound_devdata.machine = &mpc8610_hpcd_machine; + machine_data->sound_devdata.codec_dev = &soc_codec_device_cs4270; + machine_data->sound_devdata.platform = &fsl_soc_platform; + + sound_device->dev.platform_data = machine_data; + + + /* Set the platform device and ASoC device to point to each other */ + platform_set_drvdata(sound_device, &machine_data->sound_devdata); + + machine_data->sound_devdata.dev = &sound_device->dev; + + + /* Tell ASoC to probe us. This will call mpc8610_hpcd_machine.probe(), + if it exists. */ + ret = platform_device_add(sound_device); + + if (ret) { + dev_err(&ofdev->dev, "platform device add failed\n"); + goto error; + } + + dev_set_drvdata(&ofdev->dev, sound_device); + + return 0; + +error: + if (sound_device) + platform_device_unregister(sound_device); + + if (machine_data->dai.cpu_dai) + fsl_ssi_destroy_dai(machine_data->dai.cpu_dai); + + if (ssi_info.ssi) + iounmap(ssi_info.ssi); + + if (ssi_info.irq) + irq_dispose_mapping(ssi_info.irq); + + if (dma_info.dma_channel[0]) + iounmap(dma_info.dma_channel[0]); + + if (dma_info.dma_channel[1]) + iounmap(dma_info.dma_channel[1]); + + if (dma_info.dma_irq[0]) + irq_dispose_mapping(dma_info.dma_irq[0]); + + if (dma_info.dma_irq[1]) + irq_dispose_mapping(dma_info.dma_irq[1]); + + if (machine_data->guts) + iounmap(machine_data->guts); + + kfree(machine_data); + + return ret; +} + +static int mpc8610_hpcd_remove(struct of_device *ofdev) +{ + struct platform_device *sound_device = dev_get_drvdata(&ofdev->dev); + struct mpc8610hpcd_data *machine_data = sound_device->dev.platform_data; + + platform_device_unregister(sound_device); + + if (machine_data->dai.cpu_dai) + fsl_ssi_destroy_dai(machine_data->dai.cpu_dai); + + if (machine_data->ssi) + iounmap(machine_data->ssi); + + if (machine_data->dma[0]) + iounmap(machine_data->dma[0]); + + if (machine_data->dma[1]) + iounmap(machine_data->dma[1]); + + if (machine_data->dma_irq[0]) + irq_dispose_mapping(machine_data->dma_irq[0]); + + if (machine_data->dma_irq[1]) + irq_dispose_mapping(machine_data->dma_irq[1]); + + if (machine_data->guts) + iounmap(machine_data->guts); + + kfree(machine_data); + sound_device->dev.platform_data = NULL; + + dev_set_drvdata(&ofdev->dev, NULL); + + return 0; +} + +static struct of_device_id mpc8610_hpcd_match[] = { + { + .compatible = "fsl,ssi", + }, + {} +}; +MODULE_DEVICE_TABLE(of, mpc8610_hpcd_match); + +static struct of_platform_driver mpc8610_hpcd_of_driver = { + .owner = THIS_MODULE, + .name = "mpc8610_hpcd", + .match_table = mpc8610_hpcd_match, + .probe = mpc8610_hpcd_probe, + .remove = mpc8610_hpcd_remove, +}; + +/** + * Fabric driver initialization. + * + * This function is called when this module is loaded. + */ +static int __init mpc8610hpcd_init(void) +{ + int ret; + + printk(KERN_INFO "Freescale MPC8610 HPCD ALSA SoC fabric driver\n"); + + ret = of_register_platform_driver(&mpc8610_hpcd_of_driver); + + if (ret) + printk(KERN_ERR + "mpc8610-hpcd: failed to register platform driver\n"); + + return ret; +} + +/** + * Fabric driver exit + * + * This function is called when this driver is unloaded. + */ +static void __exit mpc8610hpcd_exit(void) +{ + of_unregister_platform_driver(&mpc8610_hpcd_of_driver); +} + +module_init(mpc8610hpcd_init); +module_exit(mpc8610hpcd_exit); + +MODULE_AUTHOR("Timur Tabi <timur@freescale.com>"); +MODULE_DESCRIPTION("Freescale MPC8610 HPCD ALSA SoC fabric driver"); +MODULE_LICENSE("GPL");
Hi,
This is a fairly substantial driver to get through, but here are some initial comments on some of the simpler stuff:
On Wed, Dec 19, 2007 at 06:03:09PM -0600, Timur Tabi wrote:
This patch adds ALSA SoC device drivers for the Freescale MPC8610 SoC and the MPC8610-HPCD reference board.
[...]
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c index 6390895..6e1bde3 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -34,9 +34,27 @@
#include <asm/mpic.h>
+#include <asm/of_platform.h> #include <sysdev/fsl_pci.h> #include <sysdev/fsl_soc.h>
+static struct of_device_id mpc8610_ids[] = {
- { .type = "soc", },
- {}
Please scan based on compatible instead of device_type.
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig new file mode 100644 index 0000000..4a5bbd2 --- /dev/null +++ b/sound/soc/fsl/Kconfig @@ -0,0 +1,21 @@ +menu "ALSA SoC audio for Freescale SOCs"
+config SND_SOC_MPC8610
- bool "ALSA SoC support for the MPC8610 SOC"
- depends on SND_SOC #&& MPC8610_HPCD
- default y #if MPC8610
- help
Say Y if you want to add support for codecs attached to the SSI
device on an MPC8610.
Don't default configs to 'y'. Also, what's with the commented-out dependencies and if?
+config SND_SOC_MPC8610_HPCD
- # ALSA SoC support for Freescale MPC8610HPCD
- bool "ALSA SoC support for the Freescale MPC8610 HPCD board"
- depends on SND_SOC_MPC8610
- select SND_SOC_CS4270
- select SND_SOC_CS4270_VD33_ERRATA
- default y #if MPC8610_HPCD
- help
Say Y if you want to enable audio on the Freescale MPC8610 HPCD.
Same here w.r.t. defaults and dependencies.
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c new file mode 100644 index 0000000..6b86be0 --- /dev/null +++ b/sound/soc/fsl/fsl_dma.c @@ -0,0 +1,819 @@ +/*
- Freescale DMA ALSA SoC PCM driver
- Author: Timur Tabi timur@freescale.com
- Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under
- the terms of the GNU General Public License version 2. This program
- is licensed "as is" without any warranty of any kind, whether express
- or implied.
- This driver implements ASoC support for the Elo DMA controller, which is
- the DMA controller on Freescale 83xx, 85xx, and 86xx SOCs. In ALSA terms,
- the PCM driver is what handles the DMA buffer.
- */
+#include <linux/module.h> +#include <linux/init.h> +#include <linux/platform_device.h> +#include <linux/dma-mapping.h> +#include <linux/interrupt.h> +#include <linux/delay.h>
+#include <sound/driver.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h>
+#include <asm/io.h>
+#include "fsl_dma.h"
+/*
- The formats that the DMA controller supports, which is anything
- that is 8, 16, or 32 bits.
- */
+#define FSLDMA_PCM_FORMATS (SNDRV_PCM_FMTBIT_S8 | \
SNDRV_PCM_FMTBIT_U8 | \
SNDRV_PCM_FMTBIT_S16_LE | \
SNDRV_PCM_FMTBIT_S16_BE | \
SNDRV_PCM_FMTBIT_U16_LE | \
SNDRV_PCM_FMTBIT_U16_BE | \
SNDRV_PCM_FMTBIT_S24_LE | \
SNDRV_PCM_FMTBIT_S24_BE | \
SNDRV_PCM_FMTBIT_U24_LE | \
SNDRV_PCM_FMTBIT_U24_BE | \
SNDRV_PCM_FMTBIT_S32_LE | \
SNDRV_PCM_FMTBIT_S32_BE | \
SNDRV_PCM_FMTBIT_U32_LE | \
SNDRV_PCM_FMTBIT_U32_BE)
+#define FSLDMA_PCM_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \
SNDRV_PCM_RATE_CONTINUOUS)
+/* DMA global data. This structure is used by fsl_dma_open() to determine
- which DMA channels to assign to a substream. Unfortunately, ASoC V1 does
- not allow the machine driver to provide this information to the PCM
- driver in advance, and there's no way to differentiate between the two
- DMA controllers. So for now, this driver only supports one SSI device
- using two DMA channels. We cannot support multiple DMA devices.
- ssi_stx_phys: bus address of SSI STX register
- ssi_srx_phys: bus address of SSI SRX register
- dma_channel: pointer to the DMA channel's registers
- irq: IRQ for this DMA channel
- assigned: set to 1 if that DMA channel is assigned to a substream
- */
This goes for the whole patch: You've got good documentation, but it's not in docbook format. Please reformat it since it should be a pretty simple thing to do.
+/*
- Initialize this PCM driver.
- This function is called when the codec driver calls snd_soc_new_pcms(),
- once for each .dai_link in the machine driver's snd_soc_machine
- structure.
- */
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai *dai,
- struct snd_pcm *pcm)
+{
- static u64 fsl_dma_dmamask = 0xffffffff;
- int ret;
- if (!card->dev->dma_mask)
card->dev->dma_mask = &fsl_dma_dmamask;
I haven't read how your channel allocation works, but providing a pointer to a local static variable is a bit fishy no matter what.
- /* Find the DMA channels to use. For now, we always use the first DMA
controller. */
- for_each_compatible_node(dma_np, NULL, "fsl,mpc8610-dma") {
iprop = of_get_property(dma_np, "cell-index", NULL);
if (iprop && (*iprop == 0)) {
of_node_put(dma_np);
break;
}
- }
Do you ever anticipate having other dma users on the system, such as memcpy offload? You'll probably need allocation support for channels when that day comes (I ended up writing a simple library for dma channel management for that very reason on my platform).
-Olof
Olof Johansson wrote:
+static struct of_device_id mpc8610_ids[] = {
- { .type = "soc", },
- {}
Please scan based on compatible instead of device_type.
I was just following the example from another board file. However, the 'soc' node in the device tree does not have a compatible property, so I don't how to change this.
+config SND_SOC_MPC8610
- bool "ALSA SoC support for the MPC8610 SOC"
- depends on SND_SOC #&& MPC8610_HPCD
- default y #if MPC8610
- help
Say Y if you want to add support for codecs attached to the SSI
device on an MPC8610.
Don't default configs to 'y'. Also, what's with the commented-out dependencies and if?
Sorry, that was a development change that I forgot to put back. The "y #" should be deleted.
- ssi_stx_phys: bus address of SSI STX register
- ssi_srx_phys: bus address of SSI SRX register
- dma_channel: pointer to the DMA channel's registers
- irq: IRQ for this DMA channel
- assigned: set to 1 if that DMA channel is assigned to a substream
- */
This goes for the whole patch: You've got good documentation, but it's not in docbook format. Please reformat it since it should be a pretty simple thing to do.
Ok.
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai *dai,
- struct snd_pcm *pcm)
+{
- static u64 fsl_dma_dmamask = 0xffffffff;
- int ret;
- if (!card->dev->dma_mask)
card->dev->dma_mask = &fsl_dma_dmamask;
I haven't read how your channel allocation works, but providing a pointer to a local static variable is a bit fishy no matter what.
I just copied this code from another module. All the ALSA drivers do this, but I'll look into it and see if it can't be done different. I make no promises, though!
Do you ever anticipate having other dma users on the system, such as memcpy offload? You'll probably need allocation support for channels when that day comes (I ended up writing a simple library for dma channel management for that very reason on my platform).
Yes, I plan on updating this driver to work with the standard Freescale "Elo" device driver, but that will have to wait until that code is in the kernel and stabilized. The SSI is limited in which DMA channels it can use, anyway.
At Thu, 20 Dec 2007 08:24:35 -0600, Timur Tabi wrote:
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai *dai,
- struct snd_pcm *pcm)
+{
- static u64 fsl_dma_dmamask = 0xffffffff;
- int ret;
- if (!card->dev->dma_mask)
card->dev->dma_mask = &fsl_dma_dmamask;
I haven't read how your channel allocation works, but providing a pointer to a local static variable is a bit fishy no matter what.
I just copied this code from another module. All the ALSA drivers do this,
All? No, only a few... For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask() are used, of course.
Takashi
Takashi Iwai wrote:
All? No, only a few... For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask() are used, of course.
Hmm, ok I was wrong. I took this code from the ASoC at91 driver.
Unfortunately, I don't understand what this code is trying to do. The AT91 driver isn't documented, so I don't even know if I need it. Can someone explain what all this is? What's the alternative to using a static global?
On Dec 20, 2007 8:54 AM, Takashi Iwai tiwai@suse.de wrote:
At Thu, 20 Dec 2007 08:24:35 -0600, Timur Tabi wrote:
+static int fsl_dma_new(struct snd_card *card, struct snd_soc_codec_dai *dai,
- struct snd_pcm *pcm)
+{
- static u64 fsl_dma_dmamask = 0xffffffff;
- int ret;
- if (!card->dev->dma_mask)
card->dev->dma_mask = &fsl_dma_dmamask;
I haven't read how your channel allocation works, but providing a pointer to a local static variable is a bit fishy no matter what.
I just copied this code from another module. All the ALSA drivers do this,
All? No, only a few... For PCI, usually pci_set_dma_mask() and pci_set_consistent_dma_mask() are used, of course.
Timur,
Nicely commented driver! I wish they were all like this ;-)
Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of 0xffffffff. I've personally fixed a heisenbug in an ALSA driver caused by incorrectly typed DMA mask...
Lee
Lee Revell wrote:
Please use DMA_32BIT_MASK (see include/linux/dma-mapping.h) instead of 0xffffffff.
No prob. But did you see this comment:
/* * NOTE: do not use the below macros in new code and do not add new definitions * here. * * Instead, just open-code DMA_BIT_MASK(n) within your driver */
So I guess I should use DMA_BIT_MASK(32) instead.
I've personally fixed a heisenbug in an ALSA driver caused by incorrectly typed DMA mask...
Can you explain to me what all of this does? Is it okay to use a static u64 variable? Why do so many drivers do it that way? I don't even know if 0xFFFFFFFF is the right number for my platform.
On Thu, Dec 20, 2007 at 08:24:35AM -0600, Timur Tabi wrote:
Olof Johansson wrote:
+static struct of_device_id mpc8610_ids[] = {
- { .type = "soc", },
- {}
Please scan based on compatible instead of device_type.
I was just following the example from another board file. However, the 'soc' node in the device tree does not have a compatible property, so I don't how to change this.
Then add an appropriate compatible entry to it, please.
Do you ever anticipate having other dma users on the system, such as memcpy offload? You'll probably need allocation support for channels when that day comes (I ended up writing a simple library for dma channel management for that very reason on my platform).
Yes, I plan on updating this driver to work with the standard Freescale "Elo" device driver, but that will have to wait until that code is in the kernel and stabilized. The SSI is limited in which DMA channels it can use, anyway.
Ok.
-Olof
Olof Johansson wrote:
I was just following the example from another board file. However, the 'soc' node in the device tree does not have a compatible property, so I don't how to change this.
Then add an appropriate compatible entry to it, please.
None of the SOC nodes in any DTS have a "compatible" entry. I understand the issue, but you're asking me to fix a larger problem, one that is beyond the scope of this patch. You're saying that *all* SOC needs are incorrectly defined and need to be probed differently.
Timur Tabi wrote:
Olof Johansson wrote:
I was just following the example from another board file. However, the 'soc' node in the device tree does not have a compatible property, so I don't how to change this.
Then add an appropriate compatible entry to it, please.
None of the SOC nodes in any DTS have a "compatible" entry.
Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
-Scott
Scott Wood wrote:
None of the SOC nodes in any DTS have a "compatible" entry.
Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
Ah ok. So what should the compatible entry for 8641 be?
compatible = "fsl,mpc8641"
That looks a lot like what a compatible entry for the CPU should be. How are we differentiating between the compatible cores and compatible SOCs?
On Sat, Dec 22, 2007 at 08:58:21PM -0600, Timur Tabi wrote:
Scott Wood wrote:
None of the SOC nodes in any DTS have a "compatible" entry.
Not quite true; ep88xc, mpc8272ads, and pq2fads have them.
Ah ok. So what should the compatible entry for 8641 be?
compatible = "fsl,mpc8641"
Yes.
That looks a lot like what a compatible entry for the CPU should be.
I guess technically the cpu should list something like fsl,e600 (or whatever suffix is relevant).
-Scott
So, like, the other day Timur Tabi mumbled:
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpc d.c index 6390895..6e1bde3 100644 --- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c +++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c @@ -34,9 +34,27 @@
#include <asm/mpic.h>
+#include <asm/of_platform.h> #include <sysdev/fsl_pci.h> #include <sysdev/fsl_soc.h>
Please dont' re-introduce these. I just submitted patches to move all of the PowerPC instances to using <linux/of_platform.h>
diff --git a/sound/soc/fsl/mpc8610_hpcd.c b/sound/soc/fsl/mpc8610_hpcd.c new file mode 100644 index 0000000..5421a5c --- /dev/null +++ b/sound/soc/fsl/mpc8610_hpcd.c @@ -0,0 +1,621 @@ +/**
- Freescale MPC8610HPCD ALSA SoC Fabric driver
- Author: Timur Tabi timur@freescale.com
- Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under
- the terms of the GNU General Public License version 2. This program
- is licensed "as is" without any warranty of any kind, whether express
- or implied.
- */
+#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/version.h> +#include <linux/kernel.h> +#include <linux/interrupt.h> +#include <linux/platform_device.h> +#include <asm/of_device.h> +#include <asm/of_platform.h>
Again, this should be moved up as <linux/of_platform.h>.
Thanks, jdl
On 12/19/07, Timur Tabi timur@freescale.com wrote:
+static struct of_device_id mpc8610_ids[] = {
{ .type = "soc", },
{}
+};
+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);
How is of_platform_bus_probe() supposed to be called? mpc5200/virtex call it with three NULLs. Is it necessary to name all of the buses in a of_device_id? If it's not necessary to list the buses the of_platform_bus_probe() call could be moved to common code.
Are these buses? { .compatible = "ibm,plb4", }, { .compatible = "ibm,opb", }, { .compatible = "ibm,ebc", },
Could of_platform_bus_probe() be simplified? No one uses the first and third parameters.
Jon Smirl wrote:
How is of_platform_bus_probe() supposed to be called? mpc5200/virtex call it with three NULLs. Is it necessary to name all of the buses in a of_device_id? If it's not necessary to list the buses the of_platform_bus_probe() call could be moved to common code.
I added the above code because it is the only way I could get my SSI nodes to be probed. If there's a better way to do it, I'm all ears. I just copied that code from the mpc836x_mds.c platform file.
Are these buses? { .compatible = "ibm,plb4", }, { .compatible = "ibm,opb", }, { .compatible = "ibm,ebc", },
I have no idea.
Could of_platform_bus_probe() be simplified? No one uses the first and third parameters.
Maybe, but that's not a discussion for this thread!
On 12/20/07, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
How is of_platform_bus_probe() supposed to be called? mpc5200/virtex call it with three NULLs. Is it necessary to name all of the buses in a of_device_id? If it's not necessary to list the buses the of_platform_bus_probe() call could be moved to common code.
I added the above code because it is the only way I could get my SSI nodes to be probed. If there's a better way to do it, I'm all ears. I just copied that code from the mpc836x_mds.c platform file.
mpc5200 does it like this: of_platform_bus_probe(NULL, NULL, NULL);
No need for the ids.
Are these buses? { .compatible = "ibm,plb4", }, { .compatible = "ibm,opb", }, { .compatible = "ibm,ebc", },
I have no idea.
Could of_platform_bus_probe() be simplified? No one uses the first and third parameters.
Maybe, but that's not a discussion for this thread!
-- Timur Tabi Linux kernel developer at Freescale
Jon Smirl wrote:
mpc5200 does it like this: of_platform_bus_probe(NULL, NULL, NULL);
I think that tells the OF base code to probe everything in the device tree, which is probably overkill. I think fsl_soc.c covers most of the device tree, but the SSI is not defined in fsl_soc.c.
Timur Tabi wrote:
Jon Smirl wrote:
mpc5200 does it like this: of_platform_bus_probe(NULL, NULL, NULL);
I think that tells the OF base code to probe everything in the device tree, which is probably overkill. I think fsl_soc.c covers most of the device tree, but the SSI is not defined in fsl_soc.c.
Not quite; it tells it to use a built-in list of bus matches. Most of which are device_type-based, FWIW.
-Scott
On 12/20/07, Scott Wood scottwood@freescale.com wrote:
Timur Tabi wrote:
Jon Smirl wrote:
mpc5200 does it like this: of_platform_bus_probe(NULL, NULL, NULL);
I think that tells the OF base code to probe everything in the device tree, which is probably overkill. I think fsl_soc.c covers most of the device tree, but the SSI is not defined in fsl_soc.c.
Not quite; it tells it to use a built-in list of bus matches. Most of which are device_type-based, FWIW.
Here's the default. Using NULL would work.
static struct of_device_id of_default_bus_ids[] = { { .type = "soc", }, { .compatible = "soc", }, { .type = "spider", }, { .type = "axon", }, { .type = "plb5", }, { .type = "plb4", }, { .type = "opb", }, { .type = "ebc", }, {}, };
-Scott
On Thu, Dec 20, 2007 at 06:13:31PM -0500, Jon Smirl wrote:
On 12/20/07, Scott Wood scottwood@freescale.com wrote:
Timur Tabi wrote:
Jon Smirl wrote:
mpc5200 does it like this: of_platform_bus_probe(NULL, NULL, NULL);
I think that tells the OF base code to probe everything in the device tree, which is probably overkill. I think fsl_soc.c covers most of the device tree, but the SSI is not defined in fsl_soc.c.
Not quite; it tells it to use a built-in list of bus matches. Most of which are device_type-based, FWIW.
Here's the default. Using NULL would work.
It might work, but using the default list is discouraged. Pass an explicit list of match ids for the buses you need to scan instead (and use compatible to match them, not device_type).
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
On 1/1/08, Jon Smirl jonsmirl@gmail.com wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
Looking at the cs4270 codec driver it is controlled by i2c (supports SPI too). What happened to the conversation about putting codecs on the controlling bus and then linking them to the data bus?
If that's the case the cs4270 should be in the i2c bus node (missing currently) and then a link from the SSI bus would point to it.
cs4270 is still an old style i2c driver which is going to get deprecated. It takes about thirty minutes to convert it to new style. If was new style it could pick up its i2c address from the device tree instead of searching for it.
Jon Smirl wrote:
On 1/1/08, Jon Smirl jonsmirl@gmail.com wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
Looking at the cs4270 codec driver it is controlled by i2c (supports SPI too). What happened to the conversation about putting codecs on the controlling bus and then linking them to the data bus?
The current CS4270 driver doesn't support device trees. When I wrote it, the idea of putting I2C info in the device tree was not finalized, and since the driver is supposed to be cross-platform, I decided to do it the old-fashioned way. Before I update the code, however, I'm waiting for:
1) The current code to be accepted into the tree 2) ASoC is updated to V2 3) The current drivers are updated to support ASoC V2.
I think ASoC V2 will make it easier to support device trees, but I'm not ready yet for that.
If that's the case the cs4270 should be in the i2c bus node (missing currently) and then a link from the SSI bus would point to it.
The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs to have two nodes, one under each. Your're right in that there needs to be a link, but until the code is updated to ASoC V2, I think it's premature to add that support.
On 1/2/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
On 1/1/08, Jon Smirl jonsmirl@gmail.com wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
Looking at the cs4270 codec driver it is controlled by i2c (supports SPI too). What happened to the conversation about putting codecs on the controlling bus and then linking them to the data bus?
The current CS4270 driver doesn't support device trees. When I wrote it, the idea of putting I2C info in the device tree was not finalized, and since the driver is supposed to be cross-platform, I decided to do it the old-fashioned way. Before I update the code, however, I'm waiting for:
- The current code to be accepted into the tree
- ASoC is updated to V2
- The current drivers are updated to support ASoC V2.
I've been trying to get the i2c code in for two months. Hopefully it will go in soon, no one had made any comments on it recently. Have you tried your code with it?
There is nothing stopping your from putting a node for the CS4270 on the i2c bus today. It just won't trigger the loading of the driver.
Don't we want to follow the device tree policy of putting the device on the controlling bus and then link it to the data bus?
I think ASoC V2 will make it easier to support device trees, but I'm not ready yet for that.
It makes it a little easier but it doesn't fix everything. We need to start looking at it since none of the example driver for it are device tree based. It still has problems with wanting 'struct platform_device' when we have 'struct of_platform_device' pointers. It also doesn't know how to dynamically load codecs based on device trees.
Liam messed up all of my code when he refactored it in late December. I've switched over to the current SOC code for the moment. The big thing that v2 fixes is that SOC is changed to being a subsystem instead of platform driver. Being a subsystem is the correct model.
It would be good if more pieces of v2 get push forward. Then we can sort out the device tree issues in it.
If that's the case the cs4270 should be in the i2c bus node (missing currently) and then a link from the SSI bus would point to it.
The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs to have two nodes, one under each. Your're right in that there needs to be a link, but until the code is updated to ASoC V2, I think it's premature to add that support.
Adding the second device tree node doesn't have anything to do with ASOC v2. It's specific to powerpc and device trees.
Jon Smirl wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
On 1/1/08, Jon Smirl jonsmirl@gmail.com wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
Looking at the cs4270 codec driver it is controlled by i2c (supports SPI too). What happened to the conversation about putting codecs on the controlling bus and then linking them to the data bus?
The current CS4270 driver doesn't support device trees. When I wrote it, the idea of putting I2C info in the device tree was not finalized, and since the driver is supposed to be cross-platform, I decided to do it the old-fashioned way. Before I update the code, however, I'm waiting for:
- The current code to be accepted into the tree
- ASoC is updated to V2
- The current drivers are updated to support ASoC V2.
I've been trying to get the i2c code in for two months. Hopefully it will go in soon, no one had made any comments on it recently. Have you tried your code with it?
No. I don't like updating my patches with new features while they're undergoing review. If something is clearly wrong with the patch, then I'll fix it and resubmit. But I really don't like to support new stuff just because it's there.
There is nothing stopping your from putting a node for the CS4270 on the i2c bus today. It just won't trigger the loading of the driver.
Yes, the thing that's stopping me is that I don't want to do 20 things at once. I already have pending patches that I'm trying to get in. Once those are in, then I will consider additional work.
Don't we want to follow the device tree policy of putting the device on the controlling bus and then link it to the data bus?
Normally, that sounds like a good idea, but the cs4270 is an I2S device first, and an I2C device second. I need to be able to find that codec from the I2S node. My I2S driver would not know to scan all I2C devices to find the codec.
It makes it a little easier but it doesn't fix everything. We need to start looking at it since none of the example driver for it are device tree based.
I will look at it, *after* my current V1 driver has been applied to the tree.
It still has problems with wanting 'struct platform_device' when we have 'struct of_platform_device' pointers. It also doesn't know how to dynamically load codecs based on device trees.
I agree that these things need to be fixed. I look forward to thinking about these problems, *after* my V1 patches have been applied.
Liam messed up all of my code when he refactored it in late December.
Bummer.
I've switched over to the current SOC code for the moment. The big thing that v2 fixes is that SOC is changed to being a subsystem instead of platform driver. Being a subsystem is the correct model.
It would be good if more pieces of v2 get push forward. Then we can sort out the device tree issues in it.
I agree.
Adding the second device tree node doesn't have anything to do with ASOC v2. It's specific to powerpc and device trees.
Ok, but making my CS4270 driver device-tree aware is a completely separate task from what this patchset is addressing.
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
Don't we want to follow the device tree policy of putting the device on the controlling bus and then link it to the data bus?
Normally, that sounds like a good idea, but the cs4270 is an I2S device first, and an I2C device second. I need to be able to find that codec from the I2S node. My I2S driver would not know to scan all I2C devices to find the codec.
The device tree is a description of the hardware; not software. It's not a good idea to break with convention due to current driver architecture.
Cheers, g.
Grant Likely wrote:
The device tree is a description of the hardware; not software. It's not a good idea to break with convention due to current driver architecture.
I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so the only way to make this code work is to bend some rules. Right now, the CS4270 driver does not support platform drivers or the device tree, so there's no point in putting a child I2C node for it. As I mentioned in other posts, I will be more than happy to update the CS4270 driver to support this new paradigm (which was invented after the CS4270 driver was written) *after* this current patchset is applied.
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
The device tree is a description of the hardware; not software. It's not a good idea to break with convention due to current driver architecture.
I believe that with ASoC V1, I'm stuck between a rock and a hard place, and so the only way to make this code work is to bend some rules. Right now, the CS4270 driver does not support platform drivers or the device tree, so there's no point in putting a child I2C node for it. As I mentioned in other posts, I will be more than happy to update the CS4270 driver to support this new paradigm (which was invented after the CS4270 driver was written) *after* this current patchset is applied.
If you need to bend rules, then do it in a place where it won't bite us in the butt down the road. (ie. not with the device tree). Do hacky stuff in the platform code if you need to because it can be changed easily down the road.
g.
On Thu, Jan 03, 2008 at 11:54:24AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
On 1/1/08, Jon Smirl jonsmirl@gmail.com wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
[snip]
Don't we want to follow the device tree policy of putting the device on the controlling bus and then link it to the data bus?
Normally, that sounds like a good idea, but the cs4270 is an I2S device first, and an I2C device second. I need to be able to find that codec from the I2S node. My I2S driver would not know to scan all I2C devices to find the codec.
And what distinction are you drawing between "first" and "second" here? For the device tree, the primary bus should the the one by which it's addressable - i.e. where the control registers are, not the data path.
Why would the I2S need to scan for codecs? Wouldn't it be up to the codec driver to register with I2S?
David Gibson wrote:
And what distinction are you drawing between "first" and "second" here?
Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection, but it will never work without an I2S connection.
Why would the I2S need to scan for codecs? Wouldn't it be up to the codec driver to register with I2S?
Not in ASoC V1. The codec driver registers with ASoC, but the actual connection to other devices (e.g. the I2S driver) is done either in the I2S driver or in the fabric driver, depending on your mood. And that connection is done via a pointer to a structure in the codec driver.
On Fri, Jan 04, 2008 at 08:39:54PM -0600, Timur Tabi wrote:
David Gibson wrote:
And what distinction are you drawing between "first" and "second" here?
Oh, that's an easy one: The CS4270 can work without an I2C or SPI connection, but it will never work without an I2S connection.
Why would the I2S need to scan for codecs? Wouldn't it be up to the codec driver to register with I2S?
Not in ASoC V1. The codec driver registers with ASoC, but the actual connection to other devices (e.g. the I2S driver) is done either in the I2S driver or in the fabric driver, depending on your mood. And that connection is done via a pointer to a structure in the codec driver.
Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it?
On Sun, Jan 06, 2008 at 11:46:37AM +1100, David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it?
That's what ASoC v2 is doing, more or less (the core brings things on line rather than drivers doing it). For v1 so long as it doesn't cause any problems in practice I'm not sure I'd worry about it too much.
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it?
Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules.
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.
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it?
Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules.
I'd just like to emphasise this point - ASoC v1 really doesn't understand the idea that the components of the sound subsystem might be probed separately. It's set up to handle bare hardware with everything being probed from code in the machine/fabric driver. This makes life very messy for platforms with something like the device tree.
As has been said, handling this properly is one of the major motivations behind ASoC v2.
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.
This is certainly the approach we want to take from an ASoC point of view.
On Mon, Jan 07, 2008 at 06:28:54PM +0000, Mark Brown wrote:
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it?
Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules.
I'd just like to emphasise this point - ASoC v1 really doesn't understand the idea that the components of the sound subsystem might be probed separately. It's set up to handle bare hardware with everything being probed from code in the machine/fabric driver. This makes life very messy for platforms with something like the device tree.
As has been said, handling this properly is one of the major motivations behind ASoC v2.
Ick. Ok.
Nonetheless, messing up the device tree to workaround ASoC V1's silly limitations is not a good idea. The device tree must represent the hardware as much as possible. If that means we have to have a bunch of platform-specific hacks to instatiate the drivers in the correct order / combination, that's unfortunate, but there you go.
On 1/9/08, David Gibson david@gibson.dropbear.id.au wrote:
On Mon, Jan 07, 2008 at 06:28:54PM +0000, Mark Brown wrote:
On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote:
David Gibson wrote:
Ok, but couldn't you strucutre your I2S or fabric driver so that it only becomes fully operational once the codec driver has registered with it?
Not in ASoC V1. You have to understand, ASoC V1 was designed without any consideration for runtime-bindings and other OF goodies. All connections between the drivers are static, literally. In fact, I wouldn't be surprised if some ASoC drivers cannot be compiled as modules.
I'd just like to emphasise this point - ASoC v1 really doesn't understand the idea that the components of the sound subsystem might be probed separately. It's set up to handle bare hardware with everything being probed from code in the machine/fabric driver. This makes life very messy for platforms with something like the device tree.
As has been said, handling this properly is one of the major motivations behind ASoC v2.
Ick. Ok.
Nonetheless, messing up the device tree to workaround ASoC V1's silly limitations is not a good idea. The device tree must represent the hardware as much as possible. If that means we have to have a bunch of platform-specific hacks to instatiate the drivers in the correct order / combination, that's unfortunate, but there you go.
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.
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
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
Liam Girdwood wrote:
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.
With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay? I want to get it into 2.6.25.
Keep in mind:
1) ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1 PowerPC driver "100% correct".
2) The CS4270 driver does not support I2C nodes in the device tree, so there's not point in adding any to the 8610 DTS.
3) Liam and I are working on porting this driver to ASoC V2 and resolving all open PPC issue, but that won't be done in time for 2.6.25.
On 1/10/08, Timur Tabi timur@freescale.com wrote:
Liam Girdwood wrote:
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.
With that in mind, can I get some kind of consensus from the PPC side as to whether this ASoC V1 driver is okay? I want to get it into 2.6.25.
Keep in mind:
- ASoC V1 is not PowerPC-friendly, so it's impossible to make an ASoC V1
PowerPC driver "100% correct".
The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences.
However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term.
So, I'm okay with merging the driver *minus* the .dts and booting-without-of.txt changes.
Cheers, g.
Grant Likely wrote:
The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences.
However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term.
I agree. Correct me if I'm wrong, but I think the only device tree "issue" is the definition of the 'codec' node under the SSI node. If so, I'm not sure what other changes need to be mode.
On 1/10/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
The driver doesn't need to be 100% correct. Drivers are easy to change if they aren't quite right. There are no long term consequences.
However, the device tree issues must be addressed before it is merged and deployed. Otherwise we end up having to support poorly designed trees over the long term.
I agree. Correct me if I'm wrong, but I think the only device tree "issue" is the definition of the 'codec' node under the SSI node. If so, I'm not sure what other changes need to be mode.
Isn't your codec is i2c controlled? Where does the main node for the code live, i2c bus or ssi bus? What does the link between the buses look like for pointing to the codec entry?
What about fsl,ssi being too generic for a compatible type?
-- Timur Tabi Linux kernel developer at Freescale
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the code live, i2c bus or ssi bus? What does the link between the buses look like for pointing to the codec entry?
The CS4270 driver is "old style", which means it probes all possible I2C addresses until it finds a hit, and then stops. This has all the obvious drawbacks, but I'm stuck with that design for now.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
ssi@16000 { compatible = "fsl,mpc8610-ssi";
On 1/10/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the code live, i2c bus or ssi bus? What does the link between the buses look like for pointing to the codec entry?
The CS4270 driver is "old style", which means it probes all possible I2C addresses until it finds a hit, and then stops. This has all the obvious drawbacks, but I'm stuck with that design for now.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
ssi@16000 { compatible = "fsl,mpc8610-ssi";
Nit: node name should be either i2s@16000 (the mode that it is in), or sound@16000 (if you feel that this node encapsulates the concept of a sound device enough).
Cheers, g.
Grant Likely wrote:
Nit: node name should be either i2s@16000 (the mode that it is in), or sound@16000 (if you feel that this node encapsulates the concept of a sound device enough).
Well, SSI stands for "Synchronous Serial Interface" (although it's capable of asynchronous communication as well). From the manual:
"The SSI is a full-duplex, serial port that allows the chip to communicate with a variety of serial devices. These serial devices can be standard CODer-DECoder (CODECs), Digital Signal Processors (DSPs), microprocessors, peripherals, and popular industry audio CODECs that implement the inter-IC sound bus standard (I2S) and Intel AC97 standard."
It might an I2S device in this case, but it could be an AC97 device in some other case. It all depends on how the board is wired. Do we really want to change the name of an SOC device based on what it's connected to?
On 1/10/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
Isn't your codec is i2c controlled? Where does the main node for the code live, i2c bus or ssi bus? What does the link between the buses look like for pointing to the codec entry?
The CS4270 driver is "old style", which means it probes all possible I2C addresses until it finds a hit, and then stops. This has all the obvious drawbacks, but I'm stuck with that design for now.
So the codec is controlled from the i2c bus and SSI is used to supply it with data. Based on what has been said on this list, the device tree node for the codec should be on the i2c bus with a link from the ssi bus to it.
What about fsl,ssi being too generic for a compatible type?
Already fixed:
ssi@16000 { compatible = "fsl,mpc8610-ssi";
-- Timur Tabi Linux kernel developer at Freescale
Jon Smirl wrote:
So the codec is controlled from the i2c bus and SSI is used to supply it with data. Based on what has been said on this list, the device tree node for the codec should be on the i2c bus with a link from the ssi bus to it.
I'm working on that now. I'll have a new patch with this exact change this afternoon.
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
Liam Girdwood wrote:
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'm working on some minor updates, so hold off for now. I'll post a new patch later this afternoon.
I'll then port (what I can) to V2, although I may need some assistance with some of the PPC sections.
I'll be 100% available for that.
On 1/2/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
If that's the case the cs4270 should be in the i2c bus node (missing currently) and then a link from the SSI bus would point to it.
The CS4270 is a child of both the I2C bus *and* the SSI bus. It needs to have two nodes, one under each. Your're right in that there needs to be a link, but until the code is updated to ASoC V2, I think it's premature to add that support.
Why not be a child of the i2c bus with a phandle to the ssi bus? That is the direction we've gone with other multi attachment devices. (ie. Ethernet PHYs. Child of the MDIO node, phandle to link the Ethernet controller with the PHY)
Cheers, g.
Grant Likely wrote:
Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is. So if anything, I would need a pointer from the SSI bus *to* the respective child on the I2C bus.
I know little about platform devices/drivers, so I don't know how to use them.
Currently, I have a design flaw in my driver in that if I have two SSIs, and each one is attached to a CS4270, I don't have any way of making sure that the right CS4270 is using the right I2C address. I'm guessing that if I switch to a platform-based model, I can resolve this issue. But for now, the CS4270 doesn't support that, so that patchset I have submitted works with what I have. After my patchset has been applied, I'll be more than happy to look into updating the CS4270 (and everything else) to use the platform model for I2C.
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is. So if anything, I would need a pointer from the SSI bus *to* the respective child on the I2C bus.
That's fine too (it's what is done with Ethernet PHYs). My preference is the other way around, but it's not a big issue in this case.
Cheers, g.
Grant Likely wrote:
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is. So if anything, I would need a pointer from the SSI bus *to* the respective child on the I2C bus.
That's fine too (it's what is done with Ethernet PHYs). My preference is the other way around, but it's not a big issue in this case.
I'd just link in both directions, and let software follow it in whichever direction it prefers.
-Scott
On 1/3/08, Scott Wood scottwood@freescale.com wrote:
Grant Likely wrote:
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is. So if anything, I would need a pointer from the SSI bus *to* the respective child on the I2C bus.
That's fine too (it's what is done with Ethernet PHYs). My preference is the other way around, but it's not a big issue in this case.
I'd just link in both directions, and let software follow it in whichever direction it prefers.
Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings. Don't put that burden on the dts author. (the software principle of defining things in one place only applies here)
g.
Grant Likely wrote:
On 1/3/08, Scott Wood scottwood@freescale.com wrote:
I'd just link in both directions, and let software follow it in whichever direction it prefers.
Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings.
Software is, however, lousy at correctly wading through poorly-structured data (which device trees are full of) to figure out how to locate the link it wants to follow backwards.
-Scott
On Thu, Jan 03, 2008 at 01:18:31PM -0600, Scott Wood wrote:
Grant Likely wrote:
Gah! Don't do that! Then you need to maintain both directions in the dts file. Software is good at generating reverse mappings.
Software is, however, lousy at correctly wading through poorly-structured data (which device trees are full of) to figure out how to locate the link it wants to follow backwards.
Thinking about that from an ASoC v2 perspective the approach that this immediately suggests is to represent the links between the devices in the device tree and then have those links reference the attached devices.
Grant Likely wrote:
On 1/3/08, Scott Wood scottwood@freescale.com wrote:
Grant Likely wrote:
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Why not be a child of the i2c bus with a phandle to the ssi bus?
Because when I probe the SSI node, I want to know what the attached codec is. So if anything, I would need a pointer from the SSI bus *to* the respective child on the I2C bus.
That's fine too (it's what is done with Ethernet PHYs). My preference is the other way around, but it's not a big issue in this case.
I'd just link in both directions, and let software follow it in whichever direction it prefers.
Gah! Don't do that! Then you need to maintain both directions in the dts file.
So? What's wrong with that?
Software is good at generating reverse mappings.
What software would that be? Currently, there is no software that will do that? Or are you saying that you want my driver to search the entire device tree until it finds the reverse mapping? I don't think *that* is a good idea.
Don't put that burden on the dts author.
As the DTS author in question, I hereby declare that such a requirement is not a burden in the slightest. Thank you.
On 1/4/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Don't put that burden on the dts author.
As the DTS author in question, I hereby declare that such a requirement is not a burden in the slightest. Thank you.
Dude, you work for *Freescale*. The set of dts authors affected include every engineer writing a device tree for a board that uses this part. :-)
Cheers, g.
On Tue, Jan 01, 2008 at 12:25:32PM -0500, Jon Smirl wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
Grah! If there's one obvious frequency for a node, it should always be "clock-frequency". This bus-frequency nonsense seems to be a disease that started as a secondary frequency in Freescale CPU nodes, and has escaped to all sorts of other places.
Jon Smirl wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
I'm trying to make this node as generic as possible. The fabric driver is the one that will parse this node and pass the data to the codec driver, so I can't use any codec-specific terms.
The API from the fabric driver for passing clock information includes a clock ID, a direction, and a frequency. I can do something like this:
clock1 = <0, bb8000>
Would that be better?
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
I'm going under the assumption that MCLK does not change once the board is up and running. In your case, you'd need to do something quite different, because you're not reading the clock info from the device tree and passing it to the codec at initialization once. If you want to define an extension to the 'codec' child node that handles that, I'll add it to the documentation.
On Wed, Jan 02, 2008 at 09:10:44AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
Does this need to be bus-frequency? It's always called MCLK in all of the literature.
I'm trying to make this node as generic as possible. The fabric driver is the one that will parse this node and pass the data to the codec driver, so I can't use any codec-specific terms.
The API from the fabric driver for passing clock information includes a clock ID, a direction, and a frequency. I can do something like this:
clock1 = <0, bb8000>
Would that be better?
To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like...
In my case the MCLK comes from a chip on the i2c bus that is programmable How would that be encoded?.
I'm going under the assumption that MCLK does not change once the board is up and running. In your case, you'd need to do something quite different, because you're not reading the clock info from the device tree and passing it to the codec at initialization once. If you want to define an extension to the 'codec' child node that handles that, I'll add it to the documentation.
According to the documentation in your patch the bus frequency should already be optional (though I don't immediately see that in the code, but then I'm entirely unfamiliar with OpenFirmware device trees). Boards that reconfigure the clocking at run time can then provide code to set the clocking up at the appropriate times, which is probably what they want anyway.
Mark Brown wrote:
clock1 = <0, bb8000>
Would that be better?
To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like...
The ASoC V1 API for communicating clock data from the fabric driver to the codec driver only allows for three parameters.
According to the documentation in your patch the bus frequency should already be optional
My code does not currently support that configuration, and I don't have any hardware that works that way, so I don't know what it would look like. I'm just trying to make the driver as flexible as possible, given ASoC V1 constraints.
On Thu, Jan 03, 2008 at 12:23:08PM -0600, Timur Tabi wrote:
Mark Brown wrote:
To cover everything you'd need to be able to specify all the clocking parameters, especially a PLL configuration, and also specify more than one of each item. Even then you'd still have problems like...
The ASoC V1 API for communicating clock data from the fabric driver to the codec driver only allows for three parameters.
Each individual call to set_sysclk() only takes three parameters but it can be called repeatedly and some configurations are going to require this. There's also the set_pll() call which will be required by some things too (and again that can support multiple PLLs).
For example, something like this isn't unknown:
- Set PLL input to pin A. - Configure PLL input/output frequencies. - Set codec system clock source to be the PLL
and of course the ordering matters. You can also have other dividers and clock sources within the codec which need configuring and other components outside the codec which need configuring to supply the clocks to the codec.
According to the documentation in your patch the bus frequency should already be optional
My code does not currently support that configuration, and I don't have any hardware that works that way, so I don't know what it would look like. I'm just trying to make the driver as flexible as possible, given ASoC V1 constraints.
Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it.
Mark Brown wrote:
Each individual call to set_sysclk() only takes three parameters but it can be called repeatedly and some configurations are going to require this.
In other words, ...
clock1 = <0, bb8000> clock2 = <1, 653230> clock23 = <0, ab2372>
and of course the ordering matters.
Ok, you got me there. But then, isn't this just another example where the device tree is incapable of describing a complex configuration, and so we need a platform driver?
Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it.
I definitely agree with that. I'll be the first to admit that this driver, much like ASoC V1, is a prototype.
On Fri, Jan 04, 2008 at 08:43:17PM -0600, Timur Tabi wrote:
Mark Brown wrote:
In other words, ...
clock1 = <0, bb8000> clock2 = <1, 653230> clock23 = <0, ab2372>
Yes, something like that would cover it. I'm not sure what is idiomatic for the device tree.
and of course the ordering matters.
Ok, you got me there. But then, isn't this just another example where the device tree is incapable of describing a complex configuration, and so we need a platform driver?
Yes, you could certainly do that - as you say, any device tree based configuration would be optional so it's not a blocker if some things aren't supported.
It'd be nice to have some idea of how to handle it should someone want to do it but I wouldn't think it's essential. The most common case where specific ordering is required is that a PLL will need to have all its inputs configured before the PLL is activated so it'd probably cover a large proportion of cases to do that last.
Indeed. Providing the device tree stuff doesn't get set in stone I'm not sure we need to nail this down perfectly for ASoC v1 when we're running into trouble working around it.
I definitely agree with that. I'll be the first to admit that this driver, much like ASoC V1, is a prototype.
Yes, from an ASoC point of view the driver looks good as it is. The only discussion is about the PowerPC probing stuff.
On 12/19/07, Timur Tabi timur@freescale.com wrote:
sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++ sound/soc/fsl/fsl_ssi.h | 224 +++++++
I'm confused about this part. You built a driver for the mpc8610 ssi port. This port has a device tree entry.
+ ssi@16000 { + compatible = "fsl,ssi"; + cell-index = <0>; + reg = <16000 100>; + interrupt-parent = <&mpic>; + interrupts = <3e 2>; + fsl,mode = "i2s-slave"; + codec { + compatible = "cirrus,cs4270"; + /* MCLK source is a stand-alone oscillator */ + bus-frequency = <bb8000>; + }; + };
But then you don't create an of_platform_driver for this device. Instead you create one for the fabric driver, struct of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI driver into it.
+static struct of_device_id mpc8610_hpcd_match[] = { + { + .compatible = "fsl,ssi", + }, + {} +}; +MODULE_DEVICE_TABLE(of, mpc8610_hpcd_match); + +static struct of_platform_driver mpc8610_hpcd_of_driver = { + .owner = THIS_MODULE, + .name = "mpc8610_hpcd", + .match_table = mpc8610_hpcd_match, + .probe = mpc8610_hpcd_probe, + .remove = mpc8610_hpcd_remove, +};
static int mpc8610_hpcd_probe(struct of_device *ofdev, const struct of_device_id *match) { ..... machine_data->dai.cpu_dai = fsl_ssi_create_dai(&ssi_info);
Isn't this two separate drivers that have been combined into one driver? Or does the fsl_ssi channel only work on the mpc8610_hpcd?
This is the problem of knowing how to load the fabric driver that I was talking about in the other threads. A device that can occur on more than one chip ".compatible = "fsl,ssi"," is being used to pull in a platform specific fabric driver, "mpc8610_hpcd". You can use the kernel config system to select the right driver for ".compatible = "fsl,ssi"," that matches you hardware and compile it in.
But that doesn't work in my environment. My generic channel is "fsl,i2s". I have four different systems booting off from a shared network drive. Each of these systems needs the common "fsl,i2s" driver but they all four need different fabric drivers.
Jon Smirl wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++ sound/soc/fsl/fsl_ssi.h | 224 +++++++
I'm confused about this part. You built a driver for the mpc8610 ssi port. This port has a device tree entry.
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
But then you don't create an of_platform_driver for this device. Instead you create one for the fabric driver, struct of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI driver into it.
That's the best plan I came up with. This is apparently fixed in ASoC V2. From ASoC V1's perspective, the fabric driver must be the master. However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such "device". The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec.
+static struct of_device_id mpc8610_hpcd_match[] = {
- {
.compatible = "fsl,ssi",
- },
- {}
+}; +MODULE_DEVICE_TABLE(of, mpc8610_hpcd_match);
+static struct of_platform_driver mpc8610_hpcd_of_driver = {
- .owner = THIS_MODULE,
- .name = "mpc8610_hpcd",
- .match_table = mpc8610_hpcd_match,
- .probe = mpc8610_hpcd_probe,
- .remove = mpc8610_hpcd_remove,
+};
static int mpc8610_hpcd_probe(struct of_device *ofdev, const struct of_device_id *match) { ..... machine_data->dai.cpu_dai = fsl_ssi_create_dai(&ssi_info);
Isn't this two separate drivers that have been combined into one driver? Or does the fsl_ssi channel only work on the mpc8610_hpcd?
Sorry, I don't understand your question.
This is the problem of knowing how to load the fabric driver that I was talking about in the other threads.
Yes, and the decision I made on this topic is to have the fabric driver probed on the SSI node.
For ASoC V1, I believe the problem is undefined and each driver should be implemented in whatever way works best.
A device that can occur on more than one chip ".compatible = "fsl,ssi"," is being used to pull in a platform specific fabric driver, "mpc8610_hpcd". You can use the kernel config system to select the right driver for ".compatible = "fsl,ssi"," that matches you hardware and compile it in.
Ok, I think I understand that.
But that doesn't work in my environment. My generic channel is "fsl,i2s". I have four different systems booting off from a shared network drive. Each of these systems needs the common "fsl,i2s" driver but they all four need different fabric drivers.
That, I don't understand. fsl,ssi is pretty much the same thing as fsl,i2s, since the SSI *is* an I2S device. It's also an AC97 device, which is why I added the fsl,mode property.
The fabric driver is specific to the board. So you should be using Kconfig to select the fabric driver. There is no node in the device tree for fabric drivers. I thought that was the consensus.
Are you saying that you want to use the same kernel on four different systems? If so, then you need to find a way to compile all fabric drivers together, and at boot time each fabric driver will decide whether it will do anything.
On 1/2/08, Timur Tabi timur@freescale.com wrote:
Are you saying that you want to use the same kernel on four different systems? If so, then you need to find a way to compile all fabric drivers together, and at boot time each fabric driver will decide whether it will do anything.
Yes, I have four different but similar systems. They only differer in the codec chips used. I want to make a single kernel image and then use the device tree to dynamically load the correct codec driver from initrd. That will let me ship a single kernel image that services all four machines. The codecs implement different sound systems from low end to high end.
The correct solution for this is to use kernel modules and trigger their loading based on the device tree. This is the same mechanism used by USB and PCI.
For this model to work you need to split your driver. fsl-ssi and mpc8610_hpcd need to be in two separate drivers. fsl-ssi is easy enough to load since it has a device tree entry.
mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
Instead we could make the separated mpc8610_hpcd fabric driver attach to fsl,ssi.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,ssi", }, {}, };
Then in it's probe code check for the right platform.
unsigned long node = of_get_flat_dt_root(); if (!of_flat_dt_is_compatible(node, "fsl,MPC8610HPCD")) return 0; .. activate the code ...
You also need a static flag to make sure you don't active the driver more than once.
This isn't the best solution since my four fabric drivers will still load and check what platform they are on before exiting but at least it works.
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote: mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate the correct fabric device (probably as a platform_device) from the platform code. Then the correct fabric driver can probe against it.
Cheers, g.
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote: mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate the correct fabric device (probably as a platform_device) from the platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The platform code can create a device that isn't bound to a driver. So why not make this an of_platform_device? This is basically a pseudo device that isn't in the device tree.
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
In the longer term I'd like to kill platform_bus on powerpc and only use of_platform_bus. Platform_bus seems to be functioning like a catch-all and collecting junk from lots of different platforms.
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote: mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate the correct fabric device (probably as a platform_device) from the platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The platform code can create a device that isn't bound to a driver. So why not make this an of_platform_device? This is basically a pseudo device that isn't in the device tree.
Simply because it doesn't have a device node. That's the prime characteristc that differentiates platform_bus from of_platform_bus. What do you bind against in of_platform_bus if you don't have a specific node for it?
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
Yes, but it requires the core ASoC code to not be a module. Then you can use machine_device_initcall() to register the device at a later time.
Cheers, g.
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
Yes, but it requires the core ASoC code to not be a module. Then you can use machine_device_initcall() to register the device at a later time.
How about this for a simpler solution? My mpc5200-psc-ac97 and mpc5200-psc-i2c drivers can create a device on the ASOC bus named after the first entry in the compatible field of the root node. That will cause the correct driver to get activated. I'm in the process of making ASOC drivers dynamically loadable like the i2c ones.
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
Yes, but it requires the core ASoC code to not be a module. Then you can use machine_device_initcall() to register the device at a later time.
How about this for a simpler solution? My mpc5200-psc-ac97 and mpc5200-psc-i2c drivers can create a device on the ASOC bus named after the first entry in the compatible field of the root node. That will cause the correct driver to get activated. I'm in the process of making ASOC drivers dynamically loadable like the i2c ones.
I little icky, but it doesn't sound dangerous (as in shouldn't cause any name conflicts). That may be the best we can do for the time being. But I don't think it is a good idea for the long term.
Cheers, g.
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
Yes, but it requires the core ASoC code to not be a module. Then you can use machine_device_initcall() to register the device at a later time.
How about this for a simpler solution? My mpc5200-psc-ac97 and mpc5200-psc-i2c drivers can create a device on the ASOC bus named after the first entry in the compatible field of the root node. That will cause the correct driver to get activated. I'm in the process of making ASOC drivers dynamically loadable like the i2c ones.
I little icky, but it doesn't sound dangerous (as in shouldn't cause any name conflicts). That may be the best we can do for the time being. But I don't think it is a good idea for the long term.
Simplest long term fix is to allow drivers to bind on the root node. Make this work:
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
Cheers, g.
-- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195
On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote: mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate the correct fabric device (probably as a platform_device) from the platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The platform code can create a device that isn't bound to a driver. So why not make this an of_platform_device? This is basically a pseudo device that isn't in the device tree.
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
In the longer term I'd like to kill platform_bus on powerpc and only use of_platform_bus. Platform_bus seems to be functioning like a catch-all and collecting junk from lots of different platforms.
Not going to happen. of_platform_bus is not the right solution, and in fact we're looking at moving (gradually) away from using of_platform_bus, and instead using platform devices (along with the device node being available for *any* struct device via the arch_sysdata).
On 1/2/08, David Gibson david@gibson.dropbear.id.au wrote:
On Wed, Jan 02, 2008 at 12:12:00PM -0500, Jon Smirl wrote:
On 1/2/08, Grant Likely grant.likely@secretlab.ca wrote:
On 1/2/08, Jon Smirl jonsmirl@gmail.com wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote: mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
The driver can always get the root node. But better yet, instantiate the correct fabric device (probably as a platform_device) from the platform code. Then the correct fabric driver can probe against it.
The meaning of this has finally sunk into my consciousness. The platform code can create a device that isn't bound to a driver. So why not make this an of_platform_device? This is basically a pseudo device that isn't in the device tree.
Alternatively, the best place for this device would be on the ASOC bus, but the ASOC bus hasn't been created when the platform code runs. Maybe I can figure out a place in the platform code to create this device after the ASOC driver has loaded and created the bus. Does the platform code get control back after loading all of the device drivers?
In the longer term I'd like to kill platform_bus on powerpc and only use of_platform_bus. Platform_bus seems to be functioning like a catch-all and collecting junk from lots of different platforms.
Not going to happen. of_platform_bus is not the right solution, and in fact we're looking at moving (gradually) away from using of_platform_bus, and instead using platform devices (along with the device node being available for *any* struct device via the arch_sysdata).
I do agree that of_platform_bus should have been derived from platform_bus, not a separate structure. This is causing problems in the ASLA code where they want typed pointers.
In my little test patch, I disabled platform_bus on my MPC5200. This generated some compiler errors which exposed a bunch of MPC83xxx and Apple code that was getting compiled into my MPC5200 kernel. These were platform bus drivers that weren't properly ifdef'd.
So I guess my objection is more along the lines of getting rid of driver code inside the arch directory and switching everything to modules. Then we could periodically turn off platform bus on each platform and make sure everything still builds.
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Jon Smirl wrote:
For this model to work you need to split your driver. fsl-ssi and mpc8610_hpcd need to be in two separate drivers.
They are two separate drivers. sound/soc/fsl/fsl_ssi.c and sound/soc/fsl/mpc8610_hpcd.c
fsl-ssi is easy enough to load since it has a device tree entry.
mpc8610_hpcd is the harder one to load since it doesn't have a device tree entry. What you want to do it match on the compatible field of the root node.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,MPC8610HPCD", }, {}, };
But this doesn't work since the root is the device tree isn't passed down into the device probe code. (Could this be fixed?)
I don't understand that sentence. Is there a typo?
Instead we could make the separated mpc8610_hpcd fabric driver attach to fsl,ssi.
static struct of_device_id fabric_of_match[] = { { .compatible = "fsl,ssi", }, {}, };
Then in it's probe code check for the right platform.
That's what I do. I attach to fsl,ssi, gather the information from the device tree, and then call a private API to initialize the SSI driver.
On 1/2/08, Timur Tabi timur@freescale.com wrote:
That's the best plan I came up with. This is apparently fixed in ASoC V2. From ASoC V1's perspective, the fabric driver must be the master. However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such "device". The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec.
Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead? I think that is the consensus we were leaning towards in the last discussion about this issue.
But that doesn't work in my environment. My generic channel is "fsl,i2s". I have four different systems booting off from a shared network drive. Each of these systems needs the common "fsl,i2s" driver but they all four need different fabric drivers.
That, I don't understand. fsl,ssi is pretty much the same thing as fsl,i2s, since the SSI *is* an I2S device. It's also an AC97 device, which is why I added the fsl,mode property.
This is one of the examples of where the compatible properties are trying to be far to generic about what they are. How do you define what "fsl,ssi" is? What happens when Freescale produces another peripheral that can do ssi but isn't register level compatible?
In my opinion, it is far better to be specific in the device tree and teach the driver about what versions it is able to bind against. In this case, I would use "fsl,mpc8610-ssi" or maybe better yet: "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I don't like the idea of a separate fsl,mode property to describe the behaviour of multifunction peripherals. It makes probing more difficult when there is a different driver for each mode.
The fabric driver is specific to the board. So you should be using Kconfig to select the fabric driver. There is no node in the device tree for fabric drivers. I thought that was the consensus.
No, the desire is to go multiplatform in ppc. That means you cannot use Kconfig to select the correct fabric driver.
Are you saying that you want to use the same kernel on four different systems? If so, then you need to find a way to compile all fabric drivers together, and at boot time each fabric driver will decide whether it will do anything.
Yes! That is exactly what we want to support in arch/powerpc. Use platform code to select the correct fabric driver.
Cheers, g.
On Wed, Jan 02, 2008 at 09:28:12AM -0700, Grant Likely wrote:
On 1/2/08, Timur Tabi timur@freescale.com wrote:
However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such "device". The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec.
I'm not sure I'd go so far as to say that the fabric/machine driver is purely an abstraction. It does represent real hardware, often with software control.
Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead? I think that is the consensus we were leaning towards in the last discussion about this issue.
With ASoC v2 rather than having a single monolithic ASoC device which probes everything ASoC is converted into a proper subsystem with each component (codec, SoC CPU port, whatever) having a sysfs-visible driver. These drivers register with the core as they are probed with the probing happening through whatever mechanism is appropriate for the driver.
The machine support code (fabric driver in PowerPC terms, I think?) tells the core how everything is connected together by registering devices representing the links (eg, I2S) between the codecs, CPU and other devices. The ASoC core is then responsible for ensuring that all the required components are present before it registers with the ALSA core.
Mark Brown wrote:
The machine support code (fabric driver in PowerPC terms, I think?) tells the core how everything is connected together by registering devices representing the links (eg, I2S) between the codecs, CPU and other devices. The ASoC core is then responsible for ensuring that all the required components are present before it registers with the ALSA core.
I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC itself, and everything it needed could be obtained from the device tree.
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:
Mark Brown wrote:
The machine support code (fabric driver in PowerPC terms, I think?) tells the core how everything is connected together by registering devices representing the links (eg, I2S) between the codecs, CPU and other devices. The ASoC core is then responsible for ensuring that all the required components are present before it registers with the ALSA core.
I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC itself, and everything it needed could be obtained from the device tree.
Nice idea in principle, and may be the way to go ultimately, but very tricky in practice. The whole reason the fabric driver concept exists (from other archs) is that there are an awful lot of variants on how to wire the sound components together. Devising a way of expressing those connections in the device tree that's sufficient will be very curly. Then we'd have to build the fabric driver that can parse and process them all. And then, people will no doubt produce device trees with errors in the connection information, so we'll still need platform-specific workarounds.
If we want sound working any time soon, we'll want to stick with the platform based fabric drivers for the time being.
On Fri, Jan 04, 2008 at 10:47:25AM +1100, David Gibson wrote:
On Thu, Jan 03, 2008 at 12:16:19PM -0600, Timur Tabi wrote:
I'm no expert on this, but I think from the PowerPC point-of-view, the *ideal* situation would be if the ASoC fabric driver were generic, maybe even part of ASoC itself, and everything it needed could be obtained from the device tree.
Nice idea in principle, and may be the way to go ultimately, but very tricky in practice. The whole reason the fabric driver concept exists (from other archs) is that there are an awful lot of variants on how to wire the sound components together. Devising a way of expressing those connections in the device tree that's sufficient will be very curly. Then we'd have to build the fabric driver that can parse and process them all.
Yes, there's an issue with complexity here. Some of the individual components are going to have quite a lot of different things to configure by themselves even for static use and the choices made may depend on the usage at run time rather than being a static property of the hardware. It's also more than just connections - many machine drivers will provide control for components like analogue switches or simple amplifiers controlled through GPIO lines or memory mapped registers (these are generally specific to the board).
As a result I would expect that you will always have systems using platform based drivers. I don't think that this is a bad thing - something that can completely replace them would be able to do anything that can be done in C in the kernel.
And then, people will no doubt produce device trees
with errors in the connection information, so we'll still need platform-specific workarounds.
The other concern with this is that it risks turning the interface to the codec and controller drivers into an ABI which isn't expected at the minute and might cause problems in the future. At the minute the drivers export constants to their users defining the parameters they can configure and (for things like source selection) the possible values. These can currently be changed at will and there's no great consistency in their values between drivers.
There would also be difficulties in writing the device tree - without the symbolic names you're going to end up with strings of numeric constants in the device tree which are not going to be terribly readable and will be error prone.
If we want sound working any time soon, we'll want to stick with the platform based fabric drivers for the time being.
Like I say, I would expect that you're always going to want to have platform based drivers. Even if a given board can be represented in a device tree some users will find it more straightforward or convenient to write C code for their platform and have the device tree specify more basic configuration options that correspond to the things they want to vary between boards.
Grant Likely wrote:
Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead?
I don't know. I haven't really looked at V2 yet. You'll have to ask Liam Girdwood.
This is one of the examples of where the compatible properties are trying to be far to generic about what they are. How do you define what "fsl,ssi" is?
The SSI is a specific Freescale device, so I think it's pretty well defined.
What happens when Freescale produces another peripheral that can do ssi but isn't register level compatible?
It won't be called the SSI. It will be called something else.
In my opinion, it is far better to be specific in the device tree and teach the driver about what versions it is able to bind against. In this case, I would use "fsl,mpc8610-ssi" or maybe better yet: "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I can work with that, but the SSI could be placed into any future 83xx, 85xx, or 86xx SOC, and the driver will still work with it as-is.
I don't like the idea of a separate fsl,mode property to describe the behaviour of multifunction peripherals. It makes probing more difficult when there is a different driver for each mode.
Can you propose an alternative? The driver needs to know what mode to use when communicating with its codec. How am I supposed to know if I have an I2S codec or an AC97 codec?
The fabric driver is specific to the board. So you should be using Kconfig to select the fabric driver. There is no node in the device tree for fabric drivers. I thought that was the consensus.
No, the desire is to go multiplatform in ppc. That means you cannot use Kconfig to select the correct fabric driver.
I don't see any way of avoiding this with ASoC V1.
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Does that mean with ASoC V2 you can instantiate it with the board specific platform code instead?
I don't know. I haven't really looked at V2 yet. You'll have to ask Liam Girdwood.
This is one of the examples of where the compatible properties are trying to be far to generic about what they are. How do you define what "fsl,ssi" is?
The SSI is a specific Freescale device, so I think it's pretty well defined.
What happens when Freescale produces another peripheral that can do ssi but isn't register level compatible?
It won't be called the SSI. It will be called something else.
Heh, I've seen enough to know that it's virtually impossible for a company to maintain a consistent naming scheme all the time. Better to be specific now and add generic names sometime in the future rather than the other way around.
In my opinion, it is far better to be specific in the device tree and teach the driver about what versions it is able to bind against. In this case, I would use "fsl,mpc8610-ssi" or maybe better yet: "fsl,mpc8610-ssi,i2s" (MPC8610 SSI device in I2S mode).
I can work with that, but the SSI could be placed into any future 83xx, 85xx, or 86xx SOC, and the driver will still work with it as-is.
The have the device trees claim compatibility with the older fsl,mpc8610-ssi device specifically. ie: compatible = "fsl,mpc83<whatever>-ssi,ac97", "fsl,mpc8610-ssi,ac97";
I don't like the idea of a separate fsl,mode property to describe the behaviour of multifunction peripherals. It makes probing more difficult when there is a different driver for each mode.
Can you propose an alternative? The driver needs to know what mode to use when communicating with its codec. How am I supposed to know if I have an I2S codec or an AC97 codec?
Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or for AC7, compatible = "fsl,mpc8610-ssi,ac97"
Cheers, g.
Grant Likely wrote:
Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or for AC7, compatible = "fsl,mpc8610-ssi,ac97"
That won't work. There are too many variations. I think a separate property just makes more sense. Frankly, I don't see what's wrong with it.
On 1/3/08, Timur Tabi timur@freescale.com wrote:
Grant Likely wrote:
Make the compatible property tell you! :-) If it's connected to an I2S codec, then it could be compatible = "fsl,mpc8610-ssi,i2s". Or for AC7, compatible = "fsl,mpc8610-ssi,ac97"
That won't work. There are too many variations. I think a separate property just makes more sense. Frankly, I don't see what's wrong with it.
Sure it will, that's exactly what I'm doing with the 5200, but I won't argue the point. My *opinion* is that using compatible is a more elegant approach for this type of multifunction device, but using a mode property is neither wrong or bad.
g.
On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++ sound/soc/fsl/fsl_ssi.h | 224 +++++++
I'm confused about this part. You built a driver for the mpc8610 ssi port. This port has a device tree entry.
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
But then you don't create an of_platform_driver for this device. Instead you create one for the fabric driver, struct of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI driver into it.
That's the best plan I came up with. This is apparently fixed in ASoC V2. From ASoC V1's perspective, the fabric driver must be the master. However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such "device". The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec.
Instantiating the fabric driver off any node is wrong, precisely because it is an abstraction. The fabric driver should be instantiated by the platform code.
On 1/2/08, David Gibson david@gibson.dropbear.id.au wrote:
On Wed, Jan 02, 2008 at 09:29:57AM -0600, Timur Tabi wrote:
Jon Smirl wrote:
On 12/19/07, Timur Tabi timur@freescale.com wrote:
sound/soc/fsl/fsl_ssi.c | 614 +++++++++++++++++++ sound/soc/fsl/fsl_ssi.h | 224 +++++++
I'm confused about this part. You built a driver for the mpc8610 ssi port. This port has a device tree entry.
ssi@16000 {
compatible = "fsl,ssi";
cell-index = <0>;
reg = <16000 100>;
interrupt-parent = <&mpic>;
interrupts = <3e 2>;
fsl,mode = "i2s-slave";
codec {
compatible = "cirrus,cs4270";
/* MCLK source is a stand-alone oscillator */
bus-frequency = <bb8000>;
};
};
But then you don't create an of_platform_driver for this device. Instead you create one for the fabric driver, struct of_platform_driver mpc8610_hpcd_of_driver, and directly link the SSI driver into it.
That's the best plan I came up with. This is apparently fixed in ASoC V2. From ASoC V1's perspective, the fabric driver must be the master. However, it doesn't make sense to have a node in the device tree for the fabric driver, because there is no such "device". The fabric driver is an abstraction. So I need to chose some other node to probe the fabric driver with. I chose the SSI, since each SSI can have only one codec.
Instantiating the fabric driver off any node is wrong, precisely because it is an abstraction. The fabric driver should be instantiated by the platform code.
Instantiating it from the platform code forces me to put it either the of_platform_bus or the platform_bus since there aren't any other buses around when the platform code runs. Platform bus doesn't implement dynamic module loading. So that means it has to go onto the of_platform_bus. That implies that is it a pseudo-device without a pseudo-device entry in the device tree which is fine with me. I'll need to poke around in the of_bus code and see if the driver will load without a device tree entry.
A simple fix to this would be to let me instantiate the driver off from the root node of the tree. That's the conceptually correct place for instantiating a driver that extends the platform code. Should I try adjusting the of probing code to pass the node in, or are there major objections?
Also, as others have pointed out, this driver is not an abstraction. It represents the mess of wires hooking the codec up to the jacks on the back panel and possibly GPIO pins that control the wiring. You need this because the pins on HD audio codecs are completely reconfigurable and the same chip can be wired in a thousand different ways. It lets you have a generic codec driver and the move the platform specific code out of the driver.
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Thu, Jan 03, 2008 at 09:54:45AM -0500, Jon Smirl wrote:
On 1/2/08, David Gibson david@gibson.dropbear.id.au wrote:
[snip]
Instantiating the fabric driver off any node is wrong, precisely because it is an abstraction. The fabric driver should be instantiated by the platform code.
Instantiating it from the platform code forces me to put it either the of_platform_bus or the platform_bus since there aren't any other buses around when the platform code runs. Platform bus doesn't implement dynamic module loading. So that means it has to go onto the of_platform_bus. That implies that is it a pseudo-device without a pseudo-device entry in the device tree which is fine with me. I'll need to poke around in the of_bus code and see if the driver will load without a device tree entry.
You're letting implementation warts influence basic design decisions. This is not sensible. Step back and think for a moment, work out a sane organization *then* think how you might need to fix or workaround limitations of existing infrastructure.
A simple fix to this would be to let me instantiate the driver off from the root node of the tree. That's the conceptually correct place for instantiating a driver that extends the platform code. Should I try adjusting the of probing code to pass the node in, or are there major objections?
The current probing system can't instantiate a device for the root node in any sane way, since it takes a list of suitable busses.
The constructor based approach we're looking at implementing could do it. It should, in any case, be constructing a platform_device - so the platform bus code would still need to be extended to handle the module loading. Creating it as an of_platform device bound to the root node might be a workable interim solution though.
of_platform_device simply does not *ever* make sense conceptually: the type of struct device wrapper in use depends on the bus the device is attached to, not on how we figured out the device was there. OF can potentially give information about any sort of device be it simple-bus, i2c, PCI or whatever connected.
Also, as others have pointed out, this driver is not an abstraction. It represents the mess of wires hooking the codec up to the jacks on the back panel and possibly GPIO pins that control the wiring. You need this because the pins on HD audio codecs are completely reconfigurable and the same chip can be wired in a thousand different ways. It lets you have a generic codec driver and the move the platform specific code out of the driver.
Well, "abstraction" is maybe not the right word. But the point is that the fabric driver doesn't represent a neatly isolated device with well defined bus connections. Instead it represents the tangle of essentially every link between audio devices in the platform. About the clearest possible example of a true "platform device" (as opposed to a device on some bus that just doesn't have any bus-specific logic).
participants (12)
-
David Gibson
-
Grant Likely
-
Jon Loeliger
-
Jon Smirl
-
Lee Revell
-
Liam Girdwood
-
Liam Girdwood
-
Mark Brown
-
Olof Johansson
-
Scott Wood
-
Takashi Iwai
-
Timur Tabi