Hi,
On 8/16/19 7:16 PM, Linus Walleij wrote:
Hi Hans,
On Fri, Aug 16, 2019 at 11:18 AM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
So I've just tested this on a Cherry Trail machine and
the interrupt storm, fixing which is the reason the
intel_int0002_vgpio.c driver was introduced, is back:
Sorry but just so I understand this report: when you say the
interrupt storm is back, do you mean that this patch brings
it back, or do you mean the interrupt storm is there
even before this patch?
I mean that the patch brings it back, iow the patch causes
a regression.
This patch does bring semantic differences, but very
small ones.
Could it be that the parent device of the IRQ controller is
different after this? I think that the ACPI subsys relies
on the parent being the INT0002 ACPI instantiated platform
device.
Notice that the driver has attached itself as shared irq-handler
to the ACPI IRQ
What is it sharing it with?
With the ACPI subsys, this IRQ is called the GPE which is an
interrupt normally reserved for events to be handled by the
ACPI subsys.
Do I need any patches on top of 5.3-rc4 to test this patch?
No, none that I know of.
It is weird that this driver registers a chained
interrupt handler but int0002_irq() doesn't call
chained_irq_[enter|exit].
I don't understand the ACPI code but I'm confused about
a "virtual" GPIO controller with very real interrupt lines
attached to it. If it is actually virtual then just trying to
abuse gpiolib to cascade interrupts like the shared
interrupts were some, you know, cascaded GPIO IRQ line,
I guess all the consumers should just grab the interrupt
independently and shared instead, the idea being that
each of them will drop their pull of the shared level IRQ
line until it is eventually deasserted.
I'm just confused....
The ACPI subsys has the ability to attach an event handler
written in ACPI byte code (AML code) to GPIO events (GPIO
triggered IRQs), quoting the same piece of AML as before:
Device (GPED)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "INT0002" /* Virtual GPIO Controller */) // _HID: Hardw
Name (_CID, "INT0002" /* Virtual GPIO Controller */) // _CID: Compa
Name (_DDN, "Virtual GPIO controller") // _DDN: DOS Device Name
...
Method (_AEI, 0, NotSerialized) // _AEI: ACPI Event Interrupts
{
Name (RBUF, ResourceTemplate ()
{
GpioInt (Level, ActiveHigh, ExclusiveAndWake, PullDown, 0x00
"\\_SB.GPED", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0002
}
})
Return (RBUF) /* \_SB_.GPED._AEI.RBUF */
}
Method (_L02, 0, NotSerialized) // _Lxx: Level-Triggered GPE
{
...
}
}
So what we are seeing here is an AEI (ACPI Event Interrupt) entry pointing
to pin 2 of the INT0002 GPIO chip, note this is not a real GPIO chip, but
a way to attach an ACPI event handler to GPE interrupts, while only
running the event handler when a specific status bit is set.
So what the ACPI subsys does is it looksup the GPIO with index 2
on the INT0003 gpiochip (which is unchanged) and the calls gpio_to_irq
on the found GPIO, it seems that the gpio_to_irq is no longer working,
causing the:
123: 0 0 0 0 INT0002 Virtual GPIO 2 ACPI:Event
Line in cat/ /proc/interrupts to disappear. That or gpio_to_irq works
but then for some reason the subsequent request irq fails.
Regards,
Hans
