diff --git a/Documentation/zio/00-INDEX b/Documentation/zio/00-INDEX
index 093d9fb1b47f1ed81db3f43a38ce132ff128e926..e580a430ad507e68e59dac5b011e0c31656c5057 100644
--- a/Documentation/zio/00-INDEX
+++ b/Documentation/zio/00-INDEX
@@ -3,7 +3,7 @@
device.txt
- description of what ZIO devices (and csets and channels) are.
buffer.txt
- - description of the buffer, it's methods and how it is used.
+ - description of the buffer, its methods and how it is used.
trigger.txt
- what is a trigger and what's its role in ZIO.
modules.txt
diff --git a/Documentation/zio/buffer.txt b/Documentation/zio/buffer.txt
index f80e63a661db89d4a7ec57635f2a41e5789dd181..08b90fae8ee37009218801a70abba4106b4e87bd 100644
--- a/Documentation/zio/buffer.txt
+++ b/Documentation/zio/buffer.txt
@@ -15,7 +15,7 @@ Please read <linux/zio-buffer.h> together with this file.
Buffers may be device-specific or generic. A generic buffer called
"kmalloc" is provided within zio-core; it uses kmalloc for allocation
data blocks. Such buffer is activated by default on all new csets
-being registered but is not special in any other way, you can write
+being registered but is not special in any other way. You can write
your own generic buffer (and if it's better than ours, we may use it
as default buffer in future releases).
@@ -48,17 +48,17 @@ reference to better understand the role of each method:
The create() operation allocates and initializes an instance of the
buffer type. It is called by ZIO when a channel is opened for the
-first time. The operation return a zio buffer instance (zio_bi),
+first time. The operation returns a zio buffer instance (zio_bi),
which is the generic descriptor of a buffer instance. ZIO handles
only zio_bi, so complex buffer structures must contain the zio_bi
structure and use container_of() to access the private enclosing
structure.
-Destroy() deallocates a buffer instance. ZIO calls destroy when the
+destroy() deallocates a buffer instance. ZIO calls destroy() when the
channel is unregistered from ZIO or when the user assigns a different
buffer type to the channel.
-When the control/data devices are closed, ZIO doesn't call destroy, so
+When the control/data devices are closed, ZIO doesn't call destroy(), so
incoming data can queue up while the application leaves it closed
(e.g., a shell script). Actually, the release file operation is not
handled by ZIO, so it couldn't call destroy on close even if it wanted
@@ -75,7 +75,7 @@ output, allocation happens on user write and free is called by the
trigger when it is done. Thus, the functions are sometimes called by
buffer code itself, and sometimes by the trigger. The generic
structure hosting a block is zio_block which contain both data
-(samples) and control informations. If needed, buffers may use a more
+(samples) and control information. If needed, buffers may use a more
complex structure, which will include zio_block, which is the only
structure that ZIO handles; by using container_of you can retrieve the
enclosing complex structure used in your buffer
@@ -92,8 +92,8 @@ the trigger when it receives the first data block).
File Operations
===============
-This field hosts the file_operations used by the char devices (control and
-data) for every channel using this buffer type. When char devices are
+This structure holds the file_operations used by the char devices (control
+and data) for every channel using this buffer type. When char devices are
initially opened, the open method being run is within zio-code;
it kmallocs f->private_data before calling the buffer-specific open
method. The private data being used is:
@@ -109,6 +109,6 @@ ZIO_CDEV_CTRL or ZIO_CDEV_DATA. Every buffer is expected to
call zio_generic_release() at the end of its own release operation, or
used zio_generic_release() directly in the file operations.
-ZIO offers other generic file operations, that may be enough for your
-buffer code or not. See zio-buf-kmalloc.c for a working example of
+ZIO offers other generic file operations that may be enough for your
+buffer code or may not. See zio-buf-kmalloc.c for a working example of
buffer file operations.
diff --git a/Documentation/zio/device.txt b/Documentation/zio/device.txt
index 0c960e210cb67619afab0129a891233644aa52af..15ead3aa95cda9f234eb4d04ad2a62966fb352c8 100644
--- a/Documentation/zio/device.txt
+++ b/Documentation/zio/device.txt
@@ -2,7 +2,7 @@
ZIO Device
==========
-A device, registered through zio_register_device() is the description
+A device registered through zio_register_device() is the description
of an I/O peripheral. It is made up of channel-sets, called csets
from now on. A device may represent a PCI board or an SPI integrated
circuit or whatever it makes sense to manage from a single device driver.
@@ -13,7 +13,7 @@ array of csets.
=====
A cset (channel-set) is an homogeneous set of I/O channels. All
-channels in the set are feature the same physical characteristics;
+channels in the set feature the same physical characteristics;
moreover, a cset refers to a trigger object, so all channels in a set
are triggered by the same event. This is the typical use case for
logic analysers (digital input) or multi-probe scopes (analog input),
@@ -62,8 +62,6 @@ The full set of rules for data and control transfers is described
elsewhere (FIXME: link to other docs) but it is pretty intuitive once
you get the idea.
-See the "zio-dump" host tool in the top-level zio dir for an example
-of generic and simple input application that shows use of control and
+See the "zio-dump" host tool in the top-level zio directory for an example
+of a generic and simple input application that shows use of control and
data files.
-
-
diff --git a/Documentation/zio/modules.txt b/Documentation/zio/modules.txt
index b3df00aa2904863024ba8de8f9143e99c7e2e34c..cd87833d4f0e0db0e096b2f6e610a1b4bdc8eff6 100644
--- a/Documentation/zio/modules.txt
+++ b/Documentation/zio/modules.txt
@@ -28,7 +28,7 @@ data and returns zeroes as input data. It can be used to experiment
with generic triggers and as a sandbox for local modifications and
testing.
-The parport driver registers two output csets and two input cset.
+The parport driver registers two output csets and two input csets.
In each group one cset is byte-oriented and the other is bit-oriented.
The ad7888 is an SPI ADC we mounted on an ARM board. It's a real
@@ -38,7 +38,7 @@ type (our SPI master uses DMA) and its own data-driven trigger (even
if the data will be scanned by the CPU, so it can only work at low
data rates).
-The uart driver is a line discpline that can receive data from a
+The UART driver is a line discipline that can receive data from a
serial port. The first implementation expects to receive an endless
stream of 16-bit data, big endian (we used this to run on-board ADC on
cortex-m3), but we plan to extend it as a serious test case. You can
diff --git a/Documentation/zio/trigger.txt b/Documentation/zio/trigger.txt
index 95b426f29d2a64e976341ba6a9d0d6e276fc5205..9fbfaafd15a372a4ebf9a68162a5ba2027c31f1a 100644
--- a/Documentation/zio/trigger.txt
+++ b/Documentation/zio/trigger.txt
@@ -65,7 +65,7 @@ locally or notifying the user).
The method asks the trigger for a new block. It may be called by
the buffer, if it wants a block immediately. The trigger that offers
-this method (which may be NULL) is responsible of storing a block
+this method (which may be NULL) is responsible for storing a block
when available. Since driver->input_cset completes asynchronously, this
method can't return a block directly. The block that will be stored
may be shorter than what the trigger would have stored in the buffer
@@ -75,7 +75,7 @@ by itself.
The function is called by the device, and signals the trigger that
the input or output operation on the cset is over. For input, the
-trigger will push blocks to the buffer, for output it will release
+trigger will push blocks to the buffer; for output it will release
the blocks. zio-core offers zio_generic_data_done() for triggers
that don't need special handling.
@@ -103,7 +103,7 @@ data has already happened when the trigger interrupt runs, but this
doesn't change the software flow).
Hardware-driven triggers will need to make their own work by themselves,
-but ZIO offers this help macro to loop over all non-disabled channels:
+but ZIO offers this helper macro to loop over all non-disabled channels:
cset_for_each(struct zio_cset *cset, struct zio_channel *ch)
@@ -125,4 +125,3 @@ For output, drv->outoput_cset is called.
You can refer to "zio-trig-timer" for an example of a multi-instance
generic timer and to "zio-trig-app-request" for a non-conventional
implementation based on trigger-local file_operations.
-
diff --git a/README b/README
index d537353a396a17c95f5d9831ce9c6f84cbbbf040..02169108d737eb3bb72e372dbbed7736f806d594 100644
--- a/README
+++ b/README
@@ -1,5 +1,5 @@
-Zio is "the ultimate I/O framework". Is being developed on the open
+Zio is "the ultimate I/O framework". It is being developed on the open
hardware repository at http://www.ohwr.org/projects/zio .
This version is known to compile and run with kernels 2.6.34 onwards.
@@ -24,14 +24,14 @@ The timer trigger is a kernel-timer based trigger, that fires a block
transfer on a timely basis. You can use the "ms" parameter to set the
inter-block time, in milliseconds (the default is two seconds). You
can also pass the "nsamples" parameter to say how many samples are
-aquired at each trigger instance.
+acquired at each trigger instance.
With the core in place, you can load a driver:
insmod drivers/zio-zero.ko
zio-zero has a single channel-set (number 0) with three channels.
-They simulate three analog inputs, 8-bit per sample.
+They simulate three analog inputs, 8-bits per sample.
channel 0: returns zero forever
channel 1: returns random numbers
@@ -79,7 +79,7 @@ as nsample:
Data: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f
Data: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
-Zio dump is able to access several pairs of devices (control and data),
+zio-dump is able to access several pairs of devices (control and data),
and you can change the trigger and buffer attributes for the cset.
Example: