From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Hans de Goede <hdegoede@redhat.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Subject: Re: [PATCH v6 3/5] media: uvcvideo: Increase/decrease the PM counter per IOCTL
Date: Tue, 22 Apr 2025 23:37:53 +0300 [thread overview]
Message-ID: <20250422203753.GM17813@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20250327-uvc-granpower-ng-v6-3-35a2357ff348@chromium.org>
Hi Ricardo,
Thank you for the patch.
On Thu, Mar 27, 2025 at 09:05:29PM +0000, Ricardo Ribalda wrote:
> Now we call uvc_pm_get/put from the device open/close. This low
> level of granularity might leave the camera powered on in situations
> where it is not needed.
>
> Increase the granularity by increasing and decreasing the Power
> Management counter per ioctl. There are two special cases where the
> power management outlives the ioctl: async controls and streamon. Handle
> those cases as well.
>
> In a future patch, we will remove the uvc_pm_get/put from open/close.
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 37 +++++++++++++++++++++++++++----------
> drivers/media/usb/uvc/uvc_v4l2.c | 39 +++++++++++++++++++++++++++++++++++++--
> 2 files changed, 64 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
> index cbf19aa1d82374a08cf79b6a6787fa348b83523a..3fad289e41fd5a757f8dcf30a6238c694fc4250c 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -1812,38 +1812,49 @@ static void uvc_ctrl_send_slave_event(struct uvc_video_chain *chain,
> uvc_ctrl_send_event(chain, handle, ctrl, mapping, val, changes);
> }
>
> -static void uvc_ctrl_set_handle(struct uvc_fh *handle, struct uvc_control *ctrl,
> - struct uvc_fh *new_handle)
> +static int uvc_ctrl_set_handle(struct uvc_fh *handle, struct uvc_control *ctrl,
> + struct uvc_fh *new_handle)
> {
> lockdep_assert_held(&handle->chain->ctrl_mutex);
>
> if (new_handle) {
> + int ret;
> +
> if (ctrl->handle)
> dev_warn_ratelimited(&handle->stream->dev->udev->dev,
> "UVC non compliance: Setting an async control with a pending operation.");
>
> if (new_handle == ctrl->handle)
> - return;
> + return 0;
>
> if (ctrl->handle) {
> WARN_ON(!ctrl->handle->pending_async_ctrls);
> if (ctrl->handle->pending_async_ctrls)
> ctrl->handle->pending_async_ctrls--;
> + ctrl->handle = new_handle;
> + handle->pending_async_ctrls++;
As commented previously, your usage of the handle variable is confusing.
ctrl->handle->pending_async_ctrls++;
> + return 0;
> }
>
> + ret = uvc_pm_get(handle->chain->dev);
> + if (ret)
> + return ret;
> +
> ctrl->handle = new_handle;
> handle->pending_async_ctrls++;
ctrl->handle->pending_async_ctrls++;
> - return;
> + return 0;
> }
>
> /* Cannot clear the handle for a control not owned by us.*/
> if (WARN_ON(ctrl->handle != handle))
> - return;
> + return -EINVAL;
>
> ctrl->handle = NULL;
> if (WARN_ON(!handle->pending_async_ctrls))
> - return;
> + return -EINVAL;
> handle->pending_async_ctrls--;
> + uvc_pm_put(handle->chain->dev);
> + return 0;
> }
>
> void uvc_ctrl_status_event(struct uvc_video_chain *chain,
> @@ -2137,15 +2148,16 @@ static int uvc_ctrl_commit_entity(struct uvc_device *dev,
>
> ctrl->dirty = 0;
>
> + if (!rollback && handle && !ret &&
> + ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
> + ret = uvc_ctrl_set_handle(handle, ctrl, handle);
> +
> if (ret < 0) {
> if (err_ctrl)
> *err_ctrl = ctrl;
> return ret;
> }
>
> - if (!rollback && handle &&
> - ctrl->info.flags & UVC_CTRL_FLAG_ASYNCHRONOUS)
> - uvc_ctrl_set_handle(handle, ctrl, handle);
> }
>
> return 0;
> @@ -3222,6 +3234,7 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
> void uvc_ctrl_cleanup_fh(struct uvc_fh *handle)
> {
> struct uvc_entity *entity;
> + int i;
>
> guard(mutex)(&handle->chain->ctrl_mutex);
>
> @@ -3236,7 +3249,11 @@ void uvc_ctrl_cleanup_fh(struct uvc_fh *handle)
> }
> }
>
> - WARN_ON(handle->pending_async_ctrls);
> + if (!WARN_ON(handle->pending_async_ctrls))
> + return;
> +
> + for (i = 0; i < handle->pending_async_ctrls; i++)
> + uvc_pm_put(handle->stream->dev);
> }
>
> /*
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> index 1d5be045d04ecbf17e65e14b390e494a294b735f..8bccf7e17528b62f2594c0dad99405034532973d 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -697,6 +697,9 @@ static int uvc_v4l2_release(struct file *file)
> if (uvc_has_privileges(handle))
> uvc_queue_release(&stream->queue);
>
> + if (handle->is_streaming)
> + uvc_pm_put(stream->dev);
> +
> /* Release the file handle. */
> uvc_dismiss_privileges(handle);
> v4l2_fh_del(&handle->vfh);
> @@ -862,6 +865,11 @@ static int uvc_ioctl_streamon(struct file *file, void *fh,
> if (ret)
> return ret;
>
> + ret = uvc_pm_get(stream->dev);
Shouldn't this be done before calling uvc_queue_streamon() ? There's
another PM reference being held by the ioctl handler, but if the code is
refactored later, it would be good to make sure we resume the device
before starting streaming.
> + if (ret) {
> + uvc_queue_streamoff(&stream->queue, type);
> + return ret;
> + }
> handle->is_streaming = true;
>
> return 0;
> @@ -879,7 +887,10 @@ static int uvc_ioctl_streamoff(struct file *file, void *fh,
> guard(mutex)(&stream->mutex);
>
> uvc_queue_streamoff(&stream->queue, type);
> - handle->is_streaming = false;
> + if (handle->is_streaming) {
> + handle->is_streaming = false;
> + uvc_pm_put(stream->dev);
> + }
>
> return 0;
> }
> @@ -1378,9 +1389,11 @@ static int uvc_v4l2_put_xu_query(const struct uvc_xu_control_query *kp,
> #define UVCIOC_CTRL_MAP32 _IOWR('u', 0x20, struct uvc_xu_control_mapping32)
> #define UVCIOC_CTRL_QUERY32 _IOWR('u', 0x21, struct uvc_xu_control_query32)
>
> +DEFINE_FREE(uvc_pm_put, struct uvc_device *, if (_T) uvc_pm_put(_T))
> static long uvc_v4l2_compat_ioctl32(struct file *file,
> unsigned int cmd, unsigned long arg)
> {
> + struct uvc_device *uvc_device __free(uvc_pm_put) = NULL;
> struct uvc_fh *handle = file->private_data;
> union {
> struct uvc_xu_control_mapping xmap;
> @@ -1389,6 +1402,12 @@ static long uvc_v4l2_compat_ioctl32(struct file *file,
> void __user *up = compat_ptr(arg);
> long ret;
>
> + ret = uvc_pm_get(handle->stream->dev);
> + if (ret)
> + return ret;
> +
> + uvc_device = handle->stream->dev;
Ouch... That's not nice very :-/
If you want to use the cleanup API, I think we could use guards with an
init function such as
struct uvc_device *__uvc_pm_get_init(struct uvc_device *dev, int *ret)
{
*ret = uvc_pm_get(dev);
return *ret ? NULL : dev;
}
You can use DEFINE_CLASS() instead of DEFINE_GUARD() to control the
arguments to the init function. Users of the guard could do
int ret;
guard(uvc_pm)(dev, &ret);
if (ret)
return ret;
...
Another, simpler option would be to replace returns with breaks in
uvc_v4l2_compat_ioctl32(). I'm tempted to do that in this patch, and
switching to the cleanup API as a patch on top if desired.
> +
> switch (cmd) {
> case UVCIOC_CTRL_MAP32:
> ret = uvc_v4l2_get_xu_mapping(&karg.xmap, up);
> @@ -1423,6 +1442,22 @@ static long uvc_v4l2_compat_ioctl32(struct file *file,
> }
> #endif
>
> +static long uvc_v4l2_unlocked_ioctl(struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + struct uvc_fh *handle = file->private_data;
> + int ret;
> +
> + ret = uvc_pm_get(handle->stream->dev);
> + if (ret)
> + return ret;
> +
> + ret = video_ioctl2(file, cmd, arg);
> +
> + uvc_pm_put(handle->stream->dev);
> + return ret;
> +}
> +
> static ssize_t uvc_v4l2_read(struct file *file, char __user *data,
> size_t count, loff_t *ppos)
> {
> @@ -1507,7 +1542,7 @@ const struct v4l2_file_operations uvc_fops = {
> .owner = THIS_MODULE,
> .open = uvc_v4l2_open,
> .release = uvc_v4l2_release,
> - .unlocked_ioctl = video_ioctl2,
> + .unlocked_ioctl = uvc_v4l2_unlocked_ioctl,
> #ifdef CONFIG_COMPAT
> .compat_ioctl32 = uvc_v4l2_compat_ioctl32,
> #endif
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2025-04-22 20:37 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-27 21:05 [PATCH v6 0/5] media: uvcvideo: Implement Granular Power Saving Ricardo Ribalda
2025-03-27 21:05 ` [PATCH v6 1/5] media: uvcvideo: Keep streaming state in the file handle Ricardo Ribalda
2025-03-27 21:05 ` [PATCH v6 2/5] media: uvcvideo: Create uvc_pm_(get|put) functions Ricardo Ribalda
2025-04-22 18:17 ` Laurent Pinchart
2025-03-27 21:05 ` [PATCH v6 3/5] media: uvcvideo: Increase/decrease the PM counter per IOCTL Ricardo Ribalda
2025-04-22 20:37 ` Laurent Pinchart [this message]
2025-04-22 22:58 ` Ricardo Ribalda
2025-04-28 11:54 ` Hans de Goede
2025-04-28 12:31 ` Laurent Pinchart
2025-03-27 21:05 ` [PATCH v6 4/5] media: uvcvideo: Make power management granular Ricardo Ribalda
2025-03-27 21:05 ` [PATCH v6 5/5] media: uvcvideo: Do not turn on the camera for some ioctls Ricardo Ribalda
2025-05-09 13:44 ` Hans Verkuil
2025-05-09 13:51 ` Ricardo Ribalda
2025-05-28 18:05 ` Ricardo Ribalda
2025-04-07 11:41 ` [PATCH v6 0/5] media: uvcvideo: Implement Granular Power Saving Hans de Goede
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=20250422203753.GM17813@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=guennadi.liakhovetski@intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab+samsung@kernel.org \
--cc=mchehab@kernel.org \
--cc=ribalda@chromium.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.