Paul Kavan wrote:
I just don't think it is a hardware problem. I a polling ssc driver that works very nicely for this codec. However, it is polling and I do not want to rely on it when I have more of a load on the processor.
I have the machine/codec code and at91-ssc.c configured so that the registers and gpio should be set up identical to what I had before and it is not generating a proper sync signal with arecord. When I do strace on arecord it hangs at this first line before finishing.
ioctl(4, 0x800c4151, 0xbed9cc34) = -1 EIO (Input/output error) write(2, "arecord", 7arecord) = 7 write(2, ": ", 2: ) = 2 write(2, "pcm_read", 8pcm_read) = 8 write(2, ":", 1:) = 1 write(2, "1346", 41346) = 4 write(2, ": ", 2: ) = 2 write(2, "read error: ", 12read error: ) = 12 write(2, "Input/output error", 18Input/output error) = 18 write(2, "\n", 1 ) = 1 exit(1) = ?
Does anyone know what this line is doing? I think it might give a clue. The sync line still ripples at about .3V peak to peak with f=256k (Bit Clock Rate).
Sorry, I have no idea what that line is doing.
Frank: I modified the machine code so that RF0 and RK0 are set in the gpio. The only differences are that the sync line no longer tri-states after going trying to record and instead of seeing the ripple around 3V it is now around 200 mV.
Now that I think about, if you are using RK0 as an input and driving it from TK0, then you should be initializing the RK0 GPIO. On our board, the RK2 GPIO pin is not used since RK2 is generated internally from the TK2 clock signal (AT91_SSC_CKS_CLOCK), so there was no need to initialize it.
Also, the RF2 GPIO is not used on our board, because there is a single sync signal sent to the codec, and this is supplied by TF2.
Perhaps it would be useful to see a diagram of the connections between the SSC and codec on your board, including directions.
../fam