lkml.org 
[lkml]   [2020]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v9 01/14] ASoC: sun4i-i2s: Change set_chan_cfg() params
From
Date
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
> <pierre-louis.bossart@linux.intel.com> wrote:
>>
>>
>>> @@ -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
>

\
 
 \ /
  Last update: 2020-10-30 02:31    [W:0.084 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site