- 26 Jan, 2008 40 commits
-
-
eric miao authored
registers are retained during standby mode, thus it's not necessary to save/restore and checksum Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
When PXA27x wakes up, tick_resume_oneshot() tries to set a timer interrupt to occur immediately. Since PXA27x requires at least MIN_OSCR_DELTA, this causes us to flag an error. tick_program_event() then increments the next event time by min_delta_ns. However, by the time we get back to programming the next event, the OSCR has incremented such that we fail again. We repeatedly retry, but the OSCR is too fast for us - we never catch up, so we never break out of the loop - resulting in us never apparantly resuming. Fix this by doubling min_delta_ns. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
The PXA manuals indicate that when in standby or sleep modes, clocks to peripherals are shut off by the processor itself. Eg: PXA270 standby: "In standby mode, all clocks are disabled except those for the power manager and the RTC." PXA270 sleep: "In sleep mode, all clocks are disabled to the processor and to all peripherals except the RTC." PXA255 sleep: "In Sleep Mode, all processor and peripheral clocks are disabled, except the RTC." Therefore, it should be safe to leave the clock enable register alone prior to entering low power modes for these SoCs. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Wakeup sources on PXA3 are enabled at two levels. First, the MFP configuration has to be set to enable which edges a specific pin will trigger a wakeup. The pin also has to be routed to a functional unit. Lastly, the functional unit must be enabled as a wakeup source in the appropriate AD*ER registers (AD2D0ER for standby resume.) This doesn't fit well with the IRQ wake scheme - we currently do a best effort conversion from IRQ numbers to functional unit wake enable bits. For instance, there's several USB client related enable bits but there's no corresponding IRQs to determine which you'd want. Conversely, there's a single enable bit covering several functional units. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
Hook the MFP code into the power management code so that the MFPs can be reconfigured when suspending and resuming. However, note the FIXME - low power mode MFP configuration may depend on the system state being entered. Also note that we have to clear any detected edge events prior to entering a low power mode - otherwise we immediately wake up. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
There are two reasons for making the MFP configuration to be processor independent, i.e. removing the relationship of configuration bits with actual MFPR register settings: 1. power management sometimes requires the MFP to be configured differently when in run mode or in low power mode 2. for future integration of pxa{25x,27x} GPIO configurations The modifications include: 1. introducing of processor independent MFP configuration bits, as defined in [include/asm-arm/arch-pxa/mfp.h]: bit 0.. 9 - MFP Pin Number (1024 Pins Maximum) bit 10..12 - Alternate Function Selection bit 13..15 - Drive Strength bit 16..18 - Low Power Mode State bit 19..20 - Low Power Mode Edge Detection bit 21..22 - Run Mode Pull State and so on, 2. moving the processor dependent code from mfp.h into mfp-pxa3xx.h 3. cleaning up of the MFPR bit definitions 4. mapping of processor independent MFP configuration into processor specific MFPR register settings is now totally encapsulated within pxa3xx_mfp_config() 5. using of "unsigned long" instead of invented type of "mfp_cfg_t" according to Documentation/CodingStyle Chapter 5, usage of this in platform code will be slowly removed in later patches Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
pxa3xx_mfp_set_xxx() functions are originally provided for overwriting MFP configurations performed by pxa3xx_mfp_config(), the usage of such a dirtry trick is not recommended, since there is currently no user of these functions, they are safely removed Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
There's no point building standby/sleep code for processors which aren't configured. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
PXA3 has a different memory controller from PXA2 platforms. Avoid clashing definitions by moving the PXA2 definitions to pxa2xx-regs.h Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Russell King authored
The mapping for physical address 0x48000000 is not sufficient to allow access to the dynamic memory controller configuration registers on PXA3. These registers need to be accessed to reconfigure the SDRAM when waking from a low power mode. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Bridge Wu authored
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>
-
Bridge Wu authored
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>
-
Bridge Wu authored
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>
-
eric miao authored
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>
-
Philipp Zabel authored
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>
-
Bridge Wu authored
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>
-
Bridge Wu authored
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>
-
Russell King authored
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>
-
Russell King authored
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>
-
Russell King authored
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>
-
eric miao authored
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>
-
eric miao authored
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>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
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>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
eric miao authored
Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
-
Philipp Zabel authored
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>
-
Russell King authored
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>
-
Russell King authored
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>
-
Russell King authored
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>
-
Russell King authored
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>
-