Date:	Fri, 14 Aug 2015 09:24:28 -0600
From:	Lina Iyer <lina.iyer@...aro.org>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	Bjorn Andersson <bjorn.andersson@...ymobile.com>,
	Jeffrey Hugo <jhugo@...eaurora.org>,
	"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC v2 0/2] hwspinlock: Introduce raw capability for
 hwspinlock_device

On Thu, Aug 13 2015 at 00:34 -0600, Ohad Ben-Cohen wrote:
>On Wed, Jul 29, 2015 at 12:51 AM, Lina Iyer <lina.iyer@...aro.org> wrote:
>>> Let's not make this more complicated than needed, so please add the
>>> hwcaps member to hwspinlock_device instead of to hwspinlock struct. We
>>> could always change this later if it proves to be insufficient.
>>>
>> But this could yield wrong locking scenarios. If banks are allowed RAW
>> capability and is not enforced on a per-lock basis, a driver may lock
>> using non-raw lock using the _raw API, while another driver may
>> 'acquire' the lock (since the value written to the lock would be the
>> same as raw api would). That is why you should have the capability on
>> hwspinlock and not on hwspinlock_device. Locks that are defined are RAW
>> capable should be used as RAW only.
>>
>> QCOM platform hwlock #7 is unique that different CPUs trying to acquire
>> the lock would write different values and hence would be fine. But, the
>> same is not true for other locks in the bank.
>
>As far as I understand, there is nothing special about QCOM's hwlock
>#7 in terms of hardware. It's exactly the same lock as all the others.
>
>The only difference in hwlock #7 is the way you use it, and that
>sounds like a decision the driver should be able to make. It's a
>policy, and I'm not sure we should put it in the DT. I'm also not sure
>we need this hwlock-specific complexity in the hwspinlock framework.
>
The way I see it, we made a design assumption that all hwspinlocks would
need a s/w spinlock around it. The lock #7 here challenges that
assumption. The framework imposes a s/w lock and it is only appropriate
that the framework provide an option to overcome that.

The hwspinlock bank is just a way to initalize a set of locks in a SoC.
Nobody needs the bank after that. Drivers access locks individually. It
only seems appropriate that the raw be a property of the lock access.

>The driver already makes a decision whether to disable the interrupts
>or not and whether to save their state or not. So it can also make a
>decision whether to take a sw spinlock at all or not --- if the
>hardware allows it. and that if should be encoded in an accessible
>vendor specific (not hwlock specific) struct, which is setup by the
>underlying vendor specific hwspinlock driver (no DT involved).
>
Would you rather query the hwspinlock driver to see if the framework
should take a s/w spinlock or not, IOW, raw-accessible or not?
That could work.
Every time we call into the raw access API, the framework could query
the hwspinlock driver and then bail out if the hwlock is not raw
accessible.

>Let's go over your aforementioned concerns:
>> But this could yield wrong locking scenarios. If banks are allowed RAW
>> capability and is not enforced on a per-lock basis, a driver may lock
>> using non-raw lock using the _raw API
>
>If this is allowed by the hardware, then this is a valid scenario.
>There's no such thing a non-raw lock: a lock is raw if a raw
>functionality is required.
>
Agreed. I believe, we are saying the same thing.
A raw access is a request from the calling driver. It is a request from
the driver to directly talk to its hwspinlock driver, without any
encumberance from the framework.

>> while another driver may
>> 'acquire' the lock (since the value written to the lock would be the
>> same as raw api would).
>
>Not sure I understand this one. If a lock has already been assigned to
>a driver, it cannot be re-assigned to another driver.
>
Nevermind, not a good example.

Thanks,
Lina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists