diff options
| author | Jason Wang <[email protected]> | 2010-10-19 10:03:27 +0000 |
|---|---|---|
| committer | Grant Likely <[email protected]> | 2010-10-20 16:30:53 +0000 |
| commit | e1993ed6420afd4421336d75e73641f75da87a7f (patch) | |
| tree | c511d2aabbf7107620123954757df7bf7264c404 /tools/perf/util/scripting-engines/trace-event-perl.c | |
| parent | Merge branch 'for-spi' of git://git.kernel.org/pub/scm/linux/kernel/git/vapie... (diff) | |
| download | kernel-e1993ed6420afd4421336d75e73641f75da87a7f.tar.gz kernel-e1993ed6420afd4421336d75e73641f75da87a7f.zip | |
spi/omap2_mcspi: disable channel after TX_ONLY transfer in PIO mode
In the TX_ONLY transfer, the SPI controller also receives data
simultaneously and saves them in the rx register. After the TX_ONLY
transfer, the rx register will hold the random data received during
the last tx transaction.
If the direct following transfer is RX_ONLY, this random data has the
possibility to affect this transfer like this:
When the SPI controller is changed from TX_ONLY to RX_ONLY,
the random data makes the rx register full immediately and
triggers a dummy write automatically(in SPI RX_ONLY transfers,
we need a dummy write to trigger the first transaction).
So the first data received in the RX_ONLY transfer will be that
random data instead of something meaningful.
We can avoid this by inserting a Disable/Re-enable toggle of the
channel after the TX_ONLY transfer, since it purges the rx register.
Signed-off-by: Jason Wang <[email protected]>
Tested-by: Grazvydas Ignotas <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Grant Likely <[email protected]>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-perl.c')
0 files changed, 0 insertions, 0 deletions
