Merge branch 'perf/urgent' into perf/core
Merge reason: we'll be queueing up dependent changes. Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
commit
68d2cf25d3
6
CREDITS
6
CREDITS
|
@ -1677,7 +1677,7 @@ W: http://www.codemonkey.org.uk
|
||||||
D: Assorted VIA x86 support.
|
D: Assorted VIA x86 support.
|
||||||
D: 2.5 AGPGART overhaul.
|
D: 2.5 AGPGART overhaul.
|
||||||
D: CPUFREQ maintenance.
|
D: CPUFREQ maintenance.
|
||||||
D: Fedora kernel maintainence.
|
D: Fedora kernel maintenance.
|
||||||
D: Misc/Other.
|
D: Misc/Other.
|
||||||
S: 314 Littleton Rd, Westford, MA 01886, USA
|
S: 314 Littleton Rd, Westford, MA 01886, USA
|
||||||
|
|
||||||
|
@ -3211,7 +3211,7 @@ N: James Simmons
|
||||||
E: jsimmons@infradead.org
|
E: jsimmons@infradead.org
|
||||||
E: jsimmons@users.sf.net
|
E: jsimmons@users.sf.net
|
||||||
D: Frame buffer device maintainer
|
D: Frame buffer device maintainer
|
||||||
D: input layer developement
|
D: input layer development
|
||||||
D: tty/console layer
|
D: tty/console layer
|
||||||
D: various mipsel devices
|
D: various mipsel devices
|
||||||
S: 115 Carmel Avenue
|
S: 115 Carmel Avenue
|
||||||
|
@ -3290,7 +3290,7 @@ S: USA
|
||||||
N: Manfred Spraul
|
N: Manfred Spraul
|
||||||
E: manfred@colorfullife.com
|
E: manfred@colorfullife.com
|
||||||
W: http://www.colorfullife.com/~manfred
|
W: http://www.colorfullife.com/~manfred
|
||||||
D: Lots of tiny hacks. Larger improvments to SysV IPC msg,
|
D: Lots of tiny hacks. Larger improvements to SysV IPC msg,
|
||||||
D: slab, pipe, select.
|
D: slab, pipe, select.
|
||||||
S: 71701 Schwieberdingen
|
S: 71701 Schwieberdingen
|
||||||
S: Germany
|
S: Germany
|
||||||
|
|
|
@ -206,8 +206,8 @@ laptops/
|
||||||
- directory with laptop related info and laptop driver documentation.
|
- directory with laptop related info and laptop driver documentation.
|
||||||
ldm.txt
|
ldm.txt
|
||||||
- a brief description of LDM (Windows Dynamic Disks).
|
- a brief description of LDM (Windows Dynamic Disks).
|
||||||
leds-class.txt
|
leds/
|
||||||
- documents LED handling under Linux.
|
- directory with info about LED handling under Linux.
|
||||||
local_ops.txt
|
local_ops.txt
|
||||||
- semantics and behavior of local atomic operations.
|
- semantics and behavior of local atomic operations.
|
||||||
lockdep-design.txt
|
lockdep-design.txt
|
||||||
|
|
|
@ -29,7 +29,7 @@ Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
|
||||||
linux-s390@vger.kernel.org
|
linux-s390@vger.kernel.org
|
||||||
Description: Contains the PIM/PAM/POM values, as reported by the
|
Description: Contains the PIM/PAM/POM values, as reported by the
|
||||||
channel subsystem when last queried by the common I/O
|
channel subsystem when last queried by the common I/O
|
||||||
layer (this implies that this attribute is not neccessarily
|
layer (this implies that this attribute is not necessarily
|
||||||
in sync with the values current in the channel subsystem).
|
in sync with the values current in the channel subsystem).
|
||||||
Note: This is an I/O-subchannel specific attribute.
|
Note: This is an I/O-subchannel specific attribute.
|
||||||
Users: s390-tools, HAL
|
Users: s390-tools, HAL
|
||||||
|
|
|
@ -33,5 +33,5 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||||
Description:
|
Description:
|
||||||
Invert the LED on/off state. This parameter is specific to
|
Invert the LED on/off state. This parameter is specific to
|
||||||
gpio and backlight triggers. In case of the backlight trigger,
|
gpio and backlight triggers. In case of the backlight trigger,
|
||||||
it is usefull when driving a LED which is intended to indicate
|
it is useful when driving a LED which is intended to indicate
|
||||||
a device in a standby like state.
|
a device in a standby like state.
|
||||||
|
|
|
@ -40,7 +40,7 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
|
||||||
Date: March 2010
|
Date: March 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile holds informations like button
|
press of a button. A profile holds information like button
|
||||||
mappings, sensitivity, the colors of the 5 leds and light
|
mappings, sensitivity, the colors of the 5 leds and light
|
||||||
effects.
|
effects.
|
||||||
When read, these files return the respective profile. The
|
When read, these files return the respective profile. The
|
||||||
|
|
|
@ -33,7 +33,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_buttons holds informations about button layout.
|
profile_buttons holds information about button layout.
|
||||||
When written, this file lets one write the respective profile
|
When written, this file lets one write the respective profile
|
||||||
buttons back to the mouse. The data has to be 77 bytes long.
|
buttons back to the mouse. The data has to be 77 bytes long.
|
||||||
The mouse will reject invalid data.
|
The mouse will reject invalid data.
|
||||||
|
@ -47,7 +47,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_buttons holds informations about button layout.
|
profile_buttons holds information about button layout.
|
||||||
When read, these files return the respective profile buttons.
|
When read, these files return the respective profile buttons.
|
||||||
The returned data is 77 bytes in size.
|
The returned data is 77 bytes in size.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
@ -58,7 +58,7 @@ Date: October 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_settings holds informations like resolution, sensitivity
|
profile_settings holds information like resolution, sensitivity
|
||||||
and light effects.
|
and light effects.
|
||||||
When written, this file lets one write the respective profile
|
When written, this file lets one write the respective profile
|
||||||
settings back to the mouse. The data has to be 43 bytes long.
|
settings back to the mouse. The data has to be 43 bytes long.
|
||||||
|
@ -73,7 +73,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_settings holds informations like resolution, sensitivity
|
profile_settings holds information like resolution, sensitivity
|
||||||
and light effects.
|
and light effects.
|
||||||
When read, these files return the respective profile settings.
|
When read, these files return the respective profile settings.
|
||||||
The returned data is 43 bytes in size.
|
The returned data is 43 bytes in size.
|
||||||
|
|
|
@ -52,7 +52,7 @@ Date: January 2011
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_buttons holds informations about button layout.
|
profile_buttons holds information about button layout.
|
||||||
When written, this file lets one write the respective profile
|
When written, this file lets one write the respective profile
|
||||||
buttons back to the mouse. The data has to be 23 bytes long.
|
buttons back to the mouse. The data has to be 23 bytes long.
|
||||||
The mouse will reject invalid data.
|
The mouse will reject invalid data.
|
||||||
|
@ -66,7 +66,7 @@ Date: January 2011
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_buttons holds informations about button layout.
|
profile_buttons holds information about button layout.
|
||||||
When read, these files return the respective profile buttons.
|
When read, these files return the respective profile buttons.
|
||||||
The returned data is 23 bytes in size.
|
The returned data is 23 bytes in size.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
@ -77,7 +77,7 @@ Date: January 2011
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_settings holds informations like resolution, sensitivity
|
profile_settings holds information like resolution, sensitivity
|
||||||
and light effects.
|
and light effects.
|
||||||
When written, this file lets one write the respective profile
|
When written, this file lets one write the respective profile
|
||||||
settings back to the mouse. The data has to be 16 bytes long.
|
settings back to the mouse. The data has to be 16 bytes long.
|
||||||
|
@ -92,7 +92,7 @@ Date: January 2011
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_settings holds informations like resolution, sensitivity
|
profile_settings holds information like resolution, sensitivity
|
||||||
and light effects.
|
and light effects.
|
||||||
When read, these files return the respective profile settings.
|
When read, these files return the respective profile settings.
|
||||||
The returned data is 16 bytes in size.
|
The returned data is 16 bytes in size.
|
||||||
|
|
|
@ -39,7 +39,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_settings holds informations like resolution, sensitivity
|
profile_settings holds information like resolution, sensitivity
|
||||||
and light effects.
|
and light effects.
|
||||||
When written, this file lets one write the respective profile
|
When written, this file lets one write the respective profile
|
||||||
settings back to the mouse. The data has to be 13 bytes long.
|
settings back to the mouse. The data has to be 13 bytes long.
|
||||||
|
@ -54,7 +54,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_settings holds informations like resolution, sensitivity
|
profile_settings holds information like resolution, sensitivity
|
||||||
and light effects.
|
and light effects.
|
||||||
When read, these files return the respective profile settings.
|
When read, these files return the respective profile settings.
|
||||||
The returned data is 13 bytes in size.
|
The returned data is 13 bytes in size.
|
||||||
|
@ -66,7 +66,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_buttons holds informations about button layout.
|
profile_buttons holds information about button layout.
|
||||||
When written, this file lets one write the respective profile
|
When written, this file lets one write the respective profile
|
||||||
buttons back to the mouse. The data has to be 19 bytes long.
|
buttons back to the mouse. The data has to be 19 bytes long.
|
||||||
The mouse will reject invalid data.
|
The mouse will reject invalid data.
|
||||||
|
@ -80,7 +80,7 @@ Date: August 2010
|
||||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||||
Description: The mouse can store 5 profiles which can be switched by the
|
Description: The mouse can store 5 profiles which can be switched by the
|
||||||
press of a button. A profile is split in settings and buttons.
|
press of a button. A profile is split in settings and buttons.
|
||||||
profile_buttons holds informations about button layout.
|
profile_buttons holds information about button layout.
|
||||||
When read, these files return the respective profile buttons.
|
When read, these files return the respective profile buttons.
|
||||||
The returned data is 19 bytes in size.
|
The returned data is 19 bytes in size.
|
||||||
This file is readonly.
|
This file is readonly.
|
||||||
|
|
|
@ -27,7 +27,7 @@ KernelVersion: 2.6.20
|
||||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||||
Description:
|
Description:
|
||||||
Some models like the W1N have a LED display that can be
|
Some models like the W1N have a LED display that can be
|
||||||
used to display several informations.
|
used to display several items of information.
|
||||||
To control the LED display, use the following :
|
To control the LED display, use the following :
|
||||||
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
|
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
|
||||||
where T control the 3 letters display, and DDD the 3 digits display.
|
where T control the 3 letters display, and DDD the 3 digits display.
|
||||||
|
|
|
@ -40,7 +40,7 @@
|
||||||
|
|
||||||
<para>Central frequency of the channel.</para>
|
<para>Central frequency of the channel.</para>
|
||||||
|
|
||||||
<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
|
<para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a
|
||||||
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
|
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
|
||||||
the channel which is 6MHz.</para>
|
the channel which is 6MHz.</para>
|
||||||
|
|
||||||
|
|
|
@ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para>
|
||||||
<section id="frontend_sec_tone">
|
<section id="frontend_sec_tone">
|
||||||
<title>SEC continuous tone</title>
|
<title>SEC continuous tone</title>
|
||||||
|
|
||||||
<para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
|
<para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
|
||||||
high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to
|
high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to
|
||||||
be switched consistently to the DiSEqC commands as described in the DiSEqC
|
be switched consistently to the DiSEqC commands as described in the DiSEqC
|
||||||
spec.</para>
|
spec.</para>
|
||||||
|
|
|
@ -1507,7 +1507,7 @@ and other resources, etc.
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
|
CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
|
|
|
@ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||||
Reed-Solomon library.
|
Reed-Solomon library.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The ECC bytes must be placed immidiately after the data
|
The ECC bytes must be placed immediately after the data
|
||||||
bytes in order to make the syndrome generator work. This
|
bytes in order to make the syndrome generator work. This
|
||||||
is contrary to the usual layout used by software ECC. The
|
is contrary to the usual layout used by software ECC. The
|
||||||
separation of data and out of band area is not longer
|
separation of data and out of band area is not longer
|
||||||
|
@ -629,7 +629,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||||
holds the bad block table. Store a pointer to the pattern
|
holds the bad block table. Store a pointer to the pattern
|
||||||
in the pattern field. Further the length of the pattern has to be
|
in the pattern field. Further the length of the pattern has to be
|
||||||
stored in len and the offset in the spare area must be given
|
stored in len and the offset in the spare area must be given
|
||||||
in the offs member of the nand_bbt_descr stucture. For mirrored
|
in the offs member of the nand_bbt_descr structure. For mirrored
|
||||||
bad block tables different patterns are mandatory.</para></listitem>
|
bad block tables different patterns are mandatory.</para></listitem>
|
||||||
<listitem><para>Table creation</para>
|
<listitem><para>Table creation</para>
|
||||||
<para>Set the option NAND_BBT_CREATE to enable the table creation
|
<para>Set the option NAND_BBT_CREATE to enable the table creation
|
||||||
|
@ -648,7 +648,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||||
<listitem><para>Table version control</para>
|
<listitem><para>Table version control</para>
|
||||||
<para>Set the option NAND_BBT_VERSION to enable the table version control.
|
<para>Set the option NAND_BBT_VERSION to enable the table version control.
|
||||||
It's highly recommended to enable this for mirrored tables with write
|
It's highly recommended to enable this for mirrored tables with write
|
||||||
support. It makes sure that the risk of loosing the bad block
|
support. It makes sure that the risk of losing the bad block
|
||||||
table information is reduced to the loss of the information about the
|
table information is reduced to the loss of the information about the
|
||||||
one worn out block which should be marked bad. The version is stored in
|
one worn out block which should be marked bad. The version is stored in
|
||||||
4 consecutive bytes in the spare area of the device. The position of
|
4 consecutive bytes in the spare area of the device. The position of
|
||||||
|
@ -1060,19 +1060,19 @@ data in this page</entry>
|
||||||
<row>
|
<row>
|
||||||
<entry>0x3D</entry>
|
<entry>0x3D</entry>
|
||||||
<entry>ECC byte 21</entry>
|
<entry>ECC byte 21</entry>
|
||||||
<entry>Error correction code byte 0 of the eigth 256 Bytes of data
|
<entry>Error correction code byte 0 of the eighth 256 Bytes of data
|
||||||
in this page</entry>
|
in this page</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>0x3E</entry>
|
<entry>0x3E</entry>
|
||||||
<entry>ECC byte 22</entry>
|
<entry>ECC byte 22</entry>
|
||||||
<entry>Error correction code byte 1 of the eigth 256 Bytes of data
|
<entry>Error correction code byte 1 of the eighth 256 Bytes of data
|
||||||
in this page</entry>
|
in this page</entry>
|
||||||
</row>
|
</row>
|
||||||
<row>
|
<row>
|
||||||
<entry>0x3F</entry>
|
<entry>0x3F</entry>
|
||||||
<entry>ECC byte 23</entry>
|
<entry>ECC byte 23</entry>
|
||||||
<entry>Error correction code byte 2 of the eigth 256 Bytes of data
|
<entry>Error correction code byte 2 of the eighth 256 Bytes of data
|
||||||
in this page</entry>
|
in this page</entry>
|
||||||
</row>
|
</row>
|
||||||
</tbody></tgroup></informaltable>
|
</tbody></tgroup></informaltable>
|
||||||
|
|
|
@ -267,8 +267,8 @@
|
||||||
<sect1 id="machine-constraint">
|
<sect1 id="machine-constraint">
|
||||||
<title>Constraints</title>
|
<title>Constraints</title>
|
||||||
<para>
|
<para>
|
||||||
As well as definining the connections the machine interface
|
As well as defining the connections the machine interface
|
||||||
also provides constraints definining the operations that
|
also provides constraints defining the operations that
|
||||||
clients are allowed to perform and the parameters that may be
|
clients are allowed to perform and the parameters that may be
|
||||||
set. This is required since generally regulator devices will
|
set. This is required since generally regulator devices will
|
||||||
offer more flexibility than it is safe to use on a given
|
offer more flexibility than it is safe to use on a given
|
||||||
|
|
|
@ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone.
|
||||||
perform some initialization. After that, your hardware
|
perform some initialization. After that, your hardware
|
||||||
starts working and will generate an interrupt as soon
|
starts working and will generate an interrupt as soon
|
||||||
as it's finished, has some data available, or needs your
|
as it's finished, has some data available, or needs your
|
||||||
attention because an error occured.
|
attention because an error occurred.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<filename>/dev/uioX</filename> is a read-only file. A
|
<filename>/dev/uioX</filename> is a read-only file. A
|
||||||
|
|
|
@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
|
||||||
</para><para>
|
</para><para>
|
||||||
This request lets kernel drivers talk to user mode code
|
This request lets kernel drivers talk to user mode code
|
||||||
through filesystem operations even when they don't create
|
through filesystem operations even when they don't create
|
||||||
a charactor or block special device.
|
a character or block special device.
|
||||||
It's also been used to do things like ask devices what
|
It's also been used to do things like ask devices what
|
||||||
device special file should be used.
|
device special file should be used.
|
||||||
Two pre-defined ioctls are used
|
Two pre-defined ioctls are used
|
||||||
|
|
|
@ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para>
|
||||||
|
|
||||||
<para>By convention system administrators create various
|
<para>By convention system administrators create various
|
||||||
character device special files with these major and minor numbers in
|
character device special files with these major and minor numbers in
|
||||||
the <filename>/dev</filename> directory. The names recomended for the
|
the <filename>/dev</filename> directory. The names recommended for the
|
||||||
different V4L2 device types are listed in <xref linkend="devices" />.
|
different V4L2 device types are listed in <xref linkend="devices" />.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
|
@ -1243,7 +1243,7 @@ values are:</entry>
|
||||||
</row><row><entry spanname="descr">Mutes the audio when
|
</row><row><entry spanname="descr">Mutes the audio when
|
||||||
capturing. This is not done by muting audio hardware, which can still
|
capturing. This is not done by muting audio hardware, which can still
|
||||||
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
|
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
|
||||||
and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry>
|
and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
|
||||||
</row>
|
</row>
|
||||||
<row><entry></entry></row>
|
<row><entry></entry></row>
|
||||||
<row id="v4l2-mpeg-video-encoding">
|
<row id="v4l2-mpeg-video-encoding">
|
||||||
|
|
|
@ -90,7 +90,7 @@
|
||||||
processing hardware.</para>
|
processing hardware.</para>
|
||||||
|
|
||||||
<figure id="pipeline-scaling">
|
<figure id="pipeline-scaling">
|
||||||
<title>Image Format Negotation on Pipelines</title>
|
<title>Image Format Negotiation on Pipelines</title>
|
||||||
<mediaobject>
|
<mediaobject>
|
||||||
<imageobject>
|
<imageobject>
|
||||||
<imagedata fileref="pipeline.pdf" format="PS" />
|
<imagedata fileref="pipeline.pdf" format="PS" />
|
||||||
|
|
|
@ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value.
|
||||||
<para>int v4l2_get_control(int fd, int cid) -
|
<para>int v4l2_get_control(int fd, int cid) -
|
||||||
This function returns a value of 0 - 65535, scaled to from the actual range
|
This function returns a value of 0 - 65535, scaled to from the actual range
|
||||||
of the given v4l control id. when the cid does not exist, could not be
|
of the given v4l control id. when the cid does not exist, could not be
|
||||||
accessed for some reason, or some error occured 0 is returned.
|
accessed for some reason, or some error occurred 0 is returned.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</section>
|
</section>
|
||||||
|
|
|
@ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media
|
||||||
<row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row>
|
<row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row>
|
||||||
<row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row>
|
<row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row>
|
||||||
|
|
||||||
<row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row>
|
<row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row>
|
||||||
|
|
||||||
<row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row>
|
<row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row>
|
||||||
<row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row>
|
<row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row>
|
||||||
|
|
|
@ -4784,7 +4784,7 @@ struct _snd_pcm_runtime {
|
||||||
FM registers can be directly accessed through the direct-FM API,
|
FM registers can be directly accessed through the direct-FM API,
|
||||||
defined in <filename><sound/asound_fm.h></filename>. In
|
defined in <filename><sound/asound_fm.h></filename>. In
|
||||||
ALSA native mode, FM registers are accessed through
|
ALSA native mode, FM registers are accessed through
|
||||||
the Hardware-Dependant Device direct-FM extension API, whereas in
|
the Hardware-Dependent Device direct-FM extension API, whereas in
|
||||||
OSS compatible mode, FM registers can be accessed with the OSS
|
OSS compatible mode, FM registers can be accessed with the OSS
|
||||||
direct-FM compatible API in <filename>/dev/dmfmX</filename> device.
|
direct-FM compatible API in <filename>/dev/dmfmX</filename> device.
|
||||||
</para>
|
</para>
|
||||||
|
|
|
@ -253,8 +253,8 @@ In constrast, MSI is restricted to a maximum of 32 interrupts (and
|
||||||
must be a power of two). In addition, the MSI interrupt vectors must
|
must be a power of two). In addition, the MSI interrupt vectors must
|
||||||
be allocated consecutively, so the system may not be able to allocate
|
be allocated consecutively, so the system may not be able to allocate
|
||||||
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
|
as many vectors for MSI as it could for MSI-X. On some platforms, MSI
|
||||||
interrupts must all be targetted at the same set of CPUs whereas MSI-X
|
interrupts must all be targeted at the same set of CPUs whereas MSI-X
|
||||||
interrupts can all be targetted at different CPUs.
|
interrupts can all be targeted at different CPUs.
|
||||||
|
|
||||||
4.5.2 Spinlocks
|
4.5.2 Spinlocks
|
||||||
|
|
||||||
|
|
|
@ -28,7 +28,7 @@ expect these delays to be short, measurable in days, not weeks or months.
|
||||||
A disclosure date is negotiated by the security team working with the
|
A disclosure date is negotiated by the security team working with the
|
||||||
bug submitter as well as vendors. However, the kernel security team
|
bug submitter as well as vendors. However, the kernel security team
|
||||||
holds the final say when setting a disclosure date. The timeframe for
|
holds the final say when setting a disclosure date. The timeframe for
|
||||||
disclosure is from immediate (esp. if it's already publically known)
|
disclosure is from immediate (esp. if it's already publicly known)
|
||||||
to a few weeks. As a basic default policy, we expect report date to
|
to a few weeks. As a basic default policy, we expect report date to
|
||||||
disclosure date to be on the order of 7 days.
|
disclosure date to be on the order of 7 days.
|
||||||
|
|
||||||
|
|
|
@ -101,7 +101,7 @@ PM support: Since Linux is used on many portable and desktop systems, your
|
||||||
complete overview of the power management issues related to
|
complete overview of the power management issues related to
|
||||||
drivers see Documentation/power/devices.txt .
|
drivers see Documentation/power/devices.txt .
|
||||||
|
|
||||||
Control: In general if there is active maintainance of a driver by
|
Control: In general if there is active maintenance of a driver by
|
||||||
the author then patches will be redirected to them unless
|
the author then patches will be redirected to them unless
|
||||||
they are totally obvious and without need of checking.
|
they are totally obvious and without need of checking.
|
||||||
If you want to be the contact and update point for the
|
If you want to be the contact and update point for the
|
||||||
|
|
|
@ -729,7 +729,7 @@ Linus Torvalds's mail on the canonical patch format:
|
||||||
<http://lkml.org/lkml/2005/4/7/183>
|
<http://lkml.org/lkml/2005/4/7/183>
|
||||||
|
|
||||||
Andi Kleen, "On submitting kernel patches"
|
Andi Kleen, "On submitting kernel patches"
|
||||||
Some strategies to get difficult or controversal changes in.
|
Some strategies to get difficult or controversial changes in.
|
||||||
http://halobates.de/on-submitting-patches.pdf
|
http://halobates.de/on-submitting-patches.pdf
|
||||||
|
|
||||||
--
|
--
|
||||||
|
|
|
@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
|
||||||
- Timers (watchdog, OS)
|
- Timers (watchdog, OS)
|
||||||
|
|
||||||
The following components of the chips are not supported by Linux and
|
The following components of the chips are not supported by Linux and
|
||||||
require the use of Intel's propietary CSR softare:
|
require the use of Intel's proprietary CSR softare:
|
||||||
|
|
||||||
- USB device interface
|
- USB device interface
|
||||||
- Network interfaces (HSS, Utopia, NPEs, etc)
|
- Network interfaces (HSS, Utopia, NPEs, etc)
|
||||||
|
@ -47,7 +47,7 @@ software from:
|
||||||
|
|
||||||
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
|
http://developer.intel.com/design/network/products/npfamily/ixp425.htm
|
||||||
|
|
||||||
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
|
DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
|
||||||
SOFTWARE.
|
SOFTWARE.
|
||||||
|
|
||||||
There are several websites that provide directions/pointers on using
|
There are several websites that provide directions/pointers on using
|
||||||
|
|
|
@ -116,7 +116,7 @@ Configuration
|
||||||
Allows the entire memory to be checksummed before and after the
|
Allows the entire memory to be checksummed before and after the
|
||||||
suspend to see if there has been any corruption of the contents.
|
suspend to see if there has been any corruption of the contents.
|
||||||
|
|
||||||
Note, the time to calculate the CRC is dependant on the CPU speed
|
Note, the time to calculate the CRC is dependent on the CPU speed
|
||||||
and the size of memory. For an 64Mbyte RAM area on an 200MHz
|
and the size of memory. For an 64Mbyte RAM area on an 200MHz
|
||||||
S3C2410, this can take approximately 4 seconds to complete.
|
S3C2410, this can take approximately 4 seconds to complete.
|
||||||
|
|
||||||
|
|
|
@ -5,7 +5,7 @@ Introduction
|
||||||
------------
|
------------
|
||||||
|
|
||||||
This outlines the Samsung GPIO implementation and the architecture
|
This outlines the Samsung GPIO implementation and the architecture
|
||||||
specfic calls provided alongisde the drivers/gpio core.
|
specific calls provided alongisde the drivers/gpio core.
|
||||||
|
|
||||||
|
|
||||||
S3C24XX (Legacy)
|
S3C24XX (Legacy)
|
||||||
|
|
|
@ -110,22 +110,22 @@ university server with various users - students, professors, system
|
||||||
tasks etc. The resource planning for this server could be along the
|
tasks etc. The resource planning for this server could be along the
|
||||||
following lines:
|
following lines:
|
||||||
|
|
||||||
CPU : Top cpuset
|
CPU : "Top cpuset"
|
||||||
/ \
|
/ \
|
||||||
CPUSet1 CPUSet2
|
CPUSet1 CPUSet2
|
||||||
| |
|
| |
|
||||||
(Profs) (Students)
|
(Professors) (Students)
|
||||||
|
|
||||||
In addition (system tasks) are attached to topcpuset (so
|
In addition (system tasks) are attached to topcpuset (so
|
||||||
that they can run anywhere) with a limit of 20%
|
that they can run anywhere) with a limit of 20%
|
||||||
|
|
||||||
Memory : Professors (50%), students (30%), system (20%)
|
Memory : Professors (50%), Students (30%), system (20%)
|
||||||
|
|
||||||
Disk : Prof (50%), students (30%), system (20%)
|
Disk : Professors (50%), Students (30%), system (20%)
|
||||||
|
|
||||||
Network : WWW browsing (20%), Network File System (60%), others (20%)
|
Network : WWW browsing (20%), Network File System (60%), others (20%)
|
||||||
/ \
|
/ \
|
||||||
Prof (15%) students (5%)
|
Professors (15%) students (5%)
|
||||||
|
|
||||||
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
|
Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
|
||||||
into NFS network class.
|
into NFS network class.
|
||||||
|
|
|
@ -196,7 +196,7 @@ the state as 0 when a cpu if offline and 1 when its online.
|
||||||
#To display the current cpu state.
|
#To display the current cpu state.
|
||||||
#cat /sys/devices/system/cpu/cpuX/online
|
#cat /sys/devices/system/cpu/cpuX/online
|
||||||
|
|
||||||
Q: Why cant i remove CPU0 on some systems?
|
Q: Why can't i remove CPU0 on some systems?
|
||||||
A: Some architectures may have some special dependency on a certain CPU.
|
A: Some architectures may have some special dependency on a certain CPU.
|
||||||
|
|
||||||
For e.g in IA64 platforms we have ability to sent platform interrupts to the
|
For e.g in IA64 platforms we have ability to sent platform interrupts to the
|
||||||
|
|
|
@ -62,7 +62,7 @@ image file and then arrange all these packets back to back in to one single
|
||||||
file.
|
file.
|
||||||
This file is then copied to /sys/class/firmware/dell_rbu/data.
|
This file is then copied to /sys/class/firmware/dell_rbu/data.
|
||||||
Once this file gets to the driver, the driver extracts packet_size data from
|
Once this file gets to the driver, the driver extracts packet_size data from
|
||||||
the file and spreads it accross the physical memory in contiguous packet_sized
|
the file and spreads it across the physical memory in contiguous packet_sized
|
||||||
space.
|
space.
|
||||||
This method makes sure that all the packets get to the driver in a single operation.
|
This method makes sure that all the packets get to the driver in a single operation.
|
||||||
|
|
||||||
|
|
|
@ -37,7 +37,7 @@ Algorithm
|
||||||
=========
|
=========
|
||||||
|
|
||||||
dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
|
dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
|
||||||
dispatched and substracts when completed.
|
dispatched and subtracts when completed.
|
||||||
Basically, dm-service-time selects a path having minimum service time
|
Basically, dm-service-time selects a path having minimum service time
|
||||||
which is calculated by:
|
which is calculated by:
|
||||||
|
|
||||||
|
|
|
@ -18,9 +18,9 @@ Optional properties:
|
||||||
- edid : verbatim EDID data block describing attached display.
|
- edid : verbatim EDID data block describing attached display.
|
||||||
Data from the detailed timing descriptor will be used to
|
Data from the detailed timing descriptor will be used to
|
||||||
program the display controller.
|
program the display controller.
|
||||||
- little-endian: availiable on big endian systems, to
|
- little-endian: available on big endian systems, to
|
||||||
set different foreign endian.
|
set different foreign endian.
|
||||||
- big-endian: availiable on little endian systems, to
|
- big-endian: available on little endian systems, to
|
||||||
set different foreign endian.
|
set different foreign endian.
|
||||||
|
|
||||||
Example for MPC5200:
|
Example for MPC5200:
|
||||||
|
|
|
@ -15,7 +15,7 @@ Optional properties:
|
||||||
- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
|
- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
|
||||||
(R/B#). For multi-chip devices, "n" GPIO definitions are required
|
(R/B#). For multi-chip devices, "n" GPIO definitions are required
|
||||||
according to the number of chips.
|
according to the number of chips.
|
||||||
- chip-delay : chip dependent delay for transfering data from array to
|
- chip-delay : chip dependent delay for transferring data from array to
|
||||||
read registers (tR). Required if property "gpios" is not used
|
read registers (tR). Required if property "gpios" is not used
|
||||||
(R/B# pins not connected).
|
(R/B# pins not connected).
|
||||||
|
|
||||||
|
|
|
@ -39,7 +39,7 @@ Optional properties:
|
||||||
|
|
||||||
- nxp,no-comparator-bypass : Allows to disable the CAN input comperator.
|
- nxp,no-comparator-bypass : Allows to disable the CAN input comperator.
|
||||||
|
|
||||||
For futher information, please have a look to the SJA1000 data sheet.
|
For further information, please have a look to the SJA1000 data sheet.
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
||||||
|
|
|
@ -199,7 +199,7 @@ EXAMPLE 4
|
||||||
|
|
||||||
EXAMPLE 5
|
EXAMPLE 5
|
||||||
/*
|
/*
|
||||||
* Definition of an error interrupt (interupt type 1).
|
* Definition of an error interrupt (interrupt type 1).
|
||||||
* SoC interrupt number is 16 and the specific error
|
* SoC interrupt number is 16 and the specific error
|
||||||
* interrupt bit in the error interrupt summary register
|
* interrupt bit in the error interrupt summary register
|
||||||
* is 23.
|
* is 23.
|
||||||
|
|
|
@ -138,7 +138,7 @@ and properties to be present. This will be described in detail in
|
||||||
section III, but, for example, the kernel does not require you to
|
section III, but, for example, the kernel does not require you to
|
||||||
create a node for every PCI device in the system. It is a requirement
|
create a node for every PCI device in the system. It is a requirement
|
||||||
to have a node for PCI host bridges in order to provide interrupt
|
to have a node for PCI host bridges in order to provide interrupt
|
||||||
routing informations and memory/IO ranges, among others. It is also
|
routing information and memory/IO ranges, among others. It is also
|
||||||
recommended to define nodes for on chip devices and other buses that
|
recommended to define nodes for on chip devices and other buses that
|
||||||
don't specifically fit in an existing OF specification. This creates a
|
don't specifically fit in an existing OF specification. This creates a
|
||||||
great flexibility in the way the kernel can then probe those and match
|
great flexibility in the way the kernel can then probe those and match
|
||||||
|
@ -385,7 +385,7 @@ struct boot_param_header {
|
||||||
among others, by kexec. If you are on an SMP system, this value
|
among others, by kexec. If you are on an SMP system, this value
|
||||||
should match the content of the "reg" property of the CPU node in
|
should match the content of the "reg" property of the CPU node in
|
||||||
the device-tree corresponding to the CPU calling the kernel entry
|
the device-tree corresponding to the CPU calling the kernel entry
|
||||||
point (see further chapters for more informations on the required
|
point (see further chapters for more information on the required
|
||||||
device-tree contents)
|
device-tree contents)
|
||||||
|
|
||||||
- size_dt_strings
|
- size_dt_strings
|
||||||
|
@ -553,7 +553,7 @@ looks like in practice.
|
||||||
|
|
||||||
This tree is almost a minimal tree. It pretty much contains the
|
This tree is almost a minimal tree. It pretty much contains the
|
||||||
minimal set of required nodes and properties to boot a linux kernel;
|
minimal set of required nodes and properties to boot a linux kernel;
|
||||||
that is, some basic model informations at the root, the CPUs, and the
|
that is, some basic model information at the root, the CPUs, and the
|
||||||
physical memory layout. It also includes misc information passed
|
physical memory layout. It also includes misc information passed
|
||||||
through /chosen, like in this example, the platform type (mandatory)
|
through /chosen, like in this example, the platform type (mandatory)
|
||||||
and the kernel command line arguments (optional).
|
and the kernel command line arguments (optional).
|
||||||
|
|
|
@ -138,7 +138,7 @@ Hotplug is able to load the driver, when it is needed (because you plugged
|
||||||
in the device).
|
in the device).
|
||||||
|
|
||||||
If you want to enable debug output, you have to load the driver manually and
|
If you want to enable debug output, you have to load the driver manually and
|
||||||
from withing the dvb-kernel cvs repository.
|
from within the dvb-kernel cvs repository.
|
||||||
|
|
||||||
first have a look, which debug level are available:
|
first have a look, which debug level are available:
|
||||||
|
|
||||||
|
|
|
@ -47,7 +47,7 @@ so on.
|
||||||
|
|
||||||
* CI modules that are supported
|
* CI modules that are supported
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
The CI module support is largely dependant upon the firmware on the cards
|
The CI module support is largely dependent upon the firmware on the cards
|
||||||
Some cards do support almost all of the available CI modules. There is
|
Some cards do support almost all of the available CI modules. There is
|
||||||
nothing much that can be done in order to make additional CI modules
|
nothing much that can be done in order to make additional CI modules
|
||||||
working with these cards.
|
working with these cards.
|
||||||
|
|
|
@ -106,7 +106,7 @@ Some very frequently asked questions about linuxtv-dvb
|
||||||
5. The dvb_net device doesn't give me any packets at all
|
5. The dvb_net device doesn't give me any packets at all
|
||||||
|
|
||||||
Run tcpdump on the dvb0_0 interface. This sets the interface
|
Run tcpdump on the dvb0_0 interface. This sets the interface
|
||||||
into promiscous mode so it accepts any packets from the PID
|
into promiscuous mode so it accepts any packets from the PID
|
||||||
you have configured with the dvbnet utility. Check if there
|
you have configured with the dvbnet utility. Check if there
|
||||||
are any packets with the IP addr and MAC addr you have
|
are any packets with the IP addr and MAC addr you have
|
||||||
configured with ifconfig.
|
configured with ifconfig.
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
The DVB subsystem currently registers to the sysfs subsystem using the
|
The DVB subsystem currently registers to the sysfs subsystem using the
|
||||||
"class_simple" interface.
|
"class_simple" interface.
|
||||||
|
|
||||||
This means that only the basic informations like module loading parameters
|
This means that only the basic information like module loading parameters
|
||||||
are presented through sysfs. Other things that might be interesting are
|
are presented through sysfs. Other things that might be interesting are
|
||||||
currently *not* available.
|
currently *not* available.
|
||||||
|
|
||||||
|
|
|
@ -311,7 +311,7 @@ Total Correctable Errors count attribute file:
|
||||||
'ce_noinfo_count'
|
'ce_noinfo_count'
|
||||||
|
|
||||||
This attribute file displays the number of CEs that
|
This attribute file displays the number of CEs that
|
||||||
have occurred wherewith no informations as to which DIMM slot
|
have occurred wherewith no information as to which DIMM slot
|
||||||
is having errors. Memory is handicapped, but operational,
|
is having errors. Memory is handicapped, but operational,
|
||||||
yet no information is available to indicate which slot
|
yet no information is available to indicate which slot
|
||||||
the failing memory is in. This count field should be also
|
the failing memory is in. This count field should be also
|
||||||
|
@ -741,7 +741,7 @@ were done at i7core_edac driver. This chapter will cover those differences
|
||||||
As EDAC API maps the minimum unity is csrows, the driver sequencially
|
As EDAC API maps the minimum unity is csrows, the driver sequencially
|
||||||
maps channel/dimm into different csrows.
|
maps channel/dimm into different csrows.
|
||||||
|
|
||||||
For example, suposing the following layout:
|
For example, supposing the following layout:
|
||||||
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
|
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
|
||||||
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||||
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
|
||||||
|
|
|
@ -84,7 +84,7 @@ struct eisa_driver {
|
||||||
|
|
||||||
id_table : an array of NULL terminated EISA id strings,
|
id_table : an array of NULL terminated EISA id strings,
|
||||||
followed by an empty string. Each string can
|
followed by an empty string. Each string can
|
||||||
optionally be paired with a driver-dependant value
|
optionally be paired with a driver-dependent value
|
||||||
(driver_data).
|
(driver_data).
|
||||||
|
|
||||||
driver : a generic driver, such as described in
|
driver : a generic driver, such as described in
|
||||||
|
|
|
@ -204,7 +204,7 @@ Notes:
|
||||||
|
|
||||||
supported_output_devices
|
supported_output_devices
|
||||||
|
|
||||||
This read-only file contains a full ',' seperated list containing all
|
This read-only file contains a full ',' separated list containing all
|
||||||
output devices that could be available on your platform. It is likely
|
output devices that could be available on your platform. It is likely
|
||||||
that not all of those have a connector on your hardware but it should
|
that not all of those have a connector on your hardware but it should
|
||||||
provide a good starting point to figure out which of those names match
|
provide a good starting point to figure out which of those names match
|
||||||
|
@ -225,7 +225,7 @@ Notes:
|
||||||
This can happen for example if only one (the other) iga is used.
|
This can happen for example if only one (the other) iga is used.
|
||||||
Writing to these files allows adjusting the output devices during
|
Writing to these files allows adjusting the output devices during
|
||||||
runtime. One can add new devices, remove existing ones or switch
|
runtime. One can add new devices, remove existing ones or switch
|
||||||
between igas. Essentially you can write a ',' seperated list of device
|
between igas. Essentially you can write a ',' separated list of device
|
||||||
names (or a single one) in the same format as the output to those
|
names (or a single one) in the same format as the output to those
|
||||||
files. You can add a '+' or '-' as a prefix allowing simple addition
|
files. You can add a '+' or '-' as a prefix allowing simple addition
|
||||||
and removal of devices. So a prefix '+' adds the devices from your list
|
and removal of devices. So a prefix '+' adds the devices from your list
|
||||||
|
|
|
@ -309,7 +309,7 @@ ioctlfd field set to the descriptor obtained from the open call.
|
||||||
AUTOFS_DEV_IOCTL_TIMEOUT_CMD
|
AUTOFS_DEV_IOCTL_TIMEOUT_CMD
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
Set the expire timeout for mounts withing an autofs mount point.
|
Set the expire timeout for mounts within an autofs mount point.
|
||||||
|
|
||||||
The call requires an initialized struct autofs_dev_ioctl with the
|
The call requires an initialized struct autofs_dev_ioctl with the
|
||||||
ioctlfd field set to the descriptor obtained from the open call.
|
ioctlfd field set to the descriptor obtained from the open call.
|
||||||
|
|
|
@ -95,7 +95,7 @@ restraints as possible on how an index is structured and where it is placed in
|
||||||
the tree. The netfs can even mix indices and data files at the same level, but
|
the tree. The netfs can even mix indices and data files at the same level, but
|
||||||
it's not recommended.
|
it's not recommended.
|
||||||
|
|
||||||
Each index entry consists of a key of indeterminate length plus some auxilliary
|
Each index entry consists of a key of indeterminate length plus some auxiliary
|
||||||
data, also of indeterminate length.
|
data, also of indeterminate length.
|
||||||
|
|
||||||
There are some limits on indices:
|
There are some limits on indices:
|
||||||
|
@ -203,23 +203,23 @@ This has the following fields:
|
||||||
|
|
||||||
If the function is absent, a file size of 0 is assumed.
|
If the function is absent, a file size of 0 is assumed.
|
||||||
|
|
||||||
(6) A function to retrieve auxilliary data from the netfs [optional].
|
(6) A function to retrieve auxiliary data from the netfs [optional].
|
||||||
|
|
||||||
This function will be called with the netfs data that was passed to the
|
This function will be called with the netfs data that was passed to the
|
||||||
cookie acquisition function and the maximum length of auxilliary data that
|
cookie acquisition function and the maximum length of auxiliary data that
|
||||||
it may provide. It should write the auxilliary data into the given buffer
|
it may provide. It should write the auxiliary data into the given buffer
|
||||||
and return the quantity it wrote.
|
and return the quantity it wrote.
|
||||||
|
|
||||||
If this function is absent, the auxilliary data length will be set to 0.
|
If this function is absent, the auxiliary data length will be set to 0.
|
||||||
|
|
||||||
The length of the auxilliary data buffer may be dependent on the key
|
The length of the auxiliary data buffer may be dependent on the key
|
||||||
length. A netfs mustn't rely on being able to provide more than 400 bytes
|
length. A netfs mustn't rely on being able to provide more than 400 bytes
|
||||||
for both.
|
for both.
|
||||||
|
|
||||||
(7) A function to check the auxilliary data [optional].
|
(7) A function to check the auxiliary data [optional].
|
||||||
|
|
||||||
This function will be called to check that a match found in the cache for
|
This function will be called to check that a match found in the cache for
|
||||||
this object is valid. For instance with AFS it could check the auxilliary
|
this object is valid. For instance with AFS it could check the auxiliary
|
||||||
data against the data version number returned by the server to determine
|
data against the data version number returned by the server to determine
|
||||||
whether the index entry in a cache is still valid.
|
whether the index entry in a cache is still valid.
|
||||||
|
|
||||||
|
@ -232,7 +232,7 @@ This has the following fields:
|
||||||
(*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update
|
(*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update
|
||||||
(*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted
|
(*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted
|
||||||
|
|
||||||
This function can also be used to extract data from the auxilliary data in
|
This function can also be used to extract data from the auxiliary data in
|
||||||
the cache and copy it into the netfs's structures.
|
the cache and copy it into the netfs's structures.
|
||||||
|
|
||||||
(8) A pair of functions to manage contexts for the completion callback
|
(8) A pair of functions to manage contexts for the completion callback
|
||||||
|
|
|
@ -409,7 +409,7 @@ As a consequence of this, default_groups cannot be removed directly via
|
||||||
rmdir(2). They also are not considered when rmdir(2) on the parent
|
rmdir(2). They also are not considered when rmdir(2) on the parent
|
||||||
group is checking for children.
|
group is checking for children.
|
||||||
|
|
||||||
[Dependant Subsystems]
|
[Dependent Subsystems]
|
||||||
|
|
||||||
Sometimes other drivers depend on particular configfs items. For
|
Sometimes other drivers depend on particular configfs items. For
|
||||||
example, ocfs2 mounts depend on a heartbeat region item. If that
|
example, ocfs2 mounts depend on a heartbeat region item. If that
|
||||||
|
|
|
@ -97,7 +97,7 @@ Note: More extensive information for getting started with ext4 can be
|
||||||
* Inode allocation using large virtual block groups via flex_bg
|
* Inode allocation using large virtual block groups via flex_bg
|
||||||
* delayed allocation
|
* delayed allocation
|
||||||
* large block (up to pagesize) support
|
* large block (up to pagesize) support
|
||||||
* efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force
|
* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force
|
||||||
the ordering)
|
the ordering)
|
||||||
|
|
||||||
[1] Filesystems with a block size of 1k may see a limit imposed by the
|
[1] Filesystems with a block size of 1k may see a limit imposed by the
|
||||||
|
@ -106,7 +106,7 @@ directory hash tree having a maximum depth of two.
|
||||||
2.2 Candidate features for future inclusion
|
2.2 Candidate features for future inclusion
|
||||||
|
|
||||||
* Online defrag (patches available but not well tested)
|
* Online defrag (patches available but not well tested)
|
||||||
* reduced mke2fs time via lazy itable initialization in conjuction with
|
* reduced mke2fs time via lazy itable initialization in conjunction with
|
||||||
the uninit_bg feature (capability to do this is available in e2fsprogs
|
the uninit_bg feature (capability to do this is available in e2fsprogs
|
||||||
but a kernel thread to do lazy zeroing of unused inode table blocks
|
but a kernel thread to do lazy zeroing of unused inode table blocks
|
||||||
after filesystem is first mounted is required for safety)
|
after filesystem is first mounted is required for safety)
|
||||||
|
|
|
@ -62,7 +62,7 @@ be fixed.
|
||||||
|
|
||||||
The REMOVE uevent is generated at the end of an unsuccessful mount
|
The REMOVE uevent is generated at the end of an unsuccessful mount
|
||||||
or at the end of a umount of the filesystem. All REMOVE uevents will
|
or at the end of a umount of the filesystem. All REMOVE uevents will
|
||||||
have been preceeded by at least an ADD uevent for the same fileystem,
|
have been preceded by at least an ADD uevent for the same fileystem,
|
||||||
and unlike the other uevents is generated automatically by the kernel's
|
and unlike the other uevents is generated automatically by the kernel's
|
||||||
kobject subsystem.
|
kobject subsystem.
|
||||||
|
|
||||||
|
|
|
@ -11,7 +11,7 @@ their I/O so file system consistency is maintained. One of the nifty
|
||||||
features of GFS is perfect consistency -- changes made to the file system
|
features of GFS is perfect consistency -- changes made to the file system
|
||||||
on one machine show up immediately on all other machines in the cluster.
|
on one machine show up immediately on all other machines in the cluster.
|
||||||
|
|
||||||
GFS uses interchangable inter-node locking mechanisms, the currently
|
GFS uses interchangeable inter-node locking mechanisms, the currently
|
||||||
supported mechanisms are:
|
supported mechanisms are:
|
||||||
|
|
||||||
lock_nolock -- allows gfs to be used as a local file system
|
lock_nolock -- allows gfs to be used as a local file system
|
||||||
|
|
|
@ -350,7 +350,7 @@ Note the "Should sync?" parameter "nosync" means that the two mirrors are
|
||||||
already in sync which will be the case on a clean shutdown of Windows. If the
|
already in sync which will be the case on a clean shutdown of Windows. If the
|
||||||
mirrors are not clean, you can specify the "sync" option instead of "nosync"
|
mirrors are not clean, you can specify the "sync" option instead of "nosync"
|
||||||
and the Device-Mapper driver will then copy the entirety of the "Source Device"
|
and the Device-Mapper driver will then copy the entirety of the "Source Device"
|
||||||
to the "Target Device" or if you specified multipled target devices to all of
|
to the "Target Device" or if you specified multiple target devices to all of
|
||||||
them.
|
them.
|
||||||
|
|
||||||
Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),
|
Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),
|
||||||
|
|
|
@ -80,7 +80,7 @@ user_xattr (*) Enables Extended User Attributes.
|
||||||
nouser_xattr Disables Extended User Attributes.
|
nouser_xattr Disables Extended User Attributes.
|
||||||
acl Enables POSIX Access Control Lists support.
|
acl Enables POSIX Access Control Lists support.
|
||||||
noacl (*) Disables POSIX Access Control Lists support.
|
noacl (*) Disables POSIX Access Control Lists support.
|
||||||
resv_level=2 (*) Set how agressive allocation reservations will be.
|
resv_level=2 (*) Set how aggressive allocation reservations will be.
|
||||||
Valid values are between 0 (reservations off) to 8
|
Valid values are between 0 (reservations off) to 8
|
||||||
(maximum space for reservations).
|
(maximum space for reservations).
|
||||||
dir_resv_level= (*) By default, directory reservations will scale with file
|
dir_resv_level= (*) By default, directory reservations will scale with file
|
||||||
|
|
|
@ -42,7 +42,7 @@ Path walking overview
|
||||||
A name string specifies a start (root directory, cwd, fd-relative) and a
|
A name string specifies a start (root directory, cwd, fd-relative) and a
|
||||||
sequence of elements (directory entry names), which together refer to a path in
|
sequence of elements (directory entry names), which together refer to a path in
|
||||||
the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
|
the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
|
||||||
elements are sub-strings, seperated by '/'.
|
elements are sub-strings, separated by '/'.
|
||||||
|
|
||||||
Name lookups will want to find a particular path that a name string refers to
|
Name lookups will want to find a particular path that a name string refers to
|
||||||
(usually the final element, or parent of final element). This is done by taking
|
(usually the final element, or parent of final element). This is done by taking
|
||||||
|
@ -354,7 +354,7 @@ vfstest 24185492 4945 708725(2.9%) 1076136(4.4%) 0 2651
|
||||||
|
|
||||||
What this shows is that failed rcu-walk lookups, ie. ones that are restarted
|
What this shows is that failed rcu-walk lookups, ie. ones that are restarted
|
||||||
entirely with ref-walk, are quite rare. Even the "vfstest" case which
|
entirely with ref-walk, are quite rare. Even the "vfstest" case which
|
||||||
specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise
|
specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to exercise
|
||||||
such races is not showing a huge amount of restarts.
|
such races is not showing a huge amount of restarts.
|
||||||
|
|
||||||
Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
|
Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
|
||||||
|
|
|
@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
|
||||||
so one can extend protocol as needed without breaking backward compatibility as long
|
so one can extend protocol as needed without breaking backward compatibility as long
|
||||||
as old commands are supported. All string lengths include tail 0 byte.
|
as old commands are supported. All string lengths include tail 0 byte.
|
||||||
|
|
||||||
All commans are transfered over the network in big-endian. CPU endianess is used at the end peers.
|
All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
|
||||||
|
|
||||||
@cmd - command number, which specifies command to be processed. Following
|
@cmd - command number, which specifies command to be processed. Following
|
||||||
commands are used currently:
|
commands are used currently:
|
||||||
|
|
|
@ -543,7 +543,7 @@ just those considered 'most important'. The new vectors are:
|
||||||
their statistics are used by kernel developers and interested users to
|
their statistics are used by kernel developers and interested users to
|
||||||
determine the occurrence of interrupts of the given type.
|
determine the occurrence of interrupts of the given type.
|
||||||
|
|
||||||
The above IRQ vectors are displayed only when relevent. For example,
|
The above IRQ vectors are displayed only when relevant. For example,
|
||||||
the threshold vector does not exist on x86_64 platforms. Others are
|
the threshold vector does not exist on x86_64 platforms. Others are
|
||||||
suppressed when the system is a uniprocessor. As of this writing, only
|
suppressed when the system is a uniprocessor. As of this writing, only
|
||||||
i386 and x86_64 platforms support the new IRQ vector displays.
|
i386 and x86_64 platforms support the new IRQ vector displays.
|
||||||
|
@ -1202,7 +1202,7 @@ The columns are:
|
||||||
W = can do write operations
|
W = can do write operations
|
||||||
U = can do unblank
|
U = can do unblank
|
||||||
flags E = it is enabled
|
flags E = it is enabled
|
||||||
C = it is prefered console
|
C = it is preferred console
|
||||||
B = it is primary boot console
|
B = it is primary boot console
|
||||||
p = it is used for printk buffer
|
p = it is used for printk buffer
|
||||||
b = it is not a TTY but a Braille device
|
b = it is not a TTY but a Braille device
|
||||||
|
@ -1331,7 +1331,7 @@ NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
|
||||||
Documentation/feature-removal-schedule.txt.
|
Documentation/feature-removal-schedule.txt.
|
||||||
|
|
||||||
Caveat: when a parent task is selected, the oom killer will sacrifice any first
|
Caveat: when a parent task is selected, the oom killer will sacrifice any first
|
||||||
generation children with seperate address spaces instead, if possible. This
|
generation children with separate address spaces instead, if possible. This
|
||||||
avoids servers and important system daemons from being killed and loses the
|
avoids servers and important system daemons from being killed and loses the
|
||||||
minimal amount of work.
|
minimal amount of work.
|
||||||
|
|
||||||
|
|
|
@ -219,7 +219,7 @@ or if it is stored out of line (in which case the value field stores a
|
||||||
reference to where the actual value is stored). This allows large values
|
reference to where the actual value is stored). This allows large values
|
||||||
to be stored out of line improving scanning and lookup performance and it
|
to be stored out of line improving scanning and lookup performance and it
|
||||||
also allows values to be de-duplicated, the value being stored once, and
|
also allows values to be de-duplicated, the value being stored once, and
|
||||||
all other occurences holding an out of line reference to that value.
|
all other occurrences holding an out of line reference to that value.
|
||||||
|
|
||||||
The xattr lists are packed into compressed 8K metadata blocks.
|
The xattr lists are packed into compressed 8K metadata blocks.
|
||||||
To reduce overhead in inodes, rather than storing the on-disk
|
To reduce overhead in inodes, rather than storing the on-disk
|
||||||
|
|
|
@ -62,7 +62,7 @@ values of the same type.
|
||||||
|
|
||||||
Mixing types, expressing multiple lines of data, and doing fancy
|
Mixing types, expressing multiple lines of data, and doing fancy
|
||||||
formatting of data is heavily frowned upon. Doing these things may get
|
formatting of data is heavily frowned upon. Doing these things may get
|
||||||
you publically humiliated and your code rewritten without notice.
|
you publicly humiliated and your code rewritten without notice.
|
||||||
|
|
||||||
|
|
||||||
An attribute definition is simply:
|
An attribute definition is simply:
|
||||||
|
|
|
@ -97,7 +97,7 @@ functions:
|
||||||
The passed struct file_system_type describes your filesystem. When a
|
The passed struct file_system_type describes your filesystem. When a
|
||||||
request is made to mount a filesystem onto a directory in your namespace,
|
request is made to mount a filesystem onto a directory in your namespace,
|
||||||
the VFS will call the appropriate mount() method for the specific
|
the VFS will call the appropriate mount() method for the specific
|
||||||
filesystem. New vfsmount refering to the tree returned by ->mount()
|
filesystem. New vfsmount referring to the tree returned by ->mount()
|
||||||
will be attached to the mountpoint, so that when pathname resolution
|
will be attached to the mountpoint, so that when pathname resolution
|
||||||
reaches the mountpoint it will jump into the root of that vfsmount.
|
reaches the mountpoint it will jump into the root of that vfsmount.
|
||||||
|
|
||||||
|
|
|
@ -42,7 +42,7 @@ the aggregation of all the previous changes currently held only in the log.
|
||||||
This relogging technique also allows objects to be moved forward in the log so
|
This relogging technique also allows objects to be moved forward in the log so
|
||||||
that an object being relogged does not prevent the tail of the log from ever
|
that an object being relogged does not prevent the tail of the log from ever
|
||||||
moving forward. This can be seen in the table above by the changing
|
moving forward. This can be seen in the table above by the changing
|
||||||
(increasing) LSN of each subsquent transaction - the LSN is effectively a
|
(increasing) LSN of each subsequent transaction - the LSN is effectively a
|
||||||
direct encoding of the location in the log of the transaction.
|
direct encoding of the location in the log of the transaction.
|
||||||
|
|
||||||
This relogging is also used to implement long-running, multiple-commit
|
This relogging is also used to implement long-running, multiple-commit
|
||||||
|
@ -338,7 +338,7 @@ the same time another transaction modifies the item and inserts the log item
|
||||||
into the new CIL, then checkpoint transaction commit code cannot use log items
|
into the new CIL, then checkpoint transaction commit code cannot use log items
|
||||||
to store the list of log vectors that need to be written into the transaction.
|
to store the list of log vectors that need to be written into the transaction.
|
||||||
Hence log vectors need to be able to be chained together to allow them to be
|
Hence log vectors need to be able to be chained together to allow them to be
|
||||||
detatched from the log items. That is, when the CIL is flushed the memory
|
detached from the log items. That is, when the CIL is flushed the memory
|
||||||
buffer and log vector attached to each log item needs to be attached to the
|
buffer and log vector attached to each log item needs to be attached to the
|
||||||
checkpoint context so that the log item can be released. In diagrammatic form,
|
checkpoint context so that the log item can be released. In diagrammatic form,
|
||||||
the CIL would look like this before the flush:
|
the CIL would look like this before the flush:
|
||||||
|
@ -577,7 +577,7 @@ only becomes unpinned when all the transactions complete and there are no
|
||||||
pending transactions. Thus the pinning and unpinning of a log item is symmetric
|
pending transactions. Thus the pinning and unpinning of a log item is symmetric
|
||||||
as there is a 1:1 relationship with transaction commit and log item completion.
|
as there is a 1:1 relationship with transaction commit and log item completion.
|
||||||
|
|
||||||
For delayed logging, however, we have an assymetric transaction commit to
|
For delayed logging, however, we have an asymmetric transaction commit to
|
||||||
completion relationship. Every time an object is relogged in the CIL it goes
|
completion relationship. Every time an object is relogged in the CIL it goes
|
||||||
through the commit process without a corresponding completion being registered.
|
through the commit process without a corresponding completion being registered.
|
||||||
That is, we now have a many-to-one relationship between transaction commit and
|
That is, we now have a many-to-one relationship between transaction commit and
|
||||||
|
@ -780,7 +780,7 @@ With delayed logging, there are new steps inserted into the life cycle:
|
||||||
From this, it can be seen that the only life cycle differences between the two
|
From this, it can be seen that the only life cycle differences between the two
|
||||||
logging methods are in the middle of the life cycle - they still have the same
|
logging methods are in the middle of the life cycle - they still have the same
|
||||||
beginning and end and execution constraints. The only differences are in the
|
beginning and end and execution constraints. The only differences are in the
|
||||||
commiting of the log items to the log itself and the completion processing.
|
committing of the log items to the log itself and the completion processing.
|
||||||
Hence delayed logging should not introduce any constraints on log item
|
Hence delayed logging should not introduce any constraints on log item
|
||||||
behaviour, allocation or freeing that don't already exist.
|
behaviour, allocation or freeing that don't already exist.
|
||||||
|
|
||||||
|
|
|
@ -78,7 +78,7 @@ motherboards (most modern Abit motherboards).
|
||||||
|
|
||||||
The first and second revision of the uGuru chip in reality is a Winbond
|
The first and second revision of the uGuru chip in reality is a Winbond
|
||||||
W83L950D in disguise (despite Abit claiming it is "a new microprocessor
|
W83L950D in disguise (despite Abit claiming it is "a new microprocessor
|
||||||
designed by the ABIT Engineers"). Unfortunatly this doesn't help since the
|
designed by the ABIT Engineers"). Unfortunately this doesn't help since the
|
||||||
W83L950D is a generic microcontroller with a custom Abit application running
|
W83L950D is a generic microcontroller with a custom Abit application running
|
||||||
on it.
|
on it.
|
||||||
|
|
||||||
|
|
|
@ -5,9 +5,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or
|
||||||
datasheet from Abit. The data I have got on uGuru have I assembled through
|
datasheet from Abit. The data I have got on uGuru have I assembled through
|
||||||
my weak knowledge in "backwards engineering".
|
my weak knowledge in "backwards engineering".
|
||||||
And just for the record, you may have noticed uGuru isn't a chip developed by
|
And just for the record, you may have noticed uGuru isn't a chip developed by
|
||||||
Abit, as they claim it to be. It's realy just an microprocessor (uC) created by
|
Abit, as they claim it to be. It's really just an microprocessor (uC) created by
|
||||||
Winbond (W83L950D). And no, reading the manual for this specific uC or
|
Winbond (W83L950D). And no, reading the manual for this specific uC or
|
||||||
mailing Windbond for help won't give any usefull data about uGuru, as it is
|
mailing Windbond for help won't give any useful data about uGuru, as it is
|
||||||
the program inside the uC that is responding to calls.
|
the program inside the uC that is responding to calls.
|
||||||
|
|
||||||
Olle Sandberg <ollebull@gmail.com>, 2005-05-25
|
Olle Sandberg <ollebull@gmail.com>, 2005-05-25
|
||||||
|
@ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later.
|
||||||
|
|
||||||
After wider testing of the Linux kernel driver some variants of the uGuru have
|
After wider testing of the Linux kernel driver some variants of the uGuru have
|
||||||
turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
|
turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
|
||||||
have to test CMD for two different values. On these uGuru's DATA will initally
|
have to test CMD for two different values. On these uGuru's DATA will initially
|
||||||
hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
|
hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
|
||||||
first!
|
first!
|
||||||
|
|
||||||
|
@ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks
|
||||||
resulted in a _permanent_ reprogramming of the voltages, luckily I had the
|
resulted in a _permanent_ reprogramming of the voltages, luckily I had the
|
||||||
sensors part configured so that it would shutdown my system on any out of spec
|
sensors part configured so that it would shutdown my system on any out of spec
|
||||||
voltages which proprably safed my computer (after a reboot I managed to
|
voltages which proprably safed my computer (after a reboot I managed to
|
||||||
immediatly enter the bios and reload the defaults). This probably means that
|
immediately enter the bios and reload the defaults). This probably means that
|
||||||
the read/write cycle for the non sensor part is different from the sensor part.
|
the read/write cycle for the non sensor part is different from the sensor part.
|
||||||
|
|
|
@ -47,7 +47,7 @@ This driver supports the hardware monitoring features of the third revision of
|
||||||
the Abit uGuru chip, found on recent Abit uGuru featuring motherboards.
|
the Abit uGuru chip, found on recent Abit uGuru featuring motherboards.
|
||||||
|
|
||||||
The 3rd revision of the uGuru chip in reality is a Winbond W83L951G.
|
The 3rd revision of the uGuru chip in reality is a Winbond W83L951G.
|
||||||
Unfortunatly this doesn't help since the W83L951G is a generic microcontroller
|
Unfortunately this doesn't help since the W83L951G is a generic microcontroller
|
||||||
with a custom Abit application running on it.
|
with a custom Abit application running on it.
|
||||||
|
|
||||||
Despite Abit not releasing any information regarding the uGuru revision 3,
|
Despite Abit not releasing any information regarding the uGuru revision 3,
|
||||||
|
|
|
@ -150,11 +150,11 @@ The following attributes are supported. Limits are read-write; all other
|
||||||
attributes are read-only.
|
attributes are read-only.
|
||||||
|
|
||||||
inX_input Measured voltage. From READ_VIN or READ_VOUT register.
|
inX_input Measured voltage. From READ_VIN or READ_VOUT register.
|
||||||
inX_min Minumum Voltage.
|
inX_min Minimum Voltage.
|
||||||
From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register.
|
From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register.
|
||||||
inX_max Maximum voltage.
|
inX_max Maximum voltage.
|
||||||
From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register.
|
From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register.
|
||||||
inX_lcrit Critical minumum Voltage.
|
inX_lcrit Critical minimum Voltage.
|
||||||
From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register.
|
From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register.
|
||||||
inX_crit Critical maximum voltage.
|
inX_crit Critical maximum voltage.
|
||||||
From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register.
|
From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register.
|
||||||
|
@ -169,7 +169,7 @@ inX_label "vin", "vcap", or "voutY"
|
||||||
currX_input Measured current. From READ_IIN or READ_IOUT register.
|
currX_input Measured current. From READ_IIN or READ_IOUT register.
|
||||||
currX_max Maximum current.
|
currX_max Maximum current.
|
||||||
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register.
|
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register.
|
||||||
currX_lcrit Critical minumum output current.
|
currX_lcrit Critical minimum output current.
|
||||||
From IOUT_UC_FAULT_LIMIT register.
|
From IOUT_UC_FAULT_LIMIT register.
|
||||||
currX_crit Critical maximum current.
|
currX_crit Critical maximum current.
|
||||||
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
|
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
|
||||||
|
|
|
@ -579,7 +579,7 @@ channel should not be trusted.
|
||||||
fan[1-*]_fault
|
fan[1-*]_fault
|
||||||
temp[1-*]_fault
|
temp[1-*]_fault
|
||||||
Input fault condition
|
Input fault condition
|
||||||
0: no fault occured
|
0: no fault occurred
|
||||||
1: fault condition
|
1: fault condition
|
||||||
RO
|
RO
|
||||||
|
|
||||||
|
|
|
@ -403,7 +403,7 @@ found out the following values do work as a form of coarse pwm:
|
||||||
|
|
||||||
0x80 - seems to turn fans off after some time(1-2 minutes)... might be
|
0x80 - seems to turn fans off after some time(1-2 minutes)... might be
|
||||||
some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
|
some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
|
||||||
old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan
|
old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan
|
||||||
that was dropped at the BIOS)
|
that was dropped at the BIOS)
|
||||||
0x81 - off
|
0x81 - off
|
||||||
0x82 - slightly "on-ner" than off, but my fans do not get to move. I can
|
0x82 - slightly "on-ner" than off, but my fans do not get to move. I can
|
||||||
|
|
|
@ -93,7 +93,7 @@ The sysfs interface to the beep bitmask has migrated from the original legacy
|
||||||
method of a single sysfs beep_mask file to a newer method using multiple
|
method of a single sysfs beep_mask file to a newer method using multiple
|
||||||
*_beep files as described in .../Documentation/hwmon/sysfs-interface.
|
*_beep files as described in .../Documentation/hwmon/sysfs-interface.
|
||||||
|
|
||||||
A similar change has occured for the bitmap corresponding to the alarms. The
|
A similar change has occurred for the bitmap corresponding to the alarms. The
|
||||||
original legacy method used a single sysfs alarms file containing a bitmap
|
original legacy method used a single sysfs alarms file containing a bitmap
|
||||||
of triggered alarms. The newer method uses multiple sysfs *_alarm files
|
of triggered alarms. The newer method uses multiple sysfs *_alarm files
|
||||||
(again following the pattern described in sysfs-interface).
|
(again following the pattern described in sysfs-interface).
|
||||||
|
|
|
@ -4,7 +4,7 @@ Author: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
This driver is a light version of i2c-parport. It doesn't depend
|
This driver is a light version of i2c-parport. It doesn't depend
|
||||||
on the parport driver, and uses direct I/O access instead. This might be
|
on the parport driver, and uses direct I/O access instead. This might be
|
||||||
prefered on embedded systems where wasting memory for the clean but heavy
|
preferred on embedded systems where wasting memory for the clean but heavy
|
||||||
parport handling is not an option. The drawback is a reduced portability
|
parport handling is not an option. The drawback is a reduced portability
|
||||||
and the impossibility to daisy-chain other parallel port devices.
|
and the impossibility to daisy-chain other parallel port devices.
|
||||||
|
|
||||||
|
|
|
@ -35,7 +35,7 @@ or perhaps this...
|
||||||
|
|
||||||
(kernel versions later than 2.4.18 may fill in the "Unknown"s)
|
(kernel versions later than 2.4.18 may fill in the "Unknown"s)
|
||||||
|
|
||||||
If you cant see it please look on quirk_sis_96x_smbus
|
If you can't see it please look on quirk_sis_96x_smbus
|
||||||
(drivers/pci/quirks.c) (also if southbridge detection fails)
|
(drivers/pci/quirks.c) (also if southbridge detection fails)
|
||||||
|
|
||||||
I suspect that this driver could be made to work for the following SiS
|
I suspect that this driver could be made to work for the following SiS
|
||||||
|
|
|
@ -13,7 +13,7 @@ Currently supported devices are:
|
||||||
|
|
||||||
* TAOS TSL2550 EVM
|
* TAOS TSL2550 EVM
|
||||||
|
|
||||||
For addtional information on TAOS products, please see
|
For additional information on TAOS products, please see
|
||||||
http://www.taosinc.com/
|
http://www.taosinc.com/
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -53,7 +53,7 @@ Symbios Logic (Now LSI)
|
||||||
BoxHill Corporation
|
BoxHill Corporation
|
||||||
Loan of initial FibreChannel disk array used for development work.
|
Loan of initial FibreChannel disk array used for development work.
|
||||||
|
|
||||||
European Comission
|
European Commission
|
||||||
Funding the work done by the University of Helsinki
|
Funding the work done by the University of Helsinki
|
||||||
|
|
||||||
SysKonnect
|
SysKonnect
|
||||||
|
|
|
@ -177,7 +177,7 @@ static int scan_rom(char *path, char *file)
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* It's OK if the ROM is unreadable. Maybe there
|
* It's OK if the ROM is unreadable. Maybe there
|
||||||
* is no ROM, or some other error ocurred. The
|
* is no ROM, or some other error occurred. The
|
||||||
* important thing is that no MCA happened.
|
* important thing is that no MCA happened.
|
||||||
*/
|
*/
|
||||||
if (rc > 0)
|
if (rc > 0)
|
||||||
|
|
|
@ -272,7 +272,7 @@ if you want to use gamecon.c.
|
||||||
|
|
||||||
Also, the connection is a bit more complex. You'll need a bunch of diodes,
|
Also, the connection is a bit more complex. You'll need a bunch of diodes,
|
||||||
and one pullup resistor. First, you connect the Directions and the button
|
and one pullup resistor. First, you connect the Directions and the button
|
||||||
the same as for db9, however with the diodes inbetween.
|
the same as for db9, however with the diodes between.
|
||||||
|
|
||||||
Diodes
|
Diodes
|
||||||
(pin 2) -----|<|----> Up
|
(pin 2) -----|<|----> Up
|
||||||
|
|
|
@ -46,7 +46,7 @@ c) Falling edge on channel A, channel B in high state
|
||||||
|
|
||||||
d) Falling edge on channel B, channel A in low state
|
d) Falling edge on channel B, channel A in low state
|
||||||
Parking position. If the encoder enters this state, a full transition
|
Parking position. If the encoder enters this state, a full transition
|
||||||
should have happend, unless it flipped back on half the way. The
|
should have happened, unless it flipped back on half the way. The
|
||||||
'armed' state tells us about that.
|
'armed' state tells us about that.
|
||||||
|
|
||||||
2. Platform requirements
|
2. Platform requirements
|
||||||
|
|
|
@ -77,7 +77,7 @@ pulse length:
|
||||||
|
|
||||||
24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits
|
24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits
|
||||||
|
|
||||||
(Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync
|
(Warning, pulses on ACK are inverted by transistor, irq is raised up on sync
|
||||||
to bin change or octal value to bin change).
|
to bin change or octal value to bin change).
|
||||||
|
|
||||||
Binary data representations:
|
Binary data representations:
|
||||||
|
|
|
@ -53,5 +53,5 @@ implementation in an architecture: lockdep will detect that and will
|
||||||
turn itself off. I.e. the lock validator will still be reliable. There
|
turn itself off. I.e. the lock validator will still be reliable. There
|
||||||
should be no crashes due to irq-tracing bugs. (except if the assembly
|
should be no crashes due to irq-tracing bugs. (except if the assembly
|
||||||
changes break other code by modifying conditions or registers that
|
changes break other code by modifying conditions or registers that
|
||||||
shouldnt be)
|
shouldn't be)
|
||||||
|
|
||||||
|
|
|
@ -240,7 +240,7 @@ Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert
|
||||||
messages between their transport encoding described in the CAPI 2.0 standard
|
messages between their transport encoding described in the CAPI 2.0 standard
|
||||||
and their _cmsg structure representation. Note that capi_cmsg2message() does
|
and their _cmsg structure representation. Note that capi_cmsg2message() does
|
||||||
not know or check the size of its destination buffer. The caller must make
|
not know or check the size of its destination buffer. The caller must make
|
||||||
sure it is big enough to accomodate the resulting CAPI message.
|
sure it is big enough to accommodate the resulting CAPI message.
|
||||||
|
|
||||||
|
|
||||||
5. Lower Layer Interface Functions
|
5. Lower Layer Interface Functions
|
||||||
|
|
|
@ -26,11 +26,11 @@ Additional options to the assembler (for built-in and modules).
|
||||||
|
|
||||||
AFLAGS_MODULE
|
AFLAGS_MODULE
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
Addtional module specific options to use for $(AS).
|
Additional module specific options to use for $(AS).
|
||||||
|
|
||||||
AFLAGS_KERNEL
|
AFLAGS_KERNEL
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
Addtional options for $(AS) when used for assembler
|
Additional options for $(AS) when used for assembler
|
||||||
code for code that is compiled as built-in.
|
code for code that is compiled as built-in.
|
||||||
|
|
||||||
KCFLAGS
|
KCFLAGS
|
||||||
|
@ -39,12 +39,12 @@ Additional options to the C compiler (for built-in and modules).
|
||||||
|
|
||||||
CFLAGS_KERNEL
|
CFLAGS_KERNEL
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
Addtional options for $(CC) when used to compile
|
Additional options for $(CC) when used to compile
|
||||||
code that is compiled as built-in.
|
code that is compiled as built-in.
|
||||||
|
|
||||||
CFLAGS_MODULE
|
CFLAGS_MODULE
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
Addtional module specific options to use for $(CC).
|
Additional module specific options to use for $(CC).
|
||||||
|
|
||||||
LDFLAGS_MODULE
|
LDFLAGS_MODULE
|
||||||
--------------------------------------------------
|
--------------------------------------------------
|
||||||
|
|
|
@ -699,7 +699,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
ekgdboc= [X86,KGDB] Allow early kernel console debugging
|
ekgdboc= [X86,KGDB] Allow early kernel console debugging
|
||||||
ekgdboc=kbd
|
ekgdboc=kbd
|
||||||
|
|
||||||
This is desgined to be used in conjunction with
|
This is designed to be used in conjunction with
|
||||||
the boot argument: earlyprintk=vga
|
the boot argument: earlyprintk=vga
|
||||||
|
|
||||||
edd= [EDD]
|
edd= [EDD]
|
||||||
|
@ -1832,15 +1832,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
perfmon on Intel CPUs instead of the
|
perfmon on Intel CPUs instead of the
|
||||||
CPU specific event set.
|
CPU specific event set.
|
||||||
|
|
||||||
oops=panic Always panic on oopses. Default is to just kill the process,
|
oops=panic Always panic on oopses. Default is to just kill the
|
||||||
but there is a small probability of deadlocking the machine.
|
process, but there is a small probability of
|
||||||
|
deadlocking the machine.
|
||||||
This will also cause panics on machine check exceptions.
|
This will also cause panics on machine check exceptions.
|
||||||
Useful together with panic=30 to trigger a reboot.
|
Useful together with panic=30 to trigger a reboot.
|
||||||
|
|
||||||
OSS [HW,OSS]
|
OSS [HW,OSS]
|
||||||
See Documentation/sound/oss/oss-parameters.txt
|
See Documentation/sound/oss/oss-parameters.txt
|
||||||
|
|
||||||
panic= [KNL] Kernel behaviour on panic
|
panic= [KNL] Kernel behaviour on panic: delay <timeout>
|
||||||
|
seconds before rebooting
|
||||||
Format: <timeout>
|
Format: <timeout>
|
||||||
|
|
||||||
parkbd.port= [HW] Parallel port number the keyboard adapter is
|
parkbd.port= [HW] Parallel port number the keyboard adapter is
|
||||||
|
@ -2343,6 +2345,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
|
|
||||||
softlockup_panic=
|
softlockup_panic=
|
||||||
[KNL] Should the soft-lockup detector generate panics.
|
[KNL] Should the soft-lockup detector generate panics.
|
||||||
|
Format: <integer>
|
||||||
|
|
||||||
sonypi.*= [HW] Sony Programmable I/O Control Device driver
|
sonypi.*= [HW] Sony Programmable I/O Control Device driver
|
||||||
See Documentation/sonypi.txt
|
See Documentation/sonypi.txt
|
||||||
|
@ -2475,8 +2478,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
topology= [S390]
|
topology= [S390]
|
||||||
Format: {off | on}
|
Format: {off | on}
|
||||||
Specify if the kernel should make use of the cpu
|
Specify if the kernel should make use of the cpu
|
||||||
topology informations if the hardware supports these.
|
topology information if the hardware supports this.
|
||||||
The scheduler will make use of these informations and
|
The scheduler will make use of this information and
|
||||||
e.g. base its process migration decisions on it.
|
e.g. base its process migration decisions on it.
|
||||||
Default is on.
|
Default is on.
|
||||||
|
|
||||||
|
@ -2529,8 +2532,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||||
reported either.
|
reported either.
|
||||||
|
|
||||||
unknown_nmi_panic
|
unknown_nmi_panic
|
||||||
[X86]
|
[X86] Cause panic on unknown NMI.
|
||||||
Set unknown_nmi_panic=1 early on boot.
|
|
||||||
|
|
||||||
usbcore.autosuspend=
|
usbcore.autosuspend=
|
||||||
[USB] The autosuspend time delay (in seconds) used
|
[USB] The autosuspend time delay (in seconds) used
|
||||||
|
|
|
@ -11,6 +11,7 @@ with the difference that the orphan objects are not freed but only
|
||||||
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
|
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
|
||||||
Valgrind tool (memcheck --leak-check) to detect the memory leaks in
|
Valgrind tool (memcheck --leak-check) to detect the memory leaks in
|
||||||
user-space applications.
|
user-space applications.
|
||||||
|
Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile.
|
||||||
|
|
||||||
Usage
|
Usage
|
||||||
-----
|
-----
|
||||||
|
@ -178,5 +179,4 @@ block doesn't need to be freed (some cases in the init_call functions),
|
||||||
the pointer is calculated by other methods than the usual container_of
|
the pointer is calculated by other methods than the usual container_of
|
||||||
macro or the pointer is stored in a location not scanned by kmemleak.
|
macro or the pointer is stored in a location not scanned by kmemleak.
|
||||||
|
|
||||||
Page allocations and ioremap are not tracked. Only the ARM and x86
|
Page allocations and ioremap are not tracked.
|
||||||
architectures are currently supported.
|
|
||||||
|
|
|
@ -23,7 +23,7 @@ The mmu code attempts to satisfy the following requirements:
|
||||||
and framebuffer-based displays
|
and framebuffer-based displays
|
||||||
- footprint: keep the amount of pinned kernel memory low (most memory
|
- footprint: keep the amount of pinned kernel memory low (most memory
|
||||||
should be shrinkable)
|
should be shrinkable)
|
||||||
- reliablity: avoid multipage or GFP_ATOMIC allocations
|
- reliability: avoid multipage or GFP_ATOMIC allocations
|
||||||
|
|
||||||
Acronyms
|
Acronyms
|
||||||
========
|
========
|
||||||
|
|
|
@ -136,7 +136,7 @@ Patched instructions
|
||||||
====================
|
====================
|
||||||
|
|
||||||
The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
|
The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
|
||||||
respectively on 32 bit systems with an added offset of 4 to accomodate for big
|
respectively on 32 bit systems with an added offset of 4 to accommodate for big
|
||||||
endianness.
|
endianness.
|
||||||
|
|
||||||
The following is a list of mapping the Linux kernel performs when running as
|
The following is a list of mapping the Linux kernel performs when running as
|
||||||
|
|
|
@ -81,7 +81,7 @@ Mode 0: Single Timeout. This is a one-shot software timeout that counts down
|
||||||
when the gate is high (always true for timers 0 and 1). When the count
|
when the gate is high (always true for timers 0 and 1). When the count
|
||||||
reaches zero, the output goes high.
|
reaches zero, the output goes high.
|
||||||
|
|
||||||
Mode 1: Triggered One-shot. The output is intially set high. When the gate
|
Mode 1: Triggered One-shot. The output is initially set high. When the gate
|
||||||
line is set high, a countdown is initiated (which does not stop if the gate is
|
line is set high, a countdown is initiated (which does not stop if the gate is
|
||||||
lowered), during which the output is set low. When the count reaches zero,
|
lowered), during which the output is set low. When the count reaches zero,
|
||||||
the output goes high.
|
the output goes high.
|
||||||
|
|
|
@ -61,7 +61,7 @@ Usage
|
||||||
Hotkeys are also reported as input keys (like keyboards) you can check
|
Hotkeys are also reported as input keys (like keyboards) you can check
|
||||||
which key are supported using "xev" under X11.
|
which key are supported using "xev" under X11.
|
||||||
|
|
||||||
You can get informations on the version of your DSDT table by reading the
|
You can get information on the version of your DSDT table by reading the
|
||||||
/sys/devices/platform/asus-laptop/infos entry. If you have a question or a
|
/sys/devices/platform/asus-laptop/infos entry. If you have a question or a
|
||||||
bug report to do, please include the output of this entry.
|
bug report to do, please include the output of this entry.
|
||||||
|
|
||||||
|
@ -178,7 +178,7 @@ LED display
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
Some models like the W1N have a LED display that can be used to display
|
Some models like the W1N have a LED display that can be used to display
|
||||||
several informations.
|
several items of information.
|
||||||
|
|
||||||
LED display works for the following models:
|
LED display works for the following models:
|
||||||
W1000N
|
W1000N
|
||||||
|
|
8
Documentation/leds/00-INDEX
Normal file
8
Documentation/leds/00-INDEX
Normal file
|
@ -0,0 +1,8 @@
|
||||||
|
leds-class.txt
|
||||||
|
- documents LED handling under Linux.
|
||||||
|
leds-lp3944.txt
|
||||||
|
- notes on how to use the leds-lp3944 driver.
|
||||||
|
leds-lp5521.txt
|
||||||
|
- notes on how to use the leds-lp5521 driver.
|
||||||
|
leds-lp5523.txt
|
||||||
|
- notes on how to use the leds-lp5523 driver.
|
|
@ -95,4 +95,3 @@ There are a number of cases where a trigger might only be mappable to a
|
||||||
particular LED (ACPI?). The addition of triggers provided by the LED driver
|
particular LED (ACPI?). The addition of triggers provided by the LED driver
|
||||||
should cover this option and be possible to add without breaking the
|
should cover this option and be possible to add without breaking the
|
||||||
current interface.
|
current interface.
|
||||||
|
|
|
@ -194,7 +194,7 @@ each pad.
|
||||||
|
|
||||||
Links are represented by a struct media_link instance, defined in
|
Links are represented by a struct media_link instance, defined in
|
||||||
include/media/media-entity.h. Each entity stores all links originating at or
|
include/media/media-entity.h. Each entity stores all links originating at or
|
||||||
targetting any of its pads in a links array. A given link is thus stored
|
targeting any of its pads in a links array. A given link is thus stored
|
||||||
twice, once in the source entity and once in the target entity. The array is
|
twice, once in the source entity and once in the target entity. The array is
|
||||||
pre-allocated and grows dynamically as needed.
|
pre-allocated and grows dynamically as needed.
|
||||||
|
|
||||||
|
@ -348,6 +348,6 @@ a streaming entity. Links that can be modified while streaming must be marked
|
||||||
with the MEDIA_LNK_FL_DYNAMIC flag.
|
with the MEDIA_LNK_FL_DYNAMIC flag.
|
||||||
|
|
||||||
If other operations need to be disallowed on streaming entities (such as
|
If other operations need to be disallowed on streaming entities (such as
|
||||||
changing entities configuration parameters) drivers can explictly check the
|
changing entities configuration parameters) drivers can explicitly check the
|
||||||
media_entity stream_count field to find out if an entity is streaming. This
|
media_entity stream_count field to find out if an entity is streaming. This
|
||||||
operation must be done with the media_device graph_mutex held.
|
operation must be done with the media_device graph_mutex held.
|
||||||
|
|
|
@ -39,13 +39,13 @@ Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE
|
||||||
Interface and Linux Device Driver" Application Note.
|
Interface and Linux Device Driver" Application Note.
|
||||||
|
|
||||||
|
|
||||||
FILES, CONFIGS AND COMPATABILITY
|
FILES, CONFIGS AND COMPATIBILITY
|
||||||
--------------------------------
|
--------------------------------
|
||||||
|
|
||||||
Two files are introduced:
|
Two files are introduced:
|
||||||
|
|
||||||
a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h'
|
a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h'
|
||||||
containes : struct _auide_hwif
|
contains : struct _auide_hwif
|
||||||
timing parameters for PIO mode 0/1/2/3/4
|
timing parameters for PIO mode 0/1/2/3/4
|
||||||
timing parameters for MWDMA 0/1/2
|
timing parameters for MWDMA 0/1/2
|
||||||
|
|
||||||
|
|
|
@ -5,7 +5,7 @@ Supported chips:
|
||||||
* IDT ICS932S401
|
* IDT ICS932S401
|
||||||
Prefix: 'ics932s401'
|
Prefix: 'ics932s401'
|
||||||
Addresses scanned: I2C 0x69
|
Addresses scanned: I2C 0x69
|
||||||
Datasheet: Publically available at the IDT website
|
Datasheet: Publicly available at the IDT website
|
||||||
|
|
||||||
Author: Darrick J. Wong
|
Author: Darrick J. Wong
|
||||||
|
|
||||||
|
|
|
@ -256,7 +256,7 @@ You can set the debug level via:
|
||||||
|
|
||||||
Where $VALUE would be a number in the case of this sysfs entry. The
|
Where $VALUE would be a number in the case of this sysfs entry. The
|
||||||
input to sysfs files does not have to be a number. For example, the
|
input to sysfs files does not have to be a number. For example, the
|
||||||
firmware loader used by hotplug utilizes sysfs entries for transfering
|
firmware loader used by hotplug utilizes sysfs entries for transferring
|
||||||
the firmware image from user space into the driver.
|
the firmware image from user space into the driver.
|
||||||
|
|
||||||
The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
|
The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
|
||||||
|
|
|
@ -72,7 +72,7 @@ folder:
|
||||||
# fragmentation gw_sel_class vis_mode
|
# fragmentation gw_sel_class vis_mode
|
||||||
|
|
||||||
|
|
||||||
There is a special folder for debugging informations:
|
There is a special folder for debugging information:
|
||||||
|
|
||||||
# ls /sys/kernel/debug/batman_adv/bat0/
|
# ls /sys/kernel/debug/batman_adv/bat0/
|
||||||
# gateways socket transtable_global vis_data
|
# gateways socket transtable_global vis_data
|
||||||
|
|
|
@ -368,7 +368,7 @@ fail_over_mac
|
||||||
gratuitous ARP is lost, communication may be
|
gratuitous ARP is lost, communication may be
|
||||||
disrupted.
|
disrupted.
|
||||||
|
|
||||||
When this policy is used in conjuction with the mii
|
When this policy is used in conjunction with the mii
|
||||||
monitor, devices which assert link up prior to being
|
monitor, devices which assert link up prior to being
|
||||||
able to actually transmit and receive are particularly
|
able to actually transmit and receive are particularly
|
||||||
susceptible to loss of the gratuitous ARP, and an
|
susceptible to loss of the gratuitous ARP, and an
|
||||||
|
|
|
@ -136,7 +136,7 @@ The CAIF Protocol implementation contains:
|
||||||
- CFMUX CAIF Mux layer. Handles multiplexing between multiple
|
- CFMUX CAIF Mux layer. Handles multiplexing between multiple
|
||||||
physical bearers and multiple channels such as VEI, Datagram, etc.
|
physical bearers and multiple channels such as VEI, Datagram, etc.
|
||||||
The MUX keeps track of the existing CAIF Channels and
|
The MUX keeps track of the existing CAIF Channels and
|
||||||
Physical Instances and selects the apropriate instance based
|
Physical Instances and selects the appropriate instance based
|
||||||
on Channel-Id and Physical-ID.
|
on Channel-Id and Physical-ID.
|
||||||
|
|
||||||
- CFFRML CAIF Framing layer. Handles Framing i.e. Frame length
|
- CFFRML CAIF Framing layer. Handles Framing i.e. Frame length
|
||||||
|
|
|
@ -150,7 +150,7 @@ static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
|
||||||
void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
|
void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
|
||||||
{
|
{
|
||||||
/* If xfer is true then you should assert the SPI_INT to indicate to
|
/* If xfer is true then you should assert the SPI_INT to indicate to
|
||||||
* the master that you are ready to recieve the data from the master
|
* the master that you are ready to receive the data from the master
|
||||||
* SPI. If xfer is false then you should de-assert SPI_INT to indicate
|
* SPI. If xfer is false then you should de-assert SPI_INT to indicate
|
||||||
* that the transfer is done.
|
* that the transfer is done.
|
||||||
*/
|
*/
|
||||||
|
|
|
@ -240,7 +240,7 @@ solution for a couple of reasons:
|
||||||
the user application using the common CAN filter mechanisms. Inside
|
the user application using the common CAN filter mechanisms. Inside
|
||||||
this filter definition the (interested) type of errors may be
|
this filter definition the (interested) type of errors may be
|
||||||
selected. The reception of error frames is disabled by default.
|
selected. The reception of error frames is disabled by default.
|
||||||
The format of the CAN error frame is briefly decribed in the Linux
|
The format of the CAN error frame is briefly described in the Linux
|
||||||
header file "include/linux/can/error.h".
|
header file "include/linux/can/error.h".
|
||||||
|
|
||||||
4. How to use Socket CAN
|
4. How to use Socket CAN
|
||||||
|
|
|
@ -9,7 +9,7 @@ The Linux-ZigBee project goal is to provide complete implementation
|
||||||
of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
|
of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
|
||||||
of protocols for organizing Low-Rate Wireless Personal Area Networks.
|
of protocols for organizing Low-Rate Wireless Personal Area Networks.
|
||||||
|
|
||||||
Currently only IEEE 802.15.4 layer is implemented. We have choosen
|
Currently only IEEE 802.15.4 layer is implemented. We have chosen
|
||||||
to use plain Berkeley socket API, the generic Linux networking stack
|
to use plain Berkeley socket API, the generic Linux networking stack
|
||||||
to transfer IEEE 802.15.4 messages and a special protocol over genetlink
|
to transfer IEEE 802.15.4 messages and a special protocol over genetlink
|
||||||
for configuration/management
|
for configuration/management
|
||||||
|
|
|
@ -223,7 +223,7 @@ we will get the following buffer structure:
|
||||||
|
|
||||||
A frame can be of any size with the only condition it can fit in a block. A block
|
A frame can be of any size with the only condition it can fit in a block. A block
|
||||||
can only hold an integer number of frames, or in other words, a frame cannot
|
can only hold an integer number of frames, or in other words, a frame cannot
|
||||||
be spawned accross two blocks, so there are some details you have to take into
|
be spawned across two blocks, so there are some details you have to take into
|
||||||
account when choosing the frame_size. See "Mapping and use of the circular
|
account when choosing the frame_size. See "Mapping and use of the circular
|
||||||
buffer (ring)".
|
buffer (ring)".
|
||||||
|
|
||||||
|
|
|
@ -1,5 +1,5 @@
|
||||||
|
|
||||||
The "enviromental" rules for authors of any new tc actions are:
|
The "environmental" rules for authors of any new tc actions are:
|
||||||
|
|
||||||
1) If you stealeth or borroweth any packet thou shalt be branching
|
1) If you stealeth or borroweth any packet thou shalt be branching
|
||||||
from the righteous path and thou shalt cloneth.
|
from the righteous path and thou shalt cloneth.
|
||||||
|
@ -20,7 +20,7 @@ this way any action downstream can stomp on the packet.
|
||||||
3) Dropping packets you don't own is a no-no. You simply return
|
3) Dropping packets you don't own is a no-no. You simply return
|
||||||
TC_ACT_SHOT to the caller and they will drop it.
|
TC_ACT_SHOT to the caller and they will drop it.
|
||||||
|
|
||||||
The "enviromental" rules for callers of actions (qdiscs etc) are:
|
The "environmental" rules for callers of actions (qdiscs etc) are:
|
||||||
|
|
||||||
*) Thou art responsible for freeing anything returned as being
|
*) Thou art responsible for freeing anything returned as being
|
||||||
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
|
||||||
|
|
|
@ -367,7 +367,7 @@ Drivers need to be able to handle hardware which has been reset since the
|
||||||
suspend methods were called, for example by complete reinitialization.
|
suspend methods were called, for example by complete reinitialization.
|
||||||
This may be the hardest part, and the one most protected by NDA'd documents
|
This may be the hardest part, and the one most protected by NDA'd documents
|
||||||
and chip errata. It's simplest if the hardware state hasn't changed since
|
and chip errata. It's simplest if the hardware state hasn't changed since
|
||||||
the suspend was carried out, but that can't be guaranteed (in fact, it ususally
|
the suspend was carried out, but that can't be guaranteed (in fact, it usually
|
||||||
is not the case).
|
is not the case).
|
||||||
|
|
||||||
Drivers must also be prepared to notice that the device has been removed
|
Drivers must also be prepared to notice that the device has been removed
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue