From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF7DF3AC0C7 for ; Fri, 10 Apr 2026 08:28:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775809716; cv=none; b=qdWOJkruFWvImQAtSu5OgxDSOJFNBvjw3Ims/KL4csESKp6ba0HH1qgLOhZ8hx9EBf592/oNSiqdn5EE6ot5ahhAPG7k2dBjjAxrn6jusQDzjQPntMRmHSuWJICFvoR+euRhIlhpRIS0Q1tTHJJBzdccrZCI4CM9O/JC+d+DBV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775809716; c=relaxed/simple; bh=awrT3XJPhBBbyvLD1ErA0ocQCfadNR5eeOEAw7k092o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DjPiP0jjkn8uwjtoO9VhKOGDb1/mO25u6JopJ0ZnrQBjPgrj7v0Q8+94w6uEYw434PqcMiAeg+7onxMMg8AHktc/3MBTcJOtkXWPNuwtMHhHXVAuFalZyPEt85EusiUQDWrqky4++TUDtFAkLJ4bgo8op6EbBYUsId1sQGhOoSY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=AhNBqXJm; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="AhNBqXJm" Received: from ideasonboard.com (net-93-65-100-155.cust.vodafonedsl.it [93.65.100.155]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id EB7871BA; Fri, 10 Apr 2026 10:27:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1775809621; bh=awrT3XJPhBBbyvLD1ErA0ocQCfadNR5eeOEAw7k092o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AhNBqXJmVmjEYQYpno/IHNJbpwACkTAPV5hkxOcQ5V/PjKy9TzQ6d4s73fVNgft2L dI2Hcs95KT7+Ra7YHqyq8xl5n/pT4kPD+Aaa7QU0sKzrvIKCnbrefIyneftKX1KxLp 8/agUfBJkgkm3CJPVwKDtHXMySzrGqAcW0Snj/2A= Date: Fri, 10 Apr 2026 10:28:27 +0200 From: Jacopo Mondi To: Sakari Ailus Cc: linux-media@vger.kernel.org, hans@jjverkuil.nl, laurent.pinchart@ideasonboard.com, Prabhakar , Kate Hsuan , Dave Stevenson , Tommaso Merciai , Benjamin Mugnier , Sylvain Petinot , Christophe JAILLET , Julien Massot , Naushir Patuck , "Yan, Dongcheng" , "Cao, Bingbu" , "Qiu, Tian Shu" , Stefan Klug , Mirela Rabulea , =?utf-8?B?QW5kcsOp?= Apitzsch , Heimir Thor Sverrisson , Kieran Bingham , Mehdi Djait , Ricardo Ribalda Delgado , Hans de Goede , Jacopo Mondi , Tomi Valkeinen , David Plowman , "Yu, Ong Hock" , "Ng, Khai Wen" , Jai Luthra , Rishikesh Donadkar Subject: Re: [PATCH v4 04/29] media: imx219: Scale the vblank limits according to rate_factor Message-ID: References: <20260408153939.969381-1-sakari.ailus@linux.intel.com> <20260408153939.969381-5-sakari.ailus@linux.intel.com> Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20260408153939.969381-5-sakari.ailus@linux.intel.com> Hi Sakari On Wed, Apr 08, 2026 at 06:39:13PM +0300, Sakari Ailus wrote: > The limits for vertical blanking (and frame length in pixels) is related > to the properties of the hardware, it's not in half-line units the driver > uses. Multiply the vertical blanking limits by the rate_factor to satisty > hardware requirements. > > Fixes: f513997119f4 ("media: i2c: imx219: Scale the pixel rate for analog binning") > Cc: stable@vger.kernel.org > Signed-off-by: Sakari Ailus I'm not sure I understand this change. I think we have clarified the imx219 has a "special" binning mode where the ADC consumes two lines at a time, allowing an higher framerate. The driver accounts for that by doubling the PIXEL_RATE control value and halving the VBLANK and EXPOSURE controls values when writing them to registers. Userspace is not concerned with the special binning mode and is not required to halve the values it writes to the VBLANK and EXPOSURE controls. Doesn't the same apply to the limits ? Also, I presume but special binning mode is not well documented, the actual maximum register value for the frame length is still 0xfffe. What have I missed ? > --- > drivers/media/i2c/imx219.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/i2c/imx219.c b/drivers/media/i2c/imx219.c > index 62a23541b1dc..6819a2fa3262 100644 > --- a/drivers/media/i2c/imx219.c > +++ b/drivers/media/i2c/imx219.c > @@ -878,14 +878,17 @@ static int imx219_set_pad_format(struct v4l2_subdev *sd, > crop->top = (IMX219_NATIVE_HEIGHT - crop->height) / 2; > > if (fmt->which == V4L2_SUBDEV_FORMAT_ACTIVE) { > + unsigned int rate_factor = imx219_get_rate_factor(state); > int exposure_max; > int exposure_def; > int llp_min; > int pixel_rate; > > /* Update limits and set FPS to default */ > - ret = __v4l2_ctrl_modify_range(imx219->vblank, IMX219_VBLANK_MIN, > - IMX219_FLL_MAX - mode->height, 1, > + ret = __v4l2_ctrl_modify_range(imx219->vblank, > + IMX219_VBLANK_MIN * rate_factor, > + (IMX219_FLL_MAX - mode->height) * > + rate_factor, rate_factor, > mode->fll_def - mode->height); > if (ret) > return ret; > @@ -928,8 +931,7 @@ static int imx219_set_pad_format(struct v4l2_subdev *sd, > return ret; > > /* Scale the pixel rate based on the mode specific factor */ > - pixel_rate = imx219_get_pixel_rate(imx219) * > - imx219_get_rate_factor(state); > + pixel_rate = imx219_get_pixel_rate(imx219) * rate_factor; > ret = __v4l2_ctrl_modify_range(imx219->pixel_rate, pixel_rate, > pixel_rate, 1, pixel_rate); > if (ret) > -- > 2.47.3 > >