All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv5 00/15] hwspinlock/omap dt support
@ 2014-05-01  0:34 ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Hi Ohad,

This is a refresh/update of the hwspinlock dt support series. The
series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to
handle various discussion points arised on v4.

Following are the main changes in v5:
- Base DT patches (Patches 1 to 7, except for 4) are identical to v4.
  Patch4 is updated to remove some traces and fix --strict checkpatch warnings.
- Patch 8 brings back the DT-based hwlock-base-id property, for registration
  purposes. Based on v4 discussion [1].
- Patches 9 through 13 introduce the concept of reserved locks, again based
  on the discussion in v4 [1]. The approach taken here is simplistic, each
  hwlock is assigned a type attribute during registration, with the _request_
  apis honoring the lock type attribute.
- Staged patches 14 & 15 for converting return convention to better
  support deferred probing of client drivers. I do think that it is
  still a good idea to return ERR_PTRs (unconcluded discussion in v4 [2]).
  The main advantage is to support deferred probing for DT boots. The
  original argument/change for returning NULL pointers pre-dates both
  the deferred driver probe mechanism and DT-based boot, so it may be
  moot on the current kernel.

I have marked the new patches as RFC, and should ideally be dealt
with as a separate series. I have added these to this series as
they also add couple of DT-based properties, as well as maintain the
discussion context from the previous series. I am ok for the reserved
lock patches to be left out for 3.16 merge window if these patches still
need some work. I am hoping to have the first 7 or 8 patches (and
finalized return code changes) to make it to 3.16.

The validation logs on all the applicable OMAP SoCs are at:
  OMAP4  - http://slexy.org/view/s2MMyLZTiH 
  OMAP5  - http://slexy.org/view/s20U2ElygK 
  DRA74x - http://slexy.org/view/s20fAoWJ84
  AM33xx - http://slexy.org/view/s2HLj2b406 
  AM43xx - http://slexy.org/view/s2JNrJSWLm 

The above logs are generated with some additional test patches staged
here for reference (not for merging)
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5-test

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139510004009415&w=2
[2] http://marc.info/?l=linux-omap&m=139490475424338&w=2

---
v4:
- The DT bindings are split into separate patches, and updated to
  add comments about #hwlock-cells
- Fixed a registration issue with repeated module installation and
  removal.
- Added a new OF helper to support #hwlock-cells in addition to the
  previous OF functions. The OMAP adaptation patch is updated to use
  the default translate function
- Updated hwspinlock documentation to adjust for the structure
  changes and the new api additions.
- Added build support for AM335x, AM43xx and DRA7xx
http://marc.info/?l=linux-omap&m=138965904015225&w=2

v3:
- Removed the DT property hwlock-base-id and associated OF helper
- Added changes in core to support requesting a specific hwlock using
  phandle + args approach
- Revised both the common and OMAP DT bindings document
http://marc.info/?l=linux-omap&m=138143992932197&w=2

v2:
- Added a new common DT binding documentation and OF helpers.
- Revised OMAP DT parse support to use the new OF helper (Patch2)
- OMAP5 hwspinlock support including the hwmod entry and DT node
- Add AM335x support to OMAP hwspinlock driver, including a fix
  needed in driver given that AM335 spinlock module requires s/w wakeup
- AM335 DT node for spinlock, and a hwmod change to enable smart-idle
  for AM335.
- OMAP4 DT node patch is unchanged
http://marc.info/?l=linux-omap&m=137944644112727&w=2

v1:
- Add DT parse support to OMAP hwspinlock driver
- Add OMAP4 DT node and bindings information
http://marc.info/?l=linux-omap&m=137823082308009&w=2

---

Suman Anna (15):
  Documentation: dt: add common bindings for hwspinlock
  Documentation: dt: add the omap hwspinlock bindings document
  hwspinlock/core: maintain a list of registered hwspinlock banks
  hwspinlock/core: add common OF helpers
  hwspinlock/omap: add support for dt nodes
  hwspinlock/omap: enable module before reading SYSSTATUS register
  hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
  hwspinlock/core: add support for base id in DT
  hwspinlock/core: prepare unregister code to support reserved locks
  hwspinlock/core: prepare core to support reserved locks
  hwspinlock/core: add support for reserved locks
  hwspinlock/core: add OF helper to parse reserved locks
  hwspinlock/omap: use OF helper to get reserved locks
  hwspinlock/core: return ERR_PTRs on failure in _request_ api
  hwspinlock/core: change return codes of_hwspin_lock_request_specific

 .../devicetree/bindings/hwlock/hwlock.txt          |  61 +++++
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt |  24 ++
 Documentation/hwspinlock.txt                       |  48 +++-
 MAINTAINERS                                        |   1 -
 arch/arm/mach-omap2/Makefile                       |   3 -
 arch/arm/mach-omap2/hwspinlock.c                   |  60 -----
 drivers/hwspinlock/Kconfig                         |   2 +-
 drivers/hwspinlock/hwspinlock_core.c               | 286 ++++++++++++++++++---
 drivers/hwspinlock/hwspinlock_internal.h           |  11 +
 drivers/hwspinlock/omap_hwspinlock.c               |  49 +++-
 drivers/hwspinlock/u8500_hsem.c                    |   3 +-
 include/linux/hwspinlock.h                         |  34 ++-
 12 files changed, 458 insertions(+), 124 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

-- 
1.9.2


^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 00/15] hwspinlock/omap dt support
@ 2014-05-01  0:34 ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Hi Ohad,

This is a refresh/update of the hwspinlock dt support series. The
series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to
handle various discussion points arised on v4.

Following are the main changes in v5:
- Base DT patches (Patches 1 to 7, except for 4) are identical to v4.
  Patch4 is updated to remove some traces and fix --strict checkpatch warnings.
- Patch 8 brings back the DT-based hwlock-base-id property, for registration
  purposes. Based on v4 discussion [1].
- Patches 9 through 13 introduce the concept of reserved locks, again based
  on the discussion in v4 [1]. The approach taken here is simplistic, each
  hwlock is assigned a type attribute during registration, with the _request_
  apis honoring the lock type attribute.
- Staged patches 14 & 15 for converting return convention to better
  support deferred probing of client drivers. I do think that it is
  still a good idea to return ERR_PTRs (unconcluded discussion in v4 [2]).
  The main advantage is to support deferred probing for DT boots. The
  original argument/change for returning NULL pointers pre-dates both
  the deferred driver probe mechanism and DT-based boot, so it may be
  moot on the current kernel.

I have marked the new patches as RFC, and should ideally be dealt
with as a separate series. I have added these to this series as
they also add couple of DT-based properties, as well as maintain the
discussion context from the previous series. I am ok for the reserved
lock patches to be left out for 3.16 merge window if these patches still
need some work. I am hoping to have the first 7 or 8 patches (and
finalized return code changes) to make it to 3.16.

The validation logs on all the applicable OMAP SoCs are at:
  OMAP4  - http://slexy.org/view/s2MMyLZTiH 
  OMAP5  - http://slexy.org/view/s20U2ElygK 
  DRA74x - http://slexy.org/view/s20fAoWJ84
  AM33xx - http://slexy.org/view/s2HLj2b406 
  AM43xx - http://slexy.org/view/s2JNrJSWLm 

The above logs are generated with some additional test patches staged
here for reference (not for merging)
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5-test

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139510004009415&w=2
[2] http://marc.info/?l=linux-omap&m=139490475424338&w=2

---
v4:
- The DT bindings are split into separate patches, and updated to
  add comments about #hwlock-cells
- Fixed a registration issue with repeated module installation and
  removal.
- Added a new OF helper to support #hwlock-cells in addition to the
  previous OF functions. The OMAP adaptation patch is updated to use
  the default translate function
- Updated hwspinlock documentation to adjust for the structure
  changes and the new api additions.
- Added build support for AM335x, AM43xx and DRA7xx
http://marc.info/?l=linux-omap&m=138965904015225&w=2

v3:
- Removed the DT property hwlock-base-id and associated OF helper
- Added changes in core to support requesting a specific hwlock using
  phandle + args approach
- Revised both the common and OMAP DT bindings document
http://marc.info/?l=linux-omap&m=138143992932197&w=2

v2:
- Added a new common DT binding documentation and OF helpers.
- Revised OMAP DT parse support to use the new OF helper (Patch2)
- OMAP5 hwspinlock support including the hwmod entry and DT node
- Add AM335x support to OMAP hwspinlock driver, including a fix
  needed in driver given that AM335 spinlock module requires s/w wakeup
- AM335 DT node for spinlock, and a hwmod change to enable smart-idle
  for AM335.
- OMAP4 DT node patch is unchanged
http://marc.info/?l=linux-omap&m=137944644112727&w=2

v1:
- Add DT parse support to OMAP hwspinlock driver
- Add OMAP4 DT node and bindings information
http://marc.info/?l=linux-omap&m=137823082308009&w=2

---

Suman Anna (15):
  Documentation: dt: add common bindings for hwspinlock
  Documentation: dt: add the omap hwspinlock bindings document
  hwspinlock/core: maintain a list of registered hwspinlock banks
  hwspinlock/core: add common OF helpers
  hwspinlock/omap: add support for dt nodes
  hwspinlock/omap: enable module before reading SYSSTATUS register
  hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
  hwspinlock/core: add support for base id in DT
  hwspinlock/core: prepare unregister code to support reserved locks
  hwspinlock/core: prepare core to support reserved locks
  hwspinlock/core: add support for reserved locks
  hwspinlock/core: add OF helper to parse reserved locks
  hwspinlock/omap: use OF helper to get reserved locks
  hwspinlock/core: return ERR_PTRs on failure in _request_ api
  hwspinlock/core: change return codes of_hwspin_lock_request_specific

 .../devicetree/bindings/hwlock/hwlock.txt          |  61 +++++
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt |  24 ++
 Documentation/hwspinlock.txt                       |  48 +++-
 MAINTAINERS                                        |   1 -
 arch/arm/mach-omap2/Makefile                       |   3 -
 arch/arm/mach-omap2/hwspinlock.c                   |  60 -----
 drivers/hwspinlock/Kconfig                         |   2 +-
 drivers/hwspinlock/hwspinlock_core.c               | 286 ++++++++++++++++++---
 drivers/hwspinlock/hwspinlock_internal.h           |  11 +
 drivers/hwspinlock/omap_hwspinlock.c               |  49 +++-
 drivers/hwspinlock/u8500_hsem.c                    |   3 +-
 include/linux/hwspinlock.h                         |  34 ++-
 12 files changed, 458 insertions(+), 124 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

-- 
1.9.2

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 00/15] hwspinlock/omap dt support
@ 2014-05-01  0:34 ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

This is a refresh/update of the hwspinlock dt support series. The
series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to
handle various discussion points arised on v4.

Following are the main changes in v5:
- Base DT patches (Patches 1 to 7, except for 4) are identical to v4.
  Patch4 is updated to remove some traces and fix --strict checkpatch warnings.
- Patch 8 brings back the DT-based hwlock-base-id property, for registration
  purposes. Based on v4 discussion [1].
- Patches 9 through 13 introduce the concept of reserved locks, again based
  on the discussion in v4 [1]. The approach taken here is simplistic, each
  hwlock is assigned a type attribute during registration, with the _request_
  apis honoring the lock type attribute.
- Staged patches 14 & 15 for converting return convention to better
  support deferred probing of client drivers. I do think that it is
  still a good idea to return ERR_PTRs (unconcluded discussion in v4 [2]).
  The main advantage is to support deferred probing for DT boots. The
  original argument/change for returning NULL pointers pre-dates both
  the deferred driver probe mechanism and DT-based boot, so it may be
  moot on the current kernel.

I have marked the new patches as RFC, and should ideally be dealt
with as a separate series. I have added these to this series as
they also add couple of DT-based properties, as well as maintain the
discussion context from the previous series. I am ok for the reserved
lock patches to be left out for 3.16 merge window if these patches still
need some work. I am hoping to have the first 7 or 8 patches (and
finalized return code changes) to make it to 3.16.

The validation logs on all the applicable OMAP SoCs are at:
  OMAP4  - http://slexy.org/view/s2MMyLZTiH 
  OMAP5  - http://slexy.org/view/s20U2ElygK 
  DRA74x - http://slexy.org/view/s20fAoWJ84
  AM33xx - http://slexy.org/view/s2HLj2b406 
  AM43xx - http://slexy.org/view/s2JNrJSWLm 

The above logs are generated with some additional test patches staged
here for reference (not for merging)
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5
https://github.com/sumananna/omap-kernel/commits/hwspinlock/3.15-rc3-v5-test

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139510004009415&w=2
[2] http://marc.info/?l=linux-omap&m=139490475424338&w=2

---
v4:
- The DT bindings are split into separate patches, and updated to
  add comments about #hwlock-cells
- Fixed a registration issue with repeated module installation and
  removal.
- Added a new OF helper to support #hwlock-cells in addition to the
  previous OF functions. The OMAP adaptation patch is updated to use
  the default translate function
- Updated hwspinlock documentation to adjust for the structure
  changes and the new api additions.
- Added build support for AM335x, AM43xx and DRA7xx
http://marc.info/?l=linux-omap&m=138965904015225&w=2

v3:
- Removed the DT property hwlock-base-id and associated OF helper
- Added changes in core to support requesting a specific hwlock using
  phandle + args approach
- Revised both the common and OMAP DT bindings document
http://marc.info/?l=linux-omap&m=138143992932197&w=2

v2:
- Added a new common DT binding documentation and OF helpers.
- Revised OMAP DT parse support to use the new OF helper (Patch2)
- OMAP5 hwspinlock support including the hwmod entry and DT node
- Add AM335x support to OMAP hwspinlock driver, including a fix
  needed in driver given that AM335 spinlock module requires s/w wakeup
- AM335 DT node for spinlock, and a hwmod change to enable smart-idle
  for AM335.
- OMAP4 DT node patch is unchanged
http://marc.info/?l=linux-omap&m=137944644112727&w=2

v1:
- Add DT parse support to OMAP hwspinlock driver
- Add OMAP4 DT node and bindings information
http://marc.info/?l=linux-omap&m=137823082308009&w=2

---

Suman Anna (15):
  Documentation: dt: add common bindings for hwspinlock
  Documentation: dt: add the omap hwspinlock bindings document
  hwspinlock/core: maintain a list of registered hwspinlock banks
  hwspinlock/core: add common OF helpers
  hwspinlock/omap: add support for dt nodes
  hwspinlock/omap: enable module before reading SYSSTATUS register
  hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
  hwspinlock/core: add support for base id in DT
  hwspinlock/core: prepare unregister code to support reserved locks
  hwspinlock/core: prepare core to support reserved locks
  hwspinlock/core: add support for reserved locks
  hwspinlock/core: add OF helper to parse reserved locks
  hwspinlock/omap: use OF helper to get reserved locks
  hwspinlock/core: return ERR_PTRs on failure in _request_ api
  hwspinlock/core: change return codes of_hwspin_lock_request_specific

 .../devicetree/bindings/hwlock/hwlock.txt          |  61 +++++
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt |  24 ++
 Documentation/hwspinlock.txt                       |  48 +++-
 MAINTAINERS                                        |   1 -
 arch/arm/mach-omap2/Makefile                       |   3 -
 arch/arm/mach-omap2/hwspinlock.c                   |  60 -----
 drivers/hwspinlock/Kconfig                         |   2 +-
 drivers/hwspinlock/hwspinlock_core.c               | 286 ++++++++++++++++++---
 drivers/hwspinlock/hwspinlock_internal.h           |  11 +
 drivers/hwspinlock/omap_hwspinlock.c               |  49 +++-
 drivers/hwspinlock/u8500_hsem.c                    |   3 +-
 include/linux/hwspinlock.h                         |  34 ++-
 12 files changed, 458 insertions(+), 124 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

-- 
1.9.2

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna,
	Rob Herring

This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.

All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.

Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 0000000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+=======================
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells:	Specifies the number of cells needed to represent a
+			specific lock.
+- hwlock-num-locks:	Number of locks present in a hwlock device. This
+			property is needed on hwlock devices, where the number
+			of supported locks within a hwlock device cannot be
+			read from a register.
+
+Hwlock Users:
+=============
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+	node {
+		...
+		hwlocks = <&hwlock1 2>;
+		...
+	};
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+	node {
+		...
+		hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
+		...
+	};
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Suman Anna,
	Rob Herring

This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.

All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.

Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.

Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
---
 .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 0000000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+=======================
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells:	Specifies the number of cells needed to represent a
+			specific lock.
+- hwlock-num-locks:	Number of locks present in a hwlock device. This
+			property is needed on hwlock devices, where the number
+			of supported locks within a hwlock device cannot be
+			read from a register.
+
+Hwlock Users:
+=============
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+	node {
+		...
+		hwlocks = <&hwlock1 2>;
+		...
+	};
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+	node {
+		...
+		hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
+		...
+	};
-- 
1.9.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.

All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. The number of locks
is represented by 'hwlock-num-locks' property in DT bindings. A
property for base id is not needed in DT binding, as it can be
satisfied using a phandle + args specifier. The args specifier
length is dependent on each vendor-specific implementation and
is represented through the '#hwlock-cells' property.

Note that the document is named hwlock.txt deliberately to keep it
a bit more generic.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 0000000..32381cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,52 @@
+Generic hwlock bindings
+=======================
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations, the retrieved values are used for registering the device
+specific parameters with the hwspinlock core.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if a property is mandatory or optional. Please look through the
+individual platform specific hwlock binding documentations for identifying
+the applicable properties.
+
+Common properties:
+- #hwlock-cells:	Specifies the number of cells needed to represent a
+			specific lock.
+- hwlock-num-locks:	Number of locks present in a hwlock device. This
+			property is needed on hwlock devices, where the number
+			of supported locks within a hwlock device cannot be
+			read from a register.
+
+Hwlock Users:
+=============
+
+Nodes that require specific hwlock(s) should specify them using one or more
+properties, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+	node {
+		...
+		hwlocks = <&hwlock1 2>;
+		...
+	};
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+	node {
+		...
+		hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
+		...
+	};
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna,
	Rob Herring

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 0000000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+========================
+
+Required properties:
+- compatible:		Should be "ti,omap4-hwspinlock" for
+			    OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg:			Contains the hwspinlock module register address space
+			(base address and length)
+- ti,hwmods:		Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells:	Should be 1. The OMAP hwspinlock users will use a
+			0-indexed relative hwlock number as the argument
+			specifier value for requesting a specific hwspinlock
+			within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+	compatible = "ti,omap4-hwspinlock";
+	reg = <0x4a0f6000 0x1000>;
+	ti,hwmods = "spinlock";
+	#hwlock-cells = <1>;
+};
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna,
	Rob Herring

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 0000000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+========================
+
+Required properties:
+- compatible:		Should be "ti,omap4-hwspinlock" for
+			    OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg:			Contains the hwspinlock module register address space
+			(base address and length)
+- ti,hwmods:		Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells:	Should be 1. The OMAP hwspinlock users will use a
+			0-indexed relative hwlock number as the argument
+			specifier value for requesting a specific hwspinlock
+			within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+	compatible = "ti,omap4-hwspinlock";
+	reg = <0x4a0f6000 0x1000>;
+	ti,hwmods = "spinlock";
+	#hwlock-cells = <1>;
+};
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt

diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 0000000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+========================
+
+Required properties:
+- compatible:		Should be "ti,omap4-hwspinlock" for
+			    OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg:			Contains the hwspinlock module register address space
+			(base address and length)
+- ti,hwmods:		Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells:	Should be 1. The OMAP hwspinlock users will use a
+			0-indexed relative hwlock number as the argument
+			specifier value for requesting a specific hwspinlock
+			within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock at 4a0f6000 {
+	compatible = "ti,omap4-hwspinlock";
+	reg = <0x4a0f6000 0x1000>;
+	ti,hwmods = "spinlock";
+	#hwlock-cells = <1>;
+};
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.

The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/hwspinlock.txt             |  2 ++
 drivers/hwspinlock/hwspinlock_core.c     | 51 ++++++++++++++++++++++++++++++++
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 3 files changed, 55 insertions(+)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+	struct list_head list;
 	struct device *dev;
 	const struct hwspinlock_ops *ops;
 	int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
  */
 static DEFINE_MUTEX(hwspinlock_tree_lock);
 
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
 
 /**
  * __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
 	return hwlock;
 }
 
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+	struct list_head *entry = &hwspinlock_devices;
+	struct hwspinlock_device *_bank;
+	int ret = 0;
+
+	list_for_each(entry, &hwspinlock_devices) {
+		_bank = list_entry(entry, struct hwspinlock_device, list);
+		if (_bank->base_id >= bank->base_id + bank->num_locks)
+			break;
+	}
+
+	if (entry != &hwspinlock_devices &&
+	    entry->prev != &hwspinlock_devices) {
+		_bank = list_entry(entry->prev, struct hwspinlock_device, list);
+		if (_bank->base_id + _bank->num_locks > bank->base_id) {
+			dev_err(bank->dev, "hwlock space overlap, cannot add device\n");
+			ret = -EBUSY;
+		}
+	}
+
+	if (!ret)
+		list_add_tail(&bank->list, entry);
+
+	return ret;
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	bank->base_id = base_id;
 	bank->num_locks = num_locks;
 
+	mutex_lock(&hwspinlock_tree_lock);
+	ret = hwspinlock_device_add(bank);
+	mutex_unlock(&hwspinlock_tree_lock);
+	if (ret)
+		return ret;
+
 	for (i = 0; i < num_locks; i++) {
 		hwlock = &bank->lock[i];
 
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 reg_failed:
 	while (--i >= 0)
 		hwspin_lock_unregister_single(base_id + i);
+	mutex_lock(&hwspinlock_tree_lock);
+	list_del(&bank->list);
+	mutex_unlock(&hwspinlock_tree_lock);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
 		WARN_ON(tmp != hwlock);
 	}
 
+	mutex_lock(&hwspinlock_tree_lock);
+	list_del(&bank->list);
+	mutex_unlock(&hwspinlock_tree_lock);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_unregister);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index d26f78b..aff560c 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -53,6 +53,7 @@ struct hwspinlock {
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -60,6 +61,7 @@ struct hwspinlock {
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+	struct list_head list;
 	struct device *dev;
 	const struct hwspinlock_ops *ops;
 	int base_id;
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.

The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/hwspinlock.txt             |  2 ++
 drivers/hwspinlock/hwspinlock_core.c     | 51 ++++++++++++++++++++++++++++++++
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 3 files changed, 55 insertions(+)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+	struct list_head list;
 	struct device *dev;
 	const struct hwspinlock_ops *ops;
 	int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
  */
 static DEFINE_MUTEX(hwspinlock_tree_lock);
 
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
 
 /**
  * __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
 	return hwlock;
 }
 
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+	struct list_head *entry = &hwspinlock_devices;
+	struct hwspinlock_device *_bank;
+	int ret = 0;
+
+	list_for_each(entry, &hwspinlock_devices) {
+		_bank = list_entry(entry, struct hwspinlock_device, list);
+		if (_bank->base_id >= bank->base_id + bank->num_locks)
+			break;
+	}
+
+	if (entry != &hwspinlock_devices &&
+	    entry->prev != &hwspinlock_devices) {
+		_bank = list_entry(entry->prev, struct hwspinlock_device, list);
+		if (_bank->base_id + _bank->num_locks > bank->base_id) {
+			dev_err(bank->dev, "hwlock space overlap, cannot add device\n");
+			ret = -EBUSY;
+		}
+	}
+
+	if (!ret)
+		list_add_tail(&bank->list, entry);
+
+	return ret;
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	bank->base_id = base_id;
 	bank->num_locks = num_locks;
 
+	mutex_lock(&hwspinlock_tree_lock);
+	ret = hwspinlock_device_add(bank);
+	mutex_unlock(&hwspinlock_tree_lock);
+	if (ret)
+		return ret;
+
 	for (i = 0; i < num_locks; i++) {
 		hwlock = &bank->lock[i];
 
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 reg_failed:
 	while (--i >= 0)
 		hwspin_lock_unregister_single(base_id + i);
+	mutex_lock(&hwspinlock_tree_lock);
+	list_del(&bank->list);
+	mutex_unlock(&hwspinlock_tree_lock);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
 		WARN_ON(tmp != hwlock);
 	}
 
+	mutex_lock(&hwspinlock_tree_lock);
+	list_del(&bank->list);
+	mutex_unlock(&hwspinlock_tree_lock);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_unregister);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index d26f78b..aff560c 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -53,6 +53,7 @@ struct hwspinlock {
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -60,6 +61,7 @@ struct hwspinlock {
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+	struct list_head list;
 	struct device *dev;
 	const struct hwspinlock_ops *ops;
 	int base_id;
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.

The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/hwspinlock.txt             |  2 ++
 drivers/hwspinlock/hwspinlock_core.c     | 51 ++++++++++++++++++++++++++++++++
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 3 files changed, 55 insertions(+)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+	struct list_head list;
 	struct device *dev;
 	const struct hwspinlock_ops *ops;
 	int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
  */
 static DEFINE_MUTEX(hwspinlock_tree_lock);
 
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
 
 /**
  * __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
 	return hwlock;
 }
 
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+	struct list_head *entry = &hwspinlock_devices;
+	struct hwspinlock_device *_bank;
+	int ret = 0;
+
+	list_for_each(entry, &hwspinlock_devices) {
+		_bank = list_entry(entry, struct hwspinlock_device, list);
+		if (_bank->base_id >= bank->base_id + bank->num_locks)
+			break;
+	}
+
+	if (entry != &hwspinlock_devices &&
+	    entry->prev != &hwspinlock_devices) {
+		_bank = list_entry(entry->prev, struct hwspinlock_device, list);
+		if (_bank->base_id + _bank->num_locks > bank->base_id) {
+			dev_err(bank->dev, "hwlock space overlap, cannot add device\n");
+			ret = -EBUSY;
+		}
+	}
+
+	if (!ret)
+		list_add_tail(&bank->list, entry);
+
+	return ret;
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	bank->base_id = base_id;
 	bank->num_locks = num_locks;
 
+	mutex_lock(&hwspinlock_tree_lock);
+	ret = hwspinlock_device_add(bank);
+	mutex_unlock(&hwspinlock_tree_lock);
+	if (ret)
+		return ret;
+
 	for (i = 0; i < num_locks; i++) {
 		hwlock = &bank->lock[i];
 
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 reg_failed:
 	while (--i >= 0)
 		hwspin_lock_unregister_single(base_id + i);
+	mutex_lock(&hwspinlock_tree_lock);
+	list_del(&bank->list);
+	mutex_unlock(&hwspinlock_tree_lock);
 	return ret;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
 		WARN_ON(tmp != hwlock);
 	}
 
+	mutex_lock(&hwspinlock_tree_lock);
+	list_del(&bank->list);
+	mutex_unlock(&hwspinlock_tree_lock);
 	return 0;
 }
 EXPORT_SYMBOL_GPL(hwspin_lock_unregister);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index d26f78b..aff560c 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -53,6 +53,7 @@ struct hwspinlock {
 
 /**
  * struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
  * @dev: underlying device, will be used to invoke runtime PM api
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
@@ -60,6 +61,7 @@ struct hwspinlock {
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
+	struct list_head list;
 	struct device *dev;
 	const struct hwspinlock_ops *ops;
 	int base_id;
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.

1. The of_hwspin_lock_get_num_locks() is a common helper
   function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a simple default
   translator function for hwspinlock provider implementations
   that use a single cell number for requesting a specific lock
   (relatively indexed) within a hwlock bank.
3. The of_hwspin_lock_request_specific() API can be used by
   hwspinlock clients to request a specific lock using the
   phandle + args specifier. This function relies on the
   implementation providing back a relative hwlock id within
   the bank from the args specifier.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/hwspinlock.txt             |  34 ++++++++++-
 drivers/hwspinlock/hwspinlock_core.c     | 100 ++++++++++++++++++++++++++++++-
 drivers/hwspinlock/hwspinlock_internal.h |   4 ++
 include/linux/hwspinlock.h               |  22 ++++++-
 4 files changed, 155 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..903d477 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,15 @@ independent, drivers.
      ids for predefined purposes.
      Should be called from a process context (might sleep).
 
+  struct hwspinlock *of_hwspin_lock_request_specific(
+		struct device_node *np,	const char *propname, int index);
+   - assign a specific hwspinlock id and return its address, or NULL
+     if that hwspinlock is already in use. This function is the OF
+     equivalent of hwspin_lock_request_specific() function, and provides
+     a means for users of the hwspinlock module to request a specific
+     hwspinlock using the phandle of the hwspinlock device.
+     Should be called from a process context (might sleep).
+
   int hwspin_lock_free(struct hwspinlock *hwlock);
    - free a previously-assigned hwspinlock; returns 0 on success, or an
      appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +252,23 @@ int hwspinlock_example2(void)
      Returns the address of hwspinlock on success, or NULL on error (e.g.
      if the hwspinlock is still in use).
 
+  int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				  const struct of_phandle_args *hwlock_spec);
+   - is a simple default OF translate helper function that can be plugged in
+     as the underlying vendor-specific implementation's of_xlate ops function.
+     This can be used by implementations that use a single integer argument in
+     the DT node argument specifier, that indicates the hwlock index number.
+     Returns a hwlock index within a bank, or appropriate error code on
+     failure.
+
+  int of_hwspin_lock_get_num_locks(struct device_node *dn);
+   - is a common OF helper function that can be used by some underlying
+     vendor-specific implementations. This can be used by implementations
+     that require and define the number of locks supported within a hwspinlock
+     bank as a device tree node property. This function should be called by
+     needed implementations before registering a hwspinlock device with the
+     core.
+
 5. Important structs
 
 struct hwspinlock_device is a device which usually contains a bank
@@ -288,12 +314,14 @@ initialized by the hwspinlock core itself.
 
 6. Implementation callbacks
 
-There are three possible callbacks defined in 'struct hwspinlock_ops':
+There are four possible callbacks defined in 'struct hwspinlock_ops':
 
 struct hwspinlock_ops {
 	int (*trylock)(struct hwspinlock *lock);
 	void (*unlock)(struct hwspinlock *lock);
 	void (*relax)(struct hwspinlock *lock);
+	int (*of_xlate)(struct hwspinlock_device *bank,
+			const struct of_phandle_args *hwlock_spec);
 };
 
 The first two callbacks are mandatory:
@@ -307,3 +335,7 @@ may _not_ sleep.
 The ->relax() callback is optional. It is called by hwspinlock core while
 spinning on a lock, and can be used by the underlying implementation to force
 a delay between two successive invocations of ->trylock(). It may _not_ sleep.
+
+The ->of_xlate() callback is mandatory to support requesting hwlocks through
+device-tree nodes. It is called by hwspinlock core to retrieve the relative
+lock index within a bank from the underlying implementation.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..3966c0c 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
 #include <linux/hwspinlock.h>
 #include <linux/pm_runtime.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 
 #include "hwspinlock_internal.h"
 
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 }
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
+/**
+ * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance. The hwlock-num-locks
+ * DT property may be optional for some platforms, while mandatory for
+ * some others, so this function is typically called only by needed
+ * platform-specific implementations.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ * failure or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_locks(struct device_node *dn)
+{
+	unsigned int val;
+	int ret = -ENODEV;
+
+	ret = of_property_read_u32(dn, "hwlock-num-locks", &val);
+	if (!ret)
+		ret = val ? val : -ENODEV;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_locks);
+
 static int hwspin_lock_register_single(struct hwspinlock *hwlock, int id)
 {
 	struct hwspinlock *tmp;
@@ -312,6 +340,31 @@ out:
 	return hwlock;
 }
 
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a negative value on error, and a relative index of the lock within
+ * a specified bank on success.
+ */
+int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				const struct of_phandle_args *hwlock_spec)
+{
+	/* sanity check (these shouldn't happen) */
+	if (WARN_ON(!bank->dev->of_node))
+		return -EINVAL;
+
+	if (WARN_ON(hwlock_spec->args_count != 1))
+		return -EINVAL;
+
+	return hwlock_spec->args[0];
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_simple_xlate);
+
 /*
  * Add a new hwspinlock device to the global list, keeping the list of
  * devices sorted by base order.
@@ -368,7 +421,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	int ret = 0, i;
 
 	if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-							!ops->unlock) {
+	    !ops->unlock || (dev->of_node && !ops->of_xlate)) {
 		pr_err("invalid parameters\n");
 		return -EINVAL;
 	}
@@ -592,6 +645,51 @@ out:
 EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
 
 /**
+ * of_hwspin_lock_request_specific() - request a OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @propname: property name containing hwlock specifier(s)
+ * @index: index of the hwlock
+ *
+ * This function is the OF equivalent of hwspin_lock_request_specific(). This
+ * function provides a means for users of the hwspinlock module to request a
+ * specific hwspinlock using the phandle of the hwspinlock device. The requested
+ * lock number is indexed relative to the hwspinlock device, unlike the
+ * hwspin_lock_request_specific() which is an absolute lock number.
+ *
+ * Returns the address of the assigned hwspinlock, or NULL on error
+ */
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index)
+{
+	struct hwspinlock_device *bank;
+	struct of_phandle_args args;
+	int id;
+	int ret;
+
+	ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
+					 &args);
+	if (ret)
+		return NULL;
+
+	mutex_lock(&hwspinlock_tree_lock);
+	list_for_each_entry(bank, &hwspinlock_devices, list)
+		if (bank->dev->of_node == args.np)
+			break;
+	mutex_unlock(&hwspinlock_tree_lock);
+	if (&bank->list == &hwspinlock_devices)
+		return NULL;
+
+	id = bank->ops->of_xlate(bank, &args);
+	if (id < 0 || id >= bank->num_locks)
+		return NULL;
+
+	id += bank->base_id;
+	return hwspin_lock_request_specific(id);
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_request_specific);
+
+/**
  * hwspin_lock_free() - free a specific hwspinlock
  * @hwlock: the specific hwspinlock to free
  *
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index aff560c..5e42613 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -32,11 +32,15 @@ struct hwspinlock_device;
  * @relax:   optional, platform-specific relax handler, called by hwspinlock
  *	     core while spinning on a lock, between two successive
  *	     invocations of @trylock. may _not_ sleep.
+ * @of_xlate: platform-specific hwlock specifier translate function, to
+ *	      return the relative index of the lock within a bank
  */
 struct hwspinlock_ops {
 	int (*trylock)(struct hwspinlock *lock);
 	void (*unlock)(struct hwspinlock *lock);
 	void (*relax)(struct hwspinlock *lock);
+	int (*of_xlate)(struct hwspinlock_device *bank,
+			const struct of_phandle_args *hwlock_spec);
 };
 
 /**
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 3343298..068e628 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -26,6 +26,8 @@
 #define HWLOCK_IRQ	0x02	/* Disable interrupts, don't save state */
 
 struct device;
+struct device_node;
+struct of_phandle_args;
 struct hwspinlock;
 struct hwspinlock_device;
 struct hwspinlock_ops;
@@ -60,11 +62,17 @@ struct hwspinlock_pdata {
 
 #if defined(CONFIG_HWSPINLOCK) || defined(CONFIG_HWSPINLOCK_MODULE)
 
+int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks);
 int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request(void);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index);
 int hwspin_lock_free(struct hwspinlock *hwlock);
 int hwspin_lock_get_id(struct hwspinlock *hwlock);
 int __hwspin_lock_timeout(struct hwspinlock *, unsigned int, int,
@@ -80,9 +88,9 @@ void __hwspin_unlock(struct hwspinlock *, int, unsigned long *);
  * code path get compiled away. This way, if CONFIG_HWSPINLOCK is not
  * required on a given setup, users will still work.
  *
- * The only exception is hwspin_lock_register/hwspin_lock_unregister, with which
- * we _do_ want users to fail (no point in registering hwspinlock instances if
- * the framework is not available).
+ * The only exception is hwspin_lock_register/hwspin_lock_unregister and
+ * associated OF helpers, with which we _do_ want users to fail (no point
+ * in registering hwspinlock instances if the framework is not available).
  *
  * Note: ERR_PTR(-ENODEV) will still be considered a success for NULL-checking
  * users. Others, which care, can still check this with IS_ERR.
@@ -97,6 +105,14 @@ static inline struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	return ERR_PTR(-ENODEV);
 }
 
+static inline
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 static inline int hwspin_lock_free(struct hwspinlock *hwlock)
 {
 	return 0;
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.

1. The of_hwspin_lock_get_num_locks() is a common helper
   function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a simple default
   translator function for hwspinlock provider implementations
   that use a single cell number for requesting a specific lock
   (relatively indexed) within a hwlock bank.
3. The of_hwspin_lock_request_specific() API can be used by
   hwspinlock clients to request a specific lock using the
   phandle + args specifier. This function relies on the
   implementation providing back a relative hwlock id within
   the bank from the args specifier.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/hwspinlock.txt             |  34 ++++++++++-
 drivers/hwspinlock/hwspinlock_core.c     | 100 ++++++++++++++++++++++++++++++-
 drivers/hwspinlock/hwspinlock_internal.h |   4 ++
 include/linux/hwspinlock.h               |  22 ++++++-
 4 files changed, 155 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..903d477 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,15 @@ independent, drivers.
      ids for predefined purposes.
      Should be called from a process context (might sleep).
 
+  struct hwspinlock *of_hwspin_lock_request_specific(
+		struct device_node *np,	const char *propname, int index);
+   - assign a specific hwspinlock id and return its address, or NULL
+     if that hwspinlock is already in use. This function is the OF
+     equivalent of hwspin_lock_request_specific() function, and provides
+     a means for users of the hwspinlock module to request a specific
+     hwspinlock using the phandle of the hwspinlock device.
+     Should be called from a process context (might sleep).
+
   int hwspin_lock_free(struct hwspinlock *hwlock);
    - free a previously-assigned hwspinlock; returns 0 on success, or an
      appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +252,23 @@ int hwspinlock_example2(void)
      Returns the address of hwspinlock on success, or NULL on error (e.g.
      if the hwspinlock is still in use).
 
+  int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				  const struct of_phandle_args *hwlock_spec);
+   - is a simple default OF translate helper function that can be plugged in
+     as the underlying vendor-specific implementation's of_xlate ops function.
+     This can be used by implementations that use a single integer argument in
+     the DT node argument specifier, that indicates the hwlock index number.
+     Returns a hwlock index within a bank, or appropriate error code on
+     failure.
+
+  int of_hwspin_lock_get_num_locks(struct device_node *dn);
+   - is a common OF helper function that can be used by some underlying
+     vendor-specific implementations. This can be used by implementations
+     that require and define the number of locks supported within a hwspinlock
+     bank as a device tree node property. This function should be called by
+     needed implementations before registering a hwspinlock device with the
+     core.
+
 5. Important structs
 
 struct hwspinlock_device is a device which usually contains a bank
@@ -288,12 +314,14 @@ initialized by the hwspinlock core itself.
 
 6. Implementation callbacks
 
-There are three possible callbacks defined in 'struct hwspinlock_ops':
+There are four possible callbacks defined in 'struct hwspinlock_ops':
 
 struct hwspinlock_ops {
 	int (*trylock)(struct hwspinlock *lock);
 	void (*unlock)(struct hwspinlock *lock);
 	void (*relax)(struct hwspinlock *lock);
+	int (*of_xlate)(struct hwspinlock_device *bank,
+			const struct of_phandle_args *hwlock_spec);
 };
 
 The first two callbacks are mandatory:
@@ -307,3 +335,7 @@ may _not_ sleep.
 The ->relax() callback is optional. It is called by hwspinlock core while
 spinning on a lock, and can be used by the underlying implementation to force
 a delay between two successive invocations of ->trylock(). It may _not_ sleep.
+
+The ->of_xlate() callback is mandatory to support requesting hwlocks through
+device-tree nodes. It is called by hwspinlock core to retrieve the relative
+lock index within a bank from the underlying implementation.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..3966c0c 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
 #include <linux/hwspinlock.h>
 #include <linux/pm_runtime.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 
 #include "hwspinlock_internal.h"
 
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 }
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
+/**
+ * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance. The hwlock-num-locks
+ * DT property may be optional for some platforms, while mandatory for
+ * some others, so this function is typically called only by needed
+ * platform-specific implementations.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ * failure or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_locks(struct device_node *dn)
+{
+	unsigned int val;
+	int ret = -ENODEV;
+
+	ret = of_property_read_u32(dn, "hwlock-num-locks", &val);
+	if (!ret)
+		ret = val ? val : -ENODEV;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_locks);
+
 static int hwspin_lock_register_single(struct hwspinlock *hwlock, int id)
 {
 	struct hwspinlock *tmp;
@@ -312,6 +340,31 @@ out:
 	return hwlock;
 }
 
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a negative value on error, and a relative index of the lock within
+ * a specified bank on success.
+ */
+int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				const struct of_phandle_args *hwlock_spec)
+{
+	/* sanity check (these shouldn't happen) */
+	if (WARN_ON(!bank->dev->of_node))
+		return -EINVAL;
+
+	if (WARN_ON(hwlock_spec->args_count != 1))
+		return -EINVAL;
+
+	return hwlock_spec->args[0];
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_simple_xlate);
+
 /*
  * Add a new hwspinlock device to the global list, keeping the list of
  * devices sorted by base order.
@@ -368,7 +421,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	int ret = 0, i;
 
 	if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-							!ops->unlock) {
+	    !ops->unlock || (dev->of_node && !ops->of_xlate)) {
 		pr_err("invalid parameters\n");
 		return -EINVAL;
 	}
@@ -592,6 +645,51 @@ out:
 EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
 
 /**
+ * of_hwspin_lock_request_specific() - request a OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @propname: property name containing hwlock specifier(s)
+ * @index: index of the hwlock
+ *
+ * This function is the OF equivalent of hwspin_lock_request_specific(). This
+ * function provides a means for users of the hwspinlock module to request a
+ * specific hwspinlock using the phandle of the hwspinlock device. The requested
+ * lock number is indexed relative to the hwspinlock device, unlike the
+ * hwspin_lock_request_specific() which is an absolute lock number.
+ *
+ * Returns the address of the assigned hwspinlock, or NULL on error
+ */
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index)
+{
+	struct hwspinlock_device *bank;
+	struct of_phandle_args args;
+	int id;
+	int ret;
+
+	ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
+					 &args);
+	if (ret)
+		return NULL;
+
+	mutex_lock(&hwspinlock_tree_lock);
+	list_for_each_entry(bank, &hwspinlock_devices, list)
+		if (bank->dev->of_node == args.np)
+			break;
+	mutex_unlock(&hwspinlock_tree_lock);
+	if (&bank->list == &hwspinlock_devices)
+		return NULL;
+
+	id = bank->ops->of_xlate(bank, &args);
+	if (id < 0 || id >= bank->num_locks)
+		return NULL;
+
+	id += bank->base_id;
+	return hwspin_lock_request_specific(id);
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_request_specific);
+
+/**
  * hwspin_lock_free() - free a specific hwspinlock
  * @hwlock: the specific hwspinlock to free
  *
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index aff560c..5e42613 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -32,11 +32,15 @@ struct hwspinlock_device;
  * @relax:   optional, platform-specific relax handler, called by hwspinlock
  *	     core while spinning on a lock, between two successive
  *	     invocations of @trylock. may _not_ sleep.
+ * @of_xlate: platform-specific hwlock specifier translate function, to
+ *	      return the relative index of the lock within a bank
  */
 struct hwspinlock_ops {
 	int (*trylock)(struct hwspinlock *lock);
 	void (*unlock)(struct hwspinlock *lock);
 	void (*relax)(struct hwspinlock *lock);
+	int (*of_xlate)(struct hwspinlock_device *bank,
+			const struct of_phandle_args *hwlock_spec);
 };
 
 /**
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 3343298..068e628 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -26,6 +26,8 @@
 #define HWLOCK_IRQ	0x02	/* Disable interrupts, don't save state */
 
 struct device;
+struct device_node;
+struct of_phandle_args;
 struct hwspinlock;
 struct hwspinlock_device;
 struct hwspinlock_ops;
@@ -60,11 +62,17 @@ struct hwspinlock_pdata {
 
 #if defined(CONFIG_HWSPINLOCK) || defined(CONFIG_HWSPINLOCK_MODULE)
 
+int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks);
 int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request(void);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index);
 int hwspin_lock_free(struct hwspinlock *hwlock);
 int hwspin_lock_get_id(struct hwspinlock *hwlock);
 int __hwspin_lock_timeout(struct hwspinlock *, unsigned int, int,
@@ -80,9 +88,9 @@ void __hwspin_unlock(struct hwspinlock *, int, unsigned long *);
  * code path get compiled away. This way, if CONFIG_HWSPINLOCK is not
  * required on a given setup, users will still work.
  *
- * The only exception is hwspin_lock_register/hwspin_lock_unregister, with which
- * we _do_ want users to fail (no point in registering hwspinlock instances if
- * the framework is not available).
+ * The only exception is hwspin_lock_register/hwspin_lock_unregister and
+ * associated OF helpers, with which we _do_ want users to fail (no point
+ * in registering hwspinlock instances if the framework is not available).
  *
  * Note: ERR_PTR(-ENODEV) will still be considered a success for NULL-checking
  * users. Others, which care, can still check this with IS_ERR.
@@ -97,6 +105,14 @@ static inline struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	return ERR_PTR(-ENODEV);
 }
 
+static inline
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 static inline int hwspin_lock_free(struct hwspinlock *hwlock)
 {
 	return 0;
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.

1. The of_hwspin_lock_get_num_locks() is a common helper
   function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a simple default
   translator function for hwspinlock provider implementations
   that use a single cell number for requesting a specific lock
   (relatively indexed) within a hwlock bank.
3. The of_hwspin_lock_request_specific() API can be used by
   hwspinlock clients to request a specific lock using the
   phandle + args specifier. This function relies on the
   implementation providing back a relative hwlock id within
   the bank from the args specifier.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/hwspinlock.txt             |  34 ++++++++++-
 drivers/hwspinlock/hwspinlock_core.c     | 100 ++++++++++++++++++++++++++++++-
 drivers/hwspinlock/hwspinlock_internal.h |   4 ++
 include/linux/hwspinlock.h               |  22 ++++++-
 4 files changed, 155 insertions(+), 5 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..903d477 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,15 @@ independent, drivers.
      ids for predefined purposes.
      Should be called from a process context (might sleep).
 
+  struct hwspinlock *of_hwspin_lock_request_specific(
+		struct device_node *np,	const char *propname, int index);
+   - assign a specific hwspinlock id and return its address, or NULL
+     if that hwspinlock is already in use. This function is the OF
+     equivalent of hwspin_lock_request_specific() function, and provides
+     a means for users of the hwspinlock module to request a specific
+     hwspinlock using the phandle of the hwspinlock device.
+     Should be called from a process context (might sleep).
+
   int hwspin_lock_free(struct hwspinlock *hwlock);
    - free a previously-assigned hwspinlock; returns 0 on success, or an
      appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +252,23 @@ int hwspinlock_example2(void)
      Returns the address of hwspinlock on success, or NULL on error (e.g.
      if the hwspinlock is still in use).
 
+  int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				  const struct of_phandle_args *hwlock_spec);
+   - is a simple default OF translate helper function that can be plugged in
+     as the underlying vendor-specific implementation's of_xlate ops function.
+     This can be used by implementations that use a single integer argument in
+     the DT node argument specifier, that indicates the hwlock index number.
+     Returns a hwlock index within a bank, or appropriate error code on
+     failure.
+
+  int of_hwspin_lock_get_num_locks(struct device_node *dn);
+   - is a common OF helper function that can be used by some underlying
+     vendor-specific implementations. This can be used by implementations
+     that require and define the number of locks supported within a hwspinlock
+     bank as a device tree node property. This function should be called by
+     needed implementations before registering a hwspinlock device with the
+     core.
+
 5. Important structs
 
 struct hwspinlock_device is a device which usually contains a bank
@@ -288,12 +314,14 @@ initialized by the hwspinlock core itself.
 
 6. Implementation callbacks
 
-There are three possible callbacks defined in 'struct hwspinlock_ops':
+There are four possible callbacks defined in 'struct hwspinlock_ops':
 
 struct hwspinlock_ops {
 	int (*trylock)(struct hwspinlock *lock);
 	void (*unlock)(struct hwspinlock *lock);
 	void (*relax)(struct hwspinlock *lock);
+	int (*of_xlate)(struct hwspinlock_device *bank,
+			const struct of_phandle_args *hwlock_spec);
 };
 
 The first two callbacks are mandatory:
@@ -307,3 +335,7 @@ may _not_ sleep.
 The ->relax() callback is optional. It is called by hwspinlock core while
 spinning on a lock, and can be used by the underlying implementation to force
 a delay between two successive invocations of ->trylock(). It may _not_ sleep.
+
+The ->of_xlate() callback is mandatory to support requesting hwlocks through
+device-tree nodes. It is called by hwspinlock core to retrieve the relative
+lock index within a bank from the underlying implementation.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..3966c0c 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
 #include <linux/hwspinlock.h>
 #include <linux/pm_runtime.h>
 #include <linux/mutex.h>
+#include <linux/of.h>
 
 #include "hwspinlock_internal.h"
 
@@ -262,6 +263,33 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 }
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
+/**
+ * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the number of locks
+ * present within a hwspinlock device instance. The hwlock-num-locks
+ * DT property may be optional for some platforms, while mandatory for
+ * some others, so this function is typically called only by needed
+ * platform-specific implementations.
+ *
+ * Returns a positive number of locks on success, -ENODEV on generic
+ * failure or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_locks(struct device_node *dn)
+{
+	unsigned int val;
+	int ret = -ENODEV;
+
+	ret = of_property_read_u32(dn, "hwlock-num-locks", &val);
+	if (!ret)
+		ret = val ? val : -ENODEV;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_locks);
+
 static int hwspin_lock_register_single(struct hwspinlock *hwlock, int id)
 {
 	struct hwspinlock *tmp;
@@ -312,6 +340,31 @@ out:
 	return hwlock;
 }
 
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a negative value on error, and a relative index of the lock within
+ * a specified bank on success.
+ */
+int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				const struct of_phandle_args *hwlock_spec)
+{
+	/* sanity check (these shouldn't happen) */
+	if (WARN_ON(!bank->dev->of_node))
+		return -EINVAL;
+
+	if (WARN_ON(hwlock_spec->args_count != 1))
+		return -EINVAL;
+
+	return hwlock_spec->args[0];
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_simple_xlate);
+
 /*
  * Add a new hwspinlock device to the global list, keeping the list of
  * devices sorted by base order.
@@ -368,7 +421,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	int ret = 0, i;
 
 	if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-							!ops->unlock) {
+	    !ops->unlock || (dev->of_node && !ops->of_xlate)) {
 		pr_err("invalid parameters\n");
 		return -EINVAL;
 	}
@@ -592,6 +645,51 @@ out:
 EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
 
 /**
+ * of_hwspin_lock_request_specific() - request a OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @propname: property name containing hwlock specifier(s)
+ * @index: index of the hwlock
+ *
+ * This function is the OF equivalent of hwspin_lock_request_specific(). This
+ * function provides a means for users of the hwspinlock module to request a
+ * specific hwspinlock using the phandle of the hwspinlock device. The requested
+ * lock number is indexed relative to the hwspinlock device, unlike the
+ * hwspin_lock_request_specific() which is an absolute lock number.
+ *
+ * Returns the address of the assigned hwspinlock, or NULL on error
+ */
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index)
+{
+	struct hwspinlock_device *bank;
+	struct of_phandle_args args;
+	int id;
+	int ret;
+
+	ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
+					 &args);
+	if (ret)
+		return NULL;
+
+	mutex_lock(&hwspinlock_tree_lock);
+	list_for_each_entry(bank, &hwspinlock_devices, list)
+		if (bank->dev->of_node == args.np)
+			break;
+	mutex_unlock(&hwspinlock_tree_lock);
+	if (&bank->list == &hwspinlock_devices)
+		return NULL;
+
+	id = bank->ops->of_xlate(bank, &args);
+	if (id < 0 || id >= bank->num_locks)
+		return NULL;
+
+	id += bank->base_id;
+	return hwspin_lock_request_specific(id);
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_request_specific);
+
+/**
  * hwspin_lock_free() - free a specific hwspinlock
  * @hwlock: the specific hwspinlock to free
  *
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index aff560c..5e42613 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -32,11 +32,15 @@ struct hwspinlock_device;
  * @relax:   optional, platform-specific relax handler, called by hwspinlock
  *	     core while spinning on a lock, between two successive
  *	     invocations of @trylock. may _not_ sleep.
+ * @of_xlate: platform-specific hwlock specifier translate function, to
+ *	      return the relative index of the lock within a bank
  */
 struct hwspinlock_ops {
 	int (*trylock)(struct hwspinlock *lock);
 	void (*unlock)(struct hwspinlock *lock);
 	void (*relax)(struct hwspinlock *lock);
+	int (*of_xlate)(struct hwspinlock_device *bank,
+			const struct of_phandle_args *hwlock_spec);
 };
 
 /**
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 3343298..068e628 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -26,6 +26,8 @@
 #define HWLOCK_IRQ	0x02	/* Disable interrupts, don't save state */
 
 struct device;
+struct device_node;
+struct of_phandle_args;
 struct hwspinlock;
 struct hwspinlock_device;
 struct hwspinlock_ops;
@@ -60,11 +62,17 @@ struct hwspinlock_pdata {
 
 #if defined(CONFIG_HWSPINLOCK) || defined(CONFIG_HWSPINLOCK_MODULE)
 
+int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+				const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks);
 int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request(void);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index);
 int hwspin_lock_free(struct hwspinlock *hwlock);
 int hwspin_lock_get_id(struct hwspinlock *hwlock);
 int __hwspin_lock_timeout(struct hwspinlock *, unsigned int, int,
@@ -80,9 +88,9 @@ void __hwspin_unlock(struct hwspinlock *, int, unsigned long *);
  * code path get compiled away. This way, if CONFIG_HWSPINLOCK is not
  * required on a given setup, users will still work.
  *
- * The only exception is hwspin_lock_register/hwspin_lock_unregister, with which
- * we _do_ want users to fail (no point in registering hwspinlock instances if
- * the framework is not available).
+ * The only exception is hwspin_lock_register/hwspin_lock_unregister and
+ * associated OF helpers, with which we _do_ want users to fail (no point
+ * in registering hwspinlock instances if the framework is not available).
  *
  * Note: ERR_PTR(-ENODEV) will still be considered a success for NULL-checking
  * users. Others, which care, can still check this with IS_ERR.
@@ -97,6 +105,14 @@ static inline struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	return ERR_PTR(-ENODEV);
 }
 
+static inline
+struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
+						   const char *propname,
+						   int index)
+{
+	return ERR_PTR(-ENODEV);
+}
+
 static inline int hwspin_lock_free(struct hwspinlock *hwlock)
 {
 	return 0;
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.

Signed-off-by: Suman Anna <s-anna@ti.com>
[tony@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren <tony@atomide.com>
---
 MAINTAINERS                          |  1 -
 arch/arm/mach-omap2/Makefile         |  3 --
 arch/arm/mach-omap2/hwspinlock.c     | 60 ------------------------------------
 drivers/hwspinlock/omap_hwspinlock.c | 18 ++++++++---
 4 files changed, 14 insertions(+), 68 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..5147902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,7 +6355,6 @@ M:	Ohad Ben-Cohen <ohad@wizery.com>
 L:	linux-omap@vger.kernel.org
 S:	Maintained
 F:	drivers/hwspinlock/omap_hwspinlock.c
-F:	arch/arm/mach-omap2/hwspinlock.c
 
 OMAP MMC SUPPORT
 M:	Jarkko Lavinen <jarkko.lavinen@nokia.com>
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38..9f4b6dd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -289,9 +289,6 @@ obj-y					+= $(smc91x-m) $(smc91x-y)
 
 smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
 obj-y					+= $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y					+= hwspinlock.o
-endif
 
 emac-$(CONFIG_TI_DAVINCI_EMAC)		:= am35xx-emac.o
 obj-y					+= $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..0000000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que <sque@ti.com>
- *          Hari Kanigeri <h-kanigeri2@ti.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/err.h>
-#include <linux/hwspinlock.h>
-
-#include "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
-	.base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
-	int retval = 0;
-	struct omap_hwmod *oh;
-	struct platform_device *pdev;
-	const char *oh_name = "spinlock";
-	const char *dev_name = "omap_hwspinlock";
-
-	/*
-	 * Hwmod lookup will fail in case our platform doesn't support the
-	 * hardware spinlock module, so it is safe to run this initcall
-	 * on all omaps
-	 */
-	oh = omap_hwmod_lookup(oh_name);
-	if (oh == NULL)
-		return -EINVAL;
-
-	pdev = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
-				sizeof(struct hwspinlock_pdata));
-	if (IS_ERR(pdev)) {
-		pr_err("Can't build omap_device for %s:%s\n", dev_name,
-								oh_name);
-		retval = PTR_ERR(pdev);
-	}
-
-	return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..9f56fb2 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
 /*
  * OMAP hardware spinlock driver
  *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
  *
  * Contact: Simon Que <sque@ti.com>
  *          Hari Kanigeri <h-kanigeri2@ti.com>
@@ -27,6 +27,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/hwspinlock.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 
 #include "hwspinlock_internal.h"
@@ -76,18 +77,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
 	.trylock = omap_hwspinlock_trylock,
 	.unlock = omap_hwspinlock_unlock,
 	.relax = omap_hwspinlock_relax,
+	.of_xlate = of_hwspin_lock_simple_xlate,
 };
 
 static int omap_hwspinlock_probe(struct platform_device *pdev)
 {
-	struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
+	struct device_node *node = pdev->dev.of_node;
 	struct hwspinlock_device *bank;
 	struct hwspinlock *hwlock;
 	struct resource *res;
 	void __iomem *io_base;
 	int num_locks, i, ret;
+	int base_id = 0;
 
-	if (!pdata)
+	if (!node)
 		return -ENODEV;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -128,7 +131,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
-						pdata->base_id, num_locks);
+						base_id, num_locks);
 	if (ret)
 		goto reg_fail;
 
@@ -161,12 +164,19 @@ static int omap_hwspinlock_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_hwspinlock_of_match[] = {
+	{ .compatible = "ti,omap4-hwspinlock", },
+	{ /* end */ },
+};
+MODULE_DEVICE_TABLE(of, omap_hwspinlock_of_match);
+
 static struct platform_driver omap_hwspinlock_driver = {
 	.probe		= omap_hwspinlock_probe,
 	.remove		= omap_hwspinlock_remove,
 	.driver		= {
 		.name	= "omap_hwspinlock",
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(omap_hwspinlock_of_match),
 	},
 };
 
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.

Signed-off-by: Suman Anna <s-anna@ti.com>
[tony@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren <tony@atomide.com>
---
 MAINTAINERS                          |  1 -
 arch/arm/mach-omap2/Makefile         |  3 --
 arch/arm/mach-omap2/hwspinlock.c     | 60 ------------------------------------
 drivers/hwspinlock/omap_hwspinlock.c | 18 ++++++++---
 4 files changed, 14 insertions(+), 68 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..5147902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,7 +6355,6 @@ M:	Ohad Ben-Cohen <ohad@wizery.com>
 L:	linux-omap@vger.kernel.org
 S:	Maintained
 F:	drivers/hwspinlock/omap_hwspinlock.c
-F:	arch/arm/mach-omap2/hwspinlock.c
 
 OMAP MMC SUPPORT
 M:	Jarkko Lavinen <jarkko.lavinen@nokia.com>
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38..9f4b6dd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -289,9 +289,6 @@ obj-y					+= $(smc91x-m) $(smc91x-y)
 
 smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
 obj-y					+= $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y					+= hwspinlock.o
-endif
 
 emac-$(CONFIG_TI_DAVINCI_EMAC)		:= am35xx-emac.o
 obj-y					+= $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..0000000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que <sque@ti.com>
- *          Hari Kanigeri <h-kanigeri2@ti.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/err.h>
-#include <linux/hwspinlock.h>
-
-#include "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
-	.base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
-	int retval = 0;
-	struct omap_hwmod *oh;
-	struct platform_device *pdev;
-	const char *oh_name = "spinlock";
-	const char *dev_name = "omap_hwspinlock";
-
-	/*
-	 * Hwmod lookup will fail in case our platform doesn't support the
-	 * hardware spinlock module, so it is safe to run this initcall
-	 * on all omaps
-	 */
-	oh = omap_hwmod_lookup(oh_name);
-	if (oh == NULL)
-		return -EINVAL;
-
-	pdev = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
-				sizeof(struct hwspinlock_pdata));
-	if (IS_ERR(pdev)) {
-		pr_err("Can't build omap_device for %s:%s\n", dev_name,
-								oh_name);
-		retval = PTR_ERR(pdev);
-	}
-
-	return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..9f56fb2 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
 /*
  * OMAP hardware spinlock driver
  *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
  *
  * Contact: Simon Que <sque@ti.com>
  *          Hari Kanigeri <h-kanigeri2@ti.com>
@@ -27,6 +27,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/hwspinlock.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 
 #include "hwspinlock_internal.h"
@@ -76,18 +77,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
 	.trylock = omap_hwspinlock_trylock,
 	.unlock = omap_hwspinlock_unlock,
 	.relax = omap_hwspinlock_relax,
+	.of_xlate = of_hwspin_lock_simple_xlate,
 };
 
 static int omap_hwspinlock_probe(struct platform_device *pdev)
 {
-	struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
+	struct device_node *node = pdev->dev.of_node;
 	struct hwspinlock_device *bank;
 	struct hwspinlock *hwlock;
 	struct resource *res;
 	void __iomem *io_base;
 	int num_locks, i, ret;
+	int base_id = 0;
 
-	if (!pdata)
+	if (!node)
 		return -ENODEV;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -128,7 +131,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
-						pdata->base_id, num_locks);
+						base_id, num_locks);
 	if (ret)
 		goto reg_fail;
 
@@ -161,12 +164,19 @@ static int omap_hwspinlock_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_hwspinlock_of_match[] = {
+	{ .compatible = "ti,omap4-hwspinlock", },
+	{ /* end */ },
+};
+MODULE_DEVICE_TABLE(of, omap_hwspinlock_of_match);
+
 static struct platform_driver omap_hwspinlock_driver = {
 	.probe		= omap_hwspinlock_probe,
 	.remove		= omap_hwspinlock_remove,
 	.driver		= {
 		.name	= "omap_hwspinlock",
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(omap_hwspinlock_of_match),
 	},
 };
 
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.

