/Documentation/driver-model/platform.txt
【部分翻译可能不准确，希望高人不吝赐教！】
Platform Devices and Drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See <linux/platform_device.h> for the driver model interface to the
platform bus: platform_device, and platform_driver. This pseudo-bus
is used to connect devices on busses with minimal infrastructure,
like those used to integrate peripherals on many system-on-chip
processors, or some "legacy" PC interconnects; as opposed to large
formally specified ones like PCI or USB.
Platform devices
~~~~~~~~~~~~~~~~
Platform devices are devices that typically appear as autonomous
entities in the system. This includes legacy port-based devices and
host bridges to peripheral buses, and most controllers integrated
into system-on-chip platforms. What they usually have in common
is direct addressing from a CPU bus. Rarely, a platform_device will
be connected through a segment of some other kind of bus; but its
registers will still be directly addressable.
Platform devices are given a name, used in driver binding, and a
list of resources such as addresses and IRQs.
Platform drivers
~~~~~~~~~~~~~~~~
Platform drivers follow the standard driver model convention, where
discovery/enumeration(枚举) is handled outside the drivers, and drivers
provide probe() and remove() methods. They support power management
and shutdown notifications using the standard conventions（惯例）.【使用标
准的规范，驱动部分支持电源管理以及关机通知】
Note that probe() should general verify that the specified device hardware
actually exists; sometimes platform setup code can't be sure. The probing
can use device resources, including clocks, and device platform_data.
【probe()通常应确认指定的设备是否真正存在；有时，platform的setup代码是靠不住
的。probe()可以使用设备的资源，包括时钟和设备的platform_data】
Platform drivers register themselves the normal way:
Or, in common situations where the device is known not to be hot-pluggable,
the probe() routine can live in an init section to reduce the driver's
runtime memory footprint:
Device Enumeration
~~~~~~~~~~~~~~~~~~
As a rule, platform specific (and often board-specific) setup code will
register platform devices:
The general rule is to register only those devices that actually exist,
but in some cases extra devices might be registered. For example, a kernel
might be configured to work with an external network adapter that might not
be populated(板载) on all boards, or likewise to work with an integrated controller
that some boards might not hook up(衔接) to any peripherals.
In some cases, boot firmware will export tables(输出表格) describing the devices
that are populated on a given board. Without such tables, often the
only way for system setup code to set up the correct devices is to build
a kernel for a specific target board. Such board-specific kernels are
common with embedded and custom systems development.
In many cases, the memory and IRQ resources associated with the platform
device are not enough to let the device's driver work. Board setup code
will often provide additional information using the device's platform_data
field to hold additional information.
【在很多情况下，由platform device提供的相关的memory和IRQ资源信息不足以让device
driver工作。板子的setup代码通常还使用设备的platform_data域来提供额外的信息。】
Embedded systems frequently need one or more clocks for platform devices,
which are normally kept off until they're actively needed (to save power).
System setup also associates those clocks with the device, so that that
calls to clk_get(&pdev->dev, clock_name) return them as needed.
【嵌入式系统中的platform devices常常需要1个或多个时钟，为了节省功耗，在不需要它们时，
它们通常会被隔离。系统setup也向device提供这些时钟，设备可以通过clk_get(&pdev->dev,clock_name)
获得他们想要的。】
Legacy Drivers: Device Probing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some drivers are not fully converted to the driver model, because they take
on a non-driver role: the driver registers its platform device, rather than
leaving that for system infrastructure. Such drivers can't be hotplugged
or coldplugged, since those mechanisms require device creation to be in a
different system component than the driver.
【一些(老式)驱动并不能完整的转换为现在的驱动模型，因为它们扮演着一个“非驱动”的角色：
这种驱动注册它的platform device，而不是留给系统底层结构去做。这种驱动不能支持热拔插
或者冷拔插，因为这种机制需要非驱动的不同系统组件来创建设备。】
The only "good" reason for this is to handle older system designs which, like
original IBM PCs, rely on error-prone "probe-the-hardware" models for hardware
configuration. Newer systems have largely abandoned that model, in favor of
bus-level support for dynamic configuration (PCI, USB), or device tables
provided by the boot firmware (e.g. PNPACPI on x86). There are too many
conflicting options about what might be where, and even educated（有根据的） guesses by
an operating system will be wrong often enough to make trouble.
This style of driver is discouraged. If you're updating such a driver,
please try to move the device enumeration to a more appropriate location(更合适的位置),
outside the driver. This will usually be cleanup, since such drivers
tend to(往往) already have "normal" modes, such as ones using device nodes that
were created by PNP or by platform device setup.
None the less（依然）, there are some APIs to support such legacy drivers. Avoid
using these calls except with such hotplug-deficient drivers.
You can use platform_device_alloc() to dynamically allocate a device, which
you will then initialize with resources and platform_device_register().
A better solution is usually:
You can use platform_device_register_simple() as a one-step call to allocate
and register a device.
Device Naming and Driver Binding
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The platform_device.dev.bus_id（注意格式） is the canonical(规范的) name for the devices.
It's built from two components:
* platform_device.name ... which is also used to for driver matching.
* platform_device.id ... the device instance(实例) number, or else "-1"
to indicate there's only one.
These are concatenated(连接起来的), so name/id "serial"/0 indicates bus_id "serial.0", and
"serial/3" indicates bus_id "serial.3"; both would use the platform_driver
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
and use the platform_driver called "my_rtc".
Driver binding is performed automatically by the driver core, invoking
driver probe() after finding a match between device and driver. If the
probe() succeeds, the driver and device are bound as usual. There are
three different ways to find such a match:
【driver core将会自动的执行驱动绑定工作，即在找到相匹配的device和driver后，调用驱动的probe()；
如果probe()执行成功，则driver和device像往常一样被绑定在一起。有三种不同的方法可以找到一组匹配】
- Whenever a device is registered, the drivers for that bus are
checked for matches. Platform devices should be registered very
early during system boot.
【当一个device被注册时，该总线上的驱动被检测是否与该设备匹配。因此，在系统
启动较早的时候，platform devices就应该被注册。】
- When a driver is registered using platform_driver_register(), all
unbound devices on that bus are checked for matches. Drivers
usually register later during booting, or by module loading.
【当一个driver被platform_driver_register()注册时，该总线上所有没有被绑定的devices被检测是否
与该驱动匹配。通常，该驱动在启动过程的后期就被注册，或者被module加载。】
- Registering a driver using platform_driver_probe() works just like
using platform_driver_register(), except that the driver won't
be probed later if another device registers. (Which is OK, since
this interface is only for use with non-hotpluggable devices.)
【使用platform_driver_probe()和使用platform_driver_register()注册一个驱动是一样的，不同的
是，如果当其他的devices注册的时候，驱动不再被probed。不过，这样也无所谓，因为这种接口仅仅
在非热拔插设备上使用。】
2743
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
