Difference between revisions of "Kernel areas of focus for mainlining"

From eLinux.org
Jump to: navigation, search
Line 105: Line 105:
  
 
== GPU ==
 
== GPU ==
 +
* HDMI integration with sound for EDID and hotplug information.
  
 
== Power ==
 
== Power ==

Revision as of 01:42, 4 August 2015

This page has a list of areas of the kernel where multiple SoCs have code out-of-tree, or that appear to need some work in order to accommodate contribution of device-related software.

Overview

The following table shows major out-of-tree areas of code, for mobile phone products based on the 3.4 Linux kernel. Although this kernel is quite old, it was the one currently shipping in phones in late 2014 and early 2015, when this analysis was done. It demonstrates the major technical areas where vendors used out-of-tree kernel code, for that generation of products.

The table shows different phones, and the number of lines they have out-of-mainline for several different kernel areas. The analysis was done using the upstream-analysis-tools (See https://github.com/tbird20d/upstream-analysis-tools). Since this task was mostly automated, the results here should not be considered definitive. That is, most of the categorization of diffs was done using regex matches on the file paths. Although this can result in some mis-categorizations of diffs, the results appear to show general patterns which may be of interest.

Note that the table shows the number of insertions (or changes). The number of deletions was found to be inconsequential for this analysis.

Manufacturer/phone/SoC => LG/G3/Qcom Samsung/Galaxy 4/Exynos Acer/E2/Mediatek Asus/Zenfone 6/Atom Huawei/P6/Hisilicon Sony/Z3/Qcom
Kernel area
Mach specific 417411 89118 ? ? ? 393767
Media 131811 163540 ? 1466714 153032 124973
Video 221550 176787 37876 38785 238267 214027
Wireless 110946 123308 387214 91449 122501 81502
Sound 216643 86127 12932 74057 19250 213137
Input 107334 51160 2752 53321 35410 62930
Camera 66989 1342 7900 1024348 51065 56744
GPU 53345 172300 114932 36545 198323 53468
Power 61912 7635 94059 66629 45127 46173
USB 99295 35366 30795 34074 121075 98663
Notable other Prima - 565210 firmware - 101069 i2c - 105744 reg - 90034

Technical areas

Here are some lists of things to get mainlined, in different technical areas:

Media

Video

Wireless

action item: Find out if any vendors have the same IP blocks for wireless Here are the findings for 3.4:

  • LG/G3/qcom - Broadcom 4330/4334/43341/4335/4339
    • source include drivers/net/wireless/bcmdhd
      • this code is organized differently from the Acer bcmdhd code
  • Samsung/Galaxy 4/exynos - Broadcom 4335
    • source includes drivers/net/wireless/bcmdhd
    • source includes drivers/net/wireless/ipsecdrvtl
  • Acer/E2/mediatek - Broadcom 4329/30 wireless chipsets
    • source includes drivers/net/wireless/bcmdhd
    • mainline 4.2 has drivers/net/wireless/brcm80211/brcmfmac,brcmsmac,brcmutil
    •  !! also lots of code in mdtk/krnl/drivers/combo/drv_wlan/mt66s*/wlan/mgmt,nic,os/linux
      • code under this tree is not in linux format (it has vendor style)
      • need to see if this is some mediatek on-chip thing, and Acer added external broadcom chip for E2
  • Asus/Zenfone 6/Atom - Broadcom 4329/30
    • source include drivers/net/wireless/bcmdhd
  • Huawei/P6/Hisilicon
    • defines CONFIG_WL12XX=m
  • Sony/Z3/Qcom -
    • Sony has historically used broadcom 4339 and qcom 3660 and qcom 3680.

Random notes:

  • Google got burned in early Android - TI had a bad wireless implementation (it was cross-platform and didn't work well in Linux). Google now integrates broadcom code themselves, at drivers/net/wireless/brcmdhd, and requires current Android vendors to use broadcom. This explains why everyone has it.
  • broadcom driver in mainline is a drivers/net/wireless/brcm80211/*
    • this is the one people should try to use and extend if it doesn't work

Possible strategy:

  • backport brcm80211 code to 3.18 or 3.14. These are the versions of kernels likely to be used in the next generation of Android products. Having the brcm80211 code available in that version means that phone vendors can test the driver. If it's close to product grade, they can help improve it - if not, then they can report the issues upstream.
    • Is Google or someone else already doing this - AI - check 3.18 src from SoC vendor for brcm80211 code

skeleton for other comparisons:

  • LG/G3/qcom -
  • Samsung/Galaxy 4/exynos -
  • Acer/E2/mediatek -
  • Asus/Zenfone 6/Atom -
  • Huawei/P6/Hisilicon -
  • Sony/Z3/qcom -

Sound

  • HDMI inegration with graphics for EDID and hotplug information.

Input

Camera

GPU

  • HDMI integration with sound for EDID and hotplug information.

Power

Battery charging

Battery charging to be handled in drivers/power. These can be subdivided into two classes:

  • Smart batteries, resembling laptop batteries, which have a hardware-provided state machine to charge and monitor the status of the battery. These have good framework support upstream already in the struct power_supply_desc and enum power_supply_property found in <linux/power_supply.h>
  • Batteries requireing an external charging algorithm. It was at one point unclear what part of a charging algorithm should go into kernelspace and what parts should possibly go into userspace akin to how Wireless have policy in userspace. It is nowadays widely agreed that any battery handling that may cause damage to the hardware if not attended to need to go into kernelspace, and that includes the major part of the charging algorithm.

The latter class of batteries exist upstream but does not have shared code and frameworks in place to implement the charging algorithm. These algorithms are quite physical and close to standardized, the most well-known concepts are CC/CV (Constant-Current/Constant-Voltage) and trickle charging. These algorithms are then modified to handle critical events such as overtemperature or overvoltage, and for this reason they periodically perform temperature and voltage and current measurements. They are mostly implemented in the form of a state machine. Interaction with IIO drivers for ADC and/or temperature is ideally needed to provide the necessary input.

We may not see the battery charging code in vendor kernels because it has been shimmed to userspace, even though it should technically be inside the kernel.

USB

  • USB-gadget to charger interface
    • Currently in progress at Linaro.
  • Code for external vbus and ID detection (looks like extcon was created for stuff like this - ish, it's mainly a mainlining of the Android switch API though it probably does fit)

Positioning

GPS or any other positioning system for that matter, seems to be driven from userspace. In mobile handsets Assisted GPS utilizing cell tower data is commonly used. These chips usually consists of a "baseband" (in the modem terminology, the digital chip) and a RF (radio frequency) frontend that connects to the antenna (also called an air interface). If the "baseband" is a stand-alone chip, it tends to have a large firmware and complex interactions over some local bus such as simple UART. The power states of the chip is also driven from userspace, making power-saving scenarious uncoordinated with kernel power management for the most part. Assisted GPS requires network connectivity over cellular data and special interactions with a cellular modem to work.

Stand-alone GPS chips for devices without cellular modems (such as tablets) also exist. Garmin has open source releases for all their Linux-based GPS devices, based on "basebands" such as OMAP, PXA and Telechips.

Whether the positioning code should be in the kernel or in userspace is a question of debate. We may not see the battery charging code in vendor kernels because it has been shimmed to userspace, even though it should technically be inside the kernel.

Notes from ksummit-discuss list

  • RGB leds - not the same as 3 leds, and sometimes have hardware acceleration
  • battery over-discharge protection
  • charger (there are 3 different chargers on N900)
  • voice link to modem (Nokia says ALSA is not suitable for modem audio)
    • No need for this, ALSA is in active use for rather a lot of production phones...
  • userspace (mini-distro?) for testing
  • suspend-to-ram