From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752478AbbBKKab (ORCPT ); Wed, 11 Feb 2015 05:30:31 -0500 Received: from mail-la0-f49.google.com ([209.85.215.49]:37301 "EHLO mail-la0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752407AbbBKK37 (ORCPT ); Wed, 11 Feb 2015 05:29:59 -0500 MIME-Version: 1.0 X-Originating-IP: [93.172.140.139] 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> <54CFE71E.20905@ti.com> <54D406BA.6060403@ti.com> From: Ohad Ben-Cohen Date: Wed, 11 Feb 2015 12:29:37 +0200 Message-ID: Subject: Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock To: Bjorn Andersson Cc: Suman Anna , Mark Rutland , Rob Herring , 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 Fri, Feb 6, 2015 at 2:34 AM, Bjorn Andersson wrote: >> Yep, will do as soon as I hear from Ohad on what to do with the patch >> "hwspinlock/core: maintain a list of registered hwspinlock banks" that I >> dropped from v7. Without that and dropping hwlock-base-id, I can't get >> the translations done. >> > > My suggestion is to replace the global id-tree with a list of hwlocks > and iterate over these if we ever get more than one driver registered. > As long as #hwlock-drivers < log(#total-hwlocks) this should be > faster. > > I would however argue that clients that would notice any kind of > difference are using the API incorrectly. > > Unfortunately this is a somewhat larger change than just slapping DT > support on the framework :/ I suspect we want to wait with framework changes until there's a real hardware use case justifying them. With regard to DT, however, we obviously do want to be prepared for multiple hwlock blocks even if they do not exist today. So how about adopting an approach where: - DT fully supports multi hwlock blocks (i.e. no global id field) - Framework left mostly unchanged at the moment. This means issuing an explicit error in case a secondary hwlock block shows up, and then hwlock id could trivially be the lock index. If multi hwlock hardware use case, or some new hwlock id translation requirements, do show up in the future, it's always easy to add framework support for it. At that point we'll know better what the requirements are, and framework changes would be justifiable. Thanks, Ohad.