From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [Intel-gfx] [PATCH] ACPI / bus: Introduce a list of ids for "always present" devices Date: Mon, 10 Apr 2017 15:56:05 +0200 Message-ID: References: <20170225182328.26644-1-hdegoede@redhat.com> <3161510.WQnmWnCBb0@aspire.rjw.lan> <591c099a-4b2b-0b69-575a-cd4c95c02682@redhat.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <591c099a-4b2b-0b69-575a-cd4c95c02682@redhat.com> Sender: linux-acpi-owner@vger.kernel.org To: Hans de Goede Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , intel-gfx , ACPI Devel Maling List , Andy Shevchenko , Mika Westerberg , Len Brown List-Id: intel-gfx@lists.freedesktop.org On Sun, 09 Apr 2017 22:32:46 +0200, Hans de Goede wrote: > > Hi, > > On 27-02-17 23:53, Takashi Iwai wrote: > > On Mon, 27 Feb 2017 22:27:58 +0100, > > Rafael J. Wysocki wrote: > >> > >> On Mon, Feb 27, 2017 at 3:40 PM, Takashi Iwai wrote: > > > > >>> Oh, this is interesting, please let me join to the party. > >>> > >>> We've hit a similar problem, but for other one: namely, it's INT0002 > >>> that is found on a few CHT devices. It's never bound properly by a > >>> similar reason, where _STA is always zero on Linux: > >>> > >>> Method (_STA, 0, NotSerialized) // _STA: Status > >>> { > >>> If (SOCS <= 0x04) > >>> { > >>> Return (0x0F) > >>> } > >>> Else > >>> { > >>> Return (Zero) > >>> } > >>> } > >>> > >>> The device is supposed to be a "virtual GPIO" stuff, and the driver > >>> hasn't been upstreamed from Intel. Due to the lack of this driver > >>> (and it's binding), the machine gets spurious IRQ#9 after the PM > >>> resume, and it locks up at the second time of PM. > >> > >> Well, the solution here seems to be to acquire the missing driver > >> instead of adding quirks to the ACPI core. > > > > The driver is available (not upstreamed, though), but it's not bound > > due to _STA above. That's why I'm interested in this thread. > > Takashi thanks for pointing me to the INT0002 device / driver to > fix the spurious IRQ#9 after the PM resume issue. I was seeing this > on the GPD-win too (when suspending with power-button + wakeup with > spacebar). I've added a patch to add the INT0002 device to the > always present device list + cleaned up the INT0002 driver. I plan > to submit this upstream soon. > > If you want to test this on your device you need these patches: > > https://github.com/jwrdegoede/linux-sunxi/commit/a1a6e92f2665376ed72f575553238a93e88bb037 > https://github.com/jwrdegoede/linux-sunxi/commit/4946f68f8eaa300f42289bf767722d78cf7fa9e2 > https://github.com/jwrdegoede/linux-sunxi/commit/32640c816dd60d17f003ae8306863da01c215afb > https://github.com/jwrdegoede/linux-sunxi/commit/abb6a9d69690bb2a1a00b184b06cdae43d6ad001 Thanks Hans, these look promising! One remaining concern is that INT0002 seems serving for other purpose, too, in drivers/platform/x86/intel_menlow.c for the thermal management. I wonder whether we can enable INT0002 unconditionally. Takashi