From: Gyeyoung Baek <gye976@gmail.com>
To: "Jonathan Cameron" <jic23@kernel.org>,
"David Lechner" <dlechner@baylibre.com>,
"Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>
Cc: Gyeyoung Baek <gye976@gmail.com>,
linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH RFC 6/9] iio: trigger: Define timetamp-related structures and constants
Date: Mon, 19 May 2025 23:25:58 +0900 [thread overview]
Message-ID: <20250519-timestamp-v1-6-fcb4f6c2721c@gmail.com> (raw)
In-Reply-To: <20250519-timestamp-v1-0-fcb4f6c2721c@gmail.com>
The `trig_type` indicates whether the trigger calls poll() or poll_nested().
The `early_timestamp` indicates whether the trigger grabs the timestamp at the trigger.
We need this to prevent the consumer from overwriting the timestamp.
To allow the trigger to directly write the timestamp into the consumer's poll_func,
add poll_func pointer member to the iio_trigger structure.
However, I'm not sure if having a poll_func pointer member
in iio_trigger is a good approach.
Would this approach be acceptable?
Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
---
include/linux/iio/trigger.h | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/include/linux/iio/trigger.h b/include/linux/iio/trigger.h
index bce3b1788199..f3b89a1e0318 100644
--- a/include/linux/iio/trigger.h
+++ b/include/linux/iio/trigger.h
@@ -36,6 +36,10 @@ struct iio_trigger_ops {
struct iio_dev *indio_dev);
};
+#define IIO_TRIG_TYPE_POLL BIT(0)
+#define IIO_TRIG_TYPE_POLL_NESTED BIT(1)
+#define IIO_TRIG_TYPE_BOTH (IIO_TRIG_TYPE_POLL | \
+ IIO_TRIG_TYPE_POLL_NESTED)
/**
* struct iio_trigger - industrial I/O trigger device
@@ -56,7 +60,10 @@ struct iio_trigger_ops {
* i.e. if we registered a poll function to the same
* device as the one providing the trigger.
* @reenable_work: [INTERN] work item used to ensure reenable can sleep.
+ * @trig_type: [DRIVER] specifies whether the trigger calls poll(), poll_nested(), or both.
+ * @early_timestamp: [DRIVER] set to true if the trigger supports grabbing timestamp.
**/
+
struct iio_trigger {
const struct iio_trigger_ops *ops;
struct module *owner;
@@ -76,8 +83,13 @@ struct iio_trigger {
struct mutex pool_lock;
bool attached_own_device;
struct work_struct reenable_work;
-};
+ /* RFC, exists to access the consumer device’s pollfunc. */
+ struct iio_poll_func *consumer_pf[CONFIG_IIO_CONSUMERS_PER_TRIGGER];
+
+ int trig_type;
+ bool early_timestamp;
+};
static inline struct iio_trigger *to_iio_trigger(struct device *d)
{
--
2.43.0
next prev parent reply other threads:[~2025-05-19 14:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 14:25 [PATCH RFC 0/9] iio: Introduce new timestamp grabbing APIs Gyeyoung Baek
2025-05-19 14:25 ` [PATCH RFC 1/9] iio: buffer: Fix checkpatch.pl warning Gyeyoung Baek
2025-05-25 17:35 ` Jonathan Cameron
2025-05-26 5:30 ` Gyeyoung Baek
2025-05-26 17:15 ` Jonathan Cameron
2025-05-19 14:25 ` [PATCH RFC 2/9] iio: consumer: Define timestamp-related structures and constants Gyeyoung Baek
2025-05-31 18:01 ` Jonathan Cameron
2025-05-19 14:25 ` [PATCH RFC 3/9] iio: consumer: Add new APIs of triggered_buffer_setup() family Gyeyoung Baek
2025-05-31 18:16 ` Jonathan Cameron
2025-05-19 14:25 ` [PATCH RFC 4/9] iio: consumer: Add new API iio_poll_func_register() Gyeyoung Baek
2025-05-19 14:25 ` [PATCH RFC 5/9] iio: consumer: Add new API iio_pollfunc_get_timestamp() Gyeyoung Baek
2025-05-19 14:25 ` Gyeyoung Baek [this message]
2025-05-31 18:09 ` [PATCH RFC 6/9] iio: trigger: Define timetamp-related structures and constants Jonathan Cameron
2025-05-19 14:25 ` [PATCH RFC 7/9] iio: trigger: Add new API iio_trigger_attach_timestamp() Gyeyoung Baek
2025-05-19 14:26 ` [PATCH RFC 8/9] iio: trigger: Add new API iio_trigger_store_time() Gyeyoung Baek
2025-05-19 14:26 ` [PATCH RFC 9/9] iio: rpr0521: Use new timestamp-related APIs Gyeyoung Baek
2025-05-31 18:14 ` Jonathan Cameron
2025-06-06 10:20 ` Gyeyoung Baek
2025-05-19 15:28 ` [PATCH RFC 0/9] iio: Introduce new timestamp grabbing APIs David Lechner
2025-05-19 18:24 ` Gyeyoung Baek
2025-05-31 18:10 ` Jonathan Cameron
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=20250519-timestamp-v1-6-fcb4f6c2721c@gmail.com \
--to=gye976@gmail.com \
--cc=andy@kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.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).