August 11, 2015
Related Material:
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.
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.
Pavel Machek called out the following questions:
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.
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.
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.