[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251204142845.GA1303976-robh@kernel.org>
Date: Thu, 4 Dec 2025 08:28:45 -0600
From: Rob Herring <robh@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: Mark Brown <broonie@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
Marcelo Schmitt <marcelo.schmitt@...log.com>,
Michael Hennerich <michael.hennerich@...log.com>,
Nuno Sá <nuno.sa@...log.com>,
Jonathan Cameron <jic23@...nel.org>,
Andy Shevchenko <andy@...nel.org>,
Sean Anderson <sean.anderson@...ux.dev>, linux-spi@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-iio@...r.kernel.org
Subject: Re: [PATCH v2 5/6] dt-bindings: iio: adc: adi,ad7380: add spi-buses
property
On Wed, Nov 19, 2025 at 08:45:42AM -0600, David Lechner wrote:
> On 11/19/25 7:18 AM, Rob Herring wrote:
> > On Tue, Nov 18, 2025 at 11:46 AM David Lechner <dlechner@...libre.com> wrote:
> >>
> >> On 11/18/25 9:59 AM, Rob Herring wrote:
> >>> On Fri, Nov 07, 2025 at 02:52:51PM -0600, David Lechner wrote:
> >>>> Add spi-buses property to describe how many SDO lines are wired up on
> >>>> the ADC. These chips are simultaneous sampling ADCs and have one SDO
> >>>> line per channel, either 2 or 4 total depending on the part number.
> >>>>
> >>>> Signed-off-by: David Lechner <dlechner@...libre.com>
> >>>> ---
> >>>> .../devicetree/bindings/iio/adc/adi,ad7380.yaml | 22 ++++++++++++++++++++++
> >>>> 1 file changed, 22 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
> >>>> index b91bfb16ed6bc6c605880f81050250d1ed9c307a..9ef46cdb047d45d088e0fbc345f58c5b09083385 100644
> >>>> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
> >>>> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7380.yaml
> >>>> @@ -62,6 +62,10 @@ properties:
> >>>> spi-cpol: true
> >>>> spi-cpha: true
> >>>>
> >>>> + spi-data-buses:
> >>>> + minItems: 1
> >>>> + maxItems: 4
> >>>> +
> >>>
> >>> As the property is not required, what's the default?
> >>
> >> spi-perepheral-props.yaml defines:
> >>
> >> default: [0]
> >>
> >> Do I need to repeat that here?
> >
> > No. So that means you only use one channel and the others are not connected?
>
> Correct.
>
> >
> >>
> >>>
> >>>> vcc-supply:
> >>>> description: A 3V to 3.6V supply that powers the chip.
> >>>>
> >>>> @@ -245,6 +249,22 @@ allOf:
> >>>> patternProperties:
> >>>> "^channel@[0-3]$": false
> >>>>
> >>>> + # 2-channel chip can only have up to 2 buses
> >>>> + - if:
> >>>> + properties:
> >>>> + compatible:
> >>>> + enum:
> >>>> + - adi,ad7380
> >>>> + - adi,ad7381
> >>>> + - adi,ad7386
> >>>> + - adi,ad7387
> >>>> + - adi,ad7388
> >>>> + - adi,ad7389
> >>>> + then:
> >>>> + properties:
> >>>> + spi-data-buses:
> >>>> + maxItems: 2
> >>>> +
> >>>> examples:
> >>>> - |
> >>>> #include <dt-bindings/interrupt-controller/irq.h>
> >>>> @@ -260,6 +280,7 @@ examples:
> >>>> spi-cpol;
> >>>> spi-cpha;
> >>>> spi-max-frequency = <80000000>;
> >>>> + spi-data-buses = <0>, <1>;
> >>>>
> >>>> interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
> >>>> interrupt-parent = <&gpio0>;
> >>>> @@ -284,6 +305,7 @@ examples:
> >>>> spi-cpol;
> >>>> spi-cpha;
> >>>> spi-max-frequency = <80000000>;
> >>>> + spi-data-buses = <0>, <1>, <2>, <3>;
> >>>
> >>> An example that doesn't look like a 1 to 1 mapping would be better.
> >>> Otherwise, it still looks to me like you could just define the bus
> >>> width.
> >>
> >> I'm not sure we could do that on this chip since it doesn't have
> >> the possibility of more than one line per channel.
> >
> > That's a property of the SPI controller though, right?
> >
> > If the above controller had 4 lines per channel/serializer, then you could have:
> >
> > spi-data-buses = <0>, <4>, <8>, <12>;
>
> Ah, I get what you mean now. The intention here though was that the
> index numbers correspond to the data lane (channel/serializer), not
> to individual lines. So the example you gave would mean that the chip
> has at least 13 data lanes (rather than what I think your intention was
> of saying it has at least 16 data wires). I did it that way because all
> of the hardware I looked at didn't allow assigning arbitrary data lines
> to arbitrary lanes/channels so it keeps things simpler and easier to match
> to the actual hardware docs.
But what happens if there is such h/w? Better to design things for
something we can visualize and not have to revisit this. Of course there
will be things we don't anticipate. (Who thought we'd have parallel
SPI...)
I suppose if that's rare enough we can just have another property to map
pins to channels.
Rob
Powered by blists - more mailing lists