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 48C211A8BEB; Wed, 31 Jul 2024 08:30:21 +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=1722414623; cv=none; b=PIGA8wUOJHrLNoYuAaLA53Ba0fx9Hos+SXjOoqUL5HcPhiTcpy/Ps0O3d3bH4ObY9tqUlpzbx1UHl4S1zt8TQUeHPsHYvAPM79RE/RLxMdA9cPN2I/kCAUksz5ioCghsKvIArG1IxhoslMAgyMZPwmf/1C8fJ2QOBP5nBWzsf9s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722414623; c=relaxed/simple; bh=pjw/UlZpX9tFuIUC4j7+LvlinTu1b35XlaxhKH1fHqU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fvkp9zfkub5ba7e1NsSGPuos7Fz8gs/ftLXxURPzA8/xDxvtZmDZay4LKvEwX3SH3KxYzYqWi4Jszxwk1S5Dr6WJnANnEvZ68z2MST92SWqbF9rAiDXkV08hVD3HJg4cYROfj5Bnw7L8dEDEjPcT+bB7p8G/yR8qobqYAEpd7p8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (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=cRDIygWW; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (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="cRDIygWW" Received: from pendragon.ideasonboard.com (81-175-209-231.bb.dnainternet.fi [81.175.209.231]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 61D527E4; Wed, 31 Jul 2024 10:29:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1722414571; bh=pjw/UlZpX9tFuIUC4j7+LvlinTu1b35XlaxhKH1fHqU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cRDIygWWqC6vaEQRZBb28o6at6wEtrrWEUJ4QwiDEn7WmDD+3T4tZGivw207OGM39 0HJAABhxW8BfhBQ4r+WGCwI96gUYTL6SgnAEyljLrjNPw1s+pQxMEaG0D9JKvYvPc/ TzHaCvbqEYDICyL1i4392/aZtvtO3BKnPcKa7iK4= Date: Wed, 31 Jul 2024 11:29:58 +0300 From: Laurent Pinchart To: CK Hu =?utf-8?B?KOiDoeS/iuWFiSk=?= Cc: "mchehab@kernel.org" , "conor+dt@kernel.org" , "robh@kernel.org" , Andy Hsieh =?utf-8?B?KOisneaZuueakyk=?= , "jstephan@baylibre.com" , "matthias.bgg@gmail.com" , "krzk+dt@kernel.org" , "angelogioacchino.delregno@collabora.com" , "linux-kernel@vger.kernel.org" , "linux-mediatek@lists.infradead.org" , "linux-media@vger.kernel.org" , "devicetree@vger.kernel.org" , "paul.elder@ideasonboard.com" , "linux-arm-kernel@lists.infradead.org" , "fsylvestre@baylibre.com" , "pnguyen@baylibre.com" Subject: Re: [PATCH v6 4/5] media: platform: mediatek: isp_30: add mediatek ISP3.0 camsv Message-ID: <20240731082958.GM8146@pendragon.ideasonboard.com> References: <20240729-add-mtk-isp-3-0-support-v6-0-c374c9e0c672@baylibre.com> <20240729-add-mtk-isp-3-0-support-v6-4-c374c9e0c672@baylibre.com> <6a7467cde347600015078fe7aa25c4b46c45e96d.camel@mediatek.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6a7467cde347600015078fe7aa25c4b46c45e96d.camel@mediatek.com> Hi CK, On Wed, Jul 31, 2024 at 02:59:51AM +0000, CK Hu (胡俊光) wrote: > On Mon, 2024-07-29 at 16:48 +0200, Julien Stephan wrote: > > From: Phi-bang Nguyen > > > > This driver provides a path to bypass the SoC ISP so that image data > > coming from the SENINF can go directly into memory without any image > > processing. This allows the use of an external ISP. > > > > Signed-off-by: Phi-bang Nguyen > > Signed-off-by: Florian Sylvestre > > [Paul Elder fix irq locking] > > Signed-off-by: Paul Elder > > Co-developed-by: Laurent Pinchart > > Signed-off-by: Laurent Pinchart > > Co-developed-by: Julien Stephan > > Signed-off-by: Julien Stephan > > --- > > [snip] > > > + > > +static void mtk_cam_cmos_vf_enable(struct mtk_cam_dev *cam_dev, > > + bool enable, bool pak_en) > > +{ > > +struct device *dev = cam_dev->dev; > > + > > +if (pm_runtime_get_sync(dev) < 0) { > > +dev_err(dev, "failed to get pm_runtime\n"); > > +goto out; > > +} > > + > > +if (enable) > > +cam_dev->hw_functions->mtk_cam_cmos_vf_hw_enable(cam_dev); > > Directly call mtk_camsv30_cmos_vf_hw_enable(). The goal, when this was developed, was to support multiple generations of hardware with a single driver. I think it's a worthwhile goal, but at the same time, I'm not sure that will ever happen as I'm not aware of plans to upstream Genio 350 and 500 support (which is a bad sad, as it's more or less working out-of-tree). I'm thus fine either way, and if we think the most likely outcome is that this driver will only support Genio 300, I'm fine dropping the abstraction layer. > > +else > > +cam_dev->hw_functions->mtk_cam_cmos_vf_hw_disable(cam_dev); > > Directly call mtk_camsv30_cmos_vf_hw_disable(). > > > + > > +out: > > +pm_runtime_put_autosuspend(dev); > > +} > > + -- Regards, Laurent Pinchart