public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Mark Brown <broonie@kernel.org>
Cc: Len Brown <lenb@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-acpi@vger.kernel.org, linaro-kernel@lists.linaro.org,
	Guenter Roeck <linux@roeck-us.net>,
	Mark Brown <broonie@linaro.org>
Subject: Re: [PATCH] ACPI: Flag use of ACPI and ACPI idioms for power supplies to regulator API
Date: Mon, 27 Jan 2014 09:25:09 +0100	[thread overview]
Message-ID: <20140127092509.24844e25@endymion.delvare> (raw)
In-Reply-To: <1390782734-10131-1-git-send-email-broonie@kernel.org>

On Mon, 27 Jan 2014 00:32:14 +0000, Mark Brown wrote:
> From: Mark Brown <broonie@linaro.org>
> 
> 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 <broonie@linaro.org>
> ---
>  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 <linux/proc_fs.h>
>  #include <linux/acpi.h>
>  #include <linux/slab.h>
> +#include <linux/regulator/machine.h>
>  #ifdef CONFIG_X86
>  #include <asm/mpspec.h>
>  #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:

I think it makes sense to have this included in stable kernel trees?

Thanks,
-- 
Jean Delvare

  parent reply	other threads:[~2014-01-27  8:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-27  0:32 [PATCH] ACPI: Flag use of ACPI and ACPI idioms for power supplies to regulator API Mark Brown
2014-01-27  0:54 ` Rafael J. Wysocki
2014-01-27  0:44   ` Mark Brown
2014-01-27 12:54     ` Rafael J. Wysocki
2014-01-27 13:21       ` Mark Brown
2014-01-28  0:06         ` Rafael J. Wysocki
2014-01-28 12:21           ` Mark Brown
2014-01-28 21:55             ` Rafael J. Wysocki
2014-01-27  8:25 ` Jean Delvare [this message]
2014-01-27 10:43   ` Mark Brown
2014-01-27 14:58 ` Guenter Roeck
2014-01-27 16:25   ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140127092509.24844e25@endymion.delvare \
    --to=khali@linux-fr.org \
    --cc=broonie@kernel.org \
    --cc=broonie@linaro.org \
    --cc=lenb@kernel.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=rjw@rjwysocki.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox