lkml.org 
[lkml]   [2015]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectMcSPI hangs with cs_change after "Switch driver to use transfer_one" change
Date
Hi All,

I'm in a use case where I use cs_change on McSPI channel 3 on a single transfer Full-Duplex message, then I transfer a single full duplex message without cs_change on channel 1.

Here is a better representation :
-- 1 transfer message cs_change=1
cs3 : set_cs(0)
cs3 : full-duplex transfer
cs3 : transfer ok
-- 1 transfer message cs_change=1
cs3 : set_cs(0)
cs3 : full-duplex transfer
cs3 : transfer ok
...
-- 1 transfer message cs_change=1
cs3 : set_cs(0)
cs3 : full-duplex transfer
cs3 : transfer ok
-- 1 transfer message cs_change=1
cs1 : set_cs(0)
cs1 : full-duplex transfer
cs1 : RXS timed out
cs1 : set_cs(1)

Then "RXS timed out" on each non-cs3 transfers.

The previous behavior of cs_change was :
- between transfers, unassert CS and re-assert-it for the following transfer
- between messages, unassert CS

The new behaviour inherited from the SPI core spi_transfer_one_message function :
- between transfers, unassert CS and re-assert-it for the following transfer
- between messages, leave CS asserted

We tried disabling the DMA, and the FIFO, but the behavior was actually the same, only reverting back before the "Switch driver to use transfer_one" fixed the issue.

Then actually disabling the cs_change corrected the issue. It may be why the original driver ignored the "leave it on after last xfer" hint.

The problem is : how can we disable this hint since it is managed in SPI core spi_transfer_one_message ?

A solution will be to track down the current asserted CS and unassert it them when the active channel changes.

Neil


\
 
 \ /
  Last update: 2015-10-08 16:21    [W:1.793 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site