OnePlus 6 and PocoPhone F1 Main requirements
The OnePlus 6 and PocoPhone F1 are both getting pretty well supported now, so I'm opening this issue to track what's left before potentially moving them to main (And so anyone interested can maybe chip in :D)!
Outstanding issues
OnePlus 6
Call audio
Needs Alsa UCM configs to fix the earpiece speaker, I haven't been able to get it working for quite a few kernel versions. There might be a kernel bug here but I'm not sure. The earpiece seems to be wired up differently to the Poco F1.
Charging
The OnePlus 6 has some quirk where it refuses to charge at more than 250ma, this seems to be due to some weird changes OnePlus did to support their custom Dash charging. I've done some research into it but haven't been able to resolve the issue.
OnePlus 6T
Panel
We currently have to skip the reset sequence for the 6T panel, as the init sequence in the driver doesn't work properly.
Speaker
The TFA speaker codec requires a huge downstream driver mess, and its own firmware, we currently don't carry this in our tree, but we could.
PocoPhone F1
WiFi: Although 2.4Ghz works perfectly, 5Ghz reception is poor. Not able to find the cause yet.
Mobile Data: On the surface it works, but if pmOS is dual/alternatively boot with android, somehow some modem internal config/something gets corrupted and mobile data stops working for that particular sim in pmOS (calls,sms will still work. also, in android mobile data will work. only when using pmOS/ModemManager it wouldnt). Temporary suggestion is to not boot android and pmOS with the same sim and try a different sim if mobile data doesnt work. :( Yet to find the root cause. I have a hunch that it could be related to: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/660
Poco F1 (EBBG) variant's display has some issues when display off and on, its not consistent and has issues with suspend/resume. Poco F1 (Tianma) variant's display works great and already in mainline.
Thanks Joel
Both devices
Sensors
The sensors are connected to a co-processor - the SLPI (Sensor Low Power Island), the Application Processor is prevented from communicating directly with the I2C/SPI controllers that the sensors are connected to, so the only way to communicate with them is via the SLPI. We communicate with it using ProtoBuf over QMI, so the protobuf format needs to be reversed, as well as the initialisation sequence and whatever device specific configuration is needed.
Some preliminary stuff was documented here: https://github.com/calebccff/sensordaemon-re
Wake up on phone calls/SMS
The devices don't currently wake up for calls or SMS, I asked around and it seems like the interrupt responsible for this is handled by one of the Glink drivers, these currently don't configure the interrupt as a wakeirq. This would need to be fixed. This interrupt may also be the one that fires for things like remoteproc crashes, we'd need to detect this and put the device back into suspend if this is the case, as some devices (e.g. laptops) might not automatically suspend again after waking up.
GPS
It could be talked to using ModemManager if I am right. But havent experimented with it much yet. These could improve the situation: