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 /home/davem/src/GIT/linux-2.6/
This commit is contained in:
David S. Miller
@@ -27,6 +27,7 @@
|
||||
*.gz
|
||||
*.lzma
|
||||
*.patch
|
||||
*.gcno
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
|
||||
@@ -2006,6 +2006,9 @@ E: paul@laufernet.com
|
||||
D: Soundblaster driver fixes, ISAPnP quirk
|
||||
S: California, USA
|
||||
|
||||
N: Jonathan Layes
|
||||
D: ARPD support
|
||||
|
||||
N: Tom Lees
|
||||
E: tom@lpsg.demon.co.uk
|
||||
W: http://www.lpsg.demon.co.uk/
|
||||
@@ -3802,6 +3805,9 @@ S: van Bronckhorststraat 12
|
||||
S: 2612 XV Delft
|
||||
S: The Netherlands
|
||||
|
||||
N: Thomas Woller
|
||||
D: CS461x Cirrus Logic sound driver
|
||||
|
||||
N: David Woodhouse
|
||||
E: dwmw2@infradead.org
|
||||
D: JFFS2 file system, Memory Technology Device subsystem,
|
||||
|
||||
@@ -94,28 +94,37 @@ What: /sys/block/<disk>/queue/physical_block_size
|
||||
Date: May 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
This is the smallest unit the storage device can write
|
||||
without resorting to read-modify-write operation. It is
|
||||
usually the same as the logical block size but may be
|
||||
bigger. One example is SATA drives with 4KB sectors
|
||||
that expose a 512-byte logical block size to the
|
||||
operating system.
|
||||
This is the smallest unit a physical storage device can
|
||||
write atomically. It is usually the same as the logical
|
||||
block size but may be bigger. One example is SATA
|
||||
drives with 4KB sectors that expose a 512-byte logical
|
||||
block size to the operating system. For stacked block
|
||||
devices the physical_block_size variable contains the
|
||||
maximum physical_block_size of the component devices.
|
||||
|
||||
What: /sys/block/<disk>/queue/minimum_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report a preferred minimum I/O size,
|
||||
which is the smallest request the device can perform
|
||||
without incurring a read-modify-write penalty. For disk
|
||||
drives this is often the physical block size. For RAID
|
||||
arrays it is often the stripe chunk size.
|
||||
Storage devices may report a granularity or preferred
|
||||
minimum I/O size which is the smallest request the
|
||||
device can perform without incurring a performance
|
||||
penalty. For disk drives this is often the physical
|
||||
block size. For RAID arrays it is often the stripe
|
||||
chunk size. A properly aligned multiple of
|
||||
minimum_io_size is the preferred request size for
|
||||
workloads where a high number of I/O operations is
|
||||
desired.
|
||||
|
||||
What: /sys/block/<disk>/queue/optimal_io_size
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
Description:
|
||||
Storage devices may report an optimal I/O size, which is
|
||||
the device's preferred unit of receiving I/O. This is
|
||||
rarely reported for disk drives. For RAID devices it is
|
||||
usually the stripe width or the internal block size.
|
||||
the device's preferred unit for sustained I/O. This is
|
||||
rarely reported for disk drives. For RAID arrays it is
|
||||
usually the stripe width or the internal track size. A
|
||||
properly aligned multiple of optimal_io_size is the
|
||||
preferred request size for workloads where sustained
|
||||
throughput is desired. If no optimal I/O size is
|
||||
reported this file contains 0.
|
||||
|
||||
@@ -21,6 +21,8 @@ ffff8000 ffffffff copy_user_page / clear_user_page use.
|
||||
For SA11xx and Xscale, this is used to
|
||||
setup a minicache mapping.
|
||||
|
||||
ffff4000 ffffffff cache aliasing on ARMv6 and later CPUs.
|
||||
|
||||
ffff1000 ffff7fff Reserved.
|
||||
Platforms must not use this address range.
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ encouraged them to allow separation of the data and integrity metadata
|
||||
scatter-gather lists.
|
||||
|
||||
The controller will interleave the buffers on write and split them on
|
||||
read. This means that the Linux can DMA the data buffers to and from
|
||||
read. This means that Linux can DMA the data buffers to and from
|
||||
host memory without changes to the page cache.
|
||||
|
||||
Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs
|
||||
@@ -66,7 +66,7 @@ software RAID5).
|
||||
|
||||
The IP checksum is weaker than the CRC in terms of detecting bit
|
||||
errors. However, the strength is really in the separation of the data
|
||||
buffers and the integrity metadata. These two distinct buffers much
|
||||
buffers and the integrity metadata. These two distinct buffers must
|
||||
match up for an I/O to complete.
|
||||
|
||||
The separation of the data and integrity metadata buffers as well as
|
||||
|
||||
@@ -777,6 +777,18 @@ in cpuset directories:
|
||||
# /bin/echo 1-4 > cpus -> set cpus list to cpus 1,2,3,4
|
||||
# /bin/echo 1,2,3,4 > cpus -> set cpus list to cpus 1,2,3,4
|
||||
|
||||
To add a CPU to a cpuset, write the new list of CPUs including the
|
||||
CPU to be added. To add 6 to the above cpuset:
|
||||
|
||||
# /bin/echo 1-4,6 > cpus -> set cpus list to cpus 1,2,3,4,6
|
||||
|
||||
Similarly to remove a CPU from a cpuset, write the new list of CPUs
|
||||
without the CPU to be removed.
|
||||
|
||||
To remove all the CPUs:
|
||||
|
||||
# /bin/echo "" > cpus -> clear cpus list
|
||||
|
||||
2.3 Setting flags
|
||||
-----------------
|
||||
|
||||
|
||||
@@ -207,8 +207,8 @@ Attributes
|
||||
~~~~~~~~~~
|
||||
struct driver_attribute {
|
||||
struct attribute attr;
|
||||
ssize_t (*show)(struct device_driver *, char * buf, size_t count, loff_t off);
|
||||
ssize_t (*store)(struct device_driver *, const char * buf, size_t count, loff_t off);
|
||||
ssize_t (*show)(struct device_driver *driver, char *buf);
|
||||
ssize_t (*store)(struct device_driver *, const char * buf, size_t count);
|
||||
};
|
||||
|
||||
Device drivers can export attributes via their sysfs directories.
|
||||
|
||||
@@ -25,7 +25,7 @@ use IO::Handle;
|
||||
"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
|
||||
"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
|
||||
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2" );
|
||||
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718" );
|
||||
|
||||
# Check args
|
||||
syntax() if (scalar(@ARGV) != 1);
|
||||
@@ -381,6 +381,57 @@ sub cx18 {
|
||||
$allfiles;
|
||||
}
|
||||
|
||||
sub mpc718 {
|
||||
my $archive = 'Yuan MPC718 TV Tuner Card 2.13.10.1016.zip';
|
||||
my $url = "ftp://ftp.work.acer-euro.com/desktop/aspire_idea510/vista/Drivers/$archive";
|
||||
my $fwfile = "dvb-cx18-mpc718-mt352.fw";
|
||||
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
|
||||
|
||||
checkstandard();
|
||||
wgetfile($archive, $url);
|
||||
unzip($archive, $tmpdir);
|
||||
|
||||
my $sourcefile = "$tmpdir/Yuan MPC718 TV Tuner Card 2.13.10.1016/mpc718_32bit/yuanrap.sys";
|
||||
my $found = 0;
|
||||
|
||||
open IN, '<', $sourcefile or die "Couldn't open $sourcefile to extract $fwfile data\n";
|
||||
binmode IN;
|
||||
open OUT, '>', $fwfile;
|
||||
binmode OUT;
|
||||
{
|
||||
# Block scope because we change the line terminator variable $/
|
||||
my $prevlen = 0;
|
||||
my $currlen;
|
||||
|
||||
# Buried in the data segment are 3 runs of almost identical
|
||||
# register-value pairs that end in 0x5d 0x01 which is a "TUNER GO"
|
||||
# command for the MT352.
|
||||
# Pull out the middle run (because it's easy) of register-value
|
||||
# pairs to make the "firmware" file.
|
||||
|
||||
local $/ = "\x5d\x01"; # MT352 "TUNER GO"
|
||||
|
||||
while (<IN>) {
|
||||
$currlen = length($_);
|
||||
if ($prevlen == $currlen && $currlen <= 64) {
|
||||
chop; chop; # Get rid of "TUNER GO"
|
||||
s/^\0\0//; # get rid of leading 00 00 if it's there
|
||||
printf OUT "$_";
|
||||
$found = 1;
|
||||
last;
|
||||
}
|
||||
$prevlen = $currlen;
|
||||
}
|
||||
}
|
||||
close OUT;
|
||||
close IN;
|
||||
if (!$found) {
|
||||
unlink $fwfile;
|
||||
die "Couldn't find valid register-value sequence in $sourcefile for $fwfile\n";
|
||||
}
|
||||
$fwfile;
|
||||
}
|
||||
|
||||
sub cx23885 {
|
||||
my $url = "http://linuxtv.org/downloads/firmware/";
|
||||
|
||||
|
||||
@@ -458,3 +458,13 @@ Why: Remove the old legacy 32bit machine check code. This has been
|
||||
but the old version has been kept around for easier testing. Note this
|
||||
doesn't impact the old P5 and WinChip machine check handlers.
|
||||
Who: Andi Kleen <andi@firstfloor.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
|
||||
exported interface anymore.
|
||||
When: 2.6.33
|
||||
Why: cpu_policy_rwsem has a new cleaner definition making it local to
|
||||
cpufreq core and contained inside cpufreq.c. Other dependent
|
||||
drivers should not use it in order to safely avoid lockdep issues.
|
||||
Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
|
||||
|
||||
@@ -23,7 +23,8 @@ interface.
|
||||
Using sysfs
|
||||
~~~~~~~~~~~
|
||||
|
||||
sysfs is always compiled in. You can access it by doing:
|
||||
sysfs is always compiled in if CONFIG_SYSFS is defined. You can access
|
||||
it by doing:
|
||||
|
||||
mount -t sysfs sysfs /sys
|
||||
|
||||
|
||||
+16
-9
@@ -188,13 +188,18 @@ Solution: Exclude affected source files from profiling by specifying
|
||||
GCOV_PROFILE := n or GCOV_PROFILE_basename.o := n in the
|
||||
corresponding Makefile.
|
||||
|
||||
Problem: Files copied from sysfs appear empty or incomplete.
|
||||
Cause: Due to the way seq_file works, some tools such as cp or tar
|
||||
may not correctly copy files from sysfs.
|
||||
Solution: Use 'cat' to read .gcda files and 'cp -d' to copy links.
|
||||
Alternatively use the mechanism shown in Appendix B.
|
||||
|
||||
|
||||
Appendix A: gather_on_build.sh
|
||||
==============================
|
||||
|
||||
Sample script to gather coverage meta files on the build machine
|
||||
(see 6a):
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
KSRC=$1
|
||||
@@ -226,7 +231,7 @@ Appendix B: gather_on_test.sh
|
||||
Sample script to gather coverage data files on the test machine
|
||||
(see 6b):
|
||||
|
||||
#!/bin/bash
|
||||
#!/bin/bash -e
|
||||
|
||||
DEST=$1
|
||||
GCDA=/sys/kernel/debug/gcov
|
||||
@@ -236,11 +241,13 @@ if [ -z "$DEST" ] ; then
|
||||
exit 1
|
||||
fi
|
||||
|
||||
find $GCDA -name '*.gcno' -o -name '*.gcda' | tar cfz $DEST -T -
|
||||
TEMPDIR=$(mktemp -d)
|
||||
echo Collecting data..
|
||||
find $GCDA -type d -exec mkdir -p $TEMPDIR/\{\} \;
|
||||
find $GCDA -name '*.gcda' -exec sh -c 'cat < $0 > '$TEMPDIR'/$0' {} \;
|
||||
find $GCDA -name '*.gcno' -exec sh -c 'cp -d $0 '$TEMPDIR'/$0' {} \;
|
||||
tar czf $DEST -C $TEMPDIR sys
|
||||
rm -rf $TEMPDIR
|
||||
|
||||
if [ $? -eq 0 ] ; then
|
||||
echo "$DEST successfully created, copy to build system and unpack with:"
|
||||
echo " tar xfz $DEST"
|
||||
else
|
||||
echo "Could not create file $DEST"
|
||||
fi
|
||||
echo "$DEST successfully created, copy to build system and unpack with:"
|
||||
echo " tar xfz $DEST"
|
||||
|
||||
@@ -1720,8 +1720,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
oprofile.cpu_type= Force an oprofile cpu type
|
||||
This might be useful if you have an older oprofile
|
||||
userland or if you want common events.
|
||||
Format: { archperfmon }
|
||||
archperfmon: [X86] Force use of architectural
|
||||
Format: { arch_perfmon }
|
||||
arch_perfmon: [X86] Force use of architectural
|
||||
perfmon on Intel CPUs instead of the
|
||||
CPU specific event set.
|
||||
|
||||
@@ -1915,6 +1915,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format: { 0 | 1 }
|
||||
See arch/parisc/kernel/pdc_chassis.c
|
||||
|
||||
percpu_alloc= [X86] Select which percpu first chunk allocator to use.
|
||||
Allowed values are one of "lpage", "embed" and "4k".
|
||||
See comments in arch/x86/kernel/setup_percpu.c for
|
||||
details on each allocator. This parameter is primarily
|
||||
for debugging and performance comparison.
|
||||
|
||||
pf. [PARIDE]
|
||||
See Documentation/blockdev/paride.txt.
|
||||
|
||||
@@ -2467,7 +2473,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
tp720= [HW,PS2]
|
||||
|
||||
trace_buf_size=nn[KMG] [ftrace] will set tracing buffer size.
|
||||
trace_buf_size=nn[KMG]
|
||||
[FTRACE] will set tracing buffer size.
|
||||
|
||||
trix= [HW,OSS] MediaTrix AudioTrix Pro
|
||||
Format:
|
||||
|
||||
@@ -16,13 +16,17 @@ Usage
|
||||
-----
|
||||
|
||||
CONFIG_DEBUG_KMEMLEAK in "Kernel hacking" has to be enabled. A kernel
|
||||
thread scans the memory every 10 minutes (by default) and prints any new
|
||||
unreferenced objects found. To trigger an intermediate scan and display
|
||||
all the possible memory leaks:
|
||||
thread scans the memory every 10 minutes (by default) and prints the
|
||||
number of new unreferenced objects found. To display the details of all
|
||||
the possible memory leaks:
|
||||
|
||||
# mount -t debugfs nodev /sys/kernel/debug/
|
||||
# cat /sys/kernel/debug/kmemleak
|
||||
|
||||
To trigger an intermediate memory scan:
|
||||
|
||||
# echo scan > /sys/kernel/debug/kmemleak
|
||||
|
||||
Note that the orphan objects are listed in the order they were allocated
|
||||
and one object at the beginning of the list may cause other subsequent
|
||||
objects to be reported as orphan.
|
||||
@@ -31,16 +35,21 @@ Memory scanning parameters can be modified at run-time by writing to the
|
||||
/sys/kernel/debug/kmemleak file. The following parameters are supported:
|
||||
|
||||
off - disable kmemleak (irreversible)
|
||||
stack=on - enable the task stacks scanning
|
||||
stack=on - enable the task stacks scanning (default)
|
||||
stack=off - disable the tasks stacks scanning
|
||||
scan=on - start the automatic memory scanning thread
|
||||
scan=on - start the automatic memory scanning thread (default)
|
||||
scan=off - stop the automatic memory scanning thread
|
||||
scan=<secs> - set the automatic memory scanning period in seconds (0
|
||||
to disable it)
|
||||
scan=<secs> - set the automatic memory scanning period in seconds
|
||||
(default 600, 0 to stop the automatic scanning)
|
||||
scan - trigger a memory scan
|
||||
|
||||
Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on
|
||||
the kernel command line.
|
||||
|
||||
Memory may be allocated or freed before kmemleak is initialised and
|
||||
these actions are stored in an early log buffer. The size of this buffer
|
||||
is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option.
|
||||
|
||||
Basic Algorithm
|
||||
---------------
|
||||
|
||||
|
||||
@@ -36,8 +36,6 @@ detailed description):
|
||||
- Bluetooth enable and disable
|
||||
- video output switching, expansion control
|
||||
- ThinkLight on and off
|
||||
- limited docking and undocking
|
||||
- UltraBay eject
|
||||
- CMOS/UCMS control
|
||||
- LED control
|
||||
- ACPI sounds
|
||||
@@ -729,131 +727,6 @@ cannot be read or if it is unknown, thinkpad-acpi will report it as "off".
|
||||
It is impossible to know if the status returned through sysfs is valid.
|
||||
|
||||
|
||||
Docking / undocking -- /proc/acpi/ibm/dock
|
||||
------------------------------------------
|
||||
|
||||
Docking and undocking (e.g. with the X4 UltraBase) requires some
|
||||
actions to be taken by the operating system to safely make or break
|
||||
the electrical connections with the dock.
|
||||
|
||||
The docking feature of this driver generates the following ACPI events:
|
||||
|
||||
ibm/dock GDCK 00000003 00000001 -- eject request
|
||||
ibm/dock GDCK 00000003 00000002 -- undocked
|
||||
ibm/dock GDCK 00000000 00000003 -- docked
|
||||
|
||||
NOTE: These events will only be generated if the laptop was docked
|
||||
when originally booted. This is due to the current lack of support for
|
||||
hot plugging of devices in the Linux ACPI framework. If the laptop was
|
||||
booted while not in the dock, the following message is shown in the
|
||||
logs:
|
||||
|
||||
Mar 17 01:42:34 aero kernel: thinkpad_acpi: dock device not present
|
||||
|
||||
In this case, no dock-related events are generated but the dock and
|
||||
undock commands described below still work. They can be executed
|
||||
manually or triggered by Fn key combinations (see the example acpid
|
||||
configuration files included in the driver tarball package available
|
||||
on the web site).
|
||||
|
||||
When the eject request button on the dock is pressed, the first event
|
||||
above is generated. The handler for this event should issue the
|
||||
following command:
|
||||
|
||||
echo undock > /proc/acpi/ibm/dock
|
||||
|
||||
After the LED on the dock goes off, it is safe to eject the laptop.
|
||||
Note: if you pressed this key by mistake, go ahead and eject the
|
||||
laptop, then dock it back in. Otherwise, the dock may not function as
|
||||
expected.
|
||||
|
||||
When the laptop is docked, the third event above is generated. The
|
||||
handler for this event should issue the following command to fully
|
||||
enable the dock:
|
||||
|
||||
echo dock > /proc/acpi/ibm/dock
|
||||
|
||||
The contents of the /proc/acpi/ibm/dock file shows the current status
|
||||
of the dock, as provided by the ACPI framework.
|
||||
|
||||
The docking support in this driver does not take care of enabling or
|
||||
disabling any other devices you may have attached to the dock. For
|
||||
example, a CD drive plugged into the UltraBase needs to be disabled or
|
||||
enabled separately. See the provided example acpid configuration files
|
||||
for how this can be accomplished.
|
||||
|
||||
There is no support yet for PCI devices that may be attached to a
|
||||
docking station, e.g. in the ThinkPad Dock II. The driver currently
|
||||
does not recognize, enable or disable such devices. This means that
|
||||
the only docking stations currently supported are the X-series
|
||||
UltraBase docks and "dumb" port replicators like the Mini Dock (the
|
||||
latter don't need any ACPI support, actually).
|
||||
|
||||
|
||||
UltraBay eject -- /proc/acpi/ibm/bay
|
||||
------------------------------------
|
||||
|
||||
Inserting or ejecting an UltraBay device requires some actions to be
|
||||
taken by the operating system to safely make or break the electrical
|
||||
connections with the device.
|
||||
|
||||
This feature generates the following ACPI events:
|
||||
|
||||
ibm/bay MSTR 00000003 00000000 -- eject request
|
||||
ibm/bay MSTR 00000001 00000000 -- eject lever inserted
|
||||
|
||||
NOTE: These events will only be generated if the UltraBay was present
|
||||
when the laptop was originally booted (on the X series, the UltraBay
|
||||
is in the dock, so it may not be present if the laptop was undocked).
|
||||
This is due to the current lack of support for hot plugging of devices
|
||||
in the Linux ACPI framework. If the laptop was booted without the
|
||||
UltraBay, the following message is shown in the logs:
|
||||
|
||||
Mar 17 01:42:34 aero kernel: thinkpad_acpi: bay device not present
|
||||
|
||||
In this case, no bay-related events are generated but the eject
|
||||
command described below still works. It can be executed manually or
|
||||
triggered by a hot key combination.
|
||||
|
||||
Sliding the eject lever generates the first event shown above. The
|
||||
handler for this event should take whatever actions are necessary to
|
||||
shut down the device in the UltraBay (e.g. call idectl), then issue
|
||||
the following command:
|
||||
|
||||
echo eject > /proc/acpi/ibm/bay
|
||||
|
||||
After the LED on the UltraBay goes off, it is safe to pull out the
|
||||
device.
|
||||
|
||||
When the eject lever is inserted, the second event above is
|
||||
generated. The handler for this event should take whatever actions are
|
||||
necessary to enable the UltraBay device (e.g. call idectl).
|
||||
|
||||
The contents of the /proc/acpi/ibm/bay file shows the current status
|
||||
of the UltraBay, as provided by the ACPI framework.
|
||||
|
||||
EXPERIMENTAL warm eject support on the 600e/x, A22p and A3x (To use
|
||||
this feature, you need to supply the experimental=1 parameter when
|
||||
loading the module):
|
||||
|
||||
These models do not have a button near the UltraBay device to request
|
||||
a hot eject but rather require the laptop to be put to sleep
|
||||
(suspend-to-ram) before the bay device is ejected or inserted).
|
||||
The sequence of steps to eject the device is as follows:
|
||||
|
||||
echo eject > /proc/acpi/ibm/bay
|
||||
put the ThinkPad to sleep
|
||||
remove the drive
|
||||
resume from sleep
|
||||
cat /proc/acpi/ibm/bay should show that the drive was removed
|
||||
|
||||
On the A3x, both the UltraBay 2000 and UltraBay Plus devices are
|
||||
supported. Use "eject2" instead of "eject" for the second bay.
|
||||
|
||||
Note: the UltraBay eject support on the 600e/x, A22p and A3x is
|
||||
EXPERIMENTAL and may not work as expected. USE WITH CAUTION!
|
||||
|
||||
|
||||
CMOS/UCMS control
|
||||
-----------------
|
||||
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
Kernel driver lp3944
|
||||
====================
|
||||
|
||||
* National Semiconductor LP3944 Fun-light Chip
|
||||
Prefix: 'lp3944'
|
||||
Addresses scanned: None (see the Notes section below)
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
http://www.national.com/pf/LP/LP3944.html
|
||||
|
||||
Authors:
|
||||
Antonio Ospite <ospite@studenti.unina.it>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
The LP3944 is a helper chip that can drive up to 8 leds, with two programmable
|
||||
DIM modes; it could even be used as a gpio expander but this driver assumes it
|
||||
is used as a led controller.
|
||||
|
||||
The DIM modes are used to set _blink_ patterns for leds, the pattern is
|
||||
specified supplying two parameters:
|
||||
- period: from 0s to 1.6s
|
||||
- duty cycle: percentage of the period the led is on, from 0 to 100
|
||||
|
||||
Setting a led in DIM0 or DIM1 mode makes it blink according to the pattern.
|
||||
See the datasheet for details.
|
||||
|
||||
LP3944 can be found on Motorola A910 smartphone, where it drives the rgb
|
||||
leds, the camera flash light and the lcds power.
|
||||
|
||||
|
||||
Notes
|
||||
-----
|
||||
The chip is used mainly in embedded contexts, so this driver expects it is
|
||||
registered using the i2c_board_info mechanism.
|
||||
|
||||
To register the chip at address 0x60 on adapter 0, set the platform data
|
||||
according to include/linux/leds-lp3944.h, set the i2c board info:
|
||||
|
||||
static struct i2c_board_info __initdata a910_i2c_board_info[] = {
|
||||
{
|
||||
I2C_BOARD_INFO("lp3944", 0x60),
|
||||
.platform_data = &a910_lp3944_leds,
|
||||
},
|
||||
};
|
||||
|
||||
and register it in the platform init function
|
||||
|
||||
i2c_register_board_info(0, a910_i2c_board_info,
|
||||
ARRAY_SIZE(a910_i2c_board_info));
|
||||
+483
-238
File diff suppressed because it is too large
Load Diff
@@ -30,9 +30,9 @@ State
|
||||
The validator tracks lock-class usage history into 4n + 1 separate state bits:
|
||||
|
||||
- 'ever held in STATE context'
|
||||
- 'ever head as readlock in STATE context'
|
||||
- 'ever head with STATE enabled'
|
||||
- 'ever head as readlock with STATE enabled'
|
||||
- 'ever held as readlock in STATE context'
|
||||
- 'ever held with STATE enabled'
|
||||
- 'ever held as readlock with STATE enabled'
|
||||
|
||||
Where STATE can be either one of (kernel/lockdep_states.h)
|
||||
- hardirq
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,148 @@
|
||||
4xx/Axon EMAC ethernet nodes
|
||||
|
||||
The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
|
||||
the Axon bridge. To operate this needs to interact with a ths
|
||||
special McMAL DMA controller, and sometimes an RGMII or ZMII
|
||||
interface. In addition to the nodes and properties described
|
||||
below, the node for the OPB bus on which the EMAC sits must have a
|
||||
correct clock-frequency property.
|
||||
|
||||
i) The EMAC node itself
|
||||
|
||||
Required properties:
|
||||
- device_type : "network"
|
||||
|
||||
- compatible : compatible list, contains 2 entries, first is
|
||||
"ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
|
||||
405gp, Axon) and second is either "ibm,emac" or
|
||||
"ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
|
||||
"ibm,emac4"
|
||||
- interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
|
||||
- interrupt-parent : optional, if needed for interrupt mapping
|
||||
- reg : <registers mapping>
|
||||
- local-mac-address : 6 bytes, MAC address
|
||||
- mal-device : phandle of the associated McMAL node
|
||||
- mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
|
||||
with this EMAC
|
||||
- mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
|
||||
with this EMAC
|
||||
- cell-index : 1 cell, hardware index of the EMAC cell on a given
|
||||
ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
|
||||
each Axon chip)
|
||||
- max-frame-size : 1 cell, maximum frame size supported in bytes
|
||||
- rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
|
||||
operations.
|
||||
For Axon, 2048
|
||||
- tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
|
||||
operations.
|
||||
For Axon, 2048.
|
||||
- fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
|
||||
thresholds).
|
||||
For Axon, 0x00000010
|
||||
- mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
|
||||
in bytes.
|
||||
For Axon, 0x00000100 (I think ...)
|
||||
- phy-mode : string, mode of operations of the PHY interface.
|
||||
Supported values are: "mii", "rmii", "smii", "rgmii",
|
||||
"tbi", "gmii", rtbi", "sgmii".
|
||||
For Axon on CAB, it is "rgmii"
|
||||
- mdio-device : 1 cell, required iff using shared MDIO registers
|
||||
(440EP). phandle of the EMAC to use to drive the
|
||||
MDIO lines for the PHY used by this EMAC.
|
||||
- zmii-device : 1 cell, required iff connected to a ZMII. phandle of
|
||||
the ZMII device node
|
||||
- zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
|
||||
channel or 0xffffffff if ZMII is only used for MDIO.
|
||||
- rgmii-device : 1 cell, required iff connected to an RGMII. phandle
|
||||
of the RGMII device node.
|
||||
For Axon: phandle of plb5/plb4/opb/rgmii
|
||||
- rgmii-channel : 1 cell, required iff connected to an RGMII. Which
|
||||
RGMII channel is used by this EMAC.
|
||||
Fox Axon: present, whatever value is appropriate for each
|
||||
EMAC, that is the content of the current (bogus) "phy-port"
|
||||
property.
|
||||
|
||||
Optional properties:
|
||||
- phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
|
||||
a search is performed.
|
||||
- phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
|
||||
for, used if phy-address is absent. bit 0x00000001 is
|
||||
MDIO address 0.
|
||||
For Axon it can be absent, though my current driver
|
||||
doesn't handle phy-address yet so for now, keep
|
||||
0x00ffffff in it.
|
||||
- rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
|
||||
operations (if absent the value is the same as
|
||||
rx-fifo-size). For Axon, either absent or 2048.
|
||||
- tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
|
||||
operations (if absent the value is the same as
|
||||
tx-fifo-size). For Axon, either absent or 2048.
|
||||
- tah-device : 1 cell, optional. If connected to a TAH engine for
|
||||
offload, phandle of the TAH device node.
|
||||
- tah-channel : 1 cell, optional. If appropriate, channel used on the
|
||||
TAH engine.
|
||||
|
||||
Example:
|
||||
|
||||
EMAC0: ethernet@40000800 {
|
||||
device_type = "network";
|
||||
compatible = "ibm,emac-440gp", "ibm,emac";
|
||||
interrupt-parent = <&UIC1>;
|
||||
interrupts = <1c 4 1d 4>;
|
||||
reg = <40000800 70>;
|
||||
local-mac-address = [00 04 AC E3 1B 1E];
|
||||
mal-device = <&MAL0>;
|
||||
mal-tx-channel = <0 1>;
|
||||
mal-rx-channel = <0>;
|
||||
cell-index = <0>;
|
||||
max-frame-size = <5dc>;
|
||||
rx-fifo-size = <1000>;
|
||||
tx-fifo-size = <800>;
|
||||
phy-mode = "rmii";
|
||||
phy-map = <00000001>;
|
||||
zmii-device = <&ZMII0>;
|
||||
zmii-channel = <0>;
|
||||
};
|
||||
|
||||
ii) McMAL node
|
||||
|
||||
Required properties:
|
||||
- device_type : "dma-controller"
|
||||
- compatible : compatible list, containing 2 entries, first is
|
||||
"ibm,mcmal-CHIP" where CHIP is the host ASIC (like
|
||||
emac) and the second is either "ibm,mcmal" or
|
||||
"ibm,mcmal2".
|
||||
For Axon, "ibm,mcmal-axon","ibm,mcmal2"
|
||||
- interrupts : <interrupt mapping for the MAL interrupts sources:
|
||||
5 sources: tx_eob, rx_eob, serr, txde, rxde>.
|
||||
For Axon: This is _different_ from the current
|
||||
firmware. We use the "delayed" interrupts for txeob
|
||||
and rxeob. Thus we end up with mapping those 5 MPIC
|
||||
interrupts, all level positive sensitive: 10, 11, 32,
|
||||
33, 34 (in decimal)
|
||||
- dcr-reg : < DCR registers range >
|
||||
- dcr-parent : if needed for dcr-reg
|
||||
- num-tx-chans : 1 cell, number of Tx channels
|
||||
- num-rx-chans : 1 cell, number of Rx channels
|
||||
|
||||
iii) ZMII node
|
||||
|
||||
Required properties:
|
||||
- compatible : compatible list, containing 2 entries, first is
|
||||
"ibm,zmii-CHIP" where CHIP is the host ASIC (like
|
||||
EMAC) and the second is "ibm,zmii".
|
||||
For Axon, there is no ZMII node.
|
||||
- reg : <registers mapping>
|
||||
|
||||
iv) RGMII node
|
||||
|
||||
Required properties:
|
||||
- compatible : compatible list, containing 2 entries, first is
|
||||
"ibm,rgmii-CHIP" where CHIP is the host ASIC (like
|
||||
EMAC) and the second is "ibm,rgmii".
|
||||
For Axon, "ibm,rgmii-axon","ibm,rgmii"
|
||||
- reg : <registers mapping>
|
||||
- revision : as provided by the RGMII new version register if
|
||||
available.
|
||||
For Axon: 0x0000012a
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
Specifying GPIO information for devices
|
||||
============================================
|
||||
|
||||
1) gpios property
|
||||
-----------------
|
||||
|
||||
Nodes that makes use of GPIOs should define them using `gpios' property,
|
||||
format of which is: <&gpio-controller1-phandle gpio1-specifier
|
||||
&gpio-controller2-phandle gpio2-specifier
|
||||
0 /* holes are permitted, means no GPIO 3 */
|
||||
&gpio-controller4-phandle gpio4-specifier
|
||||
...>;
|
||||
|
||||
Note that gpio-specifier length is controller dependent.
|
||||
|
||||
gpio-specifier may encode: bank, pin position inside the bank,
|
||||
whether pin is open-drain and whether pin is logically inverted.
|
||||
|
||||
Example of the node using GPIOs:
|
||||
|
||||
node {
|
||||
gpios = <&qe_pio_e 18 0>;
|
||||
};
|
||||
|
||||
In this example gpio-specifier is "18 0" and encodes GPIO pin number,
|
||||
and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
|
||||
|
||||
2) gpio-controller nodes
|
||||
------------------------
|
||||
|
||||
Every GPIO controller node must have #gpio-cells property defined,
|
||||
this information will be used to translate gpio-specifiers.
|
||||
|
||||
Example of two SOC GPIO banks defined as gpio-controller nodes:
|
||||
|
||||
qe_pio_a: gpio-controller@1400 {
|
||||
#gpio-cells = <2>;
|
||||
compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
|
||||
reg = <0x1400 0x18>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
||||
qe_pio_e: gpio-controller@1460 {
|
||||
#gpio-cells = <2>;
|
||||
compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
|
||||
reg = <0x1460 0x18>;
|
||||
gpio-controller;
|
||||
};
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user