On Mon, Dec 27, 2010 at 10:17:03PM -0600, David Lambert wrote:
> At this time, the codec driver just registers the codec DAI.
If it's doing more than that it's going to be a separate driver anyway I
expect.
> +static struct snd_soc_dai_driver dmic_dai = {
> + .name = "dmic-hifi",
> + .capture = {
> + .stream_name = "Capture",
> + .channels_min = 1,
> + .channels_max = 8,
> + .rates = SNDRV_PCM_RATE_CONTINUOUS,
> + .formats = SNDRV_PCM_FMTBIT_S32_LE
> + | SNDRV_PCM_FMTBIT_S24_LE
> + | SNDRV_PCM_FMTBIT_S16_LE,
Hrm, so. DMIC signals are inherantly stereo, though obviously you can
bind multiple DMICs in parallel using the same clock line so from the
CPU side the channel limit makes sense. Similarly the format here
really makes very little odds on a PDM interface.
What we probably want here is wildcards for both channel and format
limits which we can use to say "this is meaningless, just match
anything" in case the other end needs it (like a CPU PDM interface does
to set up the DMA).
> +static struct platform_driver dmic_driver = {
> + .driver = {
> + .name = "dmic-codec",
Just -dmic.
> +MODULE_DESCRIPTION("Generic DMIC driver");
> +MODULE_AUTHOR("Liam Girdwood <lrg@xxxxxxxxxxxxxxx>");
> +MODULE_LICENSE("GPL");
MODULE_ALIAS().
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
