From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752759AbbBALAi (ORCPT ); Sun, 1 Feb 2015 06:00:38 -0500 Received: from mail-la0-f49.google.com ([209.85.215.49]:61176 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752605AbbBALAf (ORCPT ); Sun, 1 Feb 2015 06:00:35 -0500 MIME-Version: 1.0 X-Originating-IP: [93.172.151.148] 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: Sun, 1 Feb 2015 13:00:13 +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 7:41 AM, Ohad Ben-Cohen wrote: > 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. Additionally, to support such a scenario, we can no longer retain the simple dynamic allocation API we have today, because it might end up allocating dspB an hwlock from IckA. We will have to make sure hwlocks are allocated only from pools visible to the user, something that will change not only the hwspinlock API but also the way it maintains the hwlocks. I suspect we want to wait for such hardware to show up first, and only then add framework support for it. Regardless, we obviously do want to make sure our DT binding is prepared for the worse, so we'll drop the "base-id" field. Thanks, Ohad.