Message ID | 20240208135045.3728927-2-tudor.ambarus@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-58176-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp179122dyd; Thu, 8 Feb 2024 05:52:36 -0800 (PST) X-Google-Smtp-Source: AGHT+IGfSRBbVnUwO8kTo1F6NyIUTl0vsyCnOIsQi+6bQbWQTUv61MZhsrldiiGFGQWtLIr3uPP+ X-Received: by 2002:a17:902:6503:b0:1d9:a609:dd96 with SMTP id b3-20020a170902650300b001d9a609dd96mr6968740plk.41.1707400356390; Thu, 08 Feb 2024 05:52:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707400356; cv=pass; d=google.com; s=arc-20160816; b=n1iUDKEgzGnkOHtUDqfL2qhXoUhY2C1qMGh3eKi6N83I4NK5z8qFCaJoffoIdQ7rk9 xVa3t9d9/E9R+plBcZOx5v9DnpmvgeInxz2SufDEca5iv0Xnnmv6py5KvaJAts2N+X30 BlQ1l2oUFZseFcJzD8rzBG1p146gQMZnwUO2WRbcqGbq5BQCTllXESd6ub/b4XQGKcPI CmcmWxZhwWfM9+me9wqYmEt++sV9yqs+nIP/Hrw/rob6ZllTsDr6oS9zqHk46BJRy+Fk aI3zHph5KdaXH3tYSibsQdbDVNcO6J9vJV0NXR8GnJ9Qd6DCjIdhbii23kTjwPbVaHiT PLvw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=rjENHLcLIAVWZiAZ2HXcUWfnK57wdK8wfcg4H3+qzmM=; fh=VG2vFUri+P7UMQqacv0QIYNVYfuibjHgJ8JCnV4ByhA=; b=eOXNFbeytgzmBv/k1zJh7FwXR99qFWk99aRfwR6sl+EcKBR6/hCGEqZ4rQdQsTYYkf 5MjZ1uf2N1FYAZGWEDdpm4rGVixBNSCT+HfxvkRZiig25IEABSqDzcQNbvdxY/GCsW1x 86qN59xwlU3aWW1RqJl2EA5nv2tvVCCXlz3YpBOXpdgyOVnmOO3OPFDhY+WjGGLEi1zE xrZ8mOX61csoI+pBQDVuugFyUH7zUesxE0py33UMZqrxqbsTek29s4ClhCpa1+gD3Q/M SscehWHydOmMWfNEXpKx+LNS2I6hjcZJTx6o/5L0haEeuXoYQLzyRMNf4lxb11WdbnS7 OpmQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AoVlE0sO; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-58176-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-58176-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org X-Forwarded-Encrypted: i=2; AJvYcCVArtOdJktteqrVnLybMdBi4WAyRfzN+4+PtHQR8hhuOvWUS7UKHf0V0oUEtpJKT5jwNLWPoArKNVMqtH+9lZ7KR/qKWw== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id y14-20020a17090322ce00b001d94e3bdb0esi2609715plg.278.2024.02.08.05.52.36 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Feb 2024 05:52:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-58176-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AoVlE0sO; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-58176-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-58176-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 824E2289851 for <ouuuleilei@gmail.com>; Thu, 8 Feb 2024 13:51:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9EAE07B3D9; Thu, 8 Feb 2024 13:51:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="AoVlE0sO" Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4A79476C63 for <linux-kernel@vger.kernel.org>; Thu, 8 Feb 2024 13:50:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707400257; cv=none; b=MhL5Kfqql6U6+GPEI9+D6azLHH1peb0sy4Dl7I0Yq8lynyRLvdCO/JH7JVAC2qgstkBpTMsNt27UWF5/d6YA/ZLLFXzBljPkJLsYRMHjCK6cpVQER70+YRAfKV0cTZ3URoc0vFEJb+b0o1icIoGIFq+MT3nfYX2fpU8qmGPbkAQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707400257; c=relaxed/simple; bh=p2usWgPysTo/9X224ZyHEY+TGT4J7QxxP4dWqWMr0XI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K+kiUPT7Ic5p0kwqV5i/RA1pvJESV9Dyrd6Jv+BEF19EYiZOVG5tVlIh9nINmbfmak2r7ZM2ZTZzdLGjM/W8vpkICeP0tkS3d6aOcDxx3LCsaIwCnYbjQr0dsMDgRrotWSLuXHd0RTMpUHI0pRAD8kYMnslHbQI4hcqQXjfTO0g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=AoVlE0sO; arc=none smtp.client-ip=209.85.221.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-33b58ca0b95so368699f8f.0 for <linux-kernel@vger.kernel.org>; Thu, 08 Feb 2024 05:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707400253; x=1708005053; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=rjENHLcLIAVWZiAZ2HXcUWfnK57wdK8wfcg4H3+qzmM=; b=AoVlE0sOiLAEnTCHm4OGJBe0gKJ7eNEeKclZqC9ZQuYla3RMkNoFF3jt81+GyYrQKJ btOBnbavW+LavtkdLKdb6ltdQd56NG/JSLdly0y0w/Fa/8MhcV6rZj7JZ+J7olNuu1vf I6yexrc9G/Cx7dQmdLG5c3I+JtEQmPlt/a32m1fs/zfDkqCRg68ZpvLFhhpvo4+Nf13r Ba4Em1LlxWJURfHrg7RUNVouPOnXHA5538lpA7+v8DJj6J2xc7Nu3QDtVEALoclbysG7 niOwuJhjYkZ7Ux3DGgn+LHgAyO/7gRIrgBbhhlChAg9PO1R7rJmb3V13uHQRWUkHdlGp j8nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707400253; x=1708005053; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rjENHLcLIAVWZiAZ2HXcUWfnK57wdK8wfcg4H3+qzmM=; b=ruEiJxLA5xQncQu/Q147BzXOnpLPOqjjwIEj8jTdy5VsmuAqtpkPNrUSttW+5iDMdq 9aqa5AgXQsxdly9yLkoM7wS1plQqEHptAx3k3FWch6RzCkXrf4TmthJZNkPx4BSPazHE f5m7w3NdXdx0I9netW1JZwXxv5OdJT2bDg6RLHC57qPQJvYdxUZENFPPhi6MQPsZuDVs r93qOYlmFD1wyziT5nNu8KVstZiwF9yVU1hlz7conXR6o+wMIc4vb4BjgQwIyp881koj 496yQhIWma40ol3Q5kxxcEI0AK6rMYh/ALhnnfnFhMO6nqi7lBQSmEf7Cyv/nlLDVXzU 2uxQ== X-Gm-Message-State: AOJu0YzJHVaSmjOrjfDC1Mbxi8XzUT30ltEXvU2xk/PlUI4iRIScFyKC n/pfd4R31q6/wvvaLs8f9B+M1Z/JQhr+y2BBVE6S8D0lT81p38pADyCZ9euEQyw= X-Received: by 2002:adf:f34f:0:b0:33b:295d:19b6 with SMTP id e15-20020adff34f000000b0033b295d19b6mr6293505wrp.69.1707400253564; Thu, 08 Feb 2024 05:50:53 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCUi6mIo+LskNjMyaaVLjIy6CST18FnOprx16kaQQ3OihpdMbQUNWNaYUGAGHR93OtO6K92p6mEtJnar2aOye3GKZ7S34SIxXYa+NqaxXYQo7K4Ivxg24z1FFeT4A9ctzPYwr9CmtVcR1DlJ1DV0hIjNjdzb/HZH5//1D89Tg7hXr7m7iT0ouvMzj4MT4kNjxbZfPO/wFZZlRiHkOD3AOiraCwZoUF5ZtjLwvqaUGCN0zh8xwoWx4JbnUHZu5fG+rWITuh6NDPZ2Fxk0dy22n64L6of90Y1YfLEdNX6U0knQT6hLUFxUjzM11umvZo1e5T3n9a8Xukm7pSFizaVq1rqG4ixTdfA74DMnekHEVDFCUZDiV5jhyi0FmDlVpVkbkVafpoBJWblDTQhXbaIft4ZeRKdgXTvDZYizOv9lGifXCb2RI/9EWHU8c1Z1F9nfWaSho2vrgPbQOO7prFhiFARfNnY/SWpbFq5gSKeqqhIYlESgaEt4kOZRhUZxkrTQYhJoXc263scl/YdNAZR3vwDhs4pXP7TGQvp+1vlyCf8U3f4K8b71k45qm0fLeIhjhndFbOt0Sh+5Kezk2X5q6Cd3H0Htj6huuB9EEbrBWw== Received: from ta2.c.googlers.com.com (105.168.195.35.bc.googleusercontent.com. [35.195.168.105]) by smtp.gmail.com with ESMTPSA id m20-20020a056000181400b0033b43a5f53csm3618820wrh.103.2024.02.08.05.50.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Feb 2024 05:50:53 -0800 (PST) From: Tudor Ambarus <tudor.ambarus@linaro.org> To: broonie@kernel.org, robh@kernel.org, andi.shyti@kernel.org, semen.protsenko@linaro.org Cc: krzysztof.kozlowski@linaro.org, alim.akhtar@samsung.com, linux-spi@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, andre.draszik@linaro.org, peter.griffin@linaro.org, kernel-team@android.com, willmcvicker@google.com, conor+dt@kernel.org, devicetree@vger.kernel.org, arnd@arndb.de, Tudor Ambarus <tudor.ambarus@linaro.org> Subject: [PATCH 01/12] spi: dt-bindings: introduce the ``fifo-depth`` property Date: Thu, 8 Feb 2024 13:50:34 +0000 Message-ID: <20240208135045.3728927-2-tudor.ambarus@linaro.org> X-Mailer: git-send-email 2.43.0.687.g38aa6559b0-goog In-Reply-To: <20240208135045.3728927-1-tudor.ambarus@linaro.org> References: <20240208135045.3728927-1-tudor.ambarus@linaro.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790339036438560155 X-GMAIL-MSGID: 1790339036438560155 |
Series |
spi: s3c64xx: remove OF alias ID dependency
|
|
Commit Message
Tudor Ambarus
Feb. 8, 2024, 1:50 p.m. UTC
There are instances of the same IP that are configured by the integrator
with different FIFO depths. Introduce the fifo-depth property to allow
such nodes to specify their FIFO depth.
We haven't seen SPI IPs with different FIFO depths for RX and TX, thus
introduce a single property.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Documentation/devicetree/bindings/spi/spi-controller.yaml | 5 +++++
1 file changed, 5 insertions(+)
Comments
On Thu, Feb 08, 2024 at 01:50:34PM +0000, Tudor Ambarus wrote: > There are instances of the same IP that are configured by the integrator > with different FIFO depths. Introduce the fifo-depth property to allow > such nodes to specify their FIFO depth. > > We haven't seen SPI IPs with different FIFO depths for RX and TX, thus > introduce a single property. Some citation attached to this would be nice. "We haven't seen" offers no detail as to what IPs that allow this sort of configuration of FIFO size that you have actually checked. I went and checked our IP that we use in FPGA fabric, which has a configurable fifo depth. It only has a single knob for both RX and TX FIFOs. The Xilinx xps spi core also has configurable FIFOs, but again RX and TX sizes are tied there. At least that's a sample size of three. One of our guys is working on support for the IP I just mentioned and would be defining a vendor property for this, so Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Thanks, Conor. > > Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> > --- > Documentation/devicetree/bindings/spi/spi-controller.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml > index 524f6fe8c27b..99272e6f115e 100644 > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml > @@ -69,6 +69,11 @@ properties: > Should be generally avoided and be replaced by > spi-cs-high + ACTIVE_HIGH. > > + fifo-depth: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + Size of the data FIFO in bytes. > + > num-cs: > $ref: /schemas/types.yaml#/definitions/uint32 > description: > -- > 2.43.0.687.g38aa6559b0-goog >
+ Geert On 2/8/24 18:24, Conor Dooley wrote: > On Thu, Feb 08, 2024 at 01:50:34PM +0000, Tudor Ambarus wrote: >> There are instances of the same IP that are configured by the integrator >> with different FIFO depths. Introduce the fifo-depth property to allow >> such nodes to specify their FIFO depth. >> >> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus >> introduce a single property. > > Some citation attached to this would be nice. "We haven't seen" offers > no detail as to what IPs that allow this sort of configuration of FIFO > size that you have actually checked. > > I went and checked our IP that we use in FPGA fabric, which has a > configurable fifo depth. It only has a single knob for both RX and TX > FIFOs. The Xilinx xps spi core also has configurable FIFOs, but again RX > and TX sizes are tied there. At least that's a sample size of three. > > One of our guys is working on support for the IP I just mentioned and > would be defining a vendor property for this, so > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > Thanks, Conor. I had in mind that SPI has a shift register and it's improbable to have different FIFO depths for RX and TX. At least I don't see how it would work, I guess it will use the minimum depth between the two? I grepped by "fifo" in the spi bindings and I now see that renesas is using dedicated properties for RX and TX, but I think that there too the FIFOs have the same depths. Looking into drivers/spi/spi-sh-msiof.c I see that the of_device_id.data contains 64 bytes FIFOs for RX and TX, regardless of the compatible. Geert, any idea if the FIFO depths can differ for RX and TX in spi-sh-msiof.c? Anyway, even if there are such imbalanced architectures, I guess we can consider them when/if they appear? (add rx/tx-fifo-depth dt properties) Cheers, ta ---- $ git grep fifo Documentation/devicetree/bindings/spi/ Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml: atmel,fifo-size: Documentation/devicetree/bindings/spi/atmel,at91rm9200-spi.yaml: atmel,fifo-size = <32>; Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: cdns,fifo-depth: Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: cdns,fifo-depth: Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: cdns,fifo-depth: Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: cdns,fifo-width: Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: - cdns,fifo-depth Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: - cdns,fifo-width Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: cdns,fifo-depth = <128>; Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml: cdns,fifo-width = <4>; Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: renesas,tx-fifo-size: Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: Override the default TX fifo size. Unit is words. Ignored if 0. Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: renesas,rx-fifo-size: Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: Override the default RX fifo size. Unit is words. Ignored if 0. Documentation/devicetree/bindings/spi/spi-sifive.yaml: sifive,fifo-depth: Documentation/devicetree/bindings/spi/spi-sifive.yaml: sifive,fifo-depth = <8>;
On Fri, Feb 09, 2024 at 01:56:56PM +0000, Tudor Ambarus wrote: > > + Geert > > On 2/8/24 18:24, Conor Dooley wrote: > > On Thu, Feb 08, 2024 at 01:50:34PM +0000, Tudor Ambarus wrote: > >> There are instances of the same IP that are configured by the integrator > >> with different FIFO depths. Introduce the fifo-depth property to allow > >> such nodes to specify their FIFO depth. > >> > >> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus > >> introduce a single property. > > > > Some citation attached to this would be nice. "We haven't seen" offers > > no detail as to what IPs that allow this sort of configuration of FIFO > > size that you have actually checked. > > > > I went and checked our IP that we use in FPGA fabric, which has a > > configurable fifo depth. It only has a single knob for both RX and TX > > FIFOs. The Xilinx xps spi core also has configurable FIFOs, but again RX > > and TX sizes are tied there. At least that's a sample size of three. > > > > One of our guys is working on support for the IP I just mentioned and > > would be defining a vendor property for this, so > > Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > > > > Thanks, Conor. I had in mind that SPI has a shift register and it's > improbable to have different FIFO depths for RX and TX. IDK, but I've learned to expect the unexpectable, especially when it comes to the IPs intended for use in FPGAs. > At least I don't > see how it would work, I guess it will use the minimum depth between the > two? I'm not really sure how it would work other than that in the general case, but some use case specific configuration could work, but I do agree that it is > I grepped by "fifo" in the spi bindings and I now see that renesas is > using dedicated properties for RX and TX, but I think that there too the > FIFOs have the same depths. Looking into drivers/spi/spi-sh-msiof.c I > see that the of_device_id.data contains 64 bytes FIFOs for RX and TX, > regardless of the compatible. > > Geert, any idea if the FIFO depths can differ for RX and TX in > spi-sh-msiof.c? > > Anyway, even if there are such imbalanced architectures, I guess we can > consider them when/if they appear? (add rx/tx-fifo-depth dt properties) I think so. > Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: > Override the default TX fifo size. Unit is words. Ignored if 0. > Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: > renesas,rx-fifo-size: > Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: > Override the default RX fifo size. Unit is words. Ignored if 0. These renesas ones seemed interesting at first glance due to these comments, but what's missed by grep the is "deprecated" marking on these. They seem to have been replaced by soc-specific compatibles.
On 2/9/24 16:21, Conor Dooley wrote: > On Fri, Feb 09, 2024 at 01:56:56PM +0000, Tudor Ambarus wrote: >> >> + Geert >> >> On 2/8/24 18:24, Conor Dooley wrote: >>> On Thu, Feb 08, 2024 at 01:50:34PM +0000, Tudor Ambarus wrote: >>>> There are instances of the same IP that are configured by the integrator >>>> with different FIFO depths. Introduce the fifo-depth property to allow >>>> such nodes to specify their FIFO depth. >>>> >>>> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus >>>> introduce a single property. >>> >>> Some citation attached to this would be nice. "We haven't seen" offers >>> no detail as to what IPs that allow this sort of configuration of FIFO >>> size that you have actually checked. >>> >>> I went and checked our IP that we use in FPGA fabric, which has a >>> configurable fifo depth. It only has a single knob for both RX and TX >>> FIFOs. The Xilinx xps spi core also has configurable FIFOs, but again RX >>> and TX sizes are tied there. At least that's a sample size of three. >>> >>> One of our guys is working on support for the IP I just mentioned and >>> would be defining a vendor property for this, so >>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> >>> >> >> Thanks, Conor. I had in mind that SPI has a shift register and it's >> improbable to have different FIFO depths for RX and TX. > > IDK, but I've learned to expect the unexpectable, especially when it > comes to the IPs intended for use in FPGAs. > >> At least I don't >> see how it would work, I guess it will use the minimum depth between the >> two? > > I'm not really sure how it would work other than that in the general > case, but some use case specific configuration could work, but I do > agree that it is > >> I grepped by "fifo" in the spi bindings and I now see that renesas is >> using dedicated properties for RX and TX, but I think that there too the >> FIFOs have the same depths. Looking into drivers/spi/spi-sh-msiof.c I >> see that the of_device_id.data contains 64 bytes FIFOs for RX and TX, >> regardless of the compatible. >> >> Geert, any idea if the FIFO depths can differ for RX and TX in >> spi-sh-msiof.c? >> >> Anyway, even if there are such imbalanced architectures, I guess we can >> consider them when/if they appear? (add rx/tx-fifo-depth dt properties) > > I think so. > >> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: >> Override the default TX fifo size. Unit is words. Ignored if 0. >> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: >> renesas,rx-fifo-size: >> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: >> Override the default RX fifo size. Unit is words. Ignored if 0. > > These renesas ones seemed interesting at first glance due to these > comments, but what's missed by grep the is "deprecated" marking on > these. They seem to have been replaced by soc-specific compatibles. In the driver the renesas,{rx,tx}-fifo-size properties still have the highest priority: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/tree/drivers/spi/spi-sh-msiof.c#n1350 Maybe something for Geert, as I see he was the one marking these properties as deprecated. I guess he forgot to update the driver. Anyway, I think we shall be fine, even if we don't hear from Geert. Cheers, ta
Hi Tudor, On Thu, Feb 8, 2024 at 2:51 PM Tudor Ambarus <tudor.ambarus@linaro.org> wrote: > There are instances of the same IP that are configured by the integrator > with different FIFO depths. Introduce the fifo-depth property to allow > such nodes to specify their FIFO depth. > > We haven't seen SPI IPs with different FIFO depths for RX and TX, thus > introduce a single property. Ha... Current documentation for the Clock-Synchronized Serial Interface with FIFO (MSIOF) on e.g. R-Car Gen2 and later states: FIFO capacity: 32 bits × 64 stages for transmission and 32 bits × 256 stages for reception Initially (many years ago), there was some doubt about the validity of these values (older variants on SH supported 64/64), hence drivers/spi/spi-sh-msiof.c still has .tx_fifo_size = 64, .rx_fifo_size = 64, Probably we should test and revisit this... > --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml > +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml > @@ -69,6 +69,11 @@ properties: > Should be generally avoided and be replaced by > spi-cs-high + ACTIVE_HIGH. > > + fifo-depth: > + $ref: /schemas/types.yaml#/definitions/uint32 > + description: > + Size of the data FIFO in bytes. I think it is prudent to consider the asymmetric case, too. Whether that should be just two properties ("rx-fifo-depth" and "tx-fifo-depth"), or also a third "fifo-depth", I defer to the DT maintainers... > + > num-cs: > $ref: /schemas/types.yaml#/definitions/uint32 > description: Gr{oetje,eeting}s, Geert
On Fri, Feb 09, 2024 at 04:21:16PM +0000, Conor Dooley wrote: > On Fri, Feb 09, 2024 at 01:56:56PM +0000, Tudor Ambarus wrote: > > At least I don't > > see how it would work, I guess it will use the minimum depth between the > > two? > I'm not really sure how it would work other than that in the general > case, but some use case specific configuration could work, but I do > agree that it is You do get devices that are single duplex only where the mismatched sizes wouldn't be a pressing issue.
On 09/02/2024 18:13, Geert Uytterhoeven wrote: > Hi Tudor, > > On Thu, Feb 8, 2024 at 2:51 PM Tudor Ambarus <tudor.ambarus@linaro.org> wrote: >> There are instances of the same IP that are configured by the integrator >> with different FIFO depths. Introduce the fifo-depth property to allow >> such nodes to specify their FIFO depth. >> >> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus >> introduce a single property. > > Ha... > > Current documentation for the Clock-Synchronized Serial Interface with > FIFO (MSIOF) on e.g. R-Car Gen2 and later states: > > FIFO capacity: 32 bits × 64 stages for transmission and 32 bits × > 256 stages for reception > > Initially (many years ago), there was some doubt about the validity > of these values (older variants on SH supported 64/64), hence > drivers/spi/spi-sh-msiof.c still has > > .tx_fifo_size = 64, > .rx_fifo_size = 64, > > Probably we should test and revisit this... > >> --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml >> +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml >> @@ -69,6 +69,11 @@ properties: >> Should be generally avoided and be replaced by >> spi-cs-high + ACTIVE_HIGH. >> >> + fifo-depth: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + Size of the data FIFO in bytes. > > I think it is prudent to consider the asymmetric case, too. > Whether that should be just two properties ("rx-fifo-depth" and > "tx-fifo-depth"), or also a third "fifo-depth", I defer to the DT > maintainers... Since most of the cases FIFO depth tx=rx, we could go with three properties and: allOf: - not: required: - fifo-depth - tx-fifo-depth - not: required: - fifo-depth - rx-fifo-depth and probably dependencies between rx and tx (see example-schema). Best regards, Krzysztof
Hi, Geert, Krzysztof, On 2/11/24 13:49, Krzysztof Kozlowski wrote:> On 09/02/2024 18:13, Geert Uytterhoeven wrote: >> Hi Tudor, >> >> On Thu, Feb 8, 2024 at 2:51 PM Tudor Ambarus <tudor.ambarus@linaro.org> wrote: >>> There are instances of the same IP that are configured by the integrator >>> with different FIFO depths. Introduce the fifo-depth property to allow >>> such nodes to specify their FIFO depth. >>> >>> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus >>> introduce a single property. >> >> Ha... >> >> Current documentation for the Clock-Synchronized Serial Interface with >> FIFO (MSIOF) on e.g. R-Car Gen2 and later states: >> >> FIFO capacity: 32 bits × 64 stages for transmission and 32 bits × >> 256 stages for reception >> >> Initially (many years ago), there was some doubt about the validity >> of these values (older variants on SH supported 64/64), hence >> drivers/spi/spi-sh-msiof.c still has >> >> .tx_fifo_size = 64, >> .rx_fifo_size = 64, >> >> Probably we should test and revisit this... >> >>> --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml >>> +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml >>> @@ -69,6 +69,11 @@ properties: >>> Should be generally avoided and be replaced by >>> spi-cs-high + ACTIVE_HIGH. >>> >>> + fifo-depth: >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + description: >>> + Size of the data FIFO in bytes. >> >> I think it is prudent to consider the asymmetric case, too. >> Whether that should be just two properties ("rx-fifo-depth" and >> "tx-fifo-depth"), or also a third "fifo-depth", I defer to the DT >> maintainers... Thanks, Geert for the insight! > > Since most of the cases FIFO depth tx=rx, we could go with three > properties and: > > allOf: > - not: > required: > - fifo-depth > - tx-fifo-depth > - not: > required: > - fifo-depth > - rx-fifo-depth > > and probably dependencies between rx and tx (see example-schema). > Great. Thanks, Krzysztof! I'll give it a try. Cheers, ta
Hi Tudor, On Fri, Feb 9, 2024 at 5:55 PM Tudor Ambarus <tudor.ambarus@linaro.org> wrote: > On 2/9/24 16:21, Conor Dooley wrote: > > On Fri, Feb 09, 2024 at 01:56:56PM +0000, Tudor Ambarus wrote: > >> On 2/8/24 18:24, Conor Dooley wrote: > >>> On Thu, Feb 08, 2024 at 01:50:34PM +0000, Tudor Ambarus wrote: > >>>> There are instances of the same IP that are configured by the integrator > >>>> with different FIFO depths. Introduce the fifo-depth property to allow > >>>> such nodes to specify their FIFO depth. > >>>> > >>>> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus > >>>> introduce a single property. > >>> > >>> Some citation attached to this would be nice. "We haven't seen" offers > >>> no detail as to what IPs that allow this sort of configuration of FIFO > >>> size that you have actually checked. > >>> > >>> I went and checked our IP that we use in FPGA fabric, which has a > >>> configurable fifo depth. It only has a single knob for both RX and TX > >>> FIFOs. The Xilinx xps spi core also has configurable FIFOs, but again RX > >>> and TX sizes are tied there. At least that's a sample size of three. > >>> > >>> One of our guys is working on support for the IP I just mentioned and > >>> would be defining a vendor property for this, so > >>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> > >>> > >> > >> Thanks, Conor. I had in mind that SPI has a shift register and it's > >> improbable to have different FIFO depths for RX and TX. > > > > IDK, but I've learned to expect the unexpectable, especially when it > > comes to the IPs intended for use in FPGAs. > > > >> At least I don't > >> see how it would work, I guess it will use the minimum depth between the > >> two? > > > > I'm not really sure how it would work other than that in the general > > case, but some use case specific configuration could work, but I do > > agree that it is > > > >> I grepped by "fifo" in the spi bindings and I now see that renesas is > >> using dedicated properties for RX and TX, but I think that there too the > >> FIFOs have the same depths. Looking into drivers/spi/spi-sh-msiof.c I > >> see that the of_device_id.data contains 64 bytes FIFOs for RX and TX, > >> regardless of the compatible. > >> > >> Geert, any idea if the FIFO depths can differ for RX and TX in > >> spi-sh-msiof.c? See my other email https://lore.kernel.org/all/CAMuHMdU_Hx9PLmHf2Xm1KKTy_OF-TeCv7SzmA5CZWz+PLkbAGA@mail.gmail.com Note that at one point we did have 64/256 in the driver, but that was changed in commit fe78d0b7691c0274 ("spi: sh-msiof: Fix FIFO size to 64 word from 256 word"). Diving into the discussion around that patch, there seem to be two factors at play: 1. Actual FIFO size, 2. Maximum transfer size per block (up to 2 blocks on R-Car, up to 4 blocks on SH(-Mobile)). As the driver supports only a single block, it should be limited to 64 on R-Car Gen2/3. R-Car Gen4 claims to have widened the register bit field for the maximum transfer size per block, so 256 might be possible there... > >> Anyway, even if there are such imbalanced architectures, I guess we can > >> consider them when/if they appear? (add rx/tx-fifo-depth dt properties) > > > > I think so. > > > >> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: > >> Override the default TX fifo size. Unit is words. Ignored if 0. > >> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: > >> renesas,rx-fifo-size: > >> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: > >> Override the default RX fifo size. Unit is words. Ignored if 0. > > > > These renesas ones seemed interesting at first glance due to these > > comments, but what's missed by grep the is "deprecated" marking on > > these. They seem to have been replaced by soc-specific compatibles. > > In the driver the renesas,{rx,tx}-fifo-size properties still have the > highest priority: > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/tree/drivers/spi/spi-sh-msiof.c#n1350 > > Maybe something for Geert, as I see he was the one marking these > properties as deprecated. I guess he forgot to update the driver. > > Anyway, I think we shall be fine, even if we don't hear from Geert. The renesas,{rx,tx}-fifo-size properties date back to the early days of DT an ARM, when it was assumed that slightly different versions of IP cores could be handled well using a single common compatible value, and properties describing the (few) differences. The pitfall here is the "few differences": too many times people discovered later that there were more differences, needing more properties, and complicating backwards-compatibility. Hence the handling of different FIFO sizes was moved to the driver based on compatible values, and the renesas,{rx,tx}-fifo-size properties were deprecated. See commit beb74bb0875579c4 ("spi: sh-msiof: Add support for R-Car H2 and M2"), which shows that there were more changes needed than the anticipated FIFO sizes. And more were added later, see later additions to sh_msiof_chipdata. So unless it is meant for a configurable synthesizable IP core, where this is a documented parameter of the IP core, I advise against specifying the FIFO size(s) in DT. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68korg In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 2/12/24 10:38, Geert Uytterhoeven wrote: > Hi Tudor, Hi, Geert! > > On Fri, Feb 9, 2024 at 5:55 PM Tudor Ambarus <tudor.ambarus@linaro.org> wrote: >> On 2/9/24 16:21, Conor Dooley wrote: >>> On Fri, Feb 09, 2024 at 01:56:56PM +0000, Tudor Ambarus wrote: >>>> On 2/8/24 18:24, Conor Dooley wrote: >>>>> On Thu, Feb 08, 2024 at 01:50:34PM +0000, Tudor Ambarus wrote: >>>>>> There are instances of the same IP that are configured by the integrator >>>>>> with different FIFO depths. Introduce the fifo-depth property to allow >>>>>> such nodes to specify their FIFO depth. >>>>>> >>>>>> We haven't seen SPI IPs with different FIFO depths for RX and TX, thus >>>>>> introduce a single property. >>>>> >>>>> Some citation attached to this would be nice. "We haven't seen" offers >>>>> no detail as to what IPs that allow this sort of configuration of FIFO >>>>> size that you have actually checked. >>>>> >>>>> I went and checked our IP that we use in FPGA fabric, which has a >>>>> configurable fifo depth. It only has a single knob for both RX and TX >>>>> FIFOs. The Xilinx xps spi core also has configurable FIFOs, but again RX >>>>> and TX sizes are tied there. At least that's a sample size of three. >>>>> >>>>> One of our guys is working on support for the IP I just mentioned and >>>>> would be defining a vendor property for this, so >>>>> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> >>>>> >>>> >>>> Thanks, Conor. I had in mind that SPI has a shift register and it's >>>> improbable to have different FIFO depths for RX and TX. >>> >>> IDK, but I've learned to expect the unexpectable, especially when it >>> comes to the IPs intended for use in FPGAs. >>> >>>> At least I don't >>>> see how it would work, I guess it will use the minimum depth between the >>>> two? >>> >>> I'm not really sure how it would work other than that in the general >>> case, but some use case specific configuration could work, but I do >>> agree that it is >>> >>>> I grepped by "fifo" in the spi bindings and I now see that renesas is >>>> using dedicated properties for RX and TX, but I think that there too the >>>> FIFOs have the same depths. Looking into drivers/spi/spi-sh-msiof.c I >>>> see that the of_device_id.data contains 64 bytes FIFOs for RX and TX, >>>> regardless of the compatible. >>>> >>>> Geert, any idea if the FIFO depths can differ for RX and TX in >>>> spi-sh-msiof.c? > > See my other email > https://lore.kernel.org/all/CAMuHMdU_Hx9PLmHf2Xm1KKTy_OF-TeCv7SzmA5CZWz+PLkbAGA@mail.gmail.com > I saw the response, thanks again! > Note that at one point we did have 64/256 in the driver, but that was > changed in commit fe78d0b7691c0274 ("spi: sh-msiof: Fix FIFO size to > 64 word from 256 word"). Diving into the discussion around that patch, > there seem to be two factors at play: > 1. Actual FIFO size, > 2. Maximum transfer size per block > (up to 2 blocks on R-Car, up to 4 blocks on SH(-Mobile)). > As the driver supports only a single block, it should be limited to > 64 on R-Car Gen2/3. R-Car Gen4 claims to have widened the register > bit field for the maximum transfer size per block, so 256 might be > possible there... Got it. > >>>> Anyway, even if there are such imbalanced architectures, I guess we can >>>> consider them when/if they appear? (add rx/tx-fifo-depth dt properties) >>> >>> I think so. >>> >>>> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: >>>> Override the default TX fifo size. Unit is words. Ignored if 0. >>>> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: >>>> renesas,rx-fifo-size: >>>> Documentation/devicetree/bindings/spi/renesas,sh-msiof.yaml: >>>> Override the default RX fifo size. Unit is words. Ignored if 0. >>> >>> These renesas ones seemed interesting at first glance due to these >>> comments, but what's missed by grep the is "deprecated" marking on >>> these. They seem to have been replaced by soc-specific compatibles. >> >> In the driver the renesas,{rx,tx}-fifo-size properties still have the >> highest priority: >> >> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/tree/drivers/spi/spi-sh-msiof.c#n1350 >> >> Maybe something for Geert, as I see he was the one marking these >> properties as deprecated. I guess he forgot to update the driver. >> >> Anyway, I think we shall be fine, even if we don't hear from Geert. > > The renesas,{rx,tx}-fifo-size properties date back to the early days > of DT an ARM, when it was assumed that slightly different versions of > IP cores could be handled well using a single common compatible value, > and properties describing the (few) differences. The pitfall here > is the "few differences": too many times people discovered later that > there were more differences, needing more properties, and complicating > backwards-compatibility. > > Hence the handling of different FIFO sizes was moved to the driver based > on compatible values, and the renesas,{rx,tx}-fifo-size properties were > deprecated. See commit beb74bb0875579c4 ("spi: sh-msiof: Add support > for R-Car H2 and M2"), which shows that there were more changes > needed than the anticipated FIFO sizes. And more were added later, > see later additions to sh_msiof_chipdata. > > So unless it is meant for a configurable synthesizable IP core, where > this is a documented parameter of the IP core, I advise against > specifying the FIFO size(s) in DT. > I guess I get it now. You marked those properties as deprecated so that users stop using them and rely on the driver based compatible values, but at the same time you allowed the devicetree properties to have a higher priority than the driver based compatible values in case one really wants/needs to use the dt properties. I don't have a preference here, I guess it's fine. Thanks for the explanations! ta
diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 524f6fe8c27b..99272e6f115e 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -69,6 +69,11 @@ properties: Should be generally avoided and be replaced by spi-cs-high + ACTIVE_HIGH. + fifo-depth: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Size of the data FIFO in bytes. + num-cs: $ref: /schemas/types.yaml#/definitions/uint32 description: