Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4352013pxu; Wed, 9 Dec 2020 15:07:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJz5MK2QvM1B5kElaTqbyRsQRt/TMzX9tY56pIVJsvO2OEwx0CvIff/JsvNO3wVYQ74VY2Gu X-Received: by 2002:a17:906:52d9:: with SMTP id w25mr3881893ejn.504.1607555228578; Wed, 09 Dec 2020 15:07:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607555228; cv=none; d=google.com; s=arc-20160816; b=tvYmwxNn+zx/SWNaP3rE9j794vs5XdYZFft4ZEck2XKYTt0Indx8h7eukavVeMojiI l5VyZ/cli1DHEh5wcpFt6o2qOtcu0RaVdXy/x3SXtvY0B0YES8S4UyxMVvTMMzxT1nYm av5+65VEiL/l6aXv/29BOhqwgO1sw910EswpGqUwqkuR8N+lj9MW4+X/XcG7vmHwicfX 7jmDgKcG7rOsceChR8r+4QnBIfIkZx2CMJTxU3kYwij2awcdHeLS+Va5RdQqu4Bo0jDF Pqz4edEOsUjHAMlwfJvsrxIqV9p+1ufdxbEK6wHbB/fa5Y4ZnNGqnZ31hyowrKD7COew h45g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=6hfPjXflRE4X47I2z8sLs+SGhvGM13sHjHrwL3K/vbU=; b=t3n9g2xLodbh7U5P2dys518vrdVT6DXwJepgkEq2fCZlLPAXybgNr2qh5G8W4Jm+/e 6vr0o/1AROehm0IMMP1+0RfIKxc8GZ01I+T5XzMvXKIm3BhJ+GaCt5HXpDcCT+tcKdgX 3EhPlR3leVrwHWd1Zd8ddZixz0LK6lZ3jAtsGShqLlfr71i+nuqrMrGghxqOvFrl65Rm 9E5+0E6TdJP27IRPh/rGhMr/6J+L+GmrqTLHtnWkBzhU1EH1DtDWdR47X48NKu3Ea4lI uyOvtTDtZWRWS2bUsPv6dykKiV1KRG5QEXyfxGkkWkNJcaBh30mJiXrRHwuxAGLuiuG/ gsfQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i8si1604242ejj.700.2020.12.09.15.06.45; Wed, 09 Dec 2020 15:07:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729570AbgLIJ6z (ORCPT + 99 others); Wed, 9 Dec 2020 04:58:55 -0500 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:16281 "EHLO relay1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729007AbgLIJ6z (ORCPT ); Wed, 9 Dec 2020 04:58:55 -0500 X-Originating-IP: 93.34.118.233 Received: from uno.localdomain (93-34-118-233.ip49.fastwebnet.it [93.34.118.233]) (Authenticated sender: jacopo@jmondi.org) by relay1-d.mail.gandi.net (Postfix) with ESMTPSA id DA8FB240004; Wed, 9 Dec 2020 09:58:09 +0000 (UTC) Date: Wed, 9 Dec 2020 10:58:19 +0100 From: Jacopo Mondi To: kholk11@gmail.com Cc: mchehab@kernel.org, robh+dt@kernel.org, marijn.suijten@somainline.org, konrad.dybcio@somainline.org, martin.botka@somainline.org, devicetree@vger.kernel.org, linux-media@vger.kernel.org, phone-devel@vger.kernel.org, linux-kernel@vger.kernel.org, sakari.ailus@iki.fi, andrey.konovalov@linaro.org, angelogioacchino.delregno@somainline.org Subject: Re: [PATCH v3 1/2] media: i2c: Add driver for the Sony Exmor-RS IMX300 camera sensor Message-ID: <20201209095819.w6lfpga2gqvu2ujn@uno.localdomain> References: <20201127223047.2764643-1-kholk11@gmail.com> <20201127223047.2764643-2-kholk11@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20201127223047.2764643-2-kholk11@gmail.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Fri, Nov 27, 2020 at 11:30:46PM +0100, kholk11@gmail.com wrote: > From: AngeloGioacchino Del Regno > > This is a custom multi-aspect 25MegaPixels sensor from Sony, > found in many Sony Xperia smartphones from various eras. > > The camera assembly for this sensor usually (at least in Xperia > phones) has a lens that does not cover the entire sensor area, > which means that the real corners are blind and that, in many > lighting conditions, some more pixels in the corners are very > getting obscured (as no decent amount of light can get in)... > so, the maximum resolution that can produce a good image is: > - In 4:3 aspect ratio, 5520x4160 (23.0MP) > - In 16:9 aspect ratio, 5984x3392 (20.3MP). > > This sensor supports high frame rates (>=60FPS) when in binning > mode and both RAW8 and RAW10 output modes. > In this version of the driver, support has been provided for the > following resolutions: > W x H SZ MAX_FPS BINNING > - 5520x4160 23.0MP 23 No > - 5984x3392 20.3MP 26 No > - 2992x1696 3.8MP 60 Yes > - 1424x800 1.2MP 120 Yes > > Note 1: The "standard" camera assy for IMX300 also contains an > actuator (to focus the image), but this driver only manages the > actual image sensor. > > Note 2: The command tables for this sensor were reverse > engineered from a downstream "userspace driver" that has been > released in various versions on various Xperia smartphones. > Register layout seems to be only vaguely similar to IMX219, > which has a public datasheet from where some names for the > figured out registers were taken and added to the driver: > these names are probably not the right ones, but they surely > represent the intended thing. > > Signed-off-by: AngeloGioacchino Del Regno Just a few drive-by comments, as I'm looking at selection targets for other imx sensors and I've noticed this one on the list > --- > drivers/media/i2c/Kconfig | 13 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/imx300.c | 3081 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 3095 insertions(+) > create mode 100644 drivers/media/i2c/imx300.c > [snip] > +/* > + * ** IMX300 native and active pixel array size ** > + * > + * Being this a multi-aspect sensor, the following native W/H apply, but > + * beware: the module assembly usually has a (round) lens that is shadowing > + * or covering the corners of the (square) image sensor, so the maximum > + * output resolution must be lower than the maximum sensor resolution > + * otherwise we get something like a view from a porthole... :) > + * > + * For 4:3 aspect ratio, max is: 5984x4140 (25MP) > + * For 16:9 aspect ratio, max is: 5984x3392 (20.3MP) > + */ These are the sizes > +#define IMX300_NATIVE_WIDTH 5980U > +#define IMX300_NATIVE_HEIGHT 4140U > +#define IMX300_PIXEL_ARRAY_LEFT 0U > +#define IMX300_PIXEL_ARRAY_TOP 0U > +#define IMX300_PIXEL_ARRAY_WIDTH 5520U > +#define IMX300_PIXEL_ARRAY_HEIGHT 4160U And here is how they are applied to selection targets > + case V4L2_SEL_TGT_CROP: { > + struct imx300 *imx300 = to_imx300(sd); > + > + mutex_lock(&imx300->mutex); > + sel->r = *__imx300_get_pad_crop(imx300, cfg, sel->pad, > + sel->which); > + mutex_unlock(&imx300->mutex); > + > + return 0; > + } > + > + case V4L2_SEL_TGT_NATIVE_SIZE: > + sel->r.top = 0; > + sel->r.left = 0; > + sel->r.width = IMX300_NATIVE_WIDTH; > + sel->r.height = IMX300_NATIVE_HEIGHT; > + > + return 0; > + > + case V4L2_SEL_TGT_CROP_DEFAULT: > + sel->r.top = IMX300_PIXEL_ARRAY_TOP; > + sel->r.left = IMX300_PIXEL_ARRAY_LEFT; > + sel->r.width = IMX300_PIXEL_ARRAY_WIDTH; > + sel->r.height = IMX300_PIXEL_ARRAY_HEIGHT; > + > + return 0; > + } > + 1) CROP_DEFAULT should be contained in NATIVE_SIZE (actually all targets are contained in NATIVE_SIZE, and are defined relatively to it). This means that IMX300_PIXEL_ARRAY_HEIGHT > IMX300_NATIVE_HEIGHT is probably wrong. 2) You need to specify CROP_BOUNDS too. If the driver does not support reading optically black pixels using the selection API, it should be identical to CROP_DEFAULT (v4l2-compliance should report that, see https://git.linuxtv.org/media_tree.git/commit/?id=1ed36ecd1459b653cced8929bfb37dba94b64c5d 3) CROP_DEFAULT (and BOUNDS) should report the sensor readable active area. You have one mode where the TGT_CROP rectangle width is bigger than the CROP_DEFAULT (and BOUNDS) rectangle width (5984 > 5520). I think 5984 should probably be made the CROP_DEFAULT (and BOUNDS) width then, as the 5984 mode's width implies the 464 pixels exceeding 5520 are readable and valid for image capture. It's not easy to get these right with a datasheet sometimes, without one it quickly becomes a matter of guessing. But even if the values are computed as 'best effort' we should try to respect the relationships between the different selection targets. Thanks j