Message-ID: <CAJAp7OjVULNRd113TtOEwaa6QO-XCDa0oxBm2H5NPvp_kLTSpA@mail.gmail.com>
Date:	Sun, 1 Feb 2015 09:55:02 -0800
From:	Bjorn Andersson <bjorn@...o.se>
To:	Ohad Ben-Cohen <ohad@...ery.com>
Cc:	Mark Rutland <mark.rutland@....com>,
	Rob Herring <robherring2@...il.com>,
	Suman Anna <s-anna@...com>, Kumar Gala <galak@...eaurora.org>,
	Josh Cartwright <joshc@...eaurora.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock

On Fri, Jan 30, 2015 at 9:41 PM, Ohad Ben-Cohen <ohad@...ery.com> wrote:
> On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson <bjorn@...o.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists