(In reply to Lukas Kahnert from comment #76)
> This error happens because your patch only fixes the mis-detection of the
> IRQ. There ist still https://bugzilla.kernel.org/show_bug.cgi?id=199529
> which needs also bei fixed to get the touchscreen work.

Right, I figured that out now, actually I believe that with your hack to
drivers/acpi/resource.c the changes you made to drivers/base/platform.c
should no longer be necessary.

We've been looking at the wrong part of the DSDT the culprit is not:

Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
                    {
                        0x00000007,
                    }

This uses an extended interrupt syntax, so acpi_dev_get_irqresource() gets 
called with legacy == false and the troublesome acpi_get_override_irq()
never happens.

I believe the real culprit is:

    Scope (_SB.PCI0)
    {
        Device (SMBD)
        {
            Name (_HID, "SMB0001")  // _HID: Hardware ID
            Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
            {
                IO (Decode16,
                    0x0B20,             // Range Minimum
                    0x0B20,             // Range Maximum
                    0x20,               // Alignment
                    0x20,               // Length
                    )
                IRQ (Level, ActiveLow, Shared, )
                    {7}
            })
        }
    }

Which does use a legacy style IRQ resource, this causes
acpi_dev_get_irqresource() to be called with legacy == true and then the
troublesome acpi_get_override_irq() happens.

I believe that this troublesome node gets parsed before the AMDI0030
node and then by the time the AMDI0030 node happens, inside
acpi_dev_get_irqresource() we hit the else of:

        irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
        if (irq >= 0) {
                res->start = irq;
                res->end = irq;
        } else {
                acpi_dev_irqresource_disabled(res, gsi);
        }

Which sets the DISABLED flag, which is causing the issue in
drivers/base/platform.c . The reason we hit the else path is because of
the earlier enumeration of the same interrupt with conflicting trigger /
polarity settings so the second one fails with -EBUSY (it would work if
the flags would match).

My new attempt deals with this by adding the "SMB0001" HID to the
blacklist for creating platform devices, so that
acpi_dev_get_resources() does not get called on it at all, avoiding the
call of acpi_dev_get_irqresource() with legacy == false.

The not creating of a platform_device for the "SMB0001" HID is not an
issue since the driver for it is an acpi bus driver not a platform bus
driver.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1752437

Title:
  [HP ENVY x360 - 15-bq102ng] Touchscreen does not work

To manage notifications about this bug go to:
https://bugs.launchpad.net/kernel/+bug/1752437/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to