Message ID | 20231218174042.794012-1-mike.rudenko@gmail.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-4184-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp1412349dyi; Mon, 18 Dec 2023 09:42:11 -0800 (PST) X-Google-Smtp-Source: AGHT+IGcKsFJiD92Ss/CPRhKFiU6IthYw5YtGLgS1K5vSp9Ppsf80tgnxRr0rmngHd25zhaikd4Q X-Received: by 2002:a17:903:2304:b0:1d3:beea:972b with SMTP id d4-20020a170903230400b001d3beea972bmr1211798plh.93.1702921331244; Mon, 18 Dec 2023 09:42:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702921331; cv=none; d=google.com; s=arc-20160816; b=BPYJDet5M+194penbENU8rX9uFKT1mNd6szlg5BMqAkmr8YOY2YpQfWbW6AJk1jm4G C+TAp1UZBTZ04iVVQCj5Ih/4bFqWcGKdPTHO6NhvxEYSoyzcBwbgC/jQzUJuWsGHo+L7 jQxzeaAezywi85AVnpMJIVbVnHCNIAkPbA7LnfmiXtVFwc2ICwmYCvul7B59GelK4caL Jpo7xWag3Aa/gRGOvL0YJe0+nSwtfnDm9Bdf/EjPjto4d9/xmKA9ZM1AeldPseU5hidh iRX8nWNzmPVB7kih0Rx9GnyTnSt48ALtZFUxZEpMN+bGJ2AFTNTq/OoF9KX7uV1BSmrq VuMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=D+9SpyD/fjsy+bPfqtgZB0EVZfRFSaxY+QuQ8+JRb/4=; fh=Ft8dYvEuFIKwnehVwpL0WG7QMIrRLMi0wgN4ll940k8=; b=uU7ANEoja71ZihUFn3LaneTPt1/GU9meGP+6yDVE8BFe8wLzOdcQPY9n72RiaYk5Ih W6dv4bwn+H411PVgBqh30WE1bB528/s8aSAmjfLqvFaIiwgMmSlI7l8QIUUMH77x+fSk DdVwPFMZIiCqI0EcZotozZVWyLI2gNG2fJ6VD+Q6i3Vu29USWbCQruq2ATdle+xPLIhe FjoBSW7APWlficg7zq8I0xxWszCeya5w8JiAzikY48rihcVfZNfYhW8b3kbM1iPMLM3v sPkydEOqNjm/lhyJWoIyXKqJ3cdh7/aoGLYdyGtXkNAZZcvmau2KSjvgz8Z4l5N+LKKp u35A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Vme5jySB; spf=pass (google.com: domain of linux-kernel+bounces-4184-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4184-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id a6-20020a170902ee8600b001d33e6521c8si3781083pld.472.2023.12.18.09.42.11 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 09:42:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-4184-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=Vme5jySB; spf=pass (google.com: domain of linux-kernel+bounces-4184-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-4184-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id ECC1B285084 for <ouuuleilei@gmail.com>; Mon, 18 Dec 2023 17:42:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A1E0D5BFBC; Mon, 18 Dec 2023 17:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Vme5jySB" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 792D27144F; Mon, 18 Dec 2023 17:40:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2cc6a52231cso17845621fa.3; Mon, 18 Dec 2023 09:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1702921256; x=1703526056; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=D+9SpyD/fjsy+bPfqtgZB0EVZfRFSaxY+QuQ8+JRb/4=; b=Vme5jySB1jn0Q1cr2R5F2UUfqW5WOBwKJ4f1hU8Z5+J4TjWKC8hZekuYJFAudyrsF4 mwL4HTN9mLJwjmVZLho5wq/k1mHti/ihEHEckWWlOvBhxtxEAyM4LVDvClrnJaffrwiX 3PEQOMFWd9ar6LivWECQSHOCicDIiuA1PdEFK7tLqW6ZgTIx8IkLXN4AF1yin7tpvc9q MSBQC4ghM3IBHF8lJPcxWMuxsOk0EZot0k3ZROjq+RgLricuea5zQE2iMOY7//0H4rse G13Hr3MyDLIYZACRATFqIcUd1zSGqXUhqWHA/nRd41FCipPMO1mEPE+vYBZNnrDBbusm T0zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702921256; x=1703526056; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=D+9SpyD/fjsy+bPfqtgZB0EVZfRFSaxY+QuQ8+JRb/4=; b=tP/zytH4Hk2QXDPnMBubKfBi7Jl8TKgiKogjUNJM9H03cZvfnblH3guFzQ6qOLIiDU qthCe50UN+TALeDdDufEOtICyN054FGbIAoYImO2SuygETXXB7JtzaRJAsCuZXPKup8Y fpGOLrwz663Pbn138pUuMgxx8Giswsl0nd68xzjn/fbZlkdGYM+DoiRehSXVQ3kfruDy AC3NvYWw21E5yTvbJL2Zen/6l1rHA7+HgJtaDLSzqsSQTepqYAjZskcOUOT4GiuVfA70 bkrllMfAwRLhzBVbM6D4gfjE8HvVPP5Cl3zqLwE+bsDePbnTfi5GIs77Yuu0mZlqFHSm tjKg== X-Gm-Message-State: AOJu0YzOajVxZ7d5j0ccuRah3pKCvfYRegNgKBBCuD4a/sGdljbZSrKG hPGZ1dgFvpmt7urHdoVeFSjB86fGHzVpyw== X-Received: by 2002:a2e:9604:0:b0:2cc:5e72:17f4 with SMTP id v4-20020a2e9604000000b002cc5e7217f4mr1571163ljh.47.1702921255975; Mon, 18 Dec 2023 09:40:55 -0800 (PST) Received: from localhost ([83.149.246.185]) by smtp.gmail.com with ESMTPSA id e15-20020a05651c150f00b002cc6b5ab63asm682172ljf.119.2023.12.18.09.40.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Dec 2023 09:40:55 -0800 (PST) From: Mikhail Rudenko <mike.rudenko@gmail.com> To: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Sakari Ailus <sakari.ailus@linux.intel.com>, Laurent Pinchart <laurent.pinchart@ideasonboard.com>, Jacopo Mondi <jacopo@jmondi.org>, Tommaso Merciai <tomm.merciai@gmail.com>, Christophe JAILLET <christophe.jaillet@wanadoo.fr>, Dave Stevenson <dave.stevenson@raspberrypi.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Mikhail Rudenko <mike.rudenko@gmail.com> Subject: [PATCH v2 00/20] Omnivision OV4689 refactoring and improvements Date: Mon, 18 Dec 2023 20:40:21 +0300 Message-ID: <20231218174042.794012-1-mike.rudenko@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785642438181331944 X-GMAIL-MSGID: 1785642438181331944 |
Series |
Omnivision OV4689 refactoring and improvements
|
|
Message
Mikhail Rudenko
Dec. 18, 2023, 5:40 p.m. UTC
Hi, This series contains refactoring and new features implementation for the Omnivision OV4689 sensor driver. Specifically, patches 1, 2, 3, 5, 6, 10, 15, 16, 18, and 19 are refactorings, and are not supposed to introduce any functional change. Patches 4 and 7 perform migration to CCI helpers and subdevice active state respectively, and should not introduce any hardware- and/or user-visible change either. Patch 8 fixes a possible race condition due to v4l2_async_register_subdev_sensor being called too early in ov4689_probe, and patch 9 migrates power management to PM autosuspend. Patches 11-14 expose more sensor controls to the userspace, such as (read-write) HBLANK, VFLIP/HFLIP, digital gain, and color balance. Patch 17 implements configurable analogue crop rectangle via .set_selection callback. And finally, patch 20 enables 2x2 binning option. It should be noted that publicly available sensor documentation is lacking description of many registers and their value ranges, so a lot of values had to be found by experimentation. Changes in v2: - collect Laurent's r-b's - squash together "CCI conversion" and "Set gain in one 16 bit write" - use ctrl->val in ov4689_set_ctrl - rename try_fmt to fmt in ov4689_init_cfg and drop corresponding comment - rebase on top of media-stage and rename init_cfg->init_state - sort register definitions by address throughout the whole series - fix number of controls hint in v4l2_ctrl_handler_init - make all hexadecimal constants lowercase - disable runtime pm in probe error path - implement pm autosuspend Mikhail Rudenko (20): media: i2c: ov4689: Clean up and annotate the register table media: i2c: ov4689: Sort register definitions by address media: i2c: ov4689: Fix typo in a comment media: i2c: ov4689: CCI conversion media: i2c: ov4689: Remove i2c_client from ov4689 struct media: i2c: ov4689: Refactor ov4689_set_ctrl media: i2c: ov4689: Use sub-device active state media: i2c: ov4689: Enable runtime PM before registering sub-device media: i2c: ov4689: Use runtime PM autosuspend media: i2c: ov4689: Remove max_fps field from struct ov4689_mode media: i2c: ov4689: Make horizontal blanking configurable media: i2c: ov4689: Implement vflip/hflip controls media: i2c: ov4689: Implement digital gain control media: i2c: ov4689: Implement manual color balance controls media: i2c: ov4689: Move pixel array size out of struct ov4689_mode media: i2c: ov4689: Set timing registers programmatically media: i2c: ov4689: Configurable analogue crop media: i2c: ov4689: Eliminate struct ov4689_mode media: i2c: ov4689: Refactor ov4689_s_stream media: i2c: ov4689: Implement 2x2 binning drivers/media/i2c/Kconfig | 1 + drivers/media/i2c/ov4689.c | 964 +++++++++++++++++++++++-------------- 2 files changed, 592 insertions(+), 373 deletions(-) -- 2.43.0
Comments
Hi, On 2023-12-18 at 20:40 +03, Mikhail Rudenko <mike.rudenko@gmail.com> wrote: > Hi, > > This series contains refactoring and new features implementation for > the Omnivision OV4689 sensor driver. Specifically, patches 1, 2, 3, 5, > 6, 10, 15, 16, 18, and 19 are refactorings, and are not supposed to > introduce any functional change. Patches 4 and 7 perform migration to > CCI helpers and subdevice active state respectively, and should not > introduce any hardware- and/or user-visible change either. Patch 8 > fixes a possible race condition due to v4l2_async_register_subdev_sensor > being called too early in ov4689_probe, and patch 9 migrates power > management to PM autosuspend. > > Patches 11-14 expose more sensor controls to the userspace, such as > (read-write) HBLANK, VFLIP/HFLIP, digital gain, and color > balance. Patch 17 implements configurable analogue crop rectangle via > .set_selection callback. And finally, patch 20 enables 2x2 binning > option. It should be noted that publicly available sensor > documentation is lacking description of many registers and their value > ranges, so a lot of values had to be found by experimentation. Gentle ping on this series. Anything I can do to help getting it reviewed and merged? Maybe split patches 15-20 which implement cropping and binning and change the driver away from register list based model into a separate series? Anyone? > Changes in v2: > - collect Laurent's r-b's > - squash together "CCI conversion" and "Set gain in one 16 bit write" > - use ctrl->val in ov4689_set_ctrl > - rename try_fmt to fmt in ov4689_init_cfg and drop corresponding comment > - rebase on top of media-stage and rename init_cfg->init_state > - sort register definitions by address throughout the whole series > - fix number of controls hint in v4l2_ctrl_handler_init > - make all hexadecimal constants lowercase > - disable runtime pm in probe error path > - implement pm autosuspend > > Mikhail Rudenko (20): > media: i2c: ov4689: Clean up and annotate the register table > media: i2c: ov4689: Sort register definitions by address > media: i2c: ov4689: Fix typo in a comment > media: i2c: ov4689: CCI conversion > media: i2c: ov4689: Remove i2c_client from ov4689 struct > media: i2c: ov4689: Refactor ov4689_set_ctrl > media: i2c: ov4689: Use sub-device active state > media: i2c: ov4689: Enable runtime PM before registering sub-device > media: i2c: ov4689: Use runtime PM autosuspend > media: i2c: ov4689: Remove max_fps field from struct ov4689_mode > media: i2c: ov4689: Make horizontal blanking configurable > media: i2c: ov4689: Implement vflip/hflip controls > media: i2c: ov4689: Implement digital gain control > media: i2c: ov4689: Implement manual color balance controls > media: i2c: ov4689: Move pixel array size out of struct ov4689_mode > media: i2c: ov4689: Set timing registers programmatically > media: i2c: ov4689: Configurable analogue crop > media: i2c: ov4689: Eliminate struct ov4689_mode > media: i2c: ov4689: Refactor ov4689_s_stream > media: i2c: ov4689: Implement 2x2 binning > > drivers/media/i2c/Kconfig | 1 + > drivers/media/i2c/ov4689.c | 964 +++++++++++++++++++++++-------------- > 2 files changed, 592 insertions(+), 373 deletions(-) -- Best regards, Mikhail Rudenko
Hi Mikhail, On Wed, Feb 21, 2024 at 06:02:15PM +0300, Mikhail Rudenko wrote: > > Hi, > > On 2023-12-18 at 20:40 +03, Mikhail Rudenko <mike.rudenko@gmail.com> wrote: > > > Hi, > > > > This series contains refactoring and new features implementation for > > the Omnivision OV4689 sensor driver. Specifically, patches 1, 2, 3, 5, > > 6, 10, 15, 16, 18, and 19 are refactorings, and are not supposed to > > introduce any functional change. Patches 4 and 7 perform migration to > > CCI helpers and subdevice active state respectively, and should not > > introduce any hardware- and/or user-visible change either. Patch 8 > > fixes a possible race condition due to v4l2_async_register_subdev_sensor > > being called too early in ov4689_probe, and patch 9 migrates power > > management to PM autosuspend. > > > > Patches 11-14 expose more sensor controls to the userspace, such as > > (read-write) HBLANK, VFLIP/HFLIP, digital gain, and color > > balance. Patch 17 implements configurable analogue crop rectangle via > > .set_selection callback. And finally, patch 20 enables 2x2 binning > > option. It should be noted that publicly available sensor > > documentation is lacking description of many registers and their value > > ranges, so a lot of values had to be found by experimentation. > > Gentle ping on this series. Anything I can do to help getting it > reviewed and merged? Maybe split patches 15-20 which implement cropping > and binning and change the driver away from register list based model > into a separate series? Anyone? Oops, my bad. I'll review these shortly. I can already tell there's not much to do though.
On Fri, Feb 23, 2024 at 08:15:41AM +0000, Sakari Ailus wrote: > Hi Mikhail, > > On Wed, Feb 21, 2024 at 06:02:15PM +0300, Mikhail Rudenko wrote: > > > > Hi, > > > > On 2023-12-18 at 20:40 +03, Mikhail Rudenko <mike.rudenko@gmail.com> wrote: > > > > > Hi, > > > > > > This series contains refactoring and new features implementation for > > > the Omnivision OV4689 sensor driver. Specifically, patches 1, 2, 3, 5, > > > 6, 10, 15, 16, 18, and 19 are refactorings, and are not supposed to > > > introduce any functional change. Patches 4 and 7 perform migration to > > > CCI helpers and subdevice active state respectively, and should not > > > introduce any hardware- and/or user-visible change either. Patch 8 > > > fixes a possible race condition due to v4l2_async_register_subdev_sensor > > > being called too early in ov4689_probe, and patch 9 migrates power > > > management to PM autosuspend. > > > > > > Patches 11-14 expose more sensor controls to the userspace, such as > > > (read-write) HBLANK, VFLIP/HFLIP, digital gain, and color > > > balance. Patch 17 implements configurable analogue crop rectangle via > > > .set_selection callback. And finally, patch 20 enables 2x2 binning > > > option. It should be noted that publicly available sensor > > > documentation is lacking description of many registers and their value > > > ranges, so a lot of values had to be found by experimentation. > > > > Gentle ping on this series. Anything I can do to help getting it > > reviewed and merged? Maybe split patches 15-20 which implement cropping > > and binning and change the driver away from register list based model > > into a separate series? Anyone? > > Oops, my bad. I'll review these shortly. I can already tell there's not > much to do though. Done.
Hi Mikhail, Thank you for the patch. On Mon, Dec 18, 2023 at 08:40:40PM +0300, Mikhail Rudenko wrote: > Remove repetitive pm_runtime_put calls in ov4689_s_stream function, > and call pm_runtime_put once at the end of the "on" branch if any > error occurred. > > Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com> > --- > drivers/media/i2c/ov4689.c | 29 ++++++++++------------------- > 1 file changed, 10 insertions(+), 19 deletions(-) > > diff --git a/drivers/media/i2c/ov4689.c b/drivers/media/i2c/ov4689.c > index e997c3231e85..884761d02119 100644 > --- a/drivers/media/i2c/ov4689.c > +++ b/drivers/media/i2c/ov4689.c > @@ -555,35 +555,26 @@ static int ov4689_s_stream(struct v4l2_subdev *sd, int on) > ov4689_common_regs, > ARRAY_SIZE(ov4689_common_regs), > NULL); > - if (ret) { > - pm_runtime_put_sync(dev); > - goto unlock_and_return; > - } > + if (ret) > + goto cleanup_pm; > > ret = ov4689_setup_timings(ov4689, sd_state); > - if (ret) { > - pm_runtime_put(dev); > - goto unlock_and_return; > - } > + if (ret) > + goto cleanup_pm; > > ret = ov4689_setup_blc_anchors(ov4689, sd_state); > - if (ret) { > - pm_runtime_put(dev); > - goto unlock_and_return; > - } > + if (ret) > + goto cleanup_pm; > > ret = __v4l2_ctrl_handler_setup(&ov4689->ctrl_handler); > - if (ret) { > - pm_runtime_put_sync(dev); > - goto unlock_and_return; > - } > + if (ret) > + goto cleanup_pm; > > ret = cci_write(ov4689->regmap, OV4689_REG_CTRL_MODE, > OV4689_MODE_STREAMING, NULL); > - if (ret) { > +cleanup_pm: A label within an if branch isn't great, readability-wise :-S Could we maybe split the ov4687_s_stream() function in two (streamon and streamoff, or similar names) ? You would then have a single pm_runtime_put_sync() call in ov4689_s_stream(), in the error handling path for the streamon function call. > + if (ret) > pm_runtime_put_sync(dev); > - goto unlock_and_return; > - } > } else { > cci_write(ov4689->regmap, OV4689_REG_CTRL_MODE, > OV4689_MODE_SW_STANDBY, NULL);
Hi Sakari, On 2024-02-23 at 08:43 GMT, Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > On Fri, Feb 23, 2024 at 08:15:41AM +0000, Sakari Ailus wrote: >> Hi Mikhail, >> >> On Wed, Feb 21, 2024 at 06:02:15PM +0300, Mikhail Rudenko wrote: >> > >> > Hi, >> > >> > On 2023-12-18 at 20:40 +03, Mikhail Rudenko <mike.rudenko@gmail.com> wrote: >> > >> > > Hi, >> > > >> > > This series contains refactoring and new features implementation for >> > > the Omnivision OV4689 sensor driver. Specifically, patches 1, 2, 3, 5, >> > > 6, 10, 15, 16, 18, and 19 are refactorings, and are not supposed to >> > > introduce any functional change. Patches 4 and 7 perform migration to >> > > CCI helpers and subdevice active state respectively, and should not >> > > introduce any hardware- and/or user-visible change either. Patch 8 >> > > fixes a possible race condition due to v4l2_async_register_subdev_sensor >> > > being called too early in ov4689_probe, and patch 9 migrates power >> > > management to PM autosuspend. >> > > >> > > Patches 11-14 expose more sensor controls to the userspace, such as >> > > (read-write) HBLANK, VFLIP/HFLIP, digital gain, and color >> > > balance. Patch 17 implements configurable analogue crop rectangle via >> > > .set_selection callback. And finally, patch 20 enables 2x2 binning >> > > option. It should be noted that publicly available sensor >> > > documentation is lacking description of many registers and their value >> > > ranges, so a lot of values had to be found by experimentation. >> > >> > Gentle ping on this series. Anything I can do to help getting it >> > reviewed and merged? Maybe split patches 15-20 which implement cropping >> > and binning and change the driver away from register list based model >> > into a separate series? Anyone? >> >> Oops, my bad. I'll review these shortly. I can already tell there's not >> much to do though. > > Done. Thanks for the prompt review! I'll wait a few days to collect more comments (especially on patches 17, 18, 20) and then post v3. -- Best regards, Mikhail Rudenko
Hi Laurent, and thanks for the review! On 2024-02-23 at 13:48 +02, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote: > Hi Mikhail, > > Thank you for the patch. > > On Mon, Dec 18, 2023 at 08:40:40PM +0300, Mikhail Rudenko wrote: >> Remove repetitive pm_runtime_put calls in ov4689_s_stream function, >> and call pm_runtime_put once at the end of the "on" branch if any >> error occurred. >> >> Signed-off-by: Mikhail Rudenko <mike.rudenko@gmail.com> >> --- >> drivers/media/i2c/ov4689.c | 29 ++++++++++------------------- >> 1 file changed, 10 insertions(+), 19 deletions(-) >> >> diff --git a/drivers/media/i2c/ov4689.c b/drivers/media/i2c/ov4689.c >> index e997c3231e85..884761d02119 100644 >> --- a/drivers/media/i2c/ov4689.c >> +++ b/drivers/media/i2c/ov4689.c >> @@ -555,35 +555,26 @@ static int ov4689_s_stream(struct v4l2_subdev *sd, int on) >> ov4689_common_regs, >> ARRAY_SIZE(ov4689_common_regs), >> NULL); >> - if (ret) { >> - pm_runtime_put_sync(dev); >> - goto unlock_and_return; >> - } >> + if (ret) >> + goto cleanup_pm; >> >> ret = ov4689_setup_timings(ov4689, sd_state); >> - if (ret) { >> - pm_runtime_put(dev); >> - goto unlock_and_return; >> - } >> + if (ret) >> + goto cleanup_pm; >> >> ret = ov4689_setup_blc_anchors(ov4689, sd_state); >> - if (ret) { >> - pm_runtime_put(dev); >> - goto unlock_and_return; >> - } >> + if (ret) >> + goto cleanup_pm; >> >> ret = __v4l2_ctrl_handler_setup(&ov4689->ctrl_handler); >> - if (ret) { >> - pm_runtime_put_sync(dev); >> - goto unlock_and_return; >> - } >> + if (ret) >> + goto cleanup_pm; >> >> ret = cci_write(ov4689->regmap, OV4689_REG_CTRL_MODE, >> OV4689_MODE_STREAMING, NULL); >> - if (ret) { >> +cleanup_pm: > > A label within an if branch isn't great, readability-wise :-S Could we > maybe split the ov4687_s_stream() function in two (streamon and > streamoff, or similar names) ? You would then have a single > pm_runtime_put_sync() call in ov4689_s_stream(), in the error handling > path for the streamon function call. Okay, will split it in v3. >> + if (ret) >> pm_runtime_put_sync(dev); >> - goto unlock_and_return; >> - } >> } else { >> cci_write(ov4689->regmap, OV4689_REG_CTRL_MODE, >> OV4689_MODE_SW_STANDBY, NULL); -- Best regards, Mikhail Rudenko