On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> Support for AC97 on Phytec pmc030 base board. A wm9712 AC97 codec is used.
>
> Signed-off-by: Jon Smirl <jonsmirl@xxxxxxxxx>
> ---
> 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@xxxxxxxxx>
> + *
> + * 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.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
