linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn@kryo.se>
To: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Rob Herring <robherring2@gmail.com>, Suman Anna <s-anna@ti.com>,
	Kumar Gala <galak@codeaurora.org>,
	Josh Cartwright <joshc@codeaurora.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
Date: Sun, 1 Feb 2015 09:55:02 -0800	[thread overview]
Message-ID: <CAJAp7OjVULNRd113TtOEwaa6QO-XCDa0oxBm2H5NPvp_kLTSpA@mail.gmail.com> (raw)
In-Reply-To: <CAK=WgbZ2986xxuAFvMSoyQLaPAxdUpZ8e5g-mSjyETfvd4KKHw@mail.gmail.com>

On Fri, Jan 30, 2015 at 9:41 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson <bjorn@kryo.se> wrote:
>> In a system where you have two hwlock blocks lckA and lckB, each
>> consisting of 8 locks and you have dspB that can only access lckB
>
> This is a good example - thanks. To be able to cope with such cases we
> will have to pass a hwlock block reference and its relative lock id.
>

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

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

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

So I think we can reduce the binding to:

Providers:
#hwlock-cells

Consumers:
hwlocks
hwlock-names

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

> Since the existence of several hwblocks is still fictional (Bjorn,
> please confirm too?), we may prefer to introduce changes to support it
> only when it shows up; it all depends on the amount of changes needed.
> Suman, care to take a look please?
>

I haven't seen any such systems yet.

We could introduce the logic found in other subsystems of allowing -1
as base_id and having the core find a available range. This will work
for all cases where the global ids doesn't have to be static; either
due to the fact that we use block:local-id or that the indices are
hard coded. (Referencing locks via dt is equivalent of the
block:local-id case)

>>> - Sometimes a remote processor, which may not be running Linux, will
>>> have to dynamically allocate a hwlock, and send the ID of the
>>> allocated lock to us (another processor running Linux)
>>>
>> I'm sorry but you cannot have a system on both sides that is allowed
>> to do dynamic allocation from a limited set of resources.
>
> Of course not. On such systems, Linux is not the one responsible for
> allocating the hwlocks, at least not during part of the time or from
> part of the hwlocks. There were a few different use cases, with
> different semantics, that required communicating to Linux an hwlock
> id, but since none of them have reached mainline, we should only
> remember they may show up one day, but not put too much effort to
> support them right now.
>

That makes more sense, although I still believe that you end up with a
system wide setup where locks are statically allocated in some
document beforehand. Either that or you will have to feed that other
system with the list of constraints.

Non the less, that's "unrelated".

If we get an incoming message saying lckX:Y (or the global lckZ), we
probably wouldn't define that in DT. We would need a way to resolve
the hwlock-block "lckX" so we can request lock Y from that block. We
would basically build the DT reference on the fly.

I think this is a future problem to be solved and more importantly I
don't think it's limited to hwlocks. If a system architect designs a
system where a remote entity will do allocation of resources for us,
they will most likely do so not only for hwlocks but also for gpios,
irqs and other resources that we today reference with arguments in DT.
Hopefully that will not happen anytime soon, so let's just ignore that
problem for now and go for a simple binding that will cover todays use
cases (with some thought into multi-block support).

Regards,
Bjorn

  parent reply	other threads:[~2015-02-01 17:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 20:58 [PATCH v7 0/4] hwspinlock core & omap dt support Suman Anna
2015-01-14 20:58 ` [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock Suman Anna
2015-01-15 13:52   ` Mark Rutland
2015-01-15 13:55     ` Mark Rutland
2015-01-15 14:42       ` Rob Herring
2015-01-15 20:16         ` Suman Anna
2015-01-16  6:09         ` Ohad Ben-Cohen
2015-01-16 10:17           ` Mark Rutland
2015-01-17  0:46             ` Ohad Ben-Cohen
2015-01-20 18:05               ` Tony Lindgren
2015-01-21 12:41                 ` Ohad Ben-Cohen
2015-01-21 17:56                   ` Suman Anna
2015-01-22 18:56                     ` Mark Rutland
2015-01-29  3:58                       ` Suman Anna
2015-02-11 11:29                         ` Mark Rutland
2015-02-16 18:06                           ` Bjorn Andersson
2015-01-30 23:29               ` Bjorn Andersson
2015-01-31  5:41                 ` Ohad Ben-Cohen
2015-02-01 11:00                   ` Ohad Ben-Cohen
2015-02-02 21:14                     ` Suman Anna
2015-02-01 17:55                   ` Bjorn Andersson [this message]
2015-02-02 21:07                     ` Suman Anna
2015-02-05 23:01                       ` Bjorn Andersson
2015-02-06  0:11                         ` Suman Anna
2015-02-06  0:34                           ` Bjorn Andersson
2015-02-11 10:29                             ` Ohad Ben-Cohen
2015-02-11 11:35                               ` Mark Rutland
2015-02-16 20:30                   ` Bjorn Andersson
2015-01-16 10:19         ` Mark Rutland
2015-01-16 17:49           ` Suman Anna
2015-01-14 20:58 ` [PATCH v7 2/4] Documentation: dt: add the omap hwspinlock bindings document Suman Anna
2015-01-14 20:58 ` [PATCH v7 3/4] hwspinlock/core: add common OF helpers Suman Anna
2015-01-14 20:58 ` [PATCH v7 4/4] hwspinlock/omap: add support for dt nodes Suman Anna
2015-01-15 10:13 ` [PATCH v7 0/4] hwspinlock core & omap dt support Ohad Ben-Cohen

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=CAJAp7OjVULNRd113TtOEwaa6QO-XCDa0oxBm2H5NPvp_kLTSpA@mail.gmail.com \
    --to=bjorn@kryo.se \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=joshc@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ohad@wizery.com \
    --cc=robh+dt@kernel.org \
    --cc=robherring2@gmail.com \
    --cc=s-anna@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).