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

24 responses to “Platform Device and Platform Driver @ Linux

  1. Harshil Makwana

    Good Artical

  2. dat

    Thank you so much. I understand cleary about it from your text. ^-^

  3. Nilesh

    Bhargav…it’s a good article for driver beginner….nice atricle buddy

  4. Rajkamal

    Good article for begineer

  5. Your blogs are good, simple and informative. From Vim’s useful feature to Device Driver, ISR.
    Waiting for your next blog 🙂
    Thanks for article Bhargav.

  6. monik zalavadia

    good artical

  7. Raju

    Then how about discoverable devices on PCI/USB bus, how prob back call && driver intialisation in this case … as per my knowledge it will send some uevent on netlink, please help me to make it clear

    Thanks in advance .. 🙂

  8. shah.b

    Lets take an example of USB device.
    USB protocol has a hardware arbitration mechanism, which means that a valid USB device is detected at the hardware level. USB host controller detect this hardware events and driver for USB host controller converts this low level details in to USB protocol specific details. This details contains the product_id and vendor_id. USB core layer checks the driver claiming to serve for particulate product_id and vendor_id. If it finds such driver it calls probe for device initialization.

  9. Well explained.The board file concept was replaced by Device tree i guess(At least ARM based systems)

    • shah.b

      Yes, Device Tree has replace the board file. The advantage of device tree is if you change your configuration you dont need to recompile the whole kerel. Just replace the device tree file that’s it.
      But some old targets is still using board file.

  10. Very very Good article.. Thanks You Shah. Do you have any article explain about debug of kernel code for drivers? If so please share to me..

  11. ravi sankar

    Thankyou for sharing information.By studying this article i got clear idea about platform device,driver and data.

  12. Kushal

    One of the best and easy to understand article i found about platform devices and drivers. Good work. If possible explain the same concept w.r.t device tree.
    Since many days i am looking for T32 debugging , so if we can guide in simple way as u expalined about platform devices it will be more helpful.

    • shah.b

      I will try to explain about device tree with simplicity.

      By the way, What you want to understand about T32 debugging ?

      • Kushal

        Like basics of T32 , loading cmm script for arm , loading vmlinux and debugging errors like kernel panic, oops, device hung issues.
        If you know how to get trace logs from embedded device for eg: mobiles which use qualcomm MSM chips.
        Also commands used in T32 and their meaning.
        I know this is bit tough to explain but if you have any idea about T32 debugging then its worth to share i feel.
        Thanks in advance.

  13. Pragnesh

    Thank u very much

  14. Bharat

    Excellent article. Explaining the platform device/driver in very simple language. Thanks a lot.

  15. Sipan

    The article is very nice, easily understandable. But where should I Put my device driver(.ko) file so that the file gets discovered by the kernel ?

    • shah.b

      There are two ways to load module automatically on boot-up.
      1. Add it as part of kernel. In this approach you will get get separate .ko file. Module will be part of kernel and it will get loaded on boot-up.
      2. Modify initialisation script of kernel/OS to kernel custom module. This approach is useful when you have separate .ko file.

  16. Prashant

    Very well explained. Can you please give article on kernel debugging techniques ?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s