linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Linus Walleij <linus.walleij@linaro.org>,
	Michal Simek <michal.simek@xilinx.com>,
	Nava kishore Manne <navam@xilinx.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"monstr@monstr.eu" <monstr@monstr.eu>,
	"Borsodi Petr" <Petr.Borsodi@i.cz>,
	"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
	"Steffen Trumtrar" <s.trumtrar@pengutronix.de>,
	"Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"Rob Herring" <robherring2@gmail.com>,
	"Josh Cartwright" <josh.cartwright@ni.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/8] gpio: zynq: Wakeup gpio controller when it is used as IRQ controller
Date: Mon, 14 Aug 2017 16:33:09 +0200	[thread overview]
Message-ID: <6da5fd79-fbc8-b613-954f-dcbe2ef8d6c5@xilinx.com> (raw)
In-Reply-To: <CACRpkdZE-Edr7fWZY5VQM1_65iw7MYGP-iDa2ExZsPxpM0rurQ@mail.gmail.com>

On 14.8.2017 15:53, Linus Walleij wrote:
> On Mon, Aug 7, 2017 at 1:01 PM, Michal Simek <michal.simek@xilinx.com> wrote:
> 
>> From: Borsodi Petr <Petr.Borsodi@i.cz>
>>
>> There is a problem with GPIO driver when used as IRQ controller.
>> It is not working because the module is sleeping (clock is disabled).
>> The patch enables clocks when IP is used as IRQ controller.
>>
>> Signed-off-by: Borsodi Petr <Petr.Borsodi@i.cz>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> 
> I'm a bit worried about this patch.
> 
>> +static int zynq_gpio_irq_request_resources(struct irq_data *d)
>> +{
>> +       struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
>> +       int ret;
>> +
>> +       if (!try_module_get(chip->gpiodev->owner))
>> +               return -ENODEV;
> 
> You are poking around in gpiolib internals, I don't really like that.
> I prefer that you use accessors and try to make the core deal with
> this instead of fixing it up with a local hack in the driver.
> 
>> +       ret = pm_runtime_get_sync(chip->parent);
>> +       if (ret < 0) {
>> +               module_put(chip->gpiodev->owner);
>> +               return ret;
>> +       }
> 
> What you essentially do is disable runtime PM while IRQs are in
> use, the patch commit log should say this.
> 
>> +       if (gpiochip_lock_as_irq(chip, d->hwirq)) {
>> +               chip_err(chip, "unable to lock HW IRQ %lu for IRQ\n", d->hwirq);
>> +               pm_runtime_put(chip->parent);
>> +               module_put(chip->gpiodev->owner);
>> +               return -EINVAL;
>> +       }
> 
> This is essentially a separate patch that should be done orthogonally.
> (I don't care super-much about that though.)
> 
>> +static void zynq_gpio_irq_release_resources(struct irq_data *d)
>> +{
>> +       struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
>> +
>> +       gpiochip_unlock_as_irq(chip, d->hwirq);
>> +       pm_runtime_put(chip->parent);
>> +       module_put(chip->gpiodev->owner);
>> +}
> (...)
>> +       .irq_request_resources = zynq_gpio_irq_request_resources,
>> +       .irq_release_resources = zynq_gpio_irq_release_resources,
> 
> Look at this from gpiolib.c:
> 
> static int gpiochip_irq_reqres(struct irq_data *d)
> {
>         struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
> 
>         if (!try_module_get(chip->gpiodev->owner))
>                 return -ENODEV;
> 
>         if (gpiochip_lock_as_irq(chip, d->hwirq)) {
>                 chip_err(chip,
>                         "unable to lock HW IRQ %lu for IRQ\n",
>                         d->hwirq);
>                 module_put(chip->gpiodev->owner);
>                 return -EINVAL;
>         }
>         return 0;
> }
> 
> static void gpiochip_irq_relres(struct irq_data *d)
> {
>         struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
> 
>         gpiochip_unlock_as_irq(chip, d->hwirq);
>         module_put(chip->gpiodev->owner);
> }
> 
> If you add pm_runtime_get_sync()/put to this and export
> the functions you have the same thing and you can just reuse this
> code instead of copying it.
> 
> Arguably the above should indeed have that runtime PM code
> (unless we know a better way to deal with IRQs).
> 
> So can we fix this in the core and reuse it from there?

I have checked 4.13-rc1 and none is doing anything with clock in these
irq routines.
It means it is a question if they have the same issue when device is
sleeping or we do something wrong.
It is not a problem to move these calls to core (patch is quite simple)
but validate that if this is correct on others SoC.
Do you know if we can validate this on different SoC?

Nava: Can you please validate this again on ZynqMP?

Thanks,
Michal

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9568708a550b..a08a044fa4aa 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1647,14 +1647,22 @@ static void gpiochip_irq_unmap(struct irq_domain
*d, unsigned int irq)
 static int gpiochip_irq_reqres(struct irq_data *d)
 {
        struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
+       int ret;

        if (!try_module_get(chip->gpiodev->owner))
                return -ENODEV;

+       ret = pm_runtime_get_sync(chip->parent);
+       if (ret < 0) {
+               module_put(chip->gpiodev->owner);
+               return ret;
+       }
+
        if (gpiochip_lock_as_irq(chip, d->hwirq)) {
                chip_err(chip,
                        "unable to lock HW IRQ %lu for IRQ\n",
                        d->hwirq);
+               pm_runtime_put(chip->parent);
                module_put(chip->gpiodev->owner);
                return -EINVAL;
        }
@@ -1666,6 +1674,7 @@ static void gpiochip_irq_relres(struct irq_data *d)
        struct gpio_chip *chip = irq_data_get_irq_chip_data(d);

        gpiochip_unlock_as_irq(chip, d->hwirq);
+       pm_runtime_put(chip->parent);
        module_put(chip->gpiodev->owner);
 }

  reply	other threads:[~2017-08-14 14:33 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07 11:01 [PATCH 0/8] Zynq GPIO driver changes Michal Simek
2017-08-07 11:01 ` [PATCH 1/8] gpio: zynq: Add support for suspend resume Michal Simek
2017-08-14 13:44   ` Linus Walleij
2017-08-07 11:01 ` [PATCH 2/8] gpio: zynq: Wakeup gpio controller when it is used as IRQ controller Michal Simek
2017-08-14 13:53   ` Linus Walleij
2017-08-14 14:33     ` Michal Simek [this message]
2017-08-22 12:57       ` Linus Walleij
2019-01-07 15:42       ` Thomas Petazzoni
2019-01-08 13:21         ` Michal Simek
2019-01-11  9:54         ` Linus Walleij
2019-01-11 12:54           ` Thomas Petazzoni
2019-01-11 14:37             ` Linus Walleij
2019-01-21  6:11               ` Shubhrajyoti Datta
2017-08-07 11:01 ` [PATCH 3/8] gpio: zynq: Shift zynq_gpio_init() to subsys_initcall level Michal Simek
2017-08-14 13:55   ` Linus Walleij
2017-08-14 14:15     ` Michal Simek
2017-08-22 13:02       ` Linus Walleij
2017-08-07 11:01 ` [PATCH 4/8] gpio: zynq: Provided workaround for GPIO Michal Simek
2017-08-14 13:57   ` Linus Walleij
2017-08-14 14:01     ` Michal Simek
2017-08-07 11:01 ` [PATCH 5/8] gpio: zynq: Fix kernel doc warnings Michal Simek
2017-08-14 13:58   ` Linus Walleij
2017-08-07 11:01 ` [PATCH 6/8] gpio: zynq: Fix empty lines in driver Michal Simek
2017-08-14 13:59   ` Linus Walleij
2017-08-07 11:02 ` [PATCH 7/8] gpio: zynq: Fix warnings in the driver Michal Simek
2017-08-14 14:00   ` Linus Walleij
2017-08-07 11:02 ` [PATCH 8/8] gpio: zynq: Fix driver function parameters alignment Michal Simek
2017-08-14 14:01   ` Linus Walleij
2017-08-14 14:03     ` Michal Simek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6da5fd79-fbc8-b613-954f-dcbe2ef8d6c5@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=Petr.Borsodi@i.cz \
    --cc=josh.cartwright@ni.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monstr@monstr.eu \
    --cc=navam@xilinx.com \
    --cc=peter.crosthwaite@xilinx.com \
    --cc=robherring2@gmail.com \
    --cc=s.trumtrar@pengutronix.de \
    --cc=soren.brinkmann@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).