On Mon, Feb 2, 2015 at 1:07 PM, Suman Anna [off-list ref] wrote:

On 02/01/2015 11:55 AM, Bjorn Andersson wrote:

quoted

On Fri, Jan 30, 2015 at 9:41 PM, Ohad Ben-Cohen [off-list ref] wrote:

quoted

On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson [off-list ref] wrote:

quoted

In a system where you have two hwlock blocks lckA and lckB, each
consisting of 8 locks and you have dspB that can only access lckB

This is a good example - thanks. To be able to cope with such cases we
will have to pass a hwlock block reference and its relative lock id.

Correct, so the #hwlock-cells and hwlock part from the proposal are
the important one. Having an optional hwlock-names will make things
easier to read as well, but is not necessary.

Right, if anything, it would be useful only for the clients, but the
hwspinlock core itself would not need it. So, I would forgo adding the
hwlock-names for now.

quoted

quoted

The DT binding should definitely be prepared for such cases (just kill
the base-id field?), but let's see what it means about the Linux
implementation.

From the dt binding PoV, we should be able to skip num-locks as well.
It seems most hwlock blocks have a fixed amount of locks provided and
the drivers are reporting this to the core when registering.

I added this originally based on the initial MSM HW Mutex block bindings.

It's not entirely correct to have this in DT for the MSM HW, as the
hardware has a fixed number of mutexes. As soon as we have the binding
sorted out I will follow up with a new revision of the tcsr/sfpb-mutex
driver.

quoted

So I think we can reduce the binding to:

Providers:
#hwlock-cells

Consumers:
hwlocks
hwlock-names

For the hardware where number of locks is actually variable (e.g.
different variants of same block) there can be driver specific entries
for this.

Right, we should be able to drop this and use the driver match data. As
it is, the field is used during registration of the block with the
hwspinlock core.

If we have certain systems where it actually is a property to be
configured then they can have individual properties, extending the
standard set. Either way, it's not a dynamic property shared by all
hwlock drivers, so it should not be in the common binding.

Will you send out a new revision of the binding? I would love to get
this integrated so I can move on with the dependents.

Regards,
Bjorn