Tag Archives: Linux system

Platform Device and Platform Driver @ Linux

I was trying to learn Linux device driver and  system programming. Two simple question i had was, how does the Linux kernel know, which devices are present  and what resources(bus channel, interrupts, power on switch, etc..) it is using ? what are the drivers for them ?

After going through Linux kernel source code and exploring couple of kernel documents I sum up that  “Platform Device, Platform Driver and Platform Data” is the solution of  my questions. In this post i am trying to highlight the concept of platform device and platform driver with the help of  pseudo code.

Unified driver model has introduced in the Linux kernel 2.6 release.
There are several kind of devices are connected to CPU using different type of bus interfaces.
eg : PCI, ISA, I2C, USB, SPI, etc…
According to working mechanism, these buses can be divided in to two categories.

1. Discover-able :
Now a days buses like PCI and USB, which have discover-ability built into them. When a device is connected to a bus, it receives a unique identification which will be used for further communication with the CPU. Which menace that, device sitting on a PCI/USB bus can tell the system what sort of device it is and where its resources are. So the kernel can, enumerate the available device and driver to initialized device using the probe method normally. This kind of bus mechanism usually found with x86 architecture(PC).

2 Non discover-able :
Embedded system usually don’t have a sophisticated bus mechanism found in PC systems. we have buses like I2c or SPI. Devices attached to these buses are not discoverable in the above sense as i tried to explain. The OS has to be explicitly told that, for example, a EEPROM is connected on the I2C bus at an address of 0×DA. In this case, platform device/driver comes in a picture.

So basically, Platform devices are inherently not discoverable, i.e. the hardware cannot say “Hey! I’m present!” to the software .

Unlike PCI or USB devices, I2C devices are not enumerated at the hardware level (at run time). Instead, the software must know (at compile time) which devices are connected on each I2C bus segment. So USB and PCI are not platform devices.

In the embedded and system-on-chip world, non – discoverable devices are increasing rapidly. So basically all non discoverable devices are connected to the virtual bus and declares its name. This virtual bus is known as “platform bus”. On the other side, driver requests a device with the same name on the bus.

The whole story starts from board file. A board file is heart of each Linux kernel, which specifies all the information about what and how peripherals are connected to processor. eg: devices present on buses such as SPI and I2c. In the board file you can find all the devices are registered with the name and appropriate data. This data is known as the platform data. This Platform data will pass to driver. Generally Platform data is the device specific data. Eg: Bus id, interrupts ,etc ..

Here i have created pseudo device and driver to develop clear understanding of all these. In your board header file declare a private data structure according to resources used by your device. Here, i am declaring test_platfrom_data. The snippet 1 below will provide more information about members of test_platform_data.

Snippet 1

Snippet 1

In my board c file i have created instance of this structure  with appropriate data. This  user defined structure will passed to the driver w. Snippet 2 will provide you details about private data which is assigned to structure instance.

Snippet 2

Snippet 2

Now its time to define platform device in board file. In Linux kernel struct platform_device is declared. Lets create a instance of this structure. This will passed to kernel for registration of platform device. Snippet 3 will show you definition of platform device.

Snippet 3

Snippet 3

The main important point is the name of device.  Here in my case name of my device is “drivertest”.  From board init function add line(shown by snippet 4) to register this platform device.

After this edition in board file, compile kernel using appropriate cross compiler and boot your board with this kernel.

Snippet 4

Snippet 4

After success full booting of board, start making driver(.ko) file  for your registered device. Structure platfrom_driver is used to register platform driver. Here, snippet below shows the definition of platfrom_driver structure.  Register platform driver in init function using platfrom_driver_register.

Snippet 5

Snippet 5

Here, the impotent thing is the name of driver. Name of driver is as same as the name of device(in board file). On the registration of new platform driver, linux kernel compare its name with the previously defined all platform device name. If the match is found the probe function of the driver is called with  appropriate data which is responsible to initialize the device. The whole device structure is passed through probe function. The snippet below shows the subroutine for probe function.

Snippet 6

Snippet 6

In the probe function of driver,  i have extracted platform data from probe, which is assigned to the device at the booting time. This platform_data contains all the low level information about device. On the basis of this data, probe function initialize the device and irq using this data. Generally this data contains the information about module id, data rate, interrupt   etc..

I have compiled module and the output i is pasted below which shows the platform data is extracted from the probe.


output sdfdfas

This is how the whole initialization of non dicoverable devices works.


Filed under Linux Device Driver, Platfrom device

Add new module to Linux kernel source code

Kernel modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the

functionality of the kernel without the need to reboot the system. If you want to add your code(module) to a Linux

kernel, the most basic way to do that is to add your source files to the kernel source tree, add entry of your module in

appropriate Makefile and Kconfig file  and recompile the kernel. In fact, the kernel configuration process consists

mainly of choosing which files to include in the kernel to be compiled. All the device drivers are written using these

loadable modules.Let us add a very basic sample kernel module. Add this file to drivers/gpio directory in Linux kernel

source tree.

vim ./drivers/gpio/helloWorld.c helloWorld



Now we need to add configuration setting, so that we can add or remove this module from the By the time of Linux

kernel configuration(You can configure it from “make menuconfig”).  To do that add your modules entry in ./driver

/gpio/Kconfig file. Add below codes to ./drivers/gpio/Kconfig file.

vim ./drivers/gpio/Kconfig

vim ./drivers/gpio/Kconfig

Line 1 is the macro with using which our module can be configured.Line 3 states that this option can only be enabled if

CONFIG_ARM is enabled . Next We have to inform kernel to compile hello_world.c when HELLO_WORLD_MODULE

configuration is enabled.Add this to ./drivers/gpio/Makefile.

vim ./drivers/gpio/Makefile

vim ./drivers/gpio/Makefile

We have successfully added a new module to Linux kernel. Now lets test our new module with Linux kernel.To do that

first we need to give tool chain name to CROSS_COMPILE flag and architecture name to ARCH flag in Linux terminal.

Compilation process

Compilation process

Now configuration menu will appear. Navigate to Device Drivers—>GPIO Support —>Hello World Module  and enable

it. Now start compiling kernel and modules.

Your module will get inserted as a part of kernel.

Enjoy !!!


Filed under Uncategorized