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:

quoted

Hi Viresh,

On 12/20/2017 8:56 AM, Viresh Kumar wrote:

quoted

On 19-12-17, 21:25, Sricharan R wrote:

quoted

+	cpu at 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 at 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