summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2008-01-26[ARM] pxa: make OHCI register definitions available to both pxa27x and pxa3xxeric miao
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: add clk of CKEN_USBHOST for pxa3xxeric miao
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: ensure SSP TX FIFO is empty instead of not full for pxa3xxeric miao
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: mmc: add 3rd host controller support for pxa310Bridge Wu
This patch is to add the third mmc controller support _only_ for pxa310. On zylonite, the third controller support one slot. Signed-off-by: Bridge Wu <bridge.wu@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: mmc: add 2nd host controller support for pxa3xxBridge Wu
This patch is to add the second mmc controller support for pxa3xx. It's valid for pxa3[0|1|2]0. On zylonite, the second controller has no slot. Signed-off-by: Bridge Wu <bridge.wu@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: mmc: add 1st host controller support for pxa3xxBridge Wu
This patchis to add the first mmc controller support for pxa3xx. It's valid for pxa3[0|1|2]0. On zylonite, the first controller supports two slots, this patch only support the first one right now. Signed-off-by: Bridge Wu <bridge.wu@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: create arch/arm/mach-pxa/device.c for all on-chip deviceseric miao
Considering that generic.c is getting more and more bloated by device information, moving that part out side will be much cleaner. Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] 4718/1: Fix redefinition warnings in PXA uncompressor codePhilipp Zabel
FFUART and friends are already defined as __REG(x) in pxa-regs.h. Instead of redefining them here, we can just provide the __REG macro. Including asm/arch/hardware.h is not an option because this physical addresses are needed here. This is a fix for the compiler warnings generated by 4663/1. Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] 4711/1: pxa: mmc: move DMA specific code to platform layerBridge Wu
This patch is to move pxamci DMA specific code to corresponding platform layer because using DRCMRRXMMC/DRCMRTXMMC in pxamci.c makes the driver code dedicated to platform which is not extensible. It is applicable to all pxa platforms. Signed-off-by: Bridge Wu <bridge.wu@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] 4709/1: pxa: mmc: add 26MHz support for pxa3[0|1]0 mmc controllerBridge Wu
pxa3[0|1]0 mmc controller can support 26MHz clock mode, they support SD spec 1.1 and MMC spec 4.0 which specify high speed mode. So host caps will include MMC_CAP_MMC_HIGHSPEED and MMC_CAP_SD_HIGHSPEED for pxa3[0|1]0. This patch is to add 26MHz support for them. pxa host clock will be set to 26MHz mode when the card supported max clock rate is higher than or equal to 26MHz. Signed-off-by: Bridge Wu <bridge.wu@marvell.com> Acked-by: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: add cpufreq supportRussell King
There have been patches hanging around for ages to add support for cpufreq to PXA255 processors. It's about time we applied one. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: initialise SSP earlierRussell King
Initialise the SSP driver at arch_initcall() time, so it's available for other drivers to use it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: only register "cpld_irq" for the correct platformRussell King
Only register the "cpld_irq" sysclass for mainstone/lubbock if we're running on one of those platforms. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: make pxa2xx_spi driver use ssp_request()/ssp_free()eric miao
1. make pxa2xx_spi.c use ssp_request() and ssp_free() to get the common information of the designated SSP port. 2. remove those IRQ/memory request code, ssp_request() has done that for the driver 3. the SPI platform device is thus made psuedo, no resource (memory/IRQ) has to be defined, all will be retreived by ssp_request() 4. introduce ssp_get_clk_div() to handle controller difference in clock divisor setting 5. use clk_xxx() API for clock enable/disable, and clk_get_rate() to handle the different SSP clock frequency between different processors Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: use __raw_writel()/__raw_readl() for ssp_xxxx()eric miao
1. change SSP register definitions from absolute virtual addresses to offsets 2. use __raw_writel()/__raw_readl() for functions of ssp_xxxx() Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: move SSP register definitions from pxa-regs.h to regs-ssp.heric miao
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: define "struct ssp_device" and add ssp_request()/ssp_free()eric miao
1. define "struct ssp_device" for SSP information, which is requested and released by function ssp_request()/ssp_free() 2. modify the ssp_init() and ssp_exit() to use the interface Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: add ssp devices and clk support for pxa25x/pxa27x/pxa3xxeric miao
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: define SSP platform devices for pxa2xx/pxa3xxeric miao
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] 4663/1: Only putc uncompressor output into FFUART if it was enabled by ↵Philipp Zabel
the bootloader Also, use existing register and bit definitions instead of numbers. Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa/sa1100: replace wakeup supportRussell King
Replace wakeup support using the alarm via the SA1100 RTC driver on SA1100 and PXA platforms. This allows RTC alarm wakeup to be enabled via sysfs using the conventional attributes. Acked-by: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: Don't wind OSCR backwards over suspend/resumeRussell King
OSCR is supposed to monotonically increment; however restoring it to a time prior to OSMR0 may result in it being wound backwards. Instead, if OSMR0 is within the minimum expiry time, wind OSMR0 forwards. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: remove periodic mode emulation supportRussell King
Apparantly, the generic time subsystem can accurately emulate periodic mode via the one-shot support code, so we don't need our own periodic emulation code anymore. Just ensure that we build support for one shot into the generic time subsystem. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: mainstone: update backlight to use the backlight infrastructureRussell King
Linux has framebuffer backlight support infrastructure which should be used to expose backlight attributes. Mainstone should use it. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] pxa: avoid always registering MMC, I2C, IrDA and framebuffer devicesRussell King
Only register the MMC, framebuffer, I2C and FICP devices when the platform supplies the necessary platform data structures for the devices. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: implement power-off method for QNAP TS-109/209Herbert Valerio Riedel
Since the PIC is attached to UART1, it doesn't need a kernel device driver of its own; but powering off is something that the kernel should do, so this patch forcefully configures the UART1 for 19200 baud and sends the character that tells the PIC to cut the power. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Cc: Byron Bradley <byron.bbradley@gmail.com> Acked-by: Nicolas Pitre <nico@marvell.com>
2008-01-26[ARM] Orion: add support for QNAP TS-109/TS-209Byron Bradley
This patch adds support for the Orion/MV88F5182 based QNAP TS-109/TS-209 NAS device. The driver for the S-35390A RTC chip on this board has been submitted to LKML separately. Signed-off-by: Byron Bradley <byron.bbradley@gmail.com> Tested-by: Oyvind Repvik <repvik@kynisk.com> Tested-by: Tim Ellis <timtimred@foonas.org> Tested-by: Herbert Valerio Riedel <hvr@gnu.org> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
2008-01-26[ARM] Orion: I2C supportHerbert Valerio Riedel
The Orion I2C controller is the same one used in the Discovery family (MV643XX). This patch include the common platform_device stuff according to the existing i2c_mv64xxx.c conventions. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Signed-off-by: Tzachi Perelstein <tzachi@marvell.com>
2008-01-26[I2C] i2c-mv64xxx: Don't set i2c_adapter.retriesJean Delvare
I2C adapter drivers are supposed to handle retries on nack by themselves if they do, so there's no point in setting .retries if they don't. As this retry mechanism is going away (at least in its current form), clean this up now so that we don't get build failures later. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Mark A. Greer <mgreer@mvista.com>
2008-01-26[I2C] Split mv643xx I2C platform supportTzachi Perelstein
The motivation for this change is to allow other chips, like the Marvell Orion ARM SoC family, to use the existing i2c-mv64xxx driver. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Nicolas Pitre <nico@marvell.com> Acked-by: Dale Farnsworth <dale@farnsworth.org> Acked-by: Mark A. Greer <mgreer@mvista.com> Acked-by: Jean Delvare <khali@linux-fr.org>
2008-01-26[ARM] Orion: enable CONFIG_RTC_DRV_M41T80 for D-Link DNS-323Martin Michlmayr
The D-Link DNS-323 uses a M41T80 RTC chip, so enable this driver in the Orion defconfig. Signed-off-by: Martin Michlmayr <tbm@cyrius.com> Cc: Herbert Valerio Riedel <hvr@gnu.org> Acked-by: Nicolas Pitre <nico@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion defconfigTzachi Perelstein
Basic selections for Orion machines Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Signed-off-by: Nicolas Pitre <nico@cam.org> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: add support for Orion/MV88F5181 based D-Link DNS-323Herbert Valerio Riedel
With this patch USB, SATA (via sata_mv), Ethernet, RTC, LEDs and NOR Flash work. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Acked-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: MV88F5181 support bitsHerbert Valerio Riedel
add MV88F5181 support bits required by D-link DNS-323 patch Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Acked-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: Buffalo/Revogear Kurobox Pro supportRonen Shitrit
Only serial, NOR, NAND, PCI and Ethernet is activated at the moment. Signed-off-by: Ronen Shitrit <rshitrit@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] OrionNAS RD board supportRonen Shitrit
serial, NOR, PCI and Ethernet is activated at the moment. Signed-off-by: Ronen Shitrit <rshitrit@marvell.com> Reviewed-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: support for Marvell Orion-2 (88F5281) Development BoardTzachi Perelstein
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: common platform setup for Gigabit Ethernet portTzachi Perelstein
The Orion Ethernet port is the same port used in the Discovery family (MV643XX). This patch include the common platform_device stuff according to the existing mv643xx_eth conventions. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: platform device registration for UART, USB and NANDTzachi Perelstein
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: system timer supportTzachi Perelstein
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion edge GPIO IRQ supportTzachi Perelstein
This patch adds support for Orion edge sensitive GPIO IRQs. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com> CC: Thomas Gleixner <tglx@linutronix.de>
2008-01-26[ARM] Orion: IRQ supportTzachi Perelstein
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: provide GPIO method for enabling hardware assisted blinkingHerbert Valerio Riedel
This is a pre-requisite for implementing proper hardware accelerated GPIO LED flashing, and since we want proper locking, it's sensible to provide the orion specific orion_gpio_set_blink() implementation within mach-orion/gpio.c. The functions orion_gpio_set_blink() and gpio_set_value() implicitly turn off each others state. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org> Acked-by: Tzachi Perelstein <tzachi@marvell.com> Acked-by: Nicolas Pitre <nico@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Orion: GPIO supportTzachi Perelstein
Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com> Acked-by: David Brownell <david-b@pacbell.net>
2008-01-26[ARM] Orion: programable address map supportTzachi Perelstein
The Orion has fully programable address map. There's a separate address map for each of the device _master_ interfaces, e.g. CPU, PCI, PCIE, USB, Gigabit Ethernet, DMA/XOR engines, etc. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com>
2008-01-26[ARM] Orion: PCI supportTzachi Perelstein
This patch adds support for PCI and PCI-E controllers in the Orion, Orion-NAS and Orion2. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] basic support for the Marvell Orion SoC familyTzachi Perelstein
The Marvell Orion is a family of ARM SoCs with a DDR/DDR2 memory controller, 10/100/1000 ethernet MAC, and USB 2.0 interfaces, and, depending on the specific model, PCI-E interface, PCI-X interface, SATA controllers, crypto unit, SPI interface, SDIO interface, device bus, NAND controller, DMA engine and/or XOR engine. This contains the basic structure and architecture register definitions. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Reviewed-by: Nicolas Pitre <nico@marvell.com> Reviewed-by: Lennert Buytenhek <buytenh@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] Feroceon: support old cores with ARM926 IDTzachi Perelstein
This enables the usage of some old Feroceon cores for which the CPU ID is equal to the ARM926 ID. Relevant for Feroceon-1850 and old Feroceon-2850. Signed-off-by: Tzachi Perelstein <tzachi@marvell.com> Signed-off-by: Nicolas Pitre <nico@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] add Feroceon support to compressed/head.SNicolas Pitre
The cache replacement policy on the Feroceon core doesn't guarantee that reading through a linear chunk of memory flushes the entire cache. This is however what the default method for ARMv5TE cores does. Although the Feroceon is an ARMv5TE core, it implements the same cache handling instructions as the ARMv5TEJ cores, and must use it for proper cache flush. Signed-off-by: Nicolas Pitre <nico@marvell.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
2008-01-26[ARM] add ARMv5TEJ aware cache flush method to compressed/head.SNicolas Pitre
The default ARMv4 method consisting of reading through some memory area isn't compatible with the cache replacement policy of some ARMv5TEJ compatible cache implementations. It is also a bit wasteful when a dedicated instruction can do the needed work optimally. It is hard to tell if all ARMv5TEJ cores will support the used CP15 instruction, but at least all those implementations Linux currently knows about (ARM926 and ARM1026) do support it. Tested on an OMAP1610 H2 target. Signed-off-by: Nicolas Pitre <nico@marvell.com> Tested-by: George G. Davis <gdavis@mvista.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>