On Sun, Feb 18, 2018 at 6:32 PM, Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sun, Feb 18, 2018 at 04:23:41PM +0200, Andy Shevchenko wrote: >> On Sun, Feb 18, 2018 at 11:41 AM, Dominik Brodowski >> <linux@xxxxxxxxxxxxxxxxxxxx> wrote: >> > On Sat, Feb 17, 2018 at 10:57:01PM +0200, Andy Shevchenko wrote: >> >> On Sat, 2018-02-17 at 17:58 +0100, Dominik Brodowski wrote: >> >> >> > Do you still need the DEBUG_GPIO output? >> >> >> >> It would be nice to have, though if it makes difficulties to you, then >> >> don't bother. >> > >> > Note that I have to enable CONFIG_GPIOLIB before I can enable DEBUG_GPIO; >> > CONFIG_PINCTRL was off as well. Maybe some "SELECT" is missing for >> > CONFIG_I2C_DESIGNWARE_BAYTRAIL ? >> >> Ah, so, your configuration misses pin control driver. You need to >> enable it in order to get GPIOs working. > > Well, I did not need it in the past to have working sound and working > suspend to RAM. And it already works if > > CONFIG_PINCTRL=y > CONFIG_DEBUG_PINCTRL=y > > CONFIG_GPIOLIB=y > CONFIG_GPIO_ACPI=y > CONFIG_DEBUG_GPIO=y > > are set (but no PINCTRL or GPIO drivers!). > > So I'd suggest to > > (a) keep your fixup patch (as things work as previously then), You may answer to mail with the patch by giving a Tested-by tag. > (b) to have CONFIG_I2C_DESIGNWARE_BAYTRAIL select the appropriate options from > above [and CONFIG_XPOWER_PMIC_OPREGION ?] (or depend on it?), or I don't think there is such dependency. Jarkko, what do you think? >> Yes, and with enabled pin control driver. > > Well, I've reverted your fixup patch locally and enabled all drivers that I > could -- including CONFIG_XPOWER_PMIC_OPREGION, CONFIG_MFD_AXP20X, and > CONFIG_MFD_AXP20X_I2C. But I'm not sure at all that a driver actually became > active... -ENOSYS is returned when !GPIOLIB. That what made behaviour different in the first place. -- With Best Regards, Andy Shevchenko
