Camera Walk Up on Android OS

Camera driver for Android OS would follow the V4l2 (Video for Linux) path. Generally the device driver would be basedon the SOC platform architecture, in the sense that each platform provides a platform driver architecture which would provide the right way of implementing the driver.
Android Camera can be classified into different layers,

1. Android Camera APP and Android Camera API(JAVA)
2. Android Camera Service 
3. Android Camera HAL  (Camera HW Interface implementation / Platform specific 3A and other imaging algorithms and pipeline
4. V4l2 Camera Driver (Platform Driver )  

Camera Driver and HAL
Our concentration is mostly in the V4l2 driver and HAL So we will delve further into the concepts in the coming narration.  
Camera Hard Ware

• Camera Device
  • CMOS Sensor 

CMOS Camera device would be made of the following set of individual devices, 1. Camera Sensor (Silicon wafer with pixel    matrix) where each pixel contains a photo diode, and the pixel matrix is covered with CFA (Color Filter Array). Along with this CMOS Sensor would be having the circuit to convert the light stored to digital signal (Analog to Digital Converter) also the CMOS Sensor would have the required HW logic to convert the CFA patter to either YUV or RGB patter for the platform to use.

• • Camera Lens

Camera Lens are the device or arrangement of optical lens which would allow the light to pass through and fall on the CFA    there are multiple arrangements of the lens which CMOS camera use, based on the quality of lens the quality of the image    taken also gets effected.

• • Auto Focus

Focus is achieved by different methods using VCM (vector coil motors) which move the arrangement of lens to move near the scene or father from the scene based on the view.

• • One time Memory

There would be also a small one time memory which is placed in the module to give some initial settings and calibration data on which the camera module would run,  this is known as EEPROM.

• Connection to SOC
  The camera module is connected to SOC on the MIPI and I2C lines so that data and commands move to and fro from the camera to SOC and SOC to camera respectively.

     Linux Kernel
Device driver for the camera can be classified into the following steps, and each individual step when completed with out any error would lead us a usable camera driver which can be called upon the Android HAL and upper framework layers.

• • Configuration Files

               Configuration file would have the entry for the camera sensor which is being supported.                kernel/drivers/media/platform/<PlatformName>/<camera>/Kconfig. This file would need to be edited to add                      the specific sensor entry.

• • DTSI

               We would add a new dtsi entry for the new camera sensor which needs to be supported and following important                aspects need to kept in min before specifying the dtsi entry for the camera. path "kernel/arch/arm/boot/dts/"

• • • eeprom entry
      • cell-index which would have to increase with each specific entry
      • number of pages to read for the basic calibration data. 
    • actuator entry
      • This would be the actuator for the sensor which has the actuator 
    • Cameradtsi entry
      • Back and Front camera would have separate entry 
      • register value
      • camera csi phy index
      • camera csid index
      • mount angle for the sensor
      • vana, vdig, vio, vaf supply
      • camera pin control entries
      • GPIO pin settings
      • master clock 

• • PIN-Controll

               Pin control changes would need to be done for the GPIO which would help in sensor reset and power down                          control. If these are not set properly we would fail in probe.

• • Platform Driver 

               MSM Camera Driver and related changes, There no change in the platform driver since the user space driver is                      passing the setting down the platform camera driver which would handle those settings. 

• • IR LED FLASH Driver

               This device would be switched on to provide illumination, and the Torch mode would need to be set for use case                being handled we would need to add the low array with an entry for the higher intensity of IR Light.   

• • Debugging Tips for the Camera Driver

               This section would help in understanding the architecture and then debugging the camera driver.


Camera HAL , 3A and UserSpace driver

• • User Space Driver

               User space driver has the following set of the changes for the sensor to be started and streaming to begin 

• • • Sensor Power setting, which involves the voltages and MCLK (main Clk to the sensor).
    • sensor_slave_info ,  which involves camera id (front or back) then the salve adderss and other required for the structure
    • Sensor Init Params which involves mount angle,camera sensor position, modes
    • Sensor out put configurations, involves the sensor output format(BAYER, YUV) , sensor connection mode (MIPI, CSI) and how many bit out put we need (8 Bit or 10 Bit) based on the sensor support.
    • Camera Serial interface lane settings, involves lane assign,  lane mask, csi interface number, casid core, and casi physical selection (either 0/) for us it is 0 for back camera.
    • sensor init register settings ( based on the sensor manufacturer's data sheet)

• • 3A Related Changes          

               We have changed the gain settings to maximum for IR Capture.     

• • Debugging Tips For the User Space Camera Driver