From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 43DE9ECE564 for ; Tue, 10 Sep 2024 10:13:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=g8JhSUNRb/I6C8Ti293AUw4Uh2F9g45ZJwpxWcl+8cI=; b=gKSW4awMkjvnnqGLavxE0OUNam KVR3h/3GA76FyVJkORSueVcxH1SuhntqyPsBFjl54F5tT7NSPB6uPi+cS+aLcideaCjBQfV/cRi+v Q/WDN5tVZpp3F1O1jUbAO57/hh+RKdtlh4Pb6vvLuAKwSVzZNI7jiiVbAN4Jqhn+Sn50/xG4Ah6k7 v3zcawg8niZXKFeB5qaMfLSgpEAVupHfQ9cVDKqA5575X3f8TEMA35r57rk7fJmmf/b28nQCRDVLF TUztx+2Gz7yySzX7yCPDTTjsCmmFbK2+ezps/m2H1oT7QCAyv3hs/yeCiRBB/ocUeQDJTDEIa+qIs qhpZM//A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1snxs8-00000005C4d-3hI9; Tue, 10 Sep 2024 10:13:20 +0000 Received: from perceval.ideasonboard.com ([213.167.242.64]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1snxr2-00000005Bm9-1qTk; Tue, 10 Sep 2024 10:12:13 +0000 Received: from pendragon.ideasonboard.com (213-229-8-243.static.upcbusiness.at [213.229.8.243]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id BCE023EA; Tue, 10 Sep 2024 12:10:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1725963054; bh=jHkdQsU3ps+hikIKdb68XuvJ/yFL2ruqKEOCQTmU4+Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=XHwC8iIn9ZU8OrxR9AMtSFmU2IG/v4n73gF2U4p2VU7sjWnl7UcvS6bI9OUe9BT6i K7ehaZ+YSdJV6gJuEc16gfkiqNEtqEhpcSuw0MtwDK2ve/zVNU9DTABlyLH/Yne7S7 fgLrX6v3JjwYc2YUC3f9zfdEN5UuhAQNgqzcz3qM= Date: Tue, 10 Sep 2024 13:11:37 +0300 From: Laurent Pinchart To: Tomi Valkeinen Cc: Jacopo Mondi , Sakari Ailus , Mauro Carvalho Chehab , Raspberry Pi Kernel Maintenance , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Florian Fainelli , Broadcom internal kernel review list , oe-kbuild-all@lists.linux.dev, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Naushir Patuck , Kieran Bingham , kernel test robot Subject: Re: [PATCH v4 3/4] media: raspberrypi: Add support for RP1-CFE Message-ID: <20240910101137.GD6996@pendragon.ideasonboard.com> References: <20240905111120.GK16183@pendragon.ideasonboard.com> <40cc1e95-b9fc-4c27-9428-1698d0bf9d25@ideasonboard.com> <763b3147-d7cb-44a7-b73b-8f7f4fd622ab@ideasonboard.com> <20240909134516.GA9448@pendragon.ideasonboard.com> <49e375a3-d8e4-4b58-9456-1e6395b02a07@ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <49e375a3-d8e4-4b58-9456-1e6395b02a07@ideasonboard.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240910_031212_639456_51A6A514 X-CRM114-Status: GOOD ( 21.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 10, 2024 at 12:56:38PM +0300, Tomi Valkeinen wrote: > On 10/09/2024 12:19, Jacopo Mondi wrote: > > > However, I think this current patch is correct (assuming the above > > reasoning on i2c sensor drivers is correct) and doesn't require > > CONFIG_PM, so I would be tempted to keep this version. > > I think the existence of this discussion alone proves my point that we > should only support PM-case, unless !PM is a requirement =). For me it proves there's a dire need to document the runtime PM API in a way that a human could understand :-) > But if you do want to keep !PM: > > Is there a reason why not mark the device as active with > pm_runtime_set_active() after calling pispbe_runtime_resume and before > accessing the device? That feels like the most logical way to use the > function, and it would be right regardless whether the core will enable > the parents before probe() or not. Does pm_runtime_set_active() resume the parent ? > And not related to the BE or CFE drivers, but it strikes me odd that to > support PM and !PM we need to play with these tricks. I think the core > should just do the right thing if the driver does pm_runtime_get_sync() > even with !PM (although maybe the time has passed to be able to do that). The runtime PM concepts are nice, but the API is wrong in my opinion. Instead of being designed to expose the internals of runtime PM, it should focus on usability from a driver point of view first. -- Regards, Laurent Pinchart