From: Maulik Shah <mkshah@codeaurora.org>
To: Douglas Anderson <dianders@chromium.org>,
Marc Zyngier <maz@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Linus Walleij <linus.walleij@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Neeraj Upadhyay <neeraju@codeaurora.org>,
Rajendra Nayak <rnayak@codeaurora.org>,
Stephen Boyd <swboyd@chromium.org>,
linux-gpio@vger.kernel.org,
Srinivas Ramana <sramana@codeaurora.org>,
linux-arm-msm@vger.kernel.org, Andy Gross <agross@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/4] pinctrl: qcom: No need to read-modify-write the interrupt status
Date: Mon, 11 Jan 2021 21:28:01 +0530 [thread overview]
Message-ID: <aa84c8e0-3922-cc59-7c11-663bde0d2ed8@codeaurora.org> (raw)
In-Reply-To: <20210108093339.v5.2.I3635de080604e1feda770591c5563bd6e63dd39d@changeid>
Hi Doug,
Reviewed-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Maulik Shah <mkshah@codeaurora.org>
Thanks,
Maulik
On 1/8/2021 11:05 PM, Douglas Anderson wrote:
> When the Qualcomm pinctrl driver wants to Ack an interrupt, it does a
> read-modify-write on the interrupt status register. On some SoCs it
> makes sure that the status bit is 1 to "Ack" and on others it makes
> sure that the bit is 0 to "Ack". Presumably the first type of
> interrupt controller is a "write 1 to clear" type register and the
> second just let you directly set the interrupt status register.
>
> As far as I can tell from scanning structure definitions, the
> interrupt status bit is always in a register by itself. Thus with
> both types of interrupt controllers it is safe to "Ack" interrupts
> without doing a read-modify-write. We can do a simple write.
>
> It should be noted that if the interrupt status bit _was_ ever in a
> register with other things (like maybe status bits for other GPIOs):
> a) For "write 1 clear" type controllers then read-modify-write would
> be totally wrong because we'd accidentally end up clearing
> interrupts we weren't looking at.
> b) For "direct set" type controllers then read-modify-write would also
> be wrong because someone setting one of the other bits in the
> register might accidentally clear (or set) our interrupt.
> I say this simply to show that the current read-modify-write doesn't
> provide any sort of "future proofing" of the code. In fact (for
> "write 1 clear" controllers) the new code is slightly more "future
> proof" since it would allow more than one interrupt status bits to
> share a register.
>
> NOTE: this code fixes no bugs--it simply avoids an extra register
> read.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> Changes in v5:
> - ("pinctrl: qcom: No need to read-modify-write the ...") new for v5.
>
> drivers/pinctrl/qcom/pinctrl-msm.c | 23 ++++++++---------------
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 1d2a78452c2d..1787ada6bfab 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -792,16 +792,13 @@ static void msm_gpio_irq_clear_unmask(struct irq_data *d, bool status_clear)
>
> raw_spin_lock_irqsave(&pctrl->lock, flags);
>
> - if (status_clear) {
> - /*
> - * clear the interrupt status bit before unmask to avoid
> - * any erroneous interrupts that would have got latched
> - * when the interrupt is not in use.
> - */
> - val = msm_readl_intr_status(pctrl, g);
> - val &= ~BIT(g->intr_status_bit);
> - msm_writel_intr_status(val, pctrl, g);
> - }
> + /*
> + * clear the interrupt status bit before unmask to avoid
> + * any erroneous interrupts that would have got latched
> + * when the interrupt is not in use.
> + */
> + if (status_clear)
> + msm_writel_intr_status(0, pctrl, g);
>
> val = msm_readl_intr_cfg(pctrl, g);
> val |= BIT(g->intr_raw_status_bit);
> @@ -906,11 +903,7 @@ static void msm_gpio_irq_ack(struct irq_data *d)
>
> raw_spin_lock_irqsave(&pctrl->lock, flags);
>
> - val = msm_readl_intr_status(pctrl, g);
> - if (g->intr_ack_high)
> - val |= BIT(g->intr_status_bit);
> - else
> - val &= ~BIT(g->intr_status_bit);
> + val = (g->intr_ack_high) ? BIT(g->intr_status_bit) : 0;
> msm_writel_intr_status(val, pctrl, g);
>
> if (test_bit(d->hwirq, pctrl->dual_edge_irqs))
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
next prev parent reply other threads:[~2021-01-11 15:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-08 17:35 [PATCH v5 1/4] pinctrl: qcom: Allow SoCs to specify a GPIO function that's not 0 Douglas Anderson
2021-01-08 17:35 ` [PATCH v5 2/4] pinctrl: qcom: No need to read-modify-write the interrupt status Douglas Anderson
2021-01-11 15:58 ` Maulik Shah [this message]
2021-01-14 7:01 ` Stephen Boyd
2021-01-14 16:33 ` Bjorn Andersson
2021-01-08 17:35 ` [PATCH v5 3/4] pinctrl: qcom: Properly clear "intr_ack_high" interrupts when unmasking Douglas Anderson
2021-01-11 15:59 ` Maulik Shah
2021-01-14 7:03 ` Stephen Boyd
2021-01-14 16:34 ` Bjorn Andersson
2021-01-08 17:35 ` [PATCH v5 4/4] pinctrl: qcom: Don't clear pending interrupts when enabling Douglas Anderson
2021-01-09 0:36 ` Linus Walleij
2021-01-16 1:04 ` Doug Anderson
2021-01-11 16:01 ` Maulik Shah
2021-01-14 7:14 ` Stephen Boyd
2021-01-14 17:07 ` Bjorn Andersson
2021-01-14 17:15 ` Bjorn Andersson
2021-01-14 17:58 ` Doug Anderson
2021-01-14 17:58 ` Doug Anderson
2021-01-14 21:04 ` Stephen Boyd
2021-01-11 15:56 ` [PATCH v5 1/4] pinctrl: qcom: Allow SoCs to specify a GPIO function that's not 0 Maulik Shah
2021-01-14 16:32 ` Bjorn Andersson
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=aa84c8e0-3922-cc59-7c11-663bde0d2ed8@codeaurora.org \
--to=mkshah@codeaurora.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=dianders@chromium.org \
--cc=jason@lakedaemon.net \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=neeraju@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=sramana@codeaurora.org \
--cc=swboyd@chromium.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.