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 436CEECE582 for ; Tue, 10 Sep 2024 10:10:25 +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=QQOu1vvGQJicbTpbpMDvCDOa31OchbyNm5OXOsGRD0A=; b=Dga1sfV/ypkVLhbXoxajUSQksv HVT7FtJkvXpglYfzYwjq5+sh8ZmSpHhTcbvGAXZ6ONGn09C+A2h0QW3pWFaqfjtSyOOgzRnDIf/ah b+C4PGG+BNKsJLA9zeD28/UbxVQGVt65TrvPj6m8SzOn5SJV3eyDNP5z5RtBL6owqryRglEt8SzNq uaPwfXFZQpkitd7VFGG+e+u5QWgWPhy/CNpxClTT8niqMjAxp3YN/6mSTQJrsK/AR0DyT14eMaKJ8 Ay5AS0Kld3X0QQwkGmzkNKLumtyax38d9gWEi4PIascb3wcG0bOinYHhr303bS2iUAFRcbFdYx0ul n7rTqPbA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1snxp7-00000005BLj-2rQY; Tue, 10 Sep 2024 10:10:13 +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 1snxlj-00000005AMO-0tTk; Tue, 10 Sep 2024 10:06:44 +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 042433EA; Tue, 10 Sep 2024 12:05:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1725962725; bh=qRP4ALNKD5dj2TC3hY3hzYkODtfa0xHzrUb9GlW6tMw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t6MrLWeaJ8twnv04KN60ubMnSKaq4QwAMx2wMRjVLXkjDgd2DGF5QXnhGdhbTkp8p ZgR7aY7RLWqVo6z7XvPrKLTRzpS4cXch5Hvtro00qj3sGHh+OU+J8OxjEJHpcoM0GY qdG/615/JLB3P4z8vKS3VcdTGfbwPRgrrHf3Gwcs= Date: Tue, 10 Sep 2024 13:06:08 +0300 From: Laurent Pinchart To: Sakari Ailus Cc: Jacopo Mondi , Tomi Valkeinen , 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: <20240910100608.GC6996@pendragon.ideasonboard.com> References: <763b3147-d7cb-44a7-b73b-8f7f4fd622ab@ideasonboard.com> <20240909134516.GA9448@pendragon.ideasonboard.com> <6u2g4v4ktt543sy5jlp3vonemhzhrwyz2liikg6jb2kx3h7jao@z6s233clqwqk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240910_030643_418491_84C99D3F X-CRM114-Status: GOOD ( 60.81 ) 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 09:55:20AM +0000, Sakari Ailus wrote: > On Tue, Sep 10, 2024 at 11:42:06AM +0200, Jacopo Mondi wrote: > > > > > > > > Ah, I missed that one. > > > > > > > > > > > > > > > > I don't think it fixes the issue I mentioned. If we have PM enabled, and the > > > > > > > > parent device requires powering up for the child device (BE) to be > > > > > > > > accessible, the driver will crash when calling pispbe_hw_init(). I think you > > > > > > > > should call pm_runtime_set_active() before calling pispbe_runtime_resume(). > > > > > > > > > > > > > > As discussed, this is not a problem currently for BE, but indeed you > > > > > > > have a point. > > > > > > > > I admit the runtime_pm intrinsics are obscure to me, but Laurent just > > > > made me notice something. > > > > > > > > Consider the following scenario > > > > > > > > *) Kernel compiled with CONFIG_PM > > > > *) i2c sensor driver that supports both CONFIG_PM and !CONFIG_PM by: > > > > *) Manually power up the sensor during probe > > > > *) Call pm_runtime_enable() and pm_runtime_set_active() at the end > > > > of the probe routine after having accessed the chip over i2c > > > > (like most, if not all the i2c drivers in mainline do including > > > > ccs) > > > > > > > > All these drivers work, and during the probe routine before accessing > > > > the HW, they don't need to power up the parent i2c controller. > > > > > > This isn't done explicitly by the I²C drivers, indeed but... > > > > > > > > > > > Might it be that during probe() the parent is guaranteed to be enabled ? > > > > > > ...yes. > > > > > > > Unrelated, but I am wrong the driver core calls pm_request_idle() on > > the just probed device ? Does this mean drivers doesn't have to do > > that by themseleves ? (it's not a big deal, as request_idle() doesn't > > change the usage counter) > > Seems like that. This could be omitted from drivers then. Is that guaranteed, or is it an implementation detail that could change at any time ? > > > > I add a look in the driver-core and pm Documentation/ but found > > > > nothing. > > > > > > > > A quick stroll in driver/base/ got me to __device_attach() and it > > > > seems parents are powered up before attaching a driver to a device > > > > (which in my understanding should be what ends up calling probe()). > > > > Clearly I've no real understanding of what I'm talking about when it > > > > comes to driver-core, so take this with a grain of salt. > > > > > > This only works with runtime PM enabled. > > > > It's the CONFIG_PM case that was worrying for Tomi > > > > > > > > > Sad note: most of all the occurrences of "grep set_active" in > > > > > > > drivers/media/platform/ show that set_active() is used as I've done in > > > > > > > my patch > > > > > > > > > > > > > > > However, you said above that "supporting !CONFIG_PM is not that much work". > > > > > > > > Maybe not. But how much work is it to get it right (for both PM and !PM), > > > > > > > > and make sure it stays right? =). > > > > > > > > > > > > > > > > Just my opinion, but if there are zero use cases for the !PM, I would just > > > > > > > > go with "depends on PM" to keep the driver simpler, less bug-prone, and > > > > > > > > easier to maintain. > > > > > > > > > > > > I'm fine with that, and for platform drivers, that's my preferred > > > > > > option. Sakari ? > > > > > > > > > > I'm concerned with your (?) recent finding that many architectures don't > > > > > have support for CONFIG_PM. In this case the device is very unlikely to be > > > > > used outside ARM(64) so I guess it's fine. > > > > > > > > > > > > > Also, this IP is RPi specific, and the !CONFIG_PM case is not used or > > > > tested on Pi. > > > > > > > > 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 understand the current patch does depend on CONFIG_PM: it requires > > > runtime PM to be operational to start the clock, for instance. > > > > Where do you see that ? > > > > This version still calls pispbe_runtime_resume() to power up the IP, > > it doesn't go through runtime_pm: > > https://patchwork.linuxtv.org/project/linux-media/patch/20240904095836.344833-5-jacopo.mondi@ideasonboard.com/ > > cfe_runtime_resume() is only called via runtime PM. > > > Thanks! > > > > > > > > > I don't see a use case for !PM and we confirmed with RPi they don't > > > > > > > need to support it. During the review of a previous version of the BE > > > > > > > driver iirc I've been asked to support !PM but I'm not sure I recall > > > > > > > the reasons. > > > > > > > > > > > > I hope it wasn't me :-) > > > > > > > > > > Me neither. Although it'd be nice: CONFIG_PM isn't a hardware specific > > > > > option as such. As one part of the kernel requires !CONFIG_PM and another > > > > > CONFIG_PM, we can expect problems, at least in principle. > > > > > > > > > > Ideally all architectures would support it so CONFIG_PM could be removed > > > > > and we could say the problem has been solved. :-) -- Regards, Laurent Pinchart