Bug 193891 - TI Dollar Cove PMIC support for Cherrytrail platform
Summary: TI Dollar Cove PMIC support for Cherrytrail platform
Status: RESOLVED CODE_FIX
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64 (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Mika Westerberg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-03 12:41 UTC by Johannes Stezenbach
Modified: 2018-09-03 20:00 UTC (History)
10 users (show)

See Also:
Kernel Version: 4.10.0-rc6
Tree: Mainline
Regression: No


Attachments
DSDT (1.28 MB, text/x-dsl)
2017-02-03 12:41 UTC, Johannes Stezenbach
Details
mfd driver test patch (6.62 KB, patch)
2017-02-03 12:56 UTC, Johannes Stezenbach
Details | Diff
ACPI PMIC opregion test patch (6.80 KB, patch)
2017-02-03 12:59 UTC, Johannes Stezenbach
Details | Diff
kernel config (100.51 KB, text/plain)
2017-02-03 12:59 UTC, Johannes Stezenbach
Details
kernel config 4.10.0 + Takashi's patches (101.10 KB, text/plain)
2017-03-29 20:33 UTC, Johannes Stezenbach
Details
config-4.12.3+tiwai-asus-e100h (104.14 KB, text/plain)
2017-08-06 19:56 UTC, Johannes Stezenbach
Details
S0ix blocker debug patch (7.42 KB, application/mbox)
2017-08-06 19:57 UTC, Johannes Stezenbach
Details
E200HA S0ix fix: disable SATA (2.36 KB, patch)
2017-08-16 07:35 UTC, Johannes Stezenbach
Details | Diff
E200HA S0ix fix: don't let I2C7 block DMA suspend (1.41 KB, patch)
2017-08-16 07:36 UTC, Johannes Stezenbach
Details | Diff
acpi-lpss test debug hack to fix S0ix entry (2.69 KB, patch)
2017-08-16 07:37 UTC, Johannes Stezenbach
Details | Diff
"acpidump -o tables.dat", using latest BIOS version 303 (593.47 KB, application/octet-stream)
2017-08-17 09:18 UTC, Johannes Stezenbach
Details
output of grep -H 15 /sys/bus/acpi/devices/*/status (1.70 KB, text/plain)
2017-08-17 09:19 UTC, Johannes Stezenbach
Details
lspci -nk -vv -xx (11.63 KB, text/plain)
2017-08-17 09:19 UTC, Johannes Stezenbach
Details
updated kernel config for sound/topic/asus-e100h-4.13 (105.55 KB, text/plain)
2017-08-21 17:55 UTC, Johannes Stezenbach
Details
S0ix blocker debug patch v2 (7.67 KB, patch)
2017-08-22 19:25 UTC, Johannes Stezenbach
Details | Diff
S0ix blocker debug patch v3 (7.77 KB, patch)
2017-08-23 09:43 UTC, Johannes Stezenbach
Details | Diff

Description Johannes Stezenbach 2017-02-03 12:41:58 UTC
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
Comment 1 Johannes Stezenbach 2017-02-03 12:56:45 UTC
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
Comment 2 Johannes Stezenbach 2017-02-03 12:59:09 UTC
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
Comment 3 Johannes Stezenbach 2017-02-03 12:59:58 UTC
Created attachment 253951 [details]
kernel config
Comment 4 Johannes Stezenbach 2017-02-03 13:11:23 UTC
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.
Comment 5 Jonas Aaberg 2017-02-06 11:56:50 UTC
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.
Comment 6 Takashi Iwai 2017-02-23 11:34:17 UTC
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.
Comment 7 Takashi Iwai 2017-02-24 14:32:41 UTC
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).
Comment 8 Andy Shevchenko 2017-02-24 18:25:26 UTC
@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
Comment 9 Takashi Iwai 2017-02-24 18:49:48 UTC
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!
Comment 10 Andy Shevchenko 2017-02-24 20:43:45 UTC
Takashi, have a nice vacation and thanks for the patches. We will see what we can do in a dark Finnish office :-)
Comment 11 Jonas Aaberg 2017-02-25 13:13:37 UTC
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.)
Comment 12 Takashi Iwai 2017-02-25 15:31:38 UTC
(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.
Comment 13 Takashi Iwai 2017-02-25 23:12:30 UTC
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.
Comment 14 Jonas Aaberg 2017-02-26 12:04:11 UTC
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
--
Comment 15 Jonas Aaberg 2017-02-26 12:07:14 UTC
(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.
Comment 16 Takashi Iwai 2017-02-27 11:18:43 UTC
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.
Comment 17 Jonas Aaberg 2017-02-27 19:29:00 UTC
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..
Comment 18 Takashi Iwai 2017-02-27 20:39:09 UTC
(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.)
Comment 19 Takashi Iwai 2017-02-28 10:34:23 UTC
... or the latest topic/i2c-dw-cherrytrail branch.  It contains two more fixes.
Comment 20 Jonas Aaberg 2017-02-28 18:22:05 UTC
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.
Comment 21 Johannes Stezenbach 2017-03-01 19:08:29 UTC
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).
Comment 22 Mika Westerberg 2017-03-02 09:20:46 UTC
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.
Comment 23 Johannes Stezenbach 2017-03-27 11:10:03 UTC
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.
Comment 24 Mika Westerberg 2017-03-29 09:33:09 UTC
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.
Comment 25 Johannes Stezenbach 2017-03-29 10:42:39 UTC
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...
Comment 26 Mika Westerberg 2017-03-29 10:48:31 UTC
It chould be just a placeholder. The IP does not have a single GPIO according the datasheet.
Comment 27 Jonas Aaberg 2017-03-29 18:18:49 UTC
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?
Comment 28 Johannes Stezenbach 2017-03-29 20:30:20 UTC
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)...
Comment 29 Johannes Stezenbach 2017-03-29 20:33:30 UTC
Created attachment 255633 [details]
kernel config 4.10.0 + Takashi's patches
Comment 30 Takashi Iwai 2017-04-28 13:59:23 UTC
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.
Comment 31 Erik Veijola 2017-05-02 07:53:34 UTC
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.
Comment 32 Johannes Stezenbach 2017-05-08 09:24:52 UTC
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.
Comment 33 Andy Shevchenko 2017-05-08 09:42:45 UTC
(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)
Comment 34 Johannes Stezenbach 2017-05-08 10:12:55 UTC
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.
Comment 35 Mika Westerberg 2017-05-08 11:22:22 UTC
(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.
Comment 36 Johannes Stezenbach 2017-05-08 12:21:35 UTC
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?
Comment 37 Mika Westerberg 2017-05-08 13:16:20 UTC
(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.
Comment 38 Johannes Stezenbach 2017-05-08 13:55:52 UTC
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
Comment 39 Mika Westerberg 2017-05-08 14:07:06 UTC
(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 40 Johannes Stezenbach 2017-05-09 07:46:14 UTC
> --- 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
Comment 41 Mika Westerberg 2017-05-09 10:21:23 UTC
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).
Comment 42 Johannes Stezenbach 2017-05-09 15:14:48 UTC
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?
Comment 43 Andy Shevchenko 2017-05-09 15:30:34 UTC
(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
Comment 44 Johannes Stezenbach 2017-05-09 16:08:52 UTC
(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.
Comment 45 Dainius Masiliūnas 2017-06-06 11:12:05 UTC
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.
Comment 46 Takashi Iwai 2017-06-06 12:20:45 UTC
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.
Comment 47 Dainius Masiliūnas 2017-06-08 18:13:21 UTC
Ah, you're right, the volume buttons work when I enable SOC_BUTTON_ARRAY. Thanks!
Comment 48 Dainius Masiliūnas 2017-06-08 20:07:34 UTC
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 49 Johannes Stezenbach 2017-08-06 19:51:07 UTC
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 50 Johannes Stezenbach 2017-08-06 19:52:22 UTC
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
>
Comment 51 Johannes Stezenbach 2017-08-06 19:56:00 UTC
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
Comment 52 Johannes Stezenbach 2017-08-06 19:57:12 UTC
Created attachment 257837 [details]
S0ix blocker debug patch
Comment 53 Johannes Stezenbach 2017-08-06 20:27:04 UTC
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???)
Comment 54 Dainius Masiliūnas 2017-08-06 20:47:45 UTC
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.
Comment 55 Andy Shevchenko 2017-08-07 11:22:56 UTC
(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.
Comment 56 Johannes Stezenbach 2017-08-07 11:44:41 UTC
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?
Comment 57 Andy Shevchenko 2017-08-07 11:56:22 UTC
(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.
Comment 58 Johannes Stezenbach 2017-08-07 22:32:06 UTC
(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?
Comment 59 Johannes Stezenbach 2017-08-13 08:58:02 UTC
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?
Comment 60 Johannes Stezenbach 2017-08-16 07:35:16 UTC
Created attachment 257945 [details]
E200HA S0ix fix: disable SATA
Comment 61 Johannes Stezenbach 2017-08-16 07:36:15 UTC
Created attachment 257947 [details]
E200HA S0ix fix: don't let I2C7 block DMA suspend
Comment 62 Johannes Stezenbach 2017-08-16 07:37:18 UTC
Created attachment 257949 [details]
acpi-lpss test debug hack to fix S0ix entry
Comment 63 Johannes Stezenbach 2017-08-16 07:52:11 UTC
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?
Comment 64 Andy Shevchenko 2017-08-16 18:03:09 UTC
Looks interesting...

Can you by the way instead of first patch try to enable runtime PM for SATA?
Comment 65 Johannes Stezenbach 2017-08-17 08:17:50 UTC
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.
Comment 66 Andy Shevchenko 2017-08-17 08:49:11 UTC
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
?
Comment 67 Johannes Stezenbach 2017-08-17 09:18:41 UTC
Created attachment 257981 [details]
"acpidump -o tables.dat", using latest BIOS version 303
Comment 68 Johannes Stezenbach 2017-08-17 09:19:27 UTC
Created attachment 257983 [details]
output of grep -H 15 /sys/bus/acpi/devices/*/status
Comment 69 Johannes Stezenbach 2017-08-17 09:19:52 UTC
Created attachment 257985 [details]
lspci -nk -vv -xx
Comment 70 Takashi Iwai 2017-08-20 08:06:31 UTC
(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!
Comment 71 Dainius Masiliūnas 2017-08-20 08:19:45 UTC
Is the ACPI device enumeration patch from bug #195689 included in the new branch?
Comment 72 Takashi Iwai 2017-08-20 15:08:27 UTC
(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.
Comment 73 Mika Westerberg 2017-08-21 09:03:03 UTC
Takashi, I checked the patches in your branch and they look good to me. Thanks for taking care of this!
Comment 74 Takashi Iwai 2017-08-21 12:46:52 UTC
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.
Comment 75 Johannes Stezenbach 2017-08-21 17:53:03 UTC
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.
Comment 76 Johannes Stezenbach 2017-08-21 17:55:37 UTC
Created attachment 258039 [details]
updated kernel config for sound/topic/asus-e100h-4.13
Comment 77 Johannes Stezenbach 2017-08-21 20:00:10 UTC
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.
Comment 78 Takashi Iwai 2017-08-21 20:58:22 UTC
(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.
Comment 79 Johannes Stezenbach 2017-08-21 21:04:39 UTC
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.
Comment 80 Takashi Iwai 2017-08-21 21:07:50 UTC
OK, then I'm going to submit the patches to upstream tomorrow.  Let's see how things will go.
Comment 81 Johannes Stezenbach 2017-08-21 22:00:47 UTC
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.
Comment 82 Johannes Stezenbach 2017-08-22 19:25:09 UTC
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)
Comment 83 Johannes Stezenbach 2017-08-23 09:43:07 UTC
Created attachment 258059 [details]
S0ix blocker debug patch v3

v3: fix v2, kbuild test robot mercilessly uncovers sloppy coding
Comment 84 youling257 2017-08-28 09:52:40 UTC
(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.
Comment 85 youling257 2017-08-28 10:20:58 UTC
(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.
Comment 86 youling257 2017-08-28 10:42:02 UTC
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]
Comment 87 youling257 2017-08-28 10:58:42 UTC
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]
Comment 88 youling257 2017-08-28 11:11:37 UTC
(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
Comment 89 youling257 2017-08-28 11:16:26 UTC
(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.
Comment 90 youling257 2017-08-28 11:33:11 UTC
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.
Comment 91 Hans de Goede 2017-08-28 16:54:20 UTC
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 ?
Comment 92 Dainius Masiliūnas 2017-08-28 18:57:42 UTC
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...
Comment 93 Johannes Stezenbach 2017-08-28 19:56:33 UTC
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.
Comment 94 youling257 2017-08-28 23:31:33 UTC
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) ?
Comment 95 youling257 2017-08-28 23:40:08 UTC
(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 ?
Comment 96 youling257 2017-08-29 06:48:55 UTC
(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 .
Comment 97 youling257 2017-08-29 07:11:09 UTC
(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
Comment 98 Johannes Stezenbach 2017-08-29 07:16:36 UTC
> 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.
Comment 99 Hans de Goede 2017-08-29 09:35:24 UTC
(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.
Comment 100 Johannes Stezenbach 2017-08-29 10:01:54 UTC
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.
Comment 101 Dainius Masiliūnas 2017-08-29 22:39:00 UTC
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.
Comment 102 Johannes Stezenbach 2017-09-06 20:22:44 UTC
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.)
Comment 103 youling257 2017-09-06 22:53:47 UTC
(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:/ #
Comment 104 Takashi Iwai 2017-09-07 13:58:05 UTC
(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.
Comment 105 Johannes Stezenbach 2017-09-07 14:20:19 UTC
(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...
Comment 106 Johannes Stezenbach 2017-09-07 14:27:19 UTC
(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.
Comment 107 youling257 2017-09-07 14:56:30 UTC
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.
Comment 108 Johannes Stezenbach 2017-09-07 22:18:55 UTC
FYI, I created bug #196861 on request by Rafael J. Wysocki
to track the pm core issues related to S0ix.
Comment 109 Johannes Stezenbach 2017-09-22 21:23:04 UTC
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
Comment 110 Andy Shevchenko 2017-11-21 17:33:28 UTC
(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.
Comment 111 Johannes Stezenbach 2017-11-21 19:43:04 UTC
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
Comment 112 Andy Shevchenko 2017-11-21 19:49:25 UTC
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.
Comment 113 Andy Shevchenko 2017-11-21 20:11:07 UTC
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.
Comment 114 Hans de Goede 2018-09-03 20:00:35 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.