Bug 193891
Created attachment 253931 [details] mfd driver test patch port from https://github.com/01org/ProductionKernelQuilts mfd-intel_soc_pmic-add-TI-variant-of-dollar-cove.patch Dollar-Cove-TI-handle-IRQ-as-triggered-on-high-level.patch Created attachment 253941 [details] ACPI PMIC opregion test patch based on https://github.com/01org/ProductionKernelQuilts 0001-ACPI-Adding-support-for-TI-pmic-opregion.patch Created attachment 253951 [details]
kernel config
With the test patches the mfd driver shows up in /proc/interrupts but the irq never fires, apparently it needs support for PMIC GPIOs used in DSDT. The opregion driver doesn't support thermal correctly (ADC driver not ported yet), it generates ACPI errors at boot and when running "acpi -t". [ 1129.169700] i2c_designware 808622C1:06: controller timed out [ 1129.177190] ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20160930/evregion-300) [ 1129.184801] No Local Variables are initialized for method [_TMP] [ 1129.187003] No Arguments are initialized for method [_TMP] [ 1129.188990] ACPI Error: Method parse/execution failed [\_SB.STR0._TMP] (Node ffff931db751c0f0), AE_ERROR (20160930/psparse-543) [ 1130.193730] i2c_designware 808622C1:06: controller timed out [ 1130.202138] ACPI Exception: AE_ERROR, Returned by Handler for [UserDefinedRegion] (20160930/evregion-300) [ 1130.210684] No Local Variables are initialized for method [_TMP] [ 1130.213277] No Arguments are initialized for method [_TMP] [ 1130.215554] ACPI Error: Method parse/execution failed [\_TZ.TZ00._TMP] (Node ffff931db74e0960), AE_ERROR (20160930/psparse-543) Bug 155241 might be relevant for it. I have an Asus T100HAN with Atom x5-Z8500. echo freeze > /sys/power/state works partly. Lid close works, but open doesn't wake the computer, but a key presses do. There are however loads of errors, but it wakes up. I got ASUS E200H a couple of days ago, too, and am trying to make things working, and hit the LKML thread and this bug. The i2c-designware error is irrelevant, and it's fixed by a patchset by Hans: https://bugzilla.kernel.org/show_bug.cgi?id=155241 Most of them are in the way to 4.11, I suppose. I searched the web, and hit the Android patches: https://github.com/01org/ProductionKernelQuilts there you can find lots of dollar cove stuff... Also, I noticed that a spurious IRQ#9 after the wakeup by USB keyboard. This is likely the issue with virtual GPIO. The patch 0002-gpio-virtual-Add-Virtual-GPIO-controller-driver.patch in the quilt repo above should correspond to it. However, the vgpio doesn't work as is on this machine, as it seems. Likely because of the lack of _STA in ACPI INT0002, then the kernel doesn't bind with it. We had a similar issue on a Dell machine, too. There are a few more problems with this machine, but this is the biggest one. After some hacking, now the audio works more or less, and the media keys work, too. OK, I managed to make it working with a small patchset. You can find the dollar cove TI PMIC MFD driver and the corresponding power button input driver in topic/dollar-cove-ti branch of my sound.git tree. git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git The temperature warning is still seen once, so something must be missing. But the power button handling is done by this even without opregion support. The hid-asus hack and the IRQ#9 workaround are found in topic/cherrytrail-hack branch. The topic/asus-e100h-v4.10 branch contains all these fixes as well as the audio support (merges from other branches). @tiwai, As a set of quick fixes it looks okay, though I would like to be Cc'ed when you start upstreaming them. I think Mika Westerberg and Erik Veijola are interested in that as well. For now, I'm pretty sure that power button driver belongs to PDx86, i.e. drivers/platform/x86 (while it is a separate driver, and it would go like this, it would be nice to have *some* parts in align with existing intel_mid_powerbtn.c). I like code re-use for PMIC between Crystal Cove and Dollar Cove, but instead of checking config parameter I would add ->resource_add() / ->resource_remove() hooks and define them for Crystal Cove accordingly. P.S. I sent earlier couple of clean up patches regarding MFD PMIC drivers, you might be interested to look at: http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1337297.html http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1337709.html Andy, thanks for checking. The patches aren't intended to be upstreamed yet at all, and I just wanted to fix it quickly before I go to vacation with this laptop in the upcoming week. (And no, I won't debug during vacation on the shiny Sri Lankan beach ;) I guess MFD Dollar Cove stuff could be submitted earlier; it's fairly straightforward. But the power button handling is still in question, as it could be done in a complete different way. If I understand the patchset of Intel Android correctly, the power button input driver was even disabled later in the series since gpio-keys driver is used instead. If so, we might have a better chance by extending gpio-keys stuff for matching with this device. Hans de Goede has worked on extending gpio-keys already for some other Cherrytrail devices. Unfortunately it didn't work as is with ASUS E200H, but some adjustment might bring it up. Let's see... In anyway, it'd be really appreciated if you guys can join to the development, who have a much better clue. Thanks! Takashi, have a nice vacation and thanks for the patches. We will see what we can do in a dark Finnish office :-) I tried tiwai's topic branch: asus-e100h-v4.10 on my Asus T100HAN (also cherrytrail based). Some observations: The IRQ #9 issue at resume is gone. When suspending, I get only one ACPI error: -- [ 1565.033112] ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [UserDefinedRegion] (20160930/evregion-300) [ 1565.033203] ACPI Error: Method parse/execution failed [\_SB.P33X._STA] (Node ffff88017b0c4c58), AE_BAD_PARAMETER (20160930/psparse-543) -- In pmc_atom/sleep_state only S0 is used. The power button and the volume up/down buttons are not working. -- HID: asus: Add missing Fn key maps on ASUS E200H -- Doesn't work on T100HAN. (There is another patch floating around that alters hid-input.c that works, except for one key.) (In reply to Jonas Aaberg from comment #11) > I tried tiwai's topic branch: asus-e100h-v4.10 on my Asus T100HAN (also > cherrytrail based). > Some observations: > The IRQ #9 issue at resume is gone. > When suspending, I get only one ACPI error: > -- > [ 1565.033112] ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for > [UserDefinedRegion] (20160930/evregion-300) > [ 1565.033203] ACPI Error: Method parse/execution failed [\_SB.P33X._STA] > (Node ffff88017b0c4c58), AE_BAD_PARAMETER (20160930/psparse-543) This is a known issue, likely triggered by the commit yesterday to add Dollar Cove TI PMIC opregion support. You can ignore it, so far. > -- > In pmc_atom/sleep_state only S0 is used. > The power button and the volume up/down buttons are not working. My patches have nothing to do with the volume keys, as they worked fine as is with vanilla kernel on E200H. And the volume keys should be managed by HID driver, I guess. The power button is a different thing, and it's exactly what this bugzilla entry handles. Doesn't the power button give any event even if you press it before going to suspend? At best, you can check the irq hanlder in dollar_cove_ti_powerbtn.c whether it gets any event. > -- > HID: asus: Add missing Fn key maps on ASUS E200H > -- > Doesn't work on T100HAN. (There is another patch floating around that alters > hid-input.c that works, except for one key.) Then yours must have a different mapping. Check the debugfs of HID driver (/sys/kernel/debug/hid/* entry). By watching "events" file, you can see which key corresponds to which HID entry. Then add hid-asus.c appropriately. In the case of ASUS E200H, it was about ff31.006c, etc. But for tracking further about the keyboard issue, I'd suggest you to open another bugzilla entry. My bad, there was a typo at rewriting the patch that prevented binding dollar-cove PMIC. Now it's fixed in topic/dollar-cove-ti and topic/asus-e100h-4.10 branches. Please give it a try again. Tried again, but with the same results. No power button presses detected. I based my build on your commit: 58e26ee12c9cdb2ebc2f134893a40850330a49d4 and I use the following (new) related kernel configs: -- CONFIG_KEYBOARD_DC_TI_POWER=y CONFIG_INTEL_SOC_PMIC_DC_TI=y CONFIG_INTEL_SOC_PMIC_BXTWC=m CONFIG_CHT_VGPIO=y -- (In reply to Takashi Iwai from comment #12) > (In reply to Jonas Aaberg from comment #11) > > I tried tiwai's topic branch: asus-e100h-v4.10 on my Asus T100HAN (also > > cherrytrail based). > > Some observations: > > The IRQ #9 issue at resume is gone. > > When suspending, I get only one ACPI error: > > -- > > [ 1565.033112] ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for > > [UserDefinedRegion] (20160930/evregion-300) > > [ 1565.033203] ACPI Error: Method parse/execution failed [\_SB.P33X._STA] > > (Node ffff88017b0c4c58), AE_BAD_PARAMETER (20160930/psparse-543) > > This is a known issue, likely triggered by the commit yesterday to add > Dollar Cove TI PMIC opregion support. You can ignore it, so far. I have to correct myself. This error has been around for several kernel versions. What is new is that it shows up at boot and the touchscreen has stopped working and that the touchscreen driver aborts suspend. (T100HAN is a "2-in-1" computer, the lower part with keyboard and touchpad can be removed and the computer becomes a tablet.) I did file a bug on this error message some time ago: https://bugzilla.kernel.org/show_bug.cgi?id=191751 > > > -- > > In pmc_atom/sleep_state only S0 is used. > > The power button and the volume up/down buttons are not working. > > My patches have nothing to do with the volume keys, as they worked fine as > is with vanilla kernel on E200H. And the volume keys should be managed by > HID driver, I guess. I understand. They volume button together with the power button are the only keys that are on the "tablet" part of this computer. So my wild guess would be that they have similarities. > > The power button is a different thing, and it's exactly what this bugzilla > entry handles. Doesn't the power button give any event even if you press it > before going to suspend? At best, you can check the irq hanlder in > dollar_cove_ti_powerbtn.c whether it gets any event. /proc/interrupts shows no new interrupts when pressing the power button. Also I have now two "Power button" inputs. I'll add some printk to dollar_cove_ti_powerbtn.c to see what happens there. > > > -- > > HID: asus: Add missing Fn key maps on ASUS E200H > > -- > > Doesn't work on T100HAN. (There is another patch floating around that > alters > > hid-input.c that works, except for one key.) > > Then yours must have a different mapping. Check the debugfs of HID driver > (/sys/kernel/debug/hid/* entry). By watching "events" file, you can see > which key corresponds to which HID entry. Thanks, I didn't know that! > Then add hid-asus.c appropriately. This computer's keyboard and touchpad are connected via USB, not I2C as the others in hid-asus. I will try with adding a "HID_USB_DEVICE(.." line. > In the case of ASUS E200H, it was about ff31.006c, etc. Exactly the same keys for the T100HA. Then I suppose T100HAN has a different handling of the power button key. You can try the branch topic/soc-button-array-cherrytrail, instead. It contains the recent works for supporting soc-button-array input driver that is compliant with Windows stuff. Yes, the patches on the topic/soc-button-array-cherrytrail works just fine! A single press on the power button shuts down the computer and the volume up/down are mapped correctly. Thanks! Now the big issue left on the T100HAN is that suspend bails out due to ACPI error.. (In reply to Jonas Aaberg from comment #17) > Now the big issue left on the T100HAN is that suspend bails out due to ACPI > error.. How about the branch topic/cht-whiskey-cove? (Note that this will conflict with topic/dollar-cove-ti branch.) ... or the latest topic/i2c-dw-cherrytrail branch. It contains two more fixes. Takashi, Thanks! I tried both branches, but neither did improve the situation. There is still ACPI error _SB.P33X._STA and/or _SB.P33X._ON upon boot and suspend. Hi Takashi, I tried your topic/asus-e100h-v4.10 on my E200HA but my results are mixed: - Dollar cove TI and dollar_cove_ti_powerbtn irqs seem to work according to /proc/interrupts - but no wakeup from "echo freeze >/sys/power/state" - however, wakeup from "echo mem >/sys/power/state" works sometimes, but is followed by i2c timeouts (/sys/power/mem_sleep is [s2idle]) - sometimes power button generates thermal errors, and sometimes the machine hangs hard after it - /proc/acpi/wakup is empty - .../dollar_cove_ti_power_button/power/ doesn't have wakeup node - it boots more reliably than before with Hans' i2c patches, but it still hangs reliable when booting with "debug" on the kernel command line; note I use dm-crypt root and have most drivers built-in (see my .config above), especially i2c and keyboard BTW, my E200HA has BIOS version 300 but I've seen 302 and 303 on Asus' support site (sadly without release notes). Hi, First of all, thanks Takashi for the work you have been doing. I agree with you that we should use gpio_keys instead of the custom power button driver. For this we need to get both the PMIC MFD and GPIO driver for Dollar Cover working. The ProductionKernelQuilts patches actually include some sort of GPIO driver for DollarCove so we are working on to get that probed and functional. Hi, I hope this issue is not forgotten... Meanwhile I figured out my kernel config lacked CONFIG_I2C_DESIGNWARE_BAYTRAIL=y, based on its Kconfig text which suggests it is for BayTrail with AXP288 only... so the PUNIT semaphore was not used. Now, with this fixed and using Takashi's topic/asus-e100h-4.10 branch from Bug 115531 (cx2072x codec, which includes changes to fix Bug 155241, punit semaphore), my E200HA boots reliably. Unless I add "debug" to the kernel command line which makes it hang reliably after systemd-udevd starts, but it seems to be seperate issue. Now, when it hangs the i2c keyboard still works but I couldn't get a meaningful backtrace via sysrq. After some trying I figured out it seems to be systemd-udevd's fault and it works to boot with "loglevel=8" instead of "debug". Sigh. (Debian testing, systemd-udevd 232-19) FWIW I updated my BIOS to 303, without any noticable improvements. Not forgotten. We got the TI PMIC datasheet finally last week. It looks like there is no GPIO block at all on the PMIC so using the power-button driver is probably the only option. Erik is working on that. Thanks for the update. However, now I'm confused about the meaning of the GpioIo list in the DSDT inside the "TI PMIC Controller" Device definition... It chould be just a placeholder. The IP does not have a single GPIO according the datasheet. Johannes, you are also for example missing CONFIG_DW_DMAC=y. I started with your kernel config, altering it for Asus T100HAN (also cherry trail based), but I didn't really manage to get things working properly. It was a few weeks ago, so I've forgotten the details. I use a kernel config, based upon Arch Linux default kernel config, and I've gotten most things working with about 40 extra patches on 4.11-rc3. Most of those patches comes from Takashi's git, but some comes from other sources. The patches I use, plus kernel config can be found here: http://lithops.se/patches-4.11-rc3.tar.bz2 The kernel config results in like 3000 modules, but it the result works very well on the T100HAN. Suspend/resume works. Power button and/or open lid resumes correctly. Maybe it can be some help in getting the E200HA to work better? Yeah, it is quite likely some options are missing in my kernel config, but I'd like to have a fairly minimal config, not a distro "everything as module", so I can compile on the device in reasonable time (my config takes ~20min). I did some checking: Also missing is CONFIG_SERIAL_8250_LPSS CONFIG_SPI_PXA2XX but I'm not sure these are useful on E200HA even though the SoC has the IP. And now it wakes up using power button after "echo mem >/sys/power/state". I think I didn't test this after fixing the CONFIG_I2C_DESIGNWARE_BAYTRAIL, it seems more a more likely canditate to have fixed this. Pressing the power button while on still emits a screenful of MCE errors. Now if "suspend" would actually save power (S0ix)... Created attachment 255633 [details]
kernel config 4.10.0 + Takashi's patches
Mika, how is the status of this issue? Now I finally started working again on Cherrytrail problems, and this is one of the things that haven' been upstreamed yet. FWIW, S3 works stably on my ASUS E200H works and the wakeup works via the power button with my hackish patches. They are found in topic/dollar-cove-ti branch of my sound git tree. If you think my patches should be submitted, I'm willing to do that. Or if any other test patches are floating around, I'll happily test them, too. Hi, I'm working on this issue, but haven't had time in more than a month to look at this so progress is slow. We got the datasheet like Mika said earlier, now it's just a matter of finding the time to clean up the code and getting it reviewed. Hi, while I appreciate that Intel's Linux guys seem to care about it, it doesn't help us if your management doesn't give you the time to work on it. Maybe you could change your development model from "wait for us to do it" to "here are a few untested bits that you can't figure out without the datasheet" and let community devs help out? Meanwhile I had a closer look at the Windows pmic.sys wrt the Snd9039 PMIC PGIO handling. Although Mika says the Snd9039 doesn't have any GPIO according to datasheet, the pmic.sys registers a GpioClx driver with read + write functions, which are implemented using SPB (I2C) messages to the PMIC. A possible theory is that this implementation is done for similarity with other PMICs handled by the same pmic.sys (cht, wcove etc.), and it actually writes "special purpose IO" register bits. Unfortunately my reverse engineering skills are limited and so far I couldn't figure out the actual register addresses and bits. If you look at the GPIO definitions in the DSDT, the names suggest they are used to control voltage regulators (e.g. G28X), and they are changed by other parts of the DSDT (PowerResource P28T). Now I don't understand yet how the PowerResource is used, but I suppose the meaning of all this is that the PMIC GPIO driver and ACPI GPIO OpRegion driver are needed to disable some voltage regulators needed for S0ix support. Could you please confirm (or refute)? And should/does Linux implement it the same way or completely different? @Takashi: While getting the power button to work for wakeup from freeze, it is just step 1. Contrary to what you say, the platform doesn't support ACPI S3: [ 0.472449] ACPI: (supports S0 S4 S5) To actually save power in suspend it needs to implement S0ix. For reference, the TrekStor SurfTab twin 11.6 (based on Atom x5-Z8300) is advertised with a standby time of 240 hours. (In reply to Johannes Stezenbach from comment #32) > Meanwhile I had a closer look at the Windows pmic.sys wrt the Snd9039 > PMIC PGIO handling. Although Mika says the Snd9039 doesn't have any GPIO > according to datasheet, the pmic.sys registers a GpioClx driver with > read + write functions, which are implemented using SPB (I2C) messages > to the PMIC. A possible theory is that this implementation is done > for similarity with other PMICs handled by the same pmic.sys (cht, wcove > etc.), > and it actually writes "special purpose IO" register bits. Unfortunately > my reverse engineering skills are limited and so far I couldn't figure > out the actual register addresses and bits. I have few theories about this. But let me ask first, do you mean this driver is used with Windows on very same platform and does communicate through i2c with something behind? > If you look at the GPIO definitions in the DSDT, the names suggest > they are used to control voltage regulators (e.g. G28X), and they are > changed by other parts of the DSDT (PowerResource P28T). The names looks very suspicious to me (some similarities to XPower PMIC instead) The pmic.sys is from SOCPackage_CHT_Intel_Win10_64_VER104.zip which I downloaded from Asus download site for E200HA. I took me much time to analyze it (and learn about Windows drivers), so I'm confident I'm not confusing XPower and TI. At the lowest level: $ strings pmic.sys | grep WriteGpio PmicGpioWriteGpioPins CrCWriteGpioPins CrCPlusWriteGpioPins Snd9039WriteGpioPins Axp288WriteGpioPins WCChtWriteGpioPins The pmic.sys checks the PMIC type and sets up an "ops" structure to handle it, but it seems to handle each in a similar way. For GPIO it populates the GPIO_CLIENT_REGISTRATION_PACKET with the functions according to PMIC type and calls GPIO_CLX_RegisterClient. The Snd9039WriteGpioPins and Axp288WriteGpioPins look very much alike, they check the GPIO number is valid and do one I2C read modify write. (Gpio is just one part of the pmic.sys, it also does thermal and OpRegion and I don't know what.) FWIW, if we had working S0ix for platforms with Axp288 it would also be a step forward. Maybe we'd then better understand what is missing for Snd9039. I think I saw mention in ProductionKernelQuilts about S0ix for DCove. (In reply to Johannes Stezenbach from comment #32) > Hi, > > while I appreciate that Intel's Linux guys seem to care about it, > it doesn't help us if your management doesn't give you the time to work on > it. > Maybe you could change your development model from "wait for us to do it" > to "here are a few untested bits that you can't figure out without > the datasheet" and let community devs help out? Yeah, sorry about that. We were supposed to have time to work on this but things got changed. While we can't share the datasheet, I think it is OK for us to fill in any blanks needed to get the power button at least working as the driver is already upstream and I guess all the legal checks have been done. > Meanwhile I had a closer look at the Windows pmic.sys wrt the Snd9039 > PMIC PGIO handling. Although Mika says the Snd9039 doesn't have any GPIO > according to datasheet, the pmic.sys registers a GpioClx driver with > read + write functions, which are implemented using SPB (I2C) messages > to the PMIC. A possible theory is that this implementation is done > for similarity with other PMICs handled by the same pmic.sys (cht, wcove > etc.), > and it actually writes "special purpose IO" register bits. Unfortunately > my reverse engineering skills are limited and so far I couldn't figure > out the actual register addresses and bits. According to the datasheet I have here it only has power button, ADC and fuel gauge in addition to the LDO+buck regulators. > If you look at the GPIO definitions in the DSDT, the names suggest > they are used to control voltage regulators (e.g. G28X), and they are > changed by other parts of the DSDT (PowerResource P28T). Now I don't > understand yet how the PowerResource is used, but I suppose the meaning > of all this is that the PMIC GPIO driver and ACPI GPIO OpRegion driver > are needed to disable some voltage regulators needed for S0ix support. > Could you please confirm (or refute)? Looking at the DSDT, it seems the Operation Region (GPOP) is similar in all possible PMICs (PMIC, PMI1, PMI2). Perhaps it just got copied to all of those to make users of those simpler or so. I don't think this is needed for S0ix though. Hi Mika, the problem is when you say "we're working on it" others stand back and wait. It would be good if you'd encourage Takashi and others to post their patches for review so we can make progress. (Maybe this is happening already, I had been busy recently and had to unsubcribe from various mailing lists and I'm not up to date.) Wrt power button, the description of this bug is now old, I had been testing Takashi's 4.11 branch and the power button worked. It still produces thermal warnings, but at least it wakes up fro s2idle. Maybe the reason it failed previously was hangup due to the PUNIT semaphore thing. I have no clue about S0ix since I haven't found any documents which would describe how it works. All I know now is: /sys/kernel/debug/pmc_atom/sleep_state:S0IR Residency: 0us /sys/kernel/debug/pmc_atom/sleep_state:S0I1 Residency: 0us /sys/kernel/debug/pmc_atom/sleep_state:S0I2 Residency: 0us /sys/kernel/debug/pmc_atom/sleep_state:S0I3 Residency: 0us /sys/kernel/debug/pmc_atom/sleep_state:S0 Residency: 160934496us If you can share some infomation about S0ix, i.e. steps to do to enter it? Wrt to DSDT and PMIC, other than the GPIO stuff there is also the DPTF (Dynamic Platform and Thermal Framework), what's the meaning and how to handle it? Is it related to S0ix? (In reply to Johannes Stezenbach from comment #36) > Hi Mika, > > the problem is when you say "we're working on it" others stand back and wait. Yeah, sorry about that. > It would be good if you'd encourage Takashi and others to post their > patches for review so we can make progress. (Maybe this is > happening already, I had been busy recently and had to unsubcribe > from various mailing lists and I'm not up to date.) Erik was going to work on this but since he is busy I guess we can just go with Takashi's patches to get the support to the mainline. > Wrt power button, the description of this bug is now old, I had > been testing Takashi's 4.11 branch and the power button worked. > It still produces thermal warnings, but at least it wakes up fro s2idle. > Maybe the reason it failed previously was hangup due to the > PUNIT semaphore thing. > > I have no clue about S0ix since I haven't found any documents > which would describe how it works. All I know now is: > > /sys/kernel/debug/pmc_atom/sleep_state:S0IR Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0I1 Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0I2 Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0I3 Residency: 0us > /sys/kernel/debug/pmc_atom/sleep_state:S0 Residency: 160934496us > > If you can share some infomation about S0ix, i.e. steps > to do to enter it? You enter it by running # echo freeze > /sys/power/state (Basically it goes and calls MWAIT which then puts the SoC to S0ix if all conditions are met). > Wrt to DSDT and PMIC, other than the GPIO stuff there is also > the DPTF (Dynamic Platform and Thermal Framework), what's > the meaning and how to handle it? Is it related to S0ix? I guess that is related to thermal and power capping or so but I really don't know the details, sorry. On Mon, May 08, 2017 at 01:16:20PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=193891 > > --- Comment #37 from Mika Westerberg (mika.westerberg@linux.intel.com) --- > (In reply to Johannes Stezenbach from comment #36) > > If you can share some infomation about S0ix, i.e. steps > > to do to enter it? > > You enter it by running > > # echo freeze > /sys/power/state > > (Basically it goes and calls MWAIT which then puts the SoC to S0ix if all > conditions are met). So what are the conditions to be met? Seems my mental model of how S0ix works is wrong? My idea was "save power by turning off regulator using PMIC 'GPIO'", i.e. S0ix will be entered when MWAIT sees certain voltages are off. Come one, give me some hint in which direction to look to make it work. Thanks, Johannes (In reply to Johannes Stezenbach from comment #38) > On Mon, May 08, 2017 at 01:16:20PM +0000, > bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=193891 > > > > --- Comment #37 from Mika Westerberg (mika.westerberg@linux.intel.com) --- > > (In reply to Johannes Stezenbach from comment #36) > > > If you can share some infomation about S0ix, i.e. steps > > > to do to enter it? > > > > You enter it by running > > > > # echo freeze > /sys/power/state > > > > (Basically it goes and calls MWAIT which then puts the SoC to S0ix if all > > conditions are met). > > So what are the conditions to be met? I don't know the conditions, and I don't have such document here that explains what is needed. Typically it is when all the SoC devices are suspended but it might require something else as well. It is not like I'm hiding this information from you - I just don't know. I can try to ask around if I can find someone who knows. > --- Comment #39 from Mika Westerberg (mika.westerberg@linux.intel.com) ---
> I don't know the conditions, and I don't have such document here that
> explains
> what is needed. Typically it is when all the SoC devices are suspended but it
> might require something else as well.
>
> It is not like I'm hiding this information from you - I just don't know. I
> can
> try to ask around if I can find someone who knows.
This is unexpected, I would've thought this is documented and
Intel developers have access to Intel documentation...
Anyway, I trawled through the ProductionKernelQuilts and found this:
PM-Add-interface-to-bypass-S0ix-blockers.patch
But I can't parse its comments:
"This patch includes the debugfs addition which will help to function
disable a particular south cluster IP .This interface help debug the
S0ix flows, to figure out if an IP is actually blocking S0ix.
Considering the fact on CHT that, all IPs in D0ix in not a pre-
condition for S0ix, we need to have such debug interface. This interface
eases the regression checks on PM features."
Does it mean to say all IPs must be in D0ix to enter S0ix?
And D0ix is the same as D3?
I found the MWAIT is done in intel_idle, but the atom-z8000-datasheet-vol-1.pdf
only says about package C6: "...and the processor has been granted
permission by the platform".
/sys/kernel/debug/pmc_atom/dev_state and pss_state might be showing relevant
information, but we would actually need to dump it during
freeze just before intel_idle_freeze(), right?
It would be great if you could find out more.
TIA,
Johannes
I got an answer that it is likely that S0ix was never implemented in Linux for Cherrytrail. It also depends on the BIOS so you can try run tool called "socwatch" in Windows: https://software.intel.com/sites/default/files/managed/5c/66/socwatch_windows_users_guide.pdf If Windows can go into S0ix then you may try to disable IPU (camera) from the BIOS if possible and also check that graphics goes to D3. And yes, all devices should be in D3 (D0ix is quite similar). Wrt D0ix I found references in arch/x86/platform/atom/punit_atom_debug.c
# cat /sys/kernel/debug/punit_atom/dev_power_state
PUNIT NORTH COMPLEX DEVICES :
GFX RENDER : D0i3
GFX MEDIA : D0i3
DISPLAY : D0
VED : D0i3
ISP : D0i3
MIO : D0
What is MIO?
(In reply to Johannes Stezenbach from comment #42) > Wrt D0ix I found references in arch/x86/platform/atom/punit_atom_debug.c > > # cat /sys/kernel/debug/punit_atom/dev_power_state > > > PUNIT NORTH COMPLEX DEVICES : > GFX RENDER : D0i3 > GFX MEDIA : D0i3 > DISPLAY : D0 > VED : D0i3 > ISP : D0i3 > MIO : D0 > > What is MIO? P-Unit serves North Complex, in one datasheet I see these power islands: Memory Controller Memory I/O D0 – Self-refresh Gfx Video Encode Video Decode Display/MIPI (In reply to Mika Westerberg from comment #41) > I got an answer that it is likely that S0ix was never implemented in Linux > for > Cherrytrail. I searched a bit more and found two tablets running Android 5.1 on Atom x5-z8500, Lenovo Yoga Tab 3 Pro X90F and XiaoMi Mi Pad 2. Lenovo only released crap sources, but XiaoMi has some interesting commits wrt S0ix: https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/latte-l-oss Will take some time to study it. I just tested the topic/dollar-cove-ti kernel branch (on an HP x2 210 detachable), and that indeed makes the power button work as expected. Though it doesn't seem to change the volume buttons any. However, it also makes the tablet unable to wake up (compared to de Goede's linux-sunxi tree, where it works fine: I can wake it up using the keyboard). So the result is that instead of a power button that does nothing, it's now a power button that causes the device to sleep forever :) I'll try the other topic branches and see how they compare. You need to take other branches as well. The crash at the resume is likely due to the missing INT0002 vGPIO handling, and my dollar-cove-ti branch doesn't contains it. Similarly, the volume button is handled likely by different driver. It's gpio-button-array or some specific HID driver. At any rate, you should try 4.12-rc and INT0002 workaround, as well as dollar-cove-ti fix. Ah, you're right, the volume buttons work when I enable SOC_BUTTON_ARRAY. Thanks! Hm, I thought the Dollar Cove driver would also expose the battery information, since it seems to be the driver responsible for that. However, I don't have anything at all in /proc/acpi aside from button and wakeup (and I have ACPI_BATTERY). What gives? Am I missing some other driver? Comment on attachment 253931 [details] mfd driver test patch obsoleted by https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=topic/dollar-cove-ti-4.12 Comment on attachment 253941 [details] ACPI PMIC opregion test patch >From 3e8323674c0ec71066a0fdb72c2af99808ac11e3 Mon Sep 17 00:00:00 2001 >From: Johannes Stezenbach <js@sig21.net> >Date: Wed, 1 Feb 2017 20:15:43 +0100 >Subject: [PATCH 2/2] ACPI / PMIC: support PMIC operation region for TI Dollar > Cove > >TI version of the XPower AXP288 for the Cherrytrail platform. >It defines two custom operating regions for power and thermal. > >Signed-off-by: Johannes Stezenbach <js@sig21.net> >--- > drivers/acpi/Kconfig | 6 + > drivers/acpi/Makefile | 1 + > drivers/acpi/pmic/intel_pmic_dc_ti.c | 222 > +++++++++++++++++++++++++++++++++++ > 3 files changed, 229 insertions(+) > create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c > >diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig >index 83e5f7e1a20d..1b56b18eab2e 100644 >--- a/drivers/acpi/Kconfig >+++ b/drivers/acpi/Kconfig >@@ -510,6 +510,12 @@ config XPOWER_PMIC_OPREGION > help > This config adds ACPI operation region support for XPower AXP288 > PMIC. > >+config DC_TI_PMIC_OPREGION >+ bool "ACPI operation region support for TI Dollar Cove PMIC" >+ depends on INTEL_SOC_PMIC >+ help >+ This config adds ACPI operation region support for TI DollarCove >PMIC. >+ > config BXT_WC_PMIC_OPREGION > bool "ACPI operation region support for BXT WhiskeyCove PMIC" > depends on INTEL_SOC_PMIC >diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile >index 9ed087853dee..81a4e529bada 100644 >--- a/drivers/acpi/Makefile >+++ b/drivers/acpi/Makefile >@@ -101,6 +101,7 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o > obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o > obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o > obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o >+obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o > obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o > > obj-$(CONFIG_ACPI_CONFIGFS) += acpi_configfs.o >diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c >b/drivers/acpi/pmic/intel_pmic_dc_ti.c >new file mode 100644 >index 000000000000..fcd72d87f4ab >--- /dev/null >+++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c >@@ -0,0 +1,222 @@ >+/* >+ * intel_pmic_dc_ti.c - Intel TI Dollar Cove PMIC operation region driver >+ * >+ * Based on patch by Ameermon V A <ameermonx.va@intel.com> and >+ * intel_pmic_crc.c - Intel CrystalCove PMIC operation region driver >+ * >+ * Copyright (C) 2014 Intel Corporation. All rights reserved. >+ * >+ * This program is free software; you can redistribute it and/or >+ * modify it under the terms of the GNU General Public License version >+ * 2 as published by the Free Software Foundation. >+ * >+ * This program is distributed in the hope that it will be useful, >+ * but WITHOUT ANY WARRANTY; without even the implied warranty of >+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >+ * GNU General Public License for more details. >+ */ >+ >+#include <linux/init.h> >+#include <linux/acpi.h> >+#include <linux/mfd/intel_soc_pmic.h> >+#include <linux/regmap.h> >+#include <linux/platform_device.h> >+#include "intel_pmic.h" >+ >+#define TI_DC_PMICTEMP_LOW 0x57 >+#define TI_DC_BATTEMP_LOW 0x59 >+#define TI_DC_GPADC_LOW 0x5b >+ >+ >+static struct pmic_table power_table[] = { >+ { >+ .address = 0x00, >+ .reg = 0x41, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x04, >+ .reg = 0x42, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x08, >+ .reg = 0x43, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x0c, >+ .reg = 0x45, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x10, >+ .reg = 0x46, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x14, >+ .reg = 0x47, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x18, >+ .reg = 0x48, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x1c, >+ .reg = 0x49, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x20, >+ .reg = 0x4A, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x24, >+ .reg = 0x4B, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x28, >+ .reg = 0x4C, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x2c, >+ .reg = 0x4D, >+ .bit = 0x00, >+ }, >+ { >+ .address = 0x30, >+ .reg = 0x4E, >+ .bit = 0x00, >+ }, >+}; >+ >+static struct pmic_table thermal_table[] = { >+ { >+ .address = 0x00, >+ .reg = TI_DC_GPADC_LOW >+ }, >+ { >+ .address = 0x0c, >+ .reg = TI_DC_GPADC_LOW >+ }, >+ { >+ .address = 0x18, >+ .reg = TI_DC_GPADC_LOW >+ }, /* TMP2 -> SYSTEMP */ >+ { >+ .address = 0x24, >+ .reg = TI_DC_BATTEMP_LOW >+ }, /* TMP3 -> BATTEMP */ >+ { >+ .address = 0x30, >+ .reg = TI_DC_GPADC_LOW >+ }, >+ { >+ .address = 0x3c, >+ .reg = TI_DC_PMICTEMP_LOW >+ }, /* TMP5 -> PMICTEMP */ >+}; >+ >+static int intel_dc_ti_pmic_get_power(struct regmap *regmap, int reg, >+ int bit, u64 *value) >+{ >+ int data; >+ >+ if (regmap_read(regmap, reg, &data)) >+ return -EIO; >+ >+ *value = (data & BIT(bit)) ? 1 : 0; >+ return 0; >+} >+ >+static int intel_dc_ti_pmic_update_power(struct regmap *regmap, int reg, >+ int bit, bool on) >+{ >+ int data; >+ >+ if (regmap_read(regmap, reg, &data)) >+ return -EIO; >+ >+ if (on) >+ data |= BIT(bit); >+ else >+ data &= ~BIT(bit); >+ >+ if (regmap_write(regmap, reg, data)) >+ return -EIO; >+ return 0; >+} >+ >+static int intel_dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg) >+{ >+ int temp_l, temp_h; >+ >+ /* >+ * Raw temperature value is 10bits: 8bits in reg >+ * and 2bits in reg-1: bit0,1 >+ */ >+ if (regmap_read(regmap, reg, &temp_l) || >+ regmap_read(regmap, reg - 1, &temp_h)) >+ return -EIO; >+ >+ return temp_l | (temp_h & 0x3) << 8; >+} >+ >+static struct intel_pmic_opregion_data intel_dc_ti_pmic_opregion_data = { >+ .get_power = intel_dc_ti_pmic_get_power, >+ .update_power = intel_dc_ti_pmic_update_power, >+ .get_raw_temp = intel_dc_ti_pmic_get_raw_temp, >+ .power_table = power_table, >+ .power_table_count= ARRAY_SIZE(power_table), >+ .thermal_table = thermal_table, >+ .thermal_table_count = ARRAY_SIZE(thermal_table), >+}; >+ >+static acpi_status intel_dc_ti_pmic_gpio_handler(u32 function, >+ acpi_physical_address address, u32 bit_width, u64 *value, >+ void *handler_context, void *region_context) >+{ >+ return AE_OK; >+} >+ >+static int intel_dc_ti_pmic_opregion_probe(struct platform_device *pdev) >+{ >+ struct device *parent = pdev->dev.parent; >+ struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent); >+ acpi_status status; >+ int result; >+ >+ status = acpi_install_address_space_handler(ACPI_HANDLE(parent), >+ ACPI_ADR_SPACE_GPIO, intel_dc_ti_pmic_gpio_handler, >+ NULL, NULL); >+ if (ACPI_FAILURE(status)) >+ return -ENODEV; >+ >+ result = intel_pmic_install_opregion_handler(&pdev->dev, >+ ACPI_HANDLE(pdev->dev.parent), pmic->regmap, >+ &intel_dc_ti_pmic_opregion_data); >+ if (result) >+ acpi_remove_address_space_handler(ACPI_HANDLE(parent), >+ ACPI_ADR_SPACE_GPIO, >+ >intel_dc_ti_pmic_gpio_handler); >+ return result; >+} >+ >+static struct platform_driver intel_dc_ti_pmic_opregion_driver = { >+ .probe = intel_dc_ti_pmic_opregion_probe, >+ .driver = { >+ .name = "dollar_cove_ti_pmic", >+ }, >+}; >+ >+static int __init intel_dc_ti_pmic_opregion_driver_init(void) >+{ >+ return platform_driver_register(&intel_dc_ti_pmic_opregion_driver); >+} >+device_initcall(intel_dc_ti_pmic_opregion_driver_init); >-- >2.11.0 > Created attachment 257835 [details] config-4.12.3+tiwai-asus-e100h kernel config for 4.12.3 with Takashi's patches merged from https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=topic/asus-e100h-4.12 Created attachment 257837 [details]
S0ix blocker debug patch
I finally had a little time to look into the S0ix issue, I used a 4.12.3 kernel with Takashi's patches and only the S0ix blocker patch added. The debug output is a little messy since the notifier is called once for each CPU core going to sleep, it shows this: [ 48.723560] PM: suspend-to-idle [ 48.723633] punit debug: cpu 1: MIO is in D0 prior to freeze [ 48.723657] pmc_atom: pmc debug: cpu 1: LPSS1_F0_DMA is in D0 prior to freeze [ 48.723660] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze [ 48.723662] pmc_atom: pmc debug: cpu 1: SATA is in D0 prior to freeze [ 48.723664] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze [ 48.723666] pmc_atom: pmc debug: cpu 1: LPSS2_F0_DMA is in D0 prior to freeze [ 48.723668] pmc_atom: pmc debug: cpu 1: LPSS2_F7_I2C7 is in D0 prior to freeze [ 48.723671] punit debug: cpu 0: MIO is in D0 prior to freeze [ 48.723672] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze [ 48.723679] punit debug: cpu 3: MIO is in D0 prior to freeze [ 48.723699] pmc_atom: pmc debug: cpu 0: LPSS1_F0_DMA is in D0 prior to freeze [ 48.723702] pmc_atom: pmc debug: cpu 0: GBE is in D0 prior to freeze [ 48.723704] pmc_atom: pmc debug: cpu 0: SATA is in D0 prior to freeze [ 48.723705] pmc_atom: pmc debug: cpu 0: SEC is in D0 prior to freeze [ 48.723707] pmc_atom: pmc debug: cpu 0: LPSS2_F0_DMA is in D0 prior to freeze [ 48.723709] pmc_atom: pmc debug: cpu 0: LPSS2_F7_I2C7 is in D0 prior to freeze [ 48.723711] pmc_atom: pmc debug: cpu 0: SMB is in D0 prior to freeze [ 48.723716] pmc_atom: pmc debug: cpu 3: LPSS1_F0_DMA is in D0 prior to freeze [ 48.723721] pmc_atom: pmc debug: cpu 3: GBE is in D0 prior to freeze [ 48.723726] punit debug: cpu 2: MIO is in D0 prior to freeze [ 48.723729] pmc_atom: pmc debug: cpu 3: SATA is in D0 prior to freeze [ 48.723732] pmc_atom: pmc debug: cpu 3: SEC is in D0 prior to freeze [ 48.723736] pmc_atom: pmc debug: cpu 3: LPSS2_F0_DMA is in D0 prior to freeze [ 48.723739] pmc_atom: pmc debug: cpu 3: LPSS2_F7_I2C7 is in D0 prior to freeze [ 48.723742] pmc_atom: pmc debug: cpu 3: SMB is in D0 prior to freeze [ 48.723751] pmc_atom: pmc debug: cpu 2: LPSS1_F0_DMA is in D0 prior to freeze [ 48.723755] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze [ 48.723758] pmc_atom: pmc debug: cpu 2: SATA is in D0 prior to freeze [ 48.723761] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze [ 48.723765] pmc_atom: pmc debug: cpu 2: LPSS2_F0_DMA is in D0 prior to freeze [ 48.723768] pmc_atom: pmc debug: cpu 2: LPSS2_F7_I2C7 is in D0 prior to freeze [ 48.723771] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze [ 51.295884] Suspended for 2.558 seconds [ 51.296358] PM: resume from suspend-to-idle The Xiaomi_Kernel_OpenSource also has a patch "PM : Add interface to bypass S0ix blockers", but I didn't port it and instead used busybox devmem to poke the PMC registers: get PMC base address: $ setpci -s 00:1f.0 44.l fed03002 print and change disabled IPs: $ busybox devmem 0xfed03034 32 0x00E0C204 $ busybox devmem 0xfed03034 32 0x01e2c205 This disables LPSS1_F0_DMA, LPSS2_F0_DMA and SATA as can be verified via /sys/kernel/debug/pmc_atom/dev_state. (I did a few experiments to figure out these IPs can be disabled without crashing immediately.) After this, S0ix can be entered: $ echo freeze >/sys/power/state $ cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 32us S0I1 Residency: 4864us S0I2 Residency: 19072us S0I3 Residency: 2979136us S0 Residency: 4668440640us I guess LPSS1_F0_DMA and LPSS2_F0_DMA are not safe to disable this way, they should be handled by drivers/dma/dw/ but I don't see how the driver needs to be change to handle this. About SATA, this is not used and no such IP shows up in lspci, I guess BIOS should have disabled it. Probably needs a quirk handler for E200HA? I let it sleep for a day, on first try it woke up spuriously after three hours, on second try it stayed suspended, battery usage was about 1% per hour (5000mAh battery). (PS: Sorry about comment 50, wth did bugzilla add a deleted obsolete patch as comment???) As a follow-up to my comment #48, as discussed in bug #195689, the battery doesn't appear due to dependency issues in the Dollar Cove opregion driver, and there's a patch to solve them there. (In reply to Johannes Stezenbach from comment #53) > I finally had a little time to look into the S0ix issue, > I used a 4.12.3 kernel with Takashi's patches and only the > S0ix blocker patch added. The debug output is a little messy > since the notifier is called once for each CPU core going to sleep, > it shows this: > > [ 48.723560] PM: suspend-to-idle > [ 48.723633] punit debug: cpu 1: MIO is in D0 prior to freeze > [ 48.723657] pmc_atom: pmc debug: cpu 1: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723660] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze > [ 48.723662] pmc_atom: pmc debug: cpu 1: SATA is in D0 prior to freeze > [ 48.723664] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze > [ 48.723666] pmc_atom: pmc debug: cpu 1: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723668] pmc_atom: pmc debug: cpu 1: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723671] punit debug: cpu 0: MIO is in D0 prior to freeze > [ 48.723672] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze > [ 48.723679] punit debug: cpu 3: MIO is in D0 prior to freeze > [ 48.723699] pmc_atom: pmc debug: cpu 0: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723702] pmc_atom: pmc debug: cpu 0: GBE is in D0 prior to freeze > [ 48.723704] pmc_atom: pmc debug: cpu 0: SATA is in D0 prior to freeze > [ 48.723705] pmc_atom: pmc debug: cpu 0: SEC is in D0 prior to freeze > [ 48.723707] pmc_atom: pmc debug: cpu 0: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723709] pmc_atom: pmc debug: cpu 0: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723711] pmc_atom: pmc debug: cpu 0: SMB is in D0 prior to freeze > [ 48.723716] pmc_atom: pmc debug: cpu 3: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723721] pmc_atom: pmc debug: cpu 3: GBE is in D0 prior to freeze > [ 48.723726] punit debug: cpu 2: MIO is in D0 prior to freeze > [ 48.723729] pmc_atom: pmc debug: cpu 3: SATA is in D0 prior to freeze > [ 48.723732] pmc_atom: pmc debug: cpu 3: SEC is in D0 prior to freeze > [ 48.723736] pmc_atom: pmc debug: cpu 3: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723739] pmc_atom: pmc debug: cpu 3: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723742] pmc_atom: pmc debug: cpu 3: SMB is in D0 prior to freeze > [ 48.723751] pmc_atom: pmc debug: cpu 2: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723755] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze > [ 48.723758] pmc_atom: pmc debug: cpu 2: SATA is in D0 prior to freeze > [ 48.723761] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze > [ 48.723765] pmc_atom: pmc debug: cpu 2: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723768] pmc_atom: pmc debug: cpu 2: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723771] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze > [ 51.295884] Suspended for 2.558 seconds > [ 51.296358] PM: resume from suspend-to-idle DMA is on because I2C7 is on. > > The Xiaomi_Kernel_OpenSource also has a patch > "PM : Add interface to bypass S0ix blockers", but I didn't port > it and instead used busybox devmem to poke the PMC registers: > > get PMC base address: > $ setpci -s 00:1f.0 44.l > fed03002 > > print and change disabled IPs: > $ busybox devmem 0xfed03034 32 > 0x00E0C204 > $ busybox devmem 0xfed03034 32 0x01e2c205 > > This disables LPSS1_F0_DMA, LPSS2_F0_DMA and SATA as can > be verified via /sys/kernel/debug/pmc_atom/dev_state. > (I did a few experiments to figure out these IPs can be disabled > without crashing immediately.) > > After this, S0ix can be entered: > $ echo freeze >/sys/power/state > $ cat /sys/kernel/debug/pmc_atom/sleep_state > S0IR Residency: 32us > S0I1 Residency: 4864us > S0I2 Residency: 19072us > S0I3 Residency: 2979136us > S0 Residency: 4668440640us > > I guess LPSS1_F0_DMA and LPSS2_F0_DMA are not safe to disable this way, > they should be handled by drivers/dma/dw/ but I don't see how the > driver needs to be change to handle this. Best way to get more information is to read comments in drivers/acpi/acpi_lpss.c regarding to DMA power gating issue. TL;DR LPSS is organized as one power island, moreover DMA (as you can consider in PCI case) is a function 0 and turning it off means to turn part of LPSS island off (though, since it's only one island one need to shut down both DMAs), however, it's not correct. According to Hans de Goede (and you can see in your logs) LPSS is on because of I2C7 because of PMIC is connected to this bus! As long as you don't want kernel to crash over PMIC communication missed I2C7 should be on, meaning LPSS is on, meanining no suspend for this device until you sure it's safe. Hi Andy,
> DMA is on because I2C7 is on.
I2C could be using DMA, but it's not. In DSDT it has FixedDMA
resource, but the i2c-designware* driver doesn't seem to support DMA.
Otherwise it would crash when disabling the DMA IP.
(Also the other IPs connected to dw dma, UART and SPI, are not used.
Nothing uses the dw dma, all byte counts in /sys/class/dma/ are 0.)
drivers/dma/dw/ has LATE_SYSTEM_SLEEP_PM_OPS but it doesn't
seem to work. Any idea about it? The dw DMA isn't documented
in the public atom-z8000-datasheet, could you check if there is
anything special to be done on Atom?
(In reply to Johannes Stezenbach from comment #56) > Hi Andy, > > > DMA is on because I2C7 is on. > > I2C could be using DMA, but it's not. It's irrelevant here, citing myself "LPSS is organized as *one* power island..." > Otherwise it would crash when disabling the DMA IP. What you do through PMC registers you tell it "Okay, none is using DMA, so, it might be powered off". It also requires to write into PMCSR register to actually power off (see in acpi_lpss.c). > (Also the other IPs connected to dw dma, UART and SPI, are not used. > Nothing uses the dw dma, all byte counts in /sys/class/dma/ are 0.) DMAEngine doesn't support statistics properly (yet). So, it's not a sign of anything. > > drivers/dma/dw/ has LATE_SYSTEM_SLEEP_PM_OPS but it doesn't > seem to work. Any idea about it? That is similar to point made by Hans when he proposed to remove that code entirely for DMA. > The dw DMA isn't documented > in the public atom-z8000-datasheet, could you check if there is > anything special to be done on Atom? Special there is how power rail, clocks and resets are done in hardware. It has nothing to do with DW IP itself. As I pointed earlier, the comments in acpi_lpss.c might shed a bit of light on the PM around LPSS power island. (In reply to Andy Shevchenko from comment #55) > Best way to get more information is to read comments in > drivers/acpi/acpi_lpss.c regarding to DMA power gating issue. > > TL;DR LPSS is organized as one power island, moreover DMA (as you can > consider > in PCI case) is a function 0 and turning it off means to turn part of LPSS > island off (though, since it's only one island one need to shut down both > DMAs), however, it's not correct. > > According to Hans de Goede (and you can see in your logs) LPSS is on because > of > I2C7 because of PMIC is connected to this bus! As long as you don't want > kernel > to crash over PMIC communication missed I2C7 should be on, meaning LPSS is > on, > meanining no suspend for this device until you sure it's safe. Thanks for your comments! I read acpi_lpss.c and i2c-designware* and your comment #57 and thought about it. There is one thing I didn't clearly say: LPSS2_F7_I2C7 on doesn't block S0ix as long as the DMAs (and SATA) are disabled. That seems to clash with what you say about the LPSS power island. In commit 894acb2f823b "i2c: designware: Add Intel Baytrail PMIC I2C bus support" it says: "On these platforms access to the PMIC must be shared with platform hardware. The hardware unit assumes full control of the I2C bus and the host must request access through a special semaphore. Hardware control of the bus also makes it necessary to disable runtime pm to avoid interfering with hardware transactions." I gather it means we can't ever disable I2C7 or the hardware unit's access will hang. The conclusion is that acpi_lpss.c needs to be changed to allow the DMA controllers to shut down even while I2C7 is active. Did I get it right? I tried a little modification in acpi_lpss.c
lpss_iosf_enter_d3_state():
- u32 func_dis, d3_sts_0, pmc_status, pmc_mask = 0xfe000ffe;
+ u32 func_dis, d3_sts_0, pmc_status, pmc_mask = 0x7e000ffe;
I.e. exclude i2c7.
Seemed simple enough but does not work because
lpss_iosf_enter_d3_state() is called from
acpi_lpss_runtime_suspend(), and this is called
many times during runtime, but it's *not* called
when entering freeze state by "echo mem >/sys/power/state".
Thus DMA won't be put to sleep.
Confirmed using a debug print here:
_status = (~(d3_sts_0 | func_dis)) & pmc_mask;
- if (pmc_status)
+ if (pmc_status) {
+ pr_err("acpi-lpss: active devices: %08x\n", pmc_status);
goto exit;
+ }
Any idea how to solve it? Is it useful to try a newer
kernel than 4.12.3?
Another issue I found is that any keyboard, trackpad button
(but not touch) and lid event wakes it up, thus I have to
use "sleep 3; echo mem >/sys/power/state" and then
quickly close the lid, otherwise it wakes up on lid close.
Is there a way to configure wakeup sources?
Created attachment 257945 [details]
E200HA S0ix fix: disable SATA
Created attachment 257947 [details]
E200HA S0ix fix: don't let I2C7 block DMA suspend
Created attachment 257949 [details]
acpi-lpss test debug hack to fix S0ix entry
With the three patches from comments 60+ applied my E200HA can enter S0ix as confirmed in /sys/kernel/debug/pmc_atom/sleep_state. The debug output is: [ 541.753861] PM: Syncing filesystems ... done. [ 541.784212] PM: Preparing system for sleep (freeze) [ 541.788791] Freezing user space processes ... (elapsed 0.001 seconds) done. [ 541.793797] OOM killer disabled. [ 541.796981] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 541.800942] PM: Suspending system (freeze) [ 541.802890] Suspending console(s) (use no_console_suspend to debug) [ 542.519961] WARN_ON(pipe != PIPE_A && pipe != PIPE_B) [ 542.520042] ------------[ cut here ]------------ [ 542.520070] WARNING: CPU: 0 PID: 1781 at drivers/gpu/drm/i915/intel_panel.c:771 vlv_disable_backlight+0x90/0xa0 ... (snip i915 splat) [ 542.520816] ---[ end trace f3f9a1e4e0632c94 ]--- [ 543.338975] PM: suspend of devices complete after 1316.433 msecs [ 543.373961] PM: late suspend of devices complete after 34.963 msecs [ 543.377216] acpi_lpss_suspend_noirq [ 543.377232] acpi-lpss: suspend DMA [ 543.377279] acpi_lpss_suspend_noirq [ 543.377292] acpi-lpss: suspend DMA [ 543.377335] acpi_lpss_suspend_noirq [ 543.377347] acpi-lpss: suspend DMA [ 543.377395] acpi_lpss_suspend_noirq [ 543.377408] acpi-lpss: suspend DMA [ 543.377450] acpi_lpss_suspend_noirq [ 543.377462] acpi-lpss: suspend DMA [ 543.377504] acpi_lpss_suspend_noirq [ 543.377517] acpi-lpss: suspend DMA [ 543.377610] acpi_lpss_suspend_noirq [ 543.377625] acpi-lpss: suspend DMA [ 543.377678] acpi_lpss_suspend_noirq [ 543.377691] acpi-lpss: suspend DMA [ 543.399458] PM: noirq suspend of devices complete after 25.460 msecs [ 543.399472] PM: suspend-to-idle [ 543.399576] punit debug: cpu 2: MIO is in D0 prior to freeze [ 543.399580] punit debug: cpu 3: MIO is in D0 prior to freeze [ 543.399588] punit debug: cpu 1: MIO is in D0 prior to freeze [ 543.399631] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze [ 543.399634] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze [ 543.399636] pmc_atom: pmc debug: cpu 3: GBE is in D0 prior to freeze [ 543.399639] pmc_atom: pmc debug: cpu 2: LPSS2_F7_I2C7 is in D0 prior to freeze [ 543.399641] pmc_atom: pmc debug: cpu 3: SEC is in D0 prior to freeze [ 543.399645] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze [ 543.399647] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze [ 543.399650] pmc_atom: pmc debug: cpu 3: LPSS2_F7_I2C7 is in D0 prior to freeze [ 543.399655] punit debug: cpu 0: MIO is in D0 prior to freeze [ 543.399659] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze [ 543.399661] pmc_atom: pmc debug: cpu 3: SMB is in D0 prior to freeze [ 543.399664] pmc_atom: pmc debug: cpu 1: LPSS2_F7_I2C7 is in D0 prior to freeze [ 543.399669] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze [ 543.399683] pmc_atom: pmc debug: cpu 0: GBE is in D0 prior to freeze [ 543.399687] pmc_atom: pmc debug: cpu 0: SEC is in D0 prior to freeze [ 543.399692] pmc_atom: pmc debug: cpu 0: LPSS2_F7_I2C7 is in D0 prior to freeze [ 543.399696] pmc_atom: pmc debug: cpu 0: SMB is in D0 prior to freeze [ 545.232394] Suspended for 2.255 seconds [ 545.232832] PM: resume from suspend-to-idle [ 545.236663] acpi_lpss_resume_noirq [ 545.236677] acpi_lpss_resume_noirq [ 545.236775] acpi_lpss_resume_noirq [ 545.236815] acpi_lpss_resume_noirq [ 545.236848] acpi_lpss_resume_noirq [ 545.236904] acpi_lpss_resume_noirq [ 545.236939] acpi_lpss_resume_noirq [ 545.237000] acpi_lpss_resume_noirq [ 545.258545] PM: noirq resume of devices complete after 25.644 msecs [ 546.317337] PM: early resume of devices complete after 1058.399 msecs [ 546.773115] rtc_cmos 00:05: System wakeup disabled by ACPI [ 547.131350] PM: resume of devices complete after 813.993 msecs [ 547.412483] PM: Finishing wakeup. [ 547.414200] OOM killer enabled. [ 547.415520] Restarting tasks ... done. The "acpi-lpss: suspend DMA" does not happen before freeze as part of normal runtime suspend. The patches are probably not the proper solution but outline the problems. Let me know how to get it in shape for upstream inclusion. @Takashi: Your topic/dollar-cove-ti-4.12 branch is idle for 3 months. Are these patches on their way to upstream? Looks interesting... Can you by the way instead of first patch try to enable runtime PM for SATA? There is no SATA device showing up in lspci. That's why I think it's a BIOS quirk it hasn't properly disabled the hardware. E200HA has eMMC and micro-SD slot only. Can you, please, attached the following 1) output file of acpidump -o tables.dat 2) output of grep -H 15 /sys/bus/acpi/devices/*/status 3) lspci -nk -vv -xx ? Created attachment 257981 [details]
"acpidump -o tables.dat", using latest BIOS version 303
Created attachment 257983 [details]
output of grep -H 15 /sys/bus/acpi/devices/*/status
Created attachment 257985 [details]
lspci -nk -vv -xx
(In reply to Johannes Stezenbach from comment #63) > @Takashi: Your topic/dollar-cove-ti-4.12 branch is idle > for 3 months. Are these patches on their way to upstream? Sorry, I've been just too busy for other tasks. Now I refreshed the patches, rebased to 4.13-rc5 and cleaned up a lot for upstreaming. The patches are in topic/dollar-cove-ti-4.13 branch on my sound.git tree. DC-TI + audio patches (with the revert for fixing the gpio regression) are found in topic/asus-e100h-4.13 branch, too. Could you give it a try? Also, Andy, Mika, it would be great if you guys can check the patches before submitting to upstream. Thanks! Is the ACPI device enumeration patch from bug #195689 included in the new branch? (In reply to Dainius Masiliūnas from comment #71) > Is the ACPI device enumeration patch from bug #195689 included in the new > branch? Good catch, I'll merge it in. Thanks. Takashi, I checked the patches in your branch and they look good to me. Thanks for taking care of this! FYI, topic/asus-e100h-4.13 branch was updated to contain the latest DC-TI patches and the fixed cx2072x patches (now without the revert), in addition to a few patches by Johannes. It's working fine with 4.13-rc6 on my ASUS laptop. Hi Takashi, I built and tested topic/asus-e100h-4.13 b6099763e14be, however it doesn't enter S0i3 but stays in S0i1: $ cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 64us S0I1 Residency: 7376288us S0I2 Residency: 0us S0I3 Residency: 0us S0 Residency: 365927392us The debug output from my S0ix test patch is as before, so I suppose the cause is some other change that went into 4.13-rc. I notice the power LED doesn't turn off during sleep as it did before. After three suspend/resume cycles it hung up hard. Created attachment 258039 [details]
updated kernel config for sound/topic/asus-e100h-4.13
I also experienced spontaneous reboot when wifi is enabled, unfortunately backtrace didn't make it into the logs and it rebooted before I could read it. I should mention I had a lot of objtool warnings during build, maybe it's not reliable. (In reply to Johannes Stezenbach from comment #75) > I built and tested topic/asus-e100h-4.13 b6099763e14be, > however it doesn't enter S0i3 but stays in S0i1. Could you try to merge topic/dollar-cove-ti-4.12 branch instead? You may need to resolve merge conflicts in Kconfig and Makefile, but it should be easy. I'm asking this because I cleaned up the patches significantly, and it's possible that I dropped something important by that. That is, merge topic/dollar-cove-ti-4.12, topic/soc-cx2072x-4.13 and your own patches on top of 4.13-rc, and check the result again. I had inadvertantly enabled some PANIC options in my kernel config, reboot was caused by some wifi related hung task (ieee80211_ba_session_work), so off topic here. Sorry for the noise. OK, then I'm going to submit the patches to upstream tomorrow. Let's see how things will go. Now I tested current master 4.13-rc6+ + topic/dollar-cove-ti-4.12 + topic/soc-cx2072x-4.13 + my patches. The result is the same as with your topic/asus-e100h-4.13, S0i3 can't be entered, only S0i1. Thus your patch rework is not the cause. Created attachment 258055 [details]
S0ix blocker debug patch v2
fix compile fail with !CONFIG_INTEL_IDLE found by kbuild test robot
(ugly, but it's just a debug patch)
Created attachment 258059 [details]
S0ix blocker debug patch v3
v3: fix v2, kbuild test robot mercilessly uncovers sloppy coding
(In reply to Johannes Stezenbach from comment #83) > Created attachment 258059 [details] > S0ix blocker debug patch v3 > > v3: fix v2, kbuild test robot mercilessly uncovers sloppy coding cat sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 0us S0I1 Residency: 0us S0I2 Residency: 0us S0I3 Residency: 0us S0 Residency: 42269588576us my device is z3735f，not reach the S0i3 state，only can suspend to idle. (In reply to Johannes Stezenbach from comment #53) > I finally had a little time to look into the S0ix issue, > I used a 4.12.3 kernel with Takashi's patches and only the > S0ix blocker patch added. The debug output is a little messy > since the notifier is called once for each CPU core going to sleep, > it shows this: > > [ 48.723560] PM: suspend-to-idle > [ 48.723633] punit debug: cpu 1: MIO is in D0 prior to freeze > [ 48.723657] pmc_atom: pmc debug: cpu 1: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723660] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze > [ 48.723662] pmc_atom: pmc debug: cpu 1: SATA is in D0 prior to freeze > [ 48.723664] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze > [ 48.723666] pmc_atom: pmc debug: cpu 1: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723668] pmc_atom: pmc debug: cpu 1: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723671] punit debug: cpu 0: MIO is in D0 prior to freeze > [ 48.723672] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze > [ 48.723679] punit debug: cpu 3: MIO is in D0 prior to freeze > [ 48.723699] pmc_atom: pmc debug: cpu 0: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723702] pmc_atom: pmc debug: cpu 0: GBE is in D0 prior to freeze > [ 48.723704] pmc_atom: pmc debug: cpu 0: SATA is in D0 prior to freeze > [ 48.723705] pmc_atom: pmc debug: cpu 0: SEC is in D0 prior to freeze > [ 48.723707] pmc_atom: pmc debug: cpu 0: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723709] pmc_atom: pmc debug: cpu 0: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723711] pmc_atom: pmc debug: cpu 0: SMB is in D0 prior to freeze > [ 48.723716] pmc_atom: pmc debug: cpu 3: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723721] pmc_atom: pmc debug: cpu 3: GBE is in D0 prior to freeze > [ 48.723726] punit debug: cpu 2: MIO is in D0 prior to freeze > [ 48.723729] pmc_atom: pmc debug: cpu 3: SATA is in D0 prior to freeze > [ 48.723732] pmc_atom: pmc debug: cpu 3: SEC is in D0 prior to freeze > [ 48.723736] pmc_atom: pmc debug: cpu 3: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723739] pmc_atom: pmc debug: cpu 3: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723742] pmc_atom: pmc debug: cpu 3: SMB is in D0 prior to freeze > [ 48.723751] pmc_atom: pmc debug: cpu 2: LPSS1_F0_DMA is in D0 prior to > freeze > [ 48.723755] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze > [ 48.723758] pmc_atom: pmc debug: cpu 2: SATA is in D0 prior to freeze > [ 48.723761] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze > [ 48.723765] pmc_atom: pmc debug: cpu 2: LPSS2_F0_DMA is in D0 prior to > freeze > [ 48.723768] pmc_atom: pmc debug: cpu 2: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 48.723771] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze > [ 51.295884] Suspended for 2.558 seconds > [ 51.296358] PM: resume from suspend-to-idle > > The Xiaomi_Kernel_OpenSource also has a patch > "PM : Add interface to bypass S0ix blockers", but I didn't port > it and instead used busybox devmem to poke the PMC registers: > > get PMC base address: > $ setpci -s 00:1f.0 44.l > fed03002 > > print and change disabled IPs: > $ busybox devmem 0xfed03034 32 > 0x00E0C204 > $ busybox devmem 0xfed03034 32 0x01e2c205 > > This disables LPSS1_F0_DMA, LPSS2_F0_DMA and SATA as can > be verified via /sys/kernel/debug/pmc_atom/dev_state. > (I did a few experiments to figure out these IPs can be disabled > without crashing immediately.) > > After this, S0ix can be entered: > $ echo freeze >/sys/power/state > $ cat /sys/kernel/debug/pmc_atom/sleep_state > S0IR Residency: 32us > S0I1 Residency: 4864us > S0I2 Residency: 19072us > S0I3 Residency: 2979136us > S0 Residency: 4668440640us > > I guess LPSS1_F0_DMA and LPSS2_F0_DMA are not safe to disable this way, > they should be handled by drivers/dma/dw/ but I don't see how the > driver needs to be change to handle this. > > About SATA, this is not used and no such IP shows up in lspci, > I guess BIOS should have disabled it. Probably needs a quirk > handler for E200HA? > > I let it sleep for a day, on first try it woke up spuriously > after three hours, on second try it stayed suspended, battery > usage was about 1% per hour (5000mAh battery). > > > (PS: Sorry about comment 50, wth did bugzilla add a deleted > obsolete patch as comment???) $ cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 32us S0I1 Residency: 4864us S0I2 Residency: 19072us S0I3 Residency: 2979136us S0 Residency: 4668440640us I need this happen on z3735f，i will study it. cat /sys/kernel/debug/pmc_atom/dev_state Dev: 0 - LPSS1_F0_DMA State: Enabled [D0] Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] Dev: 4 - LPSS1_F4_HSUART2 State: Enabled [D3] Dev: 5 - LPSS1_F5_SPI State: Disabled [D0] Dev: 6 - LPSS1_F6_Reserved State: Disabled [D0] Dev: 7 - LPSS1_F7_Reserved State: Disabled [D0] Dev: 8 - SCC_EMMC State: Disabled [D0] Dev: 9 - SCC_SDIO State: Enabled [D0] Dev: 10 - SCC_SDCARD State: Enabled [D0] Dev: 11 - SCC_MIPI State: Enabled [D0] Dev: 12 - HDA State: Disabled [D3] Dev: 13 - LPE State: Enabled [D0] Dev: 14 - OTG State: Disabled [D3] Dev: 15 - USH State: Enabled [D0] Dev: 16 - GBE State: Enabled [D0] Dev: 17 - SATA State: Enabled [D0] Dev: 18 - USB_EHCI State: Disabled [D0] Dev: 19 - SEC State: Enabled [D0] Dev: 20 - PCIE_PORT0 State: Enabled [D0] Dev: 21 - PCIE_PORT1 State: Enabled [D0] Dev: 22 - PCIE_PORT2 State: Enabled [D0] Dev: 23 - PCIE_PORT3 State: Enabled [D0] Dev: 24 - LPSS2_F0_DMA State: Enabled [D0] Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3] Dev: 28 - LPSS2_F3_I2C4 State: Enabled [D0] Dev: 29 - LPSS2_F5_I2C5 State: Enabled [D0] Dev: 30 - LPSS2_F6_I2C6 State: Disabled [D0] Dev: 31 - LPSS2_F7_I2C7 State: Disabled [D0] Dev: 32 - SMB State: Enabled [D0] Dev: 33 - OTG_SS_PHY State: Disabled [D0] Dev: 34 - USH_SS_PHY State: Enabled [D0] Dev: 35 - DFX State: Enabled [D0] root@localhost:/home/youling257# setpci -s 00:1f.0 44.l fed03002 root@localhost:/home/youling257# busybox devmem 0xfed03034 32 0xC00451E4 root@localhost:/home/youling257# busybox devmem 0xfed03034 32 0xC00451E4 root@localhost:/home/youling257# busybox devmem 0xfed03034 32 0x01e2c205 root@localhost:/home/youling257# Dev: 0 - LPSS1_F0_DMA State: Disabled [D0] Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] Dev: 4 - LPSS1_F4_HSUART2 State: Enabled [D3] Dev: 5 - LPSS1_F5_SPI State: Enabled [D0] Dev: 6 - LPSS1_F6_Reserved State: Enabled [D0] Dev: 7 - LPSS1_F7_Reserved State: Enabled [D0] Dev: 8 - SCC_EMMC State: Enabled [D0] Dev: 9 - SCC_SDIO State: Disabled [D0] Dev: 10 - SCC_SDCARD State: Enabled [D0] Dev: 11 - SCC_MIPI State: Enabled [D0] Dev: 12 - HDA State: Enabled [D3] Dev: 13 - LPE State: Enabled [D0] Dev: 14 - OTG State: Disabled [D3] Dev: 15 - USH State: Disabled [D0] Dev: 16 - GBE State: Enabled [D0] Dev: 17 - SATA State: Disabled [D0] Dev: 18 - USB_EHCI State: Enabled [D0] Dev: 19 - SEC State: Enabled [D0] Dev: 20 - PCIE_PORT0 State: Enabled [D0] Dev: 21 - PCIE_PORT1 State: Disabled [D0] Dev: 22 - PCIE_PORT2 State: Disabled [D0] Dev: 23 - PCIE_PORT3 State: Disabled [D0] Dev: 24 - LPSS2_F0_DMA State: Disabled [D0] Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3] Dev: 28 - LPSS2_F3_I2C4 State: Enabled [D0] Dev: 29 - LPSS2_F5_I2C5 State: Enabled [D0] Dev: 30 - LPSS2_F6_I2C6 State: Enabled [D0] Dev: 31 - LPSS2_F7_I2C7 State: Enabled [D0] Dev: 32 - SMB State: Enabled [D0] Dev: 33 - OTG_SS_PHY State: Disabled [D0] Dev: 34 - USH_SS_PHY State: Enabled [D0] Dev: 35 - DFX State: Enabled [D0] (In reply to youling257 from comment #86) > cat /sys/kernel/debug/pmc_atom/dev_state > Dev: 0 - LPSS1_F0_DMA State: Enabled [D0] > Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] > Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] > Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] > Dev: 4 - LPSS1_F4_HSUART2 State: Enabled [D3] > Dev: 5 - LPSS1_F5_SPI State: Disabled [D0] > Dev: 6 - LPSS1_F6_Reserved State: Disabled [D0] > Dev: 7 - LPSS1_F7_Reserved State: Disabled [D0] > Dev: 8 - SCC_EMMC State: Disabled [D0] > Dev: 9 - SCC_SDIO State: Enabled [D0] > Dev: 10 - SCC_SDCARD State: Enabled [D0] > Dev: 11 - SCC_MIPI State: Enabled [D0] > Dev: 12 - HDA State: Disabled [D3] > Dev: 13 - LPE State: Enabled [D0] > Dev: 14 - OTG State: Disabled [D3] > Dev: 15 - USH State: Enabled [D0] > Dev: 16 - GBE State: Enabled [D0] > Dev: 17 - SATA State: Enabled [D0] > Dev: 18 - USB_EHCI State: Disabled [D0] > Dev: 19 - SEC State: Enabled [D0] > Dev: 20 - PCIE_PORT0 State: Enabled [D0] > Dev: 21 - PCIE_PORT1 State: Enabled [D0] > Dev: 22 - PCIE_PORT2 State: Enabled [D0] > Dev: 23 - PCIE_PORT3 State: Enabled [D0] > Dev: 24 - LPSS2_F0_DMA State: Enabled [D0] > Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] > Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] > Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3] > Dev: 28 - LPSS2_F3_I2C4 State: Enabled [D0] > Dev: 29 - LPSS2_F5_I2C5 State: Enabled [D0] > Dev: 30 - LPSS2_F6_I2C6 State: Disabled [D0] > Dev: 31 - LPSS2_F7_I2C7 State: Disabled [D0] > Dev: 32 - SMB State: Enabled [D0] > Dev: 33 - OTG_SS_PHY State: Disabled [D0] > Dev: 34 - USH_SS_PHY State: Enabled [D0] > Dev: 35 - DFX State: Enabled [D0] then echo freeze > /sys/power/state，it is hung，not enter suspend，have to press power button force shutdown. my kernel include these three patches，https://github.com/jwrdegoede/linux-sunxi/commits/master/drivers/acpi/acpi_lpss.c (In reply to youling257 from comment #87) > root@localhost:/home/youling257# setpci -s 00:1f.0 44.l > fed03002 > root@localhost:/home/youling257# busybox devmem 0xfed03034 32 > 0xC00451E4 > root@localhost:/home/youling257# busybox devmem 0xfed03034 32 > 0xC00451E4 > root@localhost:/home/youling257# busybox devmem 0xfed03034 32 0x01e2c205 > root@localhost:/home/youling257# > > Dev: 0 - LPSS1_F0_DMA State: Disabled [D0] > Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] > Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] > Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] > Dev: 4 - LPSS1_F4_HSUART2 State: Enabled [D3] > Dev: 5 - LPSS1_F5_SPI State: Enabled [D0] > Dev: 6 - LPSS1_F6_Reserved State: Enabled [D0] > Dev: 7 - LPSS1_F7_Reserved State: Enabled [D0] > Dev: 8 - SCC_EMMC State: Enabled [D0] > Dev: 9 - SCC_SDIO State: Disabled [D0] > Dev: 10 - SCC_SDCARD State: Enabled [D0] > Dev: 11 - SCC_MIPI State: Enabled [D0] > Dev: 12 - HDA State: Enabled [D3] > Dev: 13 - LPE State: Enabled [D0] > Dev: 14 - OTG State: Disabled [D3] > Dev: 15 - USH State: Disabled [D0] > Dev: 16 - GBE State: Enabled [D0] > Dev: 17 - SATA State: Disabled [D0] > Dev: 18 - USB_EHCI State: Enabled [D0] > Dev: 19 - SEC State: Enabled [D0] > Dev: 20 - PCIE_PORT0 State: Enabled [D0] > Dev: 21 - PCIE_PORT1 State: Disabled [D0] > Dev: 22 - PCIE_PORT2 State: Disabled [D0] > Dev: 23 - PCIE_PORT3 State: Disabled [D0] > Dev: 24 - LPSS2_F0_DMA State: Disabled [D0] > Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] > Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] > Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3] > Dev: 28 - LPSS2_F3_I2C4 State: Enabled [D0] > Dev: 29 - LPSS2_F5_I2C5 State: Enabled [D0] > Dev: 30 - LPSS2_F6_I2C6 State: Enabled [D0] > Dev: 31 - LPSS2_F7_I2C7 State: Enabled [D0] > Dev: 32 - SMB State: Enabled [D0] > Dev: 33 - OTG_SS_PHY State: Disabled [D0] > Dev: 34 - USH_SS_PHY State: Enabled [D0] > Dev: 35 - DFX State: Enabled [D0] busybox devmem 0xfed03034 32 0x01e2c205 ，then echo freeze > /sys/power/state，it is hung，not enter suspend，have to press power button force shutdown. my #c88，I reply error，should reply to #c87. my mean is，"echo freeze > /sys/power/state" to suspend no problem on my kernel， if disables LPSS1_F0_DMA, LPSS2_F0_DMA and SATA，"echo freeze > /sys/power/state" will hung，the reason may be the three patches. So I've tried to make I2C7 use suspend_late rather then not having it suspend at all, but that did not end well. When I do this I get a bunch of errors from the i2c-designware driver when it tries to suspend, as if some resources have already been turned off. And I still get the errors from other devices my original patch solved by disabling suspend for the I2C7 device. Question, there have been a lot of comments here, is I2C7 suspend still a problem / blocker for S0ix support ? On HP x2 210 with the previous patchset, I also only got S0 Residency, everything else is at zero. I wanted to try the new patchset, but topic/dollar-cove-ti-4.13-v4 causes kernel panics due to not finding any partitions altogether for some reason... Currently S0ix is working for me on 4.12.3 + patches, see comment #51 and comment #53. With 4.13rc kernels S0ix can't be entered. Don't know why but also don't know how to bisect, I was hoping Intel guys had an idea what to check... Regarding I2C7, two interesting discussions on linux-acpi: https://marc.info/?l=linux-acpi&m=150349934126176&w=2 i2c-designware-platdrv.c vs. ACPI pm domain, long discussion which eventually might fix what I worked around with my "acpi-lpss test debug hack to fix S0ix entry" patch, if I understand correctly. https://marc.info/?l=linux-acpi&m=150284622703647&w=2 "ACPI / Sleep: Check low power idle constraints for debug only" evaluates _DSM explained in http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf to check if constraints to enter S0ix are met, and the constraint table in E200HA DSDT lists "I2C7 in D3" as prerequisite (although I could enter S0ix with I2C7 enabled). Frankly I don't understand the reason for keeping I2C7 on. In my comment #58 I quote commit 894acb2f823b "i2c: designware: Add Intel Baytrail PMIC I2C bus support" which made the claim that runtime pm must be disabled for I2C7 but doesn't really explain why. My uneducated guess is I2C7 must properly tristate the SDA+SCL pins whenever it has released the semaphore so that another master can drive the bus, nothing more. why only porting Dollar Cove TI (ACPI INT33F5) ? Bay trail-CR also need it ? Date: Mon, 19 May 2014 14:23:34 -0700 Subject: [PATCH] mfd/intel_soc_pmic: add dollar cove Dollar Cove PMIC provides ADC, GPIO, and battery charging functionalities to Intel Baytrail based SoC. This patch adds PMIC device specific info to the common Intel SoC PMIC driver. Based on MCG's code. Open issues: - ACPI i2c device HID INT33FD duplicated with Crystal Cove - Hardcoded IRQ# - Dependent cell driver functions need to be integrated can someone porting Dollar Cove (ACPI INT33FD) ? (In reply to Hans de Goede from comment #91) > So I've tried to make I2C7 use suspend_late rather then not having it > suspend at all, but that did not end well. When I do this I get a bunch of > errors from the i2c-designware driver when it tries to suspend, as if some > resources have already been turned off. And I still get the errors from > other devices my original patch solved by disabling suspend for the I2C7 > device. > > Question, there have been a lot of comments here, is I2C7 suspend still a > problem / blocker for S0ix support ? https://bugzilla.kernel.org/show_bug.cgi?id=193891#c53 >I let it sleep for a day, on first try it woke up spuriously >after three hours, on second try it stayed suspended, battery >usage was about 1% per hour (5000mAh battery). hello，Hans，is it possible on Bay trail ? (In reply to Johannes Stezenbach from comment #63) > With the three patches from comments 60+ applied > my E200HA can enter S0ix as confirmed in > /sys/kernel/debug/pmc_atom/sleep_state. > The debug output is: > > [ 541.753861] PM: Syncing filesystems ... done. > [ 541.784212] PM: Preparing system for sleep (freeze) > [ 541.788791] Freezing user space processes ... (elapsed 0.001 seconds) > done. > [ 541.793797] OOM killer disabled. > [ 541.796981] Freezing remaining freezable tasks ... (elapsed 0.001 > seconds) done. > [ 541.800942] PM: Suspending system (freeze) > [ 541.802890] Suspending console(s) (use no_console_suspend to debug) > [ 542.519961] WARN_ON(pipe != PIPE_A && pipe != PIPE_B) > [ 542.520042] ------------[ cut here ]------------ > [ 542.520070] WARNING: CPU: 0 PID: 1781 at > drivers/gpu/drm/i915/intel_panel.c:771 vlv_disable_backlight+0x90/0xa0 > ... (snip i915 splat) > [ 542.520816] ---[ end trace f3f9a1e4e0632c94 ]--- > [ 543.338975] PM: suspend of devices complete after 1316.433 msecs > [ 543.373961] PM: late suspend of devices complete after 34.963 msecs > [ 543.377216] acpi_lpss_suspend_noirq > [ 543.377232] acpi-lpss: suspend DMA > [ 543.377279] acpi_lpss_suspend_noirq > [ 543.377292] acpi-lpss: suspend DMA > [ 543.377335] acpi_lpss_suspend_noirq > [ 543.377347] acpi-lpss: suspend DMA > [ 543.377395] acpi_lpss_suspend_noirq > [ 543.377408] acpi-lpss: suspend DMA > [ 543.377450] acpi_lpss_suspend_noirq > [ 543.377462] acpi-lpss: suspend DMA > [ 543.377504] acpi_lpss_suspend_noirq > [ 543.377517] acpi-lpss: suspend DMA > [ 543.377610] acpi_lpss_suspend_noirq > [ 543.377625] acpi-lpss: suspend DMA > [ 543.377678] acpi_lpss_suspend_noirq > [ 543.377691] acpi-lpss: suspend DMA > [ 543.399458] PM: noirq suspend of devices complete after 25.460 msecs > [ 543.399472] PM: suspend-to-idle > [ 543.399576] punit debug: cpu 2: MIO is in D0 prior to freeze > [ 543.399580] punit debug: cpu 3: MIO is in D0 prior to freeze > [ 543.399588] punit debug: cpu 1: MIO is in D0 prior to freeze > [ 543.399631] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze > [ 543.399634] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze > [ 543.399636] pmc_atom: pmc debug: cpu 3: GBE is in D0 prior to freeze > [ 543.399639] pmc_atom: pmc debug: cpu 2: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 543.399641] pmc_atom: pmc debug: cpu 3: SEC is in D0 prior to freeze > [ 543.399645] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze > [ 543.399647] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze > [ 543.399650] pmc_atom: pmc debug: cpu 3: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 543.399655] punit debug: cpu 0: MIO is in D0 prior to freeze > [ 543.399659] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze > [ 543.399661] pmc_atom: pmc debug: cpu 3: SMB is in D0 prior to freeze > [ 543.399664] pmc_atom: pmc debug: cpu 1: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 543.399669] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze > [ 543.399683] pmc_atom: pmc debug: cpu 0: GBE is in D0 prior to freeze > [ 543.399687] pmc_atom: pmc debug: cpu 0: SEC is in D0 prior to freeze > [ 543.399692] pmc_atom: pmc debug: cpu 0: LPSS2_F7_I2C7 is in D0 prior to > freeze > [ 543.399696] pmc_atom: pmc debug: cpu 0: SMB is in D0 prior to freeze > [ 545.232394] Suspended for 2.255 seconds > [ 545.232832] PM: resume from suspend-to-idle > [ 545.236663] acpi_lpss_resume_noirq > [ 545.236677] acpi_lpss_resume_noirq > [ 545.236775] acpi_lpss_resume_noirq > [ 545.236815] acpi_lpss_resume_noirq > [ 545.236848] acpi_lpss_resume_noirq > [ 545.236904] acpi_lpss_resume_noirq > [ 545.236939] acpi_lpss_resume_noirq > [ 545.237000] acpi_lpss_resume_noirq > [ 545.258545] PM: noirq resume of devices complete after 25.644 msecs > [ 546.317337] PM: early resume of devices complete after 1058.399 msecs > [ 546.773115] rtc_cmos 00:05: System wakeup disabled by ACPI > [ 547.131350] PM: resume of devices complete after 813.993 msecs > [ 547.412483] PM: Finishing wakeup. > [ 547.414200] OOM killer enabled. > [ 547.415520] Restarting tasks ... done. > > > The "acpi-lpss: suspend DMA" does not happen before > freeze as part of normal runtime suspend. > > The patches are probably not the proper solution but outline > the problems. Let me know how to get it in shape for upstream > inclusion. > > @Takashi: Your topic/dollar-cove-ti-4.12 branch is idle > for 3 months. Are these patches on their way to upstream? with your three patch， [ 176.854769] PM: suspend of devices complete after 796.930 msecs [ 176.904121] PM: late suspend of devices complete after 49.332 msecs [ 176.905630] acpi_lpss_suspend_noirq [ 176.905645] acpi-lpss: busy devices 20000000 [ 176.905654] acpi_lpss_suspend_noirq [ 176.905665] acpi-lpss: busy devices 20000000 [ 176.905677] acpi_lpss_suspend_noirq [ 176.905684] acpi-lpss: busy devices 20000000 [ 176.905689] acpi_lpss_suspend_noirq [ 176.905699] acpi-lpss: busy devices 20000000 [ 176.905752] acpi_lpss_suspend_noirq [ 176.905767] acpi-lpss: busy devices 20000000 [ 176.905782] acpi_lpss_suspend_noirq [ 176.905798] acpi-lpss: busy devices 20000000 [ 176.919440] PM: noirq suspend of devices complete after 15.241 msecs [ 176.919454] PM: suspend-to-idle [ 176.919487] pmc_atom: pmc debug: cpu 2: LPSS1_F0_DMA is in D0 prior to freeze [ 176.919494] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze [ 176.919504] pmc_atom: pmc debug: cpu 3: LPSS1_F0_DMA is in D0 prior to freeze [ 176.919509] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze [ 176.919518] pmc_atom: pmc debug: cpu 0: LPSS1_F0_DMA is in D0 prior to freeze [ 176.919525] pmc_atom: pmc debug: cpu 3: GBE is in D0 prior to freeze [ 176.919530] pmc_atom: pmc debug: cpu 2: PCIE_PORT0 is in D0 prior to freeze [ 176.919536] pmc_atom: pmc debug: cpu 0: GBE is in D0 prior to freeze [ 176.919540] pmc_atom: pmc debug: cpu 3: SEC is in D0 prior to freeze [ 176.919545] pmc_atom: pmc debug: cpu 2: PCIE_PORT1 is in D0 prior to freeze [ 176.919549] pmc_atom: pmc debug: cpu 0: SEC is in D0 prior to freeze [ 176.919554] pmc_atom: pmc debug: cpu 3: PCIE_PORT0 is in D0 prior to freeze [ 176.919559] pmc_atom: pmc debug: cpu 2: PCIE_PORT2 is in D0 prior to freeze [ 176.919566] pmc_atom: pmc debug: cpu 1: LPSS1_F0_DMA is in D0 prior to freeze [ 176.919571] pmc_atom: pmc debug: cpu 0: PCIE_PORT0 is in D0 prior to freeze [ 176.919576] pmc_atom: pmc debug: cpu 3: PCIE_PORT1 is in D0 prior to freeze [ 176.919580] pmc_atom: pmc debug: cpu 2: PCIE_PORT3 is in D0 prior to freeze [ 176.919585] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze [ 176.919590] pmc_atom: pmc debug: cpu 0: PCIE_PORT1 is in D0 prior to freeze [ 176.919594] pmc_atom: pmc debug: cpu 3: PCIE_PORT2 is in D0 prior to freeze [ 176.919598] pmc_atom: pmc debug: cpu 2: LPSS2_F0_DMA is in D0 prior to freeze [ 176.919603] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze [ 176.919607] pmc_atom: pmc debug: cpu 0: PCIE_PORT2 is in D0 prior to freeze [ 176.919611] pmc_atom: pmc debug: cpu 3: PCIE_PORT3 is in D0 prior to freeze [ 176.919616] pmc_atom: pmc debug: cpu 2: LPSS2_F5_I2C5 is in D0 prior to freeze [ 176.919620] pmc_atom: pmc debug: cpu 1: PCIE_PORT0 is in D0 prior to freeze [ 176.919625] pmc_atom: pmc debug: cpu 0: PCIE_PORT3 is in D0 prior to freeze [ 176.919629] pmc_atom: pmc debug: cpu 3: LPSS2_F0_DMA is in D0 prior to freeze [ 176.919634] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze [ 176.919638] pmc_atom: pmc debug: cpu 1: PCIE_PORT1 is in D0 prior to freeze [ 176.919642] pmc_atom: pmc debug: cpu 0: LPSS2_F0_DMA is in D0 prior to freeze [ 176.919647] pmc_atom: pmc debug: cpu 3: LPSS2_F5_I2C5 is in D0 prior to freeze [ 176.919651] pmc_atom: pmc debug: cpu 2: USH_SS_PHY is in D0 prior to freeze [ 176.919655] pmc_atom: pmc debug: cpu 1: PCIE_PORT2 is in D0 prior to freeze [ 176.919660] pmc_atom: pmc debug: cpu 0: LPSS2_F5_I2C5 is in D0 prior to freeze [ 176.919664] pmc_atom: pmc debug: cpu 3: SMB is in D0 prior to freeze [ 176.919668] pmc_atom: pmc debug: cpu 2: DFX is in D0 prior to freeze [ 176.919673] pmc_atom: pmc debug: cpu 1: PCIE_PORT3 is in D0 prior to freeze [ 176.919678] pmc_atom: pmc debug: cpu 0: SMB is in D0 prior to freeze [ 176.919682] pmc_atom: pmc debug: cpu 3: USH_SS_PHY is in D0 prior to freeze [ 176.919687] pmc_atom: pmc debug: cpu 1: LPSS2_F0_DMA is in D0 prior to freeze [ 176.919691] pmc_atom: pmc debug: cpu 0: USH_SS_PHY is in D0 prior to freeze [ 176.919696] pmc_atom: pmc debug: cpu 3: DFX is in D0 prior to freeze [ 176.919700] pmc_atom: pmc debug: cpu 1: LPSS2_F5_I2C5 is in D0 prior to freeze [ 176.919705] pmc_atom: pmc debug: cpu 0: DFX is in D0 prior to freeze [ 176.919710] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze [ 176.919714] pmc_atom: pmc debug: cpu 1: USH_SS_PHY is in D0 prior to freeze [ 176.919718] pmc_atom: pmc debug: cpu 1: DFX is in D0 prior to freeze [ 179.526083] Suspended for 2.606 seconds [ 179.526634] pmc_atom: pmc debug: cpu 1: LPSS1_F0_DMA is in D0 prior to freeze [ 179.526642] pmc_atom: pmc debug: cpu 1: GBE is in D0 prior to freeze [ 179.526646] pmc_atom: pmc debug: cpu 1: SEC is in D0 prior to freeze [ 179.526651] pmc_atom: pmc debug: cpu 1: PCIE_PORT0 is in D0 prior to freeze [ 179.526655] pmc_atom: pmc debug: cpu 1: PCIE_PORT1 is in D0 prior to freeze [ 179.526667] pmc_atom: pmc debug: cpu 2: LPSS1_F0_DMA is in D0 prior to freeze [ 179.526672] pmc_atom: pmc debug: cpu 1: PCIE_PORT2 is in D0 prior to freeze [ 179.526678] pmc_atom: pmc debug: cpu 2: GBE is in D0 prior to freeze [ 179.526682] pmc_atom: pmc debug: cpu 1: PCIE_PORT3 is in D0 prior to freeze [ 179.526687] pmc_atom: pmc debug: cpu 2: SEC is in D0 prior to freeze [ 179.526691] pmc_atom: pmc debug: cpu 1: LPSS2_F0_DMA is in D0 prior to freeze [ 179.526696] pmc_atom: pmc debug: cpu 2: PCIE_PORT0 is in D0 prior to freeze [ 179.526701] pmc_atom: pmc debug: cpu 1: LPSS2_F5_I2C5 is in D0 prior to freeze [ 179.526705] pmc_atom: pmc debug: cpu 2: PCIE_PORT1 is in D0 prior to freeze [ 179.526710] pmc_atom: pmc debug: cpu 1: SMB is in D0 prior to freeze [ 179.526714] pmc_atom: pmc debug: cpu 2: PCIE_PORT2 is in D0 prior to freeze [ 179.526719] pmc_atom: pmc debug: cpu 1: USH_SS_PHY is in D0 prior to freeze [ 179.526724] pmc_atom: pmc debug: cpu 2: PCIE_PORT3 is in D0 prior to freeze [ 179.526728] pmc_atom: pmc debug: cpu 1: DFX is in D0 prior to freeze [ 179.526733] pmc_atom: pmc debug: cpu 2: LPSS2_F0_DMA is in D0 prior to freeze [ 179.526737] pmc_atom: pmc debug: cpu 2: LPSS2_F5_I2C5 is in D0 prior to freeze [ 179.526743] pmc_atom: pmc debug: cpu 2: SMB is in D0 prior to freeze [ 179.526747] pmc_atom: pmc debug: cpu 2: USH_SS_PHY is in D0 prior to freeze [ 179.526752] pmc_atom: pmc debug: cpu 2: DFX is in D0 prior to freeze [ 179.526772] PM: resume from suspend-to-idle [ 179.527399] acpi_lpss_resume_noirq [ 179.527461] acpi_lpss_resume_noirq [ 179.527849] acpi_lpss_resume_noirq [ 179.527890] acpi_lpss_resume_noirq [ 179.527931] acpi_lpss_resume_noirq [ 179.527969] acpi_lpss_resume_noirq [ 179.560245] PM: noirq resume of devices complete after 33.307 msecs [ 179.613934] PM: early resume of devices complete after 53.338 msecs android_x86:/ $ su android_x86:/ # cat /sys/kernel/debug/pmc_atom/dev_state Dev: 0 - LPSS1_F0_DMA State: Enabled [D0] Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] Dev: 4 - LPSS1_F4_HSUART2 State: Enabled [D3] Dev: 5 - LPSS1_F5_SPI State: Disabled [D0] Dev: 6 - LPSS1_F6_Reserved State: Disabled [D0] Dev: 7 - LPSS1_F7_Reserved State: Disabled [D0] Dev: 8 - SCC_EMMC State: Disabled [D0] Dev: 9 - SCC_SDIO State: Enabled [D0] Dev: 10 - SCC_SDCARD State: Enabled [D0] Dev: 11 - SCC_MIPI State: Enabled [D0] Dev: 12 - HDA State: Disabled [D3] Dev: 13 - LPE State: Enabled [D0] Dev: 14 - OTG State: Disabled [D3] Dev: 15 - USH State: Enabled [D0] Dev: 16 - GBE State: Enabled [D0] Dev: 17 - SATA State: Disabled [D0] Dev: 18 - USB_EHCI State: Disabled [D0] Dev: 19 - SEC State: Enabled [D0] Dev: 20 - PCIE_PORT0 State: Enabled [D0] Dev: 21 - PCIE_PORT1 State: Enabled [D0] Dev: 22 - PCIE_PORT2 State: Enabled [D0] Dev: 23 - PCIE_PORT3 State: Enabled [D0] Dev: 24 - LPSS2_F0_DMA State: Enabled [D0] Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3] Dev: 28 - LPSS2_F3_I2C4 State: Enabled [D0] Dev: 29 - LPSS2_F5_I2C5 State: Enabled [D0] Dev: 30 - LPSS2_F6_I2C6 State: Disabled [D0] Dev: 31 - LPSS2_F7_I2C7 State: Disabled [D0] Dev: 32 - SMB State: Enabled [D0] Dev: 33 - OTG_SS_PHY State: Disabled [D0] Dev: 34 - USH_SS_PHY State: Enabled [D0] Dev: 35 - DFX State: Enabled [D0] android_x86:/ # SATA disable，i2c7 not enable - u32 func_dis, d3_sts_0, pmc_status, pmc_mask = 0xfe000ffe; + u32 func_dis, d3_sts_0, pmc_status, pmc_mask = 0x7e000ffe is it also work for bay trail ? if busybox devmem 0xfed03034 32 0x01e2c205，my Bay trail will hung . (In reply to Johannes Stezenbach from comment #93) > Currently S0ix is working for me on 4.12.3 + patches, see comment #51 > and comment #53. With 4.13rc kernels S0ix can't be entered. > Don't know why but also don't know how to bisect, I was hoping Intel > guys had an idea what to check... > > Regarding I2C7, two interesting discussions on linux-acpi: > > https://marc.info/?l=linux-acpi&m=150349934126176&w=2 > i2c-designware-platdrv.c vs. ACPI pm domain, long discussion > which eventually might fix what I worked around with my > "acpi-lpss test debug hack to fix S0ix entry" patch, if > I understand correctly. > > https://marc.info/?l=linux-acpi&m=150284622703647&w=2 > "ACPI / Sleep: Check low power idle constraints for debug only" > evaluates _DSM explained in > http://www.uefi.org/sites/default/files/resources/ > Intel_ACPI_Low_Power_S0_Idle.pdf > to check if constraints to enter S0ix are met, and the > constraint table in E200HA DSDT lists "I2C7 in D3" > as prerequisite (although I could enter S0ix with I2C7 enabled). > > Frankly I don't understand the reason for keeping I2C7 on. > In my comment #58 I quote commit 894acb2f823b "i2c: designware: > Add Intel Baytrail PMIC I2C bus support" which made the claim > that runtime pm must be disabled for I2C7 but doesn't really > explain why. My uneducated guess is I2C7 must properly > tristate the SDA+SCL pins whenever it has released the semaphore > so that another master can drive the bus, nothing more. did you try the newest i2c: designware patch ? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=i2c%3A+designware > can someone porting Dollar Cove (ACPI INT33FD) ?
"Dollar Cove" is AXP288 (INT33F4), while INT33FD is "Crystal Cove",
both are already supported. Please stop spamming this bug with
irrelevant quotes, it is not helping.
BTW, you can try if "powertop --auto-tune" improves S0ix
preconditions, e.g. the PCIE_PORT D3.
(In reply to Johannes Stezenbach from comment #93) > Frankly I don't understand the reason for keeping I2C7 on. > In my comment #58 I quote commit 894acb2f823b "i2c: designware: > Add Intel Baytrail PMIC I2C bus support" which made the claim > that runtime pm must be disabled for I2C7 but doesn't really > explain why. My uneducated guess is I2C7 must properly > tristate the SDA+SCL pins whenever it has released the semaphore > so that another master can drive the bus, nothing more. So there are really 2 issues: 1) For unknown reasons runtime pm must be enabled (I've not verified this, this is from the patch you refer to), this should not impact the use of S0ix states when suspended (to-idle). 2) The D0 / D3 methods of some devices use ACPI OpRegions on the PMIC which is attached to I2C7, these methods get executed by acpi_dev_suspend_late / acpi_dev_resume_early. Since the i2c-designware driver uses regular suspend / resume callbacks it is already suspended at the time those calls happen, leading to a device-suspend error and the system not suspending at all. As mentioned in my earlier comment because of the S0ix concerns around my patch to completely disable suspend for I2C7 (which is necessary on some devices for suspend to work at all) I've tried changing i2c-designware-platdrv to use early_resume / late_suspend itself instead of disabling suspend completely on I2C7, but that did not work, there were 2 issues (IIRC): 1) It seems that even when using late_suspend/early_resume the i2c-designware's suspend methods still gets run before some of the device using it through PMIC OpRegions. 2) The suspending of the controller itself failed now, this may be a bad interaction with the pm code in drivers/acpi/acpi_lpss.c, I did not investigate this further due to -ENOTIME. Hi Hans, thanks for pointing out the ACPI OpRegion interaction. At the time I mailed you privatedly about this, Andy had added comment #55 "DMA is on because I2C7 is on" which I interpreted as "no S0ix while I2C7 is on", however my testing subsequently showed S0ix can be entered with I2C7 on if I force DMA off (which is safe because nothing on my machine is using the DMA controller). However, PNP0D80 table says I2C7 must be in D3. Anyway, meanwhile I saw the mess between pm core, acpi pm domain, acpi-lpss and i2c-designware-platdrv and hope eventually it'll be fixed. BTW, at the time I opened this bug I was confused about the role of the PMIC wrt S0ix, thus all the S0ix discussion here. But as I understand what Intel guys said, S0ix is a hardware function of the SoC that will be entered if the right preconditions are met at the time intel_idle executes the MWAIT to enter s2idle. But sadly there is no documentation or debug aid to figure out which precondition is missed to enter S0ix. The patch I attached here prints a list of active devices, but a) I could enter S0ix on 4.12.3 with some devices active, and b) I can't enter S0ix on 4.13-rc with the same list of devices active. Oh, turns out that the kernel panics I was seeing were due to unrelated config options. Now I did manage to test the latest topic branch, and unfortunately the HP x2 210 still doesn't go into any of the Si0x sleep states ever, no matter what I do. The kernel logs do show it suspending and resuming, but the residency statictics say it's still in S0 always. I bisected what blocks S0ix entry on v4.13 today, it is caused by d31fd43c0f9a4 "clk: x86: Do not gate clocks enabled by the firmware". Reverting this on top of v4.13 makes S0ix work again on Asus E200HA. To be precise for those who want to reproduce: - v4.13 - merge sound/topic/dollar-cove-ti-4.13-v5 - merge sound/topic/soc-cx2072x-4.13 - apply "S0ix blocker debug patch v3" from above - likely not needed for S0ix but I had 3 cleanup patches applied from https://lkml.kernel.org/r/3958866.l2qnKDbinI@aspire.rjw.lan - revert d31fd43c0f9a4 - once booted, "busybox devmem 0xfed03034 32 0x01e2c205¨ to disable SATA and dw DMA - echo freeze >/sys/power/state My bisect went wrong several times since I noticed late that S0ix sometimes can't be entered right after boot, but after up to 10 retries it suddenly works; once it worked, every suspend works. You can tell easily when it worked because the power LED turns off when S0i3 is entered, but it also shows in /sys/kernel/debug/pmc_atom/sleep_state. (If you're on some other CHT platform than E200HA, the devmen value above will likely not work for you; maybe you can figure it out from /sys/kernel/debug/pmc_atom/dev_state.) (In reply to Johannes Stezenbach from comment #102) > I bisected what blocks S0ix entry on v4.13 today, it is > caused by d31fd43c0f9a4 "clk: x86: Do not gate clocks enabled by the > firmware". > Reverting this on top of v4.13 makes S0ix work again on Asus E200HA. > > To be precise for those who want to reproduce: > - v4.13 > - merge sound/topic/dollar-cove-ti-4.13-v5 > - merge sound/topic/soc-cx2072x-4.13 > - apply "S0ix blocker debug patch v3" from above > - likely not needed for S0ix but I had 3 cleanup patches applied from > https://lkml.kernel.org/r/3958866.l2qnKDbinI@aspire.rjw.lan > - revert d31fd43c0f9a4 > - once booted, "busybox devmem 0xfed03034 32 0x01e2c205¨ > to disable SATA and dw DMA > - echo freeze >/sys/power/state > > My bisect went wrong several times since I noticed late that > S0ix sometimes can't be entered right after boot, but after > up to 10 retries it suddenly works; once it worked, every > suspend works. You can tell easily when it worked because > the power LED turns off when S0i3 is entered, but it also > shows in /sys/kernel/debug/pmc_atom/sleep_state. > > (If you're on some other CHT platform than E200HA, the > devmen value above will likely not work for you; maybe you can > figure it out from /sys/kernel/debug/pmc_atom/dev_state.) "ASoC: Intel: boards: use devm_clk_get() unconditionally" may be fix "clk: x86: Do not gate clocks enabled by the firmware"，https://github.com/plbossart/sound/commit/367d1c1391b6f9799971525c76c77078c6e19b11 how do i know my device devmem ? how to figure it ? android_x86:/ $ su android_x86:/ # cat sys/kernel/debug/pmc_atom/dev_state Dev: 0 - LPSS1_F0_DMA State: Enabled [D0] Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] Dev: 4 - LPSS1_F4_HSUART2 State: Enabled [D3] Dev: 5 - LPSS1_F5_SPI State: Disabled [D0] Dev: 6 - LPSS1_F6_Reserved State: Disabled [D0] Dev: 7 - LPSS1_F7_Reserved State: Disabled [D0] Dev: 8 - SCC_EMMC State: Disabled [D0] Dev: 9 - SCC_SDIO State: Enabled [D0] Dev: 10 - SCC_SDCARD State: Enabled [D0] Dev: 11 - SCC_MIPI State: Enabled [D3] Dev: 12 - HDA State: Disabled [D3] Dev: 13 - LPE State: Enabled [D0] Dev: 14 - OTG State: Disabled [D3] Dev: 15 - USH State: Enabled [D0] Dev: 16 - GBE State: Enabled [D0] Dev: 17 - SATA State: Enabled [D0] Dev: 18 - USB_EHCI State: Disabled [D0] Dev: 19 - SEC State: Enabled [D0] Dev: 20 - PCIE_PORT0 State: Enabled [D0] Dev: 21 - PCIE_PORT1 State: Enabled [D0] Dev: 22 - PCIE_PORT2 State: Enabled [D0] Dev: 23 - PCIE_PORT3 State: Enabled [D0] Dev: 24 - LPSS2_F0_DMA State: Enabled [D0] Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3] Dev: 28 - LPSS2_F3_I2C4 State: Enabled [D0] Dev: 29 - LPSS2_F5_I2C5 State: Enabled [D0] Dev: 30 - LPSS2_F6_I2C6 State: Disabled [D0] Dev: 31 - LPSS2_F7_I2C7 State: Disabled [D0] Dev: 32 - SMB State: Enabled [D0] Dev: 33 - OTG_SS_PHY State: Disabled [D0] Dev: 34 - USH_SS_PHY State: Enabled [D0] Dev: 35 - DFX State: Enabled [D0] android_x86:/ # (In reply to Johannes Stezenbach from comment #102) > I bisected what blocks S0ix entry on v4.13 today, it is > caused by d31fd43c0f9a4 "clk: x86: Do not gate clocks enabled by the > firmware". > Reverting this on top of v4.13 makes S0ix work again on Asus E200HA. Thanks Johannes, I confirmed that the revert worked. I updated topic/asus-e100h-4.13 branch containing the revert commit. Care to send a regression report about that commit? We'd need to either revert it or introduce a DMI white-list or black-list, I suppose. (In reply to Takashi Iwai from comment #104) > Care to send a regression report about that commit? > We'd need to either revert it or introduce a DMI white-list or black-list, I > suppose. I'm lame and didn't include you in Cc: for the query I sent here: https://marc.info/?l=linux-pm&m=150473056830789&w=2 Based on the replies I think the revert is not the solution, rather another hack to match the undocumented conditions required by the SoC to enter S0ix. Maybe we miss some call to make the BIOS disable some clocks, e.g. by putting some device in D3. Who knows... (In reply to youling257 from comment #103) > how do i know my device devmem ? how to figure it ? It is guessing and trial and error, based on hardware (e.g. lspci) and kernel config I know which hardware is used, and then I tried to disable stuff isn't used and which is flagged by "S0ix blocker debug patch v3". After a few hang-ups I found a combination that didn't hang up and allowed to enter S0i3. Probably just luck and other platforms can't work with these kind of hacks. did you read the “ASoC: Intel: boards: use devm_clk_get” ？only 5640/5645/5672 enabled MCLK，ask Pierre-Louis for the “clk: x86: Do not gate clocks”，may be he know more. (In reply to Takashi Iwai from comment #104) > (In reply to Johannes Stezenbach from comment #102) > > I bisected what blocks S0ix entry on v4.13 today, it is > > caused by d31fd43c0f9a4 "clk: x86: Do not gate clocks enabled by the > > firmware". > > Reverting this on top of v4.13 makes S0ix work again on Asus E200HA. > > Thanks Johannes, I confirmed that the revert worked. > I updated topic/asus-e100h-4.13 branch containing the revert commit. > > Care to send a regression report about that commit? > We'd need to either revert it or introduce a DMI white-list or black-list, I > suppose. FYI, I created bug #196861 on request by Rafael J. Wysocki to track the pm core issues related to S0ix. Hi Andy and Mika, the "E200HA S0ix fix: disable SATA" patch attached above works to enable S0ix, but I noticed in /sys/kernel/debug/pmc_atom/dev_state SATA is listed as "Disabled [D0]" and pss_state says the SATA power island is on. Could you share information how to really turn SATA off? Possibly we need to change PMC registers like the ones acpi_lpss.c uses to control DMA power? Thanks, Johannes (In reply to Johannes Stezenbach from comment #109) > Hi Andy and Mika, > > the "E200HA S0ix fix: disable SATA" patch attached > above works to enable S0ix, but I noticed in > /sys/kernel/debug/pmc_atom/dev_state SATA is > listed as "Disabled [D0]" and pss_state says > the SATA power island is on. > Could you share information how to really turn SATA off? > Possibly we need to change PMC registers like the > ones acpi_lpss.c uses to control DMA power? "Disabled" means the device in question is disabled by BIOS (for example, or fused out by other means if any, I dunno if there is actually any) you can't switch it's status anymore. It seems what I wrote wasn't clear. I mean: - BIOS keeps SATA enabled (although there is no SATA in lspci, seems to be BIOS bug) - SATA apparently prevents S0ix - setting SATA to "Disabled" in FUNC_DIS register enables S0ix (it's what my patch does) - power consumption in S0ix is still too high and I wonder if SATA is really properly disabled since the power island is still shown as "enabled" in pss_state Ah, so, you fused it. (Indeed, I agree that it looks like a BIOS bug) I don't know for sure, but my understanding is that when you fused device the status in PMC makes no sense anymore and just shows some default value which appears to be D0. These excerpts from internal documentation: "All function in D3 state is a precondition to S0iX state in CHV. Function should be considered as in D3 state if one of the following is true: 1. Function is statically disabled (fuse, soft-strap or function disable register) 2. Function is in RTD3hot state..." <-- Note "one of the following" and "1. ... function disable register)" "PMC has a configurable register enabling the deepest S0iX SoC could enter." <-- I dunno if Production Kernel Quilt has any disclosure of this one. Otherwise it would be interesting journey to get an approval. "PMC now supports dynamically power gating the SATA PGD1 via the interface signals." <-- This one hits when PMCSR (PCI PM command and status register) is written to D0/D3 respectively. The TI dollar cove PMIC patches are all upstream now, leaving only the S0ix issue which is being tracked separately in bug 196861. So I believe that this bug can be closed now -> closing. |
Created attachment 253921 [details] DSDT Asus E200HA (Atom x5-Z8300) uses the TI variant of the Dollar Cove PMIC (SND9039, ACPI ID INT33F5) which doesn't have a driver yet. 1. There seems to be no way to wake it up after "echo freeze >/sys/power/state", neither power button power button nor LID switch generate wakeup irqs. 2. Since Cherrytrail doesn't support ACPI S3 according to atom-z8000-datasheet-vol-1.pdf, support for S0ix states is needed. I'm attaching the DSDT for reference. acpidbg and sysfs confirm the TI DCove PMIC is used in E200HA: # cat /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/PNP0A08\:00/808622C1\:06/INT33F5\:00/status 15