From patchwork Thu Feb 4 12:16:24 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 8220461 Return-Path: X-Original-To: patchwork-linux-spi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E6A0D9F3CD for ; Thu, 4 Feb 2016 12:16:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F302C2034C for ; Thu, 4 Feb 2016 12:16:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 02CF920384 for ; Thu, 4 Feb 2016 12:16:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965237AbcBDMQd (ORCPT ); Thu, 4 Feb 2016 07:16:33 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:34965 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965233AbcBDMQb (ORCPT ); Thu, 4 Feb 2016 07:16:31 -0500 Received: from debutante.sirena.org.uk ([2a01:348:6:8808:fab::3] helo=debutante) by mezzanine.sirena.org.uk with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1aRIpn-0000nG-OD; Thu, 04 Feb 2016 12:16:28 +0000 Received: from broonie by debutante with local (Exim 4.86) (envelope-from ) id 1aRIpk-0001R1-U8; Thu, 04 Feb 2016 12:16:24 +0000 From: Mark Brown To: Weifeng Voon , Jarkko Nikula , Mark Brown Cc: linux-spi@vger.kernel.org In-Reply-To: <1454581857-12921-2-git-send-email-jarkko.nikula@linux.intel.com> Message-Id: Date: Thu, 04 Feb 2016 12:16:24 +0000 X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Subject: Applied "spi: pxa2xx: Fix too early chipselect deassert" to the spi tree X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The patch spi: pxa2xx: Fix too early chipselect deassert has been applied to the spi tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From 7a8d44bc89e5cddcd5c0704a11a90484d36ba6ba Mon Sep 17 00:00:00 2001 From: Jarkko Nikula Date: Thu, 4 Feb 2016 12:30:57 +0200 Subject: [PATCH] spi: pxa2xx: Fix too early chipselect deassert There is a chance that chipselect is deasserted too early while the last clock cycle is still running. Protocol analyzers will see this as a failed last byte. This is more likely to occur with slow bitrates, for instance at 25 kbps. Reason for this is when using SPI mode 0 that both SPI host controller and SPI slave will drive the data lines at the falling edge of clock signal and sample at the rising edge. Receive FIFO gets the last bit now at the rising edge and code sees transfer to be finished either by the interrupt in PIO mode or by the DMA completion in DMA mode. The SSP Time Out register SSTO should take care of delaying the completion but it does not seems to have effect at least on Intel Skylake and Broxton even when using long enough values. Depending on timing code may get into point where chipselect is deasserted while the last clock cycle is still running at its second half cycle. Fix this by adding a wait loop in giveback() that waits until SSP becomes idle before deasserting the chipselect. Reported-by: Weifeng Voon Signed-off-by: Jarkko Nikula Signed-off-by: Mark Brown --- drivers/spi/spi-pxa2xx.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index 9b9a528a9fbd..ce66cf44bba5 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -496,6 +496,7 @@ static void giveback(struct driver_data *drv_data) { struct spi_transfer* last_transfer; struct spi_message *msg; + unsigned long timeout; msg = drv_data->cur_msg; drv_data->cur_msg = NULL; @@ -508,6 +509,12 @@ static void giveback(struct driver_data *drv_data) if (last_transfer->delay_usecs) udelay(last_transfer->delay_usecs); + /* Wait until SSP becomes idle before deasserting the CS */ + timeout = jiffies + msecs_to_jiffies(10); + while (pxa2xx_spi_read(drv_data, SSSR) & SSSR_BSY && + !time_after(jiffies, timeout)) + cpu_relax(); + /* Drop chip select UNLESS cs_change is true or we are returning * a message with an error, or next message is for another chip */