> -----Original Message----- > From: davinci-linux-open-source-boun...@linux.davincidsp.com > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On > Behalf Of Pierre > Sent: Tuesday, November 23, 2010 5:13 AM > To: davinci-linux-open-source@linux.davincidsp.com > Subject: Re: [PATCH 00/49] spi: davinci: re-write existing driver, > DM355 DMAproblem > > 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.
If I understand you correctly, what you are saying is that when you are trying to read data from your SPI device, the data on the DM355 output signal (MOSI) is not what you expected, and is causing issues. If that is the case, I can say that I made no effort to make sure that the inactive portion of a half-duplex SPI transfer had any particular data pattern. In other words, if you have been getting a certain pattern of outbound data it is purely coincidence, and the different implementations of polled and DMA mode expose the fact that you had been getting lucky. I am not a SPI expert by any means, but it has been my approach that SPI is a full-duplex protocol and you need to specify outbound data if you want certain outbound data sent. As it turns out, most SPI devices have a protocol for determining when they are supposed to be sending or receiving, and if the device is sending it usually ignores whatever it is receiving. You mention in your later email that using a zeroed Tx buffer makes everything work OK. I think that's actually the most correct solution. The driver could be modified to ensure that it transmits zeros on a half-duplex read, and maybe it should, but I think the best solution is for the application to specify what it wants to be sent and not rely on non-portable behavior from a driver. If I'm misunderstanding the problem, then just ignore all of the above :-) > 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 _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source