From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: William Breathitt Gray <vilhelm.gray@gmail.com>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>,
<linux-arm-kernel@lists.infradead.org>,
<kamel.bouhara@bootlin.com>, <gwendal@chromium.org>,
<a.fatoum@pengutronix.de>, <david@lechnology.com>,
<linux-iio@vger.kernel.org>, <patrick.havelange@essensium.com>,
<linux-stm32@st-md-mailman.stormreply.com>,
<alexandre.belloni@bootlin.com>, <linux-kernel@vger.kernel.org>,
Dan Carpenter <dan.carpenter@oracle.com>,
<mcoquelin.stm32@gmail.com>, David Jander <david@protonic.nl>,
<fabrice.gasnier@st.com>, <syednwaris@gmail.com>,
<kernel@pengutronix.de>, <jic23@kernel.org>,
<alexandre.torgue@st.com>
Subject: Re: [PATCH v6 3/5] counter: Add character device interface
Date: Thu, 21 Jan 2021 18:26:58 +0000 [thread overview]
Message-ID: <20210121182658.00000d95@Huawei.com> (raw)
In-Reply-To: <YAk1PzXYQaJvhGSj@shinobu>
On Thu, 21 Jan 2021 17:03:11 +0900
William Breathitt Gray <vilhelm.gray@gmail.com> wrote:
> On Tue, Jan 19, 2021 at 10:20:22AM +0100, Oleksij Rempel wrote:
> > On Sun, Nov 22, 2020 at 03:29:54PM -0500, William Breathitt Gray wrote:
> > > This patch introduces a character device interface for the Counter
> > > subsystem. Device data is exposed through standard character device read
> > > operations. Device data is gathered when a Counter event is pushed by
> > > the respective Counter device driver. Configuration is handled via ioctl
> > > operations on the respective Counter character device node.
> > >
> > > Cc: David Lechner <david@lechnology.com>
> > > Cc: Gwendal Grignou <gwendal@chromium.org>
> > > Cc: Dan Carpenter <dan.carpenter@oracle.com>
> > > Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
> > > ---
> >
> > Hello William,
> >
> > the series looks quite interesting, we have some thoughts... see below:
> >
> > [...]
> > > +/**
> > > + * counter_push_event - queue event for userspace reading
> > > + * @counter: pointer to Counter structure
> > > + * @event: triggered event
> > > + * @channel: event channel
> > > + *
> > > + * Note: If no one is watching for the respective event, it is silently
> > > + * discarded.
> > > + *
> > > + * RETURNS:
> > > + * 0 on success, negative error number on failure.
> > > + */
> > > +int counter_push_event(struct counter_device *const counter, const u8 event,
> > > + const u8 channel)
> > > +{
> > > + struct counter_event ev = {0};
> > > + unsigned int copied = 0;
> > > + unsigned long flags;
> > > + struct counter_event_node *event_node;
> > > + struct counter_comp_node *comp_node;
> > > + int err = 0;
> > > +
> > > + ev.timestamp = ktime_get_ns();
> > > + ev.watch.event = event;
> > > + ev.watch.channel = channel;
> > > +
> > > + raw_spin_lock_irqsave(&counter->events_lock, flags);
> > > +
> > > + /* Search for event in the list */
> > > + list_for_each_entry(event_node, &counter->events_list, l)
> > > + if (event_node->event == event &&
> > > + event_node->channel == channel)
> > > + break;
> > > +
> > > + /* If event is not in the list */
> > > + if (&event_node->l == &counter->events_list)
> > > + goto exit_early;
> > > +
> > > + /* Read and queue relevant comp for userspace */
> > > + list_for_each_entry(comp_node, &event_node->comp_list, l) {
> > > + err = counter_get_data(counter, comp_node, &ev.value);
> > > + if (err)
> > > + goto exit_early;
> > > +
> > > + ev.watch.component = comp_node->component;
> > > +
> > > + copied += kfifo_put(&counter->events, ev);
> >
> > We want to calculate the frequency of some IRQ pulses in user space and
> > counter values with time stamps really fits well here. As the pulses are
> > from a physical system (rotating wheel), they will only change at a
> > certain rate. We want to have the possibility to read from the counter
> > device less often, we intentionally want to skip (meaning miss)
> > events.
> >
> > When reading we're interested in the newest events. The kfifo implements
> > a "tail" drop FIFO, which means new values are added at the end, and if
> > the FIFO is full, they are dropped. We need a "head" drop FIFO which
> > discards the oldest events, keeping only the recent ones.
> >
> > As far as we know, kfifo doesn't offer a head drop mode, but I think
> > this can be added.
>
> I'm not sure if kfifo has this kind of mode, but it seems like something
> that should be there if it is not already -- I imagine this kind of
> operation mode would be pretty common. Perhaps someone knows how to
> achieve this and will share here.
>
I don't think it does. In IIO we started with a ring (effectively this)
- hopefully no one else remembers the horrible mess I made of it ;),
but eventually decided that there were very few usecases that
actually demanded it so just switched over to kfifo.
It's actually pretty rare that you aren't better off draining to
a backing store of some type.
Not had any demand to bring a ring back to IIO since we dropped it.
> >
> > [...]
> >
> > > struct counter_device {
> > > const char *name;
> > > @@ -270,12 +270,20 @@ struct counter_device {
> > >
> > > int id;
> > > struct device dev;
> > > + struct cdev chrdev;
> > > + raw_spinlock_t events_lock;
> > > + struct list_head events_list;
> > > + struct list_head next_events_list;
> > > + DECLARE_KFIFO(events, struct counter_event, 64);
> >
> > Do you plan to make the size of the FIFO configurable?
> >
> > regards,
> > Oleksij & Marc
>
> I suppose it wouldn't be a problem to make this a configurable setting;
> I think I can implement this via kfifo_alloc() and kfifo_free(). How
> would users control this -- maybe using a sysfs attribute?
Would make sense to do it from sysfs.
Jonathan
>
> William Breathitt Gray
>
next prev parent reply other threads:[~2021-01-21 18:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-22 20:29 [PATCH v6 0/5] Introduce the Counter " William Breathitt Gray
2020-11-22 20:29 ` [PATCH v6 1/5] counter: Internalize sysfs interface code William Breathitt Gray
2020-11-25 13:07 ` William Breathitt Gray
2020-12-13 23:15 ` David Lechner
2020-12-20 22:11 ` William Breathitt Gray
2020-12-21 15:26 ` David Lechner
2020-11-22 20:29 ` [PATCH v6 2/5] docs: counter: Update to reflect sysfs internalization William Breathitt Gray
2020-11-22 20:29 ` [PATCH v6 3/5] counter: Add character device interface William Breathitt Gray
2020-12-13 23:58 ` David Lechner
2020-12-25 17:30 ` William Breathitt Gray
2021-01-19 9:20 ` Oleksij Rempel
2021-01-21 8:03 ` William Breathitt Gray
2021-01-21 18:26 ` Jonathan Cameron [this message]
2020-11-22 20:29 ` [PATCH v6 4/5] docs: counter: Document " William Breathitt Gray
2020-11-22 20:29 ` [PATCH v6 5/5] counter: 104-quad-8: Add IRQ support for the ACCES 104-QUAD-8 William Breathitt Gray
2020-12-13 23:15 ` [PATCH v6 0/5] Introduce the Counter character device interface David Lechner
2020-12-20 21:44 ` William Breathitt Gray
2020-12-21 15:19 ` David Lechner
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=20210121182658.00000d95@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=a.fatoum@pengutronix.de \
--cc=alexandre.belloni@bootlin.com \
--cc=alexandre.torgue@st.com \
--cc=dan.carpenter@oracle.com \
--cc=david@lechnology.com \
--cc=david@protonic.nl \
--cc=fabrice.gasnier@st.com \
--cc=gwendal@chromium.org \
--cc=jic23@kernel.org \
--cc=kamel.bouhara@bootlin.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=o.rempel@pengutronix.de \
--cc=patrick.havelange@essensium.com \
--cc=syednwaris@gmail.com \
--cc=vilhelm.gray@gmail.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
all inboxes | Powered by JetHome®