linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Horatiu Vultur <horatiu.vultur@microchip.com>
Cc: linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	andy.shevchenko@gmail.com, UNGLinuxDriver@microchip.com
Subject: Re: [PATCH v3] pinctrl: ocelot: Fix interrupt controller
Date: Wed, 14 Sep 2022 15:02:14 +0200	[thread overview]
Message-ID: <CACRpkdYWP4ASoO4wWSEgdCPbNLsx8fuHn_-oqnD+ff1TU84ieQ@mail.gmail.com> (raw)
In-Reply-To: <20220909145942.844102-1-horatiu.vultur@microchip.com>

On Fri, Sep 9, 2022 at 4:55 PM Horatiu Vultur
<horatiu.vultur@microchip.com> wrote:

> When an external device generated a level based interrupt then the
> interrupt controller could miss the interrupt. The reason is that the
> interrupt controller can detect only link changes.
>
> In the following example, if there is a PHY that generates an interrupt
> then the following would happen. The GPIO detected that the interrupt
> line changed, and then the 'ocelot_irq_handler' was called. Here it
> detects which GPIO line saw the change and for that will call the
> following:
> 1. irq_mask
> 2. phy interrupt routine
> 3. irq_eoi
> 4. irq_unmask
>
> And this works fine for simple cases, but if the PHY generates many
> interrupts, for example when doing PTP timestamping, then the following
> could happen. Again the function 'ocelot_irq_handler' will be called
> and then from here the following could happen:
> 1. irq_mask
> 2. phy interrupt routine
> 3. irq_eoi
> 4. irq_unmask
>
> Right before step 3(irq_eoi), the PHY will generate another interrupt.
> Now the interrupt controller will acknowledge the change in the
> interrupt line. So we miss the interrupt.
>
> A solution will be to use 'handle_level_irq' instead of
> 'handle_fasteoi_irq', because for this will change routine order of
> handling the interrupt.
> 1. irq_mask
> 2. irq_ack
> 3. phy interrupt routine
> 4. irq_unmask
>
> And now if the PHY will generate a new interrupt before irq_unmask, the
> interrupt controller will detect this because it already acknowledge the
> change in interrupt line at step 2(irq_ack).
>
> But this is not the full solution because there is another issue. In
> case there are 2 PHYs that share the interrupt line. For example phy1
> generates an interrupt, then the following can happen:
> 1.irq_mask
> 2.irq_ack
> 3.phy0 interrupt routine
> 4.phy1 interrupt routine
> 5.irq_unmask
>
> In case phy0 will generate an interrupt while clearing the interrupt
> source in phy1, then the interrupt line will be kept down by phy0. So
> the interrupt controller will not see any changes in the interrupt line.
> The solution here is to update 'irq_unmask' such that it can detect if
> the interrupt line is still active or not. And if it is active then call
> again the procedure to clear the interrupts. But we don't want to do it
> every time, only if we know that the interrupt controller has not seen
> already that the interrupt line has changed.
>
> While at this, add support also for IRQ_TYPE_LEVEL_LOW.
>
> Fixes: be36abb71d878f ("pinctrl: ocelot: add support for interrupt controller")
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>

This v3 patch applied for fixes so we get some rotation in linux-next
and get the Ocelot kernel in working order.
Should it even be tagged for stable?

Andy had some further things to think about, consider these
for possible further patching.

Yours,
Linus Walleij

  parent reply	other threads:[~2022-09-14 13:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-09 14:59 [PATCH v3] pinctrl: ocelot: Fix interrupt controller Horatiu Vultur
2022-09-09 15:09 ` Andy Shevchenko
2022-09-15 11:33   ` Horatiu Vultur
2022-09-14 13:02 ` Linus Walleij [this message]
2022-09-15 11:22   ` Horatiu Vultur
2022-09-18 18:55     ` Linus Walleij
2022-09-20 12:06 ` Michael Walle
2022-09-20 12:28   ` Linus Walleij
2022-09-20 12:34     ` Michael Walle
2022-09-20 14:25       ` Michael Walle
2022-09-20 19:30   ` Horatiu Vultur
2022-10-06 11:43     ` Michael Walle
2022-10-07  9:49       ` Horatiu Vultur
2022-10-13  7:30         ` Michael Walle
2022-10-13 14:11           ` Horatiu Vultur

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=CACRpkdYWP4ASoO4wWSEgdCPbNLsx8fuHn_-oqnD+ff1TU84ieQ@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=horatiu.vultur@microchip.com \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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).