On Sun, May 24, 2009 at 7:38 PM, Jon Smirl jonsmirl@gmail.com wrote:
Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
Signed-off-by: Jon Smirl jonsmirl@gmail.com
sound/soc/fsl/Kconfig | 7 +++ sound/soc/fsl/Makefile | 3 + sound/soc/fsl/pcm030-audio-fabric.c | 95 +++++++++++++++++++++++++++++++++++ 3 files changed, 105 insertions(+), 0 deletions(-) create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c
diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 3bce952..79579ae 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -39,4 +39,11 @@ config SND_SOC_MPC5200_AC97 help Say Y here to support the MPC5200 PSCs in AC97 mode.
+config SND_MPC52xx_SOC_PCM030
- tristate "SoC AC97 Audio support for Phytec pcm030 and WM9712"
- depends on PPC_MPC5200_SIMPLE
- select SND_SOC_MPC5200_AC97
- select SND_SOC_WM9712
- help
- Say Y if you want to add support for sound on the Phytec pcm030 baseboard.
diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile index 14631a1..66d88c8 100644 --- a/sound/soc/fsl/Makefile +++ b/sound/soc/fsl/Makefile @@ -15,3 +15,6 @@ obj-$(CONFIG_SND_MPC52xx_DMA) += mpc5200_dma.o obj-$(CONFIG_SND_SOC_MPC5200_I2S) += mpc5200_psc_i2s.o obj-$(CONFIG_SND_SOC_MPC5200_AC97) += mpc5200_psc_ac97.o
+# MPC5200 Machine Support +obj-$(CONFIG_SND_MPC52xx_SOC_PCM030) += pcm030-audio-fabric.o
diff --git a/sound/soc/fsl/pcm030-audio-fabric.c b/sound/soc/fsl/pcm030-audio-fabric.c new file mode 100644 index 0000000..2c426d5 --- /dev/null +++ b/sound/soc/fsl/pcm030-audio-fabric.c @@ -0,0 +1,95 @@ +/*
- Phytec pcm030 driver for the PSC of the Freescale MPC52xx
- configured as AC97 interface
- Copyright 2008 Jon Smirl, Digispeaker
- Author: Jon Smirl jonsmirl@gmail.com
- 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 <linux/of_device.h> +#include <linux/of_platform.h> +#include <linux/dma-mapping.h>
+#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/initval.h> +#include <sound/soc.h> +#include <sound/soc-of-simple.h>
+#include "mpc5200_dma.h" +#include "mpc5200_psc_ac97.h" +#include "../codecs/wm9712.h"
+static struct snd_soc_device device; +static struct snd_soc_card card;
+static struct snd_soc_dai_link pcm030_fabric_dai[] = { +{
- .name = "AC97",
- .stream_name = "AC97 Analog",
- .codec_dai = &wm9712_dai[WM9712_DAI_AC97_HIFI],
- .cpu_dai = &psc_ac97_dai[MPC5200_AC97_NORMAL],
+}, +{
- .name = "AC97",
- .stream_name = "AC97 IEC958",
- .codec_dai = &wm9712_dai[WM9712_DAI_AC97_AUX],
- .cpu_dai = &psc_ac97_dai[MPC5200_AC97_SPDIF],
+}, +};
+static __init int pcm030_fabric_init(void) +{
- struct platform_device *pdev;
- int rc;
- if (!machine_is_compatible("phytec,pcm030"))
- return -ENODEV;
- card.platform = &mpc5200_audio_dma_platform;
- card.name = "pcm030";
- card.dai_link = pcm030_fabric_dai;
- card.num_links = ARRAY_SIZE(pcm030_fabric_dai);
- device.card = &card;
- device.codec_dev = &soc_codec_dev_wm9712;
- pdev = platform_device_alloc("soc-audio", 1);
- if (!pdev) {
- pr_err("pcm030_fabric_init: platform_device_alloc() failed\n");
- return -ENODEV;
- }
- platform_set_drvdata(pdev, &device);
- device.dev = &pdev->dev;
- rc = platform_device_add(pdev);
- if (rc) {
- pr_err("pcm030_fabric_init: platform_device_add() failed\n");
- return -ENODEV;
- }
- return 0;
+}
This is ugly. I'd really rather have a generic mechanism for creating a fabric driver based on the OF data. But failing that, it seems to me that this platform device registration should be done in the platform code (arch/powerpc/platforms/52xx). Doing it in a module init looks wrong.
I was trying to do a sort of generic matching mechanism with the of simple stuff; but admittedly it was hacky and half-assed. However, I do still think it is viable to have OF hooks that kick in when codec and machine drivers are registered. If linkage data is encoded in the device tree, then generic code should be able to hook them up; pulling additional data out of the device tree as needed to configure the coded.
g.