Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp2096616ybf; Mon, 2 Mar 2020 01:49:25 -0800 (PST) X-Google-Smtp-Source: APXvYqy/EqpKsrhaL3MFeB7qV/Qw1grxQ6UB2utwX4cN9ofW0JaGKrmM6ql2N5B017v1UsbWaS7H X-Received: by 2002:a9d:46e:: with SMTP id 101mr12512720otc.11.1583142565388; Mon, 02 Mar 2020 01:49:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583142565; cv=none; d=google.com; s=arc-20160816; b=m+O8UOB8ctjF3fwv8kyHHE0uB1+O871tJ90aZ7hd52ynSPlKvRRodN9VKl/XO04kK5 BzlpX8ggQTxMExdDiKz8omvROiQy/tskoPMmSiAYWjOJkW7QTCtx4SCQEmxU3DJiwT4J pCJr6wKtTMp8HlMoAP51lidvhTmf9VrgmpaMlvn6GnVCry4rvsvbDXYwzd89jQ8VDMHV +sA8rdg8M1mCHItnNrtsI14ds7gjx/uDnbrzNvdwzEp3un/kSKz4IQ0zQwKHMPO38tqH KPYKfJgwojmhx3su0rExJ24H4R7yGP7UhmaPL6i5lpS6QuSvlSw7jPj1ILf9Y4Jk6W6v eZdA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=8mylNuvbMkUyD9rWCtIxmMJyS7kJVNxinoSR3QWr/xU=; b=VgHRk+CBSSHDezsHSuMirJUjOdVr8AiuX3+ZFPqGz0iPB3PFs7PNdhvc/Si3cjjOFD UkclYx1YoyD3BJUi/3fjiaT/pyym0hQNb6mYjHDkgQ7Ipk9nnWtwEOmRw/a5LgcB/pwJ ZPpzJ+v4GFlRdZppQdrupKSY6pu1u5M0jcaiVTA7al3z3wH7TI4pRof5PP9q/hHGYOnd vi/Ou2MRtVV9gzGQd+WomJ2KyUgeBTL05VH0Mw53oSnwgz1a/CJriKo6h3FKrg3v4Y6L 3b7gw2Qz1NCFAXYcO+P3+SWpdrIe0hoKwNWVvcp+2a7nTdl1P7oDkbiOr7A6TdaoUJMO 5xsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=E5RZ1AVS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 10si5868744ois.76.2020.03.02.01.49.12; Mon, 02 Mar 2020 01:49:25 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=E5RZ1AVS; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727511AbgCBJtI (ORCPT + 99 others); Mon, 2 Mar 2020 04:49:08 -0500 Received: from lelv0142.ext.ti.com ([198.47.23.249]:57576 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726956AbgCBJtI (ORCPT ); Mon, 2 Mar 2020 04:49:08 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0229mXWF024857; Mon, 2 Mar 2020 03:48:33 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1583142513; bh=8mylNuvbMkUyD9rWCtIxmMJyS7kJVNxinoSR3QWr/xU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=E5RZ1AVSpIt/g0rMSH1E6MehYBpDwLns1mbervza/PIeplJ/3i903D3JChyiflGUX udlfjay7F8V2/RogkH2QR8gpgPPUSDVAyV8VCx635HWvo4m+57IZG6HL1O5VrIkKb8 Vc0e5C7HscoOC/jll4acVVh5spjQslWWCkjSgA/I= Received: from DLEE109.ent.ti.com (dlee109.ent.ti.com [157.170.170.41]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0229mXHC032787 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Mar 2020 03:48:33 -0600 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE109.ent.ti.com (157.170.170.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Mon, 2 Mar 2020 03:48:33 -0600 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Mon, 2 Mar 2020 03:48:32 -0600 Received: from localhost (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 0229mWaZ019765; Mon, 2 Mar 2020 03:48:32 -0600 Date: Mon, 2 Mar 2020 15:18:31 +0530 From: Pratyush Yadav To: Boris Brezillon CC: Tudor Ambarus , Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Mark Brown , Rob Herring , Mark Rutland , , Sekhar Nori , , , Subject: Re: [PATCH v2 02/11] spi: set mode bits for "spi-rx-dtr" and "spi-tx-dtr" Message-ID: <20200302094829.opazalwldrdn4s7y@ti.com> References: <20200226093703.19765-1-p.yadav@ti.com> <20200226093703.19765-3-p.yadav@ti.com> <20200227172247.0e8ec459@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20200227172247.0e8ec459@collabora.com> User-Agent: NeoMutt/20171215 X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris, On 27/02/20 05:23PM, Boris Brezillon wrote: > On Wed, 26 Feb 2020 15:06:54 +0530 > Pratyush Yadav wrote: > > > These two DT properties express DTR receive and transmit capabilities of > > a SPI flash and controller. Introduce two new mode bits: SPI_RX_DTR and > > SPI_TX_DTR which correspond to the new DT properties. Set these bits > > when the two corresponding properties are present in the device tree. > > Also update the detection of unsupported mode bits to include the new > > bits. > > > > Signed-off-by: Pratyush Yadav > > --- > > drivers/spi/spi.c | 10 +++++++++- > > include/linux/spi/spi.h | 2 ++ > > 2 files changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > > index 38b4c78df506..25c8ed9343f9 100644 > > --- a/drivers/spi/spi.c > > +++ b/drivers/spi/spi.c > > @@ -1927,6 +1927,13 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct spi_device *spi, > > } > > } > > > > + /* Device DTR mode. */ > > + if (of_property_read_bool(nc, "spi-tx-dtr")) > > + spi->mode |= SPI_TX_DTR; > > + > > + if (of_property_read_bool(nc, "spi-rx-dtr")) > > + spi->mode |= SPI_RX_DTR; > > + > > If this DTR mode is only used in spi-mem, maybe we shouldn't add those > flags. SPI mem devices are usually smart enough to advertise what they > support, and the subsystem in charge of those devices (in this specific > case, spi-nor) will check what the controller supports > using spi_mem_supports_op(). The only case we might have to deal with > at some point is board level limitations (disabling DTR because the > routing prevents using this mode). Yes, being able to handle board-level limitations is the main reason behind this change. There should be a way to over-ride the use of DTR for a given board. And IIUC, SPI allows doing the same for Rx and Tx buswidth. So I don't see why we should deviate from that model. > > if (spi_controller_is_slave(ctlr)) { > > if (!of_node_name_eq(nc, "slave")) { > > dev_err(&ctlr->dev, "%pOF is not called 'slave'\n", > > @@ -3252,7 +3259,8 @@ int spi_setup(struct spi_device *spi) > > bad_bits &= ~SPI_CS_HIGH; > > ugly_bits = bad_bits & > > (SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL | > > - SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL); > > + SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL | > > + SPI_TX_DTR | SPI_RX_DTR); > > if (ugly_bits) { > > dev_warn(&spi->dev, > > "setup: ignoring unsupported mode bits %x\n", > > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h > > index 6d16ba01ff5a..bf1108318389 100644 > > --- a/include/linux/spi/spi.h > > +++ b/include/linux/spi/spi.h > > @@ -183,6 +183,8 @@ struct spi_device { > > #define SPI_TX_OCTAL 0x2000 /* transmit with 8 wires */ > > #define SPI_RX_OCTAL 0x4000 /* receive with 8 wires */ > > #define SPI_3WIRE_HIZ 0x8000 /* high impedance turnaround */ > > +#define SPI_RX_DTR 0x10000 /* receive in DTR mode */ > > +#define SPI_TX_DTR 0x20000 /* transmit in DTR mode */ > > int irq; > > void *controller_state; > > void *controller_data; > -- Regards, Pratyush Yadav Texas Instruments India