On 13/07/15 21:11, Stefan Wahren wrote:
Hi Srinivas,
Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx> hat am 13. Juli 2015 um
21:35 geschrieben:
On 13/07/15 19:54, Stefan Wahren wrote:
Hi Srinivas,
[...]
Providers APIs:
nvmem_register/unregister();
How do i get the cell info from the devicetree into the nvmem_config?
Not sure what is the real use-case here, But this is how it is supposed
to work.
cellinfo in nvmem_config is used to pass cell information in non-dt
style to the core. The core would parse it and convert into nvmem-cells.
Am not sure why would you want to do other way round. Could you explain
the real use case here?
my question comes from porting mxs_ocotp to NVMEM framework.
Here is the devicetree part:
ocotp: ocotp@8002c000 {
compatible = "fsl,imx28-ocotp", "fsl,ocotp";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x8002c000 0x2000>;
clocks = <&clks 25>;
read-only;
/* Data cells */
ocotp_customer: costumer@20 {
reg = <0x20 0x10>;
};
ocotp_rom0: rom0@1a0 {
reg = <0x1a0 0x4>;
};
};
After calling nvmem_register() in the provider driver [1] no data cell is
registered. So
i looked at the core code and i thought that retrieving the cell info and put it
into the nvmem_config
is job of the provider driver.
Did i missed something?
Ok,
There are 2 possible ways to specify nvmem cells
1> via the DT cell entries.
2> via provider driver directly using cell_info struct.
In the ocotp case its done via dt, so you dont need pass the cell info
in nvmem_config.
You should also note that cell structure in DT is only created when an
attempt to access is made as the provider lookup is straight forward in
this case. In non-DT case the cell structure is created immediately and
added to the global cell list.
--srini
[1] -
https://github.com/lategoodbye/fsl_ocotp/commit/7c98e19755b69f761885b0e1ceb2c258a7c47ade
...
userspace interface: binary file in /sys/bus/nvmem/devices/*/nvmem
ex:
hexdump /sys/bus/nvmem/devices/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
Since we're entering userspace the behavior should be clear.
How do we treat register gaps? Fill them with zero?
nvmem file would read full nvmem size which is passed to it as regmap.
So It would dump whatever the provider returns.
Sure, but wouldn't it be nice if different provider behave the same?
--srini
Best regards
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
