From patchwork Tue Nov 13 18:34:52 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mark Brown X-Patchwork-Id: 10681261 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 741CB13B5 for ; Tue, 13 Nov 2018 18:35:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 691E72AC3D for ; Tue, 13 Nov 2018 18:35:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 598692AEB7; Tue, 13 Nov 2018 18:35:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=2.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8790A2AC3D for ; Tue, 13 Nov 2018 18:35:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726659AbeKNEeV (ORCPT ); Tue, 13 Nov 2018 23:34:21 -0500 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:44704 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730829AbeKNEeV (ORCPT ); Tue, 13 Nov 2018 23:34:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=m77LmLUWkWz3ZJ3jphfptUm8q3R1XyuVZHhLOpFXyB4=; b=paFbnRsYyd2z NeuRG/wMzq3KwkOGvu/rgFlHd0OUmAfU5sGMrxWKmLIIBEQTo8Y6XjUMfb0Z8kneI+n4ixTrp0x4Z 1B+Vrak4IScVRlqyqphDljdmHVBqFxnliQoxekBQUMifPALvXIFRMqVqUQvk2Ds/k7qlCOrINt5ey uOTCQ=; Received: from [64.114.255.97] (helo=finisterre.ee.mobilebroadband) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gMdWc-0002Pf-3c; Tue, 13 Nov 2018 18:34:58 +0000 Received: by finisterre.ee.mobilebroadband (Postfix, from userid 1000) id 50755440078; Tue, 13 Nov 2018 18:34:52 +0000 (GMT) From: Mark Brown To: Lubomir Rintel Cc: Pavel Machek , Mark Brown , linux-spi@vger.kernel.org Subject: Applied "spi: pxa2xx: Deal with the leftover garbage in TXFIFO" to the spi tree In-Reply-To: Message-Id: <20181113183452.50755440078@finisterre.ee.mobilebroadband> Date: Tue, 13 Nov 2018 18:34:52 +0000 (GMT) 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: Deal with the leftover garbage in TXFIFO has been applied to the spi tree at https://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 82391856191878bb0047259817ab32f88438aa33 Mon Sep 17 00:00:00 2001 From: Lubomir Rintel Date: Tue, 13 Nov 2018 11:22:28 +0100 Subject: [PATCH] spi: pxa2xx: Deal with the leftover garbage in TXFIFO There doesn't seem to be a way to empty TXFIFO on MMP2. The datasheet is super-secret and the method described in Armada 16x manual won't work: "The TXFIFO and RXFIFO are cleared to 0b0 when the SSPx port is reset or disabled (by writing a 0b0 to the field in the SSP Control Register 0)." # devmem 0xd4037008 # read SSSR 0x0000F204 # devmem 0xd4037000 32 0x07 # SSE off in SSCR0 # devmem 0xd4037000 32 0x87 # SSE on # devmem 0xd4037008 0x0000F204 ^ TXFIFO level is still 2. Sigh. The OLPC 1.75 boot firmware leaves two bytes in the TXFIFO. Those are basically throwaway bytes used in response to the messages from the EC. The OLPC kernel copes with this by power-cycling the hardware. Perhaps the firmware should do this instead. Other than that, there's not much we can do other than complain loudly until the garbage gets drained and discard the actual data... For the OLPC EC this will work just fine and pushing more data to TXFIFO would break further transactions. Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek Signed-off-by: Mark Brown --- drivers/spi/spi-pxa2xx.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index 69b221e34b2d..e6a606354f62 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -1078,6 +1078,20 @@ static int pxa2xx_spi_transfer_one(struct spi_controller *master, pxa2xx_spi_write(drv_data, SSTO, chip->timeout); } + if (drv_data->ssp_type == MMP2_SSP) { + u8 tx_level = (pxa2xx_spi_read(drv_data, SSSR) + & SSSR_TFL_MASK) >> 8; + + if (tx_level) { + /* On MMP2, flipping SSE doesn't to empty TXFIFO. */ + dev_warn(&spi->dev, "%d bytes of garbage in TXFIFO!\n", + tx_level); + if (tx_level > transfer->len) + tx_level = transfer->len; + drv_data->tx += tx_level; + } + } + if (spi_controller_is_slave(master)) { while (drv_data->write(drv_data)) ;