From: Matti Vaittinen <mazziesaccount@gmail.com>
To: David Lechner <dlechner@baylibre.com>,
Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: "Lars-Peter Clausen" <lars@metafoo.de>,
"Michael Hennerich" <Michael.Hennerich@analog.com>,
"Jonathan Cameron" <jic23@kernel.org>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] dt-bindings: iio: adc: ad7476: Add ROHM bd79105
Date: Thu, 7 Aug 2025 10:14:07 +0300 [thread overview]
Message-ID: <cd85d510-b4f3-4e01-b1c2-de84204c5892@gmail.com> (raw)
In-Reply-To: <d37371a8-4a03-4893-a6bc-48b7f367c916@baylibre.com>
On 06/08/2025 18:15, David Lechner wrote:
> 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.
Ah. I had no idea. Thanks for the insight!
> 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.
After what you wrote above, I do agree. There may be systems where the
IRQ is usable, so dt should have it even if the Linux driver never used it.
> 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.
Oh. My thinking was just hard-coding the conversion-time delay, but this
can indeed make sense - especially if there are other examples :)
Thanks a lot for the insight!
Yours,
-- Matti
next prev parent reply other threads:[~2025-08-07 7:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-06 7:02 [PATCH 0/8] Support ROHM BD79105 ADC Matti Vaittinen
2025-08-06 7:02 ` [PATCH 1/8] iio: adc: ad7476: Simplify chip type detection Matti Vaittinen
2025-08-06 7:03 ` [PATCH 2/8] iio: adc: ad7476: Simplify scale handling Matti Vaittinen
2025-08-06 20:21 ` Andy Shevchenko
2025-08-07 5:43 ` Matti Vaittinen
2025-08-06 7:03 ` [PATCH 3/8] iio: adc: ad7476: Use mV for internal reference Matti Vaittinen
2025-08-06 7:03 ` [PATCH 4/8] iio: adc: ad7476: Use correct channel for bit info Matti Vaittinen
2025-08-06 15:04 ` Jonathan Cameron
2025-08-07 6:46 ` Matti Vaittinen
2025-08-06 7:04 ` [PATCH 5/8] iio: adc: ad7476: Conditionally call convstart Matti Vaittinen
2025-08-06 7:04 ` [PATCH 6/8] dt-bindings: iio: adc: ad7476: Add ROHM bd79105 Matti Vaittinen
2025-08-06 15:15 ` David Lechner
2025-08-07 7:14 ` Matti Vaittinen [this message]
2025-08-06 7:04 ` [PATCH 7/8] iio: adc: ad7476: Support ROHM BD79105 Matti Vaittinen
2025-08-06 15:23 ` David Lechner
2025-08-07 7:27 ` Matti Vaittinen
2025-08-06 20:26 ` Andy Shevchenko
2025-08-07 7:30 ` Matti Vaittinen
2025-08-07 21:08 ` Andy Shevchenko
2025-08-06 7:04 ` [PATCH 8/8] MAINTAINERS: A driver for simple 1-channel SPI ADCs Matti Vaittinen
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=cd85d510-b4f3-4e01-b1c2-de84204c5892@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=nuno.sa@analog.com \
--cc=robh@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.