From patchwork Tue Jan 23 19:56:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Jan_Kundr=C3=A1t?= X-Patchwork-Id: 10182583 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 9C2CD60233 for ; Wed, 24 Jan 2018 13:30:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 82CC728249 for ; Wed, 24 Jan 2018 13:30:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 75F6428538; Wed, 24 Jan 2018 13:30:13 +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=-5.7 required=2.0 tests=BAYES_00, DATE_IN_PAST_12_24, DKIM_SIGNED, RCVD_IN_DNSWL_HI, T_DKIM_INVALID 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 5757C28249 for ; Wed, 24 Jan 2018 13:30:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933722AbeAXNaM (ORCPT ); Wed, 24 Jan 2018 08:30:12 -0500 Received: from office2.cesnet.cz ([195.113.144.244]:52130 "EHLO office2.cesnet.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933720AbeAXNaL (ORCPT ); Wed, 24 Jan 2018 08:30:11 -0500 Received: from localhost (unknown [IPv6:2001:718:1:2c:4c87:d4a8:de7f:541e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 66CCD400052; Wed, 24 Jan 2018 14:30:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1516800609; bh=WU8E5HOpgBEbaoXk1qMtBTnCe93qurlEuCfKxbiqHbM=; h=Resent-Date:Resent-From:Resent-To:Resent-Cc:From:Date:Subject:To: Cc; b=rVesJvq8YrKT/fepNAeF3FkKGd6CgXdfoeRK9+VcMKoE9tU5YWPaJZOA82JdjEuyu edS22680aF62UehdE5V00S8rsMIraOnvmCA25xyZiwxUoHnmN8mjqNSYKej/cq6IwJ PejgN0zuBdQ8m012ZulT8Iw9NUYaYs7/nDZhC9K0= Message-Id: From: =?UTF-8?q?Jan=20Kundr=C3=A1t?= Date: Tue, 23 Jan 2018 20:56:15 +0100 Subject: [PATCH] spi: orion: Allow specifying which HW CS to use with a GPIO CS MIME-Version: 1.0 To: linux-spi@vger.kernel.org Cc: Mark Brown , Chris Packham 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 Commit b28b9149b37f added support for using an additional GPIO pin for Chip Select. According to that commit and to my understanding of a semi-public datahseet, it seems that the SPI hardware really insists on driving *some* HW CS signal whenever a SPI transaction is in progress. The old code effectively forced the HW CS pin to be CS0. That means that there could not be anything connected to the real CS0 signal when one uses a GPIO CS. That assumption does not hold on e.g. Solidrun Clearfog where some SOM models have a built-in SPI flash on SPI1, CS0. Signed-off-by: Jan Kundrát --- .../devicetree/bindings/spi/spi-orion.txt | 22 ++++++++++++++++++++++ drivers/spi/spi-orion.c | 10 +++++++--- 2 files changed, 29 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/spi/spi-orion.txt b/Documentation/devicetree/bindings/spi/spi-orion.txt index 8434a65fc12a..c7027af04fb2 100644 --- a/Documentation/devicetree/bindings/spi/spi-orion.txt +++ b/Documentation/devicetree/bindings/spi/spi-orion.txt @@ -28,6 +28,11 @@ Optional properties: - clock-names : names of used clocks, mandatory if the second clock is used, the name must be "core", and "axi" (the latter is only for Armada 7K/8K). +- orion-spi,cs-gpio-hw-cs : Because the SoC always wants to drive some HW Chip + Select pin, it is necessary to specify which one + should be used when Linux drives an additional + GPIO as a software-controlled CS. Defaults to HW + CS 0. Example: @@ -74,6 +79,23 @@ are used in the default indirect (PIO) mode): , /* SPI0-DEV1 */ ; /* SPI1-DEV2 */ + +Example with a GPIO CS to be driven by software in addition to HW CS3. This +can be used when the board or the pinmux does not allow connections to HW CS +pins, for example: + + spi0: spi@10600 { + /* ... */ + cs-gpios = <0>, <&gpio0 22 GPIO_ACTIVE_HIGH>, <0>; + orion-spi,cs-gpio-hw-cs = <3>; + + something@1 { + reg = <1>; + /* this device should be now connected to a custom GPIO CS */ + }; + } + + For further information on the MBus bindings, please see the MBus DT documentation: Documentation/devicetree/bindings/bus/mvebu-mbus.txt diff --git a/drivers/spi/spi-orion.c b/drivers/spi/spi-orion.c index 482a0cf3b7aa..b1b0537b4450 100644 --- a/drivers/spi/spi-orion.c +++ b/drivers/spi/spi-orion.c @@ -96,6 +96,7 @@ struct orion_spi { struct clk *clk; struct clk *axi_clk; const struct orion_spi_dev *devdata; + int cs_hw_gpio; struct orion_direct_acc direct_access[ORION_NUM_CHIPSELECTS]; }; @@ -324,13 +325,13 @@ static void orion_spi_set_cs(struct spi_device *spi, bool enable) struct orion_spi *orion_spi; int cs; + orion_spi = spi_master_get_devdata(spi->master); + if (gpio_is_valid(spi->cs_gpio)) - cs = 0; + cs = orion_spi->cs_hw_gpio; else cs = spi->chip_select; - orion_spi = spi_master_get_devdata(spi->master); - orion_spi_clrbits(orion_spi, ORION_SPI_IF_CTRL_REG, ORION_SPI_CS_MASK); orion_spi_setbits(orion_spi, ORION_SPI_IF_CTRL_REG, ORION_SPI_CS(cs)); @@ -645,6 +646,9 @@ static int orion_spi_probe(struct platform_device *pdev) tclk_hz = clk_get_rate(spi->clk); + if (!pdev->dev.of_node || of_property_read_u32(pdev->dev.of_node, "orion-spi,cs-gpio-hw-cs", &spi->cs_hw_gpio)) + spi->cs_hw_gpio = 0; + /* * With old device tree, armada-370-spi could be used with * Armada XP, however for this SoC the maximum frequency is