Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <1657087331-32455-1-git-send-email-quic_clew@quicinc.com> <1657087331-32455-2-git-send-email-quic_clew@quicinc.com>
In-Reply-To: <1657087331-32455-2-git-send-email-quic_clew@quicinc.com>
From:   Doug Anderson <dianders@chromium.org>
Date:   Wed, 13 Jul 2022 08:32:12 -0700
Message-ID: <CAD=FV=WfhGksEOqTeuoRawuALAt6tOtNvrajGF4iAuL1xALapQ@mail.gmail.com>
Subject: Re: [PATCH 1/4] soc: qcom: smp2p: Introduce pending state for virtual irq
To:     Chris Lew <quic_clew@quicinc.com>
Cc:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Konrad Dybcio <konrad.dybcio@somainline.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

I'm jumping in half-blind here since I've never looked at this driver
before, so if I say something that sounds wrong then it probably is.
;-P At the very least I'm super thankful for the "summary" kernel doc
at the start of this file (thanks Bjorn!)...

On Tue, Jul 5, 2022 at 11:03 PM Chris Lew <quic_clew@quicinc.com> wrote:
>
> If a smp2p change occurs while a virtual interrupt is disabled, smp2p
> should be able to resend that interrupt on enablement.

That sounds right. I made some attempt to document how I thought this
worked in commit cf9d052aa600 ("pinctrl: qcom: Don't clear pending
interrupts when enabling").


> This functionality requires the CONFIG_HARDIRQS_SW_RESEND to be enabled
> to reschedule the interrupts.

Maybe mention that you don't need to select this yourself because it's
already selected by the arm64 config?


> To ensure the mask and unmask functions
> are called during enabled and disable, set the flag to disable lazy
> IRQ state handling (IRQ_DISABLE_UNLAZY).

From your description of the problem it actually feels like you want
the opposite? When an interrupt is masked lazily then the interrupt
can still fire but won't make it to the client. Then as soon as the
client unmasks the interrupt will fire right away. That's exactly what
you want, isn't it?

Are you certain you need IRQ_DISABLE_UNLAZY?


> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> ---
>  drivers/soc/qcom/smp2p.c | 18 +++++++++++++-----
>  1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c
> index 59dbf4b61e6c..1c3259fe98be 100644
> --- a/drivers/soc/qcom/smp2p.c
> +++ b/drivers/soc/qcom/smp2p.c
> @@ -101,6 +101,7 @@ struct smp2p_entry {
>
>         struct irq_domain *domain;
>         DECLARE_BITMAP(irq_enabled, 32);
> +       DECLARE_BITMAP(irq_pending, 32);

You'll get a kernel-doc warning since the rest of the elements in this
structure are documented but your new one isn't...

...in this structure and others you're modifying in this patch...


>         DECLARE_BITMAP(irq_rising, 32);
>         DECLARE_BITMAP(irq_falling, 32);
>
> @@ -146,6 +147,7 @@ struct qcom_smp2p {
>         unsigned local_pid;
>         unsigned remote_pid;
>
> +       int irq;
>         struct regmap *ipc_regmap;
>         int ipc_offset;
>         int ipc_bit;
> @@ -217,8 +219,8 @@ static void qcom_smp2p_notify_in(struct qcom_smp2p *smp2p)
>  {
>         struct smp2p_smem_item *in;
>         struct smp2p_entry *entry;
> +       unsigned long status;
>         int irq_pin;
> -       u32 status;
>         char buf[SMP2P_MAX_ENTRY_NAME];
>         u32 val;
>         int i;
> @@ -247,19 +249,22 @@ static void qcom_smp2p_notify_in(struct qcom_smp2p *smp2p)
>
>                 status = val ^ entry->last_value;
>                 entry->last_value = val;
> +               status |= *entry->irq_pending;
>
>                 /* No changes of this entry? */
>                 if (!status)
>                         continue;
>
> -               for_each_set_bit(i, entry->irq_enabled, 32) {
> -                       if (!(status & BIT(i)))
> -                               continue;
> -
> +               for_each_set_bit(i, &status, 32) {
>                         if ((val & BIT(i) && test_bit(i, entry->irq_rising)) ||
>                             (!(val & BIT(i)) && test_bit(i, entry->irq_falling))) {
>                                 irq_pin = irq_find_mapping(entry->domain, i);
>                                 handle_nested_irq(irq_pin);
> +
> +                               if (test_bit(i, entry->irq_enabled))
> +                                       clear_bit(i, entry->irq_pending);
> +                               else
> +                                       set_bit(i, entry->irq_pending);

Your new logic seems a bit off to me.

For one thing, once an IRQ becomes pending it should stay pending.
With your code I believe that if an IRQ was marked as "rising" and
then it went high and low again while masked that you would lose track
of the interrupt. Normally an edge-triggered interrupt will latch the
edge and keep track of it.

I think the logic should be something like this (untested):

status = val ^ entry->last_value;
entry->last_value = val;

/* IRQs become pending regardless of whether they're masked or not */
for_each_set_bit(i, &status, 32) {
        if ((val & BIT(i) && test_bit(i, entry->irq_rising)) ||
            (!(val & BIT(i)) && test_bit(i, entry->irq_falling)))
                set_bit(i, entry->irq_pending);
}

/* Handled unmasked (AKA enabled) pending IRQs */
for_each_set_bit(i, entry->irq_pending), 32) {
        if (!test_bit(i, entry->irq_enabled))
                continue;
        clear_bit(i, entry->irq_pending);

        irq_pin = irq_find_mapping(entry->domain, i);
        handle_nested_irq(irq_pin);
}