Documentation: language and style fixes

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Alessandro Rubini <rubini@gnudd.com>

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

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.

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.
-
-

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

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.
-

README

 
-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: