Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1479032 > unrolled thread

Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Phidias Chiang <phidias.chiang@canonical.com> - 2016-09-08 12:20 +0200
    Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-09-08 12:30 +0200
      Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Phidias Chiang <phidias.chiang@canonical.com> - 2016-09-08 18:30 +0200
        Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-09-09 08:30 +0200
          Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Phidias Chiang <phidias.chiang@canonical.com> - 2016-09-09 10:30 +0200
            Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-09-09 11:00 +0200

#1479032 — Re: [PATCH] pinctrl: cherryview: Do not mask all interrupts on probe

On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> > <mika.westerberg@linux.intel.com> wrote:
> > > On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> > >> pin 25 (GPIO_SUS6) GPIO ctrl0 0xec918201 ctrl1 0x05c00001
> > >
> > > It is this one (GPIO_SUS6).
> > >
> > > I wonder if we can relax the driver so that it only masks pins which are
> > > not configured to generate interrupts by the BIOS. I quickly tried
> > > following on one Braswell machine and it did not generate spurious
> > > interrupts.
> > >
> > > Can you check if this works for you?
> > 
> > I tried it, your patch is working. It gives the same result as not
> > clearing the north community. I receive the ACPI events.
> 
> OK, thanks for testing.
> 
> I'll make a formal patch and submit it with you CC'd. Let's hope it will
> not break anything :)

Hi, we've also found this issue on HP X360, but both patches don't work
with on it.

My current workaround is to save INTMASK before clearing then restore
it after, but I'm not sure if there's any side-effect by doing so.

[toc] | [next] | [standalone]

#1479047

On Thu, Sep 08, 2016 at 06:13:03PM +0800, Phidias Chiang wrote:
> On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> > On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > > On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> > > <mika.westerberg@linux.intel.com> wrote:
> > > > On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> > > >> pin 25 (GPIO_SUS6) GPIO ctrl0 0xec918201 ctrl1 0x05c00001
> > > >
> > > > It is this one (GPIO_SUS6).
> > > >
> > > > I wonder if we can relax the driver so that it only masks pins which are
> > > > not configured to generate interrupts by the BIOS. I quickly tried
> > > > following on one Braswell machine and it did not generate spurious
> > > > interrupts.
> > > >
> > > > Can you check if this works for you?
> > > 
> > > I tried it, your patch is working. It gives the same result as not
> > > clearing the north community. I receive the ACPI events.
> > 
> > OK, thanks for testing.
> > 
> > I'll make a formal patch and submit it with you CC'd. Let's hope it will
> > not break anything :)
> 
> Hi, we've also found this issue on HP X360, but both patches don't work
> with on it.
> 
> My current workaround is to save INTMASK before clearing then restore
> it after, but I'm not sure if there's any side-effect by doing so.

Did you try the latest patch here?

https://patchwork.ozlabs.org/patch/661413/

[toc] | [prev] | [next] | [standalone]

#1479366

On Thu, Sep 08, 2016 at 01:24:02PM +0300, Mika Westerberg wrote:
> On Thu, Sep 08, 2016 at 06:13:03PM +0800, Phidias Chiang wrote:
> > On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> > > On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > > > On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> > > > <mika.westerberg@linux.intel.com> wrote:
> > > > > On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> > > > >> pin 25 (GPIO_SUS6) GPIO ctrl0 0xec918201 ctrl1 0x05c00001
> > > > >
> > > > > It is this one (GPIO_SUS6).
> > > > >
> > > > > I wonder if we can relax the driver so that it only masks pins which are
> > > > > not configured to generate interrupts by the BIOS. I quickly tried
> > > > > following on one Braswell machine and it did not generate spurious
> > > > > interrupts.
> > > > >
> > > > > Can you check if this works for you?
> > > > 
> > > > I tried it, your patch is working. It gives the same result as not
> > > > clearing the north community. I receive the ACPI events.
> > > 
> > > OK, thanks for testing.
> > > 
> > > I'll make a formal patch and submit it with you CC'd. Let's hope it will
> > > not break anything :)
> > 
> > Hi, we've also found this issue on HP X360, but both patches don't work
> > with on it.
> > 
> > My current workaround is to save INTMASK before clearing then restore
> > it after, but I'm not sure if there's any side-effect by doing so.
> 
> Did you try the latest patch here?
> 
> https://patchwork.ozlabs.org/patch/661413/

