[alsa-devel] [PATCH] ASoC: nau8822: new codec driver

Mark Brown broonie at kernel.org
Wed Oct 17 20:54:23 CEST 2018


On Fri, Sep 28, 2018 at 11:10:04AM +0800, David Lin wrote:

This looks mostly good so I'm going to apply it, I do have a couple of
comments below but they are quite small and I think they can be
addressed with followup patches.

> +++ b/sound/soc/codecs/nau8822.c
> @@ -0,0 +1,1136 @@
> +/*
> + * nau8822.c  --  NAU8822 ALSA Soc Audio Codec driver
> + *
> + * Copyright 2017 Nuvoton Technology Corp.
> + *
> + * Author: David Lin <ctlin0 at nuvoton.com>
> + * Co-author: John Hsu <kchsu0 at nuvoton.com>
> + * Co-author: Seven Li <wtli at nuvoton.com>
> + *
> + * Based on WM8974.c
> + *
> + * 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.
> + */

This should be converted to use a SPDX license header

	// SPDX-License-Identifier: GPL-2.0.

> +static int nau8822_config_clkdiv(struct snd_soc_dai *dai, int div, int rate)
> +{
> +	struct snd_soc_component *component = dai->component;
> +	struct nau8822 *nau8822 = snd_soc_component_get_drvdata(component);
> +	struct nau8822_pll *pll = &nau8822->pll;
> +	int i, sclk, imclk;

We're trying to get away from using set_clkdiv() as it makes it much
harder to use generic card drivers without specific knowledge of the 
card.  However in this case it seems like it's mainly choosing if we
should use the MCLK directly or the PLL and you should be able to do
everything in the set_sysclk() operation - is there a reason not to do
that?  If not then moving to set_sysclk() would avoid problems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20181017/b31ff14c/attachment-0001.sig>


More information about the Alsa-devel mailing list