From: David Lechner <dlechner@baylibre.com>
To: Marcelo Schmitt <marcelo.schmitt1@gmail.com>,
Rob Herring <robh@kernel.org>
Cc: "Mark Brown" <broonie@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Marcelo Schmitt" <marcelo.schmitt@analog.com>,
"Michael Hennerich" <michael.hennerich@analog.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"Andy Shevchenko" <andy@kernel.org>,
"Sean Anderson" <sean.anderson@linux.dev>,
linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH v3 7/7] dt-bindings: iio: adc: adi,ad4030: add data-lanes property
Date: Fri, 5 Dec 2025 15:33:49 -0600 [thread overview]
Message-ID: <0cf78f84-01e7-4507-abf9-2f82f98206b2@baylibre.com> (raw)
In-Reply-To: <aTNKyaWAEjVJixMI@debian-BULLSEYE-live-builder-AMD64>
On 12/5/25 3:12 PM, Marcelo Schmitt wrote:
> On 12/04, Rob Herring wrote:
>> On Mon, Dec 01, 2025 at 08:20:45PM -0600, David Lechner wrote:
>>> Add data-lanes property to specify the number of data lanes used on the
>>> ad463x chips that support reading two samples at the same time using
>>> two data lanes with a capable SPI controller.
>>>
>>> Signed-off-by: David Lechner <dlechner@baylibre.com>
>>> ---
>>> v3 changes: new patch
>>>
>>> I added this one to give a real-world use case where spi-rx-bus-width
>>> was not sufficient to fully describe the hardware configuration.
>>>
>>> spi-rx-bus-width = <4>; alone could be be interpreted as either:
>>>
>>> +--------------+ +----------+
>>> | SPI | | AD4630 |
>>> | Controller | | ADC |
>>> | | | |
>>> | SDIA0 |<---| SDOA0 |
>>> | SDIA1 |<---| SDOA1 |
>>> | SDIA2 |<---| SDOA2 |
>>> | SDIA3 |<---| SDOA3 |
>>> | | | |
>>> | SDIB0 |x | SDOB0 |
>>> | SDIB1 |x | SDOB1 |
>>> | SDIB2 |x | SDOB2 |
>>> | SDIB3 |x | SDOB3 |
>>> | | | |
>>> +--------------+ +---------+
>>>
>>> or
>>>
>>> +--------------+ +----------+
>>> | SPI | | AD4630 |
>>> | Controller | | ADC |
>>> | | | |
>>> | SDIA0 |<---| SDOA0 |
>>> | SDIA1 |<---| SDOA1 |
>>> | SDIA2 |x | SDOA2 |
>>> | SDIA3 |x | SDOA3 |
>>> | | | |
>>> | SDIB0 |<---| SDOB0 |
>>> | SDIB1 |<---| SDOB1 |
>>> | SDIB2 |x | SDOB2 |
>>> | SDIB3 |x | SDOB3 |
>>> | | | |
>>> +--------------+ +---------+
>>>
>>> Now, with data-lanes having a default value of [0] (inherited from
>>> spi-peripheral-props.yaml), specifying:
>>>
>>> spi-rx-bus-width = <4>;
>>>
>>> is unambiguously the first case and the example given in the binding
>>> documentation is the second case:
>>>
>>> spi-rx-bus-width = <2>;
>>> data-lanes = <0>, <1>;
>>
>> I just reviewed this and all, but what if you just did:
>>
>> spi-rx-bus-width = <2>, <2>;
>>
>> So *-bus-width becomes equal to the number of serializers/channels.
>
> Unless I'm missing something, I think that would also describe the currently
> possible use cases as well. To me, it actually seems even more accurate than
> data-lanes. The data-lanes property only describes the SPI controller input
> lines/lanes, no info is given about the output lanes.
It describes both directions.
> Well yeah, that would only> be a problem for a device with multiple input serializers and multiple output
> serializers. Still, the *-bus-width = <N>, <N>, ... <N>; notation looks clearer,
> IMHO.
>
>>
>> Rob
>>
It think it complicates Sean's use case though where such
a controller is being used as basically two separate SPI
buses.
For that case, we want to be able to do:
spi {
...
thing@0 {
compatible = ...;
reg = <0>;
/* (implicit) data-lanes = <0>; */
};
thing@1 {
compatible = ...;
reg = <1>;
data-lanes = <1>;
};
};
Meaning:
+--------------+ +----------+
| SPI | | Thing 1 |
| Controller | | |
| | | |
| CS0 |--->| CS |
| SDI0 |<---| SDO |
| SDO0 |--->| SDI |
| SCLK0 |--->| SCLK |
| | | |
| | +----------+
| |
| | +----------+
| | | Thing 2 |
| | | |
| CS1 |--->| CS |
| SDI1 |<---| SDO |
| SDO1 |--->| SDI |
| SCLK1 |--->| SCLK |
| | | |
+--------------+ +----------+
(I don't remember if SCLKs are shared or separate, but I don't
think that is relevant anyway).
I guess we could write it like this?
spi {
...
thing@0 {
compatible = ...;
reg = <0>;
};
thing@1 {
compatible = ...;
reg = <1>;
spi-tx-bus-width = <0>, <1>;
spi-rx-bus-width = <0>, <1>;
};
};
next prev parent reply other threads:[~2025-12-05 21:33 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 2:20 [PATCH v3 0/7] spi: add multi-lane support David Lechner
2025-12-02 2:20 ` [PATCH v3 1/7] spi: dt-bindings: Add data-lanes property David Lechner
2025-12-04 21:29 ` Rob Herring (Arm)
2025-12-02 2:20 ` [PATCH v3 2/7] spi: Support controllers with multiple data lanes David Lechner
2025-12-02 14:44 ` Andy Shevchenko
2025-12-02 14:47 ` David Lechner
2025-12-02 2:20 ` [PATCH v3 3/7] spi: add multi_lane_mode field to struct spi_transfer David Lechner
2025-12-02 14:48 ` Andy Shevchenko
2025-12-02 2:20 ` [PATCH v3 4/7] spi: axi-spi-engine: support SPI_MULTI_LANE_MODE_STRIPE David Lechner
2025-12-02 14:53 ` Andy Shevchenko
2025-12-02 16:36 ` Mark Brown
2025-12-10 0:02 ` David Lechner
2025-12-10 10:59 ` Andy Shevchenko
2025-12-02 2:20 ` [PATCH v3 5/7] dt-bindings: iio: adc: adi,ad7380: add spi-lanes property David Lechner
2025-12-04 21:29 ` Rob Herring (Arm)
2025-12-02 2:20 ` [PATCH v3 6/7] iio: adc: ad7380: Add support for multiple SPI lanes David Lechner
2025-12-02 2:20 ` [PATCH v3 7/7] dt-bindings: iio: adc: adi,ad4030: add data-lanes property David Lechner
2025-12-04 21:33 ` Rob Herring
2025-12-05 21:12 ` Marcelo Schmitt
2025-12-05 21:33 ` David Lechner [this message]
2025-12-05 23:43 ` David Lechner
2025-12-06 0:47 ` Rob Herring
2025-12-08 16:14 ` David Lechner
2025-12-08 18:32 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0cf78f84-01e7-4507-abf9-2f82f98206b2@baylibre.com \
--to=dlechner@baylibre.com \
--cc=andy@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=marcelo.schmitt@analog.com \
--cc=michael.hennerich@analog.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=sean.anderson@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox