From: s-anna@ti•com (Suman Anna)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks
Date: Wed, 2 Jul 2014 16:14:09 -0500 [thread overview]
Message-ID: <53B47621.6090307@ti.com> (raw)
In-Reply-To: <CAK=WgbakGbTaYz+4K24aT3vyRkDYwPKCm6XrcJvH667NMMfTTA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-07-02 21:14 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-01 0:34 [PATCHv5 00/15] hwspinlock/omap dt support Suman Anna
2014-05-01 0:34 ` [PATCHv5 01/15] Documentation: dt: add common bindings for hwspinlock Suman Anna
2014-05-02 14:58 ` Rob Herring
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 ` [PATCHv5 03/15] hwspinlock/core: maintain a list of registered hwspinlock banks Suman Anna
2014-07-01 12:26 ` Ohad Ben-Cohen
2014-07-02 21:14 ` Suman Anna [this message]
2014-07-03 7:00 ` Ohad Ben-Cohen
2014-07-03 17:28 ` Suman Anna
2014-07-04 5:01 ` Ohad Ben-Cohen
2014-07-08 15:22 ` Suman Anna
2014-05-01 0:34 ` [PATCHv5 04/15] hwspinlock/core: add common OF helpers Suman Anna
2014-07-01 12:45 ` Ohad Ben-Cohen
2014-07-02 21:14 ` Suman Anna
2014-07-03 7:15 ` Ohad Ben-Cohen
2014-07-03 17:35 ` Suman Anna
2014-07-04 4:58 ` Ohad Ben-Cohen
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-07-01 12:48 ` Ohad Ben-Cohen
2014-07-02 19:42 ` Suman Anna
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-07-01 12:51 ` Ohad Ben-Cohen
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-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-05 20:37 ` Rob Herring
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 ` [PATCHv5 RFC 10/15] hwspinlock/core: prepare core " Suman Anna
2014-05-01 0:34 ` [PATCHv5 RFC 11/15] hwspinlock/core: add support for " Suman Anna
2014-05-01 0:34 ` [PATCHv5 RFC 12/15] hwspinlock/core: add OF helper to parse " Suman Anna
2014-05-05 21:44 ` Suman Anna
2014-05-05 21:54 ` Josh Cartwright
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 ` [PATCHv5 RFC 14/15] hwspinlock/core: return ERR_PTRs on failure in _request_ api Suman Anna
2014-05-01 0:34 ` [PATCHv5 RFC 15/15] hwspinlock/core: change return codes of_hwspin_lock_request_specific Suman Anna
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53B47621.6090307@ti.com \
--to=s-anna@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox