hwspinlock/msm: Add support for Qualcomm MSM HW Mutex block

Add driver for Qualcomm MSM Hardware Mutex block that exists on newer MSM SoC (MSM8974, etc).

CC Jeffrey Hugo <[email protected]>

CC Eric Holmberg <[email protected]>

Signed-off-by Kumar Gala <[email protected]>

---
v3:
* moved dt binding into hwlock/
* removed smp_mb() as they were not needed
* cleanup warning

v2:
* Fixed init of stride
* Dealt with a number of comments from Stephen Boyd:
- use of <linux/io.h> instead of <asm/io.h>
- declaring msm_hwspinlock_of_match once & as const
- drop unneccessary () in an if statement
- style cleanup to have devm_kzalloc on one line

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt line 10

Quoted 5 lines · Kumar Gala

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt new file +5 -0

+Required properties:
+- compatible: should be "qcom,tcsr-mutex"
+- reg: Should contain registers location and length of mutex registers
+- reg-names:
+	"mutex-base"  - string to identify mutex registers

Just out of curiosity, why is reg-names required? Especially if there seem to be only one set of registers?

Indeed, I tend to think that reg-names is a bad idea.

IIRC, the rule for "reg" is that entries must always have a defined order, so that it can always be accessed by integer index.

And given
that's true, allowing for reg-names just creates confusion since it implies you can look up the index in reg-names and then read reg at that index.

Quoted 4 lines · Stephen Warren

Indeed, I tend to think that reg-names is a bad idea.

IIRC, the rule for "reg" is that entries must always have a defined order, so that it can always be accessed by integer index.

First time I hear about that rule, really...

Quoted 4 lines

And given
that's true, allowing for reg-names just creates confusion since it implies you can look up the index in reg-names and then read reg at that index.

I actually believe that named resources leave less are for error than indexed ones. And this is the message I remember being "spread" in the times of static platform devices.

Pawel

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt line 10

Quoted 5 lines · Kumar Gala

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt new file +5 -0

+Required properties:
+- compatible: should be "qcom,tcsr-mutex"
+- reg: Should contain registers location and length of mutex registers
+- reg-names:
+	"mutex-base"  - string to identify mutex registers

Just out of curiosity, why is reg-names required? Especially if there seem to be only one set of registers?

Paweł

Quoted 4 lines · Kumar Gala

Add driver for Qualcomm MSM Hardware Mutex block that exists on newer MSM SoC (MSM8974, etc).

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt +0 -0

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt line 11

Quoted 6 lines

Documentation/devicetree/bindings/hwlock/msm-tcsr-mutex.txt +6 -0

+Required properties:
+- compatible: should be "qcom,tcsr-mutex"
+- reg: Should contain registers location and length of mutex registers
+- reg-names:
+	"mutex-base"  - string to identify mutex registers
+- qcom,num-locks: the number of locks/mutexes supported

Doesn't the block support any interrupts? I suppose the interrupts property can be optional though even if it does.

Aside from the comments re: reg-names, this binding seems fine. --

drivers/hwspinlock/msm_hwspinlock.c new file +8 -0

+
+       return readl_relaxed(lock_addr) == SPINLOCK_ID_APPS_PROC;
+}
+
+static void msm_hwspinlock_unlock(struct hwspinlock *lock)
+{
+       u32 lock_owner;
+       void __iomem *lock_addr = lock->priv;