Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
R
Rk3576 Downstream U-Boot
Manage
Activity
Members
Labels
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Deploy
Releases
Package Registry
Model registry
Operate
Terraform modules
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Nicolas Frattaroli
Rk3576 Downstream U-Boot
Commits
34e4a2ec
Commit
34e4a2ec
authored
10 years ago
by
Chris Packham
Committed by
Tom Rini
10 years ago
Browse files
Options
Downloads
Patches
Plain Diff
docs: driver-model: Fix spelling
Signed-off-by:
Chris Packham
<
judge.packham@gmail.com
>
parent
7050f0de
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
doc/driver-model/README.txt
+5
-5
5 additions, 5 deletions
doc/driver-model/README.txt
with
5 additions
and
5 deletions
doc/driver-model/README.txt
+
5
−
5
View file @
34e4a2ec
...
...
@@ -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 in
di
vidual 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 proces
s
ing 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 acce
e
ss 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 w
l
il be called first (after bind). If you provide a probe
method then it wi
l
l 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 ag
g
ressively 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
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment