User:Z3ntu/Fairphone2-mainline

= Component support table =

= Test notes =

Power key
evtest /dev/input/event0

Volume &amp; camera buttons
evtest /dev/input/event1

Touchscreen
evtest /dev/input/event2

Vibration motor
fftest /dev/input/event3

Internal storage
ls /dev/mmcblk0*

SD card storage
ls /dev/mmcblk1*

Display
Framebuffer console should display the kernel messages

ls -al /dev/fb0 echo 255 &gt; /sys/class/backlight/fd922800.dsi.0/brightness

GPU
kmscube

Notification LED
echo 255 &gt; /sys/class/leds/rgb\:status/brightness

WiFi / Bluetooth / FM
echo start &gt; /sys/class/remoteproc/remoteprocX/state Regarding FM:
 * 1) set mac address according to &quot;MAC addresses&quot; section
 * 2) wifi and bluetooth interfaces should just work

someone was doing some initial work, but i got the feeling that without lpass running it didn't want to play ball

MAC addresses
$ qmicli -d /dev/wwan0qmi0 --dms-get-mac-address wlan $ ip link set dev wlan0 address 12:34:56:78:9A:BC

$ qmicli -d /dev/wwan0qmi0 --dms-get-mac-address bt $ echo BC:9A:78:56:34:12 | awk 'BEGIN{FS=OFS=&quot;:&quot;} {s=$NF; for (i=NF-1; i&gt;=1; i--) s = s OFS $i; print s}' $ btmgmt public-addr 12:34:56:78:9A:BC It looks like the Bluetooth initialization (including querying the MAC address via QMI and setting it) is done with hci_qcomm_init on downstream. It looks like there is no official public source version available for that.
 * 1) Note, that the bluetooth mac address is backwards (e.g. BC:9A:78:56:34:12 is actually 12:34:56:78:9A:BC)
 * 2) You can reverse the mac address using the following script:

For WiFi this seems to be done with libwcnss_qmi.so, a source version of that can be found here.

Sensors
Notes from IRC:

the client would need to implement the sensor qmi protocols, which we haven't tried to open up

qmi is just a method of encoding structured data; exactly like protobuf

libqmi implements a set of protocols that uses qmi to encode its data

so there's another set of 10-15 protocols, that uses qmi to encode messages, related to sensors

i think these are implemented in libsensors1.so - or something like that

but iirc libsensors1 is tied to the downstream AF_MSMIPC, and won't work on AF_QIPCRTR Further notes: https://gitlab.freedesktop.org/mobile-broadband/libqmi/issues/21

Modem
The modem gets detected with ofono but you need to do additional manual setup because it's a Dual SIM device: https://wiki.postmarketos.org/wiki/User:TravMurav/Dual-Sim_QMI_draft

The  package should handle this but hasn't been tested yet.

Mobile Data
Upstream kernel contains rmnet core driver (equivalent to downstream ) but not the platform specific part (or rather transport specific part). is (likely) used on downstream msm8974. Newer Qualcomm devices use the IPA driver but 8974 is older than that. The actual transport used is.

Mobile Data is working! At the moment these resources are required:


 * https://gitlab.com/postmarketOS/linux-postmarketos/-/commits/qcom-msm8974-5.9.y-bam
 * dual-sim things from Modem section
 * https://gist.github.com/Minecrell/4cc2bfb9fcae18e294386b0a213907d1
 * https://gitlab.com/Minecrell/pmaports/-/commit/2684abff23560dc0b5d8cb9f20baec2a28c3d0a8
 * For APN the following procedure is needed for my SIM card:

The above should all be integrated now.

Cameras
Old modules:


 * Front: OV2685
 * Back: OV8865

New modules:


 * Front: OV5670
 * Back: OV12870 (no sensor driver in Linux)

The cameras can produce a picture that can be displayed using the libcamera qcam test utility. Possibly other libcamera-based apps also might work.

Currently based on a separate kernel branch (might change), you anyways also need to rebuild your dtb with the correct camera sensors manually enabled. There's no dynamic runtime detection support. Not sure if that's even possible in Linux itself.

Replace  and run   to update   in.

Then you can try running :

eval $(cat /proc/`pidof phosh`/environ | tr '\0' '\n' | grep -v '^PS1=' | awk '{ print &quot;export \&quot;&quot; $0 &quot;\&quot;&quot; }')
 * 1) Adjust environment variables to be able to launch app via SSH

OV2685
QT_QPA_PLATFORM=wayland qcam -v -r gles

OV8865
v4l2-ctl -d /dev/v4l-subdev19 -c exposure=2500 QT_QPA_PLATFORM=wayland qcam -v -r gles -s width=3264,height=1836 (all other sizes don't deliver any data correctly)

OV5670
QT_QPA_PLATFORM=wayland qcam -v -r gles -s width=1280,height=720

Old camera module
The flash in the old camera module is controlled by the pm8941 and this hardware block is accessible on the address @d300. The qcom-lpg driver used for the notification LED is relatively similar but it should be a separate driver for the camera flash.

A driver was posted to LKML in 2020.

New camera module
For the new camera module (12MP one) the following driver is being used:

DRIVER=leds-lm3644 OF_NAME=ti,flash0 OF_FULLNAME=/soc/qcom,cci@fda0C000/ti,flash0@c6 OF_COMPATIBLE_0=ti,lm3644 OF_COMPATIBLE_N=1 MODALIAS=of:Nti,flash0T&lt;NULL&gt;Cti,lm3644 The situation seems to be more complicated than with the old module as the lm3644 driver takes over parts of the driver controlling pm8941@d300, which might be complicated to solve nicely on mainline.
 * 1) cat /sys/devices/fda0c000.qcom,cci/c6.ti,flash0/leds/torch_dual/device/uevent

The lm3644 is an i2c device sitting on the camera interface i2c bus. There's no driver in mainline for the lm3644 yet.

http://www.ti.com/lit/ds/symlink/lm3644.pdf

Audio
An initial (unsuccessful) test with out-of-tree patches from flto was done with the following config options:,  ,  ,  ,  ,  ,  ,  ,.

Headphone audio kind of works with one or both of these branches:


 * https://github.com/z3ntu/linux/commits/flto-msm8974
 * https://github.com/z3ntu/linux/commits/flto-msm8974-5.11

Others
See Brian Masney's Nexus 5 mainline to-do list.

= Kernel config options =

Base config:

cmdline
earlycon=msm_serial_dm,0xf991e000 PMOS_NO_OUTPUT_REDIRECT clk_ignore_unused pd_ignore_unused cma=500m msm.vram=192m msm.allow_vram_carveout=1