Re: [PATCH] ACPI: Flag use of ACPI and ACPI idioms for power supplies to regulator API

[Guenter Roeck <linux@roeck-us.net>]

On 01/26/2014 04:32 PM, 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:
>

Couple of scenarios where I don't entirely see how this is expected to work.

- A system which uses CPU cards which sit on a carrier card. The CPU is shared
   across multiple carrier cards, and built by an OEM. It supports and uses ACPI,
   but ACPI only knows about the CPU card and not the carrier cards, and thus does
   not know anything about the carrier card power or regulator requirements.
- A system which supports a large number of complex OIR capable cards.
   The card connector includes GPIO pins, I2C busses, PCIe busses, and various other
   functionality such as SERDES lines. The card functionality is determined by the
   card ID and not known by the time the system ships.
- A USB-I2C or USB-SPI adapter connected to a standard PC. Any I2C or SPI device
   can be connected to the I2C or SPI ports.

How is the firmware expected to know about the various devices ? Is the answer
"sorry, this scenario is not supported by the kernel" ?

Guenter