[v6,0/9] Add simple NVMEM Framework via regmap.

Commit Message

Srinivas Kandagatla June 24, 2015, 6:50 p.m. UTC

On 24/06/15 18:47, Stefan Wahren wrote:
> Hi Srinivas,
>
>> Srinivas Kandagatla <[e-mail]> hat am 24. Juni 2015 um
>> 15:03 geschrieben:
>>
>>
>>
>>
>> On 24/06/15 13:30, Stefan Wahren wrote:
>>>>> If the question is just about hexdump, then hexdump itself can read
>>>>> file from given offset and size.
>>> yes, this is my question at first. Let me show the difference between
>>> the current implementation and my expectations as a user.
>>>
>>> $ hexdump /sys/class/nvmem/mxs-ocotp/nvmem
>>>
>>> Current implementation: dump the complete register range defined in DT
>>>
>> Its dumping the range which is specified in the provider regmap. If the
>> requirement is to dump only particular range, this has to be made
>> explicit while creating regmap, which is to specify the base address to
>> start from "First data register" and max_register to be "Last data
>> register "- "First data register"
>
> i know about max_register, but i can't find the base address in regmap_config.
>
Base is not in the regmap config, its the value which you pass to the

For example, if I had to do similar change to qfprom driver It would 
look like:


 ><-----------------------cut---------------------------------><
                 return PTR_ERR(regmap);
 ><-----------------------cut---------------------------------><


--srini


> Do you mean struct regmap_access_table *rd_table ?
>
>>
>>> User expectation: dump only the data from OCOTP block
>>>
>>> Let me explain it for i.MX28 OCOTP
>>>
>>> 0x8002c000 // Start of OCOTP register block (defined in DT)
>>>
>>> 0x8002c020 // First data register
>>>
>>> 0x8002c290 // Last data register
>>>
>>> 0x8002dfff // End of OCOTP register block (defined in DT)
>>>
>>> My knowledge about regmap is limited, but how can i achieve that hexdump
>>> give me only the data registers? From my understanding this should be
>>> handled in regmap and not in the read function.
>>
>> Setup the base and regmap_config correctly in the provider driver before
>> calling regmap_init_mmio().
>>
>> Let me know if you need more details.
>
> Yes, please.
>
> Stefan
>
>>
>> --srini
>>
>>>
>>> Are my expectations about the raw access wrong?
>>>
>>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> [e-mail]
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Stefan Wahren June 30, 2015, 5:47 p.m. UTC | #1

Hi Srinivas,

> Srinivas Kandagatla <[e-mail]> hat am 24. Juni 2015 um
> 20:50 geschrieben:
>
>
>
>
> On 24/06/15 18:47, Stefan Wahren wrote:
> > Hi Srinivas,
> >
> >> Srinivas Kandagatla <[e-mail]> hat am 24. Juni 2015
> >> um
> >> 15:03 geschrieben:
> >>
> >>
> >>
> >>
> >> On 24/06/15 13:30, Stefan Wahren wrote:
> >>>>> If the question is just about hexdump, then hexdump itself can read
> >>>>> file from given offset and size.
> >>> yes, this is my question at first. Let me show the difference between
> >>> the current implementation and my expectations as a user.
> >>>
> >>> $ hexdump /sys/class/nvmem/mxs-ocotp/nvmem
> >>>
> >>> Current implementation: dump the complete register range defined in DT
> >>>
> >> Its dumping the range which is specified in the provider regmap. If the
> >> requirement is to dump only particular range, this has to be made
> >> explicit while creating regmap, which is to specify the base address to
> >> start from "First data register" and max_register to be "Last data
> >> register "- "First data register"
> >
> > i know about max_register, but i can't find the base address in
> > regmap_config.
> >
> Base is not in the regmap config, its the value which you pass to the
>

thanks for you explanation. I was confused by the word base because in your
example
it is the context variable.

Now i've successful tested my first version of the OCOTP driver based on NVMEM
framework [1].

Currently only the raw sysfs access is working. So i have another question:

How do i get the cell info from the devicetree for the nvmem_config?

I expected a function like of_nvmem_cell_info_get() .

Regards
Stefan

[1] -
https://github.com/lategoodbye/fsl_ocotp/commit/7c98e19755b69f761885b0e1ceb2c258a7c47ade
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/drivers/nvmem/qfprom.c b/drivers/nvmem/qfprom.c
index 7f7a82f..26ced95 100644
--- a/drivers/nvmem/qfprom.c
+++ b/drivers/nvmem/qfprom.c
@@ -52,9 +52,9 @@  static int qfprom_probe(struct platform_device *pdev)
         if (IS_ERR(base))
                 return PTR_ERR(base);

-       qfprom_regmap_config.max_register = resource_size(res) - 1;
+       qfprom_regmap_config.max_register = my_data_size;

-       regmap = devm_regmap_init_mmio(dev, base, &qfprom_regmap_config);
+       regmap = devm_regmap_init_mmio(dev, base + data_offset, 
&qfprom_regmap_config);
         if (IS_ERR(regmap)) {
                 dev_err(dev, "regmap init failed\n");