Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757421AbbFPWyJ (ORCPT ); Tue, 16 Jun 2015 18:54:09 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:34676 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752875AbbFPWxz (ORCPT ); Tue, 16 Jun 2015 18:53:55 -0400 Message-ID: <5580A900.9070902@codeaurora.org> Date: Tue, 16 Jun 2015 15:53:52 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Srinivas Kandagatla , linux-arm-kernel@lists.infradead.org CC: Maxime Ripard , Rob Herring , Kumar Gala , Mark Brown , s.hauer@pengutronix.de, Greg Kroah-Hartman , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, arnd@arndb.de, pantelis.antoniou@konsulko.com, mporter@konsulko.com Subject: Re: [PATCH v5 06/11] nvmem: Add bindings for simple nvmem framework References: <1432226535-8640-1-git-send-email-srinivas.kandagatla@linaro.org> <1432226652-8947-1-git-send-email-srinivas.kandagatla@linaro.org> In-Reply-To: <1432226652-8947-1-git-send-email-srinivas.kandagatla@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3077 Lines: 107 On 05/21/2015 09:44 AM, Srinivas Kandagatla wrote: > diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.txt b/Documentation/devicetree/bindings/nvmem/nvmem.txt > new file mode 100644 > index 0000000..ecea654 > --- /dev/null > +++ b/Documentation/devicetree/bindings/nvmem/nvmem.txt > @@ -0,0 +1,84 @@ > += NVMEM Data Device Tree Bindings = > + > +This binding is intended to represent the location of hardware > +configuration data stored in NVMEMs. It would be worthwhile spelling out what NVMEM stands for. > + > +On a significant proportion of boards, the manufacturer has stored > +some data on NVMEM, for the OS to be able to retrieve these information > +and act upon it. Obviously, the OS has to know about where to retrieve > +these data from, and where they are stored on the storage device. > + > +This document is here to document this. > + > += Data providers = > +Contains bindings specific to provider drivers and data cells as children > +to this node. children of this node? > + > +Optional properties: > + read-only: Mark the provider as read only. > + > += Data cells = > +These are the child nodes of the provider which contain data cell > +information like offset and size in nvmem provider. > + > +Required properties: > +reg: specifies the offset in byte within that storage device, start bit > + in the byte and the length in bits of the data we care about. > + There could be more then one offset-length pairs in this property. s/then/than/ > + > +Optional properties: > + > +bit-offset: specifies the offset in bit within the address range specified > + by reg property. Can take values from 0-7. > +nbits: specifies number of bits this cell occupies starting from bit-offset. > + Hopefully the consumer knows the endianness of the data stored. > +For example: > + > + /* Provider */ > + qfprom: qfprom@00700000 { > + ... > + > + /* Data cells */ > + tsens_calibration: calib@404 { > + reg = <0x404 0x10>; > + }; > + > + tsens_calibration_bckp: calib_bckp@504 { > + reg = <0x504 0x11>; > + bit-offset = 6; > + nbits = 128; > + }; > + > + pvs_version: pvs-version@6 { > + reg = <0x6 0x2> > + bit-offset = 7; > + nbits = 2; > + }; > + > + speed_bin: speed-bin@c{ > + reg = <0xc 0x1>; > + bit-offset = 2; > + nbits = 3; > + > + }; > + ... > + }; > + > += Data consumers = > +Are device nodes which consume nvmem data cells/providers. > + > +Required-properties: > +nvmem-cell: list of phandle to the nvmem data cells. > +nvmem-cell-names: names for the each nvmem-cell specified > + > +Optional-properties: > +nvmem : list of phandles to nvmem providers. > +nvmem-names: names for the each nvmem provider. Is nvmem-names required if nvmem is used? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/