[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a5729091-af6f-4549-8cda-ca2778346437@baylibre.com>
Date: Thu, 17 Apr 2025 10:11:40 -0500
From: David Lechner <dlechner@...libre.com>
To: 938b950b-4215-4358-a888-6f6c9aab48e8@...libre.com
Cc: Jonathan Santos <Jonathan.Santos@...log.com>, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-gpio@...r.kernel.org, lars@...afoo.de, Michael.Hennerich@...log.com,
marcelo.schmitt@...log.com, jic23@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, marcelo.schmitt1@...il.com,
linus.walleij@...aro.org, brgl@...ev.pl, lgirdwood@...il.com,
broonie@...nel.org
Subject: Re: [PATCH v5 02/14] dt-bindings: iio: adc: ad7768-1: add
trigger-sources property
On 4/16/25 7:08 PM, Jonathan Santos wrote:
> On 04/11, David Lechner wrote:
>> On 4/11/25 10:56 AM, Jonathan Santos wrote:
>>> In addition to GPIO synchronization, The AD7768-1 also supports
>>> synchronization over SPI, which use is recommended when the GPIO
>>> cannot provide a pulse synchronous with the base MCLK signal. It
>>> consists of looping back the SYNC_OUT to the SYNC_IN pin and send
>>> a command via SPI to trigger the synchronization.
>>>
>>> Introduce the 'trigger-sources' property to support SPI-based
>>> synchronization, along with additional optional entries for the SPI
>>> offload trigger and the START signal via GPIO3.
>>>
>>> While at it, add description to the interrupts property.
>>>
>>> Signed-off-by: Jonathan Santos <Jonathan.Santos@...log.com>
>>> ---
...
>>> + Supports up to three entries, each representing a different type of
>>> + trigger:
>>> +
>>> + - First entry specifies the device responsible for driving the
>>> + synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios.
>>> + This can be a `gpio-trigger` or another `ad7768-1` device. If the
>>> + device's own SYNC_OUT pin is internally connected to its SYNC_IN pin,
>>> + reference the device itself or omit this property.
>>> + - Second entry optionally defines a GPIO3 pin used as a START signal trigger.
>>> + - Third entry specifies a GPIO line to act as a trigger for SPI offload.
>>
>> SPI offload is part of the SPI controller, not the ADC chip, so doesn't
>> make sense to have that binding here. In that case, the ADC is the
>> trigger-source provider, not consumer.
>
> Right! Maybe a silly question, but this means we would have then two trigger-sources
> defined, one in the spi controller node and other in the adc node, right? like
> this:
>
> spi_controller: spi@...00000 {
> ...
> trigger-sources = <&offload_trigger_source>;
> ...
> adc0@ {
> ...
> trigger-sources = <&sync_trigger_source>;
> #trigger-source-cells = <1>;
> ...
> }
> }
Yes, this looks correct. And for the case of SYNC_OUT connected to SYNC_IN on
the ADC itself, we could omit trigger-sources = <&sync_trigger_source>;.
Powered by blists - more mailing lists