On Friday, September 21, 2018 4:05:57 PM CEST Hans de Goede wrote: > Hi Rafael, > > On 09/21/2018 01:11 PM, Rafael J. Wysocki wrote: > > On Thursday, September 20, 2018 3:08:28 PM CEST Jarkko Nikula wrote: > >> On 09/19/2018 10:15 PM, Hans de Goede wrote: > >>> On some Cherry Trail systems the GPU ACPI fwnode has power-resources which > >>> point to the PMIC, which is connected over a LPSS I2C controller. The GPU > >>> is a PCI device and PCI devices are powered-on at the resume_noirq resume > >>> phase. > >>> > >>> Since the GPU power-resources need the I2C controller, recent acpi_lpss.c > >>> changes now also power-up the LPSS I2C controllers on BYT and CHT devices > >>> in the resume_noirq resume phase. But during this phase the IRQ of the > >>> controller is disabled leading to these errors: > >>> > >>> i2c_designware 808622C1:06: controller timed out > >>> ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] > >>> ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR > >>> video LNXVIDEO:00: Failed to change power state to D0 > >>> > >>> This commit makes the i2c-designware controller set the IRQF_NO_SUSPEND > >>> flag when requesting the interrupt on BYT and CHT devices, so that the IRQ > >>> is left enabled during the noirq phase, fixing this. > >>> > >>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> > >>> --- > >>> drivers/i2c/busses/i2c-designware-core.h | 1 + > >>> drivers/i2c/busses/i2c-designware-master.c | 2 +- > >>> drivers/i2c/busses/i2c-designware-platdrv.c | 4 ++-- > >>> 3 files changed, 4 insertions(+), 3 deletions(-) > >>> > >> Acked-by: Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> > >> > > > > Thanks! > > > > Wolfram, any objections here? > > Although it would be good to get Wolfram's feedback here please note > that the intend is for patches 1-6 to be merged through your tree > and this patch through Wolfram's tree since both the acpi_lpss code > and the i2c-designware code have seen some changes recently. OK > As mentioned in the coverletter the order of merging these is not > important, the bug will not be fixed until both are present but > otherwise they can be merged in any order, so dividing them > over 2 trees is not a problem. Not really a problem technichally, but it may make it sort of hard to backport the fixes, as that would require things to be tracked down to the submission of the patches. Thanks, Rafael
