From: Stephen Boyd <swboyd@chromium.org>
To: Lina Iyer <ilina@codeaurora.org>
Cc: agross@kernel.org, bjorn.andersson@linaro.org,
linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
rnayak@codeaurora.org, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org, dianders@chromium.org,
mkshah@codeaurora.org,
"Raju P.L.S.S.S.N" <rplsssn@codeaurora.org>
Subject: Re: [PATCH V2 1/4] drivers: qcom: rpmh-rsc: simplify TCS locking
Date: Tue, 23 Jul 2019 13:18:58 -0700 [thread overview]
Message-ID: <5d376bb3.1c69fb81.2bb4e.7771@mx.google.com> (raw)
In-Reply-To: <20190723192159.GA18620@codeaurora.org>
Quoting Lina Iyer (2019-07-23 12:21:59)
> On Tue, Jul 23 2019 at 12:22 -0600, Stephen Boyd wrote:
> >Quoting Lina Iyer (2019-07-22 14:53:37)
> >> From: "Raju P.L.S.S.S.N" <rplsssn@codeaurora.org>
> >>
> >> The tcs->lock was introduced to serialize access with in TCS group. But,
> >> drv->lock is still needed to synchronize core aspects of the
> >> communication. This puts the drv->lock in the critical and high latency
> >> path of sending a request. drv->lock provides the all necessary
> >> synchronization. So remove locking around TCS group and simply use the
> >> drv->lock instead.
> >
> >This doesn't talk about removing the irq saving and restoring though.
> You mean for drv->lock? It was not an _irqsave/_irqrestore anyways and
> we were only removing the tcs->lock.
Yes drv->lock wasn't an irqsave/restore variant because it was a
spinlock inside of an obviously already irqsaved region of code because
the tcs->lock was outside the drv->lock and that was saving the irq
flags.
>
> >Can you keep irq saving and restoring in this patch and then remove that
> >in the next patch with reasoning? It probably isn't safe if the lock is
> >taken in interrupt context anyway.
> >
> Yes, the drv->lock should have been irqsave/irqrestore, but it hasn't
> been changed by this patch.
It needs to be changed to maintain the irqsaving/restoring of the code.
> >> @@ -349,41 +349,35 @@ static int tcs_write(struct rsc_drv *drv, const struct tcs_request *msg)
> >> {
> >> struct tcs_group *tcs;
> >> int tcs_id;
> >> - unsigned long flags;
> >> int ret;
> >>
> >> tcs = get_tcs_for_msg(drv, msg);
> >> if (IS_ERR(tcs))
> >> return PTR_ERR(tcs);
> >>
> >> - spin_lock_irqsave(&tcs->lock, flags);
> >> spin_lock(&drv->lock);
> >> /*
> >> * The h/w does not like if we send a request to the same address,
> >> * when one is already in-flight or being processed.
> >> */
> >> ret = check_for_req_inflight(drv, tcs, msg);
> >> - if (ret) {
> >> - spin_unlock(&drv->lock);
> >> + if (ret)
> >> goto done_write;
> >> - }
> >>
> >> tcs_id = find_free_tcs(tcs);
> >> if (tcs_id < 0) {
> >> ret = tcs_id;
> >> - spin_unlock(&drv->lock);
> >> goto done_write;
> >> }
> >>
> >> tcs->req[tcs_id - tcs->offset] = msg;
> >> set_bit(tcs_id, drv->tcs_in_use);
> >> - spin_unlock(&drv->lock);
> >>
> >> __tcs_buffer_write(drv, tcs_id, 0, msg);
> >> __tcs_trigger(drv, tcs_id);
> >>
> >> done_write:
> >> - spin_unlock_irqrestore(&tcs->lock, flags);
> >> + spin_unlock(&drv->lock);
> >> return ret;
> >> }
> >>
> >> @@ -481,19 +475,18 @@ static int tcs_ctrl_write(struct rsc_drv *drv, const struct tcs_request *msg)
> >> {
> >> struct tcs_group *tcs;
> >> int tcs_id = 0, cmd_id = 0;
> >> - unsigned long flags;
> >> int ret;
> >>
> >> tcs = get_tcs_for_msg(drv, msg);
> >> if (IS_ERR(tcs))
> >> return PTR_ERR(tcs);
> >>
> >> - spin_lock_irqsave(&tcs->lock, flags);
> >> + spin_lock(&drv->lock);
> >> /* find the TCS id and the command in the TCS to write to */
> >> ret = find_slots(tcs, msg, &tcs_id, &cmd_id);
> >> if (!ret)
> >> __tcs_buffer_write(drv, tcs_id, cmd_id, msg);
> >> - spin_unlock_irqrestore(&tcs->lock, flags);
> >> + spin_unlock(&drv->lock);
> >>
> >
> >These ones, just leave them doing the irq save restore for now?
> >
> drv->lock ??
>
Yes, it should have irq save/restore still.
next prev parent reply other threads:[~2019-07-23 20:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-22 21:53 [PATCH V2 1/4] drivers: qcom: rpmh-rsc: simplify TCS locking Lina Iyer
2019-07-22 21:53 ` [PATCH V2 2/4] drivers: qcom: rpmh-rsc: avoid locking in the interrupt handler Lina Iyer
2019-07-23 20:11 ` Stephen Boyd
2019-07-24 14:52 ` Lina Iyer
2019-07-24 19:37 ` Stephen Boyd
2019-07-24 20:36 ` Lina Iyer
2019-07-24 23:27 ` Doug Anderson
2019-07-25 15:18 ` Lina Iyer
2019-07-25 15:39 ` Doug Anderson
2019-07-29 19:01 ` Lina Iyer
2019-07-29 20:56 ` Stephen Boyd
2019-07-30 17:29 ` Lina Iyer
2019-07-22 21:53 ` [PATCH V2 3/4] drivers: qcom: rpmh: switch over from spinlock irq variants Lina Iyer
2019-07-23 18:24 ` Stephen Boyd
2019-07-22 21:53 ` [PATCH V2 4/4] drivers: qcom: rpmh-rsc: remove redundant register access Lina Iyer
2019-07-23 18:22 ` [PATCH V2 1/4] drivers: qcom: rpmh-rsc: simplify TCS locking Stephen Boyd
2019-07-23 19:21 ` Lina Iyer
2019-07-23 20:18 ` Stephen Boyd [this message]
2019-07-24 14:54 ` Lina Iyer
2019-07-24 18:32 ` Stephen Boyd
2019-07-24 19:36 ` Lina Iyer
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=5d376bb3.1c69fb81.2bb4e.7771@mx.google.com \
--to=swboyd@chromium.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=dianders@chromium.org \
--cc=ilina@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-soc@vger.kernel.org \
--cc=mkshah@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=rplsssn@codeaurora.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 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.