Android driver development interview question record

This article records some technical-related questions asked by the interviewer when I interviewed the Android driver development engineer (for reference only).

---

1. System pruning: the specific method? How to judge whether it is necessary or reserved during the cutting process?

1. Remove unnecessary apks
   There are many apks that are basically not used in the system, which probably occupy more than 100MB of space in the system partition. After removal, the boot time can be effectively shortened.

2. Remove unnecessary drivers.
   There are driver switches in the .config file, and unnecessary ones can be turned off directly (make menuconfig)

3. Framework layer
   Delete some languages ​​(languages_full.mk), delete useless files (in the mk file)

4. Remove useless services
   Delete useless scripts and services (4G services...), delete useless print information (do not output bootloader and uboot prints, and reduce the kernel print level to 1)

---

2. What is the general process when debugging peripherals? (such as LCD screen)

1. Obtain screen specifications (determine what type of screen <single/dual lvds, edp, mipi...> to debug);
2. Configure parameters in the corresponding dts file (kernel/arch/arm/boot/dts);
3. Determine the parameters according to the screen specification:

1> backlight voltage, screen power supply voltage;
2> clock-frequency: lcd clock frequency, unit is Hz;
3> Hactive: horizontal effective pixels, Vactive: vertical effective pixels
4> hback-porch/hfront-porch/hsync-len: Horizontal synchronization signal, vback-porch/vfront-porch/vsync-len: vertical synchronization signal

4. Configure the gpio state corresponding to the hardware schematic diagram (pull it high or low according to the hardware definition):

Backlight control pin (enable), screen enable pin (enable), reset pin (reset)

5. Debugging and troubleshooting methods:

cat d/dri/0/summary
to view the opening status of vop and the screen interface
cat /sys/kernel/debug/gpio
to view the gpio status, and confirm whether the gpio configuration is normal

Note: Turn on the pwm backlight first, and then enable the lvds output, which will result in a white screen ( pwm backlight enable delay > lvds screen enable delay ( 先使能lvds后使能背光).

---

3. The general process of driving?

The general process of the driver is as follows:

1. Initialization : Perform some necessary initialization operations, such as setting pin modes, initializing devices, etc.
2. Configuration parameters : According to hardware requirements or user requirements, configure corresponding parameters, such as PWM cycle, duty cycle, polarity, etc.
3. Enable device : Turn on the corresponding device or module, such as enabling SPI transmission or enabling I2C bus.
4. Operation device : perform specific operations, such as sending instructions or data to the device, receiving data returned by the device, etc.
5. Close the device : When the operation is completed, close the device or module, release related resources, and do a good job in the aftermath.

4. Interrupt? Linux interrupt processing flow? What happens when an interruption comes? Synchronize? What is synchronization for?

Interruption:
When the CPU is executing an instruction, it receives an interrupt signal and turns to execute the pre-set code, and then returns to the original instruction stream to continue executing after the execution is completed. into 硬件中断和软件中断.

interrupt flow

1. After the CPU receives the interrupt signal, it will save the register data such as ESP and CS that can restore the current execution state flow to the kernel stack.
   Basically, the design form of dual stack is adopted. The CPU will judge the current state, first switch the user stack to the kernel stack, and then save the data.

2. Get the interrupt vector number.
   Each interrupt signal has an interrupt vector number, which is an integer. When the CPU receives an interrupt signal, it will query the interrupt vector table according to the interrupt vector number of the signal, and then call the corresponding processing function of the vector table.
   Correspondence between interrupt vector numbers and interrupt signals: For CPU exceptions, the vector numbers are specified by the CPU architecture standard. For peripherals, their vector number is dynamically applied by the device driver. For IPI interrupt and instruction interrupt, the vector number is specified by the kernel.

3. Find the corresponding gate descriptor from the interrupt vector table according to the interrupt vector number, and after doing a security check on the descriptor, the CPU starts to execute the interrupt processing function (that is, the segment offset in the gate descriptor). The IRET instruction is executed at the end of the interrupt processing function, and this instruction will jump back to the original instruction to continue execution according to the data previously stored on the stack.

Synchronization:
After the operating system introduces the process concept and the process becomes a scheduling entity, 系统就具备了并发运行多个进程的能力，但也导致了系统中各个进程之间的资源竞争和共享. In addition, because of the introduction of interrupts, exception mechanisms, and kernel mode preemption, these kernel running paths (processes) run in an interleaved manner.
For kernel paths where these interleaved paths run, the necessary synchronization measures are not taken. There will be interleaved access and changes to some important data structures. This leads to inconsistencies in the state of these data structures, which in turn leads to system crashes.
In order to ensure the efficient, stable and orderly operation of the system, Linux must adopt a synchronization mechanism.

1. Atomic operation
   The atomic operation mainly protects a shared variable in the kernel to prevent the variable from being accessed simultaneously and causing data out of synchronization.

2. Semaphore
   Semaphores generally implement mutual exclusion operations, but you can specify the number of processes in the critical section. When the specified number is 1, it means that this is a mutual exclusion semaphore.

3. Spin lock
   Protection for data structures or variables
   Protection for critical section code

   The global variable V represents the lock; when V=1, it is in the locked state, and when V=0, it is in the unlocked state; the
   spin lock mechanism only agrees that the only running path holds the spin lock. Suppose code on processor A wants to enter a critical section. Just read the value of V first. Assuming that V!=0 indicates that it is in a locked state, indicating that codes of other processors are accessing shared data, then processor A enters a busy waiting state (spinning). Suppose V=0. Indicates that no code on other processors currently enters the critical section, and processor A can access the critical resource at this time.

   .
   .
   .

---

Five. Linux general driver model

The Linux device driver model includes device, bus, class and driver, which are interrelated.

Bus bus:

Device:
Each device is described by a device structure. The device structure contains some general information about the device.

When a new device is encountered, a new device structure needs to be defined, and device is a member of the new structure. In this way, some information of the new device can be defined in the new structure, and the general information of the device is represented by the device structure.

drive:

1. Struct device_driver is the abstraction of the driver in the kernel driver framework

2. Key element 1: name, the name of the driver, is often used as the basis for matching the driver and the device

3. Key element 2: probe, the detection function of the driver, used to detect whether a device can be managed by the driver

kind:

1. Related structures: struct class and struct class_device

2. The use of udev is inseparable from class

3. The real meaning of class is to serve as a multi-device container of a class with the same attribute.
   Purpose: In order to classify and manage various devices, class also puts some "labels" on each class while classifying, which is also the infrastructure provided by the device driver model for us to write drivers.