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 533B1EB64DE for ; Tue, 10 Sep 2024 10:23:29 +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-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SrdsMfRcNwUjulc/f+R9oCiabepp1pDQPw1xATOIXPg=; b=ij5Fuk6Wr9AFGkkCDwWsBJ6cuX IhJTmVc/YxULghx/HcaJIby5YjljFVPZqpNiIrMJz5JjHkykfVcotsxSQEPp+9Yc+vsr1gUJhq+kH VnUBH4wP9XxPgT9S12AMkDudbiLiE1q319azny2z5K1wGcIMD9mgoQM4Vf29G18mw0TruRNYGGWlh 5+tBhvz3g4ZFEK8lpKAB384WFus5vebNMBo1mRDsyhd3Jnkw+JYIe8u3Dh0ZAFYFdOOCfiVPBnqM2 Gs/qJ7UpEppCrmIZR/J/V5YLaArKkm71dJE3b/1gZfdSQdfgWv50z0uw6t8pnflHeonb64mKlZsvU IwFPk/kA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sny1k-00000005DrA-3yY3; Tue, 10 Sep 2024 10:23:16 +0000 Received: from mgamail.intel.com ([192.198.163.7]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sny0Y-00000005Dil-25nL; Tue, 10 Sep 2024 10:22:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1725963722; x=1757499722; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=UrcW67GFtZitZSckWZ2pJka2BxV3vmkG5mbEl6ujStw=; b=ANtSZ2qxImfcQbmAkATG+s2Q+778fQCSPF+oAbmPcGVS3ouCDsl5ClR6 MXdgJlooDKULV31UQKcur+ZBZFlYUFFLNCFNTZqvqWD3IqwVK9ErNWRLc Ms/Aqf/mxTTRpjOpc8037XB/6mkyU1LR3h3css99KQLY499CWgVO26FCq GuWzslejsXHz+0DnDSl4M+Hx/66JWW5PxHLiT5TFYMi+2iFvCEzkB20jM 4gszIqmGkrQdkxiJ0U/kVBa4ZBxFtNrP3q649xzkPuyV30FGfbvK3kpD/ Tisr6RiIqSvjoekYzt3f45/Vrk5j979DG0KFe3e0AxYxKCXymBNFO4+Ld g==; X-CSE-ConnectionGUID: hNhYPLUfT7O8GzVsQnSXpQ== X-CSE-MsgGUID: WxpIvk90QX+8xYiuc3wnNQ== X-IronPort-AV: E=McAfee;i="6700,10204,11190"; a="50115031" X-IronPort-AV: E=Sophos;i="6.10,216,1719903600"; d="scan'208";a="50115031" Received: from orviesa010.jf.intel.com ([10.64.159.150]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2024 03:22:02 -0700 X-CSE-ConnectionGUID: 6btEr7/7TtGJVjsOVFXSrQ== X-CSE-MsgGUID: g83Bpbn9QcSDxmE+uNa4qg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,216,1719903600"; d="scan'208";a="66785837" Received: from turnipsi.fi.intel.com (HELO kekkonen.fi.intel.com) ([10.237.72.44]) by orviesa010-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Sep 2024 03:21:57 -0700 Received: from kekkonen.localdomain (localhost [127.0.0.1]) by kekkonen.fi.intel.com (Postfix) with ESMTP id 9D70611F83C; Tue, 10 Sep 2024 13:21:54 +0300 (EEST) Date: Tue, 10 Sep 2024 10:21:54 +0000 From: Sakari Ailus To: Laurent Pinchart Cc: Tomi Valkeinen , Jacopo Mondi , 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: References: <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> <20240910101137.GD6996@pendragon.ideasonboard.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240910101137.GD6996@pendragon.ideasonboard.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240910_032202_575536_42043E33 X-CRM114-Status: GOOD ( 30.78 ) 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 Hi Laurent, On Tue, Sep 10, 2024 at 01:11:37PM +0300, Laurent Pinchart wrote: > 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 ? No, it simply sets the device's runtime PM status. > > > 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. It's been moving a little bit to that direction, largely with new helper functions. I²C devices have been powered on for probe since commit a76e9bd89ae70 . Relation to runtime PM wasn't considered at the time, apparently. -- Kind regards, Sakari Ailus