[V3,3/4] Support for AC97 on Phytec pmc030 base board.

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

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.

On Mon, May 25, 2009 at 12:34:57AM -0600, Grant Likely wrote:

> 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.

It's ugly but it's idiomatic for ASoC until someone has time to
implement multiple card support.

> 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

It's adequate for the cases it tries to cover, it just needs to be
merged into the core.  The problem here is AC97 since it can't be probed
until the platform comes up.

> 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.

As I explained in response to Jon's original posting AC97 is a
particular problem here since it can only be probed using the CPU DAI
and may require machine-specific work to set it up prior to use.
There's problems fixing this due to AC97 not having fully developed bus
infrastructure in the kernel at the minute.

On Sun, May 24, 2009 at 09:38:51PM -0400, Jon Smirl wrote:

> +static __exit void pcm030_fabric_exit(void)
> +{
> +}

Remove or implement, please.

On Mon, May 25, 2009 at 2:34 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On Sun, May 24, 2009 at 7:38 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> 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'm all for deleting it as soon as AC97 is capable of auto-loading.  I
thought it was better to leave it in the sound directories to keep it
isolated since the intention is to remove it when possible.

BTW, my binding files are quite simple compared to mpc8610_hpcd.c.


>
> 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.
>