From mboxrd@z Thu Jan 1 00:00:00 1970 From: Srinivas Kandagatla Subject: Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap. Date: Tue, 26 May 2015 10:12:31 +0100 Message-ID: <556438FF.7020105@linaro.org> References: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org> <1432226535-8640-1-git-send-email-srinivas.kandagatla@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Pantelis Antoniou Cc: linux-arm-msm@vger.kernel.org, devicetree , Arnd Bergmann , Greg Kroah-Hartman , Sascha Hauer , sboyd@codeaurora.org, Linux Kernel Mailing List , Rob Herring , Mark Brown , Kumar Gala , Matt Porter , Maxime Ripard , linux-api@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-api@vger.kernel.org SGkgUGFudGVsaXMsCgpPbiAyNS8wNS8xNSAxNzo1MSwgUGFudGVsaXMgQW50b25pb3Ugd3JvdGU6 Cj4gSGkgU3Jpbml2YXMsCj4KPj4gT24gTWF5IDIxLCAyMDE1LCBhdCAxOTo0MiAsIFNyaW5pdmFz IEthbmRhZ2F0bGEgPHNyaW5pdmFzLmthbmRhZ2F0bGFAbGluYXJvLm9yZz4gd3JvdGU6Cj4+Cj4+ IFRoYW5reW91IGFsbCBmb3IgcHJvdmlkaW5nIGlucHV0cyBhbmQgY29tbWVudHMgb24gcHJldmlv dXMgdmVyc2lvbnMgb2YgdGhpcyBwYXRjaHNldC4KPj4gSGVyZSBpcyB0aGUgdjUgb2YgdGhlIHBh dGNoc2V0IGFkZHJlc3NpbmcgYWxsIHRoZSBpc3N1ZXMgcmFpc2VkIGFzCj4+IHBhcnQgb2YgcHJl dmlvdXMgdmVyc2lvbnMgcmV2aWV3Lgo+Pgo+Cj4+Cj4KPiBbc25pcF0KPgo+IEkgdHJpZWQgdG8g dXNlIHRoZSB1cGRhdGVkIHBhdGNoc2V0IHdpdGggbXkgYXQyNCAmIGJlYWdsZWJvbmUgY2FwZW1h bmFnZXIgcGF0Y2hlcy4KVGhhbmtzIGZvciB0cnlpbmcgaXQgb3V0IGFuZCBtaWdyYXRpbmcgYXQy NCB0byBpdC4KCj4KPiBJIGhhdmUgYSBiaWcgcHJvYmxlbSB3aXRoIHRoZSByZW1vdmFsIG9mIHRo ZSByYXcgb2ZfKiBhY2Nlc3MgQVBJcy4KT2ssCj4KPiBUYWtlIGZvciBpbnN0YW5jZSB0aGUgY2Fz ZSB3aGVyZSB5b3UgaGF2ZSBtdWx0aXBsZSBzbG90IGFjY2Vzc2luZyBkaWZmZXJlbnQgRUVQUk9N cy4KPgo+PiBzbG90cyB7Cj4+IAlzbG90QDAgewo+PiAJCWVlcHJvbSA9IDwmY2FwZTBfZGF0YT47 Cj4+IAl9Owo+Pgo+PiAJc2xvdEAxIHsKPj4gCQllZXByb20gPSA8JmNhcGUxX2RhdGE+Owo+PiAJ fTsKPj4gfTsKCkNhbiBJIGFzayB5b3Ugd2h5IHNob3VsZCB0aGUgc2xvdHMgYmUgaW4gc3ViLW5v ZGVzPwpEbyB5b3UgZXhwZWN0IHRvIGhhdmUgbW9yZSBwcm9wZXJ0aWVzIGFzc29jaWF0ZWQgd2l0 aCBlYWNoIHNsb3QgaW4gZnV0dXJlPwpPciBpcyBpdCBqdXN0IHRvIGdldCBob2xkIG9mIGVlcHJv bSBkYXRhPwoKPgo+IEluIHRoYXQgY2FzZSB0aGVyZSBpcyBubyBwZXItZGV2aWNlIG5vZGUgbWFw cGluZzsgaXTigJlzIGEgcGVyLXN1YiBub2RlLgo+Cj4gRm9yIG5vdyBJ4oCZbSBleHBvcnRpbmcg dGhlIG9mXyogYWNjZXNzb3JzIGFnYWluLCBwbGVhc2UgY29uc2lkZXIgZXhwb3NpbmcgdGhlIG9m XyogQVBJIGFnYWluLgpTdXJlLCB3ZSBjYW4gZXhwb3J0IG9mX252bWVtX2NlbGxfZ2V0IHN5bWJv bCBmb3IgdXNlY2FzZXMgbGlrZSB0aGlzLgoKSGF2aW5nIHNhaWQgdGhhdCwgSSBnb3Qgb25lIGNv bW1lbnQgb24gdGhlIHdheSB0aGUgbnZtZW0gaXMgdXNlZCBpbiB5b3VyIApjYXNlLiBZb3Ugc2hv dWxkIHRyeSB0byB1c2UgbnZtZW1fZGV2aWNlX2dldCgpIGFuZCB0aGVuIHVzZSAKbnZtZW1fZGV2 aWNlX3JlYWQoKSBhcGlzLCBUaGVzZSBhcGlzIGFyZSBmb3IgY29uc3VtZXJzIGxpa2UgdGhpcyBv bmUuIApUaGUgYWR2YW50YWdlIG9mIHRoaXMgd291bGQgYmUgeW91IGRvIG5vdCBuZWVkIHJlYWQg YW5kIHN0b3JlIGFsbCBkYXRhIAppbiB0aGUgZHJpdmVyIGFuZCBwYXJzZSB0aGVtIGludGVybmFs bHkuIEJhc2ljYWxseSB5b3VyIGVlX2ZpZWxkX2dldCAKd291bGQganVzdCBkbyBudm1lbV9kZXZp Y2VfcmVhZCgpOyBEb2VzIGl0IG1ha2Ugc2Vuc2U/CgpXZSBjYW4gd29yayBvbiBob3cgdG8gZ2V0 IHRoZSBvZl8qYmFzZWQgb25jZSB5b3UgZGVjaWRlIHRvIG1vdmUgdG8gdGhpcyBhcGkuCgoKCi0t c3JpbmkKPgo+PiAtLQo+PiAxLjkuMQo+Pgo+Cj4gUmVnYXJkcwo+Cj4g4oCUIFBhbnRlbGlzCj4K Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFy bS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9y ZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1r ZXJuZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: srinivas.kandagatla@linaro.org (Srinivas Kandagatla) Date: Tue, 26 May 2015 10:12:31 +0100 Subject: [PATCH v5 00/11] Add simple NVMEM Framework via regmap. In-Reply-To: References: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org> <1432226535-8640-1-git-send-email-srinivas.kandagatla@linaro.org> Message-ID: <556438FF.7020105@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Pantelis, On 25/05/15 17:51, Pantelis Antoniou wrote: > Hi Srinivas, > >> On May 21, 2015, at 19:42 , Srinivas Kandagatla wrote: >> >> Thankyou all for providing inputs and comments on previous versions of this patchset. >> Here is the v5 of the patchset addressing all the issues raised as >> part of previous versions review. >> > >> > > [snip] > > I tried to use the updated patchset with my at24 & beaglebone capemanager patches. Thanks for trying it out and migrating at24 to it. > > I have a big problem with the removal of the raw of_* access APIs. Ok, > > Take for instance the case where you have multiple slot accessing different EEPROMs. > >> slots { >> slot at 0 { >> eeprom = <&cape0_data>; >> }; >> >> slot at 1 { >> eeprom = <&cape1_data>; >> }; >> }; Can I ask you why should the slots be in sub-nodes? Do you expect to have more properties associated with each slot in future? Or is it just to get hold of eeprom data? > > In that case there is no per-device node mapping; it?s a per-sub node. > > For now I?m exporting the of_* accessors again, please consider exposing the of_* API again. Sure, we can export of_nvmem_cell_get symbol for usecases like this. Having said that, I got one comment on the way the nvmem is used in your case. You should try to use nvmem_device_get() and then use nvmem_device_read() apis, These apis are for consumers like this one. The advantage of this would be you do not need read and store all data in the driver and parse them internally. Basically your ee_field_get would just do nvmem_device_read(); Does it make sense? We can work on how to get the of_*based once you decide to move to this api. --srini > >> -- >> 1.9.1 >> > > Regards > > ? Pantelis > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753344AbbEZNF5 (ORCPT ); Tue, 26 May 2015 09:05:57 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:33830 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753308AbbEZNFy (ORCPT ); Tue, 26 May 2015 09:05:54 -0400 Message-ID: <556438FF.7020105@linaro.org> Date: Tue, 26 May 2015 10:12:31 +0100 From: Srinivas Kandagatla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Pantelis Antoniou CC: linux-arm-kernel@lists.infradead.org, Maxime Ripard , Rob Herring , Kumar Gala , Mark Brown , Sascha Hauer , Greg Kroah-Hartman , linux-api@vger.kernel.org, Linux Kernel Mailing List , devicetree , linux-arm-msm@vger.kernel.org, Arnd Bergmann , sboyd@codeaurora.org, Matt Porter Subject: Re: [PATCH v5 00/11] Add simple NVMEM Framework via regmap. References: <1427752492-17039-1-git-send-email-srinivas.kandagatla@linaro.org> <1432226535-8640-1-git-send-email-srinivas.kandagatla@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Pantelis, On 25/05/15 17:51, Pantelis Antoniou wrote: > Hi Srinivas, > >> On May 21, 2015, at 19:42 , Srinivas Kandagatla wrote: >> >> Thankyou all for providing inputs and comments on previous versions of this patchset. >> Here is the v5 of the patchset addressing all the issues raised as >> part of previous versions review. >> > >> > > [snip] > > I tried to use the updated patchset with my at24 & beaglebone capemanager patches. Thanks for trying it out and migrating at24 to it. > > I have a big problem with the removal of the raw of_* access APIs. Ok, > > Take for instance the case where you have multiple slot accessing different EEPROMs. > >> slots { >> slot@0 { >> eeprom = <&cape0_data>; >> }; >> >> slot@1 { >> eeprom = <&cape1_data>; >> }; >> }; Can I ask you why should the slots be in sub-nodes? Do you expect to have more properties associated with each slot in future? Or is it just to get hold of eeprom data? > > In that case there is no per-device node mapping; it’s a per-sub node. > > For now I’m exporting the of_* accessors again, please consider exposing the of_* API again. Sure, we can export of_nvmem_cell_get symbol for usecases like this. Having said that, I got one comment on the way the nvmem is used in your case. You should try to use nvmem_device_get() and then use nvmem_device_read() apis, These apis are for consumers like this one. The advantage of this would be you do not need read and store all data in the driver and parse them internally. Basically your ee_field_get would just do nvmem_device_read(); Does it make sense? We can work on how to get the of_*based once you decide to move to this api. --srini > >> -- >> 1.9.1 >> > > Regards > > — Pantelis >