Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1452653 > unrolled thread
| Started by | John Stultz <john.stultz@linaro.org> |
|---|---|
| First post | 2016-07-30 06:40 +0200 |
| Last post | 2016-08-08 23:50 +0200 |
| Articles | 20 on this page of 23 — 6 participants |
Back to article view | Back to linux.kernel
[Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons John Stultz <john.stultz@linaro.org> - 2016-07-30 06:40 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Bjorn Andersson <bjorn.andersson@linaro.org> - 2016-07-30 07:00 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Marc Zyngier <marc.zyngier@arm.com> - 2016-07-30 13:20 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Thomas Gleixner <tglx@linutronix.de> - 2016-07-30 10:20 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons John Stultz <john.stultz@linaro.org> - 2016-08-05 20:20 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Jon Hunter <jonathanh@nvidia.com> - 2016-08-08 11:40 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Linus Walleij <linus.walleij@linaro.org> - 2016-08-09 00:00 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Linus Walleij <linus.walleij@linaro.org> - 2016-08-08 23:40 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Jon Hunter <jonathanh@nvidia.com> - 2016-08-01 12:30 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons John Stultz <john.stultz@linaro.org> - 2016-08-06 23:50 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Jon Hunter <jonathanh@nvidia.com> - 2016-08-08 11:40 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons John Stultz <john.stultz@linaro.org> - 2016-08-09 06:30 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Jon Hunter <jonathanh@nvidia.com> - 2016-08-09 15:30 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Marc Zyngier <marc.zyngier@arm.com> - 2016-08-09 17:10 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Linus Walleij <linus.walleij@linaro.org> - 2016-08-10 01:10 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Jon Hunter <jonathanh@nvidia.com> - 2016-08-10 20:10 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Marc Zyngier <marc.zyngier@arm.com> - 2016-08-10 20:50 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Linus Walleij <linus.walleij@linaro.org> - 2016-08-10 21:50 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Jon Hunter <jonathanh@nvidia.com> - 2016-08-10 23:00 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Linus Walleij <linus.walleij@linaro.org> - 2016-08-10 21:10 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Marc Zyngier <marc.zyngier@arm.com> - 2016-08-10 21:40 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Marc Zyngier <marc.zyngier@arm.com> - 2016-08-10 22:00 +0200
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons Linus Walleij <linus.walleij@linaro.org> - 2016-08-08 23:50 +0200
Page 1 of 2 [1] 2 Next page →
| From | John Stultz <john.stultz@linaro.org> |
|---|---|
| Date | 2016-07-30 06:40 +0200 |
| Subject | [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s0ue5-6ai-1@gated-at.bofh.it> |
Hey Jon,
So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
noticed the power/volume buttons stopped working.
I did a manual rebased bisection and chased it down to your commit
1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
Reverting that patch makes things work again, so I wanted to see if
there was any debugging info I could provide to try to help narrow
down the problem here. (Sorry, I'd tinker myself with it some and try
to debug the issue, but after burning my friday night on this, I'm
eager to get away from the keyboard for the weekend).
thanks
-john
[toc] | [next] | [standalone]
| From | Bjorn Andersson <bjorn.andersson@linaro.org> |
|---|---|
| Date | 2016-07-30 07:00 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s0uxs-6h2-11@gated-at.bofh.it> |
| In reply to | #1452653 |
On Fri 29 Jul 21:39 PDT 2016, John Stultz wrote:
> Hey Jon,
> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
> noticed the power/volume buttons stopped working.
>
+Linus, as that's gpio-keys on top of two fairly standard gpio/pinctrl
drivers (8064 TLMM and SSBI).
Regards,
Bjorn
> I did a manual rebased bisection and chased it down to your commit
> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>
> Reverting that patch makes things work again, so I wanted to see if
> there was any debugging info I could provide to try to help narrow
> down the problem here. (Sorry, I'd tinker myself with it some and try
> to debug the issue, but after burning my friday night on this, I'm
> eager to get away from the keyboard for the weekend).
>
> thanks
> -john
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2016-07-30 13:20 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s0Atb-1MQ-13@gated-at.bofh.it> |
| In reply to | #1452655 |
On Fri, 29 Jul 2016 21:52:01 -0700
Bjorn Andersson <bjorn.andersson@linaro.org> wrote:
> On Fri 29 Jul 21:39 PDT 2016, John Stultz wrote:
>
> > Hey Jon,
> > So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
> > noticed the power/volume buttons stopped working.
> >
>
> +Linus, as that's gpio-keys on top of two fairly standard gpio/pinctrl
> drivers (8064 TLMM and SSBI).
>
> Regards,
> Bjorn
>
> > I did a manual rebased bisection and chased it down to your commit
> > 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
> >
> > Reverting that patch makes things work again, so I wanted to see if
> > there was any debugging info I could provide to try to help narrow
> > down the problem here. (Sorry, I'd tinker myself with it some and try
> > to debug the issue, but after burning my friday night on this, I'm
> > eager to get away from the keyboard for the weekend).
It feels either like a case of trigger information not being provided
through DT *and* not passed as arguments to request_irq (and friends),
or like a conflicting trigger.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-07-30 10:20 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s0xEZ-8qi-5@gated-at.bofh.it> |
| In reply to | #1452653 |
On Fri, 29 Jul 2016, John Stultz wrote:
> Hey Jon,
> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
> noticed the power/volume buttons stopped working.
>
> I did a manual rebased bisection and chased it down to your commit
> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>
> Reverting that patch makes things work again, so I wanted to see if
> there was any debugging info I could provide to try to help narrow
> down the problem here. (Sorry, I'd tinker myself with it some and try
> to debug the issue, but after burning my friday night on this, I'm
> eager to get away from the keyboard for the weekend).
dmesg should contain debug output which yells about non matching types. Can
you provide that?
Thanks,
tglx
[toc] | [prev] | [next] | [standalone]
| From | John Stultz <john.stultz@linaro.org> |
|---|---|
| Date | 2016-08-05 20:20 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s2RSV-2B6-11@gated-at.bofh.it> |
| In reply to | #1452660 |
[Multipart message — attachments visible in raw view] — view raw
On Sat, Jul 30, 2016 at 1:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 29 Jul 2016, John Stultz wrote:
>> Hey Jon,
>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>> noticed the power/volume buttons stopped working.
>>
>> I did a manual rebased bisection and chased it down to your commit
>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>
>> Reverting that patch makes things work again, so I wanted to see if
>> there was any debugging info I could provide to try to help narrow
>> down the problem here. (Sorry, I'd tinker myself with it some and try
>> to debug the issue, but after burning my friday night on this, I'm
>> eager to get away from the keyboard for the weekend).
>
> dmesg should contain debug output which yells about non matching types. Can
> you provide that?
I'm not seeing anything about problematic type matching in the dmesg.
I've also added LinusW's patches but that didn't seem to help either.
dmesg attached.
thanks
-john
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-08 11:40 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s3Pcm-82a-27@gated-at.bofh.it> |
| In reply to | #1457229 |
On 05/08/16 19:12, John Stultz wrote:
> On Sat, Jul 30, 2016 at 1:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> On Fri, 29 Jul 2016, John Stultz wrote:
>>> Hey Jon,
>>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>>> noticed the power/volume buttons stopped working.
>>>
>>> I did a manual rebased bisection and chased it down to your commit
>>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>>
>>> Reverting that patch makes things work again, so I wanted to see if
>>> there was any debugging info I could provide to try to help narrow
>>> down the problem here. (Sorry, I'd tinker myself with it some and try
>>> to debug the issue, but after burning my friday night on this, I'm
>>> eager to get away from the keyboard for the weekend).
>>
>> dmesg should contain debug output which yells about non matching types. Can
>> you provide that?
>
> I'm not seeing anything about problematic type matching in the dmesg.
>
> I've also added LinusW's patches but that didn't seem to help either.
>
> dmesg attached.
I am wondering if it is related to ...
[ 1.678160] apq8064-pinctrl 800000.pinctrl: pin GPIO_16 already requested by 16540000.serial; cannot claim for 16580000.i2c
[ 1.678207] apq8064-pinctrl 800000.pinctrl: pin-16 (16580000.i2c) status -22
[ 1.678362] 1-0010 supply vcc33 not found, using dummy regulator
[ 1.678779] 1-0010 supply vccio not found, using dummy regulator
[ 1.702427] apq8064-pinctrl 800000.pinctrl: could not request pin 16 (GPIO_16) from group gpio16 on device 800000.pinctrl
Cheers
Jon
--
nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2016-08-09 00:00 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s40Kt-6Wq-3@gated-at.bofh.it> |
| In reply to | #1457664 |
On Mon, Aug 8, 2016 at 11:04 AM, Jon Hunter <jonathanh@nvidia.com> wrote: > I am wondering if it is related to ... > > [ 1.678160] apq8064-pinctrl 800000.pinctrl: pin GPIO_16 already requested by 16540000.serial; cannot claim for 16580000.i2c > [ 1.678207] apq8064-pinctrl 800000.pinctrl: pin-16 (16580000.i2c) status -22 > [ 1.678362] 1-0010 supply vcc33 not found, using dummy regulator > [ 1.678779] 1-0010 supply vccio not found, using dummy regulator > [ 1.702427] apq8064-pinctrl 800000.pinctrl: could not request pin 16 (GPIO_16) from group gpio16 on device 800000.pinctrl I don't think so. That looks like a straight-formward pin conflict where the i2c is tossed out because the pins it tries to take are already taken by the serial. Has nothing to do with any IRQs. It's not neat but a different issue. Yours, Linus Walleij
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2016-08-08 23:40 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s40r7-6NC-7@gated-at.bofh.it> |
| In reply to | #1452660 |
On Sat, Jul 30, 2016 at 10:07 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Fri, 29 Jul 2016, John Stultz wrote:
>> Hey Jon,
>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>> noticed the power/volume buttons stopped working.
>>
>> I did a manual rebased bisection and chased it down to your commit
>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>
>> Reverting that patch makes things work again, so I wanted to see if
>> there was any debugging info I could provide to try to help narrow
>> down the problem here. (Sorry, I'd tinker myself with it some and try
>> to debug the issue, but after burning my friday night on this, I'm
>> eager to get away from the keyboard for the weekend).
>
> dmesg should contain debug output which yells about non matching types. Can
> you provide that?
I had that problem *too* on the Qualcomm platforms (APQ8060, MSM8660
and the APQ8064 variants, but fixed it up with these two patches:
http://marc.info/?l=linux-arm-kernel&m=147038646226142&w=2
In addition to that there is some other problem, discussed in this
thread... I understand that less.
Yours,
Linus Walleij
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-01 12:30 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s1iDU-53D-23@gated-at.bofh.it> |
| In reply to | #1452653 |
Hi John,
On 30/07/16 05:39, John Stultz wrote:
> Hey Jon,
> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
> noticed the power/volume buttons stopped working.
>
> I did a manual rebased bisection and chased it down to your commit
> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>
> Reverting that patch makes things work again, so I wanted to see if
> there was any debugging info I could provide to try to help narrow
> down the problem here. (Sorry, I'd tinker myself with it some and try
> to debug the issue, but after burning my friday night on this, I'm
> eager to get away from the keyboard for the weekend).
Before this commit bad IRQ type settings in device-tree were not getting
reported and so failures to set the IRQ type were going unnoticed. It's
most likely a bad IRQ type settings somewhere.
As Thomas mentioned hopefully dmesg will shed a bit more light.
Otherwise it can be worth looking at the ->irq_set_type() function for
the irqchips in the path of the interrupt requested to see if any are
failing. Looking at the nexus7 (assuming qcom variant), it looks like
there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
type and could be worth checking. It does not look like the set_type for
the apq8064-pinctrl should ever fail (apart from calling BUG() which
would be obvious). The gic can also return a failure for setting the
type, but I did not see anything at first glance that looks incorrect in
the dts.
If we can narrow down irqchip, then hopefully it will be clearer.
Cheers
Jon
--
nvpublic
[toc] | [prev] | [next] | [standalone]
| From | John Stultz <john.stultz@linaro.org> |
|---|---|
| Date | 2016-08-06 23:50 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s3hDI-2QM-17@gated-at.bofh.it> |
| In reply to | #1453117 |
On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
> Hi John,
>
> On 30/07/16 05:39, John Stultz wrote:
>> Hey Jon,
>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>> noticed the power/volume buttons stopped working.
>>
>> I did a manual rebased bisection and chased it down to your commit
>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>
>> Reverting that patch makes things work again, so I wanted to see if
>> there was any debugging info I could provide to try to help narrow
>> down the problem here. (Sorry, I'd tinker myself with it some and try
>> to debug the issue, but after burning my friday night on this, I'm
>> eager to get away from the keyboard for the weekend).
>
> Before this commit bad IRQ type settings in device-tree were not getting
> reported and so failures to set the IRQ type were going unnoticed. It's
> most likely a bad IRQ type settings somewhere.
>
> As Thomas mentioned hopefully dmesg will shed a bit more light.
>
> Otherwise it can be worth looking at the ->irq_set_type() function for
> the irqchips in the path of the interrupt requested to see if any are
> failing. Looking at the nexus7 (assuming qcom variant), it looks like
> there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
> The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
> type and could be worth checking. It does not look like the set_type for
> the apq8064-pinctrl should ever fail (apart from calling BUG() which
> would be obvious). The gic can also return a failure for setting the
> type, but I did not see anything at first glance that looks incorrect in
> the dts.
>
> If we can narrow down irqchip, then hopefully it will be clearer.
The pm_8xxx_irq_set_type doesn't seem to be failing as far as I can see..
Looking at the patch that seems to cause the trouble, I narrowed it
down to just the following chunk:
@@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
irq_fwspec *fwspec)
* it now and return the interrupt number.
*/
if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
- irq_set_irq_type(virq, type);
+ irq_data = irq_get_irq_data(virq);
+ if (!irq_data)
+ return 0;
+
+ irqd_set_trigger_type(irq_data, type);
return virq;
}
If I revert just that, it works again.
I was worried we were hitting an early failure from !irq_data, but it
seems there's some subtle difference between irqd_set_trigger_type and
irq_set_type that makes the former break for me.
Still digging though.
thanks
-john
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-08 11:40 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s3Pcm-82a-23@gated-at.bofh.it> |
| In reply to | #1457379 |
On 06/08/16 00:45, John Stultz wrote:
> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>> Hi John,
>>
>> On 30/07/16 05:39, John Stultz wrote:
>>> Hey Jon,
>>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>>> noticed the power/volume buttons stopped working.
>>>
>>> I did a manual rebased bisection and chased it down to your commit
>>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>>
>>> Reverting that patch makes things work again, so I wanted to see if
>>> there was any debugging info I could provide to try to help narrow
>>> down the problem here. (Sorry, I'd tinker myself with it some and try
>>> to debug the issue, but after burning my friday night on this, I'm
>>> eager to get away from the keyboard for the weekend).
>>
>> Before this commit bad IRQ type settings in device-tree were not getting
>> reported and so failures to set the IRQ type were going unnoticed. It's
>> most likely a bad IRQ type settings somewhere.
>>
>> As Thomas mentioned hopefully dmesg will shed a bit more light.
>>
>> Otherwise it can be worth looking at the ->irq_set_type() function for
>> the irqchips in the path of the interrupt requested to see if any are
>> failing. Looking at the nexus7 (assuming qcom variant), it looks like
>> there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
>> The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
>> type and could be worth checking. It does not look like the set_type for
>> the apq8064-pinctrl should ever fail (apart from calling BUG() which
>> would be obvious). The gic can also return a failure for setting the
>> type, but I did not see anything at first glance that looks incorrect in
>> the dts.
>>
>> If we can narrow down irqchip, then hopefully it will be clearer.
>
> The pm_8xxx_irq_set_type doesn't seem to be failing as far as I can see..
>
> Looking at the patch that seems to cause the trouble, I narrowed it
> down to just the following chunk:
>
> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
> irq_fwspec *fwspec)
> * it now and return the interrupt number.
> */
> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
> - irq_set_irq_type(virq, type);
> + irq_data = irq_get_irq_data(virq);
> + if (!irq_data)
> + return 0;
> +
> + irqd_set_trigger_type(irq_data, type);
> return virq;
> }
>
> If I revert just that, it works again.
>
> I was worried we were hitting an early failure from !irq_data, but it
> seems there's some subtle difference between irqd_set_trigger_type and
> irq_set_type that makes the former break for me.
Thanks this is good info and at the same time odd.
I am guessing that it is failing above because the irq_data is not found
for the irq?
What is odd, is that the above sequence is only executed if a irq
mapping exists and so really, AFAICT this should not happen. Ie. the irq
descriptor should have been allocated for the mapping to exist. We
should probably warn if this happens.
Without reverting the above, can you add a print to show the
domain->name, hwirq and virq information if !irq_data? That will confirm
the domain for us.
Also it could be worth enabling all the debug prints in
kernel/irq/irqdomain.c to see what is happening on boot.
Cheers
Jon
--
nvpublic
[toc] | [prev] | [next] | [standalone]
| From | John Stultz <john.stultz@linaro.org> |
|---|---|
| Date | 2016-08-09 06:30 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s46PT-2D5-3@gated-at.bofh.it> |
| In reply to | #1457663 |
On Mon, Aug 8, 2016 at 2:31 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>
> On 06/08/16 00:45, John Stultz wrote:
>> On Mon, Aug 1, 2016 at 3:26 AM, Jon Hunter <jonathanh@nvidia.com> wrote:
>>> Hi John,
>>>
>>> On 30/07/16 05:39, John Stultz wrote:
>>>> Hey Jon,
>>>> So after rebasing my nexus7 patch stack onto pre-4.8-rc1 tree, I
>>>> noticed the power/volume buttons stopped working.
>>>>
>>>> I did a manual rebased bisection and chased it down to your commit
>>>> 1e2a7d78499e ("irqdomain: Don't set type when mapping an IRQ").
>>>>
>>>> Reverting that patch makes things work again, so I wanted to see if
>>>> there was any debugging info I could provide to try to help narrow
>>>> down the problem here. (Sorry, I'd tinker myself with it some and try
>>>> to debug the issue, but after burning my friday night on this, I'm
>>>> eager to get away from the keyboard for the weekend).
>>>
>>> Before this commit bad IRQ type settings in device-tree were not getting
>>> reported and so failures to set the IRQ type were going unnoticed. It's
>>> most likely a bad IRQ type settings somewhere.
>>>
>>> As Thomas mentioned hopefully dmesg will shed a bit more light.
>>>
>>> Otherwise it can be worth looking at the ->irq_set_type() function for
>>> the irqchips in the path of the interrupt requested to see if any are
>>> failing. Looking at the nexus7 (assuming qcom variant), it looks like
>>> there are 3 irqchips in the path (pm8921 --> apq8064-pinctrl --> gic).
>>> The pm8xxx_irq_set_type() could return a failure when setting up the IRQ
>>> type and could be worth checking. It does not look like the set_type for
>>> the apq8064-pinctrl should ever fail (apart from calling BUG() which
>>> would be obvious). The gic can also return a failure for setting the
>>> type, but I did not see anything at first glance that looks incorrect in
>>> the dts.
>>>
>>> If we can narrow down irqchip, then hopefully it will be clearer.
>>
>> The pm_8xxx_irq_set_type doesn't seem to be failing as far as I can see..
>>
>> Looking at the patch that seems to cause the trouble, I narrowed it
>> down to just the following chunk:
>>
>> @@ -614,7 +615,11 @@ unsigned int irq_create_fwspec_mapping(struct
>> irq_fwspec *fwspec)
>> * it now and return the interrupt number.
>> */
>> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
>> - irq_set_irq_type(virq, type);
>> + irq_data = irq_get_irq_data(virq);
>> + if (!irq_data)
>> + return 0;
>> +
>> + irqd_set_trigger_type(irq_data, type);
>> return virq;
>> }
>>
>> If I revert just that, it works again.
>>
>> I was worried we were hitting an early failure from !irq_data, but it
>> seems there's some subtle difference between irqd_set_trigger_type and
>> irq_set_type that makes the former break for me.
>
> Thanks this is good info and at the same time odd.
>
> I am guessing that it is failing above because the irq_data is not found
> for the irq?
So actually no. We usually call irqd_set_trigger_type() but something
still doesn't work.
Interestingly, just adding irq_set_irq_type(virq, type); to the top of
that block (leaving the rest of the code) also works.
> What is odd, is that the above sequence is only executed if a irq
> mapping exists and so really, AFAICT this should not happen. Ie. the irq
> descriptor should have been allocated for the mapping to exist. We
> should probably warn if this happens.
>
> Without reverting the above, can you add a print to show the
> domain->name, hwirq and virq information if !irq_data? That will confirm
> the domain for us.
So I put some printk info in (in either case since I'm never seeing
the !irq_data case happen):
[ 1.514217] JDB: virq: 93 hwirq: 74 domain name: msmgpio
[ 1.838342] JDB: virq: 25 hwirq: 6 domain name: msmgpio
Which is odd, looking at:
shell@flo:/ $ cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
16: 1159 1138 1332 1574 GIC-0 18 Edge
gp_timer
25: 0 0 0 0 msmgpio 6 Edge
ekth3500
111: 6 0 0 0 GIC-0 51 Edge
qcom_rpm_ack
112: 0 0 0 0 GIC-0 53 Edge
qcom_rpm_err
113: 0 0 0 0 GIC-0 54 Edge
qcom_rpm_wakeup
114: 48 0 0 0 GIC-0 132 Edge
msm_otg, ci_hdrc_msm
115: 796 0 0 0 GIC-0 130 Level bam_dma
116: 0 0 0 0 GIC-0 128 Level bam_dma
117: 0 0 0 0 GIC-0 127 Level bam_dma
118: 2627 0 0 0 GIC-0 136 Level
mmci-pl18x (cmd)
119: 54 0 0 0 GIC-0 226 Level i2c_qup
120: 21 0 0 0 GIC-0 183 Level i2c_qup
122: 0 0 0 0 GIC-0 189 Level i2c_qup
123: 202 0 0 0 GIC-0 190 Level
msm_serial0
124: 0 0 0 0 GIC-0 70 Edge smsm
125: 0 0 0 0 GIC-0 121 Edge smsm
126: 0 0 0 0 GIC-0 236 Edge smsm
127: 0 0 0 0 GIC-0 169 Edge smsm
131: 0 0 0 0 pm8xxx 195 Edge
Volume Up
165: 0 0 0 0 pm8xxx 229 Edge
Volume Down
184: 0 0 0 0 pm8xxx 39 Edge
pm8xxx_rtc_alarm
185: 0 0 0 0 pm8xxx 50 Edge
pmic8xxx_pwrkey_release
186: 0 0 0 0 pm8xxx 51 Edge
pmic8xxx_pwrkey_press
IPI0: 0 1 1 1 CPU wakeup interrupts
IPI1: 0 0 0 0 Timer broadcast interrupts
IPI2: 944 539 1015 529 Rescheduling interrupts
IPI3: 1 4 6 4 Function call interrupts
IPI4: 0 0 0 0 CPU stop interrupts
IPI5: 0 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 completion interrupts
Err: 0
Since 25 maps to the ekth3500 (touch panel, which is still working
fine), but 93/74 doesn't seem to map to anything, and the problematic
irqs are the volume keys 195/229 and power keys 50/51.
thanks
-john
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-09 15:30 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4fgt-888-5@gated-at.bofh.it> |
| In reply to | #1458394 |
On 09/08/16 05:25, John Stultz wrote:
...
> So actually no. We usually call irqd_set_trigger_type() but something
> still doesn't work.
>
> Interestingly, just adding irq_set_irq_type(virq, type); to the top of
> that block (leaving the rest of the code) also works.
Interesting. By saving the trigger type during the mapping, we defer
setting the interrupt type to when the interrupt is requested. So this
would imply that the interrupt is not being setup as expected when its
requested.
>> What is odd, is that the above sequence is only executed if a irq
>> mapping exists and so really, AFAICT this should not happen. Ie. the irq
>> descriptor should have been allocated for the mapping to exist. We
>> should probably warn if this happens.
>>
>> Without reverting the above, can you add a print to show the
>> domain->name, hwirq and virq information if !irq_data? That will confirm
>> the domain for us.
>
> So I put some printk info in (in either case since I'm never seeing
> the !irq_data case happen):
>
> [ 1.514217] JDB: virq: 93 hwirq: 74 domain name: msmgpio
> [ 1.838342] JDB: virq: 25 hwirq: 6 domain name: msmgpio
>
> Which is odd, looking at:
>
> shell@flo:/ $ cat /proc/interrupts
> CPU0 CPU1 CPU2 CPU3
> 16: 1159 1138 1332 1574 GIC-0 18 Edge
> gp_timer
> 25: 0 0 0 0 msmgpio 6 Edge
> ekth3500
> 111: 6 0 0 0 GIC-0 51 Edge
> qcom_rpm_ack
> 112: 0 0 0 0 GIC-0 53 Edge
> qcom_rpm_err
> 113: 0 0 0 0 GIC-0 54 Edge
> qcom_rpm_wakeup
> 114: 48 0 0 0 GIC-0 132 Edge
> msm_otg, ci_hdrc_msm
> 115: 796 0 0 0 GIC-0 130 Level bam_dma
> 116: 0 0 0 0 GIC-0 128 Level bam_dma
> 117: 0 0 0 0 GIC-0 127 Level bam_dma
> 118: 2627 0 0 0 GIC-0 136 Level
> mmci-pl18x (cmd)
> 119: 54 0 0 0 GIC-0 226 Level i2c_qup
> 120: 21 0 0 0 GIC-0 183 Level i2c_qup
> 122: 0 0 0 0 GIC-0 189 Level i2c_qup
> 123: 202 0 0 0 GIC-0 190 Level
> msm_serial0
> 124: 0 0 0 0 GIC-0 70 Edge smsm
> 125: 0 0 0 0 GIC-0 121 Edge smsm
> 126: 0 0 0 0 GIC-0 236 Edge smsm
> 127: 0 0 0 0 GIC-0 169 Edge smsm
> 131: 0 0 0 0 pm8xxx 195 Edge
> Volume Up
> 165: 0 0 0 0 pm8xxx 229 Edge
> Volume Down
> 184: 0 0 0 0 pm8xxx 39 Edge
> pm8xxx_rtc_alarm
> 185: 0 0 0 0 pm8xxx 50 Edge
> pmic8xxx_pwrkey_release
> 186: 0 0 0 0 pm8xxx 51 Edge
> pmic8xxx_pwrkey_press
> IPI0: 0 1 1 1 CPU wakeup interrupts
> IPI1: 0 0 0 0 Timer broadcast interrupts
> IPI2: 944 539 1015 529 Rescheduling interrupts
> IPI3: 1 4 6 4 Function call interrupts
> IPI4: 0 0 0 0 CPU stop interrupts
> IPI5: 0 0 0 0 IRQ work interrupts
> IPI6: 0 0 0 0 completion interrupts
> Err: 0
>
> Since 25 maps to the ekth3500 (touch panel, which is still working
> fine), but 93/74 doesn't seem to map to anything, and the problematic
> irqs are the volume keys 195/229 and power keys 50/51.
So looking at the DT source, I believe that hwirq 74 (virq 93) is the
problem. This is the parent interrupt from the pm8xxx to the apq8064
if it is not requested then the type is not set. It seems that for
parent interrupts these are not typically requested, but enabled when
an irqchip is chained.
To confirm and for testing purposes I am curious if this works ...
if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
irq_data = irq_get_irq_data(virq);
if (!irq_data)
return 0;
- irqd_set_trigger_type(irq_data, type);
+ if (hwirq == 74)
+ irq_set_irq_type(virq, type);
+ else
+ irqd_set_trigger_type(irq_data, type);
return virq;
}
If that works, then does the following also work (without the above) ...
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index b4c1bc7c9ca2..e111b72e3162 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle,
irq_settings_set_norequest(desc);
irq_settings_set_nothread(desc);
desc->action = &chained_action;
+ __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data));
irq_startup(desc, true);
}
}
It looks like there is a path for parent interrupts where the type
is not getting set. If the above works then we can discuss with Thomas
and Marc on the correct fix.
Cheers
Jon
--
nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2016-08-09 17:10 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4gPg-NP-25@gated-at.bofh.it> |
| In reply to | #1458735 |
On 09/08/16 14:20, Jon Hunter wrote:
>
> On 09/08/16 05:25, John Stultz wrote:
>
> ...
>
>> So actually no. We usually call irqd_set_trigger_type() but something
>> still doesn't work.
>>
>> Interestingly, just adding irq_set_irq_type(virq, type); to the top of
>> that block (leaving the rest of the code) also works.
>
> Interesting. By saving the trigger type during the mapping, we defer
> setting the interrupt type to when the interrupt is requested. So this
> would imply that the interrupt is not being setup as expected when its
> requested.
>
>>> What is odd, is that the above sequence is only executed if a irq
>>> mapping exists and so really, AFAICT this should not happen. Ie. the irq
>>> descriptor should have been allocated for the mapping to exist. We
>>> should probably warn if this happens.
>>>
>>> Without reverting the above, can you add a print to show the
>>> domain->name, hwirq and virq information if !irq_data? That will confirm
>>> the domain for us.
>>
>> So I put some printk info in (in either case since I'm never seeing
>> the !irq_data case happen):
>>
>> [ 1.514217] JDB: virq: 93 hwirq: 74 domain name: msmgpio
>> [ 1.838342] JDB: virq: 25 hwirq: 6 domain name: msmgpio
>>
>> Which is odd, looking at:
>>
>> shell@flo:/ $ cat /proc/interrupts
>> CPU0 CPU1 CPU2 CPU3
>> 16: 1159 1138 1332 1574 GIC-0 18 Edge
>> gp_timer
>> 25: 0 0 0 0 msmgpio 6 Edge
>> ekth3500
>> 111: 6 0 0 0 GIC-0 51 Edge
>> qcom_rpm_ack
>> 112: 0 0 0 0 GIC-0 53 Edge
>> qcom_rpm_err
>> 113: 0 0 0 0 GIC-0 54 Edge
>> qcom_rpm_wakeup
>> 114: 48 0 0 0 GIC-0 132 Edge
>> msm_otg, ci_hdrc_msm
>> 115: 796 0 0 0 GIC-0 130 Level bam_dma
>> 116: 0 0 0 0 GIC-0 128 Level bam_dma
>> 117: 0 0 0 0 GIC-0 127 Level bam_dma
>> 118: 2627 0 0 0 GIC-0 136 Level
>> mmci-pl18x (cmd)
>> 119: 54 0 0 0 GIC-0 226 Level i2c_qup
>> 120: 21 0 0 0 GIC-0 183 Level i2c_qup
>> 122: 0 0 0 0 GIC-0 189 Level i2c_qup
>> 123: 202 0 0 0 GIC-0 190 Level
>> msm_serial0
>> 124: 0 0 0 0 GIC-0 70 Edge smsm
>> 125: 0 0 0 0 GIC-0 121 Edge smsm
>> 126: 0 0 0 0 GIC-0 236 Edge smsm
>> 127: 0 0 0 0 GIC-0 169 Edge smsm
>> 131: 0 0 0 0 pm8xxx 195 Edge
>> Volume Up
>> 165: 0 0 0 0 pm8xxx 229 Edge
>> Volume Down
>> 184: 0 0 0 0 pm8xxx 39 Edge
>> pm8xxx_rtc_alarm
>> 185: 0 0 0 0 pm8xxx 50 Edge
>> pmic8xxx_pwrkey_release
>> 186: 0 0 0 0 pm8xxx 51 Edge
>> pmic8xxx_pwrkey_press
>> IPI0: 0 1 1 1 CPU wakeup interrupts
>> IPI1: 0 0 0 0 Timer broadcast interrupts
>> IPI2: 944 539 1015 529 Rescheduling interrupts
>> IPI3: 1 4 6 4 Function call interrupts
>> IPI4: 0 0 0 0 CPU stop interrupts
>> IPI5: 0 0 0 0 IRQ work interrupts
>> IPI6: 0 0 0 0 completion interrupts
>> Err: 0
>>
>> Since 25 maps to the ekth3500 (touch panel, which is still working
>> fine), but 93/74 doesn't seem to map to anything, and the problematic
>> irqs are the volume keys 195/229 and power keys 50/51.
>
> So looking at the DT source, I believe that hwirq 74 (virq 93) is the
> problem. This is the parent interrupt from the pm8xxx to the apq8064
> if it is not requested then the type is not set. It seems that for
> parent interrupts these are not typically requested, but enabled when
> an irqchip is chained.
>
> To confirm and for testing purposes I am curious if this works ...
>
> if (irq_get_trigger_type(virq) == IRQ_TYPE_NONE) {
> irq_data = irq_get_irq_data(virq);
> if (!irq_data)
> return 0;
>
> - irqd_set_trigger_type(irq_data, type);
> + if (hwirq == 74)
> + irq_set_irq_type(virq, type);
> + else
> + irqd_set_trigger_type(irq_data, type);
> return virq;
> }
>
> If that works, then does the following also work (without the above) ...
>
> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> index b4c1bc7c9ca2..e111b72e3162 100644
> --- a/kernel/irq/chip.c
> +++ b/kernel/irq/chip.c
> @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle,
> irq_settings_set_norequest(desc);
> irq_settings_set_nothread(desc);
> desc->action = &chained_action;
> + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data));
> irq_startup(desc, true);
> }
> }
>
> It looks like there is a path for parent interrupts where the type
> is not getting set. If the above works then we can discuss with Thomas
> and Marc on the correct fix.
This definitely looks like an something that is worth a patch anyway, as
I otherwise don't see how we configure cascaded interrupts with the new
deferred scheme.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2016-08-10 01:10 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4ojL-5xv-1@gated-at.bofh.it> |
| In reply to | #1458735 |
On Tue, Aug 9, 2016 at 3:20 PM, Jon Hunter <jonathanh@nvidia.com> wrote: > If that works, then does the following also work (without the above) ... > > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c > index b4c1bc7c9ca2..e111b72e3162 100644 > --- a/kernel/irq/chip.c > +++ b/kernel/irq/chip.c > @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle, > irq_settings_set_norequest(desc); > irq_settings_set_nothread(desc); > desc->action = &chained_action; > + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); > irq_startup(desc, true); > } > } > > It looks like there is a path for parent interrupts where the type > is not getting set. If the above works then we can discuss with Thomas > and Marc on the correct fix. I tried this on my problematic platform and then this happens: preparing networking... [ 2.628246] ------------[ cut here ]------------ [ 2.628303] WARNING: CPU: 0 PID: 92 at ../kernel/irq/chip.c:26 bad_chained_irq+0x44/0x4c [ 2.631939] Chained irq 109 should not call an action [ 2.640008] Modules linked in: [ 2.647909] CPU: 0 PID: 92 Comm: ip Not tainted 4.8.0-rc1-00011-ga21e27b4cb66 #194 [ 2.647996] Hardware name: Generic DT based system [ 2.655486] [<c030f8c8>] (unwind_backtrace) from [<c030c714>] (show_stack+0x10/0x14) [ 2.660254] [<c030c714>] (show_stack) from [<c05df420>] (dump_stack+0x78/0x8c) [ 2.668147] [<c05df420>] (dump_stack) from [<c031cef4>] (__warn+0xec/0x104) [ 2.675173] [<c031cef4>] (__warn) from [<c031cf44>] (warn_slowpath_fmt+0x38/0x48) [ 2.682033] [<c031cf44>] (warn_slowpath_fmt) from [<c0369160>] (bad_chained_irq+0x44/0x4c) [ 2.689687] [<c0369160>] (bad_chained_irq) from [<c0365e28>] (__handle_irq_event_percpu+0x5c/0x290) [ 2.697836] [<c0365e28>] (__handle_irq_event_percpu) from [<c0366078>] (handle_irq_event_percpu+0x1c/0x58) [ 2.706778] [<c0366078>] (handle_irq_event_percpu) from [<c03660ec>] (handle_irq_event+0x38/0x5c) [ 2.716498] [<c03660ec>] (handle_irq_event) from [<c03693f0>] (handle_level_irq+0xc4/0x150) [ 2.725438] [<c03693f0>] (handle_level_irq) from [<c036542c>] (generic_handle_irq+0x24/0x34) [ 2.733602] [<c036542c>] (generic_handle_irq) from [<c06127d4>] (msm_gpio_irq_handler+0xc8/0x150) [ 2.742280] [<c06127d4>] (msm_gpio_irq_handler) from [<c036542c>] (generic_handle_irq+0x24/0x34) [ 2.751048] [<c036542c>] (generic_handle_irq) from [<c0365720>] (__handle_domain_irq+0x7c/0xec) [ 2.759901] [<c0365720>] (__handle_domain_irq) from [<c0301464>] (gic_handle_irq+0x48/0x8c) [ 2.768323] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] (__irq_svc+0x6c/0xa8) [ 2.776644] Exception stack(0xdeca1d48 to 0xdeca1d90) [ 2.784284] 1d40: deca1dc0 00000000 00000000 deca0018 ffff8bd6 deca1dc0 [ 2.789324] 1d60: 00000000 c0378ad0 60070013 00000000 00000000 001f3df8 c108fa04 deca1d98 [ 2.797481] 1d80: c08b77fc c0377930 60070013 ffffffff [ 2.805651] [<c08b8e4c>] (__irq_svc) from [<c0377930>] (init_timer_key+0x28/0x104) [ 2.810679] [<c0377930>] (init_timer_key) from [<c08b77fc>] (schedule_timeout+0x48/0x410) [ 2.818145] [<c08b77fc>] (schedule_timeout) from [<c0378ad0>] (msleep+0x2c/0x38) [ 2.826399] [<c0378ad0>] (msleep) from [<c06c2980>] (smsc911x_open+0x268/0x50c) [ 2.833859] [<c06c2980>] (smsc911x_open) from [<c07c1994>] (__dev_open+0xa8/0x10c) [ 2.840887] [<c07c1994>] (__dev_open) from [<c07c1c1c>] (__dev_change_flags+0x94/0x144) [ 2.848525] [<c07c1c1c>] (__dev_change_flags) from [<c07c1ce4>] (dev_change_flags+0x18/0x48) [ 2.856428] [<c07c1ce4>] (dev_change_flags) from [<c0823048>] (devinet_ioctl+0x6b0/0x768) [ 2.865120] [<c0823048>] (devinet_ioctl) from [<c07a4ac4>] (sock_ioctl+0x1f4/0x2c8) [ 2.873186] [<c07a4ac4>] (sock_ioctl) from [<c0432678>] (do_vfs_ioctl+0x9c/0x910) [ 2.880645] [<c0432678>] (do_vfs_ioctl) from [<c0432f20>] (SyS_ioctl+0x34/0x5c) [ 2.888290] [<c0432f20>] (SyS_ioctl) from [<c0308480>] (ret_fast_syscall+0x0/0x3c) [ 2.895395] ---[ end trace a53e1e63b7bdfc4a ]--- [ 2.903917] random: fast init done [ 3.036378] random: crng init done [ 3.883906] irq 109: nobody cared (try booting with the "irqpoll" option) [ 3.883940] CPU: 0 PID: 92 Comm: ip Tainted: G W 4.8.0-rc1-00011-ga21e27b4cb66 #194 [ 3.889673] Hardware name: Generic DT based system [ 3.898538] [<c030f8c8>] (unwind_backtrace) from [<c030c714>] (show_stack+0x10/0x14) [ 3.903137] [<c030c714>] (show_stack) from [<c05df420>] (dump_stack+0x78/0x8c) [ 3.911034] [<c05df420>] (dump_stack) from [<c0368804>] (__report_bad_irq+0x28/0xcc) [ 3.918065] [<c0368804>] (__report_bad_irq) from [<c0368c18>] (note_interrupt+0x298/0x2e8) [ 3.925971] [<c0368c18>] (note_interrupt) from [<c03660a8>] (handle_irq_event_percpu+0x4c/0x58) [ 3.934040] [<c03660a8>] (handle_irq_event_percpu) from [<c03660ec>] (handle_irq_event+0x38/0x5c) [ 3.942634] [<c03660ec>] (handle_irq_event) from [<c03693f0>] (handle_level_irq+0xc4/0x150) [ 3.951660] [<c03693f0>] (handle_level_irq) from [<c036542c>] (generic_handle_irq+0x24/0x34) [ 3.959821] [<c036542c>] (generic_handle_irq) from [<c06127d4>] (msm_gpio_irq_handler+0xc8/0x150) [ 3.968502] [<c06127d4>] (msm_gpio_irq_handler) from [<c036542c>] (generic_handle_irq+0x24/0x34) [ 3.977269] [<c036542c>] (generic_handle_irq) from [<c0365720>] (__handle_domain_irq+0x7c/0xec) [ 3.986122] [<c0365720>] (__handle_domain_irq) from [<c0301464>] (gic_handle_irq+0x48/0x8c) [ 3.994541] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] (__irq_svc+0x6c/0xa8) [ 4.002865] Exception stack(0xdeca1c60 to 0xdeca1ca8) [ 4.010507] 1c60: 00000000 c0abce68 c109f9c0 00000000 c109f9c0 00000000 deca0000 00000000 [ 4.015546] 1c80: 00000282 deca1d48 c0210800 001f3df8 e080400c deca1cb0 c0322330 c0322340 [ 4.023701] 1ca0: 20070113 ffffffff [ 4.031868] [<c08b8e4c>] (__irq_svc) from [<c0322340>] (__do_softirq+0x9c/0x388) [ 4.035166] [<c0322340>] (__do_softirq) from [<c03228f0>] (irq_exit+0xc0/0xfc) [ 4.042805] [<c03228f0>] (irq_exit) from [<c0365724>] (__handle_domain_irq+0x80/0xec) [ 4.049835] [<c0365724>] (__handle_domain_irq) from [<c0301464>] (gic_handle_irq+0x48/0x8c) [ 4.057735] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] (__irq_svc+0x6c/0xa8) [ 4.065887] Exception stack(0xdeca1d48 to 0xdeca1d90) [ 4.073528] 1d40: deca1dc0 00000000 00000000 deca0018 ffff8bd6 deca1dc0 [ 4.078566] 1d60: 00000000 c0378ad0 60070013 00000000 00000000 001f3df8 c108fa04 deca1d98 [ 4.086723] 1d80: c08b77fc c0377930 60070013 ffffffff [ 4.094889] [<c08b8e4c>] (__irq_svc) from [<c0377930>] (init_timer_key+0x28/0x104) [ 4.099921] [<c0377930>] (init_timer_key) from [<c08b77fc>] (schedule_timeout+0x48/0x410) [ 4.107389] [<c08b77fc>] (schedule_timeout) from [<c0378ad0>] (msleep+0x2c/0x38) [ 4.115640] [<c0378ad0>] (msleep) from [<c06c2980>] (smsc911x_open+0x268/0x50c) [ 4.123100] [<c06c2980>] (smsc911x_open) from [<c07c1994>] (__dev_open+0xa8/0x10c) [ 4.130128] [<c07c1994>] (__dev_open) from [<c07c1c1c>] (__dev_change_flags+0x94/0x144) [ 4.137769] [<c07c1c1c>] (__dev_change_flags) from [<c07c1ce4>] (dev_change_flags+0x18/0x48) [ 4.145670] [<c07c1ce4>] (dev_change_flags) from [<c0823048>] (devinet_ioctl+0x6b0/0x768) [ 4.154357] [<c0823048>] (devinet_ioctl) from [<c07a4ac4>] (sock_ioctl+0x1f4/0x2c8) [ 4.162425] [<c07a4ac4>] (sock_ioctl) from [<c0432678>] (do_vfs_ioctl+0x9c/0x910) [ 4.169887] [<c0432678>] (do_vfs_ioctl) from [<c0432f20>] (SyS_ioctl+0x34/0x5c) [ 4.177529] [<c0432f20>] (SyS_ioctl) from [<c0308480>] (ret_fast_syscall+0x0/0x3c) [ 4.184635] handlers: [ 4.192273] [<c036911c>] bad_chained_irq [ 4.198255] Disabling IRQ #109 (...) [ 34.170316] smsc911x 1b800000.ethernet-ebi2 eth0: ISR failed signaling test (IRQ 208) Yours, Linus Walleij
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-10 20:10 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4G6Z-8uN-21@gated-at.bofh.it> |
| In reply to | #1459168 |
Hi Marc, Linus, On 10/08/16 10:41, Marc Zyngier wrote: > Hi Linus, > > On 10/08/16 00:03, Linus Walleij wrote: >> On Tue, Aug 9, 2016 at 3:20 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >> >>> If that works, then does the following also work (without the above) ... >>> >>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c >>> index b4c1bc7c9ca2..e111b72e3162 100644 >>> --- a/kernel/irq/chip.c >>> +++ b/kernel/irq/chip.c >>> @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle, >>> irq_settings_set_norequest(desc); >>> irq_settings_set_nothread(desc); >>> desc->action = &chained_action; >>> + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); >>> irq_startup(desc, true); >>> } >>> } >>> >>> It looks like there is a path for parent interrupts where the type >>> is not getting set. If the above works then we can discuss with Thomas >>> and Marc on the correct fix. >> >> I tried this on my problematic platform and then this happens: >> >> preparing networking... >> [ 2.628246] ------------[ cut here ]------------ >> [ 2.628303] WARNING: CPU: 0 PID: 92 at ../kernel/irq/chip.c:26 >> bad_chained_irq+0x44/0x4c >> [ 2.631939] Chained irq 109 should not call an action >> [ 2.640008] Modules linked in: >> [ 2.647909] CPU: 0 PID: 92 Comm: ip Not tainted >> 4.8.0-rc1-00011-ga21e27b4cb66 #194 >> [ 2.647996] Hardware name: Generic DT based system >> [ 2.655486] [<c030f8c8>] (unwind_backtrace) from [<c030c714>] >> (show_stack+0x10/0x14) >> [ 2.660254] [<c030c714>] (show_stack) from [<c05df420>] >> (dump_stack+0x78/0x8c) >> [ 2.668147] [<c05df420>] (dump_stack) from [<c031cef4>] (__warn+0xec/0x104) >> [ 2.675173] [<c031cef4>] (__warn) from [<c031cf44>] >> (warn_slowpath_fmt+0x38/0x48) >> [ 2.682033] [<c031cf44>] (warn_slowpath_fmt) from [<c0369160>] >> (bad_chained_irq+0x44/0x4c) >> [ 2.689687] [<c0369160>] (bad_chained_irq) from [<c0365e28>] >> (__handle_irq_event_percpu+0x5c/0x290) >> [ 2.697836] [<c0365e28>] (__handle_irq_event_percpu) from >> [<c0366078>] (handle_irq_event_percpu+0x1c/0x58) >> [ 2.706778] [<c0366078>] (handle_irq_event_percpu) from >> [<c03660ec>] (handle_irq_event+0x38/0x5c) >> [ 2.716498] [<c03660ec>] (handle_irq_event) from [<c03693f0>] >> (handle_level_irq+0xc4/0x150) >> [ 2.725438] [<c03693f0>] (handle_level_irq) from [<c036542c>] >> (generic_handle_irq+0x24/0x34) >> [ 2.733602] [<c036542c>] (generic_handle_irq) from [<c06127d4>] >> (msm_gpio_irq_handler+0xc8/0x150) >> [ 2.742280] [<c06127d4>] (msm_gpio_irq_handler) from [<c036542c>] >> (generic_handle_irq+0x24/0x34) >> [ 2.751048] [<c036542c>] (generic_handle_irq) from [<c0365720>] >> (__handle_domain_irq+0x7c/0xec) >> [ 2.759901] [<c0365720>] (__handle_domain_irq) from [<c0301464>] >> (gic_handle_irq+0x48/0x8c) >> [ 2.768323] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] >> (__irq_svc+0x6c/0xa8) >> [ 2.776644] Exception stack(0xdeca1d48 to 0xdeca1d90) >> [ 2.784284] 1d40: deca1dc0 00000000 00000000 >> deca0018 ffff8bd6 deca1dc0 >> [ 2.789324] 1d60: 00000000 c0378ad0 60070013 00000000 00000000 >> 001f3df8 c108fa04 deca1d98 >> [ 2.797481] 1d80: c08b77fc c0377930 60070013 ffffffff >> [ 2.805651] [<c08b8e4c>] (__irq_svc) from [<c0377930>] >> (init_timer_key+0x28/0x104) >> [ 2.810679] [<c0377930>] (init_timer_key) from [<c08b77fc>] >> (schedule_timeout+0x48/0x410) >> [ 2.818145] [<c08b77fc>] (schedule_timeout) from [<c0378ad0>] >> (msleep+0x2c/0x38) >> [ 2.826399] [<c0378ad0>] (msleep) from [<c06c2980>] >> (smsc911x_open+0x268/0x50c) >> [ 2.833859] [<c06c2980>] (smsc911x_open) from [<c07c1994>] >> (__dev_open+0xa8/0x10c) >> [ 2.840887] [<c07c1994>] (__dev_open) from [<c07c1c1c>] >> (__dev_change_flags+0x94/0x144) >> [ 2.848525] [<c07c1c1c>] (__dev_change_flags) from [<c07c1ce4>] >> (dev_change_flags+0x18/0x48) >> [ 2.856428] [<c07c1ce4>] (dev_change_flags) from [<c0823048>] >> (devinet_ioctl+0x6b0/0x768) >> [ 2.865120] [<c0823048>] (devinet_ioctl) from [<c07a4ac4>] >> (sock_ioctl+0x1f4/0x2c8) >> [ 2.873186] [<c07a4ac4>] (sock_ioctl) from [<c0432678>] >> (do_vfs_ioctl+0x9c/0x910) >> [ 2.880645] [<c0432678>] (do_vfs_ioctl) from [<c0432f20>] >> (SyS_ioctl+0x34/0x5c) >> [ 2.888290] [<c0432f20>] (SyS_ioctl) from [<c0308480>] >> (ret_fast_syscall+0x0/0x3c) >> [ 2.895395] ---[ end trace a53e1e63b7bdfc4a ]--- >> [ 2.903917] random: fast init done >> [ 3.036378] random: crng init done >> [ 3.883906] irq 109: nobody cared (try booting with the "irqpoll" option) >> [ 3.883940] CPU: 0 PID: 92 Comm: ip Tainted: G W >> 4.8.0-rc1-00011-ga21e27b4cb66 #194 >> [ 3.889673] Hardware name: Generic DT based system >> [ 3.898538] [<c030f8c8>] (unwind_backtrace) from [<c030c714>] >> (show_stack+0x10/0x14) >> [ 3.903137] [<c030c714>] (show_stack) from [<c05df420>] >> (dump_stack+0x78/0x8c) >> [ 3.911034] [<c05df420>] (dump_stack) from [<c0368804>] >> (__report_bad_irq+0x28/0xcc) >> [ 3.918065] [<c0368804>] (__report_bad_irq) from [<c0368c18>] >> (note_interrupt+0x298/0x2e8) >> [ 3.925971] [<c0368c18>] (note_interrupt) from [<c03660a8>] >> (handle_irq_event_percpu+0x4c/0x58) >> [ 3.934040] [<c03660a8>] (handle_irq_event_percpu) from >> [<c03660ec>] (handle_irq_event+0x38/0x5c) >> [ 3.942634] [<c03660ec>] (handle_irq_event) from [<c03693f0>] >> (handle_level_irq+0xc4/0x150) >> [ 3.951660] [<c03693f0>] (handle_level_irq) from [<c036542c>] >> (generic_handle_irq+0x24/0x34) >> [ 3.959821] [<c036542c>] (generic_handle_irq) from [<c06127d4>] >> (msm_gpio_irq_handler+0xc8/0x150) >> [ 3.968502] [<c06127d4>] (msm_gpio_irq_handler) from [<c036542c>] >> (generic_handle_irq+0x24/0x34) >> [ 3.977269] [<c036542c>] (generic_handle_irq) from [<c0365720>] >> (__handle_domain_irq+0x7c/0xec) >> [ 3.986122] [<c0365720>] (__handle_domain_irq) from [<c0301464>] >> (gic_handle_irq+0x48/0x8c) >> [ 3.994541] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] >> (__irq_svc+0x6c/0xa8) >> [ 4.002865] Exception stack(0xdeca1c60 to 0xdeca1ca8) >> [ 4.010507] 1c60: 00000000 c0abce68 c109f9c0 00000000 c109f9c0 >> 00000000 deca0000 00000000 >> [ 4.015546] 1c80: 00000282 deca1d48 c0210800 001f3df8 e080400c >> deca1cb0 c0322330 c0322340 >> [ 4.023701] 1ca0: 20070113 ffffffff >> [ 4.031868] [<c08b8e4c>] (__irq_svc) from [<c0322340>] >> (__do_softirq+0x9c/0x388) >> [ 4.035166] [<c0322340>] (__do_softirq) from [<c03228f0>] >> (irq_exit+0xc0/0xfc) >> [ 4.042805] [<c03228f0>] (irq_exit) from [<c0365724>] >> (__handle_domain_irq+0x80/0xec) >> [ 4.049835] [<c0365724>] (__handle_domain_irq) from [<c0301464>] >> (gic_handle_irq+0x48/0x8c) >> [ 4.057735] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] >> (__irq_svc+0x6c/0xa8) >> [ 4.065887] Exception stack(0xdeca1d48 to 0xdeca1d90) >> [ 4.073528] 1d40: deca1dc0 00000000 00000000 >> deca0018 ffff8bd6 deca1dc0 >> [ 4.078566] 1d60: 00000000 c0378ad0 60070013 00000000 00000000 >> 001f3df8 c108fa04 deca1d98 >> [ 4.086723] 1d80: c08b77fc c0377930 60070013 ffffffff >> [ 4.094889] [<c08b8e4c>] (__irq_svc) from [<c0377930>] >> (init_timer_key+0x28/0x104) >> [ 4.099921] [<c0377930>] (init_timer_key) from [<c08b77fc>] >> (schedule_timeout+0x48/0x410) >> [ 4.107389] [<c08b77fc>] (schedule_timeout) from [<c0378ad0>] >> (msleep+0x2c/0x38) >> [ 4.115640] [<c0378ad0>] (msleep) from [<c06c2980>] >> (smsc911x_open+0x268/0x50c) >> [ 4.123100] [<c06c2980>] (smsc911x_open) from [<c07c1994>] >> (__dev_open+0xa8/0x10c) >> [ 4.130128] [<c07c1994>] (__dev_open) from [<c07c1c1c>] >> (__dev_change_flags+0x94/0x144) >> [ 4.137769] [<c07c1c1c>] (__dev_change_flags) from [<c07c1ce4>] >> (dev_change_flags+0x18/0x48) >> [ 4.145670] [<c07c1ce4>] (dev_change_flags) from [<c0823048>] >> (devinet_ioctl+0x6b0/0x768) >> [ 4.154357] [<c0823048>] (devinet_ioctl) from [<c07a4ac4>] >> (sock_ioctl+0x1f4/0x2c8) >> [ 4.162425] [<c07a4ac4>] (sock_ioctl) from [<c0432678>] >> (do_vfs_ioctl+0x9c/0x910) >> [ 4.169887] [<c0432678>] (do_vfs_ioctl) from [<c0432f20>] >> (SyS_ioctl+0x34/0x5c) >> [ 4.177529] [<c0432f20>] (SyS_ioctl) from [<c0308480>] >> (ret_fast_syscall+0x0/0x3c) >> [ 4.184635] handlers: >> [ 4.192273] [<c036911c>] bad_chained_irq >> [ 4.198255] Disabling IRQ #109 >> (...) >> [ 34.170316] smsc911x 1b800000.ethernet-ebi2 eth0: ISR failed >> signaling test (IRQ 208) > > Is this platform related to the Dragonboard 410C? I've got one from > Sudeep, and it seems to work fine (though I've spotted a couple of > gotchas in the DT). Just to confirm is that with or without the proposed change? Linus, I have been trying to find out which qcom board has this smsc911x but I was unable to find any, so more info on the platform would be great! I have been testing this on various Tegra boards that use gpio irqchips for various external functions and have not seen any such problems so far. Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Marc Zyngier <marc.zyngier@arm.com> |
|---|---|
| Date | 2016-08-10 20:50 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4GJJ-j6-93@gated-at.bofh.it> |
| In reply to | #1459303 |
On 10/08/16 10:56, Jon Hunter wrote: > Hi Marc, Linus, > > On 10/08/16 10:41, Marc Zyngier wrote: >> Hi Linus, >> >> On 10/08/16 00:03, Linus Walleij wrote: >>> On Tue, Aug 9, 2016 at 3:20 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> >>>> If that works, then does the following also work (without the above) ... >>>> >>>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c >>>> index b4c1bc7c9ca2..e111b72e3162 100644 >>>> --- a/kernel/irq/chip.c >>>> +++ b/kernel/irq/chip.c >>>> @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle, >>>> irq_settings_set_norequest(desc); >>>> irq_settings_set_nothread(desc); >>>> desc->action = &chained_action; >>>> + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); >>>> irq_startup(desc, true); >>>> } >>>> } >>>> >>>> It looks like there is a path for parent interrupts where the type >>>> is not getting set. If the above works then we can discuss with Thomas >>>> and Marc on the correct fix. >>> >>> I tried this on my problematic platform and then this happens: >>> >>> preparing networking... >>> [ 2.628246] ------------[ cut here ]------------ >>> [ 2.628303] WARNING: CPU: 0 PID: 92 at ../kernel/irq/chip.c:26 >>> bad_chained_irq+0x44/0x4c >>> [ 2.631939] Chained irq 109 should not call an action >>> [ 2.640008] Modules linked in: >>> [ 2.647909] CPU: 0 PID: 92 Comm: ip Not tainted >>> 4.8.0-rc1-00011-ga21e27b4cb66 #194 >>> [ 2.647996] Hardware name: Generic DT based system >>> [ 2.655486] [<c030f8c8>] (unwind_backtrace) from [<c030c714>] >>> (show_stack+0x10/0x14) >>> [ 2.660254] [<c030c714>] (show_stack) from [<c05df420>] >>> (dump_stack+0x78/0x8c) >>> [ 2.668147] [<c05df420>] (dump_stack) from [<c031cef4>] (__warn+0xec/0x104) >>> [ 2.675173] [<c031cef4>] (__warn) from [<c031cf44>] >>> (warn_slowpath_fmt+0x38/0x48) >>> [ 2.682033] [<c031cf44>] (warn_slowpath_fmt) from [<c0369160>] >>> (bad_chained_irq+0x44/0x4c) >>> [ 2.689687] [<c0369160>] (bad_chained_irq) from [<c0365e28>] >>> (__handle_irq_event_percpu+0x5c/0x290) >>> [ 2.697836] [<c0365e28>] (__handle_irq_event_percpu) from >>> [<c0366078>] (handle_irq_event_percpu+0x1c/0x58) >>> [ 2.706778] [<c0366078>] (handle_irq_event_percpu) from >>> [<c03660ec>] (handle_irq_event+0x38/0x5c) >>> [ 2.716498] [<c03660ec>] (handle_irq_event) from [<c03693f0>] >>> (handle_level_irq+0xc4/0x150) >>> [ 2.725438] [<c03693f0>] (handle_level_irq) from [<c036542c>] >>> (generic_handle_irq+0x24/0x34) >>> [ 2.733602] [<c036542c>] (generic_handle_irq) from [<c06127d4>] >>> (msm_gpio_irq_handler+0xc8/0x150) >>> [ 2.742280] [<c06127d4>] (msm_gpio_irq_handler) from [<c036542c>] >>> (generic_handle_irq+0x24/0x34) >>> [ 2.751048] [<c036542c>] (generic_handle_irq) from [<c0365720>] >>> (__handle_domain_irq+0x7c/0xec) >>> [ 2.759901] [<c0365720>] (__handle_domain_irq) from [<c0301464>] >>> (gic_handle_irq+0x48/0x8c) >>> [ 2.768323] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] >>> (__irq_svc+0x6c/0xa8) >>> [ 2.776644] Exception stack(0xdeca1d48 to 0xdeca1d90) >>> [ 2.784284] 1d40: deca1dc0 00000000 00000000 >>> deca0018 ffff8bd6 deca1dc0 >>> [ 2.789324] 1d60: 00000000 c0378ad0 60070013 00000000 00000000 >>> 001f3df8 c108fa04 deca1d98 >>> [ 2.797481] 1d80: c08b77fc c0377930 60070013 ffffffff >>> [ 2.805651] [<c08b8e4c>] (__irq_svc) from [<c0377930>] >>> (init_timer_key+0x28/0x104) >>> [ 2.810679] [<c0377930>] (init_timer_key) from [<c08b77fc>] >>> (schedule_timeout+0x48/0x410) >>> [ 2.818145] [<c08b77fc>] (schedule_timeout) from [<c0378ad0>] >>> (msleep+0x2c/0x38) >>> [ 2.826399] [<c0378ad0>] (msleep) from [<c06c2980>] >>> (smsc911x_open+0x268/0x50c) >>> [ 2.833859] [<c06c2980>] (smsc911x_open) from [<c07c1994>] >>> (__dev_open+0xa8/0x10c) >>> [ 2.840887] [<c07c1994>] (__dev_open) from [<c07c1c1c>] >>> (__dev_change_flags+0x94/0x144) >>> [ 2.848525] [<c07c1c1c>] (__dev_change_flags) from [<c07c1ce4>] >>> (dev_change_flags+0x18/0x48) >>> [ 2.856428] [<c07c1ce4>] (dev_change_flags) from [<c0823048>] >>> (devinet_ioctl+0x6b0/0x768) >>> [ 2.865120] [<c0823048>] (devinet_ioctl) from [<c07a4ac4>] >>> (sock_ioctl+0x1f4/0x2c8) >>> [ 2.873186] [<c07a4ac4>] (sock_ioctl) from [<c0432678>] >>> (do_vfs_ioctl+0x9c/0x910) >>> [ 2.880645] [<c0432678>] (do_vfs_ioctl) from [<c0432f20>] >>> (SyS_ioctl+0x34/0x5c) >>> [ 2.888290] [<c0432f20>] (SyS_ioctl) from [<c0308480>] >>> (ret_fast_syscall+0x0/0x3c) >>> [ 2.895395] ---[ end trace a53e1e63b7bdfc4a ]--- >>> [ 2.903917] random: fast init done >>> [ 3.036378] random: crng init done >>> [ 3.883906] irq 109: nobody cared (try booting with the "irqpoll" option) >>> [ 3.883940] CPU: 0 PID: 92 Comm: ip Tainted: G W >>> 4.8.0-rc1-00011-ga21e27b4cb66 #194 >>> [ 3.889673] Hardware name: Generic DT based system >>> [ 3.898538] [<c030f8c8>] (unwind_backtrace) from [<c030c714>] >>> (show_stack+0x10/0x14) >>> [ 3.903137] [<c030c714>] (show_stack) from [<c05df420>] >>> (dump_stack+0x78/0x8c) >>> [ 3.911034] [<c05df420>] (dump_stack) from [<c0368804>] >>> (__report_bad_irq+0x28/0xcc) >>> [ 3.918065] [<c0368804>] (__report_bad_irq) from [<c0368c18>] >>> (note_interrupt+0x298/0x2e8) >>> [ 3.925971] [<c0368c18>] (note_interrupt) from [<c03660a8>] >>> (handle_irq_event_percpu+0x4c/0x58) >>> [ 3.934040] [<c03660a8>] (handle_irq_event_percpu) from >>> [<c03660ec>] (handle_irq_event+0x38/0x5c) >>> [ 3.942634] [<c03660ec>] (handle_irq_event) from [<c03693f0>] >>> (handle_level_irq+0xc4/0x150) >>> [ 3.951660] [<c03693f0>] (handle_level_irq) from [<c036542c>] >>> (generic_handle_irq+0x24/0x34) >>> [ 3.959821] [<c036542c>] (generic_handle_irq) from [<c06127d4>] >>> (msm_gpio_irq_handler+0xc8/0x150) >>> [ 3.968502] [<c06127d4>] (msm_gpio_irq_handler) from [<c036542c>] >>> (generic_handle_irq+0x24/0x34) >>> [ 3.977269] [<c036542c>] (generic_handle_irq) from [<c0365720>] >>> (__handle_domain_irq+0x7c/0xec) >>> [ 3.986122] [<c0365720>] (__handle_domain_irq) from [<c0301464>] >>> (gic_handle_irq+0x48/0x8c) >>> [ 3.994541] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] >>> (__irq_svc+0x6c/0xa8) >>> [ 4.002865] Exception stack(0xdeca1c60 to 0xdeca1ca8) >>> [ 4.010507] 1c60: 00000000 c0abce68 c109f9c0 00000000 c109f9c0 >>> 00000000 deca0000 00000000 >>> [ 4.015546] 1c80: 00000282 deca1d48 c0210800 001f3df8 e080400c >>> deca1cb0 c0322330 c0322340 >>> [ 4.023701] 1ca0: 20070113 ffffffff >>> [ 4.031868] [<c08b8e4c>] (__irq_svc) from [<c0322340>] >>> (__do_softirq+0x9c/0x388) >>> [ 4.035166] [<c0322340>] (__do_softirq) from [<c03228f0>] >>> (irq_exit+0xc0/0xfc) >>> [ 4.042805] [<c03228f0>] (irq_exit) from [<c0365724>] >>> (__handle_domain_irq+0x80/0xec) >>> [ 4.049835] [<c0365724>] (__handle_domain_irq) from [<c0301464>] >>> (gic_handle_irq+0x48/0x8c) >>> [ 4.057735] [<c0301464>] (gic_handle_irq) from [<c08b8e4c>] >>> (__irq_svc+0x6c/0xa8) >>> [ 4.065887] Exception stack(0xdeca1d48 to 0xdeca1d90) >>> [ 4.073528] 1d40: deca1dc0 00000000 00000000 >>> deca0018 ffff8bd6 deca1dc0 >>> [ 4.078566] 1d60: 00000000 c0378ad0 60070013 00000000 00000000 >>> 001f3df8 c108fa04 deca1d98 >>> [ 4.086723] 1d80: c08b77fc c0377930 60070013 ffffffff >>> [ 4.094889] [<c08b8e4c>] (__irq_svc) from [<c0377930>] >>> (init_timer_key+0x28/0x104) >>> [ 4.099921] [<c0377930>] (init_timer_key) from [<c08b77fc>] >>> (schedule_timeout+0x48/0x410) >>> [ 4.107389] [<c08b77fc>] (schedule_timeout) from [<c0378ad0>] >>> (msleep+0x2c/0x38) >>> [ 4.115640] [<c0378ad0>] (msleep) from [<c06c2980>] >>> (smsc911x_open+0x268/0x50c) >>> [ 4.123100] [<c06c2980>] (smsc911x_open) from [<c07c1994>] >>> (__dev_open+0xa8/0x10c) >>> [ 4.130128] [<c07c1994>] (__dev_open) from [<c07c1c1c>] >>> (__dev_change_flags+0x94/0x144) >>> [ 4.137769] [<c07c1c1c>] (__dev_change_flags) from [<c07c1ce4>] >>> (dev_change_flags+0x18/0x48) >>> [ 4.145670] [<c07c1ce4>] (dev_change_flags) from [<c0823048>] >>> (devinet_ioctl+0x6b0/0x768) >>> [ 4.154357] [<c0823048>] (devinet_ioctl) from [<c07a4ac4>] >>> (sock_ioctl+0x1f4/0x2c8) >>> [ 4.162425] [<c07a4ac4>] (sock_ioctl) from [<c0432678>] >>> (do_vfs_ioctl+0x9c/0x910) >>> [ 4.169887] [<c0432678>] (do_vfs_ioctl) from [<c0432f20>] >>> (SyS_ioctl+0x34/0x5c) >>> [ 4.177529] [<c0432f20>] (SyS_ioctl) from [<c0308480>] >>> (ret_fast_syscall+0x0/0x3c) >>> [ 4.184635] handlers: >>> [ 4.192273] [<c036911c>] bad_chained_irq >>> [ 4.198255] Disabling IRQ #109 >>> (...) >>> [ 34.170316] smsc911x 1b800000.ethernet-ebi2 eth0: ISR failed >>> signaling test (IRQ 208) >> >> Is this platform related to the Dragonboard 410C? I've got one from >> Sudeep, and it seems to work fine (though I've spotted a couple of >> gotchas in the DT). > > Just to confirm is that with or without the proposed change? The proposed change didn't have any impact on this board, but it may just be that the firmware had done the right thing... > Linus, I have been trying to find out which qcom board has this smsc911x > but I was unable to find any, so more info on the platform would be great! > > I have been testing this on various Tegra boards that use gpio irqchips > for various external functions and have not seen any such problems so far. I'm also struggling to reproduce this issue, so any pointer to an easy to source board would be appreciated (I can trade in Versatile/Realview HW...). Thanks, M. -- Jazz is not dead. It just smells funny...
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2016-08-10 21:50 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4HFM-12V-27@gated-at.bofh.it> |
| In reply to | #1459303 |
On Wed, Aug 10, 2016 at 11:56 AM, Jon Hunter <jonathanh@nvidia.com> wrote: > Hi Marc, Linus, > On 10/08/16 10:41, Marc Zyngier wrote: >> On 10/08/16 00:03, Linus Walleij wrote: >>> On Tue, Aug 9, 2016 at 3:20 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>> >>>> If that works, then does the following also work (without the above) ... >>>> >>>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c >>>> index b4c1bc7c9ca2..e111b72e3162 100644 >>>> --- a/kernel/irq/chip.c >>>> +++ b/kernel/irq/chip.c >>>> @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle, >>>> irq_settings_set_norequest(desc); >>>> irq_settings_set_nothread(desc); >>>> desc->action = &chained_action; >>>> + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); >>>> irq_startup(desc, true); >>>> } >>>> } (...) >>> I tried this on my problematic platform and then this happens: >>> >>> preparing networking... >>> [ 2.628246] ------------[ cut here ]------------ >>> [ 2.628303] WARNING: CPU: 0 PID: 92 at ../kernel/irq/chip.c:26 >>> bad_chained_irq+0x44/0x4c (...) > Just to confirm is that with or without the proposed change? This is with: + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); No other changes. Before the change it boots, but the IRQs don't work. After the change it boots and crashes like that. > Linus, I have been trying to find out which qcom board has this smsc911x > but I was unable to find any, so more info on the platform would be great! It has nothing to do with the SMSC911x per se. The problem pertains to *all* IRQs from the PMIC. This is the original APQ8060 Dragonboard from BSquare. https://dflund.se/~triad/krad/dragonboard/ Qualcomm also have a development board called "Surf" which likely have this problem. This is the MFD irqchip driver that has the problem: drivers/mfd/pm8921-core.c No IRQs from this works. Not even the power button or anything. > I have been testing this on various Tegra boards that use gpio irqchips > for various external functions and have not seen any such problems so far. John seems to be seeing it on other Qualcomm gpiochip drivers with APQ8064 on the Nexus 7. I would be surprised if any of the APQ8064 boards doesn't have the issue. Yours, Linus Walleij
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2016-08-10 23:00 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4ILw-1Hq-39@gated-at.bofh.it> |
| In reply to | #1459710 |
On 10/08/16 14:58, Linus Walleij wrote: > On Wed, Aug 10, 2016 at 11:56 AM, Jon Hunter <jonathanh@nvidia.com> wrote: >> Hi Marc, Linus, >> On 10/08/16 10:41, Marc Zyngier wrote: >>> On 10/08/16 00:03, Linus Walleij wrote: >>>> On Tue, Aug 9, 2016 at 3:20 PM, Jon Hunter <jonathanh@nvidia.com> wrote: >>>> >>>>> If that works, then does the following also work (without the above) ... >>>>> >>>>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c >>>>> index b4c1bc7c9ca2..e111b72e3162 100644 >>>>> --- a/kernel/irq/chip.c >>>>> +++ b/kernel/irq/chip.c >>>>> @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, irq_flow_handler_t handle, >>>>> irq_settings_set_norequest(desc); >>>>> irq_settings_set_nothread(desc); >>>>> desc->action = &chained_action; >>>>> + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); >>>>> irq_startup(desc, true); >>>>> } >>>>> } > (...) >>>> I tried this on my problematic platform and then this happens: >>>> >>>> preparing networking... >>>> [ 2.628246] ------------[ cut here ]------------ >>>> [ 2.628303] WARNING: CPU: 0 PID: 92 at ../kernel/irq/chip.c:26 >>>> bad_chained_irq+0x44/0x4c > (...) >> Just to confirm is that with or without the proposed change? > > This is with: > + __irq_set_trigger(desc, irqd_get_trigger_type(&desc->irq_data)); > > No other changes. > > Before the change it boots, but the IRQs don't work. > > After the change it boots and crashes like that. OK. >> Linus, I have been trying to find out which qcom board has this smsc911x >> but I was unable to find any, so more info on the platform would be great! > > It has nothing to do with the SMSC911x per se. The problem pertains > to *all* IRQs from the PMIC. > > This is the original APQ8060 Dragonboard from BSquare. > https://dflund.se/~triad/krad/dragonboard/ Where can I see the DT source for this board? There is a arch/arm/boot/dts/qcom-apq8060-dragonboard.dts but this does not appear to be the same (does not have smsc911x). Cheers Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Linus Walleij <linus.walleij@linaro.org> |
|---|---|
| Date | 2016-08-10 21:10 +0200 |
| Subject | Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons |
| Message-ID | <s4H33-I0-13@gated-at.bofh.it> |
| In reply to | #1459168 |
On Wed, Aug 10, 2016 at 11:41 AM, Marc Zyngier <marc.zyngier@arm.com> wrote: > Is this platform related to the Dragonboard 410C? I've got one from > Sudeep, and it seems to work fine (though I've spotted a couple of > gotchas in the DT). Nopes this is the ARMv7 APQ8060, the original (first!) dragonboard. https://dflund.se/~triad/krad/dragonboard/ (You know me, I always use the odd hardware nobody else use...) > Do you see this symptom on all chained interrupts? Or just this > particular one? This appears on all IRQs on the PM (MFD) ASIC. Yours, Linus Walleij
[toc] | [prev] | [next] | [standalone]
Page 1 of 2 [1] 2 Next page →
Back to top | Article view | linux.kernel
csiph-web