Hans Verkuil wrote:
> Hi Sakari,
Hi, Hans!
> The code looks good, but I'm not so sure about the use of kmem_cache_*. It
> seems serious overkill to me.
>
> Most of the time there will only be a handful of event messages pending. So
> setting up a kmem_cache for this seems unnecessary to me.
>
>
Hi Sakari,
The code looks good, but I'm not so sure about the use of kmem_cache_*. It
seems serious overkill to me.
Most of the time there will only be a handful of event messages pending. So
setting up a kmem_cache for this seems unnecessary to me.
A much better way to ensure fast event report
Hi Andy,
Andy Walls wrote:
+int v4l2_event_pending(struct v4l2_fh *fh)
+{
+ struct v4l2_events *events =&fh->events;
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(&events->lock, flags);
+ ret = !list_empty(&events->available);
+ spin_unlock_irqrestor
On Tue, 2009-12-22 at 18:43 +0200, Sakari Ailus wrote:
> Add event handling backend to V4L2. The backend handles event subscription
> and delivery to file handles. Event subscriptions are based on file handle.
> Events may be delivered to all subscribed file handles on a device
> independent of whe
Add event handling backend to V4L2. The backend handles event subscription
and delivery to file handles. Event subscriptions are based on file handle.
Events may be delivered to all subscribed file handles on a device
independent of where they originate from.
Signed-off-by: Sakari Ailus
---
driv
