[LA.UM.7.1.r1] linux: 4.14.254

[Haxk20]

A small PR for updating our kernel to latest stable on kernel.org.

Patch: 4.14.254

[roberto-sartori-gl]

Hi, Just a quick question as I'm using this kernel as base for a different device (OnePlus 5/5T).

Is there a reason you are merging the kernel from kernel.org instead of the Android 4.14 common branch from Google? Merging the common kernel would both update the Linux version and provide all the needed Android patches (instead of cherry-picking them).

Thanks for the work on this!

[MarijnS95]

@roberto-sartori-gl I don't think this has been an explicit choice, just that:

• Contributors started submitting kernel.org patches (and integration from newer tags from the related CAF branches);
• android-4.14-stable branches might have already diverged enough to be unmergeable into the CAF branch this kernel is based on;
• Even more so now, it is impossible to integrate that branch with ours, without getting 3000+ conflicts.

[roberto-sartori-gl]

@MarijnS95 Yes, now it is basically impossible to merge it (I did try, I promise, but there are too many conficts :) ), I was just wondering why this was decided at the 'beginning'.

But, as you said, it was not decided, it just happened :)

Thanks for the answer!

[MarijnS95]

@roberto-sartori-gl Hence we're now going in the opposite direction: merging our patches (drivers, fixes, device support) to the Linux kernel directly. This is an even longer, more tedious process, but much more rewarding and sustainable in the end.

Stay tuned!

[roberto-sartori-gl]

@MarijnS95 Yes, thanks to the work of @kholk I was also able to boot Android on 5.10/5.11 some time ago (on OnePlus 5). I'm only worried about the 'dependencies' to the Qualcomm binaries (or other vendors). Example: we can even port the fingerprint reader driver, or the Qualcomm camera driver to the mainline Kernel, but then there are a series of user space binaries that will not work. Am I too worried? :D

[MarijnS95]

@roberto-sartori-gl We're definitely going offtopic here, but alas:

Binaries are of some concern. Certain parts have replacements such as the GPU stack being replaced by freedreno, but performance isn't great. External processors and modems is handled by libqmi/qrtr/modemmanager etc. Cameras can be (and are already, to some extent) mapped out in a clean-room kernel driver implementation and exposed as a (complex, not straightforward to use like a PC webcam) v4l media device - but will lack all the "software enhancements" (same for audio: it's a complex system with lots of custom parts - the basics may work but anything advanced likely requires a custom kernel/userspace opensource re-implementation).

The fingerprint sensor doesn't however have a true hardware driver in the generic sense of a desktop platform. Our kernel driver only performs power management (which is different per board/platform) but any actual communication with the device and logic happens in a TrustZone app (blob). Assuming we can start apps on and communicate with the TZ, we can use the clean-room opensource fingerprint HAL written for SODP to control this custom TZ app. Integrating that with libfingerprint/fprintd for use in non-Android Linux mobile distros will prove another challenge though.

[Thaodan]

@roberto-sartori-gl We're definitely going offtopic here, but alas:

The fingerprint sensor doesn't however have a true hardware driver in the generic sense of a desktop platform. Our kernel driver only performs power management (which is different per board/platform) but any actual communication with the device and logic happens in a TrustZone app (blob). Assuming we can start apps on and communicate with the TZ, we can use the clean-room opensource fingerprint HAL written for SODP to control this custom TZ app. Integrating that with libfingerprint/fprintd for use in non-Android Linux mobile distros will prove another challenge though.

This actually similar for bluetooth on mainline there is no blob and the kernel does the job vs. in this kernels/androids case its a userspace blob and the kernel just does power management.

[MarijnS95]

This actually similar for bluetooth on mainline there is no blob and the kernel does the job vs. in this kernels/androids case its a userspace blob and the kernel just does power management.

I thought even our downstream kernels provide simple HCI drivers that Android's opensource Bluetooth stack can use?

[Thaodan]

This actually similar for bluetooth on mainline there is no blob and the kernel does the job vs. in this kernels/androids case its a userspace blob and the kernel just does power management.

I thought even our downstream kernels provide simple HCI drivers that Android's opensource Bluetooth stack can use?

It can however the current bluetooth hardware isn't supported by the bluetooth driver (btqca). It gets better after 4.19.

[MarijnS95]

And the blob probably also intercepts and changes certain commands it receives on android.hardware.bluetooth@1.0::IBluetoothHci/default, just to make things work.

[Thaodan]

I don't think that even since than you would need blob even on 4.19+ kernels. Even especially after 5.4 the blob is almost useless. There's already mainline on sdm845 running. Only slimbus side makes wonder since I have no idea about audio.

[MarijnS95]

I don't think that even since than you would need blob even on 4.19+ kernels. Even especially after 5.4 the blob is almost useless. There's already mainline on sdm845 running. Only slimbus side makes wonder since I have no idea about audio.

Yes, we have it working on many mainline Sony devices already. In other words, whatever the blob does (for basic functionality) is now built into the kernel driver such that Android through IBluetoothHci and BlueZ can simply use HCI to control the adapter.

Android sends vendor commands to start A2DP-offload-receiving on the Bluetooth side, I have a hunch those are intercepted in the blob to subsequently prepare the adapter for SLIMbus - unless the adapter can work with these HCI commands as-is. bt-sco is already built into the mainline kernel for certain devices but doesn't do anything with the Bluetooth adapter besides providing "ghost" audio widgets (since the audio magically "disappears" from the audio graph there, only to surface again inside the BT adapter out of the kernels' reach).

[Thaodan]

I don't think that even since than you would need blob even on 4.19+ kernels. Even especially after 5.4 the blob is almost useless. There's already mainline on sdm845 running. Only slimbus side makes wonder since I have no idea about audio.

Yes, we have it working on many mainline Sony devices already. In other words, whatever the blob does (for basic functionality) is now built into the kernel driver such that Android through IBluetoothHci and BlueZ can simply use HCI to control the adapter. That sounds nice and bad at the same time because of below:

Android sends vendor commands to start A2DP-offload-receiving on the Bluetooth side, I have a hunch those are intercepted in the blob to subsequently prepare the adapter for SLIMbus - unless the adapter can work with these HCI commands as-is. bt-sco is already built into the mainline kernel for certain devices but doesn't do anything with the Bluetooth adapter besides providing "ghost" audio widgets (since the audio magically "disappears" from the audio graph there, only to surface again inside the BT adapter out of the kernels' reach).

Well there is SLIMbus in mainline but I guess the approach you explained is used us a dirty way to those things for the public. I really would like to have HCI without the blob or at least not through binder on sfos there still seams to be some magic going on since the tty device used by the blob doesn't really work in bluez. For older socs Bluez could initialize the device natively.

[MarijnS95]

@Thaodan Hehe don't forget the newlines between the quotation block and your reply :)

Well there is SLIMbus in mainline but I guess the approach you explained is used us a dirty way to those things for the public.

Yeah exactly, it's just an endpoint driver that has no ties into any actual Bluetooth drivers, because it doesn't need to: https://github.com/torvalds/linux/blob/master/sound/soc/codecs/bt-sco.c. It just exposes the possible format and sampling rate for HSP/HFP, which are transmitted over SCO.

Note that this isn't limited to SLIMbus, though that's afaik what most if not all our SoCs use to transmit both HFP/HSP and A2DP audio to/from the adapter.

For A2DP I assume the DAPM graph is going to be more complicated, perhaps with the Bluetooth codec actively exposing the right widgets and afaik connecting it all together to ensure everything is properly enabled/disabled. But don't quote me on that since it's not built yet, not even HFP/HSP offloading through the resulting ALSA mixer hasn't been implemented in PA/PW yet (but sfos does have that... https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1217).

without the blob or at least not through binder on sfos

Anyway, this is definitely why we're working on mainline support:

• Latest stable/secure opensource kernel;
• No reliance on blobs;
• Work just like a normal desktop computer, allowing any (though preferably mobile focused UX-wise) distro to work OOTB.

It is taking a lot of effort to do this in ones free time, but perhaps we should sync up with sfos and see if you can take advantage of mainlined devices sooner rather than later?