[PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Aaron Lu]

On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
ACPI operation regions defined for the Power Management Integrated Circuit
device, one is for power resource handling and one is for thermal: sensor
temperature reporting, trip point setting, etc. There are different PMIC
chips used on those platforms and though each has the same two operation
regions and functionality, their implementation is different so every PMIC
will need a driver. But since their functionality is similar, some common
code is abstracted into the intel_soc_pmic_opregion.c.

The last version is posted here:
https://lkml.org/lkml/2014/9/8/801

Changes since then:
1 Move to drivers/acpi as discussed on the above thread;
2 Added support for XPower AXP288 PMIC operation region support;
3 Since operation region handler can not be removed(at the moment at least),
  use bool for the two operation region driver configs instead of tristate;
  Another reason to do this is that, with Mika's MFD ACPI support patch, all
  those MFD cell devices created will have the same modalias as their parent's
  so it doesn't make much sense to compile these drivers into modules.

Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
driver XPower AXP288 and iio driver axp288_adc is located.

Aaron Lu (3):
  ACPI / pmic_opregion: support PMIC operation region for CrystalCove
  ACPI / pmic_opregion: support PMIC operation region for XPower AXP288
  ACPI / pmic_opregion: AXP288: support virtual GPIO in ACPI table

[PATCH 1/3] ACPI / pmic_opregion: support PMIC operation region for CrystalCove

[Aaron Lu]

The Baytrail-T platform firmware has defined two customized operation
regions for PMIC chip Crystal Cove - one is for power resource handling
and one is for thermal: sensor temperature reporting, trip point setting,
etc. This patch adds support for them on top of the existing Crystal Cove
PMIC driver.

The reason to split code into a separate file intel_soc_pmic_opregion.c
is that there are more PMIC driver with ACPI operation region support
coming and we can re-use those code. The intel_soc_pmic_opregion_data
structure is created also for this purpose: when we need to support a
new PMIC's operation region, we just need to fill those callbacks and
the two register mapping tables.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
---
 drivers/acpi/Kconfig                               |  17 +
 drivers/acpi/Makefile                              |   3 +
 .../pmic_opregion/intel_soc_pmic_crc_opregion.c    | 216 +++++++++++++
 .../acpi/pmic_opregion/intel_soc_pmic_opregion.c   | 341 +++++++++++++++++++++
 .../acpi/pmic_opregion/intel_soc_pmic_opregion.h   |  34 ++
 drivers/mfd/intel_soc_pmic_crc.c                   |   3 +
 6 files changed, 614 insertions(+)
 create mode 100644 drivers/acpi/pmic_opregion/intel_soc_pmic_crc_opregion.c
 create mode 100644 drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.c
 create mode 100644 drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.h

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index b23fe37f67c0..df816456dc06 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -394,4 +394,21 @@ config ACPI_EXTLOG
 	  driver adds support for that functionality with corresponding
 	  tracepoint which carries that information to userspace.
 
+menuconfig PMIC_OPREGION
+	bool "PMIC (Power Management Integrated Circuit) operation region support"
+	help
+	  Select this option to enable support for ACPI operation
+	  region of the PMIC chip. The operation region can be used
+	  to control power rails and sensor reading/writing on the
+	  PMIC chip.
+
+if PMIC_OPREGION
+config CRC_PMIC_OPREGION
+	bool "ACPI operation region support for CrystalCove PMIC"
+	depends on INTEL_SOC_PMIC
+	help
+	  This config adds ACPI operation region support for CrystalCove PMIC.
+
+endif
+
 endif	# ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 6d11522f0e48..123f0f159bdc 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -88,3 +88,6 @@ obj-$(CONFIG_ACPI_PROCESSOR_AGGREGATOR) += acpi_pad.o
 obj-$(CONFIG_ACPI_APEI)		+= apei/
 
 obj-$(CONFIG_ACPI_EXTLOG)	+= acpi_extlog.o
+
+obj-$(CONFIG_PMIC_OPREGION)	+= pmic_opregion/intel_soc_pmic_opregion.o
+obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic_opregion/intel_soc_pmic_crc_opregion.o
diff --git a/drivers/acpi/pmic_opregion/intel_soc_pmic_crc_opregion.c b/drivers/acpi/pmic_opregion/intel_soc_pmic_crc_opregion.c
new file mode 100644
index 000000000000..f1624f2e84f2
--- /dev/null
+++ b/drivers/acpi/pmic_opregion/intel_soc_pmic_crc_opregion.c
@@ -0,0 +1,216 @@
+/*
+ * intel_soc_pmic_crc_opregion.c - Intel SoC PMIC operation region Driver
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/mfd/intel_soc_pmic.h>
+#include <linux/regmap.h>
+#include <linux/platform_device.h>
+#include "intel_soc_pmic_opregion.h"
+
+#define PWR_SOURCE_SELECT	BIT(1)
+
+#define PMIC_A0LOCK_REG		0xc5
+
+static struct pmic_pwr_table pwr_table[] = {
+	{
+		.address = 0x24,
+		.pwr_reg = {
+			.reg = 0x66,
+			.bit = 0x00,
+		},
+	},	/* X285 -> V2P85SX, camara */
+	{
+		.address = 0x48,
+		.pwr_reg = {
+			.reg = 0x5d,
+			.bit = 0x00,
+		},
+	},	/* V18X -> V1P8SX, eMMC/camara/audio */
+};
+
+static struct pmic_dptf_table dptf_table[] = {
+	{
+		.address = 0x00,
+		.reg = 0x75
+	},	/* TMP0 -> SYS0_THRM_RSLT_L */
+	{
+		.address = 0x04,
+		.reg = 0x95
+	},	/* AX00 -> SYS0_THRMALRT0_L */
+	{
+		.address = 0x08,
+		.reg = 0x97
+	},	/* AX01 -> SYS0_THRMALRT1_L */
+	{
+		.address = 0x0c,
+		.reg = 0x77
+	},	/* TMP1 -> SYS1_THRM_RSLT_L */
+	{
+		.address = 0x10,
+		.reg = 0x9a
+	},	/* AX10 -> SYS1_THRMALRT0_L */
+	{
+		.address = 0x14,
+		.reg = 0x9c
+	},	/* AX11 -> SYS1_THRMALRT1_L */
+	{
+		.address = 0x18,
+		.reg = 0x79
+	},	/* TMP2 -> SYS2_THRM_RSLT_L */
+	{
+		.address = 0x1c,
+		.reg = 0x9f
+	},	/* AX20 -> SYS2_THRMALRT0_L */
+	{
+		.address = 0x20,
+		.reg = 0xa1
+	},	/* AX21 -> SYS2_THRMALRT1_L */
+	{
+		.address = 0x48,
+		.reg = 0x94
+	},	/* PEN0 -> SYS0_THRMALRT0_H */
+	{
+		.address = 0x4c,
+		.reg = 0x99
+	},	/* PEN1 -> SYS1_THRMALRT1_H */
+	{
+		.address = 0x50,
+		.reg = 0x9e
+	},	/* PEN2 -> SYS2_THRMALRT2_H */
+};
+
+static int intel_crc_pmic_get_power(struct regmap *regmap,
+				    struct pmic_pwr_reg *preg, u64 *value)
+{
+	int data;
+
+	if (regmap_read(regmap, preg->reg, &data))
+		return -EIO;
+
+	*value = (data & PWR_SOURCE_SELECT) && (data & BIT(preg->bit)) ? 1 : 0;
+	return 0;
+}
+
+static int intel_crc_pmic_update_power(struct regmap *regmap,
+				       struct pmic_pwr_reg *preg, bool on)
+{
+	int data;
+
+	if (regmap_read(regmap, preg->reg, &data))
+		return -EIO;
+
+	if (on) {
+		data |= PWR_SOURCE_SELECT | BIT(preg->bit);
+	} else {
+		data &= ~BIT(preg->bit);
+		data |= PWR_SOURCE_SELECT;
+	}
+
+	if (regmap_write(regmap, preg->reg, data))
+		return -EIO;
+	return 0;
+}
+
+/* Raw temperature value is 10bits: 8bits in reg and 2bits in reg-1 bit0,1 */
+static int intel_crc_pmic_get_raw_temp(struct regmap *regmap, int reg)
+{
+	int temp_l, temp_h;
+
+	if (regmap_read(regmap, reg, &temp_l) ||
+	    regmap_read(regmap, reg - 1, &temp_h))
+		return -EIO;
+
+	return (temp_l | ((temp_h & 0x3) << 8));
+}
+
+static int
+intel_crc_pmic_update_aux(struct regmap *regmap, int reg, int raw)
+{
+	if (regmap_write(regmap, reg, raw) ||
+	    regmap_update_bits(regmap, reg - 1, 0x3, raw >> 8))
+		return -EIO;
+
+	return 0;
+}
+
+static int
+intel_crc_pmic_get_policy(struct regmap *regmap, int reg, u64 *value)
+{
+	int pen;
+
+	if (regmap_read(regmap, reg, &pen))
+		return -EIO;
+	*value = pen >> 7;
+	return 0;
+}
+
+static int intel_crc_pmic_update_policy(struct regmap *regmap,
+					int reg, int enable)
+{
+	int alert0;
+
+	/* Update to policy enable bit requires unlocking a0lock */
+	if (regmap_read(regmap, PMIC_A0LOCK_REG, &alert0))
+		return -EIO;
+	if (regmap_update_bits(regmap, PMIC_A0LOCK_REG, 0x01, 0))
+		return -EIO;
+
+	if (regmap_update_bits(regmap, reg, 0x80, enable << 7))
+		return -EIO;
+
+	/* restore alert0 */
+	if (regmap_write(regmap, PMIC_A0LOCK_REG, alert0))
+		return -EIO;
+
+	return 0;
+}
+
+static struct intel_soc_pmic_opregion_data intel_crc_pmic_opregion_data = {
+	.get_power	= intel_crc_pmic_get_power,
+	.update_power	= intel_crc_pmic_update_power,
+	.get_raw_temp	= intel_crc_pmic_get_raw_temp,
+	.update_aux	= intel_crc_pmic_update_aux,
+	.get_policy	= intel_crc_pmic_get_policy,
+	.update_policy	= intel_crc_pmic_update_policy,
+	.pwr_table	= pwr_table,
+	.pwr_table_count= ARRAY_SIZE(pwr_table),
+	.dptf_table	= dptf_table,
+	.dptf_table_count = ARRAY_SIZE(dptf_table),
+};
+
+static int intel_crc_pmic_opregion_probe(struct platform_device *pdev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
+	return intel_soc_pmic_install_opregion_handler(&pdev->dev,
+			ACPI_HANDLE(pdev->dev.parent), pmic->regmap,
+			&intel_crc_pmic_opregion_data);
+}
+
+static struct platform_driver intel_crc_pmic_opregion_driver = {
+	.probe = intel_crc_pmic_opregion_probe,
+	.driver = {
+		.name = "crystal_cove_region",
+	},
+};
+
+static int __init intel_crc_pmic_opregion_driver_init(void)
+{
+	return platform_driver_register(&intel_crc_pmic_opregion_driver);
+}
+module_init(intel_crc_pmic_opregion_driver_init);
+
+MODULE_DESCRIPTION("CrystalCove ACPI opration region driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.c b/drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.c
new file mode 100644
index 000000000000..ae3f88b30a63
--- /dev/null
+++ b/drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.c
@@ -0,0 +1,341 @@
+/*
+ * intel_soc_pmic_opregion.c - Intel SoC PMIC operation region Driver
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/regmap.h>
+#include "intel_soc_pmic_opregion.h"
+
+#define PMIC_PMOP_OPREGION_ID	0x8d
+#define PMIC_DPTF_OPREGION_ID	0x8c
+
+struct acpi_lpat {
+	int temp;
+	int raw;
+};
+
+struct intel_soc_pmic_opregion {
+	struct mutex lock;
+	struct acpi_lpat *lpat;
+	int lpat_count;
+	struct regmap *regmap;
+	struct intel_soc_pmic_opregion_data *data;
+};
+
+static struct pmic_pwr_reg *
+pmic_get_pwr_reg(int address, struct pmic_pwr_table *table, int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++) {
+		if (table[i].address == address)
+			return &table[i].pwr_reg;
+	}
+	return NULL;
+}
+
+static int
+pmic_get_dptf_reg(int address, struct pmic_dptf_table *table, int count)
+{
+	int i;
+
+	for (i = 0; i < count; i++) {
+		if (table[i].address == address)
+			return table[i].reg;
+	}
+	return -ENOENT;
+}
+
+/* Return temperature from raw value through LPAT table */
+static int raw_to_temp(struct acpi_lpat *lpat, int count, int raw)
+{
+	int i, delta_temp, delta_raw, temp;
+
+	for (i = 0; i < count - 1; i++) {
+		if ((raw >= lpat[i].raw && raw <= lpat[i+1].raw) ||
+		    (raw <= lpat[i].raw && raw >= lpat[i+1].raw))
+			break;
+	}
+
+	if (i == count - 1)
+		return -ENOENT;
+
+	delta_temp = lpat[i+1].temp - lpat[i].temp;
+	delta_raw = lpat[i+1].raw - lpat[i].raw;
+	temp = lpat[i].temp + (raw - lpat[i].raw) * delta_temp / delta_raw;
+
+	return temp;
+}
+
+/* Return raw value from temperature through LPAT table */
+static int temp_to_raw(struct acpi_lpat *lpat, int count, int temp)
+{
+	int i, delta_temp, delta_raw, raw;
+
+	for (i = 0; i < count - 1; i++) {
+		if (temp >= lpat[i].temp && temp <= lpat[i+1].temp)
+			break;
+	}
+
+	if (i == count - 1)
+		return -ENOENT;
+
+	delta_temp = lpat[i+1].temp - lpat[i].temp;
+	delta_raw = lpat[i+1].raw - lpat[i].raw;
+	raw = lpat[i].raw + (temp - lpat[i].temp) * delta_raw / delta_temp;
+
+	return raw;
+}
+
+static void
+pmic_dptf_lpat(struct intel_soc_pmic_opregion *opregion, acpi_handle handle,
+	       struct device *dev)
+{
+	struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL };
+	union acpi_object *obj_p, *obj_e;
+	int *lpat, i;
+	acpi_status status;
+
+	status = acpi_evaluate_object(handle, "LPAT", NULL, &buffer);
+	if (ACPI_FAILURE(status))
+		return;
+
+	obj_p = (union acpi_object *)buffer.pointer;
+	if (!obj_p || (obj_p->type != ACPI_TYPE_PACKAGE) ||
+	    (obj_p->package.count % 2) || (obj_p->package.count < 4))
+		goto out;
+
+	lpat = devm_kmalloc(dev, sizeof(*lpat) * obj_p->package.count,
+			    GFP_KERNEL);
+	if (!lpat)
+		goto out;
+
+	for (i = 0; i < obj_p->package.count; i++) {
+		obj_e = &obj_p->package.elements[i];
+		if (obj_e->type != ACPI_TYPE_INTEGER)
+			goto out;
+		lpat[i] = obj_e->integer.value;
+	}
+
+	opregion->lpat = (struct acpi_lpat *)lpat;
+	opregion->lpat_count = obj_p->package.count / 2;
+
+out:
+	kfree(buffer.pointer);
+}
+
+static acpi_status
+intel_soc_pmic_pmop_handler(u32 function, acpi_physical_address address,
+			    u32 bits, u64 *value64,
+			    void *handler_context, void *region_context)
+{
+	struct intel_soc_pmic_opregion *opregion = region_context;
+	struct regmap *regmap = opregion->regmap;
+	struct intel_soc_pmic_opregion_data *d = opregion->data;
+	struct pmic_pwr_reg *preg;
+	int result;
+
+	if (bits != 32 || !value64)
+		return AE_BAD_PARAMETER;
+
+	if (function == ACPI_WRITE && !(*value64 == 0 || *value64 == 1))
+		return AE_BAD_PARAMETER;
+
+	preg = pmic_get_pwr_reg(address, d->pwr_table, d->pwr_table_count);
+	if (!preg)
+		return AE_BAD_PARAMETER;
+
+	mutex_lock(&opregion->lock);
+
+	if (function == ACPI_READ)
+		result = d->get_power(regmap, preg, value64);
+	else
+		result = d->update_power(regmap, preg, *value64 == 1);
+
+	mutex_unlock(&opregion->lock);
+
+	return result ? AE_ERROR : AE_OK;
+}
+
+static acpi_status pmic_read_temp(struct intel_soc_pmic_opregion *opregion,
+				  int reg, u64 *value)
+{
+	int raw_temp, temp;
+
+	if (!opregion->data->get_raw_temp)
+		return AE_BAD_PARAMETER;
+
+	raw_temp = opregion->data->get_raw_temp(opregion->regmap, reg);
+	if (raw_temp < 0)
+		return AE_ERROR;
+
+	if (!opregion->lpat) {
+		*value = raw_temp;
+		return AE_OK;
+	}
+
+	temp = raw_to_temp(opregion->lpat, opregion->lpat_count, raw_temp);
+	if (temp < 0)
+		return AE_ERROR;
+
+	*value = temp;
+	return AE_OK;
+}
+
+static acpi_status pmic_dptf_temp(struct intel_soc_pmic_opregion *opregion,
+				  int reg, u32 function, u64 *value)
+{
+	if (function != ACPI_READ)
+		return AE_BAD_PARAMETER;
+
+	return pmic_read_temp(opregion, reg, value);
+}
+
+static acpi_status pmic_dptf_aux(struct intel_soc_pmic_opregion *opregion,
+				 int reg, u32 function, u64 *value)
+{
+	int raw_temp;
+
+	if (function == ACPI_READ)
+		return pmic_read_temp(opregion, reg, value);
+
+	if (!opregion->data->update_aux)
+		return AE_BAD_PARAMETER;
+
+	if (opregion->lpat) {
+		raw_temp = temp_to_raw(opregion->lpat, opregion->lpat_count,
+					 *value);
+		if (raw_temp < 0)
+			return AE_ERROR;
+	} else {
+		raw_temp = *value;
+	}
+
+	return opregion->data->update_aux(opregion->regmap, reg, raw_temp) ?
+		AE_ERROR : AE_OK;
+}
+
+static acpi_status pmic_dptf_pen(struct intel_soc_pmic_opregion *opregion,
+				 int reg, u32 function, u64 *value)
+{
+	struct intel_soc_pmic_opregion_data *d = opregion->data;
+	struct regmap *regmap = opregion->regmap;
+
+	if (!d->get_policy || !d->update_policy)
+		return AE_BAD_PARAMETER;
+
+	if (function == ACPI_READ)
+		return d->get_policy(regmap, reg, value) ? AE_ERROR : AE_OK;
+
+	if (*value != 0 || *value != 1)
+		return AE_BAD_PARAMETER;
+
+	return d->update_policy(regmap, reg, *value) ? AE_ERROR : AE_OK;
+}
+
+static bool pmic_dptf_is_temp(int address)
+{
+	return (address <= 0x3c) && !(address % 12);
+}
+
+static bool pmic_dptf_is_aux(int address)
+{
+	return (address >= 4 && address <= 0x40 && !((address - 4) % 12)) ||
+	       (address >= 8 && address <= 0x44 && !((address - 8) % 12));
+}
+
+static bool pmic_dptf_is_pen(int address)
+{
+	return address >= 0x48 && address <= 0x5c;
+}
+
+static acpi_status
+intel_soc_pmic_dptf_handler(u32 function, acpi_physical_address address,
+			    u32 bits, u64 *value64,
+			    void *handler_context, void *region_context)
+{
+	struct intel_soc_pmic_opregion *opregion = region_context;
+	int reg;
+	int result;
+
+	if (bits != 32 || !value64)
+		return AE_BAD_PARAMETER;
+
+	reg = pmic_get_dptf_reg(address, opregion->data->dptf_table,
+				opregion->data->dptf_table_count);
+	if (!reg)
+		return AE_BAD_PARAMETER;
+
+	mutex_lock(&opregion->lock);
+
+	result = AE_BAD_PARAMETER;
+	if (pmic_dptf_is_temp(address))
+		result = pmic_dptf_temp(opregion, reg, function, value64);
+	else if (pmic_dptf_is_aux(address))
+		result = pmic_dptf_aux(opregion, reg, function, value64);
+	else if (pmic_dptf_is_pen(address))
+		result = pmic_dptf_pen(opregion, reg, function, value64);
+
+	mutex_unlock(&opregion->lock);
+
+	return result;
+}
+
+int
+intel_soc_pmic_install_opregion_handler(struct device *dev,
+					acpi_handle handle,
+					struct regmap *regmap,
+					struct intel_soc_pmic_opregion_data *d)
+{
+	acpi_status status;
+	struct intel_soc_pmic_opregion *opregion;
+
+	if (!dev || !regmap || !d)
+		return -EINVAL;
+
+	if (!handle)
+		return -ENODEV;
+
+	opregion = devm_kzalloc(dev, sizeof(*opregion), GFP_KERNEL);
+	if (!opregion)
+		return -ENOMEM;
+
+	mutex_init(&opregion->lock);
+	opregion->regmap = regmap;
+	pmic_dptf_lpat(opregion, handle, dev);
+
+	status = acpi_install_address_space_handler(handle,
+						    PMIC_PMOP_OPREGION_ID,
+						    intel_soc_pmic_pmop_handler,
+						    NULL, opregion);
+	if (ACPI_FAILURE(status))
+		return -ENODEV;
+
+	status = acpi_install_address_space_handler(handle,
+						    PMIC_DPTF_OPREGION_ID,
+						    intel_soc_pmic_dptf_handler,
+						    NULL, opregion);
+	if (ACPI_FAILURE(status)) {
+		acpi_remove_address_space_handler(handle, PMIC_PMOP_OPREGION_ID,
+						  intel_soc_pmic_pmop_handler);
+		return -ENODEV;
+	}
+
+	opregion->data = d;
+	return 0;
+}
+EXPORT_SYMBOL_GPL(intel_soc_pmic_install_opregion_handler);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.h b/drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.h
new file mode 100644
index 000000000000..3c21eeb1a775
--- /dev/null
+++ b/drivers/acpi/pmic_opregion/intel_soc_pmic_opregion.h
@@ -0,0 +1,34 @@
+#ifndef __INTEL_SOC_PMIC_OPREGION_H
+#define __INTEL_SOC_PMIC_OPREGION_H
+
+struct pmic_pwr_reg {
+	int reg;	/* corresponding PMIC register */
+	int bit;	/* control bit for power */
+};
+
+struct pmic_pwr_table {
+	int address;	/* operation region address */
+	struct pmic_pwr_reg pwr_reg;
+};
+
+struct pmic_dptf_table {
+	int address;	/* operation region address */
+	int reg;	/* corresponding thermal register */
+};
+
+struct intel_soc_pmic_opregion_data {
+	int (*get_power)(struct regmap *r, struct pmic_pwr_reg *preg, u64 *value);
+	int (*update_power)(struct regmap *r, struct pmic_pwr_reg *preg, bool on);
+	int (*get_raw_temp)(struct regmap *r, int reg);
+	int (*update_aux)(struct regmap *r, int reg, int raw_temp);
+	int (*get_policy)(struct regmap *r, int reg, u64 *value);
+	int (*update_policy)(struct regmap *r, int reg, int enable);
+	struct pmic_pwr_table *pwr_table;
+	int pwr_table_count;
+	struct pmic_dptf_table *dptf_table;
+	int dptf_table_count;
+};
+
+int intel_soc_pmic_install_opregion_handler(struct device *dev, acpi_handle handle, struct regmap *regmap, struct intel_soc_pmic_opregion_data *d);
+
+#endif
diff --git a/drivers/mfd/intel_soc_pmic_crc.c b/drivers/mfd/intel_soc_pmic_crc.c
index 7107cab832e6..48845d636bba 100644
--- a/drivers/mfd/intel_soc_pmic_crc.c
+++ b/drivers/mfd/intel_soc_pmic_crc.c
@@ -106,6 +106,9 @@ static struct mfd_cell crystal_cove_dev[] = {
 		.num_resources = ARRAY_SIZE(gpio_resources),
 		.resources = gpio_resources,
 	},
+	{
+		.name = "crystal_cove_region",
+	},
 };
 
 static struct regmap_config crystal_cove_regmap_config = {
-- 
1.9.3

[PATCH 2/3] ACPI / pmic_opregion: support PMIC operation region for XPower AXP288

[Aaron Lu]

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: Aaron Lu <aaron.lu@intel.com>
---
 drivers/acpi/Kconfig                               |   6 +
 drivers/acpi/Makefile                              |   1 +
 .../pmic_opregion/intel_soc_pmic_xpower_opregion.c | 277 +++++++++++++++++++++
 drivers/mfd/axp20x.c                               |   3 +
 4 files changed, 287 insertions(+)
 create mode 100644 drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index df816456dc06..1b7b753cadcc 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -409,6 +409,12 @@ config CRC_PMIC_OPREGION
 	help
 	  This config adds ACPI operation region support for CrystalCove PMIC.
 
+config XPOWER_PMIC_OPREGION
+	bool "ACPI operation region support for XPower AXP288 PMIC"
+	depends on AXP288_ADC
+	help
+	  This config adds ACPI operation region support for XPower AXP288 PMIC.
+
 endif
 
 endif	# ACPI
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 123f0f159bdc..f2a6a1d56ef7 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -91,3 +91,4 @@ obj-$(CONFIG_ACPI_EXTLOG)	+= acpi_extlog.o
 
 obj-$(CONFIG_PMIC_OPREGION)	+= pmic_opregion/intel_soc_pmic_opregion.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic_opregion/intel_soc_pmic_crc_opregion.o
+obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic_opregion/intel_soc_pmic_xpower_opregion.o
diff --git a/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c b/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c
new file mode 100644
index 000000000000..ab462708aecf
--- /dev/null
+++ b/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c
@@ -0,0 +1,277 @@
+/*
+ * intel_soc_pmic_xpower_opregion.c - Intel SoC PMIC operation region Driver
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/acpi.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/regmap.h>
+#include <linux/platform_device.h>
+#include <linux/iio/consumer.h>
+#include "intel_soc_pmic_opregion.h"
+
+#define XPOWER_GPADC_LOW	0x5b
+
+static struct pmic_pwr_table pwr_table[] = {
+	{
+		.address = 0x00,
+		.pwr_reg = {
+			.reg = 0x13,
+			.bit = 0x05,
+		}
+	}, /* ALD1, 0x13, bit5 */
+	{
+		.address = 0x04,
+		.pwr_reg = {
+			.reg = 0x13,
+			.bit = 0x06,
+		}
+	}, /* ALD2, 0x13, bit6 */
+	{
+		.address = 0x08,
+		.pwr_reg = {
+			.reg = 0x13,
+			.bit = 0x07,
+		}
+	}, /* ALD3, 0x13, bit7 */
+	{
+		.address = 0x0c,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x03,
+		}
+	}, /* DLD1, 0x12, bit3 */
+	{
+		.address = 0x10,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x04,
+		}
+	}, /* DLD2, 0x12, bit4 */
+	{
+		.address = 0x14,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x05,
+		}
+	}, /* DLD3, 0x12, bit5 */
+	{
+		.address = 0x18,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x06,
+		}
+	}, /* DLD4, 0x12, bit6 */
+	{
+		.address = 0x1c,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x00,
+		}
+	}, /* ELD1, 0x12, bit0 */
+	{
+		.address = 0x20,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x01,
+		}
+	}, /* ELD2, 0x12, bit1 */
+	{
+		.address = 0x24,
+		.pwr_reg = {
+			.reg = 0x12,
+			.bit = 0x02,
+		}
+	}, /* ELD3, 0x12, bit2 */
+	{
+		.address = 0x28,
+		.pwr_reg = {
+			.reg = 0x13,
+			.bit = 0x02,
+		}
+	}, /* FLD1, 0x13, bit2 */
+	{
+		.address = 0x2c,
+		.pwr_reg = {
+			.reg = 0x13,
+			.bit = 0x03,
+		}
+	}, /* FLD2, 0x13, bit3 */
+	{
+		.address = 0x30,
+		.pwr_reg = {
+			.reg = 0x13,
+			.bit = 0x04,
+		}
+	}, /* FLD3, 0x13, bit4 */
+	{
+		.address = 0x38,
+		.pwr_reg = {
+			.reg = 0x10,
+			.bit = 0x03,
+		}
+	}, /* BUC1, 0x10, bit3 */
+	{
+		.address = 0x3c,
+		.pwr_reg = {
+			.reg = 0x10,
+			.bit = 0x06,
+		}
+	}, /* BUC2, 0x10, bit6 */
+	{
+		.address = 0x40,
+		.pwr_reg = {
+			.reg = 0x10,
+			.bit = 0x05,
+		}
+	}, /* BUC3, 0x10, bit5 */
+	{
+		.address = 0x44,
+		.pwr_reg = {
+			.reg = 0x10,
+			.bit = 0x04,
+		}
+	}, /* BUC4, 0x10, bit4 */
+	{
+		.address = 0x48,
+		.pwr_reg = {
+			.reg = 0x10,
+			.bit = 0x01,
+		}
+	}, /* BUC5, 0x10, bit1 */
+	{
+		.address = 0x4c,
+		.pwr_reg = {
+			.reg = 0x10,
+			.bit = 0x00
+		}
+	}, /* BUC6, 0x10, bit0 */
+};
+
+/* TMP0 - TMP5 are the same, all from GPADC */
+static struct pmic_dptf_table dptf_table[] = {
+	{
+		.address = 0x00,
+		.reg = XPOWER_GPADC_LOW
+	},
+	{
+		.address = 0x0c,
+		.reg = XPOWER_GPADC_LOW
+	},
+	{
+		.address = 0x18,
+		.reg = XPOWER_GPADC_LOW
+	},
+	{
+		.address = 0x24,
+		.reg = XPOWER_GPADC_LOW
+	},
+	{
+		.address = 0x30,
+		.reg = XPOWER_GPADC_LOW
+	},
+	{
+		.address = 0x3c,
+		.reg = XPOWER_GPADC_LOW
+	},
+};
+
+static int intel_xpower_pmic_get_power(struct regmap *regmap,
+				       struct pmic_pwr_reg *preg, u64 *value)
+{
+	int data;
+
+	if (regmap_read(regmap, preg->reg, &data))
+		return -EIO;
+
+	*value = (data & BIT(preg->bit)) ? 1 : 0;
+	return 0;
+}
+
+static int intel_xpower_pmic_update_power(struct regmap *regmap,
+					  struct pmic_pwr_reg *preg, bool on)
+{
+	int data;
+
+	if (regmap_read(regmap, preg->reg, &data))
+		return -EIO;
+
+	if (on)
+		data |= BIT(preg->bit);
+	else
+		data &= ~BIT(preg->bit);
+
+	if (regmap_write(regmap, preg->reg, data))
+		return -EIO;
+
+	return 0;
+}
+
+/*
+ * We could get the sensor value by manipulating the HW regs here, but since
+ * the axp288 IIO driver may also access the same regs at the same time, the
+ * APIs provided by IIO subsystem are used here instead to avoid problems. As
+ * a result, the two passed in params are of no actual use.
+ */
+static int intel_xpower_pmic_get_raw_temp(struct regmap *regmap, int reg)
+{
+	struct iio_channel *gpadc_chan;
+	int ret, val;
+
+	gpadc_chan = iio_channel_get(NULL, "axp288-system-temp");
+	if (IS_ERR_OR_NULL(gpadc_chan))
+		return -EACCES;
+
+	ret = iio_read_channel_raw(gpadc_chan, &val);
+	if (ret < 0)
+		val = ret;
+
+	iio_channel_release(gpadc_chan);
+	return val;
+}
+
+static struct intel_soc_pmic_opregion_data intel_xpower_pmic_opregion_data = {
+	.get_power = intel_xpower_pmic_get_power,
+	.update_power = intel_xpower_pmic_update_power,
+	.get_raw_temp = intel_xpower_pmic_get_raw_temp,
+	.pwr_table = pwr_table,
+	.pwr_table_count = ARRAY_SIZE(pwr_table),
+	.dptf_table = dptf_table,
+	.dptf_table_count = ARRAY_SIZE(dptf_table),
+};
+
+
+static int intel_xpower_pmic_opregion_probe(struct platform_device *pdev)
+{
+	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
+	return intel_soc_pmic_install_opregion_handler(&pdev->dev,
+			ACPI_HANDLE(pdev->dev.parent), axp20x->regmap,
+			&intel_xpower_pmic_opregion_data);
+}
+
+static struct platform_driver intel_xpower_pmic_opregion_driver = {
+	.probe = intel_xpower_pmic_opregion_probe,
+	.driver = {
+		.name = "axp288_opregion",
+	},
+};
+
+static int __init intel_xpower_pmic_opregion_driver_init(void)
+{
+	return platform_driver_register(&intel_xpower_pmic_opregion_driver);
+}
+module_init(intel_xpower_pmic_opregion_driver_init);
+
+MODULE_DESCRIPTION("XPower AXP288 ACPI operation region driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index acbb4c3bf98c..daf3c8d33b4d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -354,6 +354,9 @@ static struct mfd_cell axp288_cells[] = {
 		.num_resources = ARRAY_SIZE(axp288_battery_resources),
 		.resources = axp288_battery_resources,
 	},
+	{
+		.name = "axp288_opregion",
+	},
 };
 
 static struct axp20x_dev *axp20x_pm_power_off;
-- 
1.9.3

[PATCH 3/3] ACPI / pmic_opregion: AXP288: support virtual GPIO in ACPI table

[Aaron Lu]

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: Aaron Lu <aaron.lu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
 .../pmic_opregion/intel_soc_pmic_xpower_opregion.c | 27 ++++++++++++++++++----
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c b/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c
index ab462708aecf..e25c83da90a5 100644
--- a/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c
+++ b/drivers/acpi/pmic_opregion/intel_soc_pmic_xpower_opregion.c
@@ -251,13 +251,32 @@ static struct intel_soc_pmic_opregion_data intel_xpower_pmic_opregion_data = {
 	.dptf_table_count = ARRAY_SIZE(dptf_table),
 };
 
+static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
+		acpi_physical_address address, u32 bit_width, u64 *value,
+		void *handler_context, void *region_context)
+{
+	return AE_OK;
+}
 
 static int intel_xpower_pmic_opregion_probe(struct platform_device *pdev)
 {
-	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
-	return intel_soc_pmic_install_opregion_handler(&pdev->dev,
-			ACPI_HANDLE(pdev->dev.parent), axp20x->regmap,
-			&intel_xpower_pmic_opregion_data);
+	struct device *parent = pdev->dev.parent;
+	struct axp20x_dev *axp20x = dev_get_drvdata(parent);
+	acpi_status status;
+	int result;
+
+	result = intel_soc_pmic_install_opregion_handler(&pdev->dev,
+					ACPI_HANDLE(parent), axp20x->regmap,
+					&intel_xpower_pmic_opregion_data);
+	if (!result) {
+		status = acpi_install_address_space_handler(
+				ACPI_HANDLE(parent), ACPI_ADR_SPACE_GPIO,
+				intel_xpower_pmic_gpio_handler, NULL, NULL);
+		if (ACPI_FAILURE(status))
+			result = -ENODEV;
+	}
+
+	return result;
 }
 
 static struct platform_driver intel_xpower_pmic_opregion_driver = {
-- 
1.9.3

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Aaron Lu]

On 10/31/2014 02:08 PM, Aaron Lu wrote:
> On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> ACPI operation regions defined for the Power Management Integrated Circuit
> device, one is for power resource handling and one is for thermal: sensor
> temperature reporting, trip point setting, etc. There are different PMIC
> chips used on those platforms and though each has the same two operation
> regions and functionality, their implementation is different so every PMIC
> will need a driver. But since their functionality is similar, some common
> code is abstracted into the intel_soc_pmic_opregion.c.
> 
> The last version is posted here:
> https://lkml.org/lkml/2014/9/8/801
> 
> Changes since then:
> 1 Move to drivers/acpi as discussed on the above thread;
> 2 Added support for XPower AXP288 PMIC operation region support;
> 3 Since operation region handler can not be removed(at the moment at least),
>   use bool for the two operation region driver configs instead of tristate;
>   Another reason to do this is that, with Mika's MFD ACPI support patch, all
>   those MFD cell devices created will have the same modalias as their parent's
>   so it doesn't make much sense to compile these drivers into modules.
> 
> Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> driver XPower AXP288 and iio driver axp288_adc is located.

Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
would be easy to go through the mfd/ib-mfd-iio-3.19 branch.

Rafael,
Can I get your ACK for the three patches?

Lee,
Can you please take the series if Rafael gives it ack?

Thanks,
Aaron

> 
> Aaron Lu (3):
>   ACPI / pmic_opregion: support PMIC operation region for CrystalCove
>   ACPI / pmic_opregion: support PMIC operation region for XPower AXP288
>   ACPI / pmic_opregion: AXP288: support virtual GPIO in ACPI table
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Lee Jones]

On Tue, 11 Nov 2014, Aaron Lu wrote:

> On 10/31/2014 02:08 PM, Aaron Lu wrote:
> > On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> > ACPI operation regions defined for the Power Management Integrated Circuit
> > device, one is for power resource handling and one is for thermal: sensor
> > temperature reporting, trip point setting, etc. There are different PMIC
> > chips used on those platforms and though each has the same two operation
> > regions and functionality, their implementation is different so every PMIC
> > will need a driver. But since their functionality is similar, some common
> > code is abstracted into the intel_soc_pmic_opregion.c.
> > 
> > The last version is posted here:
> > https://lkml.org/lkml/2014/9/8/801
> > 
> > Changes since then:
> > 1 Move to drivers/acpi as discussed on the above thread;
> > 2 Added support for XPower AXP288 PMIC operation region support;
> > 3 Since operation region handler can not be removed(at the moment at least),
> >   use bool for the two operation region driver configs instead of tristate;
> >   Another reason to do this is that, with Mika's MFD ACPI support patch, all
> >   those MFD cell devices created will have the same modalias as their parent's
> >   so it doesn't make much sense to compile these drivers into modules.
> > 
> > Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> > patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> > driver XPower AXP288 and iio driver axp288_adc is located.
> 
> Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
> would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
> 
> Rafael,
> Can I get your ACK for the three patches?
> 
> Lee,
> Can you please take the series if Rafael gives it ack?

Yes, no problem.

> > Aaron Lu (3):
> >   ACPI / pmic_opregion: support PMIC operation region for CrystalCove
> >   ACPI / pmic_opregion: support PMIC operation region for XPower AXP288
> >   ACPI / pmic_opregion: AXP288: support virtual GPIO in ACPI table
> > 
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Rafael J. Wysocki]

On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
> On Tue, 11 Nov 2014, Aaron Lu wrote:
> 
> > On 10/31/2014 02:08 PM, Aaron Lu wrote:
> > > On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> > > ACPI operation regions defined for the Power Management Integrated Circuit
> > > device, one is for power resource handling and one is for thermal: sensor
> > > temperature reporting, trip point setting, etc. There are different PMIC
> > > chips used on those platforms and though each has the same two operation
> > > regions and functionality, their implementation is different so every PMIC
> > > will need a driver. But since their functionality is similar, some common
> > > code is abstracted into the intel_soc_pmic_opregion.c.
> > > 
> > > The last version is posted here:
> > > https://lkml.org/lkml/2014/9/8/801
> > > 
> > > Changes since then:
> > > 1 Move to drivers/acpi as discussed on the above thread;
> > > 2 Added support for XPower AXP288 PMIC operation region support;
> > > 3 Since operation region handler can not be removed(at the moment at least),
> > >   use bool for the two operation region driver configs instead of tristate;
> > >   Another reason to do this is that, with Mika's MFD ACPI support patch, all
> > >   those MFD cell devices created will have the same modalias as their parent's
> > >   so it doesn't make much sense to compile these drivers into modules.
> > > 
> > > Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> > > patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> > > driver XPower AXP288 and iio driver axp288_adc is located.
> > 
> > Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
> > would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
> > 
> > Rafael,
> > Can I get your ACK for the three patches?
> > 
> > Lee,
> > Can you please take the series if Rafael gives it ack?
> 
> Yes, no problem.

Well, since the code is going to reside mostly in drivers/acpi, I think I should
be applying the patches and from your response it looks like you are fine with
them.  Is that correct?

Rafael

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Aaron Lu]

