On 10/27/20 4:43 PM, Clément Péron wrote:

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.

Regards,
Samuel

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