All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@iki.fi>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com
Subject: Re: [RFCv1 PATCH 0/8] Allocate events per-event-type, v4l2-ctrls cleanup
Date: Wed, 15 Jun 2011 20:24:44 +0300	[thread overview]
Message-ID: <4DF8EADC.5060209@iki.fi> (raw)
In-Reply-To: <1308064953-11156-1-git-send-email-hverkuil@xs4all.nl>

Hans Verkuil wrote:
> This patch series consists of two parts: the first four patches change the
> way events are allocated and what to do when the event queue is full.
>
> These first four patches are the most important ones to review. The big
> change is that event allocation now happens when subscribing an event.
> So you not only specify which event you want to subscribe to for a particular
> filehandle, but also how many events should be reserved for that event type.
> Currently the driver specifies the number of events to allocate, but later
> this can be something that the application might want to set manually.
>
> This ensures that for each event type you will never entirely miss all events
> of a particular type. Currently this is a real possibility.
>
> The other change is that instead of dropping the new event if there is no more
> space available, the oldest event is dropped. This ensures that you get at
> least the latest state. And optionally a merge function can be provided that
> merges information of two events into one. This allows the control event to
> require just one event: if a new event is raised, then the new and old one
> can be merged and all state is preserved. Only the intermediate steps are
> no longer available. This makes for very good behavior of events and is IMHO
> a requirement for using the control event in a real production environment.
>
> The second four patches reorganize the way extended controls are processed
> in the control framework. This is the first step towards allowing control
> changes from within interrupt handlers. The main purpose is to move as much
> code as possible out of the critical sections. This reduces the size of
> those sections, making it easier to eventually switch to spinlocks for
> certain kinds of controls.
>
> It's lots of internal churn, so it's probably not easy to review. There are
> no real functional changes, however.

I have no further comments. Thus,

Acked-by: Sakari Ailus <sakari.ailus@iki.fi>

-- 
Sakari Ailus
sakari.ailus@iki.fi

      parent reply	other threads:[~2011-06-15 17:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-14 15:22 [RFCv1 PATCH 0/8] Allocate events per-event-type, v4l2-ctrls cleanup Hans Verkuil
2011-06-14 15:22 ` [RFCv1 PATCH 1/8] v4l2-events/fh: merge v4l2_events into v4l2_fh Hans Verkuil
2011-06-14 15:22   ` [RFCv1 PATCH 2/8] v4l2-ctrls/event: remove struct v4l2_ctrl_fh, instead use v4l2_subscribed_event Hans Verkuil
2011-06-20 13:50     ` Laurent Pinchart
2011-06-14 15:22   ` [RFCv1 PATCH 3/8] v4l2-event/ctrls/fh: allocate events per fh and per type instead of just per-fh Hans Verkuil
2011-06-14 15:22   ` [RFCv1 PATCH 4/8] v4l2-event: add optional 'merge' callback to merge two events Hans Verkuil
2011-06-20 14:09     ` Laurent Pinchart
2011-06-20 14:11       ` Hans Verkuil
2011-06-14 15:22   ` [RFCv1 PATCH 5/8] v4l2-ctrls: don't initially set CH_VALUE for write-only controls Hans Verkuil
2011-06-14 15:22   ` [RFCv1 PATCH 6/8] v4l2-ctrls: improve discovery of controls of the same cluster Hans Verkuil
2011-06-14 15:22   ` [RFCv1 PATCH 7/8] v4l2-ctrls: split try_or_set_ext_ctrls() Hans Verkuil
2011-06-14 15:22   ` [RFCv1 PATCH 8/8] v4l2-ctrls: v4l2_ctrl_handler_setup code simplification Hans Verkuil
2011-06-15  9:30   ` [RFCv1 PATCH 1/8] v4l2-events/fh: merge v4l2_events into v4l2_fh Sakari Ailus
2011-06-15 16:39     ` Hans Verkuil
2011-06-15 16:59       ` Sakari Ailus
2011-06-15 17:10         ` Hans Verkuil
2011-06-15 17:24 ` Sakari Ailus [this message]

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=4DF8EADC.5060209@iki.fi \
    --to=sakari.ailus@iki.fi \
    --cc=hverkuil@xs4all.nl \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.