[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d37371a8-4a03-4893-a6bc-48b7f367c916@baylibre.com>
Date: Wed, 6 Aug 2025 10:15:09 -0500
From: David Lechner <dlechner@...libre.com>
To: Matti Vaittinen <mazziesaccount@...il.com>,
Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Jonathan Cameron <jic23@...nel.org>, Nuno Sá
<nuno.sa@...log.com>, Andy Shevchenko <andy@...nel.org>,
Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/8] dt-bindings: iio: adc: ad7476: Add ROHM bd79105
On 8/6/25 2:04 AM, Matti Vaittinen wrote:
> The ROHM BD79105 is a simple, 16-bit, 1-channel ADC with a 'CONVSTART'
> pin used to start the ADC conversion. Other than the 'CONVSTART', there
> are 3 supply pins (one used as a reference), analog inputs, ground and
> communication pins. It's worth noting that the pin somewhat confusingly
> labeled as 'DIN', is a pin which should be used as a chip-select. The IC
> does not have any writable registers.
>
> The device is designed so that the output pin can, in addition to
> outputting the data, be used as a 'data-ready'-IRQ. This, however, would
> require the IRQ to be masked from host side for the duration of the data
> reads - and it wouldn't also work when the SPI is shared. (As access to
> the other SPI devices would cause data line changes to be detected as
> IRQs - and the BD79105 provides no means to detect if it has generated
> an IRQ).
>
> Hence the device-tree does not contain any IRQ properties.
There are lots of other ADC chips that have a ready signal like this
and we've made them work. Since devicetree bindings should be as
complete as possible even if the driver doesn't use all of the
features, I think we should be including the interrupt in the binding.
We have also found that some interrupt controllers won't work
as you have suggested and in that case we also needed a ready-gpios
to be able to read the state of the pin.
Powered by blists - more mailing lists