[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cef4bf31-35d9-4304-804d-5384018c0900@linaro.org>
Date: Thu, 9 May 2024 01:32:27 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Dave Stevenson <dave.stevenson@...pberrypi.com>,
Jacopo Mondi <jacopo.mondi@...asonboard.com>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
"Paul J. Murphy" <paul.j.murphy@...el.com>,
Martina Krasteva <quic_mkrastev@...cinc.com>,
Daniele Alessandrelli <daniele.alessandrelli@...el.com>,
Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] media: i2c: Fix imx412 exposure control
On 08/05/2024 17:31, Dave Stevenson wrote:
> For reference certainly imx327/290/462 which are all siblings in the
> Sony Starvis family do calculate exposure as
> exposure = 1 frame period - (SHS1 + 1) * (1H period)
> So 0 = max exposure and bigger values are shorter exposure time.
ack
> I'm not saying that the imx412 driver is right in doing this as well,
> but it seems there is a trend with the Sony Starvis family to program
> exposure in this different manner. Don't discount it as wrong for all
> drivers!
Understood. For the record the rpi imx477 driver writes the CID value
provided by user-space.
https://github.com/raspberrypi/linux/blob/rpi-6.6.y/drivers/media/i2c/imx477.c#L1376
With an exposure multiplier we don't support upstream at the moment. So,
I think this patch is the right fix after all.
---
bod
Powered by blists - more mailing lists