| Message ID | 20190319033756.20616-13-nh6z@nh6z.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ASoC: tlv320aic32x4: Rework Clock Setting | expand |
On Mon, Mar 18, 2019 at 08:37:55PM -0700, Annaliese McDermond wrote: > Different processing blocks are required for different sampling > rates and power parameters. Set the processing blocks based > on this information. Is this another bug fix or does it depend on the rest of the series somehow?
> On Mar 19, 2019, at 8:37 AM, Mark Brown <broonie@kernel.org> wrote: > > On Mon, Mar 18, 2019 at 08:37:55PM -0700, Annaliese McDermond wrote: >> Different processing blocks are required for different sampling >> rates and power parameters. Set the processing blocks based >> on this information. > > Is this another bug fix or does it depend on the rest of the series > somehow? It’s not really a bug fix. The codec has a variety of “processing blocks” that enable different filters (there’s an onboard FIR, Biquad, etc.) and such. The big thing they change with regard to how the driver is written now is that they change the decimation filter used. The documentation specifies to use certain filters for certain sample rates. This hasn’t mattered very much in the past because the default filters (P1 and R1) are the ones recommended for 48kHz and below. This is particularly important for 192kHz operation because it won’t work with P1 and R1. So, it’s not really a bug fix. It’s part of the road to enabling 192kHz operation. -- Annaliese McDermond nh6z@nh6z.net
On Tue, Mar 19, 2019 at 09:24:00AM -0700, Annaliese McDermond wrote: > It’s not really a bug fix. The codec has a variety of “processing blocks” > that enable different filters (there’s an onboard FIR, Biquad, etc.) and > such. The big thing they change with regard to how the driver is written > now is that they change the decimation filter used. The documentation > specifies to use certain filters for certain sample rates. This > hasn’t mattered very much in the past because the default filters > (P1 and R1) are the ones recommended for 48kHz and below. This is > particularly important for 192kHz operation because it won’t > work with P1 and R1. So, it’s not really a bug fix. It’s part > of the road to enabling 192kHz operation. It does sound like a bug fix for higher sample rates (96kHz is supported?) even if it's a fairly niche case.
diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index 2940cb2e5a4a..3a42a08d2a7a 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -632,6 +632,18 @@ static int aic32x4_set_dosr(struct snd_soc_component *component, u16 dosr) return 0; } +static int aic32x4_set_processing_blocks(struct snd_soc_component *component, + u8 r_block, u8 p_block) +{ + if (r_block > 18 || p_block > 25) + return -EINVAL; + + snd_soc_component_write(component, AIC32X4_ADCSPB, r_block); + snd_soc_component_write(component, AIC32X4_DACSPB, p_block); + + return 0; +} + static int aic32x4_setup_clocks(struct snd_soc_component *component, unsigned int sample_rate) { @@ -665,16 +677,19 @@ static int aic32x4_setup_clocks(struct snd_soc_component *component, adc_resource_class = 6; dac_resource_class = 8; dosr_increment = 8; + aic32x4_set_processing_blocks(component, 1, 1); } else if (sample_rate <= 96000) { aosr = 64; adc_resource_class = 6; dac_resource_class = 8; dosr_increment = 4; + aic32x4_set_processing_blocks(component, 1, 9); } else if (sample_rate == 192000) { aosr = 32; adc_resource_class = 3; dac_resource_class = 4; dosr_increment = 2; + aic32x4_set_processing_blocks(component, 13, 19); } else { dev_err(component->dev, "Sampling rate not supported\n"); return -EINVAL;
Different processing blocks are required for different sampling rates and power parameters. Set the processing blocks based on this information. Signed-off-by: Annaliese McDermond <nh6z@nh6z.net> --- sound/soc/codecs/tlv320aic32x4.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)