summaryrefslogtreecommitdiff
path: root/drivers/gpio/Kconfig
diff options
context:
space:
mode:
authorJon Hunter <jon-hunter@ti.com>2013-04-15 13:06:54 -0500
committerLinus Walleij <linus.walleij@linaro.org>2013-05-13 21:20:44 +0200
commit352a2d5bfc336d980af69cb0ed24f86d9026f377 (patch)
tree65b8c78f26230fd3b526709cb4490f1cf233f759 /drivers/gpio/Kconfig
parentf722406faae2d073cc1d01063d1123c35425939e (diff)
gpio/omap: ensure gpio context is initialised
Commit a2797be (gpio/omap: force restore if context loss is not detectable) broke gpio support for OMAP when booting with device-tree because a restore of the gpio context being performed without ever initialising the gpio context. In other words, the context restored was bad. This problem could also occur in the non device-tree case, however, it is much less likely because when booting without device-tree we can detect context loss via a platform specific API and so context restore is performed less often. Nevertheless we should ensure that the gpio context is initialised on the first pm-runtime resume for gpio banks that could lose their state regardless of whether we are booting with device-tree or not. The context loss count was being initialised on the first pm-runtime suspend following a resume, by populating the get_count_loss_count() function pointer after the first pm-runtime resume. To make the code more readable and logical, initialise the context loss count on the first pm-runtime resume if the context is not yet valid. Reported-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Acked-by: Santosh Shilimkar<santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Diffstat (limited to 'drivers/gpio/Kconfig')
0 files changed, 0 insertions, 0 deletions