summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChris Packham <judge.packham@gmail.com>2014-06-07 10:35:55 +1200
committerTom Rini <trini@ti.com>2014-06-11 16:27:05 -0400
commit34e4a2ec0ad95cea910094e33761bddf56ad7fc0 (patch)
tree179476ed110f04146330340de101e0390f6c6255
parent7050f0de7e566862ed72ac4d86ddf21d929651c8 (diff)
downloadu-boot-imx-34e4a2ec0ad95cea910094e33761bddf56ad7fc0.zip
u-boot-imx-34e4a2ec0ad95cea910094e33761bddf56ad7fc0.tar.gz
u-boot-imx-34e4a2ec0ad95cea910094e33761bddf56ad7fc0.tar.bz2
docs: driver-model: Fix spelling
Signed-off-by: Chris Packham <judge.packham@gmail.com>
-rw-r--r--doc/driver-model/README.txt10
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index dcecb9a..a5035be 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -20,7 +20,7 @@ Terminology
-----------
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
operations for get/set value. An I2C uclass may have 10 I2C ports,
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
-the usual command procesing and then:
+the usual command processing and then:
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
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
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.
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.
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
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.
- 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