2021–03–15: Some PinePhone updates

There were a bunch of smallish news/fixes in my kernel since my last post:

Kernel log during boot is now a bit less noisy with non-important errors. This is mostly due to use of dev_err_probe() function that hides the temporary probe errors in case probe of some driver fails due to missing dependencies. If you want to see drivers that failed to probe due to a missing dependency, those are listed in /sys/kernel/debug/devices_deferred.

I've fixed the ANX7688 flashing timeout, so that flashing the firmware to ANX7688 works again on my 5.10 and 5.11 kernels.

There was some interest in mainlining the device tree bindings for ANX7688 this month, so I've added my observations to the discussion. Hopefully this will lead to getting ANX7688 driver mainline, eventually. Though the discussion has stalled.

There's an interesting new feature in my Linux kernel. Samuel proposed a nvmem based reboot driver. So I've took the idea, and updated the p-boot implementation so that it works with a modified variant of the proposal. It's now possible to reboot into a different boot option, or into eMMC, or into a p-boot boot menu, or even into FEL just by calling reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART2, "something"), where something can be one of emmc-egon, fel, menu, sd1, sd2, emmc1, emmc2, … and more. This will make the kernel inform p-boot to perform boot in a particular mode after the reboot, regardless of the default boot menu selection. Neat, eh? You can pass this argument to systemctl like this: systemctl reboot --reboot-argument sd3, and the phone will reboot to p-boot's 3rd boot menu option for SD card.

I've enabled USB_QUIRK_RESET for the modem's USB device in my kernel tree. This is supposed to help with modem USB interface resets during resume from sleep. more information With this it is not necessary to change power/persist: 0 and avoid_reset_quirk: 1, because that's done by the kernel automatically when the modem's USB device is probed.

With the help from #linux-sunxi/Peetz0r, I've enabled remote wakeup via WiFi packets in the 8723cs driver.

You can now configure the wifi driver to receive and react to some packets and wake the phone up if it's sleeping.

On PinePhone:

iw dev # and write down mac address, eg. 02:ba:7c:9c:cc:78
echo clean > /proc/net/rtl8723cs/wlan0/wow_pattern_info
iw phy0 wowlan enable any

# ... suspend to ram ...

On other device:

wol -i pinephone_ip_address 02:ba:7c:9c:cc:78

# ... pinephone wakes up over wifi ... :)

And the last change of note is a new patch that enables PMIC to wake the SoC from sleep when the battery is running low (<10% capacity), so that the OS may shut down gracefully, instead of just running out of power while asleep. This needs some userspace support, which is probably already implemented by some desktop environments. In case it isn't, the phone will just wake up from sleep and die sooner. I don't think the PMIC will keep sending interrupts, so the OS will need to be careful to use this opportunity to power off. It may still be more reliable to just perform periodic RTC based wakeups for various book keeping tasks, incl. battery monitoring, instead of relying on this one shot low battery interrupt from PMIC.

You can follow these kinds of changes and news in my kernel by looking at the latest orange-pi-$VER-$DATE tags in my kernel tree.

If you click at the tag name, you'll see the NEWS log. It's just not as pretty as this blog. :)

The latest tag also gets a build here: https://xff.cz/kernels/ for all the devices that I maintain my kernel for.

I didn't do much new work on my previously announced modem userspace project, because while I was away on holidays biktorgj seems to have poured a lot of effort into the same general idea, so there's no real need.

I have a bunch of things I'd like to try to tackle next. One of those is imprvoing the performance of USB peripheral mode. Currently when connecting PinePhone to a PC directly via USB cable, the performance of the USB is limited to speeds around 10 MiB/s. This is due to missing DMA implementation in the driver, so CPU has to push every byte individually into the FIFO, which is not very optimal. I have a work in progress implementation of the DMA support that I'd like to finish. Hopefully this will improve the speeds to be closer to the theoretical limit of ~40MiB/s.