diff mbox

[v2,1/2] gpio / CrystalCove: support virtual GPIO

Message ID 54238496.70505@intel.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Aaron Lu Sept. 25, 2014, 2:57 a.m. UTC
The virtual GPIO introduced in ACPI table of Baytrail-T based system is
used to solve a problem under Windows. We do not have such problems
under Linux so we do not actually need them. But we have to tell GPIO
library that the Crystal Cove GPIO chip has this many GPIO pins or the
common GPIO handler will refuse any access to those high number GPIO
pins, which will resulted in a failure evaluation of every ACPI control
method that is used to turn on/off power resource and/or report sensor
temperatures.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
---
v2: remove the hunk to increase NR_GPIO to 512.

 drivers/gpio/gpio-crystalcove.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

Comments

Mika Westerberg Sept. 25, 2014, 11:15 a.m. UTC | #1
On Thu, Sep 25, 2014 at 10:57:26AM +0800, Aaron Lu wrote:
> The virtual GPIO introduced in ACPI table of Baytrail-T based system is
> used to solve a problem under Windows. We do not have such problems
> under Linux so we do not actually need them. But we have to tell GPIO
> library that the Crystal Cove GPIO chip has this many GPIO pins or the
> common GPIO handler will refuse any access to those high number GPIO
> pins, which will resulted in a failure evaluation of every ACPI control
> method that is used to turn on/off power resource and/or report sensor
> temperatures.
> 
> Signed-off-by: Aaron Lu <aaron.lu@intel.com>

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

A minor nit, see below:

> ---
> v2: remove the hunk to increase NR_GPIO to 512.
> 
>  drivers/gpio/gpio-crystalcove.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
> index e3712f0e51ab..186b76ef71a1 100644
> --- a/drivers/gpio/gpio-crystalcove.c
> +++ b/drivers/gpio/gpio-crystalcove.c
> @@ -24,6 +24,7 @@
>  #include <linux/mfd/intel_soc_pmic.h>
>  
>  #define CRYSTALCOVE_GPIO_NUM	16
> +#define CRYSTALCOVE_VGPIO_NUM	0x5e

I would rather see this spelled in decimal base.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Linus Walleij Sept. 25, 2014, 1:16 p.m. UTC | #2
On Thu, Sep 25, 2014 at 4:57 AM, Aaron Lu <aaron.lu@intel.com> wrote:

> The virtual GPIO introduced in ACPI table of Baytrail-T based system is
> used to solve a problem under Windows. We do not have such problems
> under Linux so we do not actually need them. But we have to tell GPIO
> library that the Crystal Cove GPIO chip has this many GPIO pins or the
> common GPIO handler will refuse any access to those high number GPIO
> pins, which will resulted in a failure evaluation of every ACPI control
> method that is used to turn on/off power resource and/or report sensor
> temperatures.
>
> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> ---
> v2: remove the hunk to increase NR_GPIO to 512.

Patch applied with Mika's ACK, also renumbered 0x5e to 94.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Aaron Lu Sept. 26, 2014, 5:21 a.m. UTC | #3
On 09/25/2014 07:15 PM, Mika Westerberg wrote:
> On Thu, Sep 25, 2014 at 10:57:26AM +0800, Aaron Lu wrote:
>> The virtual GPIO introduced in ACPI table of Baytrail-T based system is
>> used to solve a problem under Windows. We do not have such problems
>> under Linux so we do not actually need them. But we have to tell GPIO
>> library that the Crystal Cove GPIO chip has this many GPIO pins or the
>> common GPIO handler will refuse any access to those high number GPIO
>> pins, which will resulted in a failure evaluation of every ACPI control
>> method that is used to turn on/off power resource and/or report sensor
>> temperatures.
>>
>> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> 
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Thanks for the review!

Regards,
Aaron

> 
> A minor nit, see below:
> 
>> ---
>> v2: remove the hunk to increase NR_GPIO to 512.
>>
>>  drivers/gpio/gpio-crystalcove.c | 19 ++++++++++++++++---
>>  1 file changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
>> index e3712f0e51ab..186b76ef71a1 100644
>> --- a/drivers/gpio/gpio-crystalcove.c
>> +++ b/drivers/gpio/gpio-crystalcove.c
>> @@ -24,6 +24,7 @@
>>  #include <linux/mfd/intel_soc_pmic.h>
>>  
>>  #define CRYSTALCOVE_GPIO_NUM	16
>> +#define CRYSTALCOVE_VGPIO_NUM	0x5e
> 
> I would rather see this spelled in decimal base.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Aaron Lu Sept. 26, 2014, 5:22 a.m. UTC | #4
On 09/25/2014 09:16 PM, Linus Walleij wrote:
> On Thu, Sep 25, 2014 at 4:57 AM, Aaron Lu <aaron.lu@intel.com> wrote:
> 
>> The virtual GPIO introduced in ACPI table of Baytrail-T based system is
>> used to solve a problem under Windows. We do not have such problems
>> under Linux so we do not actually need them. But we have to tell GPIO
>> library that the Crystal Cove GPIO chip has this many GPIO pins or the
>> common GPIO handler will refuse any access to those high number GPIO
>> pins, which will resulted in a failure evaluation of every ACPI control
>> method that is used to turn on/off power resource and/or report sensor
>> temperatures.
>>
>> Signed-off-by: Aaron Lu <aaron.lu@intel.com>
>> ---
>> v2: remove the hunk to increase NR_GPIO to 512.
> 
> Patch applied with Mika's ACK, also renumbered 0x5e to 94.

