Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
On Thu, May 19, 2011 at 01:08:41PM -0600, Grant Likely wrote: > On Thu, May 12, 2011 at 11:42:39AM +0200, Kevin Hilman wrote: > > Linus Walleij writes: > > > > [...] > > > > > For TI I guess this currently means you simply cannot work > > > on GPIO stuff until you know where to go with it unless you > > > allow the OMAP GPIO authors to keep churning in arch/arm/*... > > > > > > That's unless Grant is OK with us moving stuff into > > > drivers/gpio that does *not* use gpiolib and utilize singletons to > > > get at the gpio_chip addresses (i.e. current form) and keep it > > > churning like that until it can be refactored. > > > > The churn will happen one way or another. the only question is whether > > it happens in drivers/gpio or arch/arm/*. > > > > Grant, what's your feeling here. How much ugliness are you willing to > > tolerate in a bulk move to drivers/gpio. At least for OMAP, I am > > personally be working on the cleanup/move so I can work either way, > > although I know Tony has an obvious preference for moving it to > > drivers/gpio. :) > > > > The OMAP driver is already using gpiolib. The main ugliness in the OMAP > > driver is the awful ifdeffery used to handle the differences across the > > various SoCs in the OMAP family. I've already got most of that cleaned > > up[1]. > > Go ahead and move stuff. I may as well have the junk in my tree. > > I request however to have at least some semblance of organization. > I'd like each driver filename to be named something like gpio_*.c, and Just confirm that you really mean gpio_*.c than *_gpio.c, because I see there have been several *_gpio.c but none gpio_*.c under drivers/gpio. > put things into the Makefile/Kconfig in alphabetical order as much as > possible. > -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
On Thu, May 12, 2011 at 11:42:39AM +0200, Kevin Hilman wrote: > Linus Walleij writes: > > [...] > > > For TI I guess this currently means you simply cannot work > > on GPIO stuff until you know where to go with it unless you > > allow the OMAP GPIO authors to keep churning in arch/arm/*... > > > > That's unless Grant is OK with us moving stuff into > > drivers/gpio that does *not* use gpiolib and utilize singletons to > > get at the gpio_chip addresses (i.e. current form) and keep it > > churning like that until it can be refactored. > > The churn will happen one way or another. the only question is whether > it happens in drivers/gpio or arch/arm/*. > > Grant, what's your feeling here. How much ugliness are you willing to > tolerate in a bulk move to drivers/gpio. At least for OMAP, I am > personally be working on the cleanup/move so I can work either way, > although I know Tony has an obvious preference for moving it to > drivers/gpio. :) > > The OMAP driver is already using gpiolib. The main ugliness in the OMAP > driver is the awful ifdeffery used to handle the differences across the > various SoCs in the OMAP family. I've already got most of that cleaned > up[1]. Go ahead and move stuff. I may as well have the junk in my tree. I request however to have at least some semblance of organization. I'd like each driver filename to be named something like gpio_*.c, and put things into the Makefile/Kconfig in alphabetical order as much as possible. Also, for an awful lot of these SoC gpio controllers there is almost zero value in having a user visible Kconfig entry for it because they are so tiny. I'd rather see on-chip gpio controllers configured in automatically without any user selectable options. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
On Thu, May 12, 2011 at 02:57:04AM +0200, Linus Walleij wrote: > 2011/5/4 Tony Lindgren : > > * Linus Walleij [110504 00:37]: > >> 2011/5/3 Kevin Hilman : > >> > >> > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) > >> > into drivers/gpio first, followed by the cleanup/restructure patches? > >> > >> In my case I actually did some cleanup after moving the driver for > >> U300, but I think this is a question to the GPIO maintainer who > >> I want to ACK this stuff in the end. > >> > >> Grant? > >> > >> You can always squash it later ... > > > > Personally I would prefer absolutely minimal clean-up of current > > code before moving to drivers/gpio to cut down the "crazy churn" in > > arch/arm/. Also then further changes are easier for the GPIO > > maintainers to review. > > > > Of course I understand that this might cause extra load for the > > GPIO maintainers, so it's up to the GPIO maintainers to set the > > required standards before accepting the code into drivers/gpio. > > After discussion with Grant (in person) here at UDS I am informed > that he will not be able to review my GPIO consolidation patches in > time to make adjustments needed for this merge window, so we're > aiming at early 2.6.41 for these. > > He has indicated that he has problems with the chosen config > mechanism and that we may need to back a few technical > assumptions out, and we need some more time for that. > > For example we may need to refer to configurations by a string > or indeed export the struct gpio_chip accessor function > gpio_to_chip() and use custom functions for special stuff, > as was the first idea. > > I will do the refactoring once I have a clear indication from the > maintainer where he wants this to end up, so my GPIO > consolidation patches will need to rest for a while. > > For TI I guess this currently means you simply cannot work > on GPIO stuff until you know where to go with it unless you > allow the OMAP GPIO authors to keep churning in arch/arm/*... > > That's unless Grant is OK with us moving stuff into > drivers/gpio that does *not* use gpiolib and utilize singletons to > get at the gpio_chip addresses (i.e. current form) and keep it > churning like that until it can be refactored. I'm okay with non-gpiolib drivers being moved in before they are cleaned up. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Linus Walleij writes: [...] > For TI I guess this currently means you simply cannot work > on GPIO stuff until you know where to go with it unless you > allow the OMAP GPIO authors to keep churning in arch/arm/*... > > That's unless Grant is OK with us moving stuff into > drivers/gpio that does *not* use gpiolib and utilize singletons to > get at the gpio_chip addresses (i.e. current form) and keep it > churning like that until it can be refactored. The churn will happen one way or another. the only question is whether it happens in drivers/gpio or arch/arm/*. Grant, what's your feeling here. How much ugliness are you willing to tolerate in a bulk move to drivers/gpio. At least for OMAP, I am personally be working on the cleanup/move so I can work either way, although I know Tony has an obvious preference for moving it to drivers/gpio. :) The OMAP driver is already using gpiolib. The main ugliness in the OMAP driver is the awful ifdeffery used to handle the differences across the various SoCs in the OMAP family. I've already got most of that cleaned up[1]. Kevin [1] http://marc.info/?l=linux-omap&m=130351321022770&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
2011/5/4 Tony Lindgren : > * Linus Walleij [110504 00:37]: >> 2011/5/3 Kevin Hilman : >> >> > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) >> > into drivers/gpio first, followed by the cleanup/restructure patches? >> >> In my case I actually did some cleanup after moving the driver for >> U300, but I think this is a question to the GPIO maintainer who >> I want to ACK this stuff in the end. >> >> Grant? >> >> You can always squash it later ... > > Personally I would prefer absolutely minimal clean-up of current > code before moving to drivers/gpio to cut down the "crazy churn" in > arch/arm/. Also then further changes are easier for the GPIO > maintainers to review. > > Of course I understand that this might cause extra load for the > GPIO maintainers, so it's up to the GPIO maintainers to set the > required standards before accepting the code into drivers/gpio. After discussion with Grant (in person) here at UDS I am informed that he will not be able to review my GPIO consolidation patches in time to make adjustments needed for this merge window, so we're aiming at early 2.6.41 for these. He has indicated that he has problems with the chosen config mechanism and that we may need to back a few technical assumptions out, and we need some more time for that. For example we may need to refer to configurations by a string or indeed export the struct gpio_chip accessor function gpio_to_chip() and use custom functions for special stuff, as was the first idea. I will do the refactoring once I have a clear indication from the maintainer where he wants this to end up, so my GPIO consolidation patches will need to rest for a while. For TI I guess this currently means you simply cannot work on GPIO stuff until you know where to go with it unless you allow the OMAP GPIO authors to keep churning in arch/arm/*... That's unless Grant is OK with us moving stuff into drivers/gpio that does *not* use gpiolib and utilize singletons to get at the gpio_chip addresses (i.e. current form) and keep it churning like that until it can be refactored. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Linus Walleij [110504 00:37]: > 2011/5/3 Kevin Hilman : > > > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) > > into drivers/gpio first, followed by the cleanup/restructure patches? > > In my case I actually did some cleanup after moving the driver for > U300, but I think this is a question to the GPIO maintainer who > I want to ACK this stuff in the end. > > Grant? > > You can always squash it later ... Personally I would prefer absolutely minimal clean-up of current code before moving to drivers/gpio to cut down the "crazy churn" in arch/arm/. Also then further changes are easier for the GPIO maintainers to review. Of course I understand that this might cause extra load for the GPIO maintainers, so it's up to the GPIO maintainers to set the required standards before accepting the code into drivers/gpio. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
2011/5/3 Kevin Hilman : > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) > into drivers/gpio first, followed by the cleanup/restructure patches? In my case I actually did some cleanup after moving the driver for U300, but I think this is a question to the GPIO maintainer who I want to ACK this stuff in the end. Grant? You can always squash it later ... Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Linus Walleij writes: > 2011/4/26 Tony Lindgren : >> * Linus Walleij [110423 01:32]: >>> Since you'll probably be dependent on stuff happening in my patches >>> to move stuff into drivers/gpio I'll be happy to carry the patches in my >>> gpio-consolidation branch with Tony's ACKs if need be. >> >> Sounds good to me. > > I've just posted a patch series that moves "our" two GPIO drivers to > drivers/gpio, they should serve as good inspiration... Tell me if I can > help out, stack patches on top of this series and I'll carry them. Great, thanks. Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into drivers/gpio first, followed by the cleanup/restructure patches? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
2011/4/26 Tony Lindgren : > * Linus Walleij [110423 01:32]: >> Since you'll probably be dependent on stuff happening in my patches >> to move stuff into drivers/gpio I'll be happy to carry the patches in my >> gpio-consolidation branch with Tony's ACKs if need be. > > Sounds good to me. I've just posted a patch series that moves "our" two GPIO drivers to drivers/gpio, they should serve as good inspiration... Tell me if I can help out, stack patches on top of this series and I'll carry them. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Linus Walleij [110423 01:32]: > 2011/4/21 Tony Lindgren : > > * Kevin Hilman [110421 02:56]: > > >> > - Move it to drivers/gpio > >> > > >> > - Further consolidate with whatever common GPIO code might > >> > be coming up. > >> > >> Is the above order required? > > > > Yes please. Otherwise we'll have more of the "crazy churn" in > > arch/arm/*omap*/ and the runtime PM patches should apply easily > > in drivers/gpio too. > > Since you'll probably be dependent on stuff happening in my patches > to move stuff into drivers/gpio I'll be happy to carry the patches in my > gpio-consolidation branch with Tony's ACKs if need be. Sounds good to me. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
2011/4/21 Tony Lindgren : > * Kevin Hilman [110421 02:56]: >> > - Move it to drivers/gpio >> > >> > - Further consolidate with whatever common GPIO code might >> > be coming up. >> >> Is the above order required? > > Yes please. Otherwise we'll have more of the "crazy churn" in > arch/arm/*omap*/ and the runtime PM patches should apply easily > in drivers/gpio too. Since you'll probably be dependent on stuff happening in my patches to move stuff into drivers/gpio I'll be happy to carry the patches in my gpio-consolidation branch with Tony's ACKs if need be. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Kevin Hilman [110421 18:12]: > Tony Lindgren writes: > > > > Saw that, looks good :) Need to post it also to lakml BTW. > > Yeah, I only posted to l-o so far because it's not done. I only removed > a few of the #ifdef sections, there are still several more to do. Oh I see. Anyways looks good to me. I can give it a try next week too on few boards. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Tony Lindgren writes: > * Kevin Hilman [110421 02:56]: >> Hi Tony, >> >> Tony Lindgren writes: >> >> > * Varadarajan, Charulatha [110418 18:00]: >> >> From: Charulatha V >> >> >> >> Use PM runtime framework in OMAP GPIO driver. >> > ... >> > >> >> arch/arm/mach-omap2/gpio.c |6 + >> >> arch/arm/mach-omap2/pm34xx.c | 22 +- >> >> arch/arm/plat-omap/gpio.c | 766 >> >> ++-- >> >> arch/arm/plat-omap/include/plat/gpio.h |3 +- >> >> 4 files changed, 439 insertions(+), 358 deletions(-) >> > >> > Before this series gets merged we first need to do the following: >> > - Pass some registers in platform_data so we can have common >> > functions in gpio.c instead of having to test for the bank->method >> > in each function. This allows getting rid of the ifdefs as >> > discussed in the ARM Linux consolidation thread. >> >> I have a series that starts this process, will post it shortly. > > Saw that, looks good :) Need to post it also to lakml BTW. Yeah, I only posted to l-o so far because it's not done. I only removed a few of the #ifdef sections, there are still several more to do. >> > - Move it to drivers/gpio >> > >> > - Further consolidate with whatever common GPIO code might >> > be coming up. >> >> Is the above order required? > > Yes please. Otherwise we'll have more of the "crazy churn" in > arch/arm/*omap*/ and the runtime PM patches should apply easily > in drivers/gpio too. > >> IMO, before we move it to drivers/gpio, this code needs to be runtime PM >> converted (using this series from Charu.) The runtime PM conversion >> removes a bunch of platform-specific hacks that should be moved into >> drivers/*. >> >> Personally, I think we should go in this order >> >> - runtime PM conversion > > Let's do this after the consolidation and move to drivers/gpio. > This way any additions can be reviewed by the drivers/gpio maintainers. OK >> - #ifdef cleanup > > Looks like you got this already done :) Well, it's only partially done. I only converted the direction and data in/out functions. There are several others to do still. >> - move to drivers/gpio > > With this part there may be more comments from the drivers/gpio > maintainers so we need to get to this point ASAP. OK >> - look at consolidation with other drivers >> >> I'm willing to queue the GPIO work in my tree while it's under way if >> you like as well. > > If so, please put all the consolidation patches into a separate > branch with absolutely zero additional new code. And let's merge > those branches into linux-omap devel-cleanup branch on regular > basis for testing. > OK Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Kevin Hilman [110421 02:56]: > Hi Tony, > > Tony Lindgren writes: > > > * Varadarajan, Charulatha [110418 18:00]: > >> From: Charulatha V > >> > >> Use PM runtime framework in OMAP GPIO driver. > > ... > > > >> arch/arm/mach-omap2/gpio.c |6 + > >> arch/arm/mach-omap2/pm34xx.c | 22 +- > >> arch/arm/plat-omap/gpio.c | 766 > >> ++-- > >> arch/arm/plat-omap/include/plat/gpio.h |3 +- > >> 4 files changed, 439 insertions(+), 358 deletions(-) > > > > Before this series gets merged we first need to do the following: > > - Pass some registers in platform_data so we can have common > > functions in gpio.c instead of having to test for the bank->method > > in each function. This allows getting rid of the ifdefs as > > discussed in the ARM Linux consolidation thread. > > I have a series that starts this process, will post it shortly. Saw that, looks good :) Need to post it also to lakml BTW. > > - Move it to drivers/gpio > > > > - Further consolidate with whatever common GPIO code might > > be coming up. > > Is the above order required? Yes please. Otherwise we'll have more of the "crazy churn" in arch/arm/*omap*/ and the runtime PM patches should apply easily in drivers/gpio too. > IMO, before we move it to drivers/gpio, this code needs to be runtime PM > converted (using this series from Charu.) The runtime PM conversion > removes a bunch of platform-specific hacks that should be moved into > drivers/*. > > Personally, I think we should go in this order > > - runtime PM conversion Let's do this after the consolidation and move to drivers/gpio. This way any additions can be reviewed by the drivers/gpio maintainers. > - #ifdef cleanup Looks like you got this already done :) > - move to drivers/gpio With this part there may be more comments from the drivers/gpio maintainers so we need to get to this point ASAP. > - look at consolidation with other drivers > > I'm willing to queue the GPIO work in my tree while it's under way if > you like as well. If so, please put all the consolidation patches into a separate branch with absolutely zero additional new code. And let's merge those branches into linux-omap devel-cleanup branch on regular basis for testing. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Hi Tony, Tony Lindgren writes: > * Varadarajan, Charulatha [110418 18:00]: >> From: Charulatha V >> >> Use PM runtime framework in OMAP GPIO driver. > ... > >> arch/arm/mach-omap2/gpio.c |6 + >> arch/arm/mach-omap2/pm34xx.c | 22 +- >> arch/arm/plat-omap/gpio.c | 766 >> ++-- >> arch/arm/plat-omap/include/plat/gpio.h |3 +- >> 4 files changed, 439 insertions(+), 358 deletions(-) > > Before this series gets merged we first need to do the following: > - Pass some registers in platform_data so we can have common > functions in gpio.c instead of having to test for the bank->method > in each function. This allows getting rid of the ifdefs as > discussed in the ARM Linux consolidation thread. I have a series that starts this process, will post it shortly. > - Move it to drivers/gpio > > - Further consolidate with whatever common GPIO code might > be coming up. Is the above order required? IMO, before we move it to drivers/gpio, this code needs to be runtime PM converted (using this series from Charu.) The runtime PM conversion removes a bunch of platform-specific hacks that should be moved into drivers/*. Personally, I think we should go in this order - runtime PM conversion - #ifdef cleanup - move to drivers/gpio - look at consolidation with other drivers I'm willing to queue the GPIO work in my tree while it's under way if you like as well. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
* Varadarajan, Charulatha [110418 18:00]: > From: Charulatha V > > Use PM runtime framework in OMAP GPIO driver. ... > arch/arm/mach-omap2/gpio.c |6 + > arch/arm/mach-omap2/pm34xx.c | 22 +- > arch/arm/plat-omap/gpio.c | 766 > ++-- > arch/arm/plat-omap/include/plat/gpio.h |3 +- > 4 files changed, 439 insertions(+), 358 deletions(-) Before this series gets merged we first need to do the following: - Pass some registers in platform_data so we can have common functions in gpio.c instead of having to test for the bank->method in each function. This allows getting rid of the ifdefs as discussed in the ARM Linux consolidation thread. - Move it to drivers/gpio - Further consolidate with whatever common GPIO code might be coming up. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[v2 0/7] OMAP: GPIO: Use PM runtime framework
From: Charulatha V Use PM runtime framework in OMAP GPIO driver. Patch series is based on mainline rc3 following commit commit a1b49cb7e2a7961ec3aa8b64860bf480d4ec9077 Merge branch 'i2c-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Changes in v2: * Use a per-bank flag 'looses_context' (using pwrdm_can_ever_lose_context()) instead of using the powerdomain name * Make use of omap_device_get_context_loss_count() to decide on if restore context needs to be done. * Do not remove #ifdef CONFIG_ARCH_OMAP2PLUS * Do not use pm_runtime_suspended() before calling pm_runtime_get_sync/put_sync * use IS_ERR_VALUE() instead of '< 0' in "if" conditions (Thanks to Kevin and Paul for the above suggestions) Previous version of this patch series is available at: http://ns.spinics.net/lists/linux-omap/msg48167.html http://ns.spinics.net/lists/linux-omap/msg47989.html http://ns.spinics.net/lists/linux-omap/msg47827.html http://ns.spinics.net/lists/linux-omap/msg47830.html Compile tested for: - omap1_defconfig - omap2plus_defconfig Boot test (success on the following boards): - OMAP1710-H3 - OMAP2420-H4 - OMAP3430-SDP - OMAP3430-Zoom2 - OMAP3630-Zoom3 - OMAP4430-SDP GPIO module functionality testing (success on the following boards): - OMAP2420-H4 - OMAP3430-SDP - OMAP3430-Zoom2 - OMAP3630-Zoom3 - OMAP4430-SDP PM Testing (success as given below): OMAP3430-SDP: retention, off_mode, system_wide suspend, gpio wakeup OMAP3630-Zoom3: retention, system_wide suspend using the following: echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout echo 5 > /sys/devices/platform/omap/omap_uart.3/sleep_timeout echo '5' > /debug/pm_debug/wakeup_timer_seconds echo 1 > /debug/pm_debug/sleep_while_idle echo 1 > /debug/pm_debug/enable_off_mode echo mem > /sys/power/state Charulatha V (7): OMAP: GPIO: Make gpio_context part of gpio_bank structure OMAP: GPIO: Use flag to identify wkup dmn GPIO OMAP4: GPIO: Save/restore context OMAP: GPIO: handle save/restore ctx in GPIO driver OMAP2+: GPIO: make workaround_enabled bank specific OMAP: GPIO: Cleanup prepare_for_idle/resume OMAP: GPIO: use PM runtime framework arch/arm/mach-omap2/gpio.c |6 + arch/arm/mach-omap2/pm34xx.c | 22 +- arch/arm/plat-omap/gpio.c | 766 ++-- arch/arm/plat-omap/include/plat/gpio.h |3 +- 4 files changed, 439 insertions(+), 358 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
