2 Commits (481c5346d0981940ee63037eb53e4e37b0735c10)

Author	SHA1	Message	Date
eric miao	c0a596d6a1	[ARM] pxa: allow dynamic enable/disable of GPIO wakeup for pxa{25x,27x} ... Changes include: 1. rename MFP_LPM_WAKEUP_ENABLE into MFP_LPM_CAN_WAKEUP to indicate the board capability of this pin to wakeup the system 2. add gpio_set_wake() and keypad_set_wake() to allow dynamically enable/disable wakeup from GPIOs and keypad GPIO * these functions are currently kept in mfp-pxa2xx.c due to their dependency to the MFP configuration 3. pxa2xx_mfp_config() only gives early warning if MFP_LPM_CAN_WAKEUP is set on incorrect pins So that the GPIO's wakeup capability is now decided by the following: a) processor's capability: (only those GPIOs which have dedicated bits within PWER/PRER/PFER can wakeup the system), this is initialized by pxa{25x,27x}_init_mfp() b) board design decides: - whether the pin is designed to wakeup the system (some of the GPIOs are configured as other functions, which is not intended to be a wakeup source), by OR'ing the pin config with MFP_LPM_CAN_WAKEUP - which edge the pin is designed to wakeup the system, this may depends on external peripherals/connections, which is totally board specific; this is indicated by MFP_LPM_EDGE_* c) the corresponding device's (most likely the gpio_keys.c) wakeup attribute: Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>	17 years ago
eric miao	7facc2f937	[ARM] pxa: add MFP-alike pin configuration support for pxa{25x, 27x} ... Pin configuration on pxa{25x,27x} has now separated from generic GPIO into dedicated mfp-pxa2xx.c by this patch. The name "mfp" is borrowed from pxa3xx and is used here to alert the difference between the two concepts: pin configuration and generic GPIOs. A GPIO can be called a "GPIO" _only_ when the corresponding pin is configured so. A pin configuration on pxa{25x,27x} is composed of: - alternate function selection (or pin mux as commonly called) - low power state or sleep state - wakeup enabling from low power mode The following MFP_xxx bit definitions in mfp.h are re-used: - MFP_PIN(x) - MFP_AFx - MFP_LPM_DRIVE_{LOW, HIGH} - MFP_LPM_EDGE_* Selecting alternate function on pxa{25x, 27x} involves configuration of GPIO direction register GPDRx, so a new bit and MFP_DIR_{IN, OUT} are introduced. And pin configurations are defined by the following two macros: - MFP_CFG_IN : for input alternate functions - MFP_CFG_OUT : for output alternate functions Every configuration should provide a low power state if it configured as output using MFP_CFG_OUT(). As a general guideline, the low power state should be decided to minimize the overall power dissipation. As an example, it is better to drive the pin as high level in low power mode if the GPIO is configured as an active low chip select. Pins configured as GPIO are defined by MFP_CFG_IN(). This is to avoid side effects when it is firstly configured as output. The actual direction of the GPIO is configured by gpio_direction_{input, output} Wakeup enabling on pxa{25x, 27x} is actually GPIO based wakeup, thus the device based enable_irq_wake() mechanism is not applicable here. E.g. invoking enable_irq_wake() with a GPIO IRQ as in the following code to enable OTG wakeup is by no means portable and intuitive, and it is valid _only_ when GPIO35 is configured as USB_P2_1: enable_irq_wake( gpio_to_irq(35) ); To make things worse, not every GPIO is able to wakeup the system. Only a small number of them can, on either rising or falling edge, or when level is high (for keypad GPIOs). Thus, another new bit is introduced to indicate that the GPIO will wakeup the system: - MFP_LPM_WAKEUP_ENABLE The following macros can be used in platform code, and be OR'ed to the GPIO configuration to enable its wakeup: - WAKEUP_ON_EDGE_{RISE, FALL, BOTH} - WAKEUP_ON_LEVEL_HIGH The WAKEUP_ON_LEVEL_HIGH is used for keypad GPIOs _only_, there is no edge settings for those GPIOs. These WAKEUP_ON_* flags OR'ed on wrong GPIOs will be ignored in case that platform code author is careless enough. The tradeoff here is that the wakeup source is fully determined by the platform configuration, instead of enable_irq_wake(). Signed-off-by: eric miao <eric.miao@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>	17 years ago