Thanks for taking care of this.

Regards,
Aaron

> 
> Yours,
> Linus Walleij
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/drivers/gpio/gpio-crystalcove.c b/drivers/gpio/gpio-crystalcove.c
index e3712f0e51ab..186b76ef71a1 100644
--- a/drivers/gpio/gpio-crystalcove.c
+++ b/drivers/gpio/gpio-crystalcove.c
@@ -24,6 +24,7 @@ 
 #include <linux/mfd/intel_soc_pmic.h>
 
 #define CRYSTALCOVE_GPIO_NUM	16
+#define CRYSTALCOVE_VGPIO_NUM	0x5e
 
 #define UPDATE_IRQ_TYPE		BIT(0)
 #define UPDATE_IRQ_MASK		BIT(1)
@@ -130,6 +131,9 @@  static int crystalcove_gpio_dir_in(struct gpio_chip *chip, unsigned gpio)
 {
 	struct crystalcove_gpio *cg = to_cg(chip);
 
+	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+		return 0;
+
 	return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
 			    CTLO_INPUT_SET);
 }
@@ -139,6 +143,9 @@  static int crystalcove_gpio_dir_out(struct gpio_chip *chip, unsigned gpio,
 {
 	struct crystalcove_gpio *cg = to_cg(chip);
 
+	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+		return 0;
+
 	return regmap_write(cg->regmap, to_reg(gpio, CTRL_OUT),
 			    CTLO_OUTPUT_SET | value);
 }
@@ -149,6 +156,9 @@  static int crystalcove_gpio_get(struct gpio_chip *chip, unsigned gpio)
 	int ret;
 	unsigned int val;
 
+	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+		return 0;
+
 	ret = regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), &val);
 	if (ret)
 		return ret;
@@ -161,6 +171,9 @@  static void crystalcove_gpio_set(struct gpio_chip *chip,
 {
 	struct crystalcove_gpio *cg = to_cg(chip);
 
+	if (gpio > CRYSTALCOVE_VGPIO_NUM)
+		return;
+
 	if (value)
 		regmap_update_bits(cg->regmap, to_reg(gpio, CTRL_OUT), 1, 1);
 	else
@@ -256,7 +269,7 @@  static irqreturn_t crystalcove_gpio_irq_handler(int irq, void *data)
 
 	pending = p0 | p1 << 8;
 
-	for (gpio = 0; gpio < cg->chip.ngpio; gpio++) {
+	for (gpio = 0; gpio < CRYSTALCOVE_GPIO_NUM; gpio++) {
 		if (pending & BIT(gpio)) {
 			virq = irq_find_mapping(cg->chip.irqdomain, gpio);
 			generic_handle_irq(virq);
@@ -273,7 +286,7 @@  static void crystalcove_gpio_dbg_show(struct seq_file *s,
 	int gpio, offset;
 	unsigned int ctlo, ctli, mirqs0, mirqsx, irq;
 
-	for (gpio = 0; gpio < cg->chip.ngpio; gpio++) {
+	for (gpio = 0; gpio < CRYSTALCOVE_GPIO_NUM; gpio++) {
 		regmap_read(cg->regmap, to_reg(gpio, CTRL_OUT), &ctlo);
 		regmap_read(cg->regmap, to_reg(gpio, CTRL_IN), &ctli);
 		regmap_read(cg->regmap, gpio < 8 ? MGPIO0IRQS0 : MGPIO1IRQS0,
@@ -320,7 +333,7 @@  static int crystalcove_gpio_probe(struct platform_device *pdev)
 	cg->chip.get = crystalcove_gpio_get;
 	cg->chip.set = crystalcove_gpio_set;
 	cg->chip.base = -1;
-	cg->chip.ngpio = CRYSTALCOVE_GPIO_NUM;
+	cg->chip.ngpio = CRYSTALCOVE_VGPIO_NUM;
 	cg->chip.can_sleep = true;
 	cg->chip.dev = dev;
 	cg->chip.dbg_show = crystalcove_gpio_dbg_show;