On 11/12/2014 07:35 AM, Rafael J. Wysocki wrote:
> On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
>> On Tue, 11 Nov 2014, Aaron Lu wrote:
>>
>>> On 10/31/2014 02:08 PM, Aaron Lu wrote:
>>>> On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
>>>> ACPI operation regions defined for the Power Management Integrated Circuit
>>>> device, one is for power resource handling and one is for thermal: sensor
>>>> temperature reporting, trip point setting, etc. There are different PMIC
>>>> chips used on those platforms and though each has the same two operation
>>>> regions and functionality, their implementation is different so every PMIC
>>>> will need a driver. But since their functionality is similar, some common
>>>> code is abstracted into the intel_soc_pmic_opregion.c.
>>>>
>>>> The last version is posted here:
>>>> https://lkml.org/lkml/2014/9/8/801
>>>>
>>>> Changes since then:
>>>> 1 Move to drivers/acpi as discussed on the above thread;
>>>> 2 Added support for XPower AXP288 PMIC operation region support;
>>>> 3 Since operation region handler can not be removed(at the moment at least),
>>>>   use bool for the two operation region driver configs instead of tristate;
>>>>   Another reason to do this is that, with Mika's MFD ACPI support patch, all
>>>>   those MFD cell devices created will have the same modalias as their parent's
>>>>   so it doesn't make much sense to compile these drivers into modules.
>>>>
>>>> Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
>>>> patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
>>>> driver XPower AXP288 and iio driver axp288_adc is located.
>>>
>>> Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
>>> would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
>>>
>>> Rafael,
>>> Can I get your ACK for the three patches?
>>>
>>> Lee,
>>> Can you please take the series if Rafael gives it ack?
>>
>> Yes, no problem.
> 
> Well, since the code is going to reside mostly in drivers/acpi, I think I should
> be applying the patches and from your response it looks like you are fine with
> them.  Is that correct?

Oh I thought you may not want to merge another branch into your next
branch so I asked this question. If you can handle the whole thing in your
tree, that's of course not a problem :-)

Thanks,
Aaron

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Rafael J. Wysocki]

On Wednesday, November 12, 2014 09:48:10 AM Aaron Lu wrote:
> On 11/12/2014 07:35 AM, Rafael J. Wysocki wrote:
> > On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
> >> On Tue, 11 Nov 2014, Aaron Lu wrote:
> >>
> >>> On 10/31/2014 02:08 PM, Aaron Lu wrote:
> >>>> On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> >>>> ACPI operation regions defined for the Power Management Integrated Circuit
> >>>> device, one is for power resource handling and one is for thermal: sensor
> >>>> temperature reporting, trip point setting, etc. There are different PMIC
> >>>> chips used on those platforms and though each has the same two operation
> >>>> regions and functionality, their implementation is different so every PMIC
> >>>> will need a driver. But since their functionality is similar, some common
> >>>> code is abstracted into the intel_soc_pmic_opregion.c.
> >>>>
> >>>> The last version is posted here:
> >>>> https://lkml.org/lkml/2014/9/8/801
> >>>>
> >>>> Changes since then:
> >>>> 1 Move to drivers/acpi as discussed on the above thread;
> >>>> 2 Added support for XPower AXP288 PMIC operation region support;
> >>>> 3 Since operation region handler can not be removed(at the moment at least),
> >>>>   use bool for the two operation region driver configs instead of tristate;
> >>>>   Another reason to do this is that, with Mika's MFD ACPI support patch, all
> >>>>   those MFD cell devices created will have the same modalias as their parent's
> >>>>   so it doesn't make much sense to compile these drivers into modules.
> >>>>
> >>>> Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> >>>> patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> >>>> driver XPower AXP288 and iio driver axp288_adc is located.
> >>>
> >>> Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
> >>> would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
> >>>
> >>> Rafael,
> >>> Can I get your ACK for the three patches?
> >>>
> >>> Lee,
> >>> Can you please take the series if Rafael gives it ack?
> >>
> >> Yes, no problem.
> > 
> > Well, since the code is going to reside mostly in drivers/acpi, I think I should
> > be applying the patches and from your response it looks like you are fine with
> > them.  Is that correct?
> 
> Oh I thought you may not want to merge another branch into your next
> branch so I asked this question. If you can handle the whole thing in your
> tree, that's of course not a problem :-)

Merging one more branch wouldn't be a problem, but we'll take care of that
later.

For now, would it be possible to rename the subdir to "pmic" instead of
"pmic_opregion"?  The "_opregion" part doesn't seem to add much value here.

And can the names of the files be somewhat shorter too?  Like "intel_pmic.[h][c]"
and "intel_pmic_crc.c"?


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Aaron Lu]

On 11/13/2014 08:51 AM, Rafael J. Wysocki wrote:
> On Wednesday, November 12, 2014 09:48:10 AM Aaron Lu wrote:
>> On 11/12/2014 07:35 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
>>>> On Tue, 11 Nov 2014, Aaron Lu wrote:
>>>>
>>>>> On 10/31/2014 02:08 PM, Aaron Lu wrote:
>>>>>> On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
>>>>>> ACPI operation regions defined for the Power Management Integrated Circuit
>>>>>> device, one is for power resource handling and one is for thermal: sensor
>>>>>> temperature reporting, trip point setting, etc. There are different PMIC
>>>>>> chips used on those platforms and though each has the same two operation
>>>>>> regions and functionality, their implementation is different so every PMIC
>>>>>> will need a driver. But since their functionality is similar, some common
>>>>>> code is abstracted into the intel_soc_pmic_opregion.c.
>>>>>>
>>>>>> The last version is posted here:
>>>>>> https://lkml.org/lkml/2014/9/8/801
>>>>>>
>>>>>> Changes since then:
>>>>>> 1 Move to drivers/acpi as discussed on the above thread;
>>>>>> 2 Added support for XPower AXP288 PMIC operation region support;
>>>>>> 3 Since operation region handler can not be removed(at the moment at least),
>>>>>>   use bool for the two operation region driver configs instead of tristate;
>>>>>>   Another reason to do this is that, with Mika's MFD ACPI support patch, all
>>>>>>   those MFD cell devices created will have the same modalias as their parent's
>>>>>>   so it doesn't make much sense to compile these drivers into modules.
>>>>>>
>>>>>> Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
>>>>>> patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
>>>>>> driver XPower AXP288 and iio driver axp288_adc is located.
>>>>>
>>>>> Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
>>>>> would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
>>>>>
>>>>> Rafael,
>>>>> Can I get your ACK for the three patches?
>>>>>
>>>>> Lee,
>>>>> Can you please take the series if Rafael gives it ack?
>>>>
>>>> Yes, no problem.
>>>
>>> Well, since the code is going to reside mostly in drivers/acpi, I think I should
>>> be applying the patches and from your response it looks like you are fine with
>>> them.  Is that correct?
>>
>> Oh I thought you may not want to merge another branch into your next
>> branch so I asked this question. If you can handle the whole thing in your
>> tree, that's of course not a problem :-)
> 
> Merging one more branch wouldn't be a problem, but we'll take care of that
> later.
> 
> For now, would it be possible to rename the subdir to "pmic" instead of
> "pmic_opregion"?  The "_opregion" part doesn't seem to add much value here.

No problem.

> 
> And can the names of the files be somewhat shorter too?  Like "intel_pmic.[h][c]"
> and "intel_pmic_crc.c"?

Sure, will update and send v2, thanks for the advice.

Regards,
Aaron

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Lee Jones]

On Wed, 12 Nov 2014, Rafael J. Wysocki wrote:

