Re: [PATCH v9 01/14] ASoC: sun4i-i2s: Change set_chan_cfg() params
From: Clément Péron <hidden>
Date: 2020-10-30 12:58:23
Also in:
alsa-devel, linux-devicetree, lkml
Hi Samuel On Fri, 30 Oct 2020 at 02:20, Samuel Holland [off-list ref] wrote:
On 10/27/20 4:43 PM, Clément Péron wrote:quoted
Hi Pierre-Louis, On Tue, 27 Oct 2020 at 19:59, Pierre-Louis Bossart [off-list ref] wrote:quoted
quoted
@@ -452,11 +454,11 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s, case SND_SOC_DAIFMT_DSP_B: case SND_SOC_DAIFMT_LEFT_J: case SND_SOC_DAIFMT_RIGHT_J: - lrck_period = params_physical_width(params) * slots; + lrck_period = slot_width * slots; break; case SND_SOC_DAIFMT_I2S: - lrck_period = params_physical_width(params); + lrck_period = slot_width; break;Aren't I2S, LEFT_J and RIGHT_J pretty much the same in terms of lrclk rate/period? the only thing that can change is the polarity, no? Not sure why it's handled differently here?I just had a look at the User Manual for H3 and H6 and I didn't find any reason why LEFT_J and RIGHT_J should be computed in a different way as I2S.Yes, and the manual explicitly groups LEFT_J and RIGHT_J with I2S when describing this field: PCM Mode: Number of BCLKs within (Left + Right) channel width. I2S/Left-Justified/Right-Justified Mode: Number of BCLKs within each individual channel width(Left or Right) So I agree that the code is wrong here.
Thanks, I will send a fix in the v10. Regards, Clement
Regards, Samuelquoted
Also the commit introducing this doesn't mention it. 7ae7834ec446 ("ASoC: sun4i-i2s: Add support for DSP formats") I can't test it with my board but if nobody complains about it, I will introduce a fix for this in the next version and change this also for H6. Thanks for your review, Clement
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel