From patchwork Mon Nov 3 20:02:44 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Bruno_Pr=C3=A9mont?= X-Patchwork-Id: 5219601 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.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id EFF109F349 for ; Mon, 3 Nov 2014 20:05:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id EDF072013A for ; Mon, 3 Nov 2014 20:05:24 +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 E360320136 for ; Mon, 3 Nov 2014 20:05:23 +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 1XlNqU-0001lf-Jo; Mon, 03 Nov 2014 20:03:22 +0000 Received: from hygieia.santi-shop.eu ([2a01:4f8:d13:3b02::2]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1XlNqP-0001Pr-PM for linux-arm-kernel@lists.infradead.org; Mon, 03 Nov 2014 20:03:19 +0000 Received: from neptune.home (unknown [IPv6:2001:960:7ab:0:2c0:9fff:fe2d:39d]) by smtp.sysophe.eu (Postfix) with ESMTPSA id 18C4F486BF61; Mon, 3 Nov 2014 21:02:46 +0100 (CET) Date: Mon, 3 Nov 2014 21:02:44 +0100 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= To: Maxime Ripard Subject: Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation Message-ID: <20141103210244.1425e0c7@neptune.home> In-Reply-To: <20141021191905.GR21108@lukather> References: <20141020221959.2f312906@neptune.home> <20141020223314.0484f795@neptune.home> <20141021101503.GE26842@x1> <20141021180916.432f02e1@neptune.home> <20141021191905.GR21108@lukather> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; i686-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141103_120318_159233_4C07E282 X-CRM114-Status: GOOD ( 26.32 ) X-Spam-Score: -1.6 (-) Cc: Olliver Schinagl , linux-pm@vger.kernel.org, Dmitry Eremin-Solenikov , Lee Jones , Sebastian Reichel , linux-sunxi@googlegroups.com, David Woodhouse , linux-arm-kernel@lists.infradead.org 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=-2.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, 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 Hi Maxime, On Tue, 21 October 2014 Maxime Ripard wrote: > On Tue, Oct 21, 2014 at 06:09:16PM +0200, Bruno Prémont wrote: > > On Tue, 21 October 2014 Lee Jones wrote: > > > On Mon, 20 Oct 2014, Bruno Prémont wrote: > > > > --- > > > > Note: the OCV values seem to have some defaults build into the > > > > PMIC though may need adjustment if the used battery has a different > > > > open circuit voltage curve. > > > > As far as understood (these values are set in vendor driver but not > > > > mentioned in chip documentation) they represent charge percentage > > > > for some predefined voltages. > > > > > > > > If prefixing these values with "x-power," is preferred the following > > > > patch should becomes a dependency: > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html > > > > and users in patch 2/4, 4/4 need adjusting. > > > > > > > > > > > > Documentation/devicetree/bindings/mfd/axp20x.txt | 20 + > > > > 1 files changed, 20 insertions(+), 0 deletion(-) > > > > > > > > diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt > > > > index cc9e01b..8ea681c 100644 > > > > --- a/Documentation/devicetree/bindings/mfd/axp20x.txt > > > > +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt > > > > @@ -28,6 +28,20 @@ Required properties: > > > > (range: 750-1875). Default: 1.5MHz > > > > > > > > Optional properties for DCDCs: > > > > +- backup: Settings for backup/RTC battery charger > > > > + (Voltage in µV, current in µA) > > > > + If not present, charger will be left untouched > > > > +- battery.ocv: OCV capacity curve points (16 data values) > > > > +- battery.resistance: internal battery resistance in m? > > > > + (defaults to 100m?) > > > > +- battery.capacity: Battery capacity in mAh > > > > + If this attribute is missing, charger will be disabled > > > > + unless there is a battery connected. > > > > +- battery.temp_sensor: Description of temperautre sensor, 3 values > > > > + - driver current (20µA, 40µA, 60µA or 80µA) > > > > + - low temperature warning level (in µV) > > > > + - high temperature warning level (in µV) > > > > + If missing, temperature sensor gets disabled > > > > - x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode > > > > Default: AUTO mode > > > > > > > > @@ -49,6 +63,12 @@ axp209: pmic@34 { > > > > ldo3in-supply = <&axp_ipsout_reg>; > > > > ldo5in-supply = <&axp_ipsout_reg>; > > > > > > > > + backup = <3000000 200>; > > > > + battery.ocv = <0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>; > > > > + battery.resistance = <0>; > > > > + battery.capacity = <2000>; > > > > + battery.temp_sensor = <20 1000000 4000000>; > > > > > > Since when do we use '.'s in property names? > > > > I've not found guidelines on this, but whatever is the right way to > > name them, I'm open for suggestions. > > You can take a look at the ePAPR specs. Even if it's quite outdated, > it still puts you in the right mindset. There seems to be some kind of e-mail wall in front of this document. > That being said, since they are driver-specific properties, they > should be prefixed by the vendor name (here x-powers). > > And I think they all belong in a sub-node, just like what's been done > for the regulators. Doing something like this?: What are the rules to define the label after the colon? Looking at the existing nodes it's either some address or a number... and then the following in driver code (also adjusting the other property names accessed)?: @@ -678,11 +677,11 @@ static int axp20x_battery_config(struct platform_device *pdev, if (ret) return ret; - np = of_node_get(axp20x->dev->of_node); + np = of_find_node_by_name(axp20x->dev->of_node, "battery"); if (!np) return -ENODEV; - ret = of_property_read_u32_array(np, "battery.ocv", ocv, 16); + ret = of_property_read_u32_array(np, "x-powers,ocv", ocv, 16); for (i = 0; ret == 0 && i < ARRAY_SIZE(ocv); i++) if (ocv[i] > 100) { dev_warn(&pdev->dev, "OCV[%d] %u > 100\n", i, ocv[i]); Bruno --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts @@ -126,9 +126,11 @@ interrupt-controller; #interrupt-cells = <1>; - backup = <3000000 200>; - battery.resistance = <100>; - battery.capacity = <2000>; + x-powers,backup = <3000000 200>; + battery: battery@0 { + x-powers,resistance = <100>; + x-powers,capacity = <2000>; + }; }; };