From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933051AbbJHNy4 (ORCPT ); Thu, 8 Oct 2015 09:54:56 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:32886 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932876AbbJHNyx (ORCPT ); Thu, 8 Oct 2015 09:54:53 -0400 To: Mark Brown , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, Michael Welling , Fionn Cleary , Wolfram Sang , Jarkko Nikula , Sebastian Reichel From: Neil Armstrong Subject: McSPI hangs with cs_change after "Switch driver to use transfer_one" change X-Enigmail-Draft-Status: N1110 Organization: Baylibre Message-ID: <561675AA.4010505@baylibre.com> Date: Thu, 8 Oct 2015 14:54:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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