From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2D5B522A4F3; Mon, 13 Jan 2025 13:49:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736776159; cv=none; b=RGPcjjzpc7jORLPDY8ArUJlOSH9WUusxCKCxppdWBbwE8DG7IcujsPE3vNxHtW1d2cmTxW981YLZ9E2JgNs7jif7ehxRCJ6aS0Ddb2Wvvjo/THYrohHyHdbsq/VzOF2Ao1z/dA1Ls9dljsJVWPUq2SvmcxlYgA16e6BBtoxRHwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736776159; c=relaxed/simple; bh=myuRouzYLHW5pKKkFI3W0E4x/ZFfRzNrQHwvAV/0YeI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mEb+w2GhgUkmUgwOjSchMp1ztWW7HRWkD8gUZp3+9Fdy7kis875CmZJqmttPUTLntcaZQ4/YUo1sP5GYMKh9M9bkpDqP4NjtNht1rxPKWxZ/5tzhNzoDWpW146QjJEuoOfkxR8a6zuLy12IOmvrng5gE1ZXK1xaYHnCHWMNgqmU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A6BA612FC; Mon, 13 Jan 2025 05:49:44 -0800 (PST) Received: from bogus (e133711.arm.com [10.1.196.55]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CA8643F673; Mon, 13 Jan 2025 05:49:14 -0800 (PST) Date: Mon, 13 Jan 2025 13:49:12 +0000 From: Sudeep Holla To: Peng Fan Cc: "Peng Fan (OSS)" , "cristian.marussi@arm.com" , Sudeep Holla , "ulf.hansson@linaro.org" , "arm-scmi@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Ranjani Vaidyanathan Subject: Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off Message-ID: References: <20250110061346.2440772-1-peng.fan@oss.nxp.com> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon, Jan 13, 2025 at 11:37:23AM +0000, Peng Fan wrote: > > Subject: Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize > > state as off > > > > On Fri, Jan 10, 2025 at 02:13:46PM +0800, Peng Fan (OSS) wrote: > > > From: Peng Fan > > > > > > Per ARM SCMI Spec DEN0056E, page 16, "The platform may disable a > > > resource if no agent has requested to use that resource." > > > > > > > True, but ... > > > > > Linux Kernel should not rely on a state that it has not requested, so > > > make state as off during initialization. > > > > > > > IIUC, this was done to avoid any transitions if the bootloader like U- > > Boot has turned on the resource and OS can just rely on that stay. > > But if it is not U-Boot turned it on? Not sure if I understand what exactly you mean by that. > Or U-Boot is in a separate agent? > No, it will be same as OS for the SCMI platform/agent as they use/share the same transport. It is hard to distinguish between them. > > Anyways if the resource is not used by any driver/device in the kernel, > > won't it be turned off anyways ? What am I missing ? > > Because the power domain is ON, kernel will not issue SCMI > to platform to request it ON when kernel needs this power domain > on. > Yes, but the agent(via bootloader) has already requested the SCMI platform, so it should be fine. No ? > But in case when kernel is doing some jobs that needs the > power domain ON, SCMI platform might power down the > power domain because kernel agent not request that. > See my comment/question above. -- Regards, Sudeep