When we try to read some register using SPI, port 1 in version 2.6, the read process isn’t executed. In other words, kernel is not generating the clock pulses after the write step.
We test our program in version 2.4 and it is working well for SPI port 1, chip select 0.
Bellow the part of the program we run to read the register.
char bufOut[WRITE_SIZE];
uint32_t tamBufOut;
struct spi_ioc_transfer xfer[2];
uint8_t buf[32];
memset(xfer, 0, sizeof xfer);
//memset(in, 0, sizeof buf);
// inicia contador do tamanho do buffer de envio
tamBufOut = 0;
//monta mensagem
bufOut[tamBufOut++] = chip_address | READ_MASK; //endereço do chip + bit de write
bufOut[tamBufOut++] = reg_id; //registro a ser lido
xfer[0].tx_buf = (unsigned long)bufOut;
xfer[0].rx_buf = NULL;
xfer[0].len = tamBufOut;
//xfer[0].cs_change = true;
xfer[1].tx_buf = NULL;
xfer[1].rx_buf = (unsigned long)buf;
xfer[1].len = 1;
if (ioctl(fd, SPI_IOC_MESSAGE(2), xfer) < 0)
{
cout << "falha na leitura do registro" << endl;
return ERRO_MCP23S17_READ_REGISTER;
}
else
{
cout << "Valor Reg = " << hex << buf[0] << endl;
}
return OK;
And these are the settings in the Device Tree:
&dspi1 {
bus-num = <1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dspi1>;
status = "okay";
spidev0: spidev@0 {
compatible = "toradex,evalspi";
reg = <0>;
spi-max-frequency = <1000000>;
};
spidev1: spidev@2 {
compatible = "toradex,evalspi";
reg = <2>;
spi-max-frequency = <1000000>;
};
};
As noted in the related thread, v2.4b1 is really a somewhat old release with the Linux 4.0 Kernel which is not a LTS version. I strongly suggest to move to v2.5b3 (release) which comes with Linux 4.1 or the latest Beta release (which uses Linux 4.4)… We are currently working on SPI DMA support for the Linux 4.4 and later.
Hello Stefan,
In this case, we are using 4.4.21 kernel version.
Oh I see, I am sorry!
I guess this could be related to our latest DMA changes. Can you try with a kernel which has the following patch reverted?
http://git.toradex.com/cgit/linux-toradex.git/commit/?h=toradex_vf_4.4-next&id=45de59e3f1511606433c294e9ec85c5b9d4f637f
@gafernandes You can try by disabling dma and use EOQ mode, using the following in dspi node in device tree
dma-names = " ", " ";
instead of reverting the patch. I was able to reproduce the issue here. We will look into it.
Hello,
I tried both options, and still have problems to read from SPI when use more the one struct in the SPI_IO_MESSAGE, or when I use the device driver (“microchip,mcp23s17”).
I was able to read using one struct passed to SPI_IO_MESSAGE. To evaluate our system, I will use this option.
I would expect having
dma-names = " ", " ";
to work in your case since it would then disable DMA and use EOQ mode as in the older kernel/image version. I have raised a ticket internally and we have started looking into the issue.
We could reproduce the issue and working on a fix. You can expect a patch soon.
@gafernandes Fixes for SPI DMA are now available in the latest 4.4-next branch with the latest 7 commits. The issue reported by you is specifically fixed by this commit. However we also noticed some additional issues as reported here and they have been fixed as well.