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 commit 'v3.2-rc6' into perf/core
Merge reason: Update with the latest fixes. Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Ingo Molnar
@@ -206,16 +206,3 @@ Description:
|
||||
when a discarded area is read the discard_zeroes_data
|
||||
parameter will be set to one. Otherwise it will be 0 and
|
||||
the result of reading a discarded area is undefined.
|
||||
What: /sys/block/<disk>/alias
|
||||
Date: Aug 2011
|
||||
Contact: Nao Nishijima <nao.nishijima.xt@hitachi.com>
|
||||
Description:
|
||||
A raw device name of a disk does not always point a same disk
|
||||
each boot-up time. Therefore, users have to use persistent
|
||||
device names, which udev creates when the kernel finds a disk,
|
||||
instead of raw device name. However, kernel doesn't show those
|
||||
persistent names on its messages (e.g. dmesg).
|
||||
This file can store an alias of the disk and it would be
|
||||
appeared in kernel messages if it is set. A disk can have an
|
||||
alias which length is up to 255bytes. Users can use alphabets,
|
||||
numbers, "-" and "_" in alias name. This file is writeonce.
|
||||
|
||||
@@ -57,13 +57,6 @@ create_snap
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create
|
||||
|
||||
rollback_snap
|
||||
|
||||
Rolls back data to the specified snapshot. This goes over the entire
|
||||
list of rados blocks and sends a rollback command to each.
|
||||
|
||||
$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback
|
||||
|
||||
snap_*
|
||||
|
||||
A directory per each snapshot
|
||||
|
||||
@@ -520,6 +520,11 @@ Here's a description of the fields of <varname>struct uio_mem</varname>:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<varname>const char *name</varname>: Optional. Set this to help identify
|
||||
the memory region, it will show up in the corresponding sysfs node.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>int memtype</varname>: Required if the mapping is used. Set this to
|
||||
<varname>UIO_MEM_PHYS</varname> if you you have physical memory on your
|
||||
@@ -553,7 +558,7 @@ instead to remember such an address.
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Please do not touch the <varname>kobj</varname> element of
|
||||
Please do not touch the <varname>map</varname> element of
|
||||
<varname>struct uio_mem</varname>! It is used by the UIO framework
|
||||
to set up sysfs files for this mapping. Simply leave it alone.
|
||||
</para>
|
||||
|
||||
@@ -98,14 +98,12 @@ You must enable "SCSI tape drive support for Smart Array 5xxx" and
|
||||
"SCSI support" in your kernel configuration to be able to use SCSI
|
||||
tape drives with your Smart Array 5xxx controller.
|
||||
|
||||
Additionally, note that the driver will not engage the SCSI core at init
|
||||
time. The driver must be directed to dynamically engage the SCSI core via
|
||||
the /proc filesystem entry which the "block" side of the driver creates as
|
||||
/proc/driver/cciss/cciss* at runtime. This is because at driver init time,
|
||||
the SCSI core may not yet be initialized (because the driver is a block
|
||||
driver) and attempting to register it with the SCSI core in such a case
|
||||
would cause a hang. This is best done via an initialization script
|
||||
(typically in /etc/init.d, but could vary depending on distribution).
|
||||
Additionally, note that the driver will engage the SCSI core at init
|
||||
time if any tape drives or medium changers are detected. The driver may
|
||||
also be directed to dynamically engage the SCSI core via the /proc filesystem
|
||||
entry which the "block" side of the driver creates as
|
||||
/proc/driver/cciss/cciss* at runtime. This is best done via a script.
|
||||
|
||||
For example:
|
||||
|
||||
for x in /proc/driver/cciss/cciss[0-9]*
|
||||
|
||||
@@ -33,6 +33,7 @@ qcom Qualcomm, Inc.
|
||||
ramtron Ramtron International
|
||||
samsung Samsung Semiconductor
|
||||
schindler Schindler
|
||||
sil Silicon Image
|
||||
simtek
|
||||
sirf SiRF Technology, Inc.
|
||||
stericsson ST-Ericsson
|
||||
|
||||
@@ -63,8 +63,8 @@ IRC network.
|
||||
Userspace tools for creating and manipulating Btrfs file systems are
|
||||
available from the git repository at the following location:
|
||||
|
||||
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
|
||||
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
|
||||
|
||||
These include the following tools:
|
||||
|
||||
|
||||
@@ -1,22 +1,24 @@
|
||||
The I2C protocol knows about two kinds of device addresses: normal 7 bit
|
||||
addresses, and an extended set of 10 bit addresses. The sets of addresses
|
||||
do not intersect: the 7 bit address 0x10 is not the same as the 10 bit
|
||||
address 0x10 (though a single device could respond to both of them). You
|
||||
select a 10 bit address by adding an extra byte after the address
|
||||
byte:
|
||||
S Addr7 Rd/Wr ....
|
||||
becomes
|
||||
S 11110 Addr10 Rd/Wr
|
||||
S is the start bit, Rd/Wr the read/write bit, and if you count the number
|
||||
of bits, you will see the there are 8 after the S bit for 7 bit addresses,
|
||||
and 16 after the S bit for 10 bit addresses.
|
||||
address 0x10 (though a single device could respond to both of them).
|
||||
|
||||
WARNING! The current 10 bit address support is EXPERIMENTAL. There are
|
||||
several places in the code that will cause SEVERE PROBLEMS with 10 bit
|
||||
addresses, even though there is some basic handling and hooks. Also,
|
||||
almost no supported adapter handles the 10 bit addresses correctly.
|
||||
I2C messages to and from 10-bit address devices have a different format.
|
||||
See the I2C specification for the details.
|
||||
|
||||
As soon as a real 10 bit address device is spotted 'in the wild', we
|
||||
can and will add proper support. Right now, 10 bit address devices
|
||||
are defined by the I2C protocol, but we have never seen a single device
|
||||
which supports them.
|
||||
The current 10 bit address support is minimal. It should work, however
|
||||
you can expect some problems along the way:
|
||||
* Not all bus drivers support 10-bit addresses. Some don't because the
|
||||
hardware doesn't support them (SMBus doesn't require 10-bit address
|
||||
support for example), some don't because nobody bothered adding the
|
||||
code (or it's there but not working properly.) Software implementation
|
||||
(i2c-algo-bit) is known to work.
|
||||
* Some optional features do not support 10-bit addresses. This is the
|
||||
case of automatic detection and instantiation of devices by their,
|
||||
drivers, for example.
|
||||
* Many user-space packages (for example i2c-tools) lack support for
|
||||
10-bit addresses.
|
||||
|
||||
Note that 10-bit address devices are still pretty rare, so the limitations
|
||||
listed above could stay for a long time, maybe even forever if nobody
|
||||
needs them to be fixed.
|
||||
|
||||
@@ -315,12 +315,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
CPU-intensive style benchmark, and it can vary highly in
|
||||
a microbenchmark depending on workload and compiler.
|
||||
|
||||
1: only for 32-bit processes
|
||||
2: only for 64-bit processes
|
||||
32: only for 32-bit processes
|
||||
64: only for 64-bit processes
|
||||
on: enable for both 32- and 64-bit processes
|
||||
off: disable for both 32- and 64-bit processes
|
||||
|
||||
amd_iommu= [HW,X86-84]
|
||||
amd_iommu= [HW,X86-64]
|
||||
Pass parameters to the AMD IOMMU driver in the system.
|
||||
Possible values are:
|
||||
fullflush - enable flushing of IO/TLB entries when
|
||||
|
||||
@@ -20,7 +20,7 @@ ip_no_pmtu_disc - BOOLEAN
|
||||
default FALSE
|
||||
|
||||
min_pmtu - INTEGER
|
||||
default 562 - minimum discovered Path MTU
|
||||
default 552 - minimum discovered Path MTU
|
||||
|
||||
route/max_size - INTEGER
|
||||
Maximum number of routes allowed in the kernel. Increase
|
||||
@@ -282,11 +282,11 @@ tcp_max_ssthresh - INTEGER
|
||||
Default: 0 (off)
|
||||
|
||||
tcp_max_syn_backlog - INTEGER
|
||||
Maximal number of remembered connection requests, which are
|
||||
still did not receive an acknowledgment from connecting client.
|
||||
Default value is 1024 for systems with more than 128Mb of memory,
|
||||
and 128 for low memory machines. If server suffers of overload,
|
||||
try to increase this number.
|
||||
Maximal number of remembered connection requests, which have not
|
||||
received an acknowledgment from connecting client.
|
||||
The minimal value is 128 for low memory machines, and it will
|
||||
increase in proportion to the memory of machine.
|
||||
If server suffers from overload, try increasing this number.
|
||||
|
||||
tcp_max_tw_buckets - INTEGER
|
||||
Maximal number of timewait sockets held by system simultaneously.
|
||||
|
||||
@@ -123,9 +123,10 @@ please refer directly to the source code for more information about it.
|
||||
Subsystem-Level Methods
|
||||
-----------------------
|
||||
The core methods to suspend and resume devices reside in struct dev_pm_ops
|
||||
pointed to by the pm member of struct bus_type, struct device_type and
|
||||
struct class. They are mostly of interest to the people writing infrastructure
|
||||
for buses, like PCI or USB, or device type and device class drivers.
|
||||
pointed to by the ops member of struct dev_pm_domain, or by the pm member of
|
||||
struct bus_type, struct device_type and struct class. They are mostly of
|
||||
interest to the people writing infrastructure for platforms and buses, like PCI
|
||||
or USB, or device type and device class drivers.
|
||||
|
||||
Bus drivers implement these methods as appropriate for the hardware and the
|
||||
drivers using it; PCI works differently from USB, and so on. Not many people
|
||||
@@ -139,41 +140,57 @@ sequencing in the driver model tree.
|
||||
|
||||
/sys/devices/.../power/wakeup files
|
||||
-----------------------------------
|
||||
All devices in the driver model have two flags to control handling of wakeup
|
||||
events (hardware signals that can force the device and/or system out of a low
|
||||
power state). These flags are initialized by bus or device driver code using
|
||||
All device objects in the driver model contain fields that control the handling
|
||||
of system wakeup events (hardware signals that can force the system out of a
|
||||
sleep state). These fields are initialized by bus or device driver code using
|
||||
device_set_wakeup_capable() and device_set_wakeup_enable(), defined in
|
||||
include/linux/pm_wakeup.h.
|
||||
|
||||
The "can_wakeup" flag just records whether the device (and its driver) can
|
||||
The "power.can_wakeup" flag just records whether the device (and its driver) can
|
||||
physically support wakeup events. The device_set_wakeup_capable() routine
|
||||
affects this flag. The "should_wakeup" flag controls whether the device should
|
||||
try to use its wakeup mechanism. device_set_wakeup_enable() affects this flag;
|
||||
for the most part drivers should not change its value. The initial value of
|
||||
should_wakeup is supposed to be false for the majority of devices; the major
|
||||
exceptions are power buttons, keyboards, and Ethernet adapters whose WoL
|
||||
(wake-on-LAN) feature has been set up with ethtool. It should also default
|
||||
to true for devices that don't generate wakeup requests on their own but merely
|
||||
forward wakeup requests from one bus to another (like PCI bridges).
|
||||
affects this flag. The "power.wakeup" field is a pointer to an object of type
|
||||
struct wakeup_source used for controlling whether or not the device should use
|
||||
its system wakeup mechanism and for notifying the PM core of system wakeup
|
||||
events signaled by the device. This object is only present for wakeup-capable
|
||||
devices (i.e. devices whose "can_wakeup" flags are set) and is created (or
|
||||
removed) by device_set_wakeup_capable().
|
||||
|
||||
Whether or not a device is capable of issuing wakeup events is a hardware
|
||||
matter, and the kernel is responsible for keeping track of it. By contrast,
|
||||
whether or not a wakeup-capable device should issue wakeup events is a policy
|
||||
decision, and it is managed by user space through a sysfs attribute: the
|
||||
power/wakeup file. User space can write the strings "enabled" or "disabled" to
|
||||
set or clear the "should_wakeup" flag, respectively. This file is only present
|
||||
for wakeup-capable devices (i.e. devices whose "can_wakeup" flags are set)
|
||||
and is created (or removed) by device_set_wakeup_capable(). Reads from the
|
||||
file will return the corresponding string.
|
||||
"power/wakeup" file. User space can write the strings "enabled" or "disabled"
|
||||
to it to indicate whether or not, respectively, the device is supposed to signal
|
||||
system wakeup. This file is only present if the "power.wakeup" object exists
|
||||
for the given device and is created (or removed) along with that object, by
|
||||
device_set_wakeup_capable(). Reads from the file will return the corresponding
|
||||
string.
|
||||
|
||||
The device_may_wakeup() routine returns true only if both flags are set.
|
||||
The "power/wakeup" file is supposed to contain the "disabled" string initially
|
||||
for the majority of devices; the major exceptions are power buttons, keyboards,
|
||||
and Ethernet adapters whose WoL (wake-on-LAN) feature has been set up with
|
||||
ethtool. It should also default to "enabled" for devices that don't generate
|
||||
wakeup requests on their own but merely forward wakeup requests from one bus to
|
||||
another (like PCI Express ports).
|
||||
|
||||
The device_may_wakeup() routine returns true only if the "power.wakeup" object
|
||||
exists and the corresponding "power/wakeup" file contains the string "enabled".
|
||||
This information is used by subsystems, like the PCI bus type code, to see
|
||||
whether or not to enable the devices' wakeup mechanisms. If device wakeup
|
||||
mechanisms are enabled or disabled directly by drivers, they also should use
|
||||
device_may_wakeup() to decide what to do during a system sleep transition.
|
||||
However for runtime power management, wakeup events should be enabled whenever
|
||||
the device and driver both support them, regardless of the should_wakeup flag.
|
||||
Device drivers, however, are not supposed to call device_set_wakeup_enable()
|
||||
directly in any case.
|
||||
|
||||
It ought to be noted that system wakeup is conceptually different from "remote
|
||||
wakeup" used by runtime power management, although it may be supported by the
|
||||
same physical mechanism. Remote wakeup is a feature allowing devices in
|
||||
low-power states to trigger specific interrupts to signal conditions in which
|
||||
they should be put into the full-power state. Those interrupts may or may not
|
||||
be used to signal system wakeup events, depending on the hardware design. On
|
||||
some systems it is impossible to trigger them from system sleep states. In any
|
||||
case, remote wakeup should always be enabled for runtime power management for
|
||||
all devices and drivers that support it.
|
||||
|
||||
/sys/devices/.../power/control files
|
||||
------------------------------------
|
||||
@@ -249,20 +266,31 @@ for every device before the next phase begins. Not all busses or classes
|
||||
support all these callbacks and not all drivers use all the callbacks. The
|
||||
various phases always run after tasks have been frozen and before they are
|
||||
unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have
|
||||
been disabled (except for those marked with the IRQ_WAKEUP flag).
|
||||
been disabled (except for those marked with the IRQF_NO_SUSPEND flag).
|
||||
|
||||
All phases use bus, type, or class callbacks (that is, methods defined in
|
||||
dev->bus->pm, dev->type->pm, or dev->class->pm). These callbacks are mutually
|
||||
exclusive, so if the device type provides a struct dev_pm_ops object pointed to
|
||||
by its pm field (i.e. both dev->type and dev->type->pm are defined), the
|
||||
callbacks included in that object (i.e. dev->type->pm) will be used. Otherwise,
|
||||
if the class provides a struct dev_pm_ops object pointed to by its pm field
|
||||
(i.e. both dev->class and dev->class->pm are defined), the PM core will use the
|
||||
callbacks from that object (i.e. dev->class->pm). Finally, if the pm fields of
|
||||
both the device type and class objects are NULL (or those objects do not exist),
|
||||
the callbacks provided by the bus (that is, the callbacks from dev->bus->pm)
|
||||
will be used (this allows device types to override callbacks provided by bus
|
||||
types or classes if necessary).
|
||||
All phases use PM domain, bus, type, or class callbacks (that is, methods
|
||||
defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).
|
||||
These callbacks are regarded by the PM core as mutually exclusive. Moreover,
|
||||
PM domain callbacks always take precedence over bus, type and class callbacks,
|
||||
while type callbacks take precedence over bus and class callbacks, and class
|
||||
callbacks take precedence over bus callbacks. To be precise, the following
|
||||
rules are used to determine which callback to execute in the given phase:
|
||||
|
||||
1. If dev->pm_domain is present, the PM core will attempt to execute the
|
||||
callback included in dev->pm_domain->ops. If that callback is not
|
||||
present, no action will be carried out for the given device.
|
||||
|
||||
2. Otherwise, if both dev->type and dev->type->pm are present, the callback
|
||||
included in dev->type->pm will be executed.
|
||||
|
||||
3. Otherwise, if both dev->class and dev->class->pm are present, the
|
||||
callback included in dev->class->pm will be executed.
|
||||
|
||||
4. Otherwise, if both dev->bus and dev->bus->pm are present, the callback
|
||||
included in dev->bus->pm will be executed.
|
||||
|
||||
This allows PM domains and device types to override callbacks provided by bus
|
||||
types or device classes if necessary.
|
||||
|
||||
These callbacks may in turn invoke device- or driver-specific methods stored in
|
||||
dev->driver->pm, but they don't have to.
|
||||
@@ -283,9 +311,8 @@ When the system goes into the standby or memory sleep state, the phases are:
|
||||
|
||||
After the prepare callback method returns, no new children may be
|
||||
registered below the device. The method may also prepare the device or
|
||||
driver in some way for the upcoming system power transition (for
|
||||
example, by allocating additional memory required for this purpose), but
|
||||
it should not put the device into a low-power state.
|
||||
driver in some way for the upcoming system power transition, but it
|
||||
should not put the device into a low-power state.
|
||||
|
||||
2. The suspend methods should quiesce the device to stop it from performing
|
||||
I/O. They also may save the device registers and put it into the
|
||||
|
||||
@@ -44,25 +44,33 @@ struct dev_pm_ops {
|
||||
};
|
||||
|
||||
The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks
|
||||
are executed by the PM core for either the power domain, or the device type
|
||||
(if the device power domain's struct dev_pm_ops does not exist), or the class
|
||||
(if the device power domain's and type's struct dev_pm_ops object does not
|
||||
exist), or the bus type (if the device power domain's, type's and class'
|
||||
struct dev_pm_ops objects do not exist) of the given device, so the priority
|
||||
order of callbacks from high to low is that power domain callbacks, device
|
||||
type callbacks, class callbacks and bus type callbacks, and the high priority
|
||||
one will take precedence over low priority one. The bus type, device type and
|
||||
class callbacks are referred to as subsystem-level callbacks in what follows,
|
||||
and generally speaking, the power domain callbacks are used for representing
|
||||
power domains within a SoC.
|
||||
are executed by the PM core for the device's subsystem that may be either of
|
||||
the following:
|
||||
|
||||
1. PM domain of the device, if the device's PM domain object, dev->pm_domain,
|
||||
is present.
|
||||
|
||||
2. Device type of the device, if both dev->type and dev->type->pm are present.
|
||||
|
||||
3. Device class of the device, if both dev->class and dev->class->pm are
|
||||
present.
|
||||
|
||||
4. Bus type of the device, if both dev->bus and dev->bus->pm are present.
|
||||
|
||||
The PM core always checks which callback to use in the order given above, so the
|
||||
priority order of callbacks from high to low is: PM domain, device type, class
|
||||
and bus type. Moreover, the high-priority one will always take precedence over
|
||||
a low-priority one. The PM domain, bus type, device type and class callbacks
|
||||
are referred to as subsystem-level callbacks in what follows.
|
||||
|
||||
By default, the callbacks are always invoked in process context with interrupts
|
||||
enabled. However, subsystems can use the pm_runtime_irq_safe() helper function
|
||||
to tell the PM core that a device's ->runtime_suspend() and ->runtime_resume()
|
||||
callbacks should be invoked in atomic context with interrupts disabled.
|
||||
This implies that these callback routines must not block or sleep, but it also
|
||||
means that the synchronous helper functions listed at the end of Section 4 can
|
||||
be used within an interrupt handler or in an atomic context.
|
||||
to tell the PM core that their ->runtime_suspend(), ->runtime_resume() and
|
||||
->runtime_idle() callbacks may be invoked in atomic context with interrupts
|
||||
disabled for a given device. This implies that the callback routines in
|
||||
question must not block or sleep, but it also means that the synchronous helper
|
||||
functions listed at the end of Section 4 may be used for that device within an
|
||||
interrupt handler or generally in an atomic context.
|
||||
|
||||
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
|
||||
the suspend of the device as appropriate, which may, but need not include
|
||||
|
||||
@@ -97,15 +97,23 @@
|
||||
|
||||
struct serial_rs485 rs485conf;
|
||||
|
||||
/* Set RS485 mode: */
|
||||
/* Enable RS485 mode: */
|
||||
rs485conf.flags |= SER_RS485_ENABLED;
|
||||
|
||||
/* Set logical level for RTS pin equal to 1 when sending: */
|
||||
rs485conf.flags |= SER_RS485_RTS_ON_SEND;
|
||||
/* or, set logical level for RTS pin equal to 0 when sending: */
|
||||
rs485conf.flags &= ~(SER_RS485_RTS_ON_SEND);
|
||||
|
||||
/* Set logical level for RTS pin equal to 1 after sending: */
|
||||
rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
|
||||
/* or, set logical level for RTS pin equal to 0 after sending: */
|
||||
rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
|
||||
|
||||
/* Set rts delay before send, if needed: */
|
||||
rs485conf.flags |= SER_RS485_RTS_BEFORE_SEND;
|
||||
rs485conf.delay_rts_before_send = ...;
|
||||
|
||||
/* Set rts delay after send, if needed: */
|
||||
rs485conf.flags |= SER_RS485_RTS_AFTER_SEND;
|
||||
rs485conf.delay_rts_after_send = ...;
|
||||
|
||||
/* Set this flag if you want to receive data even whilst sending data */
|
||||
|
||||
@@ -579,7 +579,7 @@ Development Tree
|
||||
~~~~~~~~~~~~~~~~
|
||||
The latest development codes for HD-audio are found on sound git tree:
|
||||
|
||||
- git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
|
||||
- git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
||||
|
||||
The master branch or for-next branches can be used as the main
|
||||
development branches in general while the HD-audio specific patches
|
||||
@@ -594,7 +594,7 @@ is, installed via the usual spells: configure, make and make
|
||||
install(-modules). See INSTALL in the package. The snapshot tarballs
|
||||
are found at:
|
||||
|
||||
- ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/
|
||||
- ftp://ftp.suse.com/pub/people/tiwai/snapshot/
|
||||
|
||||
|
||||
Sending a Bug Report
|
||||
@@ -696,7 +696,7 @@ via hda-verb won't change the mixer value.
|
||||
|
||||
The hda-verb program is found in the ftp directory:
|
||||
|
||||
- ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/
|
||||
- ftp://ftp.suse.com/pub/people/tiwai/misc/
|
||||
|
||||
Also a git repository is available:
|
||||
|
||||
@@ -764,7 +764,7 @@ operation, the jack plugging simulation, etc.
|
||||
|
||||
The package is found in:
|
||||
|
||||
- ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/
|
||||
- ftp://ftp.suse.com/pub/people/tiwai/misc/
|
||||
|
||||
A git repository is available:
|
||||
|
||||
|
||||
@@ -50,8 +50,7 @@ Machine DAI Configuration
|
||||
The machine DAI configuration glues all the codec and CPU DAIs together. It can
|
||||
also be used to set up the DAI system clock and for any machine related DAI
|
||||
initialisation e.g. the machine audio map can be connected to the codec audio
|
||||
map, unconnected codec pins can be set as such. Please see corgi.c, spitz.c
|
||||
for examples.
|
||||
map, unconnected codec pins can be set as such.
|
||||
|
||||
struct snd_soc_dai_link is used to set up each DAI in your machine. e.g.
|
||||
|
||||
@@ -83,8 +82,7 @@ Machine Power Map
|
||||
The machine driver can optionally extend the codec power map and to become an
|
||||
audio power map of the audio subsystem. This allows for automatic power up/down
|
||||
of speaker/HP amplifiers, etc. Codec pins can be connected to the machines jack
|
||||
sockets in the machine init function. See soc/pxa/spitz.c and dapm.txt for
|
||||
details.
|
||||
sockets in the machine init function.
|
||||
|
||||
|
||||
Machine Controls
|
||||
|
||||
@@ -90,10 +90,10 @@ ServiceBinary=%12%\USBSER.sys
|
||||
[SourceDisksFiles]
|
||||
[SourceDisksNames]
|
||||
[DeviceList]
|
||||
%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02
|
||||
%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02, USB\VID_1D6B&PID_0106&MI_00
|
||||
|
||||
[DeviceList.NTamd64]
|
||||
%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02
|
||||
%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_1D6B&PID_0104&MI_02, USB\VID_1D6B&PID_0106&MI_00
|
||||
|
||||
|
||||
;------------------------------------------------------------------------------
|
||||
|
||||
Reference in New Issue
Block a user