From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753190AbdLULxO (ORCPT ); Thu, 21 Dec 2017 06:53:14 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:37152 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751884AbdLULxK (ORCPT ); Thu, 21 Dec 2017 06:53:10 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 2668B601D9 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sricharan@codeaurora.org Subject: Re: [PATCH v5 15/15] devicetree: bindings: Document qcom,pvs To: Rob Herring Cc: mark.rutland@arm.com, rjw@rjwysocki.net, devicetree@vger.kernel.org, Viresh Kumar , mturquette@baylibre.com, linux-pm@vger.kernel.org, sboyd@codeaurora.org, linux@armlinux.org.uk, linux-kernel@vger.kernel.org, david.brown@linaro.org, linux-arm-msm@vger.kernel.org, andy.gross@linaro.org, linux-soc@vger.kernel.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org References: <1513698900-10638-1-git-send-email-sricharan@codeaurora.org> <1513698900-10638-16-git-send-email-sricharan@codeaurora.org> <20171220032614.GQ19815@vireshk-i7> <20171220211817.mpkkj747blr4qkqm@rob-hp-laptop> From: Sricharan R Message-ID: <864b6cfd-d3eb-d876-82e2-ebc79c5a6956@codeaurora.org> Date: Thu, 21 Dec 2017 17:23:01 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171220211817.mpkkj747blr4qkqm@rob-hp-laptop> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 12/21/2017 2:48 AM, Rob Herring wrote: > On Wed, Dec 20, 2017 at 11:55:33AM +0530, Sricharan R wrote: >> Hi Viresh, >> >> On 12/20/2017 8:56 AM, Viresh Kumar wrote: >>> On 19-12-17, 21:25, Sricharan R wrote: >>>> + cpu@0 { >>>> + compatible = "qcom,krait"; >>>> + enable-method = "qcom,kpss-acc-v1"; >>>> + device_type = "cpu"; >>>> + reg = <0>; >>>> + qcom,acc = <&acc0>; >>>> + qcom,saw = <&saw0>; >>>> + clocks = <&kraitcc 0>; >>>> + clock-names = "cpu"; >>>> + cpu-supply = <&smb208_s2a>; >>>> + operating-points-v2 = <&cpu_opp_table>; >>>> + }; >>>> + >>>> + qcom,pvs { >>>> + qcom,pvs-format-a; >>>> + }; >>> >>> Not sure what Rob is going to say on that :) >>> >> >> Yes. Would be good to know the best way. > > Seems like this should be a property of an efuse node either implied by > the compatible or a separate property. What determines format A vs. B? > Yes, this efuse registers are part of the eeprom (qfprom) tied to the soc. So this property (details like bitfields and register offsets that it represents) can be put soc specific and nvmem apis can be used to read the registers. Does something like below look ok ? qcom,pvs { compatible = "qcom,pvs-ipq8064"; nvmem-cells = <&pvs_efuse>; } qfprom: qfprom@700000 { compatible = "qcom,qfprom"; reg = <0x00700000 0x1000>; #address-cells = <1>; #size-cells = <1>; ranges; pvs_efuse: pvs { reg = <0xc0 0x8>; }; }; Regards, Sricharan -- "QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation