[PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[Hans de Goede]

Offset/pin 0 is a perfectly valid offset, so stop using it to have
the special meaning of interrupt line not used in the intr_lines.

Instead introduce a new special INTR_LINE_UNUSED value which is never
a valid offset and use that to indicate unused interrupt lines.

Cc: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Reword commit + log messages a bit (as requested by Mika)
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 980099028cf8..55ccdcecd94e 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -73,6 +73,8 @@ struct intel_pad_context {
 	u32 padctrl1;
 };
 
+#define INTR_LINE_UNUSED		U32_MAX
+
 /**
  * struct intel_community_context - community context for Cherryview
  * @intr_lines: Mapping between 16 HW interrupt wires and GPIO offset (in GPIO number space)
@@ -812,7 +814,7 @@ static int chv_gpio_request_enable(struct pinctrl_dev *pctldev,
 		/* Reset the interrupt mapping */
 		for (i = 0; i < ARRAY_SIZE(cctx->intr_lines); i++) {
 			if (cctx->intr_lines[i] == offset) {
-				cctx->intr_lines[i] = 0;
+				cctx->intr_lines[i] = INTR_LINE_UNUSED;
 				break;
 			}
 		}
@@ -1319,7 +1321,7 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d)
 		else
 			handler = handle_edge_irq;
 
-		if (!cctx->intr_lines[intsel]) {
+		if (cctx->intr_lines[intsel] == INTR_LINE_UNUSED) {
 			irq_set_handler_locked(d, handler);
 			cctx->intr_lines[intsel] = pin;
 		}
@@ -1412,6 +1414,12 @@ static void chv_gpio_irq_handler(struct irq_desc *desc)
 		unsigned int offset;
 
 		offset = cctx->intr_lines[intr_line];
+		if (offset == INTR_LINE_UNUSED) {
+			dev_err(pctrl->dev, "interrupt on unused interrupt line %u\n",
+				intr_line);
+			continue;
+		}
+
 		generic_handle_domain_irq(gc->irq.domain, offset);
 	}
 
@@ -1620,9 +1628,10 @@ static int chv_pinctrl_probe(struct platform_device *pdev)
 	struct intel_community *community;
 	struct device *dev = &pdev->dev;
 	struct acpi_device *adev = ACPI_COMPANION(dev);
+	struct intel_community_context *cctx;
 	struct intel_pinctrl *pctrl;
 	acpi_status status;
-	int ret, irq;
+	int i, ret, irq;
 
 	soc_data = intel_pinctrl_get_soc_data(pdev);
 	if (IS_ERR(soc_data))
@@ -1663,6 +1672,10 @@ static int chv_pinctrl_probe(struct platform_device *pdev)
 	if (!pctrl->context.communities)
 		return -ENOMEM;
 
+	cctx = &pctrl->context.communities[0];
+	for (i = 0; i < ARRAY_SIZE(cctx->intr_lines); i++)
+		cctx->intr_lines[i] = INTR_LINE_UNUSED;
+
 	irq = platform_get_irq(pdev, 0);
 	if (irq < 0)
 		return irq;
-- 
2.31.1

[PATCH v2 2/3] pinctrl: cherryview: Do not allow the same interrupt line to be used by 2 pins

[Hans de Goede]

It is impossible to use the same interrupt line for 2 pins, this will
result in the interrupts only being delivered to the IRQ handler for
the pin for which chv_gpio_irq_type() was called last.

The pinctrl-cherryview.c code relies on the BIOS to correctly setup the
interrupt line, but there is a BIOS bug on at least the Medion Akoya E1239T
and the GPD win models where both INT33FF:02 pin 8, used by the powerbutton
and INT33FF:02 pin 21 used as IRQ input for the accelerometer are mapped to
interrupt line 0.

This causes 2 problems:
1. The accelerometer IRQ does not work, since the power button is probed
later taking over the intr_lines[0] slot.

2. Since the accelerometer IRQ is not marked as wakeup, interrupt line 0
gets masked on suspend, causing the power button to not work to wake
the system from suspend.

Likewise on the Lenovo Yogabook, which has a touchscreen as keyboard
and the keyboard half of the tablet also has a Wacom digitizer, the BIOS
by default assigns the same interrupt line to the GPIOs used
for their interrupts.

Fix these problems by adding a check for this and assigning a new
interrupt line to the 2nd pin for which chv_gpio_irq_type() gets called.

With this fix in place the following 2 messages show up in dmesg on
the Medion Akoya E1239T and the GPD win:

 cherryview-pinctrl INT33FF:02: interrupt line 0 is used by both pin 21 and pin 8
 cherryview-pinctrl INT33FF:02: changing the interrupt line for pin 8 to 15

And the following gets logged on the Lenovo Yogabook:

 cherryview-pinctrl INT33FF:01: interrupt-line 0 is used by both pin 49 and pin 56
 cherryview-pinctrl INT33FF:01: changing the interrupt line for pin 56 to 7

Note commit 9747070c11d6 ("Input: axp20x-pek - always register interrupt
handlers") was added as a work around for the power button not being able
to wakeup the system. This relies on using the PMIC's connection to the
power button but that only works on systems with the AXP288 PMIC.
Once this fix has been merged that workaround can be removed.

Cc: Yauhen Kharuzhy <jekhor@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Reword commit + log messages a bit (as requested by Mika)
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 69 +++++++++++++++++++---
 1 file changed, 61 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 55ccdcecd94e..da68f8a849ab 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1323,6 +1323,8 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d)
 
 		if (cctx->intr_lines[intsel] == INTR_LINE_UNUSED) {
 			irq_set_handler_locked(d, handler);
+			dev_dbg(pctrl->dev, "using interrupt line %u for IRQ_TYPE_NONE IRQ on pin %u\n",
+				intsel, pin);
 			cctx->intr_lines[intsel] = pin;
 		}
 		raw_spin_unlock_irqrestore(&chv_lock, flags);
@@ -1332,17 +1334,73 @@ static unsigned chv_gpio_irq_startup(struct irq_data *d)
 	return 0;
 }
 
