From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S933605AbbJHOrX (ORCPT <rfc822;w@1wt.eu>);
	Thu, 8 Oct 2015 10:47:23 -0400
Received: from mail-io0-f169.google.com ([209.85.223.169]:35786 "EHLO
	mail-io0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S933200AbbJHOrV (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 8 Oct 2015 10:47:21 -0400
Date: Thu, 8 Oct 2015 09:47:11 -0500
From: Michael Welling <mwelling@ieee.org>
To: Neil Armstrong <narmstrong@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>, linux-spi@vger.kernel.org,
        linux-kernel@vger.kernel.org, Fionn Cleary <clearyf@tcd.ie>,
        Wolfram Sang <wsa@the-dreams.de>,
        Jarkko Nikula <jarkko.nikula@linux.intel.com>,
        Sebastian Reichel <sre@kernel.org>
Subject: Re: McSPI hangs with cs_change after "Switch driver to use
 transfer_one" change
Message-ID: <20151008144711.GA8072@deathstar>
References: <561675AA.4010505@baylibre.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <561675AA.4010505@baylibre.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Oct 08, 2015 at 02:54:50PM +0100, Neil Armstrong wrote:
> 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)

Looks like bus contention here.

> 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 ?

It seems the core driver assumes that the driver is smart enough to deselect
the previous chip select instead of doing it explicitly.

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