From patchwork Mon Jun 22 23:09:07 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Srinivas Kandagatla X-Patchwork-Id: 50188 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wi0-f198.google.com (mail-wi0-f198.google.com [209.85.212.198]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id BE6EA21575 for ; Mon, 22 Jun 2015 23:09:24 +0000 (UTC) Received: by wiea6 with SMTP id a6sf147838wie.1 for ; Mon, 22 Jun 2015 16:09:24 -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:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=4oOAoue75oBR4nL+s77OaEGC/3Xc67fNuA0XNc6eVos=; b=DPCpjEsiIsVFD0avPoxrpX0xex2JZbPTfq4GFriVBMHnSnwJ+76n4ya1O1iytGAE5N 4mJol4mEBFvx0v60FU8uTCxr2aUb6wET9K8TTZtaGLayvGw4DAyhE3HAeYHw0C9hFaSs nnO6G/1uHeEwMwlp3YTJLjypIFc8oQuODGTMrfDoCUPz9MKBZC9nEhjmjPAnp2HVB3zC VzNGN4NWdU/05UpJUmYVV2ZEHO0CDfCvl+yXmE0mSlEasPM9JWfn8zKvKH3Eo4CE+tyE PVHUhm8iyp6HGOyub35JySV5nNA08vkR5INQUtJBpmauN7wybg1xioUvTSj0hXf6/zGY WSTQ== X-Gm-Message-State: ALoCoQlXeKlPY7japUNy3DPAii6jy+cgyN7h9Vrbc3o5OJqT1scS325nwKCqzcSnmLzjXKX4YTDX X-Received: by 10.180.90.106 with SMTP id bv10mr17692830wib.6.1435014564112; Mon, 22 Jun 2015 16:09:24 -0700 (PDT) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.120.71 with SMTP id la7ls916283lab.25.gmail; Mon, 22 Jun 2015 16:09:23 -0700 (PDT) X-Received: by 10.112.93.37 with SMTP id cr5mr32703445lbb.106.1435014563946; Mon, 22 Jun 2015 16:09:23 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com. [209.85.215.45]) by mx.google.com with ESMTPS id r1si17759919lar.2.2015.06.22.16.09.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2015 16:09:23 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.45 as permitted sender) client-ip=209.85.215.45; Received: by lagi2 with SMTP id i2so29605049lag.2 for ; Mon, 22 Jun 2015 16:09:23 -0700 (PDT) X-Received: by 10.152.36.161 with SMTP id r1mr32323459laj.88.1435014563840; Mon, 22 Jun 2015 16:09:23 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.108.230 with SMTP id hn6csp2688707lbb; Mon, 22 Jun 2015 16:09:22 -0700 (PDT) X-Received: by 10.70.0.202 with SMTP id 10mr6658663pdg.41.1435014561628; Mon, 22 Jun 2015 16:09:21 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id kp10si31653008pdb.200.2015.06.22.16.09.20; Mon, 22 Jun 2015 16:09:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-arm-msm-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753681AbbFVXJQ (ORCPT + 6 others); Mon, 22 Jun 2015 19:09:16 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:35102 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932194AbbFVXJN (ORCPT ); Mon, 22 Jun 2015 19:09:13 -0400 Received: by wiga1 with SMTP id a1so90442112wig.0 for ; Mon, 22 Jun 2015 16:09:11 -0700 (PDT) X-Received: by 10.194.200.73 with SMTP id jq9mr55743630wjc.52.1435014551905; Mon, 22 Jun 2015 16:09:11 -0700 (PDT) Received: from srini-ThinkPad-X1-Carbon-2nd.dlink.com (host-2-98-208-65.as13285.net. [2.98.208.65]) by mx.google.com with ESMTPSA id tl3sm32717381wjc.20.2015.06.22.16.09.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Jun 2015 16:09:11 -0700 (PDT) From: Srinivas Kandagatla To: linux-arm-kernel@lists.infradead.org, Greg Kroah-Hartman Cc: Maxime Ripard , Rob Herring , Kumar Gala , Mark Brown , s.hauer@pengutronix.de, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, arnd@arndb.de, sboyd@codeaurora.org, pantelis.antoniou@konsulko.com, mporter@konsulko.com, stefan.wahren@i2se.com, wxt@rock-chips.com, Srinivas Kandagatla Subject: [PATCH v6 5/9] Documentation: nvmem: add nvmem api level and how-to doc Date: Tue, 23 Jun 2015 00:09:07 +0100 Message-Id: <1435014547-26350-1-git-send-email-srinivas.kandagatla@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1435014459-26138-1-git-send-email-srinivas.kandagatla@linaro.org> References: <1435014459-26138-1-git-send-email-srinivas.kandagatla@linaro.org> Sender: linux-arm-msm-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: srinivas.kandagatla@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.45 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , This patch add basic how-to and api summary documentation for simple NVMEM framework. Signed-off-by: Srinivas Kandagatla --- Documentation/nvmem/nvmem.txt | 151 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 Documentation/nvmem/nvmem.txt diff --git a/Documentation/nvmem/nvmem.txt b/Documentation/nvmem/nvmem.txt new file mode 100644 index 0000000..28b3579 --- /dev/null +++ b/Documentation/nvmem/nvmem.txt @@ -0,0 +1,151 @@ + NVMEM SUBSYSTEM + Srinivas Kandagatla + +This document explains the Simple NVMEM Framework along with the APIs provided, +and how-to-use. + +1. Introduction +=============== +*NVMEM* is the abbreviation for Non Volatile Memory layer. It is used to +retrieve configuration or SOC or Device specific data from a non volatile memories +like eeprom, efuses and so on. + +Up until now, NVMEM drivers like eeprom were stored in drivers/misc, where they +all had to duplicate pretty much the same code to register a sysfs file, allow +in-kernel users to access the content of the devices they were driving, etc. + +This was also a problem as far as other in-kernel users were involved, since +the solutions used were pretty much different from on driver to another, there +was a rather big abstraction leak. + +Introduction of this framework aims at solving this. 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. + +NVMEM Providers ++++++++++++++++ + +NVMEM provider refers to an entity that implements methods to initialize, read +and write the non-volatile memory. + +2. Registering/Unregistering the NVMEM provider +=============================================== + +A NVMEM provider can register with NVMEM core by suppling relevant +nvmem configuration to nvmem_register(), on success core would return a valid +nvmem_device pointer. + +nvmem_unregister(nvmem) is used to unregister the already registered provider. + +For example for simple qfprom case: + +static struct nvmem_config econfig = { + .name = "qfprom", + .owner = THIS_MODULE, +}; + +static int qfprom_probe(struct platform_device *pdev) +{ + ... + econfig.dev = &pdev->dev; + nvmem = nvmem_register(&econfig); + ... +} + +It is mandatory that the NVMEM provider has a regmap associated with its +struct device. + +NVMEM Consumers ++++++++++++++++ + +NVMEM consumers are the entities which make use of the NVMEM provider to +read/write into NVMEM. + +3. NVMEM cell based consumer APIs. +================================= + +NVMEM cells are the data entries/fields in the NVMEM. +The NVMEM framework provides 3 APIs to read/write NVMEM cells. + +struct nvmem_cell *nvmem_cell_get(struct device *dev, const char *name); +struct nvmem_cell *devm_nvmem_cell_get(struct device *dev, const char *name); + +void nvmem_cell_put(struct nvmem_cell *cell); +void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell); + +void *nvmem_cell_read(struct nvmem_cell *cell, ssize_t *len); +int nvmem_cell_write(struct nvmem_cell *cell, void *buf, ssize_t len); + +*nvmem_cell_get() apis will get a reference to nvmem cell for a given id, +and nvmem_cell_read/write() can then directly read or write to the cell. +Once the usage of the cell is finished the consumer should call *nvmem_cell_put() +to free all the allocation memory for the cell. + +4. Direct NVMEM device based consumer APIs. +========================================== + +In some instances it is necessary to directly read/write the NVMEM. +To facilitate such consumers NVMEM framework provides below apis. + +struct nvmem_device *nvmem_device_get(struct device *dev, const char *name); +struct nvmem_device *devm_nvmem_device_get(struct device *dev, + const char *name); +void nvmem_device_put(struct nvmem_device *nvmem); +int nvmem_device_read(struct nvmem_device *nvmem, unsigned int offset, + size_t bytes, void *buf); +int nvmem_device_write(struct nvmem_device *nvmem, unsigned int offset, + size_t bytes, void *buf); +int nvmem_device_cell_read(struct nvmem_device *nvmem, + struct nvmem_cell_info *info, void *buf); +int nvmem_device_cell_write(struct nvmem_device *nvmem, + struct nvmem_cell_info *info, void *buf); + +Before the consumers can read/write NVMEM directly, it should get hold +of nvmem_controller from one of the *nvmem_device_get() api. + +Difference between these apis and cell based apis is that these apis +always take nvmem_device as parameter. + +5. Releasing a reference to the NVMEM +===================================== + +When the consumers no longer needs the NVMEM, it has to release the reference +to the NVMEM it has obtained using the APIs mentioned in the above section. +NVMEM framework provides 2 APIs to release a reference to the NVMEM. + +void nvmem_cell_put(struct nvmem_cell *cell); +void devm_nvmem_cell_put(struct device *dev, struct nvmem_cell *cell); +void nvmem_device_put(struct nvmem_device *nvmem); +void devm_nvmem_device_put(struct device *dev, struct nvmem_device *nvmem); + +Both these APIs are used to release a reference to the NVMEM and +devm_nvmem_cell_put and devm_nvmem_device_put destroys the devres associated +with this NVMEM. + +Userspace ++++++++++ + +6. Userspace binary interface. +============================== + +Userspace can read/write the raw NVMEM file located at /sys/class/nvmem/*/nvmem + +ex: + +hexdump /sys/class/nvmem/qfprom0/nvmem + +0000000 0000 0000 0000 0000 0000 0000 0000 0000 +* +00000a0 db10 2240 0000 e000 0c00 0c00 0000 0c00 +0000000 0000 0000 0000 0000 0000 0000 0000 0000 +... +* +0001000 + +7. DeviceTree Binding +===================== + +The documentation for NVMEM dt binding can be found @ +Documentation/devicetree/bindings/nvmem/nvmem.txt