From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH] ACPI: Flag use of ACPI and ACPI idioms for power supplies to regulator API Date: Mon, 27 Jan 2014 01:54:49 +0100 Message-ID: <2348079.FWLATJ4QDO@vostro.rjw.lan> References: <1390782734-10131-1-git-send-email-broonie@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Return-path: Received: from v094114.home.net.pl ([79.96.170.134]:51143 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753257AbaA0Akd (ORCPT ); Sun, 26 Jan 2014 19:40:33 -0500 In-Reply-To: <1390782734-10131-1-git-send-email-broonie@kernel.org> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Mark Brown Cc: Len Brown , linux-acpi@vger.kernel.org, linaro-kernel@lists.linaro.org, Jean Delvare , Guenter Roeck , Mark Brown On Monday, January 27, 2014 12:32:14 AM Mark Brown wrote: > From: Mark Brown > > There is currently no facility in ACPI to express the hookup of voltage > regulators, the expectation is that the regulators that exist in the > system will be handled transparently by firmware if they need software > control at all. This means that if for some reason the regulator API is > enabled on such a system it should assume that any supplies that devices > need are provided by the system at all relevant times without any software > intervention. > > Tell the regulator core to make this assumption by calling > regulator_has_full_constraints(). Do this as soon as we know we are using > ACPI so that the information is available to the regulator core as early > as possible. This will cause the regulator core to pretend that there is > an always on regulator supplying any supply that is requested but that has > not otherwise been mapped which is the behaviour expected on a system with > ACPI. > > Should the ability to specify regulators be added in future revisions of > ACPI then once we have support for ACPI mappings in the kernel the same > assumptions will apply. It is also likely that systems will default to a > mode of operation which does not require any interpretation of these > mappings in order to be compatible with existing operating system releases > so it should remain safe to make these assumptions even if the mappings > exist but are not supported by the kernel. > > Signed-off-by: Mark Brown > --- > drivers/acpi/bus.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c > index 384da5ab5955..fcb59c21c68d 100644 > --- a/drivers/acpi/bus.c > +++ b/drivers/acpi/bus.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > #ifdef CONFIG_X86 > #include > #endif > @@ -509,6 +510,14 @@ void __init acpi_early_init(void) > goto error0; > } > > + /* > + * If the system is using ACPI then we can be reasonably > + * confident that any regulators are managed by the firmware > + * so tell the regulator core it has everything it needs to > + * know. > + */ > + regulator_has_full_constraints(); > + > return; > > error0: That's going to be called earlier than it use to be in 3.13 and before. No problems with that? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.