{"id":3187,"date":"2017-06-28T10:09:27","date_gmt":"2017-06-28T09:09:27","guid":{"rendered":"https:\/\/www.inovex.de\/blog\/?p=3187"},"modified":"2026-03-17T08:32:48","modified_gmt":"2026-03-17T07:32:48","slug":"migrating-an-embedded-android-setup-kernel-driver","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/migrating-an-embedded-android-setup-kernel-driver\/","title":{"rendered":"Migrating an embedded Android setup: Porting the Kernel Driver (Part 2)"},"content":{"rendered":"

After getting the display up and running<\/a>, we’ll have a look at the kernel drivers. It would be way too much work describing each kernel driver in detail, so I will concentrate on the changes needed to port them to the newer kernel version, 3.14 to be exact. A more thorough introduction to the sensor driver and the whole sensor integration can be found here<\/a>. Of course I learned a lot since I wrote my previous series of articles so I improved the driver quite a bit. Both devices are connected to the Wandboard via the I2C-bus, so they are working really similar at this level. Just controlling it, reading data and sleep management differs for each device.<\/p>\n

<\/p>\n

\"The<\/p>\n

Let’s continue with the changes we needed to apply to port each driver to the newer kernel version 3.14. In total, there are three drivers, one for the ultrasonic sensor, one for the Grove LCD RGB backlight and one for its text. As an example, we’ll use the RGB backlight driver.<\/p>\n

The first issue is ARM-related. Almost every single board has another layout, other interfaces available and nothing has defined addresses as compared to x86. Older Linux Kernels used so-called board description files, hard coded to the specific board kernel to handle this situation. But because that method is quite inflexible and each board needs a unique, non-reusable kernel, the device tree has now replaced it.<\/p>\n

The idea behind the device tree is to be able to use one Linux Kernel compiled for ARM (e.g. v7) on each board with dynamically loadable files describing the board\u2019s hardware interfaces, connected devices and so on. It is a very interesting and powerful system that enables you, amongst others, to expand or change a development board’s connections at run-time with so called device tree overlays. In short, that means it is e.g. possible to enable or disable an UART port without rebooting the board<\/a>.<\/p>\n

This also influences the way we match our I2C devices with the right drivers. Luckily, the changes are small and easy to understand.<\/p>\n

static struct i2c_board_info mxc_i2c2_board_info[] __initdata = {\r\n\r\n\t{\r\n\r\n\t\tI2C_BOARD_INFO(\"rgb1313M1\", 0x62),\r\n\r\n\t},\r\n\r\n};<\/pre>\n
This is a snippet from an old board description file, describing a fixed allocation between I2C bus no. 2, the I2C device with the address 0x62 and a driver with the name „rgb1313M1“.<\/p>\n
In the device tree system, this structure moved into the driver file, while driver\u2019s init function get extended by this parts:<\/p>\n
 \/\/ static int __init rgb1313M1_init(void)\r\n\r\nadapter = i2c_get_adapter(1);\r\n\r\nif (adapter == NULL) {\r\n\r\n\tPRINT (\"- i2c_get_adapter failed\");\r\n\r\n\tgoto exit_i2c_get_adapter;\r\n\r\n}\r\n\r\nrgb1313M1_client = i2c_new_device (adapter, &info_62);\r\n\r\nif (rgb1313M1_client == NULL) {\r\n\r\n\tgoto exit_i2c_get_adapter;\r\n\r\n}<\/pre>\n
The first one indicates the I2C bus we hope to find in the device, the second one matches the information about the device\u2019s address, the right driver and the right I2C bus. This bus information was previously coded in the board description file at the board info structure. You see, to change something at this point, less files than before need to be touched. In my opinion, the device tree is a significant improvement as long as you do not have to modify it.<\/p>\n
Sleep, where did you go?<\/h2>\n
The second, really big change in kernel space depends on sleep management. As you may know, there were significant modifications in Android 5 and 6 regarding this issue, but especially in the kernel everything depending on sleep changed.<\/p>\n
If you missed this development, you may ask yourself what happened to the old android power management system. It seems everything sleep related vanished.<\/p>\n
Previously, we had earlysuspend as a exclusive power management system in the Android kernel patch set. After the power management was completely rewritten, we now use runtime_pm infrastructure for all kernel related power management. With this, we got a consistent power management for both, Linux and Android, which is more flexible than earlysuspend. Because runtime_pm is not able to handle power management while a device is in use, there is a setInteractive hook in the HAL (Hardware Abstraction Layer) power module that could be used. Our use case however only requires runtime_pm, so I will just write about the kernel space changes. If you are more interested in the power management changes, just look at these sources:<\/p>\n