Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
This commit is contained in:
commit
9714d315d2
|
@ -28,6 +28,7 @@ modules.builtin
|
|||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
*.lzo
|
||||
*.patch
|
||||
*.gcno
|
||||
|
||||
|
|
|
@ -0,0 +1,7 @@
|
|||
filesystems/dnotify_test
|
||||
laptops/dslm
|
||||
timers/hpet_example
|
||||
vm/hugepage-mmap
|
||||
vm/hugepage-shm
|
||||
vm/map_hugetlb
|
||||
|
|
@ -32,8 +32,6 @@ DocBook/
|
|||
- directory with DocBook templates etc. for kernel documentation.
|
||||
HOWTO
|
||||
- the process and procedures of how to do Linux kernel development.
|
||||
IO-mapping.txt
|
||||
- how to access I/O mapped memory from within device drivers.
|
||||
IPMI.txt
|
||||
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
|
||||
IRQ-affinity.txt
|
||||
|
@ -84,6 +82,8 @@ blockdev/
|
|||
- info on block devices & drivers
|
||||
btmrvl.txt
|
||||
- info on Marvell Bluetooth driver usage.
|
||||
bus-virt-phys-mapping.txt
|
||||
- how to access I/O mapped memory from within device drivers.
|
||||
cachetlb.txt
|
||||
- describes the cache/TLB flushing interfaces Linux uses.
|
||||
cdrom/
|
||||
|
@ -168,6 +168,8 @@ initrd.txt
|
|||
- how to use the RAM disk as an initial/temporary root filesystem.
|
||||
input/
|
||||
- info on Linux input device support.
|
||||
io-mapping.txt
|
||||
- description of io_mapping functions in linux/io-mapping.h
|
||||
io_ordering.txt
|
||||
- info on ordering I/O writes to memory-mapped addresses.
|
||||
ioctl/
|
||||
|
|
|
@ -0,0 +1,20 @@
|
|||
What: /sys/kernel/debug/ec/*/{gpe,use_global_lock,io}
|
||||
Date: July 2010
|
||||
Contact: Thomas Renninger <trenn@suse.de>
|
||||
Description:
|
||||
|
||||
General information like which GPE is assigned to the EC and whether
|
||||
the global lock should get used.
|
||||
Knowing the EC GPE one can watch the amount of HW events related to
|
||||
the EC here (XY -> GPE number from /sys/kernel/debug/ec/*/gpe):
|
||||
/sys/firmware/acpi/interrupts/gpeXY
|
||||
|
||||
The io file is binary and a userspace tool located here:
|
||||
ftp://ftp.suse.com/pub/people/trenn/sources/ec/
|
||||
should get used to read out the 256 Embedded Controller registers
|
||||
or writing to them.
|
||||
|
||||
CAUTION: Do not write to the Embedded Controller if you don't know
|
||||
what you are doing! Rebooting afterwards also is a good idea.
|
||||
This can influence the way your machine is cooled and fans may
|
||||
not get switched on again after you did a wrong write.
|
|
@ -133,46 +133,6 @@ Description:
|
|||
The symbolic link points to the PCI device sysfs entry of the
|
||||
Physical Function this device associates with.
|
||||
|
||||
|
||||
What: /sys/bus/pci/slots/...
|
||||
Date: April 2005 (possibly older)
|
||||
KernelVersion: 2.6.12 (possibly older)
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
When the appropriate driver is loaded, it will create a
|
||||
directory per claimed physical PCI slot in
|
||||
/sys/bus/pci/slots/. The names of these directories are
|
||||
specific to the driver, which in turn, are specific to the
|
||||
platform, but in general, should match the label on the
|
||||
machine's physical chassis.
|
||||
|
||||
The drivers that can create slot directories include the
|
||||
PCI hotplug drivers, and as of 2.6.27, the pci_slot driver.
|
||||
|
||||
The slot directories contain, at a minimum, a file named
|
||||
'address' which contains the PCI bus:device:function tuple.
|
||||
Other files may appear as well, but are specific to the
|
||||
driver.
|
||||
|
||||
What: /sys/bus/pci/slots/.../function[0-7]
|
||||
Date: March 2010
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
If PCI slot directories (as described above) are created,
|
||||
and the physical slot is actually populated with a device,
|
||||
symbolic links in the slot directory pointing to the
|
||||
device's PCI functions are created as well.
|
||||
|
||||
What: /sys/bus/pci/devices/.../slot
|
||||
Date: March 2010
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
If PCI slot directories (as described above) are created,
|
||||
a symbolic link pointing to the slot directory will be
|
||||
created as well.
|
||||
|
||||
What: /sys/bus/pci/slots/.../module
|
||||
Date: June 2009
|
||||
Contact: linux-pci@vger.kernel.org
|
||||
|
|
|
@ -7,7 +7,7 @@ Description:
|
|||
added or removed dynamically to represent hot-add/remove
|
||||
operations.
|
||||
Users: hotplug memory add/remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/removable
|
||||
Date: June 2008
|
||||
|
@ -19,7 +19,7 @@ Description:
|
|||
identify removable sections of the memory before attempting
|
||||
potentially expensive hot-remove memory operation
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_device
|
||||
Date: September 2008
|
||||
|
@ -58,7 +58,7 @@ Description:
|
|||
by root to offline that section.
|
||||
# echo offline > /sys/devices/system/memory/memory22/state
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
|
||||
|
||||
|
||||
What: /sys/devices/system/memoryX/nodeY
|
||||
|
|
|
@ -197,7 +197,7 @@ Description: These files exist in every cpu's cache index directories.
|
|||
Currently, only AMD Family 10h Processors support cache index
|
||||
disable, and only for their L3 caches. See the BIOS and
|
||||
Kernel Developer's Guide at
|
||||
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf
|
||||
http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf
|
||||
for formatting information and other details on the
|
||||
cache index disable.
|
||||
Users: joachim.deguara@amd.com
|
||||
|
|
|
@ -33,19 +33,6 @@ Description: When read, this file returns the raw integer version number of the
|
|||
left. E.g. a returned value of 138 means 1.38
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/kone_driver_version
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the driver version.
|
||||
The format of the string is "v<major>.<minor>.<patchlevel>".
|
||||
This attribute is used by the userland tools to find the sysfs-
|
||||
paths of installed kone-mice and determine the capabilites of
|
||||
the driver. Versions of this driver for old kernels replace
|
||||
usbhid instead of generic-usb. The way to scan for this file
|
||||
has been chosen to provide a consistent way for all supported
|
||||
kernel versions.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
|
|
|
@ -114,3 +114,18 @@ Description:
|
|||
if this file contains "1", which is the default. It may be
|
||||
disabled by writing "0" to this file, in which case all devices
|
||||
will be suspended and resumed synchronously.
|
||||
|
||||
What: /sys/power/wakeup_count
|
||||
Date: July 2010
|
||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
Description:
|
||||
The /sys/power/wakeup_count file allows user space to put the
|
||||
system into a sleep state while taking into account the
|
||||
concurrent arrival of wakeup events. Reading from it returns
|
||||
the current number of registered wakeup events and it blocks if
|
||||
some wakeup events are being processed at the time the file is
|
||||
read from. Writing to it will only succeed if the current
|
||||
number of wakeup events is equal to the written value and, if
|
||||
successful, will make the kernel abort a subsequent transition
|
||||
to a sleep state if any wakeup events are reported after the
|
||||
write has returned.
|
||||
|
|
|
@ -331,7 +331,7 @@ o <ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/>
|
|||
|
||||
Mkinitrd
|
||||
--------
|
||||
o <ftp://rawhide.redhat.com/pub/rawhide/SRPMS/SRPMS/>
|
||||
o <https://code.launchpad.net/initrd-tools/main>
|
||||
|
||||
E2fsprogs
|
||||
---------
|
||||
|
@ -343,11 +343,11 @@ o <http://jfs.sourceforge.net/>
|
|||
|
||||
Reiserfsprogs
|
||||
-------------
|
||||
o <http://www.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.3.tar.gz>
|
||||
o <http://www.kernel.org/pub/linux/utils/fs/reiserfs/>
|
||||
|
||||
Xfsprogs
|
||||
--------
|
||||
o <ftp://oss.sgi.com/projects/xfs/download/>
|
||||
o <ftp://oss.sgi.com/projects/xfs/>
|
||||
|
||||
Pcmciautils
|
||||
-----------
|
||||
|
@ -387,18 +387,18 @@ o <http://sourceforge.net/projects/fuse>
|
|||
|
||||
mcelog
|
||||
------
|
||||
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/mcelog/>
|
||||
o <ftp://ftp.kernel.org/pub/linux/utils/cpu/mce/>
|
||||
|
||||
Networking
|
||||
**********
|
||||
|
||||
PPP
|
||||
---
|
||||
o <ftp://ftp.samba.org/pub/ppp/ppp-2.4.0.tar.gz>
|
||||
o <ftp://ftp.samba.org/pub/ppp/>
|
||||
|
||||
Isdn4k-utils
|
||||
------------
|
||||
o <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/isdn4k-utils.v3.1pre1.tar.gz>
|
||||
o <ftp://ftp.isdn4linux.de/pub/isdn4linux/utils/>
|
||||
|
||||
NFS-utils
|
||||
---------
|
||||
|
|
|
@ -389,7 +389,7 @@
|
|||
</para>
|
||||
<para>
|
||||
If your driver supports memory management (it should!), you'll
|
||||
need to set that up at load time as well. How you intialize
|
||||
need to set that up at load time as well. How you initialize
|
||||
it depends on which memory manager you're using, TTM or GEM.
|
||||
</para>
|
||||
<sect3>
|
||||
|
@ -399,7 +399,7 @@
|
|||
aperture space for graphics devices. TTM supports both UMA devices
|
||||
and devices with dedicated video RAM (VRAM), i.e. most discrete
|
||||
graphics devices. If your device has dedicated RAM, supporting
|
||||
TTM is desireable. TTM also integrates tightly with your
|
||||
TTM is desirable. TTM also integrates tightly with your
|
||||
driver specific buffer execution function. See the radeon
|
||||
driver for examples.
|
||||
</para>
|
||||
|
@ -443,7 +443,7 @@
|
|||
likely eventually calling ttm_bo_global_init and
|
||||
ttm_bo_global_release, respectively. Also like the previous
|
||||
object, ttm_global_item_ref is used to create an initial reference
|
||||
count for the TTM, which will call your initalization function.
|
||||
count for the TTM, which will call your initialization function.
|
||||
</para>
|
||||
</sect3>
|
||||
<sect3>
|
||||
|
@ -557,7 +557,7 @@ void intel_crt_init(struct drm_device *dev)
|
|||
CRT connector and encoder combination is created. A device
|
||||
specific i2c bus is also created, for fetching EDID data and
|
||||
performing monitor detection. Once the process is complete,
|
||||
the new connector is regsitered with sysfs, to make its
|
||||
the new connector is registered with sysfs, to make its
|
||||
properties available to applications.
|
||||
</para>
|
||||
<sect4>
|
||||
|
@ -581,12 +581,12 @@ void intel_crt_init(struct drm_device *dev)
|
|||
<para>
|
||||
For each encoder, CRTC and connector, several functions must
|
||||
be provided, depending on the object type. Encoder objects
|
||||
need should provide a DPMS (basically on/off) function, mode fixup
|
||||
need to provide a DPMS (basically on/off) function, mode fixup
|
||||
(for converting requested modes into native hardware timings),
|
||||
and prepare, set and commit functions for use by the core DRM
|
||||
helper functions. Connector helpers need to provide mode fetch and
|
||||
validity functions as well as an encoder matching function for
|
||||
returing an ideal encoder for a given connector. The core
|
||||
returning an ideal encoder for a given connector. The core
|
||||
connector functions include a DPMS callback, (deprecated)
|
||||
save/restore routines, detection, mode probing, property handling,
|
||||
and cleanup functions.
|
||||
|
|
|
@ -12,10 +12,12 @@
|
|||
<othername role="mi">O. C.</othername>
|
||||
<affiliation><address><email>rjkm@metzlerbros.de</email></address></affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Mauro</firstname>
|
||||
<surname>Chehab</surname>
|
||||
<othername role="mi">Carvalho</othername>
|
||||
<surname>Chehab</surname>
|
||||
<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
|
||||
<contrib>Ported document to Docbook XML.</contrib>
|
||||
</author>
|
||||
|
@ -23,12 +25,23 @@
|
|||
<copyright>
|
||||
<year>2002</year>
|
||||
<year>2003</year>
|
||||
<year>2009</year>
|
||||
<holder>Convergence GmbH</holder>
|
||||
</copyright>
|
||||
<copyright>
|
||||
<year>2009-2010</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
<revhistory>
|
||||
<!-- Put document revisions here, newest first. -->
|
||||
<revision>
|
||||
<revnumber>2.0.3</revnumber>
|
||||
<date>2010-07-03</date>
|
||||
<authorinitials>mcc</authorinitials>
|
||||
<revremark>
|
||||
Add some frontend capabilities flags, present on kernel, but missing at the specs.
|
||||
</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>2.0.2</revnumber>
|
||||
<date>2009-10-25</date>
|
||||
|
@ -63,7 +76,7 @@ Added ISDB-T test originally written by Patrick Boettcher
|
|||
|
||||
|
||||
<title>LINUX DVB API</title>
|
||||
<subtitle>Version 3</subtitle>
|
||||
<subtitle>Version 5.2</subtitle>
|
||||
<!-- ADD THE CHAPTERS HERE -->
|
||||
<chapter id="dvb_introdution">
|
||||
&sub-intro;
|
||||
|
|
|
@ -63,6 +63,7 @@ typedef enum fe_caps {
|
|||
FE_CAN_8VSB = 0x200000,
|
||||
FE_CAN_16VSB = 0x400000,
|
||||
FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */
|
||||
FE_CAN_TURBO_FEC = 0x8000000, /* frontend supports "turbo fec modulation" */
|
||||
FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
|
||||
FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
|
||||
FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */
|
||||
|
|
|
@ -64,8 +64,14 @@ a specific frontend type.</para>
|
|||
FE_CAN_BANDWIDTH_AUTO = 0x40000,
|
||||
FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
|
||||
FE_CAN_HIERARCHY_AUTO = 0x100000,
|
||||
FE_CAN_MUTE_TS = 0x80000000,
|
||||
FE_CAN_CLEAN_SETUP = 0x40000000
|
||||
FE_CAN_8VSB = 0x200000,
|
||||
FE_CAN_16VSB = 0x400000,
|
||||
FE_HAS_EXTENDED_CAPS = 0x800000,
|
||||
FE_CAN_TURBO_FEC = 0x8000000,
|
||||
FE_CAN_2G_MODULATION = 0x10000000,
|
||||
FE_NEEDS_BENDING = 0x20000000,
|
||||
FE_CAN_RECOVER = 0x40000000,
|
||||
FE_CAN_MUTE_TS = 0x80000000
|
||||
} fe_caps_t;
|
||||
</programlisting>
|
||||
</section>
|
||||
|
|
|
@ -218,6 +218,7 @@
|
|||
<!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml">
|
||||
<!ENTITY sub-driver SYSTEM "v4l/driver.xml">
|
||||
<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml">
|
||||
<!ENTITY sub-lirc_device_interface SYSTEM "v4l/lirc_device_interface.xml">
|
||||
<!ENTITY sub-remote_controllers SYSTEM "v4l/remote_controllers.xml">
|
||||
<!ENTITY sub-fdl-appendix SYSTEM "v4l/fdl-appendix.xml">
|
||||
<!ENTITY sub-close SYSTEM "v4l/func-close.xml">
|
||||
|
|
|
@ -28,7 +28,7 @@
|
|||
<title>LINUX MEDIA INFRASTRUCTURE API</title>
|
||||
|
||||
<copyright>
|
||||
<year>2009</year>
|
||||
<year>2009-2010</year>
|
||||
<holder>LinuxTV Developers</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -61,7 +61,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
|||
in fact it covers several different video standards including
|
||||
DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated
|
||||
to documment support also for DVB-S2, ISDB-T and ISDB-S.</para>
|
||||
<para>The third part covers other API's used by all media infrastructure devices</para>
|
||||
<para>The third part covers Remote Controller API</para>
|
||||
<para>For additional information and for the latest development code,
|
||||
see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
|
||||
<para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
|
||||
|
@ -86,7 +86,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
|||
</author>
|
||||
</authorgroup>
|
||||
<copyright>
|
||||
<year>2009</year>
|
||||
<year>2009-2010</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
|
@ -101,7 +101,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
|||
</revhistory>
|
||||
</partinfo>
|
||||
|
||||
<title>Other API's used by media infrastructure drivers</title>
|
||||
<title>Remote Controller API</title>
|
||||
<chapter id="remote_controllers">
|
||||
&sub-remote_controllers;
|
||||
</chapter>
|
||||
|
|
|
@ -393,7 +393,7 @@
|
|||
</para>
|
||||
<para>
|
||||
For documentation see
|
||||
<ulink url='http://www.torque.net/sg/sdebug26.html'>http://www.torque.net/sg/sdebug26.html</ulink>
|
||||
<ulink url='http://sg.danny.cz/sg/sdebug26.html'>http://sg.danny.cz/sg/sdebug26.html</ulink>
|
||||
</para>
|
||||
<!-- !Edrivers/scsi/scsi_debug.c -->
|
||||
</sect2>
|
||||
|
|
|
@ -1091,8 +1091,9 @@ signed 64-bit integer. Output devices should not send a buffer out
|
|||
until the time in the timestamp field has arrived. I would like to
|
||||
follow SGI's lead, and adopt a multimedia timestamping system like
|
||||
their UST (Unadjusted System Time). See
|
||||
http://reality.sgi.com/cpirazzi_engr/lg/time/intro.html. [This link is
|
||||
no longer valid.] UST uses timestamps that are 64-bit signed integers
|
||||
http://web.archive.org/web/*/http://reality.sgi.com
|
||||
/cpirazzi_engr/lg/time/intro.html.
|
||||
UST uses timestamps that are 64-bit signed integers
|
||||
(not struct timeval's) and given in nanosecond units. The UST clock
|
||||
starts at zero when the system is booted and runs continuously and
|
||||
uniformly. It takes a little over 292 years for UST to overflow. There
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
The GNU Free Documentation License 1.1 in DocBook
|
||||
Markup by Eric Baudais <baudais@okstate.edu>
|
||||
Maintained by the GNOME Documentation Project
|
||||
http://developer.gnome.org/projects/gdp
|
||||
http://live.gnome.org/DocumentationProject
|
||||
Version: 1.0.1
|
||||
Last Modified: Nov 16, 2000
|
||||
-->
|
||||
|
|
|
@ -0,0 +1,235 @@
|
|||
<section id="lirc_dev">
|
||||
<title>LIRC Device Interface</title>
|
||||
|
||||
|
||||
<section id="lirc_dev_intro">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>The LIRC device interface is a bi-directional interface for
|
||||
transporting raw IR data between userspace and kernelspace. Fundamentally,
|
||||
it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number
|
||||
of standard struct file_operations defined on it. With respect to
|
||||
transporting raw IR data to and fro, the essential fops are read, write
|
||||
and ioctl.</para>
|
||||
|
||||
<para>Example dmesg output upon a driver registering w/LIRC:</para>
|
||||
<blockquote>
|
||||
<para>$ dmesg |grep lirc_dev</para>
|
||||
<para>lirc_dev: IR Remote Control driver registered, major 248</para>
|
||||
<para>rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0</para>
|
||||
</blockquote>
|
||||
|
||||
<para>What you should see for a chardev:</para>
|
||||
<blockquote>
|
||||
<para>$ ls -l /dev/lirc*</para>
|
||||
<para>crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0</para>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section id="lirc_read">
|
||||
<title>LIRC read fop</title>
|
||||
|
||||
<para>The lircd userspace daemon reads raw IR data from the LIRC chardev. The
|
||||
exact format of the data depends on what modes a driver supports, and what
|
||||
mode has been selected. lircd obtains supported modes and sets the active mode
|
||||
via the ioctl interface, detailed at <xref linkend="lirc_ioctl"/>. The generally
|
||||
preferred mode is LIRC_MODE_MODE2, in which packets containing an int value
|
||||
describing an IR signal are read from the chardev.</para>
|
||||
|
||||
<para>See also <ulink url="http://www.lirc.org/html/technical.html">http://www.lirc.org/html/technical.html</ulink> for more info.</para>
|
||||
</section>
|
||||
|
||||
<section id="lirc_write">
|
||||
<title>LIRC write fop</title>
|
||||
|
||||
<para>The data written to the chardev is a pulse/space sequence of integer
|
||||
values. Pulses and spaces are only marked implicitly by their position. The
|
||||
data must start and end with a pulse, therefore, the data must always include
|
||||
an unevent number of samples. The write function must block until the data has
|
||||
been transmitted by the hardware.</para>
|
||||
</section>
|
||||
|
||||
<section id="lirc_ioctl">
|
||||
<title>LIRC ioctl fop</title>
|
||||
|
||||
<para>The LIRC device's ioctl definition is bound by the ioctl function
|
||||
definition of struct file_operations, leaving us with an unsigned int
|
||||
for the ioctl command and an unsigned long for the arg. For the purposes
|
||||
of ioctl portability across 32-bit and 64-bit, these values are capped
|
||||
to their 32-bit sizes.</para>
|
||||
|
||||
<para>The following ioctls can be used to change specific hardware settings.
|
||||
In general each driver should have a default set of settings. The driver
|
||||
implementation is expected to re-apply the default settings when the device
|
||||
is closed by user-space, so that every application opening the device can rely
|
||||
on working with the default settings initially.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_FEATURES</term>
|
||||
<listitem>
|
||||
<para>Obviously, get the underlying hardware device's features. If a driver
|
||||
does not announce support of certain features, calling of the corresponding
|
||||
ioctls is undefined.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_SEND_MODE</term>
|
||||
<listitem>
|
||||
<para>Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_REC_MODE</term>
|
||||
<listitem>
|
||||
<para>Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE
|
||||
are supported by lircd.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_SEND_CARRIER</term>
|
||||
<listitem>
|
||||
<para>Get carrier frequency (in Hz) currently used for transmit.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_REC_CARRIER</term>
|
||||
<listitem>
|
||||
<para>Get carrier frequency (in Hz) currently used for IR reception.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE</term>
|
||||
<listitem>
|
||||
<para>Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently,
|
||||
no special meaning is defined for 0 or 100, but this could be used to switch
|
||||
off carrier generation in the future, so these values should be reserved.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_REC_RESOLUTION</term>
|
||||
<listitem>
|
||||
<para>Some receiver have maximum resolution which is defined by internal
|
||||
sample rate or data format limitations. E.g. it's common that signals can
|
||||
only be reported in 50 microsecond steps. This integer value is used by
|
||||
lircd to automatically adjust the aeps tolerance value in the lircd
|
||||
config file.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_M{IN,AX}_TIMEOUT</term>
|
||||
<listitem>
|
||||
<para>Some devices have internal timers that can be used to detect when
|
||||
there's no IR activity for a long time. This can help lircd in detecting
|
||||
that a IR signal is finished and can speed up the decoding process.
|
||||
Returns an integer value with the minimum/maximum timeout that can be
|
||||
set. Some devices have a fixed timeout, in that case both ioctls will
|
||||
return the same value even though the timeout cannot be changed.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE}</term>
|
||||
<listitem>
|
||||
<para>Some devices are able to filter out spikes in the incoming signal
|
||||
using given filter rules. These ioctls return the hardware capabilities
|
||||
that describe the bounds of the possible filters. Filter settings depend
|
||||
on the IR protocols that are expected. lircd derives the settings from
|
||||
all protocols definitions found in its config file.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_GET_LENGTH</term>
|
||||
<listitem>
|
||||
<para>Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE).
|
||||
Reads on the device must be done in blocks matching the bit count.
|
||||
The bit could should be rounded up so that it matches full bytes.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_{SEND,REC}_MODE</term>
|
||||
<listitem>
|
||||
<para>Set send/receive mode. Largely obsolete for send, as only
|
||||
LIRC_MODE_PULSE is supported.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_{SEND,REC}_CARRIER</term>
|
||||
<listitem>
|
||||
<para>Set send/receive carrier (in Hz).</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_TRANSMITTER_MASK</term>
|
||||
<listitem>
|
||||
<para>This enables the given set of transmitters. The first transmitter
|
||||
is encoded by the least significant bit, etc. When an invalid bit mask
|
||||
is given, i.e. a bit is set, even though the device does not have so many
|
||||
transitters, then this ioctl returns the number of available transitters
|
||||
and does nothing otherwise.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_REC_TIMEOUT</term>
|
||||
<listitem>
|
||||
<para>Sets the integer value for IR inactivity timeout (cf.
|
||||
LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if
|
||||
supported by the hardware) disables all hardware timeouts and data should
|
||||
be reported as soon as possible. If the exact value cannot be set, then
|
||||
the next possible value _greater_ than the given value should be set.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_REC_TIMEOUT_REPORTS</term>
|
||||
<listitem>
|
||||
<para>Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By
|
||||
default, timeout reports should be turned off.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_REC_FILTER_{,PULSE,SPACE}</term>
|
||||
<listitem>
|
||||
<para>Pulses/spaces shorter than this are filtered out by hardware. If
|
||||
filters cannot be set independently for pulse/space, the corresponding
|
||||
ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_MEASURE_CARRIER_MODE</term>
|
||||
<listitem>
|
||||
<para>Enable (1)/disable (0) measure mode. If enabled, from the next key
|
||||
press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default
|
||||
this should be turned off.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE</term>
|
||||
<listitem>
|
||||
<para>To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE
|
||||
with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER
|
||||
with the upper bound.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_NOTIFY_DECODE</term>
|
||||
<listitem>
|
||||
<para>This ioctl is called by lircd whenever a successful decoding of an
|
||||
incoming IR signal could be done. This can be used by supporting hardware
|
||||
to give visual feedback to the user e.g. by flashing a LED.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SETUP_{START,END}</term>
|
||||
<listitem>
|
||||
<para>Setting of several driver parameters can be optimized by encapsulating
|
||||
the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a
|
||||
driver receives a LIRC_SETUP_START ioctl it can choose to not commit
|
||||
further setting changes to the hardware until a LIRC_SETUP_END is received.
|
||||
But this is open to the driver implementation and every driver must also
|
||||
handle parameter changes which are not encapsulated by LIRC_SETUP_START
|
||||
and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</section>
|
||||
</section>
|
|
@ -173,3 +173,5 @@ keymapping.</para>
|
|||
<para>This program demonstrates how to replace the keymap tables.</para>
|
||||
&sub-keytable-c;
|
||||
</section>
|
||||
|
||||
&sub-lirc_device_interface;
|
||||
|
|
|
@ -58,7 +58,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
|
|||
</contrib>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>awalls@radix.net</email>
|
||||
<email>awalls@md.metrocast.net</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
|
|
|
@ -53,8 +53,10 @@ input</refpurpose>
|
|||
automatically, similar to sensing the video standard. To do so, applications
|
||||
call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
|
||||
&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
|
||||
returned in the preset field of &v4l2-dv-preset;. When detection is not
|
||||
possible or fails, the value V4L2_DV_INVALID is returned.</para>
|
||||
returned in the preset field of &v4l2-dv-preset;. If the preset could not be
|
||||
detected because there was no signal, or the signal was unreliable, or the
|
||||
signal did not map to a supported preset, then the value V4L2_DV_INVALID is
|
||||
returned.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
|
@ -187,7 +187,7 @@ apply a patch.
|
|||
If you do not know where you want to start, but you want to look for
|
||||
some task to start doing to join into the kernel development community,
|
||||
go to the Linux Kernel Janitor's project:
|
||||
http://janitor.kernelnewbies.org/
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
It is a great place to start. It describes a list of relatively simple
|
||||
problems that need to be cleaned up and fixed within the Linux kernel
|
||||
source tree. Working with the developers in charge of this project, you
|
||||
|
@ -315,7 +315,7 @@ process is tracked with the tool patchwork. Patchwork offers a web
|
|||
interface which shows patch postings, any comments on a patch or
|
||||
revisions to it, and maintainers can mark patches as under review,
|
||||
accepted, or rejected. Most of these patchwork sites are listed at
|
||||
http://patchwork.kernel.org/ or http://patchwork.ozlabs.org/.
|
||||
http://patchwork.kernel.org/.
|
||||
|
||||
2.6.x -next kernel tree for integration tests
|
||||
---------------------------------------------
|
||||
|
@ -595,7 +595,7 @@ start exactly where you are now.
|
|||
|
||||
----------
|
||||
Thanks to Paolo Ciarrocchi who allowed the "Development Process"
|
||||
(http://linux.tar.bz/articles/2.6-development_process) section
|
||||
(http://lwn.net/Articles/94386/) section
|
||||
to be based on text he had written, and to Randy Dunlap and Gerrit
|
||||
Huizenga for some of the list of things you should and should not say.
|
||||
Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
|
||||
|
|
|
@ -581,7 +581,7 @@ to be handled by platform and generic code, not individual drivers.
|
|||
8. Vendor and device identifications
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
One is not not required to add new device ids to include/linux/pci_ids.h.
|
||||
One is not required to add new device ids to include/linux/pci_ids.h.
|
||||
Please add PCI_VENDOR_ID_xxx for vendors and a hex constant for device ids.
|
||||
|
||||
PCI_VENDOR_ID_xxx constants are re-used. The device ids are arbitrary
|
||||
|
|
|
@ -606,7 +606,7 @@ Suparna Bhattacharya"
|
|||
,Year="2006"
|
||||
,pages="v2 123-138"
|
||||
,note="Available:
|
||||
\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
|
||||
\url{http://www.linuxsymposium.org/2006/index_2006.php}
|
||||
\url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf}
|
||||
[Viewed January 1, 2007]"
|
||||
,annotation="
|
||||
|
|
|
@ -161,7 +161,7 @@ How to NOT write kernel driver by Arjan van de Ven:
|
|||
http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf
|
||||
|
||||
Kernel Janitor:
|
||||
http://janitor.kernelnewbies.org/
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
|
||||
GIT, Fast Version Control System:
|
||||
http://git-scm.com/
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ...
|
||||
|
||||
http://www.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html
|
||||
http://www.coraid.com/SUPPORT/EtherDrive-HBA
|
||||
|
||||
It has many tips and hints!
|
||||
|
||||
|
|
|
@ -0,0 +1,39 @@
|
|||
--- What is AppArmor? ---
|
||||
|
||||
AppArmor is MAC style security extension for the Linux kernel. It implements
|
||||
a task centered policy, with task "profiles" being created and loaded
|
||||
from user space. Tasks on the system that do not have a profile defined for
|
||||
them run in an unconfined state which is equivalent to standard Linux DAC
|
||||
permissions.
|
||||
|
||||
--- How to enable/disable ---
|
||||
|
||||
set CONFIG_SECURITY_APPARMOR=y
|
||||
|
||||
If AppArmor should be selected as the default security module then
|
||||
set CONFIG_DEFAULT_SECURITY="apparmor"
|
||||
and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
|
||||
|
||||
Build the kernel
|
||||
|
||||
If AppArmor is not the default security module it can be enabled by passing
|
||||
security=apparmor on the kernel's command line.
|
||||
|
||||
If AppArmor is the default security module it can be disabled by passing
|
||||
apparmor=0, security=XXXX (where XXX is valid security module), on the
|
||||
kernel's command line
|
||||
|
||||
For AppArmor to enforce any restrictions beyond standard Linux DAC permissions
|
||||
policy must be loaded into the kernel from user space (see the Documentation
|
||||
and tools links).
|
||||
|
||||
--- Documentation ---
|
||||
|
||||
Documentation can be found on the wiki.
|
||||
|
||||
--- Links ---
|
||||
|
||||
Mailing List - apparmor@lists.ubuntu.com
|
||||
Wiki - http://apparmor.wiki.kernel.org/
|
||||
User space tools - https://launchpad.net/apparmor
|
||||
Kernel module - git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
|
|
@ -14,7 +14,7 @@ telecom systems. In addition to an XScale core, it contains up to 8
|
|||
interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
|
||||
flash interface, and some other odds and ends. For more information, see:
|
||||
|
||||
http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm
|
||||
http://developer.intel.com
|
||||
|
||||
2. Linux Support
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ require the use of Intel's propietary CSR softare:
|
|||
If you need to use any of the above, you need to download Intel's
|
||||
software from:
|
||||
|
||||
http://developer.intel.com/design/network/products/npfamily/ixp425swr1.htm
|
||||
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
|
||||
|
||||
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
|
||||
SOFTWARE.
|
||||
|
@ -53,7 +53,7 @@ SOFTWARE.
|
|||
There are several websites that provide directions/pointers on using
|
||||
Intel's software:
|
||||
|
||||
http://ixp4xx-osdg.sourceforge.net/
|
||||
http://sourceforge.net/projects/ixp4xx-osdg/
|
||||
Open Source Developer's Guide for using uClinux and the Intel libraries
|
||||
|
||||
http://gatewaymaker.sourceforge.net/
|
||||
|
@ -112,21 +112,21 @@ http://www.adiengineering.com/productsCoyote.html
|
|||
Finally, there is an IDE port hanging off the expansion bus.
|
||||
|
||||
Gateworks Avila Network Platform
|
||||
http://www.gateworks.com/avila_sbc.htm
|
||||
http://www.gateworks.com/support/overview.php
|
||||
|
||||
The Avila platform is basically and IXDP425 with the 4 PCI slots
|
||||
replaced with mini-PCI slots and a CF IDE interface hanging off
|
||||
the expansion bus.
|
||||
|
||||
Intel IXDP425 Development Platform
|
||||
http://developer.intel.com/design/network/products/npfamily/ixdp425.htm
|
||||
http://www.intel.com/design/network/products/npfamily/ixdpg425.htm
|
||||
|
||||
This is Intel's standard reference platform for the IXDP425 and is
|
||||
also known as the Richfield board. It contains 4 PCI slots, 16MB
|
||||
of flash, two 10/100 ports and one ADSL port.
|
||||
|
||||
Intel IXDP465 Development Platform
|
||||
http://developer.intel.com/design/network/products/npfamily/ixdp465.htm
|
||||
http://www.intel.com/design/network/products/npfamily/ixdp465.htm
|
||||
|
||||
This is basically an IXDP425 with an IXP465 and 32M of flash instead
|
||||
of just 16.
|
||||
|
@ -141,15 +141,13 @@ Intel IXDPG425 Development Platform
|
|||
a pivot_root to NFS.
|
||||
|
||||
Motorola PrPMC1100 Processor Mezanine Card
|
||||
http://www.fountainsys.com/datasheet/PrPMC1100.pdf
|
||||
http://www.fountainsys.com
|
||||
|
||||
The PrPMC1100 is based on the IXCP1100 and is meant to plug into
|
||||
and IXP2400/2800 system to act as the system controller. It simply
|
||||
contains a CPU and 16MB of flash on the board and needs to be
|
||||
plugged into a carrier board to function. Currently Linux only
|
||||
supports the Motorola PrPMC carrier board for this platform.
|
||||
See https://mcg.motorola.com/us/ds/pdf/ds0144.pdf for info
|
||||
on the carrier board.
|
||||
|
||||
5. TODO LIST
|
||||
|
||||
|
|
|
@ -41,12 +41,12 @@ Bug reports etc
|
|||
---------------
|
||||
|
||||
Please send patches to the patch system. For more information, see
|
||||
http://www.arm.linux.org.uk/patches/info.html Always include some
|
||||
http://www.arm.linux.org.uk/developer/patches/info.php Always include some
|
||||
explanation as to what the patch does and why it is needed.
|
||||
|
||||
Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk,
|
||||
or submitted through the web form at
|
||||
http://www.arm.linux.org.uk/forms/solution.shtml
|
||||
http://www.arm.linux.org.uk/developer/
|
||||
|
||||
When sending bug reports, please ensure that they contain all relevant
|
||||
information, eg. the kernel messages that were printed before/during
|
||||
|
|
|
@ -2,8 +2,7 @@ The Intel Assabet (SA-1110 evaluation) board
|
|||
============================================
|
||||
|
||||
Please see:
|
||||
http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm
|
||||
http://developer.intel.com/design/strong/guides/278278.htm
|
||||
http://developer.intel.com
|
||||
|
||||
Also some notes from John G Dorsey <jd5q@andrew.cmu.edu>:
|
||||
http://www.cs.cmu.edu/~wearable/software/assabet.html
|
||||
|
@ -64,7 +63,7 @@ Initial RedBoot configuration
|
|||
-----------------------------
|
||||
|
||||
The commands used here are explained in The RedBoot User's Guide available
|
||||
on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html.
|
||||
on-line at http://sources.redhat.com/ecos/docs.html.
|
||||
Please refer to it for explanations.
|
||||
|
||||
If you have a CF network card (my Assabet kit contained a CF+ LP-E from
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
Brutus is an evaluation platform for the SA1100 manufactured by Intel.
|
||||
For more details, see:
|
||||
|
||||
http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm
|
||||
http://developer.intel.com
|
||||
|
||||
To compile for Brutus, you must issue the following commands:
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
Freebird-1.1 is produced by Legned(C) ,Inc.
|
||||
(http://www.legend.com.cn)
|
||||
http://web.archive.org/web/*/http://www.legend.com.cn
|
||||
and software/linux mainatined by Coventive(C),Inc.
|
||||
(http://www.coventive.com)
|
||||
|
||||
|
|
|
@ -71,7 +71,7 @@ Supported peripherals:
|
|||
- serial ports (ttyS[0-2])
|
||||
- ttyS0 is default for serial console
|
||||
- Smart I/O (ADC, keypad, digital inputs, etc)
|
||||
See http://www.applieddata.com/developers/linux for IOCTL documentation
|
||||
See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
|
||||
and example user space code. ps/2 keybd is multiplexed through this driver
|
||||
|
||||
To do:
|
||||
|
|
|
@ -28,7 +28,7 @@ Supported peripherals:
|
|||
- serial ports (ttyS[0-2])
|
||||
- ttyS0 is default for serial console
|
||||
- Smart I/O (ADC, keypad, digital inputs, etc)
|
||||
See http://www.applieddata.com/developers/linux for IOCTL documentation
|
||||
See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation
|
||||
and example user space code. ps/2 keybd is multiplexed through this driver
|
||||
|
||||
To do:
|
||||
|
|
|
@ -4,7 +4,7 @@ research projects at Compaq that are related to pocket computing.
|
|||
|
||||
For more information, see:
|
||||
|
||||
http://www.research.digital.com/wrl/itsy/index.html
|
||||
http://www.hpl.hp.com/downloads/crl/itsy/
|
||||
|
||||
Notes on initial 2.4 Itsy support (8/27/2000) :
|
||||
The port was done on an Itsy version 1.5 machine with a daughtercard with
|
||||
|
|
|
@ -6,6 +6,6 @@ PLEB support has yet to be fully integrated.
|
|||
|
||||
For more information, see:
|
||||
|
||||
http://www.cse.unsw.edu.au/~pleb/
|
||||
http://www.cse.unsw.edu.au
|
||||
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ VisuAide, Inc. to be used by blind people.
|
|||
|
||||
For more information related to Victor, see:
|
||||
|
||||
http://www.visuaide.com/victor
|
||||
http://www.humanware.com/en-usa/products
|
||||
|
||||
Of course Victor is using Linux as its main operating system.
|
||||
The Victor implementation for Linux is maintained by Nicolas Pitre:
|
||||
|
|
|
@ -7,5 +7,5 @@ for more info.
|
|||
(Ref: Stuart Adams <sja@brightstareng.com>)
|
||||
|
||||
Also visit Larry Doolittle's "Linux for the nanoEngine" site:
|
||||
http://recycle.lbl.gov/~ldoolitt/bse/
|
||||
http://www.brightstareng.com/arm/nanoeng.htm
|
||||
|
||||
|
|
|
@ -33,7 +33,13 @@ ffff0000 ffff0fff CPU vector page.
|
|||
|
||||
fffe0000 fffeffff XScale cache flush area. This is used
|
||||
in proc-xscale.S to flush the whole data
|
||||
cache. Free for other usage on non-XScale.
|
||||
cache. (XScale does not have TCM.)
|
||||
|
||||
fffe8000 fffeffff DTCM mapping area for platforms with
|
||||
DTCM mounted inside the CPU.
|
||||
|
||||
fffe0000 fffe7fff ITCM mapping area for platforms with
|
||||
ITCM mounted inside the CPU.
|
||||
|
||||
fff00000 fffdffff Fixmap mapping region. Addresses provided
|
||||
by fix_to_virt() will be located here.
|
||||
|
|
|
@ -19,8 +19,8 @@ defines a CPUID_TCM register that you can read out from the
|
|||
system control coprocessor. Documentation from ARM can be found
|
||||
at http://infocenter.arm.com, search for "TCM Status Register"
|
||||
to see documents for all CPUs. Reading this register you can
|
||||
determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the
|
||||
machine.
|
||||
determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present
|
||||
in the machine.
|
||||
|
||||
There is further a TCM region register (search for "TCM Region
|
||||
Registers" at the ARM site) that can report and modify the location
|
||||
|
@ -35,7 +35,15 @@ The TCM memory can then be remapped to another address again using
|
|||
the MMU, but notice that the TCM if often used in situations where
|
||||
the MMU is turned off. To avoid confusion the current Linux
|
||||
implementation will map the TCM 1 to 1 from physical to virtual
|
||||
memory in the location specified by the machine.
|
||||
memory in the location specified by the kernel. Currently Linux
|
||||
will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and
|
||||
on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM.
|
||||
|
||||
Newer versions of the region registers also support dividing these
|
||||
TCMs in two separate banks, so for example an 8KiB ITCM is divided
|
||||
into two 4KiB banks with its own control registers. The idea is to
|
||||
be able to lock and hide one of the banks for use by the secure
|
||||
world (TrustZone).
|
||||
|
||||
TCM is used for a few things:
|
||||
|
||||
|
@ -65,18 +73,18 @@ in <asm/tcm.h>. Using this interface it is possible to:
|
|||
memory. Such a heap is great for things like saving
|
||||
device state when shutting off device power domains.
|
||||
|
||||
A machine that has TCM memory shall select HAVE_TCM in
|
||||
arch/arm/Kconfig for itself, and then the
|
||||
rest of the functionality will depend on the physical
|
||||
location and size of ITCM and DTCM to be defined in
|
||||
mach/memory.h for the machine. Code that needs to use
|
||||
TCM shall #include <asm/tcm.h> If the TCM is not located
|
||||
at the place given in memory.h it will be moved using
|
||||
the TCM Region registers.
|
||||
A machine that has TCM memory shall select HAVE_TCM from
|
||||
arch/arm/Kconfig for itself. Code that needs to use TCM shall
|
||||
#include <asm/tcm.h>
|
||||
|
||||
Functions to go into itcm can be tagged like this:
|
||||
int __tcmfunc foo(int bar);
|
||||
|
||||
Since these are marked to become long_calls and you may want
|
||||
to have functions called locally inside the TCM without
|
||||
wasting space, there is also the __tcmlocalfunc prefix that
|
||||
will make the call relative.
|
||||
|
||||
Variables to go into dtcm can be tagged like this:
|
||||
int __tcmdata foo;
|
||||
|
||||
|
|
|
@ -111,6 +111,6 @@ cause unexpected behaviour and can be a security hazard.
|
|||
|
||||
|
||||
There is a web page about binfmt_misc at
|
||||
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html
|
||||
http://www.tat.physik.uni-tuebingen.de
|
||||
|
||||
Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
|
||||
|
|
|
@ -412,6 +412,6 @@ have in your mail headers, when sending mail to the list server.
|
|||
You might also find some useful information on the linux-parport
|
||||
web pages (although they are not always up to date) at
|
||||
|
||||
http://www.torque.net/parport/
|
||||
http://web.archive.org/web/*/http://www.torque.net/parport/
|
||||
|
||||
|
||||
|
|
|
@ -95,7 +95,7 @@ Using the pktcdvd sysfs interface
|
|||
|
||||
Since Linux 2.6.20, the pktcdvd module has a sysfs interface
|
||||
and can be controlled by it. For example the "pktcdvd" tool uses
|
||||
this interface. (see http://people.freenet.de/BalaGi#pktcdvd )
|
||||
this interface. (see http://tom.ist-im-web.de/download/pktcdvd )
|
||||
|
||||
"pktcdvd" works similar to "pktsetup", e.g.:
|
||||
|
||||
|
|
|
@ -691,7 +691,7 @@ There are ways to query or modify cpusets:
|
|||
cat, rmdir commands from the shell, or their equivalent from C.
|
||||
- via the C library libcpuset.
|
||||
- via the C library libcgroup.
|
||||
(http://sourceforge.net/proects/libcg/)
|
||||
(http://sourceforge.net/projects/libcg/)
|
||||
- via the python application cset.
|
||||
(http://developer.novell.com/wiki/index.php/Cpuset)
|
||||
|
||||
|
|
|
@ -417,6 +417,9 @@ reference on them using:
|
|||
This does all the RCU magic inside of it. The caller must call put_cred() on
|
||||
the credentials so obtained when they're finished with.
|
||||
|
||||
[*] Note: The result of __task_cred() should not be passed directly to
|
||||
get_cred() as this may race with commit_cred().
|
||||
|
||||
There are a couple of convenience functions to access bits of another task's
|
||||
credentials, hiding the RCU magic from the caller:
|
||||
|
||||
|
|
|
@ -281,7 +281,7 @@ With sparse, the programmer can be warned about confusion between
|
|||
user-space and kernel-space addresses, mixture of big-endian and
|
||||
small-endian quantities, the passing of integer values where a set of bit
|
||||
flags is expected, and so on. Sparse must be installed separately (it can
|
||||
be found at http://www.kernel.org/pub/software/devel/sparse/ if your
|
||||
be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your
|
||||
distributor does not package it); it can then be run on the code by adding
|
||||
"C=1" to your make command.
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ Example scripts
|
|||
===============
|
||||
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
|
||||
encryption with dm-crypt using the 'cryptsetup' utility, see
|
||||
http://luks.endorphin.org/
|
||||
http://clemens.endorphin.org/cryptography
|
||||
|
||||
[[
|
||||
#!/bin/sh
|
||||
|
|
|
@ -1517,7 +1517,7 @@ Your cooperation is appreciated.
|
|||
...
|
||||
|
||||
The driver and documentation may be obtained from
|
||||
http://www.proximity.com.au/~brian/winradio/
|
||||
http://www.winradio.com/
|
||||
|
||||
82 block I2O hard disk
|
||||
0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk
|
||||
|
@ -1723,7 +1723,7 @@ Your cooperation is appreciated.
|
|||
1 = /dev/comedi1 Second comedi device
|
||||
...
|
||||
|
||||
See http://stm.lbl.gov/comedi or http://www.llp.fu-berlin.de/.
|
||||
See http://stm.lbl.gov/comedi.
|
||||
|
||||
98 block User-mode virtual block device
|
||||
0 = /dev/ubda First user-mode block device
|
||||
|
@ -1984,7 +1984,7 @@ Your cooperation is appreciated.
|
|||
256 NetWare volumes can be supported in a single
|
||||
machine.
|
||||
|
||||
http://www.kernel.org/pub/linux/kernel/people/jmerkey/nwfs
|
||||
http://cgfa.telepac.pt/ftp2/kernel.org/linux/kernel/people/jmerkey/nwfs/
|
||||
|
||||
0 = /dev/nwfs/v0 First NetWare (NWFS) Logical Volume
|
||||
1 = /dev/nwfs/v1 Second NetWare (NWFS) Logical Volume
|
||||
|
@ -2591,7 +2591,8 @@ Your cooperation is appreciated.
|
|||
1 = /dev/intermezzo1 Second cache manager
|
||||
...
|
||||
|
||||
See http://www.inter-mezzo.org/ for more information.
|
||||
See http://web.archive.org/web/20080115195241/
|
||||
http://inter-mezzo.org/index.html
|
||||
|
||||
186 char Object-based storage control device
|
||||
0 = /dev/obd0 First obd control device
|
||||
|
|
|
@ -76,7 +76,7 @@ Some very frequently asked questions about linuxtv-dvb
|
|||
the TuxBox CVS many interesting DVB applications and the dBox2
|
||||
DVB source
|
||||
|
||||
http://sourceforge.net/projects/dvbsak/
|
||||
http://www.linuxtv.org/downloads/
|
||||
DVB Swiss Army Knife library and utilities
|
||||
|
||||
http://www.nenie.org/misc/mpsys/
|
||||
|
|
|
@ -26,7 +26,7 @@ use IO::Handle;
|
|||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
|
||||
"af9015", "ngene");
|
||||
"af9015", "ngene", "az6027");
|
||||
|
||||
# Check args
|
||||
syntax() if (scalar(@ARGV) != 1);
|
||||
|
@ -518,11 +518,11 @@ sub bluebird {
|
|||
sub af9015 {
|
||||
my $sourcefile = "download.ashx?file=57";
|
||||
my $url = "http://www.ite.com.tw/EN/Services/$sourcefile";
|
||||
my $hash = "ff5b096ed47c080870eacdab2de33ad6";
|
||||
my $hash = "e3f08935158038d385ad382442f4bb2d";
|
||||
my $outfile = "dvb-usb-af9015.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
my $fwoffset = 0x22708;
|
||||
my $fwlength = 18225;
|
||||
my $fwoffset = 0x25690;
|
||||
my $fwlength = 18725;
|
||||
my ($chunklength, $buf, $rcount);
|
||||
|
||||
checkstandard();
|
||||
|
@ -567,6 +567,23 @@ sub ngene {
|
|||
"$file1, $file2";
|
||||
}
|
||||
|
||||
sub az6027{
|
||||
my $file = "AZ6027_Linux_Driver.tar.gz";
|
||||
my $url = "http://linux.terratec.de/files/$file";
|
||||
my $firmware = "dvb-usb-az6027-03.fw";
|
||||
|
||||
wgetfile($file, $url);
|
||||
|
||||
#untar
|
||||
if( system("tar xzvf $file $firmware")){
|
||||
die "failed to untar firmware";
|
||||
}
|
||||
if( system("rm $file")){
|
||||
die ("unable to remove unnecessary files");
|
||||
}
|
||||
|
||||
$firmware;
|
||||
}
|
||||
# ---------------------------------------------------------------
|
||||
# Utilities
|
||||
|
||||
|
|
|
@ -6,6 +6,8 @@ Written by Doug Thompson <dougthompson@xmission.com>
|
|||
7 Dec 2005
|
||||
17 Jul 2007 Updated
|
||||
|
||||
(c) Mauro Carvalho Chehab <mchehab@redhat.com>
|
||||
05 Aug 2009 Nehalem interface
|
||||
|
||||
EDAC is maintained and written by:
|
||||
|
||||
|
@ -717,3 +719,153 @@ unique drivers for their hardware systems.
|
|||
The 'test_device_edac' sample driver is located at the
|
||||
bluesmoke.sourceforge.net project site for EDAC.
|
||||
|
||||
=======================================================================
|
||||
NEHALEM USAGE OF EDAC APIs
|
||||
|
||||
This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
|
||||
Nehalem EDAC driver. They will likely be changed on future versions
|
||||
of the driver.
|
||||
|
||||
Due to the way Nehalem exports Memory Controller data, some adjustments
|
||||
were done at i7core_edac driver. This chapter will cover those differences
|
||||
|
||||
1) On Nehalem, there are one Memory Controller per Quick Patch Interconnect
|
||||
(QPI). At the driver, the term "socket" means one QPI. This is
|
||||
associated with a physical CPU socket.
|
||||
|
||||
Each MC have 3 physical read channels, 3 physical write channels and
|
||||
3 logic channels. The driver currenty sees it as just 3 channels.
|
||||
Each channel can have up to 3 DIMMs.
|
||||
|
||||
The minimum known unity is DIMMs. There are no information about csrows.
|
||||
As EDAC API maps the minimum unity is csrows, the driver sequencially
|
||||
maps channel/dimm into different csrows.
|
||||
|
||||
For example, suposing the following layout:
|
||||
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
|
||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
|
||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
|
||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||
The driver will map it as:
|
||||
csrow0: channel 0, dimm0
|
||||
csrow1: channel 0, dimm1
|
||||
csrow2: channel 1, dimm0
|
||||
csrow3: channel 2, dimm0
|
||||
|
||||
exports one
|
||||
DIMM per csrow.
|
||||
|
||||
Each QPI is exported as a different memory controller.
|
||||
|
||||
2) Nehalem MC has the hability to generate errors. The driver implements this
|
||||
functionality via some error injection nodes:
|
||||
|
||||
For injecting a memory error, there are some sysfs nodes, under
|
||||
/sys/devices/system/edac/mc/mc?/:
|
||||
|
||||
inject_addrmatch/*:
|
||||
Controls the error injection mask register. It is possible to specify
|
||||
several characteristics of the address to match an error code:
|
||||
dimm = the affected dimm. Numbers are relative to a channel;
|
||||
rank = the memory rank;
|
||||
channel = the channel that will generate an error;
|
||||
bank = the affected bank;
|
||||
page = the page address;
|
||||
column (or col) = the address column.
|
||||
each of the above values can be set to "any" to match any valid value.
|
||||
|
||||
At driver init, all values are set to any.
|
||||
|
||||
For example, to generate an error at rank 1 of dimm 2, for any channel,
|
||||
any bank, any page, any column:
|
||||
echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
|
||||
echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
|
||||
|
||||
To return to the default behaviour of matching any, you can do:
|
||||
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
|
||||
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank
|
||||
|
||||
inject_eccmask:
|
||||
specifies what bits will have troubles,
|
||||
|
||||
inject_section:
|
||||
specifies what ECC cache section will get the error:
|
||||
3 for both
|
||||
2 for the highest
|
||||
1 for the lowest
|
||||
|
||||
inject_type:
|
||||
specifies the type of error, being a combination of the following bits:
|
||||
bit 0 - repeat
|
||||
bit 1 - ecc
|
||||
bit 2 - parity
|
||||
|
||||
inject_enable starts the error generation when something different
|
||||
than 0 is written.
|
||||
|
||||
All inject vars can be read. root permission is needed for write.
|
||||
|
||||
Datasheet states that the error will only be generated after a write on an
|
||||
address that matches inject_addrmatch. It seems, however, that reading will
|
||||
also produce an error.
|
||||
|
||||
For example, the following code will generate an error for any write access
|
||||
at socket 0, on any DIMM/address on channel 2:
|
||||
|
||||
echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
|
||||
echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
|
||||
echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
|
||||
echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
|
||||
echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
|
||||
dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null
|
||||
|
||||
For socket 1, it is needed to replace "mc0" by "mc1" at the above
|
||||
commands.
|
||||
|
||||
The generated error message will look like:
|
||||
|
||||
EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))
|
||||
|
||||
3) Nehalem specific Corrected Error memory counters
|
||||
|
||||
Nehalem have some registers to count memory errors. The driver uses those
|
||||
registers to report Corrected Errors on devices with Registered Dimms.
|
||||
|
||||
However, those counters don't work with Unregistered Dimms. As the chipset
|
||||
offers some counters that also work with UDIMMS (but with a worse level of
|
||||
granularity than the default ones), the driver exposes those registers for
|
||||
UDIMM memories.
|
||||
|
||||
They can be read by looking at the contents of all_channel_counts/
|
||||
|
||||
$ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
|
||||
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
|
||||
0
|
||||
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
|
||||
0
|
||||
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
|
||||
0
|
||||
|
||||
What happens here is that errors on different csrows, but at the same
|
||||
dimm number will increment the same counter.
|
||||
So, in this memory mapping:
|
||||
csrow0: channel 0, dimm0
|
||||
csrow1: channel 0, dimm1
|
||||
csrow2: channel 1, dimm0
|
||||
csrow3: channel 2, dimm0
|
||||
The hardware will increment udimm0 for an error at the first dimm at either
|
||||
csrow0, csrow2 or csrow3;
|
||||
The hardware will increment udimm1 for an error at the second dimm at either
|
||||
csrow0, csrow2 or csrow3;
|
||||
The hardware will increment udimm2 for an error at the third dimm at either
|
||||
csrow0, csrow2 or csrow3;
|
||||
|
||||
4) Standard error counters
|
||||
|
||||
The standard error counters are generated when an mcelog error is received
|
||||
by the driver. Since, with udimm, this is counted by software, it is
|
||||
possible that some errors could be lost. With rdimm's, they displays the
|
||||
contents of the registers
|
||||
|
|
|
@ -330,7 +330,7 @@ and on its mirrors.
|
|||
|
||||
The latest version of fbset can be found at
|
||||
|
||||
http://home.tvd.be/cr26864/Linux/fbdev/
|
||||
http://www.linux-fbdev.org/
|
||||
|
||||
|
||||
10. Credits
|
||||
|
|
|
@ -93,7 +93,7 @@ Why: Broken design for runtime control over driver power states, confusing
|
|||
inputs. This framework was never widely used, and most attempts to
|
||||
use it were broken. Drivers should instead be exposing domain-specific
|
||||
interfaces either to kernel or to userspace.
|
||||
Who: Pavel Machek <pavel@suse.cz>
|
||||
Who: Pavel Machek <pavel@ucw.cz>
|
||||
|
||||
---------------------------
|
||||
|
||||
|
@ -368,16 +368,6 @@ Who: Eric Paris <eparis@redhat.com>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
|
||||
exported interface anymore.
|
||||
When: 2.6.33
|
||||
Why: cpu_policy_rwsem has a new cleaner definition making it local to
|
||||
cpufreq core and contained inside cpufreq.c. Other dependent
|
||||
drivers should not use it in order to safely avoid lockdep issues.
|
||||
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: sound-slot/service-* module aliases and related clutters in
|
||||
sound/sound_core.c
|
||||
When: August 2010
|
||||
|
@ -450,57 +440,6 @@ Who: Corentin Chary <corentin.chary@gmail.com>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: usbvideo quickcam_messenger driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv06xx
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ov511 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ov511.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: w9968cf v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/w9968cf*.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ovcamchip sensor framework
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ovcamchip/*
|
||||
Why: Only used by obsoleted v4l1 drivers
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: stv680 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/stv680.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv0680
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: zc0301 v4l driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/zc0301/*
|
||||
Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
|
||||
supports 2 USB-ID's (because it only supports a limited set of
|
||||
sensors) wich are also supported by the gspca_zc3xx driver
|
||||
(which supports 53 USB-ID's in total)
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: sysfs-class-rfkill state file
|
||||
When: Feb 2014
|
||||
Files: net/rfkill/core.c
|
||||
|
@ -529,17 +468,6 @@ Who: Jan Kiszka <jan.kiszka@web.de>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: KVM memory aliases support
|
||||
When: July 2010
|
||||
Why: Memory aliasing support is used for speeding up guest vga access
|
||||
through the vga windows.
|
||||
|
||||
Modern userspace no longer uses this feature, so it's just bitrotted
|
||||
code and can be removed with no impact.
|
||||
Who: Avi Kivity <avi@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: xtime, wall_to_monotonic
|
||||
When: 2.6.36+
|
||||
Files: kernel/time/timekeeping.c include/linux/time.h
|
||||
|
@ -550,16 +478,6 @@ Who: John Stultz <johnstul@us.ibm.com>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: KVM kernel-allocated memory slots
|
||||
When: July 2010
|
||||
Why: Since 2.6.25, kvm supports user-allocated memory slots, which are
|
||||
much more flexible than kernel-allocated slots. All current userspace
|
||||
supports the newer interface and this code can be removed with no
|
||||
impact.
|
||||
Who: Avi Kivity <avi@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: KVM paravirt mmu host support
|
||||
When: January 2011
|
||||
Why: The paravirt mmu host support is slower than non-paravirt mmu, both
|
||||
|
@ -569,15 +487,6 @@ Who: Avi Kivity <avi@redhat.com>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: "acpi=ht" boot option
|
||||
When: 2.6.35
|
||||
Why: Useful in 2003, implementation is a hack.
|
||||
Generally invoked by accident today.
|
||||
Seen as doing more harm than good.
|
||||
Who: Len Brown <len.brown@intel.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: iwlwifi 50XX module parameters
|
||||
When: 2.6.40
|
||||
Why: The "..50" modules parameters were used to configure 5000 series and
|
||||
|
@ -647,3 +556,10 @@ Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|||
|
||||
----------------------------
|
||||
|
||||
What: The acpi_sleep=s4_nonvs command line option
|
||||
When: 2.6.37
|
||||
Files: arch/x86/kernel/acpi/sleep.c
|
||||
Why: superseded by acpi_sleep=nonvs
|
||||
Who: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
|
||||
----------------------------
|
||||
|
|
|
@ -128,7 +128,7 @@ OPTIONS
|
|||
RESOURCES
|
||||
=========
|
||||
|
||||
Our current recommendation is to use Inferno (http://www.vitanuova.com/inferno)
|
||||
Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html)
|
||||
as the 9p server. You can start a 9p server under Inferno by issuing the
|
||||
following command:
|
||||
; styxlisten -A tcp!*!564 export '#U*'
|
||||
|
|
|
@ -216,4 +216,4 @@ due to an incompatibility with the Amiga floppy controller.
|
|||
|
||||
If you are interested in an Amiga Emulator for Linux, look at
|
||||
|
||||
http://www.freiburg.linux.de/~uae/
|
||||
http://web.archive.org/web/*/http://www.freiburg.linux.de/~uae/
|
||||
|
|
|
@ -31,7 +31,7 @@ Current maintainer: Sergey S. Kostyliov <rathamahata@php4.ru>
|
|||
|
||||
WHAT IS THIS DRIVER?
|
||||
==================
|
||||
This module implements the native filesystem of BeOS <http://www.be.com/>
|
||||
This module implements the native filesystem of BeOS http://www.beincorporated.com/
|
||||
for the linux 2.4.1 and later kernels. Currently it is a read-only
|
||||
implementation.
|
||||
|
||||
|
@ -61,7 +61,7 @@ step 2. Configuration & make kernel
|
|||
|
||||
The linux kernel has many compile-time options. Most of them are beyond the
|
||||
scope of this document. I suggest the Kernel-HOWTO document as a good general
|
||||
reference on this topic. <http://www.linux.com/howto/Kernel-HOWTO.html>
|
||||
reference on this topic. http://www.linuxdocs.org/HOWTOs/Kernel-HOWTO-4.html
|
||||
|
||||
However, to use the BeFS module, you must enable it at configure time.
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ Mount options unique to the isofs filesystem.
|
|||
sbsector=xxx Session begins from sector xxx
|
||||
|
||||
Recommended documents about ISO 9660 standard are located at:
|
||||
http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm
|
||||
http://www.y-adagio.com/
|
||||
ftp://ftp.ecma.ch/ecma-st/Ecma-119.pdf
|
||||
Quoting from the PDF "This 2nd Edition of Standard ECMA-119 is technically
|
||||
identical with ISO 9660.", so it is a valid and gratis substitute of the
|
||||
|
|
|
@ -73,9 +73,9 @@ contact Bodo Bauer at bb@ricochet.net. We'll be happy to add them to this
|
|||
document.
|
||||
|
||||
The latest version of this document is available online at
|
||||
http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version.
|
||||
http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html
|
||||
|
||||
If the above direction does not works for you, ypu could try the kernel
|
||||
If the above direction does not works for you, you could try the kernel
|
||||
mailing list at linux-kernel@vger.kernel.org and/or try to reach me at
|
||||
comandante@zaralinux.com.
|
||||
|
||||
|
|
|
@ -165,7 +165,8 @@ TEST SUITE
|
|||
If you plan to make any modifications to the vfat filesystem, please
|
||||
get the test suite that comes with the vfat distribution at
|
||||
|
||||
http://bmrc.berkeley.edu/people/chaffee/vfat.html
|
||||
http://web.archive.org/web/*/http://bmrc.berkeley.edu/
|
||||
people/chaffee/vfat.html
|
||||
|
||||
This tests quite a few parts of the vfat filesystem and additional
|
||||
tests for new features or untested features would be appreciated.
|
||||
|
|
|
@ -794,11 +794,6 @@ designed.
|
|||
|
||||
Roadmap:
|
||||
|
||||
2.6.35 Inclusion in mainline as an experimental mount option
|
||||
=> approximately 2-3 months to merge window
|
||||
=> needs to be in xfs-dev tree in 4-6 weeks
|
||||
=> code is nearing readiness for review
|
||||
|
||||
2.6.37 Remove experimental tag from mount option
|
||||
=> should be roughly 6 months after initial merge
|
||||
=> enough time to:
|
||||
|
|
|
@ -131,17 +131,6 @@ When mounting an XFS filesystem, the following options are accepted.
|
|||
Don't check for double mounted file systems using the file system uuid.
|
||||
This is useful to mount LVM snapshot volumes.
|
||||
|
||||
osyncisosync
|
||||
Make O_SYNC writes implement true O_SYNC. WITHOUT this option,
|
||||
Linux XFS behaves as if an "osyncisdsync" option is used,
|
||||
which will make writes to files opened with the O_SYNC flag set
|
||||
behave as if the O_DSYNC flag had been used instead.
|
||||
This can result in better performance without compromising
|
||||
data safety.
|
||||
However if this option is not in effect, timestamp updates from
|
||||
O_SYNC writes can be lost if the system crashes.
|
||||
If timestamp updates are critical, use the osyncisosync option.
|
||||
|
||||
uquota/usrquota/uqnoenforce/quota
|
||||
User disk quota accounting enabled, and limits (optionally)
|
||||
enforced. Refer to xfs_quota(8) for further details.
|
||||
|
|
|
@ -6,7 +6,7 @@ Supported chips:
|
|||
Prefix: 'adm1026'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: Publicly available at the Analog Devices website
|
||||
http://www.analog.com/en/prod/0,,766_825_ADM1026,00.html
|
||||
http://www.onsemi.com/PowerSolutions/product.do?id=ADM1026
|
||||
|
||||
Authors:
|
||||
Philip Pokorny <ppokorny@penguincomputing.com> for Penguin Computing
|
||||
|
|
|
@ -5,7 +5,7 @@ Supported chips:
|
|||
* Global Mixed-mode Technology Inc. G760A
|
||||
Prefix: 'g760a'
|
||||
Datasheet: Publicly available at the GMT website
|
||||
http://www.gmt.com.tw/datasheet/g760a.pdf
|
||||
http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf
|
||||
|
||||
Author: Herbert Valerio Riedel <hvr@gnu.org>
|
||||
|
||||
|
|
|
@ -5,11 +5,10 @@ Supported chips:
|
|||
* Genesys Logic GL518SM release 0x00
|
||||
Prefix: 'gl518sm'
|
||||
Addresses scanned: I2C 0x2c and 0x2d
|
||||
Datasheet: http://www.genesyslogic.com/pdf
|
||||
* Genesys Logic GL518SM release 0x80
|
||||
Prefix: 'gl518sm'
|
||||
Addresses scanned: I2C 0x2c and 0x2d
|
||||
Datasheet: http://www.genesyslogic.com/pdf
|
||||
Datasheet: http://www.genesyslogic.com/
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
/* Disk protection for HP machines.
|
||||
*
|
||||
* Copyright 2008 Eric Piel
|
||||
* Copyright 2009 Pavel Machek <pavel@suse.cz>
|
||||
* Copyright 2009 Pavel Machek <pavel@ucw.cz>
|
||||
*
|
||||
* GPLv2.
|
||||
*/
|
||||
|
|
|
@ -5,7 +5,7 @@ Supported chips:
|
|||
* AMD Athlon64/FX or Opteron CPUs
|
||||
Prefix: 'k8temp'
|
||||
Addresses scanned: PCI space
|
||||
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
|
||||
Datasheet: http://support.amd.com/us/Processor_TechDocs/32559.pdf
|
||||
|
||||
Author: Rudolf Marek
|
||||
Contact: Rudolf Marek <r.marek@assembler.cz>
|
||||
|
|
|
@ -9,15 +9,15 @@ Supported chips:
|
|||
* Analog Devices ADM1027
|
||||
Prefix: 'adm1027'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADM1027,00.html
|
||||
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADM1027
|
||||
* Analog Devices ADT7463
|
||||
Prefix: 'adt7463'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html
|
||||
Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463
|
||||
* SMSC EMC6D100, SMSC EMC6D101
|
||||
Prefix: 'emc6d100'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
Datasheet: http://www.smsc.com/main/tools/discontinued/6d100.pdf
|
||||
Datasheet: http://www.smsc.com/media/Downloads_Public/discontinued/6d100.pdf
|
||||
* SMSC EMC6D102
|
||||
Prefix: 'emc6d102'
|
||||
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
|
||||
|
|
|
@ -7,13 +7,10 @@ Supported chips:
|
|||
Addresses scanned: none, address read from Super I/O config space
|
||||
Prefix: 'smsc47m1'
|
||||
Datasheets:
|
||||
http://www.smsc.com/main/datasheets/47b27x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m10x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m112.pdf
|
||||
http://www.smsc.com/main/tools/discontinued/47m13x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m14x.pdf
|
||||
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
|
||||
http://www.smsc.com/main/datasheets/47m192.pdf
|
||||
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47b272.pdf
|
||||
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m10x.pdf
|
||||
http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m112.pdf
|
||||
http://www.smsc.com/
|
||||
* SMSC LPC47M292
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Prefix: 'smsc47m2'
|
||||
|
|
|
@ -9,7 +9,7 @@ Supported chips:
|
|||
* Texas Instruments THMC50
|
||||
Prefix: 'thmc50'
|
||||
Addresses scanned: I2C 0x2c - 0x2e
|
||||
Datasheet: http://focus.ti.com/docs/prod/folders/print/thmc50.html
|
||||
Datasheet: http://www.ti.com/
|
||||
|
||||
Author: Krzysztof Helt <krzysztof.h1@wp.pl>
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@ Supported chips:
|
|||
* Via VT82C686A, VT82C686B Southbridge Integrated Hardware Monitor
|
||||
Prefix: 'via686a'
|
||||
Addresses scanned: ISA in PCI-space encoded address
|
||||
Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/)
|
||||
Datasheet: On request through web form (http://www.via.com.tw/en/resources/download-center/)
|
||||
|
||||
Authors:
|
||||
Kyösti Mälkki <kmalkki@cc.hut.fi>,
|
||||
|
|
|
@ -5,23 +5,19 @@ Supported chips:
|
|||
* Winbond W83627HF (ISA accesses ONLY)
|
||||
Prefix: 'w83627hf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf
|
||||
* Winbond W83627THF
|
||||
Prefix: 'w83627thf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83627thf.pdf
|
||||
* Winbond W83697HF
|
||||
Prefix: 'w83697hf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/697hf.pdf
|
||||
* Winbond W83637HF
|
||||
Prefix: 'w83637hf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83637hf.pdf
|
||||
* Winbond W83687THF
|
||||
Prefix: 'w83687thf'
|
||||
Addresses scanned: ISA address retrieved from Super I/O registers
|
||||
Datasheet: Provided by Winbond on request
|
||||
Datasheet: Provided by Winbond on request(http://www.winbond.com/hq/enu)
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
|
|
|
@ -9,7 +9,7 @@ Supported chips:
|
|||
* Winbond W83782D
|
||||
Prefix: 'w83782d'
|
||||
Addresses scanned: I2C 0x28 - 0x2f, ISA 0x290 (8 I/O ports)
|
||||
Datasheet: http://www.winbond.com/PDF/sheet/w83782d.pdf
|
||||
Datasheet: http://www.winbond.com
|
||||
* Winbond W83783S
|
||||
Prefix: 'w83783s'
|
||||
Addresses scanned: I2C 0x2d
|
||||
|
|
|
@ -5,7 +5,7 @@ Supported chips:
|
|||
* Winbond W83792D
|
||||
Prefix: 'w83792d'
|
||||
Addresses scanned: I2C 0x2c - 0x2f
|
||||
Datasheet: http://www.winbond.com.tw/E-WINBONDHTM/partner/PDFresult.asp?Pname=1035
|
||||
Datasheet: http://www.winbond.com.tw
|
||||
|
||||
Author: Chunhao Huang
|
||||
Contact: DZShen <DZShen@Winbond.com.tw>
|
||||
|
|
|
@ -3,15 +3,15 @@ Kernel driver i2c-ali1535
|
|||
Supported adapters:
|
||||
* Acer Labs, Inc. ALI 1535 (south bridge)
|
||||
Datasheet: Now under NDA
|
||||
http://www.ali.com.tw/eng/support/datasheet_request.php
|
||||
http://www.ali.com.tw/
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||
Dan Eaton <dan.eaton@rocketlogix.com>,
|
||||
Stephen Rousset<stephen.rousset@rocketlogix.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
|
|
|
@ -3,7 +3,7 @@ Kernel driver i2c-ali1563
|
|||
Supported adapters:
|
||||
* Acer Labs, Inc. ALI 1563 (south bridge)
|
||||
Datasheet: Now under NDA
|
||||
http://www.ali.com.tw/eng/support/datasheet_request.php
|
||||
http://www.ali.com.tw/
|
||||
|
||||
Author: Patrick Mochel <mochel@digitalimplant.org>
|
||||
|
||||
|
@ -18,7 +18,7 @@ For an overview of these chips see http://www.acerlabs.com
|
|||
The M1563 southbridge is deceptively similar to the M1533, with a few
|
||||
notable exceptions. One of those happens to be the fact they upgraded the
|
||||
i2c core to be SMBus 2.0 compliant, and happens to be almost identical to
|
||||
the i2c controller found in the Intel 801 south bridges.
|
||||
the i2c controller found in the Intel 801 south bridges.
|
||||
|
||||
Features
|
||||
--------
|
||||
|
|
|
@ -3,11 +3,11 @@ Kernel driver i2c-ali15x3
|
|||
Supported adapters:
|
||||
* Acer Labs, Inc. ALI 1533 and 1543C (south bridge)
|
||||
Datasheet: Now under NDA
|
||||
http://www.ali.com.tw/eng/support/datasheet_request.php
|
||||
http://www.ali.com.tw/
|
||||
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>
|
||||
|
||||
Module Parameters
|
||||
|
@ -40,10 +40,10 @@ M1541 and M1543C South Bridges.
|
|||
The M1543C is a South bridge for desktop systems.
|
||||
The M1541 is a South bridge for portable systems.
|
||||
They are part of the following ALI chipsets:
|
||||
|
||||
* "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
|
||||
|
||||
* "Aladdin Pro 2" includes the M1621 Slot 1 North bridge with AGP and
|
||||
100MHz CPU Front Side bus
|
||||
* "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
|
||||
* "Aladdin V" includes the M1541 Socket 7 North bridge with AGP and 100MHz
|
||||
CPU Front Side bus
|
||||
Some Aladdin V motherboards:
|
||||
Asus P5A
|
||||
|
@ -77,7 +77,7 @@ output of lspci will show something similar to the following:
|
|||
** then run lspci.
|
||||
** If you see the 1533 and 5229 devices but NOT the 7101 device,
|
||||
** then you must enable ACPI, the PMU, SMB, or something similar
|
||||
** in the BIOS.
|
||||
** in the BIOS.
|
||||
** The driver won't work if it can't find the M7101 device.
|
||||
|
||||
The SMB controller is part of the M7101 device, which is an ACPI-compliant
|
||||
|
@ -87,8 +87,8 @@ The whole M7101 device has to be enabled for the SMB to work. You can't
|
|||
just enable the SMB alone. The SMB and the ACPI have separate I/O spaces.
|
||||
We make sure that the SMB is enabled. We leave the ACPI alone.
|
||||
|
||||
Features
|
||||
--------
|
||||
Features
|
||||
--------
|
||||
|
||||
This driver controls the SMB Host only. The SMB Slave
|
||||
controller on the M15X3 is not enabled. This driver does not use
|
||||
|
|
|
@ -1,10 +1,10 @@
|
|||
Kernel driver i2c-pca-isa
|
||||
|
||||
Supported adapters:
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
|
||||
Author: Ian Campbell <icampbell@arcom.com>, Arcom Control Systems
|
||||
Author: Ian Campbell <icampbell@arcom.com>, Arcom Control Systems
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
@ -12,12 +12,12 @@ Module Parameters
|
|||
* base int
|
||||
I/O base address
|
||||
* irq int
|
||||
IRQ interrupt
|
||||
* clock int
|
||||
IRQ interrupt
|
||||
* clock int
|
||||
Clock rate as described in table 1 of PCA9564 datasheet
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
This driver supports ISA boards using the Philips PCA 9564
|
||||
Parallel bus to I2C bus controller
|
||||
|
|
|
@ -97,4 +97,4 @@ of all affected systems, so the only safe solution was to prevent access to
|
|||
the SMBus on all IBM systems (detected using DMI data.)
|
||||
|
||||
For additional information, read:
|
||||
http://www.lm-sensors.org/browser/lm-sensors/trunk/README.thinkpad
|
||||
http://www.lm-sensors.org/browser/lm-sensors/trunk/README
|
||||
|
|
|
@ -1,41 +1,41 @@
|
|||
Kernel driver i2c-sis5595
|
||||
|
||||
Authors:
|
||||
Authors:
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Mark D. Studebaker <mdsxyz123@yahoo.com>,
|
||||
Philip Edelbrock <phil@netroedge.com>
|
||||
Philip Edelbrock <phil@netroedge.com>
|
||||
|
||||
Supported adapters:
|
||||
* Silicon Integrated Systems Corp. SiS5595 Southbridge
|
||||
Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.
|
||||
|
||||
Note: all have mfr. ID 0x1039.
|
||||
Note: all have mfr. ID 0x1039.
|
||||
|
||||
SUPPORTED PCI ID
|
||||
5595 0008
|
||||
|
||||
Note: these chips contain a 0008 device which is incompatible with the
|
||||
5595. We recognize these by the presence of the listed
|
||||
"blacklist" PCI ID and refuse to load.
|
||||
|
||||
NOT SUPPORTED PCI ID BLACKLIST PCI ID
|
||||
540 0008 0540
|
||||
550 0008 0550
|
||||
5513 0008 5511
|
||||
5581 0008 5597
|
||||
5582 0008 5597
|
||||
5597 0008 5597
|
||||
5598 0008 5597/5598
|
||||
630 0008 0630
|
||||
645 0008 0645
|
||||
646 0008 0646
|
||||
648 0008 0648
|
||||
650 0008 0650
|
||||
651 0008 0651
|
||||
730 0008 0730
|
||||
735 0008 0735
|
||||
745 0008 0745
|
||||
746 0008 0746
|
||||
SUPPORTED PCI ID
|
||||
5595 0008
|
||||
|
||||
Note: these chips contain a 0008 device which is incompatible with the
|
||||
5595. We recognize these by the presence of the listed
|
||||
"blacklist" PCI ID and refuse to load.
|
||||
|
||||
NOT SUPPORTED PCI ID BLACKLIST PCI ID
|
||||
540 0008 0540
|
||||
550 0008 0550
|
||||
5513 0008 5511
|
||||
5581 0008 5597
|
||||
5582 0008 5597
|
||||
5597 0008 5597
|
||||
5598 0008 5597/5598
|
||||
630 0008 0630
|
||||
645 0008 0645
|
||||
646 0008 0646
|
||||
648 0008 0648
|
||||
650 0008 0650
|
||||
651 0008 0651
|
||||
730 0008 0730
|
||||
735 0008 0735
|
||||
745 0008 0745
|
||||
746 0008 0746
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
|
|
@ -2,7 +2,7 @@ Kernel driver i2c-sis630
|
|||
|
||||
Supported adapters:
|
||||
* Silicon Integrated Systems Corp (SiS)
|
||||
630 chipset (Datasheet: available at http://amalysh.bei.t-online.de/docs/SIS/)
|
||||
630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux)
|
||||
730 chipset
|
||||
* Possible other SiS chipsets ?
|
||||
|
||||
|
@ -14,9 +14,9 @@ Module Parameters
|
|||
* force = [1|0] Forcibly enable the SIS630. DANGEROUS!
|
||||
This can be interesting for chipsets not named
|
||||
above to check if it works for you chipset, but DANGEROUS!
|
||||
|
||||
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
|
||||
what your BIOS use). DANGEROUS! This should be a bit
|
||||
|
||||
* high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default,
|
||||
what your BIOS use). DANGEROUS! This should be a bit
|
||||
faster, but freeze some systems (i.e. my Laptop).
|
||||
|
||||
|
||||
|
@ -44,6 +44,6 @@ Philip Edelbrock <phil@netroedge.com>
|
|||
- testing SiS730 support
|
||||
Mark M. Hoffman <mhoffman@lightlink.com>
|
||||
- bug fixes
|
||||
|
||||
|
||||
To anyone else which I forgot here ;), thanks!
|
||||
|
||||
|
|
|
@ -1,17 +1,17 @@
|
|||
The I2C protocol knows about two kinds of device addresses: normal 7 bit
|
||||
The I2C protocol knows about two kinds of device addresses: normal 7 bit
|
||||
addresses, and an extended set of 10 bit addresses. The sets of addresses
|
||||
do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
|
||||
address 0x10 (though a single device could respond to both of them). You
|
||||
select a 10 bit address by adding an extra byte after the address
|
||||
byte:
|
||||
S Addr7 Rd/Wr ....
|
||||
S Addr7 Rd/Wr ....
|
||||
becomes
|
||||
S 11110 Addr10 Rd/Wr
|
||||
S is the start bit, Rd/Wr the read/write bit, and if you count the number
|
||||
of bits, you will see the there are 8 after the S bit for 7 bit addresses,
|
||||
and 16 after the S bit for 10 bit addresses.
|
||||
|
||||
WARNING! The current 10 bit address support is EXPERIMENTAL. There are
|
||||
WARNING! The current 10 bit address support is EXPERIMENTAL. There are
|
||||
several places in the code that will cause SEVERE PROBLEMS with 10 bit
|
||||
addresses, even though there is some basic handling and hooks. Also,
|
||||
almost no supported adapter handles the 10 bit addresses correctly.
|
||||
|
|
|
@ -168,8 +168,6 @@ PAST PROBLEM CASES
|
|||
|
||||
mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
|
||||
|
||||
See https://bugzilla.novell.com/show_bug.cgi?id=140858.
|
||||
|
||||
The EFI memory map reports the following attributes:
|
||||
0x00000-0x9FFFF WB only
|
||||
0xA0000-0xBFFFF UC only (VGA frame buffer)
|
||||
|
|
|
@ -133,7 +133,7 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS
|
|||
|
||||
|
||||
|
||||
[1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf
|
||||
[1] http://www.dig64.org/specifications/agreement
|
||||
The table was originally defined as the "HCDP" for "Headless
|
||||
Console/Debug Port." The current version is the "PCDP" for
|
||||
"Primary Console and Debug Port Devices."
|
||||
|
|
|
@ -5,7 +5,7 @@ USERSPACE VERBS ACCESS
|
|||
described in chapter 11 of the InfiniBand Architecture Specification.
|
||||
|
||||
To use the verbs, the libibverbs library, available from
|
||||
<http://openib.org/>, is required. libibverbs contains a
|
||||
http://www.openfabrics.org/, is required. libibverbs contains a
|
||||
device-independent API for using the ib_uverbs interface.
|
||||
libibverbs also requires appropriate device-dependent kernel and
|
||||
userspace driver for your InfiniBand hardware. For example, to use
|
||||
|
|
|
@ -82,4 +82,4 @@ Links:
|
|||
------
|
||||
|
||||
[1]: http://johannes.sipsolutions.net/PowerBook/touchpad/
|
||||
[2]: http://web.telia.com/~u89404340/touchpad/index.html
|
||||
[2]: http://web.archive.org/web/*/http://web.telia.com/~u89404340/touchpad/index.html
|
||||
|
|
|
@ -62,4 +62,4 @@ Links
|
|||
-----
|
||||
|
||||
[1] http://ubuntuforums.org/showthread.php?t=840040
|
||||
[2] http://http://bitmath.org/code/
|
||||
[2] http://bitmath.org/code/
|
||||
|
|
|
@ -251,7 +251,7 @@ Check www.immerse.com for Immersion Studio, and www.fcoder.com for ComPortSpy.
|
|||
|
||||
** Author of this document **
|
||||
Johann Deneux <johann.deneux@gmail.com>
|
||||
Home page at http://www.esil.univ-mrs.fr/~jdeneux/projects/ff/
|
||||
Home page at http://web.archive.org/web/*/http://www.esil.univ-mrs.fr
|
||||
|
||||
Additions by Vojtech Pavlik.
|
||||
|
||||
|
|
|
@ -6,31 +6,149 @@ Multi-touch (MT) Protocol
|
|||
Introduction
|
||||
------------
|
||||
|
||||
In order to utilize the full power of the new multi-touch devices, a way to
|
||||
report detailed finger data to user space is needed. This document
|
||||
describes the multi-touch (MT) protocol which allows kernel drivers to
|
||||
report details for an arbitrary number of fingers.
|
||||
In order to utilize the full power of the new multi-touch and multi-user
|
||||
devices, a way to report detailed data from multiple contacts, i.e.,
|
||||
objects in direct contact with the device surface, is needed. This
|
||||
document describes the multi-touch (MT) protocol which allows kernel
|
||||
drivers to report details for an arbitrary number of contacts.
|
||||
|
||||
The protocol is divided into two types, depending on the capabilities of the
|
||||
hardware. For devices handling anonymous contacts (type A), the protocol
|
||||
describes how to send the raw data for all contacts to the receiver. For
|
||||
devices capable of tracking identifiable contacts (type B), the protocol
|
||||
describes how to send updates for individual contacts via event slots.
|
||||
|
||||
|
||||
Usage
|
||||
-----
|
||||
Protocol Usage
|
||||
--------------
|
||||
|
||||
Anonymous finger details are sent sequentially as separate packets of ABS
|
||||
events. Only the ABS_MT events are recognized as part of a finger
|
||||
packet. The end of a packet is marked by calling the input_mt_sync()
|
||||
function, which generates a SYN_MT_REPORT event. This instructs the
|
||||
receiver to accept the data for the current finger and prepare to receive
|
||||
another. The end of a multi-touch transfer is marked by calling the usual
|
||||
Contact details are sent sequentially as separate packets of ABS_MT
|
||||
events. Only the ABS_MT events are recognized as part of a contact
|
||||
packet. Since these events are ignored by current single-touch (ST)
|
||||
applications, the MT protocol can be implemented on top of the ST protocol
|
||||
in an existing driver.
|
||||
|
||||
Drivers for type A devices separate contact packets by calling
|
||||
input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
|
||||
event, which instructs the receiver to accept the data for the current
|
||||
contact and prepare to receive another.
|
||||
|
||||
Drivers for type B devices separate contact packets by calling
|
||||
input_mt_slot(), with a slot as argument, at the beginning of each packet.
|
||||
This generates an ABS_MT_SLOT event, which instructs the receiver to
|
||||
prepare for updates of the given slot.
|
||||
|
||||
All drivers mark the end of a multi-touch transfer by calling the usual
|
||||
input_sync() function. This instructs the receiver to act upon events
|
||||
accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new
|
||||
set of events/packets.
|
||||
accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set
|
||||
of events/packets.
|
||||
|
||||
The main difference between the stateless type A protocol and the stateful
|
||||
type B slot protocol lies in the usage of identifiable contacts to reduce
|
||||
the amount of data sent to userspace. The slot protocol requires the use of
|
||||
the ABS_MT_TRACKING_ID, either provided by the hardware or computed from
|
||||
the raw data [5].
|
||||
|
||||
For type A devices, the kernel driver should generate an arbitrary
|
||||
enumeration of the full set of anonymous contacts currently on the
|
||||
surface. The order in which the packets appear in the event stream is not
|
||||
important. Event filtering and finger tracking is left to user space [3].
|
||||
|
||||
For type B devices, the kernel driver should associate a slot with each
|
||||
identified contact, and use that slot to propagate changes for the contact.
|
||||
Creation, replacement and destruction of contacts is achieved by modifying
|
||||
the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id
|
||||
is interpreted as a contact, and the value -1 denotes an unused slot. A
|
||||
tracking id not previously present is considered new, and a tracking id no
|
||||
longer present is considered removed. Since only changes are propagated,
|
||||
the full state of each initiated contact has to reside in the receiving
|
||||
end. Upon receiving an MT event, one simply updates the appropriate
|
||||
attribute of the current slot.
|
||||
|
||||
|
||||
Protocol Example A
|
||||
------------------
|
||||
|
||||
Here is what a minimal event sequence for a two-contact touch would look
|
||||
like for a type A device:
|
||||
|
||||
ABS_MT_POSITION_X x[0]
|
||||
ABS_MT_POSITION_Y y[0]
|
||||
SYN_MT_REPORT
|
||||
ABS_MT_POSITION_X x[1]
|
||||
ABS_MT_POSITION_Y y[1]
|
||||
SYN_MT_REPORT
|
||||
SYN_REPORT
|
||||
|
||||
The sequence after moving one of the contacts looks exactly the same; the
|
||||
raw data for all present contacts are sent between every synchronization
|
||||
with SYN_REPORT.
|
||||
|
||||
Here is the sequence after lifting the first contact:
|
||||
|
||||
ABS_MT_POSITION_X x[1]
|
||||
ABS_MT_POSITION_Y y[1]
|
||||
SYN_MT_REPORT
|
||||
SYN_REPORT
|
||||
|
||||
And here is the sequence after lifting the second contact:
|
||||
|
||||
SYN_MT_REPORT
|
||||
SYN_REPORT
|
||||
|
||||
If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
|
||||
ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
|
||||
last SYN_REPORT will be dropped by the input core, resulting in no
|
||||
zero-contact event reaching userland.
|
||||
|
||||
|
||||
Protocol Example B
|
||||
------------------
|
||||
|
||||
Here is what a minimal event sequence for a two-contact touch would look
|
||||
like for a type B device:
|
||||
|
||||
ABS_MT_SLOT 0
|
||||
ABS_MT_TRACKING_ID 45
|
||||
ABS_MT_POSITION_X x[0]
|
||||
ABS_MT_POSITION_Y y[0]
|
||||
ABS_MT_SLOT 1
|
||||
ABS_MT_TRACKING_ID 46
|
||||
ABS_MT_POSITION_X x[1]
|
||||
ABS_MT_POSITION_Y y[1]
|
||||
SYN_REPORT
|
||||
|
||||
Here is the sequence after moving contact 45 in the x direction:
|
||||
|
||||
ABS_MT_SLOT 0
|
||||
ABS_MT_POSITION_X x[0]
|
||||
SYN_REPORT
|
||||
|
||||
Here is the sequence after lifting the contact in slot 0:
|
||||
|
||||
ABS_MT_TRACKING_ID -1
|
||||
SYN_REPORT
|
||||
|
||||
The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The
|
||||
message removes the association of slot 0 with contact 45, thereby
|
||||
destroying contact 45 and freeing slot 0 to be reused for another contact.
|
||||
|
||||
Finally, here is the sequence after lifting the second contact:
|
||||
|
||||
ABS_MT_SLOT 1
|
||||
ABS_MT_TRACKING_ID -1
|
||||
SYN_REPORT
|
||||
|
||||
|
||||
Event Usage
|
||||
-----------
|
||||
|
||||
A set of ABS_MT events with the desired properties is defined. The events
|
||||
are divided into categories, to allow for partial implementation. The
|
||||
minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which
|
||||
allows for multiple fingers to be tracked. If the device supports it, the
|
||||
allows for multiple contacts to be tracked. If the device supports it, the
|
||||
ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size
|
||||
of the contact area and approaching finger, respectively.
|
||||
of the contact area and approaching contact, respectively.
|
||||
|
||||
The TOUCH and WIDTH parameters have a geometrical interpretation; imagine
|
||||
looking through a window at someone gently holding a finger against the
|
||||
|
@ -41,56 +159,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is
|
|||
ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder
|
||||
against the glass. The inner region will increase, and in general, the
|
||||
ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than
|
||||
unity, is related to the finger pressure. For pressure-based devices,
|
||||
unity, is related to the contact pressure. For pressure-based devices,
|
||||
ABS_MT_PRESSURE may be used to provide the pressure on the contact area
|
||||
instead.
|
||||
|
||||
In addition to the MAJOR parameters, the oval shape of the finger can be
|
||||
In addition to the MAJOR parameters, the oval shape of the contact can be
|
||||
described by adding the MINOR parameters, such that MAJOR and MINOR are the
|
||||
major and minor axis of an ellipse. Finally, the orientation of the oval
|
||||
shape can be describe with the ORIENTATION parameter.
|
||||
|
||||
The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
|
||||
finger or a pen or something else. Devices with more granular information
|
||||
contact or a pen or something else. Devices with more granular information
|
||||
may specify general shapes as blobs, i.e., as a sequence of rectangular
|
||||
shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices
|
||||
that currently support it, the ABS_MT_TRACKING_ID event may be used to
|
||||
report finger tracking from hardware [5].
|
||||
report contact tracking from hardware [5].
|
||||
|
||||
Here is what a minimal event sequence for a two-finger touch would look
|
||||
like:
|
||||
|
||||
ABS_MT_POSITION_X
|
||||
ABS_MT_POSITION_Y
|
||||
SYN_MT_REPORT
|
||||
ABS_MT_POSITION_X
|
||||
ABS_MT_POSITION_Y
|
||||
SYN_MT_REPORT
|
||||
SYN_REPORT
|
||||
|
||||
Here is the sequence after lifting one of the fingers:
|
||||
|
||||
ABS_MT_POSITION_X
|
||||
ABS_MT_POSITION_Y
|
||||
SYN_MT_REPORT
|
||||
SYN_REPORT
|
||||
|
||||
And here is the sequence after lifting the remaining finger:
|
||||
|
||||
SYN_MT_REPORT
|
||||
SYN_REPORT
|
||||
|
||||
If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the
|
||||
ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the
|
||||
last SYN_REPORT will be dropped by the input core, resulting in no
|
||||
zero-finger event reaching userland.
|
||||
|
||||
Event Semantics
|
||||
---------------
|
||||
|
||||
The word "contact" is used to describe a tool which is in direct contact
|
||||
with the surface. A finger, a pen or a rubber all classify as contacts.
|
||||
|
||||
ABS_MT_TOUCH_MAJOR
|
||||
|
||||
The length of the major axis of the contact. The length should be given in
|
||||
|
@ -157,15 +245,16 @@ MT_TOOL_PEN [2].
|
|||
ABS_MT_BLOB_ID
|
||||
|
||||
The BLOB_ID groups several packets together into one arbitrarily shaped
|
||||
contact. This is a low-level anonymous grouping, and should not be confused
|
||||
with the high-level trackingID [5]. Most kernel drivers will not have blob
|
||||
capability, and can safely omit the event.
|
||||
contact. This is a low-level anonymous grouping for type A devices, and
|
||||
should not be confused with the high-level trackingID [5]. Most type A
|
||||
devices do not have blob capability, so drivers can safely omit this event.
|
||||
|
||||
ABS_MT_TRACKING_ID
|
||||
|
||||
The TRACKING_ID identifies an initiated contact throughout its life cycle
|
||||
[5]. There are currently only a few devices that support it, so this event
|
||||
should normally be omitted.
|
||||
[5]. This event is mandatory for type B devices. The value range of the
|
||||
TRACKING_ID should be large enough to ensure unique identification of a
|
||||
contact maintained over an extended period of time.
|
||||
|
||||
|
||||
Event Computation
|
||||
|
@ -192,20 +281,11 @@ finger along the X axis (1).
|
|||
Finger Tracking
|
||||
---------------
|
||||
|
||||
The kernel driver should generate an arbitrary enumeration of the set of
|
||||
anonymous contacts currently on the surface. The order in which the packets
|
||||
appear in the event stream is not important.
|
||||
|
||||
The process of finger tracking, i.e., to assign a unique trackingID to each
|
||||
initiated contact on the surface, is left to user space; preferably the
|
||||
multi-touch X driver [3]. In that driver, the trackingID stays the same and
|
||||
unique until the contact vanishes (when the finger leaves the surface). The
|
||||
problem of assigning a set of anonymous fingers to a set of identified
|
||||
fingers is a euclidian bipartite matching problem at each event update, and
|
||||
relies on a sufficiently rapid update rate.
|
||||
|
||||
There are a few devices that support trackingID in hardware. User space can
|
||||
make use of these native identifiers to reduce bandwidth and cpu usage.
|
||||
initiated contact on the surface, is a Euclidian Bipartite Matching
|
||||
problem. At each event synchronization, the set of actual contacts is
|
||||
matched to the set of contacts from the previous synchronization. A full
|
||||
implementation can be found in [3].
|
||||
|
||||
|
||||
Gestures
|
||||
|
|
|
@ -341,7 +341,7 @@ Byte 5~8: Don't care (Absolute packet)
|
|||
FSP supports basic PS/2 commanding set and modes, refer to following URL for
|
||||
details about PS/2 commands:
|
||||
|
||||
http://www.computer-engineering.org/index.php?title=PS/2_Mouse_Interface
|
||||
http://www.computer-engineering.org/ps2mouse/
|
||||
|
||||
==============================================================================
|
||||
* Programming Sequence for Determining Packet Parsing Flow
|
||||
|
|
|
@ -150,7 +150,7 @@ the basic functionality.
|
|||
|
||||
1. http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki)
|
||||
2. http://xpad.xbox-scene.com/
|
||||
3. http://www.xboxhackz.com/Hackz-Reference.htm
|
||||
3. http://www.markosweb.com/www/xboxhackz.com/
|
||||
|
||||
4. /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany):
|
||||
|
||||
|
|
|
@ -25,20 +25,18 @@ which has been updated for the new released platforms.
|
|||
Intel TXT has been presented at various events over the past few
|
||||
years, some of which are:
|
||||
LinuxTAG 2008:
|
||||
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag/
|
||||
details.html?talkid=110
|
||||
http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html
|
||||
TRUST2008:
|
||||
http://www.trust2008.eu/downloads/Keynote-Speakers/
|
||||
http://www.trust-conference.eu/downloads/Keynote-Speakers/
|
||||
3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
|
||||
IDF 2008, Shanghai:
|
||||
http://inteldeveloperforum.com.edgesuite.net/shanghai_2008/
|
||||
aep/PROS003/index.html
|
||||
IDF, Shanghai:
|
||||
http://www.prcidf.com.cn/index_en.html
|
||||
IDFs 2006, 2007 (I'm not sure if/where they are online)
|
||||
|
||||
Trusted Boot Project Overview:
|
||||
=============================
|
||||
|
||||
Trusted Boot (tboot) is an open source, pre- kernel/VMM module that
|
||||
Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
|
||||
uses Intel TXT to perform a measured and verified launch of an OS
|
||||
kernel/VMM.
|
||||
|
||||
|
|
|
@ -74,7 +74,7 @@ Code Seq#(hex) Include File Comments
|
|||
0x10 00-0F drivers/char/s390/vmcp.h
|
||||
0x12 all linux/fs.h
|
||||
linux/blkpg.h
|
||||
0x1b all InfiniBand Subsystem <http://www.openib.org/>
|
||||
0x1b all InfiniBand Subsystem <http://infiniband.sourceforge.net/>
|
||||
0x20 all drivers/cdrom/cm206.h
|
||||
0x22 all scsi/sg.h
|
||||
'#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem
|
||||
|
@ -190,7 +190,7 @@ Code Seq#(hex) Include File Comments
|
|||
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
|
||||
<mailto:gregkh@suse.de>
|
||||
'a' all linux/atm*.h, linux/sonet.h ATM on linux
|
||||
<http://lrcwww.epfl.ch/linux-atm/magic.html>
|
||||
<http://lrcwww.epfl.ch/>
|
||||
'b' 00-FF conflict! bit3 vme host bridge
|
||||
<mailto:natalia@nikhefk.nikhef.nl>
|
||||
'b' 00-0F media/bt819.h conflict!
|
||||
|
@ -225,7 +225,7 @@ Code Seq#(hex) Include File Comments
|
|||
'k' 00-0F linux/spi/spidev.h conflict!
|
||||
'k' 00-05 video/kyro.h conflict!
|
||||
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
|
||||
<http://mikonos.dia.unisa.it/tcfs>
|
||||
<http://web.archive.org/web/*/http://mikonos.dia.unisa.it/tcfs>
|
||||
'l' 40-7F linux/udf_fs_i.h in development:
|
||||
<http://sourceforge.net/projects/linux-udf/>
|
||||
'm' 00-09 linux/mmtimer.h conflict!
|
||||
|
@ -252,7 +252,7 @@ Code Seq#(hex) Include File Comments
|
|||
<mailto:giometti@linux.it>
|
||||
'q' 00-1F linux/serio.h
|
||||
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
|
||||
linux/ixjuser.h <http://www.quicknet.net>
|
||||
linux/ixjuser.h <http://web.archive.org/web/*/http://www.quicknet.net>
|
||||
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
|
||||
's' all linux/cdk.h
|
||||
't' 00-7F linux/if_ppp.h
|
||||
|
@ -286,7 +286,7 @@ Code Seq#(hex) Include File Comments
|
|||
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
|
||||
0x8B all linux/wireless.h
|
||||
0x8C 00-3F WiNRADiO driver
|
||||
<http://www.proximity.com.au/~brian/winradio/>
|
||||
<http://www.winradio.com.au/>
|
||||
0x90 00 drivers/cdrom/sbpcd.h
|
||||
0x92 00-0F drivers/usb/mon/mon_bin.c
|
||||
0x93 60-7F linux/auto_fs.h
|
||||
|
|
|
@ -36,7 +36,7 @@ README for the ISDN-subsystem
|
|||
http://www.mhessler.de/i4lfaq/
|
||||
It can be viewed online, or downloaded in sgml/text/html format.
|
||||
The FAQ can also be viewed online at
|
||||
http://www.isdn4inux.de/faq/
|
||||
http://www.isdn4linux.de/faq/
|
||||
or downloaded from
|
||||
ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/
|
||||
|
||||
|
|
|
@ -486,7 +486,7 @@ Appendix: Teles PCMCIA driver
|
|||
-----------------------------
|
||||
|
||||
See
|
||||
http://www.stud.uni-wuppertal.de/~ea0141/pcmcia.html
|
||||
http://www.linux.no/teles_cs.txt
|
||||
for instructions.
|
||||
|
||||
Appendix: Linux and ISDN-leased lines
|
||||
|
|
|
@ -223,7 +223,7 @@ web サイトには、コードの構成、サブシステム、現在存在す
|
|||
あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ
|
||||
ニティに参加して何かすることをさがしている場合には、Linux kernel
|
||||
Janitor's プロジェクトにいけば良いでしょう -
|
||||
http://janitor.kernelnewbies.org/
|
||||
http://kernelnewbies.org/KernelJanitors
|
||||
ここはそのようなスタートをするのにうってつけの場所です。ここには、
|
||||
Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな
|
||||
らない、単純な問題のリストが記述されています。このプロジェクトに関わる
|
||||
|
|
|
@ -97,7 +97,7 @@ Quilt:
|
|||
http://savannah.nongnu.org/projects/quilt
|
||||
|
||||
Andrew Morton's patch scripts:
|
||||
http://www.zip.com.au/~akpm/linux/patches/
|
||||
http://userweb.kernel.org/~akpm/stuff/tpp.txt
|
||||
このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント
|
||||
ツールとして推奨されています(上のリンクを見てください)。
|
||||
|
||||
|
@ -210,7 +210,7 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの
|
|||
・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で
|
||||
あればアーキテクチャ特有のことでも他の人がコピーできます)
|
||||
・作者やメンテナによる修正(すなわち patch monkey の再転送モード)
|
||||
URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
|
||||
EMAIL: <trivial@kernel.org>
|
||||
|
||||
7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ
|
||||
|
||||
|
@ -534,7 +534,7 @@ gcc においては、マクロと同じくらい軽いです。
|
|||
----------------------
|
||||
|
||||
Andrew Morton, "The perfect patch" (tpp).
|
||||
<http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
|
||||
<http://userweb.kernel.org/~akpm/stuff/tpp.txt>
|
||||
|
||||
Jeff Garzik, "Linux kernel patch submission format".
|
||||
<http://linux.yyz.us/patch-format.html>
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue