Received-SPF: pass (google.com: domain of linux-kernel+bounces-76781-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240216-ad7944-mainline-v2-0-7eb69651e592@baylibre.com>
 <20240216-ad7944-mainline-v2-1-7eb69651e592@baylibre.com> <20240221152226.GA2868707-robh@kernel.org>
 <CAMknhBFytGYNo8FviHepoxLApoGyo0mVhL2BzVmm1vt8-Evn9Q@mail.gmail.com>
In-Reply-To: <CAMknhBFytGYNo8FviHepoxLApoGyo0mVhL2BzVmm1vt8-Evn9Q@mail.gmail.com>
From: Rob Herring <robh@kernel.org>
Date: Thu, 22 Feb 2024 08:34:16 -0700
Message-ID: <CAL_Jsq+diFUEn=Tf99_FkXqLHuyLrZW_jaYoPjGhGjGbecgivg@mail.gmail.com>
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: adc: add ad7944 ADCs
To: David Lechner <dlechner@baylibre.com>
Cc: linux-iio@vger.kernel.org, 
	Michael Hennerich <Michael.Hennerich@analog.com>, Jonathan Cameron <jic23@kernel.org>, 
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, 
	=?UTF-8?B?TnVubyBTw6E=?= <nuno.sa@analog.com>, 
	Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, devicetree@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 21, 2024 at 8:44=E2=80=AFAM David Lechner <dlechner@baylibre.co=
m> wrote:
>
> On Wed, Feb 21, 2024 at 9:22=E2=80=AFAM Rob Herring <robh@kernel.org> wro=
te:
> >
> > On Fri, Feb 16, 2024 at 01:46:18PM -0600, David Lechner wrote:
>
> ...
>
> > > +  adi,spi-mode:
> > > +    $ref: /schemas/types.yaml#/definitions/string
> > > +    enum: [ single, multi, chain ]
> > > +    default: multi
> > > +    description: |
> > > +      * single: The datasheet calls this "3-wire mode". It is often =
used when
> > > +        the ADC is the only device on the bus. In this mode, SDI is =
tied to VIO,
> > > +        and the CNV line can be connected to the CS line of the SPI =
controller
> > > +        or to a GPIO, in which case the CS line of the controller is=
 unused.
> >
> > We have a standard property for this.
>
> As discussed in v1 [1], the datasheet's definition of "3-wire mode" is
> _not_ the same as the standard spi-3wire property. I can add that to
> the description here to clarify (I hoped changing the enum name was
> enough, but perhaps not). Or is there a different property you are
> referring to?
>
> [1]: https://lore.kernel.org/all/20240216140826.58b3318d@jic23-huawei/
>
> >
> > > +      * multi: The datasheet calls this "4-wire mode". This is the c=
onvential

Also, typo.

> > > +        SPI mode used when there are multiple devices on the same bu=
s. In this
> > > +        mode, the CNV line is used to initiate the conversion and th=
e SDI line
> > > +        is connected to CS on the SPI controller.
> >
> > That's "normal" mode.
>
> That was my first choice, but the datasheet uses the term "normal
> mode" to mean not TURBO mode which is something else unrelated to the
> SPI mode.

What I mean is this should be conveyed by the absence of any property.
You don't need a property for "normal SPI mode".

> >
> > > +      * chain: The datasheet calls this "chain mode". This mode is u=
sed to save
> > > +        on wiring when multiple ADCs are used. In this mode, the SDI=
 line of
> > > +        one chip is tied to the SDO of the next chip in the chain an=
d the SDI of
> > > +        the last chip in the chain is tied to GND. Only the first ch=
ip in the
> > > +        chain is connected to the SPI bus. The CNV line of all chips=
 are tied
> > > +        together. The CS line of the SPI controller is unused.
> >
> > Don't you need to know how many chips are chained? In any case, you jus=
t
> > need a property for chain mode. There's some existing properties for
> > chained devices I think. Standard logic shift register based GPIO IIRC.
>
> Thanks, I see #daisy-chained-devices now. I missed that before.
>
> >
> > CNV are tied together, but must be driven by something? I suppose
> > cnv-gpios?
>
> Yes.
>
> > But wouldn't that be the same as the SPI controller GPIO CS?
> > Does a SPI controller CS line connected to CNV not work in this case?
>
> Maybe technically possible if CS is inverted on the bus since the line
> has to be high to trigger the conversion and during the xfer.

That's supported by the binding. Seems like it would simplify the
driver if you went that route and better support other devices on the
SPI bus. Also, we require 'reg', so I don't know what you'd put in it
in the no CS case. Though, we probably already have that case with CS
tied active. Shrug.

Rob