[PATCH v4 00/11] ASoC: fsl_ssi: Clean up - coding style level

[Caleb Crome]

On Wed, Dec 20, 2017 at 3:40 AM, Arnaud Mouiche <arnaud.mouiche at invoxia.com>
wrote:

>
>
> On 19/12/2017 01:25, Caleb Crome wrote:
>
>> On Mon, Dec 18, 2017 at 3:02 PM, Nicolin Chen <nicoleotsuka at gmail.com>
>> wrote:
>>
>>> On Mon, Dec 18, 2017 at 02:19:08PM -0800, Caleb Crome wrote:
>>>
>>> Acked-by: Timur Tabi <timur at tabi.org>
>>>>>
>>>> --- To Mark ---
>>>
>>> Mark, can you still take these changes first? Since this failed
>>> test that Caleb reported here is already existing on the top of
>>> the mainline tree, I would like to treat this mail as a separate
>>> bug report and fix it with a separate patch.
>>>
>>> Besides, this series of changes don't change any function flow.
>>>
>>> Thank you
>>>
>>> Sorry!  I should have created a separate thread for this subject.  My
>> comments have *nothing* to do with this patch set, except they are
>> about the same source files.
>>
>> --- To Caleb ---
>>>
>>> I'm re-setting up my loopback test to try to verify these most recent
>>>> changes.
>>>>
>>> I really appreciate your verification and help.
>>>
>> Of course!  I have this wandboard permanently set up for this
>> verification test, so that I can easily repeat whenever I touch our
>> kernel.
>>
>> It's a dead-simple hardware mod just to connect TX to RX.
>>
>> warn:   11a0 11a1 1160 11a3 11a4 11a5 11a6 11a7
>>>> warn: Valid frame after 1 invalid frames
>>>> warn:   11c0 11c1 11c2 11c3 11c4 11c5 11c6 11c7
>>>> warn: first invalid frame while expecting frame 0x00a0
>>>> warn:   13e7 1400 1401 1402 1403 1404 1405 1404
>>>> warn:   1407 1420 1421 1422 1423 1424 1425 1426
>>>> warn:   1427 1440 1441 1442 1443 1444 1445 1484
>>>> warn:   1447 1460 1461 1462 1463 1464 1465 1466
>>>>
>>>> Those last 4 lines are the channel slips -- the least significant
>>>> nibble should be the channel number:  i.e. should go 0, 1, 2, 3, 4, 5,
>>>> 6, 7.
>>>>
>>>> Ugh, so it's basically quite broken again -- before these patches.
>>>>
>>> I remember Arnaud reviewed one of my changes back to September.
>>> So I suppose the test should be fine at that time -- so a change
>>> being merged recently might have impacted the test result.
>>>
>>
>> It's certainly possible that I'm doing something wrong again -- it
>> wouldn't be the first time :-)
>>
>
> Hi All,
>
> Sorry but I will be busy until mid January, I could help testing and
> fixing broken multi channel after.
> Anyway, I don't see specific issues with Nicolin patches.
> We can take time to fix what was broken before this patch set... after.
>
> Arnaud
>
>
>
>> I guess I need to go backwards in time and see what rev re-broke it.
>>>> I don't really have time to dig too deep on this again.
>>>>
>>>> I'd be happy to provide the hardware to anybody that can diagnose and
>>>> debug this more quickly than I can.  I'm very inefficient at kernel
>>>> drivers I think.   My day job is acoustical and electrical
>>>> engineering.
>>>>
>>>> Here's what the hardware looks like for anybody that's interested.
>>>> Just a single wire loopback on the wandboard header.
>>>>
>>> I would definitely like to take the hardware to debug it as long
>>> as you are willing to provide me. Can you send me a private mail
>>> to discuss about it?
>>>
>> Absolutely.
>> -Caleb
>>
>>
>> Thanks
>>> Nicolin
>>>
>>
>
Okay, operator error on my part.  There was an old clock setting in my ssi3
dtsi file that (falsely) modified the ssi baud clock frequency.  Nicolin's
patch

    ASoC: fsl_ssi: Caculate bit clock rate using slot number and width

now properly computes the master clock, and the old dtsi settings that were
necessary to fake things into the right speed are now obsolete.

So... basically, everything is back to working properly.  it wasn't broken
at all -- just my oversight on a ssi clock setting in the dtb.

-Caleb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20171221/3f128432/attachment-0001.html>