From: David Lechner <dlechner@baylibre.com>
To: Jorge Marques <gastmaier@gmail.com>, Jonathan Cameron <jic23@kernel.org>
Cc: "Jorge Marques" <jorge.marques@analog.com>,
"Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Uwe Kleine-König" <ukleinek@kernel.org>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-pwm@vger.kernel.org
Subject: Re: [PATCH v3 2/8] dt-bindings: iio: adc: Add adi,ad4052
Date: Thu, 12 Jun 2025 10:03:37 -0500 [thread overview]
Message-ID: <ef0d4038-b665-4ef0-9e7b-7ad2ce154c50@baylibre.com> (raw)
In-Reply-To: <xqkr3rq6ikuiz5wcbxmto4gp7wnccmmogklf2ux2edauotufim@pcuhddxdzjxi>
On 6/12/25 5:11 AM, Jorge Marques wrote:
> On Wed, Jun 11, 2025 at 06:18:18PM +0100, Jonathan Cameron wrote:
>> On Tue, 10 Jun 2025 09:34:35 +0200
>> Jorge Marques <jorge.marques@analog.com> wrote:
>>
...
>>> + trigger-sources:
>>> + minItems: 1
>>> + maxItems: 2
>>> + description:
>>> + Describes the output pin and event associated.
trigger-sources would be an input pin connected to an external trigger.
For example, the CNV pin could be connected to a trigger-source
provider to trigger a conversion. But there aren't any other digital
inputs, so I don't know what the 2nd source would be here.
As an example, see [1]. We could potentially use the same gpio
trigger-source for the conversion pin here. There is already
a similar binding for pwm triggers, so we could drop the separate
pwms binding as well an just have a single trigger-sources
property for the CNV pin that works for both gpio and pwm.
[1]: https://lore.kernel.org/linux-iio/cover.1749569957.git.Jonathan.Santos@analog.com/
>>> +
>>> + "#trigger-source-cells":
>>> + const: 2
>>> + description: |
>>> + Output pins used as trigger source.
>>> +
>>> + Cell 0 defines the event:
>>> + * 0 = Data ready
>>> + * 1 = Min threshold
>>> + * 2 = Max threshold
>>> + * 3 = Either threshold
>>> + * 4 = CHOP control
>>> + * 5 = Device enable
>>> + * 6 = Device ready (only GP1)
>>
>> Hmm. I'm a bit dubious on why 'what the offload trigger is'
>> is a DT thing? Is that because the IP needs to comprehend
>> this? I guess only data ready is actually supported in
>> practice?
>
> A trigger can be connected to trigger something other than a spi
> offload, it is in the DT because it describes how the device is
> connected. When using spi offload, the trigger-source at the spi handle
> describes which gpio and event is routed to the offload trigger input.
> At the ADC node, trigger-source-cells describe the source gpio and event
> for the device driver.
>
> In practice, in this series, one gpio is Data ready, triggering offload
> when buffer enabled, and raw reads, when disabled. And the other is
> Either threshold, propagated as an IIO event. Fancy logic can be added
> to the driver in future patches to allow other combinations.
>
> It is also worth to mention that the trigger-source is duplicated for
> each node that uses it, as seen in the second dts example:
>
> &adc AD4052_TRIGGER_EVENT_DATA_READY AD4052_TRIGGER_PIN_GP1
>
> Is repeated on both adc and spi node.
That sounds wrong. This would only make sense if an output of the
ADC was wired back to itself.
>
> One last thing, on the driver, for v3, I should handle -ENOENT:
>
> ret = of_parse_phandle_with_args(np, "trigger-sources",
> "#trigger-source-cells", i,
> &trigger_sources);
> if (ret)
> return ret == -ENOENT ? 0 : ret;
>
> To assert only when present, since the nodes are not required.
> Or, in the driver,
> require AD4052_TRIGGER_PIN_GP0 if irq_get_byname finds gp0, and
> require AD4052_TRIGGER_PIN_GP1 if irq_get_byname finds gp1?
> (I would go with the first option).
>>
,,,
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/gpio/gpio.h>
>>> + #include <dt-bindings/interrupt-controller/irq.h>
>>> + #include <dt-bindings/iio/adc/adi,ad4052.h>
>>> +
>>> + spi {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + adc@0 {
>>> + compatible = "adi,ad4052";
>>> + reg = <0>;
>>> + vdd-supply = <&vdd>;
>>> + vio-supply = <&vio>;
>>> + ref-supply = <&ref>;
>>> + spi-max-frequency = <83333333>;
>>> +
>>> + #trigger-source-cells = <2>;
>>> + trigger-sources = <&adc AD4052_TRIGGER_EVENT_EITHER_THRESH
>>> + AD4052_TRIGGER_PIN_GP0
>>> + &adc AD4052_TRIGGER_EVENT_DATA_READY
>>> + AD4052_TRIGGER_PIN_GP1>;
This doesn't make sense for the reason given above. These outputs
aren't wired back to inputs on the ADC. They are wired to interrupts
on the MCU, which is already described below.
>>> + interrupt-parent = <&gpio>;
>>> + interrupts = <0 0 IRQ_TYPE_EDGE_RISING>,
>>> + <0 1 IRQ_TYPE_EDGE_FALLING>;
>>> + interrupt-names = "gp0", "gp1";
>>> + cnv-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
>>> + };
>>> + };
>>> + - |
>>> + #include <dt-bindings/gpio/gpio.h>
>>> + #include <dt-bindings/interrupt-controller/irq.h>
>>> + #include <dt-bindings/iio/adc/adi,ad4052.h>
>>> +
>>> + rx_dma {
>>> + #dma-cells = <1>;
>>> + };
>>> +
>>> + spi {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + dmas = <&rx_dma 0>;
>>> + dma-names = "offload0-rx";
The dmas aren't related to the ADC, so can be left out of the example.
>>> + trigger-sources = <&adc AD4052_TRIGGER_EVENT_DATA_READY
>>> + AD4052_TRIGGER_PIN_GP1>;
>>> +
>>> + adc@0 {
>>> + compatible = "adi,ad4052";
>>> + reg = <0>;
>>> + vdd-supply = <&vdd>;
>>> + vio-supply = <&vio>;
>>> + spi-max-frequency = <83333333>;
>>> + pwms = <&adc_trigger 0 10000 0>;
>>> +
>>> + #trigger-source-cells = <2>;
>>> + trigger-sources = <&adc AD4052_TRIGGER_EVENT_EITHER_THRESH
>>> + AD4052_TRIGGER_PIN_GP0
>>> + &adc AD4052_TRIGGER_EVENT_DATA_READY
>>> + AD4052_TRIGGER_PIN_GP1>;
Same as above - the GP pins aren't wired back to the ADC itself.
>>> + interrupt-parent = <&gpio>;
>>> + interrupts = <0 0 IRQ_TYPE_EDGE_RISING>,
>>> + <0 1 IRQ_TYPE_EDGE_FALLING>;
>>> + interrupt-names = "gp0", "gp1";
>>> + cnv-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>;
>>> + };
>>> + };
next prev parent reply other threads:[~2025-06-12 15:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 7:34 [PATCH v3 0/8] Add support for AD4052 device family Jorge Marques
2025-06-10 7:34 ` [PATCH v3 1/8] Documentation: ABI: add oversampling frequency in sysfs-bus-iio Jorge Marques
2025-06-11 17:02 ` Jonathan Cameron
2025-06-12 10:10 ` Jorge Marques
2025-06-10 7:34 ` [PATCH v3 2/8] dt-bindings: iio: adc: Add adi,ad4052 Jorge Marques
2025-06-11 17:18 ` Jonathan Cameron
2025-06-12 10:11 ` Jorge Marques
2025-06-12 15:03 ` David Lechner [this message]
2025-06-12 19:42 ` Jorge Marques
2025-06-12 20:20 ` David Lechner
2025-06-13 11:17 ` Jorge Marques
2025-06-14 10:14 ` Jonathan Cameron
2025-06-10 7:34 ` [PATCH v3 3/8] docs: iio: New docs for ad4052 driver Jorge Marques
2025-06-10 7:34 ` [PATCH v3 4/8] iio: adc: Add support for ad4052 Jorge Marques
2025-06-14 10:08 ` Jonathan Cameron
2025-06-16 14:54 ` David Lechner
2025-06-21 16:08 ` Jonathan Cameron
2025-06-21 16:13 ` David Lechner
2025-06-22 14:28 ` Jonathan Cameron
2025-06-17 14:59 ` Uwe Kleine-König
2025-06-17 15:34 ` Jorge Marques
2025-06-18 17:55 ` Uwe Kleine-König
2025-06-10 7:34 ` [PATCH v3 5/8] docs: iio: ad4052: Add offload support documentation Jorge Marques
2025-06-10 7:34 ` [PATCH v3 6/8] iio: adc: Add offload support for ad4052 Jorge Marques
2025-06-14 10:20 ` Jonathan Cameron
2025-06-20 18:52 ` Jorge Marques
2025-06-21 16:16 ` Jonathan Cameron
2025-06-10 7:34 ` [PATCH v3 7/8] docs: iio: ad4052: Add event documentation Jorge Marques
2025-06-10 7:34 ` [PATCH v3 8/8] iio: adc: Add events support to ad4052 Jorge Marques
2025-06-12 19:38 ` David Lechner
2025-06-13 10:02 ` Jorge Marques
2025-06-13 16:03 ` David Lechner
2025-06-14 10:25 ` Jonathan Cameron
2025-06-14 10:40 ` Jonathan Cameron
2025-06-14 10:36 ` Jonathan Cameron
2025-06-16 13:54 ` Jorge Marques
2025-06-21 16:20 ` 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=ef0d4038-b665-4ef0-9e7b-7ad2ce154c50@baylibre.com \
--to=dlechner@baylibre.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=gastmaier@gmail.com \
--cc=jic23@kernel.org \
--cc=jorge.marques@analog.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=ukleinek@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®