+static int chv_gpio_set_intr_line(struct intel_pinctrl *pctrl, unsigned int pin)
+{
+	struct intel_community_context *cctx = &pctrl->context.communities[0];
+	const struct intel_community *community = &pctrl->communities[0];
+	u32 value, intsel;
+	int i;
+
+	value = chv_readl(pctrl, pin, CHV_PADCTRL0);
+	intsel = (value & CHV_PADCTRL0_INTSEL_MASK) >> CHV_PADCTRL0_INTSEL_SHIFT;
+
+	if (cctx->intr_lines[intsel] == pin)
+		return 0;
+
+	if (cctx->intr_lines[intsel] == INTR_LINE_UNUSED) {
+		dev_dbg(pctrl->dev, "using interrupt line %u for pin %u\n", intsel, pin);
+		cctx->intr_lines[intsel] = pin;
+		return 0;
+	}
+
+	/*
+	 * The interrupt line selected by the BIOS is already in use by
+	 * another pin, this is a known BIOS bug found on several models.
+	 * But this may also be caused by Linux deciding to use a pin as
+	 * IRQ which was not expected to be used as such by the BIOS authors,
+	 * so log this at info level only.
+	 */
+	dev_info(pctrl->dev, "interrupt line %u is used by both pin %u and pin %u\n",
+		 intsel, cctx->intr_lines[intsel], pin);
+
+	if (chv_pad_locked(pctrl, pin))
+		return -EBUSY;
+
+	/*
+	 * The BIOS fills the interrupt lines from 0 counting up, start at
+	 * the other end to find a free interrupt line to workaround this.
+	 */
+	for (i = community->nirqs - 1; i >= 0; i--) {
+		if (cctx->intr_lines[i] == INTR_LINE_UNUSED)
+			break;
+	}
+	if (i < 0)
+		return -EBUSY;
+
+	dev_info(pctrl->dev, "changing the interrupt line for pin %u to %d\n", pin, i);
+
+	value = (value & ~CHV_PADCTRL0_INTSEL_MASK) | (i << CHV_PADCTRL0_INTSEL_SHIFT);
+	chv_writel(pctrl, pin, CHV_PADCTRL0, value);
+	cctx->intr_lines[i] = pin;
+
+	return 0;
+}
+
 static int chv_gpio_irq_type(struct irq_data *d, unsigned int type)
 {
 	struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
 	struct intel_pinctrl *pctrl = gpiochip_get_data(gc);
-	struct intel_community_context *cctx = &pctrl->context.communities[0];
 	unsigned int pin = irqd_to_hwirq(d);
 	unsigned long flags;
 	u32 value;
+	int ret;
 
 	raw_spin_lock_irqsave(&chv_lock, flags);
 
+	ret = chv_gpio_set_intr_line(pctrl, pin);
+	if (ret)
+		goto out_unlock;
+
 	/*
 	 * Pins which can be used as shared interrupt are configured in
 	 * BIOS. Driver trusts BIOS configurations and assigns different
@@ -1377,20 +1435,15 @@ static int chv_gpio_irq_type(struct irq_data *d, unsigned int type)
 		chv_writel(pctrl, pin, CHV_PADCTRL1, value);
 	}
 
-	value = chv_readl(pctrl, pin, CHV_PADCTRL0);
-	value &= CHV_PADCTRL0_INTSEL_MASK;
-	value >>= CHV_PADCTRL0_INTSEL_SHIFT;
-
-	cctx->intr_lines[value] = pin;
-
 	if (type & IRQ_TYPE_EDGE_BOTH)
 		irq_set_handler_locked(d, handle_edge_irq);
 	else if (type & IRQ_TYPE_LEVEL_MASK)
 		irq_set_handler_locked(d, handle_level_irq);
 
+out_unlock:
 	raw_spin_unlock_irqrestore(&chv_lock, flags);
 
-	return 0;
+	return ret;
 }
 
 static void chv_gpio_irq_handler(struct irq_desc *desc)
-- 
2.31.1

Re: [PATCH v2 2/3] pinctrl: cherryview: Do not allow the same interrupt line to be used by 2 pins

[Mika Westerberg]

On Thu, Nov 18, 2021 at 11:56:49AM +0100, Hans de Goede wrote:
> It is impossible to use the same interrupt line for 2 pins, this will
> result in the interrupts only being delivered to the IRQ handler for
> the pin for which chv_gpio_irq_type() was called last.
> 
> The pinctrl-cherryview.c code relies on the BIOS to correctly setup the
> interrupt line, but there is a BIOS bug on at least the Medion Akoya E1239T
> and the GPD win models where both INT33FF:02 pin 8, used by the powerbutton
> and INT33FF:02 pin 21 used as IRQ input for the accelerometer are mapped to
> interrupt line 0.
> 
> This causes 2 problems:
> 1. The accelerometer IRQ does not work, since the power button is probed
> later taking over the intr_lines[0] slot.
> 
> 2. Since the accelerometer IRQ is not marked as wakeup, interrupt line 0
> gets masked on suspend, causing the power button to not work to wake
> the system from suspend.
> 
> Likewise on the Lenovo Yogabook, which has a touchscreen as keyboard
> and the keyboard half of the tablet also has a Wacom digitizer, the BIOS
> by default assigns the same interrupt line to the GPIOs used
> for their interrupts.
> 
> Fix these problems by adding a check for this and assigning a new
> interrupt line to the 2nd pin for which chv_gpio_irq_type() gets called.
> 
> With this fix in place the following 2 messages show up in dmesg on
> the Medion Akoya E1239T and the GPD win:
> 
>  cherryview-pinctrl INT33FF:02: interrupt line 0 is used by both pin 21 and pin 8
>  cherryview-pinctrl INT33FF:02: changing the interrupt line for pin 8 to 15
> 
> And the following gets logged on the Lenovo Yogabook:
> 
>  cherryview-pinctrl INT33FF:01: interrupt-line 0 is used by both pin 49 and pin 56
>  cherryview-pinctrl INT33FF:01: changing the interrupt line for pin 56 to 7
> 
> Note commit 9747070c11d6 ("Input: axp20x-pek - always register interrupt
> handlers") was added as a work around for the power button not being able
> to wakeup the system. This relies on using the PMIC's connection to the
> power button but that only works on systems with the AXP288 PMIC.
> Once this fix has been merged that workaround can be removed.
> 
> Cc: Yauhen Kharuzhy <jekhor@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

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

Re: [PATCH v2 2/3] pinctrl: cherryview: Do not allow the same interrupt line to be used by 2 pins

[Andy Shevchenko]

On Thu, Nov 18, 2021 at 01:14:53PM +0200, Mika Westerberg wrote:
> On Thu, Nov 18, 2021 at 11:56:49AM +0100, Hans de Goede wrote:
> > It is impossible to use the same interrupt line for 2 pins, this will
> > result in the interrupts only being delivered to the IRQ handler for
> > the pin for which chv_gpio_irq_type() was called last.
> > 
> > The pinctrl-cherryview.c code relies on the BIOS to correctly setup the
> > interrupt line, but there is a BIOS bug on at least the Medion Akoya E1239T
> > and the GPD win models where both INT33FF:02 pin 8, used by the powerbutton
> > and INT33FF:02 pin 21 used as IRQ input for the accelerometer are mapped to
> > interrupt line 0.
> > 
> > This causes 2 problems:
> > 1. The accelerometer IRQ does not work, since the power button is probed
> > later taking over the intr_lines[0] slot.
> > 
> > 2. Since the accelerometer IRQ is not marked as wakeup, interrupt line 0
> > gets masked on suspend, causing the power button to not work to wake
> > the system from suspend.
> > 
> > Likewise on the Lenovo Yogabook, which has a touchscreen as keyboard
> > and the keyboard half of the tablet also has a Wacom digitizer, the BIOS
> > by default assigns the same interrupt line to the GPIOs used
> > for their interrupts.
> > 
> > Fix these problems by adding a check for this and assigning a new
> > interrupt line to the 2nd pin for which chv_gpio_irq_type() gets called.
> > 
> > With this fix in place the following 2 messages show up in dmesg on
> > the Medion Akoya E1239T and the GPD win:
> > 
> >  cherryview-pinctrl INT33FF:02: interrupt line 0 is used by both pin 21 and pin 8
> >  cherryview-pinctrl INT33FF:02: changing the interrupt line for pin 8 to 15
> > 
> > And the following gets logged on the Lenovo Yogabook:
> > 
> >  cherryview-pinctrl INT33FF:01: interrupt-line 0 is used by both pin 49 and pin 56
> >  cherryview-pinctrl INT33FF:01: changing the interrupt line for pin 56 to 7
> > 
> > Note commit 9747070c11d6 ("Input: axp20x-pek - always register interrupt
> > handlers") was added as a work around for the power button not being able
> > to wakeup the system. This relies on using the PMIC's connection to the
> > power button but that only works on systems with the AXP288 PMIC.
> > Once this fix has been merged that workaround can be removed.
> > 
> > Cc: Yauhen Kharuzhy <jekhor@gmail.com>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Pushed to my review and testing queue, thanks!

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device

[Hans de Goede]

Many Cherry Trail DSDTs have an extra INT33FF device with UID 5,
the intel_pinctrl_get_soc_data() call will fail for this extra
unknown UID, leading to the following error in dmesg:

 cherryview-pinctrl: probe of INT33FF:04 failed with error -61

Add a check for this extra UID and return -ENODEV for it to
silence this false-positive error message.

Cc: Yauhen Kharuzhy <jekhor@gmail.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Add Mika's Acked-by
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index da68f8a849ab..487e343b68e1 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1686,6 +1686,10 @@ static int chv_pinctrl_probe(struct platform_device *pdev)
 	acpi_status status;
 	int i, ret, irq;
 
+	/* Cherry Trail DSDTs have an extra INT33FF device with UID 5, ignore */
+	if (!strcmp(adev->pnp.unique_id, "5"))
+		return -ENODEV;
+
 	soc_data = intel_pinctrl_get_soc_data(pdev);
 	if (IS_ERR(soc_data))
 		return PTR_ERR(soc_data);
-- 
2.31.1

Re: [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device

[Andy Shevchenko]

On Thu, Nov 18, 2021 at 11:56:50AM +0100, Hans de Goede wrote:
> Many Cherry Trail DSDTs have an extra INT33FF device with UID 5,
> the intel_pinctrl_get_soc_data() call will fail for this extra
> unknown UID, leading to the following error in dmesg:
> 
>  cherryview-pinctrl: probe of INT33FF:04 failed with error -61
> 
> Add a check for this extra UID and return -ENODEV for it to
> silence this false-positive error message.

Hmm... Interesting. Why do they have it?
Give me some time to check this...

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device

[Andy Shevchenko]

On Thu, Nov 18, 2021 at 01:28:02PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 18, 2021 at 11:56:50AM +0100, Hans de Goede wrote:
> > Many Cherry Trail DSDTs have an extra INT33FF device with UID 5,
> > the intel_pinctrl_get_soc_data() call will fail for this extra
> > unknown UID, leading to the following error in dmesg:
> > 
> >  cherryview-pinctrl: probe of INT33FF:04 failed with error -61
> > 
> > Add a check for this extra UID and return -ENODEV for it to
> > silence this false-positive error message.
> 
> Hmm... Interesting. Why do they have it?
> Give me some time to check this...

_DDN in ACPI describes this as Virtual GPIO. The only documentation at hand
right now tells me that this is a "solution" to represent the "virtual GPIO"
as fifth community (no connection to any pads, minimum configuration, etc).

The goal as far as I can see is "to convert a PME event generated by PCI device
to a GPIO interrupt".

Seems like we better have a driver for it, but the only purpose of it is to
generate interrupts based on PME.

I'll try to dig more may be next week, but for now I would like to postpone the
patch. Do you agree?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device

[Hans de Goede]

Hi,

On 11/26/21 19:12, Andy Shevchenko wrote:
> On Thu, Nov 18, 2021 at 01:28:02PM +0200, Andy Shevchenko wrote:
>> On Thu, Nov 18, 2021 at 11:56:50AM +0100, Hans de Goede wrote:
>>> Many Cherry Trail DSDTs have an extra INT33FF device with UID 5,
>>> the intel_pinctrl_get_soc_data() call will fail for this extra
>>> unknown UID, leading to the following error in dmesg:
>>>
>>>  cherryview-pinctrl: probe of INT33FF:04 failed with error -61
>>>
>>> Add a check for this extra UID and return -ENODEV for it to
>>> silence this false-positive error message.
>>
>> Hmm... Interesting. Why do they have it?
>> Give me some time to check this...
> 
> _DDN in ACPI describes this as Virtual GPIO. The only documentation at hand
> right now tells me that this is a "solution" to represent the "virtual GPIO"
> as fifth community (no connection to any pads, minimum configuration, etc).
> 
> The goal as far as I can see is "to convert a PME event generated by PCI device
> to a GPIO interrupt".
> 
> Seems like we better have a driver for it, but the only purpose of it is to
> generate interrupts based on PME.
> 
> I'll try to dig more may be next week, but for now I would like to postpone the
> patch. Do you agree?

Yes postponing merging this is fine. There is no hurry since this does
not fix anything broken. I just wanted to get rid of the annoying log message :)

Regards,

Hans

Re: [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device

[Andy Shevchenko]

On Sat, Nov 27, 2021 at 10:49:55PM +0100, Hans de Goede wrote:
> On 11/26/21 19:12, Andy Shevchenko wrote:
> > On Thu, Nov 18, 2021 at 01:28:02PM +0200, Andy Shevchenko wrote:
> >> On Thu, Nov 18, 2021 at 11:56:50AM +0100, Hans de Goede wrote:
> >>> Many Cherry Trail DSDTs have an extra INT33FF device with UID 5,
> >>> the intel_pinctrl_get_soc_data() call will fail for this extra
> >>> unknown UID, leading to the following error in dmesg:
> >>>
> >>>  cherryview-pinctrl: probe of INT33FF:04 failed with error -61
> >>>
> >>> Add a check for this extra UID and return -ENODEV for it to
> >>> silence this false-positive error message.
> >>
> >> Hmm... Interesting. Why do they have it?
> >> Give me some time to check this...
> > 
> > _DDN in ACPI describes this as Virtual GPIO. The only documentation at hand
> > right now tells me that this is a "solution" to represent the "virtual GPIO"
> > as fifth community (no connection to any pads, minimum configuration, etc).
> > 
> > The goal as far as I can see is "to convert a PME event generated by PCI device
> > to a GPIO interrupt".
> > 
> > Seems like we better have a driver for it, but the only purpose of it is to
> > generate interrupts based on PME.
> > 
> > I'll try to dig more may be next week, but for now I would like to postpone the
> > patch. Do you agree?
> 
> Yes postponing merging this is fine. There is no hurry since this does
> not fix anything broken. I just wanted to get rid of the annoying log message :)

So, documentation says the following.

  "Chassis GPIO does not support the notion of Virtual GPIOs. So a fifth GPIO
   Community was added to provide virtual GPIOs. This virtual GPIO resides
   inside PCU."

  "Table 8‑19: Virtual GPIO Assignments in CHV
   GPIO-V[x]	Usage
   [7]		 Reserved for PMC usage
   [6]		 PME handling
   [5]		 Reserved for PMC usage
   [4]		 OTG PME
   [3:1]	 In VLV2, was used for tx_modphy_common_mode_en.
		 In CHV, these are reserved for future use.
   [0]		 SATA PME"

IOAPIC mapping:

  "108  GPIO_virtual"


While at it, in case you want the mapping for direct IRQ:

    1) GPIO North:  eight interrupts used, connected to IOxAPIC IRQ51 to IRQ58.
    2) GPIO Southwest:  eight interrupts used, connected to IOxAPIC IRQ59 to IRQ66.
    3) GPIO East:  all sixteen interrupts used, connected to IOxAPIC IRQ67 to IRQ82.
    4) GPIO Southeast:  all sixteen interrupt used, connected to IOxAPIC IRQ92 to IRQ107.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[Mika Westerberg]

