Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753080AbbGMULu (ORCPT ); Mon, 13 Jul 2015 16:11:50 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:54713 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751115AbbGMULs (ORCPT ); Mon, 13 Jul 2015 16:11:48 -0400 Date: Mon, 13 Jul 2015 22:11:10 +0200 (CEST) From: Stefan Wahren Reply-To: Stefan Wahren To: Srinivas Kandagatla , Greg Kroah-Hartman , linux-arm-kernel@lists.infradead.org Cc: wxt@rock-chips.com, linux-api@vger.kernel.org, Rob Herring , Kumar Gala , arnd@arndb.de, sboyd@codeaurora.org, s.hauer@pengutronix.de, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, mporter@konsulko.com, pantelis.antoniou@konsulko.com, ezequiel@vanguardiasur.com.ar, Mark Brown , devicetree@vger.kernel.org Message-ID: <139301016.164015.1436818270753.JavaMail.open-xchange@oxbsltgw04.schlund.de> In-Reply-To: <55A4131C.7040700@linaro.org> References: <1436521427-10568-1-git-send-email-srinivas.kandagatla@linaro.org> <1984575203.163267.1436813665815.JavaMail.open-xchange@oxbsltgw06.schlund.de> <55A4131C.7040700@linaro.org> Subject: Re: [PATCH v7 0/9] Add simple NVMEM Framework via regmap. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.6.2-Rev20 X-Originating-Client: com.openexchange.ox.gui.dhtml X-Provags-ID: V03:K0:wwpTMebkpi/kqQfJGl4V8BPd6hbKp77b+ZHMabCTvQ5Iwf2E4Vj MWH0E2pso8nCprFilYvYjcIAGr6Jzy8jEyMZ0SXrNJOtpp7WzqCUbzcMqx49dCgHLBlOtWM yN29Lx5BSRifc9LHLimrXQdpREnOXcWt+SD1bwVPYaAWNt5aId84W2Mx5PhS7D7o25Fmx2E J8mazFRchzQVsLxLOlh7Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:x9+Ui3LYgRE=:f7e1eGhI41jDNIC3vlHcMm JWIo7OEzvdpE4Zf8GtqkjZ5DkfM6sFM5kWXfZVDsXrn3XoPL+ppC7ICxhYmXsqt22KkgBtqFi KcKmKcMCCm2LiPADuHpB0MCMgX6soG5saxc3j7oxMRfwtTAMC1edZLEfsGJEJoP+4ZNXZTcV5 j8E6n0MfmwKju8Wh2VA75KTNEcH20YleDOQAq/86RvzbbUgV80kbiV6P8rwVtpcPdpl4RAK4g 0zPVCJAZKzz3EPn4xKm7HHzfZ7aT16HOHS7E+pKXc1TFSjZFkTBhBLYV8lvcM0hbE+Jr9Kd1R At1BKM5FzLp09rHub/1vXTX3uBCbJlRzVNkPSXoYPvnhQYYUZ/D23R4QehTBKDk5HN9Gvh2sv qO1TCsIvcaIO3r1ET1++Htt/3KnxIs9lRJyvIisV/vNdR6TCf/OHTn5px5ApCLgYqmgFI+S8b zQqkanQQzN0KAoUChZKOGgz22EDBWYaJrzQcSDAAqD3ubw7njxywk7HgamIqjr5YfPOfR7+Lk RueFKPNEwYUHPrvDQXT9t6rfyCtHYWd/GpNwXHQOE/EIeTrJZmGtlDlQgnTdV2DKzlumfW0Ef 0V7Hi/gJA33GfGi06Jv26NeaNS1Z51obzWs+M1G3xzd2fK0ANObHteCwGs/dud/ZgSLfdyLll 66E9Lqo9E2ee5xJUeQgnP4/3S1WlAoRiZsJeGsQQlRsy8wA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2382 Lines: 95 Hi Srinivas, > Srinivas Kandagatla 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? [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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/