lkml.org 
[lkml]   [2015]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH v5 00/11] Add simple NVMEM Framework via regmap.
    From
    On Thu, May 21, 2015 at 9:42 AM, Srinivas Kandagatla
    <srinivas.kandagatla@linaro.org> wrote:
    > 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@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;
    >
    > };
    > ...
    > };
    >
    > 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?


    \
     
     \ /
      Last update: 2015-05-29 04:01    [W:4.242 / U:0.504 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site