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@xxxxxxxxxxx> > + * Co-author: John Hsu <kchsu0@xxxxxxxxxxx> > + * Co-author: Seven Li <wtli@xxxxxxxxxxx> > + * > + * 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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel