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

From: Caleb Crome
Date: Mon Dec 18 2017 - 17:19:35 EST

On Sun, Dec 17, 2017 at 7:13 PM, Timur Tabi <timur@xxxxxxxx> wrote:
> On 12/17/17 8:51 PM, Nicolin Chen wrote:
>> Nicolin Chen (11):
>> ASoC: fsl_ssi: Rename fsl_ssi_private to fsl_ssi
>> ASoC: fsl_ssi: Cache pdev->dev pointer
>> ASoC: fsl_ssi: Refine all comments
>> ASoC: fsl_ssi: Rename registers and fields macros
>> ASoC: fsl_ssi: Refine indentations and wrappings
>> ASoC: fsl_ssi: Refine printk outputs
>> ASoC: fsl_ssi: Rename cpu_dai parameter to dai
>> ASoC: fsl_ssi: Rename scr_val to scr
>> ASoC: fsl_ssi: Replace fsl_ssi_rxtx_reg_val with fsl_ssi_regvals
>> ASoC: fsl_ssi: Rename i2smode to i2s_net
>> ASoC: fsl_ssi: Define ternary macros to simplify code
> Acked-by: Timur Tabi <timur@xxxxxxxx>

I'm re-setting up my loopback test to try to verify these most recent changes.

I'm starting with the for-next branch at
git:// (which
is a 4.15 numbered kernel).

The basic setup is using a wandboard with a TX pin tied directly to an
RX pin do test if what is sent is what is received, using Arnaud's
tester here:

Unfortunately, it doesn't pass the loopback test, even before these
patches. I'm not actively developing on this platform at the moment,
and my brain has been out of kernel development for quite a while.

I'm getting channel slips again.

output from atest:

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 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

Here's what the hardware looks like for anybody that's interested.
Just a single wire loopback on the wandboard header.