On Thu, Nov 18, 2021 at 11:56:48AM +0100, Hans de Goede wrote:
> Offset/pin 0 is a perfectly valid offset, so stop using it to have
> the special meaning of interrupt line not used in the intr_lines.
> 
> Instead introduce a new special INTR_LINE_UNUSED value which is never
> a valid offset and use that to indicate unused interrupt lines.
> 
> Cc: Yauhen Kharuzhy <jekhor@gmail.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

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

Re: [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[Andy Shevchenko]

On Thu, Nov 18, 2021 at 01:14:15PM +0200, Mika Westerberg wrote:
> On Thu, Nov 18, 2021 at 11:56:48AM +0100, Hans de Goede wrote:
> > Offset/pin 0 is a perfectly valid offset, so stop using it to have
> > the special meaning of interrupt line not used in the intr_lines.
> > 
> > Instead introduce a new special INTR_LINE_UNUSED value which is never
> > a valid offset and use that to indicate unused interrupt lines.
> > 
> > Cc: Yauhen Kharuzhy <jekhor@gmail.com>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> 
> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Pushed to my review and testing queue, thanks!

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[Andy Shevchenko]

On Thu, Nov 18, 2021 at 11:56:48AM +0100, Hans de Goede wrote:
> Offset/pin 0 is a perfectly valid offset, so stop using it to have
> the special meaning of interrupt line not used in the intr_lines.
> 
> Instead introduce a new special INTR_LINE_UNUSED value which is never
> a valid offset and use that to indicate unused interrupt lines.

...

> +#define INTR_LINE_UNUSED		U32_MAX

Funny, I have had something similar in my local branch for a few years ;-)

