Messages in this thread |  | | Date | Tue, 1 Nov 2016 16:44:00 +0200 | From | Mika Westerberg <> | Subject | Re: BUG? genirq: irq 14 uses trigger mode 8; requested 0 |
| |
On Tue, Nov 01, 2016 at 02:24:38PM +0000, Jon Hunter wrote: > Hi Mika, > > On 01/11/16 13:02, Mika Westerberg wrote: > > Hi, > > > > I started seeing following messages on Intel Broxton when the > > pinctrl/GPIO driver [1] loads: > > > > [ 0.645786] genirq: irq 14 uses trigger mode 8; requested 0 > > > > The driver shares interrupt with other GPIO "communities" or banks so it > > uses request_irq() instead of irq_set_chained_handler_and_data(). The > > driver does not specify IRQ flags as those come from ACPI resources. > > > > This started happen after commit 4b357daed698 ("genirq: Look-up trigger > > type if not specified by caller"). > > > > I think this is what happens: > > > > 1. ACPI platform sets up the interrupt according what is in the _CRS > > of the GPIO device. This ends up setting trigger type for irq_data of > > the irq. > > > > 2. First GPIO device is found and the driver calls request_irq() which > > calls __setup_irq() where shared == 0. > > > > 3. Since new->flags is read back from irq_data we call __irq_set_trigger() > > passing the flags. > > > > 4. The parent IRQ chip, IO-APIC, does not have ->irq_set_type callback > > so __irq_set_trigger() never calls irq_settings_set_trigger_mask() for > > the desciptor. > > > > 5. The second GPIO device is found and this time shared == 1 so we > > end up comparing nmsk with omsk where nmsk was read from irq_data > > and omsk is read using irq_settings_get_trigger_mask(). > > > > 6. Because we never called irq_settings_set_trigger_mask() for the > > descriptor, omsk is 0 and we print out a warning: > > > > [ 0.645786] genirq: irq 14 uses trigger mode 8; requested 0 > > > > If I revert commit 4b357daed698 the warning goes away. > > > > Do you have any ideas how to get rid of the warning properly? > > May be I am misunderstanding something here, but if the parent does not have > a ->irq_set_type callback, then it would seem that the type for the > interrupt should be not specified/set in the ACPI _CRS for the GPIO device, > right?
Not sure.
Why the parent driver (IO-APIC) does not have ->irq_set_type callback is beyond me. I guess it might have something to do with the IRQ hierarchy domains it is part of.
When the ACPI core parses _CRS for the GPIO device it calls acpi_register_gsi() with the triggering flags from _CRS and that ends up calling acpi_register_gsi_ioapic() that programs the hardware accordingly. So we definitely need to have the type in _CRS.
|  |