redonkable
/
remarkable-uboot
1
0
Fork 0
Code Releases Activity

docs: driver-model: Fix spelling 

Signed-off-by: Chris Packham <judge.packham@gmail.com>
utp
Chris Packham 2014-06-07 10:35:55 +12:00 committed by Tom Rini
parent 7050f0de7e
commit 34e4a2ec0a
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
doc/driver-model/README.txt
View File

@ -20,7 +20,7 @@ Terminology
----------- -----------
Uclass - a group of devices which operate in the same way. A uclass provides Uclass - a group of devices which operate in the same way. A uclass provides
a way of accessing invidual devices within the group, but always a way of accessing individual devices within the group, but always
using the same interface. For example a GPIO uclass provides using the same interface. For example a GPIO uclass provides
operations for get/set value. An I2C uclass may have 10 I2C ports, operations for get/set value. An I2C uclass may have 10 I2C ports,
4 with one driver, and 6 with another. 4 with one driver, and 6 with another.
@ -120,7 +120,7 @@ What is going on?
----------------- -----------------
Let's start at the top. The demo command is in common/cmd_demo.c. It does Let's start at the top. The demo command is in common/cmd_demo.c. It does
the usual command procesing and then: the usual command processing and then:
struct udevice *demo_dev; struct udevice *demo_dev;
@ -228,7 +228,7 @@ The data can be interpreted by the drivers however they like - it is
basically a communication scheme between the board-specific code and basically a communication scheme between the board-specific code and
the generic drivers, which are intended to work on any board. the generic drivers, which are intended to work on any board.
Drivers can acceess their data via dev->info->platdata. Here is Drivers can access their data via dev->info->platdata. Here is
the declaration for the platform data, which would normally appear the declaration for the platform data, which would normally appear
in the board file. in the board file.
@ -272,7 +272,7 @@ method reads the information out of the device tree and puts it in
dev->platdata. Then the probe method is called to set up the device. dev->platdata. Then the probe method is called to set up the device.
Note that both methods are optional. If you provide an ofdata_to_platdata Note that both methods are optional. If you provide an ofdata_to_platdata
method then it wlil be called first (after bind). If you provide a probe method then it will be called first (after bind). If you provide a probe
method it will be called next. method it will be called next.
If you don't want to have the platdata automatically allocated then you If you don't want to have the platdata automatically allocated then you
@ -310,7 +310,7 @@ Changes since v1
For the record, this implementation uses a very similar approach to the For the record, this implementation uses a very similar approach to the
original patches, but makes at least the following changes: original patches, but makes at least the following changes:
- Tried to agressively remove boilerplate, so that for most drivers there - Tried to aggressively remove boilerplate, so that for most drivers there
is little or no 'driver model' code to write. is little or no 'driver model' code to write.
- Moved some data from code into data structure - e.g. store a pointer to - Moved some data from code into data structure - e.g. store a pointer to
the driver operations structure in the driver, rather than passing it the driver operations structure in the driver, rather than passing it