Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMA problem
Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't fully checked what i am saying i am just supposing that it's what occured. Anyway the behaviour was different in DMA and polling mode. I didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) So is this a bug or a feature ? I don't have time right know to work on that problem but i can test solutions if anyone have. Regards. Pierre ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMA problem
Hi Pierre, On Tue, Nov 23, 2010 at 16:43:27, Pierre wrote: Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't Hmm, didn't really see this before. fully checked what i am saying i am just supposing that it's what occured. Anyway the behaviour was different in DMA and polling mode. I While working on the patches I noticed that DM355 has an errata regarding behavior of CSHOLD. In the patches, I take care of it by having DM355 define cshold_bug to true. Can you please make sure you have taken care of this as well while porting to 2.6.32? http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021045.html didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) How about with Brian's patch applied? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 00/49] spi: davinci: re-write existing driver, DM355 DMA problem
I took the tree version of the davinci_spi.c file after every patches have been applied ( the 49 spi patches ). I tested with the csbug on and off before and if i remember well, it was not working. I'll try again as soon as i have time. The weird thing is that the problem doesn't occur at each transfer. The details of what i noticed is: -Chipselect to the client is a GPIO, chip_sel array is a 1 byte array containing the gpio pin. -The DM355 application uses spidev char driver to read and write data to spidev0.0 -When dm355 was reading a 16 bytes buffer, the client sent the data correctly but afterwards it received a byte : the 15th byte of the sent buffer. -When I added to spidev_sync_read a tx zeroed buffer everything worked perfectly. (-The problem was there even if cshold_bug was true, but i'll check that again) -The spi was correctly working in polling mode. Pierre Le 11/23/2010 01:32 PM, Nori, Sekhar a écrit : Hi Pierre, On Tue, Nov 23, 2010 at 16:43:27, Pierre wrote: Hi, I have tested the new driver using DMA mode on our custom DM355 board. I replaced the linux 2.6.32 spi driver by this driver and it seemed to work except for on point. The dm355 spi polling mode was correctly working but the DMA mode was causing some communication problems. It appeared that when dm355 was reading on the spi, it was actually resending received data to our slave device on the spi bus, i didn't Hmm, didn't really see this before. fully checked what i am saying i am just supposing that it's what occured. Anyway the behaviour was different in DMA and polling mode. I While working on the patches I noticed that DM355 has an errata regarding behavior of CSHOLD. In the patches, I take care of it by having DM355 define cshold_bug to true. Can you please make sure you have taken care of this as well while porting to 2.6.32? http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-November/021045.html didn't dig deep into the driver i just solved the problem (quick and dirty) by setting tx buffer to zero in the spidev driver. The problem can be caused by using SPIDAT as dma buffer when the tx buffer is empty. (If it helps i have tested before the spi patch V5 from Brian Niebuhr and the problem was already there) How about with Brian's patch applied? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
