mirror of
https://github.com/ukui/kernel.git
synced 2026-03-09 10:07:04 -07:00
Merge branch 'master' into for-linus
This commit is contained in:
Chris Metcalf
@@ -130,8 +130,6 @@ edac.txt
|
||||
- information on EDAC - Error Detection And Correction
|
||||
eisa.txt
|
||||
- info on EISA bus support.
|
||||
exception.txt
|
||||
- how Linux v2.2 handles exceptions without verify_area etc.
|
||||
fault-injection/
|
||||
- dir with docs about the fault injection capabilities infrastructure.
|
||||
fb/
|
||||
@@ -234,6 +232,8 @@ memory.txt
|
||||
- info on typical Linux memory problems.
|
||||
mips/
|
||||
- directory with info about Linux on MIPS architecture.
|
||||
mmc/
|
||||
- directory with info about the MMC subsystem
|
||||
mono.txt
|
||||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
mutex-design.txt
|
||||
|
||||
@@ -753,6 +753,16 @@ to "Closing".
|
||||
alignment constraints (e.g. the alignment constraints about 64-bit
|
||||
objects).
|
||||
|
||||
3) Supporting multiple types of IOMMUs
|
||||
|
||||
If your architecture needs to support multiple types of IOMMUs, you
|
||||
can use include/linux/asm-generic/dma-mapping-common.h. It's a
|
||||
library to support the DMA API with multiple types of IOMMUs. Lots
|
||||
of architectures (x86, powerpc, sh, alpha, ia64, microblaze and
|
||||
sparc) use it. Choose one to see how it can be used. If you need to
|
||||
support multiple types of IOMMUs in a single system, the example of
|
||||
x86 or powerpc helps.
|
||||
|
||||
Closing
|
||||
|
||||
This document, and the API itself, would not be in its current
|
||||
|
||||
@@ -455,12 +455,6 @@ Free memory allocated by the nonconsistent API. All parameters must
|
||||
be identical to those passed in (and returned by
|
||||
dma_alloc_noncoherent()).
|
||||
|
||||
int
|
||||
dma_is_consistent(struct device *dev, dma_addr_t dma_handle)
|
||||
|
||||
Returns true if the device dev is performing consistent DMA on the memory
|
||||
area pointed to by the dma_handle.
|
||||
|
||||
int
|
||||
dma_get_cache_alignment(void)
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ PS_METHOD = $(prefer-db2x)
|
||||
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks
|
||||
|
||||
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
|
||||
xmldocs: $(BOOKS) xmldoclinks
|
||||
xmldocs: $(BOOKS)
|
||||
sgmldocs: xmldocs
|
||||
|
||||
PS := $(patsubst %.xml, %.ps, $(BOOKS))
|
||||
@@ -95,7 +95,7 @@ define rule_docproc
|
||||
) > $(dir $@).$(notdir $@).cmd
|
||||
endef
|
||||
|
||||
%.xml: %.tmpl FORCE
|
||||
%.xml: %.tmpl xmldoclinks FORCE
|
||||
$(call if_changed_rule,docproc)
|
||||
|
||||
###
|
||||
|
||||
@@ -132,7 +132,6 @@ X!Ilib/string.c
|
||||
<title>FIFO Buffer</title>
|
||||
<sect1><title>kfifo interface</title>
|
||||
!Iinclude/linux/kfifo.h
|
||||
!Ekernel/kfifo.c
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
Maintainers:
|
||||
CPU Hotplug Core:
|
||||
Rusty Russell <rusty@rustycorp.com.au>
|
||||
Rusty Russell <rusty@rustcorp.com.au>
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>
|
||||
i386:
|
||||
Zwane Mwaikambo <zwane@arm.linux.org.uk>
|
||||
|
||||
@@ -445,6 +445,7 @@ Your cooperation is appreciated.
|
||||
233 = /dev/kmview View-OS A process with a view
|
||||
234 = /dev/btrfs-control Btrfs control device
|
||||
235 = /dev/autofs Autofs control device
|
||||
236 = /dev/mapper/control Device-Mapper control device
|
||||
240-254 Reserved for local use
|
||||
255 Reserved for MISC_DYNAMIC_MINOR
|
||||
|
||||
|
||||
@@ -547,3 +547,20 @@ Why: superseded by acpi_sleep=nonvs
|
||||
Who: Rafael J. Wysocki <rjw@sisk.pl>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: PCI DMA unmap state API
|
||||
When: August 2012
|
||||
Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced
|
||||
with DMA unmap state API (DMA unmap state API can be used for
|
||||
any bus).
|
||||
Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: DMA_xxBIT_MASK macros
|
||||
When: Jun 2011
|
||||
Why: DMA_xxBIT_MASK macros were replaced with DMA_BIT_MASK() macros.
|
||||
Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
||||
|
||||
----------------------------
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@ SQUASHFS 4.0 FILESYSTEM
|
||||
=======================
|
||||
|
||||
Squashfs is a compressed read-only filesystem for Linux.
|
||||
It uses zlib compression to compress files, inodes and directories.
|
||||
It uses zlib/lzo compression to compress files, inodes and directories.
|
||||
Inodes in the system are very small and all blocks are packed to minimise
|
||||
data overhead. Block sizes greater than 4K are supported up to a maximum
|
||||
of 1Mbytes (default block size 128K).
|
||||
|
||||
@@ -158,10 +158,11 @@ and configure pullups/pulldowns appropriately.)
|
||||
Spinlock-Safe GPIO access
|
||||
-------------------------
|
||||
Most GPIO controllers can be accessed with memory read/write instructions.
|
||||
That doesn't need to sleep, and can safely be done from inside IRQ handlers.
|
||||
(That includes hardirq contexts on RT kernels.)
|
||||
Those don't need to sleep, and can safely be done from inside hard
|
||||
(nonthreaded) IRQ handlers and similar contexts.
|
||||
|
||||
Use these calls to access such GPIOs:
|
||||
Use the following calls to access such GPIOs,
|
||||
for which gpio_cansleep() will always return false (see below):
|
||||
|
||||
/* GPIO INPUT: return zero or nonzero */
|
||||
int gpio_get_value(unsigned gpio);
|
||||
@@ -210,9 +211,31 @@ To access such GPIOs, a different set of accessors is defined:
|
||||
/* GPIO OUTPUT, might sleep */
|
||||
void gpio_set_value_cansleep(unsigned gpio, int value);
|
||||
|
||||
Other than the fact that these calls might sleep, and will not be ignored
|
||||
for GPIOs that can't be accessed from IRQ handlers, these calls act the
|
||||
same as the spinlock-safe calls.
|
||||
|
||||
Accessing such GPIOs requires a context which may sleep, for example
|
||||
a threaded IRQ handler, and those accessors must be used instead of
|
||||
spinlock-safe accessors without the cansleep() name suffix.
|
||||
|
||||
Other than the fact that these accessors might sleep, and will work
|
||||
on GPIOs that can't be accessed from hardIRQ handlers, these calls act
|
||||
the same as the spinlock-safe calls.
|
||||
|
||||
** IN ADDITION ** calls to setup and configure such GPIOs must be made
|
||||
from contexts which may sleep, since they may need to access the GPIO
|
||||
controller chip too: (These setup calls are usually made from board
|
||||
setup or driver probe/teardown code, so this is an easy constraint.)
|
||||
|
||||
gpio_direction_input()
|
||||
gpio_direction_output()
|
||||
gpio_request()
|
||||
|
||||
## gpio_request_one()
|
||||
## gpio_request_array()
|
||||
## gpio_free_array()
|
||||
|
||||
gpio_free()
|
||||
gpio_set_debounce()
|
||||
|
||||
|
||||
|
||||
Claiming and Releasing GPIOs
|
||||
|
||||
@@ -102,7 +102,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev)
|
||||
memset(&i2c_info, 0, sizeof(struct i2c_board_info));
|
||||
strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE);
|
||||
isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info,
|
||||
normal_i2c);
|
||||
normal_i2c, NULL);
|
||||
i2c_put_adapter(i2c_adap);
|
||||
(...)
|
||||
}
|
||||
|
||||
@@ -915,9 +915,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
controller
|
||||
i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
|
||||
controllers
|
||||
i8042.panicblink=
|
||||
[HW] Frequency with which keyboard LEDs should blink
|
||||
when kernel panics (default is 0.5 sec)
|
||||
i8042.reset [HW] Reset the controller during init and cleanup
|
||||
i8042.unlock [HW] Unlock (ignore) the keylock
|
||||
|
||||
|
||||
4
Documentation/mmc/00-INDEX
Normal file
4
Documentation/mmc/00-INDEX
Normal file
@@ -0,0 +1,4 @@
|
||||
00-INDEX
|
||||
- this file
|
||||
mmc-dev-attrs.txt
|
||||
- info on SD and MMC device attributes
|
||||
56
Documentation/mmc/mmc-dev-attrs.txt
Normal file
56
Documentation/mmc/mmc-dev-attrs.txt
Normal file
@@ -0,0 +1,56 @@
|
||||
SD and MMC Device Attributes
|
||||
============================
|
||||
|
||||
All attributes are read-only.
|
||||
|
||||
cid Card Identifaction Register
|
||||
csd Card Specific Data Register
|
||||
scr SD Card Configuration Register (SD only)
|
||||
date Manufacturing Date (from CID Register)
|
||||
fwrev Firmware/Product Revision (from CID Register) (SD and MMCv1 only)
|
||||
hwrev Hardware/Product Revision (from CID Register) (SD and MMCv1 only)
|
||||
manfid Manufacturer ID (from CID Register)
|
||||
name Product Name (from CID Register)
|
||||
oemid OEM/Application ID (from CID Register)
|
||||
serial Product Serial Number (from CID Register)
|
||||
erase_size Erase group size
|
||||
preferred_erase_size Preferred erase size
|
||||
|
||||
Note on Erase Size and Preferred Erase Size:
|
||||
|
||||
"erase_size" is the minimum size, in bytes, of an erase
|
||||
operation. For MMC, "erase_size" is the erase group size
|
||||
reported by the card. Note that "erase_size" does not apply
|
||||
to trim or secure trim operations where the minimum size is
|
||||
always one 512 byte sector. For SD, "erase_size" is 512
|
||||
if the card is block-addressed, 0 otherwise.
|
||||
|
||||
SD/MMC cards can erase an arbitrarily large area up to and
|
||||
including the whole card. When erasing a large area it may
|
||||
be desirable to do it in smaller chunks for three reasons:
|
||||
1. A single erase command will make all other I/O on
|
||||
the card wait. This is not a problem if the whole card
|
||||
is being erased, but erasing one partition will make
|
||||
I/O for another partition on the same card wait for the
|
||||
duration of the erase - which could be a several
|
||||
minutes.
|
||||
2. To be able to inform the user of erase progress.
|
||||
3. The erase timeout becomes too large to be very
|
||||
useful. Because the erase timeout contains a margin
|
||||
which is multiplied by the size of the erase area,
|
||||
the value can end up being several minutes for large
|
||||
areas.
|
||||
|
||||
"erase_size" is not the most efficient unit to erase
|
||||
(especially for SD where it is just one sector),
|
||||
hence "preferred_erase_size" provides a good chunk
|
||||
size for erasing large areas.
|
||||
|
||||
For MMC, "preferred_erase_size" is the high-capacity
|
||||
erase size if a card specifies one, otherwise it is
|
||||
based on the capacity of the card.
|
||||
|
||||
For SD, "preferred_erase_size" is the allocation unit
|
||||
size specified by the card.
|
||||
|
||||
"preferred_erase_size" is in bytes.
|
||||
@@ -1,74 +0,0 @@
|
||||
The Wavelan drivers saga
|
||||
------------------------
|
||||
|
||||
By Jean Tourrilhes <jt@hpl.hp.com>
|
||||
|
||||
The Wavelan is a Radio network adapter designed by
|
||||
Lucent. Under this generic name is hidden quite a variety of hardware,
|
||||
and many Linux driver to support it.
|
||||
The get the full story on Wireless LANs, please consult :
|
||||
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/
|
||||
|
||||
"wavelan" driver (old ISA Wavelan)
|
||||
----------------
|
||||
o Config : Network device -> Wireless LAN -> AT&T WaveLAN
|
||||
o Location : .../drivers/net/wireless/wavelan*
|
||||
o in-line doc : .../drivers/net/wireless/wavelan.p.h
|
||||
o on-line doc :
|
||||
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
|
||||
|
||||
This is the driver for the ISA version of the first generation
|
||||
of the Wavelan, now discontinued. The device is 2 Mb/s, composed of a
|
||||
Intel 82586 controller and a Lucent Modem, and is NOT 802.11 compliant.
|
||||
The driver has been tested with the following hardware :
|
||||
o Wavelan ISA 915 MHz (full length ISA card)
|
||||
o Wavelan ISA 915 MHz 2.0 (half length ISA card)
|
||||
o Wavelan ISA 2.4 GHz (full length ISA card, fixed frequency)
|
||||
o Wavelan ISA 2.4 GHz 2.0 (half length ISA card, frequency selectable)
|
||||
o Above cards with the optional DES encryption feature
|
||||
|
||||
"wavelan_cs" driver (old Pcmcia Wavelan)
|
||||
-------------------
|
||||
o Config : Network device -> PCMCIA network ->
|
||||
Pcmcia Wireless LAN -> AT&T/Lucent WaveLAN
|
||||
o Location : .../drivers/net/pcmcia/wavelan*
|
||||
o in-line doc : .../drivers/net/pcmcia/wavelan_cs.h
|
||||
o on-line doc :
|
||||
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
|
||||
|
||||
This is the driver for the PCMCIA version of the first
|
||||
generation of the Wavelan, now discontinued. The device is 2 Mb/s,
|
||||
composed of a Intel 82593 controller (totally different from the 82586)
|
||||
and a Lucent Modem, and NOT 802.11 compatible.
|
||||
The driver has been tested with the following hardware :
|
||||
o Wavelan Pcmcia 915 MHz 2.0 (Pcmcia card + separate
|
||||
modem/antenna block)
|
||||
o Wavelan Pcmcia 2.4 GHz 2.0 (Pcmcia card + separate
|
||||
modem/antenna block)
|
||||
|
||||
"wvlan_cs" driver (Wavelan IEEE, GPL)
|
||||
-----------------
|
||||
o Config : Not yet in kernel
|
||||
o Location : Pcmcia package 3.1.10+
|
||||
o on-line doc :
|
||||
http://web.archive.org/web/*/http://www.fasta.fh-dortmund.de/users/andy/wvlan/
|
||||
|
||||
This is the driver for the current generation of Wavelan IEEE,
|
||||
which is 802.11 compatible. Depending on version, it is 2 Mb/s or 11
|
||||
Mb/s, with or without encryption, all implemented in Lucent specific
|
||||
DSP (the Hermes).
|
||||
This is a GPL full source PCMCIA driver (ISA is just a Pcmcia
|
||||
card with ISA-Pcmcia bridge).
|
||||
|
||||
"wavelan2_cs" driver (Wavelan IEEE, binary)
|
||||
--------------------
|
||||
o Config : Not yet in kernel
|
||||
o Location : ftp://sourceforge.org/pcmcia/contrib/
|
||||
|
||||
This driver support exactly the same hardware as the previous
|
||||
driver, the main difference is that it is based on a binary library
|
||||
and supported by Lucent.
|
||||
|
||||
I hope it clears the confusion ;-)
|
||||
|
||||
Jean
|
||||
@@ -19,7 +19,7 @@ overall control of how tasks are to be run:
|
||||
|
||||
The pcpumask describes which processors will be used to execute work
|
||||
submitted to this instance in parallel. The cbcpumask defines which
|
||||
processors are allowed to use as the serialization callback processor.
|
||||
processors are allowed to be used as the serialization callback processor.
|
||||
The workqueue wq is where the work will actually be done; it should be
|
||||
a multithreaded queue, naturally.
|
||||
|
||||
@@ -30,10 +30,10 @@ cpumasks this helper function can be used:
|
||||
|
||||
Note: Padata maintains two kinds of cpumasks internally. The user supplied
|
||||
cpumasks, submitted by padata_alloc/padata_alloc_possible and the 'usable'
|
||||
cpumasks. The usable cpumasks are always the subset of active cpus in the
|
||||
user supplied cpumasks, these are the cpumasks padata actually use. So
|
||||
it is legal to supply a cpumask to padata that contains offline cpus.
|
||||
Once a offline cpu in the user supplied cpumask comes online, padata
|
||||
cpumasks. The usable cpumasks are always a subset of active CPUs in the
|
||||
user supplied cpumasks; these are the cpumasks padata actually uses. So
|
||||
it is legal to supply a cpumask to padata that contains offline CPUs.
|
||||
Once an offline CPU in the user supplied cpumask comes online, padata
|
||||
is going to use it.
|
||||
|
||||
There are functions for enabling and disabling the instance:
|
||||
@@ -44,7 +44,7 @@ There are functions for enabling and disabling the instance:
|
||||
These functions are setting or clearing the "PADATA_INIT" flag;
|
||||
if that flag is not set, other functions will refuse to work.
|
||||
padata_start returns zero on success (flag set) or -EINVAL if the
|
||||
padata cpumask contains no active cpu (flag not set).
|
||||
padata cpumask contains no active CPU (flag not set).
|
||||
padata_stop clears the flag and blocks until the padata instance
|
||||
is unused.
|
||||
|
||||
@@ -63,11 +63,11 @@ done with great frequency.
|
||||
|
||||
It's possible to change both cpumasks of a padata instance with
|
||||
padata_set_cpumasks by specifying the cpumasks for parallel execution (pcpumask)
|
||||
and for the serial callback function (cbcpumask). padata_set_cpumask is to
|
||||
and for the serial callback function (cbcpumask). padata_set_cpumask is used to
|
||||
change just one of the cpumasks. Here cpumask_type is one of PADATA_CPU_SERIAL,
|
||||
PADATA_CPU_PARALLEL and cpumask specifies the new cpumask to use.
|
||||
To simply add or remove one cpu from a certain cpumask the functions
|
||||
padata_add_cpu/padata_remove_cpu are used. cpu specifies the cpu to add or
|
||||
To simply add or remove one CPU from a certain cpumask the functions
|
||||
padata_add_cpu/padata_remove_cpu are used. cpu specifies the CPU to add or
|
||||
remove and mask is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL.
|
||||
|
||||
If a user is interested in padata cpumask changes, he can register to
|
||||
@@ -82,7 +82,7 @@ To unregister from that notifier:
|
||||
struct notifier_block *nblock);
|
||||
|
||||
The padata cpumask change notifier notifies about changes of the usable
|
||||
cpumasks, i.e. the subset of active cpus in the user supplied cpumask.
|
||||
cpumasks, i.e. the subset of active CPUs in the user supplied cpumask.
|
||||
|
||||
Padata calls the notifier chain with:
|
||||
|
||||
@@ -92,7 +92,7 @@ Padata calls the notifier chain with:
|
||||
|
||||
Here cpumask_change_notifier is registered notifier, notification_mask
|
||||
is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL and cpumask is a pointer
|
||||
to a struct padata_cpumask that contains the new cpumask informations.
|
||||
to a struct padata_cpumask that contains the new cpumask information.
|
||||
|
||||
Actually submitting work to the padata instance requires the creation of a
|
||||
padata_priv structure:
|
||||
@@ -104,7 +104,7 @@ padata_priv structure:
|
||||
};
|
||||
|
||||
This structure will almost certainly be embedded within some larger
|
||||
structure specific to the work to be done. Most its fields are private to
|
||||
structure specific to the work to be done. Most of its fields are private to
|
||||
padata, but the structure should be zeroed at initialisation time, and the
|
||||
parallel() and serial() functions should be provided. Those functions will
|
||||
be called in the process of getting the work done as we will see
|
||||
|
||||
@@ -14,6 +14,8 @@ Required properties:
|
||||
reports inverted write-protect state;
|
||||
- sdhci,1-bit-only : (optional) specifies that a controller can
|
||||
only handle 1-bit data transfers.
|
||||
- sdhci,auto-cmd12: (optional) specifies that a controller can
|
||||
only handle auto CMD12.
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -83,8 +83,8 @@ ALC269
|
||||
======
|
||||
basic Basic preset
|
||||
quanta Quanta FL1
|
||||
eeepc-p703 ASUS Eeepc P703 P900A
|
||||
eeepc-p901 ASUS Eeepc P901 S101
|
||||
laptop-amic Laptops with analog-mic input
|
||||
laptop-dmic Laptops with digital-mic input
|
||||
fujitsu FSC Amilo
|
||||
lifebook Fujitsu Lifebook S6420
|
||||
auto auto-config reading BIOS (default)
|
||||
@@ -109,6 +109,8 @@ ALC662/663/272
|
||||
asus-mode4 ASUS
|
||||
asus-mode5 ASUS
|
||||
asus-mode6 ASUS
|
||||
asus-mode7 ASUS
|
||||
asus-mode8 ASUS
|
||||
dell Dell with ALC272
|
||||
dell-zm1 Dell ZM1 with ALC272
|
||||
samsung-nc10 Samsung NC10 mini notebook
|
||||
@@ -295,8 +297,10 @@ Conexant 5066
|
||||
=============
|
||||
laptop Basic Laptop config (default)
|
||||
dell-laptop Dell laptops
|
||||
dell-vostro Dell Vostro
|
||||
olpc-xo-1_5 OLPC XO 1.5
|
||||
ideapad Lenovo IdeaPad U150
|
||||
thinkpad Lenovo Thinkpad
|
||||
|
||||
STAC9200
|
||||
========
|
||||
@@ -404,6 +408,7 @@ STAC92HD83*
|
||||
mic-ref Reference board with power management for ports
|
||||
dell-s14 Dell laptop
|
||||
hp HP laptops with (inverted) mute-LED
|
||||
hp-dv7-4000 HP dv-7 4000
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC9872
|
||||
@@ -416,3 +421,7 @@ Cirrus Logic CS4206/4207
|
||||
mbp55 MacBook Pro 5,5
|
||||
imac27 IMac 27 Inch
|
||||
auto BIOS setup (default)
|
||||
|
||||
VIA VT17xx/VT18xx/VT20xx
|
||||
========================
|
||||
auto BIOS setup (default)
|
||||
|
||||
21
MAINTAINERS
21
MAINTAINERS
@@ -616,10 +616,10 @@ M: Richard Purdie <rpurdie@rpsys.net>
|
||||
S: Maintained
|
||||
|
||||
ARM/CORTINA SYSTEMS GEMINI ARM ARCHITECTURE
|
||||
M: Paulius Zaleckas <paulius.zaleckas@gmail.com>
|
||||
M: Hans Ulli Kroll <ulli.kroll@googlemail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
T: git git://gitorious.org/linux-gemini/mainline.git
|
||||
S: Odd Fixes
|
||||
T: git git://git.berlios.de/gemini-board
|
||||
S: Maintained
|
||||
F: arch/arm/mach-gemini/
|
||||
|
||||
ARM/EBSA110 MACHINE SUPPORT
|
||||
@@ -641,9 +641,10 @@ T: topgit git://git.openezx.org/openezx.git
|
||||
F: arch/arm/mach-pxa/ezx.c
|
||||
|
||||
ARM/FARADAY FA526 PORT
|
||||
M: Paulius Zaleckas <paulius.zaleckas@gmail.com>
|
||||
M: Hans Ulli Kroll <ulli.kroll@googlemail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Odd Fixes
|
||||
S: Maintained
|
||||
T: git://git.berlios.de/gemini-board
|
||||
F: arch/arm/mm/*-fa*
|
||||
|
||||
ARM/FOOTBRIDGE ARCHITECTURE
|
||||
@@ -692,6 +693,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
|
||||
F: arch/arm/mach-sa1100/jornada720.c
|
||||
F: arch/arm/mach-sa1100/include/mach/jornada720.h
|
||||
|
||||
ARM/INCOME PXA270 SUPPORT
|
||||
M: Marek Vasut <marek.vasut@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/income.c
|
||||
F: arch/arm/mach-pxa/include/mach-pxa/income.h
|
||||
|
||||
ARM/INTEL IOP32X ARM ARCHITECTURE
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
@@ -947,8 +955,9 @@ ARM/SHMOBILE ARM ARCHITECTURE
|
||||
M: Paul Mundt <lethal@linux-sh.org>
|
||||
M: Magnus Damm <magnus.damm@gmail.com>
|
||||
L: linux-sh@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/genesis-2.6.git
|
||||
W: http://oss.renesas.com
|
||||
Q: http://patchwork.kernel.org/project/linux-sh/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lethal/genesis-2.6.git
|
||||
S: Supported
|
||||
F: arch/arm/mach-shmobile/
|
||||
F: drivers/sh/
|
||||
|
||||
@@ -41,9 +41,7 @@ static inline int dma_set_mask(struct device *dev, u64 mask)
|
||||
|
||||
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
|
||||
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
|
||||
#define dma_is_consistent(d, h) (1)
|
||||
|
||||
#define dma_cache_sync(dev, va, size, dir) ((void)0)
|
||||
#define dma_get_cache_alignment() L1_CACHE_BYTES
|
||||
|
||||
#endif /* _ALPHA_DMA_MAPPING_H */
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user