Linux Driver Status

This page has the status for driver bringup for Vita Linux and is a good place to start with for people who want to contribute. The priority is determined as follows: high - required for a usable environment, med - required to be livable on it, low - not needed but would be nice to have, extra - not needed at all but bonus points for anyone who gets it working.

Devices

Device	Status	Priority	Links	Notes
Framebuffer	25%	High	IFTU Registers	Uses pre-configured framebuffer by Vita Linux bootloader
PMU	0%	Med	Pervasive SN99057
GPIO	0%	Med	GPIO Registers	LEDs mostly
UART	50%	High	UART Registers UART Console	Console, debugging
DSI	0%	High	DSI Registers	Display interface
CSI	0%	Low	CSI Registers	Camera interface
I2S	0%	Med	I2S Registers	Audio
I2C	0%	Med	I2C Registers	PMIC, camera, accelerometer, OLED brightness, clockgen, HDMI control
SPI	50%	Med	SPI Registers	Syscon, accelerometer, OLED, touchscreen. Needs code cleanup as a proper SPI driver.
Buttons/joysticks	95%	Med	Current implementation libbaremetal implementation	Needs code cleanup: depends on SPI driver and MFD subsystem driver for Syscon.
Touch	95%	Med	Current implementation libbaremetal implementation	Needs code cleanup: depends on SPI driver and MFD subsystem driver for Syscon.
Motion	0%	Low		SPI, some ST chip
SDIO	0%	High	SceSdif [1]	eMMC, GC, Wifi/BT uses this. Standard SD interface.
MSIF	0%	Low	MSIF Registers SceMsif SceSblSsMgr	MemoryStick
WLAN/BT	0%	Med		Marvell 88W878S-BKB2, SDIO interface
eMMC	0%	High		SDIO interface, standard chip
Gamecard	0%	Med	Game Card	SDIO interface, extra auth (can be disabled and use sd2vita)
Memory Card	0%	Low	Memory Card libbaremetal implementation	MSIF interface, extra auth
GPU	0%	Med	GPU	SGX543MP4+
USB	0%	Med	EHCI	Ethernet, Audio codec, accessories
UDC	0%	Low	UDC SceUdcd	Connecting to host PC
PSP	0%	Extra	PSP Emulator	Custom MIPS
Codec	0%	Extra	Venezia	Toshiba MeP based

Plan

Start with the low level interfaces (SPI, I2C, etc). Those are relatively simple. Some might even have standard controller interface (like SDIO). The hardest is probably USB (unless the interface is standard). Then you can implement the devices on top of the interfaces. A lot of the devices seem to use standard chips (WLAN, motion, touch, etc) so we may get them "for free".

For power management, we need sleep/resume first. Would be great is we can use the dynamic clocking features to save battery but that's low priority. Battery fuel gauge is through a standard chip over I2C interface.

Framebuffer might be the hardest. Seems to be a custom interface. If we can find any open source device that uses a similar controller, it would make things a lot easier.