Messages in this thread | | | Date | Thu, 18 Jun 2015 14:01:40 +0100 | From | Srinivas Kandagatla <> | Subject | Re: [PATCH v5 06/11] nvmem: Add bindings for simple nvmem framework |
| |
On 16/06/15 23:53, Stephen Boyd wrote: > 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? > Yep, will fix the text >> + >> +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/ Yep. > >> + >> +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.
As we read byte-byte, does it matter, as long as consumer gets them in the same order as its 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? Yes, will fix it. >
| |