On Mon, Apr 03, 2017 at 05:39:22PM -0700, Caleb Crome wrote:
If possible, could you try to confirm what's the diff between the two SCR values of before-regmap and after-regmap in your case?
With this patch (broken audio, includes tx and rx, so 2 updates. Running atest software)
Apr 4 00:35:03 arm kernel: [ 33.678451] Before update: 0x00001098 Apr 4 00:35:03 arm kernel: [ 33.682339] After update: 0x0000109f Apr 4 00:35:04 arm kernel: [ 33.687196] Before update: 0x0000109f Apr 4 00:35:04 arm kernel: [ 33.690916] After update: 0x0000109f
Before this patch (working audio, running atest software)
Apr 4 00:38:24 arm kernel: [ 68.261765] Before update: 0x00001098 Apr 4 00:38:24 arm kernel: [ 68.265653] After update: 0x0000109d Apr 4 00:38:24 arm kernel: [ 68.270865] Before update: 0x0000109d Apr 4 00:38:24 arm kernel: [ 68.274560] After update: 0x0000109f
So my understanding is correct. For 2-channel use cases, this change probably wouldn't matter because the data is correctly aligned -- there'd be only some zero data in the beginning. But it is hard to tell for multi-channels.
SSI FIFO depth is 15 -- for dual-fifo settings, data wouldd be only aligned if the channel number is 2, 6, 10. If you are able to test 6 or 10 channels, I would like to see the result.
Overall, we probably need some support from i.MX hardware team. Instead of setting three bits together, we need an alternative solution which would create some flexibility for multi channel cases. Otherwise, we may try to get rid of the NETWORK mode, and the TE/RE-together-set accordingly.