From: David Lechner <dlechner@baylibre.com>
To: Jonathan Cameron <jic23@kernel.org>,
Marcelo Schmitt <marcelo.schmitt1@gmail.com>
Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>,
lars@metafoo.de, Michael.Hennerich@analog.com,
robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: adc: Add AD4000
Date: Sat, 13 Apr 2024 12:33:54 -0500 [thread overview]
Message-ID: <87058695-a1a6-4e68-87c5-accdb8451bf4@baylibre.com> (raw)
In-Reply-To: <20240413171409.4575fe6f@jic23-huawei>
On 4/13/24 11:14 AM, Jonathan Cameron wrote:
> On Tue, 9 Apr 2024 12:30:09 -0300
> Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
>
>> On 04/08, David Lechner wrote:
>>> On Mon, Apr 8, 2024 at 9:32 AM Marcelo Schmitt
>>> <marcelo.schmitt@analog.com> wrote:
>>>>
...
>>>> +
>>>> + adi,spi-mode:
>>>> + $ref: /schemas/types.yaml#/definitions/string
>>>> + enum: [ single, chain ]
>>>
>>> It sounds like there are more possible wiring configurations for these
>>> chips that I thought when suggesting reusing this binding from AD7944
>>> so we probably need more options here. (see my reply to the cover
>>> letter for the complete context of these remarks)
>>>
>>> We identified A) an additional wiring configuration where SDI of the
>>> ADC chip is wired to SDO of the SPI controller and B) a potential need
>>> to pin mux between wiring modes to work around SPI controller
>>> limitations perhaps we could omit the adi,spi-mode property and just
>>> use the standard pinctrl properties.
>>>
>>> pinctrl-names:
>
> I'm lost on how pinctrl makes sense here.
> Yes you are changing the modes of the pins, but not in a conventional sense
> of some register that is being updated to say now use them like this.
> The mode is dependent on the timing sequence of how the pins are used.
> Otherwise looking at it a different way it's an external wiring thing we
> aren't controlling it at all. Is pinctrl suitable for that?
> I always thought of it as a way to change configurations of SoC pins.
Yes, this is exactly what I think we need here.
To write to the register, the chip has to be wired like this ("default"):
+-------------+
+-----------------------------------| SDO |
| | |
| +--------------------| CS |
| v | |
| +--------------------+ | HOST |
| | CNV | | |
+--->| SDI AD7944 SDO |-------->| SDI |
| SCK | | |
+--------------------+ | |
^ | |
+--------------------| SCLK |
+-------------+
But to read sample data, the chip has to be wired in one of these
3 configurations:
3-wire mode ("single"):
+-------------+
+--------------------| CS |
v | |
VIO +--------------------+ | HOST |
| | CNV | | |
+--->| SDI AD7944 SDO |-------->| SDI |
| SCK | | |
+--------------------+ | |
^ | |
+--------------------| SCLK |
+-------------+
4-wire mode ("multi"):
+-------------+
+-----------------------------------| CS |
| | |
| +--------------------| GPIO |
| v | |
| +--------------------+ | HOST |
| | CNV | | |
+--->| SDI AD7944 SDO |-------->| SDI |
| SCK | | |
+--------------------+ | |
^ | |
+--------------------| SCLK |
+-------------+
Chain mode ("chain"):
+-------------+
+--------------------| CS |
v | |
+--------------------+ | HOST |
| CNV | | |
+--->| SDI AD7944 SDO |-------->| SDI |
| | SCK | | |
GND +--------------------+ | |
^ | |
+--------------------| SCLK |
+-------------+
If we want to be able to both write the register and read data,
some reconfiguration is needed. It might be possible to read data
using the register-write wiring configuration, but that only
works if SDO can be set to the correct state *before* the
CS line changes. This is not something that I think most SPI
controllers can do (e.g. Marcelo mentioned in the cover letter
that RPi always returns SDO to low after every xfer while
the AXI SPI Engine leaves SDO wherever it was last).
>
> A pointer to some precendence in another driver for using it like this
> would go some way towards convincing me.
>
> Jonathan
>
I didn't find much precedence for something like this, but I
found devicetree/bindings/net/mediatek-bluetooth.txt that uses
pinctrl to pull a UART Rx pin low for a bootstrap mode which
sounds very similar to what we need to do here (pull the SPI
controller SDO pin high or low for 3-wire or chain mode).
For example, if we wanted to use 3-wire mode for reading
data, we would set the pinctrl to "default" to write the
register to configure the chip during driver probe. Then
to read data, we would change the pinctrl to "single" before
doing the SPI xfer to ensure that the ADC SDI pin is pulled
high independent of what the SDO line of the SPI controller
is currently doing.
next prev parent reply other threads:[~2024-04-13 17:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 14:30 [PATCH v2 0/2] Add support for AD4000 series Marcelo Schmitt
2024-04-08 14:31 ` [PATCH v2 1/2] dt-bindings: iio: adc: Add AD4000 Marcelo Schmitt
2024-04-09 2:57 ` David Lechner
2024-04-09 15:30 ` Marcelo Schmitt
2024-04-13 16:14 ` Jonathan Cameron
2024-04-13 17:33 ` David Lechner [this message]
2024-04-14 18:09 ` Jonathan Cameron
2024-04-16 21:46 ` Marcelo Schmitt
2024-04-20 14:17 ` Jonathan Cameron
2024-04-21 22:38 ` Marcelo Schmitt
2024-04-08 14:31 ` [PATCH v2 2/2] iio: adc: Add support for AD4000 Marcelo Schmitt
2024-04-09 3:05 ` David Lechner
2024-04-09 16:09 ` Marcelo Schmitt
2024-04-09 16:44 ` David Lechner
2024-04-09 18:12 ` Marcelo Schmitt
2024-04-13 16:34 ` Jonathan Cameron
2024-04-13 16:19 ` Jonathan Cameron
2024-04-13 16:39 ` Jonathan Cameron
2024-04-09 2:54 ` [PATCH v2 0/2] Add support for AD4000 series David Lechner
2024-04-09 14:59 ` Marcelo Schmitt
2024-04-09 16:31 ` David Lechner
2024-04-13 16:07 ` Jonathan Cameron
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=87058695-a1a6-4e68-87c5-accdb8451bf4@baylibre.com \
--to=dlechner@baylibre.com \
--cc=Michael.Hennerich@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo.schmitt1@gmail.com \
--cc=marcelo.schmitt@analog.com \
--cc=robh+dt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.