mirror of
https://github.com/joel16/android_kernel_sony_msm8994.git
synced 2024-11-27 14:11:04 +00:00
Merge branch 'master' into for-linus
This commit is contained in:
commit
ab11b48740
@ -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/
|
||||
|
20
Documentation/ABI/testing/debugfs-ec
Normal file
20
Documentation/ABI/testing/debugfs-ec
Normal file
@ -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.
|
@ -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
|
||||
---------
|
||||
|
@ -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>
|
||||
|
@ -199,10 +199,33 @@
|
||||
may be configured as a kernel built-in or a kernel loadable module.
|
||||
You can only make use of <constant>kgdbwait</constant> and early
|
||||
debugging if you build kgdboc into the kernel as a built-in.
|
||||
<para>Optionally you can elect to activate kms (Kernel Mode
|
||||
Setting) integration. When you use kms with kgdboc and you have a
|
||||
video driver that has atomic mode setting hooks, it is possible to
|
||||
enter the debugger on the graphics console. When the kernel
|
||||
execution is resumed, the previous graphics mode will be restored.
|
||||
This integration can serve as a useful tool to aid in diagnosing
|
||||
crashes or doing analysis of memory with kdb while allowing the
|
||||
full graphics console applications to run.
|
||||
</para>
|
||||
</para>
|
||||
<sect2 id="kgdbocArgs">
|
||||
<title>kgdboc arguments</title>
|
||||
<para>Usage: <constant>kgdboc=[kbd][[,]serial_device][,baud]</constant></para>
|
||||
<para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>
|
||||
<para>The order listed above must be observed if you use any of the
|
||||
optional configurations together.
|
||||
</para>
|
||||
<para>Abbreviations:
|
||||
<itemizedlist>
|
||||
<listitem><para>kms = Kernel Mode Setting</para></listitem>
|
||||
<listitem><para>kbd = Keyboard</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
||||
device depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios. The order listed above must be observed if
|
||||
you use any of the optional configurations together. Using kms +
|
||||
only gdb is generally not a useful combination.</para>
|
||||
<sect3 id="kgdbocArgs1">
|
||||
<title>Using loadable module or built-in</title>
|
||||
<para>
|
||||
@ -212,7 +235,7 @@
|
||||
<listitem>
|
||||
<para>As a kernel loadable module:</para>
|
||||
<para>Use the command: <constant>modprobe kgdboc kgdboc=<tty-device>,[baud]</constant></para>
|
||||
<para>Here are two examples of how you might formate the kgdboc
|
||||
<para>Here are two examples of how you might format the kgdboc
|
||||
string. The first is for an x86 target using the first serial port.
|
||||
The second example is for the ARM Versatile AB using the second
|
||||
serial port.
|
||||
@ -240,6 +263,9 @@
|
||||
</sect3>
|
||||
<sect3 id="kgdbocArgs3">
|
||||
<title>More examples</title>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
||||
device depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios.</para>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial device
|
||||
depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios.
|
||||
@ -255,6 +281,12 @@
|
||||
<listitem><para>kdb with a keyboard</para>
|
||||
<para><constant>kgdboc=kbd</constant></para>
|
||||
</listitem>
|
||||
<listitem><para>kdb with kernel mode setting</para>
|
||||
<para><constant>kgdboc=kms,kbd</constant></para>
|
||||
</listitem>
|
||||
<listitem><para>kdb with kernel mode setting and kgdb over a serial port</para>
|
||||
<para><constant>kgdboc=kms,kbd,ttyS0,115200</constant></para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</sect3>
|
||||
@ -637,6 +669,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
<listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem>
|
||||
<listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem>
|
||||
<listitem><para>The API to invoke either the kdb or kgdb frontend to the debug core.</para></listitem>
|
||||
<listitem><para>The structures and callback API for atomic kernel mode setting.</para>
|
||||
<para>NOTE: kgdboc is where the kms callbacks are invoked.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
@ -747,6 +781,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
</sect1>
|
||||
<sect1 id="kgdbocDesign">
|
||||
<title>kgdboc internals</title>
|
||||
<sect2>
|
||||
<title>kgdboc and uarts</title>
|
||||
<para>
|
||||
The kgdboc driver is actually a very thin driver that relies on the
|
||||
underlying low level to the hardware driver having "polling hooks"
|
||||
@ -754,11 +790,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
implementation of kgdboc it the serial_core was changed to expose a
|
||||
low level UART hook for doing polled mode reading and writing of a
|
||||
single character while in an atomic context. When kgdb makes an I/O
|
||||
request to the debugger, kgdboc invokes a call back in the serial
|
||||
core which in turn uses the call back in the UART driver. It is
|
||||
certainly possible to extend kgdboc to work with non-UART based
|
||||
consoles in the future.
|
||||
</para>
|
||||
request to the debugger, kgdboc invokes a callback in the serial
|
||||
core which in turn uses the callback in the UART driver.</para>
|
||||
<para>
|
||||
When using kgdboc with a UART, the UART driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting>
|
||||
#ifdef CONFIG_CONSOLE_POLL
|
||||
@ -772,9 +805,68 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
that they can be called from an atomic context and have to restore
|
||||
the state of the UART chip on return such that the system can return
|
||||
to normal when the debugger detaches. You need to be very careful
|
||||
with any kind of lock you consider, because failing here is most
|
||||
with any kind of lock you consider, because failing here is most likely
|
||||
going to mean pressing the reset button.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="kgdbocKbd">
|
||||
<title>kgdboc and keyboards</title>
|
||||
<para>The kgdboc driver contains logic to configure communications
|
||||
with an attached keyboard. The keyboard infrastructure is only
|
||||
compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the
|
||||
kernel configuration.</para>
|
||||
<para>The core polled keyboard driver driver for PS/2 type keyboards
|
||||
is in drivers/char/kdb_keyboard.c. This driver is hooked into the
|
||||
debug core when kgdboc populates the callback in the array
|
||||
called <constant>kdb_poll_funcs[]</constant>. The
|
||||
kdb_get_kbd_char() is the top-level function which polls hardware
|
||||
for single character input.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="kgdbocKms">
|
||||
<title>kgdboc and kms</title>
|
||||
<para>The kgdboc driver contains logic to request the graphics
|
||||
display to switch to a text context when you are using
|
||||
"kgdboc=kms,kbd", provided that you have a video driver which has a
|
||||
frame buffer console and atomic kernel mode setting support.</para>
|
||||
<para>
|
||||
Every time the kernel
|
||||
debugger is entered it calls kgdboc_pre_exp_handler() which in turn
|
||||
calls con_debug_enter() in the virtual console layer. On resuming kernel
|
||||
execution, the kernel debugger calls kgdboc_post_exp_handler() which
|
||||
in turn calls con_debug_leave().</para>
|
||||
<para>Any video driver that wants to be compatible with the kernel
|
||||
debugger and the atomic kms callbacks must implement the
|
||||
mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations.
|
||||
For the fb_debug_enter and fb_debug_leave the option exists to use
|
||||
the generic drm fb helper functions or implement something custom for
|
||||
the hardware. The following example shows the initialization of the
|
||||
.mode_set_base_atomic operation in
|
||||
drivers/gpu/drm/i915/intel_display.c:
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
static const struct drm_crtc_helper_funcs intel_helper_funcs = {
|
||||
[...]
|
||||
.mode_set_base_atomic = intel_pipe_set_base_atomic,
|
||||
[...]
|
||||
};
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
<para>Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in
|
||||
drivers/gpu/drm/i915/intel_fb.c:
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
static struct fb_ops intelfb_ops = {
|
||||
[...]
|
||||
.fb_debug_enter = drm_fb_helper_debug_enter,
|
||||
.fb_debug_leave = drm_fb_helper_debug_leave,
|
||||
[...]
|
||||
};
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="credits">
|
||||
|
@ -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>
|
||||
|
@ -6,4 +6,5 @@
|
||||
<param name="callout.graphics">0</param>
|
||||
<!-- <param name="paper.type">A4</param> -->
|
||||
<param name="generate.section.toc.level">2</param>
|
||||
<param name="use.id.as.filename">1</param>
|
||||
</stylesheet>
|
||||
|
@ -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
|
||||
-->
|
||||
|
235
Documentation/DocBook/v4l/lirc_device_interface.xml
Normal file
235
Documentation/DocBook/v4l/lirc_device_interface.xml
Normal file
@ -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;
|
||||
|
@ -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!
|
||||
|
||||
|
39
Documentation/apparmor.txt
Normal file
39
Documentation/apparmor.txt
Normal file
@ -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>
|
||||
|
@ -7,7 +7,7 @@ Notes Written on Jan 15, 2002:
|
||||
|
||||
Last Updated May 2, 2002
|
||||
September 2003: Updated I/O Scheduler portions
|
||||
Nick Piggin <piggin@cyberone.com.au>
|
||||
Nick Piggin <npiggin@kernel.dk>
|
||||
|
||||
Introduction:
|
||||
|
||||
|
@ -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)
|
||||
|
||||
|
258
Documentation/coccinelle.txt
Normal file
258
Documentation/coccinelle.txt
Normal file
@ -0,0 +1,258 @@
|
||||
Copyright 2010 Nicolas Palix <npalix@diku.dk>
|
||||
Copyright 2010 Julia Lawall <julia@diku.dk>
|
||||
Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
|
||||
|
||||
|
||||
Getting Coccinelle
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The semantic patches included in the kernel use the 'virtual rule'
|
||||
feature which was introduced in Coccinelle version 0.1.11.
|
||||
|
||||
Coccinelle (>=0.2.0) is available through the package manager
|
||||
of many distributions, e.g. :
|
||||
|
||||
- Debian (>=squeeze)
|
||||
- Fedora (>=13)
|
||||
- Ubuntu (>=10.04 Lucid Lynx)
|
||||
- OpenSUSE
|
||||
- Arch Linux
|
||||
- NetBSD
|
||||
- FreeBSD
|
||||
|
||||
|
||||
You can get the latest version released from the Coccinelle homepage at
|
||||
http://coccinelle.lip6.fr/
|
||||
|
||||
Once you have it, run the following command:
|
||||
|
||||
./configure
|
||||
make
|
||||
|
||||
as a regular user, and install it with
|
||||
|
||||
sudo make install
|
||||
|
||||
|
||||
Using Coccinelle on the Linux kernel
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A Coccinelle-specific target is defined in the top level
|
||||
Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
|
||||
front-end in the 'scripts' directory.
|
||||
|
||||
Four modes are defined: report, patch, context, and org. The mode to
|
||||
use is specified by setting the MODE variable with 'MODE=<mode>'.
|
||||
|
||||
'report' generates a list in the following format:
|
||||
file:line:column-column: message
|
||||
|
||||
'patch' proposes a fix, when possible.
|
||||
|
||||
'context' highlights lines of interest and their context in a
|
||||
diff-like style.Lines of interest are indicated with '-'.
|
||||
|
||||
'org' generates a report in the Org mode format of Emacs.
|
||||
|
||||
Note that not all semantic patches implement all modes.
|
||||
|
||||
To make a report for every semantic patch, run the following command:
|
||||
|
||||
make coccicheck MODE=report
|
||||
|
||||
NB: The 'report' mode is the default one.
|
||||
|
||||
To produce patches, run:
|
||||
|
||||
make coccicheck MODE=patch
|
||||
|
||||
|
||||
The coccicheck target applies every semantic patch available in the
|
||||
subdirectories of 'scripts/coccinelle' to the entire Linux kernel.
|
||||
|
||||
For each semantic patch, a changelog message is proposed. It gives a
|
||||
description of the problem being checked by the semantic patch, and
|
||||
includes a reference to Coccinelle.
|
||||
|
||||
As any static code analyzer, Coccinelle produces false
|
||||
positives. Thus, reports must be carefully checked, and patches
|
||||
reviewed.
|
||||
|
||||
|
||||
Using Coccinelle with a single semantic patch
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The optional make variable COCCI can be used to check a single
|
||||
semantic patch. In that case, the variable must be initialized with
|
||||
the name of the semantic patch to apply.
|
||||
|
||||
For instance:
|
||||
|
||||
make coccicheck COCCI=<my_SP.cocci> MODE=patch
|
||||
or
|
||||
make coccicheck COCCI=<my_SP.cocci> MODE=report
|
||||
|
||||
|
||||
Proposing new semantic patches
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
New semantic patches can be proposed and submitted by kernel
|
||||
developers. For sake of clarity, they should be organized in the
|
||||
subdirectories of 'scripts/coccinelle/'.
|
||||
|
||||
|
||||
Detailed description of the 'report' mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
'report' generates a list in the following format:
|
||||
file:line:column-column: message
|
||||
|
||||
Example:
|
||||
|
||||
Running
|
||||
|
||||
make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci
|
||||
|
||||
will execute the following part of the SmPL script.
|
||||
|
||||
<smpl>
|
||||
@r depends on !context && !patch && (org || report)@
|
||||
expression x;
|
||||
position p;
|
||||
@@
|
||||
|
||||
ERR_PTR@p(PTR_ERR(x))
|
||||
|
||||
@script:python depends on report@
|
||||
p << r.p;
|
||||
x << r.x;
|
||||
@@
|
||||
|
||||
msg="ERR_CAST can be used with %s" % (x)
|
||||
coccilib.report.print_report(p[0], msg)
|
||||
</smpl>
|
||||
|
||||
This SmPL excerpt generates entries on the standard output, as
|
||||
illustrated below:
|
||||
|
||||
/home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg
|
||||
/home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth
|
||||
/home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg
|
||||
|
||||
|
||||
Detailed description of the 'patch' mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When the 'patch' mode is available, it proposes a fix for each problem
|
||||
identified.
|
||||
|
||||
Example:
|
||||
|
||||
Running
|
||||
make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci
|
||||
|
||||
will execute the following part of the SmPL script.
|
||||
|
||||
<smpl>
|
||||
@ depends on !context && patch && !org && !report @
|
||||
expression x;
|
||||
@@
|
||||
|
||||
- ERR_PTR(PTR_ERR(x))
|
||||
+ ERR_CAST(x)
|
||||
</smpl>
|
||||
|
||||
This SmPL excerpt generates patch hunks on the standard output, as
|
||||
illustrated below:
|
||||
|
||||
diff -u -p a/crypto/ctr.c b/crypto/ctr.c
|
||||
--- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
|
||||
+++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200
|
||||
@@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct
|
||||
alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
|
||||
CRYPTO_ALG_TYPE_MASK);
|
||||
if (IS_ERR(alg))
|
||||
- return ERR_PTR(PTR_ERR(alg));
|
||||
+ return ERR_CAST(alg);
|
||||
|
||||
/* Block size must be >= 4 bytes. */
|
||||
err = -EINVAL;
|
||||
|
||||
Detailed description of the 'context' mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
'context' highlights lines of interest and their context
|
||||
in a diff-like style.
|
||||
|
||||
NOTE: The diff-like output generated is NOT an applicable patch. The
|
||||
intent of the 'context' mode is to highlight the important lines
|
||||
(annotated with minus, '-') and gives some surrounding context
|
||||
lines around. This output can be used with the diff mode of
|
||||
Emacs to review the code.
|
||||
|
||||
Example:
|
||||
|
||||
Running
|
||||
make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci
|
||||
|
||||
will execute the following part of the SmPL script.
|
||||
|
||||
<smpl>
|
||||
@ depends on context && !patch && !org && !report@
|
||||
expression x;
|
||||
@@
|
||||
|
||||
* ERR_PTR(PTR_ERR(x))
|
||||
</smpl>
|
||||
|
||||
This SmPL excerpt generates diff hunks on the standard output, as
|
||||
illustrated below:
|
||||
|
||||
diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
|
||||
--- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200
|
||||
+++ /tmp/nothing
|
||||
@@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct
|
||||
alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER,
|
||||
CRYPTO_ALG_TYPE_MASK);
|
||||
if (IS_ERR(alg))
|
||||
- return ERR_PTR(PTR_ERR(alg));
|
||||
|
||||
/* Block size must be >= 4 bytes. */
|
||||
err = -EINVAL;
|
||||
|
||||
Detailed description of the 'org' mode
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
'org' generates a report in the Org mode format of Emacs.
|
||||
|
||||
Example:
|
||||
|
||||
Running
|
||||
make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci
|
||||
|
||||
will execute the following part of the SmPL script.
|
||||
|
||||
<smpl>
|
||||
@r depends on !context && !patch && (org || report)@
|
||||
expression x;
|
||||
position p;
|
||||
@@
|
||||
|
||||
ERR_PTR@p(PTR_ERR(x))
|
||||
|
||||
@script:python depends on org@
|
||||
p << r.p;
|
||||
x << r.x;
|
||||
@@
|
||||
|
||||
msg="ERR_CAST can be used with %s" % (x)
|
||||
msg_safe=msg.replace("[","@(").replace("]",")")
|
||||
coccilib.org.print_todo(p[0], msg_safe)
|
||||
</smpl>
|
||||
|
||||
This SmPL excerpt generates Org entries on the standard output, as
|
||||
illustrated below:
|
||||
|
||||
* TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]]
|
||||
* TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]]
|
||||
* TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]]
|
@ -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
|
||||
|
||||
|
@ -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>
|
||||
|
||||
---------------------------
|
||||
|
||||
@ -303,15 +303,6 @@ Who: Johannes Berg <johannes@sipsolutions.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_NF_CT_ACCT
|
||||
When: 2.6.29
|
||||
Why: Accounting can now be enabled/disabled without kernel recompilation.
|
||||
Currently used only to set a default value for a feature that is also
|
||||
controlled by a kernel/module/sysfs/sysctl parameter.
|
||||
Who: Krzysztof Piotr Oledzki <ole@ans.pl>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: sysfs ui for changing p4-clockmod parameters
|
||||
When: September 2009
|
||||
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
|
||||
@ -377,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
|
||||
@ -459,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
|
||||
@ -538,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
|
||||
@ -559,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
|
||||
@ -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
|
||||
|
@ -124,6 +124,8 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
|
||||
|
||||
<hostname> Name of the client. May be supplied by autoconfiguration,
|
||||
but its absence will not trigger autoconfiguration.
|
||||
If specified and DHCP is used, the user provided hostname will
|
||||
be carried in the DHCP request to hopefully update DNS record.
|
||||
|
||||
Default: Client IP address is used in ASCII notation.
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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,7 +3,7 @@ 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>,
|
||||
|
@ -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>
|
||||
|
||||
|
@ -3,7 +3,7 @@ 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>,
|
||||
|
@ -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
|
||||
|
@ -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 ?
|
||||
|
||||
|
@ -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
|
||||
|
@ -113,12 +113,16 @@ char *driver_name
|
||||
int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata)
|
||||
(optional) pointer to a callback function for sending firmware and
|
||||
configuration data to the device
|
||||
The function may return before the operation has completed.
|
||||
Completion must be signalled by a call to capi_ctr_ready().
|
||||
Return value: 0 on success, error code on error
|
||||
Called in process context.
|
||||
|
||||
void (*reset_ctr)(struct capi_ctr *ctrlr)
|
||||
(optional) pointer to a callback function for performing a reset on
|
||||
the device, releasing all registered applications
|
||||
(optional) pointer to a callback function for stopping the device,
|
||||
releasing all registered applications
|
||||
The function may return before the operation has completed.
|
||||
Completion must be signalled by a call to capi_ctr_down().
|
||||
Called in process context.
|
||||
|
||||
void (*register_appl)(struct capi_ctr *ctrlr, u16 applid,
|
||||
|
@ -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
|
||||
|
@ -47,9 +47,9 @@ GigaSet 307x Device Driver
|
||||
|
||||
1.2. Software
|
||||
--------
|
||||
The driver works with ISDN4linux and so can be used with any software
|
||||
which is able to use ISDN4linux for ISDN connections (voice or data).
|
||||
Experimental Kernel CAPI support is available as a compilation option.
|
||||
The driver works with the Kernel CAPI subsystem as well as the old
|
||||
ISDN4Linux subsystem, so it can be used with any software which is able
|
||||
to use CAPI 2.0 or ISDN4Linux for ISDN connections (voice or data).
|
||||
|
||||
There are some user space tools available at
|
||||
http://sourceforge.net/projects/gigaset307x/
|
||||
@ -152,61 +152,42 @@ GigaSet 307x Device Driver
|
||||
- GIGVER_FWBASE: retrieve the firmware version of the base
|
||||
Upon return, version[] is filled with the requested version information.
|
||||
|
||||
2.3. ISDN4linux
|
||||
----------
|
||||
This is the "normal" mode of operation. After loading the module you can
|
||||
set up the ISDN system just as you'd do with any ISDN card supported by
|
||||
the ISDN4Linux subsystem. Most distributions provide some configuration
|
||||
utility. If not, you can use some HOWTOs like
|
||||
http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html
|
||||
If this doesn't work, because you have some device like SX100 where
|
||||
debug output (see section 3.2.) shows something like this when dialing
|
||||
CMD Received: ERROR
|
||||
Available Params: 0
|
||||
Connection State: 0, Response: -1
|
||||
gigaset_process_response: resp_code -1 in ConState 0 !
|
||||
Timeout occurred
|
||||
you probably need to use unimodem mode. (see section 2.5.)
|
||||
|
||||
2.4. CAPI
|
||||
2.3. CAPI
|
||||
----
|
||||
If the driver is compiled with CAPI support (kernel configuration option
|
||||
GIGASET_CAPI, experimental) it can also be used with CAPI 2.0 kernel and
|
||||
user space applications. For user space access, the module capi.ko must
|
||||
be loaded. The capiinit command (included in the capi4k-utils package)
|
||||
does this for you.
|
||||
GIGASET_CAPI) the devices will show up as CAPI controllers as soon as the
|
||||
corresponding driver module is loaded, and can then be used with CAPI 2.0
|
||||
kernel and user space applications. For user space access, the module
|
||||
capi.ko must be loaded.
|
||||
|
||||
The CAPI variant of the driver supports legacy ISDN4Linux applications
|
||||
via the capidrv compatibility driver. The kernel module capidrv.ko must
|
||||
be loaded explicitly with the command
|
||||
Legacy ISDN4Linux applications are supported via the capidrv
|
||||
compatibility driver. The kernel module capidrv.ko must be loaded
|
||||
explicitly with the command
|
||||
modprobe capidrv
|
||||
if needed, and cannot be unloaded again without unloading the driver
|
||||
first. (These are limitations of capidrv.)
|
||||
|
||||
The note about unimodem mode in the preceding section applies here, too.
|
||||
Most distributions handle loading and unloading of the various CAPI
|
||||
modules automatically via the command capiinit(1) from the capi4k-utils
|
||||
package or a similar mechanism. Note that capiinit(1) cannot unload the
|
||||
Gigaset drivers because it doesn't support more than one module per
|
||||
driver.
|
||||
|
||||
2.4. ISDN4Linux
|
||||
----------
|
||||
If the driver is compiled without CAPI support (native ISDN4Linux
|
||||
variant), it registers the device with the legacy ISDN4Linux subsystem
|
||||
after loading the module. It can then be used with ISDN4Linux
|
||||
applications only. Most distributions provide some configuration utility
|
||||
for setting up that subsystem. Otherwise you can use some HOWTOs like
|
||||
http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html
|
||||
|
||||
|
||||
2.5. Unimodem mode
|
||||
-------------
|
||||
This is needed for some devices [e.g. SX100] as they have problems with
|
||||
the "normal" commands.
|
||||
|
||||
If you have installed the command line tool gigacontr, you can enter
|
||||
unimodem mode using
|
||||
gigacontr --mode unimodem
|
||||
You can switch back using
|
||||
gigacontr --mode isdn
|
||||
|
||||
You can also put the driver directly into Unimodem mode when it's loaded,
|
||||
by passing the module parameter startmode=0 to the hardware specific
|
||||
module, e.g.
|
||||
modprobe usb_gigaset startmode=0
|
||||
or by adding a line like
|
||||
options usb_gigaset startmode=0
|
||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
||||
or /etc/modprobe.conf.local.
|
||||
|
||||
In this mode the device works like a modem connected to a serial port
|
||||
(the /dev/ttyGU0, ... mentioned above) which understands the commands
|
||||
|
||||
ATZ init, reset
|
||||
=> OK or ERROR
|
||||
ATD
|
||||
@ -234,6 +215,31 @@ GigaSet 307x Device Driver
|
||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
||||
or /etc/modprobe.conf.local.
|
||||
|
||||
Unimodem mode is needed for making some devices [e.g. SX100] work which
|
||||
do not support the regular Gigaset command set. If debug output (see
|
||||
section 3.2.) shows something like this when dialing:
|
||||
CMD Received: ERROR
|
||||
Available Params: 0
|
||||
Connection State: 0, Response: -1
|
||||
gigaset_process_response: resp_code -1 in ConState 0 !
|
||||
Timeout occurred
|
||||
then switching to unimodem mode may help.
|
||||
|
||||
If you have installed the command line tool gigacontr, you can enter
|
||||
unimodem mode using
|
||||
gigacontr --mode unimodem
|
||||
You can switch back using
|
||||
gigacontr --mode isdn
|
||||
|
||||
You can also put the driver directly into Unimodem mode when it's loaded,
|
||||
by passing the module parameter startmode=0 to the hardware specific
|
||||
module, e.g.
|
||||
modprobe usb_gigaset startmode=0
|
||||
or by adding a line like
|
||||
options usb_gigaset startmode=0
|
||||
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
|
||||
or /etc/modprobe.conf.local.
|
||||
|
||||
2.6. Call-ID (CID) mode
|
||||
------------------
|
||||
Call-IDs are numbers used to tag commands to, and responses from, the
|
||||
@ -263,7 +269,22 @@ GigaSet 307x Device Driver
|
||||
change its CID mode while the driver is loaded, eg.
|
||||
echo 0 > /sys/class/tty/ttyGU0/cidmode
|
||||
|
||||
2.7. Unregistered Wireless Devices (M101/M105)
|
||||
2.7. Dialing Numbers
|
||||
---------------
|
||||
The called party number provided by an application for dialing out must
|
||||
be a public network number according to the local dialing plan, without
|
||||
any dial prefix for getting an outside line.
|
||||
|
||||
Internal calls can be made by providing an internal extension number
|
||||
prefixed with "**" (two asterisks) as the called party number. So to dial
|
||||
eg. the first registered DECT handset, give "**11" as the called party
|
||||
number. Dialing "***" (three asterisks) calls all extensions
|
||||
simultaneously (global call).
|
||||
|
||||
This holds for both CAPI 2.0 and ISDN4Linux applications. Unimodem mode
|
||||
does not support internal calls.
|
||||
|
||||
2.8. Unregistered Wireless Devices (M101/M105)
|
||||
-----------------------------------------
|
||||
The main purpose of the ser_gigaset and usb_gigaset drivers is to allow
|
||||
the M101 and M105 wireless devices to be used as ISDN devices for ISDN
|
||||
|
@ -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>
|
||||
|
@ -22,11 +22,33 @@ building C files and assembler files.
|
||||
|
||||
KAFLAGS
|
||||
--------------------------------------------------
|
||||
Additional options to the assembler.
|
||||
Additional options to the assembler (for built-in and modules).
|
||||
|
||||
AFLAGS_MODULE
|
||||
--------------------------------------------------
|
||||
Addtional module specific options to use for $(AS).
|
||||
|
||||
AFLAGS_KERNEL
|
||||
--------------------------------------------------
|
||||
Addtional options for $(AS) when used for assembler
|
||||
code for code that is compiled as built-in.
|
||||
|
||||
KCFLAGS
|
||||
--------------------------------------------------
|
||||
Additional options to the C compiler.
|
||||
Additional options to the C compiler (for built-in and modules).
|
||||
|
||||
CFLAGS_KERNEL
|
||||
--------------------------------------------------
|
||||
Addtional options for $(CC) when used to compile
|
||||
code that is compiled as built-in.
|
||||
|
||||
CFLAGS_MODULE
|
||||
--------------------------------------------------
|
||||
Addtional module specific options to use for $(CC).
|
||||
|
||||
LDFLAGS_MODULE
|
||||
--------------------------------------------------
|
||||
Additional options used for $(LD) when linking modules.
|
||||
|
||||
KBUILD_VERBOSE
|
||||
--------------------------------------------------
|
||||
@ -40,15 +62,15 @@ Set the directory to look for the kernel source when building external
|
||||
modules.
|
||||
The directory can be specified in several ways:
|
||||
1) Use "M=..." on the command line
|
||||
2) Environmnet variable KBUILD_EXTMOD
|
||||
3) Environmnet variable SUBDIRS
|
||||
2) Environment variable KBUILD_EXTMOD
|
||||
3) Environment variable SUBDIRS
|
||||
The possibilities are listed in the order they take precedence.
|
||||
Using "M=..." will always override the others.
|
||||
|
||||
KBUILD_OUTPUT
|
||||
--------------------------------------------------
|
||||
Specify the output directory when building the kernel.
|
||||
The output directory can also be specificed using "O=...".
|
||||
The output directory can also be specified using "O=...".
|
||||
Setting "O=..." takes precedence over KBUILD_OUTPUT.
|
||||
|
||||
ARCH
|
||||
@ -90,7 +112,7 @@ The script will be called with the following arguments:
|
||||
$3 - kernel map file
|
||||
$4 - default install path (use root directory if blank)
|
||||
|
||||
The implmentation of "make install" is architecture specific
|
||||
The implementation of "make install" is architecture specific
|
||||
and it may differ from the above.
|
||||
|
||||
INSTALLKERNEL is provided to enable the possibility to
|
||||
|
@ -65,7 +65,7 @@ also use the environment variable KCONFIG_ALLCONFIG as a flag or a
|
||||
filename that contains config symbols that the user requires to be
|
||||
set to a specific value. If KCONFIG_ALLCONFIG is used without a
|
||||
filename, "make *config" checks for a file named
|
||||
"all{yes/mod/no/random}.config" (corresponding to the *config command
|
||||
"all{yes/mod/no/def/random}.config" (corresponding to the *config command
|
||||
that was used) for symbol values that are to be forced. If this file
|
||||
is not found, it checks for a file named "all.config" to contain forced
|
||||
values.
|
||||
|
@ -168,7 +168,7 @@ more details, with real examples.
|
||||
#drivers/isdn/i4l/Makefile
|
||||
# Makefile for the kernel ISDN subsystem and device drivers.
|
||||
# Each configuration option enables a list of files.
|
||||
obj-$(CONFIG_ISDN) += isdn.o
|
||||
obj-$(CONFIG_ISDN_I4L) += isdn.o
|
||||
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
|
||||
|
||||
--- 3.3 Loadable module goals - obj-m
|
||||
@ -187,34 +187,35 @@ more details, with real examples.
|
||||
Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm'
|
||||
|
||||
If a kernel module is built from several source files, you specify
|
||||
that you want to build a module in the same way as above.
|
||||
|
||||
Kbuild needs to know which the parts that you want to build your
|
||||
module from, so you have to tell it by setting an
|
||||
$(<module_name>-objs) variable.
|
||||
that you want to build a module in the same way as above; however,
|
||||
kbuild needs to know which object files you want to build your
|
||||
module from, so you have to tell it by setting a $(<module_name>-y)
|
||||
variable.
|
||||
|
||||
Example:
|
||||
#drivers/isdn/i4l/Makefile
|
||||
obj-$(CONFIG_ISDN) += isdn.o
|
||||
isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
|
||||
obj-$(CONFIG_ISDN_I4L) += isdn.o
|
||||
isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o
|
||||
|
||||
In this example, the module name will be isdn.o. Kbuild will
|
||||
compile the objects listed in $(isdn-objs) and then run
|
||||
compile the objects listed in $(isdn-y) and then run
|
||||
"$(LD) -r" on the list of these files to generate isdn.o.
|
||||
|
||||
Kbuild recognises objects used for composite objects by the suffix
|
||||
-objs, and the suffix -y. This allows the Makefiles to use
|
||||
the value of a CONFIG_ symbol to determine if an object is part
|
||||
of a composite object.
|
||||
Due to kbuild recognizing $(<module_name>-y) for composite objects,
|
||||
you can use the value of a CONFIG_ symbol to optionally include an
|
||||
object file as part of a composite object.
|
||||
|
||||
Example:
|
||||
#fs/ext2/Makefile
|
||||
obj-$(CONFIG_EXT2_FS) += ext2.o
|
||||
ext2-y := balloc.o bitmap.o
|
||||
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
|
||||
obj-$(CONFIG_EXT2_FS) += ext2.o
|
||||
ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \
|
||||
namei.o super.o symlink.o
|
||||
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \
|
||||
xattr_trusted.o
|
||||
|
||||
In this example, xattr.o is only part of the composite object
|
||||
ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
|
||||
In this example, xattr.o, xattr_user.o and xattr_trusted.o are only
|
||||
part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR)
|
||||
evaluates to 'y'.
|
||||
|
||||
Note: Of course, when you are building objects into the kernel,
|
||||
the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
|
||||
@ -244,12 +245,12 @@ more details, with real examples.
|
||||
may contain both a built-in.o and a lib.a file.
|
||||
|
||||
Example:
|
||||
#arch/i386/lib/Makefile
|
||||
lib-y := checksum.o delay.o
|
||||
#arch/x86/lib/Makefile
|
||||
lib-y := delay.o
|
||||
|
||||
This will create a library lib.a based on checksum.o and delay.o.
|
||||
For kbuild to actually recognize that there is a lib.a being built,
|
||||
the directory shall be listed in libs-y.
|
||||
This will create a library lib.a based on delay.o. For kbuild to
|
||||
actually recognize that there is a lib.a being built, the directory
|
||||
shall be listed in libs-y.
|
||||
See also "6.3 List directories to visit when descending".
|
||||
|
||||
Use of lib-y is normally restricted to lib/ and arch/*/lib.
|
||||
@ -284,43 +285,40 @@ more details, with real examples.
|
||||
--- 3.7 Compilation flags
|
||||
|
||||
ccflags-y, asflags-y and ldflags-y
|
||||
The three flags listed above applies only to the kbuild makefile
|
||||
where they are assigned. They are used for all the normal
|
||||
cc, as and ld invocation happenign during a recursive build.
|
||||
These three flags apply only to the kbuild makefile in which they
|
||||
are assigned. They are used for all the normal cc, as and ld
|
||||
invocations happening during a recursive build.
|
||||
Note: Flags with the same behaviour were previously named:
|
||||
EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
|
||||
They are yet supported but their use are deprecated.
|
||||
They are still supported but their usage is deprecated.
|
||||
|
||||
ccflags-y specifies options for compiling C files with $(CC).
|
||||
ccflags-y specifies options for compiling with $(CC).
|
||||
|
||||
Example:
|
||||
# drivers/sound/emu10k1/Makefile
|
||||
ccflags-y += -I$(obj)
|
||||
ccflags-$(DEBUG) += -DEMU10K1_DEBUG
|
||||
|
||||
# drivers/acpi/Makefile
|
||||
ccflags-y := -Os
|
||||
ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT
|
||||
|
||||
This variable is necessary because the top Makefile owns the
|
||||
variable $(KBUILD_CFLAGS) and uses it for compilation flags for the
|
||||
entire tree.
|
||||
|
||||
asflags-y is a similar string for per-directory options
|
||||
when compiling assembly language source.
|
||||
asflags-y specifies options for assembling with $(AS).
|
||||
|
||||
Example:
|
||||
#arch/x86_64/kernel/Makefile
|
||||
asflags-y := -traditional
|
||||
#arch/sparc/kernel/Makefile
|
||||
asflags-y := -ansi
|
||||
|
||||
|
||||
ldflags-y is a string for per-directory options to $(LD).
|
||||
ldflags-y specifies options for linking with $(LD).
|
||||
|
||||
Example:
|
||||
#arch/m68k/fpsp040/Makefile
|
||||
ldflags-y := -x
|
||||
#arch/cris/boot/compressed/Makefile
|
||||
ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds
|
||||
|
||||
subdir-ccflags-y, subdir-asflags-y
|
||||
The two flags listed above are similar to ccflags-y and as-falgs-y.
|
||||
The difference is that the subdir- variants has effect for the kbuild
|
||||
file where tey are present and all subdirectories.
|
||||
The two flags listed above are similar to ccflags-y and asflags-y.
|
||||
The difference is that the subdir- variants have effect for the kbuild
|
||||
file where they are present and all subdirectories.
|
||||
Options specified using subdir-* are added to the commandline before
|
||||
the options specified using the non-subdir variants.
|
||||
|
||||
@ -340,18 +338,18 @@ more details, with real examples.
|
||||
CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF
|
||||
CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
|
||||
-DGDTH_STATISTICS
|
||||
CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM
|
||||
|
||||
These three lines specify compilation flags for aha152x.o,
|
||||
gdth.o, and seagate.o
|
||||
These two lines specify compilation flags for aha152x.o and gdth.o.
|
||||
|
||||
$(AFLAGS_$@) is a similar feature for source files in assembly
|
||||
languages.
|
||||
|
||||
Example:
|
||||
# arch/arm/kernel/Makefile
|
||||
AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional
|
||||
AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional
|
||||
AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
|
||||
AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312
|
||||
AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
|
||||
|
||||
|
||||
--- 3.9 Dependency tracking
|
||||
|
||||
@ -923,16 +921,33 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
The first example utilises the trick that a config option expands
|
||||
to 'y' when selected.
|
||||
|
||||
CFLAGS_KERNEL $(CC) options specific for built-in
|
||||
KBUILD_AFLAGS_KERNEL $(AS) options specific for built-in
|
||||
|
||||
$(CFLAGS_KERNEL) contains extra C compiler flags used to compile
|
||||
$(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile
|
||||
resident kernel code.
|
||||
|
||||
CFLAGS_MODULE $(CC) options specific for modules
|
||||
KBUILD_AFLAGS_MODULE Options for $(AS) when building modules
|
||||
|
||||
$(CFLAGS_MODULE) contains extra C compiler flags used to compile code
|
||||
for loadable kernel modules.
|
||||
$(KBUILD_AFLAGS_MODULE) is used to add arch specific options that
|
||||
are used for $(AS).
|
||||
From commandline AFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
|
||||
KBUILD_CFLAGS_KERNEL $(CC) options specific for built-in
|
||||
|
||||
$(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile
|
||||
resident kernel code.
|
||||
|
||||
KBUILD_CFLAGS_MODULE Options for $(CC) when building modules
|
||||
|
||||
$(KBUILD_CFLAGS_MODULE) is used to add arch specific options that
|
||||
are used for $(CC).
|
||||
From commandline CFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
|
||||
KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules
|
||||
|
||||
$(KBUILD_LDFLAGS_MODULE) is used to add arch specific options
|
||||
used when linking modules. This is often a linker script.
|
||||
From commandline LDFLAGS_MODULE shall be used (see kbuild.txt).
|
||||
|
||||
--- 6.2 Add prerequisites to archprepare:
|
||||
|
||||
@ -1176,14 +1191,14 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
=== 7 Kbuild syntax for exported headers
|
||||
|
||||
The kernel include a set of headers that is exported to userspace.
|
||||
Many headers can be exported as-is but other headers requires a
|
||||
Many headers can be exported as-is but other headers require a
|
||||
minimal pre-processing before they are ready for user-space.
|
||||
The pre-processing does:
|
||||
- drop kernel specific annotations
|
||||
- drop include of compiler.h
|
||||
- drop all sections that is kernel internat (guarded by ifdef __KERNEL__)
|
||||
- drop all sections that are kernel internal (guarded by ifdef __KERNEL__)
|
||||
|
||||
Each relevant directory contain a file name "Kbuild" which specify the
|
||||
Each relevant directory contains a file name "Kbuild" which specifies the
|
||||
headers to be exported.
|
||||
See subsequent chapter for the syntax of the Kbuild file.
|
||||
|
||||
|
@ -75,7 +75,7 @@
|
||||
|
||||
* Title: "Conceptual Architecture of the Linux Kernel"
|
||||
Author: Ivan T. Bowman.
|
||||
URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a1.html
|
||||
URL: http://plg.uwaterloo.ca/
|
||||
Keywords: conceptual software architecture, extracted design,
|
||||
reverse engineering, system structure.
|
||||
Description: Conceptual software architecture of the Linux kernel,
|
||||
@ -84,7 +84,7 @@
|
||||
|
||||
* Title: "Concrete Architecture of the Linux Kernel"
|
||||
Author: Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan.
|
||||
URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a2.html
|
||||
URL: http://plg.uwaterloo.ca/
|
||||
Keywords: concrete architecture, extracted design, reverse
|
||||
engineering, system structure, dependencies.
|
||||
Description: Concrete architecture of the Linux kernel,
|
||||
@ -95,7 +95,7 @@
|
||||
* Title: "Linux as a Case Study: Its Extracted Software
|
||||
Architecture"
|
||||
Author: Ivan T. Bowman, Richard C. Holt and Neil V. Brewster.
|
||||
URL: http://plg.uwaterloo.ca/~itbowman/papers/linuxcase.html
|
||||
URL: http://plg.uwaterloo.ca/
|
||||
Keywords: software architecture, architecture recovery,
|
||||
redocumentation.
|
||||
Description: Paper appeared at ICSE'99, Los Angeles, May 16-22,
|
||||
@ -104,7 +104,7 @@
|
||||
|
||||
* Title: "Overview of the Virtual File System"
|
||||
Author: Richard Gooch.
|
||||
URL: http://www.atnf.csiro.au/~rgooch/linux/vfs.txt
|
||||
URL: http://www.mjmwired.net/kernel/Documentation/filesystems/vfs.txt
|
||||
Keywords: VFS, File System, mounting filesystems, opening files,
|
||||
dentries, dcache.
|
||||
Description: Brief introduction to the Linux Virtual File System.
|
||||
@ -267,15 +267,13 @@
|
||||
* Title: "Kernel API changes from 2.0 to 2.2"
|
||||
Author: Richard Gooch.
|
||||
URL:
|
||||
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html
|
||||
http://www.linuxhq.com/guides/LKMPG/node28.html
|
||||
Keywords: 2.2, changes.
|
||||
Description: Kernel functions/structures/variables which changed
|
||||
from 2.0.x to 2.2.x.
|
||||
|
||||
* Title: "Kernel API changes from 2.2 to 2.4"
|
||||
Author: Richard Gooch.
|
||||
URL:
|
||||
http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.4.html
|
||||
Keywords: 2.4, changes.
|
||||
Description: Kernel functions/structures/variables which changed
|
||||
from 2.2.x to 2.4.x.
|
||||
@ -290,7 +288,6 @@
|
||||
|
||||
* Title: "I/O Event Handling Under Linux"
|
||||
Author: Richard Gooch.
|
||||
URL: http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
|
||||
Keywords: IO, I/O, select(2), poll(2), FDs, aio_read(2), readiness
|
||||
event queues.
|
||||
Description: From the Introduction: "I/O Event handling is about
|
||||
@ -386,64 +383,64 @@
|
||||
|
||||
* Title: "Porting Device Drivers To Linux 2.2: part II"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/1999-06/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/238
|
||||
Keywords: ports, porting.
|
||||
Description: Second part on porting from 2.0 to 2.2 kernels.
|
||||
|
||||
* Title: "How To Make Sure Your Driver Will Work On The Power
|
||||
Macintosh"
|
||||
Author: Paul Mackerras.
|
||||
URL: http://www.linux-mag.com/1999-07/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/261
|
||||
Keywords: Mac, Power Macintosh, porting, drivers, compatibility.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "An Introduction to SCSI Drivers"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/1999-08/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/284
|
||||
Keywords: SCSI, device, driver.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "Advanced SCSI Drivers And Other Tales"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/1999-09/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/307
|
||||
Keywords: SCSI, device, driver, advanced.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "Writing Linux Mouse Drivers"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/1999-10/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/330
|
||||
Keywords: mouse, driver, gpm.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "More on Mouse Drivers"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/1999-11/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/356
|
||||
Keywords: mouse, driver, gpm, races, asynchronous I/O.
|
||||
Description: The title still says it all.
|
||||
|
||||
* Title: "Writing Video4linux Radio Driver"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/1999-12/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/381
|
||||
Keywords: video4linux, driver, radio, radio devices.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "Video4linux Drivers, Part 1: Video-Capture Device"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/2000-01/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/406
|
||||
Keywords: video4linux, driver, video capture, capture devices,
|
||||
camera driver.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "Video4linux Drivers, Part 2: Video-capture Devices"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/2000-02/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/429
|
||||
Keywords: video4linux, driver, video capture, capture devices,
|
||||
camera driver, control, query capabilities, capability, facility.
|
||||
Description: The title says it all.
|
||||
|
||||
* Title: "PCI Management in Linux 2.2"
|
||||
Author: Alan Cox.
|
||||
URL: http://www.linux-mag.com/2000-03/gear_01.html
|
||||
URL: http://www.linux-mag.com/id/452
|
||||
Keywords: PCI, bus, bus-mastering.
|
||||
Description: The title says it all.
|
||||
|
||||
@ -502,7 +499,7 @@
|
||||
|
||||
* Title: "A Linux vm README"
|
||||
Author: Kanoj Sarcar.
|
||||
URL: http://reality.sgi.com/kanoj_engr/vm229.html
|
||||
URL: http://kos.enix.org/pub/linux-vmm.html
|
||||
Keywords: virtual memory, mm, pgd, vma, page, page flags, page
|
||||
cache, swap cache, kswapd.
|
||||
Description: Telegraphic, short descriptions and definitions
|
||||
@ -659,7 +656,7 @@
|
||||
|
||||
* Name: "Linux Kernel Source Reference"
|
||||
Author: Thomas Graichen.
|
||||
URL: http://innominate.org/~graichen/projects/lksr/
|
||||
URL: http://marc.info/?l=linux-kernel&m=96446640102205&w=4
|
||||
Keywords: CVS, web, cvsweb, browsing source code.
|
||||
Description: Web interface to a CVS server with the kernel
|
||||
sources. "Here you can have a look at any file of the Linux kernel
|
||||
@ -682,7 +679,7 @@
|
||||
produced during the week. Published every Thursday.
|
||||
|
||||
* Name: "Kernel Traffic"
|
||||
URL: http://kt.zork.net/kernel-traffic/
|
||||
URL: http://kt.earth.li/kernel-traffic/index.html
|
||||
Keywords: linux-kernel mailing list, weekly kernel news.
|
||||
Description: Weekly newsletter covering the most relevant
|
||||
discussions of the linux-kernel mailing list.
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user