From patchwork Mon Sep 17 12:08:03 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lubomir Rintel X-Patchwork-Id: 10602625 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 CA3D71508 for ; Mon, 17 Sep 2018 12:08:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B4DC2299DB for ; Mon, 17 Sep 2018 12:08:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A9022299EE; Mon, 17 Sep 2018 12:08:38 +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.9 required=2.0 tests=BAYES_00,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 3702C299DB for ; Mon, 17 Sep 2018 12:08:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728440AbeIQRfj (ORCPT ); Mon, 17 Sep 2018 13:35:39 -0400 Received: from shell.v3.sk ([90.176.6.54]:47276 "EHLO shell.v3.sk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728386AbeIQRfj (ORCPT ); Mon, 17 Sep 2018 13:35:39 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.v3.sk (Postfix) with ESMTP id 5D093AF2E6; Mon, 17 Sep 2018 14:08:34 +0200 (CEST) Received: from shell.v3.sk ([127.0.0.1]) by localhost (zimbra.v3.sk [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3kjHkzOfsv-f; Mon, 17 Sep 2018 14:08:21 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.v3.sk (Postfix) with ESMTP id 061F6AF118; Mon, 17 Sep 2018 14:08:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.v3.sk Received: from shell.v3.sk ([127.0.0.1]) by localhost (zimbra.v3.sk [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ejiL2BVPYkHq; Mon, 17 Sep 2018 14:08:20 +0200 (CEST) Received: from belphegor.brq.redhat.com (nat-pool-brq-t.redhat.com [213.175.37.10]) by zimbra.v3.sk (Postfix) with ESMTPSA id DB9AAAEEAD; Mon, 17 Sep 2018 14:08:19 +0200 (CEST) From: Lubomir Rintel To: Geert Uytterhoeven Cc: linux-spi@vger.kernel.org Subject: [PATCH RFC 0/7] Signal pxa2xx SPI slave readiness via handshake signal [Was: SPI Slave with handshaking] Date: Mon, 17 Sep 2018 14:08:03 +0200 Message-Id: <20180917120808.20224-1-lkundrak@v3.sk> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: 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 Hello Geert, thanks for your response. On Mon, 2018-08-27 at 16:32 +0200, Geert Uytterhoeven wrote: > Hi Lubo, > > On Tue, Aug 21, 2018 at 10:14 AM Lubomir Rintel wrote: > > I'm trying to port the OPLC XO 1.75 Embedded Controler (EC) driver to the SPI > > slave framework. The EC is a SPI master that uses an extra pair of handshake > > signals to determine when is it safe to transmit. The original driver [1] > > included the SPI slave driver. > > > > [1] http://dev.laptop.org/git/olpc-kernel/tree/drivers/misc/olpc-ec-1-75.c?h=arm-3.0-wip > > > > To send the command to the EC, the protocol requires me to [2] signal to the > > master that the tx FIFO is filled and it can start the transaction. The problem > > is that I have no idea when that is. I'm wondering what my options are? > > The SPI slave output FIFO has been filled after the SPI slave controller's > spi_controller.transfer_one() function has written all data to the controller's > FIFO. Hence this is SPI controller specific. > > After filling the FIFO, the SPI slave controller should assert the ACK line. Yes. In fact, the EC detect an edge on the ACK/Ready line, and resets its state machine when it's held high for too long, thus it just needs to be strobed. > > > [2] http://wiki.laptop.org/go/XO_1.75_HOST_to_EC_Protocol > > > > 1.) Add a ready() callback to the spi_message, that would fire after the tx > > FIFO has been filled? > > > > 2.) Delay the ACK strobe a bit after spi_async() and just hope for the best > > (Eek) > > > > 3.) Have the transfer with NULL rx_buf complete just after sending the data to > > the controller, not waiting for actual transfer. And then strobe the ACK. > > > > 4.) Keep the SPI slave code in the EC driver. I suppose this wouldn't be > > acceptable? > > > > Better ideas, opinions & advice appreciated! > > Is this on a DT-based platform? > If yes, the GPIO (I assume it's a GPIO) used for the ACK signal will be > provided by DT, and the SPI slave controller driver can assert it from its > transfer_one() (or .transfer_one_message()) function after filling the FIFO. Yes it is. I'm following up with a couple of patches that aim to implement your suggestion. I'd be very thankful if you could take a look and let me know if I got that right. The patches don't include the EC driver, since that one needs some more infrastructure work. My current working version is here: https://github.com/hackerspace/olpc-xo175-linux/commits/lr/olpc-xo175-fixes2-spi-ec The relevant patches are the last two: https://github.com/hackerspace/olpc-xo175-linux/commit/ae67cbc4d86.patch https://github.com/hackerspace/olpc-xo175-linux/commit/70bca1bc176.patch If that looks reasonable, I'll go ahead and submit the whole thing for review. Regards, Lubo