From: Lina Iyer <lina.iyer@linaro.org>
To: Bjorn Andersson <bjorn@kryo.se>
Cc: Ohad Ben-Cohen <ohad@wizery.com>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jeffrey Hugo <jhugo@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@sonymobile.com>,
Andy Gross <agross@codeaurora.org>
Subject: Re: [PATCH RFC v2 2/2] hwspinlock: qcom: Lock #7 is special lock, uses dynamic proc_id
Date: Wed, 10 Jun 2015 14:13:19 -0600 [thread overview]
Message-ID: <20150610201319.GA7715@linaro.org> (raw)
In-Reply-To: <CAJAp7Oi23Ho_og9+GSv3qDnWZ0fkf2JydHssPH06jBuE4i3EzA@mail.gmail.com>
On Wed, Jun 10 2015 at 11:33 -0600, Bjorn Andersson wrote:
>On Tue, Jun 9, 2015 at 9:23 AM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Hwspinlocks are widely used between processors in an SoC, and also
>> between elevation levels within in the same processor. QCOM SoC's use
>> hwspinlock to serialize entry into a low power mode when the context
>> switches from Linux to secure monitor.
>>
>> Lock #7 has been assigned for this purpose. In order to differentiate
>> between one cpu core holding a lock while another cpu is contending for
>> the same lock, the proc id written into the lock is (128 + cpu id). This
>> makes it unique value among the cpu cores and therefore when a core
>> locks the hwspinlock, other cores would wait for the lock to be released
>> since they would have a different proc id. This value is specific for
>> the lock #7 only.
>>
>> Declare lock #7 as raw capable, so the hwspinlock framework would not
>> enfore acquiring a s/w spinlock before acquiring the hwspinlock.
>>
>
>Hi Lina,
>
>Very sorry for slacking off and missing v1 of this.
>
No worries. Thanks for reviewing.
>I'm puzzled to the concept of using the hwspinlock framework for
>lock-only locks. The patch your proposed is rather clean and as long
>as there's no lock-debugging added to the framework it would work...
>
>
>Blindly declaring lock #7 as special on all Qualcomm hwspinlocks I do
>however not like at all. There's nothing in either the SFPB nor TCSR
>mutex hardware that dictates this fact, it's a system configuration
>fact. As such this "requirement" should be described in the device
>tree.
>
Its not a mutable entity, but sure.
>The puzzling part of the value to be written is strongly cpuidle
>implementation defined makes me wonder if it belong in this driver at
>all.
>
>At least this should be configured/flagged by some devicetree
>property. "qcom,lock-by-cpu-id-locks = <7, ...>"?
>
Okay.
>
>The other alternative to these patches would be to just consume the
>syscon in cpuidle and opencode the locking there. It isolates the
>cpuidle specifics of this to the original place and it isn't using
>only one side of the hwspinlock framework...
>
Well, ultimately a hwspinlock is just a writel, so that is a
possibility, if we want. But it is a hwspinlock, therefore the use of
the framework seems appropriate, even amidst the unique behavior of the
lock.
Thanks,
Lina
next prev parent reply other threads:[~2015-06-10 20:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-09 16:23 [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device Lina Iyer
2015-06-09 16:23 ` [PATCH RFC v2 1/2] hwspinlock: Introduce raw capability for hwspinlocks Lina Iyer
2015-06-09 16:59 ` Jeffrey Hugo
2015-06-09 16:23 ` [PATCH RFC v2 2/2] hwspinlock: qcom: Lock #7 is special lock, uses dynamic proc_id Lina Iyer
2015-06-10 17:33 ` Bjorn Andersson
2015-06-10 20:13 ` Lina Iyer [this message]
2015-06-27 3:05 ` [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for hwspinlock_device Lina Iyer
2015-06-27 11:25 ` Ohad Ben-Cohen
2015-07-02 20:30 ` Lina Iyer
2015-07-18 11:31 ` Ohad Ben-Cohen
2015-07-28 21:51 ` Lina Iyer
2015-08-13 6:34 ` Ohad Ben-Cohen
2015-08-13 15:25 ` Andy Gross
2015-08-14 10:52 ` Ohad Ben-Cohen
2015-08-14 13:52 ` Lina Iyer
2015-08-14 15:24 ` Lina Iyer
2015-09-20 13:02 ` Ohad Ben-Cohen
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=20150610201319.GA7715@linaro.org \
--to=lina.iyer@linaro.org \
--cc=agross@codeaurora.org \
--cc=bjorn.andersson@sonymobile.com \
--cc=bjorn@kryo.se \
--cc=jhugo@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ohad@wizery.com \
/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).