Message-ID: <CAK=WgbYjtw+cxy5wX6pjK=Rpj6wOk6Cu+GrPuFN+sqtgDAY=_Q@mail.gmail.com>
Date:	Mon, 17 Mar 2014 21:47:42 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Tony Lindgren <tony@...mide.com>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCHv4 0/7] omap hwspinlock dt support

Hi Suman,

On Mon, Mar 17, 2014 at 9:10 PM, Suman Anna <s-anna@...com> wrote:
> base_id would be a property (if added) of the hwspinlock controller node,
> and from DT perspective, we will be using the phandle for the controller
> anyway. So, using a base_id+specifier seems redundant, as the specifier is
> already w.r.t a hwspinlock controller node.  It is best to leave the base_id
> out, just use the specifier. This is pretty much the standard practice
> (GPIOs, DMAs, etc all follow this).

Do you mean hwspin_lock_get_id() will return just the specifier
instead of base_id+specifier? This is problematic, because Linux will
not be able to communicate this lock id outside to a different core
running a different OS: that OS will have no idea what hwlock
controller this is relative to.

> Please see the comments from Mark regarding the same on an earlier version.

I think I understand and agree with Mark generally, but in this case,
the hwlock id is not an implementation detail. Unlike GPIOs/DMAs, this
id number is global and system-wide (Linux is just one component in
the system, and must use the same predefined id numbers all other
cores use, otherwise it will be impossible to use those hwlocks for
multi-core synchronization).

> Yes, I agree this is an issue if we have to have the base_ids fixed per
> controller.

Do you see any other way this could work if the base_ids were not
predefined? Linux and some other core running a different OS must
agree on the id numbers of the hardware locks we have in the system.

>> Before DT came along, early board code could have reserved specific
>> hwspinlocks if needed. Now with DT, we should add the list of reserved
>> locks to the controller node, in order to prevent them from being
>> dynamically allocated by others.
>
>
> But that strictly relied on the order of requests without any core changes
> in the hwspinlock core, right.

I don't think so, you could request a specific lock by id number.

> With DT, the early board code is much simplified. Looking at the same
> scenario from DT case, it seems kinda redundant to specify a set of reserved
> locks both in the controller node, as well as the respective client drivers,
> as there is almost no platform data with DT. The only use case for DT client
> nodes would be for requesting specific locks. I agree with the problem you
> described, and I think it will require a different set of changes to the
> core.

Exactly. The platform-specific hwspinlock driver will have to inform
the core, upon registration, which of the locks are already reserved.
In turn, the core will never provide them to clients that dynamically
allocate an hwlock: they will be provided only to clients that ask for
them specifically (using phandle+specifier).

Thanks,
Ohad.
--
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