You are correctly understanding my problem.
Ok, So spidev should specify the out buffer in case of a read or the
application should specify the out buffer.
By the way, thanks for this new driver that is fully satisfying.
Regards
Le 11/23/2010 03:47 PM, Brian Niebuhr a écrit :
-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