> On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
> > On Tue, 11 Nov 2014, Aaron Lu wrote:
> > 
> > > On 10/31/2014 02:08 PM, Aaron Lu wrote:
> > > > On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> > > > ACPI operation regions defined for the Power Management Integrated Circuit
> > > > device, one is for power resource handling and one is for thermal: sensor
> > > > temperature reporting, trip point setting, etc. There are different PMIC
> > > > chips used on those platforms and though each has the same two operation
> > > > regions and functionality, their implementation is different so every PMIC
> > > > will need a driver. But since their functionality is similar, some common
> > > > code is abstracted into the intel_soc_pmic_opregion.c.
> > > > 
> > > > The last version is posted here:
> > > > https://lkml.org/lkml/2014/9/8/801
> > > > 
> > > > Changes since then:
> > > > 1 Move to drivers/acpi as discussed on the above thread;
> > > > 2 Added support for XPower AXP288 PMIC operation region support;
> > > > 3 Since operation region handler can not be removed(at the moment at least),
> > > >   use bool for the two operation region driver configs instead of tristate;
> > > >   Another reason to do this is that, with Mika's MFD ACPI support patch, all
> > > >   those MFD cell devices created will have the same modalias as their parent's
> > > >   so it doesn't make much sense to compile these drivers into modules.
> > > > 
> > > > Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> > > > patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> > > > driver XPower AXP288 and iio driver axp288_adc is located.
> > > 
> > > Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
> > > would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
> > > 
> > > Rafael,
> > > Can I get your ACK for the three patches?
> > > 
> > > Lee,
> > > Can you please take the series if Rafael gives it ack?
> > 
> > Yes, no problem.
> 
> Well, since the code is going to reside mostly in drivers/acpi, I think I should
> be applying the patches and from your response it looks like you are fine with
> them.  Is that correct?

I read that this set has dependencies on patches which are already in
the MFD tree.  If that's not the case please go ahead and apply them
with my Ack for the MFD components.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Rafael J. Wysocki]

On Wednesday, November 12, 2014 09:44:19 AM Lee Jones wrote:
> On Wed, 12 Nov 2014, Rafael J. Wysocki wrote:
> 
> > On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
> > > On Tue, 11 Nov 2014, Aaron Lu wrote:
> > > 
> > > > On 10/31/2014 02:08 PM, Aaron Lu wrote:
> > > > > On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> > > > > ACPI operation regions defined for the Power Management Integrated Circuit
> > > > > device, one is for power resource handling and one is for thermal: sensor
> > > > > temperature reporting, trip point setting, etc. There are different PMIC
> > > > > chips used on those platforms and though each has the same two operation
> > > > > regions and functionality, their implementation is different so every PMIC
> > > > > will need a driver. But since their functionality is similar, some common
> > > > > code is abstracted into the intel_soc_pmic_opregion.c.
> > > > > 
> > > > > The last version is posted here:
> > > > > https://lkml.org/lkml/2014/9/8/801
> > > > > 
> > > > > Changes since then:
> > > > > 1 Move to drivers/acpi as discussed on the above thread;
> > > > > 2 Added support for XPower AXP288 PMIC operation region support;
> > > > > 3 Since operation region handler can not be removed(at the moment at least),
> > > > >   use bool for the two operation region driver configs instead of tristate;
> > > > >   Another reason to do this is that, with Mika's MFD ACPI support patch, all
> > > > >   those MFD cell devices created will have the same modalias as their parent's
> > > > >   so it doesn't make much sense to compile these drivers into modules.
> > > > > 
> > > > > Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> > > > > patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> > > > > driver XPower AXP288 and iio driver axp288_adc is located.
> > > > 
> > > > Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
> > > > would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
> > > > 
> > > > Rafael,
> > > > Can I get your ACK for the three patches?
> > > > 
> > > > Lee,
> > > > Can you please take the series if Rafael gives it ack?
> > > 
> > > Yes, no problem.
> > 
> > Well, since the code is going to reside mostly in drivers/acpi, I think I should
> > be applying the patches and from your response it looks like you are fine with
> > them.  Is that correct?
> 
> I read that this set has dependencies on patches which are already in
> the MFD tree.  If that's not the case please go ahead and apply them
> with my Ack for the MFD components.

I thought you had a branch that I could pull into my tree and apply the patches
on top of it.  At least that was my understanding of the Aaron's message, so
please let me know if that's not the case.

Rafael

Re: [PATCH 0/3] Support PMIC operation region for CrystalCove and XPower

[Lee Jones]

On Thu, 13 Nov 2014, Rafael J. Wysocki wrote:

> On Wednesday, November 12, 2014 09:44:19 AM Lee Jones wrote:
> > On Wed, 12 Nov 2014, Rafael J. Wysocki wrote:
> > 
> > > On Tuesday, November 11, 2014 11:11:52 AM Lee Jones wrote:
> > > > On Tue, 11 Nov 2014, Aaron Lu wrote:
> > > > 
> > > > > On 10/31/2014 02:08 PM, Aaron Lu wrote:
> > > > > > On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> > > > > > ACPI operation regions defined for the Power Management Integrated Circuit
> > > > > > device, one is for power resource handling and one is for thermal: sensor
> > > > > > temperature reporting, trip point setting, etc. There are different PMIC
> > > > > > chips used on those platforms and though each has the same two operation
> > > > > > regions and functionality, their implementation is different so every PMIC
> > > > > > will need a driver. But since their functionality is similar, some common
> > > > > > code is abstracted into the intel_soc_pmic_opregion.c.
> > > > > > 
> > > > > > The last version is posted here:
> > > > > > https://lkml.org/lkml/2014/9/8/801
> > > > > > 
> > > > > > Changes since then:
> > > > > > 1 Move to drivers/acpi as discussed on the above thread;
> > > > > > 2 Added support for XPower AXP288 PMIC operation region support;
> > > > > > 3 Since operation region handler can not be removed(at the moment at least),
> > > > > >   use bool for the two operation region driver configs instead of tristate;
> > > > > >   Another reason to do this is that, with Mika's MFD ACPI support patch, all
> > > > > >   those MFD cell devices created will have the same modalias as their parent's
> > > > > >   so it doesn't make much sense to compile these drivers into modules.
> > > > > > 
> > > > > > Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> > > > > > patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> > > > > > driver XPower AXP288 and iio driver axp288_adc is located.
> > > > > 
> > > > > Since patch 2-3 are based on top of the mfd/ib-mfd-iio-3.19 branch, it
> > > > > would be easy to go through the mfd/ib-mfd-iio-3.19 branch.
> > > > > 
> > > > > Rafael,
> > > > > Can I get your ACK for the three patches?
> > > > > 
> > > > > Lee,
> > > > > Can you please take the series if Rafael gives it ack?
> > > > 
> > > > Yes, no problem.
> > > 
> > > Well, since the code is going to reside mostly in drivers/acpi, I think I should
> > > be applying the patches and from your response it looks like you are fine with
> > > them.  Is that correct?
> > 
> > I read that this set has dependencies on patches which are already in
> > the MFD tree.  If that's not the case please go ahead and apply them
> > with my Ack for the MFD components.
> 
> I thought you had a branch that I could pull into my tree and apply the patches
> on top of it.  At least that was my understanding of the Aaron's message, so
> please let me know if that's not the case.

That is absolutely the case.  'mfd/ib-mfd-iio-3.19' is good to go.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog