Setting some clocks back to DUMMY fixes spdif output on imx6q wandboard rev B1
Xavi Drudis Ferran
xdrudis at tinet.cat
Wed Aug 31 19:10:13 AEST 2016
El Tue, Aug 30, 2016 at 09:21:01PM -0700, Nicolin Chen deia:
> No, the problem is not at the rate but the source -- Although the
> MLB clock exists in the clock tree as a better rate provider, it
> might not be correctly enabled or running at the rate it claims.
> There are five MLB clocks sharing the same clock gate according
> to CCM chapter in the Reference Manual of imx6q. But five clocks
> come from three different parent clocks, and I am wondering if
> the MLB clock that's connected to the S/PDIF module is really
> derived from this AXI.
> Hope Fabio might be able to help on the clock tree issue here:)
I hope too, it's a little over my head, to be euphemistic.
> Another solution for you could be to change the rates of two of
> those existing clocks to the perfect rates for 44.1KHz and 48KHz
> respectively, 22579200Hz and 24576000Hz for example. (If you
> only need one sample rate support, changing rxtx1 SPDIF clock
> only then.)
Thank you very much. I'm not sure what practical problem that would
solve for me, audio sounds quite right to my ears with the workaround
(disabling MLB). I've looked page 121 of
And it seems like the the margin for the SPDIF clock would be 16 ns
and I'm like 10 times out of spec. But I can't hear the problem. I
may try it one day to hear how it sounds.
I'll try to remember it if I ever come across some problem with my audio.
For now what I'd like is to stay as close to linux-libre mainline
as possible, so the quick workaround is enough for me.
Now for the general case, I'm not sure what the solution should be.
Page 4 of the pdf above says MLB is not present in industrial "parts",
only automotive, or consumer "parts". There are several versions of
IMX6Q in the market. What version must I have ? I guess consumer
(with MLB) but I'm not sure... According to the wandboard-quad-rev-b1
manual its consumer, MCIMX6Q5EYM10AC, so I should have MLB, I guess.
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 10 (v7l)
BogoMIPS : 7.54
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 10
I can't tell what CPU part : 0xc09 means.
In the reference manual pg 796 I see the same gate seems to affect Media
Local Bus (MLB) clock and Digital Transmission Content Protection
(DTCP). I don't use DTCP but I haven't done anything to disable it.
Thanks again, you've been very helpful.
More information about the Linuxppc-dev