yes, that, including another patch in this thread. I inserted some debug
message and found out INTMASK was still cleared after `gpiochip_irqchip_add`,
hope it helps.

[toc] | [prev] | [next] | [standalone]

#1479679

On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> On Thu, Sep 08, 2016 at 01:24:02PM +0300, Mika Westerberg wrote:
> > On Thu, Sep 08, 2016 at 06:13:03PM +0800, Phidias Chiang wrote:
> > > On Thu, Aug 18, 2016 at 04:58:13PM +0300, Mika Westerberg wrote:
> > > > On Thu, Aug 18, 2016 at 03:52:57PM +0200, Anisse Astier wrote:
> > > > > On Thu, Aug 18, 2016 at 2:13 PM, Mika Westerberg
> > > > > <mika.westerberg@linux.intel.com> wrote:
> > > > > > On Wed, Aug 17, 2016 at 03:42:58PM +0200, Anisse Astier wrote:
> > > > > >> pin 25 (GPIO_SUS6) GPIO ctrl0 0xec918201 ctrl1 0x05c00001
> > > > > >
> > > > > > It is this one (GPIO_SUS6).
> > > > > >
> > > > > > I wonder if we can relax the driver so that it only masks pins which are
> > > > > > not configured to generate interrupts by the BIOS. I quickly tried
> > > > > > following on one Braswell machine and it did not generate spurious
> > > > > > interrupts.
> > > > > >
> > > > > > Can you check if this works for you?
> > > > > 
> > > > > I tried it, your patch is working. It gives the same result as not
> > > > > clearing the north community. I receive the ACPI events.
> > > > 
> > > > OK, thanks for testing.
> > > > 
> > > > I'll make a formal patch and submit it with you CC'd. Let's hope it will
> > > > not break anything :)
> > > 
> > > Hi, we've also found this issue on HP X360, but both patches don't work
> > > with on it.
> > > 
> > > My current workaround is to save INTMASK before clearing then restore
> > > it after, but I'm not sure if there's any side-effect by doing so.
> > 
> > Did you try the latest patch here?
> > 
> > https://patchwork.ozlabs.org/patch/661413/
> 
> yes, that, including another patch in this thread. I inserted some debug
> message and found out INTMASK was still cleared after `gpiochip_irqchip_add`,
> hope it helps.

Hmm, how can that happen? The patch removes clearing of INTMASK and only
other place where it is cleared temporarily is on resume. Can you add
dev_info() calls like:

	/* Clear all interrupts */
	chv_writel(0xffff, pctrl->regs + CHV_INTSTAT);
	dev_info(pctrl->dev, "INTMASK0: 0x%08x\n", readl(pctrl->regs + CHV_INTMASK));

	...

	gpiochip_set_chained_irqchip(chip, &chv_gpio_irqchip, irq,
				     chv_gpio_irq_handler);
	dev_info(pctrl->dev, "INTMASK1: 0x%08x\n", readl(pctrl->regs + CHV_INTMASK));
	return 0;

It should print the same values both time.

Also which interrupt does not work and can you send me output of
/proc/interrupts?

[toc] | [prev] | [next] | [standalone]

#1479737

On Fri, Sep 09, 2016 at 09:18:34AM +0300, Mika Westerberg wrote:
> On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> 
> Hmm, how can that happen? The patch removes clearing of INTMASK and only
> other place where it is cleared temporarily is on resume. Can you add
> dev_info() calls like:
> 
> 	/* Clear all interrupts */
> 	chv_writel(0xffff, pctrl->regs + CHV_INTSTAT);
> 	dev_info(pctrl->dev, "INTMASK0: 0x%08x\n", readl(pctrl->regs + CHV_INTMASK));
> 
> 	...
> 
> 	gpiochip_set_chained_irqchip(chip, &chv_gpio_irqchip, irq,
> 				     chv_gpio_irq_handler);
> 	dev_info(pctrl->dev, "INTMASK1: 0x%08x\n", readl(pctrl->regs + CHV_INTMASK));
> 	return 0;
> 
> It should print the same values both time.
> 
> Also which interrupt does not work and can you send me output of
> /proc/interrupts?

Output in dmesg:
[    2.054475] cherryview-pinctrl INT33FF:00: INTMASK0: 0x00000006
[    2.055247] cherryview-pinctrl INT33FF:00: INTMASK1: 0x00000000
[    2.055375] cherryview-pinctrl INT33FF:01: INTMASK0: 0x00004000
[    2.056931] cherryview-pinctrl INT33FF:01: INTMASK1: 0x00000000
[    2.057036] cherryview-pinctrl INT33FF:02: INTMASK0: 0x00000000
[    2.057367] cherryview-pinctrl INT33FF:02: INTMASK1: 0x00000000
[    2.057489] cherryview-pinctrl INT33FF:03: INTMASK0: 0x00000000
[    2.058337] cherryview-pinctrl INT33FF:03: INTMASK1: 0x00000000

So it's somehow got cleared in the process after.

And the following link is the complete /proc/interrupts:
http://pastebin.com/qwamyKZb

THe interrupt doesn't work is 9, when I made it work it responsed to
pressing hotkeys.

[toc] | [prev] | [next] | [standalone]

#1479763

On Fri, Sep 09, 2016 at 04:23:58PM +0800, Phidias Chiang wrote:
> On Fri, Sep 09, 2016 at 09:18:34AM +0300, Mika Westerberg wrote:
> > On Fri, Sep 09, 2016 at 12:28:43AM +0800, Phidias Chiang wrote:
> > 
> > Hmm, how can that happen? The patch removes clearing of INTMASK and only
> > other place where it is cleared temporarily is on resume. Can you add
> > dev_info() calls like:
> > 
> > 	/* Clear all interrupts */
> > 	chv_writel(0xffff, pctrl->regs + CHV_INTSTAT);
> > 	dev_info(pctrl->dev, "INTMASK0: 0x%08x\n", readl(pctrl->regs + CHV_INTMASK));
> > 
> > 	...
> > 
> > 	gpiochip_set_chained_irqchip(chip, &chv_gpio_irqchip, irq,
> > 				     chv_gpio_irq_handler);
> > 	dev_info(pctrl->dev, "INTMASK1: 0x%08x\n", readl(pctrl->regs + CHV_INTMASK));
> > 	return 0;
> > 
> > It should print the same values both time.
> > 
> > Also which interrupt does not work and can you send me output of
> > /proc/interrupts?
> 
> Output in dmesg:
> [    2.054475] cherryview-pinctrl INT33FF:00: INTMASK0: 0x00000006
> [    2.055247] cherryview-pinctrl INT33FF:00: INTMASK1: 0x00000000
> [    2.055375] cherryview-pinctrl INT33FF:01: INTMASK0: 0x00004000
> [    2.056931] cherryview-pinctrl INT33FF:01: INTMASK1: 0x00000000
> [    2.057036] cherryview-pinctrl INT33FF:02: INTMASK0: 0x00000000
> [    2.057367] cherryview-pinctrl INT33FF:02: INTMASK1: 0x00000000
> [    2.057489] cherryview-pinctrl INT33FF:03: INTMASK0: 0x00000000
> [    2.058337] cherryview-pinctrl INT33FF:03: INTMASK1: 0x00000000
> 
> So it's somehow got cleared in the process after.

Only other place where we touch INTMASK register is
chv_gpio_irq_mask_unmask(). Can you add some debug there to find out the
caller?

> And the following link is the complete /proc/interrupts:
> http://pastebin.com/qwamyKZb

Looks quite normal.

> THe interrupt doesn't work is 9, when I made it work it responsed to
> pressing hotkeys.

9 is the SCI interrupt used by ACPI which explains.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web