Linux kernel and device drivers for NXP i.MX platforms
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: DelaySystem <DelaySystem@tubot.lat>
Cc: imx@lists.linux.dev, Frank.Li@kernel.org, media-ci@linuxtv.org
Subject: Re: [PATCH] staging: media: imx: ic-prpencvf: add FORMAT_TRY frame interval support
Date: Sun, 08 Nov 2026 05:35:30 +0000	[thread overview]
Message-ID: <sashiko-outbox-203585@kernel.org> (raw)
In-Reply-To: <20261107-batch1-m2-prpencvf-try-v1-1-76bd9f505710@tubot.lat>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] staging: media: imx: unpropagated TRY interval in
  prp_set_frame_interval()
--

commit 39c074ccbb9c23c1bfb8a1a38f0cced39b190229
Author: DelaySystem <DelaySystem@tubot.lat>

staging: media: imx: ic-prpencvf: add FORMAT_TRY frame interval support

This commit adds V4L2_SUBDEV_FORMAT_TRY support to the frame interval
callbacks in imx-ic-prpencvf by storing TRY intervals in the subdev state
and initializing them from the default active interval in a new init_state
callback.

> diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c b/drivers/staging/media/imx/imx-ic-prpencvf.c
> index 3430ddeac3569..fd70c9a36f7ee 100644
> --- a/drivers/staging/media/imx/imx-ic-prpencvf.c
> +++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
> @@ -795,6 +795,18 @@ __prp_get_fmt(struct prp_priv *priv, struct v4l2_subdev_state *sd_state,
>  		return &priv->format_mbus[pad];
>  }
>  
> +static struct v4l2_fract *
> +__prp_get_frame_interval(struct prp_priv *priv,
> +			 struct v4l2_subdev_state *sd_state,
> +			 unsigned int pad,
> +			 enum v4l2_subdev_format_whence which)
> +{
> +	if (which == V4L2_SUBDEV_FORMAT_TRY)
> +		return v4l2_subdev_state_get_interval(sd_state, pad);
> +
> +	return &priv->frame_interval;
> +}
> +

[ ... ]

> @@ -1231,24 +1246,50 @@ static int prp_set_frame_interval(struct v4l2_subdev *sd,
>  				  struct v4l2_subdev_frame_interval *fi)
>  {
>  	struct prp_priv *priv = sd_to_priv(sd);
> -
> -	/*
> -	 * FIXME: Implement support for V4L2_SUBDEV_FORMAT_TRY, using the V4L2
> -	 * subdev active state API.
> -	 */
> -	if (fi->which != V4L2_SUBDEV_FORMAT_ACTIVE)
> -		return -EINVAL;
> +	struct v4l2_fract *interval;
> +	int ret = 0;
>  
>  	if (fi->pad >= PRPENCVF_NUM_PADS)
>  		return -EINVAL;
>  
>  	mutex_lock(&priv->lock);
> +	interval = __prp_get_frame_interval(priv, sd_state, fi->pad,
> +					    fi->which);
> +	if (!interval) {
> +		ret = -EINVAL;
> +		goto out;
> +	}
>  
>  	/* No limits on valid frame intervals */
>  	if (fi->interval.numerator == 0 || fi->interval.denominator == 0)
> -		fi->interval = priv->frame_interval;
> +		fi->interval = *interval;
>  	else
> -		priv->frame_interval = fi->interval;
> +		*interval = fi->interval;
> +out:
>  	mutex_unlock(&priv->lock);
>  
> -	return 0;
> +	return ret;
> +}

[Severity: Medium]
Should prp_set_frame_interval() keep the sink and source pad intervals in
sync when fi->which is V4L2_SUBDEV_FORMAT_TRY?

For V4L2_SUBDEV_FORMAT_ACTIVE, __prp_get_frame_interval() ignores pad and
returns the single shared &priv->frame_interval because the IC preprocess
task does not change the frame rate between PRPENCVF_SINK_PAD and
PRPENCVF_SRC_PAD.  For V4L2_SUBDEV_FORMAT_TRY, v4l2_subdev_state_get_interval()
returns a separate slot per pad, and prp_set_frame_interval() only updates
fi->pad without propagating the interval to the other pad (unlike
prp_set_fmt(), which propagates sink pad changes to PRPENCVF_SRC_PAD).
Userspace negotiating TRY frame intervals on PRPENCVF_SINK_PAD will read a
stale interval on PRPENCVF_SRC_PAD, or configure different TRY intervals on
the two pads that the hardware and ACTIVE state cannot represent.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261107-batch1-m2-prpencvf-try-v1-1-76bd9f505710@tubot.lat?part=1

      reply	other threads:[~2026-11-08  5:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08  5:17 [PATCH] staging: media: imx: ic-prpencvf: add FORMAT_TRY frame interval support DelaySystem via B4 Relay
2026-11-08  5:35 ` sashiko-bot [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=sashiko-outbox-203585@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=DelaySystem@tubot.lat \
    --cc=Frank.Li@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=media-ci@linuxtv.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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