Re: [PATCH v7 0/9] Add simple NVMEM Framework via regmap.

[Srinivas Kandagatla]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/