linux-kernel - Re: [PATCH v6] sound/soc/codecs: add LAPIS Semiconductor ML26124

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANKRQngoDf_U8U7txG0AT1TKmSeq2FfqwjWD7EEiLROWzn+f5Q@mail.gmail.com>
Date:	Tue, 6 Mar 2012 12:03:20 +0900
From:	Tomoya MORINAGA <tomoya.rohm@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Liam Girdwood <lrg@...com>, Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.de>, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org, qi.wang@...el.com,
	yong.y.wang@...el.com, joel.clark@...el.com, kok.howg.ewe@...el.com
Subject: Re: [PATCH v6] sound/soc/codecs: add LAPIS Semiconductor ML26124

2012年3月2日21:58 Mark Brown <broonie@...nsource.wolfsonmicro.com>:
>> >> +static int ml26124_set_dai_clkdiv(struct snd_soc_dai *codec_dai,
>> >> +                               int div_id, int div)
>> >> +{
>> >> +     struct snd_soc_codec *codec = codec_dai->codec;
>
>> >> +     switch (div_id) {
>> >> +     case ML26124_MCLK:
>> >> +             ml26124_update_bits(codec, ML26124_CLK_CTL,
>> >> +                                   BIT(0) | BIT(1), div);
>> >> +             break;
>
>> > Why can't the driver calculate this automatically given the MCLK?
>
>> Sorry, I can't understand your saying.
>> Why does this driver need to calculate ?
>> I think this driver can use "div" value directly.
>
> Why does the user have to set this divider by hand at all?  There's
> already a set_sysclk() function, just have the user specify the clock
> they're providing.
I see.
This processing will move to set_sysclk()

>> >> +     ret = snd_soc_codec_set_cache_io(codec, 8, 8, SND_SOC_I2C);
>> > You're mixing regmap API usage and ASoC level I2C, this should be
>> > _REGMAP.
>> Currently, it seems codec control via i2c works well.
>> Let me know why I should  use SND_SOC_REGMAP not _I2C.
> Have you checked what _I2C and _REGMAP do?
I've just checked it.
If SND_SOC_REGMAP is used, it seems there is no processing in it.
So, can I delete snd_soc_codec_set_cache_io ?

>
>> >> +static int __init ml26124_modinit(void)
>> >> +{
>> >> +     int ret;
>> >> +
>> >> +     ret = i2c_add_driver(&ml26124_i2c_driver);
>> >> +     if (ret != 0)
>
>> > module_i2c_driver().
>
>> Sorry, I can't understand your saying.
>
> Use module_i2c_driver().
I understand.
As a matter of interest, why can I use module_i2c_driver ?
There is no ASoC driver uses module_i2c_driver.

>> +static int ml26124_update_bits(struct snd_soc_codec *codec, unsigned short reg,
>> +                             unsigned int mask, unsigned int value)
>
> Why are you open coding this in your driver?  There is no point in
> replicating subsystem functionality.
For ML26124 spec, it's necessary.
Because the codec's register read-address and write-address is not the same.
E.G.
Sampling Rate Register
R: offset=0
W: offset=1

thanks,
-- 
ROHM Co., Ltd.
tomoya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/