| Message ID | 1414151970-6626-7-git-send-email-thomas.petazzoni@free-electrons.com |
|---|---|
| State | Accepted |
| Headers | show |
On Fri, Oct 24, 2014 at 01:59:19PM +0200, Thomas Petazzoni wrote: > This commit adds the implementation of ->suspend() and ->resume() > platform_driver hooks in order to save and restore the state of the > GPIO configuration. In order to achieve that, additional fields are > added to the mvebu_gpio_chip structure. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Alexandre Courbot <gnurou@gmail.com> > Cc: linux-gpio@vger.kernel.org > --- > drivers/gpio/gpio-mvebu.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 99 insertions(+) > > diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c > index 418e386..dd5545c 100644 > --- a/drivers/gpio/gpio-mvebu.c > +++ b/drivers/gpio/gpio-mvebu.c > @@ -83,6 +83,14 @@ struct mvebu_gpio_chip { > int irqbase; > struct irq_domain *domain; > int soc_variant; > + > + /* Used to preserve GPIO registers accross suspend/resume */ > + u32 out_reg; > + u32 io_conf_reg; > + u32 blink_en_reg; > + u32 in_pol_reg; > + u32 edge_mask_regs[4]; > + u32 level_mask_regs[4]; > }; > > /* > @@ -554,6 +562,93 @@ static const struct of_device_id mvebu_gpio_of_match[] = { > }; > MODULE_DEVICE_TABLE(of, mvebu_gpio_of_match); > > +static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state) > +{ > + struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev); > + int i; > + > + mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip)); > + mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip)); > + mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip)); > + mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip)); > + > + switch (mvchip->soc_variant) { > + case MVEBU_GPIO_SOC_VARIANT_ORION: > + mvchip->edge_mask_regs[0] = > + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); > + mvchip->level_mask_regs[0] = > + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); > + break; > + case MVEBU_GPIO_SOC_VARIANT_MV78200: > + for (i = 0; i < 2; i++) { > + mvchip->edge_mask_regs[i] = > + readl(mvchip->membase + > + GPIO_EDGE_MASK_MV78200_OFF(i)); > + mvchip->level_mask_regs[i] = > + readl(mvchip->membase + > + GPIO_LEVEL_MASK_MV78200_OFF(i)); > + } > + break; > + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: > + for (i = 0; i < 4; i++) { > + mvchip->edge_mask_regs[i] = > + readl(mvchip->membase + > + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); > + mvchip->level_mask_regs[i] = > + readl(mvchip->membase + > + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); > + } > + break; > + default: > + BUG(); Isn't it too severe? Is the platform going too unstable if driver reaches this case? I'd consider a WARN() instead. > + } > + > + return 0; > +} > + > +static int mvebu_gpio_resume(struct platform_device *pdev) > +{ > + struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev); > + int i; > + > + writel(mvchip->out_reg, mvebu_gpioreg_out(mvchip)); > + writel(mvchip->io_conf_reg, mvebu_gpioreg_io_conf(mvchip)); > + writel(mvchip->blink_en_reg, mvebu_gpioreg_blink(mvchip)); > + writel(mvchip->in_pol_reg, mvebu_gpioreg_in_pol(mvchip)); > + > + switch (mvchip->soc_variant) { > + case MVEBU_GPIO_SOC_VARIANT_ORION: > + writel(mvchip->edge_mask_regs[0], > + mvchip->membase + GPIO_EDGE_MASK_OFF); > + writel(mvchip->level_mask_regs[0], > + mvchip->membase + GPIO_LEVEL_MASK_OFF); > + break; > + case MVEBU_GPIO_SOC_VARIANT_MV78200: > + for (i = 0; i < 2; i++) { > + writel(mvchip->edge_mask_regs[i], > + mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(i)); > + writel(mvchip->level_mask_regs[i], > + mvchip->membase + > + GPIO_LEVEL_MASK_MV78200_OFF(i)); > + } > + break; > + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: > + for (i = 0; i < 4; i++) { > + writel(mvchip->edge_mask_regs[i], > + mvchip->membase + > + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); > + writel(mvchip->level_mask_regs[i], > + mvchip->membase + > + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); > + } > + break; > + default: > + BUG(); Ditto. Br, David Cohen > + } > + > + return 0; > +} > + > static int mvebu_gpio_probe(struct platform_device *pdev) > { > struct mvebu_gpio_chip *mvchip; > @@ -577,6 +672,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev) > if (!mvchip) > return -ENOMEM; > > + platform_set_drvdata(pdev, mvchip); > + > if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios)) { > dev_err(&pdev->dev, "Missing ngpios OF property\n"); > return -ENODEV; > @@ -735,5 +832,7 @@ static struct platform_driver mvebu_gpio_driver = { > .of_match_table = mvebu_gpio_of_match, > }, > .probe = mvebu_gpio_probe, > + .suspend = mvebu_gpio_suspend, > + .resume = mvebu_gpio_resume, > }; > module_platform_driver(mvebu_gpio_driver); > -- > 2.0.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > + switch (mvchip->soc_variant) { > > + case MVEBU_GPIO_SOC_VARIANT_ORION: > > + mvchip->edge_mask_regs[0] = > > + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); > > + mvchip->level_mask_regs[0] = > > + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); > > + break; > > + case MVEBU_GPIO_SOC_VARIANT_MV78200: > > + for (i = 0; i < 2; i++) { > > + mvchip->edge_mask_regs[i] = > > + readl(mvchip->membase + > > + GPIO_EDGE_MASK_MV78200_OFF(i)); > > + mvchip->level_mask_regs[i] = > > + readl(mvchip->membase + > > + GPIO_LEVEL_MASK_MV78200_OFF(i)); > > + } > > + break; > > + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: > > + for (i = 0; i < 4; i++) { > > + mvchip->edge_mask_regs[i] = > > + readl(mvchip->membase + > > + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); > > + mvchip->level_mask_regs[i] = > > + readl(mvchip->membase + > > + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); > > + } > > + break; > > + default: > > + BUG(); > > Isn't it too severe? Is the platform going too unstable if driver > reaches this case? > I'd consider a WARN() instead. This is a common pattern in this driver. So i guess Thomas just cut/pasted the switch statement from _probe(), which also has the BUG(). Given that _probe() should of thrown a BUG() in this situation, if it happens here, it means mvchip->soc_variant has been corrupted, and so bad things are happening. So a BUG() is maybe called for? Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 25, 2014 at 5:45 AM, Andrew Lunn <andrew@lunn.ch> wrote: >> > + switch (mvchip->soc_variant) { >> > + case MVEBU_GPIO_SOC_VARIANT_ORION: >> > + mvchip->edge_mask_regs[0] = >> > + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); >> > + mvchip->level_mask_regs[0] = >> > + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); >> > + break; >> > + case MVEBU_GPIO_SOC_VARIANT_MV78200: >> > + for (i = 0; i < 2; i++) { >> > + mvchip->edge_mask_regs[i] = >> > + readl(mvchip->membase + >> > + GPIO_EDGE_MASK_MV78200_OFF(i)); >> > + mvchip->level_mask_regs[i] = >> > + readl(mvchip->membase + >> > + GPIO_LEVEL_MASK_MV78200_OFF(i)); >> > + } >> > + break; >> > + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: >> > + for (i = 0; i < 4; i++) { >> > + mvchip->edge_mask_regs[i] = >> > + readl(mvchip->membase + >> > + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); >> > + mvchip->level_mask_regs[i] = >> > + readl(mvchip->membase + >> > + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); >> > + } >> > + break; >> > + default: >> > + BUG(); >> >> Isn't it too severe? Is the platform going too unstable if driver >> reaches this case? >> I'd consider a WARN() instead. > > This is a common pattern in this driver. So i guess Thomas just > cut/pasted the switch statement from _probe(), which also has the > BUG(). > > Given that _probe() should of thrown a BUG() in this situation, if it > happens here, it means mvchip->soc_variant has been corrupted, and so > bad things are happening. So a BUG() is maybe called for? I agree that BUG() is adequate here. probe() should recognize the exact same set of chips - if we reach this point this means that either the data has been corrupted or we added support for a new chip in probe() and forgot suspend/resume. In both cases the driver should express its discontent. Acked-by: Alexandre Courbot <acourbot@nvidia.com> -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 27, 2014 at 02:27:16PM +0900, Alexandre Courbot wrote: > On Sat, Oct 25, 2014 at 5:45 AM, Andrew Lunn <andrew@lunn.ch> wrote: > >> > + switch (mvchip->soc_variant) { > >> > + case MVEBU_GPIO_SOC_VARIANT_ORION: > >> > + mvchip->edge_mask_regs[0] = > >> > + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); > >> > + mvchip->level_mask_regs[0] = > >> > + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); > >> > + break; > >> > + case MVEBU_GPIO_SOC_VARIANT_MV78200: > >> > + for (i = 0; i < 2; i++) { > >> > + mvchip->edge_mask_regs[i] = > >> > + readl(mvchip->membase + > >> > + GPIO_EDGE_MASK_MV78200_OFF(i)); > >> > + mvchip->level_mask_regs[i] = > >> > + readl(mvchip->membase + > >> > + GPIO_LEVEL_MASK_MV78200_OFF(i)); > >> > + } > >> > + break; > >> > + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: > >> > + for (i = 0; i < 4; i++) { > >> > + mvchip->edge_mask_regs[i] = > >> > + readl(mvchip->membase + > >> > + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); > >> > + mvchip->level_mask_regs[i] = > >> > + readl(mvchip->membase + > >> > + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); > >> > + } > >> > + break; > >> > + default: > >> > + BUG(); > >> > >> Isn't it too severe? Is the platform going too unstable if driver > >> reaches this case? > >> I'd consider a WARN() instead. > > > > This is a common pattern in this driver. So i guess Thomas just > > cut/pasted the switch statement from _probe(), which also has the > > BUG(). > > > > Given that _probe() should of thrown a BUG() in this situation, if it > > happens here, it means mvchip->soc_variant has been corrupted, and so > > bad things are happening. So a BUG() is maybe called for? > > I agree that BUG() is adequate here. probe() should recognize the > exact same set of chips - if we reach this point this means that > either the data has been corrupted or we added support for a new chip > in probe() and forgot suspend/resume. In both cases the driver should > express its discontent. Just for the records, since I don't know this platform very well :) IMHO unless this issue is the source of a serious instability or data corruption, a WARN() would be a better way for the driver express its discontent. It's way better to have a functional platform for further debugging. This driver can also be compiled as a module. I wonder if it's a good behavior boot the platform and then crash the kernel when loading the module driver. But anyway, that would be just me. Br, David Cohen > > Acked-by: Alexandre Courbot <acourbot@nvidia.com> -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 24, 2014 at 1:59 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > This commit adds the implementation of ->suspend() and ->resume() > platform_driver hooks in order to save and restore the state of the > GPIO configuration. In order to achieve that, additional fields are > added to the mvebu_gpio_chip structure. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Alexandre Courbot <gnurou@gmail.com> > Cc: linux-gpio@vger.kernel.org (...) > + mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip)); > + mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip)); > + mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip)); > + mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip)); OK... > + switch (mvchip->soc_variant) { > + case MVEBU_GPIO_SOC_VARIANT_ORION: > + mvchip->edge_mask_regs[0] = > + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); > + mvchip->level_mask_regs[0] = > + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); > + break; You are assigning index [0] twice, why? There must be some reason, and it should be stated in a comment. If the first read is necessary for hardware reasons, don't assign it but discard the result. (void) readl(...); (This pattern repeats for each save call below.) > + switch (mvchip->soc_variant) { > + case MVEBU_GPIO_SOC_VARIANT_ORION: > + writel(mvchip->edge_mask_regs[0], > + mvchip->membase + GPIO_EDGE_MASK_OFF); > + writel(mvchip->level_mask_regs[0], > + mvchip->membase + GPIO_LEVEL_MASK_OFF); And on the way up same thing. Now you write each register twice. Why? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus, > >> + switch (mvchip->soc_variant) { >> + case MVEBU_GPIO_SOC_VARIANT_ORION: >> + mvchip->edge_mask_regs[0] = >> + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); >> + mvchip->level_mask_regs[0] = >> + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); >> + break; > > You are assigning index [0] twice, why? There must be some > reason, and it should be stated in a comment. If the first read > is necessary for hardware reasons, don't assign it but > discard the result. Maybe I missed something but for me these 2 registers are different: one is the _EDGE_ mask and the other the _LEVEL_ mask. Gregory
Hello, On Fri, 31 Oct 2014 08:52:15 +0100, Gregory CLEMENT wrote: > >> + switch (mvchip->soc_variant) { > >> + case MVEBU_GPIO_SOC_VARIANT_ORION: > >> + mvchip->edge_mask_regs[0] = > >> + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); > >> + mvchip->level_mask_regs[0] = > >> + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); > >> + break; > > > > You are assigning index [0] twice, why? There must be some > > reason, and it should be stated in a comment. If the first read > > is necessary for hardware reasons, don't assign it but > > discard the result. > > Maybe I missed something but for me these 2 registers are different: > one is the _EDGE_ mask and the other the _LEVEL_ mask. Good that you looked at it Greg because I must admit I did not understand the comment from Linus :-) I read things again and both the variable *and* the register offset are different. I guess it's probably due to a -ENOTENOUGHCOFFEE :-) Thanks! Thomas
On Fri, Oct 31, 2014 at 8:52 AM, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote: > Hi Linus, >>> + switch (mvchip->soc_variant) { >>> + case MVEBU_GPIO_SOC_VARIANT_ORION: >>> + mvchip->edge_mask_regs[0] = >>> + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); >>> + mvchip->level_mask_regs[0] = >>> + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); >>> + break; >> >> You are assigning index [0] twice, why? There must be some >> reason, and it should be stated in a comment. If the first read >> is necessary for hardware reasons, don't assign it but >> discard the result. > > Maybe I missed something but for me these 2 registers are different: > one is the _EDGE_ mask and the other the _LEVEL_ mask. Yeah haha I must have had a bad perception day :D Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 24, 2014 at 1:59 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > This commit adds the implementation of ->suspend() and ->resume() > platform_driver hooks in order to save and restore the state of the > GPIO configuration. In order to achieve that, additional fields are > added to the mvebu_gpio_chip structure. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Alexandre Courbot <gnurou@gmail.com> > Cc: linux-gpio@vger.kernel.org Patch applied with Alexandre's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 24/10/2014 13:59, Thomas Petazzoni wrote: > This commit adds the implementation of ->suspend() and ->resume() > platform_driver hooks in order to save and restore the state of the > GPIO configuration. In order to achieve that, additional fields are > added to the mvebu_gpio_chip structure. > > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> > Cc: Linus Walleij <linus.walleij@linaro.org> > Cc: Alexandre Courbot <gnurou@gmail.com> > Cc: linux-gpio@vger.kernel.org > --- > drivers/gpio/gpio-mvebu.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 99 insertions(+) > > diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c > index 418e386..dd5545c 100644 > --- a/drivers/gpio/gpio-mvebu.c > +++ b/drivers/gpio/gpio-mvebu.c > @@ -83,6 +83,14 @@ struct mvebu_gpio_chip { > int irqbase; > struct irq_domain *domain; > int soc_variant; > + > + /* Used to preserve GPIO registers accross suspend/resume */ across > + u32 out_reg; > + u32 io_conf_reg; > + u32 blink_en_reg; > + u32 in_pol_reg; > + u32 edge_mask_regs[4]; > + u32 level_mask_regs[4]; > }; > > /* > @@ -554,6 +562,93 @@ static const struct of_device_id mvebu_gpio_of_match[] = { > }; > MODULE_DEVICE_TABLE(of, mvebu_gpio_of_match); > > +static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state) > +{ > + struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev); > + int i; > + > + mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip)); > + mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip)); > + mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip)); > + mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip)); > + > + switch (mvchip->soc_variant) { > + case MVEBU_GPIO_SOC_VARIANT_ORION: > + mvchip->edge_mask_regs[0] = > + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); > + mvchip->level_mask_regs[0] = > + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); > + break; > + case MVEBU_GPIO_SOC_VARIANT_MV78200: > + for (i = 0; i < 2; i++) { > + mvchip->edge_mask_regs[i] = > + readl(mvchip->membase + > + GPIO_EDGE_MASK_MV78200_OFF(i)); > + mvchip->level_mask_regs[i] = > + readl(mvchip->membase + > + GPIO_LEVEL_MASK_MV78200_OFF(i)); > + } > + break; I don't know if the suspend is supported on this platform but as we were on the road to remove this platform I don't know it it worth testing it unless some interested users show up. I didn't tested it on a mv782xx platform but the patch looks correct: Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Thanks, Gregory
Dear Gregory CLEMENT, On Mon, 03 Nov 2014 18:53:29 +0100, Gregory CLEMENT wrote: > I don't know if the suspend is supported on this platform but as we were > on the road to remove this platform I don't know it it worth testing it unless > some interested users show up. The same can be said of the entire mv78xx0 support in gpio-mvebu: it's completely unused today. Since the migration to mv78xx0 has not been started, this platform is still using the old style GPIO driver in plat-orion/gpio.c. And therefore, all the mv78xx0 specific code in gpio-mvebu.c is purely "tentative" and has never been actually tested on HW. Best regards, Thomas
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c index 418e386..dd5545c 100644 --- a/drivers/gpio/gpio-mvebu.c +++ b/drivers/gpio/gpio-mvebu.c @@ -83,6 +83,14 @@ struct mvebu_gpio_chip { int irqbase; struct irq_domain *domain; int soc_variant; + + /* Used to preserve GPIO registers accross suspend/resume */ + u32 out_reg; + u32 io_conf_reg; + u32 blink_en_reg; + u32 in_pol_reg; + u32 edge_mask_regs[4]; + u32 level_mask_regs[4]; }; /* @@ -554,6 +562,93 @@ static const struct of_device_id mvebu_gpio_of_match[] = { }; MODULE_DEVICE_TABLE(of, mvebu_gpio_of_match); +static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state) +{ + struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev); + int i; + + mvchip->out_reg = readl(mvebu_gpioreg_out(mvchip)); + mvchip->io_conf_reg = readl(mvebu_gpioreg_io_conf(mvchip)); + mvchip->blink_en_reg = readl(mvebu_gpioreg_blink(mvchip)); + mvchip->in_pol_reg = readl(mvebu_gpioreg_in_pol(mvchip)); + + switch (mvchip->soc_variant) { + case MVEBU_GPIO_SOC_VARIANT_ORION: + mvchip->edge_mask_regs[0] = + readl(mvchip->membase + GPIO_EDGE_MASK_OFF); + mvchip->level_mask_regs[0] = + readl(mvchip->membase + GPIO_LEVEL_MASK_OFF); + break; + case MVEBU_GPIO_SOC_VARIANT_MV78200: + for (i = 0; i < 2; i++) { + mvchip->edge_mask_regs[i] = + readl(mvchip->membase + + GPIO_EDGE_MASK_MV78200_OFF(i)); + mvchip->level_mask_regs[i] = + readl(mvchip->membase + + GPIO_LEVEL_MASK_MV78200_OFF(i)); + } + break; + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: + for (i = 0; i < 4; i++) { + mvchip->edge_mask_regs[i] = + readl(mvchip->membase + + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); + mvchip->level_mask_regs[i] = + readl(mvchip->membase + + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); + } + break; + default: + BUG(); + } + + return 0; +} + +static int mvebu_gpio_resume(struct platform_device *pdev) +{ + struct mvebu_gpio_chip *mvchip = platform_get_drvdata(pdev); + int i; + + writel(mvchip->out_reg, mvebu_gpioreg_out(mvchip)); + writel(mvchip->io_conf_reg, mvebu_gpioreg_io_conf(mvchip)); + writel(mvchip->blink_en_reg, mvebu_gpioreg_blink(mvchip)); + writel(mvchip->in_pol_reg, mvebu_gpioreg_in_pol(mvchip)); + + switch (mvchip->soc_variant) { + case MVEBU_GPIO_SOC_VARIANT_ORION: + writel(mvchip->edge_mask_regs[0], + mvchip->membase + GPIO_EDGE_MASK_OFF); + writel(mvchip->level_mask_regs[0], + mvchip->membase + GPIO_LEVEL_MASK_OFF); + break; + case MVEBU_GPIO_SOC_VARIANT_MV78200: + for (i = 0; i < 2; i++) { + writel(mvchip->edge_mask_regs[i], + mvchip->membase + GPIO_EDGE_MASK_MV78200_OFF(i)); + writel(mvchip->level_mask_regs[i], + mvchip->membase + + GPIO_LEVEL_MASK_MV78200_OFF(i)); + } + break; + case MVEBU_GPIO_SOC_VARIANT_ARMADAXP: + for (i = 0; i < 4; i++) { + writel(mvchip->edge_mask_regs[i], + mvchip->membase + + GPIO_EDGE_MASK_ARMADAXP_OFF(i)); + writel(mvchip->level_mask_regs[i], + mvchip->membase + + GPIO_LEVEL_MASK_ARMADAXP_OFF(i)); + } + break; + default: + BUG(); + } + + return 0; +} + static int mvebu_gpio_probe(struct platform_device *pdev) { struct mvebu_gpio_chip *mvchip; @@ -577,6 +672,8 @@ static int mvebu_gpio_probe(struct platform_device *pdev) if (!mvchip) return -ENOMEM; + platform_set_drvdata(pdev, mvchip); + if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios)) { dev_err(&pdev->dev, "Missing ngpios OF property\n"); return -ENODEV; @@ -735,5 +832,7 @@ static struct platform_driver mvebu_gpio_driver = { .of_match_table = mvebu_gpio_of_match, }, .probe = mvebu_gpio_probe, + .suspend = mvebu_gpio_suspend, + .resume = mvebu_gpio_resume, }; module_platform_driver(mvebu_gpio_driver);
This commit adds the implementation of ->suspend() and ->resume() platform_driver hooks in order to save and restore the state of the GPIO configuration. In order to achieve that, additional fields are added to the mvebu_gpio_chip structure. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: linux-gpio@vger.kernel.org --- drivers/gpio/gpio-mvebu.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+)