From patchwork Tue May 5 11:43:33 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 6337001 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 668249F32B for ; Tue, 5 May 2015 11:46:05 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8F839202A1 for ; Tue, 5 May 2015 11:46:04 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B79732026D for ; Tue, 5 May 2015 11:46:03 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1YpbGY-0001Ti-7S; Tue, 05 May 2015 11:43:58 +0000 Received: from mail-oi0-f49.google.com ([209.85.218.49]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1YpbGV-0001Pj-76 for linux-arm-kernel@lists.infradead.org; Tue, 05 May 2015 11:43:55 +0000 Received: by oift201 with SMTP id t201so143144423oif.3 for ; Tue, 05 May 2015 04:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G98z9lvbxgmOyTySmMA7hh9OOxPlxvA9Sznjw4LsMPg=; b=VeXTRHLsbl7WZqPCN7CiPsTJDv5sCk51cnqjGWgoMIxzUUffB2b6egfEEkOwzsO+n4 gkk8fcDHk312C6ihdxjKXwuOise4CTl3Y4t1044JNyONKXgbscqnXuW3iFHxxpaz48Y4 4F6/RmwJSyQzNPFSaA4JStSA0P55LFMQWq6idVp8I6X+DNvAkCu5G00FLB19ARtQHgDD sMDWIrVK6KzJPMjnmmOJYNhQNWgef9u7GZFbi7aGgiIpF9Rv+jDGw9lAHiZSpnRSjeMK Eo+cM2iHhd52QnYkKrtlayit5Dxshn8afAmQ93ktzew60T0Qi+VUH1y/PDUEyYyJ5Hx1 wIKA== X-Gm-Message-State: ALoCoQleDztGOrDqpKT/CnCuqnYsofTf9+R5XLIML01JpoNAzIbFBZvK2wnIKEuOweNYA9E4dQGq MIME-Version: 1.0 X-Received: by 10.60.63.244 with SMTP id j20mr22339998oes.12.1430826213906; Tue, 05 May 2015 04:43:33 -0700 (PDT) Received: by 10.182.185.18 with HTTP; Tue, 5 May 2015 04:43:33 -0700 (PDT) In-Reply-To: <20150505105714.GA22845@sirena.org.uk> References: <20150504121209.GM15510@sirena.org.uk> <20150505105714.GA22845@sirena.org.uk> Date: Tue, 5 May 2015 17:13:33 +0530 Message-ID: Subject: Re: [PATCH V4 1/3] OPP: Redefine bindings to overcome shortcomings From: Viresh Kumar To: Mark Brown X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20150505_044355_313301_3AAD1C94 X-CRM114-Status: GOOD ( 15.31 ) X-Spam-Score: -0.7 (/) Cc: Nishanth Menon , Rob Herring , Abhilash Kesavan , Linaro Kernel Mailman List , Thomas Abraham , "linux-pm@vger.kernel.org" , Viswanath Puttagunta , Stephen Boyd , santosh shilimkar , Rafael Wysocki , "olof@lixom.net" , "devicetree@vger.kernel.org" , Kevin Hilman , Mike Turquette , Sudeep Holla , Grant Likely , Arnd Bergmann , Thomas Petazzoni , "linux-arm-kernel@lists.infradead.org" , Lucas Stach X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 5 May 2015 at 16:27, Mark Brown wrote: > No, it doesn't - you're not answering the question about what this is > for. I don't know how this information will be used finally. Probably the platform driver will do the configuration based on the volt-cur pair. > To know if this makes sense I need to know what you beleive "setting the > current" does. If you literally mean setting the current it makes no > sense at all. If you mean something else that something else should > probably be written into the binding. Yeah, that was a wrong statement. We can't configure current separately. Does this diff make it any better ? nanoseconds) for switching to this OPP from any other OPP. (Restoring my laptop after a corrupted disk, and so sending it from gmail, might be a bit corrupted).. diff --git a/Documentation/devicetree/bindings/power/opp.txt b/Documentation/devicetree/bindings/power/opp.txt index c96dc77121b7..a57e88ab4554 100644 --- a/Documentation/devicetree/bindings/power/opp.txt +++ b/Documentation/devicetree/bindings/power/opp.txt @@ -59,16 +59,18 @@ properties. regulators are specified in device's DT node. - opp-microamp: current in micro Amperes. It can contain entries for multiple - regulators. + regulators. This can be referenced (along with voltage and freqency) while + programming the regulator. A single regulator's current is specified with an array of size one or three. Single entry is for target current and three entries are for currents. Entries for multiple regulators must be present in the same order as - regulators are specified in device's DT node. If few regulators don't provide - capability to configure current, then values for then should be marked as - zero. + regulators are specified in device's DT node. If current value for few + regulators isn't required to be passed, then values for such regulators should + be marked as zero. If it isn't required for any regulator, then this property + need not be present. - clock-latency-ns: Specifies the maximum possible transition latency (in