Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
Message-ID: <a1f60bf6-5fb6-4814-b3b5-799fb8ffb847@gmail.com>
Date:   Thu, 14 Dec 2023 19:03:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 1/2] dt-bindings: adc: add AD7173
To:     David Lechner <dlechner@baylibre.com>
Cc:     linus.walleij@linaro.org, brgl@bgdev.pl, andy@kernel.org,
        linux-gpio@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>,
        Jonathan Cameron <jic23@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Conor Dooley <conor+dt@kernel.org>,
        Michael Walle <michael@walle.cc>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>,
        ChiaEn Wu <chiaen_wu@richtek.com>,
        Niklas Schnelle <schnelle@linux.ibm.com>,
        =?UTF-8?Q?Leonard_G=C3=B6hrs?= <l.goehrs@pengutronix.de>,
        Mike Looijmans <mike.looijmans@topic.nl>,
        Haibo Chen <haibo.chen@nxp.com>,
        Hugo Villeneuve <hvilleneuve@dimonoff.com>,
        Ceclan Dumitru <dumitru.ceclan@analog.com>,
        linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20231212104451.22522-1-mitrutzceclan@gmail.com>
 <CAMknhBEfisaSbHhnnei=gT1HZvHNWHrJD3O2y4b_TikkH=v2Ag@mail.gmail.com>
 <e4a9dde7-dca6-4862-bfb3-a93b879c9a1f@gmail.com>
 <CAMknhBFQ56SwMvOni6UDqvaq8t0iydHcggiL0biUeLQ6OV1ONA@mail.gmail.com>
Content-Language: en-US
From:   Ceclan Dumitru <mitrutzceclan@gmail.com>
In-Reply-To: <CAMknhBFQ56SwMvOni6UDqvaq8t0iydHcggiL0biUeLQ6OV1ONA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 12/14/23 18:12, David Lechner wrote:
> On Thu, Dec 14, 2023 at 1:43 PM Ceclan Dumitru <mitrutzceclan@gmail.com> wrote:
>> On 12/12/23 17:09, David Lechner wrote:
>>> On Tue, Dec 12, 2023 at 11:45 AM Dumitru Ceclan <mitrutzceclan@gmail.com> wrote:

>> ...
>>
>>>> +  interrupts:
>>>> +    maxItems: 1
>>>
>>> Shouldn't this be 2? The datasheet says there is a "Data Output Ready"
>>> signal on the DOUT/RDY pin and an "Error Output" on the SYNC/ERROR
>>> pin. Although I could see how RDY could be considered part of the SPI
>>> bus. In any case, a description explaining what the interrupt is would
>>> be useful.
>>>
>>
>> I do not see how there could be 2 interrupts. DOUT/RDY is used as an
>> interrupt when waiting for a conversion to finalize.
>>
>> Sync and Error are sepparate pins, Sync(if enabled) works only as an
>> input that resets the modulator and the digital filter.
> 
> I only looked at the AD7172-2 datasheet and pin 15 is labeled
> SYNC/ERROR. Maybe they are separate pins on other chips?

Yep, sorry, missed that. All other supported models have them separate.

> 
>>
>> Error can be configured as input, output or ERROR output (OR between all
>> internal error sources).
>>
>> Would this be alright
>>   interrupts:
>>
>>     description: Conversion completion interrupt.
>>                  Pin is shared with SPI DOUT.
>>     maxItems: 1
> 
> Since ERROR is an output, I would expect it to be an interrupt. The
> RDY output, on the other hand, would be wired to a SPI controller with
> the SPI_READY feature (I use the Linux flag name here because I'm not
> aware of a corresponding devicetree flag). So I don't think the RDY
> signal would be an interrupt.
> 

Error does not have the purpose to be an interrupt. The only interrupt
used from this chip is the one from the DOUT/~RDY pin. Sure, it is wired
to the SPI controller, but when you can't also receive interrupts on
that very same CPU pin an issue arises. So that pin is also wired to
another GPIO with interrupt support.

This is the same way that ad4130.yaml is written for example (with the
exception that ad4130 supports configuring where the interrupt is routed).

In regards to SPI_READY _BITUL(7) /* slave pulls low to pause */: the
ad_sigma_delta framework (if it can be called that) is written to expect
a pin interrupt, not to use SPI_READY controller feature.