Commit 0d6a4b98 authored by Randy Dunlap's avatar Randy Dunlap Committed by Alessandro Rubini

Documentation: language and style fixes

Signed-off-by: 's avatarRandy Dunlap <rdunlap@xenotime.net>
Acked-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
parent f216c7a3
......@@ -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
......
......@@ -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.
......@@ -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.
......@@ -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
......
......@@ -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.
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:
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment