-
Notifications
You must be signed in to change notification settings - Fork 6
Kernel V4.4 New _ Current issues and fixes
-
Audio over HDMI doesn't work: Audio gets routed to the phone's speakers instead. Happens on V20 and G5- Fixed, see theFixes
section below. -
Camera doesn't work: It's close, but still fails when trying to actually use it. Seems to be something on ISP.- Fixed, for the V20 and G6 at least. Details in theFixes
section below. -
Infrared Blaster: It's in the "almost works" territory ever since 3.18 got updated. Currently we have some minor improvements to it in the form of suspend/resume routines that not only improve power consumption, but also help it work a bit better at sending signals.- Fixed (finally!). Details in theFixes
section below. -
5Ghz hotspot doesn't work.- Fixed. Details in theFixes
section below. -
LineageOS Charge limiter doesn't work and makes the phone constantly switch between charging and not charging.- Fixed. Details in theFixes
section below. -
Wired headset buttons don't work for some reason.- Fixed. Details in theFixes
section below.
Turns out this one was a regression from changing the mtp audio props in the device trees. By not including the following commits in the newer source:
Delete "sound-9335" node from msm8996-mtp.dtsi
Change how we handle msm8996-mtp additions
And adding some adjustments to G5 and G6 such as: This one and also this one seems to have fixed audio as a whole for all phones.
That one was a rather simple fix, we only had to remove some sink widgets by cherry-picking this:
Not sure if it works for all phones yet, but it's confirmed to work on V20 & G6 now and we already have some fixes in place:
Adjust the LGE ifdefs in msmb_camera.h
Make LGE additions be easier to toggle
msm: camera: sensor: Fix video node creation
Revert "msm: camera: sensor: Add OIS read functionality"- Removed, doesn't help.msm: camera: isp: Fix memory leaks in vfe probe
camera: isp: Add an LGE ifdef for vfe_fuse attribution
camera_v2: Add a workaround to VIDIOC_MSM_ISP_AHB_CLK_CFG cmd
defconfig: Disable LGE_CAM_PREVIEW_TUNE
It's a good idea to go back and see if any of those commits can be reverted later.
As of yet, we only have a single commit that helps it work better:
We'll need some additional adjustments to IR if we are to fix it kernel-side without depending on the rom's consumerIR hal patches.
This one was caused by vbus and power roles still trying to set properties on now-disabled power supplies on tusb422:
These fixes help make sure that those drivers (which are used by the phones) are using the correct band names on the kernel:
USB isn't perfect yet. Charging is too slow compared to 3.18, and we have a few leftover issues to iron out. So far there are the following fixes:
drivers: power: qcom: Remove CONFIG_LGE_PM parallel psy rename
This issue has been around since 4.4's early days. But since it wasn't as critical as the other major subsystems like USB, Audio, Camera, etc. It was ignored until we upstreamed the kernel in order to comply with lineage's requirements for official support. One of the requirements is that encryption has to work (File-Based Encryption, more specifically), and the kernel needs a working crypto engine for that to happen.
Our issue lied on the fact that the two available drivers
QCE
andQcrypto
were enabled, and assigned the sameqcrypto
driver name on the kernel, which resulted in QCE failing to probe, andQcrypto
right after since QCE was already registered as qcrypto. This, in turn, led us to disable QCE since our platform's Qcrypto driver already has a QCE implementation of its own. The following commits made a few cleanups to the crypto drivers, and disabled QCE so that we could use Qcom's Qcrypto driver:crypto: msm: make qcrypto and qcedev independent of DEBUG_FS
defconfig: Disable CONFIG_CRYPTO_DEV_QCE
By fixing the registration issue, the kernel logs now give the impression that part of the crypto engine is failing to probe, however, it actually seems to probe just fine. This happens because QCE fails in the beginning but Qcrypto successfully probes right after, so qce failing first is not an issue. The logs look like this:
qce 660000.qcedev: Qualcomm Crypto 5.3.1 device found @0x660000
[probe fails for this driver]
*messages about qce failing and other unrelated kernel drivers*
qcrypto 660000.qcrypto: Qualcomm Crypto 5.3.1 device found @0x660000
[probe succeeds on this one]
The G5 was plagued with i2c issues throughout 4.4, and HDMI was no exception, with slimport7816 throwing multiple
i2c-msm-v2 757a000.i2c: NACK: slave not responding
errors. Those were sorted out by modernizing the drivers, removing unused stuff and fixing gpio, all of which was done by three commits:video: slimport: Remove unused drivers from LG
This one turned out to be relatively small, only needing a few tweaks to our device trees to remove duplicate nodes and definitions that are already present on qcom's dts files such as msm8996-mtp:
No wonder it was an issue for so long. The infrared was broken by some updates to binder_alloc. Namely adjustments that touched page_update, vma and memmap logic, which handle how binder structs are allocated and freed in memory.
Note: This might receive some improvements later, as the current patch isn't that clean and possibly adjusts way more code than it should.
drivers: android: Patch some binder_alloc sections to fix IR
This happened because us996 builds assumed the device was unlocked with the dirtysanta exploit, while in fact us996 is the only v20 model that can (or rather, could) have its bootloader officially unlocked, removing the need for any display patches needed by models unlocked via the exploit. At the end of the day, separating US996 into two separate variants with and without the dirtysanta fix-ups solved the problem, since Lineage now has separate trees for those as well.
defconfig: Separate officially unlocked US996 and Dirtysanta US996
This one was just a matter of working around whatever lineage was doing by making SoMC kick in whenever it detected that something was trying to limit the charge level.
drivers: power: Use SoMC's built-in structures for charge limiting
A rather common case of LGE stuff doing more harm than good. Removing all of it from our wcd drivers fixed this issue, while also making their code much cleaner since we don't use any of LGE's additions in there anymore
Wasn't a kernel issue, instead it was fixed by disabling support for softAP IEEE80211AC on our msm8996-common tree: