Hi,
I am having a problem with the linux mcspi driver for the AM335X product using the PSP_04.06.00.02 branch off of Arago.
Basically, it looks like the spi_write_then_read() calls don't work correctly. We are able to see (using a scope) proper "read" requests to an AM335X connected to a TLV320AIC26, but the results from the MCSPI driver are not matching the scope.
The code in question is in the aic26_reg_read() method of sound/soc/codecs/tlv320aic26.c, the call
rc = spi_write_then_read(aic26->spi, buffer, 2, buffer, 2);
is failling. This call, when you walk down into the mcspi driver is running a polled TXONLY transfer of 2 bytes followed by a polled RXONLY transfer of 2 bytes. We are using the same codec code on other platforms without any issue, so I don't think there is a bug in the codec software. Observing the SPI data lines, clock, and chip select lines with a scope it appears that the transmit portion is working fine, but the receive portion is not getting the received bytes (which are posted on the MISO data line) correctly.
If I use a "standard" 4 byte transfer (which uses a polled by-directional transfer in the driver) with something like snippet below, the SPI interface works (and our codec interface works), which implies the hardware and the SPI interface setup is OK.
{
u8 buffer[4];
struct spi_message message;
struct spi_transfer x;
spi_message_init(&message);
memset(buffer, 0, 4); x.len = 4; x.tx_buf = buffer; x.rx_buf = buffer; spi_message_add_tail(&x, &message); cmd = AIC26_READ_COMMAND_WORD(reg); buffer[0] = (cmd >> 8) & 0xff; buffer[1] = cmd & 0xff; rc = spi_sync(aic26->spi, &message); value = (buffer[2] << 8) | buffer[3];
}
I suspect that the receive buffer on the MCSPI port is not getting drained / reset properly on TX_ONLY or RX_ONLY transfers, but haven't gotten to the bottom of it...
Anyone seen this before?
-Mike
