On Fri, May 29, 2015 at 12:09 AM, Srinivas Kandagatla
[off-list ref] wrote:

On 29/05/15 02:20, Dan Williams wrote:

quoted

On Thu, May 21, 2015 at 9:42 AM, Srinivas Kandagatla
[off-list ref] wrote:

quoted

Thankyou all for providing inputs and comments on previous versions of
this patchset.
Here is the v5 of the patchset addressing all the issues raised as
part of previous versions review.

This patchset adds a new simple NVMEM framework to kernel.

Up until now, NVMEM drivers 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.

After learning few things about QCOM qfprom and other eeprom/efuses,
which
has packed fields at bit level. Which makes it important to add support
to
such memories. This version adds support to this type of non volatile
memories by adding support to bit level nvmem-cells.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

patch 1-2 Introduces two regmap helper functions.
patch 3-6 Introduces the NVMEM framework.
Patch 7 Adds helper functions for nvmems based on mmio.
Patch 8 migrates an existing driver to nvmem framework.
Patch 9-10 Adds Qualcomm specific qfprom driver.
Patch 11 adds entry in MAINTAINERS.

Its also possible to migrate other nvmem drivers to this framework.

Providers APIs:
         nvmem_register/unregister();

Consumers APIs:
Cell based apis for both DT/Non-DT:
         nvmem_cell_get()/nvmem_cell_put();
         nvmem_cell_read()/nvmem_cell_write();

Raw byte access apis for both DT/non-DT.
         nvmem_device_get()/nvmem_device_put()
         nvmem_device_read()/nvmem_device_write();
         nvmem_device_cell_read()/nvmem_device_cell_write();

Device Tree:

         /* Provider */
         qfprom: qfprom at 00700000 {
                 ...

                 /* Data cells */
                 tsens_calibration: calib at 404 {
                         reg = <0x404 0x10>;
                 };

                 tsens_calibration_bckp: calib_bckp at 504 {
                         reg = <0x504 0x11>;
                         bit-offset = 6;
                         nbits = 128;
                 };

                 pvs_version: pvs-version at 6 {
                         reg = <0x6 0x2>
                         bit-offset = 7;
                         nbits = 2;
                 };

                 speed_bin: speed-bin at c{
                         reg = <0xc 0x1>;
                         bit-offset = 2;
                         nbits   = 3;

                 };
                 ...
         };

userspace interface: binary file in /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

Changes since v4(https://lkml.org/lkml/2015/3/30/725)
  * rename eeprom to nvmem suggested by Matt Porter

Apologies for the bikeshed fly-by review, but given we already have
NVME and are adding an NVDIMM driver sub-system is s/eeprom/nvmem/ a
good idea?

IMO yes.

I did briefly looked at NVME before renaming the eeprom to nvmem,
NVME is aimed at defining the command/feature set for PCIe-based SSDs with
the goals of increased and efficient performance and interoperability.

This patch-set introduces simple nvmem which is applicable for non volatile
memories like efuses, eeprom, ROM, NVRAM .. etc, which are used in most
boards/SBC's. Data like calibration table, mac address or opps, are
generally stored this. This data is required by multiple drivers and
currently there is no framework in the kernel to address/abstract this,
resulting in code duplication.

Understood, but don't be surprised when people confuse NVMEM support
(sub to single digit megabyte capacities for firmware) and NVDIMM
support (multiple gigabyte capacities for i/o).