Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
This commit is contained in:
Коммит
7f46b1343f
1
.mailmap
1
.mailmap
|
@ -32,6 +32,7 @@ Christoph Hellwig <hch@lst.de>
|
|||
Corey Minyard <minyard@acm.org>
|
||||
David Brownell <david-b@pacbell.net>
|
||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||
Domen Puncer <domen@coderock.org>
|
||||
Douglas Gilbert <dougg@torque.net>
|
||||
Ed L. Cashin <ecashin@coraid.com>
|
||||
|
|
19
CREDITS
19
CREDITS
|
@ -464,6 +464,11 @@ S: 1200 Goldenrod Dr.
|
|||
S: Nampa, Idaho 83686
|
||||
S: USA
|
||||
|
||||
N: Dirk J. Brandewie
|
||||
E: dirk.j.brandewie@intel.com
|
||||
E: linux-wimax@intel.com
|
||||
D: Intel Wireless WiMAX Connection 2400 SDIO driver
|
||||
|
||||
N: Derrick J. Brashear
|
||||
E: shadow@dementia.org
|
||||
W: http://www.dementia.org/~shadow
|
||||
|
@ -1681,7 +1686,7 @@ E: ajoshi@shell.unixbox.com
|
|||
D: fbdev hacking
|
||||
|
||||
N: Jesper Juhl
|
||||
E: jesper.juhl@gmail.com
|
||||
E: jj@chaosbits.net
|
||||
D: Various fixes, cleanups and minor features all over the tree.
|
||||
D: Wrote initial version of the hdaps driver (since passed on to others).
|
||||
S: Lemnosvej 1, 3.tv
|
||||
|
@ -2119,6 +2124,11 @@ N: H.J. Lu
|
|||
E: hjl@gnu.ai.mit.edu
|
||||
D: GCC + libraries hacker
|
||||
|
||||
N: Yanir Lubetkin
|
||||
E: yanirx.lubatkin@intel.com
|
||||
E: linux-wimax@intel.com
|
||||
D: Intel Wireless WiMAX Connection 2400 driver
|
||||
|
||||
N: Michal Ludvig
|
||||
E: michal@logix.cz
|
||||
E: michal.ludvig@asterisk.co.nz
|
||||
|
@ -2693,6 +2703,13 @@ S: RR #5, 497 Pole Line Road
|
|||
S: Thunder Bay, Ontario
|
||||
S: CANADA P7C 5M9
|
||||
|
||||
N: Inaky Perez-Gonzalez
|
||||
E: inaky.perez-gonzalez@intel.com
|
||||
E: linux-wimax@intel.com
|
||||
E: inakypg@yahoo.com
|
||||
D: WiMAX stack
|
||||
D: Intel Wireless WiMAX Connection 2400 driver
|
||||
|
||||
N: Yuri Per
|
||||
E: yuri@pts.mipt.ru
|
||||
D: Some smbfs fixes
|
||||
|
|
|
@ -6,7 +6,6 @@ Description:
|
|||
internal state of the kernel memory blocks. Files could be
|
||||
added or removed dynamically to represent hot-add/remove
|
||||
operations.
|
||||
|
||||
Users: hotplug memory add/remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
|
@ -19,6 +18,56 @@ Description:
|
|||
This is useful for a user-level agent to determine
|
||||
identify removable sections of the memory before attempting
|
||||
potentially expensive hot-remove memory operation
|
||||
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_device
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/phys_device
|
||||
is read-only and is designed to show the name of physical
|
||||
memory device. Implementation is currently incomplete.
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/phys_index
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/phys_index
|
||||
is read-only and contains the section ID in hexadecimal
|
||||
which is equivalent to decimal X contained in the
|
||||
memory section directory name.
|
||||
|
||||
What: /sys/devices/system/memory/memoryX/state
|
||||
Date: September 2008
|
||||
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||
Description:
|
||||
The file /sys/devices/system/memory/memoryX/state
|
||||
is read-write. When read, it's contents show the
|
||||
online/offline state of the memory section. When written,
|
||||
root can toggle the the online/offline state of a removable
|
||||
memory section (see removable file description above)
|
||||
using the following commands.
|
||||
# echo online > /sys/devices/system/memory/memoryX/state
|
||||
# echo offline > /sys/devices/system/memory/memoryX/state
|
||||
|
||||
For example, if /sys/devices/system/memory/memory22/removable
|
||||
contains a value of 1 and
|
||||
/sys/devices/system/memory/memory22/state contains the
|
||||
string "online" the following command can be executed by
|
||||
by root to offline that section.
|
||||
# echo offline > /sys/devices/system/memory/memory22/state
|
||||
Users: hotplug memory remove tools
|
||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||
|
||||
What: /sys/devices/system/node/nodeX/memoryY
|
||||
Date: September 2008
|
||||
Contact: Gary Hade <garyhade@us.ibm.com>
|
||||
Description:
|
||||
When CONFIG_NUMA is enabled
|
||||
/sys/devices/system/node/nodeX/memoryY is a symbolic link that
|
||||
points to the corresponding /sys/devices/system/memory/memoryY
|
||||
memory section directory. For example, the following symbolic
|
||||
link is created for memory section 9 on node0.
|
||||
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ mapped only for the time they are actually used and unmapped after the DMA
|
|||
transfer.
|
||||
|
||||
The following API will work of course even on platforms where no such
|
||||
hardware exists, see e.g. include/asm-i386/pci.h for how it is implemented on
|
||||
hardware exists, see e.g. arch/x86/include/asm/pci.h for how it is implemented on
|
||||
top of the virt_to_bus interface.
|
||||
|
||||
First of all, you should make sure
|
||||
|
|
|
@ -74,6 +74,14 @@
|
|||
!Enet/sunrpc/rpcb_clnt.c
|
||||
!Enet/sunrpc/clnt.c
|
||||
</sect1>
|
||||
<sect1><title>WiMAX</title>
|
||||
!Enet/wimax/op-msg.c
|
||||
!Enet/wimax/op-reset.c
|
||||
!Enet/wimax/op-rfkill.c
|
||||
!Enet/wimax/stack.c
|
||||
!Iinclude/net/wimax.h
|
||||
!Iinclude/linux/wimax.h
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="netdev">
|
||||
|
|
|
@ -41,6 +41,12 @@ GPL version 2.
|
|||
</abstract>
|
||||
|
||||
<revhistory>
|
||||
<revision>
|
||||
<revnumber>0.6</revnumber>
|
||||
<date>2008-12-05</date>
|
||||
<authorinitials>hjk</authorinitials>
|
||||
<revremark>Added description of portio sysfs attributes.</revremark>
|
||||
</revision>
|
||||
<revision>
|
||||
<revnumber>0.5</revnumber>
|
||||
<date>2008-05-22</date>
|
||||
|
@ -318,6 +324,54 @@ interested in translating it, please email me
|
|||
offset = N * getpagesize();
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
Sometimes there is hardware with memory-like regions that can not be
|
||||
mapped with the technique described here, but there are still ways to
|
||||
access them from userspace. The most common example are x86 ioports.
|
||||
On x86 systems, userspace can access these ioports using
|
||||
<function>ioperm()</function>, <function>iopl()</function>,
|
||||
<function>inb()</function>, <function>outb()</function>, and similar
|
||||
functions.
|
||||
</para>
|
||||
<para>
|
||||
Since these ioport regions can not be mapped, they will not appear under
|
||||
<filename>/sys/class/uio/uioX/maps/</filename> like the normal memory
|
||||
described above. Without information about the port regions a hardware
|
||||
has to offer, it becomes difficult for the userspace part of the
|
||||
driver to find out which ports belong to which UIO device.
|
||||
</para>
|
||||
<para>
|
||||
To address this situation, the new directory
|
||||
<filename>/sys/class/uio/uioX/portio/</filename> was added. It only
|
||||
exists if the driver wants to pass information about one or more port
|
||||
regions to userspace. If that is the case, subdirectories named
|
||||
<filename>port0</filename>, <filename>port1</filename>, and so on,
|
||||
will appear underneath
|
||||
<filename>/sys/class/uio/uioX/portio/</filename>.
|
||||
</para>
|
||||
<para>
|
||||
Each <filename>portX/</filename> directory contains three read-only
|
||||
files that show start, size, and type of the port region:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>start</filename>: The first port of this region.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>size</filename>: The number of ports in this region.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
<filename>porttype</filename>: A string describing the type of port.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
@ -339,12 +393,12 @@ offset = N * getpagesize();
|
|||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<varname>char *name</varname>: Required. The name of your driver as
|
||||
<varname>const char *name</varname>: Required. The name of your driver as
|
||||
it will appear in sysfs. I recommend using the name of your module for this.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>char *version</varname>: Required. This string appears in
|
||||
<varname>const char *version</varname>: Required. This string appears in
|
||||
<filename>/sys/class/uio/uioX/version</filename>.
|
||||
</para></listitem>
|
||||
|
||||
|
@ -355,6 +409,13 @@ mapping you need to fill one of the <varname>uio_mem</varname> structures.
|
|||
See the description below for details.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>struct uio_port port[ MAX_UIO_PORTS_REGIONS ]</varname>: Required
|
||||
if you want to pass information about ioports to userspace. For each port
|
||||
region you need to fill one of the <varname>uio_port</varname> structures.
|
||||
See the description below for details.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>long irq</varname>: Required. If your hardware generates an
|
||||
interrupt, it's your modules task to determine the irq number during
|
||||
|
@ -448,6 +509,42 @@ Please do not touch the <varname>kobj</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>
|
||||
|
||||
<para>
|
||||
Sometimes, your device can have one or more port regions which can not be
|
||||
mapped to userspace. But if there are other possibilities for userspace to
|
||||
access these ports, it makes sense to make information about the ports
|
||||
available in sysfs. For each region, you have to set up a
|
||||
<varname>struct uio_port</varname> in the <varname>port[]</varname> array.
|
||||
Here's a description of the fields of <varname>struct uio_port</varname>:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<varname>char *porttype</varname>: Required. Set this to one of the predefined
|
||||
constants. Use <varname>UIO_PORT_X86</varname> for the ioports found in x86
|
||||
architectures.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>unsigned long start</varname>: Required if the port region is used.
|
||||
Fill in the number of the first port of this region.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>unsigned long size</varname>: Fill in the number of ports in this
|
||||
region. If <varname>size</varname> is zero, the region is considered unused.
|
||||
Note that you <emphasis>must</emphasis> initialize <varname>size</varname>
|
||||
with zero for all unused regions.
|
||||
</para></listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Please do not touch the <varname>portio</varname> element of
|
||||
<varname>struct uio_port</varname>! It is used internally by the UIO
|
||||
framework to set up sysfs files for this region. Simply leave it alone.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="adding_irq_handler">
|
||||
|
|
|
@ -294,7 +294,8 @@ NOTE: pci_enable_device() can fail! Check the return value.
|
|||
|
||||
pci_set_master() will enable DMA by setting the bus master bit
|
||||
in the PCI_COMMAND register. It also fixes the latency timer value if
|
||||
it's set to something bogus by the BIOS.
|
||||
it's set to something bogus by the BIOS. pci_clear_master() will
|
||||
disable DMA by clearing the bus master bit.
|
||||
|
||||
If the PCI device can use the PCI Memory-Write-Invalidate transaction,
|
||||
call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval
|
||||
|
|
|
@ -9,3 +9,6 @@ cachefeatures.txt
|
|||
|
||||
Filesystems
|
||||
- Requirements for mounting the root file system.
|
||||
|
||||
bfin-gpio-note.txt
|
||||
- Notes in developing/using bfin-gpio driver.
|
||||
|
|
|
@ -0,0 +1,71 @@
|
|||
/*
|
||||
* File: Documentation/blackfin/bfin-gpio-note.txt
|
||||
* Based on:
|
||||
* Author:
|
||||
*
|
||||
* Created: $Id: bfin-gpio-note.txt 2008-11-24 16:42 grafyang $
|
||||
* Description: This file contains the notes in developing/using bfin-gpio.
|
||||
*
|
||||
*
|
||||
* Rev:
|
||||
*
|
||||
* Modified:
|
||||
* Copyright 2004-2008 Analog Devices Inc.
|
||||
*
|
||||
* Bugs: Enter bugs at http://blackfin.uclinux.org/
|
||||
*
|
||||
*/
|
||||
|
||||
|
||||
1. Blackfin GPIO introduction
|
||||
|
||||
There are many GPIO pins on Blackfin. Most of these pins are muxed to
|
||||
multi-functions. They can be configured as peripheral, or just as GPIO,
|
||||
configured to input with interrupt enabled, or output.
|
||||
|
||||
For detailed information, please see "arch/blackfin/kernel/bfin_gpio.c",
|
||||
or the relevant HRM.
|
||||
|
||||
|
||||
2. Avoiding resource conflict
|
||||
|
||||
Followed function groups are used to avoiding resource conflict,
|
||||
- Use the pin as peripheral,
|
||||
int peripheral_request(unsigned short per, const char *label);
|
||||
int peripheral_request_list(const unsigned short per[], const char *label);
|
||||
void peripheral_free(unsigned short per);
|
||||
void peripheral_free_list(const unsigned short per[]);
|
||||
- Use the pin as GPIO,
|
||||
int bfin_gpio_request(unsigned gpio, const char *label);
|
||||
void bfin_gpio_free(unsigned gpio);
|
||||
- Use the pin as GPIO interrupt,
|
||||
int bfin_gpio_irq_request(unsigned gpio, const char *label);
|
||||
void bfin_gpio_irq_free(unsigned gpio);
|
||||
|
||||
The request functions will record the function state for a certain pin,
|
||||
the free functions will clear it's function state.
|
||||
Once a pin is requested, it can't be requested again before it is freed by
|
||||
previous caller, otherwise kernel will dump stacks, and the request
|
||||
function fail.
|
||||
These functions are wrapped by other functions, most of the users need not
|
||||
care.
|
||||
|
||||
|
||||
3. But there are some exceptions
|
||||
- Kernel permit the identical GPIO be requested both as GPIO and GPIO
|
||||
interrut.
|
||||
Some drivers, like gpio-keys, need this behavior. Kernel only print out
|
||||
warning messages like,
|
||||
bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
|
||||
configuring it as IRQ!
|
||||
|
||||
Note: Consider the case that, if there are two drivers need the
|
||||
identical GPIO, one of them use it as GPIO, the other use it as
|
||||
GPIO interrupt. This will really cause resource conflict. So if
|
||||
there is any abnormal driver behavior, please check the bfin-gpio
|
||||
warning messages.
|
||||
|
||||
- Kernel permit the identical GPIO be requested from the same driver twice.
|
||||
|
||||
|
||||
|
|
@ -81,8 +81,8 @@ Until this step is completed the driver cannot be unloaded.
|
|||
Also echoing either mono ,packet or init in to image_type will free up the
|
||||
memory allocated by the driver.
|
||||
|
||||
If an user by accident executes steps 1 and 3 above without executing step 2;
|
||||
it will make the /sys/class/firmware/dell_rbu/ entries to disappear.
|
||||
If a user by accident executes steps 1 and 3 above without executing step 2;
|
||||
it will make the /sys/class/firmware/dell_rbu/ entries disappear.
|
||||
The entries can be recreated by doing the following
|
||||
echo init > /sys/devices/platform/dell_rbu/image_type
|
||||
NOTE: echoing init in image_type does not change it original value.
|
||||
|
|
|
@ -315,3 +315,23 @@ When: 2.6.29 (ideally) or 2.6.30 (more likely)
|
|||
Why: Deprecated by the new (standard) device driver binding model. Use
|
||||
i2c_driver->probe() and ->remove() instead.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: fscher and fscpos drivers
|
||||
When: June 2009
|
||||
Why: Deprecated by the new fschmd driver.
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: SELinux "compat_net" functionality
|
||||
When: 2.6.30 at the earliest
|
||||
Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
|
||||
network access control functionality of SELinux. Secmark offers both
|
||||
better performance and greater flexibility than the "compat_net"
|
||||
mechanism. Now that the major Linux distributions have moved to
|
||||
Secmark, it is time to deprecate the older mechanism and start the
|
||||
process of removing the old code.
|
||||
Who: Paul Moore <paul.moore@hp.com>
|
||||
|
|
|
@ -397,7 +397,7 @@ prototypes:
|
|||
};
|
||||
|
||||
locking rules:
|
||||
All except ->poll() may block.
|
||||
All may block.
|
||||
BKL
|
||||
llseek: no (see below)
|
||||
read: no
|
||||
|
|
|
@ -140,6 +140,7 @@ Table 1-1: Process specific entries in /proc
|
|||
statm Process memory status information
|
||||
status Process status in human readable form
|
||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||
stack Report full stack trace, enable via CONFIG_STACKTRACE
|
||||
smaps Extension based on maps, the rss size for each mapped file
|
||||
..............................................................................
|
||||
|
||||
|
@ -1385,6 +1386,15 @@ swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
|
|||
to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100
|
||||
causes the kernel to prefer to reclaim dentries and inodes.
|
||||
|
||||
dirty_background_bytes
|
||||
----------------------
|
||||
|
||||
Contains the amount of dirty memory at which the pdflush background writeback
|
||||
daemon will start writeback.
|
||||
|
||||
If dirty_background_bytes is written, dirty_background_ratio becomes a function
|
||||
of its value (dirty_background_bytes / the amount of dirtyable system memory).
|
||||
|
||||
dirty_background_ratio
|
||||
----------------------
|
||||
|
||||
|
@ -1393,14 +1403,29 @@ pages + file cache, not including locked pages and HugePages), the number of
|
|||
pages at which the pdflush background writeback daemon will start writing out
|
||||
dirty data.
|
||||
|
||||
If dirty_background_ratio is written, dirty_background_bytes becomes a function
|
||||
of its value (dirty_background_ratio * the amount of dirtyable system memory).
|
||||
|
||||
dirty_bytes
|
||||
-----------
|
||||
|
||||
Contains the amount of dirty memory at which a process generating disk writes
|
||||
will itself start writeback.
|
||||
|
||||
If dirty_bytes is written, dirty_ratio becomes a function of its value
|
||||
(dirty_bytes / the amount of dirtyable system memory).
|
||||
|
||||
dirty_ratio
|
||||
-----------------
|
||||
-----------
|
||||
|
||||
Contains, as a percentage of the dirtyable system memory (free pages + mapped
|
||||
pages + file cache, not including locked pages and HugePages), the number of
|
||||
pages at which a process which is generating disk writes will itself start
|
||||
writing out dirty data.
|
||||
|
||||
If dirty_ratio is written, dirty_bytes becomes a function of its value
|
||||
(dirty_ratio * the amount of dirtyable system memory).
|
||||
|
||||
dirty_writeback_centisecs
|
||||
-------------------------
|
||||
|
||||
|
|
|
@ -74,7 +74,7 @@ a sensor.
|
|||
Notice that some banks have both a read and a write address this is how the
|
||||
uGuru determines if a read from or a write to the bank is taking place, thus
|
||||
when reading you should always use the read address and when writing the
|
||||
write address. The write address is always one (1) more then the read address.
|
||||
write address. The write address is always one (1) more than the read address.
|
||||
|
||||
|
||||
uGuru ready
|
||||
|
@ -224,7 +224,7 @@ Bit 3: Beep if alarm (RW)
|
|||
Bit 4: 1 if alarm cause measured temp is over the warning threshold (R)
|
||||
Bit 5: 1 if alarm cause measured volt is over the max threshold (R)
|
||||
Bit 6: 1 if alarm cause measured volt is under the min threshold (R)
|
||||
Bit 7: Volt sensor: Shutdown if alarm persist for more then 4 seconds (RW)
|
||||
Bit 7: Volt sensor: Shutdown if alarm persist for more than 4 seconds (RW)
|
||||
Temp sensor: Shutdown if temp is over the shutdown threshold (RW)
|
||||
|
||||
* This bit is only honored/used by the uGuru if a temp sensor is connected
|
||||
|
@ -293,7 +293,7 @@ Byte 0:
|
|||
Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
|
||||
Bit 0: Give an alarm if measured rpm is under the min threshold (RW)
|
||||
Bit 3: Beep if alarm (RW)
|
||||
Bit 7: Shutdown if alarm persist for more then 4 seconds (RW)
|
||||
Bit 7: Shutdown if alarm persist for more than 4 seconds (RW)
|
||||
|
||||
Byte 1:
|
||||
min threshold (scale as bank 0x26)
|
||||
|
|
|
@ -31,15 +31,11 @@ Each of the measured inputs (temperature, fan speed) has corresponding high/low
|
|||
limit values. The ADT7470 will signal an ALARM if any measured value exceeds
|
||||
either limit.
|
||||
|
||||
The ADT7470 DOES NOT sample all inputs continuously. A single pin on the
|
||||
ADT7470 is connected to a multitude of thermal diodes, but the chip must be
|
||||
instructed explicitly to read the multitude of diodes. If you want to use
|
||||
automatic fan control mode, you must manually read any of the temperature
|
||||
sensors or the fan control algorithm will not run. The chip WILL NOT DO THIS
|
||||
AUTOMATICALLY; this must be done from userspace. This may be a bug in the chip
|
||||
design, given that many other AD chips take care of this. The driver will not
|
||||
read the registers more often than once every 5 seconds. Further,
|
||||
configuration data is only read once per minute.
|
||||
The ADT7470 samples all inputs continuously. A kernel thread is started up for
|
||||
the purpose of periodically querying the temperature sensors, thus allowing the
|
||||
automatic fan pwm control to set the fan speed. The driver will not read the
|
||||
registers more often than once every 5 seconds. Further, configuration data is
|
||||
only read once per minute.
|
||||
|
||||
Special Features
|
||||
----------------
|
||||
|
@ -72,5 +68,6 @@ pwm#_auto_point2_temp.
|
|||
Notes
|
||||
-----
|
||||
|
||||
As stated above, the temperature inputs must be read periodically from
|
||||
userspace in order for the automatic pwm algorithm to run.
|
||||
The temperature inputs no longer need to be read periodically from userspace in
|
||||
order for the automatic pwm algorithm to run. This was the case for earlier
|
||||
versions of the driver.
|
||||
|
|
|
@ -0,0 +1,89 @@
|
|||
Kernel driver f71882fg
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Fintek F71882FG and F71883FG
|
||||
Prefix: 'f71882fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Available from the Fintek website
|
||||
* Fintek F71862FG and F71863FG
|
||||
Prefix: 'f71862fg'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Available from the Fintek website
|
||||
* Fintek F8000
|
||||
Prefix: 'f8000'
|
||||
Addresses scanned: none, address read from Super I/O config space
|
||||
Datasheet: Not public
|
||||
|
||||
Author: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
Fintek F718xxFG/F8000 Super I/O chips include complete hardware monitoring
|
||||
capabilities. They can monitor up to 9 voltages (3 for the F8000), 4 fans and
|
||||
3 temperature sensors.
|
||||
|
||||
These chips also have fan controlling features, using either DC or PWM, in
|
||||
three different modes (one manual, two automatic).
|
||||
|
||||
The driver assumes that no more than one chip is present, which seems
|
||||
reasonable.
|
||||
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
|
||||
The Voltage, Fan and Temperature Monitoring uses the standard sysfs
|
||||
interface as documented in sysfs-interface, without any exceptions.
|
||||
|
||||
|
||||
Fan Control
|
||||
-----------
|
||||
|
||||
Both PWM (pulse-width modulation) and DC fan speed control methods are
|
||||
supported. The right one to use depends on external circuitry on the
|
||||
motherboard, so the driver assumes that the BIOS set the method
|
||||
properly.
|
||||
|
||||
There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
|
||||
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
|
||||
mode where the actual RPM of the fan (as measured) is controlled and the speed
|
||||
gets specified as 0-100% of the fan#_full_speed file.
|
||||
|
||||
Since both modes work in a 0-100% (mapped to 0-255) scale, there isn't a
|
||||
whole lot of a difference when modifying fan control settings. The only
|
||||
important difference is that in RPM mode the 0-100% controls the fan speed
|
||||
between 0-100% of fan#_full_speed. It is assumed that if the BIOS programs
|
||||
RPM mode, it will also set fan#_full_speed properly, if it does not then
|
||||
fan control will not work properly, unless you set a sane fan#_full_speed
|
||||
value yourself.
|
||||
|
||||
Switching between these modes requires re-initializing a whole bunch of
|
||||
registers, so the mode which the BIOS has set is kept. The mode is
|
||||
printed when loading the driver.
|
||||
|
||||
Three different fan control modes are supported; the mode number is written
|
||||
to the pwm#_enable file. Note that not all modes are supported on all
|
||||
chips, and some modes may only be available in RPM / PWM mode on the F8000.
|
||||
Writing an unsupported mode will result in an invalid parameter error.
|
||||
|
||||
* 1: Manual mode
|
||||
You ask for a specific PWM duty cycle / DC voltage or a specific % of
|
||||
fan#_full_speed by writing to the pwm# file. This mode is only
|
||||
available on the F8000 if the fan channel is in RPM mode.
|
||||
|
||||
* 2: Normal auto mode
|
||||
You can define a number of temperature/fan speed trip points, which % the
|
||||
fan should run at at this temp and which temp a fan should follow using the
|
||||
standard sysfs interface. The number and type of trip points is chip
|
||||
depended, see which files are available in sysfs.
|
||||
Fan/PWM channel 3 of the F8000 is always in this mode!
|
||||
|
||||
* 3: Thermostat mode (Only available on the F8000 when in duty cycle mode)
|
||||
The fan speed is regulated to keep the temp the fan is mapped to between
|
||||
temp#_auto_point2_temp and temp#_auto_point3_temp.
|
||||
|
||||
Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
|
||||
fan2 and pwm3 to fan3.
|
|
@ -26,6 +26,10 @@ Supported chips:
|
|||
Datasheet: Publicly available at the ITE website
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip
|
||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip
|
||||
* IT8720F
|
||||
Prefix: 'it8720'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
Datasheet: Not yet publicly available.
|
||||
* SiS950 [clone of IT8705F]
|
||||
Prefix: 'it87'
|
||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||
|
@ -71,7 +75,7 @@ Description
|
|||
-----------
|
||||
|
||||
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
||||
IT8718F, IT8726F and SiS950 chips.
|
||||
IT8718F, IT8720F, IT8726F and SiS950 chips.
|
||||
|
||||
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
||||
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
||||
|
@ -84,19 +88,19 @@ the IT8716F and late IT8712F have 6. They are shared with other functions
|
|||
though, so the functionality may not be available on a given system.
|
||||
The driver dumbly assume it is there.
|
||||
|
||||
The IT8718F also features VID inputs (up to 8 pins) but the value is
|
||||
stored in the Super-I/O configuration space. Due to technical limitations,
|
||||
The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
|
||||
is stored in the Super-I/O configuration space. Due to technical limitations,
|
||||
this value can currently only be read once at initialization time, so
|
||||
the driver won't notice and report changes in the VID value. The two
|
||||
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
||||
can't have both on a given board.
|
||||
|
||||
The IT8716F, IT8718F and later IT8712F revisions have support for
|
||||
The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for
|
||||
2 additional fans. The additional fans are supported by the driver.
|
||||
|
||||
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
|
||||
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
|
||||
clock divider mess) but not compatible with the older chips and
|
||||
The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have
|
||||
optional 16-bit tachometer counters for fans 1 to 3. This is better (no more
|
||||
fan clock divider mess) but not compatible with the older chips and
|
||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
||||
of the above chips is detected.
|
||||
|
||||
|
@ -122,7 +126,7 @@ zero'; this is important for negative voltage measurements. All voltage
|
|||
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
||||
0.016 volt. The battery voltage in8 does not have limit registers.
|
||||
|
||||
The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value:
|
||||
The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
|
||||
the voltage level your processor should work with. This is hardcoded by
|
||||
the mainboard and/or processor itself. It is a value in volts.
|
||||
|
||||
|
|
|
@ -1,9 +1,11 @@
|
|||
Kernel driver lm70
|
||||
==================
|
||||
|
||||
Supported chip:
|
||||
Supported chips:
|
||||
* National Semiconductor LM70
|
||||
Datasheet: http://www.national.com/pf/LM/LM70.html
|
||||
* Texas Instruments TMP121/TMP123
|
||||
Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
|
||||
|
||||
Author:
|
||||
Kaiwan N Billimoria <kaiwan@designergraphix.com>
|
||||
|
@ -25,6 +27,14 @@ complement digital temperature (sent via the SIO line), is available in the
|
|||
driver for interpretation. This driver makes use of the kernel's in-core
|
||||
SPI support.
|
||||
|
||||
As a real (in-tree) example of this "SPI protocol driver" interfacing
|
||||
with a "SPI master controller driver", see drivers/spi/spi_lm70llp.c
|
||||
and its associated documentation.
|
||||
|
||||
The TMP121/TMP123 are very similar; main differences are 4 wire SPI inter-
|
||||
face (read only) and 13-bit temperature data (0.0625 degrees celsius reso-
|
||||
lution).
|
||||
|
||||
Thanks to
|
||||
---------
|
||||
Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver
|
||||
|
|
|
@ -164,7 +164,7 @@ configured individually according to the following options.
|
|||
temperature. (PWM value from 0 to 255)
|
||||
|
||||
* pwm#_auto_pwm_minctl - this flags selects for temp#_auto_temp_off temperature
|
||||
the bahaviour of fans. Write 1 to let fans spinning at
|
||||
the behaviour of fans. Write 1 to let fans spinning at
|
||||
pwm#_auto_pwm_min or write 0 to let them off.
|
||||
|
||||
NOTE: It has been reported that there is a bug in the LM85 that causes the flag
|
||||
|
|
|
@ -0,0 +1,81 @@
|
|||
Kernel driver ltc4245
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Linear Technology LTC4245
|
||||
Prefix: 'ltc4245'
|
||||
Addresses scanned: 0x20-0x3f
|
||||
Datasheet:
|
||||
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1140,P19392,D13517
|
||||
|
||||
Author: Ira W. Snyder <iws@ovro.caltech.edu>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The LTC4245 controller allows a board to be safely inserted and removed
|
||||
from a live backplane in multiple supply systems such as CompactPCI and
|
||||
PCI Express.
|
||||
|
||||
|
||||
Usage Notes
|
||||
-----------
|
||||
|
||||
This driver does not probe for LTC4245 devices, due to the fact that some
|
||||
of the possible addresses are unfriendly to probing. You will need to use
|
||||
the "force" parameter to tell the driver where to find the device.
|
||||
|
||||
Example: the following will load the driver for an LTC4245 at address 0x23
|
||||
on I2C bus #1:
|
||||
$ modprobe ltc4245 force=1,0x23
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The LTC4245 has built-in limits for over and under current warnings. This
|
||||
makes it very likely that the reference circuit will be used.
|
||||
|
||||
This driver uses the values in the datasheet to change the register values
|
||||
into the values specified in the sysfs-interface document. The current readings
|
||||
rely on the sense resistors listed in Table 2: "Sense Resistor Values".
|
||||
|
||||
in1_input 12v input voltage (mV)
|
||||
in2_input 5v input voltage (mV)
|
||||
in3_input 3v input voltage (mV)
|
||||
in4_input Vee (-12v) input voltage (mV)
|
||||
|
||||
in1_min_alarm 12v input undervoltage alarm
|
||||
in2_min_alarm 5v input undervoltage alarm
|
||||
in3_min_alarm 3v input undervoltage alarm
|
||||
in4_min_alarm Vee (-12v) input undervoltage alarm
|
||||
|
||||
curr1_input 12v current (mA)
|
||||
curr2_input 5v current (mA)
|
||||
curr3_input 3v current (mA)
|
||||
curr4_input Vee (-12v) current (mA)
|
||||
|
||||
curr1_max_alarm 12v overcurrent alarm
|
||||
curr2_max_alarm 5v overcurrent alarm
|
||||
curr3_max_alarm 3v overcurrent alarm
|
||||
curr4_max_alarm Vee (-12v) overcurrent alarm
|
||||
|
||||
in5_input 12v output voltage (mV)
|
||||
in6_input 5v output voltage (mV)
|
||||
in7_input 3v output voltage (mV)
|
||||
in8_input Vee (-12v) output voltage (mV)
|
||||
|
||||
in5_min_alarm 12v output undervoltage alarm
|
||||
in6_min_alarm 5v output undervoltage alarm
|
||||
in7_min_alarm 3v output undervoltage alarm
|
||||
in8_min_alarm Vee (-12v) output undervoltage alarm
|
||||
|
||||
in9_input GPIO #1 voltage data
|
||||
in10_input GPIO #2 voltage data
|
||||
in11_input GPIO #3 voltage data
|
||||
|
||||
power1_input 12v power usage (mW)
|
||||
power2_input 5v power usage (mW)
|
||||
power3_input 3v power usage (mW)
|
||||
power4_input Vee (-12v) power usage (mW)
|
|
@ -11,3 +11,8 @@ unplug old device(s) and plug new device(s)
|
|||
# echo -n "1" > /sys/class/ide_port/idex/scan
|
||||
|
||||
done
|
||||
|
||||
NOTE: please make sure that partitions are unmounted and that there are
|
||||
no other active references to devices before doing "delete_devices" step,
|
||||
also do not attempt "scan" step on devices currently in use -- otherwise
|
||||
results may be unpredictable and lead to data loss if you're unlucky
|
||||
|
|
|
@ -0,0 +1,109 @@
|
|||
|
||||
Walkera WK-0701 transmitter is supplied with a ready to fly Walkera
|
||||
helicopters such as HM36, HM37, HM60. The walkera0701 module enables to use
|
||||
this transmitter as joystick
|
||||
|
||||
Devel homepage and download:
|
||||
http://zub.fei.tuke.sk/walkera-wk0701/
|
||||
|
||||
or use cogito:
|
||||
cg-clone http://zub.fei.tuke.sk/GIT/walkera0701-joystick
|
||||
|
||||
|
||||
Connecting to PC:
|
||||
|
||||
At back side of transmitter S-video connector can be found. Modulation
|
||||
pulses from processor to HF part can be found at pin 2 of this connector,
|
||||
pin 3 is GND. Between pin 3 and CPU 5k6 resistor can be found. To get
|
||||
modulation pulses to PC, signal pulses must be amplified.
|
||||
|
||||
Cable: (walkera TX to parport)
|
||||
|
||||
Walkera WK-0701 TX S-VIDEO connector:
|
||||
(back side of TX)
|
||||
__ __ S-video: canon25
|
||||
/ |_| \ pin 2 (signal) NPN parport
|
||||
/ O 4 3 O \ pin 3 (GND) LED ________________ 10 ACK
|
||||
( O 2 1 O ) | C
|
||||
\ ___ / 2 ________________________|\|_____|/
|
||||
| [___] | |/| B |\
|
||||
------- 3 __________________________________|________________ 25 GND
|
||||
E
|
||||
|
||||
|
||||
I use green LED and BC109 NPN transistor.
|
||||
|
||||
Software:
|
||||
|
||||
Build kernel with walkera0701 module. Module walkera0701 need exclusive
|
||||
access to parport, modules like lp must be unloaded before loading
|
||||
walkera0701 module, check dmesg for error messages. Connect TX to PC by
|
||||
cable and run jstest /dev/input/js0 to see values from TX. If no value can
|
||||
be changed by TX "joystick", check output from /proc/interrupts. Value for
|
||||
(usually irq7) parport must increase if TX is on.
|
||||
|
||||
|
||||
|
||||
Technical details:
|
||||
|
||||
Driver use interrupt from parport ACK input bit to measure pulse length
|
||||
using hrtimers.
|
||||
|
||||
Frame format:
|
||||
Based on walkera WK-0701 PCM Format description by Shaul Eizikovich.
|
||||
(downloaded from http://www.smartpropoplus.com/Docs/Walkera_Wk-0701_PCM.pdf)
|
||||
|
||||
Signal pulses:
|
||||
(ANALOG)
|
||||
SYNC BIN OCT
|
||||
+---------+ +------+
|
||||
| | | |
|
||||
--+ +------+ +---
|
||||
|
||||
Frame:
|
||||
SYNC , BIN1, OCT1, BIN2, OCT2 ... BIN24, OCT24, BIN25, next frame SYNC ..
|
||||
|
||||
pulse length:
|
||||
Binary values: Analog octal values:
|
||||
|
||||
288 uS Binary 0 318 uS 000
|
||||
438 uS Binary 1 398 uS 001
|
||||
478 uS 010
|
||||
558 uS 011
|
||||
638 uS 100
|
||||
1306 uS SYNC 718 uS 101
|
||||
798 uS 110
|
||||
878 uS 111
|
||||
|
||||
24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits
|
||||
|
||||
(Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync
|
||||
to bin change or octal value to bin change).
|
||||
|
||||
Binary data representations:
|
||||
|
||||
One binary and octal value can be grouped to nibble. 24 nibbles + one binary
|
||||
values can be sampled between sync pulses.
|
||||
|
||||
Values for first four channels (analog joystick values) can be found in
|
||||
first 10 nibbles. Analog value is represented by one sign bit and 9 bit
|
||||
absolute binary value. (10 bits per channel). Next nibble is checksum for
|
||||
first ten nibbles.
|
||||
|
||||
Next nibbles 12 .. 21 represents four channels (not all channels can be
|
||||
directly controlled from TX). Binary representations ar the same as in first
|
||||
four channels. In nibbles 22 and 23 is a special magic number. Nibble 24 is
|
||||
checksum for nibbles 12..23.
|
||||
|
||||
After last octal value for nibble 24 and next sync pulse one additional
|
||||
binary value can be sampled. This bit and magic number is not used in
|
||||
software driver. Some details about this magic numbers can be found in
|
||||
Walkera_Wk-0701_PCM.pdf.
|
||||
|
||||
Checksum calculation:
|
||||
|
||||
Summary of octal values in nibbles must be same as octal value in checksum
|
||||
nibble (only first 3 bits are used). Binary value for checksum nibble is
|
||||
calculated by sum of binary values in checked nibbles + sum of octal values
|
||||
in checked nibbles divided by 8. Only bit 0 of this sum is used.
|
||||
|
|
@ -84,7 +84,7 @@ Code Seq# Include File Comments
|
|||
'B' C0-FF advanced bbus
|
||||
<mailto:maassen@uni-freiburg.de>
|
||||
'C' all linux/soundcard.h
|
||||
'D' all asm-s390/dasd.h
|
||||
'D' all arch/s390/include/asm/dasd.h
|
||||
'E' all linux/input.h
|
||||
'F' all linux/fb.h
|
||||
'H' all linux/hiddev.h
|
||||
|
@ -105,7 +105,7 @@ Code Seq# Include File Comments
|
|||
'S' 80-81 scsi/scsi_ioctl.h conflict!
|
||||
'S' 82-FF scsi/scsi.h conflict!
|
||||
'T' all linux/soundcard.h conflict!
|
||||
'T' all asm-i386/ioctls.h conflict!
|
||||
'T' all arch/x86/include/asm/ioctls.h conflict!
|
||||
'U' 00-EF linux/drivers/usb/usb.h
|
||||
'V' all linux/vt.h
|
||||
'W' 00-1F linux/watchdog.h conflict!
|
||||
|
@ -120,7 +120,7 @@ Code Seq# Include File Comments
|
|||
<mailto:natalia@nikhefk.nikhef.nl>
|
||||
'c' 00-7F linux/comstats.h conflict!
|
||||
'c' 00-7F linux/coda.h conflict!
|
||||
'c' 80-9F asm-s390/chsc.h
|
||||
'c' 80-9F arch/s390/include/asm/chsc.h
|
||||
'd' 00-FF linux/char/drm/drm/h conflict!
|
||||
'd' 00-DF linux/video_decoder.h conflict!
|
||||
'd' F0-FF linux/digi1.h
|
||||
|
@ -170,7 +170,7 @@ Code Seq# Include File Comments
|
|||
<mailto:oe@port.de>
|
||||
0x80 00-1F linux/fb.h
|
||||
0x81 00-1F linux/videotext.h
|
||||
0x89 00-06 asm-i386/sockios.h
|
||||
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||
0x89 0B-DF linux/sockios.h
|
||||
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
|
||||
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
|
||||
|
|
|
@ -124,3 +124,10 @@ KBUILD_EXTRA_SYMBOLS
|
|||
--------------------------------------------------
|
||||
For modules use symbols from another modules.
|
||||
See more details in modules.txt.
|
||||
|
||||
ALLSOURCE_ARCHS
|
||||
--------------------------------------------------
|
||||
For tags/TAGS/cscope targets, you can specify more than one archs
|
||||
to be included in the databases, separated by blankspace. e.g.
|
||||
|
||||
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
|
||||
|
|
|
@ -253,7 +253,7 @@ following files:
|
|||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
echo "X" > 8123_bin_shipped
|
||||
echo "X" > 8123_bin.o_shipped
|
||||
|
||||
|
||||
In example 2, we are down to two fairly simple files and for simple
|
||||
|
@ -279,7 +279,7 @@ following files:
|
|||
|
||||
# Module specific targets
|
||||
genbin:
|
||||
echo "X" > 8123_bin_shipped
|
||||
echo "X" > 8123_bin.o_shipped
|
||||
|
||||
endif
|
||||
|
||||
|
|
|
@ -71,6 +71,11 @@ The @argument descriptions must begin on the very next line following
|
|||
this opening short function description line, with no intervening
|
||||
empty comment lines.
|
||||
|
||||
If a function parameter is "..." (varargs), it should be listed in
|
||||
kernel-doc notation as:
|
||||
* @...: description
|
||||
|
||||
|
||||
Example kernel-doc data structure comment.
|
||||
|
||||
/**
|
||||
|
@ -282,6 +287,32 @@ struct my_struct {
|
|||
};
|
||||
|
||||
|
||||
Including documentation blocks in source files
|
||||
----------------------------------------------
|
||||
|
||||
To facilitate having source code and comments close together, you can
|
||||
include kernel-doc documentation blocks that are free-form comments
|
||||
instead of being kernel-doc for functions, structures, unions,
|
||||
enums, or typedefs. This could be used for something like a
|
||||
theory of operation for a driver or library code, for example.
|
||||
|
||||
This is done by using a DOC: section keyword with a section title. E.g.:
|
||||
|
||||
/**
|
||||
* DOC: Theory of Operation
|
||||
*
|
||||
* The whizbang foobar is a dilly of a gizmo. It can do whatever you
|
||||
* want it to do, at any time. It reads your mind. Here's how it works.
|
||||
*
|
||||
* foo bar splat
|
||||
*
|
||||
* The only drawback to this gizmo is that is can sometimes damage
|
||||
* hardware, software, or its subject(s).
|
||||
*/
|
||||
|
||||
DOC: sections are used in SGML templates files as indicated below.
|
||||
|
||||
|
||||
How to make new SGML template files
|
||||
-----------------------------------
|
||||
|
||||
|
@ -302,6 +333,9 @@ exported using EXPORT_SYMBOL.
|
|||
!F<filename> <function [functions...]> is replaced by the
|
||||
documentation, in <filename>, for the functions listed.
|
||||
|
||||
!P<filename> <section title> is replaced by the contents of the DOC:
|
||||
section titled <section title> from <filename>.
|
||||
Spaces are allowed in <section title>; do not quote the <section title>.
|
||||
|
||||
Tim.
|
||||
*/ <twaugh@redhat.com>
|
||||
|
|
|
@ -91,6 +91,7 @@ parameter is applicable:
|
|||
SUSPEND System suspend states are enabled.
|
||||
FTRACE Function tracing enabled.
|
||||
TS Appropriate touchscreen support is enabled.
|
||||
UMS USB Mass Storage support is enabled.
|
||||
USB USB support is enabled.
|
||||
USBHID USB Human Interface Device support is enabled.
|
||||
V4L Video For Linux support is enabled.
|
||||
|
@ -469,8 +470,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
clearcpuid=BITNUM [X86]
|
||||
Disable CPUID feature X for the kernel. See
|
||||
include/asm-x86/cpufeature.h for the valid bit numbers.
|
||||
Note the Linux specific bits are not necessarily
|
||||
arch/x86/include/asm/cpufeature.h for the valid bit
|
||||
numbers. Note the Linux specific bits are not necessarily
|
||||
stable over kernel options, but the vendor specific
|
||||
ones should be.
|
||||
Also note that user programs calling CPUID directly
|
||||
|
@ -551,6 +552,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
not work reliably with all consoles, but is known
|
||||
to work with serial and VGA consoles.
|
||||
|
||||
coredump_filter=
|
||||
[KNL] Change the default value for
|
||||
/proc/<pid>/coredump_filter.
|
||||
See also Documentation/filesystems/proc.txt.
|
||||
|
||||
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
|
||||
Format:
|
||||
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
|
||||
|
@ -913,6 +919,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
inttest= [IA64]
|
||||
|
||||
iomem= Disable strict checking of access to MMIO memory
|
||||
strict regions from userspace.
|
||||
relaxed
|
||||
|
||||
iommu= [x86]
|
||||
off
|
||||
force
|
||||
|
@ -1117,6 +1127,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
If there are multiple matching configurations changing
|
||||
the same attribute, the last one is used.
|
||||
|
||||
lmb=debug [KNL] Enable lmb debug messages.
|
||||
|
||||
load_ramdisk= [RAM] List of ramdisks to load from floppy
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
|
||||
|
@ -1569,6 +1581,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
|
||||
|
||||
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
|
||||
See Documentation/debugging-via-ohci1394.txt for more
|
||||
info.
|
||||
|
||||
olpc_ec_timeout= [OLPC] ms delay when issuing EC commands
|
||||
Rather than timing out after 20 ms if an EC
|
||||
command is not properly ACKed, override the length
|
||||
|
@ -1793,10 +1809,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
autoconfiguration.
|
||||
Ranges are in pairs (memory base and size).
|
||||
|
||||
dynamic_printk
|
||||
Enables pr_debug()/dev_dbg() calls if
|
||||
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled. These can also
|
||||
be switched on/off via <debugfs>/dynamic_printk/modules
|
||||
dynamic_printk Enables pr_debug()/dev_dbg() calls if
|
||||
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled.
|
||||
These can also be switched on/off via
|
||||
<debugfs>/dynamic_printk/modules
|
||||
|
||||
print-fatal-signals=
|
||||
[KNL] debug: print fatal signals
|
||||
|
@ -1884,7 +1900,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
reboot= [BUGS=X86-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
|
||||
Format: <reboot_mode>[,<reboot_mode2>[,...]]
|
||||
See arch/*/kernel/reboot.c or arch/*/kernel/process.c
|
||||
See arch/*/kernel/reboot.c or arch/*/kernel/process.c
|
||||
|
||||
relax_domain_level=
|
||||
[KNL, SMP] Set scheduler's default relax_domain_level.
|
||||
|
@ -2372,6 +2388,41 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
usbhid.mousepoll=
|
||||
[USBHID] The interval which mice are to be polled at.
|
||||
|
||||
usb-storage.delay_use=
|
||||
[UMS] The delay in seconds before a new device is
|
||||
scanned for Logical Units (default 5).
|
||||
|
||||
usb-storage.quirks=
|
||||
[UMS] A list of quirks entries to supplement or
|
||||
override the built-in unusual_devs list. List
|
||||
entries are separated by commas. Each entry has
|
||||
the form VID:PID:Flags where VID and PID are Vendor
|
||||
and Product ID values (4-digit hex numbers) and
|
||||
Flags is a set of characters, each corresponding
|
||||
to a common usb-storage quirk flag as follows:
|
||||
a = SANE_SENSE (collect more than 18 bytes
|
||||
of sense data);
|
||||
c = FIX_CAPACITY (decrease the reported
|
||||
device capacity by one sector);
|
||||
h = CAPACITY_HEURISTICS (decrease the
|
||||
reported device capacity by one
|
||||
sector if the number is odd);
|
||||
i = IGNORE_DEVICE (don't bind to this
|
||||
device);
|
||||
l = NOT_LOCKABLE (don't try to lock and
|
||||
unlock ejectable media);
|
||||
m = MAX_SECTORS_64 (don't transfer more
|
||||
than 64 sectors = 32 KB at a time);
|
||||
o = CAPACITY_OK (accept the capacity
|
||||
reported by the device);
|
||||
r = IGNORE_RESIDUE (the device reports
|
||||
bogus residue values);
|
||||
s = SINGLE_LUN (the device has only one
|
||||
Logical Unit);
|
||||
w = NO_WP_DETECT (don't test whether the
|
||||
medium is write-protected).
|
||||
Example: quirks=0419:aaf5:rl,0421:0433:rc
|
||||
|
||||
add_efi_memmap [EFI; x86-32,X86-64] Include EFI memory map in
|
||||
kernel's map of available physical RAM.
|
||||
|
||||
|
@ -2432,8 +2483,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Format:
|
||||
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
|
||||
|
||||
norandmaps Don't use address space randomization
|
||||
Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
|
||||
norandmaps Don't use address space randomization. Equivalent to
|
||||
echo 0 > /proc/sys/kernel/randomize_va_space
|
||||
|
||||
______________________________________________________________________
|
||||
|
||||
|
|
|
@ -118,8 +118,8 @@ the name of the kobject, call kobject_rename():
|
|||
|
||||
int kobject_rename(struct kobject *kobj, const char *new_name);
|
||||
|
||||
Note kobject_rename does perform any locking or have a solid notion of
|
||||
what names are valid so the provide must provide their own sanity checking
|
||||
kobject_rename does not perform any locking or have a solid notion of
|
||||
what names are valid so the caller must provide their own sanity checking
|
||||
and serialization.
|
||||
|
||||
There is a function called kobject_set_name() but that is legacy cruft and
|
||||
|
|
|
@ -497,7 +497,10 @@ The first column provides the kernel address where the probe is inserted.
|
|||
The second column identifies the type of probe (k - kprobe, r - kretprobe
|
||||
and j - jprobe), while the third column specifies the symbol+offset of
|
||||
the probe. If the probed function belongs to a module, the module name
|
||||
is also specified.
|
||||
is also specified. Following columns show probe status. If the probe is on
|
||||
a virtual address that is no longer valid (module init sections, module
|
||||
virtual addresses that correspond to modules that've been unloaded),
|
||||
such probes are marked with [GONE].
|
||||
|
||||
/debug/kprobes/enabled: Turn kprobes ON/OFF
|
||||
|
||||
|
|
|
@ -1475,7 +1475,7 @@ Sysfs interface changelog:
|
|||
|
||||
0x020100: Marker for thinkpad-acpi with hot key NVRAM polling
|
||||
support. If you must, use it to know you should not
|
||||
start an userspace NVRAM poller (allows to detect when
|
||||
start a userspace NVRAM poller (allows to detect when
|
||||
NVRAM is compiled out by the user because it is
|
||||
unneeded/undesired in the first place).
|
||||
0x020101: Marker for thinkpad-acpi with hot key NVRAM polling
|
||||
|
|
|
@ -125,14 +125,14 @@ TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
|
|||
ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
|
||||
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
|
||||
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
|
||||
GDA_MAGIC 0x58464552 gda include/asm-mips64/sn/gda.h
|
||||
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
|
||||
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
||||
STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h
|
||||
EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c
|
||||
HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
|
||||
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h
|
||||
PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h
|
||||
KV_MAGIC 0x5f4b565f kernel_vars_s include/asm-mips64/sn/klkernvars.h
|
||||
KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h
|
||||
I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c
|
||||
TRIDENT_STATE_MAGIC 0x63657373 trient_state sound/oss/trident.c
|
||||
M3_CARD_MAGIC 0x646e6f50 m3_card sound/oss/maestro3.c
|
||||
|
@ -158,7 +158,7 @@ CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c
|
|||
QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c
|
||||
QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c
|
||||
HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c
|
||||
NMI_MAGIC 0x48414d4d455201 nmi_s include/asm-mips64/sn/nmi.h
|
||||
NMI_MAGIC 0x48414d4d455201 nmi_s arch/mips/include/asm/sn/nmi.h
|
||||
|
||||
Note that there are also defined special per-driver magic numbers in sound
|
||||
memory management. See include/sound/sndmagic.h for complete list of them. Many
|
||||
|
|
|
@ -124,7 +124,7 @@ config options.
|
|||
This option can be kernel module too.
|
||||
|
||||
--------------------------------
|
||||
3 sysfs files for memory hotplug
|
||||
4 sysfs files for memory hotplug
|
||||
--------------------------------
|
||||
All sections have their device information under /sys/devices/system/memory as
|
||||
|
||||
|
@ -138,11 +138,12 @@ For example, assume 1GiB section size. A device for a memory starting at
|
|||
(0x100000000 / 1Gib = 4)
|
||||
This device covers address range [0x100000000 ... 0x140000000)
|
||||
|
||||
Under each section, you can see 3 files.
|
||||
Under each section, you can see 4 files.
|
||||
|
||||
/sys/devices/system/memory/memoryXXX/phys_index
|
||||
/sys/devices/system/memory/memoryXXX/phys_device
|
||||
/sys/devices/system/memory/memoryXXX/state
|
||||
/sys/devices/system/memory/memoryXXX/removable
|
||||
|
||||
'phys_index' : read-only and contains section id, same as XXX.
|
||||
'state' : read-write
|
||||
|
@ -150,10 +151,20 @@ Under each section, you can see 3 files.
|
|||
at write: user can specify "online", "offline" command
|
||||
'phys_device': read-only: designed to show the name of physical memory device.
|
||||
This is not well implemented now.
|
||||
'removable' : read-only: contains an integer value indicating
|
||||
whether the memory section is removable or not
|
||||
removable. A value of 1 indicates that the memory
|
||||
section is removable and a value of 0 indicates that
|
||||
it is not removable.
|
||||
|
||||
NOTE:
|
||||
These directories/files appear after physical memory hotplug phase.
|
||||
|
||||
If CONFIG_NUMA is enabled the
|
||||
/sys/devices/system/memory/memoryXXX memory section
|
||||
directories can also be accessed via symbolic links located in
|
||||
the /sys/devices/system/node/node* directories. For example:
|
||||
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||
|
||||
--------------------------------
|
||||
4. Physical memory hot-add phase
|
||||
|
@ -365,7 +376,6 @@ node if necessary.
|
|||
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
|
||||
sysctl or new control file.
|
||||
- showing memory section and physical device relationship.
|
||||
- showing memory section and node relationship (maybe good for NUMA)
|
||||
- showing memory section is under ZONE_MOVABLE or not
|
||||
- test and make it better memory offlining.
|
||||
- support HugeTLB page migration and offlining.
|
||||
|
|
|
@ -44,7 +44,7 @@ FILES, CONFIGS AND COMPATABILITY
|
|||
|
||||
Two files are introduced:
|
||||
|
||||
a) 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
|
||||
a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h'
|
||||
containes : struct _auide_hwif
|
||||
timing parameters for PIO mode 0/1/2/3/4
|
||||
timing parameters for MWDMA 0/1/2
|
||||
|
|
|
@ -540,7 +540,7 @@ A client would issue an operation by:
|
|||
MSG_MORE should be set in msghdr::msg_flags on all but the last part of
|
||||
the request. Multiple requests may be made simultaneously.
|
||||
|
||||
If a call is intended to go to a destination other then the default
|
||||
If a call is intended to go to a destination other than the default
|
||||
specified through connect(), then msghdr::msg_name should be set on the
|
||||
first request message of that call.
|
||||
|
||||
|
|
|
@ -118,7 +118,7 @@ As mentioned above, main purpose of TUN/TAP driver is tunneling.
|
|||
It is used by VTun (http://vtun.sourceforge.net).
|
||||
|
||||
Another interesting application using TUN/TAP is pipsecd
|
||||
(http://perso.enst.fr/~beyssac/pipsec/), an userspace IPSec
|
||||
(http://perso.enst.fr/~beyssac/pipsec/), a userspace IPSec
|
||||
implementation that can use complete kernel routing (unlike FreeS/WAN).
|
||||
|
||||
3. How does Virtual network device actually work ?
|
||||
|
|
|
@ -31,7 +31,7 @@ anyways).
|
|||
|
||||
After detecting the processor type, the kernel patches out sections of code
|
||||
that shouldn't be used by writing nop's over it. Using cpufeatures requires
|
||||
just 2 macros (found in include/asm-ppc/cputable.h), as seen in head.S
|
||||
just 2 macros (found in arch/powerpc/include/asm/cputable.h), as seen in head.S
|
||||
transfer_to_handler:
|
||||
|
||||
#ifdef CONFIG_ALTIVEC
|
||||
|
|
|
@ -1402,7 +1402,7 @@ Syscalls are implemented on Linux for S390 by the Supervisor call instruction (S
|
|||
possibilities of these as the instruction is made up of a 0xA opcode & the second byte being
|
||||
the syscall number. They are traced using the simple command.
|
||||
TR SVC <Optional value or range>
|
||||
the syscalls are defined in linux/include/asm-s390/unistd.h
|
||||
the syscalls are defined in linux/arch/s390/include/asm/unistd.h
|
||||
e.g. to trace all file opens just do
|
||||
TR SVC 5 ( as this is the syscall number of open )
|
||||
|
||||
|
|
|
@ -98,7 +98,7 @@ platform. Some of the interface routines are specific to Linux/390 and some
|
|||
of them can be found on other Linux platforms implementations too.
|
||||
Miscellaneous function prototypes, data declarations, and macro definitions
|
||||
can be found in the architecture specific C header file
|
||||
linux/include/asm-s390/irq.h.
|
||||
linux/arch/s390/include/asm/irq.h.
|
||||
|
||||
Overview of CDS interface concepts
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@ S390 Debug Feature
|
|||
==================
|
||||
|
||||
files: arch/s390/kernel/debug.c
|
||||
include/asm-s390/debug.h
|
||||
arch/s390/include/asm/debug.h
|
||||
|
||||
Description:
|
||||
------------
|
||||
|
|
|
@ -733,7 +733,7 @@ Changes from 20040920 to 20041018
|
|||
I/O completion path a little more, especially taking care of
|
||||
fast-pathing the non-error case. Also removes tons of dead
|
||||
members and defines from lpfc_scsi.h - e.g. lpfc_target is down
|
||||
to nothing more then the lpfc_nodelist pointer.
|
||||
to nothing more than the lpfc_nodelist pointer.
|
||||
* Added binary sysfs file to issue mbox commands
|
||||
* Replaced #if __BIG_ENDIAN with #if __BIG_ENDIAN_BITFIELD for
|
||||
compatibility with the user space applications.
|
||||
|
|
|
@ -19,7 +19,7 @@ Sun Sep 24 21:30 2000 Gerard Roudier (groudier@club-internet.fr)
|
|||
|
||||
Wed Jul 26 23:30 2000 Gerard Roudier (groudier@club-internet.fr)
|
||||
* version ncr53c8xx-3.4.1
|
||||
- Provide OpenFirmare path through the proc FS on PPC.
|
||||
- Provide OpenFirmware path through the proc FS on PPC.
|
||||
- Remove trailing argument #2 from a couple of #undefs.
|
||||
|
||||
Sun Jul 09 16:30 2000 Gerard Roudier (groudier@club-internet.fr)
|
||||
|
|
|
@ -81,7 +81,7 @@ Sun Sep 24 21:30 2000 Gerard Roudier (groudier@club-internet.fr)
|
|||
|
||||
Wed Jul 26 23:30 2000 Gerard Roudier (groudier@club-internet.fr)
|
||||
* version sym53c8xx-1.7.1
|
||||
- Provide OpenFirmare path through the proc FS on PPC.
|
||||
- Provide OpenFirmware path through the proc FS on PPC.
|
||||
- Download of on-chip SRAM using memcpy_toio() doesn't work
|
||||
on PPC. Restore previous method (MEMORY MOVE from SCRIPTS).
|
||||
- Remove trailing argument #2 from a couple of #undefs.
|
||||
|
|
|
@ -13,10 +13,20 @@ Description
|
|||
This driver provides glue code connecting a National Semiconductor LM70 LLP
|
||||
temperature sensor evaluation board to the kernel's SPI core subsystem.
|
||||
|
||||
This is a SPI master controller driver. It can be used in conjunction with
|
||||
(layered under) the LM70 logical driver (a "SPI protocol driver").
|
||||
In effect, this driver turns the parallel port interface on the eval board
|
||||
into a SPI bus with a single device, which will be driven by the generic
|
||||
LM70 driver (drivers/hwmon/lm70.c).
|
||||
|
||||
|
||||
Hardware Interfacing
|
||||
--------------------
|
||||
The schematic for this particular board (the LM70EVAL-LLP) is
|
||||
available (on page 4) here:
|
||||
|
||||
http://www.national.com/appinfo/tempsensors/files/LM70LLPEVALmanual.pdf
|
||||
|
||||
The hardware interfacing on the LM70 LLP eval board is as follows:
|
||||
|
||||
Parallel LM70 LLP
|
||||
|
|
|
@ -41,7 +41,8 @@ Currently, these files are in /proc/sys/vm:
|
|||
|
||||
==============================================================
|
||||
|
||||
dirty_ratio, dirty_background_ratio, dirty_expire_centisecs,
|
||||
dirty_bytes, dirty_ratio, dirty_background_bytes,
|
||||
dirty_background_ratio, dirty_expire_centisecs,
|
||||
dirty_writeback_centisecs, highmem_is_dirtyable,
|
||||
vfs_cache_pressure, laptop_mode, block_dump, swap_token_timeout,
|
||||
drop-caches, hugepages_treat_as_movable:
|
||||
|
|
|
@ -313,11 +313,13 @@ three of the methods listed above. In addition, a driver indicates
|
|||
that it supports autosuspend by setting the .supports_autosuspend flag
|
||||
in its usb_driver structure. It is then responsible for informing the
|
||||
USB core whenever one of its interfaces becomes busy or idle. The
|
||||
driver does so by calling these three functions:
|
||||
driver does so by calling these five functions:
|
||||
|
||||
int usb_autopm_get_interface(struct usb_interface *intf);
|
||||
void usb_autopm_put_interface(struct usb_interface *intf);
|
||||
int usb_autopm_set_interface(struct usb_interface *intf);
|
||||
int usb_autopm_get_interface_async(struct usb_interface *intf);
|
||||
void usb_autopm_put_interface_async(struct usb_interface *intf);
|
||||
|
||||
The functions work by maintaining a counter in the usb_interface
|
||||
structure. When intf->pm_usage_count is > 0 then the interface is
|
||||
|
@ -330,10 +332,12 @@ associated with the device itself rather than any of its interfaces.
|
|||
This field is used only by the USB core.)
|
||||
|
||||
The driver owns intf->pm_usage_count; it can modify the value however
|
||||
and whenever it likes. A nice aspect of the usb_autopm_* routines is
|
||||
that the changes they make are protected by the usb_device structure's
|
||||
PM mutex (udev->pm_mutex); however drivers may change pm_usage_count
|
||||
without holding the mutex.
|
||||
and whenever it likes. A nice aspect of the non-async usb_autopm_*
|
||||
routines is that the changes they make are protected by the usb_device
|
||||
structure's PM mutex (udev->pm_mutex); however drivers may change
|
||||
pm_usage_count without holding the mutex. Drivers using the async
|
||||
routines are responsible for their own synchronization and mutual
|
||||
exclusion.
|
||||
|
||||
usb_autopm_get_interface() increments pm_usage_count and
|
||||
attempts an autoresume if the new value is > 0 and the
|
||||
|
@ -348,6 +352,14 @@ without holding the mutex.
|
|||
is suspended, and it attempts an autosuspend if the value is
|
||||
<= 0 and the device isn't suspended.
|
||||
|
||||
usb_autopm_get_interface_async() and
|
||||
usb_autopm_put_interface_async() do almost the same things as
|
||||
their non-async counterparts. The differences are: they do
|
||||
not acquire the PM mutex, and they use a workqueue to do their
|
||||
jobs. As a result they can be called in an atomic context,
|
||||
such as an URB's completion handler, but when they return the
|
||||
device will not generally not yet be in the desired state.
|
||||
|
||||
There also are a couple of utility routines drivers can use:
|
||||
|
||||
usb_autopm_enable() sets pm_usage_cnt to 0 and then calls
|
||||
|
|
|
@ -137,13 +137,6 @@ shrink_page_list() where they will be detected when vmscan walks the reverse
|
|||
map in try_to_unmap(). If try_to_unmap() returns SWAP_MLOCK, shrink_page_list()
|
||||
will cull the page at that point.
|
||||
|
||||
Note that for anonymous pages, shrink_page_list() attempts to add the page to
|
||||
the swap cache before it tries to unmap the page. To avoid this unnecessary
|
||||
consumption of swap space, shrink_page_list() calls try_to_munlock() to check
|
||||
whether any VM_LOCKED vmas map the page without attempting to unmap the page.
|
||||
If try_to_munlock() returns SWAP_MLOCK, shrink_page_list() will cull the page
|
||||
without consuming swap space. try_to_munlock() will be described below.
|
||||
|
||||
To "cull" an unevictable page, vmscan simply puts the page back on the lru
|
||||
list using putback_lru_page()--the inverse operation to isolate_lru_page()--
|
||||
after dropping the page lock. Because the condition which makes the page
|
||||
|
@ -190,8 +183,8 @@ several places:
|
|||
in the VM_LOCKED flag being set for the vma.
|
||||
3) in the fault path, if mlocked pages are "culled" in the fault path,
|
||||
and when a VM_LOCKED stack segment is expanded.
|
||||
4) as mentioned above, in vmscan:shrink_page_list() with attempting to
|
||||
reclaim a page in a VM_LOCKED vma--via try_to_unmap() or try_to_munlock().
|
||||
4) as mentioned above, in vmscan:shrink_page_list() when attempting to
|
||||
reclaim a page in a VM_LOCKED vma via try_to_unmap().
|
||||
|
||||
Mlocked pages become unlocked and rescued from the unevictable list when:
|
||||
|
||||
|
@ -260,9 +253,9 @@ mlock_fixup() filters several classes of "special" vmas:
|
|||
|
||||
2) vmas mapping hugetlbfs page are already effectively pinned into memory.
|
||||
We don't need nor want to mlock() these pages. However, to preserve the
|
||||
prior behavior of mlock()--before the unevictable/mlock changes--mlock_fixup()
|
||||
will call make_pages_present() in the hugetlbfs vma range to allocate the
|
||||
huge pages and populate the ptes.
|
||||
prior behavior of mlock()--before the unevictable/mlock changes--
|
||||
mlock_fixup() will call make_pages_present() in the hugetlbfs vma range
|
||||
to allocate the huge pages and populate the ptes.
|
||||
|
||||
3) vmas with VM_DONTEXPAND|VM_RESERVED are generally user space mappings of
|
||||
kernel pages, such as the vdso page, relay channel pages, etc. These pages
|
||||
|
@ -322,7 +315,7 @@ __mlock_vma_pages_range()--the same function used to mlock a vma range--
|
|||
passing a flag to indicate that munlock() is being performed.
|
||||
|
||||
Because the vma access protections could have been changed to PROT_NONE after
|
||||
faulting in and mlocking some pages, get_user_pages() was unreliable for visiting
|
||||
faulting in and mlocking pages, get_user_pages() was unreliable for visiting
|
||||
these pages for munlocking. Because we don't want to leave pages mlocked(),
|
||||
get_user_pages() was enhanced to accept a flag to ignore the permissions when
|
||||
fetching the pages--all of which should be resident as a result of previous
|
||||
|
@ -416,8 +409,8 @@ Mlocked Pages: munmap()/exit()/exec() System Call Handling
|
|||
When unmapping an mlocked region of memory, whether by an explicit call to
|
||||
munmap() or via an internal unmap from exit() or exec() processing, we must
|
||||
munlock the pages if we're removing the last VM_LOCKED vma that maps the pages.
|
||||
Before the unevictable/mlock changes, mlocking did not mark the pages in any way,
|
||||
so unmapping them required no processing.
|
||||
Before the unevictable/mlock changes, mlocking did not mark the pages in any
|
||||
way, so unmapping them required no processing.
|
||||
|
||||
To munlock a range of memory under the unevictable/mlock infrastructure, the
|
||||
munmap() hander and task address space tear down function call
|
||||
|
@ -517,12 +510,10 @@ couldn't be mlocked.
|
|||
Mlocked pages: try_to_munlock() Reverse Map Scan
|
||||
|
||||
TODO/FIXME: a better name might be page_mlocked()--analogous to the
|
||||
page_referenced() reverse map walker--especially if we continue to call this
|
||||
from shrink_page_list(). See related TODO/FIXME below.
|
||||
page_referenced() reverse map walker.
|
||||
|
||||
When munlock_vma_page()--see "Mlocked Pages: munlock()/munlockall() System
|
||||
Call Handling" above--tries to munlock a page, or when shrink_page_list()
|
||||
encounters an anonymous page that is not yet in the swap cache, they need to
|
||||
When munlock_vma_page()--see "Mlocked Pages: munlock()/munlockall()
|
||||
System Call Handling" above--tries to munlock a page, it needs to
|
||||
determine whether or not the page is mapped by any VM_LOCKED vma, without
|
||||
actually attempting to unmap all ptes from the page. For this purpose, the
|
||||
unevictable/mlock infrastructure introduced a variant of try_to_unmap() called
|
||||
|
@ -535,10 +526,7 @@ for VM_LOCKED vmas. When such a vma is found for anonymous pages and file
|
|||
pages mapped in linear VMAs, as in the try_to_unmap() case, the functions
|
||||
attempt to acquire the associated mmap semphore, mlock the page via
|
||||
mlock_vma_page() and return SWAP_MLOCK. This effectively undoes the
|
||||
pre-clearing of the page's PG_mlocked done by munlock_vma_page() and informs
|
||||
shrink_page_list() that the anonymous page should be culled rather than added
|
||||
to the swap cache in preparation for a try_to_unmap() that will almost
|
||||
certainly fail.
|
||||
pre-clearing of the page's PG_mlocked done by munlock_vma_page.
|
||||
|
||||
If try_to_unmap() is unable to acquire a VM_LOCKED vma's associated mmap
|
||||
semaphore, it will return SWAP_AGAIN. This will allow shrink_page_list()
|
||||
|
@ -557,10 +545,7 @@ However, the scan can terminate when it encounters a VM_LOCKED vma and can
|
|||
successfully acquire the vma's mmap semphore for read and mlock the page.
|
||||
Although try_to_munlock() can be called many [very many!] times when
|
||||
munlock()ing a large region or tearing down a large address space that has been
|
||||
mlocked via mlockall(), overall this is a fairly rare event. In addition,
|
||||
although shrink_page_list() calls try_to_munlock() for every anonymous page that
|
||||
it handles that is not yet in the swap cache, on average anonymous pages will
|
||||
have very short reverse map lists.
|
||||
mlocked via mlockall(), overall this is a fairly rare event.
|
||||
|
||||
Mlocked Page: Page Reclaim in shrink_*_list()
|
||||
|
||||
|
@ -588,8 +573,8 @@ Some examples of these unevictable pages on the LRU lists are:
|
|||
munlock_vma_page() was forced to let the page back on to the normal
|
||||
LRU list for vmscan to handle.
|
||||
|
||||
shrink_inactive_list() also culls any unevictable pages that it finds
|
||||
on the inactive lists, again diverting them to the appropriate zone's unevictable
|
||||
shrink_inactive_list() also culls any unevictable pages that it finds on
|
||||
the inactive lists, again diverting them to the appropriate zone's unevictable
|
||||
lru list. shrink_inactive_list() should only see SHM_LOCKed pages that became
|
||||
SHM_LOCKed after shrink_active_list() had moved them to the inactive list, or
|
||||
pages mapped into VM_LOCKED vmas that munlock_vma_page() couldn't isolate from
|
||||
|
@ -597,19 +582,7 @@ the lru to recheck via try_to_munlock(). shrink_inactive_list() won't notice
|
|||
the latter, but will pass on to shrink_page_list().
|
||||
|
||||
shrink_page_list() again culls obviously unevictable pages that it could
|
||||
encounter for similar reason to shrink_inactive_list(). As already discussed,
|
||||
shrink_page_list() proactively looks for anonymous pages that should have
|
||||
PG_mlocked set but don't--these would not be detected by page_evictable()--to
|
||||
avoid adding them to the swap cache unnecessarily. File pages mapped into
|
||||
encounter for similar reason to shrink_inactive_list(). Pages mapped into
|
||||
VM_LOCKED vmas but without PG_mlocked set will make it all the way to
|
||||
try_to_unmap(). shrink_page_list() will divert them to the unevictable list when
|
||||
try_to_unmap() returns SWAP_MLOCK, as discussed above.
|
||||
|
||||
TODO/FIXME: If we can enhance the swap cache to reliably remove entries
|
||||
with page_count(page) > 2, as long as all ptes are mapped to the page and
|
||||
not the swap entry, we can probably remove the call to try_to_munlock() in
|
||||
shrink_page_list() and just remove the page from the swap cache when
|
||||
try_to_unmap() returns SWAP_MLOCK. Currently, remove_exclusive_swap_page()
|
||||
doesn't seem to allow that.
|
||||
|
||||
|
||||
try_to_unmap(). shrink_page_list() will divert them to the unevictable list
|
||||
when try_to_unmap() returns SWAP_MLOCK, as discussed above.
|
||||
|
|
|
@ -0,0 +1,260 @@
|
|||
|
||||
Driver for the Intel Wireless Wimax Connection 2400m
|
||||
|
||||
(C) 2008 Intel Corporation < linux-wimax@intel.com >
|
||||
|
||||
This provides a driver for the Intel Wireless WiMAX Connection 2400m
|
||||
and a basic Linux kernel WiMAX stack.
|
||||
|
||||
1. Requirements
|
||||
|
||||
* Linux installation with Linux kernel 2.6.22 or newer (if building
|
||||
from a separate tree)
|
||||
* Intel i2400m Echo Peak or Baxter Peak; this includes the Intel
|
||||
Wireless WiMAX/WiFi Link 5x50 series.
|
||||
* build tools:
|
||||
+ Linux kernel development package for the target kernel; to
|
||||
build against your currently running kernel, you need to have
|
||||
the kernel development package corresponding to the running
|
||||
image installed (usually if your kernel is named
|
||||
linux-VERSION, the development package is called
|
||||
linux-dev-VERSION or linux-headers-VERSION).
|
||||
+ GNU C Compiler, make
|
||||
|
||||
2. Compilation and installation
|
||||
|
||||
2.1. Compilation of the drivers included in the kernel
|
||||
|
||||
Configure the kernel; to enable the WiMAX drivers select Drivers >
|
||||
Networking Drivers > WiMAX device support. Enable all of them as
|
||||
modules (easier).
|
||||
|
||||
If USB or SDIO are not enabled in the kernel configuration, the options
|
||||
to build the i2400m USB or SDIO drivers will not show. Enable said
|
||||
subsystems and go back to the WiMAX menu to enable the drivers.
|
||||
|
||||
Compile and install your kernel as usual.
|
||||
|
||||
2.2. Compilation of the drivers distributed as an standalone module
|
||||
|
||||
To compile
|
||||
|
||||
$ cd source/directory
|
||||
$ make
|
||||
|
||||
Once built you can load and unload using the provided load.sh script;
|
||||
load.sh will load the modules, load.sh u will unload them.
|
||||
|
||||
To install in the default kernel directories (and enable auto loading
|
||||
when the device is plugged):
|
||||
|
||||
$ make install
|
||||
$ depmod -a
|
||||
|
||||
If your kernel development files are located in a non standard
|
||||
directory or if you want to build for a kernel that is not the
|
||||
currently running one, set KDIR to the right location:
|
||||
|
||||
$ make KDIR=/path/to/kernel/dev/tree
|
||||
|
||||
For more information, please contact linux-wimax@intel.com.
|
||||
|
||||
3. Installing the firmware
|
||||
|
||||
The firmware can be obtained from http://linuxwimax.org or might have
|
||||
been supplied with your hardware.
|
||||
|
||||
It has to be installed in the target system:
|
||||
*
|
||||
$ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf
|
||||
|
||||
* NOTE: if your firmware came in an .rpm or .deb file, just install
|
||||
it as normal, with the rpm (rpm -i FIRMWARE.rpm) or dpkg
|
||||
(dpkg -i FIRMWARE.deb) commands. No further action is needed.
|
||||
* BUSTYPE will be usb or sdio, depending on the hardware you have.
|
||||
Each hardware type comes with its own firmware and will not work
|
||||
with other types.
|
||||
|
||||
4. Design
|
||||
|
||||
This package contains two major parts: a WiMAX kernel stack and a
|
||||
driver for the Intel i2400m.
|
||||
|
||||
The WiMAX stack is designed to provide for common WiMAX control
|
||||
services to current and future WiMAX devices from any vendor; please
|
||||
see README.wimax for details.
|
||||
|
||||
The i2400m kernel driver is broken up in two main parts: the bus
|
||||
generic driver and the bus-specific drivers. The bus generic driver
|
||||
forms the drivercore and contain no knowledge of the actual method we
|
||||
use to connect to the device. The bus specific drivers are just the
|
||||
glue to connect the bus-generic driver and the device. Currently only
|
||||
USB and SDIO are supported. See drivers/net/wimax/i2400m/i2400m.h for
|
||||
more information.
|
||||
|
||||
The bus generic driver is logically broken up in two parts: OS-glue and
|
||||
hardware-glue. The OS-glue interfaces with Linux. The hardware-glue
|
||||
interfaces with the device on using an interface provided by the
|
||||
bus-specific driver. The reason for this breakup is to be able to
|
||||
easily reuse the hardware-glue to write drivers for other OSes; note
|
||||
the hardware glue part is written as a native Linux driver; no
|
||||
abstraction layers are used, so to port to another OS, the Linux kernel
|
||||
API calls should be replaced with the target OS's.
|
||||
|
||||
5. Usage
|
||||
|
||||
To load the driver, follow the instructions in the install section;
|
||||
once the driver is loaded, plug in the device (unless it is permanently
|
||||
plugged in). The driver will enumerate the device, upload the firmware
|
||||
and output messages in the kernel log (dmesg, /var/log/messages or
|
||||
/var/log/kern.log) such as:
|
||||
|
||||
...
|
||||
i2400m_usb 5-4:1.0: firmware interface version 8.0.0
|
||||
i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready
|
||||
|
||||
At this point the device is ready to work.
|
||||
|
||||
Current versions require the Intel WiMAX Network Service in userspace
|
||||
to make things work. See the network service's README for instructions
|
||||
on how to scan, connect and disconnect.
|
||||
|
||||
5.1. Module parameters
|
||||
|
||||
Module parameters can be set at kernel or module load time or by
|
||||
echoing values:
|
||||
|
||||
$ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME
|
||||
|
||||
To make changes permanent, for example, for the i2400m module, you can
|
||||
also create a file named /etc/modprobe.d/i2400m containing:
|
||||
|
||||
options i2400m idle_mode_disabled=1
|
||||
|
||||
To find which parameters are supported by a module, run:
|
||||
|
||||
$ modinfo path/to/module.ko
|
||||
|
||||
During kernel bootup (if the driver is linked in the kernel), specify
|
||||
the following to the kernel command line:
|
||||
|
||||
i2400m.PARAMETER=VALUE
|
||||
|
||||
5.1.1. i2400m: idle_mode_disabled
|
||||
|
||||
The i2400m module supports a parameter to disable idle mode. This
|
||||
parameter, once set, will take effect only when the device is
|
||||
reinitialized by the driver (eg: following a reset or a reconnect).
|
||||
|
||||
5.2. Debug operations: debugfs entries
|
||||
|
||||
The driver will register debugfs entries that allow the user to tweak
|
||||
debug settings. There are three main container directories where
|
||||
entries are placed, which correspond to the three blocks a i2400m WiMAX
|
||||
driver has:
|
||||
* /sys/kernel/debug/wimax:DEVNAME/ for the generic WiMAX stack
|
||||
controls
|
||||
* /sys/kernel/debug/wimax:DEVNAME/i2400m for the i2400m generic
|
||||
driver controls
|
||||
* /sys/kernel/debug/wimax:DEVNAME/i2400m-usb (or -sdio) for the
|
||||
bus-specific i2400m-usb or i2400m-sdio controls).
|
||||
|
||||
Of course, if debugfs is mounted in a directory other than
|
||||
/sys/kernel/debug, those paths will change.
|
||||
|
||||
5.2.1. Increasing debug output
|
||||
|
||||
The files named *dl_* indicate knobs for controlling the debug output
|
||||
of different submodules:
|
||||
*
|
||||
# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_tx
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_rx
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_fw
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_driver
|
||||
/sys/kernel/debug/wimax:wmx0/i2400m/dl_control
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_stack
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs
|
||||
|
||||
By reading the file you can obtain the current value of said debug
|
||||
level; by writing to it, you can set it.
|
||||
|
||||
To increase the debug level of, for example, the i2400m's generic TX
|
||||
engine, just write:
|
||||
|
||||
$ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx
|
||||
|
||||
Increasing numbers yield increasing debug information; for details of
|
||||
what is printed and the available levels, check the source. The code
|
||||
uses 0 for disabled and increasing values until 8.
|
||||
|
||||
5.2.2. RX and TX statistics
|
||||
|
||||
The i2400m/rx_stats and i2400m/tx_stats provide statistics about the
|
||||
data reception/delivery from the device:
|
||||
|
||||
$ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats
|
||||
45 1 3 34 3104 48 480
|
||||
|
||||
The numbers reported are
|
||||
* packets/RX-buffer: total, min, max
|
||||
* RX-buffers: total RX buffers received, accumulated RX buffer size
|
||||
in bytes, min size received, max size received
|
||||
|
||||
Thus, to find the average buffer size received, divide accumulated
|
||||
RX-buffer / total RX-buffers.
|
||||
|
||||
To clear the statistics back to 0, write anything to the rx_stats file:
|
||||
|
||||
$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats
|
||||
|
||||
Likewise for TX.
|
||||
|
||||
Note the packets this debug file refers to are not network packet, but
|
||||
packets in the sense of the device-specific protocol for communication
|
||||
to the host. See drivers/net/wimax/i2400m/tx.c.
|
||||
|
||||
5.2.3. Tracing messages received from user space
|
||||
|
||||
To echo messages received from user space into the trace pipe that the
|
||||
i2400m driver creates, set the debug file i2400m/trace_msg_from_user to
|
||||
1:
|
||||
*
|
||||
$ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user
|
||||
|
||||
5.2.4. Performing a device reset
|
||||
|
||||
By writing a 0, a 1 or a 2 to the file
|
||||
/sys/kernel/debug/wimax:wmx0/reset, the driver performs a warm (without
|
||||
disconnecting from the bus), cold (disconnecting from the bus) or bus
|
||||
(bus specific) reset on the device.
|
||||
|
||||
5.2.5. Asking the device to enter power saving mode
|
||||
|
||||
By writing any value to the /sys/kernel/debug/wimax:wmx0 file, the
|
||||
device will attempt to enter power saving mode.
|
||||
|
||||
6. Troubleshooting
|
||||
|
||||
6.1. Driver complains about 'i2400m-fw-usb-1.2.sbcf: request failed'
|
||||
|
||||
If upon connecting the device, the following is output in the kernel
|
||||
log:
|
||||
|
||||
i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2
|
||||
|
||||
This means that the driver cannot locate the firmware file named
|
||||
/lib/firmware/i2400m-fw-usb-1.2.sbcf. Check that the file is present in
|
||||
the right location.
|
|
@ -0,0 +1,81 @@
|
|||
|
||||
Linux kernel WiMAX stack
|
||||
|
||||
(C) 2008 Intel Corporation < linux-wimax@intel.com >
|
||||
|
||||
This provides a basic Linux kernel WiMAX stack to provide a common
|
||||
control API for WiMAX devices, usable from kernel and user space.
|
||||
|
||||
1. Design
|
||||
|
||||
The WiMAX stack is designed to provide for common WiMAX control
|
||||
services to current and future WiMAX devices from any vendor.
|
||||
|
||||
Because currently there is only one and we don't know what would be the
|
||||
common services, the APIs it currently provides are very minimal.
|
||||
However, it is done in such a way that it is easily extensible to
|
||||
accommodate future requirements.
|
||||
|
||||
The stack works by embedding a struct wimax_dev in your device's
|
||||
control structures. This provides a set of callbacks that the WiMAX
|
||||
stack will call in order to implement control operations requested by
|
||||
the user. As well, the stack provides API functions that the driver
|
||||
calls to notify about changes of state in the device.
|
||||
|
||||
The stack exports the API calls needed to control the device to user
|
||||
space using generic netlink as a marshalling mechanism. You can access
|
||||
them using your own code or use the wrappers provided for your
|
||||
convenience in libwimax (in the wimax-tools package).
|
||||
|
||||
For detailed information on the stack, please see
|
||||
include/linux/wimax.h.
|
||||
|
||||
2. Usage
|
||||
|
||||
For usage in a driver (registration, API, etc) please refer to the
|
||||
instructions in the header file include/linux/wimax.h.
|
||||
|
||||
When a device is registered with the WiMAX stack, a set of debugfs
|
||||
files will appear in /sys/kernel/debug/wimax:wmxX can tweak for
|
||||
control.
|
||||
|
||||
2.1. Obtaining debug information: debugfs entries
|
||||
|
||||
The WiMAX stack is compiled, by default, with debug messages that can
|
||||
be used to diagnose issues. By default, said messages are disabled.
|
||||
|
||||
The drivers will register debugfs entries that allow the user to tweak
|
||||
debug settings.
|
||||
|
||||
Each driver, when registering with the stack, will cause a debugfs
|
||||
directory named wimax:DEVICENAME to be created; optionally, it might
|
||||
create more subentries below it.
|
||||
|
||||
2.1.1. Increasing debug output
|
||||
|
||||
The files named *dl_* indicate knobs for controlling the debug output
|
||||
of different submodules of the WiMAX stack:
|
||||
*
|
||||
# find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\*
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_stack
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
|
||||
/sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs
|
||||
/sys/kernel/debug/wimax:wmx0/.... # other driver specific files
|
||||
|
||||
NOTE: Of course, if debugfs is mounted in a directory other than
|
||||
/sys/kernel/debug, those paths will change.
|
||||
|
||||
By reading the file you can obtain the current value of said debug
|
||||
level; by writing to it, you can set it.
|
||||
|
||||
To increase the debug level of, for example, the id-table submodule,
|
||||
just write:
|
||||
|
||||
$ echo 3 > /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table
|
||||
|
||||
Increasing numbers yield increasing debug information; for details of
|
||||
what is printed and the available levels, check the source. The code
|
||||
uses 0 for disabled and increasing values until 8.
|
|
@ -3,7 +3,7 @@ protocol of kernel. These should be filled by bootloader or 16-bit
|
|||
real-mode setup code of the kernel. References/settings to it mainly
|
||||
are in:
|
||||
|
||||
include/asm-x86/bootparam.h
|
||||
arch/x86/include/asm/bootparam.h
|
||||
|
||||
|
||||
Offset Proto Name Meaning
|
||||
|
|
94
MAINTAINERS
94
MAINTAINERS
|
@ -616,7 +616,7 @@ M: mkpetch@internode.on.net
|
|||
S: Maintained
|
||||
|
||||
ARM/TOSA MACHINE SUPPORT
|
||||
P: Dmitry Baryshkov
|
||||
P: Dmitry Eremin-Solenikov
|
||||
M: dbaryshkov@gmail.com
|
||||
P: Dirk Opfer
|
||||
M: dirk@opfer-online.de
|
||||
|
@ -1024,16 +1024,17 @@ S: Maintained
|
|||
BTTV VIDEO4LINUX DRIVER
|
||||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@infradead.org
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
L: linux-media@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linuxtv.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
CAFE CMOS INTEGRATED CAMERA CONTROLLER DRIVER
|
||||
P: Jonathan Corbet
|
||||
M: corbet@lwn.net
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
CALGARY x86-64 IOMMU
|
||||
|
@ -1092,11 +1093,8 @@ S: Maintained
|
|||
|
||||
CHECKPATCH
|
||||
P: Andy Whitcroft
|
||||
M: apw@shadowen.org
|
||||
P: Randy Dunlap
|
||||
M: rdunlap@xenotime.net
|
||||
P: Joel Schopp
|
||||
M: jschopp@austin.ibm.com
|
||||
M: apw@canonical.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Supported
|
||||
|
||||
CISCO 10G ETHERNET DRIVER
|
||||
|
@ -1264,7 +1262,8 @@ P: Hans Verkuil, Andy Walls
|
|||
M: hverkuil@xs4all.nl, awalls@radix.net
|
||||
L: ivtv-devel@ivtvdriver.org
|
||||
L: ivtv-users@ivtvdriver.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://linuxtv.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -1490,10 +1489,10 @@ S: Maintained
|
|||
|
||||
DVB SUBSYSTEM AND DRIVERS
|
||||
P: LinuxTV.org Project
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
M: linux-media@vger.kernel.org
|
||||
L: linux-dvb@linuxtv.org (subscription required)
|
||||
W: http://linuxtv.org/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
DZ DECSTATION DZ11 SERIAL DRIVER
|
||||
|
@ -1885,32 +1884,37 @@ S: Maintained
|
|||
GSPCA FINEPIX SUBDRIVER
|
||||
P: Frank Zago
|
||||
M: frank@zago.net
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
GSPCA M5602 SUBDRIVER
|
||||
P: Erik Andren
|
||||
M: erik.andren@gmail.com
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
GSPCA PAC207 SONIXB SUBDRIVER
|
||||
P: Hans de Goede
|
||||
M: hdegoede@redhat.com
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
GSPCA T613 SUBDRIVER
|
||||
P: Leandro Costantino
|
||||
M: lcostantino@gmail.com
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
GSPCA USB WEBCAM DRIVER
|
||||
P: Jean-Francois Moine
|
||||
M: moinejf@free.fr
|
||||
W: http://moinejf.free.fr
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
HARDWARE MONITORING
|
||||
|
@ -2308,6 +2312,14 @@ W: http://lists.sourceforge.net/mailman/listinfo/ipw2100-devel
|
|||
W: http://ipw2200.sourceforge.net
|
||||
S: Supported
|
||||
|
||||
INTEL WIRELESS WIMAX CONNECTION 2400
|
||||
P: Inaky Perez-Gonzalez
|
||||
M: inaky.perez-gonzalez@intel.com
|
||||
M: linux-wimax@intel.com
|
||||
L: wimax@linuxwimax.org
|
||||
S: Supported
|
||||
W: http://linuxwimax.org
|
||||
|
||||
INTEL WIRELESS WIFI LINK (iwlwifi)
|
||||
P: Zhu Yi
|
||||
M: yi.zhu@intel.com
|
||||
|
@ -2432,7 +2444,8 @@ P: Hans Verkuil
|
|||
M: hverkuil@xs4all.nl
|
||||
L: ivtv-devel@ivtvdriver.org
|
||||
L: ivtv-users@ivtvdriver.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.ivtvdriver.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -2985,6 +2998,7 @@ MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER
|
|||
P: Felipe Balbi
|
||||
M: felipe.balbi@nokia.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
T: git gitorious.org:/musb/mainline.git
|
||||
S: Maintained
|
||||
|
||||
MYRICOM MYRI-10G 10GbE DRIVER (MYRI10GE)
|
||||
|
@ -3191,7 +3205,8 @@ S: Maintained
|
|||
OMNIVISION OV7670 SENSOR DRIVER
|
||||
P: Jonathan Corbet
|
||||
M: corbet@lwn.net
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
ONENAND FLASH DRIVER
|
||||
|
@ -3473,8 +3488,9 @@ PVRUSB2 VIDEO4LINUX DRIVER
|
|||
P: Mike Isely
|
||||
M: isely@pobox.com
|
||||
L: pvrusb2@isely.net (subscribers-only)
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
W: http://www.isely.net/pvrusb2/
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
PXA2xx/PXA3xx SUPPORT
|
||||
|
@ -3694,6 +3710,8 @@ S: Supported
|
|||
SAA7146 VIDEO4LINUX-2 DRIVER
|
||||
P: Michael Hunold
|
||||
M: michael@mihu.de
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.mihu.de/linux/saa7146
|
||||
S: Maintained
|
||||
|
||||
|
@ -3957,7 +3975,8 @@ S: Maintained
|
|||
SOC-CAMERA V4L2 SUBSYSTEM
|
||||
P: Guennadi Liakhovetski
|
||||
M: g.liakhovetski@gmx.de
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
SOEKRIS NET48XX LED SUPPORT
|
||||
|
@ -4232,9 +4251,10 @@ L: tpmdd-devel@lists.sourceforge.net (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
|
||||
TRIVIAL PATCHES
|
||||
P: Jesper Juhl
|
||||
P: Jiri Kosina
|
||||
M: trivial@kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/jikos/trivial.git
|
||||
S: Maintained
|
||||
|
||||
TTY LAYER
|
||||
|
@ -4375,7 +4395,8 @@ USB ET61X[12]51 DRIVER
|
|||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -4524,7 +4545,8 @@ USB SN9C1xx DRIVER
|
|||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -4553,7 +4575,8 @@ USB VIDEO CLASS
|
|||
P: Laurent Pinchart
|
||||
M: laurent.pinchart@skynet.be
|
||||
L: linux-uvc-devel@lists.berlios.de (subscribers-only)
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://linux-uvc.berlios.de
|
||||
S: Maintained
|
||||
|
||||
|
@ -4561,7 +4584,8 @@ USB W996[87]CF DRIVER
|
|||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -4575,7 +4599,8 @@ USB ZC0301 DRIVER
|
|||
P: Luca Risolia
|
||||
M: luca.risolia@studio.unibo.it
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://www.linux-projects.org
|
||||
S: Maintained
|
||||
|
||||
|
@ -4590,7 +4615,8 @@ USB ZR364XX DRIVER
|
|||
P: Antoine Jacquet
|
||||
M: royale@zerezo.com
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
W: http://royale.zerezo.com/zr364xx/
|
||||
S: Maintained
|
||||
|
||||
|
@ -4659,10 +4685,10 @@ S: Maintained
|
|||
VIDEO FOR LINUX (V4L)
|
||||
P: Mauro Carvalho Chehab
|
||||
M: mchehab@infradead.org
|
||||
M: v4l-dvb-maintainer@linuxtv.org
|
||||
L: linux-media@vger.kernel.org
|
||||
L: video4linux-list@redhat.com
|
||||
W: http://linuxtv.org
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
|
||||
T: git kernel.org:/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
|
||||
VLAN (802.1Q)
|
||||
|
@ -4735,6 +4761,14 @@ M: zaga@fly.cc.fer.hr
|
|||
L: linux-scsi@vger.kernel.org
|
||||
S: Maintained
|
||||
|
||||
WIMAX STACK
|
||||
P: Inaky Perez-Gonzalez
|
||||
M: inaky.perez-gonzalez@intel.com
|
||||
M: linux-wimax@intel.com
|
||||
L: wimax@linuxwimax.org
|
||||
S: Supported
|
||||
W: http://linuxwimax.org
|
||||
|
||||
WIMEDIA LLC PROTOCOL (WLP) SUBSYSTEM
|
||||
P: David Vrabel
|
||||
M: david.vrabel@csr.com
|
||||
|
|
3
Makefile
3
Makefile
|
@ -965,6 +965,7 @@ ifneq ($(KBUILD_SRC),)
|
|||
mkdir -p include2; \
|
||||
ln -fsn $(srctree)/include/asm-$(SRCARCH) include2/asm; \
|
||||
fi
|
||||
ln -fsn $(srctree) source
|
||||
endif
|
||||
|
||||
# prepare2 creates a makefile if using a separate output directory
|
||||
|
@ -1008,7 +1009,7 @@ define check-symlink
|
|||
endef
|
||||
|
||||
# We create the target directory of the symlink if it does
|
||||
# not exist so the test in chack-symlink works and we have a
|
||||
# not exist so the test in check-symlink works and we have a
|
||||
# directory for generated filesas used by some architectures.
|
||||
define create-symlink
|
||||
if [ ! -L include/asm ]; then \
|
||||
|
|
|
@ -9,3 +9,4 @@ unifdef-y += console.h
|
|||
unifdef-y += fpu.h
|
||||
unifdef-y += sysinfo.h
|
||||
unifdef-y += compiler.h
|
||||
unifdef-y += swab.h
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
#ifndef _ALPHA_ATOMIC_H
|
||||
#define _ALPHA_ATOMIC_H
|
||||
|
||||
#include <linux/types.h>
|
||||
#include <asm/barrier.h>
|
||||
#include <asm/system.h>
|
||||
|
||||
|
@ -13,14 +14,6 @@
|
|||
*/
|
||||
|
||||
|
||||
/*
|
||||
* Counter is volatile to make sure gcc doesn't try to be clever
|
||||
* and move things around on us. We need to use _exactly_ the address
|
||||
* the user gave us, not some alias that contains the same information.
|
||||
*/
|
||||
typedef struct { volatile int counter; } atomic_t;
|
||||
typedef struct { volatile long counter; } atomic64_t;
|
||||
|
||||
#define ATOMIC_INIT(i) ( (atomic_t) { (i) } )
|
||||
#define ATOMIC64_INIT(i) ( (atomic64_t) { (i) } )
|
||||
|
||||
|
|
|
@ -1,47 +1,7 @@
|
|||
#ifndef _ALPHA_BYTEORDER_H
|
||||
#define _ALPHA_BYTEORDER_H
|
||||
|
||||
#include <asm/types.h>
|
||||
#include <linux/compiler.h>
|
||||
#include <asm/compiler.h>
|
||||
|
||||
#ifdef __GNUC__
|
||||
|
||||
static inline __attribute_const__ __u32 __arch__swab32(__u32 x)
|
||||
{
|
||||
/*
|
||||
* Unfortunately, we can't use the 6 instruction sequence
|
||||
* on ev6 since the latency of the UNPKBW is 3, which is
|
||||
* pretty hard to hide. Just in case a future implementation
|
||||
* has a lower latency, here's the sequence (also by Mike Burrows)
|
||||
*
|
||||
* UNPKBW a0, v0 v0: 00AA00BB00CC00DD
|
||||
* SLL v0, 24, a0 a0: BB00CC00DD000000
|
||||
* BIS v0, a0, a0 a0: BBAACCBBDDCC00DD
|
||||
* EXTWL a0, 6, v0 v0: 000000000000BBAA
|
||||
* ZAP a0, 0xf3, a0 a0: 00000000DDCC0000
|
||||
* ADDL a0, v0, v0 v0: ssssssssDDCCBBAA
|
||||
*/
|
||||
|
||||
__u64 t0, t1, t2, t3;
|
||||
|
||||
t0 = __kernel_inslh(x, 7); /* t0 : 0000000000AABBCC */
|
||||
t1 = __kernel_inswl(x, 3); /* t1 : 000000CCDD000000 */
|
||||
t1 |= t0; /* t1 : 000000CCDDAABBCC */
|
||||
t2 = t1 >> 16; /* t2 : 0000000000CCDDAA */
|
||||
t0 = t1 & 0xFF00FF00; /* t0 : 00000000DD00BB00 */
|
||||
t3 = t2 & 0x00FF00FF; /* t3 : 0000000000CC00AA */
|
||||
t1 = t0 + t3; /* t1 : ssssssssDDCCBBAA */
|
||||
|
||||
return t1;
|
||||
}
|
||||
|
||||
#define __arch__swab32 __arch__swab32
|
||||
|
||||
#endif /* __GNUC__ */
|
||||
|
||||
#define __BYTEORDER_HAS_U64__
|
||||
|
||||
#include <asm/swab.h>
|
||||
#include <linux/byteorder/little_endian.h>
|
||||
|
||||
#endif /* _ALPHA_BYTEORDER_H */
|
||||
|
|
|
@ -0,0 +1,42 @@
|
|||
#ifndef _ALPHA_SWAB_H
|
||||
#define _ALPHA_SWAB_H
|
||||
|
||||
#include <asm/types.h>
|
||||
#include <linux/compiler.h>
|
||||
#include <asm/compiler.h>
|
||||
|
||||
#ifdef __GNUC__
|
||||
|
||||
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
|
||||
{
|
||||
/*
|
||||
* Unfortunately, we can't use the 6 instruction sequence
|
||||
* on ev6 since the latency of the UNPKBW is 3, which is
|
||||
* pretty hard to hide. Just in case a future implementation
|
||||
* has a lower latency, here's the sequence (also by Mike Burrows)
|
||||
*
|
||||
* UNPKBW a0, v0 v0: 00AA00BB00CC00DD
|
||||
* SLL v0, 24, a0 a0: BB00CC00DD000000
|
||||
* BIS v0, a0, a0 a0: BBAACCBBDDCC00DD
|
||||
* EXTWL a0, 6, v0 v0: 000000000000BBAA
|
||||
* ZAP a0, 0xf3, a0 a0: 00000000DDCC0000
|
||||
* ADDL a0, v0, v0 v0: ssssssssDDCCBBAA
|
||||
*/
|
||||
|
||||
__u64 t0, t1, t2, t3;
|
||||
|
||||
t0 = __kernel_inslh(x, 7); /* t0 : 0000000000AABBCC */
|
||||
t1 = __kernel_inswl(x, 3); /* t1 : 000000CCDD000000 */
|
||||
t1 |= t0; /* t1 : 000000CCDDAABBCC */
|
||||
t2 = t1 >> 16; /* t2 : 0000000000CCDDAA */
|
||||
t0 = t1 & 0xFF00FF00; /* t0 : 00000000DD00BB00 */
|
||||
t3 = t2 & 0x00FF00FF; /* t3 : 0000000000CC00AA */
|
||||
t1 = t0 + t3; /* t1 : ssssssssDDCCBBAA */
|
||||
|
||||
return t1;
|
||||
}
|
||||
#define __arch_swab32 __arch_swab32
|
||||
|
||||
#endif /* __GNUC__ */
|
||||
|
||||
#endif /* _ALPHA_SWAB_H */
|
|
@ -320,24 +320,6 @@ pcibios_update_irq(struct pci_dev *dev, int irq)
|
|||
pci_write_config_byte(dev, PCI_INTERRUPT_LINE, irq);
|
||||
}
|
||||
|
||||
/* Most Alphas have straight-forward swizzling needs. */
|
||||
|
||||
u8 __init
|
||||
common_swizzle(struct pci_dev *dev, u8 *pinp)
|
||||
{
|
||||
u8 pin = *pinp;
|
||||
|
||||
while (dev->bus->parent) {
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn));
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
}
|
||||
*pinp = pin;
|
||||
|
||||
/* The slot is the slot of the last bridge. */
|
||||
return PCI_SLOT(dev->devfn);
|
||||
}
|
||||
|
||||
void
|
||||
pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
|
||||
struct resource *res)
|
||||
|
|
|
@ -106,16 +106,11 @@ struct pci_iommu_arena;
|
|||
* Where A = pin 1, B = pin 2 and so on and pin=0 = default = A.
|
||||
* Thus, each swizzle is ((pin-1) + (device#-4)) % 4
|
||||
*
|
||||
* The following code swizzles for exactly one bridge. The routine
|
||||
* common_swizzle below handles multiple bridges. But there are a
|
||||
* couple boards that do strange things, so we define this here.
|
||||
* pci_swizzle_interrupt_pin() swizzles for exactly one bridge. The routine
|
||||
* pci_common_swizzle() handles multiple bridges. But there are a
|
||||
* couple boards that do strange things.
|
||||
*/
|
||||
|
||||
static inline u8 bridge_swizzle(u8 pin, u8 slot)
|
||||
{
|
||||
return (((pin-1) + slot) % 4) + 1;
|
||||
}
|
||||
|
||||
|
||||
/* The following macro is used to implement the table-based irq mapping
|
||||
function for all single-bus Alphas. */
|
||||
|
@ -184,7 +179,7 @@ extern int pci_probe_only;
|
|||
extern unsigned long alpha_agpgart_size;
|
||||
|
||||
extern void common_init_pci(void);
|
||||
extern u8 common_swizzle(struct pci_dev *, u8 *);
|
||||
#define common_swizzle pci_common_swizzle
|
||||
extern struct pci_controller *alloc_pci_controller(void);
|
||||
extern struct resource *alloc_resource(void);
|
||||
|
||||
|
|
|
@ -481,7 +481,7 @@ monet_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
slot = PCI_SLOT(dev->devfn);
|
||||
break;
|
||||
}
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn)) ;
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
|
|
|
@ -204,7 +204,7 @@ eiger_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
break;
|
||||
}
|
||||
/* Must be a card-based bridge. */
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn));
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
|
|
|
@ -219,7 +219,7 @@ miata_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
slot = PCI_SLOT(dev->devfn) + 9;
|
||||
break;
|
||||
}
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn));
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
|
|
|
@ -257,7 +257,7 @@ noritake_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
slot = PCI_SLOT(dev->devfn) + 15;
|
||||
break;
|
||||
}
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn)) ;
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
|
|
|
@ -160,7 +160,7 @@ ruffian_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
slot = PCI_SLOT(dev->devfn) + 10;
|
||||
break;
|
||||
}
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn));
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
|
|
|
@ -425,7 +425,7 @@ lynx_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
slot = PCI_SLOT(dev->devfn) + 11;
|
||||
break;
|
||||
}
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn)) ;
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
|
||||
/* Move up the chain of bridges. */
|
||||
dev = dev->bus->self;
|
||||
|
|
|
@ -1325,6 +1325,8 @@ source "drivers/regulator/Kconfig"
|
|||
|
||||
source "drivers/uio/Kconfig"
|
||||
|
||||
source "drivers/staging/Kconfig"
|
||||
|
||||
endmenu
|
||||
|
||||
source "fs/Kconfig"
|
||||
|
|
|
@ -1,3 +1,4 @@
|
|||
include include/asm-generic/Kbuild.asm
|
||||
|
||||
unifdef-y += hwcap.h
|
||||
unifdef-y += swab.h
|
||||
|
|
|
@ -12,10 +12,9 @@
|
|||
#define __ASM_ARM_ATOMIC_H
|
||||
|
||||
#include <linux/compiler.h>
|
||||
#include <linux/types.h>
|
||||
#include <asm/system.h>
|
||||
|
||||
typedef struct { volatile int counter; } atomic_t;
|
||||
|
||||
#define ATOMIC_INIT(i) { (i) }
|
||||
|
||||
#ifdef __KERNEL__
|
||||
|
|
|
@ -15,38 +15,7 @@
|
|||
#ifndef __ASM_ARM_BYTEORDER_H
|
||||
#define __ASM_ARM_BYTEORDER_H
|
||||
|
||||
#include <linux/compiler.h>
|
||||
#include <asm/types.h>
|
||||
|
||||
static inline __attribute_const__ __u32 ___arch__swab32(__u32 x)
|
||||
{
|
||||
__u32 t;
|
||||
|
||||
#ifndef __thumb__
|
||||
if (!__builtin_constant_p(x)) {
|
||||
/*
|
||||
* The compiler needs a bit of a hint here to always do the
|
||||
* right thing and not screw it up to different degrees
|
||||
* depending on the gcc version.
|
||||
*/
|
||||
asm ("eor\t%0, %1, %1, ror #16" : "=r" (t) : "r" (x));
|
||||
} else
|
||||
#endif
|
||||
t = x ^ ((x << 16) | (x >> 16)); /* eor r1,r0,r0,ror #16 */
|
||||
|
||||
x = (x << 24) | (x >> 8); /* mov r0,r0,ror #8 */
|
||||
t &= ~0x00FF0000; /* bic r1,r1,#0x00FF0000 */
|
||||
x ^= (t >> 8); /* eor r0,r0,r1,lsr #8 */
|
||||
|
||||
return x;
|
||||
}
|
||||
|
||||
#define __arch__swab32(x) ___arch__swab32(x)
|
||||
|
||||
#if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
|
||||
# define __BYTEORDER_HAS_U64__
|
||||
# define __SWAB_64_THRU_32__
|
||||
#endif
|
||||
#include <asm/swab.h>
|
||||
|
||||
#ifdef __ARMEB__
|
||||
#include <linux/byteorder/big_endian.h>
|
||||
|
|
|
@ -42,7 +42,7 @@ struct pci_sys_data {
|
|||
/*
|
||||
* This is the standard PCI-PCI bridge swizzling algorithm.
|
||||
*/
|
||||
u8 pci_std_swizzle(struct pci_dev *dev, u8 *pinp);
|
||||
#define pci_std_swizzle pci_common_swizzle
|
||||
|
||||
/*
|
||||
* Call this with your hw_pci struct to initialise the PCI system.
|
||||
|
|
|
@ -0,0 +1,50 @@
|
|||
/*
|
||||
* arch/arm/include/asm/byteorder.h
|
||||
*
|
||||
* ARM Endian-ness. In little endian mode, the data bus is connected such
|
||||
* that byte accesses appear as:
|
||||
* 0 = d0...d7, 1 = d8...d15, 2 = d16...d23, 3 = d24...d31
|
||||
* and word accesses (data or instruction) appear as:
|
||||
* d0...d31
|
||||
*
|
||||
* When in big endian mode, byte accesses appear as:
|
||||
* 0 = d24...d31, 1 = d16...d23, 2 = d8...d15, 3 = d0...d7
|
||||
* and word accesses (data or instruction) appear as:
|
||||
* d0...d31
|
||||
*/
|
||||
#ifndef __ASM_ARM_SWAB_H
|
||||
#define __ASM_ARM_SWAB_H
|
||||
|
||||
#include <linux/compiler.h>
|
||||
#include <asm/types.h>
|
||||
|
||||
#if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
|
||||
# define __SWAB_64_THRU_32__
|
||||
#endif
|
||||
|
||||
static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
|
||||
{
|
||||
__u32 t;
|
||||
|
||||
#ifndef __thumb__
|
||||
if (!__builtin_constant_p(x)) {
|
||||
/*
|
||||
* The compiler needs a bit of a hint here to always do the
|
||||
* right thing and not screw it up to different degrees
|
||||
* depending on the gcc version.
|
||||
*/
|
||||
asm ("eor\t%0, %1, %1, ror #16" : "=r" (t) : "r" (x));
|
||||
} else
|
||||
#endif
|
||||
t = x ^ ((x << 16) | (x >> 16)); /* eor r1,r0,r0,ror #16 */
|
||||
|
||||
x = (x << 24) | (x >> 8); /* mov r0,r0,ror #8 */
|
||||
t &= ~0x00FF0000; /* bic r1,r1,#0x00FF0000 */
|
||||
x ^= (t >> 8); /* eor r0,r0,r1,lsr #8 */
|
||||
|
||||
return x;
|
||||
}
|
||||
#define __arch_swab32 __arch_swab32
|
||||
|
||||
#endif
|
||||
|
|
@ -479,33 +479,6 @@ EXPORT_SYMBOL(pcibios_resource_to_bus);
|
|||
EXPORT_SYMBOL(pcibios_bus_to_resource);
|
||||
#endif
|
||||
|
||||
/*
|
||||
* This is the standard PCI-PCI bridge swizzling algorithm:
|
||||
*
|
||||
* Dev: 0 1 2 3
|
||||
* A A B C D
|
||||
* B B C D A
|
||||
* C C D A B
|
||||
* D D A B C
|
||||
* ^^^^^^^^^^ irq pin on bridge
|
||||
*/
|
||||
u8 __devinit pci_std_swizzle(struct pci_dev *dev, u8 *pinp)
|
||||
{
|
||||
int pin = *pinp - 1;
|
||||
|
||||
while (dev->bus->self) {
|
||||
pin = (pin + PCI_SLOT(dev->devfn)) & 3;
|
||||
/*
|
||||
* move up the chain of bridges,
|
||||
* swizzling as we go.
|
||||
*/
|
||||
dev = dev->bus->self;
|
||||
}
|
||||
*pinp = pin + 1;
|
||||
|
||||
return PCI_SLOT(dev->devfn);
|
||||
}
|
||||
|
||||
/*
|
||||
* Swizzle the device pin each time we cross a bridge.
|
||||
* This might update pin and returns the slot number.
|
||||
|
|
|
@ -817,7 +817,7 @@ static struct expansion_card *__init ecard_alloc_card(int type, int slot)
|
|||
ec->dma = NO_DMA;
|
||||
ec->ops = &ecard_default_ops;
|
||||
|
||||
snprintf(ec->dev.bus_id, sizeof(ec->dev.bus_id), "ecard%d", slot);
|
||||
dev_set_name(&ec->dev, "ecard%d", slot);
|
||||
ec->dev.parent = NULL;
|
||||
ec->dev.bus = &ecard_bus_type;
|
||||
ec->dev.dma_mask = &ec->dma_mask;
|
||||
|
|
|
@ -92,9 +92,7 @@ void __kprobes arch_disarm_kprobe(struct kprobe *p)
|
|||
void __kprobes arch_remove_kprobe(struct kprobe *p)
|
||||
{
|
||||
if (p->ainsn.insn) {
|
||||
mutex_lock(&kprobe_mutex);
|
||||
free_insn_slot(p->ainsn.insn, 0);
|
||||
mutex_unlock(&kprobe_mutex);
|
||||
p->ainsn.insn = NULL;
|
||||
}
|
||||
}
|
||||
|
|
|
@ -212,7 +212,7 @@ static struct clcd_board clcd_plat_data = {
|
|||
|
||||
static struct amba_device clcd_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:16",
|
||||
.init_name = "mb:16",
|
||||
.coherent_dma_mask = ~0,
|
||||
.platform_data = &clcd_plat_data,
|
||||
},
|
||||
|
|
|
@ -409,7 +409,7 @@ static struct amba_pl010_data ep93xx_uart_data = {
|
|||
|
||||
static struct amba_device uart1_device = {
|
||||
.dev = {
|
||||
.bus_id = "apb:uart1",
|
||||
.init_name = "apb:uart1",
|
||||
.platform_data = &ep93xx_uart_data,
|
||||
},
|
||||
.res = {
|
||||
|
@ -423,7 +423,7 @@ static struct amba_device uart1_device = {
|
|||
|
||||
static struct amba_device uart2_device = {
|
||||
.dev = {
|
||||
.bus_id = "apb:uart2",
|
||||
.init_name = "apb:uart2",
|
||||
.platform_data = &ep93xx_uart_data,
|
||||
},
|
||||
.res = {
|
||||
|
@ -437,7 +437,7 @@ static struct amba_device uart2_device = {
|
|||
|
||||
static struct amba_device uart3_device = {
|
||||
.dev = {
|
||||
.bus_id = "apb:uart3",
|
||||
.init_name = "apb:uart3",
|
||||
.platform_data = &ep93xx_uart_data,
|
||||
},
|
||||
.res = {
|
||||
|
|
|
@ -37,7 +37,7 @@ static struct amba_pl010_data integrator_uart_data;
|
|||
|
||||
static struct amba_device rtc_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:15",
|
||||
.init_name = "mb:15",
|
||||
},
|
||||
.res = {
|
||||
.start = INTEGRATOR_RTC_BASE,
|
||||
|
@ -50,7 +50,7 @@ static struct amba_device rtc_device = {
|
|||
|
||||
static struct amba_device uart0_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:16",
|
||||
.init_name = "mb:16",
|
||||
.platform_data = &integrator_uart_data,
|
||||
},
|
||||
.res = {
|
||||
|
@ -64,7 +64,7 @@ static struct amba_device uart0_device = {
|
|||
|
||||
static struct amba_device uart1_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:17",
|
||||
.init_name = "mb:17",
|
||||
.platform_data = &integrator_uart_data,
|
||||
},
|
||||
.res = {
|
||||
|
@ -78,7 +78,7 @@ static struct amba_device uart1_device = {
|
|||
|
||||
static struct amba_device kmi0_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:18",
|
||||
.init_name = "mb:18",
|
||||
},
|
||||
.res = {
|
||||
.start = KMI0_BASE,
|
||||
|
@ -91,7 +91,7 @@ static struct amba_device kmi0_device = {
|
|||
|
||||
static struct amba_device kmi1_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:19",
|
||||
.init_name = "mb:19",
|
||||
},
|
||||
.res = {
|
||||
.start = KMI1_BASE,
|
||||
|
|
|
@ -407,7 +407,7 @@ static struct mmc_platform_data mmc_data = {
|
|||
|
||||
static struct amba_device mmc_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:1c",
|
||||
.init_name = "mb:1c",
|
||||
.platform_data = &mmc_data,
|
||||
},
|
||||
.res = {
|
||||
|
@ -421,7 +421,7 @@ static struct amba_device mmc_device = {
|
|||
|
||||
static struct amba_device aaci_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:1d",
|
||||
.init_name = "mb:1d",
|
||||
},
|
||||
.res = {
|
||||
.start = INTCP_PA_AACI_BASE,
|
||||
|
@ -532,7 +532,7 @@ static struct clcd_board clcd_data = {
|
|||
|
||||
static struct amba_device clcd_device = {
|
||||
.dev = {
|
||||
.bus_id = "mb:c0",
|
||||
.init_name = "mb:c0",
|
||||
.coherent_dma_mask = ~0,
|
||||
.platform_data = &clcd_data,
|
||||
},
|
||||
|
|
|
@ -63,13 +63,7 @@
|
|||
*
|
||||
* Where A = pin 1, B = pin 2 and so on and pin=0 = default = A.
|
||||
* Thus, each swizzle is ((pin-1) + (device#-4)) % 4
|
||||
*
|
||||
* The following code swizzles for exactly one bridge.
|
||||
*/
|
||||
static inline int bridge_swizzle(int pin, unsigned int slot)
|
||||
{
|
||||
return (pin + slot) & 3;
|
||||
}
|
||||
|
||||
/*
|
||||
* This routine handles multiple bridges.
|
||||
|
@ -81,15 +75,14 @@ static u8 __init integrator_swizzle(struct pci_dev *dev, u8 *pinp)
|
|||
if (pin == 0)
|
||||
pin = 1;
|
||||
|
||||
pin -= 1;
|
||||
while (dev->bus->self) {
|
||||
pin = bridge_swizzle(pin, PCI_SLOT(dev->devfn));
|
||||
pin = pci_swizzle_interrupt_pin(dev, pin);
|
||||
/*
|
||||
* move up the chain of bridges, swizzling as we go.
|
||||
*/
|
||||
dev = dev->bus->self;
|
||||
}
|
||||
*pinp = pin + 1;
|
||||
*pinp = pin;
|
||||
|
||||
return PCI_SLOT(dev->devfn);
|
||||
}
|
||||
|
|
|
@ -207,7 +207,7 @@ static struct clcd_board clcd_platform_data = {
|
|||
static struct amba_device name##_device = { \
|
||||
.dev = { \
|
||||
.coherent_dma_mask = ~0, \
|
||||
.bus_id = busid, \
|
||||
.init_name = busid, \
|
||||
.platform_data = plat, \
|
||||
}, \
|
||||
.res = { \
|
||||
|
|
|
@ -91,7 +91,7 @@ void clk_put(struct clk *clk)
|
|||
|
||||
static struct amba_device fb_device = {
|
||||
.dev = {
|
||||
.bus_id = "fb",
|
||||
.init_name = "fb",
|
||||
.coherent_dma_mask = ~0,
|
||||
},
|
||||
.res = {
|
||||
|
|
|
@ -0,0 +1,20 @@
|
|||
#ifndef __ASM_ARCH_PXA930_ROTARY_H
|
||||
#define __ASM_ARCH_PXA930_ROTARY_H
|
||||
|
||||
/* NOTE:
|
||||
*
|
||||
* rotary can be either interpreted as a ralative input event (e.g.
|
||||
* REL_WHEEL or REL_HWHEEL) or a specific key event (e.g. UP/DOWN
|
||||
* or LEFT/RIGHT), depending on if up_key & down_key are assigned
|
||||
* or rel_code is assigned a non-zero value. When all are non-zero,
|
||||
* up_key and down_key will be preferred.
|
||||
*/
|
||||
struct pxa930_rotary_platform_data {
|
||||
int up_key;
|
||||
int down_key;
|
||||
int rel_code;
|
||||
};
|
||||
|
||||
void __init pxa930_set_rotarykey_info(struct pxa930_rotary_platform_data *info);
|
||||
|
||||
#endif /* __ASM_ARCH_PXA930_ROTARY_H */
|
|
@ -0,0 +1,10 @@
|
|||
#ifndef __ASM_ARCH_PXA930_TRKBALL_H
|
||||
#define __ASM_ARCH_PXA930_TRKBALL_H
|
||||
|
||||
struct pxa930_trkball_platform_data {
|
||||
int x_filter;
|
||||
int y_filter;
|
||||
};
|
||||
|
||||
#endif /* __ASM_ARCH_PXA930_TRKBALL_H */
|
||||
|
|
@ -31,7 +31,7 @@
|
|||
static struct amba_device name##_device = { \
|
||||
.dev = { \
|
||||
.coherent_dma_mask = ~0, \
|
||||
.bus_id = busid, \
|
||||
.init_name = busid, \
|
||||
.platform_data = plat, \
|
||||
}, \
|
||||
.res = { \
|
||||
|
|
|
@ -14,7 +14,7 @@
|
|||
#define __ASM_ARCH_SPI_H __FILE__
|
||||
|
||||
struct s3c2410_spi_info {
|
||||
unsigned long pin_cs; /* simple gpio cs */
|
||||
int pin_cs; /* simple gpio cs */
|
||||
unsigned int num_cs; /* total chipselects */
|
||||
int bus_num; /* bus number to use. */
|
||||
|
||||
|
|
|
@ -34,7 +34,7 @@ extern unsigned int mmc_status(struct device *dev);
|
|||
static struct amba_device name##_device = { \
|
||||
.dev = { \
|
||||
.coherent_dma_mask = ~0, \
|
||||
.bus_id = busid, \
|
||||
.init_name = busid, \
|
||||
.platform_data = plat, \
|
||||
}, \
|
||||
.res = { \
|
||||
|
|
|
@ -0,0 +1,23 @@
|
|||
/*
|
||||
* Copyright (C) 2008 Darius Augulis <augulis.darius@gmail.com>
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License as published by
|
||||
* the Free Software Foundation; either version 2 of the License, or
|
||||
* (at your option) any later version.
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*/
|
||||
|
||||
#ifndef __ASM_ARCH_MXC_USB
|
||||
#define __ASM_ARCH_MXC_USB
|
||||
|
||||
struct imxusb_platform_data {
|
||||
int (*init)(struct device *);
|
||||
int (*exit)(struct device *);
|
||||
};
|
||||
|
||||
#endif /* __ASM_ARCH_MXC_USB */
|
|
@ -59,7 +59,7 @@
|
|||
|
||||
#define virt_to_lbus(x) ((x) - PAGE_OFFSET + OMAP1510_LB_OFFSET)
|
||||
#define lbus_to_virt(x) ((x) - OMAP1510_LB_OFFSET + PAGE_OFFSET)
|
||||
#define is_lbus_device(dev) (cpu_is_omap15xx() && dev && (strncmp(dev->bus_id, "ohci", 4) == 0))
|
||||
#define is_lbus_device(dev) (cpu_is_omap15xx() && dev && (strncmp(dev_name(dev), "ohci", 4) == 0))
|
||||
|
||||
#define __arch_page_to_dma(dev, page) ({is_lbus_device(dev) ? \
|
||||
(dma_addr_t)virt_to_lbus(page_address(page)) : \
|
||||
|
|
|
@ -77,38 +77,6 @@
|
|||
|
||||
/*-------------------------------------------------------------------------*/
|
||||
|
||||
#if defined(CONFIG_ARCH_OMAP_OTG) || defined(CONFIG_USB_MUSB_OTG)
|
||||
|
||||
static struct otg_transceiver *xceiv;
|
||||
|
||||
/**
|
||||
* otg_get_transceiver - find the (single) OTG transceiver driver
|
||||
*
|
||||
* Returns the transceiver driver, after getting a refcount to it; or
|
||||
* null if there is no such transceiver. The caller is responsible for
|
||||
* releasing that count.
|
||||
*/
|
||||
struct otg_transceiver *otg_get_transceiver(void)
|
||||
{
|
||||
if (xceiv)
|
||||
get_device(xceiv->dev);
|
||||
return xceiv;
|
||||
}
|
||||
EXPORT_SYMBOL(otg_get_transceiver);
|
||||
|
||||
int otg_set_transceiver(struct otg_transceiver *x)
|
||||
{
|
||||
if (xceiv && x)
|
||||
return -EBUSY;
|
||||
xceiv = x;
|
||||
return 0;
|
||||
}
|
||||
EXPORT_SYMBOL(otg_set_transceiver);
|
||||
|
||||
#endif
|
||||
|
||||
/*-------------------------------------------------------------------------*/
|
||||
|
||||
#if defined(CONFIG_ARCH_OMAP_OTG) || defined(CONFIG_ARCH_OMAP15XX)
|
||||
|
||||
static void omap2_usb_devconf_clear(u8 port, u32 mask)
|
||||
|
|
|
@ -122,6 +122,24 @@ config BOARD_ATNGW100
|
|||
bool "ATNGW100 Network Gateway"
|
||||
select CPU_AT32AP7000
|
||||
|
||||
config BOARD_HAMMERHEAD
|
||||
bool "Hammerhead board"
|
||||
select CPU_AT32AP7000
|
||||
select USB_ARCH_HAS_HCD
|
||||
help
|
||||
The Hammerhead platform is built around a AVR32 32-bit microcontroller from Atmel.
|
||||
It offers versatile peripherals, such as ethernet, usb device, usb host etc.
|
||||
|
||||
The board also incooperates a power supply and is a Power over Ethernet (PoE) Powered
|
||||
Device (PD).
|
||||
|
||||
Additonally, a Cyclone III FPGA from Altera is integrated on the board. The FPGA is
|
||||
mapped into the 32-bit AVR memory bus. The FPGA offers two DDR2 SDRAM interfaces, which
|
||||
will cover even the most exceptional need of memory bandwidth. Together with the onboard
|
||||
video decoder the board is ready for video processing.
|
||||
|
||||
For more information see: http://www.miromico.com/hammerhead
|
||||
|
||||
config BOARD_FAVR_32
|
||||
bool "Favr-32 LCD-board"
|
||||
select CPU_AT32AP7000
|
||||
|
@ -133,6 +151,7 @@ endchoice
|
|||
|
||||
source "arch/avr32/boards/atstk1000/Kconfig"
|
||||
source "arch/avr32/boards/atngw100/Kconfig"
|
||||
source "arch/avr32/boards/hammerhead/Kconfig"
|
||||
source "arch/avr32/boards/favr-32/Kconfig"
|
||||
|
||||
choice
|
||||
|
|
|
@ -33,6 +33,7 @@ head-y += arch/avr32/kernel/head.o
|
|||
core-y += $(machdirs)
|
||||
core-$(CONFIG_BOARD_ATSTK1000) += arch/avr32/boards/atstk1000/
|
||||
core-$(CONFIG_BOARD_ATNGW100) += arch/avr32/boards/atngw100/
|
||||
core-$(CONFIG_BOARD_HAMMERHEAD) += arch/avr32/boards/hammerhead/
|
||||
core-$(CONFIG_BOARD_FAVR_32) += arch/avr32/boards/favr-32/
|
||||
core-$(CONFIG_BOARD_MIMC200) += arch/avr32/boards/mimc200/
|
||||
core-$(CONFIG_LOADER_U_BOOT) += arch/avr32/boot/u-boot/
|
||||
|
|
|
@ -19,8 +19,8 @@
|
|||
#include <linux/types.h>
|
||||
#include <linux/leds.h>
|
||||
#include <linux/spi/spi.h>
|
||||
#include <linux/atmel-mci.h>
|
||||
|
||||
#include <asm/atmel-mci.h>
|
||||
#include <asm/io.h>
|
||||
#include <asm/setup.h>
|
||||
|
||||
|
|
|
@ -16,12 +16,12 @@
|
|||
#include <linux/types.h>
|
||||
#include <linux/spi/spi.h>
|
||||
#include <linux/spi/at73c213.h>
|
||||
#include <linux/atmel-mci.h>
|
||||
|
||||
#include <video/atmel_lcdc.h>
|
||||
|
||||
#include <asm/io.h>
|
||||
#include <asm/setup.h>
|
||||
#include <asm/atmel-mci.h>
|
||||
|
||||
#include <mach/at32ap700x.h>
|
||||
#include <mach/board.h>
|
||||
|
@ -287,23 +287,7 @@ static int __init atstk1002_init(void)
|
|||
* ATSTK1000 uses 32-bit SDRAM interface. Reserve the
|
||||
* SDRAM-specific pins so that nobody messes with them.
|
||||
*/
|
||||
at32_reserve_pin(GPIO_PIN_PE(0)); /* DATA[16] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(1)); /* DATA[17] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(2)); /* DATA[18] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(3)); /* DATA[19] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(4)); /* DATA[20] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(5)); /* DATA[21] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(6)); /* DATA[22] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(7)); /* DATA[23] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(8)); /* DATA[24] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(9)); /* DATA[25] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(10)); /* DATA[26] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(11)); /* DATA[27] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(12)); /* DATA[28] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(13)); /* DATA[29] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(14)); /* DATA[30] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(15)); /* DATA[31] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(26)); /* SDCS */
|
||||
at32_reserve_pin(GPIO_PIOE_BASE, ATMEL_EBI_PE_DATA_ALL);
|
||||
|
||||
#ifdef CONFIG_BOARD_ATSTK1006
|
||||
smc_set_timing(&nand_config, &nand_timing);
|
||||
|
|
|
@ -17,9 +17,9 @@
|
|||
|
||||
#include <linux/spi/at73c213.h>
|
||||
#include <linux/spi/spi.h>
|
||||
#include <linux/atmel-mci.h>
|
||||
|
||||
#include <asm/setup.h>
|
||||
#include <asm/atmel-mci.h>
|
||||
|
||||
#include <mach/at32ap700x.h>
|
||||
#include <mach/board.h>
|
||||
|
@ -131,23 +131,7 @@ static int __init atstk1003_init(void)
|
|||
* ATSTK1000 uses 32-bit SDRAM interface. Reserve the
|
||||
* SDRAM-specific pins so that nobody messes with them.
|
||||
*/
|
||||
at32_reserve_pin(GPIO_PIN_PE(0)); /* DATA[16] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(1)); /* DATA[17] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(2)); /* DATA[18] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(3)); /* DATA[19] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(4)); /* DATA[20] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(5)); /* DATA[21] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(6)); /* DATA[22] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(7)); /* DATA[23] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(8)); /* DATA[24] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(9)); /* DATA[25] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(10)); /* DATA[26] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(11)); /* DATA[27] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(12)); /* DATA[28] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(13)); /* DATA[29] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(14)); /* DATA[30] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(15)); /* DATA[31] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(26)); /* SDCS */
|
||||
at32_reserve_pin(GPIO_PIOE_BASE, ATMEL_EBI_PE_DATA_ALL);
|
||||
|
||||
#ifdef CONFIG_BOARD_ATSTK100X_SW2_CUSTOM
|
||||
at32_add_device_usart(1);
|
||||
|
|
|
@ -17,11 +17,11 @@
|
|||
|
||||
#include <linux/spi/at73c213.h>
|
||||
#include <linux/spi/spi.h>
|
||||
#include <linux/atmel-mci.h>
|
||||
|
||||
#include <video/atmel_lcdc.h>
|
||||
|
||||
#include <asm/setup.h>
|
||||
#include <asm/atmel-mci.h>
|
||||
|
||||
#include <mach/at32ap700x.h>
|
||||
#include <mach/board.h>
|
||||
|
|
|
@ -17,6 +17,7 @@
|
|||
#include <linux/linkage.h>
|
||||
#include <linux/gpio.h>
|
||||
#include <linux/leds.h>
|
||||
#include <linux/atmel-mci.h>
|
||||
#include <linux/atmel-pwm-bl.h>
|
||||
#include <linux/spi/spi.h>
|
||||
#include <linux/spi/ads7846.h>
|
||||
|
@ -79,6 +80,14 @@ static struct spi_board_info __initdata spi1_board_info[] = {
|
|||
},
|
||||
};
|
||||
|
||||
static struct mci_platform_data __initdata mci0_data = {
|
||||
.slot[0] = {
|
||||
.bus_width = 4,
|
||||
.detect_pin = -ENODEV,
|
||||
.wp_pin = -ENODEV,
|
||||
},
|
||||
};
|
||||
|
||||
static struct fb_videomode __initdata lb104v03_modes[] = {
|
||||
{
|
||||
.name = "640x480 @ 50",
|
||||
|
@ -307,28 +316,10 @@ static int __init favr32_init(void)
|
|||
* Favr-32 uses 32-bit SDRAM interface. Reserve the SDRAM-specific
|
||||
* pins so that nobody messes with them.
|
||||
*/
|
||||
at32_reserve_pin(GPIO_PIN_PE(0)); /* DATA[16] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(1)); /* DATA[17] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(2)); /* DATA[18] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(3)); /* DATA[19] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(4)); /* DATA[20] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(5)); /* DATA[21] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(6)); /* DATA[22] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(7)); /* DATA[23] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(8)); /* DATA[24] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(9)); /* DATA[25] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(10)); /* DATA[26] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(11)); /* DATA[27] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(12)); /* DATA[28] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(13)); /* DATA[29] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(14)); /* DATA[30] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(15)); /* DATA[31] */
|
||||
at32_reserve_pin(GPIO_PIN_PE(26)); /* SDCS */
|
||||
at32_reserve_pin(GPIO_PIOE_BASE, ATMEL_EBI_PE_DATA_ALL);
|
||||
|
||||
at32_select_gpio(GPIO_PIN_PB(3), 0); /* IRQ from ADS7843 */
|
||||
|
||||
at32_add_system_devices();
|
||||
|
||||
at32_add_device_usart(0);
|
||||
|
||||
set_hw_addr(at32_add_device_eth(0, ð_data[0]));
|
||||
|
@ -339,7 +330,7 @@ static int __init favr32_init(void)
|
|||
|
||||
at32_add_device_pwm(1 << atmel_pwm_bl_pdata.pwm_channel);
|
||||
at32_add_device_spi(1, spi1_board_info, ARRAY_SIZE(spi1_board_info));
|
||||
at32_add_device_mci(0, NULL);
|
||||
at32_add_device_mci(0, &mci0_data);
|
||||
at32_add_device_usba(0, NULL);
|
||||
at32_add_device_lcdc(0, &favr32_lcdc_data, fbmem_start, fbmem_size, 0);
|
||||
|
||||
|
|
|
@ -0,0 +1,43 @@
|
|||
# Hammerhead customization
|
||||
|
||||
if BOARD_HAMMERHEAD
|
||||
|
||||
config BOARD_HAMMERHEAD_USB
|
||||
bool "Philips ISP116x-hcd USB support"
|
||||
help
|
||||
This enables USB support for Hammerheads internal ISP116x
|
||||
controller from Philips.
|
||||
|
||||
Choose 'Y' here if you want to have your board USB driven.
|
||||
|
||||
config BOARD_HAMMERHEAD_LCD
|
||||
bool "Atmel AT91/AT32 LCD support"
|
||||
help
|
||||
This enables LCD support for the Hammerhead board. You may
|
||||
also add support for framebuffer devices (AT91/AT32 LCD Controller)
|
||||
and framebuffer console support to get the most out of your LCD.
|
||||
|
||||
Choose 'Y' here if you have ordered a Corona daugther board and
|
||||
want to have support for your Hantronix HDA-351T-LV LCD.
|
||||
|
||||
config BOARD_HAMMERHEAD_SND
|
||||
bool "Atmel AC97 Sound support"
|
||||
help
|
||||
This enables Sound support for the Hammerhead board. You may
|
||||
also go trough the ALSA settings to get it working.
|
||||
|
||||
Choose 'Y' here if you have ordered a Corona daugther board and
|
||||
want to make your board funky.
|
||||
|
||||
config BOARD_HAMMERHEAD_FPGA
|
||||
bool "Hammerhead FPGA Support"
|
||||
default y
|
||||
help
|
||||
This adds support for the Cyclone III FPGA from Altera
|
||||
found on Miromico's Hammerhead board.
|
||||
|
||||
Choose 'Y' here if you want to have FPGA support enabled.
|
||||
You will have to choose the "Hammerhead FPGA Device Support" in
|
||||
Device Drivers->Misc to be able to use FPGA functionality.
|
||||
|
||||
endif # BOARD_ATNGW100
|
|
@ -0,0 +1 @@
|
|||
obj-y += setup.o flash.o
|
|
@ -0,0 +1,377 @@
|
|||
/*
|
||||
* Hammerhead board-specific flash initialization
|
||||
*
|
||||
* Copyright (C) 2008 Miromico AG
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/mtd/mtd.h>
|
||||
#include <linux/mtd/partitions.h>
|
||||
#include <linux/mtd/physmap.h>
|
||||
#include <linux/usb/isp116x.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/delay.h>
|
||||
|
||||
#include <mach/portmux.h>
|
||||
#include <mach/at32ap700x.h>
|
||||
#include <mach/smc.h>
|
||||
|
||||
#include "../../mach-at32ap/clock.h"
|
||||
#include "flash.h"
|
||||
|
||||
|
||||
#define HAMMERHEAD_USB_PERIPH_GCLK0 0x40000000
|
||||
#define HAMMERHEAD_USB_PERIPH_CS2 0x02000000
|
||||
#define HAMMERHEAD_USB_PERIPH_EXTINT0 0x02000000
|
||||
|
||||
#define HAMMERHEAD_FPGA_PERIPH_MOSI 0x00000002
|
||||
#define HAMMERHEAD_FPGA_PERIPH_SCK 0x00000020
|
||||
#define HAMMERHEAD_FPGA_PERIPH_EXTINT3 0x10000000
|
||||
|
||||
static struct smc_timing flash_timing __initdata = {
|
||||
.ncs_read_setup = 0,
|
||||
.nrd_setup = 40,
|
||||
.ncs_write_setup = 0,
|
||||
.nwe_setup = 10,
|
||||
|
||||
.ncs_read_pulse = 80,
|
||||
.nrd_pulse = 40,
|
||||
.ncs_write_pulse = 65,
|
||||
.nwe_pulse = 55,
|
||||
|
||||
.read_cycle = 120,
|
||||
.write_cycle = 120,
|
||||
};
|
||||
|
||||
static struct smc_config flash_config __initdata = {
|
||||
.bus_width = 2,
|
||||
.nrd_controlled = 1,
|
||||
.nwe_controlled = 1,
|
||||
.byte_write = 1,
|
||||
};
|
||||
|
||||
static struct mtd_partition flash_parts[] = {
|
||||
{
|
||||
.name = "u-boot",
|
||||
.offset = 0x00000000,
|
||||
.size = 0x00020000, /* 128 KiB */
|
||||
.mask_flags = MTD_WRITEABLE,
|
||||
},
|
||||
{
|
||||
.name = "root",
|
||||
.offset = 0x00020000,
|
||||
.size = 0x007d0000,
|
||||
},
|
||||
{
|
||||
.name = "env",
|
||||
.offset = 0x007f0000,
|
||||
.size = 0x00010000,
|
||||
.mask_flags = MTD_WRITEABLE,
|
||||
},
|
||||
};
|
||||
|
||||
static struct physmap_flash_data flash_data = {
|
||||
.width = 2,
|
||||
.nr_parts = ARRAY_SIZE(flash_parts),
|
||||
.parts = flash_parts,
|
||||
};
|
||||
|
||||
static struct resource flash_resource = {
|
||||
.start = 0x00000000,
|
||||
.end = 0x007fffff,
|
||||
.flags = IORESOURCE_MEM,
|
||||
};
|
||||
|
||||
static struct platform_device flash_device = {
|
||||
.name = "physmap-flash",
|
||||
.id = 0,
|
||||
.resource = &flash_resource,
|
||||
.num_resources = 1,
|
||||
.dev = { .platform_data = &flash_data, },
|
||||
};
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_USB
|
||||
|
||||
static struct smc_timing isp1160_timing __initdata = {
|
||||
.ncs_read_setup = 75,
|
||||
.nrd_setup = 75,
|
||||
.ncs_write_setup = 75,
|
||||
.nwe_setup = 75,
|
||||
|
||||
|
||||
/* We use conservative timing settings, as the minimal settings aren't
|
||||
stable. There may be room for tweaking. */
|
||||
.ncs_read_pulse = 75, /* min. 33ns */
|
||||
.nrd_pulse = 75, /* min. 33ns */
|
||||
.ncs_write_pulse = 75, /* min. 26ns */
|
||||
.nwe_pulse = 75, /* min. 26ns */
|
||||
|
||||
.read_cycle = 225, /* min. 143ns */
|
||||
.write_cycle = 225, /* min. 136ns */
|
||||
};
|
||||
|
||||
static struct smc_config isp1160_config __initdata = {
|
||||
.bus_width = 2,
|
||||
.nrd_controlled = 1,
|
||||
.nwe_controlled = 1,
|
||||
.byte_write = 0,
|
||||
};
|
||||
|
||||
/*
|
||||
* The platform delay function is only used to enforce the strange
|
||||
* read to write delay. This can not be configured in the SMC. All other
|
||||
* timings are controlled by the SMC (see timings obove)
|
||||
* So in isp116x-hcd.c we should comment out USE_PLATFORM_DELAY
|
||||
*/
|
||||
void isp116x_delay(struct device *dev, int delay)
|
||||
{
|
||||
if (delay > 150)
|
||||
ndelay(delay - 150);
|
||||
}
|
||||
|
||||
static struct isp116x_platform_data isp1160_data = {
|
||||
.sel15Kres = 1, /* use internal downstream resistors */
|
||||
.oc_enable = 0, /* external overcurrent detection */
|
||||
.int_edge_triggered = 0, /* interrupt is level triggered */
|
||||
.int_act_high = 0, /* interrupt is active low */
|
||||
.delay = isp116x_delay, /* platform delay function */
|
||||
};
|
||||
|
||||
static struct resource isp1160_resource[] = {
|
||||
{
|
||||
.start = 0x08000000,
|
||||
.end = 0x08000001,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
{
|
||||
.start = 0x08000002,
|
||||
.end = 0x08000003,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
{
|
||||
.start = 64,
|
||||
.flags = IORESOURCE_IRQ,
|
||||
},
|
||||
};
|
||||
|
||||
static struct platform_device isp1160_device = {
|
||||
.name = "isp116x-hcd",
|
||||
.id = 0,
|
||||
.resource = isp1160_resource,
|
||||
.num_resources = 3,
|
||||
.dev = {
|
||||
.platform_data = &isp1160_data,
|
||||
},
|
||||
};
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_USB
|
||||
static int __init hammerhead_usbh_init(void)
|
||||
{
|
||||
struct clk *gclk;
|
||||
struct clk *osc;
|
||||
|
||||
int ret;
|
||||
|
||||
/* setup smc for usbh */
|
||||
smc_set_timing(&isp1160_config, &isp1160_timing);
|
||||
ret = smc_set_configuration(2, &isp1160_config);
|
||||
|
||||
if (ret < 0) {
|
||||
printk(KERN_ERR
|
||||
"hammerhead: failed to set ISP1160 USBH timing\n");
|
||||
return ret;
|
||||
}
|
||||
|
||||
/* setup gclk0 to run from osc1 */
|
||||
gclk = clk_get(NULL, "gclk0");
|
||||
if (IS_ERR(gclk))
|
||||
goto err_gclk;
|
||||
|
||||
osc = clk_get(NULL, "osc1");
|
||||
if (IS_ERR(osc))
|
||||
goto err_osc;
|
||||
|
||||
if (clk_set_parent(gclk, osc)) {
|
||||
pr_debug("hammerhead: failed to set osc1 for USBH clock\n");
|
||||
goto err_set_clk;
|
||||
}
|
||||
|
||||
/* set clock to 6MHz */
|
||||
clk_set_rate(gclk, 6000000);
|
||||
|
||||
/* and enable */
|
||||
clk_enable(gclk);
|
||||
|
||||
/* select GCLK0 peripheral function */
|
||||
at32_select_periph(GPIO_PIOA_BASE, HAMMERHEAD_USB_PERIPH_GCLK0,
|
||||
GPIO_PERIPH_A, 0);
|
||||
|
||||
/* enable CS2 peripheral function */
|
||||
at32_select_periph(GPIO_PIOE_BASE, HAMMERHEAD_USB_PERIPH_CS2,
|
||||
GPIO_PERIPH_A, 0);
|
||||
|
||||
/* H_WAKEUP must be driven low */
|
||||
at32_select_gpio(GPIO_PIN_PA(8), AT32_GPIOF_OUTPUT);
|
||||
|
||||
/* Select EXTINT0 for PB25 */
|
||||
at32_select_periph(GPIO_PIOB_BASE, HAMMERHEAD_USB_PERIPH_EXTINT0,
|
||||
GPIO_PERIPH_A, 0);
|
||||
|
||||
/* register usbh device driver */
|
||||
platform_device_register(&isp1160_device);
|
||||
|
||||
err_set_clk:
|
||||
clk_put(osc);
|
||||
err_osc:
|
||||
clk_put(gclk);
|
||||
err_gclk:
|
||||
return ret;
|
||||
}
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_FPGA
|
||||
static struct smc_timing fpga_timing __initdata = {
|
||||
.ncs_read_setup = 16,
|
||||
.nrd_setup = 32,
|
||||
.ncs_read_pulse = 48,
|
||||
.nrd_pulse = 32,
|
||||
.read_cycle = 64,
|
||||
|
||||
.ncs_write_setup = 16,
|
||||
.nwe_setup = 16,
|
||||
.ncs_write_pulse = 32,
|
||||
.nwe_pulse = 32,
|
||||
.write_cycle = 64,
|
||||
};
|
||||
|
||||
static struct smc_config fpga_config __initdata = {
|
||||
.bus_width = 4,
|
||||
.nrd_controlled = 1,
|
||||
.nwe_controlled = 1,
|
||||
.byte_write = 0,
|
||||
};
|
||||
|
||||
static struct resource hh_fpga0_resource[] = {
|
||||
{
|
||||
.start = 0xffe00400,
|
||||
.end = 0xffe00400 + 0x3ff,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
{
|
||||
.start = 4,
|
||||
.end = 4,
|
||||
.flags = IORESOURCE_IRQ,
|
||||
},
|
||||
{
|
||||
.start = 0x0c000000,
|
||||
.end = 0x0c000100,
|
||||
.flags = IORESOURCE_MEM,
|
||||
},
|
||||
{
|
||||
.start = 67,
|
||||
.end = 67,
|
||||
.flags = IORESOURCE_IRQ,
|
||||
},
|
||||
};
|
||||
|
||||
static u64 hh_fpga0_dma_mask = DMA_32BIT_MASK;
|
||||
static struct platform_device hh_fpga0_device = {
|
||||
.name = "hh_fpga",
|
||||
.id = 0,
|
||||
.dev = {
|
||||
.dma_mask = &hh_fpga0_dma_mask,
|
||||
.coherent_dma_mask = DMA_32BIT_MASK,
|
||||
},
|
||||
.resource = hh_fpga0_resource,
|
||||
.num_resources = ARRAY_SIZE(hh_fpga0_resource),
|
||||
};
|
||||
|
||||
static struct clk hh_fpga0_spi_clk = {
|
||||
.name = "spi_clk",
|
||||
.dev = &hh_fpga0_device.dev,
|
||||
.mode = pba_clk_mode,
|
||||
.get_rate = pba_clk_get_rate,
|
||||
.index = 1,
|
||||
};
|
||||
|
||||
struct platform_device *__init at32_add_device_hh_fpga(void)
|
||||
{
|
||||
/* Select peripheral functionallity for SPI SCK and MOSI */
|
||||
at32_select_periph(GPIO_PIOB_BASE, HAMMERHEAD_FPGA_PERIPH_SCK,
|
||||
GPIO_PERIPH_B, 0);
|
||||
at32_select_periph(GPIO_PIOB_BASE, HAMMERHEAD_FPGA_PERIPH_MOSI,
|
||||
GPIO_PERIPH_B, 0);
|
||||
|
||||
/* reserve all other needed gpio
|
||||
* We have on board pull ups, so there is no need
|
||||
* to enable gpio pull ups */
|
||||
/* INIT_DONE (input) */
|
||||
at32_select_gpio(GPIO_PIN_PB(0), 0);
|
||||
|
||||
/* nSTATUS (input) */
|
||||
at32_select_gpio(GPIO_PIN_PB(2), 0);
|
||||
|
||||
/* nCONFIG (output, low) */
|
||||
at32_select_gpio(GPIO_PIN_PB(3), AT32_GPIOF_OUTPUT);
|
||||
|
||||
/* CONF_DONE (input) */
|
||||
at32_select_gpio(GPIO_PIN_PB(4), 0);
|
||||
|
||||
/* Select EXTINT3 for PB28 (Interrupt from FPGA) */
|
||||
at32_select_periph(GPIO_PIOB_BASE, HAMMERHEAD_FPGA_PERIPH_EXTINT3,
|
||||
GPIO_PERIPH_A, 0);
|
||||
|
||||
/* Get our parent clock */
|
||||
hh_fpga0_spi_clk.parent = clk_get(NULL, "pba");
|
||||
clk_put(hh_fpga0_spi_clk.parent);
|
||||
|
||||
/* Register clock in at32 clock tree */
|
||||
at32_clk_register(&hh_fpga0_spi_clk);
|
||||
|
||||
platform_device_register(&hh_fpga0_device);
|
||||
return &hh_fpga0_device;
|
||||
}
|
||||
#endif
|
||||
|
||||
/* This needs to be called after the SMC has been initialized */
|
||||
static int __init hammerhead_flash_init(void)
|
||||
{
|
||||
int ret;
|
||||
|
||||
smc_set_timing(&flash_config, &flash_timing);
|
||||
ret = smc_set_configuration(0, &flash_config);
|
||||
|
||||
if (ret < 0) {
|
||||
printk(KERN_ERR "hammerhead: failed to set NOR flash timing\n");
|
||||
return ret;
|
||||
}
|
||||
|
||||
platform_device_register(&flash_device);
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_USB
|
||||
hammerhead_usbh_init();
|
||||
#endif
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_FPGA
|
||||
/* Setup SMC for FPGA interface */
|
||||
smc_set_timing(&fpga_config, &fpga_timing);
|
||||
ret = smc_set_configuration(3, &fpga_config);
|
||||
#endif
|
||||
|
||||
|
||||
if (ret < 0) {
|
||||
printk(KERN_ERR "hammerhead: failed to set FPGA timing\n");
|
||||
return ret;
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
device_initcall(hammerhead_flash_init);
|
|
@ -0,0 +1,6 @@
|
|||
#ifndef __BOARDS_HAMMERHEAD_FLASH_H
|
||||
#define __BOARDS_HAMMERHEAD_FLASH_H
|
||||
|
||||
struct platform_device *at32_add_device_hh_fpga(void);
|
||||
|
||||
#endif /* __BOARDS_HAMMERHEAD_FLASH_H */
|
|
@ -0,0 +1,245 @@
|
|||
/*
|
||||
* Board-specific setup code for the Miromico Hammerhead board
|
||||
*
|
||||
* Copyright (C) 2008 Miromico AG
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation.
|
||||
*/
|
||||
#include <linux/atmel-mci.h>
|
||||
#include <linux/clk.h>
|
||||
#include <linux/fb.h>
|
||||
#include <linux/etherdevice.h>
|
||||
#include <linux/i2c.h>
|
||||
#include <linux/i2c-gpio.h>
|
||||
#include <linux/init.h>
|
||||
#include <linux/linkage.h>
|
||||
#include <linux/platform_device.h>
|
||||
#include <linux/types.h>
|
||||
#include <linux/spi/spi.h>
|
||||
|
||||
#include <video/atmel_lcdc.h>
|
||||
|
||||
#include <linux/io.h>
|
||||
#include <asm/setup.h>
|
||||
|
||||
#include <mach/at32ap700x.h>
|
||||
#include <mach/board.h>
|
||||
#include <mach/init.h>
|
||||
#include <mach/portmux.h>
|
||||
|
||||
#include "../../mach-at32ap/clock.h"
|
||||
#include "flash.h"
|
||||
|
||||
/* Oscillator frequencies. These are board-specific */
|
||||
unsigned long at32_board_osc_rates[3] = {
|
||||
[0] = 32768, /* 32.768 kHz on RTC osc */
|
||||
[1] = 25000000, /* 25MHz on osc0 */
|
||||
[2] = 12000000, /* 12 MHz on osc1 */
|
||||
};
|
||||
|
||||
/* Initialized by bootloader-specific startup code. */
|
||||
struct tag *bootloader_tags __initdata;
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_LCD
|
||||
static struct fb_videomode __initdata hda350tlv_modes[] = {
|
||||
{
|
||||
.name = "320x240 @ 75",
|
||||
.refresh = 75,
|
||||
.xres = 320,
|
||||
.yres = 240,
|
||||
.pixclock = KHZ2PICOS(6891),
|
||||
|
||||
.left_margin = 48,
|
||||
.right_margin = 18,
|
||||
.upper_margin = 18,
|
||||
.lower_margin = 4,
|
||||
.hsync_len = 20,
|
||||
.vsync_len = 2,
|
||||
|
||||
.sync = 0,
|
||||
.vmode = FB_VMODE_NONINTERLACED,
|
||||
},
|
||||
};
|
||||
|
||||
static struct fb_monspecs __initdata hammerhead_hda350t_monspecs = {
|
||||
.manufacturer = "HAN",
|
||||
.monitor = "HDA350T-LV",
|
||||
.modedb = hda350tlv_modes,
|
||||
.modedb_len = ARRAY_SIZE(hda350tlv_modes),
|
||||
.hfmin = 14900,
|
||||
.hfmax = 22350,
|
||||
.vfmin = 60,
|
||||
.vfmax = 90,
|
||||
.dclkmax = 10000000,
|
||||
};
|
||||
|
||||
struct atmel_lcdfb_info __initdata hammerhead_lcdc_data = {
|
||||
.default_bpp = 24,
|
||||
.default_dmacon = ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN,
|
||||
.default_lcdcon2 = (ATMEL_LCDC_DISTYPE_TFT
|
||||
| ATMEL_LCDC_INVCLK
|
||||
| ATMEL_LCDC_CLKMOD_ALWAYSACTIVE
|
||||
| ATMEL_LCDC_MEMOR_BIG),
|
||||
.default_monspecs = &hammerhead_hda350t_monspecs,
|
||||
.guard_time = 2,
|
||||
};
|
||||
#endif
|
||||
|
||||
static struct mci_platform_data __initdata mci0_data = {
|
||||
.slot[0] = {
|
||||
.bus_width = 4,
|
||||
.detect_pin = -ENODEV,
|
||||
.wp_pin = -ENODEV,
|
||||
},
|
||||
};
|
||||
|
||||
struct eth_addr {
|
||||
u8 addr[6];
|
||||
};
|
||||
|
||||
static struct eth_addr __initdata hw_addr[1];
|
||||
static struct eth_platform_data __initdata eth_data[1];
|
||||
|
||||
/*
|
||||
* The next two functions should go away as the boot loader is
|
||||
* supposed to initialize the macb address registers with a valid
|
||||
* ethernet address. But we need to keep it around for a while until
|
||||
* we can be reasonably sure the boot loader does this.
|
||||
*
|
||||
* The phy_id is ignored as the driver will probe for it.
|
||||
*/
|
||||
static int __init parse_tag_ethernet(struct tag *tag)
|
||||
{
|
||||
int i = tag->u.ethernet.mac_index;
|
||||
|
||||
if (i < ARRAY_SIZE(hw_addr))
|
||||
memcpy(hw_addr[i].addr, tag->u.ethernet.hw_address,
|
||||
sizeof(hw_addr[i].addr));
|
||||
|
||||
return 0;
|
||||
}
|
||||
__tagtable(ATAG_ETHERNET, parse_tag_ethernet);
|
||||
|
||||
static void __init set_hw_addr(struct platform_device *pdev)
|
||||
{
|
||||
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
|
||||
const u8 *addr;
|
||||
void __iomem *regs;
|
||||
struct clk *pclk;
|
||||
|
||||
if (!res)
|
||||
return;
|
||||
|
||||
if (pdev->id >= ARRAY_SIZE(hw_addr))
|
||||
return;
|
||||
|
||||
addr = hw_addr[pdev->id].addr;
|
||||
|
||||
if (!is_valid_ether_addr(addr))
|
||||
return;
|
||||
|
||||
/*
|
||||
* Since this is board-specific code, we'll cheat and use the
|
||||
* physical address directly as we happen to know that it's
|
||||
* the same as the virtual address.
|
||||
*/
|
||||
regs = (void __iomem __force *)res->start;
|
||||
pclk = clk_get(&pdev->dev, "pclk");
|
||||
|
||||
if (!pclk)
|
||||
return;
|
||||
|
||||
clk_enable(pclk);
|
||||
|
||||
__raw_writel((addr[3] << 24) | (addr[2] << 16) | (addr[1] << 8) |
|
||||
addr[0], regs + 0x98);
|
||||
__raw_writel((addr[5] << 8) | addr[4], regs + 0x9c);
|
||||
|
||||
clk_disable(pclk);
|
||||
clk_put(pclk);
|
||||
}
|
||||
|
||||
void __init setup_board(void)
|
||||
{
|
||||
at32_map_usart(1, 0); /* USART 1: /dev/ttyS0, DB9 */
|
||||
at32_setup_serial_console(0);
|
||||
}
|
||||
|
||||
static struct i2c_gpio_platform_data i2c_gpio_data = {
|
||||
.sda_pin = GPIO_PIN_PA(6),
|
||||
.scl_pin = GPIO_PIN_PA(7),
|
||||
.sda_is_open_drain = 1,
|
||||
.scl_is_open_drain = 1,
|
||||
.udelay = 2, /* close to 100 kHz */
|
||||
};
|
||||
|
||||
static struct platform_device i2c_gpio_device = {
|
||||
.name = "i2c-gpio",
|
||||
.id = 0,
|
||||
.dev = { .platform_data = &i2c_gpio_data, },
|
||||
};
|
||||
|
||||
static struct i2c_board_info __initdata i2c_info[] = {};
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_SND
|
||||
static struct ac97c_platform_data ac97c_data = {
|
||||
.reset_pin = GPIO_PIN_PA(16),
|
||||
};
|
||||
#endif
|
||||
|
||||
static int __init hammerhead_init(void)
|
||||
{
|
||||
/*
|
||||
* Hammerhead uses 32-bit SDRAM interface. Reserve the
|
||||
* SDRAM-specific pins so that nobody messes with them.
|
||||
*/
|
||||
at32_reserve_pin(GPIO_PIOE_BASE, ATMEL_EBI_PE_DATA_ALL);
|
||||
|
||||
at32_add_device_usart(0);
|
||||
|
||||
/* Reserve PB29 (GCLK3). This pin is used as clock source
|
||||
* for ETH PHY (25MHz). GCLK3 setup is done by U-Boot.
|
||||
*/
|
||||
at32_reserve_pin(GPIO_PIOB_BASE, (1<<29));
|
||||
|
||||
/*
|
||||
* Hammerhead uses only one ethernet port, so we don't set
|
||||
* address of second port
|
||||
*/
|
||||
set_hw_addr(at32_add_device_eth(0, ð_data[0]));
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_FPGA
|
||||
at32_add_device_hh_fpga();
|
||||
#endif
|
||||
at32_add_device_mci(0, &mci0_data);
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_USB
|
||||
at32_add_device_usba(0, NULL);
|
||||
#endif
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_LCD
|
||||
at32_add_device_lcdc(0, &hammerhead_lcdc_data, fbmem_start,
|
||||
fbmem_size, ATMEL_LCDC_PRI_24BIT);
|
||||
#endif
|
||||
|
||||
at32_select_gpio(i2c_gpio_data.sda_pin,
|
||||
AT32_GPIOF_MULTIDRV | AT32_GPIOF_OUTPUT |
|
||||
AT32_GPIOF_HIGH);
|
||||
at32_select_gpio(i2c_gpio_data.scl_pin,
|
||||
AT32_GPIOF_MULTIDRV | AT32_GPIOF_OUTPUT |
|
||||
AT32_GPIOF_HIGH);
|
||||
platform_device_register(&i2c_gpio_device);
|
||||
i2c_register_board_info(0, i2c_info, ARRAY_SIZE(i2c_info));
|
||||
|
||||
#ifdef CONFIG_BOARD_HAMMERHEAD_SND
|
||||
at32_add_device_ac97c(0, &ac97c_data);
|
||||
#endif
|
||||
|
||||
/* Select the Touchscreen interrupt pin mode */
|
||||
at32_select_periph(GPIO_PIOB_BASE, 0x08000000, GPIO_PERIPH_A, 0);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
postcore_initcall(hammerhead_init);
|
|
@ -24,7 +24,7 @@ extern struct atmel_lcdfb_info mimc200_lcdc_data;
|
|||
#include <video/atmel_lcdc.h>
|
||||
#include <linux/fb.h>
|
||||
|
||||
#include <asm/atmel-mci.h>
|
||||
#include <linux/atmel-mci.h>
|
||||
#include <linux/io.h>
|
||||
#include <asm/setup.h>
|
||||
|
||||
|
@ -207,8 +207,6 @@ static int __init mimc200_init(void)
|
|||
* reserve any pins for it.
|
||||
*/
|
||||
|
||||
at32_add_system_devices();
|
||||
|
||||
at32_add_device_usart(0);
|
||||
at32_add_device_usart(1);
|
||||
at32_add_device_usart(2);
|
||||
|
|
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче