Linux mainline fork with MSM8998 patches | https://mainline.space | Currently supported devices:
OnePlus 5/5T, Xiaomi Mi 6, F(x)tec Pro¹ (2019 QX1000 model) & Sony Xperia XZ Premium (UNTESTED!)
5912827dfe
This change adds abstracted constants for National Instruments
terminal/signal names.
Some background:
There have been significant confusions over the past many years for users
when trying to understand how to connect to/from signals and terminals on
NI hardware using comedi. The major reason for this is that the actual
register values were exposed and required to be used by users. Several
major reasons exist why this caused major confusion for users:
1) The register values are _NOT_ in user documentation, but rather in
arcane locations, such as a few register programming manuals that are
increasingly hard to find and the NI-MHDDK (comments in in example
code). There is no one place to find the various valid values of the
registers.
2) The register values are _NOT_ completely consistent. There is no way
to gain any sense of intuition of which values, or even enums one
should use for various registers. There was some attempt in prior use
of comedi to name enums such that a user might know which enums should
be used for varying purposes, but the end-user had to gain a knowledge
of register values to correctly wield this approach.
3) The names for signals and registers found in the various register
level programming manuals and vendor-provided documentation are _not_
even close to the same names that are in the end-user documentation.
Similar confusion, albeit less, plagued NI's previous version of their own
proprietary drivers. Earlier than 2003, NI greatly simplified the
situation for users by releasing a new API that abstracted the names of
signals/terminals to a common and intuitive set of names. In addition,
this new API provided a much more common interface to use for most of NI
hardware.
The names added here mirror the names chosen and well documented by NI.
These names are exposed to the user via the comedilib user library. By
keeping the names in this format, in spite of the use of CamelScript,
maintenance will be greatly eased and confusion for users _and_ comedi
developers will be greatly reduced.
Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
||
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| firmware | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
See Documentation/00-INDEX for a list of what is contained in each file.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.