pinctrl: baytrail: Clear direct_irq_en flag on broken configs
Some boards set the direct_irq_en flag in the conf0 register without setting the correct trigger bits. The direct_irq_en flag just means that the GPIO will send IRQs directly to the APIC instead of going through the shared interrupt for the GPIO controller, in order for the pin to be able to actually generate IRQs the trigger flags must configure the IRQ as a level-high or level-low active IRQ. Note testing shows that using edge trigger add the conf0 register level does NOT work, instead edge triggering should be set at the IO-APIC level. I believe that the direct_irq_en flag connects the output of the GPIO's IRQ trigger block, which normally sets the status flag in the IRQ status reg at 0x800 to one of the IO-APIC pins according to the direct IRQ mux. This means that the TRIG_LVL bit *must* be set, so that the GPIO's input value is directly passed (1:1 or inverted) to the IO-APIC pin, if TRIG_LVL is not set, selecting edge mode operation then on the first edge the selected IO-APIC pin goes high, but since no write-to-clear write will be done to the IRQ status reg at 0x800, the detected edge condition will never get cleared. This APIC pin stuck high condition can be observed with the pin configured as level-high active, in the form of an interrupt storm. Clearing the TRIG_MASK bits of conf0 stops the storm, reconfiguring them as edge again results in a storm again as soon as the edge is triggered once. Detect invalid trigger flags, log a FW_BUG warning when encountering this and clear the direct_irq_en flag so that a driver can actually use the pin as IRQ through gpiod_to_irq(). Specifically this allows the edt-ft5x06 touchscreen driver to use INT33FC:02 pin 3 as touchscreen IRQ on the Nextbook Ares 8 tablet, accompanied by the following new log message byt_gpio INT33FC:02: [Firmware Bug]: pin 3: direct_irq_en set without trigger, clearing The new byt_direct_irq_sanity_check() function also checks that the pin is actually appointed to one of the 16 direct-IRQs which the GPIO controller supports and on success prints debug messages like these: byt_gpio INT33FC:02: Pin 0: uses direct IRQ 0 (IO-APIC 67) byt_gpio INT33FC:02: Pin 15: uses direct IRQ 2 (IO-APIC 69) This is useful to figure out the GPIO pin belonging to ACPI resources like this one: "Interrupt () { 0x00000043 }" or the other way around. The strict checking of valid trigger flags this introduces does result in FW_BUG messages on quite a few devices. E.g. on the Yoga Tablet 2 1051L: byt_gpio INT33FC:00: [Firmware Bug]: pin 92: direct_irq_en set but no IRQ assigned, clearing byt_gpio INT33FC:00: [Firmware Bug]: pin 93: direct_irq_en set but no IRQ assigned, clearing These 2 also have mux set to 7 and fall + rise + level trigger bits set, presumably something has written 0xffffffff to their conf0 registers byt_gpio INT33FC:02: Pin 3: uses direct IRQ 1 (IO-APIC 68) byt_gpio INT33FC:02: [Firmware Bug]: pin 3: direct_irq_en set without trigger (conf0: 2803cc00h), clearing Most tablets seem to have this, looking at DSDTs this seems intended for use with an I2C HID sensor-hub and is still set on devices without one. To make sure this does not cause any regressions this has been tested, including checking disabled direct-IRQs are not used in the DSDT, on the following devices: Asus ME176C Asus TF103C Chuwi Vi10 (with its Windows BIOS) HP x2 10-n000nd Lenovo Yoga Tablet 2 1050L (Android version, without EC, with buggy DSDT) Lenovo Yoga Tablet 2 1051L (Windows version, with EC) Suggested-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Showing
Please register or sign in to comment