From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: linux-media@vger.kernel.org
Cc: hverkuil@xs4all.nl
Subject: [PATCH 0/6] Provide a serialisation mechanism for subdev ops
Date: Mon, 19 Aug 2019 15:47:22 +0300 [thread overview]
Message-ID: <20190819124728.10511-1-sakari.ailus@linux.intel.com> (raw)
Hi folks,
While access to the V4L2 device nodes was conveniently serialised for
devices the drivers of which used the V4L2 framework, this was no the case
for sub-devices that also may be called from other drivers.
Instead acquire the lock to the v4l2_subdev_call macro.
This set adds the capability to the framework and makes smiapp use it.
This is a big change. I'm still not posting this as RFC as the feature is
entirely optional. Albeit I'd expect new drivers to use it in the future:
quite a bit of code was removed from the smiapp driver as a result (there
were other cleanups, too).
Generally drivers that handle multiple sub-devices need to take special
care when making nested calls (hopefully as few as possible, but starting
streaming comes to mind). We may need an unlocked variant of the macro as
well.
Sakari Ailus (6):
v4l: subdev: Set sd->devnode before registering the subdev
v4l: subdev: Provide a locking scheme for subdev operations
smiapp: Error handling cleanups and fixes
smiapp: Rely on V4L2 sub-device framework to do the locking
smiapp: Remove the active field from sensor's struct
smiapp: Avoid fall-through in switch
drivers/media/i2c/smiapp/smiapp-core.c | 203 ++++++++-----------------
drivers/media/i2c/smiapp/smiapp-regs.c | 3 -
drivers/media/i2c/smiapp/smiapp.h | 1 -
drivers/media/v4l2-core/v4l2-device.c | 3 +-
include/media/v4l2-subdev.h | 25 ++-
5 files changed, 86 insertions(+), 149 deletions(-)
--
2.20.1
next reply other threads:[~2019-08-19 12:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-19 12:47 Sakari Ailus [this message]
2019-08-19 12:47 ` [PATCH 1/6] v4l: subdev: Set sd->devnode before registering the subdev Sakari Ailus
2019-09-12 12:40 ` Hans Verkuil
2019-08-19 12:47 ` [PATCH 2/6] v4l: subdev: Provide a locking scheme for subdev operations Sakari Ailus
2019-09-12 13:11 ` Hans Verkuil
2019-09-12 13:24 ` Sakari Ailus
2019-08-19 12:47 ` [PATCH 3/6] smiapp: Error handling cleanups and fixes Sakari Ailus
2019-08-19 12:47 ` [PATCH 4/6] smiapp: Rely on V4L2 sub-device framework to do the locking Sakari Ailus
2019-08-19 12:47 ` [PATCH 5/6] smiapp: Remove the active field from sensor's struct Sakari Ailus
2019-08-19 12:47 ` [PATCH 6/6] smiapp: Avoid fall-through in switch Sakari Ailus
2019-09-12 13:17 ` Hans Verkuil
2019-09-13 6:50 ` Sakari Ailus
2019-09-13 6:47 ` [PATCH v2 " Sakari Ailus
2019-09-13 6:52 ` Hans Verkuil
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=20190819124728.10511-1-sakari.ailus@linux.intel.com \
--to=sakari.ailus@linux.intel.com \
--cc=hverkuil@xs4all.nl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox