Created attachment 273951 [details] dmesg after suspending (kernel compiled with acpi debug features enabled) With kernel releases candidates around v4.14-rc7 there was a brief period the kernel allowed my Asus X205TA to reach S0I3 suspend state (with power led off) as it does under windows, this state is very power efficient. In later releases of v4.14 I needed to revert a commit by Rafael J. Wysocki <rafael.j.wysocki@intel.com> (specifically the runtime.c hunk): https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20180129&id=d5919dcc349d2a16d805ef8096d36e4f519e42ae To achieve the same results. Since v4.15 I am not able to revert this hunk anymore (because then i2c_designware_core will break on hibernation). The laptop will now only suspend with the led light on (and /sys/kernel/debug/pmc_atom/sleep_state shows the laptop resides only in S0 state instead of S0I3). From the commits that followed later on that seem to block the X205TA from reaching S0I3 state I gather (I am not a coder) that the 4.14 release candidates that worked for me put devices to S0I3 state unconditionally (which I assume breaks stuff on some other devices). I also gather that now that certain runtime conditions need to be met to be able to enter S0I3 sleep state, the X205TA somehow does not meet those conditions. I have been unable to find out which runtime conditions don't allow the laptop to enter S0I3 state. I am not really sure which information I should provide here, I attached a dmesg output after suspend (with acpi debug features enabled in the kernel). If any more information is necessary, please let me know and I'll supply them.
I found some more bug threads pertaining this issue. https://bugzilla.kernel.org/show_bug.cgi?id=196861 https://bugzilla.kernel.org/show_bug.cgi?id=196915 As Zhang Rui stated that S0ix support has platform specific dependencies. I'll provide some more info about the device (as others have done for their devices in the above listed bugthreads.)
Created attachment 274041 [details] acpidump
Created attachment 274043 [details] dsdt.dsl
Created attachment 274045 [details] lspci -v
Created attachment 274047 [details] pcm_atom_states cat /sys/kernel/debug/pmc_atom/{sleep,dev,pss}_state
(In reply to harryharryharry from comment #0) > Created attachment 273951 [details] > dmesg after suspending (kernel compiled with acpi debug features enabled) > > With kernel releases candidates around v4.14-rc7 there was a brief period > the kernel allowed my Asus X205TA to reach S0I3 > suspend state (with power led off) as it does under windows, this state is > very power efficient. In later releases of v4.14 I > needed to revert a commit by Rafael J. Wysocki <rafael.j.wysocki@intel.com> > (specifically the runtime.c hunk): > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/ > ?h=next-20180129&id=d5919dcc349d2a16d805ef8096d36e4f519e42ae > To achieve the same results. May I know how did you figure out the first bad commit? Just curious on how to debug such kind of s0ix residency issues..
Sorry not much I can help you with as I'm struggling with debugging this issue myself. Finding the commit was a combination of perseverance and dumb luck :) I'm testing out each new rc so I had it narrowed down to the commits in one rc already. After that it was lots of trying reverse patching the commits I thought could be the cause...
@Chen Yu I see you changed the status to NEEDINFO. Which info is needed and (how) can I supply it ?
Please attach the output of "cat /proc/cpuinfo"
Created attachment 275737 [details] cpuinfo - asus x205ta
I think I found something that might help debug this issue: when I do: echo 0x00800000 > /sys/module/acpi/parameters/debug_layer Dmesg shows a device called SDHA is constantly being switched from D3hot to D0 and back. I have a hacky patched kernel that basically reverts a bunch of commits to v4.14-rc7 state - which still allows s0i3 state - and this patched kernel does not exhibit this behaviour (the SDHA device goes to and stays in D3hot when suspending.) I'll add the 2 dmesgs from patched and unpatched kernel below.
Created attachment 277671 [details] dmesg debug 4.18.0-rc7 patched kernel
Created attachment 277673 [details] dmesg debug 4.18.0-rc7 unpatched kernel
my tablet is BYTCR z3735f， unbelievable ! cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 1568us S0I1 Residency: 1792us S0I2 Residency: 30144us S0I3 Residency: 3903136us S0 Residency: 1043594112us seem because https://github.com/torvalds/linux/commit/12864ff8545f6b8144fdf1bb89b5663357f29ec4 but resume failed，auto reboot， mmc1: error -110 doing runtime resume [cut here] bdi-block not register call trace: _set_page_dirty this is other one problem mmc not support s0i3 on BYTCR.
Excellent find, thanks for sharing! I just tested a 4.18.0-rc7 kernel with only that commit applied, and it enables s0i3 suspend for me again. Suspending and even hibernating (which previously resulted in keyboard/touchpad issues) also work reasonably fine now! (sound doesn't work after hibernation, powerbutton doesn't work after suspending. But I think I better make separate bug reports for those.)
I tested Linux 4.18rc8 which include mentioned commit and find that at least on HP Stream 7 Tablet there is no mentioned mmc. I doesn't get S0i3 residency - S0i1 at most. However, instead of mmc issue on this tablet after wakeup axp288 driver stop reporting battery level and stop react on power button.
(In reply to RussianNeuroMancer from comment #16) > I tested Linux 4.18rc8 which include mentioned commit and find that at least > on HP Stream 7 Tablet there is no mentioned mmc. I doesn't get S0i3 > residency - S0i1 at most. However, instead of mmc issue on this tablet after > wakeup axp288 driver stop reporting battery level and stop react on power > button. the different of /sys/kernel/debug/pmc_atom/dev_state is only DMA can entry D3 , diff before and now dev_state . @@ -1,4 +1,4 @@ -Dev: 0 - LPSS1_F0_DMA State: Enabled [D0] +Dev: 0 - LPSS1_F0_DMA State: Enabled [D3] Dev: 1 - LPSS1_F1_PWM1 State: Enabled [D0] Dev: 2 - LPSS1_F2_PWM2 State: Disabled [D3] Dev: 3 - LPSS1_F3_HSUART1 State: Enabled [D0] @@ -22,7 +22,7 @@ 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: 24 - LPSS2_F0_DMA State: Enabled [D3] Dev: 25 - LPSS2_F1_I2C1 State: Enabled [D3] Dev: 26 - LPSS2_F2_I2C2 State: Enabled [D3] Dev: 27 - LPSS2_F3_I2C3 State: Enabled [D3]
Same on HP Stream 7, both of LPSS1_F0_DMA and LPSS2_F0_DMA in Enabled state now. Also: Dev: 8 - SCC_EMMC State: Disabled [D0] Dev: 9 - SCC_SDIO State: Enabled [D3] Dev: 10 - SCC_SDCARD State: Enabled [D0] Dev: 11 - SCC_MIPI State: Enabled [D3] It is same on your tablet?
(In reply to RussianNeuroMancer from comment #18) > Same on HP Stream 7, both of LPSS1_F0_DMA and LPSS2_F0_DMA in Enabled state > now. Also: > Dev: 8 - SCC_EMMC State: Disabled [D0] > Dev: 9 - SCC_SDIO State: Enabled [D3] > Dev: 10 - SCC_SDCARD State: Enabled [D0] > Dev: 11 - SCC_MIPI State: Enabled [D3] > It is same on your tablet? scc_emmc、sdio、sdcard all same，bios may be same . bios has scc emmc 4.5 enable，if disable scc sdio and sdcard，then boot userspace，only has mmc0 for emmc 4.5，no 8723bs and sdcard，mmc0 also will resume failed. bios has scc emmc 4.5 enable，but dev_state scc_emmc disabled. if you change lpss&scc to pci mode，can you boot ?
4.14.61 kernel just need drivers/base/power/runtime.c - else if (__dev_pm_qos_read_value(dev) < 0) + else if (__dev_pm_qos_read_value(dev) == 0) can make F0_DMA entry d3，sleep_state ca reach s0i3，but has more resume problem for my tablet. as he said "Some drivers may not support it"，https://github.com/torvalds/linux/commit/d5919dcc349d2a16d805ef8096d36e4f519e42ae 4.14 rc8 d5919dcc349d2a16d805ef8096d36e4f519e42ae is correct， 4.14 rc7 0cc2b4e only because "== 0" make reach s0i3，but has some resume problem. so has 4.15 rc1 0759e80b84e34a84e7e46e2b1adb528c83d84a47，but this "== 0" not make reach s0i3，until 4.18rc8 kernel，it can rework for s0i3， still has some resume problem about pm_qos value is 0 .
> if you change lpss&scc to pci mode，can you boot ? This settings is not available in HP Stream 7 Tablet BIOS.
Hi All, I've been working on fixing S0ix support for most Bay and Cherry Trail devices recently. For me it works on all devices I've tested using 4.18.x + the following patches: 1) A fix for the i2c controller connected to the PMIC no longer working after suspend/resume: https://github.com/jwrdegoede/linux-sunxi/commit/49ae76ac49f104fd06a96b7e41c5c02991a33684 2) A set of fixes to make sure the PMC clocks are disabled during boot https://github.com/jwrdegoede/linux-sunxi/commit/21727f53891a3b7162474680a3ad7725a1b19308 https://github.com/jwrdegoede/linux-sunxi/commit/1c0f485edb8bdc0def5ba4aebe394bf11e207d16 https://github.com/jwrdegoede/linux-sunxi/commit/a2290d4ab214753162f3d89d4e72921ca22f46ad 3) Make sure the 2nd pwm controller on Cherry Trail gets a driver attached and thus gets properly suspended: https://github.com/jwrdegoede/linux-sunxi/commit/2870b0d7537d7c2d1f2724e4171ca47fe1aaa7b9 4) A dummy driver for the Cherry Trail ISP processor (builtin camera sensor interface), so that the ISP properly gets suspended / put in D3. https://github.com/jwrdegoede/linux-sunxi/commit/548d9dba657947708a887ba3b41b5a9b74343a04 3 and 4 only apply to Cherry Trail devices (such as the Asus E200HA this bug was originally opened for). harryharryharry, please try a 4.18.x kernel with the above patches added and let me know here in bugzilla if that makes the laptop properly enter/use S0ix modes. Other people following this bug, also please try a 4.18.x kernel with the above patches, if you still do not get S0ix mode an a Bay or Cherry Trail based device , please open a *new* bug for that and let me know about it. Regards, Hans
Hi Hans, thanks for your work! Although my device already suspends to s0i3 again since 4.18.0-rc7 (see comment #15), if needed I'll gladly test your patches. Silly question: what's the easiest way to apply the commits on github you linked to, to say, a 4.18.5 tarball ? (I can't seem to find a 'raw patch' type download on github) Off topic: I've recently tested this patch: [PATCH v2] brcmfmac: Add support for getting nvram contents from EFI variables https://www.spinics.net/lists/linux-wireless/msg171359.html which works beautifully on 4.16.x, but I can't apply it anymore to subsequent kernels. I this patch being merged to the mainline kernel soon? (or is there some way to apply it to newer kernels?)
Hi, (In reply to harryharryharry from comment #23) > Hi Hans, thanks for your work! > Although my device already suspends to s0i3 again since 4.18.0-rc7 (see > comment #15) Right, but with regressions to the power-button after suspend-resume, my patches (first one specifically) should fix that. > if needed I'll gladly test your patches. It would be good to get confirmation that my patches fix the regressions you are seeing with 4.18.0-rc7, while still allowing s0i3. > Silly question: > what's the easiest way to apply the commits on github you linked to, to say, > a 4.18.5 tarball ? (I can't seem to find a 'raw patch' type download on > github) Add .patch at the end of URLs to get files which you can git am, e.g. : https://github.com/jwrdegoede/linux-sunxi/commit/49ae76ac49f104fd06a96b7e41c5c02991a33684.patch > Off topic: I've recently tested this patch: > [PATCH v2] brcmfmac: Add support for getting nvram contents from EFI > variables > https://www.spinics.net/lists/linux-wireless/msg171359.html > which works beautifully on 4.16.x, but I can't apply it anymore to > subsequent kernels. I this patch being merged to the mainline kernel soon? > (or is there some way to apply it to newer kernels?) I need to respin that patch, splitting out the somewhat controversial world domain mangling bits into a separate patch in the mean time you can find a rebased version here: https://github.com/jwrdegoede/linux-sunxi/tree/v4.18-footrail And specifically this commit (for 4.18) : https://github.com/jwrdegoede/linux-sunxi/commit/9cfa9a18ca200b7827da09460fb161010bb2a4c74.patch Regards, Hans
S0i3 works now on HP Stream 7 Tablet: ~# cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 171136us S0I1 Residency: 1184us S0I2 Residency: 15904us S0I3 Residency: 599030240us S0 Residency: 144164480us Thanks you! :)
Thanks for the neat url+.patch trick :) All s0ix modes also work for me with the patches and the power button still works after suspend and/or hibernate. (I had to change the 'dummy driver' patch a little because the Makefile hunk wouldn't apply properly, due to the CONFIG_I2C_MULTI_INSTANTIATE line missing in the original Makefile). Now the only thing not working after hibernate is audio. Gr Harry ps: Also, thank you for the tip about the brcmfmac patch, that patch does the trick again on 4.18.
Hmmm, I just built 4.19-rc3 and the s0i3 state is not available again. I've looked at the diff between rc2 (with which s0i3 is working) and rc3, and it appears to be the following commit: ACPI / LPSS: Force LPSS quirks on boot (Zhang Rui) https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.19-rc3&id=f11fc4bc669b8622510c1039499f5a9d24248fec If I compile rc3 with this commit reverted, s0i3 is enabled again.
(In reply to harryharryharry from comment #27) > Hmmm, I just built 4.19-rc3 and the s0i3 state is not available again. I've > looked at the diff between rc2 (with which s0i3 is working) and rc3, and it > appears to be the following commit: > ACPI / LPSS: Force LPSS quirks on boot (Zhang Rui) > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?h=v4.19-rc3&id=f11fc4bc669b8622510c1039499f5a9d24248fec > > If I compile rc3 with this commit reverted, s0i3 is enabled again. Yes, this is caused by the fix for bug 200989 and is being discussed there. Instead of reverting that commit, can you try adding these 2 patches instead? : https://github.com/jwrdegoede/linux-sunxi/commit/06c152e724237bad7f31df7da554ae1ab27454a9.patch https://github.com/jwrdegoede/linux-sunxi/commit/fec7df233c9e9668d95c6d5756f7ceb5be0239fe.patch I expect those will fix this again for you, these are queued up for merging into 4.20. If those 2 do not fix things also try adding: https://github.com/jwrdegoede/linux-sunxi/commit/29b8592d679bd1a086dd88b8273c40c8ace37ca6.patch That is likely how we will end up fixing this, so getting confirmed that this fixes it for you would be good.
Thanks for the fast reply! I 'reapplied' the commit from comment #27 and applied the first 2 commits you linked to, and the s0i3 state could not yet be reached after recompiling. With the third patch also applied, the s0i3 state can be reached again.
Hi, (In reply to harryharryharry from comment #29) > Thanks for the fast reply! Thank you for the quick testing. > I 'reapplied' the commit from comment #27 and applied the first 2 commits > you linked to, and the s0i3 state could not yet be reached after recompiling. > > With the third patch also applied, the s0i3 state can be reached again. OK, that means that the X205TA has a PMIC where the I2C to the PMIC is shared between the OS (the Linux kernel) and the PUNIT inside the SoC. I've several of those devices myself so although it is not yet entirely sure how we will resolve this, I'm sure that we will fix this somehow. ATM it seems likely this will be done through the 3th patch which you added. Regards, Hans
Thanks for the explanation and good luck with the puzzle!
Quick status update, it looks like we will indeed go with the 3th patch you added as fix for this.
I'm not see it improve battery life,suspend one hour,usage 8%,suspend 4 hours,usage 30%. battery 5000mah，every hour discharge 400mah，Discharge at 400 Ma per second. cat /sys/kernel/debug/pmc_atom/sleep_state S0IR Residency: 9664us S0I1 Residency: 29216us S0I2 Residency: 5898983424us S0I3 Residency: 11603320512us S0 Residency: 6721288608us
(In reply to Hans de Goede from comment #28) > (In reply to harryharryharry from comment #27) > > Hmmm, I just built 4.19-rc3 and the s0i3 state is not available again. I've > > looked at the diff between rc2 (with which s0i3 is working) and rc3, and it > > appears to be the following commit: > > ACPI / LPSS: Force LPSS quirks on boot (Zhang Rui) > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > > ?h=v4.19-rc3&id=f11fc4bc669b8622510c1039499f5a9d24248fec > > > > If I compile rc3 with this commit reverted, s0i3 is enabled again. > > Yes, this is caused by the fix for bug 200989 and is being discussed there. > > Instead of reverting that commit, can you try adding these 2 patches > instead? : > > https://github.com/jwrdegoede/linux-sunxi/commit/ > 06c152e724237bad7f31df7da554ae1ab27454a9.patch > https://github.com/jwrdegoede/linux-sunxi/commit/ > fec7df233c9e9668d95c6d5756f7ceb5be0239fe.patch > > I expect those will fix this again for you, these are queued up for merging > into 4.20. > > If those 2 do not fix things also try adding: > > https://github.com/jwrdegoede/linux-sunxi/commit/ > 29b8592d679bd1a086dd88b8273c40c8ace37ca6.patch > > That is likely how we will end up fixing this, so getting confirmed that > this fixes it for you would be good. Hi there, I currently have a device running k4.18.14 and am also having issues with s0ix states not working, and have applied all of your earlier patches and would like to give these three a try, but the links are all 404 :( Can I kindly request these from you if they are still available somewhere? Thx!
(In reply to ouija from comment #34) > Hi there, > > I currently have a device running k4.18.14 and am also having issues with > s0ix states not working, and have applied all of your earlier patches and > would like to give these three a try, but the links are all 404 :( > > Can I kindly request these from you if they are still available somewhere? > Thx! 4.18.14 is really old. Can you please try with a new kernel like 5.9 ? Even if you want to stay with an older distro, most distro's have a mainline-kernel repository available to switch to a new kernel and the kernel has excellent backward compatibility, so old code should run fine even with older userspace. Alternatively, try dd-ing the Fedora 33 workstation livecd iso to an USB stick and booting that and doing suspend/resume from the live environment. The Fedora 33 workstation livecd is the default download at: https://getfedora.org/
My main issue with running 4.18.4 is due to this bytcr5651 device not working properly due to ext-amp GPIO missing. In 4.18.14, I've resorted to using a patch that enabled the missing pin (https://github.com/ouija/android-x86_insignia_flex8/blob/master/Android-x86-8.1r5/00%20%20Patches/INSIGNIA-0007---AUDIO-FIX---ouija-k418-rt5651-add-speaker-amp-GPIO.diff) which I created based off another user with similar issues, but this same patch has no effect in later kernels and after trying multiple other patches to try and enable support, I've failed miserably.
Hi, (In reply to ouija from comment #36) > My main issue with running 4.18.4 is due to this bytcr5651 device not > working properly due to ext-amp GPIO missing. In 4.18.14, I've resorted to > using a patch that enabled the missing pin > (https://github.com/ouija/android-x86_insignia_flex8/blob/master/Android-x86- > 8.1r5/00%20%20Patches/INSIGNIA-0007---AUDIO-FIX---ouija-k418-rt5651-add- > speaker-amp-GPIO.diff) which I created based off another user with similar > issues, but this same patch has no effect in later kernels and after trying > multiple other patches to try and enable support, I've failed miserably. Recent kernels automatically use the speaker-enable GPIO on all CherryTrail based boards with a rt5651 codec, this is now handled inside: sound/soc/intel/boards/bytcr_rt5651.c The easiest way to try this might be to boot a Fedora 33 livecd from an USB stick as mentioned before, I would expect sound to just work there. If it does not work, you could try building your own more recent kernel and changing this line in sound/soc/intel/boards/bytcr_rt5651.c : static const struct acpi_gpio_params ext_amp_enable_gpios = { 0, 0, false }; To: static const struct acpi_gpio_params ext_amp_enable_gpios = { 1, 0, false }; If that is necessary, take a look at the special handling of the Point of View p1006w (search for p1006w in the file) for how to add a DMI string based quirk which uses a non-default GPIO mapping. Also if you can attach an acpidump of your device here that would be great.
I have two different models of Cherrytrail Windows tablets, a Toshiba WT8-B and this rather tempermental Insignia Flex 8 [NS-P08W7100] tablet, which is the one giving me the most grief. Because this Insignia Flex 8 [NS-P08W7100] tablet does a terrible job at running Windows, I'm trying to create a custom build of Android-x86 on it, however, the latest kernel I can build for it is 5.8 (as 5.9 was giving me a compiler out of date error, and I tried updated my local gcc version but that made no difference, and I *think* it's the gcc version in the toolchain for Android that needs to be updated to work with compiling that kernel?) I'm still figuring my way around here :) The kernel source is from Mauro's source here: https://github.com/maurossi/linux What you've shared here regarding the > static const struct acpi_gpio_params ext_amp_enable_gpios = { 1, 0, false }; looks like it's exactly what I need -- this is very similar to the patch that I have which enables the bytcr_rt565 in kernel 4.18, where the GPIO needs to be hi vs lo (which I believe is what the difference there is) I'm attemping another build from scratch with k5.8 and will see if changing that value indicated helps the GPIO and speaker-amp become attached and enables the device, which wasn't working when I last tried running k5.8 and gave up on it. I just booted Fedora 33 and sound is indeed working right out of the gate, even with headphone input detection. Here's the acpidump from Fedora: https://file.io/8PYgTRiouwJu And here's a decompiled DSDT: https://file.io/OVgCwSJmdlku
(In reply to ouija from comment #38) > I just booted Fedora 33 and sound is indeed working right out of the gate, > even with headphone input detection. Good so in that case you don't need to make any chances to the GPIO-lookup when building your own kernel as it is already working with the defaults. The reason why the new upstream code uses: static const struct acpi_gpio_params ext_amp_enable_gpios = { 0, 0, false }; Where as the patch you were using uses something similar to: static const struct acpi_gpio_params ext_amp_enable_gpios = { 1, 0, false }; Is because the upstream code is using this in this way: static const struct acpi_gpio_mapping cht_rt5651_gpios[] = { /* * Some boards have I2cSerialBusV2, GpioIo, GpioInt as ACPI resources, * other boards may have I2cSerialBusV2, GpioInt, GpioIo instead. * We want the GpioIo one for the ext-amp-enable-gpio. */ { "ext-amp-enable-gpios", &ext_amp_enable_gpios, 1, ACPI_GPIO_QUIRK_ONLY_GPIOIO }, { }, }; Note the ACPI_GPIO_QUIRK_ONLY_GPIOIO flag, this causes the GpioInt entry in the resource table to be skipped so that we always get the first actually GPIO and not the interrupt line. So AFAICT with recent upstream kernels sounds just works for you (as shown with the Fedora 33 live). So that should no longer be a reason to stick with an older kernel. ### Did you test suspend/resume with Fedora 33 live and then do: sudo sh -c 'cat /sys/kernel/debug/pmc_atom/sleep_state' To check S0ix support there? ### BTW have you tried using the kernel the upstream AndroidX86 ships ? That one might be slightly older but the spk-amp-enable GPIO support has been in place for a while now. > Here's the acpidump from Fedora: https://file.io/8PYgTRiouwJu Thank you.
With out without changing that line: > static const struct acpi_gpio_params ext_amp_enable_gpios = { 1, 0, false }; there is NO speaker-amp GPIO being detected with this 5.8 kernel in Android-x86: gpiochip4: GPIOs 225-227, parent: platform/INT0002:00, INT0002 Virtual GPIO: gpio-227 ( |ACPI:Event ) in lo IRQ gpiochip3: GPIOs 228-313, parent: platform/INT33FF:03, INT33FF:03: gpio-274 ( |ACPI:OpRegion ) out lo gpio-309 ( |80860F14:03 ) in hi IRQ ACTIVE LOW gpiochip2: GPIOs 314-340, parent: platform/INT33FF:02, INT33FF:02: gpio-322 ( |power ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 341-413, parent: platform/INT33FF:01, INT33FF:01: gpio-344 ( |ACPI:Event ) in hi IRQ gpio-345 ( |device-wake ) out hi gpio-366 ( |ACPI:OpRegion ) out lo gpio-393 ( |ACPI:OpRegion ) out hi gpiochip0: GPIOs 414-511, parent: platform/INT33FF:00, INT33FF:00: gpio-492 ( |volume_up ) in hi IRQ ACTIVE LOW gpio-494 ( |volume_down ) in hi IRQ ACTIVE LOW gpio-504 ( |enable ) out hi I just don't understand it. I've tried this a million times, and it honestly only ever works in k4.18 using a similar patch. s0ix isn't working in 5.8 either on this unit: S0IR Residency: 0us S0I1 Residency: 0us S0I2 Residency: 0us S0I3 Residency: 0us S0 Residency: 456817440us And it won't resume from suspend with 5.8, but did previously (I have acpi_backlight=vendor enabled or it will have issues in the older kernel)
Sorry that is supposed to be written "with OR without changing that line, there is no GPIO for speaker-amp being created"
It won't reboot either apparently with 5.8 :(
I assume all this won't work is with your own kernel build from: https://github.com/maurossi/linux I took a quick peek there and that is a real frankenstein kernel. It is also missing a lot of things which are actually in 5.8 upstream, so not sure if it is really based on 5.8 upstream. So 2 things: 1. Please try reproducing your problems in the Fedora live environment, if they do not happen there then it is an issue with the android kernels you are building not with the mainline kernel. 2. Maybe try building an android kernel based on: https://git.osdn.net/view?p=android-x86/kernel.git From the 5.4 branch, I checked and the 5.4 branch does have the speaker-amp-enable gpio bits. This is the kernel tree from the official androidx86 project. I also wonder what you results are when simply using androidx86 with the kernel with which it ships ? Alternatively you could try building from the latest aosp kernel sources: https://github.com/aosp-mirror/kernel_common/ and then use the mainline-tracking branch
Cool! Thank you for the tips, much appreciated. I will try re-building from the 5.4 source and see how that fairs. Fedora 33 is actually one of the first livecds I've used with this device where the majority of the hardware works out of the box. When using the Kernel that Android-x86 (8.1r5) come with (4.19.122), the same issue with the GPIO pin for the speaker-amp not existing occurs. I'll post back here with my results using 5.4 shortly - Let me know if we should move this to a different topic too since this isn't exactly related to s0ix issues (but may eventually come that way, once I find a more modern kernel that works with this GPIO issue!) Thanks again
OK, so k5.4 from Android-x86 source still has issues with the missing GPIO for the speaker-amp, going to try a rebuild with that single-line patch here shortly. I am also having reboot issues with this (and other kernels) where it freezes when rebooting (have to hard-reset by holding power button down); k4.18 didn't have this issue. I've tried using various kernel arguments like acpi=forece reboot=acpi, etc. but nothing seems to help.
Noticed also if I run the "reboot" command from an ALT-F1 terminal, the screen will dim so that you can bareley read the text but it's still visible, so it's like its stuck or something. When not in terminal, the display goes blank, but you can still swap between this and the barely visible terminal (but no keyboard input works on the command line, if that makes sense)...
Just wanted to update with a finding of mine regarding the *other model* I am working on (Toshiba WT8-B) which is running that k5.8: In order to achieve s0ix in Android-x86 8.1r5, I had to add the following properties: >set_property power.nonboot-cpu-off 0 >set_property sleep.state force Which I originally came across a few weeks ago at https://groups.google.com/g/android-x86/c/UJUk0rDbxds/m/5ZFNDaexBAAJ Just wanted to make note of this on here for now. I've somewhat given up hope again on running anything other than k4.18 on this Insignia tablet due to this wonky GPIO issue, and I'm going to attempt another go at it with this knowledge about enabling s0ix when I do, because if I can get that working under 4.18, I'm happy with it for now.
Went back to using 4.18 on this tempermental unit, but still unable to get proper s0ix states using the patches above or using the additional ones here: https://bugzilla.kernel.org/show_bug.cgi?id=196915#c11 >S0IR Residency: 0us >S0I1 Residency: 0us >S0I2 Residency: 0us >S0I3 Residency: 0us >S0 Residency: 40347628384us I've also tried with later kernels such as 4.19, 5.4 and 5.8 and same thing. Tried also reverting some of the patches indicated instead, but no difference. Double checked bios, s0ix is indeed enabled, so not sure why it doesn't quite work. I just know this tablet is a cheap POS haha.