Some Bay Trail devices use a GPI1 regulator field (address 0x4c) in
their 0x8d power OpRegion, add support for this.

This fixes AE_BAD_PARAMETER errors getting thrown on these devices and
fixes these errors causing these devices to not suspend.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The power table addresses should be contiguous, but there was a hole
where 0x34 was missing. On most devices this is not a problem as
addresses above 0x34 are used for the BUC# convertors which are not
used in the DSDTs I've access to but after the BUC# convertors
there is a field named GPI1 in the DSTDs, which does get used in some
cases and ended up turning BUC6 on and off due to the wrong addresses,
resulting in turning the entire device off (or causing it to reboot).

Removing the hole in the addresses fixes this, fixing one of my
Bay Trail tablets turning off while booting the mainline kernel.

While at it add comments with the field names used in the DSDTs to
make it easier to compare the register and bits used at each address
with the datasheet.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The intel_pmic_xpower code provides an OPRegion handler, which must be
available before other drivers using it are loaded, which can only be
ensured if both the mfd and opregion drivers are built in, which is why
the Kconfig option for intel_pmic_xpower is a bool.

The use of IIO is causing trouble for generic distro configs here as
distros will typically want to build IIO drivers as modules and there
really is no reason to use IIO here. The reading of the ADC value is a
single regmap_bulk_read, which is already protected against races by
the regmap-lock.

This commit removes the use of IIO, allowing distros to enable the
driver without needing to built IIO in and also actually simplifies
the code.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Kconfig currently controlling compilation of these files are:

drivers/acpi/Kconfig:menuconfig PMIC_OPREGION
drivers/acpi/Kconfig:   bool "PMIC (Power Management Integrated Circuit) operation region support"

drivers/acpi/Kconfig:config BXT_WC_PMIC_OPREGION
drivers/acpi/Kconfig:   bool "ACPI operation region support for BXT WhiskeyCove PMIC"

drivers/acpi/Kconfig:config XPOWER_PMIC_OPREGION
drivers/acpi/Kconfig:   bool "ACPI operation region support for XPower AXP288 PMIC"

...meaning they currently are not being built as a module by anyone.

Lets remove the couple traces of modular infrastructure use, so that
when reading the code there is no doubt it is builtin-only.

We delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

One file was using module_init.  Since module_init translates to
device_initcall in the non-modular case, the init ordering remains
unchanged with this commit.

In one case we replace the module.h with export.h since that file
is exporting some symbols, but does not use __init.  The other two
are using __init and so module.h gets replaced with init.h there.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The same virtual GPIO strategy is also used for the AXP288 PMIC in that
various control methods that are used to do power rail handling and
sensor reading/setting will touch GPIO fields defined under the PMIC
device. The GPIO fileds are only defined by the ACPI code while the
actual hardware doesn't really have a GPIO controller, but to make those
control method execution succeed, we have to install a GPIO handler for
the PMIC device handle. Since we do not need the virtual GPIO strategy,
we can simply do nothing in that handler.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The Baytrail-T-CR platform firmware has defined two customized operation
regions for PMIC chip Dollar Cove XPower - one is for power resource
handling and one is for thermal just like the CrystalCove one. This patch
adds support for them on top of the common PMIC opregion region code.
Signed-off-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>