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-a...@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-a...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html