From: Matti Vaittinen <mazziesaccount@gmail.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
Lee Jones <lee@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jonathan Cameron <jic23@kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Linus Walleij <linus.walleij@linaro.org>,
Nuno Sa <nuno.sa@analog.com>,
David Lechner <dlechner@baylibre.com>,
Dumitru Ceclan <mitrutzceclan@gmail.com>,
Trevor Gamblin <tgamblin@baylibre.com>,
Matteo Martelli <matteomartelli3@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-iio@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [RFC PATCH 3/5] iio: adc: Support ROHM BD79124 ADC
Date: Wed, 5 Feb 2025 15:58:18 +0200 [thread overview]
Message-ID: <8353a96d-fe39-45c2-b6da-e8083a6bdcd8@gmail.com> (raw)
In-Reply-To: <20250131174118.0000209a@huawei.com>
On 31/01/2025 19:41, Jonathan Cameron wrote:
> On Fri, 31 Jan 2025 15:37:48 +0200
> Matti Vaittinen <mazziesaccount@gmail.com> wrote:
>
>> The ROHM BD79124 is a 12-bit, 8-channel, SAR ADC. The ADC supports
>> an automatic measurement mode, with an alarm interrupt for out-of-window
>> measurements. The window is configurable for each channel.
>>
Hi Jonathan,
I just sent the v2, where I (think I) addressed all comments except ones
below. Just wanted to point out what was not changed and why :)
...
>
>> +struct bd79124_raw {
>> + u8 bit0_3; /* Is set in high bits of the byte */
>> + u8 bit4_11;
>> +};
>> +#define BD79124_RAW_TO_INT(r) ((r.bit4_11 << 4) | (r.bit0_3 >> 4))
> You could do this as an endian conversion and a single shift I think.
> Might be slightly simpler.
I kept this struct with bytes matching the register spec. Doing the
endian conversion and then shifting would probably have worked, but my
head hurts when I try thinking how the bits settle there. Especially if
this is done on a big-endian machine. I can rework this for v3 if you
feel very strongly about this.
...
>
>> +static irqreturn_t bd79124_event_handler(int irq, void *priv)
>> +{
>> + int ret, i_hi, i_lo, i;
>> + struct iio_dev *idev = priv;
>> + struct bd79124_data *d = iio_priv(idev);
>> +
>> + /*
>> + * Return IRQ_NONE if bailing-out without acking. This allows the IRQ
>> + * subsystem to disable the offending IRQ line if we get a hardware
>> + * problem. This behaviour has saved my poor bottom a few times in the
>> + * past as, instead of getting unusably unresponsive, the system has
>> + * spilled out the magic words "...nobody cared".
> *laughs*. Maybe the comment isn't strictly necessary but it cheered
> up my Friday.
>> + */
>> + ret = regmap_read(d->map, BD79124_REG_EVENT_FLAG_HI, &i_hi);
>> + if (ret)
>> + return IRQ_NONE;
>> +
>> + ret = regmap_read(d->map, BD79124_REG_EVENT_FLAG_LO, &i_lo);
>> + if (ret)
>> + return IRQ_NONE;
>> +
>> + if (!i_lo && !i_hi)
>> + return IRQ_NONE;
>> +
>> + for (i = 0; i < BD79124_MAX_NUM_CHANNELS; i++) {
>> + u64 ecode;
>> +
>> + if (BIT(i) & i_hi) {
> Maybe cleaner as a pair of
>
> for_each_set_bit() loops.
>
I kept the original for 2 reasons.
1. the main reason is that the for_each_set_bit() would want the value
read from a register to be in long. Regmap wants to use int. Solving
this produced (in my 'humblish' opinion) less readable code.
2. The current implementation has only one loop, which should perhaps be
a tiny bit more efficient.
>> + ecode = IIO_UNMOD_EVENT_CODE(IIO_VOLTAGE, i,
>> + IIO_EV_TYPE_THRESH, IIO_EV_DIR_RISING);
>> +
>> + iio_push_event(idev, ecode, d->timestamp);
>> + /*
>> + * The BD79124 keeps the IRQ asserted for as long as
>> + * the voltage exceeds the threshold. It may not serve
>> + * the purpose to keep the IRQ firing and events
>> + * generated in a loop because it may yield the
>> + * userspace to have some problems when event handling
>> + * there is slow.
>> + *
>> + * Thus, we disable the event for the channel. Userspace
>> + * needs to re-enable the event.
>
> That's not pretty. So I'd prefer a timeout and autoreenable if we can.
And I did this, but with constant 1 sec 'grace time' instead of
modifiable time-out. I believe this suffices and keeps it simpler.
Yours,
-- Matti
next prev parent reply other threads:[~2025-02-05 13:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 13:34 [RFC PATCH 0/5] Support ROHM BD79124 ADC/GPO Matti Vaittinen
2025-01-31 13:36 ` [RFC PATCH 1/5] dt-bindings: " Matti Vaittinen
2025-01-31 13:37 ` [RFC PATCH 2/5] mfd: Add " Matti Vaittinen
2025-01-31 17:14 ` Jonathan Cameron
2025-02-01 16:04 ` Matti Vaittinen
2025-02-05 13:40 ` Matti Vaittinen
2025-01-31 13:37 ` [RFC PATCH 3/5] iio: adc: Support ROHM BD79124 ADC Matti Vaittinen
2025-01-31 17:41 ` Jonathan Cameron
2025-02-01 15:38 ` Matti Vaittinen
2025-02-01 16:26 ` Jonathan Cameron
2025-02-05 13:58 ` Matti Vaittinen [this message]
2025-02-08 13:01 ` Jonathan Cameron
2025-01-31 13:38 ` [RFC PATCH 4/5] pinctrl: Support ROHM BD79124 pinmux / GPO Matti Vaittinen
2025-02-05 13:40 ` Matti Vaittinen
2025-02-06 9:39 ` Linus Walleij
2025-02-06 10:05 ` Matti Vaittinen
2025-02-06 10:09 ` Matti Vaittinen
2025-02-13 11:53 ` Linus Walleij
2025-02-13 12:10 ` Matti Vaittinen
2025-02-13 16:18 ` David Lechner
2025-01-31 13:38 ` [RFC PATCH 5/5] MAINTAINERS: Add ROHM BD79124 ADC/GPO Matti Vaittinen
2025-01-31 17:08 ` [RFC PATCH 0/5] Support " Jonathan Cameron
2025-02-01 15:00 ` Matti Vaittinen
2025-02-01 16:30 ` Jonathan Cameron
2025-02-01 17:12 ` 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=8353a96d-fe39-45c2-b6da-e8083a6bdcd8@gmail.com \
--to=mazziesaccount@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=angelogioacchino.delregno@collabora.com \
--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=lee@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matteomartelli3@gmail.com \
--cc=matti.vaittinen@fi.rohmeurope.com \
--cc=mitrutzceclan@gmail.com \
--cc=nuno.sa@analog.com \
--cc=robh@kernel.org \
--cc=tgamblin@baylibre.com \
/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;
as well as URLs for NNTP newsgroup(s).