From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751064AbbAaFlq (ORCPT ); Sat, 31 Jan 2015 00:41:46 -0500 Received: from mail-la0-f52.google.com ([209.85.215.52]:56651 "EHLO mail-la0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750963AbbAaFlm (ORCPT ); Sat, 31 Jan 2015 00:41:42 -0500 MIME-Version: 1.0 X-Originating-IP: [93.172.190.235] In-Reply-To: References: <1421269101-51105-1-git-send-email-s-anna@ti.com> <1421269101-51105-2-git-send-email-s-anna@ti.com> <20150115135201.GG16217@leverpostej> <20150115135556.GH16217@leverpostej> <20150116101746.GA21809@leverpostej> From: Ohad Ben-Cohen Date: Sat, 31 Jan 2015 07:41:20 +0200 Message-ID: Subject: Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock To: Bjorn Andersson Cc: Mark Rutland , Rob Herring , Suman Anna , Kumar Gala , Josh Cartwright , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Rob Herring Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson 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. 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. 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? >> - 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. Thanks, Ohad.