On Thu, Dec 21, 2017 at 8:08 AM, Caleb Crome caleb@crome.org wrote:
On Wed, Dec 20, 2017 at 3:40 AM, Arnaud Mouiche arnaud.mouiche@invoxia.com wrote:
On 19/12/2017 01:25, Caleb Crome wrote:
On Mon, Dec 18, 2017 at 3:02 PM, Nicolin Chen nicoleotsuka@gmail.com wrote:
On Mon, Dec 18, 2017 at 02:19:08PM -0800, Caleb Crome wrote:
Acked-by: Timur Tabi timur@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 :-)
[resend -- previous wasn't in plain text mode]
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