+#define CHV_INVALID_HWIRQ      ((unsigned int)INVALID_HWIRQ)

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[Andy Shevchenko]

On Thu, Nov 18, 2021 at 01:26:28PM +0200, Andy Shevchenko wrote:
> On Thu, Nov 18, 2021 at 11:56:48AM +0100, Hans de Goede wrote:
> > Offset/pin 0 is a perfectly valid offset, so stop using it to have
> > the special meaning of interrupt line not used in the intr_lines.
> > 
> > Instead introduce a new special INTR_LINE_UNUSED value which is never
> > a valid offset and use that to indicate unused interrupt lines.
> 
> ...
> 
> > +#define INTR_LINE_UNUSED		U32_MAX
> 
> Funny, I have had something similar in my local branch for a few years ;-)
> 
> +#define CHV_INVALID_HWIRQ      ((unsigned int)INVALID_HWIRQ)

I will rename this when applying. I assume there is no objection on doing it.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused

[Hans de Goede]

Hi,

On 11/26/21 18:43, Andy Shevchenko wrote:
> On Thu, Nov 18, 2021 at 01:26:28PM +0200, Andy Shevchenko wrote:
>> On Thu, Nov 18, 2021 at 11:56:48AM +0100, Hans de Goede wrote:
>>> Offset/pin 0 is a perfectly valid offset, so stop using it to have
>>> the special meaning of interrupt line not used in the intr_lines.
>>>
>>> Instead introduce a new special INTR_LINE_UNUSED value which is never
>>> a valid offset and use that to indicate unused interrupt lines.
>>
>> ...
>>
>>> +#define INTR_LINE_UNUSED		U32_MAX
>>
>> Funny, I have had something similar in my local branch for a few years ;-)
>>
>> +#define CHV_INVALID_HWIRQ      ((unsigned int)INVALID_HWIRQ)
> 
> I will rename this when applying. I assume there is no objection on doing it.

Yes that is fine.

Regards,

Hans