Signed-off-by: Suman Anna <s-anna@ti.com>
[tony at atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren <tony@atomide.com>
---
 MAINTAINERS                          |  1 -
 arch/arm/mach-omap2/Makefile         |  3 --
 arch/arm/mach-omap2/hwspinlock.c     | 60 ------------------------------------
 drivers/hwspinlock/omap_hwspinlock.c | 18 ++++++++---
 4 files changed, 14 insertions(+), 68 deletions(-)
 delete mode 100644 arch/arm/mach-omap2/hwspinlock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index e67ea24..5147902 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6355,7 +6355,6 @@ M:	Ohad Ben-Cohen <ohad@wizery.com>
 L:	linux-omap at vger.kernel.org
 S:	Maintained
 F:	drivers/hwspinlock/omap_hwspinlock.c
-F:	arch/arm/mach-omap2/hwspinlock.c
 
 OMAP MMC SUPPORT
 M:	Jarkko Lavinen <jarkko.lavinen@nokia.com>
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8421f38..9f4b6dd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -289,9 +289,6 @@ obj-y					+= $(smc91x-m) $(smc91x-y)
 
 smsc911x-$(CONFIG_SMSC911X)		:= gpmc-smsc911x.o
 obj-y					+= $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y					+= hwspinlock.o
-endif
 
 emac-$(CONFIG_TI_DAVINCI_EMAC)		:= am35xx-emac.o
 obj-y					+= $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..0000000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que <sque@ti.com>
- *          Hari Kanigeri <h-kanigeri2@ti.com>
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
- * General Public License for more details.
- */
-
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/err.h>
-#include <linux/hwspinlock.h>
-
-#include "soc.h"
-#include "omap_hwmod.h"
-#include "omap_device.h"
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
-	.base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
-	int retval = 0;
-	struct omap_hwmod *oh;
-	struct platform_device *pdev;
-	const char *oh_name = "spinlock";
-	const char *dev_name = "omap_hwspinlock";
-
-	/*
-	 * Hwmod lookup will fail in case our platform doesn't support the
-	 * hardware spinlock module, so it is safe to run this initcall
-	 * on all omaps
-	 */
-	oh = omap_hwmod_lookup(oh_name);
-	if (oh == NULL)
-		return -EINVAL;
-
-	pdev = omap_device_build(dev_name, 0, oh, &omap_hwspinlock_pdata,
-				sizeof(struct hwspinlock_pdata));
-	if (IS_ERR(pdev)) {
-		pr_err("Can't build omap_device for %s:%s\n", dev_name,
-								oh_name);
-		retval = PTR_ERR(pdev);
-	}
-
-	return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 292869c..9f56fb2 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
 /*
  * OMAP hardware spinlock driver
  *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
  *
  * Contact: Simon Que <sque@ti.com>
  *          Hari Kanigeri <h-kanigeri2@ti.com>
@@ -27,6 +27,7 @@
 #include <linux/slab.h>
 #include <linux/spinlock.h>
 #include <linux/hwspinlock.h>
+#include <linux/of_device.h>
 #include <linux/platform_device.h>
 
 #include "hwspinlock_internal.h"
@@ -76,18 +77,20 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
 	.trylock = omap_hwspinlock_trylock,
 	.unlock = omap_hwspinlock_unlock,
 	.relax = omap_hwspinlock_relax,
+	.of_xlate = of_hwspin_lock_simple_xlate,
 };
 
 static int omap_hwspinlock_probe(struct platform_device *pdev)
 {
-	struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
+	struct device_node *node = pdev->dev.of_node;
 	struct hwspinlock_device *bank;
 	struct hwspinlock *hwlock;
 	struct resource *res;
 	void __iomem *io_base;
 	int num_locks, i, ret;
+	int base_id = 0;
 
-	if (!pdata)
+	if (!node)
 		return -ENODEV;
 
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -128,7 +131,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
-						pdata->base_id, num_locks);
+						base_id, num_locks);
 	if (ret)
 		goto reg_fail;
 
@@ -161,12 +164,19 @@ static int omap_hwspinlock_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id omap_hwspinlock_of_match[] = {
+	{ .compatible = "ti,omap4-hwspinlock", },
+	{ /* end */ },
+};
+MODULE_DEVICE_TABLE(of, omap_hwspinlock_of_match);
+
 static struct platform_driver omap_hwspinlock_driver = {
 	.probe		= omap_hwspinlock_probe,
 	.remove		= omap_hwspinlock_remove,
 	.driver		= {
 		.name	= "omap_hwspinlock",
 		.owner	= THIS_MODULE,
+		.of_match_table = of_match_ptr(omap_hwspinlock_of_match),
 	},
 };
 
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.

This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/omap_hwspinlock.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	if (!io_base)
 		return -ENOMEM;
 
+	/*
+	 * make sure the module is enabled and clocked before reading
+	 * the module SYSSTATUS register
+	 */
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(&pdev->dev);
+		goto iounmap_base;
+	}
+
 	/* Determine number of locks */
 	i = readl(io_base + SYSSTATUS_OFFSET);
 	i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET;
 
+	/*
+	 * runtime PM will make sure the clock of this module is
+	 * enabled again iff at least one lock is requested
+	 */
+	ret = pm_runtime_put_sync(&pdev->dev);
+	if (ret < 0)
+		goto iounmap_base;
+
 	/* one of the four lsb's must be set, and nothing else */
 	if (hweight_long(i & 0xf) != 1 || i > 8) {
 		ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
-	/*
-	 * runtime PM will make sure the clock of this module is
-	 * enabled iff at least one lock is requested
-	 */
-	pm_runtime_enable(&pdev->dev);
-
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
 						base_id, num_locks);
 	if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	return 0;
 
 reg_fail:
-	pm_runtime_disable(&pdev->dev);
 	kfree(bank);
 iounmap_base:
+	pm_runtime_disable(&pdev->dev);
 	iounmap(io_base);
 	return ret;
 }
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.

This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/omap_hwspinlock.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	if (!io_base)
 		return -ENOMEM;
 
+	/*
+	 * make sure the module is enabled and clocked before reading
+	 * the module SYSSTATUS register
+	 */
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(&pdev->dev);
+		goto iounmap_base;
+	}
+
 	/* Determine number of locks */
 	i = readl(io_base + SYSSTATUS_OFFSET);
 	i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET;
 
+	/*
+	 * runtime PM will make sure the clock of this module is
+	 * enabled again iff at least one lock is requested
+	 */
+	ret = pm_runtime_put_sync(&pdev->dev);
+	if (ret < 0)
+		goto iounmap_base;
+
 	/* one of the four lsb's must be set, and nothing else */
 	if (hweight_long(i & 0xf) != 1 || i > 8) {
 		ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
-	/*
-	 * runtime PM will make sure the clock of this module is
-	 * enabled iff at least one lock is requested
-	 */
-	pm_runtime_enable(&pdev->dev);
-
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
 						base_id, num_locks);
 	if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	return 0;
 
 reg_fail:
-	pm_runtime_disable(&pdev->dev);
 	kfree(bank);
 iounmap_base:
+	pm_runtime_disable(&pdev->dev);
 	iounmap(io_base);
 	return ret;
 }
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.

This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/omap_hwspinlock.c | 27 ++++++++++++++++++++-------
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 9f56fb2..7764291 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -101,10 +101,29 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	if (!io_base)
 		return -ENOMEM;
 
+	/*
+	 * make sure the module is enabled and clocked before reading
+	 * the module SYSSTATUS register
+	 */
+	pm_runtime_enable(&pdev->dev);
+	ret = pm_runtime_get_sync(&pdev->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(&pdev->dev);
+		goto iounmap_base;
+	}
+
 	/* Determine number of locks */
 	i = readl(io_base + SYSSTATUS_OFFSET);
 	i >>= SPINLOCK_NUMLOCKS_BIT_OFFSET;
 
+	/*
+	 * runtime PM will make sure the clock of this module is
+	 * enabled again iff at least one lock is requested
+	 */
+	ret = pm_runtime_put_sync(&pdev->dev);
+	if (ret < 0)
+		goto iounmap_base;
+
 	/* one of the four lsb's must be set, and nothing else */
 	if (hweight_long(i & 0xf) != 1 || i > 8) {
 		ret = -EINVAL;
@@ -124,12 +143,6 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
-	/*
-	 * runtime PM will make sure the clock of this module is
-	 * enabled iff at least one lock is requested
-	 */
-	pm_runtime_enable(&pdev->dev);
-
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
 						base_id, num_locks);
 	if (ret)
@@ -138,9 +151,9 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	return 0;
 
 reg_fail:
-	pm_runtime_disable(&pdev->dev);
 	kfree(bank);
 iounmap_base:
+	pm_runtime_disable(&pdev->dev);
 	iounmap(io_base);
 	return ret;
 }
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.

Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 70637d2..3612cb5 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers"
 
 config HWSPINLOCK_OMAP
 	tristate "OMAP Hardware Spinlock device"
-	depends on ARCH_OMAP4 || SOC_OMAP5
+	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX
 	select HWSPINLOCK
 	help
 	  Say y here to support the OMAP Hardware Spinlock device (firstly
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.

Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 70637d2..3612cb5 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers"
 
 config HWSPINLOCK_OMAP
 	tristate "OMAP Hardware Spinlock device"
-	depends on ARCH_OMAP4 || SOC_OMAP5
+	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX
 	select HWSPINLOCK
 	help
 	  Say y here to support the OMAP Hardware Spinlock device (firstly
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.

Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 70637d2..3612cb5 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers"
 
 config HWSPINLOCK_OMAP
 	tristate "OMAP Hardware Spinlock device"
-	depends on ARCH_OMAP4 || SOC_OMAP5
+	depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX
 	select HWSPINLOCK
 	help
 	  Say y here to support the OMAP Hardware Spinlock device (firstly
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The HwSpinlock core requires a base id for registering a bank
of hwspinlocks. This base id needs to be unique across multiple
IP instances of a hwspinlock device, so that each hwlock can be
represented uniquely in a system.

Support has been added to represent this in DT through a common
property 'hwlock-base-id', and retrieve the value through a core
OF helper function, of_hwspin_lock_get_base_id(). The representation
in DT provides a uniform way of assigning a fixed base value for a
hwspinlock device across different SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
 drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
 include/linux/hwspinlock.h                          |  1 +
 3 files changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index 32381cc..d538a9b 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,12 @@ Common properties:
 			property is needed on hwlock devices, where the number
 			of supported locks within a hwlock device cannot be
 			read from a register.
+- hwlock-base-id:	An unique base Id for the locks for a particular hwlock
+			device. This property is mandatory ONLY if a SoC has
+			several hwlock devices.
+
+			See documentation on struct hwspinlock_pdata in
+			include/linux/hwspinlock.h for more details.
 
 Hwlock Users:
 =============
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 3966c0c..4be1664 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -264,6 +264,27 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
 /**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, or an appropriate error code
+ * as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+	unsigned int val;
+	int ret;
+
+	ret = of_property_read_u32(dn, "hwlock-base-id", &val);
+	return ret ? ret : val;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 068e628..4857728 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -64,6 +64,7 @@ struct hwspinlock_pdata {
 
 int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 				const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks);
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The HwSpinlock core requires a base id for registering a bank
of hwspinlocks. This base id needs to be unique across multiple
IP instances of a hwspinlock device, so that each hwlock can be
represented uniquely in a system.

Support has been added to represent this in DT through a common
property 'hwlock-base-id', and retrieve the value through a core
OF helper function, of_hwspin_lock_get_base_id(). The representation
in DT provides a uniform way of assigning a fixed base value for a
hwspinlock device across different SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
 drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
 include/linux/hwspinlock.h                          |  1 +
 3 files changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index 32381cc..d538a9b 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,12 @@ Common properties:
 			property is needed on hwlock devices, where the number
 			of supported locks within a hwlock device cannot be
 			read from a register.
+- hwlock-base-id:	An unique base Id for the locks for a particular hwlock
+			device. This property is mandatory ONLY if a SoC has
+			several hwlock devices.
+
+			See documentation on struct hwspinlock_pdata in
+			include/linux/hwspinlock.h for more details.
 
 Hwlock Users:
 =============
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 3966c0c..4be1664 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -264,6 +264,27 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
 /**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, or an appropriate error code
+ * as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+	unsigned int val;
+	int ret;
+
+	ret = of_property_read_u32(dn, "hwlock-base-id", &val);
+	return ret ? ret : val;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 068e628..4857728 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -64,6 +64,7 @@ struct hwspinlock_pdata {
 
 int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 				const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The HwSpinlock core requires a base id for registering a bank
of hwspinlocks. This base id needs to be unique across multiple
IP instances of a hwspinlock device, so that each hwlock can be
represented uniquely in a system.

Support has been added to represent this in DT through a common
property 'hwlock-base-id', and retrieve the value through a core
OF helper function, of_hwspin_lock_get_base_id(). The representation
in DT provides a uniform way of assigning a fixed base value for a
hwspinlock device across different SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
 drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
 include/linux/hwspinlock.h                          |  1 +
 3 files changed, 28 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index 32381cc..d538a9b 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,12 @@ Common properties:
 			property is needed on hwlock devices, where the number
 			of supported locks within a hwlock device cannot be
 			read from a register.
+- hwlock-base-id:	An unique base Id for the locks for a particular hwlock
+			device. This property is mandatory ONLY if a SoC has
+			several hwlock devices.
+
+			See documentation on struct hwspinlock_pdata in
+			include/linux/hwspinlock.h for more details.
 
 Hwlock Users:
 =============
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 3966c0c..4be1664 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -264,6 +264,27 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 EXPORT_SYMBOL_GPL(__hwspin_unlock);
 
 /**
+ * of_hwspin_lock_get_base_id() - OF helper to retrieve base id
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying
+ * platform-specific implementations, to retrieve the base id for the
+ * set of locks present within a hwspinlock device instance.
+ *
+ * Returns the base id value on success, or an appropriate error code
+ * as returned by the OF layer
+ */
+int of_hwspin_lock_get_base_id(struct device_node *dn)
+{
+	unsigned int val;
+	int ret;
+
+	ret = of_property_read_u32(dn, "hwlock-base-id", &val);
+	return ret ? ret : val;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 068e628..4857728 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -64,6 +64,7 @@ struct hwspinlock_pdata {
 
 int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 				const struct of_phandle_args *hwlock_spec);
+int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c | 37 +++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 4be1664..ed47e77 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -336,29 +336,33 @@ out:
 	return 0;
 }
 
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 {
-	struct hwspinlock *hwlock = NULL;
-	int ret;
+	struct hwspinlock *tmp = NULL;
+	int ret = 0;
 
 	mutex_lock(&hwspinlock_tree_lock);
 
 	/* make sure the hwspinlock is not in use (tag is set) */
-	ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
-	if (ret == 0) {
+	if (!radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
 		pr_err("hwspinlock %d still in use (or not present)\n", id);
+		ret = -EBUSY;
 		goto out;
 	}
 
-	hwlock = radix_tree_delete(&hwspinlock_tree, id);
-	if (!hwlock) {
+	tmp = radix_tree_delete(&hwspinlock_tree, id);
+	if (!tmp) {
 		pr_err("failed to delete hwspinlock %d\n", id);
+		ret = -EIO;
 		goto out;
 	}
 
+	/* self-sanity check that should never fail */
+	WARN_ON(tmp != hwlock);
+
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
-	return hwlock;
+	return ret;
 }
 
 /**
@@ -472,8 +476,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	return 0;
 
 reg_failed:
-	while (--i >= 0)
-		hwspin_lock_unregister_single(base_id + i);
+	while (--i >= 0) {
+		hwlock =  &bank->lock[i];
+		hwspin_lock_unregister_single(hwlock, base_id + i);
+	}
 	mutex_lock(&hwspinlock_tree_lock);
 	list_del(&bank->list);
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -494,18 +500,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
  */
 int hwspin_lock_unregister(struct hwspinlock_device *bank)
 {
-	struct hwspinlock *hwlock, *tmp;
-	int i;
+	struct hwspinlock *hwlock;
+	int i, ret;
 
 	for (i = 0; i < bank->num_locks; i++) {
 		hwlock = &bank->lock[i];
 
-		tmp = hwspin_lock_unregister_single(bank->base_id + i);
-		if (!tmp)
+		ret = hwspin_lock_unregister_single(hwlock, bank->base_id + i);
+		if (ret)
 			return -EBUSY;
-
-		/* self-sanity check that should never fail */
-		WARN_ON(tmp != hwlock);
 	}
 
 	mutex_lock(&hwspinlock_tree_lock);
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c | 37 +++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 4be1664..ed47e77 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -336,29 +336,33 @@ out:
 	return 0;
 }
 
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 {
-	struct hwspinlock *hwlock = NULL;
-	int ret;
+	struct hwspinlock *tmp = NULL;
+	int ret = 0;
 
 	mutex_lock(&hwspinlock_tree_lock);
 
 	/* make sure the hwspinlock is not in use (tag is set) */
-	ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
-	if (ret == 0) {
+	if (!radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
 		pr_err("hwspinlock %d still in use (or not present)\n", id);
+		ret = -EBUSY;
 		goto out;
 	}
 
-	hwlock = radix_tree_delete(&hwspinlock_tree, id);
-	if (!hwlock) {
+	tmp = radix_tree_delete(&hwspinlock_tree, id);
+	if (!tmp) {
 		pr_err("failed to delete hwspinlock %d\n", id);
+		ret = -EIO;
 		goto out;
 	}
 
+	/* self-sanity check that should never fail */
+	WARN_ON(tmp != hwlock);
+
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
-	return hwlock;
+	return ret;
 }
 
 /**
@@ -472,8 +476,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	return 0;
 
 reg_failed:
-	while (--i >= 0)
-		hwspin_lock_unregister_single(base_id + i);
+	while (--i >= 0) {
+		hwlock =  &bank->lock[i];
+		hwspin_lock_unregister_single(hwlock, base_id + i);
+	}
 	mutex_lock(&hwspinlock_tree_lock);
 	list_del(&bank->list);
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -494,18 +500,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
  */
 int hwspin_lock_unregister(struct hwspinlock_device *bank)
 {
-	struct hwspinlock *hwlock, *tmp;
-	int i;
+	struct hwspinlock *hwlock;
+	int i, ret;
 
 	for (i = 0; i < bank->num_locks; i++) {
 		hwlock = &bank->lock[i];
 
-		tmp = hwspin_lock_unregister_single(bank->base_id + i);
-		if (!tmp)
+		ret = hwspin_lock_unregister_single(hwlock, bank->base_id + i);
+		if (ret)
 			return -EBUSY;
-
-		/* self-sanity check that should never fail */
-		WARN_ON(tmp != hwlock);
 	}
 
 	mutex_lock(&hwspinlock_tree_lock);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c | 37 +++++++++++++++++++-----------------
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 4be1664..ed47e77 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -336,29 +336,33 @@ out:
 	return 0;
 }
 
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 {
-	struct hwspinlock *hwlock = NULL;
-	int ret;
+	struct hwspinlock *tmp = NULL;
+	int ret = 0;
 
 	mutex_lock(&hwspinlock_tree_lock);
 
 	/* make sure the hwspinlock is not in use (tag is set) */
-	ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
-	if (ret == 0) {
+	if (!radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
 		pr_err("hwspinlock %d still in use (or not present)\n", id);
+		ret = -EBUSY;
 		goto out;
 	}
 
-	hwlock = radix_tree_delete(&hwspinlock_tree, id);
-	if (!hwlock) {
+	tmp = radix_tree_delete(&hwspinlock_tree, id);
+	if (!tmp) {
 		pr_err("failed to delete hwspinlock %d\n", id);
+		ret = -EIO;
 		goto out;
 	}
 
+	/* self-sanity check that should never fail */
+	WARN_ON(tmp != hwlock);
+
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
-	return hwlock;
+	return ret;
 }
 
 /**
@@ -472,8 +476,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	return 0;
 
 reg_failed:
-	while (--i >= 0)
-		hwspin_lock_unregister_single(base_id + i);
+	while (--i >= 0) {
+		hwlock =  &bank->lock[i];
+		hwspin_lock_unregister_single(hwlock, base_id + i);
+	}
 	mutex_lock(&hwspinlock_tree_lock);
 	list_del(&bank->list);
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -494,18 +500,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
  */
 int hwspin_lock_unregister(struct hwspinlock_device *bank)
 {
-	struct hwspinlock *hwlock, *tmp;
-	int i;
+	struct hwspinlock *hwlock;
+	int i, ret;
 
 	for (i = 0; i < bank->num_locks; i++) {
 		hwlock = &bank->lock[i];
 
-		tmp = hwspin_lock_unregister_single(bank->base_id + i);
-		if (!tmp)
+		ret = hwspin_lock_unregister_single(hwlock, bank->base_id + i);
+		if (ret)
 			return -EBUSY;
-
-		/* self-sanity check that should never fail */
-		WARN_ON(tmp != hwlock);
 	}
 
 	mutex_lock(&hwspinlock_tree_lock);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 10/15] hwspinlock/core: prepare core to support reserved locks
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.

This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwlock to
identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() variants or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c     | 14 ++++++++------
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index ed47e77..c2063bc 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
 
 /* radix tree tags */
 #define HWSPINLOCK_UNUSED	(0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED	(1) /* tags an hwspinlock as reserved */
 
 /*
  * A radix tree is used to maintain the available hwspinlock instances.
@@ -326,7 +327,7 @@ static int hwspin_lock_register_single(struct hwspinlock *hwlock, int id)
 	}
 
 	/* mark this hwspinlock as available */
-	tmp = radix_tree_tag_set(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+	tmp = radix_tree_tag_set(&hwspinlock_tree, id, hwlock->type);
 
 	/* self-sanity check which should never fail */
 	WARN_ON(tmp != hwlock);
@@ -344,7 +345,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 	mutex_lock(&hwspinlock_tree_lock);
 
 	/* make sure the hwspinlock is not in use (tag is set) */
-	if (!radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
+	if (!radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type)) {
 		pr_err("hwspinlock %d still in use (or not present)\n", id);
 		ret = -EBUSY;
 		goto out;
@@ -467,6 +468,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 
 		spin_lock_init(&hwlock->lock);
 		hwlock->bank = bank;
+		hwlock->type = HWSPINLOCK_UNUSED;
 
 		ret = hwspin_lock_register_single(hwlock, base_id + i);
 		if (ret)
@@ -551,7 +553,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
 
 	/* mark hwspinlock as used, should not fail */
 	tmp = radix_tree_tag_clear(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 
 	/* self-sanity check that should never fail */
 	WARN_ON(tmp != hwlock);
@@ -650,7 +652,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	WARN_ON(hwlock_to_id(hwlock) != id);
 
 	/* make sure this hwspinlock is unused */
-	ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
 		hwlock = NULL;
@@ -741,7 +743,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
 	/* make sure the hwspinlock is used */
 	ret = radix_tree_tag_get(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 	if (ret == 1) {
 		dev_err(dev, "%s: hwlock is already free\n", __func__);
 		dump_stack();
@@ -756,7 +758,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
 	/* mark this hwspinlock as available */
 	tmp = radix_tree_tag_set(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 
 	/* sanity check (this shouldn't happen) */
 	WARN_ON(tmp != hwlock);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index 5e42613..1be32ca 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -47,11 +47,13 @@ struct hwspinlock_ops {
  * struct hwspinlock - this struct represents a single hwspinlock instance
  * @bank: the hwspinlock_device structure which owns this lock
  * @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
  * @priv: private data, owned by the underlying platform-specific hwspinlock drv
  */
 struct hwspinlock {
 	struct hwspinlock_device *bank;
 	spinlock_t lock;
+	unsigned int type;
 	void *priv;
 };
 
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 10/15] hwspinlock/core: prepare core to support reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.

This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwlock to
identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() variants or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c     | 14 ++++++++------
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index ed47e77..c2063bc 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
 
 /* radix tree tags */
 #define HWSPINLOCK_UNUSED	(0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED	(1) /* tags an hwspinlock as reserved */
 
 /*
  * A radix tree is used to maintain the available hwspinlock instances.
@@ -326,7 +327,7 @@ static int hwspin_lock_register_single(struct hwspinlock *hwlock, int id)
 	}
 
 	/* mark this hwspinlock as available */
-	tmp = radix_tree_tag_set(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+	tmp = radix_tree_tag_set(&hwspinlock_tree, id, hwlock->type);
 
 	/* self-sanity check which should never fail */
 	WARN_ON(tmp != hwlock);
@@ -344,7 +345,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 	mutex_lock(&hwspinlock_tree_lock);
 
 	/* make sure the hwspinlock is not in use (tag is set) */
-	if (!radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
+	if (!radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type)) {
 		pr_err("hwspinlock %d still in use (or not present)\n", id);
 		ret = -EBUSY;
 		goto out;
@@ -467,6 +468,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 
 		spin_lock_init(&hwlock->lock);
 		hwlock->bank = bank;
+		hwlock->type = HWSPINLOCK_UNUSED;
 
 		ret = hwspin_lock_register_single(hwlock, base_id + i);
 		if (ret)
@@ -551,7 +553,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
 
 	/* mark hwspinlock as used, should not fail */
 	tmp = radix_tree_tag_clear(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 
 	/* self-sanity check that should never fail */
 	WARN_ON(tmp != hwlock);
@@ -650,7 +652,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	WARN_ON(hwlock_to_id(hwlock) != id);
 
 	/* make sure this hwspinlock is unused */
-	ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
 		hwlock = NULL;
@@ -741,7 +743,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
 	/* make sure the hwspinlock is used */
 	ret = radix_tree_tag_get(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 	if (ret == 1) {
 		dev_err(dev, "%s: hwlock is already free\n", __func__);
 		dump_stack();
@@ -756,7 +758,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
 	/* mark this hwspinlock as available */
 	tmp = radix_tree_tag_set(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 
 	/* sanity check (this shouldn't happen) */
 	WARN_ON(tmp != hwlock);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index 5e42613..1be32ca 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -47,11 +47,13 @@ struct hwspinlock_ops {
  * struct hwspinlock - this struct represents a single hwspinlock instance
  * @bank: the hwspinlock_device structure which owns this lock
  * @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
  * @priv: private data, owned by the underlying platform-specific hwspinlock drv
  */
 struct hwspinlock {
 	struct hwspinlock_device *bank;
 	spinlock_t lock;
+	unsigned int type;
 	void *priv;
 };
 
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 10/15] hwspinlock/core: prepare core to support reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.

This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwlock to
identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() variants or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c     | 14 ++++++++------
 drivers/hwspinlock/hwspinlock_internal.h |  2 ++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index ed47e77..c2063bc 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
 
 /* radix tree tags */
 #define HWSPINLOCK_UNUSED	(0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED	(1) /* tags an hwspinlock as reserved */
 
 /*
  * A radix tree is used to maintain the available hwspinlock instances.
@@ -326,7 +327,7 @@ static int hwspin_lock_register_single(struct hwspinlock *hwlock, int id)
 	}
 
 	/* mark this hwspinlock as available */
-	tmp = radix_tree_tag_set(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+	tmp = radix_tree_tag_set(&hwspinlock_tree, id, hwlock->type);
 
 	/* self-sanity check which should never fail */
 	WARN_ON(tmp != hwlock);
@@ -344,7 +345,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
 	mutex_lock(&hwspinlock_tree_lock);
 
 	/* make sure the hwspinlock is not in use (tag is set) */
-	if (!radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
+	if (!radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type)) {
 		pr_err("hwspinlock %d still in use (or not present)\n", id);
 		ret = -EBUSY;
 		goto out;
@@ -467,6 +468,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 
 		spin_lock_init(&hwlock->lock);
 		hwlock->bank = bank;
+		hwlock->type = HWSPINLOCK_UNUSED;
 
 		ret = hwspin_lock_register_single(hwlock, base_id + i);
 		if (ret)
@@ -551,7 +553,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
 
 	/* mark hwspinlock as used, should not fail */
 	tmp = radix_tree_tag_clear(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 
 	/* self-sanity check that should never fail */
 	WARN_ON(tmp != hwlock);
@@ -650,7 +652,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	WARN_ON(hwlock_to_id(hwlock) != id);
 
 	/* make sure this hwspinlock is unused */
-	ret = radix_tree_tag_get(&hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
 		hwlock = NULL;
@@ -741,7 +743,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
 	/* make sure the hwspinlock is used */
 	ret = radix_tree_tag_get(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 	if (ret == 1) {
 		dev_err(dev, "%s: hwlock is already free\n", __func__);
 		dump_stack();
@@ -756,7 +758,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 
 	/* mark this hwspinlock as available */
 	tmp = radix_tree_tag_set(&hwspinlock_tree, hwlock_to_id(hwlock),
-							HWSPINLOCK_UNUSED);
+							hwlock->type);
 
 	/* sanity check (this shouldn't happen) */
 	WARN_ON(tmp != hwlock);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index 5e42613..1be32ca 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -47,11 +47,13 @@ struct hwspinlock_ops {
  * struct hwspinlock - this struct represents a single hwspinlock instance
  * @bank: the hwspinlock_device structure which owns this lock
  * @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
  * @priv: private data, owned by the underlying platform-specific hwspinlock drv
  */
 struct hwspinlock {
 	struct hwspinlock_device *bank;
 	spinlock_t lock;
+	unsigned int type;
 	void *priv;
 };
 
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 11/15] hwspinlock/core: add support for reserved locks
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to:
  1. allow the platform implementations to register a set of 'reserved'
     locks
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks
  3. limit these reserved locks to be allocated only using the
     _request_specific() API variants.

The existing platform implementations have also been updated to adjust
for the change of the registration API.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c     | 20 ++++++++++++++++----
 drivers/hwspinlock/hwspinlock_internal.h |  3 +++
 drivers/hwspinlock/omap_hwspinlock.c     |  4 ++--
 drivers/hwspinlock/u8500_hsem.c          |  3 ++-
 include/linux/hwspinlock.h               | 10 +++++++---
 5 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..e05cea8 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -432,6 +432,8 @@ static int hwspinlock_device_add(struct hwspinlock_device *bank)
  * @ops: hwspinlock handlers for this device
  * @base_id: id of the first hardware spinlock in this bank
  * @num_locks: number of hwspinlocks provided by this device
+ * @num_reserved_locks: number of reserved hwspinlocks starting from @base_id
+ *			on this device
  *
  * This function should be called from the underlying platform-specific
  * implementation, to register a new hwspinlock device instance.
@@ -441,13 +443,15 @@ static int hwspinlock_device_add(struct hwspinlock_device *bank)
  * Returns 0 on success, or an appropriate error code on failure
  */
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks)
+		const struct hwspinlock_ops *ops, int base_id, int num_locks,
+		int num_reserved_locks)
 {
 	struct hwspinlock *hwlock;
 	int ret = 0, i;
 
 	if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-	    !ops->unlock || (dev->of_node && !ops->of_xlate)) {
+	    !ops->unlock || (dev->of_node && !ops->of_xlate) ||
+	    (num_locks < num_reserved_locks)) {
 		pr_err("invalid parameters\n");
 		return -EINVAL;
 	}
@@ -456,6 +460,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	bank->ops = ops;
 	bank->base_id = base_id;
 	bank->num_locks = num_locks;
+	bank->num_reserved_locks = num_reserved_locks;
 
 	mutex_lock(&hwspinlock_tree_lock);
 	ret = hwspinlock_device_add(bank);
@@ -468,7 +473,8 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 
 		spin_lock_init(&hwlock->lock);
 		hwlock->bank = bank;
-		hwlock->type = HWSPINLOCK_UNUSED;
+		hwlock->type = (i < num_reserved_locks ?
+				HWSPINLOCK_RESERVED : HWSPINLOCK_UNUSED);
 
 		ret = hwspin_lock_register_single(hwlock, base_id + i);
 		if (ret)
@@ -651,7 +657,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	/* sanity check (this shouldn't happen) */
 	WARN_ON(hwlock_to_id(hwlock) != id);
 
-	/* make sure this hwspinlock is unused */
+	if (hwlock->type != HWSPINLOCK_RESERVED) {
+		pr_warn("hwspinlock %u is not a reserved lock\n", id);
+		hwlock = NULL;
+		goto out;
+	}
+
+	/* make sure this hwspinlock is an unused reserved lock */
 	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index 1be32ca..570e876 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -64,6 +64,8 @@ struct hwspinlock {
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
  * @num_locks: number of locks in this device
+ * @num_reserved_locks: number of reserved locks in this device starting
+ *			from @base_id
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
@@ -72,6 +74,7 @@ struct hwspinlock_device {
 	const struct hwspinlock_ops *ops;
 	int base_id;
 	int num_locks;
+	int num_reserved_locks;
 	struct hwspinlock lock[0];
 };
 
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 7764291..1d0c78e 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -88,7 +88,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	struct resource *res;
 	void __iomem *io_base;
 	int num_locks, i, ret;
-	int base_id = 0;
+	int base_id = 0, reserved_locks = 0;
 
 	if (!node)
 		return -ENODEV;
@@ -144,7 +144,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
-						base_id, num_locks);
+					base_id, num_locks, reserved_locks);
 	if (ret)
 		goto reg_fail;
 
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 401c33b..2b4f001 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -134,7 +134,8 @@ static int u8500_hsem_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &u8500_hwspinlock_ops,
-						pdata->base_id, num_locks);
+					pdata->base_id, num_locks,
+					pdata->num_reserved_locks);
 	if (ret)
 		goto reg_fail;
 
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 4857728..d120035 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -35,6 +35,7 @@ struct hwspinlock_ops;
 /**
  * struct hwspinlock_pdata - platform data for hwspinlock drivers
  * @base_id: base id for this hwspinlock device
+ * @num_reserved_locks: number of reserved locks starting from @base_id
  *
  * hwspinlock devices provide system-wide hardware locks that are used
  * by remote processors that have no other way to achieve synchronization.
@@ -53,11 +54,13 @@ struct hwspinlock_ops;
  *
  * This platform data structure should be used to provide the base id
  * for each device (which is trivially 0 when only a single hwspinlock
- * device exists). It can be shared between different platforms, hence
- * its location.
+ * device exists). It should also be used to provide the number of reserved
+ * locks for non-DT based devices. It can be shared between different
+ * platforms, hence its location.
  */
 struct hwspinlock_pdata {
 	int base_id;
+	int num_reserved_locks;
 };
 
 #if defined(CONFIG_HWSPINLOCK) || defined(CONFIG_HWSPINLOCK_MODULE)
@@ -67,7 +70,8 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks);
+		const struct hwspinlock_ops *ops, int base_id, int num_locks,
+		int num_reserved_locks);
 int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request(void);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 11/15] hwspinlock/core: add support for reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to:
  1. allow the platform implementations to register a set of 'reserved'
     locks
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks
  3. limit these reserved locks to be allocated only using the
     _request_specific() API variants.

The existing platform implementations have also been updated to adjust
for the change of the registration API.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c     | 20 ++++++++++++++++----
 drivers/hwspinlock/hwspinlock_internal.h |  3 +++
 drivers/hwspinlock/omap_hwspinlock.c     |  4 ++--
 drivers/hwspinlock/u8500_hsem.c          |  3 ++-
 include/linux/hwspinlock.h               | 10 +++++++---
 5 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..e05cea8 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -432,6 +432,8 @@ static int hwspinlock_device_add(struct hwspinlock_device *bank)
  * @ops: hwspinlock handlers for this device
  * @base_id: id of the first hardware spinlock in this bank
  * @num_locks: number of hwspinlocks provided by this device
+ * @num_reserved_locks: number of reserved hwspinlocks starting from @base_id
+ *			on this device
  *
  * This function should be called from the underlying platform-specific
  * implementation, to register a new hwspinlock device instance.
@@ -441,13 +443,15 @@ static int hwspinlock_device_add(struct hwspinlock_device *bank)
  * Returns 0 on success, or an appropriate error code on failure
  */
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks)
+		const struct hwspinlock_ops *ops, int base_id, int num_locks,
+		int num_reserved_locks)
 {
 	struct hwspinlock *hwlock;
 	int ret = 0, i;
 
 	if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-	    !ops->unlock || (dev->of_node && !ops->of_xlate)) {
+	    !ops->unlock || (dev->of_node && !ops->of_xlate) ||
+	    (num_locks < num_reserved_locks)) {
 		pr_err("invalid parameters\n");
 		return -EINVAL;
 	}
@@ -456,6 +460,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	bank->ops = ops;
 	bank->base_id = base_id;
 	bank->num_locks = num_locks;
+	bank->num_reserved_locks = num_reserved_locks;
 
 	mutex_lock(&hwspinlock_tree_lock);
 	ret = hwspinlock_device_add(bank);
@@ -468,7 +473,8 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 
 		spin_lock_init(&hwlock->lock);
 		hwlock->bank = bank;
-		hwlock->type = HWSPINLOCK_UNUSED;
+		hwlock->type = (i < num_reserved_locks ?
+				HWSPINLOCK_RESERVED : HWSPINLOCK_UNUSED);
 
 		ret = hwspin_lock_register_single(hwlock, base_id + i);
 		if (ret)
@@ -651,7 +657,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	/* sanity check (this shouldn't happen) */
 	WARN_ON(hwlock_to_id(hwlock) != id);
 
-	/* make sure this hwspinlock is unused */
+	if (hwlock->type != HWSPINLOCK_RESERVED) {
+		pr_warn("hwspinlock %u is not a reserved lock\n", id);
+		hwlock = NULL;
+		goto out;
+	}
+
+	/* make sure this hwspinlock is an unused reserved lock */
 	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index 1be32ca..570e876 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -64,6 +64,8 @@ struct hwspinlock {
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
  * @num_locks: number of locks in this device
+ * @num_reserved_locks: number of reserved locks in this device starting
+ *			from @base_id
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
@@ -72,6 +74,7 @@ struct hwspinlock_device {
 	const struct hwspinlock_ops *ops;
 	int base_id;
 	int num_locks;
+	int num_reserved_locks;
 	struct hwspinlock lock[0];
 };
 
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 7764291..1d0c78e 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -88,7 +88,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	struct resource *res;
 	void __iomem *io_base;
 	int num_locks, i, ret;
-	int base_id = 0;
+	int base_id = 0, reserved_locks = 0;
 
 	if (!node)
 		return -ENODEV;
@@ -144,7 +144,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
-						base_id, num_locks);
+					base_id, num_locks, reserved_locks);
 	if (ret)
 		goto reg_fail;
 
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 401c33b..2b4f001 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -134,7 +134,8 @@ static int u8500_hsem_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &u8500_hwspinlock_ops,
-						pdata->base_id, num_locks);
+					pdata->base_id, num_locks,
+					pdata->num_reserved_locks);
 	if (ret)
 		goto reg_fail;
 
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 4857728..d120035 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -35,6 +35,7 @@ struct hwspinlock_ops;
 /**
  * struct hwspinlock_pdata - platform data for hwspinlock drivers
  * @base_id: base id for this hwspinlock device
+ * @num_reserved_locks: number of reserved locks starting from @base_id
  *
  * hwspinlock devices provide system-wide hardware locks that are used
  * by remote processors that have no other way to achieve synchronization.
@@ -53,11 +54,13 @@ struct hwspinlock_ops;
  *
  * This platform data structure should be used to provide the base id
  * for each device (which is trivially 0 when only a single hwspinlock
- * device exists). It can be shared between different platforms, hence
- * its location.
+ * device exists). It should also be used to provide the number of reserved
+ * locks for non-DT based devices. It can be shared between different
+ * platforms, hence its location.
  */
 struct hwspinlock_pdata {
 	int base_id;
+	int num_reserved_locks;
 };
 
 #if defined(CONFIG_HWSPINLOCK) || defined(CONFIG_HWSPINLOCK_MODULE)
@@ -67,7 +70,8 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks);
+		const struct hwspinlock_ops *ops, int base_id, int num_locks,
+		int num_reserved_locks);
 int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request(void);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 11/15] hwspinlock/core: add support for reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to:
  1. allow the platform implementations to register a set of 'reserved'
     locks
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks
  3. limit these reserved locks to be allocated only using the
     _request_specific() API variants.

The existing platform implementations have also been updated to adjust
for the change of the registration API.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c     | 20 ++++++++++++++++----
 drivers/hwspinlock/hwspinlock_internal.h |  3 +++
 drivers/hwspinlock/omap_hwspinlock.c     |  4 ++--
 drivers/hwspinlock/u8500_hsem.c          |  3 ++-
 include/linux/hwspinlock.h               | 10 +++++++---
 5 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..e05cea8 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -432,6 +432,8 @@ static int hwspinlock_device_add(struct hwspinlock_device *bank)
  * @ops: hwspinlock handlers for this device
  * @base_id: id of the first hardware spinlock in this bank
  * @num_locks: number of hwspinlocks provided by this device
+ * @num_reserved_locks: number of reserved hwspinlocks starting from @base_id
+ *			on this device
  *
  * This function should be called from the underlying platform-specific
  * implementation, to register a new hwspinlock device instance.
@@ -441,13 +443,15 @@ static int hwspinlock_device_add(struct hwspinlock_device *bank)
  * Returns 0 on success, or an appropriate error code on failure
  */
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks)
+		const struct hwspinlock_ops *ops, int base_id, int num_locks,
+		int num_reserved_locks)
 {
 	struct hwspinlock *hwlock;
 	int ret = 0, i;
 
 	if (!bank || !ops || !dev || !num_locks || !ops->trylock ||
-	    !ops->unlock || (dev->of_node && !ops->of_xlate)) {
+	    !ops->unlock || (dev->of_node && !ops->of_xlate) ||
+	    (num_locks < num_reserved_locks)) {
 		pr_err("invalid parameters\n");
 		return -EINVAL;
 	}
@@ -456,6 +460,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 	bank->ops = ops;
 	bank->base_id = base_id;
 	bank->num_locks = num_locks;
+	bank->num_reserved_locks = num_reserved_locks;
 
 	mutex_lock(&hwspinlock_tree_lock);
 	ret = hwspinlock_device_add(bank);
@@ -468,7 +473,8 @@ int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 
 		spin_lock_init(&hwlock->lock);
 		hwlock->bank = bank;
-		hwlock->type = HWSPINLOCK_UNUSED;
+		hwlock->type = (i < num_reserved_locks ?
+				HWSPINLOCK_RESERVED : HWSPINLOCK_UNUSED);
 
 		ret = hwspin_lock_register_single(hwlock, base_id + i);
 		if (ret)
@@ -651,7 +657,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	/* sanity check (this shouldn't happen) */
 	WARN_ON(hwlock_to_id(hwlock) != id);
 
-	/* make sure this hwspinlock is unused */
+	if (hwlock->type != HWSPINLOCK_RESERVED) {
+		pr_warn("hwspinlock %u is not a reserved lock\n", id);
+		hwlock = NULL;
+		goto out;
+	}
+
+	/* make sure this hwspinlock is an unused reserved lock */
 	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
diff --git a/drivers/hwspinlock/hwspinlock_internal.h b/drivers/hwspinlock/hwspinlock_internal.h
index 1be32ca..570e876 100644
--- a/drivers/hwspinlock/hwspinlock_internal.h
+++ b/drivers/hwspinlock/hwspinlock_internal.h
@@ -64,6 +64,8 @@ struct hwspinlock {
  * @ops: platform-specific hwspinlock handlers
  * @base_id: id index of the first lock in this device
  * @num_locks: number of locks in this device
+ * @num_reserved_locks: number of reserved locks in this device starting
+ *			from @base_id
  * @lock: dynamically allocated array of 'struct hwspinlock'
  */
 struct hwspinlock_device {
@@ -72,6 +74,7 @@ struct hwspinlock_device {
 	const struct hwspinlock_ops *ops;
 	int base_id;
 	int num_locks;
+	int num_reserved_locks;
 	struct hwspinlock lock[0];
 };
 
diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 7764291..1d0c78e 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -88,7 +88,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	struct resource *res;
 	void __iomem *io_base;
 	int num_locks, i, ret;
-	int base_id = 0;
+	int base_id = 0, reserved_locks = 0;
 
 	if (!node)
 		return -ENODEV;
@@ -144,7 +144,7 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
-						base_id, num_locks);
+					base_id, num_locks, reserved_locks);
 	if (ret)
 		goto reg_fail;
 
diff --git a/drivers/hwspinlock/u8500_hsem.c b/drivers/hwspinlock/u8500_hsem.c
index 401c33b..2b4f001 100644
--- a/drivers/hwspinlock/u8500_hsem.c
+++ b/drivers/hwspinlock/u8500_hsem.c
@@ -134,7 +134,8 @@ static int u8500_hsem_probe(struct platform_device *pdev)
 	pm_runtime_enable(&pdev->dev);
 
 	ret = hwspin_lock_register(bank, &pdev->dev, &u8500_hwspinlock_ops,
-						pdata->base_id, num_locks);
+					pdata->base_id, num_locks,
+					pdata->num_reserved_locks);
 	if (ret)
 		goto reg_fail;
 
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index 4857728..d120035 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -35,6 +35,7 @@ struct hwspinlock_ops;
 /**
  * struct hwspinlock_pdata - platform data for hwspinlock drivers
  * @base_id: base id for this hwspinlock device
+ * @num_reserved_locks: number of reserved locks starting from @base_id
  *
  * hwspinlock devices provide system-wide hardware locks that are used
  * by remote processors that have no other way to achieve synchronization.
@@ -53,11 +54,13 @@ struct hwspinlock_ops;
  *
  * This platform data structure should be used to provide the base id
  * for each device (which is trivially 0 when only a single hwspinlock
- * device exists). It can be shared between different platforms, hence
- * its location.
+ * device exists). It should also be used to provide the number of reserved
+ * locks for non-DT based devices. It can be shared between different
+ * platforms, hence its location.
  */
 struct hwspinlock_pdata {
 	int base_id;
+	int num_reserved_locks;
 };
 
 #if defined(CONFIG_HWSPINLOCK) || defined(CONFIG_HWSPINLOCK_MODULE)
@@ -67,7 +70,8 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
-		const struct hwspinlock_ops *ops, int base_id, int num_locks);
+		const struct hwspinlock_ops *ops, int base_id, int num_locks,
+		int num_reserved_locks);
 int hwspin_lock_unregister(struct hwspinlock_device *bank);
 struct hwspinlock *hwspin_lock_request(void);
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.

The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
 drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
 include/linux/hwspinlock.h                         |  1 +
 3 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
 			property is needed on hwlock devices, where the number
 			of supported locks within a hwlock device cannot be
 			read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+			specific locks. This value cannot exceed the value of
+			hwlock-num-locks.
 - hwlock-base-id:	An unique base Id for the locks for a particular hwlock
 			device. This property is mandatory ONLY if a SoC has
 			several hwlock devices.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index e05cea8..e74b55b 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
 EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
 
 /**
+ * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying platform
+ * specific implementations, to retrieve the number of locks to reserve from
+ * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
+ * property needs to be defined for requesting any DT-based locks.
+ *
+ * Returns a positive number of locks on success, a default value of 0 if the
+ * property is missing or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
+{
+	unsigned int val = 0;
+	int ret;
+
+	ret = of_property_read_u32(dn, "hwlock-reserved-locks", &val);
+	if (!ret || ret == -EINVAL)
+		ret = val;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index d120035..d18431f 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 				const struct of_phandle_args *hwlock_spec);
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks,
 		int num_reserved_locks);
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.

The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
 drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
 include/linux/hwspinlock.h                         |  1 +
 3 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
 			property is needed on hwlock devices, where the number
 			of supported locks within a hwlock device cannot be
 			read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+			specific locks. This value cannot exceed the value of
+			hwlock-num-locks.
 - hwlock-base-id:	An unique base Id for the locks for a particular hwlock
 			device. This property is mandatory ONLY if a SoC has
 			several hwlock devices.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index e05cea8..e74b55b 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
 EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
 
 /**
+ * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying platform
+ * specific implementations, to retrieve the number of locks to reserve from
+ * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
+ * property needs to be defined for requesting any DT-based locks.
+ *
+ * Returns a positive number of locks on success, a default value of 0 if the
+ * property is missing or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
+{
+	unsigned int val = 0;
+	int ret;
+
+	ret = of_property_read_u32(dn, "hwlock-reserved-locks", &val);
+	if (!ret || ret == -EINVAL)
+		ret = val;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index d120035..d18431f 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 				const struct of_phandle_args *hwlock_spec);
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks,
 		int num_reserved_locks);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform implementations.

The function will return a value of 0 if the property is not
defined, so as to support a default behavior of marking all
locks as unused and open for anonymous allocations.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
 drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
 include/linux/hwspinlock.h                         |  1 +
 3 files changed, 29 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
index d538a9b..88d16d2 100644
--- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -18,6 +18,9 @@ Common properties:
 			property is needed on hwlock devices, where the number
 			of supported locks within a hwlock device cannot be
 			read from a register.
+- hwlock-reserved-locks: Number of locks to reserve for clients requiring
+			specific locks. This value cannot exceed the value of
+			hwlock-num-locks.
 - hwlock-base-id:	An unique base Id for the locks for a particular hwlock
 			device. This property is mandatory ONLY if a SoC has
 			several hwlock devices.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index e05cea8..e74b55b 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
 EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
 
 /**
+ * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
+ * @dn: device node pointer
+ *
+ * This is an OF helper function that can be called by the underlying platform
+ * specific implementations, to retrieve the number of locks to reserve from
+ * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
+ * property needs to be defined for requesting any DT-based locks.
+ *
+ * Returns a positive number of locks on success, a default value of 0 if the
+ * property is missing or an appropriate error code as returned by the OF layer
+ */
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
+{
+	unsigned int val = 0;
+	int ret;
+
+	ret = of_property_read_u32(dn, "hwlock-reserved-locks", &val);
+	if (!ret || ret == -EINVAL)
+		ret = val;
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
+
+/**
  * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
  * @dn: device node pointer
  *
diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
index d120035..d18431f 100644
--- a/include/linux/hwspinlock.h
+++ b/include/linux/hwspinlock.h
@@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
 				const struct of_phandle_args *hwlock_spec);
 int of_hwspin_lock_get_base_id(struct device_node *dn);
 int of_hwspin_lock_get_num_locks(struct device_node *dn);
+int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
 int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
 		const struct hwspinlock_ops *ops, int base_id, int num_locks,
 		int num_reserved_locks);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get reserved locks
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/omap_hwspinlock.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 1d0c78e..0dad783 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -143,6 +143,12 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
+	reserved_locks = of_hwspin_lock_get_num_reserved_locks(node);
+	if (reserved_locks < 0) {
+		ret = -EINVAL;
+		goto iounmap_base;
+	}
+
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
 					base_id, num_locks, reserved_locks);
 	if (ret)
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/omap_hwspinlock.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 1d0c78e..0dad783 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -143,6 +143,12 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
+	reserved_locks = of_hwspin_lock_get_num_reserved_locks(node);
+	if (reserved_locks < 0) {
+		ret = -EINVAL;
+		goto iounmap_base;
+	}
+
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
 					base_id, num_locks, reserved_locks);
 	if (ret)
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get reserved locks
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/omap_hwspinlock.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
index 1d0c78e..0dad783 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -143,6 +143,12 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
 	for (i = 0, hwlock = &bank->lock[0]; i < num_locks; i++, hwlock++)
 		hwlock->priv = io_base + LOCK_BASE_OFFSET + sizeof(u32) * i;
 
+	reserved_locks = of_hwspin_lock_get_num_reserved_locks(node);
+	if (reserved_locks < 0) {
+		ret = -EINVAL;
+		goto iounmap_base;
+	}
+
 	ret = hwspin_lock_register(bank, &pdev->dev, &omap_hwspinlock_ops,
 					base_id, num_locks, reserved_locks);
 	if (ret)
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular client api functions are
also modified to check for an invalid hwlock handle.

The consumers MUST check using IS_ERR() when requesting hwlocks
going forward to determine a valid hwlock.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
TODO: Move this patch before the Patch4,
	"hwspinlock/core: add common OF helpers"
	if accepted to go with the current series
---
 Documentation/hwspinlock.txt         | 12 ++++++------
 drivers/hwspinlock/hwspinlock_core.c | 25 ++++++++++++++-----------
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 903d477..bf1c7e46 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -35,15 +35,15 @@ independent, drivers.
 2. User API
 
   struct hwspinlock *hwspin_lock_request(void);
-   - dynamically assign an hwspinlock and return its address, or NULL
-     in case an unused hwspinlock isn't available. Users of this
+   - dynamically assign a hwspinlock and return its address, or an equivalent
+     ERR_PTR() in case an unused hwspinlock isn't available. Users of this
      API will usually want to communicate the lock's id to the remote core
      before it can be used to achieve synchronization.
      Should be called from a process context (might sleep).
 
   struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-   - assign a specific hwspinlock id and return its address, or NULL
-     if that hwspinlock is already in use. Usually board code will
+   - assign a specific hwspinlock id and return its address, or an equivalent
+     ERR_PTR() if that hwspinlock is already in use. Usually board code will
      be calling this function in order to reserve specific hwspinlock
      ids for predefined purposes.
      Should be called from a process context (might sleep).
@@ -172,7 +172,7 @@ int hwspinlock_example1(void)
 
 	/* dynamically assign a hwspinlock */
 	hwlock = hwspin_lock_request();
-	if (!hwlock)
+	if (IS_ERR(hwlock))
 		...
 
 	id = hwspin_lock_get_id(hwlock);
@@ -208,7 +208,7 @@ int hwspinlock_example2(void)
 	 * by board init code.
 	 */
 	hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID);
-	if (!hwlock)
+	if (IS_ERR(hwlock))
 		...
 
 	/* try to take it, but don't spin on it */
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index e74b55b..56c4303 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -96,7 +96,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
 	int ret;
 
-	BUG_ON(!hwlock);
+	BUG_ON(IS_ERR_OR_NULL(hwlock));
 	BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
 	/*
@@ -235,7 +235,7 @@ EXPORT_SYMBOL_GPL(__hwspin_lock_timeout);
  */
 void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
-	BUG_ON(!hwlock);
+	BUG_ON(IS_ERR_OR_NULL(hwlock));
 	BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
 	/*
@@ -600,7 +600,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
  */
 int hwspin_lock_get_id(struct hwspinlock *hwlock)
 {
-	if (!hwlock) {
+	if (IS_ERR_OR_NULL(hwlock)) {
 		pr_err("invalid hwlock\n");
 		return -EINVAL;
 	}
@@ -620,7 +620,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_get_id);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent ERR_PTR()
+ * on error
  */
 struct hwspinlock *hwspin_lock_request(void)
 {
@@ -634,7 +635,7 @@ struct hwspinlock *hwspin_lock_request(void)
 						0, 1, HWSPINLOCK_UNUSED);
 	if (ret == 0) {
 		pr_warn("a free hwspinlock is not available\n");
-		hwlock = NULL;
+		hwlock = ERR_PTR(-ENXIO);
 		goto out;
 	}
 
@@ -644,7 +645,7 @@ struct hwspinlock *hwspin_lock_request(void)
 	/* mark as used and power up */
 	ret = __hwspin_lock_request(hwlock);
 	if (ret < 0)
-		hwlock = NULL;
+		hwlock = ERR_PTR(ret);
 
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -663,7 +664,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 {
@@ -676,6 +678,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	hwlock = radix_tree_lookup(&hwspinlock_tree, id);
 	if (!hwlock) {
 		pr_warn("hwspinlock %u does not exist\n", id);
+		hwlock = ERR_PTR(-EINVAL);
 		goto out;
 	}
 
@@ -684,7 +687,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 
 	if (hwlock->type != HWSPINLOCK_RESERVED) {
 		pr_warn("hwspinlock %u is not a reserved lock\n", id);
-		hwlock = NULL;
+		hwlock = ERR_PTR(-EINVAL);
 		goto out;
 	}
 
@@ -692,14 +695,14 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
-		hwlock = NULL;
+		hwlock = ERR_PTR(-EBUSY);
 		goto out;
 	}
 
 	/* mark as used and power up */
 	ret = __hwspin_lock_request(hwlock);
 	if (ret < 0)
-		hwlock = NULL;
+		hwlock = ERR_PTR(ret);
 
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -770,7 +773,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 	struct hwspinlock *tmp;
 	int ret;
 
-	if (!hwlock) {
+	if (IS_ERR_OR_NULL(hwlock)) {
 		pr_err("invalid hwlock\n");
 		return -EINVAL;
 	}
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular client api functions are
also modified to check for an invalid hwlock handle.

The consumers MUST check using IS_ERR() when requesting hwlocks
going forward to determine a valid hwlock.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
TODO: Move this patch before the Patch4,
	"hwspinlock/core: add common OF helpers"
	if accepted to go with the current series
---
 Documentation/hwspinlock.txt         | 12 ++++++------
 drivers/hwspinlock/hwspinlock_core.c | 25 ++++++++++++++-----------
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 903d477..bf1c7e46 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -35,15 +35,15 @@ independent, drivers.
 2. User API
 
   struct hwspinlock *hwspin_lock_request(void);
-   - dynamically assign an hwspinlock and return its address, or NULL
-     in case an unused hwspinlock isn't available. Users of this
+   - dynamically assign a hwspinlock and return its address, or an equivalent
+     ERR_PTR() in case an unused hwspinlock isn't available. Users of this
      API will usually want to communicate the lock's id to the remote core
      before it can be used to achieve synchronization.
      Should be called from a process context (might sleep).
 
   struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-   - assign a specific hwspinlock id and return its address, or NULL
-     if that hwspinlock is already in use. Usually board code will
+   - assign a specific hwspinlock id and return its address, or an equivalent
+     ERR_PTR() if that hwspinlock is already in use. Usually board code will
      be calling this function in order to reserve specific hwspinlock
      ids for predefined purposes.
      Should be called from a process context (might sleep).
@@ -172,7 +172,7 @@ int hwspinlock_example1(void)
 
 	/* dynamically assign a hwspinlock */
 	hwlock = hwspin_lock_request();
-	if (!hwlock)
+	if (IS_ERR(hwlock))
 		...
 
 	id = hwspin_lock_get_id(hwlock);
@@ -208,7 +208,7 @@ int hwspinlock_example2(void)
 	 * by board init code.
 	 */
 	hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID);
-	if (!hwlock)
+	if (IS_ERR(hwlock))
 		...
 
 	/* try to take it, but don't spin on it */
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index e74b55b..56c4303 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -96,7 +96,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
 	int ret;
 
-	BUG_ON(!hwlock);
+	BUG_ON(IS_ERR_OR_NULL(hwlock));
 	BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
 	/*
@@ -235,7 +235,7 @@ EXPORT_SYMBOL_GPL(__hwspin_lock_timeout);
  */
 void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
-	BUG_ON(!hwlock);
+	BUG_ON(IS_ERR_OR_NULL(hwlock));
 	BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
 	/*
@@ -600,7 +600,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
  */
 int hwspin_lock_get_id(struct hwspinlock *hwlock)
 {
-	if (!hwlock) {
+	if (IS_ERR_OR_NULL(hwlock)) {
 		pr_err("invalid hwlock\n");
 		return -EINVAL;
 	}
@@ -620,7 +620,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_get_id);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent ERR_PTR()
+ * on error
  */
 struct hwspinlock *hwspin_lock_request(void)
 {
@@ -634,7 +635,7 @@ struct hwspinlock *hwspin_lock_request(void)
 						0, 1, HWSPINLOCK_UNUSED);
 	if (ret == 0) {
 		pr_warn("a free hwspinlock is not available\n");
-		hwlock = NULL;
+		hwlock = ERR_PTR(-ENXIO);
 		goto out;
 	}
 
@@ -644,7 +645,7 @@ struct hwspinlock *hwspin_lock_request(void)
 	/* mark as used and power up */
 	ret = __hwspin_lock_request(hwlock);
 	if (ret < 0)
-		hwlock = NULL;
+		hwlock = ERR_PTR(ret);
 
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -663,7 +664,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 {
@@ -676,6 +678,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	hwlock = radix_tree_lookup(&hwspinlock_tree, id);
 	if (!hwlock) {
 		pr_warn("hwspinlock %u does not exist\n", id);
+		hwlock = ERR_PTR(-EINVAL);
 		goto out;
 	}
 
@@ -684,7 +687,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 
 	if (hwlock->type != HWSPINLOCK_RESERVED) {
 		pr_warn("hwspinlock %u is not a reserved lock\n", id);
-		hwlock = NULL;
+		hwlock = ERR_PTR(-EINVAL);
 		goto out;
 	}
 
@@ -692,14 +695,14 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
-		hwlock = NULL;
+		hwlock = ERR_PTR(-EBUSY);
 		goto out;
 	}
 
 	/* mark as used and power up */
 	ret = __hwspin_lock_request(hwlock);
 	if (ret < 0)
-		hwlock = NULL;
+		hwlock = ERR_PTR(ret);
 
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -770,7 +773,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 	struct hwspinlock *tmp;
 	int ret;
 
-	if (!hwlock) {
+	if (IS_ERR_OR_NULL(hwlock)) {
 		pr_err("invalid hwlock\n");
 		return -EINVAL;
 	}
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular client api functions are
also modified to check for an invalid hwlock handle.

The consumers MUST check using IS_ERR() when requesting hwlocks
going forward to determine a valid hwlock.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
TODO: Move this patch before the Patch4,
	"hwspinlock/core: add common OF helpers"
	if accepted to go with the current series
---
 Documentation/hwspinlock.txt         | 12 ++++++------
 drivers/hwspinlock/hwspinlock_core.c | 25 ++++++++++++++-----------
 2 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 903d477..bf1c7e46 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -35,15 +35,15 @@ independent, drivers.
 2. User API
 
   struct hwspinlock *hwspin_lock_request(void);
-   - dynamically assign an hwspinlock and return its address, or NULL
-     in case an unused hwspinlock isn't available. Users of this
+   - dynamically assign a hwspinlock and return its address, or an equivalent
+     ERR_PTR() in case an unused hwspinlock isn't available. Users of this
      API will usually want to communicate the lock's id to the remote core
      before it can be used to achieve synchronization.
      Should be called from a process context (might sleep).
 
   struct hwspinlock *hwspin_lock_request_specific(unsigned int id);
-   - assign a specific hwspinlock id and return its address, or NULL
-     if that hwspinlock is already in use. Usually board code will
+   - assign a specific hwspinlock id and return its address, or an equivalent
+     ERR_PTR() if that hwspinlock is already in use. Usually board code will
      be calling this function in order to reserve specific hwspinlock
      ids for predefined purposes.
      Should be called from a process context (might sleep).
@@ -172,7 +172,7 @@ int hwspinlock_example1(void)
 
 	/* dynamically assign a hwspinlock */
 	hwlock = hwspin_lock_request();
-	if (!hwlock)
+	if (IS_ERR(hwlock))
 		...
 
 	id = hwspin_lock_get_id(hwlock);
@@ -208,7 +208,7 @@ int hwspinlock_example2(void)
 	 * by board init code.
 	 */
 	hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID);
-	if (!hwlock)
+	if (IS_ERR(hwlock))
 		...
 
 	/* try to take it, but don't spin on it */
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index e74b55b..56c4303 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -96,7 +96,7 @@ int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
 	int ret;
 
-	BUG_ON(!hwlock);
+	BUG_ON(IS_ERR_OR_NULL(hwlock));
 	BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
 	/*
@@ -235,7 +235,7 @@ EXPORT_SYMBOL_GPL(__hwspin_lock_timeout);
  */
 void __hwspin_unlock(struct hwspinlock *hwlock, int mode, unsigned long *flags)
 {
-	BUG_ON(!hwlock);
+	BUG_ON(IS_ERR_OR_NULL(hwlock));
 	BUG_ON(!flags && mode == HWLOCK_IRQSTATE);
 
 	/*
@@ -600,7 +600,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
  */
 int hwspin_lock_get_id(struct hwspinlock *hwlock)
 {
-	if (!hwlock) {
+	if (IS_ERR_OR_NULL(hwlock)) {
 		pr_err("invalid hwlock\n");
 		return -EINVAL;
 	}
@@ -620,7 +620,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_get_id);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent ERR_PTR()
+ * on error
  */
 struct hwspinlock *hwspin_lock_request(void)
 {
@@ -634,7 +635,7 @@ struct hwspinlock *hwspin_lock_request(void)
 						0, 1, HWSPINLOCK_UNUSED);
 	if (ret == 0) {
 		pr_warn("a free hwspinlock is not available\n");
-		hwlock = NULL;
+		hwlock = ERR_PTR(-ENXIO);
 		goto out;
 	}
 
@@ -644,7 +645,7 @@ struct hwspinlock *hwspin_lock_request(void)
 	/* mark as used and power up */
 	ret = __hwspin_lock_request(hwlock);
 	if (ret < 0)
-		hwlock = NULL;
+		hwlock = ERR_PTR(ret);
 
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -663,7 +664,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request);
  *
  * Should be called from a process context (might sleep)
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 {
@@ -676,6 +678,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	hwlock = radix_tree_lookup(&hwspinlock_tree, id);
 	if (!hwlock) {
 		pr_warn("hwspinlock %u does not exist\n", id);
+		hwlock = ERR_PTR(-EINVAL);
 		goto out;
 	}
 
@@ -684,7 +687,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 
 	if (hwlock->type != HWSPINLOCK_RESERVED) {
 		pr_warn("hwspinlock %u is not a reserved lock\n", id);
-		hwlock = NULL;
+		hwlock = ERR_PTR(-EINVAL);
 		goto out;
 	}
 
@@ -692,14 +695,14 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned int id)
 	ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
 	if (ret == 0) {
 		pr_warn("hwspinlock %u is already in use\n", id);
-		hwlock = NULL;
+		hwlock = ERR_PTR(-EBUSY);
 		goto out;
 	}
 
 	/* mark as used and power up */
 	ret = __hwspin_lock_request(hwlock);
 	if (ret < 0)
-		hwlock = NULL;
+		hwlock = ERR_PTR(ret);
 
 out:
 	mutex_unlock(&hwspinlock_tree_lock);
@@ -770,7 +773,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
 	struct hwspinlock *tmp;
 	int ret;
 
-	if (!hwlock) {
+	if (IS_ERR_OR_NULL(hwlock)) {
 		pr_err("invalid hwlock\n");
 		return -EINVAL;
 	}
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific
  2014-05-01  0:34 ` Suman Anna
  (?)
@ 2014-05-01  0:34   ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Changed the return statements to return an ERR_PTR instead of NULL
in case of an error. This patch helps with deferred probing of any
client users if the corresponding hwspinlock bank is not yet registered
with the hwspinlock core.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
TODO: Collapse into Patch4,
	 "hwspinlock/core: add common OF helpers"
	if accepted to go with the current series
---
 Documentation/hwspinlock.txt         | 4 ++--
 drivers/hwspinlock/hwspinlock_core.c | 9 +++++----
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index bf1c7e46..10d7ecc 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -50,8 +50,8 @@ independent, drivers.
 
   struct hwspinlock *of_hwspin_lock_request_specific(
 		struct device_node *np,	const char *propname, int index);
-   - assign a specific hwspinlock id and return its address, or NULL
-     if that hwspinlock is already in use. This function is the OF
+   - assign a specific hwspinlock id and return its address, or an equivalent
+     ERR_PTR() if that hwspinlock is already in use. This function is the OF
      equivalent of hwspin_lock_request_specific() function, and provides
      a means for users of the hwspinlock module to request a specific
      hwspinlock using the phandle of the hwspinlock device.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 56c4303..a838dbd 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -722,7 +722,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
  * lock number is indexed relative to the hwspinlock device, unlike the
  * hwspin_lock_request_specific() which is an absolute lock number.
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 						   const char *propname,
@@ -736,7 +737,7 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 	ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
 					 &args);
 	if (ret)
-		return NULL;
+		return ERR_PTR(ret);
 
 	mutex_lock(&hwspinlock_tree_lock);
 	list_for_each_entry(bank, &hwspinlock_devices, list)
@@ -744,11 +745,11 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 			break;
 	mutex_unlock(&hwspinlock_tree_lock);
 	if (&bank->list == &hwspinlock_devices)
-		return NULL;
+		return ERR_PTR(-EPROBE_DEFER);
 
 	id = bank->ops->of_xlate(bank, &args);
 	if (id < 0 || id >= bank->num_locks)
-		return NULL;
+		return ERR_PTR(-EINVAL);
 
 	id += bank->base_id;
 	return hwspin_lock_request_specific(id);
-- 
1.9.2


^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel, Suman Anna

Changed the return statements to return an ERR_PTR instead of NULL
in case of an error. This patch helps with deferred probing of any
client users if the corresponding hwspinlock bank is not yet registered
with the hwspinlock core.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
TODO: Collapse into Patch4,
	 "hwspinlock/core: add common OF helpers"
	if accepted to go with the current series
---
 Documentation/hwspinlock.txt         | 4 ++--
 drivers/hwspinlock/hwspinlock_core.c | 9 +++++----
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index bf1c7e46..10d7ecc 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -50,8 +50,8 @@ independent, drivers.
 
   struct hwspinlock *of_hwspin_lock_request_specific(
 		struct device_node *np,	const char *propname, int index);
-   - assign a specific hwspinlock id and return its address, or NULL
-     if that hwspinlock is already in use. This function is the OF
+   - assign a specific hwspinlock id and return its address, or an equivalent
+     ERR_PTR() if that hwspinlock is already in use. This function is the OF
      equivalent of hwspin_lock_request_specific() function, and provides
      a means for users of the hwspinlock module to request a specific
      hwspinlock using the phandle of the hwspinlock device.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 56c4303..a838dbd 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -722,7 +722,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
  * lock number is indexed relative to the hwspinlock device, unlike the
  * hwspin_lock_request_specific() which is an absolute lock number.
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 						   const char *propname,
@@ -736,7 +737,7 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 	ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
 					 &args);
 	if (ret)
-		return NULL;
+		return ERR_PTR(ret);
 
 	mutex_lock(&hwspinlock_tree_lock);
 	list_for_each_entry(bank, &hwspinlock_devices, list)
@@ -744,11 +745,11 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 			break;
 	mutex_unlock(&hwspinlock_tree_lock);
 	if (&bank->list == &hwspinlock_devices)
-		return NULL;
+		return ERR_PTR(-EPROBE_DEFER);
 
 	id = bank->ops->of_xlate(bank, &args);
 	if (id < 0 || id >= bank->num_locks)
-		return NULL;
+		return ERR_PTR(-EINVAL);
 
 	id += bank->base_id;
 	return hwspin_lock_request_specific(id);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific
@ 2014-05-01  0:34   ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-01  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

Changed the return statements to return an ERR_PTR instead of NULL
in case of an error. This patch helps with deferred probing of any
client users if the corresponding hwspinlock bank is not yet registered
with the hwspinlock core.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
TODO: Collapse into Patch4,
	 "hwspinlock/core: add common OF helpers"
	if accepted to go with the current series
---
 Documentation/hwspinlock.txt         | 4 ++--
 drivers/hwspinlock/hwspinlock_core.c | 9 +++++----
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index bf1c7e46..10d7ecc 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -50,8 +50,8 @@ independent, drivers.
 
   struct hwspinlock *of_hwspin_lock_request_specific(
 		struct device_node *np,	const char *propname, int index);
-   - assign a specific hwspinlock id and return its address, or NULL
-     if that hwspinlock is already in use. This function is the OF
+   - assign a specific hwspinlock id and return its address, or an equivalent
+     ERR_PTR() if that hwspinlock is already in use. This function is the OF
      equivalent of hwspin_lock_request_specific() function, and provides
      a means for users of the hwspinlock module to request a specific
      hwspinlock using the phandle of the hwspinlock device.
diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
index 56c4303..a838dbd 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -722,7 +722,8 @@ EXPORT_SYMBOL_GPL(hwspin_lock_request_specific);
  * lock number is indexed relative to the hwspinlock device, unlike the
  * hwspin_lock_request_specific() which is an absolute lock number.
  *
- * Returns the address of the assigned hwspinlock, or NULL on error
+ * Returns the address of the assigned hwspinlock, or an equivalent
+ * ERR_PTR() on error
  */
 struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 						   const char *propname,
@@ -736,7 +737,7 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 	ret = of_parse_phandle_with_args(np, propname, "#hwlock-cells", index,
 					 &args);
 	if (ret)
-		return NULL;
+		return ERR_PTR(ret);
 
 	mutex_lock(&hwspinlock_tree_lock);
 	list_for_each_entry(bank, &hwspinlock_devices, list)
@@ -744,11 +745,11 @@ struct hwspinlock *of_hwspin_lock_request_specific(struct device_node *np,
 			break;
 	mutex_unlock(&hwspinlock_tree_lock);
 	if (&bank->list == &hwspinlock_devices)
-		return NULL;
+		return ERR_PTR(-EPROBE_DEFER);
 
 	id = bank->ops->of_xlate(bank, &args);
 	if (id < 0 || id >= bank->num_locks)
-		return NULL;
+		return ERR_PTR(-EINVAL);
 
 	id += bank->base_id;
 	return hwspin_lock_request_specific(id);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
  2014-05-01  0:34   ` Suman Anna
  (?)
@ 2014-05-02 14:58     ` Rob Herring
  -1 siblings, 0 replies; 111+ messages in thread
From: Rob Herring @ 2014-05-02 14:58 UTC (permalink / raw)
  To: Suman Anna
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Tony Lindgren,
	Josh Cartwright, Bjorn Andersson, linux-kernel, linux-omap,
	devicetree, linux-arm-kernel, Rob Herring

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
> This patch adds the generic common bindings used to represent
> a hwlock device and use/request locks in a device-tree build.
>
> All the platform-specific hwlock driver implementations need the
> number of locks and associated base id for registering the locks
> present within the device with the driver core. The number of locks
> is represented by 'hwlock-num-locks' property in DT bindings. A
> property for base id is not needed in DT binding, as it can be
> satisfied using a phandle + args specifier. The args specifier
> length is dependent on each vendor-specific implementation and
> is represented through the '#hwlock-cells' property.
>
> Note that the document is named hwlock.txt deliberately to keep it
> a bit more generic.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> new file mode 100644
> index 0000000..32381cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -0,0 +1,52 @@
> +Generic hwlock bindings
> +=======================
> +
> +Generic bindings that are common to all the hwlock platform specific driver
> +implementations, the retrieved values are used for registering the device
> +specific parameters with the hwspinlock core.
> +
> +The validity and need of these common properties may vary from one platform
> +implementation to another. The platform specific bindings should explicitly
> +state if a property is mandatory or optional. Please look through the
> +individual platform specific hwlock binding documentations for identifying
> +the applicable properties.
> +
> +Common properties:
> +- #hwlock-cells:       Specifies the number of cells needed to represent a
> +                       specific lock.

This should never be optional.

> +- hwlock-num-locks:    Number of locks present in a hwlock device. This
> +                       property is needed on hwlock devices, where the number
> +                       of supported locks within a hwlock device cannot be
> +                       read from a register.

Do you have any users of this? The omap binding doesn't use it.
Wouldn't you typically know this based on the IP block? Similarly you
typically don't have to list how many irqs an interrupt controller
has.


> +
> +Hwlock Users:
> +=============
> +
> +Nodes that require specific hwlock(s) should specify them using one or more
> +properties, each containing a phandle to the hwlock node and an args specifier
> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
> +an array of the phandle and hwlock number specifier tuple.
> +
> +1. Example of a node using a single specific hwlock:
> +
> +The following example has a node requesting a hwlock in the bank defined by
> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
> +of length 1.
> +
> +       node {
> +               ...
> +               hwlocks = <&hwlock1 2>;
> +               ...
> +       };
> +
> +2. Example of a node using multiple specific hwlocks:
> +
> +The following example has a node requesting two hwlocks, a hwlock within
> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
> +
> +       node {
> +               ...
> +               hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
> +               ...
> +       };
> --
> 1.9.2
>

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-02 14:58     ` Rob Herring
  0 siblings, 0 replies; 111+ messages in thread
From: Rob Herring @ 2014-05-02 14:58 UTC (permalink / raw)
  To: Suman Anna
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Tony Lindgren,
	Josh Cartwright, Bjorn Andersson, linux-kernel, linux-omap,
	devicetree, linux-arm-kernel, Rob Herring

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
> This patch adds the generic common bindings used to represent
> a hwlock device and use/request locks in a device-tree build.
>
> All the platform-specific hwlock driver implementations need the
> number of locks and associated base id for registering the locks
> present within the device with the driver core. The number of locks
> is represented by 'hwlock-num-locks' property in DT bindings. A
> property for base id is not needed in DT binding, as it can be
> satisfied using a phandle + args specifier. The args specifier
> length is dependent on each vendor-specific implementation and
> is represented through the '#hwlock-cells' property.
>
> Note that the document is named hwlock.txt deliberately to keep it
> a bit more generic.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> new file mode 100644
> index 0000000..32381cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -0,0 +1,52 @@
> +Generic hwlock bindings
> +=======================
> +
> +Generic bindings that are common to all the hwlock platform specific driver
> +implementations, the retrieved values are used for registering the device
> +specific parameters with the hwspinlock core.
> +
> +The validity and need of these common properties may vary from one platform
> +implementation to another. The platform specific bindings should explicitly
> +state if a property is mandatory or optional. Please look through the
> +individual platform specific hwlock binding documentations for identifying
> +the applicable properties.
> +
> +Common properties:
> +- #hwlock-cells:       Specifies the number of cells needed to represent a
> +                       specific lock.

This should never be optional.

> +- hwlock-num-locks:    Number of locks present in a hwlock device. This
> +                       property is needed on hwlock devices, where the number
> +                       of supported locks within a hwlock device cannot be
> +                       read from a register.

Do you have any users of this? The omap binding doesn't use it.
Wouldn't you typically know this based on the IP block? Similarly you
typically don't have to list how many irqs an interrupt controller
has.


> +
> +Hwlock Users:
> +=============
> +
> +Nodes that require specific hwlock(s) should specify them using one or more
> +properties, each containing a phandle to the hwlock node and an args specifier
> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
> +an array of the phandle and hwlock number specifier tuple.
> +
> +1. Example of a node using a single specific hwlock:
> +
> +The following example has a node requesting a hwlock in the bank defined by
> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
> +of length 1.
> +
> +       node {
> +               ...
> +               hwlocks = <&hwlock1 2>;
> +               ...
> +       };
> +
> +2. Example of a node using multiple specific hwlocks:
> +
> +The following example has a node requesting two hwlocks, a hwlock within
> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
> +
> +       node {
> +               ...
> +               hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
> +               ...
> +       };
> --
> 1.9.2
>

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-02 14:58     ` Rob Herring
  0 siblings, 0 replies; 111+ messages in thread
From: Rob Herring @ 2014-05-02 14:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
> This patch adds the generic common bindings used to represent
> a hwlock device and use/request locks in a device-tree build.
>
> All the platform-specific hwlock driver implementations need the
> number of locks and associated base id for registering the locks
> present within the device with the driver core. The number of locks
> is represented by 'hwlock-num-locks' property in DT bindings. A
> property for base id is not needed in DT binding, as it can be
> satisfied using a phandle + args specifier. The args specifier
> length is dependent on each vendor-specific implementation and
> is represented through the '#hwlock-cells' property.
>
> Note that the document is named hwlock.txt deliberately to keep it
> a bit more generic.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> new file mode 100644
> index 0000000..32381cc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -0,0 +1,52 @@
> +Generic hwlock bindings
> +=======================
> +
> +Generic bindings that are common to all the hwlock platform specific driver
> +implementations, the retrieved values are used for registering the device
> +specific parameters with the hwspinlock core.
> +
> +The validity and need of these common properties may vary from one platform
> +implementation to another. The platform specific bindings should explicitly
> +state if a property is mandatory or optional. Please look through the
> +individual platform specific hwlock binding documentations for identifying
> +the applicable properties.
> +
> +Common properties:
> +- #hwlock-cells:       Specifies the number of cells needed to represent a
> +                       specific lock.

This should never be optional.

> +- hwlock-num-locks:    Number of locks present in a hwlock device. This
> +                       property is needed on hwlock devices, where the number
> +                       of supported locks within a hwlock device cannot be
> +                       read from a register.

Do you have any users of this? The omap binding doesn't use it.
Wouldn't you typically know this based on the IP block? Similarly you
typically don't have to list how many irqs an interrupt controller
has.


> +
> +Hwlock Users:
> +=============
> +
> +Nodes that require specific hwlock(s) should specify them using one or more
> +properties, each containing a phandle to the hwlock node and an args specifier
> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
> +an array of the phandle and hwlock number specifier tuple.
> +
> +1. Example of a node using a single specific hwlock:
> +
> +The following example has a node requesting a hwlock in the bank defined by
> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
> +of length 1.
> +
> +       node {
> +               ...
> +               hwlocks = <&hwlock1 2>;
> +               ...
> +       };
> +
> +2. Example of a node using multiple specific hwlocks:
> +
> +The following example has a node requesting two hwlocks, a hwlock within
> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
> +
> +       node {
> +               ...
> +               hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
> +               ...
> +       };
> --
> 1.9.2
>

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
  2014-05-02 14:58     ` Rob Herring
  (?)
@ 2014-05-02 22:46       ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-02 22:46 UTC (permalink / raw)
  To: Rob Herring
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Tony Lindgren,
	Josh Cartwright, Bjorn Andersson, linux-kernel, linux-omap,
	devicetree, linux-arm-kernel, Rob Herring

Hi Rob,

On 05/02/2014 09:58 AM, Rob Herring wrote:
> On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
>> This patch adds the generic common bindings used to represent
>> a hwlock device and use/request locks in a device-tree build.
>>
>> All the platform-specific hwlock driver implementations need the
>> number of locks and associated base id for registering the locks
>> present within the device with the driver core. The number of locks
>> is represented by 'hwlock-num-locks' property in DT bindings. A
>> property for base id is not needed in DT binding, as it can be
>> satisfied using a phandle + args specifier. The args specifier
>> length is dependent on each vendor-specific implementation and
>> is represented through the '#hwlock-cells' property.
>>
>> Note that the document is named hwlock.txt deliberately to keep it
>> a bit more generic.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>>  .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> new file mode 100644
>> index 0000000..32381cc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> @@ -0,0 +1,52 @@
>> +Generic hwlock bindings
>> +=======================
>> +
>> +Generic bindings that are common to all the hwlock platform specific driver
>> +implementations, the retrieved values are used for registering the device
>> +specific parameters with the hwspinlock core.
>> +
>> +The validity and need of these common properties may vary from one platform
>> +implementation to another. The platform specific bindings should explicitly
>> +state if a property is mandatory or optional. Please look through the
>> +individual platform specific hwlock binding documentations for identifying
>> +the applicable properties.
>> +
>> +Common properties:
>> +- #hwlock-cells:       Specifies the number of cells needed to represent a
>> +                       specific lock.
> 
> This should never be optional.

Thanks for reviewing this. I can add a statement here to make this clear.

> 
>> +- hwlock-num-locks:    Number of locks present in a hwlock device. This
>> +                       property is needed on hwlock devices, where the number
>> +                       of supported locks within a hwlock device cannot be
>> +                       read from a register.
> 
> Do you have any users of this? The omap binding doesn't use it.
> Wouldn't you typically know this based on the IP block? Similarly you
> typically don't have to list how many irqs an interrupt controller
> has.

The MSM Spinlock driver [1] would be using this, it is waiting on this
series to get finalized. It currently defines a custom property, and the
number of locks is a generic property that the hwspinlock core uses and
is common to different platform implementations, so created the generic
property. OMAP doesn't use this because the number is read directly off
a IP register.

 can you also take a look at patches 8 and 12 as they add additional
properties based on discussion in [2]. The hwspinlocks are used for
arbitration between different initiators on an SoC, and typically would
need a SoC-level identifier for each lock. All these properties allow a
hwlock to be statically identified and be assigned to a user and its
peer user on a different initiator, and not allowing them to be run-time
assigned.

regards
Suman

[1] https://lkml.org/lkml/2013/8/14/528
[2] http://marc.info/?l=linux-omap&m=139510004009415&w=2

> 
> 
>> +
>> +Hwlock Users:
>> +=============
>> +
>> +Nodes that require specific hwlock(s) should specify them using one or more
>> +properties, each containing a phandle to the hwlock node and an args specifier
>> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
>> +an array of the phandle and hwlock number specifier tuple.
>> +
>> +1. Example of a node using a single specific hwlock:
>> +
>> +The following example has a node requesting a hwlock in the bank defined by
>> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
>> +of length 1.
>> +
>> +       node {
>> +               ...
>> +               hwlocks = <&hwlock1 2>;
>> +               ...
>> +       };
>> +
>> +2. Example of a node using multiple specific hwlocks:
>> +
>> +The following example has a node requesting two hwlocks, a hwlock within
>> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
>> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
>> +
>> +       node {
>> +               ...
>> +               hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
>> +               ...
>> +       };
>> --
>> 1.9.2
>>


^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-02 22:46       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-02 22:46 UTC (permalink / raw)
  To: Rob Herring
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Tony Lindgren,
	Josh Cartwright, Bjorn Andersson, linux-kernel, linux-omap,
	devicetree, linux-arm-kernel, Rob Herring

Hi Rob,

On 05/02/2014 09:58 AM, Rob Herring wrote:
> On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
>> This patch adds the generic common bindings used to represent
>> a hwlock device and use/request locks in a device-tree build.
>>
>> All the platform-specific hwlock driver implementations need the
>> number of locks and associated base id for registering the locks
>> present within the device with the driver core. The number of locks
>> is represented by 'hwlock-num-locks' property in DT bindings. A
>> property for base id is not needed in DT binding, as it can be
>> satisfied using a phandle + args specifier. The args specifier
>> length is dependent on each vendor-specific implementation and
>> is represented through the '#hwlock-cells' property.
>>
>> Note that the document is named hwlock.txt deliberately to keep it
>> a bit more generic.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>>  .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> new file mode 100644
>> index 0000000..32381cc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> @@ -0,0 +1,52 @@
>> +Generic hwlock bindings
>> +=======================
>> +
>> +Generic bindings that are common to all the hwlock platform specific driver
>> +implementations, the retrieved values are used for registering the device
>> +specific parameters with the hwspinlock core.
>> +
>> +The validity and need of these common properties may vary from one platform
>> +implementation to another. The platform specific bindings should explicitly
>> +state if a property is mandatory or optional. Please look through the
>> +individual platform specific hwlock binding documentations for identifying
>> +the applicable properties.
>> +
>> +Common properties:
>> +- #hwlock-cells:       Specifies the number of cells needed to represent a
>> +                       specific lock.
> 
> This should never be optional.

Thanks for reviewing this. I can add a statement here to make this clear.

> 
>> +- hwlock-num-locks:    Number of locks present in a hwlock device. This
>> +                       property is needed on hwlock devices, where the number
>> +                       of supported locks within a hwlock device cannot be
>> +                       read from a register.
> 
> Do you have any users of this? The omap binding doesn't use it.
> Wouldn't you typically know this based on the IP block? Similarly you
> typically don't have to list how many irqs an interrupt controller
> has.

The MSM Spinlock driver [1] would be using this, it is waiting on this
series to get finalized. It currently defines a custom property, and the
number of locks is a generic property that the hwspinlock core uses and
is common to different platform implementations, so created the generic
property. OMAP doesn't use this because the number is read directly off
a IP register.

 can you also take a look at patches 8 and 12 as they add additional
properties based on discussion in [2]. The hwspinlocks are used for
arbitration between different initiators on an SoC, and typically would
need a SoC-level identifier for each lock. All these properties allow a
hwlock to be statically identified and be assigned to a user and its
peer user on a different initiator, and not allowing them to be run-time
assigned.

regards
Suman

[1] https://lkml.org/lkml/2013/8/14/528
[2] http://marc.info/?l=linux-omap&m=139510004009415&w=2

> 
> 
>> +
>> +Hwlock Users:
>> +=============
>> +
>> +Nodes that require specific hwlock(s) should specify them using one or more
>> +properties, each containing a phandle to the hwlock node and an args specifier
>> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
>> +an array of the phandle and hwlock number specifier tuple.
>> +
>> +1. Example of a node using a single specific hwlock:
>> +
>> +The following example has a node requesting a hwlock in the bank defined by
>> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
>> +of length 1.
>> +
>> +       node {
>> +               ...
>> +               hwlocks = <&hwlock1 2>;
>> +               ...
>> +       };
>> +
>> +2. Example of a node using multiple specific hwlocks:
>> +
>> +The following example has a node requesting two hwlocks, a hwlock within
>> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
>> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
>> +
>> +       node {
>> +               ...
>> +               hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
>> +               ...
>> +       };
>> --
>> 1.9.2
>>


^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock
@ 2014-05-02 22:46       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-02 22:46 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Rob,

On 05/02/2014 09:58 AM, Rob Herring wrote:
> On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
>> This patch adds the generic common bindings used to represent
>> a hwlock device and use/request locks in a device-tree build.
>>
>> All the platform-specific hwlock driver implementations need the
>> number of locks and associated base id for registering the locks
>> present within the device with the driver core. The number of locks
>> is represented by 'hwlock-num-locks' property in DT bindings. A
>> property for base id is not needed in DT binding, as it can be
>> satisfied using a phandle + args specifier. The args specifier
>> length is dependent on each vendor-specific implementation and
>> is represented through the '#hwlock-cells' property.
>>
>> Note that the document is named hwlock.txt deliberately to keep it
>> a bit more generic.
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>>  .../devicetree/bindings/hwlock/hwlock.txt          | 52 ++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> new file mode 100644
>> index 0000000..32381cc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> @@ -0,0 +1,52 @@
>> +Generic hwlock bindings
>> +=======================
>> +
>> +Generic bindings that are common to all the hwlock platform specific driver
>> +implementations, the retrieved values are used for registering the device
>> +specific parameters with the hwspinlock core.
>> +
>> +The validity and need of these common properties may vary from one platform
>> +implementation to another. The platform specific bindings should explicitly
>> +state if a property is mandatory or optional. Please look through the
>> +individual platform specific hwlock binding documentations for identifying
>> +the applicable properties.
>> +
>> +Common properties:
>> +- #hwlock-cells:       Specifies the number of cells needed to represent a
>> +                       specific lock.
> 
> This should never be optional.

Thanks for reviewing this. I can add a statement here to make this clear.

> 
>> +- hwlock-num-locks:    Number of locks present in a hwlock device. This
>> +                       property is needed on hwlock devices, where the number
>> +                       of supported locks within a hwlock device cannot be
>> +                       read from a register.
> 
> Do you have any users of this? The omap binding doesn't use it.
> Wouldn't you typically know this based on the IP block? Similarly you
> typically don't have to list how many irqs an interrupt controller
> has.

The MSM Spinlock driver [1] would be using this, it is waiting on this
series to get finalized. It currently defines a custom property, and the
number of locks is a generic property that the hwspinlock core uses and
is common to different platform implementations, so created the generic
property. OMAP doesn't use this because the number is read directly off
a IP register.

 can you also take a look at patches 8 and 12 as they add additional
properties based on discussion in [2]. The hwspinlocks are used for
arbitration between different initiators on an SoC, and typically would
need a SoC-level identifier for each lock. All these properties allow a
hwlock to be statically identified and be assigned to a user and its
peer user on a different initiator, and not allowing them to be run-time
assigned.

regards
Suman

[1] https://lkml.org/lkml/2013/8/14/528
[2] http://marc.info/?l=linux-omap&m=139510004009415&w=2

> 
> 
>> +
>> +Hwlock Users:
>> +=============
>> +
>> +Nodes that require specific hwlock(s) should specify them using one or more
>> +properties, each containing a phandle to the hwlock node and an args specifier
>> +value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
>> +an array of the phandle and hwlock number specifier tuple.
>> +
>> +1. Example of a node using a single specific hwlock:
>> +
>> +The following example has a node requesting a hwlock in the bank defined by
>> +the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
>> +of length 1.
>> +
>> +       node {
>> +               ...
>> +               hwlocks = <&hwlock1 2>;
>> +               ...
>> +       };
>> +
>> +2. Example of a node using multiple specific hwlocks:
>> +
>> +The following example has a node requesting two hwlocks, a hwlock within
>> +the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
>> +hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
>> +
>> +       node {
>> +               ...
>> +               hwlocks = <&hwlock1 2>, <&hwlock2 0 3>;
>> +               ...
>> +       };
>> --
>> 1.9.2
>>

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-05 20:37     ` Rob Herring
  0 siblings, 0 replies; 111+ messages in thread
From: Rob Herring @ 2014-05-05 20:37 UTC (permalink / raw)
  To: Suman Anna
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, devicetree,
	Tony Lindgren, Josh Cartwright, linux-kernel, linux-omap,
	Bjorn Andersson, linux-arm-kernel

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
> The HwSpinlock core requires a base id for registering a bank
> of hwspinlocks. This base id needs to be unique across multiple
> IP instances of a hwspinlock device, so that each hwlock can be
> represented uniquely in a system.
>
> Support has been added to represent this in DT through a common
> property 'hwlock-base-id', and retrieve the value through a core
> OF helper function, of_hwspin_lock_get_base_id(). The representation
> in DT provides a uniform way of assigning a fixed base value for a
> hwspinlock device across different SoCs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
>  drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
>  include/linux/hwspinlock.h                          |  1 +
>  3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> index 32381cc..d538a9b 100644
> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -18,6 +18,12 @@ Common properties:
>                         property is needed on hwlock devices, where the number
>                         of supported locks within a hwlock device cannot be
>                         read from a register.
> +- hwlock-base-id:      An unique base Id for the locks for a particular hwlock
> +                       device. This property is mandatory ONLY if a SoC has
> +                       several hwlock devices.
> +
> +                       See documentation on struct hwspinlock_pdata in
> +                       include/linux/hwspinlock.h for more details.

The documentation cannot refer to kernel files. Generally, creating a
global number space like this would not be accepted, but I don't
really have any better idea here.

Please put all binding docs in 1 patch and copy all the DT binding maintainers.

Rob

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-05 20:37     ` Rob Herring
  0 siblings, 0 replies; 111+ messages in thread
From: Rob Herring @ 2014-05-05 20:37 UTC (permalink / raw)
  To: Suman Anna
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren,
	Josh Cartwright, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-omap,
	Bjorn Andersson,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
> The HwSpinlock core requires a base id for registering a bank
> of hwspinlocks. This base id needs to be unique across multiple
> IP instances of a hwspinlock device, so that each hwlock can be
> represented uniquely in a system.
>
> Support has been added to represent this in DT through a common
> property 'hwlock-base-id', and retrieve the value through a core
> OF helper function, of_hwspin_lock_get_base_id(). The representation
> in DT provides a uniform way of assigning a fixed base value for a
> hwspinlock device across different SoCs.
>
> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
>  drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
>  include/linux/hwspinlock.h                          |  1 +
>  3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> index 32381cc..d538a9b 100644
> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -18,6 +18,12 @@ Common properties:
>                         property is needed on hwlock devices, where the number
>                         of supported locks within a hwlock device cannot be
>                         read from a register.
> +- hwlock-base-id:      An unique base Id for the locks for a particular hwlock
> +                       device. This property is mandatory ONLY if a SoC has
> +                       several hwlock devices.
> +
> +                       See documentation on struct hwspinlock_pdata in
> +                       include/linux/hwspinlock.h for more details.

The documentation cannot refer to kernel files. Generally, creating a
global number space like this would not be accepted, but I don't
really have any better idea here.

Please put all binding docs in 1 patch and copy all the DT binding maintainers.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-05 20:37     ` Rob Herring
  0 siblings, 0 replies; 111+ messages in thread
From: Rob Herring @ 2014-05-05 20:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
> The HwSpinlock core requires a base id for registering a bank
> of hwspinlocks. This base id needs to be unique across multiple
> IP instances of a hwspinlock device, so that each hwlock can be
> represented uniquely in a system.
>
> Support has been added to represent this in DT through a common
> property 'hwlock-base-id', and retrieve the value through a core
> OF helper function, of_hwspin_lock_get_base_id(). The representation
> in DT provides a uniform way of assigning a fixed base value for a
> hwspinlock device across different SoCs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
>  drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
>  include/linux/hwspinlock.h                          |  1 +
>  3 files changed, 28 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> index 32381cc..d538a9b 100644
> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -18,6 +18,12 @@ Common properties:
>                         property is needed on hwlock devices, where the number
>                         of supported locks within a hwlock device cannot be
>                         read from a register.
> +- hwlock-base-id:      An unique base Id for the locks for a particular hwlock
> +                       device. This property is mandatory ONLY if a SoC has
> +                       several hwlock devices.
> +
> +                       See documentation on struct hwspinlock_pdata in
> +                       include/linux/hwspinlock.h for more details.

The documentation cannot refer to kernel files. Generally, creating a
global number space like this would not be accepted, but I don't
really have any better idea here.

Please put all binding docs in 1 patch and copy all the DT binding maintainers.

Rob

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-05 21:37       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-05 21:37 UTC (permalink / raw)
  To: Rob Herring
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, devicetree,
	Tony Lindgren, Josh Cartwright, linux-kernel, linux-omap,
	Bjorn Andersson, linux-arm-kernel

Hi Rob,

On 05/05/2014 03:37 PM, Rob Herring wrote:
> On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
>> The HwSpinlock core requires a base id for registering a bank
>> of hwspinlocks. This base id needs to be unique across multiple
>> IP instances of a hwspinlock device, so that each hwlock can be
>> represented uniquely in a system.
>>
>> Support has been added to represent this in DT through a common
>> property 'hwlock-base-id', and retrieve the value through a core
>> OF helper function, of_hwspin_lock_get_base_id(). The representation
>> in DT provides a uniform way of assigning a fixed base value for a
>> hwspinlock device across different SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>>  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
>>  drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
>>  include/linux/hwspinlock.h                          |  1 +
>>  3 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> index 32381cc..d538a9b 100644
>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> @@ -18,6 +18,12 @@ Common properties:
>>                         property is needed on hwlock devices, where the number
>>                         of supported locks within a hwlock device cannot be
>>                         read from a register.
>> +- hwlock-base-id:      An unique base Id for the locks for a particular hwlock
>> +                       device. This property is mandatory ONLY if a SoC has
>> +                       several hwlock devices.
>> +
>> +                       See documentation on struct hwspinlock_pdata in
>> +                       include/linux/hwspinlock.h for more details.
> 
> The documentation cannot refer to kernel files. 

OK, good to know. There are couple of such existing references, so
didn't think it was an issue. I will fold this patch and remove the
kernel reference if this property is ok to add.

> Generally, creating a
> global number space like this would not be accepted, but I don't
> really have any better idea here.
> 
> Please put all binding docs in 1 patch and copy all the DT binding maintainers.

I have deliberately put these in separate patches (as RFC) as there
doesn't seem to be a consensus on this. I had added this originally,
dropped it and brought it back again based on discussion on the previous
version. Intention was either to fold into the original patch if
accepted or drop them and revisit later.

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-05 21:37       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-05 21:37 UTC (permalink / raw)
  To: Rob Herring
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren,
	Josh Cartwright, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-omap,
	Bjorn Andersson,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Hi Rob,

On 05/05/2014 03:37 PM, Rob Herring wrote:
> On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
>> The HwSpinlock core requires a base id for registering a bank
>> of hwspinlocks. This base id needs to be unique across multiple
>> IP instances of a hwspinlock device, so that each hwlock can be
>> represented uniquely in a system.
>>
>> Support has been added to represent this in DT through a common
>> property 'hwlock-base-id', and retrieve the value through a core
>> OF helper function, of_hwspin_lock_get_base_id(). The representation
>> in DT provides a uniform way of assigning a fixed base value for a
>> hwspinlock device across different SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
>> ---
>>  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
>>  drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
>>  include/linux/hwspinlock.h                          |  1 +
>>  3 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> index 32381cc..d538a9b 100644
>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> @@ -18,6 +18,12 @@ Common properties:
>>                         property is needed on hwlock devices, where the number
>>                         of supported locks within a hwlock device cannot be
>>                         read from a register.
>> +- hwlock-base-id:      An unique base Id for the locks for a particular hwlock
>> +                       device. This property is mandatory ONLY if a SoC has
>> +                       several hwlock devices.
>> +
>> +                       See documentation on struct hwspinlock_pdata in
>> +                       include/linux/hwspinlock.h for more details.
> 
> The documentation cannot refer to kernel files. 

OK, good to know. There are couple of such existing references, so
didn't think it was an issue. I will fold this patch and remove the
kernel reference if this property is ok to add.

> Generally, creating a
> global number space like this would not be accepted, but I don't
> really have any better idea here.
> 
> Please put all binding docs in 1 patch and copy all the DT binding maintainers.

I have deliberately put these in separate patches (as RFC) as there
doesn't seem to be a consensus on this. I had added this originally,
dropped it and brought it back again based on discussion on the previous
version. Intention was either to fold into the original patch if
accepted or drop them and revisit later.

regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT
@ 2014-05-05 21:37       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-05 21:37 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Rob,

On 05/05/2014 03:37 PM, Rob Herring wrote:
> On Wed, Apr 30, 2014 at 7:34 PM, Suman Anna <s-anna@ti.com> wrote:
>> The HwSpinlock core requires a base id for registering a bank
>> of hwspinlocks. This base id needs to be unique across multiple
>> IP instances of a hwspinlock device, so that each hwlock can be
>> represented uniquely in a system.
>>
>> Support has been added to represent this in DT through a common
>> property 'hwlock-base-id', and retrieve the value through a core
>> OF helper function, of_hwspin_lock_get_base_id(). The representation
>> in DT provides a uniform way of assigning a fixed base value for a
>> hwspinlock device across different SoCs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>>  Documentation/devicetree/bindings/hwlock/hwlock.txt |  6 ++++++
>>  drivers/hwspinlock/hwspinlock_core.c                | 21 +++++++++++++++++++++
>>  include/linux/hwspinlock.h                          |  1 +
>>  3 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> index 32381cc..d538a9b 100644
>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>> @@ -18,6 +18,12 @@ Common properties:
>>                         property is needed on hwlock devices, where the number
>>                         of supported locks within a hwlock device cannot be
>>                         read from a register.
>> +- hwlock-base-id:      An unique base Id for the locks for a particular hwlock
>> +                       device. This property is mandatory ONLY if a SoC has
>> +                       several hwlock devices.
>> +
>> +                       See documentation on struct hwspinlock_pdata in
>> +                       include/linux/hwspinlock.h for more details.
> 
> The documentation cannot refer to kernel files. 

OK, good to know. There are couple of such existing references, so
didn't think it was an issue. I will fold this patch and remove the
kernel reference if this property is ok to add.

> Generally, creating a
> global number space like this would not be accepted, but I don't
> really have any better idea here.
> 
> Please put all binding docs in 1 patch and copy all the DT binding maintainers.

I have deliberately put these in separate patches (as RFC) as there
doesn't seem to be a consensus on this. I had added this originally,
dropped it and brought it back again based on discussion on the previous
version. Intention was either to fold into the original patch if
accepted or drop them and revisit later.

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
  2014-05-01  0:34   ` Suman Anna
  (?)
@ 2014-05-05 21:44     ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-05 21:44 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Rob Herring
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel

Hi Rob,

On 04/30/2014 07:34 PM, Suman Anna wrote:
> The property 'hwlock-reserved-locks' will be used to represent
> the number of locks to be reserved for clients that would need
> to request/operate on specific locks. A new OF helper function,
> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
> duplication in different platform implementations.
> 
> The function will return a value of 0 if the property is not
> defined, so as to support a default behavior of marking all
> locks as unused and open for anonymous allocations.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
>  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
>  include/linux/hwspinlock.h                         |  1 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> index d538a9b..88d16d2 100644
> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -18,6 +18,9 @@ Common properties:
>  			property is needed on hwlock devices, where the number
>  			of supported locks within a hwlock device cannot be
>  			read from a register.
> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
> +			specific locks. This value cannot exceed the value of
> +			hwlock-num-locks.

Any suggestions here on the approach? This property falls into a gray
area as well, as the current approach is somewhat limiting (it doesn't
support sparse reserved locks, and expects them at the beginning of the
lock range).

regards
Suman

>  - hwlock-base-id:	An unique base Id for the locks for a particular hwlock
>  			device. This property is mandatory ONLY if a SoC has
>  			several hwlock devices.
> diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
> index e05cea8..e74b55b 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
>  EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
>  
>  /**
> + * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
> + * @dn: device node pointer
> + *
> + * This is an OF helper function that can be called by the underlying platform
> + * specific implementations, to retrieve the number of locks to reserve from
> + * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
> + * property needs to be defined for requesting any DT-based locks.
> + *
> + * Returns a positive number of locks on success, a default value of 0 if the
> + * property is missing or an appropriate error code as returned by the OF layer
> + */
> +int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
> +{
> +	unsigned int val = 0;
> +	int ret;
> +
> +	ret = of_property_read_u32(dn, "hwlock-reserved-locks", &val);
> +	if (!ret || ret == -EINVAL)
> +		ret = val;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
> +
> +/**
>   * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
>   * @dn: device node pointer
>   *
> diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
> index d120035..d18431f 100644
> --- a/include/linux/hwspinlock.h
> +++ b/include/linux/hwspinlock.h
> @@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
>  				const struct of_phandle_args *hwlock_spec);
>  int of_hwspin_lock_get_base_id(struct device_node *dn);
>  int of_hwspin_lock_get_num_locks(struct device_node *dn);
> +int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
>  int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
>  		const struct hwspinlock_ops *ops, int base_id, int num_locks,
>  		int num_reserved_locks);
> 


^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-05 21:44     ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-05 21:44 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Rob Herring
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel

Hi Rob,

On 04/30/2014 07:34 PM, Suman Anna wrote:
> The property 'hwlock-reserved-locks' will be used to represent
> the number of locks to be reserved for clients that would need
> to request/operate on specific locks. A new OF helper function,
> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
> duplication in different platform implementations.
> 
> The function will return a value of 0 if the property is not
> defined, so as to support a default behavior of marking all
> locks as unused and open for anonymous allocations.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
>  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
>  include/linux/hwspinlock.h                         |  1 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> index d538a9b..88d16d2 100644
> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -18,6 +18,9 @@ Common properties:
>  			property is needed on hwlock devices, where the number
>  			of supported locks within a hwlock device cannot be
>  			read from a register.
> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
> +			specific locks. This value cannot exceed the value of
> +			hwlock-num-locks.

Any suggestions here on the approach? This property falls into a gray
area as well, as the current approach is somewhat limiting (it doesn't
support sparse reserved locks, and expects them at the beginning of the
lock range).

regards
Suman

>  - hwlock-base-id:	An unique base Id for the locks for a particular hwlock
>  			device. This property is mandatory ONLY if a SoC has
>  			several hwlock devices.
> diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
> index e05cea8..e74b55b 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
>  EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
>  
>  /**
> + * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
> + * @dn: device node pointer
> + *
> + * This is an OF helper function that can be called by the underlying platform
> + * specific implementations, to retrieve the number of locks to reserve from
> + * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
> + * property needs to be defined for requesting any DT-based locks.
> + *
> + * Returns a positive number of locks on success, a default value of 0 if the
> + * property is missing or an appropriate error code as returned by the OF layer
> + */
> +int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
> +{
> +	unsigned int val = 0;
> +	int ret;
> +
> +	ret = of_property_read_u32(dn, "hwlock-reserved-locks", &val);
> +	if (!ret || ret == -EINVAL)
> +		ret = val;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
> +
> +/**
>   * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
>   * @dn: device node pointer
>   *
> diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
> index d120035..d18431f 100644
> --- a/include/linux/hwspinlock.h
> +++ b/include/linux/hwspinlock.h
> @@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
>  				const struct of_phandle_args *hwlock_spec);
>  int of_hwspin_lock_get_base_id(struct device_node *dn);
>  int of_hwspin_lock_get_num_locks(struct device_node *dn);
> +int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
>  int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
>  		const struct hwspinlock_ops *ops, int base_id, int num_locks,
>  		int num_reserved_locks);
> 


^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-05 21:44     ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-05 21:44 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Rob,

On 04/30/2014 07:34 PM, Suman Anna wrote:
> The property 'hwlock-reserved-locks' will be used to represent
> the number of locks to be reserved for clients that would need
> to request/operate on specific locks. A new OF helper function,
> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
> duplication in different platform implementations.
> 
> The function will return a value of 0 if the property is not
> defined, so as to support a default behavior of marking all
> locks as unused and open for anonymous allocations.
> 
> Signed-off-by: Suman Anna <s-anna@ti.com>
> ---
>  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
>  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
>  include/linux/hwspinlock.h                         |  1 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> index d538a9b..88d16d2 100644
> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> @@ -18,6 +18,9 @@ Common properties:
>  			property is needed on hwlock devices, where the number
>  			of supported locks within a hwlock device cannot be
>  			read from a register.
> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
> +			specific locks. This value cannot exceed the value of
> +			hwlock-num-locks.

Any suggestions here on the approach? This property falls into a gray
area as well, as the current approach is somewhat limiting (it doesn't
support sparse reserved locks, and expects them at the beginning of the
lock range).

regards
Suman

>  - hwlock-base-id:	An unique base Id for the locks for a particular hwlock
>  			device. This property is mandatory ONLY if a SoC has
>  			several hwlock devices.
> diff --git a/drivers/hwspinlock/hwspinlock_core.c b/drivers/hwspinlock/hwspinlock_core.c
> index e05cea8..e74b55b 100644
> --- a/drivers/hwspinlock/hwspinlock_core.c
> +++ b/drivers/hwspinlock/hwspinlock_core.c
> @@ -286,6 +286,31 @@ int of_hwspin_lock_get_base_id(struct device_node *dn)
>  EXPORT_SYMBOL_GPL(of_hwspin_lock_get_base_id);
>  
>  /**
> + * of_hwspin_lock_get_num_reserved_locks() - retrieve number of reserved locks
> + * @dn: device node pointer
> + *
> + * This is an OF helper function that can be called by the underlying platform
> + * specific implementations, to retrieve the number of locks to reserve from
> + * the hwspinlock device instance's base id. The hwlock-reserved-locks DT
> + * property needs to be defined for requesting any DT-based locks.
> + *
> + * Returns a positive number of locks on success, a default value of 0 if the
> + * property is missing or an appropriate error code as returned by the OF layer
> + */
> +int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn)
> +{
> +	unsigned int val = 0;
> +	int ret;
> +
> +	ret = of_property_read_u32(dn, "hwlock-reserved-locks", &val);
> +	if (!ret || ret == -EINVAL)
> +		ret = val;
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(of_hwspin_lock_get_num_reserved_locks);
> +
> +/**
>   * of_hwspin_lock_get_num_locks() - OF helper to retrieve number of locks
>   * @dn: device node pointer
>   *
> diff --git a/include/linux/hwspinlock.h b/include/linux/hwspinlock.h
> index d120035..d18431f 100644
> --- a/include/linux/hwspinlock.h
> +++ b/include/linux/hwspinlock.h
> @@ -69,6 +69,7 @@ int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
>  				const struct of_phandle_args *hwlock_spec);
>  int of_hwspin_lock_get_base_id(struct device_node *dn);
>  int of_hwspin_lock_get_num_locks(struct device_node *dn);
> +int of_hwspin_lock_get_num_reserved_locks(struct device_node *dn);
>  int hwspin_lock_register(struct hwspinlock_device *bank, struct device *dev,
>  		const struct hwspinlock_ops *ops, int base_id, int num_locks,
>  		int num_reserved_locks);
> 

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-05 21:54       ` Josh Cartwright
  0 siblings, 0 replies; 111+ messages in thread
From: Josh Cartwright @ 2014-05-05 21:54 UTC (permalink / raw)
  To: Suman Anna
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Rob Herring,
	Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm-kernel

On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
> Hi Rob,
> 
> On 04/30/2014 07:34 PM, Suman Anna wrote:
> > The property 'hwlock-reserved-locks' will be used to represent
> > the number of locks to be reserved for clients that would need
> > to request/operate on specific locks. A new OF helper function,
> > of_hwspin_lock_get_num_reserved_locks(), is added to minimize
> > duplication in different platform implementations.
> > 
> > The function will return a value of 0 if the property is not
> > defined, so as to support a default behavior of marking all
> > locks as unused and open for anonymous allocations.
> > 
> > Signed-off-by: Suman Anna <s-anna@ti.com>
> > ---
> >  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
> >  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
> >  include/linux/hwspinlock.h                         |  1 +
> >  3 files changed, 29 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > index d538a9b..88d16d2 100644
> > --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > @@ -18,6 +18,9 @@ Common properties:
> >  			property is needed on hwlock devices, where the number
> >  			of supported locks within a hwlock device cannot be
> >  			read from a register.
> > +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
> > +			specific locks. This value cannot exceed the value of
> > +			hwlock-num-locks.
> 
> Any suggestions here on the approach? This property falls into a gray
> area as well, as the current approach is somewhat limiting (it doesn't
> support sparse reserved locks, and expects them at the beginning of the
> lock range).

Is it possible to implement a pinctrl-like hogging approach, whereby the
specific locks that need to be reserved are consumed by the controller
itself?

  Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-05 21:54       ` Josh Cartwright
  0 siblings, 0 replies; 111+ messages in thread
From: Josh Cartwright @ 2014-05-05 21:54 UTC (permalink / raw)
  To: Suman Anna
  Cc: Ohad Ben-Cohen, Mark Rutland, Kumar Gala, Rob Herring,
	Tony Lindgren, Josh Cartwright, Bjorn Andersson,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
> Hi Rob,
> 
> On 04/30/2014 07:34 PM, Suman Anna wrote:
> > The property 'hwlock-reserved-locks' will be used to represent
> > the number of locks to be reserved for clients that would need
> > to request/operate on specific locks. A new OF helper function,
> > of_hwspin_lock_get_num_reserved_locks(), is added to minimize
> > duplication in different platform implementations.
> > 
> > The function will return a value of 0 if the property is not
> > defined, so as to support a default behavior of marking all
> > locks as unused and open for anonymous allocations.
> > 
> > Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> > ---
> >  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
> >  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
> >  include/linux/hwspinlock.h                         |  1 +
> >  3 files changed, 29 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > index d538a9b..88d16d2 100644
> > --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > @@ -18,6 +18,9 @@ Common properties:
> >  			property is needed on hwlock devices, where the number
> >  			of supported locks within a hwlock device cannot be
> >  			read from a register.
> > +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
> > +			specific locks. This value cannot exceed the value of
> > +			hwlock-num-locks.
> 
> Any suggestions here on the approach? This property falls into a gray
> area as well, as the current approach is somewhat limiting (it doesn't
> support sparse reserved locks, and expects them at the beginning of the
> lock range).

Is it possible to implement a pinctrl-like hogging approach, whereby the
specific locks that need to be reserved are consumed by the controller
itself?

  Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-05 21:54       ` Josh Cartwright
  0 siblings, 0 replies; 111+ messages in thread
From: Josh Cartwright @ 2014-05-05 21:54 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
> Hi Rob,
> 
> On 04/30/2014 07:34 PM, Suman Anna wrote:
> > The property 'hwlock-reserved-locks' will be used to represent
> > the number of locks to be reserved for clients that would need
> > to request/operate on specific locks. A new OF helper function,
> > of_hwspin_lock_get_num_reserved_locks(), is added to minimize
> > duplication in different platform implementations.
> > 
> > The function will return a value of 0 if the property is not
> > defined, so as to support a default behavior of marking all
> > locks as unused and open for anonymous allocations.
> > 
> > Signed-off-by: Suman Anna <s-anna@ti.com>
> > ---
> >  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
> >  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
> >  include/linux/hwspinlock.h                         |  1 +
> >  3 files changed, 29 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > index d538a9b..88d16d2 100644
> > --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
> > @@ -18,6 +18,9 @@ Common properties:
> >  			property is needed on hwlock devices, where the number
> >  			of supported locks within a hwlock device cannot be
> >  			read from a register.
> > +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
> > +			specific locks. This value cannot exceed the value of
> > +			hwlock-num-locks.
> 
> Any suggestions here on the approach? This property falls into a gray
> area as well, as the current approach is somewhat limiting (it doesn't
> support sparse reserved locks, and expects them at the beginning of the
> lock range).

Is it possible to implement a pinctrl-like hogging approach, whereby the
specific locks that need to be reserved are consumed by the controller
itself?

  Josh

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
  2014-05-05 21:54       ` Josh Cartwright
  (?)
@ 2014-05-10  1:17         ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-10  1:17 UTC (permalink / raw)
  To: Josh Cartwright, Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Rob Herring, Tony Lindgren,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree,
	linux-arm-kernel

Hi Josh,

On 05/05/2014 04:54 PM, Josh Cartwright wrote:
> On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
>> Hi Rob,
>>
>> On 04/30/2014 07:34 PM, Suman Anna wrote:
>>> The property 'hwlock-reserved-locks' will be used to represent
>>> the number of locks to be reserved for clients that would need
>>> to request/operate on specific locks. A new OF helper function,
>>> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
>>> duplication in different platform implementations.
>>>
>>> The function will return a value of 0 if the property is not
>>> defined, so as to support a default behavior of marking all
>>> locks as unused and open for anonymous allocations.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>>  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
>>>  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
>>>  include/linux/hwspinlock.h                         |  1 +
>>>  3 files changed, 29 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> index d538a9b..88d16d2 100644
>>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> @@ -18,6 +18,9 @@ Common properties:
>>>  			property is needed on hwlock devices, where the number
>>>  			of supported locks within a hwlock device cannot be
>>>  			read from a register.
>>> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
>>> +			specific locks. This value cannot exceed the value of
>>> +			hwlock-num-locks.
>>
>> Any suggestions here on the approach? This property falls into a gray
>> area as well, as the current approach is somewhat limiting (it doesn't
>> support sparse reserved locks, and expects them at the beginning of the
>> lock range).
> 
> Is it possible to implement a pinctrl-like hogging approach, whereby the
> specific locks that need to be reserved are consumed by the controller
> itself?
> 

Thanks for the suggestion. I did take a look at pinctrl and while it is
possible to implement something similar, I feel it is a bit heavy for
hwspinlock framework with no added advantages. It requires that the
controller and clients always need to be updated together. Ohad had
already brought this up [1]. Here's an alternate approach that does not
require any additional property to the controller itself, while the
client node usage is as before. The logic is based on parsing through
the DT blob and marking only those that are used by any clients. The RFC
patch below is a replacement for Patches 11 to 15, and do not require
any changes to platform implementations or additional DT properties.

It currently marks locks as reserved even for disabled client nodes
(very easy to change that behavior). It will also impose a standard
property name "hwlocks" on the client nodes. What do you think of this
approach?

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139514977622964&w=2

----
>From 4f4cbe91e56c1be8faa6a3ee863add4df6e6714b Mon Sep 17 00:00:00 2001
From: Suman Anna <s-anna@ti.com>
Date: Fri, 9 May 2014 14:26:54 -0500
Subject: [RFC PATCH] hwspinlock/core: add support for reserved locks

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to mark certain locks as 'reserved'
by parsing through the DT blob. Thes

The HwSpinlock core has been enhanced to:
  1. mark certain locks as 'reserved' by parsing the DT blob for any
     locks used by client nodes.
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks for DT boots.
  3. limit these reserved locks to be allocated only using the
     _request_specific() API variants for DT boots.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c | 50
++++++++++++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..0c924c9 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -425,6 +425,42 @@ static int hwspinlock_device_add(struct
hwspinlock_device *bank)
        return ret;
 }

+static void hwspin_mark_reserved_locks(struct hwspinlock_device *bank)
+{
+       struct device_node *np = bank->dev->of_node;
+       const char *prop_name = "hwlocks";
+       const char *cells_name = "#hwlock-cells";
+       struct device_node *node = NULL;
+       struct of_phandle_args args;
+       struct hwspinlock *hwlock;
+       int i, id, count, ret;
+
+       for_each_node_with_property(node, prop_name) {
+               count = of_count_phandle_with_args(node, prop_name,
cells_name);
+               if (count <= 0)
+                       continue;
+
+               for (i = 0; i < count; i++) {
+                       ret = of_parse_phandle_with_args(node, prop_name,
+                                                        cells_name, i,
&args);
+                       if (ret || np != args.np)
+                               continue;
+
+                       id = bank->ops->of_xlate(bank, &args);
+                       if (id < 0 || id >= bank->num_locks)
+                               continue;
+
+                       hwlock = &bank->lock[id];
+                       if (hwlock->type == HWSPINLOCK_RESERVED) {
+                               dev_err(bank->dev, "potential reuse of
hwspinlock %d between multiple clients on %s\n",
+                                       id, np->full_name);
+                               continue;
+                       }
+                       hwlock->type = HWSPINLOCK_RESERVED;
+               }
+       }
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -463,12 +499,16 @@ int hwspin_lock_register(struct hwspinlock_device
*bank, struct device *dev,
        if (ret)
                return ret;

+       if (dev->of_node)
+               hwspin_mark_reserved_locks(bank);
+
        for (i = 0; i < num_locks; i++) {
                hwlock = &bank->lock[i];

                spin_lock_init(&hwlock->lock);
                hwlock->bank = bank;
-               hwlock->type = HWSPINLOCK_UNUSED;
+               if (hwlock->type != HWSPINLOCK_RESERVED)
+                       hwlock->type = HWSPINLOCK_UNUSED;

                ret = hwspin_lock_register_single(hwlock, base_id + i);
                if (ret)
@@ -651,7 +691,13 @@ struct hwspinlock
*hwspin_lock_request_specific(unsigned int id)
        /* sanity check (this shouldn't happen) */
        WARN_ON(hwlock_to_id(hwlock) != id);

-       /* make sure this hwspinlock is unused */
+       if (hwlock->type != HWSPINLOCK_RESERVED) {
+               pr_warn("hwspinlock %u is not a reserved lock\n", id);
+               hwlock = NULL;
+               goto out;
+       }
+
+       /* make sure this hwspinlock is an unused reserved lock */
        ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
        if (ret == 0) {
                pr_warn("hwspinlock %u is already in use\n", id);
-- 
1.9.2



^ permalink raw reply related	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-10  1:17         ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-10  1:17 UTC (permalink / raw)
  To: Josh Cartwright, Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Rob Herring, Tony Lindgren,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree,
	linux-arm-kernel

Hi Josh,

On 05/05/2014 04:54 PM, Josh Cartwright wrote:
> On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
>> Hi Rob,
>>
>> On 04/30/2014 07:34 PM, Suman Anna wrote:
>>> The property 'hwlock-reserved-locks' will be used to represent
>>> the number of locks to be reserved for clients that would need
>>> to request/operate on specific locks. A new OF helper function,
>>> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
>>> duplication in different platform implementations.
>>>
>>> The function will return a value of 0 if the property is not
>>> defined, so as to support a default behavior of marking all
>>> locks as unused and open for anonymous allocations.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>>  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
>>>  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
>>>  include/linux/hwspinlock.h                         |  1 +
>>>  3 files changed, 29 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> index d538a9b..88d16d2 100644
>>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> @@ -18,6 +18,9 @@ Common properties:
>>>  			property is needed on hwlock devices, where the number
>>>  			of supported locks within a hwlock device cannot be
>>>  			read from a register.
>>> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
>>> +			specific locks. This value cannot exceed the value of
>>> +			hwlock-num-locks.
>>
>> Any suggestions here on the approach? This property falls into a gray
>> area as well, as the current approach is somewhat limiting (it doesn't
>> support sparse reserved locks, and expects them at the beginning of the
>> lock range).
> 
> Is it possible to implement a pinctrl-like hogging approach, whereby the
> specific locks that need to be reserved are consumed by the controller
> itself?
> 

Thanks for the suggestion. I did take a look at pinctrl and while it is
possible to implement something similar, I feel it is a bit heavy for
hwspinlock framework with no added advantages. It requires that the
controller and clients always need to be updated together. Ohad had
already brought this up [1]. Here's an alternate approach that does not
require any additional property to the controller itself, while the
client node usage is as before. The logic is based on parsing through
the DT blob and marking only those that are used by any clients. The RFC
patch below is a replacement for Patches 11 to 15, and do not require
any changes to platform implementations or additional DT properties.

It currently marks locks as reserved even for disabled client nodes
(very easy to change that behavior). It will also impose a standard
property name "hwlocks" on the client nodes. What do you think of this
approach?

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139514977622964&w=2

----
>From 4f4cbe91e56c1be8faa6a3ee863add4df6e6714b Mon Sep 17 00:00:00 2001
From: Suman Anna <s-anna@ti.com>
Date: Fri, 9 May 2014 14:26:54 -0500
Subject: [RFC PATCH] hwspinlock/core: add support for reserved locks

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to mark certain locks as 'reserved'
by parsing through the DT blob. Thes

The HwSpinlock core has been enhanced to:
  1. mark certain locks as 'reserved' by parsing the DT blob for any
     locks used by client nodes.
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks for DT boots.
  3. limit these reserved locks to be allocated only using the
     _request_specific() API variants for DT boots.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c | 50
++++++++++++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..0c924c9 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -425,6 +425,42 @@ static int hwspinlock_device_add(struct
hwspinlock_device *bank)
        return ret;
 }

+static void hwspin_mark_reserved_locks(struct hwspinlock_device *bank)
+{
+       struct device_node *np = bank->dev->of_node;
+       const char *prop_name = "hwlocks";
+       const char *cells_name = "#hwlock-cells";
+       struct device_node *node = NULL;
+       struct of_phandle_args args;
+       struct hwspinlock *hwlock;
+       int i, id, count, ret;
+
+       for_each_node_with_property(node, prop_name) {
+               count = of_count_phandle_with_args(node, prop_name,
cells_name);
+               if (count <= 0)
+                       continue;
+
+               for (i = 0; i < count; i++) {
+                       ret = of_parse_phandle_with_args(node, prop_name,
+                                                        cells_name, i,
&args);
+                       if (ret || np != args.np)
+                               continue;
+
+                       id = bank->ops->of_xlate(bank, &args);
+                       if (id < 0 || id >= bank->num_locks)
+                               continue;
+
+                       hwlock = &bank->lock[id];
+                       if (hwlock->type == HWSPINLOCK_RESERVED) {
+                               dev_err(bank->dev, "potential reuse of
hwspinlock %d between multiple clients on %s\n",
+                                       id, np->full_name);
+                               continue;
+                       }
+                       hwlock->type = HWSPINLOCK_RESERVED;
+               }
+       }
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -463,12 +499,16 @@ int hwspin_lock_register(struct hwspinlock_device
*bank, struct device *dev,
        if (ret)
                return ret;

+       if (dev->of_node)
+               hwspin_mark_reserved_locks(bank);
+
        for (i = 0; i < num_locks; i++) {
                hwlock = &bank->lock[i];

                spin_lock_init(&hwlock->lock);
                hwlock->bank = bank;
-               hwlock->type = HWSPINLOCK_UNUSED;
+               if (hwlock->type != HWSPINLOCK_RESERVED)
+                       hwlock->type = HWSPINLOCK_UNUSED;

                ret = hwspin_lock_register_single(hwlock, base_id + i);
                if (ret)
@@ -651,7 +691,13 @@ struct hwspinlock
*hwspin_lock_request_specific(unsigned int id)
        /* sanity check (this shouldn't happen) */
        WARN_ON(hwlock_to_id(hwlock) != id);

-       /* make sure this hwspinlock is unused */
+       if (hwlock->type != HWSPINLOCK_RESERVED) {
+               pr_warn("hwspinlock %u is not a reserved lock\n", id);
+               hwlock = NULL;
+               goto out;
+       }
+
+       /* make sure this hwspinlock is an unused reserved lock */
        ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
        if (ret == 0) {
                pr_warn("hwspinlock %u is already in use\n", id);
-- 
1.9.2



^ permalink raw reply related	[flat|nested] 111+ messages in thread
* [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse reserved locks
@ 2014-05-10  1:17         ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-05-10  1:17 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Josh,

On 05/05/2014 04:54 PM, Josh Cartwright wrote:
> On Mon, May 05, 2014 at 04:44:25PM -0500, Suman Anna wrote:
>> Hi Rob,
>>
>> On 04/30/2014 07:34 PM, Suman Anna wrote:
>>> The property 'hwlock-reserved-locks' will be used to represent
>>> the number of locks to be reserved for clients that would need
>>> to request/operate on specific locks. A new OF helper function,
>>> of_hwspin_lock_get_num_reserved_locks(), is added to minimize
>>> duplication in different platform implementations.
>>>
>>> The function will return a value of 0 if the property is not
>>> defined, so as to support a default behavior of marking all
>>> locks as unused and open for anonymous allocations.
>>>
>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>> ---
>>>  .../devicetree/bindings/hwlock/hwlock.txt          |  3 +++
>>>  drivers/hwspinlock/hwspinlock_core.c               | 25 ++++++++++++++++++++++
>>>  include/linux/hwspinlock.h                         |  1 +
>>>  3 files changed, 29 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> index d538a9b..88d16d2 100644
>>> --- a/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> +++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
>>> @@ -18,6 +18,9 @@ Common properties:
>>>  			property is needed on hwlock devices, where the number
>>>  			of supported locks within a hwlock device cannot be
>>>  			read from a register.
>>> +- hwlock-reserved-locks: Number of locks to reserve for clients requiring
>>> +			specific locks. This value cannot exceed the value of
>>> +			hwlock-num-locks.
>>
>> Any suggestions here on the approach? This property falls into a gray
>> area as well, as the current approach is somewhat limiting (it doesn't
>> support sparse reserved locks, and expects them at the beginning of the
>> lock range).
> 
> Is it possible to implement a pinctrl-like hogging approach, whereby the
> specific locks that need to be reserved are consumed by the controller
> itself?
> 

Thanks for the suggestion. I did take a look at pinctrl and while it is
possible to implement something similar, I feel it is a bit heavy for
hwspinlock framework with no added advantages. It requires that the
controller and clients always need to be updated together. Ohad had
already brought this up [1]. Here's an alternate approach that does not
require any additional property to the controller itself, while the
client node usage is as before. The logic is based on parsing through
the DT blob and marking only those that are used by any clients. The RFC
patch below is a replacement for Patches 11 to 15, and do not require
any changes to platform implementations or additional DT properties.

It currently marks locks as reserved even for disabled client nodes
(very easy to change that behavior). It will also impose a standard
property name "hwlocks" on the client nodes. What do you think of this
approach?

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139514977622964&w=2

----
>From 4f4cbe91e56c1be8faa6a3ee863add4df6e6714b Mon Sep 17 00:00:00 2001
From: Suman Anna <s-anna@ti.com>
Date: Fri, 9 May 2014 14:26:54 -0500
Subject: [RFC PATCH] hwspinlock/core: add support for reserved locks

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.

The HwSpinlock core has been enhanced to mark certain locks as 'reserved'
by parsing through the DT blob. Thes

The HwSpinlock core has been enhanced to:
  1. mark certain locks as 'reserved' by parsing the DT blob for any
     locks used by client nodes.
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks for DT boots.
  3. limit these reserved locks to be allocated only using the
     _request_specific() API variants for DT boots.

Signed-off-by: Suman Anna <s-anna@ti.com>
---
 drivers/hwspinlock/hwspinlock_core.c | 50
++++++++++++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index c2063bc..0c924c9 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -425,6 +425,42 @@ static int hwspinlock_device_add(struct
hwspinlock_device *bank)
        return ret;
 }

+static void hwspin_mark_reserved_locks(struct hwspinlock_device *bank)
+{
+       struct device_node *np = bank->dev->of_node;
+       const char *prop_name = "hwlocks";
+       const char *cells_name = "#hwlock-cells";
+       struct device_node *node = NULL;
+       struct of_phandle_args args;
+       struct hwspinlock *hwlock;
+       int i, id, count, ret;
+
+       for_each_node_with_property(node, prop_name) {
+               count = of_count_phandle_with_args(node, prop_name,
cells_name);
+               if (count <= 0)
+                       continue;
+
+               for (i = 0; i < count; i++) {
+                       ret = of_parse_phandle_with_args(node, prop_name,
+                                                        cells_name, i,
&args);
+                       if (ret || np != args.np)
+                               continue;
+
+                       id = bank->ops->of_xlate(bank, &args);
+                       if (id < 0 || id >= bank->num_locks)
+                               continue;
+
+                       hwlock = &bank->lock[id];
+                       if (hwlock->type == HWSPINLOCK_RESERVED) {
+                               dev_err(bank->dev, "potential reuse of
hwspinlock %d between multiple clients on %s\n",
+                                       id, np->full_name);
+                               continue;
+                       }
+                       hwlock->type = HWSPINLOCK_RESERVED;
+               }
+       }
+}
+
 /**
  * hwspin_lock_register() - register a new hw spinlock device
  * @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -463,12 +499,16 @@ int hwspin_lock_register(struct hwspinlock_device
*bank, struct device *dev,
        if (ret)
                return ret;

+       if (dev->of_node)
+               hwspin_mark_reserved_locks(bank);
+
        for (i = 0; i < num_locks; i++) {
                hwlock = &bank->lock[i];

                spin_lock_init(&hwlock->lock);
                hwlock->bank = bank;
-               hwlock->type = HWSPINLOCK_UNUSED;
+               if (hwlock->type != HWSPINLOCK_RESERVED)
+                       hwlock->type = HWSPINLOCK_UNUSED;

                ret = hwspin_lock_register_single(hwlock, base_id + i);
                if (ret)
@@ -651,7 +691,13 @@ struct hwspinlock
*hwspin_lock_request_specific(unsigned int id)
        /* sanity check (this shouldn't happen) */
        WARN_ON(hwlock_to_id(hwlock) != id);

-       /* make sure this hwspinlock is unused */
+       if (hwlock->type != HWSPINLOCK_RESERVED) {
+               pr_warn("hwspinlock %u is not a reserved lock\n", id);
+               hwlock = NULL;
+               goto out;
+       }
+
+       /* make sure this hwspinlock is an unused reserved lock */
        ret = radix_tree_tag_get(&hwspinlock_tree, id, hwlock->type);
        if (ret == 0) {
                pr_warn("hwspinlock %u is already in use\n", id);
-- 
1.9.2

^ permalink raw reply related	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
  2014-05-01  0:34   ` Suman Anna
@ 2014-07-01 12:26     ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:26 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>
> The hwspinlock_device structure is used for registering a bank of
> locks with the driver core. The structure already contains the
> necessary members to identify the bank of locks. The core does not
> maintain the hwspinlock_devices itself, but maintains only a radix
> tree for all the registered locks. A specific lock can be requested
> by users using a global lock id, and any device-specific fields
> can be retrieved through a reference to the hwspinlock_device in
> each lock.
>
> The global lock id, however, is not friendly to be requested for
> users using the device-tree model. The device-tree representation
> will typically have each of the hwspinlock devices represented as
> a DT node, and a specific lock can be requested using the device's
> phandle and a lock specifier. Add support to the core therefore to
> maintain all the registered hwspinlock_devices, so that a device
> can be looked up and a specific lock belonging to the device
> requested through a phandle + args approach.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>

I'm not sure we need this patch.

It seems to me that the global lock id can be the base_id + lock
index, where the former should be a property of the parent dt node,
and the latter can just be the phandle argument. Then, with the global
lock id in hand, drivers could just use the existing
hwspin_lock_request_specific API.

If future hardware will bring a more complex scenario, we could then
introduce the xlate proposal to resolve it. As long as we're not
changing the dt data, and this is all handled by kernel code, then I'd
prefer opting for less code now as long as it addresses the
requirements.

Please let me know if currently there is a use case that can't be
addressed using this simpler model.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-01 12:26     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:26 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>
> The hwspinlock_device structure is used for registering a bank of
> locks with the driver core. The structure already contains the
> necessary members to identify the bank of locks. The core does not
> maintain the hwspinlock_devices itself, but maintains only a radix
> tree for all the registered locks. A specific lock can be requested
> by users using a global lock id, and any device-specific fields
> can be retrieved through a reference to the hwspinlock_device in
> each lock.
>
> The global lock id, however, is not friendly to be requested for
> users using the device-tree model. The device-tree representation
> will typically have each of the hwspinlock devices represented as
> a DT node, and a specific lock can be requested using the device's
> phandle and a lock specifier. Add support to the core therefore to
> maintain all the registered hwspinlock_devices, so that a device
> can be looked up and a specific lock belonging to the device
> requested through a phandle + args approach.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>

I'm not sure we need this patch.

It seems to me that the global lock id can be the base_id + lock
index, where the former should be a property of the parent dt node,
and the latter can just be the phandle argument. Then, with the global
lock id in hand, drivers could just use the existing
hwspin_lock_request_specific API.

If future hardware will bring a more complex scenario, we could then
introduce the xlate proposal to resolve it. As long as we're not
changing the dt data, and this is all handled by kernel code, then I'd
prefer opting for less code now as long as it addresses the
requirements.

Please let me know if currently there is a use case that can't be
addressed using this simpler model.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
  2014-05-01  0:34   ` Suman Anna
@ 2014-07-01 12:45     ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:45 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
> 2. The of_hwspin_lock_simple_xlate() is a simple default
>    translator function for hwspinlock provider implementations
>    that use a single cell number for requesting a specific lock
>    (relatively indexed) within a hwlock bank.

Do we have a use case today that require the xlate() method?

If not, let's remove it as we could always add it back if some new
hardware shows up that needs it.

As long as the dt data is unchanged, we should generally only add
kernel code that we really need.

> 3. The of_hwspin_lock_request_specific() API can be used by
>    hwspinlock clients to request a specific lock using the
>    phandle + args specifier. This function relies on the
>    implementation providing back a relative hwlock id within
>    the bank from the args specifier.

It seems to me we can just introduce a of_hwspin_lock_get_id() method
which will provide the global lock id to dt users, with which they
could just invoke the existing hwspin_lock_request_specific(). This
way we will have more common code between dt users and users who get
the lock id from a remote processor.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-01 12:45     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:45 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
> 2. The of_hwspin_lock_simple_xlate() is a simple default
>    translator function for hwspinlock provider implementations
>    that use a single cell number for requesting a specific lock
>    (relatively indexed) within a hwlock bank.

Do we have a use case today that require the xlate() method?

If not, let's remove it as we could always add it back if some new
hardware shows up that needs it.

As long as the dt data is unchanged, we should generally only add
kernel code that we really need.

> 3. The of_hwspin_lock_request_specific() API can be used by
>    hwspinlock clients to request a specific lock using the
>    phandle + args specifier. This function relies on the
>    implementation providing back a relative hwlock id within
>    the bank from the args specifier.

It seems to me we can just introduce a of_hwspin_lock_get_id() method
which will provide the global lock id to dt users, with which they
could just invoke the existing hwspin_lock_request_specific(). This
way we will have more common code between dt users and users who get
the lock id from a remote processor.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
  2014-05-01  0:34   ` Suman Anna
@ 2014-07-01 12:48     ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:48 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>  static int omap_hwspinlock_probe(struct platform_device *pdev)
>  {
> -       struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
> +       struct device_node *node = pdev->dev.of_node;
>         struct hwspinlock_device *bank;
>         struct hwspinlock *hwlock;
>         struct resource *res;
>         void __iomem *io_base;
>         int num_locks, i, ret;
> +       int base_id = 0;

We shouldn't implicitly assume base_id is zero: let's explicitly
protect against potential subsequent invocations of
omap_hwspinlock_probe.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
@ 2014-07-01 12:48     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:48 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>  static int omap_hwspinlock_probe(struct platform_device *pdev)
>  {
> -       struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
> +       struct device_node *node = pdev->dev.of_node;
>         struct hwspinlock_device *bank;
>         struct hwspinlock *hwlock;
>         struct resource *res;
>         void __iomem *io_base;
>         int num_locks, i, ret;
> +       int base_id = 0;

We shouldn't implicitly assume base_id is zero: let's explicitly
protect against potential subsequent invocations of
omap_hwspinlock_probe.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
  2014-05-01  0:34   ` Suman Anna
@ 2014-07-01 12:51     ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:51 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
> The number of hwspinlocks are determined based on the value read
> from the IP block's SYSSTATUS register. However, the module may
> not be enabled and clocked, and the read may result in a bus error.
>
> This particular issue is seen rather easily on AM33XX, since the
> module wakeup is software controlled, and it is disabled out of
> reset. Make sure the module is enabled and clocked before reading
> the SYSSTATUS register.

This seems like a valid fix that is independent of this patch series.

Feel free to submit it separately if you want, so we can get it merged.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
@ 2014-07-01 12:51     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:51 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
> The number of hwspinlocks are determined based on the value read
> from the IP block's SYSSTATUS register. However, the module may
> not be enabled and clocked, and the read may result in a bus error.
>
> This particular issue is seen rather easily on AM33XX, since the
> module wakeup is software controlled, and it is disabled out of
> reset. Make sure the module is enabled and clocked before reading
> the SYSSTATUS register.

This seems like a valid fix that is independent of this patch series.

Feel free to submit it separately if you want, so we can get it merged.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
@ 2014-07-01 12:53     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:53 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
> HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
> device families as well. The IPs are identical to that of
> OMAP4/OMAP5, except for the number of locks.
>
> Add a depends on to the above family of SoCs to enable the
> build support for OMAP hwspinlock driver for any of the above
> SoC configs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>

This looks too like an independent change. If you want it merged
without waiting for the entire series please submit it separately.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
@ 2014-07-01 12:53     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:53 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
> HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
> device families as well. The IPs are identical to that of
> OMAP4/OMAP5, except for the number of locks.
>
> Add a depends on to the above family of SoCs to enable the
> build support for OMAP hwspinlock driver for any of the above
> SoC configs.
>
> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>

This looks too like an independent change. If you want it merged
without waiting for the entire series please submit it separately.

Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
@ 2014-07-01 12:53     ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-01 12:53 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
> HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
> device families as well. The IPs are identical to that of
> OMAP4/OMAP5, except for the number of locks.
>
> Add a depends on to the above family of SoCs to enable the
> build support for OMAP hwspinlock driver for any of the above
> SoC configs.
>
> Signed-off-by: Suman Anna <s-anna@ti.com>

This looks too like an independent change. If you want it merged
without waiting for the entire series please submit it separately.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
  2014-07-01 12:51     ` Ohad Ben-Cohen
@ 2014-07-02 19:38       ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 19:38 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/01/2014 07:51 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>> The number of hwspinlocks are determined based on the value read
>> from the IP block's SYSSTATUS register. However, the module may
>> not be enabled and clocked, and the read may result in a bus error.
>>
>> This particular issue is seen rather easily on AM33XX, since the
>> module wakeup is software controlled, and it is disabled out of
>> reset. Make sure the module is enabled and clocked before reading
>> the SYSSTATUS register.
> 
> This seems like a valid fix that is independent of this patch series.
> 
> Feel free to submit it separately if you want, so we can get it merged.
> 

OK, I will submit this patch and Patch 7 separately.

regards
Suman



^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register
@ 2014-07-02 19:38       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 19:38 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/01/2014 07:51 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>> The number of hwspinlocks are determined based on the value read
>> from the IP block's SYSSTATUS register. However, the module may
>> not be enabled and clocked, and the read may result in a bus error.
>>
>> This particular issue is seen rather easily on AM33XX, since the
>> module wakeup is software controlled, and it is disabled out of
>> reset. Make sure the module is enabled and clocked before reading
>> the SYSSTATUS register.
> 
> This seems like a valid fix that is independent of this patch series.
> 
> Feel free to submit it separately if you want, so we can get it merged.
> 

OK, I will submit this patch and Patch 7 separately.

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
  2014-07-01 12:48     ` Ohad Ben-Cohen
@ 2014-07-02 19:42       ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 19:42 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/01/2014 07:48 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>>  static int omap_hwspinlock_probe(struct platform_device *pdev)
>>  {
>> -       struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
>> +       struct device_node *node = pdev->dev.of_node;
>>         struct hwspinlock_device *bank;
>>         struct hwspinlock *hwlock;
>>         struct resource *res;
>>         void __iomem *io_base;
>>         int num_locks, i, ret;
>> +       int base_id = 0;
> 
> We shouldn't implicitly assume base_id is zero: let's explicitly
> protect against potential subsequent invocations of
> omap_hwspinlock_probe.
> 

Yeah, I did this since we only had 1 instance, and used the same value
as used in the non-DT legacy code. Once I fold back Patch 8 that adds
the hwlock-base-id property, this will be assigned by reading that property.

regards
Suman


^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
@ 2014-07-02 19:42       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 19:42 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/01/2014 07:48 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>>  static int omap_hwspinlock_probe(struct platform_device *pdev)
>>  {
>> -       struct hwspinlock_pdata *pdata = pdev->dev.platform_data;
>> +       struct device_node *node = pdev->dev.of_node;
>>         struct hwspinlock_device *bank;
>>         struct hwspinlock *hwlock;
>>         struct resource *res;
>>         void __iomem *io_base;
>>         int num_locks, i, ret;
>> +       int base_id = 0;
> 
> We shouldn't implicitly assume base_id is zero: let's explicitly
> protect against potential subsequent invocations of
> omap_hwspinlock_probe.
> 

Yeah, I did this since we only had 1 instance, and used the same value
as used in the non-DT legacy code. Once I fold back Patch 8 that adds
the hwlock-base-id property, this will be assigned by reading that property.

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-02 21:14       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 21:14 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson, linux-kernel,
	linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/01/2014 07:26 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>>
>> The hwspinlock_device structure is used for registering a bank of
>> locks with the driver core. The structure already contains the
>> necessary members to identify the bank of locks. The core does not
>> maintain the hwspinlock_devices itself, but maintains only a radix
>> tree for all the registered locks. A specific lock can be requested
>> by users using a global lock id, and any device-specific fields
>> can be retrieved through a reference to the hwspinlock_device in
>> each lock.
>>
>> The global lock id, however, is not friendly to be requested for
>> users using the device-tree model. The device-tree representation
>> will typically have each of the hwspinlock devices represented as
>> a DT node, and a specific lock can be requested using the device's
>> phandle and a lock specifier. Add support to the core therefore to
>> maintain all the registered hwspinlock_devices, so that a device
>> can be looked up and a specific lock belonging to the device
>> requested through a phandle + args approach.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
> 
> I'm not sure we need this patch.

This patch is needed if we use the controller-phandle + args specifier
for requesting hwlocks by a client, as we need to translate
controller-phandle to the corresponding hwspinlock_device.

Looks like we still don't have a closure on the semantics of how
clients have to request a lock in DT. You are suggesting something like
    hwlocks = <global_lock1 global_lock2 ...>;

whereas this patch is built to support based on comments from
DT-maintainers,
    hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
lock-specifier2>...;

Mark, Kumar,
We need your input here as DT maintainers. Some of the discussion is on
the v4 cover-letter thread [1].

Kumar, Josh,
How does this fit with the MSM spinlock driver?

> It seems to me that the global lock id can be the base_id + lock
> index, where the former should be a property of the parent dt node,
> and the latter can just be the phandle argument. Then, with the global
> lock id in hand, drivers could just use the existing
> hwspin_lock_request_specific API.
> 
> If future hardware will bring a more complex scenario, we could then
> introduce the xlate proposal to resolve it. As long as we're not
> changing the dt data, and this is all handled by kernel code, 

Once we define dt data one way, how can we support a different mechanism
later on? Are you implying that we support both controller-phandle +
specifier and global-lock convention somehow through driver changes?

> then I'd
> prefer opting for less code now as long as it addresses the
> requirements.
> 
> Please let me know if currently there is a use case that can't be
> addressed using this simpler model.

This is just a question of DT semantics for the longer term, it can be
done both ways. I have started out the series with exactly what you are
suggesting here.

regards
Suman

[1] https://lkml.org/lkml/2014/3/17/576


^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-02 21:14       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 21:14 UTC (permalink / raw)
  To: Ohad Ben-Cohen, Mark Rutland, Kumar Gala
  Cc: Tony Lindgren, Josh Cartwright, Bjorn Andersson,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm

Hi Ohad,

On 07/01/2014 07:26 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
>>
>> The hwspinlock_device structure is used for registering a bank of
>> locks with the driver core. The structure already contains the
>> necessary members to identify the bank of locks. The core does not
>> maintain the hwspinlock_devices itself, but maintains only a radix
>> tree for all the registered locks. A specific lock can be requested
>> by users using a global lock id, and any device-specific fields
>> can be retrieved through a reference to the hwspinlock_device in
>> each lock.
>>
>> The global lock id, however, is not friendly to be requested for
>> users using the device-tree model. The device-tree representation
>> will typically have each of the hwspinlock devices represented as
>> a DT node, and a specific lock can be requested using the device's
>> phandle and a lock specifier. Add support to the core therefore to
>> maintain all the registered hwspinlock_devices, so that a device
>> can be looked up and a specific lock belonging to the device
>> requested through a phandle + args approach.
>>
>> Signed-off-by: Suman Anna <s-anna-l0cyMroinI0@public.gmane.org>
> 
> I'm not sure we need this patch.

This patch is needed if we use the controller-phandle + args specifier
for requesting hwlocks by a client, as we need to translate
controller-phandle to the corresponding hwspinlock_device.

Looks like we still don't have a closure on the semantics of how
clients have to request a lock in DT. You are suggesting something like
    hwlocks = <global_lock1 global_lock2 ...>;

whereas this patch is built to support based on comments from
DT-maintainers,
    hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
lock-specifier2>...;

Mark, Kumar,
We need your input here as DT maintainers. Some of the discussion is on
the v4 cover-letter thread [1].

Kumar, Josh,
How does this fit with the MSM spinlock driver?

> It seems to me that the global lock id can be the base_id + lock
> index, where the former should be a property of the parent dt node,
> and the latter can just be the phandle argument. Then, with the global
> lock id in hand, drivers could just use the existing
> hwspin_lock_request_specific API.
> 
> If future hardware will bring a more complex scenario, we could then
> introduce the xlate proposal to resolve it. As long as we're not
> changing the dt data, and this is all handled by kernel code, 

Once we define dt data one way, how can we support a different mechanism
later on? Are you implying that we support both controller-phandle +
specifier and global-lock convention somehow through driver changes?

> then I'd
> prefer opting for less code now as long as it addresses the
> requirements.
> 
> Please let me know if currently there is a use case that can't be
> addressed using this simpler model.

This is just a question of DT semantics for the longer term, it can be
done both ways. I have started out the series with exactly what you are
suggesting here.

regards
Suman

[1] https://lkml.org/lkml/2014/3/17/576

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-02 21:14       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 21:14 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/01/2014 07:26 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>>
>> The hwspinlock_device structure is used for registering a bank of
>> locks with the driver core. The structure already contains the
>> necessary members to identify the bank of locks. The core does not
>> maintain the hwspinlock_devices itself, but maintains only a radix
>> tree for all the registered locks. A specific lock can be requested
>> by users using a global lock id, and any device-specific fields
>> can be retrieved through a reference to the hwspinlock_device in
>> each lock.
>>
>> The global lock id, however, is not friendly to be requested for
>> users using the device-tree model. The device-tree representation
>> will typically have each of the hwspinlock devices represented as
>> a DT node, and a specific lock can be requested using the device's
>> phandle and a lock specifier. Add support to the core therefore to
>> maintain all the registered hwspinlock_devices, so that a device
>> can be looked up and a specific lock belonging to the device
>> requested through a phandle + args approach.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
> 
> I'm not sure we need this patch.

This patch is needed if we use the controller-phandle + args specifier
for requesting hwlocks by a client, as we need to translate
controller-phandle to the corresponding hwspinlock_device.

Looks like we still don't have a closure on the semantics of how
clients have to request a lock in DT. You are suggesting something like
    hwlocks = <global_lock1 global_lock2 ...>;

whereas this patch is built to support based on comments from
DT-maintainers,
    hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
lock-specifier2>...;

Mark, Kumar,
We need your input here as DT maintainers. Some of the discussion is on
the v4 cover-letter thread [1].

Kumar, Josh,
How does this fit with the MSM spinlock driver?

> It seems to me that the global lock id can be the base_id + lock
> index, where the former should be a property of the parent dt node,
> and the latter can just be the phandle argument. Then, with the global
> lock id in hand, drivers could just use the existing
> hwspin_lock_request_specific API.
> 
> If future hardware will bring a more complex scenario, we could then
> introduce the xlate proposal to resolve it. As long as we're not
> changing the dt data, and this is all handled by kernel code, 

Once we define dt data one way, how can we support a different mechanism
later on? Are you implying that we support both controller-phandle +
specifier and global-lock convention somehow through driver changes?

> then I'd
> prefer opting for less code now as long as it addresses the
> requirements.
> 
> Please let me know if currently there is a use case that can't be
> addressed using this simpler model.

This is just a question of DT semantics for the longer term, it can be
done both ways. I have started out the series with exactly what you are
suggesting here.

regards
Suman

[1] https://lkml.org/lkml/2014/3/17/576

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
  2014-07-01 12:45     ` Ohad Ben-Cohen
@ 2014-07-02 21:14       ` Suman Anna
  -1 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 21:14 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

>
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>> 2. The of_hwspin_lock_simple_xlate() is a simple default
>>    translator function for hwspinlock provider implementations
>>    that use a single cell number for requesting a specific lock
>>    (relatively indexed) within a hwlock bank.
> 
> Do we have a use case today that require the xlate() method?
> 
> If not, let's remove it as we could always add it back if some new
> hardware shows up that needs it.

The xlate() method is to support the phandle + args specifier way of
requesting hwlocks, platform implementations are free to implement their
own xlate functions, but the above supports the simplest case of
controller + relative lock index within controller.

> 
> As long as the dt data is unchanged, we should generally only add
> kernel code that we really need.
> 
>> 3. The of_hwspin_lock_request_specific() API can be used by
>>    hwspinlock clients to request a specific lock using the
>>    phandle + args specifier. This function relies on the
>>    implementation providing back a relative hwlock id within
>>    the bank from the args specifier.
> 
> It seems to me we can just introduce a of_hwspin_lock_get_id() method
> which will provide the global lock id to dt users, with which they
> could just invoke the existing hwspin_lock_request_specific(). This
> way we will have more common code between dt users and users who get
> the lock id from a remote processor.

This function again is to support the phandle + args specifier way of
requesting hwlocks, the hwspin_lock_request_specific() is invoked
internally within this function, so we are still reusing the actual
request code other than handling the DT parsing portion. If we go back
to using global locks in client hwlocks property, we don't need a
of_hwspin_lock_get_id(), the same can be achieved using the existing DT
function, of_property_read_u32_index().

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-02 21:14       ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-02 21:14 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

>
> On Thu, May 1, 2014 at 3:34 AM, Suman Anna <s-anna@ti.com> wrote:
>> 2. The of_hwspin_lock_simple_xlate() is a simple default
>>    translator function for hwspinlock provider implementations
>>    that use a single cell number for requesting a specific lock
>>    (relatively indexed) within a hwlock bank.
> 
> Do we have a use case today that require the xlate() method?
> 
> If not, let's remove it as we could always add it back if some new
> hardware shows up that needs it.

The xlate() method is to support the phandle + args specifier way of
requesting hwlocks, platform implementations are free to implement their
own xlate functions, but the above supports the simplest case of
controller + relative lock index within controller.

> 
> As long as the dt data is unchanged, we should generally only add
> kernel code that we really need.
> 
>> 3. The of_hwspin_lock_request_specific() API can be used by
>>    hwspinlock clients to request a specific lock using the
>>    phandle + args specifier. This function relies on the
>>    implementation providing back a relative hwlock id within
>>    the bank from the args specifier.
> 
> It seems to me we can just introduce a of_hwspin_lock_get_id() method
> which will provide the global lock id to dt users, with which they
> could just invoke the existing hwspin_lock_request_specific(). This
> way we will have more common code between dt users and users who get
> the lock id from a remote processor.

This function again is to support the phandle + args specifier way of
requesting hwlocks, the hwspin_lock_request_specific() is invoked
internally within this function, so we are still reusing the actual
request code other than handling the DT parsing portion. If we go back
to using global locks in client hwlocks property, we don't need a
of_hwspin_lock_get_id(), the same can be achieved using the existing DT
function, of_property_read_u32_index().

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
  2014-07-02 21:14       ` Suman Anna
@ 2014-07-03  7:00         ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-03  7:00 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>> I'm not sure we need this patch.
>
> This patch is needed if we use the controller-phandle + args specifier
> for requesting hwlocks by a client, as we need to translate
> controller-phandle to the corresponding hwspinlock_device.
>
> Looks like we still don't have a closure on the semantics of how
> clients have to request a lock in DT. You are suggesting something like
>     hwlocks = <global_lock1 global_lock2 ...>;
>
> whereas this patch is built to support based on comments from
> DT-maintainers,
>     hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
> lock-specifier2>...;

I'm actually ok with this suggestion and haven't suggested otherwise.

All I propose is that we add the base_id property to the controller
node (as you have done in the subsequent patches), and then drivers
will be able to infer the global lock id from the DT data by adding
the controller's base_id to the lock specifier.

Controllers with non standard lock indexing may use an xlate() method
if needed but frankly this is fictional right now. We can start
without this, and add it later when needed, as this doesn't affect the
DT data.

With the global lock id in hand, drivers could simply use the existing
hwspin_lock_request_specific API to obtain a specific lock, and then
we don't need this patch.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-03  7:00         ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-03  7:00 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>> I'm not sure we need this patch.
>
> This patch is needed if we use the controller-phandle + args specifier
> for requesting hwlocks by a client, as we need to translate
> controller-phandle to the corresponding hwspinlock_device.
>
> Looks like we still don't have a closure on the semantics of how
> clients have to request a lock in DT. You are suggesting something like
>     hwlocks = <global_lock1 global_lock2 ...>;
>
> whereas this patch is built to support based on comments from
> DT-maintainers,
>     hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
> lock-specifier2>...;

I'm actually ok with this suggestion and haven't suggested otherwise.

All I propose is that we add the base_id property to the controller
node (as you have done in the subsequent patches), and then drivers
will be able to infer the global lock id from the DT data by adding
the controller's base_id to the lock specifier.

Controllers with non standard lock indexing may use an xlate() method
if needed but frankly this is fictional right now. We can start
without this, and add it later when needed, as this doesn't affect the
DT data.

With the global lock id in hand, drivers could simply use the existing
hwspin_lock_request_specific API to obtain a specific lock, and then
we don't need this patch.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
  2014-07-02 21:14       ` Suman Anna
@ 2014-07-03  7:15         ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-03  7:15 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>> Do we have a use case today that require the xlate() method?
>>
>> If not, let's remove it as we could always add it back if some new
>> hardware shows up that needs it.
>
> The xlate() method is to support the phandle + args specifier way of
> requesting hwlocks, platform implementations are free to implement their
> own xlate functions, but the above supports the simplest case of
> controller + relative lock index within controller.

Do we have a use case for a different implementation other than the
simplest case? If not, it seems to me this will just become redundant
boilerplate code (every platform will use the simple xlate method).

> This function again is to support the phandle + args specifier way of
> requesting hwlocks, the hwspin_lock_request_specific() is invoked
> internally within this function, so we are still reusing the actual
> request code other than handling the DT parsing portion. If we go back
> to using global locks in client hwlocks property, we don't need a
> of_hwspin_lock_get_id(), the same can be achieved using the existing DT
> function, of_property_read_u32_index().

I think you may have misunderstood me, sorry. I'm ok with the phandle
+ args specifier. I just think we can use it, together with the
base_id property, to infer the global lock id from the DT data. This
is not only a must to support heterogenous multi-processing systems,
it will also substantially simplify the code.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-03  7:15         ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-03  7:15 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>> Do we have a use case today that require the xlate() method?
>>
>> If not, let's remove it as we could always add it back if some new
>> hardware shows up that needs it.
>
> The xlate() method is to support the phandle + args specifier way of
> requesting hwlocks, platform implementations are free to implement their
> own xlate functions, but the above supports the simplest case of
> controller + relative lock index within controller.

Do we have a use case for a different implementation other than the
simplest case? If not, it seems to me this will just become redundant
boilerplate code (every platform will use the simple xlate method).

> This function again is to support the phandle + args specifier way of
> requesting hwlocks, the hwspin_lock_request_specific() is invoked
> internally within this function, so we are still reusing the actual
> request code other than handling the DT parsing portion. If we go back
> to using global locks in client hwlocks property, we don't need a
> of_hwspin_lock_get_id(), the same can be achieved using the existing DT
> function, of_property_read_u32_index().

I think you may have misunderstood me, sorry. I'm ok with the phandle
+ args specifier. I just think we can use it, together with the
base_id property, to infer the global lock id from the DT data. This
is not only a must to support heterogenous multi-processing systems,
it will also substantially simplify the code.

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
  2014-07-02 19:42       ` Suman Anna
@ 2014-07-03  7:25         ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-03  7:25 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

On Wed, Jul 2, 2014 at 10:42 PM, Suman Anna <s-anna@ti.com> wrote:
> Yeah, I did this since we only had 1 instance, and used the same value
> as used in the non-DT legacy code. Once I fold back Patch 8 that adds
> the hwlock-base-id property, this will be assigned by reading that property.

Sounds good, thanks!

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes
@ 2014-07-03  7:25         ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-03  7:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jul 2, 2014 at 10:42 PM, Suman Anna <s-anna@ti.com> wrote:
> Yeah, I did this since we only had 1 instance, and used the same value
> as used in the non-DT legacy code. Once I fold back Patch 8 that adds
> the hwlock-base-id property, this will be assigned by reading that property.

Sounds good, thanks!

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-03 17:28           ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-03 17:28 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/03/2014 02:00 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>>> I'm not sure we need this patch.
>>
>> This patch is needed if we use the controller-phandle + args specifier
>> for requesting hwlocks by a client, as we need to translate
>> controller-phandle to the corresponding hwspinlock_device.
>>
>> Looks like we still don't have a closure on the semantics of how
>> clients have to request a lock in DT. You are suggesting something like
>>     hwlocks = <global_lock1 global_lock2 ...>;
>>
>> whereas this patch is built to support based on comments from
>> DT-maintainers,
>>     hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
>> lock-specifier2>...;
> 
> I'm actually ok with this suggestion and haven't suggested otherwise.

OK, thanks for confirming and sorry for the misinterpretation.

> 
> All I propose is that we add the base_id property to the controller
> node (as you have done in the subsequent patches), and then drivers
> will be able to infer the global lock id from the DT data by adding
> the controller's base_id to the lock specifier.

OK, but we would still require this function to lookup the registered
device from the controller-phandle to retrieve the base_id. Do note that
the hwspinlock core currently only maintains the registered locks in an
integrated radix tree, but not the registered hwspinlock banks themselves.

regards
Suman

> Controllers with non standard lock indexing may use an xlate() method
> if needed but frankly this is fictional right now. We can start
> without this, and add it later when needed, as this doesn't affect the
> DT data.
> 
> With the global lock id in hand, drivers could simply use the existing
> hwspin_lock_request_specific API to obtain a specific lock, and then
> we don't need this patch.
> 
> Thanks,
> Ohad.
> 


^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-03 17:28           ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-03 17:28 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm

Hi Ohad,

On 07/03/2014 02:00 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
>>> I'm not sure we need this patch.
>>
>> This patch is needed if we use the controller-phandle + args specifier
>> for requesting hwlocks by a client, as we need to translate
>> controller-phandle to the corresponding hwspinlock_device.
>>
>> Looks like we still don't have a closure on the semantics of how
>> clients have to request a lock in DT. You are suggesting something like
>>     hwlocks = <global_lock1 global_lock2 ...>;
>>
>> whereas this patch is built to support based on comments from
>> DT-maintainers,
>>     hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
>> lock-specifier2>...;
> 
> I'm actually ok with this suggestion and haven't suggested otherwise.

OK, thanks for confirming and sorry for the misinterpretation.

> 
> All I propose is that we add the base_id property to the controller
> node (as you have done in the subsequent patches), and then drivers
> will be able to infer the global lock id from the DT data by adding
> the controller's base_id to the lock specifier.

OK, but we would still require this function to lookup the registered
device from the controller-phandle to retrieve the base_id. Do note that
the hwspinlock core currently only maintains the registered locks in an
integrated radix tree, but not the registered hwspinlock banks themselves.

regards
Suman

> Controllers with non standard lock indexing may use an xlate() method
> if needed but frankly this is fictional right now. We can start
> without this, and add it later when needed, as this doesn't affect the
> DT data.
> 
> With the global lock id in hand, drivers could simply use the existing
> hwspin_lock_request_specific API to obtain a specific lock, and then
> we don't need this patch.
> 
> Thanks,
> Ohad.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-03 17:28           ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-03 17:28 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/03/2014 02:00 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>>> I'm not sure we need this patch.
>>
>> This patch is needed if we use the controller-phandle + args specifier
>> for requesting hwlocks by a client, as we need to translate
>> controller-phandle to the corresponding hwspinlock_device.
>>
>> Looks like we still don't have a closure on the semantics of how
>> clients have to request a lock in DT. You are suggesting something like
>>     hwlocks = <global_lock1 global_lock2 ...>;
>>
>> whereas this patch is built to support based on comments from
>> DT-maintainers,
>>     hwlocks = <controller-phandle lock-specifier1>, <controller-phandle
>> lock-specifier2>...;
> 
> I'm actually ok with this suggestion and haven't suggested otherwise.

OK, thanks for confirming and sorry for the misinterpretation.

> 
> All I propose is that we add the base_id property to the controller
> node (as you have done in the subsequent patches), and then drivers
> will be able to infer the global lock id from the DT data by adding
> the controller's base_id to the lock specifier.

OK, but we would still require this function to lookup the registered
device from the controller-phandle to retrieve the base_id. Do note that
the hwspinlock core currently only maintains the registered locks in an
integrated radix tree, but not the registered hwspinlock banks themselves.

regards
Suman

> Controllers with non standard lock indexing may use an xlate() method
> if needed but frankly this is fictional right now. We can start
> without this, and add it later when needed, as this doesn't affect the
> DT data.
> 
> With the global lock id in hand, drivers could simply use the existing
> hwspin_lock_request_specific API to obtain a specific lock, and then
> we don't need this patch.
> 
> Thanks,
> Ohad.
> 

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-03 17:35           ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-03 17:35 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/03/2014 02:15 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>>> Do we have a use case today that require the xlate() method?
>>>
>>> If not, let's remove it as we could always add it back if some new
>>> hardware shows up that needs it.
>>
>> The xlate() method is to support the phandle + args specifier way of
>> requesting hwlocks, platform implementations are free to implement their
>> own xlate functions, but the above supports the simplest case of
>> controller + relative lock index within controller.
> 
> Do we have a use case for a different implementation other than the
> simplest case? If not, it seems to me this will just become redundant
> boilerplate code (every platform will use the simple xlate method).

Not at the moment, with the existing platform implementations. So, if I
understand you correctly, you are asking to leave out the xlate ops and
make the of_hwspin_lock_simple_xlate() internal until a need for an
xlate method arises. This also means, we only support a value of 1 for
#hwlock-cells.

> 
>> This function again is to support the phandle + args specifier way of
>> requesting hwlocks, the hwspin_lock_request_specific() is invoked
>> internally within this function, so we are still reusing the actual
>> request code other than handling the DT parsing portion. If we go back
>> to using global locks in client hwlocks property, we don't need a
>> of_hwspin_lock_get_id(), the same can be achieved using the existing DT
>> function, of_property_read_u32_index().
> 
> I think you may have misunderstood me, sorry. I'm ok with the phandle
> + args specifier. I just think we can use it, together with the
> base_id property, to infer the global lock id from the DT data. 

Aah ok, its minor code rearrangement for what you are asking - I just
need to leave out invoking the request_specific invocation in the OF
request specific existing function, just return the global id and let
the client users call the normal request_specific API themselves.

But, that would mean DT-based client users would have to invoke two
function calls to request a hwspinlock. We already have an API to get
the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
API for requesting a lock directly rather than giving an OF API for
getting the lock id. This is in keeping in convention with what other
drivers do normally - a regular get and an OF get. I can modify it if
you still prefer the OF API for getting a global lock id, but I feel its
a burden for client users.

Also, do you prefer an open property-name in client users (like I am
doing at the moment) or imposing a standard property name "hwlocks"?

regards
Suman

> This is not only a must to support heterogenous multi-processing systems,
> it will also substantially simplify the code.
> 
> Thanks,
> Ohad.
> 


^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-03 17:35           ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-03 17:35 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm

Hi Ohad,

On 07/03/2014 02:15 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
>>> Do we have a use case today that require the xlate() method?
>>>
>>> If not, let's remove it as we could always add it back if some new
>>> hardware shows up that needs it.
>>
>> The xlate() method is to support the phandle + args specifier way of
>> requesting hwlocks, platform implementations are free to implement their
>> own xlate functions, but the above supports the simplest case of
>> controller + relative lock index within controller.
> 
> Do we have a use case for a different implementation other than the
> simplest case? If not, it seems to me this will just become redundant
> boilerplate code (every platform will use the simple xlate method).

Not at the moment, with the existing platform implementations. So, if I
understand you correctly, you are asking to leave out the xlate ops and
make the of_hwspin_lock_simple_xlate() internal until a need for an
xlate method arises. This also means, we only support a value of 1 for
#hwlock-cells.

> 
>> This function again is to support the phandle + args specifier way of
>> requesting hwlocks, the hwspin_lock_request_specific() is invoked
>> internally within this function, so we are still reusing the actual
>> request code other than handling the DT parsing portion. If we go back
>> to using global locks in client hwlocks property, we don't need a
>> of_hwspin_lock_get_id(), the same can be achieved using the existing DT
>> function, of_property_read_u32_index().
> 
> I think you may have misunderstood me, sorry. I'm ok with the phandle
> + args specifier. I just think we can use it, together with the
> base_id property, to infer the global lock id from the DT data. 

Aah ok, its minor code rearrangement for what you are asking - I just
need to leave out invoking the request_specific invocation in the OF
request specific existing function, just return the global id and let
the client users call the normal request_specific API themselves.

But, that would mean DT-based client users would have to invoke two
function calls to request a hwspinlock. We already have an API to get
the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
API for requesting a lock directly rather than giving an OF API for
getting the lock id. This is in keeping in convention with what other
drivers do normally - a regular get and an OF get. I can modify it if
you still prefer the OF API for getting a global lock id, but I feel its
a burden for client users.

Also, do you prefer an open property-name in client users (like I am
doing at the moment) or imposing a standard property name "hwlocks"?

regards
Suman

> This is not only a must to support heterogenous multi-processing systems,
> it will also substantially simplify the code.
> 
> Thanks,
> Ohad.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-03 17:35           ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-03 17:35 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/03/2014 02:15 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 12:14 AM, Suman Anna <s-anna@ti.com> wrote:
>>> Do we have a use case today that require the xlate() method?
>>>
>>> If not, let's remove it as we could always add it back if some new
>>> hardware shows up that needs it.
>>
>> The xlate() method is to support the phandle + args specifier way of
>> requesting hwlocks, platform implementations are free to implement their
>> own xlate functions, but the above supports the simplest case of
>> controller + relative lock index within controller.
> 
> Do we have a use case for a different implementation other than the
> simplest case? If not, it seems to me this will just become redundant
> boilerplate code (every platform will use the simple xlate method).

Not at the moment, with the existing platform implementations. So, if I
understand you correctly, you are asking to leave out the xlate ops and
make the of_hwspin_lock_simple_xlate() internal until a need for an
xlate method arises. This also means, we only support a value of 1 for
#hwlock-cells.

> 
>> This function again is to support the phandle + args specifier way of
>> requesting hwlocks, the hwspin_lock_request_specific() is invoked
>> internally within this function, so we are still reusing the actual
>> request code other than handling the DT parsing portion. If we go back
>> to using global locks in client hwlocks property, we don't need a
>> of_hwspin_lock_get_id(), the same can be achieved using the existing DT
>> function, of_property_read_u32_index().
> 
> I think you may have misunderstood me, sorry. I'm ok with the phandle
> + args specifier. I just think we can use it, together with the
> base_id property, to infer the global lock id from the DT data. 

Aah ok, its minor code rearrangement for what you are asking - I just
need to leave out invoking the request_specific invocation in the OF
request specific existing function, just return the global id and let
the client users call the normal request_specific API themselves.

But, that would mean DT-based client users would have to invoke two
function calls to request a hwspinlock. We already have an API to get
the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
API for requesting a lock directly rather than giving an OF API for
getting the lock id. This is in keeping in convention with what other
drivers do normally - a regular get and an OF get. I can modify it if
you still prefer the OF API for getting a global lock id, but I feel its
a burden for client users.

Also, do you prefer an open property-name in client users (like I am
doing at the moment) or imposing a standard property name "hwlocks"?

regards
Suman

> This is not only a must to support heterogenous multi-processing systems,
> it will also substantially simplify the code.
> 
> Thanks,
> Ohad.
> 

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
  2014-07-03 17:35           ` Suman Anna
@ 2014-07-04  4:58             ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-04  4:58 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna <s-anna@ti.com> wrote:
> Not at the moment, with the existing platform implementations. So, if I
> understand you correctly, you are asking to leave out the xlate ops and
> make the of_hwspin_lock_simple_xlate() internal until a need for an
> xlate method arises.

Yes, please. It seems to me this way we're reducing complexity without
compromising anything.

> This also means, we only support a value of 1 for #hwlock-cells.

When a different #hwlock-cells value shows up, someone would have to
write a new xlate implementation anyway. At the same time, the xlate
ops could be brought back quite easily.

Since we're not imposing anything on the DT data, this doesn't affect
our ability to support these scenarios in the future, but unless I'm
missing a current use case, these scenarios right now seems somewhat
fictional.

> But, that would mean DT-based client users would have to invoke two
> function calls to request a hwspinlock. We already have an API to get
> the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
> API for requesting a lock directly rather than giving an OF API for
> getting the lock id. This is in keeping in convention with what other
> drivers do normally - a regular get and an OF get. I can modify it if
> you still prefer the OF API for getting a global lock id, but I feel its
> a burden for client users.

Let's discuss this.

I was actually thinking of the more general use case of an heterogenous system:

- driver gets the global lock id from a remote processor
- driver then requests the specific lock

Looking at these cases, the OF scenario only differs in the small part
of fetching the lock id, and if we keep the regular request_specific
API we'll have more common code between drivers.

What do you think?

> Also, do you prefer an open property-name in client users (like I am
> doing at the moment) or imposing a standard property name "hwlocks"?

Good point - I think we can start with an imposed "hwlocks" name, and
evolve in the future as needed (again, only because we're not really
imposing anything on the DT data - this is just kernel code that we
could always extend as needed).

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-04  4:58             ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-04  4:58 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna <s-anna@ti.com> wrote:
> Not at the moment, with the existing platform implementations. So, if I
> understand you correctly, you are asking to leave out the xlate ops and
> make the of_hwspin_lock_simple_xlate() internal until a need for an
> xlate method arises.

Yes, please. It seems to me this way we're reducing complexity without
compromising anything.

> This also means, we only support a value of 1 for #hwlock-cells.

When a different #hwlock-cells value shows up, someone would have to
write a new xlate implementation anyway. At the same time, the xlate
ops could be brought back quite easily.

Since we're not imposing anything on the DT data, this doesn't affect
our ability to support these scenarios in the future, but unless I'm
missing a current use case, these scenarios right now seems somewhat
fictional.

> But, that would mean DT-based client users would have to invoke two
> function calls to request a hwspinlock. We already have an API to get
> the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
> API for requesting a lock directly rather than giving an OF API for
> getting the lock id. This is in keeping in convention with what other
> drivers do normally - a regular get and an OF get. I can modify it if
> you still prefer the OF API for getting a global lock id, but I feel its
> a burden for client users.

Let's discuss this.

I was actually thinking of the more general use case of an heterogenous system:

- driver gets the global lock id from a remote processor
- driver then requests the specific lock

Looking at these cases, the OF scenario only differs in the small part
of fetching the lock id, and if we keep the regular request_specific
API we'll have more common code between drivers.

What do you think?

> Also, do you prefer an open property-name in client users (like I am
> doing at the moment) or imposing a standard property name "hwlocks"?

Good point - I think we can start with an imposed "hwlocks" name, and
evolve in the future as needed (again, only because we're not really
imposing anything on the DT data - this is just kernel code that we
could always extend as needed).

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
  2014-07-03 17:28           ` Suman Anna
@ 2014-07-04  5:01             ` Ohad Ben-Cohen
  -1 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-04  5:01 UTC (permalink / raw)
  To: Suman Anna
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Suman,

On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna <s-anna@ti.com> wrote:
> OK, but we would still require this function to lookup the registered
> device from the controller-phandle to retrieve the base_id.

Can we retrieve the base_id from the parent DT node itself?

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-04  5:01             ` Ohad Ben-Cohen
  0 siblings, 0 replies; 111+ messages in thread
From: Ohad Ben-Cohen @ 2014-07-04  5:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suman,

On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna <s-anna@ti.com> wrote:
> OK, but we would still require this function to lookup the registered
> device from the controller-phandle to retrieve the base_id.

Can we retrieve the base_id from the parent DT node itself?

Thanks,
Ohad.

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-08 15:22               ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-08 15:22 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/04/2014 12:01 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna <s-anna@ti.com> wrote:
>> OK, but we would still require this function to lookup the registered
>> device from the controller-phandle to retrieve the base_id.
> 
> Can we retrieve the base_id from the parent DT node itself?

Yeah, it is possible using the of_hwspin_lock_get_base_id function added
in Patch8, once we convert the phandle to a device node. The platform
implementations would be using this function during the registration
phase to register the base id, and we have to do the DT parse/lookup
again in the core.

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-08 15:22               ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-08 15:22 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm

Hi Ohad,

On 07/04/2014 12:01 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
>> OK, but we would still require this function to lookup the registered
>> device from the controller-phandle to retrieve the base_id.
> 
> Can we retrieve the base_id from the parent DT node itself?

Yeah, it is possible using the of_hwspin_lock_get_base_id function added
in Patch8, once we convert the phandle to a device node. The platform
implementations would be using this function during the registration
phase to register the base id, and we have to do the DT parse/lookup
again in the core.

regards
Suman
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
@ 2014-07-08 15:22               ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-08 15:22 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/04/2014 12:01 AM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 8:28 PM, Suman Anna <s-anna@ti.com> wrote:
>> OK, but we would still require this function to lookup the registered
>> device from the controller-phandle to retrieve the base_id.
> 
> Can we retrieve the base_id from the parent DT node itself?

Yeah, it is possible using the of_hwspin_lock_get_base_id function added
in Patch8, once we convert the phandle to a device node. The platform
implementations would be using this function during the registration
phase to register the base id, and we have to do the DT parse/lookup
again in the core.

regards
Suman

^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-08 15:37               ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-08 15:37 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel, linux-omap, devicetree, linux-arm

Hi Ohad,

On 07/03/2014 11:58 PM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna <s-anna@ti.com> wrote:
>> Not at the moment, with the existing platform implementations. So, if I
>> understand you correctly, you are asking to leave out the xlate ops and
>> make the of_hwspin_lock_simple_xlate() internal until a need for an
>> xlate method arises.
> 
> Yes, please. It seems to me this way we're reducing complexity without
> compromising anything.

OK, will make this change and add a comment in the code in the next version.

> 
>> This also means, we only support a value of 1 for #hwlock-cells.
> 
> When a different #hwlock-cells value shows up, someone would have to
> write a new xlate implementation anyway. At the same time, the xlate
> ops could be brought back quite easily.
> 
> Since we're not imposing anything on the DT data, this doesn't affect
> our ability to support these scenarios in the future, but unless I'm
> missing a current use case, these scenarios right now seems somewhat
> fictional.

OK, fair enough.

> 
>> But, that would mean DT-based client users would have to invoke two
>> function calls to request a hwspinlock. We already have an API to get
>> the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
>> API for requesting a lock directly rather than giving an OF API for
>> getting the lock id. This is in keeping in convention with what other
>> drivers do normally - a regular get and an OF get. I can modify it if
>> you still prefer the OF API for getting a global lock id, but I feel its
>> a burden for client users.
> 
> Let's discuss this.
> 
> I was actually thinking of the more general use case of an heterogenous system:
> 
> - driver gets the global lock id from a remote processor
> - driver then requests the specific lock
> 
> Looking at these cases, the OF scenario only differs in the small part
> of fetching the lock id, and if we keep the regular request_specific
> API we'll have more common code between drivers.
> 
> What do you think?

We should also be thinking about the how to add the support for the
reserved locks. Please take a look at the added RFC patches 9 through
13, specifically the reworked Patch 12 [1]. I moved away from adding a
reserved property to the controller node, as it means updating both
controller and client nodes. Depending on where we enforce the check (in
the OF API or in the common request_specific, the behavior would change.

> 
>> Also, do you prefer an open property-name in client users (like I am
>> doing at the moment) or imposing a standard property name "hwlocks"?
> 
> Good point - I think we can start with an imposed "hwlocks" name, and
> evolve in the future as needed (again, only because we're not really
> imposing anything on the DT data - this is just kernel code that we
> could always extend as needed).
> 

OK. Actually, I didn't realize that I had already made this change as
part of the reserved locks RFC patch.

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139968467307977&w=2


^ permalink raw reply	[flat|nested] 111+ messages in thread
* Re: [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-08 15:37               ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-08 15:37 UTC (permalink / raw)
  To: Ohad Ben-Cohen
  Cc: Mark Rutland, Kumar Gala, Tony Lindgren, Josh Cartwright,
	Bjorn Andersson, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-omap-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm

Hi Ohad,

On 07/03/2014 11:58 PM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna <s-anna-l0cyMroinI0@public.gmane.org> wrote:
>> Not at the moment, with the existing platform implementations. So, if I
>> understand you correctly, you are asking to leave out the xlate ops and
>> make the of_hwspin_lock_simple_xlate() internal until a need for an
>> xlate method arises.
> 
> Yes, please. It seems to me this way we're reducing complexity without
> compromising anything.

OK, will make this change and add a comment in the code in the next version.

> 
>> This also means, we only support a value of 1 for #hwlock-cells.
> 
> When a different #hwlock-cells value shows up, someone would have to
> write a new xlate implementation anyway. At the same time, the xlate
> ops could be brought back quite easily.
> 
> Since we're not imposing anything on the DT data, this doesn't affect
> our ability to support these scenarios in the future, but unless I'm
> missing a current use case, these scenarios right now seems somewhat
> fictional.

OK, fair enough.

> 
>> But, that would mean DT-based client users would have to invoke two
>> function calls to request a hwspinlock. We already have an API to get
>> the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
>> API for requesting a lock directly rather than giving an OF API for
>> getting the lock id. This is in keeping in convention with what other
>> drivers do normally - a regular get and an OF get. I can modify it if
>> you still prefer the OF API for getting a global lock id, but I feel its
>> a burden for client users.
> 
> Let's discuss this.
> 
> I was actually thinking of the more general use case of an heterogenous system:
> 
> - driver gets the global lock id from a remote processor
> - driver then requests the specific lock
> 
> Looking at these cases, the OF scenario only differs in the small part
> of fetching the lock id, and if we keep the regular request_specific
> API we'll have more common code between drivers.
> 
> What do you think?

We should also be thinking about the how to add the support for the
reserved locks. Please take a look at the added RFC patches 9 through
13, specifically the reworked Patch 12 [1]. I moved away from adding a
reserved property to the controller node, as it means updating both
controller and client nodes. Depending on where we enforce the check (in
the OF API or in the common request_specific, the behavior would change.

> 
>> Also, do you prefer an open property-name in client users (like I am
>> doing at the moment) or imposing a standard property name "hwlocks"?
> 
> Good point - I think we can start with an imposed "hwlocks" name, and
> evolve in the future as needed (again, only because we're not really
> imposing anything on the DT data - this is just kernel code that we
> could always extend as needed).
> 

OK. Actually, I didn't realize that I had already made this change as
part of the reserved locks RFC patch.

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139968467307977&w=2

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 111+ messages in thread
* [PATCHv5 04/15] hwspinlock/core: add common OF helpers
@ 2014-07-08 15:37               ` Suman Anna
  0 siblings, 0 replies; 111+ messages in thread
From: Suman Anna @ 2014-07-08 15:37 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Ohad,

On 07/03/2014 11:58 PM, Ohad Ben-Cohen wrote:
> Hi Suman,
> 
> On Thu, Jul 3, 2014 at 8:35 PM, Suman Anna <s-anna@ti.com> wrote:
>> Not at the moment, with the existing platform implementations. So, if I
>> understand you correctly, you are asking to leave out the xlate ops and
>> make the of_hwspin_lock_simple_xlate() internal until a need for an
>> xlate method arises.
> 
> Yes, please. It seems to me this way we're reducing complexity without
> compromising anything.

OK, will make this change and add a comment in the code in the next version.

> 
>> This also means, we only support a value of 1 for #hwlock-cells.
> 
> When a different #hwlock-cells value shows up, someone would have to
> write a new xlate implementation anyway. At the same time, the xlate
> ops could be brought back quite easily.
> 
> Since we're not imposing anything on the DT data, this doesn't affect
> our ability to support these scenarios in the future, but unless I'm
> missing a current use case, these scenarios right now seems somewhat
> fictional.

OK, fair enough.

> 
>> But, that would mean DT-based client users would have to invoke two
>> function calls to request a hwspinlock. We already have an API to get
>> the lock id given a hwspinlock - hwspin_lock_get_id(), so I added the OF
>> API for requesting a lock directly rather than giving an OF API for
>> getting the lock id. This is in keeping in convention with what other
>> drivers do normally - a regular get and an OF get. I can modify it if
>> you still prefer the OF API for getting a global lock id, but I feel its
>> a burden for client users.
> 
> Let's discuss this.
> 
> I was actually thinking of the more general use case of an heterogenous system:
> 
> - driver gets the global lock id from a remote processor
> - driver then requests the specific lock
> 
> Looking at these cases, the OF scenario only differs in the small part
> of fetching the lock id, and if we keep the regular request_specific
> API we'll have more common code between drivers.
> 
> What do you think?

We should also be thinking about the how to add the support for the
reserved locks. Please take a look at the added RFC patches 9 through
13, specifically the reworked Patch 12 [1]. I moved away from adding a
reserved property to the controller node, as it means updating both
controller and client nodes. Depending on where we enforce the check (in
the OF API or in the common request_specific, the behavior would change.

> 
>> Also, do you prefer an open property-name in client users (like I am
>> doing at the moment) or imposing a standard property name "hwlocks"?
> 
> Good point - I think we can start with an imposed "hwlocks" name, and
> evolve in the future as needed (again, only because we're not really
> imposing anything on the DT data - this is just kernel code that we
> could always extend as needed).
> 

OK. Actually, I didn't realize that I had already made this change as
part of the reserved locks RFC patch.

regards
Suman

[1] http://marc.info/?l=linux-omap&m=139968467307977&w=2

^ permalink raw reply	[flat|nested] 111+ messages in thread
end of thread, other threads:[~2014-07-08 15:38 UTC | newest]

Thread overview: 111+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-01  0:34 [PATCHv5 00/15] hwspinlock/omap dt support Suman Anna
2014-05-01  0:34 ` Suman Anna
2014-05-01  0:34 ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-02 14:58   ` Rob Herring
2014-05-02 14:58     ` Rob Herring
2014-05-02 14:58     ` Rob Herring
2014-05-02 22:46     ` Suman Anna
2014-05-02 22:46       ` Suman Anna
2014-05-02 22:46       ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 02/15] Documentation: dt: add the omap hwspinlock bindings document Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-07-01 12:26   ` Ohad Ben-Cohen
2014-07-01 12:26     ` Ohad Ben-Cohen
2014-07-02 21:14     ` Suman Anna
2014-07-02 21:14       ` Suman Anna
2014-07-02 21:14       ` Suman Anna
2014-07-03  7:00       ` Ohad Ben-Cohen
2014-07-03  7:00         ` Ohad Ben-Cohen
2014-07-03 17:28         ` Suman Anna
2014-07-03 17:28           ` Suman Anna
2014-07-03 17:28           ` Suman Anna
2014-07-04  5:01           ` Ohad Ben-Cohen
2014-07-04  5:01             ` Ohad Ben-Cohen
2014-07-08 15:22             ` Suman Anna
2014-07-08 15:22               ` Suman Anna
2014-07-08 15:22               ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 04/15] hwspinlock/core: add common OF helpers Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-07-01 12:45   ` Ohad Ben-Cohen
2014-07-01 12:45     ` Ohad Ben-Cohen
2014-07-02 21:14     ` Suman Anna
2014-07-02 21:14       ` Suman Anna
2014-07-03  7:15       ` Ohad Ben-Cohen
2014-07-03  7:15         ` Ohad Ben-Cohen
2014-07-03 17:35         ` Suman Anna
2014-07-03 17:35           ` Suman Anna
2014-07-03 17:35           ` Suman Anna
2014-07-04  4:58           ` Ohad Ben-Cohen
2014-07-04  4:58             ` Ohad Ben-Cohen
2014-07-08 15:37             ` Suman Anna
2014-07-08 15:37               ` Suman Anna
2014-07-08 15:37               ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 05/15] hwspinlock/omap: add support for dt nodes Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-07-01 12:48   ` Ohad Ben-Cohen
2014-07-01 12:48     ` Ohad Ben-Cohen
2014-07-02 19:42     ` Suman Anna
2014-07-02 19:42       ` Suman Anna
2014-07-03  7:25       ` Ohad Ben-Cohen
2014-07-03  7:25         ` Ohad Ben-Cohen
2014-05-01  0:34 ` [PATCHv5 06/15] hwspinlock/omap: enable module before reading SYSSTATUS register Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-07-01 12:51   ` Ohad Ben-Cohen
2014-07-01 12:51     ` Ohad Ben-Cohen
2014-07-02 19:38     ` Suman Anna
2014-07-02 19:38       ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 07/15] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-07-01 12:53   ` Ohad Ben-Cohen
2014-07-01 12:53     ` Ohad Ben-Cohen
2014-07-01 12:53     ` Ohad Ben-Cohen
2014-05-01  0:34 ` [PATCHv5 RFC 08/15] hwspinlock/core: add support for base id in DT Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-05 20:37   ` Rob Herring
2014-05-05 20:37     ` Rob Herring
2014-05-05 20:37     ` Rob Herring
2014-05-05 21:37     ` Suman Anna
2014-05-05 21:37       ` Suman Anna
2014-05-05 21:37       ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 09/15] hwspinlock/core: prepare unregister code to support reserved locks Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 10/15] hwspinlock/core: prepare core " Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 11/15] hwspinlock/core: add support for " Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse " Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-05 21:44   ` Suman Anna
2014-05-05 21:44     ` Suman Anna
2014-05-05 21:44     ` Suman Anna
2014-05-05 21:54     ` Josh Cartwright
2014-05-05 21:54       ` Josh Cartwright
2014-05-05 21:54       ` Josh Cartwright
2014-05-10  1:17       ` Suman Anna
2014-05-10  1:17         ` Suman Anna
2014-05-10  1:17         ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 13/15] hwspinlock/omap: use OF helper to get " Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34 ` [PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific Suman Anna
2014-05-01  0:34   ` Suman Anna
2014-05-01  0:34   ` Suman Anna

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.