Platform device and drivers

Platform device and drivers
From <Linux/platform_device.h>, we can understand the driver model interfaces of platform Bus: platform_device and platform_driver. Unlike PCI and USB, the virtual bus platform bus uses the smallest structure to integrate various peripherals on SOC processer, or to interconnect various "Legacy.

Platform Device
A typical platform device is a variety of autonomous devices in the system, including a variety of port-based device and host bridging on the peripheral bus, and a variety of controllers integrated on the SOC platform. They all have a feature that the CPU bus can be directly addressable, or in special cases platform_device is connected to other bus, but its registers can be directly addressable.
The platform device has a name used to bind the driver, and a list of resources such as interrupt and address.

Struct platform_device {
Const char * Name;
U32 ID;
Struct device dev;
U32 num_resources;
Struct resource * resource;
};

Platform drivers
The Platform driver meets the standard driver model. The driver's discovery/enumeration is performed outside the driver. The driver provides the probe () and remove () methods. platfomr dirvers provides power management and shutdown notifications through standard models.

Struct platform_driver {
INT (* probe) (struct platform_device *);
INT (* remove) (struct platform_device *);
Void (* shutdown) (struct platform_device *);
INT (* suspend) (struct platform_device *, pm_message_t State );
INT (* suspend_late) (struct platform_device *, pm_message_t State );
INT (* resume_early) (struct platform_device *);
INT (* resume) (struct platform_device *);
Struct device_driver driver;
};

The probe () function must verify whether the hardware of the specified device exists. Probe () can use the resources of the device, including the clock and platform_data, platform driver can use the following functions to register the driver:
Int platform_driver_register (struct platform_driver * DRV );
Generally, devices cannot be hot-swappable. Therefore, you can put the probe () function in the init segment to save the memory overhead during driver running:
Int platform_driver_probe (struct platform_driver * DRV,
INT (* probe) (struct platform_device *))

Device Enumeration
As a rule, the Platform (generally board-level) Startup code registers all platform devices:
Int platform_device_register (struct platform_device * pdev );
Int platform_add_devices (struct platform_device ** pdevs, int ndev );
Generally, only the actually existing devices will be registered, but there are also special circumstances. For example, the kernel may need to work with an external network adapter that is not on the board, or controllers that are not attached to any bus.
In general, the firmware Startup Process outputs a table of all devices on the board. If this table is not available, the only way to establish the correct device using the system startup code is to compile a kernel for a specific board. This board-specific kernel is widely used in embedded and general system development.
In most cases, the device's memory and IRQ resources are insufficient for the driver to work properly. The setup code of the Board uses the platform_data field of the device to provide additional resources for the device.
Devices in the embedded system frequently use one or more clocks. These clocks are turned on only when they are actually used for power saving, the system allocates a clock for the device during startup. You can use clk_get (& pdev-> Dev, clock_name) to obtain the required clock.

Legacy drivers: Device probing
Some drivers do not fully comply with the standard driver model. These drivers register their own platform device instead of letting the system complete registration. This is not worth pushing
Recommended, mainly used to be compatible with old devices. You can use the following APIs to support these legacy drivers. Generally, these APIs are used on drivers that do not support hot swapping:
Struct platform_device * platform_device_alloc (
Const char * Name, int ID );
You can use platform_device_alloc to dynamically create a device. A better way is to dynamically create a device using the following function and register the device to the system:
Struct platform_device * platform_device_register_simple (
Const char * Name, int ID,
Struct resource * res, unsigned int nres );

Device naming and driver binding
Platform_device.dev.bus_id is the name of a device on the bus. It contains two parts:
* Platform_device.name: The device name used for driver matching.
* The number of the platform_device.id device instance. If it is-1, only one device with the same name is available.
For example, if name/ID is "serial/1", its bus_id is serial.1. If name/ID is "serial/0", its bus_id is serial.0, if its name/ID is "serial/-1", its bus_id is serial.
The driver binding is automatically completed through the driver core. After matching the driver and device is completed, the probe () function is automatically executed. If the function is successfully executed, then the driver and device are bound together. There are three methods for matching drvier and device:
* When a device is registered, it searches for a matching driver on the bus. Generally, the platform device is registered very early when the system starts up.
* When a driver registers for [platform_driver_register ()], it traverses all the devices on the bus to find a match. During the startup process, the driver registration is generally relatively late, or when the module is loaded
* When a driver registers for [platform_driver_probe ()], the function is the same as using platform_driver_register (). The only difference is that it cannot be probe by other devices in the future, that is to say, this driver can only be bound to one device.

Platform device and platform driver are actually devices and drivers that can be directly addressable by the CPU bus. They are mounted on a virtual bus platform_bus_type and are a bus-specific device and driver. Similar to other bus-specific drivers, such as PCI. They all add a warpper to the device and device_driver to generate the device. Take a closer look at platform_device and you can see that it must contain a device Dev, and platform_driver is the same. It must contain a device_driver driver.
All devices are mounted to the bus by bus_id. Multiple devices can share one driver, but one device cannot correspond to multiple drivers. When the driver registers, it will find the device based on the device name. If no device is registered, it will fail. The registration process will use probe to apply for the corresponding resources and initialize the hardware. If probe is successfully executed, then the device and driver are bound successfully. When the device registers, it will also find the corresponding driver on the bus. if it finds it, it will try to bind it. The binding process is also to execute probe.