diff options
Diffstat (limited to 'Documentation/driver-api/nvmem.rst')
| -rw-r--r-- | Documentation/driver-api/nvmem.rst | 65 |
1 files changed, 38 insertions, 27 deletions
diff --git a/Documentation/driver-api/nvmem.rst b/Documentation/driver-api/nvmem.rst index 287e86819640..790e2dc652c0 100644 --- a/Documentation/driver-api/nvmem.rst +++ b/Documentation/driver-api/nvmem.rst @@ -26,9 +26,7 @@ was a rather big abstraction leak. This framework aims at solve these problems. It also introduces DT representation for consumer devices to go get the data they require (MAC -Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. This -framework is based on regmap, so that most of the abstraction available in -regmap can be reused, across multiple types of buses. +Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. NVMEM Providers +++++++++++++++ @@ -43,30 +41,28 @@ A NVMEM provider can register with NVMEM core by supplying relevant nvmem configuration to nvmem_register(), on success core would return a valid nvmem_device pointer. -nvmem_unregister(nvmem) is used to unregister a previously registered provider. +nvmem_unregister() is used to unregister a previously registered provider. -For example, a simple qfprom case:: +For example, a simple nvram case:: - static struct nvmem_config econfig = { - .name = "qfprom", - .owner = THIS_MODULE, - }; - - static int qfprom_probe(struct platform_device *pdev) + static int brcm_nvram_probe(struct platform_device *pdev) { + struct nvmem_config config = { + .name = "brcm-nvram", + .reg_read = brcm_nvram_read, + }; ... - econfig.dev = &pdev->dev; - nvmem = nvmem_register(&econfig); - ... - } + config.dev = &pdev->dev; + config.priv = priv; + config.size = resource_size(res); -It is mandatory that the NVMEM provider has a regmap associated with its -struct device. Failure to do would return error code from nvmem_register(). + devm_nvmem_register(&config); + } -Users of board files can define and register nvmem cells using the -nvmem_cell_table struct:: +Device drivers can define and register an nvmem cell using the nvmem_cell_info +struct:: - static struct nvmem_cell_info foo_nvmem_cells[] = { + static const struct nvmem_cell_info foo_nvmem_cell = { { .name = "macaddr", .offset = 0x7f00, @@ -74,13 +70,7 @@ nvmem_cell_table struct:: } }; - static struct nvmem_cell_table foo_nvmem_cell_table = { - .nvmem_name = "i2c-eeprom", - .cells = foo_nvmem_cells, - .ncells = ARRAY_SIZE(foo_nvmem_cells), - }; - - nvmem_add_cell_table(&foo_nvmem_cell_table); + int nvmem_add_one_cell(nvmem, &foo_nvmem_cell); Additionally it is possible to create nvmem cell lookup entries and register them with the nvmem framework from machine code as shown in the example below:: @@ -189,3 +179,24 @@ ex:: ===================== See Documentation/devicetree/bindings/nvmem/nvmem.txt + +8. NVMEM layouts +================ + +NVMEM layouts are yet another mechanism to create cells. With the device +tree binding it is possible to specify simple cells by using an offset +and a length. Sometimes, the cells doesn't have a static offset, but +the content is still well defined, e.g. tag-length-values. In this case, +the NVMEM device content has to be first parsed and the cells need to +be added accordingly. Layouts let you read the content of the NVMEM device +and let you add cells dynamically. + +Another use case for layouts is the post processing of cells. With layouts, +it is possible to associate a custom post processing hook to a cell. It +even possible to add this hook to cells not created by the layout itself. + +9. Internal kernel API +====================== + +.. kernel-doc:: drivers/nvmem/core.c + :export: |