Re: [PATCH 0/2] nvmem: imx-ocotp: allow reads with arbitrary size and offset

[Srinivas Kandagatla <srinivas.kandagatla@linaro.org>]

On 23/07/2019 16:32, Jose Diaz de Grenu wrote:
> Currently the imx-ocotp driver does only allow reading complete OTP words
> correcty aligned.
> 
> Usually OTP memory is limited, so the fields are stored using as few bits as
> possible. This means that a given value rarely uses 32 bits and happens to be
> aligned.
> 
> Even though the NVMEM API offers a way to define offset and size of each cell
> (at bit level) this is not currently usable iwth the imx-ocotp driver, which
> forces consumers to read complete words and then hardcode the necessary
> shifting and masking in the driver code.
> 
> As an example take the nvmem consumer imx_thermal.c, which reads nvmem cells
> as uint32_t words:
> 
> 	ret = nvmem_cell_read_u32(&pdev->dev, "calib", &val);
> 	if (ret)
> 		return ret;
> 
> 	ret = imx_init_calib(pdev, val);
> 	if (ret)
> 		return ret;
> 
> 	ret = nvmem_cell_read_u32(&pdev->dev, "temp_grade", &val);
> 	if (ret)
> 		return ret;
> 	imx_init_temp_grade(pdev, val);
> 	
> but needs to later adjust the values in code:
> 
> 	// Inside imx_init_calib()
> 	data->c1 = (ocotp_ana1 >> 9) & 0x1ff;
> 
> 	// Inside imx_init_temp_grade()
> 	switch ((ocotp_mem0 >> 6) & 0x3) {
> 	
> This patch adjusts the driver so that reads can be requested using any size
> and offset. Then, for example the nvmem cell "calib" could use the 'bits'
> property to specify size and offset in bits, removing the need to mask and
> shift in the driver code.
> 
> This is specially useful when several drivers use the same nvmem cell and when
> the specific size and offset of a OTP value depends on a hardware version.
> 
> Jose Diaz de Grenu (2):
>    nvmem: imx-ocotp: use constant for write restriction
>    nvmem: imx-ocotp: allow reads with arbitrary size and offset
> 
>   drivers/nvmem/imx-ocotp.c | 34 ++++++++++++++++------------------
>   1 file changed, 16 insertions(+), 18 deletions(-)

Anyone form IMX can test this patchset before I push this out?

Thanks,
srini
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel