[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250112114101.63e8e726@jic23-huawei>
Date: Sun, 12 Jan 2025 11:41:01 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: Julien Stephan <jstephan@...libre.com>
Cc: Lars-Peter Clausen <lars@...afoo.de>, Michael Hennerich
<Michael.Hennerich@...log.com>, Nuno Sá <nuno.sa@...log.com>,
David Lechner <dlechner@...libre.com>, Jonathan Corbet <corbet@....net>,
linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v3 4/5] iio: adc: ad7380: add alert support
On Tue, 07 Jan 2025 09:48:28 +0100
Julien Stephan <jstephan@...libre.com> wrote:
> The alert functionality is an out of range indicator and can be used as
> an early indicator of an out of bounds conversion result.
>
> ALERT_LOW_THRESHOLD and ALERT_HIGH_THRESHOLD registers are common to all
> channels.
>
> When using 1 SDO line (only mode supported by the driver right now), i.e
> data outputs only on SDOA, SDOB (or SDOD for 4 channels variants) is
> used as an alert pin. The alert pin is updated at the end of the
> conversion (set to low if an alert occurs) and is cleared on a falling
> edge of CS.
>
> The ALERT register contains information about the exact alert status:
> channel and direction. ALERT register can be accessed using debugfs if
> enabled.
>
> User can set high/low thresholds and enable alert detection using the
> regular iio events attributes:
>
> events/in_thresh_falling_value events/in_thresh_rising_value
> events/thresh_either_en
>
> In most use cases, user will hardwire the alert pin to trigger a shutdown.
>
> In theory, we could generate userspace IIO events for alerts, but this
> is not implemented yet for several reasons [1]. This can be implemented
> later if a real use case actually requires it.
>
> Signed-off-by: Julien Stephan <jstephan@...libre.com>
>
> [1] https://lore.kernel.org/all/4be16272-5197-4fa1-918c-c4cdfcaee02e@baylibre.com/
Hmm. This does end up odd in that userspace is configuring event
related stuff and not getting an event.
If we can fix that later I'd like to do so, but we can move forwards
with this odd bit of ABI in the meantime. Even then we'd need to support
the case where it's not wired to the host but is really controlling
an external cut off.
I've got nothing else to add to David's review.
Jonathan
Powered by blists - more mailing lists