mirror of
https://github.com/Dasharo/linux.git
synced 2026-03-06 15:25:10 -08:00
Merge branch 'master'; commit 'v2.6.39-rc3' into next
This commit is contained in:
6
CREDITS
6
CREDITS
@@ -1677,7 +1677,7 @@ W: http://www.codemonkey.org.uk
|
||||
D: Assorted VIA x86 support.
|
||||
D: 2.5 AGPGART overhaul.
|
||||
D: CPUFREQ maintenance.
|
||||
D: Fedora kernel maintainence.
|
||||
D: Fedora kernel maintenance.
|
||||
D: Misc/Other.
|
||||
S: 314 Littleton Rd, Westford, MA 01886, USA
|
||||
|
||||
@@ -3211,7 +3211,7 @@ N: James Simmons
|
||||
E: jsimmons@infradead.org
|
||||
E: jsimmons@users.sf.net
|
||||
D: Frame buffer device maintainer
|
||||
D: input layer developement
|
||||
D: input layer development
|
||||
D: tty/console layer
|
||||
D: various mipsel devices
|
||||
S: 115 Carmel Avenue
|
||||
@@ -3290,7 +3290,7 @@ S: USA
|
||||
N: Manfred Spraul
|
||||
E: manfred@colorfullife.com
|
||||
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.
|
||||
S: 71701 Schwieberdingen
|
||||
S: Germany
|
||||
|
||||
@@ -206,8 +206,8 @@ laptops/
|
||||
- directory with laptop related info and laptop driver documentation.
|
||||
ldm.txt
|
||||
- a brief description of LDM (Windows Dynamic Disks).
|
||||
leds-class.txt
|
||||
- documents LED handling under Linux.
|
||||
leds/
|
||||
- directory with info about LED handling under Linux.
|
||||
local_ops.txt
|
||||
- semantics and behavior of local atomic operations.
|
||||
lockdep-design.txt
|
||||
|
||||
@@ -29,7 +29,7 @@ Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
|
||||
linux-s390@vger.kernel.org
|
||||
Description: Contains the PIM/PAM/POM values, as reported by the
|
||||
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).
|
||||
Note: This is an I/O-subchannel specific attribute.
|
||||
Users: s390-tools, HAL
|
||||
|
||||
@@ -33,5 +33,5 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Invert the LED on/off state. This parameter is specific to
|
||||
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.
|
||||
|
||||
@@ -40,7 +40,7 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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
|
||||
effects.
|
||||
When read, these files return the respective profile. The
|
||||
|
||||
@@ -33,7 +33,7 @@ Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 77 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
@@ -47,7 +47,7 @@ Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 77 bytes in size.
|
||||
This file is readonly.
|
||||
@@ -58,7 +58,7 @@ Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
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>
|
||||
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.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 43 bytes in size.
|
||||
|
||||
@@ -52,7 +52,7 @@ Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 23 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
@@ -66,7 +66,7 @@ Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 23 bytes in size.
|
||||
This file is readonly.
|
||||
@@ -77,7 +77,7 @@ Date: January 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
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>
|
||||
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.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 16 bytes in size.
|
||||
|
||||
@@ -39,7 +39,7 @@ Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
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>
|
||||
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.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
profile_settings holds information like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 13 bytes in size.
|
||||
@@ -66,7 +66,7 @@ Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 19 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
@@ -80,7 +80,7 @@ Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
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.
|
||||
profile_buttons holds informations about button layout.
|
||||
profile_buttons holds information about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 19 bytes in size.
|
||||
This file is readonly.
|
||||
|
||||
@@ -27,7 +27,7 @@ KernelVersion: 2.6.20
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
Description:
|
||||
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 :
|
||||
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
|
||||
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>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
|
||||
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">
|
||||
<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
|
||||
be switched consistently to the DiSEqC commands as described in the DiSEqC
|
||||
spec.</para>
|
||||
|
||||
@@ -1763,7 +1763,7 @@ as it would be on UP.
|
||||
There is a furthur optimization possible here: remember our original
|
||||
cache code, where there were no reference counts and the caller simply
|
||||
held the lock whenever using the object? This is still possible: if
|
||||
you hold the lock, noone can delete the object, so you don't need to
|
||||
you hold the lock, no one can delete the object, so you don't need to
|
||||
get and put the reference count.
|
||||
</para>
|
||||
|
||||
|
||||
@@ -1032,7 +1032,7 @@ and other resources, etc.
|
||||
<listitem>
|
||||
<para>
|
||||
This is indicated by ICRC bit in the ERROR register and
|
||||
means that corruption occurred during data transfer. Upto
|
||||
means that corruption occurred during data transfer. Up to
|
||||
ATA/ATAPI-7, the standard specifies that this bit is only
|
||||
applicable to UDMA transfers but ATA/ATAPI-8 draft revision
|
||||
1f says that the bit may be applicable to multiword DMA and
|
||||
@@ -1045,10 +1045,10 @@ and other resources, etc.
|
||||
<term>ABRT error during data transfer or on completion</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Upto ATA/ATAPI-7, the standard specifies that ABRT could be
|
||||
Up to ATA/ATAPI-7, the standard specifies that ABRT could be
|
||||
set on ICRC errors and on cases where a device is not able
|
||||
to complete a command. Combined with the fact that MWDMA
|
||||
and PIO transfer errors aren't allowed to use ICRC bit upto
|
||||
and PIO transfer errors aren't allowed to use ICRC bit up to
|
||||
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
|
||||
indicate tranfer errors.
|
||||
</para>
|
||||
@@ -1122,7 +1122,7 @@ and other resources, etc.
|
||||
<para>
|
||||
Depending on commands, not all STATUS/ERROR bits are
|
||||
applicable. These non-applicable bits are marked with
|
||||
"na" in the output descriptions but upto ATA/ATAPI-7
|
||||
"na" in the output descriptions but up to ATA/ATAPI-7
|
||||
no definition of "na" can be found. However,
|
||||
ATA/ATAPI-8 draft revision 1f describes "N/A" as
|
||||
follows.
|
||||
@@ -1507,7 +1507,7 @@ and other resources, etc.
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
|
||||
CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
||||
@@ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
Reed-Solomon library.
|
||||
</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
|
||||
is contrary to the usual layout used by software ECC. The
|
||||
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
|
||||
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
|
||||
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>
|
||||
<listitem><para>Table creation</para>
|
||||
<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>
|
||||
<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
|
||||
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
|
||||
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
|
||||
@@ -1060,19 +1060,19 @@ data in this page</entry>
|
||||
<row>
|
||||
<entry>0x3D</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>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0x3E</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>
|
||||
</row>
|
||||
<row>
|
||||
<entry>0x3F</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>
|
||||
</row>
|
||||
</tbody></tgroup></informaltable>
|
||||
|
||||
@@ -267,8 +267,8 @@
|
||||
<sect1 id="machine-constraint">
|
||||
<title>Constraints</title>
|
||||
<para>
|
||||
As well as definining the connections the machine interface
|
||||
also provides constraints definining the operations that
|
||||
As well as defining the connections the machine interface
|
||||
also provides constraints defining the operations that
|
||||
clients are allowed to perform and the parameters that may be
|
||||
set. This is required since generally regulator devices will
|
||||
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
|
||||
starts working and will generate an interrupt as soon
|
||||
as it's finished, has some data available, or needs your
|
||||
attention because an error occured.
|
||||
attention because an error occurred.
|
||||
</para>
|
||||
<para>
|
||||
<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>
|
||||
This request lets kernel drivers talk to user mode code
|
||||
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
|
||||
device special file should be 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
|
||||
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" />.
|
||||
</para>
|
||||
|
||||
|
||||
@@ -1243,7 +1243,7 @@ values are:</entry>
|
||||
</row><row><entry spanname="descr">Mutes the audio when
|
||||
capturing. This is not done by muting audio hardware, which can still
|
||||
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><entry></entry></row>
|
||||
<row id="v4l2-mpeg-video-encoding">
|
||||
|
||||
@@ -90,7 +90,7 @@
|
||||
processing hardware.</para>
|
||||
|
||||
<figure id="pipeline-scaling">
|
||||
<title>Image Format Negotation on Pipelines</title>
|
||||
<title>Image Format Negotiation on Pipelines</title>
|
||||
<mediaobject>
|
||||
<imageobject>
|
||||
<imagedata fileref="pipeline.pdf" format="PS" />
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user