[alsa-devel] [PATCH 1/2 v2] mfd: wm5102: Update register patch
Update the register patch based on latest evaluation of the device.
Signed-off-by: Charles Keepax ckeepax@opensource.wolfsonmicro.com ---
Changed since v1: - Updated commit message on patch 2
Thanks, Charles
drivers/mfd/wm5102-tables.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/wm5102-tables.c b/drivers/mfd/wm5102-tables.c index 1e9a4b2..f9b1e96 100644 --- a/drivers/mfd/wm5102-tables.c +++ b/drivers/mfd/wm5102-tables.c @@ -73,6 +73,7 @@ static const struct reg_default wm5102_revb_patch[] = { { 0x171, 0x0000 }, { 0x35E, 0x000C }, { 0x2D4, 0x0000 }, + { 0x4DC, 0x0900 }, { 0x80, 0x0000 }, };
Evaluation of the device has given some settings to improve the ultrasonic frequency response. However, this may cause sub-optimal performance in system designs with high output gains on the headphone path (0dB or -2dB), and as the frequencies are inaudible anyway some users may not desire higher frequency response at those frequencies. So allow the user the option to select it if it is appopriate for their system design.
Signed-off-by: Charles Keepax ckeepax@opensource.wolfsonmicro.com --- include/linux/mfd/arizona/pdata.h | 3 +++ sound/soc/codecs/arizona.c | 15 +++++++++++++++ 2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/include/linux/mfd/arizona/pdata.h b/include/linux/mfd/arizona/pdata.h index 12a5c13..3df0ed5 100644 --- a/include/linux/mfd/arizona/pdata.h +++ b/include/linux/mfd/arizona/pdata.h @@ -177,6 +177,9 @@ struct arizona_pdata { /** Mode for outputs */ bool out_mono[ARIZONA_MAX_OUTPUT];
+ /** Provide improved ultrasonic frequency response */ + bool ultrasonic_response; + /** PDM speaker mute setting */ unsigned int spk_mute[ARIZONA_MAX_PDM_SPK];
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index e4295fe..f2e1ffe 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -1134,6 +1134,21 @@ static int arizona_hw_params_rate(struct snd_pcm_substream *substream, } sr_val = i;
+ switch (priv->arizona->type) { + case WM5102: + if (priv->arizona->pdata.ultrasonic_response) { + snd_soc_write(codec, 0x80, 0x3); + if (params_rate(params) >= 176400) + snd_soc_write(codec, 0x4dd, 0x1); + else + snd_soc_write(codec, 0x4dd, 0x0); + snd_soc_write(codec, 0x80, 0x0); + } + break; + default: + break; + } + switch (dai_priv->clk) { case ARIZONA_CLK_SYSCLK: snd_soc_update_bits(codec, ARIZONA_SAMPLE_RATE_1,
On Fri, Jan 31, 2014 at 04:16:18PM +0000, Charles Keepax wrote:
Evaluation of the device has given some settings to improve the ultrasonic frequency response. However, this may cause sub-optimal performance in system designs with high output gains on the headphone path (0dB or -2dB), and as the frequencies are inaudible anyway some users may not desire higher frequency response at those frequencies. So allow the user the option to select it if it is appopriate for their system design.
Reading what you're saying here I can't help but think that this sounds like it may be use case dependent as well and therefore something that ought to be runtime controllable depending on if ultrasonics and/or line level outputs are in use (0dB isn't high gain, it's no gain!) for example.
On Tue, Feb 04, 2014 at 12:17:27AM +0000, Mark Brown wrote:
On Fri, Jan 31, 2014 at 04:16:18PM +0000, Charles Keepax wrote:
Evaluation of the device has given some settings to improve the ultrasonic frequency response. However, this may cause sub-optimal performance in system designs with high output gains on the headphone path (0dB or -2dB), and as the frequencies are inaudible anyway some users may not desire higher frequency response at those frequencies. So allow the user the option to select it if it is appopriate for their system design.
Reading what you're saying here I can't help but think that this sounds like it may be use case dependent as well and therefore something that ought to be runtime controllable depending on if ultrasonics and/or line level outputs are in use (0dB isn't high gain, it's no gain!) for example.
I think in practice it will likely be set once for a given system. Although that said there is nothing that would prevent this being switchable at runtime, I will look into respinning it with runtime control.
Thanks, Charles
On Fri, 31 Jan 2014, Charles Keepax wrote:
Update the register patch based on latest evaluation of the device.
Signed-off-by: Charles Keepax ckeepax@opensource.wolfsonmicro.com
drivers/mfd/wm5102-tables.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
Applied, thanks.
participants (3)
-
Charles Keepax -
Lee Jones -
Mark Brown