11-09-2019, 12:03 PM
A true mainline Linux Kernel for the Pinebook Pro
|
11-09-2019, 12:57 PM
(11-09-2019, 12:03 PM)hmuller Wrote:(11-09-2019, 11:47 AM)tsys Wrote: Just installed the M.2 adapter (after some mechanical optimization) and PCIe works with PCIe 2.0 speed and full 4 lanes. Yep. That's why I cut away about a third of the adapter so is does not longer interfere with the tochpad. I'll of course install the revised adapter since the NVMe SSD is now mounted using tape rather than the proper screw.
11-09-2019, 02:28 PM
Full system powerdown is now working, too. Previously the device would hang in a state where the power led and most voltage rails were still on when shut down.
11-09-2019, 04:22 PM
Awesome! Looks like a very busy day on your side.
BTW you mentioned some issues with the WiFi and I'm certainly seeing very lumpy packet reception (even simple ping test are asymmetric with pings from the PBP working normally but pings to he PBP can take up to 1500ms to reply). Is that the same issue you were worried about? For me that definitely comes and goes with dynamic changes to WiFi power management. (11-09-2019, 04:22 PM)danielt Wrote: Awesome! Looks like a very busy day on your side. No. Unfortunately it is a crash of the firmware in the ap6255 wifi module. However, I've found another firmware binary in my firmware collection that seems to work a lot more stable. Haven't seen it crash in the past 5 hours or so. I'll keep it running over night and see if it is indeed stable. Regarding your experience I'd guess on aggressive power saving, too. I see the same behaviour with most modern smartphones and there I know for a fact that it is power management.
11-09-2019, 06:16 PM
@tsys first of all, awesome work. Second of all, suspend is always a pain on mainline; what is your gut feeling re. getting suspend to work for the PBP?
11-09-2019, 06:22 PM
(11-09-2019, 06:16 PM)Luke Wrote: @tsys first of all, awesome work. Thanks (11-09-2019, 06:16 PM)Luke Wrote: Second of all, suspend is always a pain on mainline; what is your gut feeling re. getting suspend to work for the PBP? I feared something along those lines might be the case. I've not looked into the component support enough to give an educated guess yet. I think there is at least some supend support in the rk808 driver so we should be pretty much covered as far as power management goes. I'm not sure about the actual soc though. I'd immagine it does work for chromebooks based on the rk3399 so support will probably not be too bad on that end either. I'll just try and see what I can do.
11-10-2019, 11:41 AM
@tsys thanks for the response. Yes, I think that looking into RK3399-based Chromebooks for a suspend fix is certainly worthwhile. Again, great job.
11-11-2019, 06:01 AM
(11-09-2019, 05:36 PM)tsys Wrote: No. Unfortunately it is a crash of the firmware in the ap6255 wifi module. However, I've found another firmware binary in my firmware collection that seems to work a lot more stable. Haven't seen it crash in the past 5 hours or so. I'll keep it running over night and see if it is indeed stable. Interesting. In that case WiFi has been fully stable for me :-). Which firmwares have you tried? I have been working with the firmware and nvram.txt that I copied from the mrfixit Debian Stretch image that shipped by default. [quote pid='52275' dateline='1573342608'] Regarding your experience I'd guess on aggressive power saving, too. I see the same behaviour with most modern smartphones and there I know for a fact that it is power management. [/quote] Agree. To be honest I was just relieved that the standard kernel interfaces are sufficient to work around it (I've worked on platforms where that isn't the case).
11-11-2019, 07:26 AM
(11-09-2019, 06:16 PM)Luke Wrote: Second of all, suspend is always a pain on mainline; what is your gut feeling re. getting suspend to work for the PBP? suspend-to-idle works and does save a little power. Using the built in battery monitor (which happily takes quite a long time to observe changes so I can peek just after a wake up) then the system is consuming 0.5A whilst suspended to idle versus somewhere between 0.7A and 0.8A with just the backlight disabled. This is enough to be useful to conserve battery life in long meetings but I wouldn't want to leave it sleeping in my bag. So far I have not been able to wake the machine after suspending-to-ram. Thus enabling suspend to idle (echo s2idle | sudo tee /sys/power/mem_sleep or the tmpfiles.d equivalent) is a good idea for the time being since that way you can leave all the suspend machinary in your desktop environment in the default settings. |
Users browsing this thread: 3 Guest(s)