Pavel Machek: Mainline kernel on a cellphone

August 11, 2015

Related Material:

  1. Kernel areas of focus for mainlining (describes deviation of several handsets from mainline and issues for several subsystems)

Additional Participants: Bintian, Björn Andersson, Daniel Vetter, Heiko Stübner, Johannes Berg, John W. Linville, Josh Triplett, Krzysztof Kozlowski, Kyungmin Park, Laurent Pinchart, Linus Walleij, Marcel Holtmann, Mark Brown, Neil Brown, Rafael J. Wysocki, Rob Herring, Samuel Ortiz, Shuah Khan, Steven Rostedt, Tim Bird, and Tony Lindgren.

People tagged: Sebastian Reichel, Pali Rohár, Björn Anderssen, Tim Bird,

Please note that this is a summarized summary.

Pavel Machek noted that while many phones run Linux today, it is quite difficult to get a mainline kernel running on one. Obstacles include large patches from silicon vendors, missing GNU/Linux userspace support (making testing difficult), interfaces unsuitable for phones, and power-management problems. Linus Walleij pointed out that Björn Anderssen booted a mainline kernel on a Sony Xperia Z3. Pavel added that a group at Samsung is rumored to be working on this as well.

Steven Rostedt seconded this topic, especially given that Linux Kernel Summit is being held in South Korea. Steven asked whether this should be a core topic or a tech topic, whether it affects the core kernel (as opposed to just drivers), and exactly what a Linux Kernel Summit session would be expected to solve.

Ongoing Upstreaming Efforts

Mark Brown argued that many subsystems are impacted, and that the desired resolution was likely more action-planning and process discussion than deep technology. Mark also pointed out that Tim Bird has been working this problem at other conferences, but that a Linux Kernel Session might be useful. Tim Bird has done an analysis of the upstreaming situation, finding that there is a lot of out-of-tree code for some areas, for example, 80K-100K of wireless driver (which Rob Herring calls out as the Broadcom vendor driver, and Bjorn agreed). Bjorn Andersson got Xperia Z3 up using the brcmf driver in mainline, and expects that other phones will be able to use wcn36xx at some point. Krzysztof Kozlowski noted some Samsung efforts runnning mainline kernels on the Trats and Trats2 devices, noting that it is much easier to run standard Debian on a mainline kernel on such devices than it is to run Tizen on a mainline kernel. Camera firmware is a problem for mainline, prompting additional discussion of such firmware.

Although Rob Herring was impressed with Bjorn's work, Rob is concerned that phones running mainline kernels would suffer from feature gaps, including switching between application processor (AP) and client modes, P2P support, power optimization, Bluetooth, and near-field communications (NFC). Bjorn agreed that both functional and stability gaps remain, but looks forward to work on closing these gaps. In particular, Bjorn expects to use the fact that mainline runs at all on these systems to pressure vendors into putting their code upstream. Bjorn also says that Android NFC is implemented entirely in userspace. Tim Bird is considering backporting current upstream brcm80211 back to 3.18 in order to expose it to testing on the next generation of mobile platforms, and would like feedback on the sanity of this approach. John W. Linville cautioned Tim to make sure that the current mainline driver supports the chips that are actually in use.

Linus Walleij was puzzled by some of the Bluetooth design choices, including use of a UART connection which makes it impossible to correctly instantiate them using the Linux-kernel driver model. Therefore, userspace peeking and poking is used to bridge the gap, but in a way that is highly counterintuitive for kernel engineers. Rob Herring replied that his was due to the need for sideband signals for regulator control, reset, clocks, wakeup, RF-kill, and so on. Rob said that Neil Brown has created a UART slave device, but that this approach currently results in one-off device bindings, and Rob would like to see more commonality. Marcel Holtmann said that Bluetooth support was in fact being moved into the kernel. Linus Walleij hopes that GPS and NFC will also be moved into the kernel. Marcel replied that NFC is already in mainline with wide vendor support, despite Android's insistance on doing NFC in userspace. However, GPS faces some “funky” issues. There was additional discussion of interesting hardware implementation choices of various SoC vendors, and the code-quality advantages of upstream code were called out.

Samuel Ortiz argued that some vendors want to keep GPS and NFC in userspace to avoid the requirements of GPL.

Heiko Stübner argued that this is a consumer-electronics problem as opposed to a smartphone-specific problem. That said, he believes that ChromeOS does things right in terms of development model.

What to Solve at Linux Kernel Summit?

Pavel Machek called out the following questions:

  1. How to support the RGB LEDs and their hardware acceleration? (Not to be confused with the “3 LEDs”.)
  2. Is it the kernel's jobs to protect the hardware from its user, for example, by protecting against battery over-discharge?
  3. Should the kernel hide differences between different hardware platforms? (Currently, it does not do so in the phone arena.)
  4. What should be used as the voice link to modem? Nokia feels that ALSA is unsuitable.
  5. What userspace should be used for testing?
  6. For Android, is suspend-to-RAM needed to save power on cellphones? If so, does there need to be a new interface to allow applications to signal that they are ready to run?

Question 1: Support of RGB LEDs?

Josh Triplett suggested that RGB LEDs be treated as 3 LEDs, but that the interface to userspace treat the three brightness values together. Josh also wondered whether the hardware acceleration was anything more than pulse-width modulation (PWM). Pavel agreed, stating that the interface should say “display magenta” rather than having to call out the red, blue, and green components. However, Pavel pointed out that the hardware acceleration including complex pattern generation over and above automating PWM.

Question 4: Voice Link to Modem?

Mark Brown argued that ALSA is in fact the correct interface, and suspected some misunderstanding, driver limitations, or unfortunate hardware design (such as bouncing the voice call through the AP). Mark noted that many production phones are doing just fine using ALSA. Pavel Machek argued that sending data through the AP is a good idea from a security perspective, as it makes it harder for a hacked baseband to eavesdrop (a point that was debated at some length). Pavel also pointed to an LKML email from Kai Vehmanen calling out some ALSA issues, but agreeing that misunderstandings and/or hardware limitations are likely the root cause.

Question 6: Suspend to RAM?

Neil Brown argued that Runtime-PM can put all the devices to sleep, and that the cgroup freezer should be able to freeze untrusted processes. However, Neil believes that system suspend provides greater power savings, and that use of the cgroup freezer would require large userspace changes. Neil stated that userspace decides when to suspend, or alternatively, that CONFIG_PM_WAKELOCKS provides the needed /sys/power/wake_lock interface. Tony Lindgren pointed out that timers do not work when suspended, so suspend-to-RAM needs to be optional. Rafael J. Wysocki added that disabling timer events is key to low energy usage, which allows suspend-to-idle to achieve very low energy consumption. Additional discussion ensued surrounding the value of predicting idle-time duration and exactly what events tend to wake the system.