From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (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 912D93783BB for ; Thu, 18 Jun 2026 10:40:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781779226; cv=none; b=ceW/Tv+icBBaxhcH+nnMIhE7che5n+kgRcSVAMOiuNT0VriOuCwmzIatOxTcd4+76NQT9XQb3tuIpu2utqVIDhYTjnd4exMwsvMxPUZfax6W+C+c4R3PgN1iX+bRLHOxO0kE+xz4WR8alZivEKikCRZRJabCXVJGX1fz1PnQxhU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781779226; c=relaxed/simple; bh=OwcKWPU6mEZsgYgs6LunH9zaHVHp5M2NIvO8gs69LII=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C2xczOb7RnVpMzxRjpJlzp8YIDdC4nu+D76yJyUvaV8jivogS2VtJao3j+nOdALC6gm/AiLT3MH9B2Owgj5MGtFpsFrOmYVbMkMLpFKs+cfxp4aHBzl0kkJBy/5wuxE5mEx7gKnUduRhvt5+JeKMyRXZWJekMDV1Nk4deCp7MJE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ZkKtOza6; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ZkKtOza6" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1781779225; x=1813315225; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=OwcKWPU6mEZsgYgs6LunH9zaHVHp5M2NIvO8gs69LII=; b=ZkKtOza6ihUyR74sUx+o2gWIgAAe1nuz0Bh3fovykcecMvGeWNbYPMqz DDnDpYAL6/A8O0pYglHm8c7b8LN7wIt6guZ8UfqAfGQx3Sdq/v1mqJt3o UcHvY4JW5aAk5eXE9nfVV0/yR8YbK2TqBigyM8P8GrqYH4xbYTjtCj3BO 2BQrCtb3SnwIg7arZraL+2pZcNJnmFCUMzMIkiCw3UmLirSmJovSMjrwZ N/n3aAEvZKmQOrxJMPxWsriSnV61hbVYCsbhmGCDydUNoNHYoacw6xhAZ CQWvuf3ydOw1qPXfN7uYSDmK4GFC9TnAA9bQsdpzHp1L6FdbI4A5fmyZb g==; X-CSE-ConnectionGUID: p5Tejq+1Q0Koj/zDDLvpUg== X-CSE-MsgGUID: WEgEdCqMT5yQVxbtXY4Y9g== X-IronPort-AV: E=McAfee;i="6800,10657,11820"; a="82613035" X-IronPort-AV: E=Sophos;i="6.24,211,1774335600"; d="scan'208";a="82613035" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2026 03:40:24 -0700 X-CSE-ConnectionGUID: q1GaPYtPT5WqDQyUEwU2FQ== X-CSE-MsgGUID: 83JSVugKSoSF5gmg5MOXig== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,211,1774335600"; d="scan'208";a="253441235" Received: from smoticic-mobl1.ger.corp.intel.com (HELO kekkonen.fi.intel.com) ([10.245.244.24]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jun 2026 03:40:18 -0700 Received: from kekkonen.localdomain (localhost [IPv6:::1]) by kekkonen.fi.intel.com (Postfix) with SMTP id 57106121C36; Thu, 18 Jun 2026 13:40:17 +0300 (EEST) Date: Thu, 18 Jun 2026 13:40:17 +0300 Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo From: Sakari Ailus To: Dave Stevenson Cc: linux-media@vger.kernel.org, hans@jjverkuil.nl, laurent.pinchart@ideasonboard.com, Prabhakar , Kate Hsuan , Tommaso Merciai , Benjamin Mugnier , Sylvain Petinot , Christophe JAILLET , Julien Massot , Naushir Patuck , "Yan, Dongcheng" , Stefan Klug , Mirela Rabulea , =?iso-8859-1?Q?Andr=E9?= 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 v5 03/10] media: imx219: Account rate_factor in setting upper exposure limit Message-ID: References: <20260607215356.842932-1-sakari.ailus@linux.intel.com> <20260607215356.842932-4-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=us-ascii Content-Disposition: inline In-Reply-To: Hi Dave, On Mon, Jun 08, 2026 at 04:42:44PM +0100, Dave Stevenson wrote: > Hi Sakari > > On Sun, 7 Jun 2026 at 22:54, Sakari Ailus wrote: > > > > The rate_factor multiplier is used to multiply a few values in the > > sensor's timing configuration and the exposure time is one of them. This > > also needs to be taken into account in exposure time margin: multiply it > > by rate_factor so that sensor's exposure time margin is respected. > > Testing the 1640x1232 mode with FRM_LENGTH_A set to 0x288 (79.07fps), > I can write register 0x15a (COARSE_INTEGRATION_TIME_A) with values up > to and including 0x284 without it affecting the output frame rate, and > without image corruption. > With IMX219_EXPOSURE_OFFSET being 4, the current code implements > exactly those limits, so why do you believe the offset should be > increased? I agree with the upper exposure time limit (with FRM_LENGTH_A set to 0x288) and the margin above but the issue is that the driver only implements these limits when rate_factor is 1. The margin is subtracted from the frame length to calculate the upper exposure limit, but as the frame length in lines an the exposure values are divided by rate_factor, the margin gets divided, too, resulting the effective margin of 2. I tested that setting the exposure value to higher than FRM_LENGTH_A - margin increases the frame time. This shouldn't be the case i.e. it's a driver bug. > > To my mind section 5-5 Frame Rate Calculation Formula of the datasheet > is fairly clear with > [ In the case of (frame_length_lines - 4 > coarse_integration_time) ]: > Frame_Length = frame_length_lines > [ In the case of (frame_length_lines - 4 < coarse_integration_time) ]: > Frame_Length = coarse_integration_time + 4 > > The register FRM_LENGTH_A (0x160) being in units of 2 lines doesn't > change that calculation. -- Kind regards, Sakari Ailus