From: Stephen Boyd <swboyd@chromium.org>
To: Lina Iyer <ilina@codeaurora.org>
Cc: andy.gross@linaro.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 1/2] drivers: qcom: rpmh-rsc: simplify TCS locking
Date: Mon, 22 Jul 2019 11:18:34 -0700 [thread overview]
Message-ID: <5d35fdfb.1c69fb81.5fafa.aaa9@mx.google.com> (raw)
In-Reply-To: <20190722162003.GG25567@codeaurora.org>
Quoting Lina Iyer (2019-07-22 09:20:03)
> On Fri, Jul 19 2019 at 12:20 -0600, Stephen Boyd wrote:
> >Quoting Lina Iyer (2019-07-01 08:29:06)
> >> From: "Raju P.L.S.S.S.N" <rplsssn@codeaurora.org>
> >>
> >> tcs->lock was introduced to serialize access with in TCS group. But
> >> even without tcs->lock, drv->lock is serving the same purpose. So
> >> use a single drv->lock.
> >
> >Isn't the downside now that we're going to be serializing access to the
> >different TCSes when two are being written in parallel or waited on? I
> >thought that was the whole point of splitting the lock into a TCS lock
> >and a general "driver" lock that protects the global driver state vs.
> >the specific TCS state.
> >
> Yes but we were holding the drv->lock as well as tcs->lock for the most
> critical of the path anyways (writing to TCS). The added complexity
> doesn't seem to help reduce the latency that it expected to reduce.
Ok. That sort of information should be in the commit text to explain why
it's not helping with reducing the latency or throughput of the API.
next prev parent reply other threads:[~2019-07-22 18:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-01 15:29 [PATCH 1/2] drivers: qcom: rpmh-rsc: simplify TCS locking Lina Iyer
2019-07-01 15:29 ` [PATCH 2/2] drivers: qcom: rpmh-rsc: fix read back of trigger register Lina Iyer
2019-07-01 15:53 ` Lina Iyer
2019-07-19 18:22 ` Stephen Boyd
2019-07-22 15:51 ` Lina Iyer
2019-07-01 15:52 ` [PATCH 1/2] drivers: qcom: rpmh-rsc: simplify TCS locking Lina Iyer
2019-07-19 18:20 ` Stephen Boyd
2019-07-22 16:20 ` Lina Iyer
2019-07-22 18:18 ` Stephen Boyd [this message]
2019-07-22 19:46 ` 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=5d35fdfb.1c69fb81.5fafa.aaa9@mx.google.com \
--to=swboyd@chromium.org \
--cc=andy.gross@linaro.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 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).