OMAP: GPIO: Use PM runtime framework
v2 cover OMAP: GPIO: Use PM runtime framework
From: Charulatha V <[email protected]>
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(-)
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 3 lines · Varadarajan, Charulatha
From: Charulatha V <[email protected]>
Use PM runtime framework in OMAP GPIO driver.
...
Quoted 5 lines
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
v2 cover OMAP: GPIO: Use PM runtime framework
Hi Tony,
Quoted 12 lines · Tony Lindgren
Quoted 3 lines · Varadarajan, Charulatha
From: Charulatha V <[email protected]>
Use PM runtime framework in OMAP GPIO driver.
...
Quoted 5 lines
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(-)
Quoted 5 lines
Before this series gets merged we first need to do the following:
- Pass some registers inplatform_dataso we can have common functions ingpio.cinstead of having to test for thebank->methodin 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.
Quoted 4 lines
- 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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 16 lines · Kevin Hilman
Hi Tony,
Quoted 12 lines · Tony Lindgren
Quoted 3 lines · Varadarajan, Charulatha
From: Charulatha V <[email protected]>
Use PM runtime framework in OMAP GPIO driver.
...
Quoted 5 lines
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(-)
Quoted 7 lines
Quoted 5 lines
Before this series gets merged we first need to do the following:
- Pass some registers inplatform_dataso we can have common functions ingpio.cinstead of having to test for thebank->methodin 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.
Quoted 6 lines
Quoted 4 lines
- 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.
Quoted 8 lines
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 intodrivers/*.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.
Quoted 1 line
- #ifdef cleanup
Looks like you got this already done :)
Quoted 1 line
- 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.
Quoted 4 lines
- 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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 23 lines · Tony Lindgren
Quoted 22 lines · Kevin Hilman
Hi Tony,
Quoted 17 lines · Tony Lindgren
Quoted 3 lines · Varadarajan, Charulatha
From: Charulatha V <[email protected]>
Use PM runtime framework in OMAP GPIO driver.
...
Quoted 5 lines
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 inplatform_dataso we can have common functions ingpio.cinstead of having to test for thebank->methodin each function. This allows getting rid of the ifdefs as discussed in the ARM Linux consolidation thread.
Quoted 3 lines
Quoted 1 line
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.
Quoted 16 lines
Quoted 6 lines
Quoted 4 lines
- 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 indrivers/gpiotoo.Quoted 5 lines
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 intodrivers/*.
Quoted 6 lines
Quoted 3 lines
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 thedrivers/gpiomaintainers.
OK
Quoted 3 lines
Quoted 1 line
- #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.
Quoted 4 lines
Quoted 1 line
- move to
drivers/gpioWith this part there may be more comments from the
drivers/gpiomaintainers so we need to get to this point ASAP.
OK
Quoted 10 lines
Quoted 4 lines
- 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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 6 lines · Kevin Hilman
Quoted 2 lines · Tony Lindgren
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
v2 cover OMAP: GPIO: Use PM runtime framework
In reply to Tony Lindgren2011/4/21 Tony Lindgren <[email protected]>:
Quoted 12 lines · Kevin Hilman
Quoted 7 lines
Quoted 5 lines
- 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 indrivers/gpiotoo.
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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 10 lines · Linus Walleij
2011/4/21 Tony Lindgren <[email protected]>:
Quoted 9 lines · Kevin Hilman
Quoted 7 lines
Quoted 5 lines
- Move it to
drivers/gpio- Further consolidate with whatever common GPIO code might ? be coming up.
Is the above order required?
Quoted 7 lines
Quoted 3 lines
Yes please. Otherwise we'll have more of the "crazy churn" in
arch/arm/*omap*/and the runtime PM patches should apply easily indrivers/gpiotoo.Since you'll probably be dependent on stuff happening in my patches to move stuff into
drivers/gpioI'll be happy to carry the patches in my gpio-consolidation branch with Tony's ACKs if need be.
Sounds good to me.
Tony
v2 cover OMAP: GPIO: Use PM runtime framework
2011/4/26 Tony Lindgren <[email protected]>:
Quoted 6 lines · Linus Walleij
Quoted 3 lines
Since you'll probably be dependent on stuff happening in my patches to move stuff into
drivers/gpioI'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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 11 lines · Linus Walleij
2011/4/26 Tony Lindgren <[email protected]>:
Quoted 6 lines · Linus Walleij
Quoted 3 lines
Since you'll probably be dependent on stuff happening in my patches to move stuff into
drivers/gpioI'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
v2 cover OMAP: GPIO: Use PM runtime framework
2011/5/3 Kevin Hilman <[email protected]>:
Quoted 2 lines
Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into
drivers/gpiofirst, 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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 5 lines · Linus Walleij
2011/5/3 Kevin Hilman <[email protected]>:
Quoted 2 lines
Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into
drivers/gpiofirst, followed by the cleanup/restructure patches?
Quoted 7 lines
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
v2 cover OMAP: GPIO: Use PM runtime framework
2011/5/4 Tony Lindgren <[email protected]>:
Quoted 14 lines · Linus Walleij
Quoted 5 lines
2011/5/3 Kevin Hilman <[email protected]>:
Quoted 2 lines
Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into
drivers/gpiofirst, followed by the cleanup/restructure patches?Quoted 7 lines
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 ...
Quoted 8 lines
Personally I would prefer absolutely minimal clean-up of current code before moving to
drivers/gpioto cut down the "crazy churn" inarch/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
v2 cover OMAP: GPIO: Use PM runtime framework
Linus Walleij <[email protected]> writes:
[...]
Quoted 8 lines
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/gpiothat does *not* use gpiolib and utilize singletons to get at thegpio_chipaddresses (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
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 22 lines · Kevin Hilman
Linus Walleij <[email protected]> writes:
[...]
Quoted 8 lines
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/gpiothat does *not* use gpiolib and utilize singletons to get at thegpio_chipaddresses (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/gpioorarch/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 todrivers/gpio. :)
Quoted 4 lines
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.
v2 cover OMAP: GPIO: Use PM runtime framework
Quoted 28 lines · Grant Likely
Quoted 22 lines · Kevin Hilman
Linus Walleij <[email protected]> writes:
[...]
Quoted 8 lines
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/gpiothat does *not* use gpiolib and utilize singletons to get at thegpio_chipaddresses (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/gpioorarch/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 todrivers/gpio. :)Quoted 4 lines
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].
Quoted 4 lines
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.
Quoted 3 lines
put things into the Makefile/Kconfig in alphabetical order as much as possible.
Signature · 2 lines
Regards, Shawn
v2 cover OMAP: GPIO: Use PM runtime framework
In reply to Linus WalleijQuoted 42 lines · Linus Walleij
2011/5/4 Tony Lindgren <[email protected]>:
Quoted 14 lines · Linus Walleij
Quoted 5 lines
2011/5/3 Kevin Hilman <[email protected]>:
Quoted 2 lines
Are you OK with a move of the current OMAP GPIO drivers (rather ugly) into
drivers/gpiofirst, followed by the cleanup/restructure patches?Quoted 7 lines
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 ...
Quoted 8 lines
Personally I would prefer absolutely minimal clean-up of current code before moving to
drivers/gpioto cut down the "crazy churn" inarch/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_chipaccessor functiongpio_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.
Quoted 8 lines
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/gpiothat does *not* use gpiolib and utilize singletons to get at thegpio_chipaddresses (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.