You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
David S. Miller
@@ -130,8 +130,6 @@ edac.txt
|
||||
- information on EDAC - Error Detection And Correction
|
||||
eisa.txt
|
||||
- info on EISA bus support.
|
||||
exception.txt
|
||||
- how Linux v2.2 handles exceptions without verify_area etc.
|
||||
fault-injection/
|
||||
- dir with docs about the fault injection capabilities infrastructure.
|
||||
fb/
|
||||
@@ -234,6 +232,8 @@ memory.txt
|
||||
- info on typical Linux memory problems.
|
||||
mips/
|
||||
- directory with info about Linux on MIPS architecture.
|
||||
mmc/
|
||||
- directory with info about the MMC subsystem
|
||||
mono.txt
|
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
mutex-design.txt
|
||||
|
||||
@@ -1,71 +0,0 @@
|
||||
What: /sys/kernel/debug/kmemtrace/
|
||||
Date: July 2008
|
||||
Contact: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
|
||||
Description:
|
||||
|
||||
In kmemtrace-enabled kernels, the following files are created:
|
||||
|
||||
/sys/kernel/debug/kmemtrace/
|
||||
cpu<n> (0400) Per-CPU tracing data, see below. (binary)
|
||||
total_overruns (0400) Total number of bytes which were dropped from
|
||||
cpu<n> files because of full buffer condition,
|
||||
non-binary. (text)
|
||||
abi_version (0400) Kernel's kmemtrace ABI version. (text)
|
||||
|
||||
Each per-CPU file should be read according to the relay interface. That is,
|
||||
the reader should set affinity to that specific CPU and, as currently done by
|
||||
the userspace application (though there are other methods), use poll() with
|
||||
an infinite timeout before every read(). Otherwise, erroneous data may be
|
||||
read. The binary data has the following _core_ format:
|
||||
|
||||
Event ID (1 byte) Unsigned integer, one of:
|
||||
0 - represents an allocation (KMEMTRACE_EVENT_ALLOC)
|
||||
1 - represents a freeing of previously allocated memory
|
||||
(KMEMTRACE_EVENT_FREE)
|
||||
Type ID (1 byte) Unsigned integer, one of:
|
||||
0 - this is a kmalloc() / kfree()
|
||||
1 - this is a kmem_cache_alloc() / kmem_cache_free()
|
||||
2 - this is a __get_free_pages() et al.
|
||||
Event size (2 bytes) Unsigned integer representing the
|
||||
size of this event. Used to extend
|
||||
kmemtrace. Discard the bytes you
|
||||
don't know about.
|
||||
Sequence number (4 bytes) Signed integer used to reorder data
|
||||
logged on SMP machines. Wraparound
|
||||
must be taken into account, although
|
||||
it is unlikely.
|
||||
Caller address (8 bytes) Return address to the caller.
|
||||
Pointer to mem (8 bytes) Pointer to target memory area. Can be
|
||||
NULL, but not all such calls might be
|
||||
recorded.
|
||||
|
||||
In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow:
|
||||
|
||||
Requested bytes (8 bytes) Total number of requested bytes,
|
||||
unsigned, must not be zero.
|
||||
Allocated bytes (8 bytes) Total number of actually allocated
|
||||
bytes, unsigned, must not be lower
|
||||
than requested bytes.
|
||||
Requested flags (4 bytes) GFP flags supplied by the caller.
|
||||
Target CPU (4 bytes) Signed integer, valid for event id 1.
|
||||
If equal to -1, target CPU is the same
|
||||
as origin CPU, but the reverse might
|
||||
not be true.
|
||||
|
||||
The data is made available in the same endianness the machine has.
|
||||
|
||||
Other event ids and type ids may be defined and added. Other fields may be
|
||||
added by increasing event size, but see below for details.
|
||||
Every modification to the ABI, including new id definitions, are followed
|
||||
by bumping the ABI version by one.
|
||||
|
||||
Adding new data to the packet (features) is done at the end of the mandatory
|
||||
data:
|
||||
Feature size (2 byte)
|
||||
Feature ID (1 byte)
|
||||
Feature data (Feature size - 3 bytes)
|
||||
|
||||
|
||||
Users:
|
||||
kmemtrace-user - git://repo.or.cz/kmemtrace-user.git
|
||||
|
||||
@@ -0,0 +1,21 @@
|
||||
Where: /sys/bus/i2c/devices/.../heading0_input
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.36?
|
||||
Contact: alan.cox@intel.com
|
||||
Description: Reports the current heading from the compass as a floating
|
||||
point value in degrees.
|
||||
|
||||
Where: /sys/bus/i2c/devices/.../power_state
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.36?
|
||||
Contact: alan.cox@intel.com
|
||||
Description: Sets the power state of the device. 0 sets the device into
|
||||
sleep mode, 1 wakes it up.
|
||||
|
||||
Where: /sys/bus/i2c/devices/.../calibration
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.36?
|
||||
Contact: alan.cox@intel.com
|
||||
Description: Sets the calibration on or off (1 = on, 0 = off). See the
|
||||
chip data sheet.
|
||||
|
||||
@@ -139,3 +139,30 @@ Contact: linux-pci@vger.kernel.org
|
||||
Description:
|
||||
This symbolic link points to the PCI hotplug controller driver
|
||||
module that manages the hotplug slot.
|
||||
|
||||
What: /sys/bus/pci/devices/.../label
|
||||
Date: July 2010
|
||||
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
|
||||
Description:
|
||||
Reading this attribute will provide the firmware
|
||||
given name(SMBIOS type 41 string) of the PCI device.
|
||||
The attribute will be created only if the firmware
|
||||
has given a name to the PCI device.
|
||||
Users:
|
||||
Userspace applications interested in knowing the
|
||||
firmware assigned name of the PCI device.
|
||||
|
||||
What: /sys/bus/pci/devices/.../index
|
||||
Date: July 2010
|
||||
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
|
||||
Description:
|
||||
Reading this attribute will provide the firmware
|
||||
given instance(SMBIOS type 41 device type instance)
|
||||
of the PCI device. The attribute will be created
|
||||
only if the firmware has given a device type instance
|
||||
to the PCI device.
|
||||
Users:
|
||||
Userspace applications interested in knowing the
|
||||
firmware assigned device type instance of the PCI
|
||||
device that can help in understanding the firmware
|
||||
intended order of the PCI device.
|
||||
|
||||
@@ -7,3 +7,15 @@ Description:
|
||||
0 -> resumed
|
||||
|
||||
(_UDC_ is the name of the USB Device Controller driver)
|
||||
|
||||
What: /sys/devices/platform/_UDC_/gadget/gadget-lunX/nofua
|
||||
Date: July 2010
|
||||
Contact: Andy Shevchenko <andy.shevchenko@gmail.com>
|
||||
Description:
|
||||
Show or set the reaction on the FUA (Force Unit Access) bit in
|
||||
the SCSI WRITE(10,12) commands when a gadget in USB Mass
|
||||
Storage mode.
|
||||
|
||||
Possible values are:
|
||||
1 -> ignore the FUA flag
|
||||
0 -> obey the FUA flag
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
What: /sys/bus/i2c/devices/<busnum>-<devaddr>/pressure0_input
|
||||
Date: June 2010
|
||||
Contact: Christoph Mair <christoph.mair@gmail.com>
|
||||
Description: Start a pressure measurement and read the result. Values
|
||||
represent the ambient air pressure in pascal (0.01 millibar).
|
||||
|
||||
Reading: returns the current air pressure.
|
||||
|
||||
|
||||
What: /sys/bus/i2c/devices/<busnum>-<devaddr>/temp0_input
|
||||
Date: June 2010
|
||||
Contact: Christoph Mair <christoph.mair@gmail.com>
|
||||
Description: Measure the ambient temperature. The returned value represents
|
||||
the ambient temperature in units of 0.1 degree celsius.
|
||||
|
||||
Reading: returns the current temperature.
|
||||
|
||||
|
||||
What: /sys/bus/i2c/devices/<busnum>-<devaddr>/oversampling
|
||||
Date: June 2010
|
||||
Contact: Christoph Mair <christoph.mair@gmail.com>
|
||||
Description: Tell the bmp085 to use more samples to calculate a pressure
|
||||
value. When writing to this file the chip will use 2^x samples
|
||||
to calculate the next pressure value with x being the value
|
||||
written. Using this feature will decrease RMS noise and
|
||||
increase the measurement time.
|
||||
|
||||
Reading: returns the current oversampling setting.
|
||||
|
||||
Writing: sets a new oversampling setting.
|
||||
Accepted values: 0..3.
|
||||
@@ -738,21 +738,31 @@ to "Closing".
|
||||
CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs
|
||||
(including software IOMMU).
|
||||
|
||||
2) ARCH_KMALLOC_MINALIGN
|
||||
2) ARCH_DMA_MINALIGN
|
||||
|
||||
Architectures must ensure that kmalloc'ed buffer is
|
||||
DMA-safe. Drivers and subsystems depend on it. If an architecture
|
||||
isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in
|
||||
the CPU cache is identical to data in main memory),
|
||||
ARCH_KMALLOC_MINALIGN must be set so that the memory allocator
|
||||
ARCH_DMA_MINALIGN must be set so that the memory allocator
|
||||
makes sure that kmalloc'ed buffer doesn't share a cache line with
|
||||
the others. See arch/arm/include/asm/cache.h as an example.
|
||||
|
||||
Note that ARCH_KMALLOC_MINALIGN is about DMA memory alignment
|
||||
Note that ARCH_DMA_MINALIGN is about DMA memory alignment
|
||||
constraints. You don't need to worry about the architecture data
|
||||
alignment constraints (e.g. the alignment constraints about 64-bit
|
||||
objects).
|
||||
|
||||
3) Supporting multiple types of IOMMUs
|
||||
|
||||
If your architecture needs to support multiple types of IOMMUs, you
|
||||
can use include/linux/asm-generic/dma-mapping-common.h. It's a
|
||||
library to support the DMA API with multiple types of IOMMUs. Lots
|
||||
of architectures (x86, powerpc, sh, alpha, ia64, microblaze and
|
||||
sparc) use it. Choose one to see how it can be used. If you need to
|
||||
support multiple types of IOMMUs in a single system, the example of
|
||||
x86 or powerpc helps.
|
||||
|
||||
Closing
|
||||
|
||||
This document, and the API itself, would not be in its current
|
||||
|
||||
@@ -455,12 +455,6 @@ Free memory allocated by the nonconsistent API. All parameters must
|
||||
be identical to those passed in (and returned by
|
||||
dma_alloc_noncoherent()).
|
||||
|
||||
int
|
||||
dma_is_consistent(struct device *dev, dma_addr_t dma_handle)
|
||||
|
||||
Returns true if the device dev is performing consistent DMA on the memory
|
||||
area pointed to by the dma_handle.
|
||||
|
||||
int
|
||||
dma_get_cache_alignment(void)
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ PS_METHOD = $(prefer-db2x)
|
||||
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks
|
||||
|
||||
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
|
||||
xmldocs: $(BOOKS) xmldoclinks
|
||||
xmldocs: $(BOOKS)
|
||||
sgmldocs: xmldocs
|
||||
|
||||
PS := $(patsubst %.xml, %.ps, $(BOOKS))
|
||||
@@ -45,7 +45,7 @@ PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
|
||||
pdfdocs: $(PDF)
|
||||
|
||||
HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
|
||||
htmldocs: $(HTML)
|
||||
htmldocs: $(HTML) xmldoclinks
|
||||
$(call build_main_index)
|
||||
$(call build_images)
|
||||
|
||||
@@ -95,7 +95,7 @@ define rule_docproc
|
||||
) > $(dir $@).$(notdir $@).cmd
|
||||
endef
|
||||
|
||||
%.xml: %.tmpl FORCE
|
||||
%.xml: %.tmpl xmldoclinks FORCE
|
||||
$(call if_changed_rule,docproc)
|
||||
|
||||
###
|
||||
|
||||
@@ -111,6 +111,7 @@ X!Edrivers/base/attribute_container.c
|
||||
<!--
|
||||
X!Edrivers/base/interface.c
|
||||
-->
|
||||
!Iinclude/linux/platform_device.h
|
||||
!Edrivers/base/platform.c
|
||||
!Edrivers/base/bus.c
|
||||
</sect1>
|
||||
|
||||
@@ -132,7 +132,6 @@ X!Ilib/string.c
|
||||
<title>FIFO Buffer</title>
|
||||
<sect1><title>kfifo interface</title>
|
||||
!Iinclude/linux/kfifo.h
|
||||
!Ekernel/kfifo.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
||||
@@ -1922,9 +1922,12 @@ machines due to caching.
|
||||
<function>mutex_lock()</function>
|
||||
</para>
|
||||
<para>
|
||||
There is a <function>mutex_trylock()</function> which can be
|
||||
used inside interrupt context, as it will not sleep.
|
||||
There is a <function>mutex_trylock()</function> which does not
|
||||
sleep. Still, it must not be used inside interrupt context since
|
||||
its implementation is not safe for that.
|
||||
<function>mutex_unlock()</function> will also never sleep.
|
||||
It cannot be used in interrupt context either since a mutex
|
||||
must be released by the same task that acquired it.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
@@ -199,10 +199,33 @@
|
||||
may be configured as a kernel built-in or a kernel loadable module.
|
||||
You can only make use of <constant>kgdbwait</constant> and early
|
||||
debugging if you build kgdboc into the kernel as a built-in.
|
||||
<para>Optionally you can elect to activate kms (Kernel Mode
|
||||
Setting) integration. When you use kms with kgdboc and you have a
|
||||
video driver that has atomic mode setting hooks, it is possible to
|
||||
enter the debugger on the graphics console. When the kernel
|
||||
execution is resumed, the previous graphics mode will be restored.
|
||||
This integration can serve as a useful tool to aid in diagnosing
|
||||
crashes or doing analysis of memory with kdb while allowing the
|
||||
full graphics console applications to run.
|
||||
</para>
|
||||
</para>
|
||||
<sect2 id="kgdbocArgs">
|
||||
<title>kgdboc arguments</title>
|
||||
<para>Usage: <constant>kgdboc=[kbd][[,]serial_device][,baud]</constant></para>
|
||||
<para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para>
|
||||
<para>The order listed above must be observed if you use any of the
|
||||
optional configurations together.
|
||||
</para>
|
||||
<para>Abbreviations:
|
||||
<itemizedlist>
|
||||
<listitem><para>kms = Kernel Mode Setting</para></listitem>
|
||||
<listitem><para>kbd = Keyboard</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
||||
device depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios. The order listed above must be observed if
|
||||
you use any of the optional configurations together. Using kms +
|
||||
only gdb is generally not a useful combination.</para>
|
||||
<sect3 id="kgdbocArgs1">
|
||||
<title>Using loadable module or built-in</title>
|
||||
<para>
|
||||
@@ -212,7 +235,7 @@
|
||||
<listitem>
|
||||
<para>As a kernel loadable module:</para>
|
||||
<para>Use the command: <constant>modprobe kgdboc kgdboc=<tty-device>,[baud]</constant></para>
|
||||
<para>Here are two examples of how you might formate the kgdboc
|
||||
<para>Here are two examples of how you might format the kgdboc
|
||||
string. The first is for an x86 target using the first serial port.
|
||||
The second example is for the ARM Versatile AB using the second
|
||||
serial port.
|
||||
@@ -240,6 +263,9 @@
|
||||
</sect3>
|
||||
<sect3 id="kgdbocArgs3">
|
||||
<title>More examples</title>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial
|
||||
device depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios.</para>
|
||||
<para>You can configure kgdboc to use the keyboard, and or a serial device
|
||||
depending on if you are using kdb and or kgdb, in one of the
|
||||
following scenarios.
|
||||
@@ -255,6 +281,12 @@
|
||||
<listitem><para>kdb with a keyboard</para>
|
||||
<para><constant>kgdboc=kbd</constant></para>
|
||||
</listitem>
|
||||
<listitem><para>kdb with kernel mode setting</para>
|
||||
<para><constant>kgdboc=kms,kbd</constant></para>
|
||||
</listitem>
|
||||
<listitem><para>kdb with kernel mode setting and kgdb over a serial port</para>
|
||||
<para><constant>kgdboc=kms,kbd,ttyS0,115200</constant></para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
</sect3>
|
||||
@@ -637,6 +669,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
<listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem>
|
||||
<listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem>
|
||||
<listitem><para>The API to invoke either the kdb or kgdb frontend to the debug core.</para></listitem>
|
||||
<listitem><para>The structures and callback API for atomic kernel mode setting.</para>
|
||||
<para>NOTE: kgdboc is where the kms callbacks are invoked.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</listitem>
|
||||
@@ -747,6 +781,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
</sect1>
|
||||
<sect1 id="kgdbocDesign">
|
||||
<title>kgdboc internals</title>
|
||||
<sect2>
|
||||
<title>kgdboc and uarts</title>
|
||||
<para>
|
||||
The kgdboc driver is actually a very thin driver that relies on the
|
||||
underlying low level to the hardware driver having "polling hooks"
|
||||
@@ -754,11 +790,8 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
implementation of kgdboc it the serial_core was changed to expose a
|
||||
low level UART hook for doing polled mode reading and writing of a
|
||||
single character while in an atomic context. When kgdb makes an I/O
|
||||
request to the debugger, kgdboc invokes a call back in the serial
|
||||
core which in turn uses the call back in the UART driver. It is
|
||||
certainly possible to extend kgdboc to work with non-UART based
|
||||
consoles in the future.
|
||||
</para>
|
||||
request to the debugger, kgdboc invokes a callback in the serial
|
||||
core which in turn uses the callback in the UART driver.</para>
|
||||
<para>
|
||||
When using kgdboc with a UART, the UART driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting>
|
||||
#ifdef CONFIG_CONSOLE_POLL
|
||||
@@ -772,9 +805,68 @@ Task Addr Pid Parent [*] cpu State Thread Command
|
||||
that they can be called from an atomic context and have to restore
|
||||
the state of the UART chip on return such that the system can return
|
||||
to normal when the debugger detaches. You need to be very careful
|
||||
with any kind of lock you consider, because failing here is most
|
||||
with any kind of lock you consider, because failing here is most likely
|
||||
going to mean pressing the reset button.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="kgdbocKbd">
|
||||
<title>kgdboc and keyboards</title>
|
||||
<para>The kgdboc driver contains logic to configure communications
|
||||
with an attached keyboard. The keyboard infrastructure is only
|
||||
compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the
|
||||
kernel configuration.</para>
|
||||
<para>The core polled keyboard driver driver for PS/2 type keyboards
|
||||
is in drivers/char/kdb_keyboard.c. This driver is hooked into the
|
||||
debug core when kgdboc populates the callback in the array
|
||||
called <constant>kdb_poll_funcs[]</constant>. The
|
||||
kdb_get_kbd_char() is the top-level function which polls hardware
|
||||
for single character input.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="kgdbocKms">
|
||||
<title>kgdboc and kms</title>
|
||||
<para>The kgdboc driver contains logic to request the graphics
|
||||
display to switch to a text context when you are using
|
||||
"kgdboc=kms,kbd", provided that you have a video driver which has a
|
||||
frame buffer console and atomic kernel mode setting support.</para>
|
||||
<para>
|
||||
Every time the kernel
|
||||
debugger is entered it calls kgdboc_pre_exp_handler() which in turn
|
||||
calls con_debug_enter() in the virtual console layer. On resuming kernel
|
||||
execution, the kernel debugger calls kgdboc_post_exp_handler() which
|
||||
in turn calls con_debug_leave().</para>
|
||||
<para>Any video driver that wants to be compatible with the kernel
|
||||
debugger and the atomic kms callbacks must implement the
|
||||
mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations.
|
||||
For the fb_debug_enter and fb_debug_leave the option exists to use
|
||||
the generic drm fb helper functions or implement something custom for
|
||||
the hardware. The following example shows the initialization of the
|
||||
.mode_set_base_atomic operation in
|
||||
drivers/gpu/drm/i915/intel_display.c:
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
static const struct drm_crtc_helper_funcs intel_helper_funcs = {
|
||||
[...]
|
||||
.mode_set_base_atomic = intel_pipe_set_base_atomic,
|
||||
[...]
|
||||
};
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
<para>Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in
|
||||
drivers/gpu/drm/i915/intel_fb.c:
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
static struct fb_ops intelfb_ops = {
|
||||
[...]
|
||||
.fb_debug_enter = drm_fb_helper_debug_enter,
|
||||
.fb_debug_leave = drm_fb_helper_debug_leave,
|
||||
[...]
|
||||
};
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id="credits">
|
||||
|
||||
@@ -6,4 +6,5 @@
|
||||
<param name="callout.graphics">0</param>
|
||||
<!-- <param name="paper.type">A4</param> -->
|
||||
<param name="generate.section.toc.level">2</param>
|
||||
<param name="use.id.as.filename">1</param>
|
||||
</stylesheet>
|
||||
|
||||
@@ -104,4 +104,9 @@
|
||||
<title>Block IO</title>
|
||||
!Iinclude/trace/events/block.h
|
||||
</chapter>
|
||||
|
||||
<chapter id="workqueue">
|
||||
<title>Workqueue</title>
|
||||
!Iinclude/trace/events/workqueue.h
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
@@ -229,6 +229,22 @@ on working with the default settings initially.</para>
|
||||
and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>LIRC_SET_WIDEBAND_RECEIVER</term>
|
||||
<listitem>
|
||||
<para>Some receivers are equipped with special wide band receiver which is intended
|
||||
to be used to learn output of existing remote.
|
||||
Calling that ioctl with (1) will enable it, and with (0) disable it.
|
||||
This might be useful of receivers that have otherwise narrow band receiver
|
||||
that prevents them to be used with some remotes.
|
||||
Wide band receiver might also be more precise
|
||||
On the other hand its disadvantage it usually reduced range of reception.
|
||||
Note: wide band receiver might be implictly enabled if you enable
|
||||
carrier reports. In that case it will be disabled as soon as you disable
|
||||
carrier reports. Trying to disable wide band receiver while carrier
|
||||
reports are active will do nothing.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</section>
|
||||
|
||||
@@ -240,6 +240,45 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR24">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
|
||||
<entry>'BGR3'</entry>
|
||||
@@ -700,6 +739,45 @@ defined in error. Drivers may interpret them as in <xref
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
</row>
|
||||
<row id="V4L2-PIX-FMT-BGR666">
|
||||
<entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
|
||||
<entry>'BGRH'</entry>
|
||||
<entry></entry>
|
||||
<entry>b<subscript>5</subscript></entry>
|
||||
<entry>b<subscript>4</subscript></entry>
|
||||
<entry>b<subscript>3</subscript></entry>
|
||||
<entry>b<subscript>2</subscript></entry>
|
||||
<entry>b<subscript>1</subscript></entry>
|
||||
<entry>b<subscript>0</subscript></entry>
|
||||
<entry>g<subscript>5</subscript></entry>
|
||||
<entry>g<subscript>4</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>g<subscript>3</subscript></entry>
|
||||
<entry>g<subscript>2</subscript></entry>
|
||||
<entry>g<subscript>1</subscript></entry>
|
||||
<entry>g<subscript>0</subscript></entry>
|
||||
<entry>r<subscript>5</subscript></entry>
|
||||
<entry>r<subscript>4</subscript></entry>
|
||||
<entry>r<subscript>3</subscript></entry>
|
||||
<entry>r<subscript>2</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry>r<subscript>1</subscript></entry>
|
||||
<entry>r<subscript>0</subscript></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
<entry></entry>
|
||||
</row>
|
||||
<row><!-- id="V4L2-PIX-FMT-BGR24" -->
|
||||
<entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
|
||||
<entry>'BGR3'</entry>
|
||||
|
||||
@@ -98,6 +98,17 @@ system, git, as a "commit log". See #15, below.
|
||||
If your description starts to get long, that's a sign that you probably
|
||||
need to split up your patch. See #3, next.
|
||||
|
||||
When you submit or resubmit a patch or patch series, include the
|
||||
complete patch description and justification for it. Don't just
|
||||
say that this is version N of the patch (series). Don't expect the
|
||||
patch merger to refer back to earlier patch versions or referenced
|
||||
URLs to find the patch description and put that into the patch.
|
||||
I.e., the patch (series) and its description should be self-contained.
|
||||
This benefits both the patch merger(s) and reviewers. Some reviewers
|
||||
probably didn't even receive earlier versions of the patch.
|
||||
|
||||
If the patch fixes a logged bug entry, refer to that bug entry by
|
||||
number and URL.
|
||||
|
||||
|
||||
3) Separate your changes.
|
||||
|
||||
@@ -19,6 +19,8 @@ Note: Only ACPI METHOD can be overridden, any other object types like
|
||||
"Device", "OperationRegion", are not recognized.
|
||||
Note: The same ACPI control method can be overridden for many times,
|
||||
and it's always the latest one that used by Linux/kernel.
|
||||
Note: To get the ACPI debug object output (Store (AAAA, Debug)),
|
||||
please run "echo 1 > /sys/module/acpi/parameters/aml_debug_output".
|
||||
|
||||
1. override an existing method
|
||||
a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT,
|
||||
|
||||
@@ -1,11 +1,8 @@
|
||||
00-INDEX
|
||||
- This file
|
||||
|
||||
cachefeatures.txt
|
||||
- Supported cache features.
|
||||
|
||||
Filesystems
|
||||
- Requirements for mounting the root file system.
|
||||
|
||||
bfin-gpio-note.txt
|
||||
bfin-gpio-notes.txt
|
||||
- Notes in developing/using bfin-gpio driver.
|
||||
|
||||
bfin-spi-notes.txt
|
||||
- Notes for using bfin spi bus driver.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user