* [PATCH v15 2/2] dt-bindings: cpufreq: Document operating-points-v2-kryo-cpu
From: Ilia Lin @ 2018-05-30 2:39 UTC (permalink / raw)
To: ilia.lin, vireshk, nm, sboyd, robh, mark.rutland, rjw
Cc: linux-pm, devicetree, linux-kernel, ilialin
In-Reply-To: <1527647969-15716-1-git-send-email-ilialin@codeaurora.org>
The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
to provide the OPP framework with required information.
This is used to determine the voltage and frequency value for each OPP of
operating-points-v2 table when it is parsed by the OPP framework.
This change adds documentation for the DT bindings.
The "operating-points-v2-kryo-cpu" DT extends the "operating-points-v2"
with following parameters:
- nvmem-cells (NVMEM area containig the speedbin information)
- opp-supported-hw: A single 32 bit bitmap value,
representing compatible HW:
0: MSM8996 V3, speedbin 0
1: MSM8996 V3, speedbin 1
2: MSM8996 V3, speedbin 2
3: unused
4: MSM8996 SG, speedbin 0
5: MSM8996 SG, speedbin 1
6: MSM8996 SG, speedbin 2
7-31: unused
Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
.../devicetree/bindings/opp/kryo-cpufreq.txt | 680 +++++++++++++++++++++
1 file changed, 680 insertions(+)
create mode 100644 Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
new file mode 100644
index 0000000..c2127b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/opp/kryo-cpufreq.txt
@@ -0,0 +1,680 @@
+Qualcomm Technologies, Inc. KRYO CPUFreq and OPP bindings
+===================================
+
+In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996
+that have KRYO processors, the CPU ferequencies subset and voltage value
+of each OPP varies based on the silicon variant in use.
+Qualcomm Technologies, Inc. Process Voltage Scaling Tables
+defines the voltage and frequency value based on the msm-id in SMEM
+and speedbin blown in the efuse combination.
+The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC
+to provide the OPP framework with required information (existing HW bitmap).
+This is used to determine the voltage and frequency value for each OPP of
+operating-points-v2 table when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-kryo-cpu' for apq8096 and msm8996.
+- nvmem-cells: A phandle pointing to a nvmem-cells node representing the
+ efuse registers that has information about the
+ speedbin that is used to select the right frequency/voltage
+ value pair.
+ Please refer the for nvmem-cells
+ bindings Documentation/devicetree/bindings/nvmem/nvmem.txt
+ and also examples below.
+
+In every OPP node:
+- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW.
+ Bitmap:
+ 0: MSM8996 V3, speedbin 0
+ 1: MSM8996 V3, speedbin 1
+ 2: MSM8996 V3, speedbin 2
+ 3: unused
+ 4: MSM8996 SG, speedbin 0
+ 5: MSM8996 SG, speedbin 1
+ 6: MSM8996 SG, speedbin 2
+ 7-31: unused
+
+Example 1:
+---------
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ L2_0: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU1: cpu@1 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ clocks = <&kryocc 0>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster0_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_0>;
+ };
+
+ CPU2: cpu@100 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ L2_1: l2-cache {
+ compatible = "cache";
+ cache-level = <2>;
+ };
+ };
+
+ CPU3: cpu@101 {
+ device_type = "cpu";
+ compatible = "qcom,kryo";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ clocks = <&kryocc 1>;
+ cpu-supply = <&pm8994_s11_saw>;
+ operating-points-v2 = <&cluster1_opp>;
+ #cooling-cells = <2>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+
+ core1 {
+ cpu = <&CPU1>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&CPU2>;
+ };
+
+ core1 {
+ cpu = <&CPU3>;
+ };
+ };
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-422400000 {
+ opp-hz = /bits/ 64 <422400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-768000000 {
+ opp-hz = /bits/ 64 <768000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-844800000 {
+ opp-hz = /bits/ 64 <844800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-960000000 {
+ opp-hz = /bits/ 64 <960000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x72>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x5>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1497600000 {
+ opp-hz = /bits/ 64 <1497600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x4>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x20>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2188800000 {
+ opp-hz = /bits/ 64 <2188800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp: opp_table1 {
+ compatible = "operating-points-v2-kryo-cpu";
+ nvmem-cells = <&speedbin_efuse>;
+ opp-shared;
+
+ opp-307200000 {
+ opp-hz = /bits/ 64 <307200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x77>;
+ clock-latency-ns = <200000>;
+ };
+ opp-384000000 {
+ opp-hz = /bits/ 64 <384000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-403200000 {
+ opp-hz = /bits/ 64 <403200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-460800000 {
+ opp-hz = /bits/ 64 <460800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-537600000 {
+ opp-hz = /bits/ 64 <537600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-556800000 {
+ opp-hz = /bits/ 64 <556800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-652800000 {
+ opp-hz = /bits/ 64 <652800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-691200000 {
+ opp-hz = /bits/ 64 <691200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-729600000 {
+ opp-hz = /bits/ 64 <729600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-748800000 {
+ opp-hz = /bits/ 64 <748800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-806400000 {
+ opp-hz = /bits/ 64 <806400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-825600000 {
+ opp-hz = /bits/ 64 <825600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-883200000 {
+ opp-hz = /bits/ 64 <883200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-902400000 {
+ opp-hz = /bits/ 64 <902400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-940800000 {
+ opp-hz = /bits/ 64 <940800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-979200000 {
+ opp-hz = /bits/ 64 <979200000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1036800000 {
+ opp-hz = /bits/ 64 <1036800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1056000000 {
+ opp-hz = /bits/ 64 <1056000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1113600000 {
+ opp-hz = /bits/ 64 <1113600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1132800000 {
+ opp-hz = /bits/ 64 <1132800000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1190400000 {
+ opp-hz = /bits/ 64 <1190400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1209600000 {
+ opp-hz = /bits/ 64 <1209600000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1248000000 {
+ opp-hz = /bits/ 64 <1248000000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1286400000 {
+ opp-hz = /bits/ 64 <1286400000>;
+ opp-microvolt = <905000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1324800000 {
+ opp-hz = /bits/ 64 <1324800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1363200000 {
+ opp-hz = /bits/ 64 <1363200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1401600000 {
+ opp-hz = /bits/ 64 <1401600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1440000000 {
+ opp-hz = /bits/ 64 <1440000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1478400000 {
+ opp-hz = /bits/ 64 <1478400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1516800000 {
+ opp-hz = /bits/ 64 <1516800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1555200000 {
+ opp-hz = /bits/ 64 <1555200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1593600000 {
+ opp-hz = /bits/ 64 <1593600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1632000000 {
+ opp-hz = /bits/ 64 <1632000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1670400000 {
+ opp-hz = /bits/ 64 <1670400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1708800000 {
+ opp-hz = /bits/ 64 <1708800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1747200000 {
+ opp-hz = /bits/ 64 <1747200000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x70>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1785600000 {
+ opp-hz = /bits/ 64 <1785600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x7>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1804800000 {
+ opp-hz = /bits/ 64 <1804800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x6>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1824000000 {
+ opp-hz = /bits/ 64 <1824000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x71>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1900800000 {
+ opp-hz = /bits/ 64 <1900800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x74>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1920000000 {
+ opp-hz = /bits/ 64 <1920000000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1977600000 {
+ opp-hz = /bits/ 64 <1977600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-1996800000 {
+ opp-hz = /bits/ 64 <1996800000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2054400000 {
+ opp-hz = /bits/ 64 <2054400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x30>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2073600000 {
+ opp-hz = /bits/ 64 <2073600000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x1>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2150400000 {
+ opp-hz = /bits/ 64 <2150400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x31>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2246400000 {
+ opp-hz = /bits/ 64 <2246400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ opp-2342400000 {
+ opp-hz = /bits/ 64 <2342400000>;
+ opp-microvolt = <1140000 905000 1140000>;
+ opp-supported-hw = <0x10>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+....
+
+reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+....
+ smem_mem: smem-mem@86000000 {
+ reg = <0x0 0x86000000 0x0 0x200000>;
+ no-map;
+ };
+....
+};
+
+smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_mem>;
+ hwlocks = <&tcsr_mutex 3>;
+};
+
+soc {
+....
+ qfprom: qfprom@74000 {
+ compatible = "qcom,qfprom";
+ reg = <0x00074000 0x8ff>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ....
+ speedbin_efuse: speedbin@133 {
+ reg = <0x133 0x1>;
+ bits = <5 3>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6 05/15] usb: typec: add API to get typec basic port power and data config
From: kbuild test robot @ 2018-05-30 4:25 UTC (permalink / raw)
To: Li Jun
Cc: kbuild-all, robh+dt, gregkh, heikki.krogerus, linux, cw00.choi,
a.hajda, shufan_lee, peter.chen, garsilva, gsomlo, linux-usb,
devicetree, linux-imx
In-Reply-To: <1527475967-15201-6-git-send-email-jun.li@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 4364 bytes --]
Hi Li,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.17-rc7 next-20180529]
[cannot apply to staging/staging-testing]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Li-Jun/staging-typec-tcpci-move-out-of-staging/20180530-110011
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: i386-randconfig-x017-201821 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from include/linux/linkage.h:7:0,
from include/linux/kernel.h:7,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from drivers/usb/typec/class.c:9:
>> drivers/usb/typec/class.c:1274:19: error: 'typec_find_power_type' undeclared here (not in a function); did you mean 'typec_find_power_role'?
EXPORT_SYMBOL_GPL(typec_find_power_type);
^
include/linux/export.h:65:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
>> drivers/usb/typec/class.c:1274:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(typec_find_power_type);
^~~~~~~~~~~~~~~~~
>> drivers/usb/typec/class.c:1288:19: error: 'typec_find_preferred_role' undeclared here (not in a function); did you mean 'typec_find_power_role'?
EXPORT_SYMBOL_GPL(typec_find_preferred_role);
^
include/linux/export.h:65:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
drivers/usb/typec/class.c:1288:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(typec_find_preferred_role);
^~~~~~~~~~~~~~~~~
>> drivers/usb/typec/class.c:1303:19: error: 'typec_find_data_type' undeclared here (not in a function); did you mean 'typec_find_power_type'?
EXPORT_SYMBOL_GPL(typec_find_data_type);
^
include/linux/export.h:65:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
drivers/usb/typec/class.c:1303:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(typec_find_data_type);
^~~~~~~~~~~~~~~~~
vim +1274 drivers/usb/typec/class.c
1260
1261 /**
1262 * typec_find_port_power_role - Get the typec port power capability
1263 * @name: port power capability string
1264 *
1265 * This routine is used to find the typec_port_type by its string name.
1266 *
1267 * Returns typec_port_type if success, otherwise negative error code.
1268 */
1269 int typec_find_port_power_role(const char *name)
1270 {
1271 return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
1272 name);
1273 }
> 1274 EXPORT_SYMBOL_GPL(typec_find_power_type);
1275
1276 /**
1277 * typec_find_power_role - Find the typec one specific power role
1278 * @name: power role string
1279 *
1280 * This routine is used to find the typec_role by its string name.
1281 *
1282 * Returns typec_role if success, otherwise negative error code.
1283 */
1284 int typec_find_power_role(const char *name)
1285 {
1286 return match_string(typec_roles, ARRAY_SIZE(typec_roles), name);
1287 }
> 1288 EXPORT_SYMBOL_GPL(typec_find_preferred_role);
1289
1290 /**
1291 * typec_find_port_data_role - Get the typec port data capability
1292 * @name: port data capability string
1293 *
1294 * This routine is used to find the typec_port_data by its string name.
1295 *
1296 * Returns typec_port_data if success, otherwise negative error code.
1297 */
1298 int typec_find_port_data_role(const char *name)
1299 {
1300 return match_string(typec_data_caps, ARRAY_SIZE(typec_data_caps),
1301 name);
1302 }
> 1303 EXPORT_SYMBOL_GPL(typec_find_data_type);
1304
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29759 bytes --]
^ permalink raw reply
* Re: [PATCH 07/15] arm: dts: exynos: Add missing cooling device properties for CPUs
From: Viresh Kumar @ 2018-05-30 4:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: arm, Rob Herring, Mark Rutland, Kukjin Kim, Vincent Guittot,
ionela.voinescu, Daniel Lezcano, chris.redpath, devicetree,
linux-arm-kernel, linux-samsung-soc@vger.kernel.org, linux-kernel
In-Reply-To: <CAJKOXPcyV=fdRu7oLXHMimSFR9ktJ23uBriswTStkEkAMbTaNw@mail.gmail.com>
On 29-05-18, 15:18, Krzysztof Kozlowski wrote:
> Thanks for the patch.
>
> In case of Exynos, the booting CPU always has these information in DT
> and the booting CPU cannot be changed (chosen by firmware/hardware
> configuration).
But can the booting CPU be offlined ?
If yes, then this is how things are broken right now.
Build cpufreq driver as module, boot kernel, hotplug out CPU0, insert
cpufreq driver and that will try to find these properties in CPU1.
> Therefore there is no real risk of falling although
> for correctness of DT your change makes sense.
>
> It is too late for this cycle for me so I'll pick it up after merge window.
> Alternatively, arm-soc guys can pick it up directly with my tag:
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
No worries, you can pick it up later on.
--
viresh
^ permalink raw reply
* [PATCH V2 13/15] arm: dts: r8a77xx: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-30 4:46 UTC (permalink / raw)
To: arm, biju.das, Simon Horman, Magnus Damm, Rob Herring,
Mark Rutland
Cc: Viresh Kumar, Vincent Guittot, ionela.voinescu, Daniel Lezcano,
chris.redpath, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <5821a6dbe413b5a217ca1e24ddf8ebfa63ba6ef0.1527244201.git.viresh.kumar@linaro.org>
The OPP properties, like "operating-points", should either be present
for all the CPUs of a cluster or none. If these are present only for a
subset of CPUs of a cluster then things will start falling apart as soon
as the CPUs are brought online in a different order. For example, this
will happen because the operating system looks for such properties in
the CPU node it is trying to bring up, so that it can create an OPP
table.
Add such missing properties.
Fix other missing properties (like, clock latency, voltage tolerance,
etc) as well to make it all work.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
arch/arm/boot/dts/r8a7743.dtsi | 9 +++++++++
arch/arm/boot/dts/r8a7790.dtsi | 34 ++++++++++++++++++++++++++++++++--
arch/arm/boot/dts/r8a7791.dtsi | 14 ++++++++++++--
arch/arm/boot/dts/r8a7793.dtsi | 15 +++++++++++++--
4 files changed, 66 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 142949d7066f..e4fb31c4f0ee 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -98,8 +98,17 @@
reg = <1>;
clock-frequency = <1500000000>;
clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ clock-latency = <300000>; /* 300 us */
power-domains = <&sysc R8A7743_PD_CA15_CPU1>;
next-level-cache = <&L2_CA15>;
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1500000 1000000>,
+ <1312500 1000000>,
+ <1125000 1000000>,
+ < 937500 1000000>,
+ < 750000 1000000>,
+ < 375000 1000000>;
};
L2_CA15: cache-controller-0 {
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 4d06b154bd7e..c4324b1a2ec4 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -79,12 +79,12 @@
compatible = "arm,cortex-a15";
reg = <0>;
clock-frequency = <1300000000>;
- voltage-tolerance = <1>; /* 1% */
clocks = <&cpg CPG_CORE R8A7790_CLK_Z>;
- clock-latency = <300000>; /* 300 us */
power-domains = <&sysc R8A7790_PD_CA15_CPU0>;
next-level-cache = <&L2_CA15>;
capacity-dmips-mhz = <1024>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
/* kHz - uV - OPPs unknown yet */
operating-points = <1400000 1000000>,
@@ -104,6 +104,16 @@
power-domains = <&sysc R8A7790_PD_CA15_CPU1>;
next-level-cache = <&L2_CA15>;
capacity-dmips-mhz = <1024>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1400000 1000000>,
+ <1225000 1000000>,
+ <1050000 1000000>,
+ < 875000 1000000>,
+ < 700000 1000000>,
+ < 350000 1000000>;
};
cpu2: cpu@2 {
@@ -115,6 +125,16 @@
power-domains = <&sysc R8A7790_PD_CA15_CPU2>;
next-level-cache = <&L2_CA15>;
capacity-dmips-mhz = <1024>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1400000 1000000>,
+ <1225000 1000000>,
+ <1050000 1000000>,
+ < 875000 1000000>,
+ < 700000 1000000>,
+ < 350000 1000000>;
};
cpu3: cpu@3 {
@@ -126,6 +146,16 @@
power-domains = <&sysc R8A7790_PD_CA15_CPU3>;
next-level-cache = <&L2_CA15>;
capacity-dmips-mhz = <1024>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1400000 1000000>,
+ <1225000 1000000>,
+ <1050000 1000000>,
+ < 875000 1000000>,
+ < 700000 1000000>,
+ < 350000 1000000>;
};
cpu4: cpu@100 {
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 6e1dd7ad7bd6..d1d726a1364a 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -78,11 +78,11 @@
compatible = "arm,cortex-a15";
reg = <0>;
clock-frequency = <1500000000>;
- voltage-tolerance = <1>; /* 1% */
clocks = <&cpg CPG_CORE R8A7791_CLK_Z>;
- clock-latency = <300000>; /* 300 us */
power-domains = <&sysc R8A7791_PD_CA15_CPU0>;
next-level-cache = <&L2_CA15>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
/* kHz - uV - OPPs unknown yet */
operating-points = <1500000 1000000>,
@@ -101,6 +101,16 @@
clocks = <&cpg CPG_CORE R8A7791_CLK_Z>;
power-domains = <&sysc R8A7791_PD_CA15_CPU1>;
next-level-cache = <&L2_CA15>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1500000 1000000>,
+ <1312500 1000000>,
+ <1125000 1000000>,
+ < 937500 1000000>,
+ < 750000 1000000>,
+ < 375000 1000000>;
};
L2_CA15: cache-controller-0 {
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 4abecfc0ca98..1e6439b85a6b 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -70,10 +70,10 @@
compatible = "arm,cortex-a15";
reg = <0>;
clock-frequency = <1500000000>;
- voltage-tolerance = <1>; /* 1% */
clocks = <&cpg CPG_CORE R8A7793_CLK_Z>;
- clock-latency = <300000>; /* 300 us */
power-domains = <&sysc R8A7793_PD_CA15_CPU0>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
/* kHz - uV - OPPs unknown yet */
operating-points = <1500000 1000000>,
@@ -92,6 +92,17 @@
clock-frequency = <1500000000>;
clocks = <&cpg CPG_CORE R8A7793_CLK_Z>;
power-domains = <&sysc R8A7793_PD_CA15_CPU1>;
+ voltage-tolerance = <1>; /* 1% */
+ clock-latency = <300000>; /* 300 us */
+
+ /* kHz - uV - OPPs unknown yet */
+ operating-points = <1500000 1000000>,
+ <1312500 1000000>,
+ <1125000 1000000>,
+ < 937500 1000000>,
+ < 750000 1000000>,
+ < 375000 1000000>;
+ next-level-cache = <&L2_CA15>;
};
L2_CA15: cache-controller-0 {
--
2.15.0.194.g9af6a3dea062
^ permalink raw reply related
* Re: [PATCH 13/15] arm: dts: r8a7743: Add missing OPP properties for CPUs
From: Viresh Kumar @ 2018-05-30 4:47 UTC (permalink / raw)
To: Biju Das
Cc: Simon Horman, arm@kernel.org, Magnus Damm, Rob Herring,
Mark Rutland, Vincent Guittot, ionela.voinescu@arm.com,
Daniel Lezcano, chris.redpath@arm.com,
linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <OSBPR01MB2103A3411D0C3C5DB76F715EB86D0@OSBPR01MB2103.jpnprd01.prod.outlook.com>
On 29-05-18, 13:33, Biju Das wrote:
> Hi All,
>
> I have tested this patch on RZ/G1M and I didn't find any issues.
> r8a7743 is similar to r8a7791. So I assume you will apply the same
> patch for other R-SoC devices as well.
Okay, I have sent V2 for this and it fixes all those platforms as
well.
> Apart from this, maybe we need to update the OPP binding
> documentation. i.e., extend the operating- point usage to other
> cores in the cluster (Binding 1: operating-points).
Its already done, you need to start using operating-points-v2 property
to avoid duplication like this.
--
viresh
^ permalink raw reply
* [PATCH] drivers: of: of_reserved_mem: detect count overflow or range overlap
From: Jaewon Kim @ 2018-05-30 5:21 UTC (permalink / raw)
To: robh+dt, m.szyprowski, mitchelh
Cc: frowand.list, devicetree, linux-mm, linux-kernel, jaewon31.kim,
Jaewon Kim
In-Reply-To: <CGME20180530052041epcas2p395f2fbf4506d911c127cc4243838fedb@epcas2p3.samsung.com>
During development, number of reserved memory region could be increased
and a new region could be unwantedly overlapped. In that case the new
region may work well but one of exisiting region could be affected so
that it would not be defined properly. It may require time consuming
work to find reason that there is a newly added region.
If a newly added region invoke kernel panic, it will be helpful. This
patch records if there is count overflow or range overlap, and invoke
panic if that case.
These are test example based on v4.9.
Case 1 - out of region count
<3>[ 0.000000] [0: swapper: 0] OF: reserved mem: not enough space all defined regions.
<0>[ 1.688695] [6: swapper/0: 1] Kernel panic - not syncing: overflow on reserved memory, check the latest change
<4>[ 1.688743] [6: swapper/0: 1] CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.9.65+ #10
<4>[ 1.688836] [6: swapper/0: 1] Call trace:
<4>[ 1.688869] [6: swapper/0: 1] [<ffffff8008095748>] dump_backtrace+0x0/0x248
<4>[ 1.688913] [6: swapper/0: 1] [<ffffff8008095b48>] show_stack+0x18/0x28
<4>[ 1.688958] [6: swapper/0: 1] [<ffffff8008446e84>] dump_stack+0x98/0xc0
<4>[ 1.689001] [6: swapper/0: 1] [<ffffff80081cf784>] panic+0x1e0/0x404
<4>[ 1.689046] [6: swapper/0: 1] [<ffffff8008ddcdb8>] check_reserved_mem+0x40/0x50
<4>[ 1.689091] [6: swapper/0: 1] [<ffffff8008090190>] do_one_initcall+0x54/0x214
<4>[ 1.689138] [6: swapper/0: 1] [<ffffff8009eacf98>] kernel_init_freeable+0x198/0x24c
<4>[ 1.689187] [6: swapper/0: 1] [<ffffff8009396950>] kernel_init+0x18/0x144
<4>[ 1.689229] [6: swapper/0: 1] [<ffffff800808fa50>] ret_from_fork+0x10/0x40
Case 2 - overlapped region
<3>[ 0.000000] [0: swapper: 0] OF: reserved mem: OVERLAP DETECTED!
<0>[ 2.309331] [2: swapper/0: 1] Kernel panic - not syncing: reserved memory overlap, check the latest change
<4>[ 2.309398] [2: swapper/0: 1] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.9.65+ #14
<4>[ 2.309508] [2: swapper/0: 1] Call trace:
<4>[ 2.309546] [2: swapper/0: 1] [<ffffff8008121748>] dump_backtrace+0x0/0x248
<4>[ 2.309599] [2: swapper/0: 1] [<ffffff8008121b48>] show_stack+0x18/0x28
<4>[ 2.309652] [2: swapper/0: 1] [<ffffff80084d2e84>] dump_stack+0x98/0xc0
<4>[ 2.309701] [2: swapper/0: 1] [<ffffff800825b784>] panic+0x1e0/0x404
<4>[ 2.309751] [2: swapper/0: 1] [<ffffff8008e68dc4>] check_reserved_mem+0x4c/0x50
<4>[ 2.309802] [2: swapper/0: 1] [<ffffff800811c190>] do_one_initcall+0x54/0x214
<4>[ 2.309856] [2: swapper/0: 1] [<ffffff8009f38f98>] kernel_init_freeable+0x198/0x24c
<4>[ 2.309913] [2: swapper/0: 1] [<ffffff8009422950>] kernel_init+0x18/0x144
<4>[ 2.309961] [2: swapper/0: 1] [<ffffff800811ba50>] ret_from_fork+0x10/0x40
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
---
drivers/of/of_reserved_mem.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 9a4f4246231d..e97d5c5dcc9a 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -65,6 +65,7 @@ int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
#endif
+static bool rmem_overflow;
/**
* res_mem_save_node() - save fdt node for second pass initialization
*/
@@ -75,6 +76,7 @@ void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
pr_err("not enough space all defined regions.\n");
+ rmem_overflow = true;
return;
}
@@ -221,6 +223,7 @@ static int __init __rmem_cmp(const void *a, const void *b)
return 0;
}
+static bool rmem_overlap;
static void __init __rmem_check_for_overlap(void)
{
int i;
@@ -245,6 +248,7 @@ static void __init __rmem_check_for_overlap(void)
pr_err("OVERLAP DETECTED!\n%s (%pa--%pa) overlaps with %s (%pa--%pa)\n",
this->name, &this->base, &this_end,
next->name, &next->base, &next_end);
+ rmem_overlap = true;
}
}
}
@@ -419,3 +423,13 @@ struct reserved_mem *of_reserved_mem_lookup(struct device_node *np)
return NULL;
}
EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
+
+static int check_reserved_mem(void)
+{
+ if (rmem_overflow)
+ panic("overflow on reserved memory, check the latest change");
+ if (rmem_overlap)
+ panic("overlap on reserved memory, check the latest change");
+ return 0;
+}
+late_initcall(check_reserved_mem);
--
2.13.0
^ permalink raw reply related
* Re: [PATCH v4 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 5:23 UTC (permalink / raw)
To: David Collins
Cc: Mark Brown, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <6d03576cf90f06afb1194301cb41fc31704def1d.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> +========
> +Examples
> +========
> +
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +
> +&apps_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l7-l12-l14-l15-supply = <&pm8998_s5>;
> +
> + smps2 {
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + };
> +
> + pm8998_s5: smps5 {
> + regulator-min-microvolt = <1904000>;
> + regulator-max-microvolt = <2040000>;
> + };
> +
> + ldo7 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
> + regulator-allowed-modes =
> + <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + regulator-allow-set-load;
> + qcom,regulator-drms-modes =
> + <RPMH_REGULATOR_MODE_LPM
> + RPMH_REGULATOR_MODE_HPM>;
> + qcom,drms-mode-max-microamps = <10000 1000000>;
Things look pretty good to me now. I'm still hesitant about the whole
need to list the modes twice (once using the unordered
"regulator-allowed-modes" and once to match up against the ordered
"qcom,drms-mode-max-microamps"). I'm also still of the opinion that
the whole "drms-mode-max-microamps" ought to be a standard property
(not a qcom specific one) and handled in the regulator core.
However, for both of these things I leave it to the discretion of Mark
to choose what he wants. Thus assuming Mark is OK with these two
things, feel free to add my Reviewed-by.
-Doug
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-30 5:30 UTC (permalink / raw)
To: Mark Brown
Cc: David Collins, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <20180523155617.GN4828@sirena.org.uk>
Hi,
On Wed, May 23, 2018 at 8:56 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 23, 2018 at 08:50:22AM -0700, Doug Anderson wrote:
>> On Wed, May 23, 2018 at 8:40 AM, Mark Brown <broonie@kernel.org> wrote:
>
>> > It's got to be valid to think about the voltage of a disabled regulator
>> > since drivers want to be able make sure that the regulator gets enabled
>> > with a sensible config. With most hardware this is really easy since
>> > you can just look at the status reported by the hardware but the RPM
>> > makes this hard since there's so much write only stuff in there.
>
>> I should be more clear. Certainly it should be valid to set the
>> voltage before enabling it so, as you said, the regulator turns on at
>> the right voltage. I'm saying that it's weird (to me) to expect that
>> setting the voltage for a regulator that a client thinks is disabled
>> will affect any real voltages in the system until the regulator is
>> enabled. In RPMh apparently setting a voltage of a regulator you
>> think is disabled can affect the regulator output if another client
>> (unbeknownst to you) happens to have it enabled.
>
> Yes, that's definitely not what's expected but it's unfortunately what
> the firmware chose to implement so we may well be stuck with it
> unfortunately.
We're not really stuck with it if we do what I was suggesting. I was
suggesting that every time we disable the regulator in Linux we have
Linux vote for the lowest voltage it's comfortable with. Linux keeps
track of the true voltage that the driver wants and will always change
its vote back to that before enabling. Thus (assuming Linux is OK
with 1.2 V - 1.4 V for a rail):
Modem: want 1.3 V and enabled.
=> Modem votes for 1.3 V
=> Modem votes for enabled.
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.3V
=> True output: 1.3V
Linux: want 1.4 V and enabled.
=> Linux votes for 1.4 V
=> Linux votes for enabled
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.4V
=> True output: 1.4V
Linux: want disabled
=> Linux votes for disabled
=> Linux votes for 1.2 V (keeps 1.4 V in local var)
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.3V
=> True output: 1.3V
Linux: want enabled
=> Linux votes for 1.4 V (from local var)
=> Linux votes for enabled
=> At least one vote for enabled? Yes
=> Highest voltage vote: 1.4V
=> True output: 1.4V
...but I'll leave it to you if you think this is a big deal. If
you're happy with how David's driver works without my suggestion then
I won't push it.
-Doug
^ permalink raw reply
* Re: [PATCH v4 2/2] regulator: add QCOM RPMh regulator driver
From: Doug Anderson @ 2018-05-30 5:32 UTC (permalink / raw)
To: David Collins
Cc: Mark Brown, Liam Girdwood, Rob Herring, Mark Rutland,
linux-arm-msm, Linux ARM, devicetree, LKML, Rajendra Nayak,
Stephen Boyd
In-Reply-To: <7489cd65fedb8a31488cf8188885759bcd4820ce.1527040878.git.collinsd@codeaurora.org>
Hi,
On Tue, May 22, 2018 at 7:43 PM, David Collins <collinsd@codeaurora.org> wrote:
> + * @ever_enabled: Boolean indicating that the regulator has been
> + * explicitly enabled at least once. Voltage
> + * requests should be cached when this flag is not
> + * set.
Do you really need this extra boolean? Can't you just check if
"enabled" is still "-EINVAL"? If it is then you don't pass the
voltage along.
...this would mean that you'd also need to send the voltage vote when
the regulator core tries to disable unused regulators at the end of
bootup, but that should be OK right? If we never touched a regulator
anywhere at probe time and we're about to vote to disable it, we know
there's nobody requiring it to still be on. We can vote for the
voltage now without fear of messing up a vote that the BIOS left in
place.
In theory this should also allow you to assert your vote about the
voltage of a regulator that has never been enabled, which (if I
understand correctly) you consider to be a feature.
---
Other than that comment, everything else here looks good to go if Mark
is good with it. As per the previous threads there are some things
that I don't like a ton, but I feel it is between you and Mark to
decide if you're good with it. A summary of those issues are:
1. I still believe that when we disable a regulator in Linux we should
tell RPMh that we vote for the lowest voltage. ...but if Mark is
happy with the way the driver works now I won't push it.
2. As per my comments in the bindings patch, I still believe that
"qcom,drms-mode-max-microamps" belongs in the core. Again, up to
Mark.
3. As per my comments in the bindings patch, I still believe that
we're just adding lots of noise to the DT most of the time by
specifying both "qcom,regulator-drms-modes" and
"regulator-allowed-modes". Again, up to Mark.
-Doug
^ permalink raw reply
* RE: [PATCH v6 05/15] usb: typec: add API to get typec basic port power and data config
From: Jun Li @ 2018-05-30 5:56 UTC (permalink / raw)
To: kbuild test robot
Cc: kbuild-all@01.org, robh+dt@kernel.org, gregkh@linuxfoundation.org,
heikki.krogerus@linux.intel.com, linux@roeck-us.net,
cw00.choi@samsung.com, a.hajda@samsung.com,
shufan_lee@richtek.com, Peter Chen, garsilva@embeddedor.com,
gsomlo@gmail.com, linux-usb@vger.kernel.org,
devicetree@vger.kernel.org, dl-linux-imx
In-Reply-To: <201805301107.ZBFjEv0u%fengguang.wu@intel.com>
Hi
> -----Original Message-----
> From: kbuild test robot [mailto:lkp@intel.com]
> Sent: 2018年5月30日 12:26
> To: Jun Li <jun.li@nxp.com>
> Cc: kbuild-all@01.org; robh+dt@kernel.org; gregkh@linuxfoundation.org;
> heikki.krogerus@linux.intel.com; linux@roeck-us.net;
> cw00.choi@samsung.com; a.hajda@samsung.com; shufan_lee@richtek.com;
> Peter Chen <peter.chen@nxp.com>; garsilva@embeddedor.com;
> gsomlo@gmail.com; Jun Li <jun.li@nxp.com>; linux-usb@vger.kernel.org;
> devicetree@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH v6 05/15] usb: typec: add API to get typec basic port power
> and data config
>
> Hi Li,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.17-rc7
> next-20180529] [cannot apply to staging/staging-testing] [if your patch is
> applied to the wrong git tree, please drop us a note to help improve the
> system]
>
> url:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu
> b.com%2F0day-ci%2Flinux%2Fcommits%2FLi-Jun%2Fstaging-typec-tcpci-move-
> out-of-staging%2F20180530-110011&data=02%7C01%7Cjun.li%40nxp.com%7
> C56116c50269f48ac2af208d5c5e590b3%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C636632515483673101&sdata=0DFAYwcBjlLN1SmO%2BvCG
> s1YLoyjLCjlh89TTyHH1TFs%3D&reserved=0
> base:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ke
> rnel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fgregkh%2Fusb.git&data=
> 02%7C01%7Cjun.li%40nxp.com%7C56116c50269f48ac2af208d5c5e590b3%7C6
> 86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636632515483673101&sd
> ata=OJnSzPSGMdKkV9w2wT8a7OjwKIME2g0VGmVxJerIhTc%3D&reserved=0
> usb-testing
> config: i386-randconfig-x017-201821 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/linux/linkage.h:7:0,
> from include/linux/kernel.h:7,
> from include/linux/list.h:9,
> from include/linux/kobject.h:19,
> from include/linux/device.h:16,
> from drivers/usb/typec/class.c:9:
> >> drivers/usb/typec/class.c:1274:19: error: 'typec_find_power_type'
> undeclared here (not in a function); did you mean 'typec_find_power_role'?
> EXPORT_SYMBOL_GPL(typec_find_power_type);
> ^
> include/linux/export.h:65:16: note: in definition of macro
> '___EXPORT_SYMBOL'
> extern typeof(sym) sym; \
> ^~~
> >> drivers/usb/typec/class.c:1274:1: note: in expansion of macro
> 'EXPORT_SYMBOL_GPL'
> EXPORT_SYMBOL_GPL(typec_find_power_type);
> ^~~~~~~~~~~~~~~~~
> >> drivers/usb/typec/class.c:1288:19: error: 'typec_find_preferred_role'
> undeclared here (not in a function); did you mean 'typec_find_power_role'?
> EXPORT_SYMBOL_GPL(typec_find_preferred_role);
> ^
> include/linux/export.h:65:16: note: in definition of macro
> '___EXPORT_SYMBOL'
> extern typeof(sym) sym; \
> ^~~
> drivers/usb/typec/class.c:1288:1: note: in expansion of macro
> 'EXPORT_SYMBOL_GPL'
> EXPORT_SYMBOL_GPL(typec_find_preferred_role);
> ^~~~~~~~~~~~~~~~~
> >> drivers/usb/typec/class.c:1303:19: error: 'typec_find_data_type' undeclared
> here (not in a function); did you mean 'typec_find_power_type'?
> EXPORT_SYMBOL_GPL(typec_find_data_type);
> ^
> include/linux/export.h:65:16: note: in definition of macro
> '___EXPORT_SYMBOL'
> extern typeof(sym) sym; \
> ^~~
> drivers/usb/typec/class.c:1303:1: note: in expansion of macro
> 'EXPORT_SYMBOL_GPL'
> EXPORT_SYMBOL_GPL(typec_find_data_type);
> ^~~~~~~~~~~~~~~~~
>
> vim +1274 drivers/usb/typec/class.c
Will fix all above 3 export symbol mismatch.
Li Jun
>
> 1260
> 1261 /**
> 1262 * typec_find_port_power_role - Get the typec port power capability
> 1263 * @name: port power capability string
> 1264 *
> 1265 * This routine is used to find the typec_port_type by its string name.
> 1266 *
> 1267 * Returns typec_port_type if success, otherwise negative error
> code.
> 1268 */
> 1269 int typec_find_port_power_role(const char *name)
> 1270 {
> 1271 return match_string(typec_port_types,
> ARRAY_SIZE(typec_port_types),
> 1272 name);
> 1273 }
> > 1274 EXPORT_SYMBOL_GPL(typec_find_power_type);
> 1275
> 1276 /**
> 1277 * typec_find_power_role - Find the typec one specific power role
> 1278 * @name: power role string
> 1279 *
> 1280 * This routine is used to find the typec_role by its string name.
> 1281 *
> 1282 * Returns typec_role if success, otherwise negative error code.
> 1283 */
> 1284 int typec_find_power_role(const char *name)
> 1285 {
> 1286 return match_string(typec_roles, ARRAY_SIZE(typec_roles),
> name);
> 1287 }
> > 1288 EXPORT_SYMBOL_GPL(typec_find_preferred_role);
> 1289
> 1290 /**
> 1291 * typec_find_port_data_role - Get the typec port data capability
> 1292 * @name: port data capability string
> 1293 *
> 1294 * This routine is used to find the typec_port_data by its string name.
> 1295 *
> 1296 * Returns typec_port_data if success, otherwise negative error
> code.
> 1297 */
> 1298 int typec_find_port_data_role(const char *name)
> 1299 {
> 1300 return match_string(typec_data_caps,
> ARRAY_SIZE(typec_data_caps),
> 1301 name);
> 1302 }
> > 1303 EXPORT_SYMBOL_GPL(typec_find_data_type);
> 1304
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology
> Center
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.0
> 1.org%2Fpipermail%2Fkbuild-all&data=02%7C01%7Cjun.li%40nxp.com%7C561
> 16c50269f48ac2af208d5c5e590b3%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C636632515483673101&sdata=Dc5nz3r2TWU76saOKc03d2DBUe
> htMfokRBfKEbzFQ9s%3D&reserved=0 Intel Corporation
^ permalink raw reply
* Re: [reset-control] How to initialize hardware state with the shared reset line?
From: Masahiro Yamada @ 2018-05-30 5:57 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Philipp Zabel, Rob Herring, Lee Jones, Hans de Goede,
Felipe Balbi, DTML, Arnd Bergmann, Linus Walleij,
Linux Kernel Mailing List, linux-arm-kernel, linux-amlogic
In-Reply-To: <CAFBinCBAoRebScz+DTSKSgiU5DjeSHS1F3=2vt8KM-yCv+2A8g@mail.gmail.com>
2018-05-25 5:09 GMT+09:00 Martin Blumenstingl
<martin.blumenstingl@googlemail.com>:
> Hi Philipp,
>
> On Tue, May 22, 2018 at 4:04 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>> Hi Martin,
>>
>> On Mon, 2018-05-21 at 12:40 +0200, Martin Blumenstingl wrote:
>>> Hello,
>>>
>>> On Mon, May 21, 2018 at 3:27 AM, Masahiro Yamada
>>> <yamada.masahiro@socionext.com> wrote:
>>> > Hi.
>>> >
>>> >
>>> > 2018-05-20 19:57 GMT+09:00 Martin Blumenstingl
>>> > <martin.blumenstingl@googlemail.com>:
>>> > > Hi,
>>> > >
>>> > > On Thu, May 10, 2018 at 11:16 AM, Masahiro Yamada
>>> > > <yamada.masahiro@socionext.com> wrote:
>>> > > [snip]
>>> > > > I may be missing something, but
>>> > > > one solution might be reset hogging on the
>>> > > > reset provider side. This allows us to describe
>>> > > > the initial state of reset lines in the reset controller.
>>> > > >
>>> > > > The idea for "reset-hog" is similar to:
>>> > > > - "gpio-hog" defined in
>>> > > > Documentation/devicetree/bindings/gpio/gpio.txt
>>> > > > - "assigned-clocks" defined in
>>> > > > Documetation/devicetree/bindings/clock/clock-bindings.txt
>>> > > >
>>> > > >
>>> > > >
>>> > > > For example,
>>> > > >
>>> > > > reset-controller {
>>> > > > ....
>>> > > >
>>> > > > line_a {
>>> > > > reset-hog;
>>> > > > resets = <1>;
>>> > > > reset-assert;
>>> > > > };
>>> > > > }
>>> > > >
>>> > > >
>>> > > > When the reset controller is registered,
>>> > > > the reset ID '1' is asserted.
>>> > > >
>>> > > >
>>> > > > So, all reset consumers that share the reset line '1'
>>> > > > will start from the asserted state
>>> > > > (i.e. defined state machine state).
>>> > >
>>> > > I wonder if a "reset hog" can be board specific:
>>> > > - GPIO hogs are definitely board specific (meson-gxbb-odroidc2.dts for
>>> > > example uses it to take the USB hub out of reset)
>>> > > - assigned-clock-parents (and the like) can also be board specific (I
>>> > > made up a use-case since I don't know of any actual examples: board A
>>> > > uses an external XTAL while board B uses some other internal
>>> > > clock-source because it doesn't have an external XTAL)
>>> > >
>>> > > however, can reset lines be board specific? or in other words: do we
>>> > > need to describe them in device-tree?
>>> >
>>> > Indeed.
>>> >
>>> > I did not come up with board-specific cases.
>>> >
>>> > The problem we are discussing is SoC-specific,
>>> > and reset-controller drivers are definitely SoC-specific.
>>> >
>>> > So, I think the initial state can be coded in drivers instead of DT.
>>>
>>> OK, let's also hear Philipp's (reset framework maintainer) opinion on this
>>
>> I'd like to know if there are other SoC families besides Amlogic Meson
>> that potentially could have this problem and about how many of the
>> resets that are documented in include/dt-bindings/reset/amlogic,meson*
>> we are actually talking. Are all of those initially deasserted and none
>> of the connected peripherals have power-on reset mechanisms?
> I cannot speak for other SoC families besides Amlogic
> Meson8/Meson8b/Meson8m2 and GX (disclaimer: I am a community
> contributor, I don't have access to Amlogic's internal datasheets - my
> knowledge is based on their public datasheets, their GPL kernel/u-boot
> sources and trial and error)
>
> it seems that at least "some" (but I don't know the exact number)
> resets are de-asserted by the bootloader
> Amlogic's u-boot for example also enables all gate clocks by default
>
> I CC'ed the Amlogic mailing list because I'm not sure if everyone
> working on that SoC family is watching the linux-arm-kernel mailing
> list
>
>>> > > we could extend struct reset_controller_dev (= reset controller
>>> > > driver) if they are not board specific:
>>> > > - either assert all reset lines by default except if they are listed
>>> > > in a new field (may break backwards compatibility, requires testing of
>>> > > all reset controller drivers)
>>> >
>>> > This is quite simple, but I am afraid there are some cases where the forcible
>>> > reset-assert is not preferred.
>>> >
>>> > For example, the earlycon. When we use earlycon, we would expect it has been
>>> > initialized by a boot-loader, or something.
>>> > If it is reset-asserted on the while, the console output
>>> > will not be good.
>>>
>>> indeed, so let's skip this idea
>>
>> Maybe we should at first add initial reset assertion to the Meson driver
>> on a case by case bases?
> this seems simple enough to test it - we can still generalize this
> later on (either by adding support to the reset framework, DT bindings
> or something else)
>
>> We can't add required reset hog DT bindings to the Meson reset
>> controller anyway without breaking DT backwards compatibility.
>>
>>> > > - specify a list of reset lines and their desired state (or to keep it
>>> > > easy: specify a list of reset lines that should be asserted)
>>> > > (I must admit that this is basically your idea but the definition is
>>> > > moved from device-tree to the reset controller driver)
>>> >
>>> > Yes, I think the list of "reset line ID" and "init state" pairs
>>> > would be nicer.
>>>
>>> $ grep -R "of_reset_n_cells = [^1]" drivers/reset/
>>> drivers/reset/reset-berlin.c: priv->rcdev.of_reset_n_cells = 2;
>>> drivers/reset/hisilicon/reset-hi3660.c: rc->rst.of_reset_n_cells = 2;
>>> drivers/reset/reset-ti-sci.c: data->rcdev.of_reset_n_cells = 2;
>>> drivers/reset/reset-lantiq.c: priv->rcdev.of_reset_n_cells = 2;
>>>
>>> everything else uses only one reset cell
>>> from the lantiq reset dt-binding documentation: "The first cell takes
>>> the reset set bit and the second cell takes the status bit."
>>>
>>> I'm not sure what to do with drivers that specify != 1 reset-cell
>>> though if we use a simple "init state pair"
>>> maybe Philipp can share his opinion on this one as well
>>
>> See above, so far I am not convinced (either way) whether this should be
>> described in the DT at all.
>>
>>> > > any "chip" specific differences could be expressed by using a
>>> > > different of_device_id
>>> > >
>>> > > one the other hand: your "reset hog" solution looks fine to me if
>>> > > reset lines can be board specific
>>> > >
>>> > > > From the discussion with Martin Blumenstingl
>>> > > > (https://lkml.org/lkml/2018/4/28/115),
>>> > > > the problem for Amlogic is that
>>> > > > the reset line is "de-asserted" by default.
>>> > > > If so, the 'reset-hog' would fix the problem,
>>> > > > and DWC3 driver would be able to use
>>> > > > shared, level reset, I think.
>>> > >
>>> > > I think you are right: if we could control the initial state then we
>>> > > should be able to use level resets
>>> >
>>> >
>>> > Even further, can we drop the shared reset_control_reset() support, maybe?
>>> > (in other words, revert commit 7da33a37b48f11)
>>>
>>> I believe we need to keep this if there's hardware out there:
>>> - where the reset controller only supports reset pulses
>>> - at least one reset line is shared between multiple devices
>>>
>>> I didn't have a closer look at the Amlogic Meson6 SoC yet, but I think
>>> it matches above criteria. as far as I know:
>>> - the USB situation there is similar to Meson8b (USB controllers and
>>> PHYs share a reset line)
>>> - it uses an older reset controller IP block which does not support
>>> level resets (only reset pulses)
>>
>> See my answer to Masahiro's first mail. I think somebody suggested in
>> the past to add a fallback from the deassert to the reset op. I think
>> this is something that should work in this case.
> this is an interesting idea - it should work for Meson6 (in case
> mainline ever gains support for this old SoC)
>
>
One more thing.
I want to remove reset_control_reset() entirely.
[1] Some reset consumers (e.g. drivers/ata/sata_gemini.c)
use reset_control_reset() to reset the HW.
[2] Some reset consumers (e.g. drivers/input/keyboard/tegra-kbc.c)
use the combination of reset_control_assert() and reset_control_deassert()
to reset the HW.
[1] is the only way if the reset controller only supports the pulse reset.
[2] is the only way if the reset controller only supports the level reset.
So, this is another strangeness because
the implementation of reset controller
affects reset consumers.
We do not need [1].
[2] is more flexible than [1] because hardware usually specifies
how long the reset line should be kept asserted.
For all reset consumers,
replace
reset_control_reset();
with
reset_control_assert();
reset_control_deassert();
and deprecate reset_control_reset().
I think this is the right thing to do.
The reset controller side should be implemented like this:
If your reset controller only supports the pulse reset,
.deassert hook should be no-op.
.assert hook should pulse the reset
Then .reset hook should be removed.
Or, we can keep the reset drivers as they are.
drivers/reset/core.c can take care of the proper fallback logic.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* RE: [PATCH 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem driver
From: Vishal Sagar @ 2018-05-30 6:22 UTC (permalink / raw)
To: Randy Dunlap, Vishal Sagar, Hyun Kwon,
laurent.pinchart@ideasonboard.com, michal.simek@xilinx.com,
linux-media@vger.kernel.org, devicetree@vger.kernel.org
Cc: sakari.ailus@linux.intel.com, hans.verkuil@cisco.com,
mchehab@kernel.org, robh+dt@kernel.org, mark.rutland@arm.com,
Dinesh Kumar, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5bf470c0-8737-273e-c138-58a05d7d9a30@infradead.org>
Hi Randy,
Thanks for reviewing.
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap@infradead.org]
> Sent: Wednesday, May 30, 2018 1:29 AM
> To: Vishal Sagar <vishal.sagar@xilinx.com>; Hyun Kwon <hyunk@xilinx.com>;
> laurent.pinchart@ideasonboard.com; michal.simek@xilinx.com; linux-
> media@vger.kernel.org; devicetree@vger.kernel.org
> Cc: sakari.ailus@linux.intel.com; hans.verkuil@cisco.com;
> mchehab@kernel.org; robh+dt@kernel.org; mark.rutland@arm.com; Dinesh
> Kumar <dineshk@xilinx.com>; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 2/2] media: v4l: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
> driver
>
> On 05/29/2018 11:54 AM, Vishal Sagar wrote:
> >
> > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > ---
> > drivers/media/platform/xilinx/Kconfig | 12 +
> > drivers/media/platform/xilinx/Makefile | 1 +
> > drivers/media/platform/xilinx/xilinx-csi2rxss.c | 1751
> +++++++++++++++++++++++
> > include/uapi/linux/xilinx-csi2rxss.h | 25 +
> > include/uapi/linux/xilinx-v4l2-controls.h | 14 +
> > 5 files changed, 1803 insertions(+)
> > create mode 100644 drivers/media/platform/xilinx/xilinx-csi2rxss.c
> > create mode 100644 include/uapi/linux/xilinx-csi2rxss.h
> >
> > diff --git a/drivers/media/platform/xilinx/Kconfig
> b/drivers/media/platform/xilinx/Kconfig
> > index a5d21b7..06d5944 100644
> > --- a/drivers/media/platform/xilinx/Kconfig
> > +++ b/drivers/media/platform/xilinx/Kconfig
> > @@ -8,6 +8,18 @@ config VIDEO_XILINX
> >
> > if VIDEO_XILINX
> >
> > +config VIDEO_XILINX_CSI2RXSS
> > + tristate "Xilinx CSI2 Rx Subsystem"
> > + depends on VIDEO_XILINX
> > + help
> > + Driver for Xilinx MIPI CSI2 Rx Subsystem. This is a V4L sub-device
> > + based driver that takes input from CSI2 Tx source and converts
> > + it into an AXI4-Stream. It has a DPHY (whose register interface
> > + can be enabled, an optional I2C controller and an optional Video
>
> can be enabled),
>
Noted. I will update in next revision of patch.
> > + Format Bridge which converts the AXI4-Stream data to Xilinx Video
> > + Bus formats based on UG934. The driver is used to set the number
> > + of active lanes and get short packet data.
> > +
> > config VIDEO_XILINX_TPG
> > tristate "Xilinx Video Test Pattern Generator"
> > depends on VIDEO_XILINX
>
>
>
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be proprietary,
> privileged or copyrighted under applicable law. If you are not the intended
> recipient, do not read, copy, or forward this email message or any attachments.
> Delete this email message and any attachments immediately.
>
> :(
>
Sorry about that.
I will work with IT on getting this removed before sending v2 for the patches.
-- Vishal
> --
> ~Randy
^ permalink raw reply
* Re: [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Marcel Holtmann @ 2018-05-30 6:26 UTC (permalink / raw)
To: Sean Wang
Cc: Mark Rutland, devicetree, Johan Hedberg, LKML, BlueZ development,
Rob Herring, linux-mediatek, linux-arm-kernel
In-Reply-To: <1527175805.4607.103.camel@mtkswgap22>
Hi Sean,
>>>>>>
>>>>>> [ ... ]
>
> [ ... ]
>
>>> I post it as plain text as below
>>>
>>>
>>> Bluetooth monitor ver 5.37
>>> = Note: Linux version 4.16.0-rc1+ (aarch64) 0.641494
>>> = Note: Bluetooth subsystem version 2.22 0.641502
>>> = New Index: 00:00:46:76:22:01 (BR/EDR,UART,hci0) [hci0] 0.641505
>>> * Unknown packet (code 14 len 30) 0.641509
>>> 01 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 6c ..............bl
>>> 75 65 74 6f 6f 74 68 64 00 00 00 00 00 00 uetoothd......
>>> * Unknown packet (code 14 len 30) 0.641592
>>> 02 00 00 00 02 00 01 0e 00 01 00 00 00 10 62 74 ..............bt
>>> 6d 6f 6e 00 00 00 00 00 00 00 00 00 00 00 mon...........
>>> * Unknown packet (code 16 len 7) [hci0] 6.536771
>>> 01 00 00 00 05 00 01 .......
>>> = Open Index: 00:00:46:76:22:01 [hci0] 6.717019
>>> = Index Info: 00:00:46:76:22:01 (MediaTek, Inc.) [hci0] 6.717030
>>
>> can you try with the latest BlueZ 5.49 or git version. Seems it actually stumbles over the extra packet here. Fun fact is that I can not get a backtrace to pin-point the issue in btmon and why it crashes.
>>
>
> I had less experience updating user land BlueZ, but I can try it as possible and see whether Unknown packets still are present at newest version BlueZ. Hopefully I don't misunderstand your point here.
please use the latest btmon and check if it can read your trace.
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.741093
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.742088
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.743102
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.744105
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.745109
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.746104
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.747097
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.748090
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.749078
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.750070
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.751061
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.752054
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.753046
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.754038
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.755031
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.756025
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.757013
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758006
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.758999
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.759991
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.760983
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.761975
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.762963
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.763956
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.764948
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.765941
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.766933
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.767926
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.768919
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.769914
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.770909
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.771908
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.772904
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.773898
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.774892
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.775890
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.776882
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.777877
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.778871
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.779869
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.780864
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.781858
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.782852
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.783850
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.784845
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.785839
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.786833
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.787831
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.788826
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.789820
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.790814
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.791813
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.792809
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.793803
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.794798
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.795797
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.796791
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.797786
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.798779
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.799778
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.800774
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.801769
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.802763
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.803761
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.804755
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.805749
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.806743
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.807741
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.808737
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.809731
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.810725
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.811725
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.812719
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.813714
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.814708
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.815705
>>> 02 01 01 00 00 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816378
>>> 02 01 01 00 00 .....
>>
>> Why do I see only HCI events here? Is this event conveying any useful information. It is kinda complicated that this is 0xe4 event code which is actually reserved for future use by the Bluetooth SIG. Are there any accompanying HCI commands for this and they just not make it into btmon?
>>
>
> I have made all vendor HCI commands go through BlueZ core in v2 patch.
>
> And for these HCI events, they are all corresponding to vendor ACL data, applied only to firmware setup packets, but they're not being sent via BlueZ core, so they are not being logged in btmon.
>
> As for its event, where heading 0xe4 refers to a vendor event and is used on notification of that either vendor ACL data or vendor HCI command have been done.
I would prefer if everything goes via the Bluetooth core since then we have it all properly scheduled. Sending things down the ACL data path however if kinda funky. Does your hardware accept sending command both via ACL data and as HCI command? If so, then I would prefer sending them as HCI commands since the speed improvement you think you are getting is neglectable on Linux (I have been down that path). This seems to be a pure optimization when Windows is driving the device.
And the vendor event 0xe4 is really only received during firmware download? It is not ever received during normal operation?
>
>>
>>
>>> < HCI Command: Vendor (0x3f|0x006f) plen 5 [hci0] 6.816413
>>> 01 07 01 00 04 .....
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 6.816536
>>> 02 07 01 00 00 .....
>>> < HCI Command: Vendor (0x3f|0x006f) plen 6 [hci0] 8.845071
>>> 01 06 02 00 00 01 ......
>>>> HCI Event: Unknown (0xe4) plen 5 [hci0] 8.923456
>>> 02 06 01 00 00 .....
>>
>> Here it looks like you have 0x006f opcode with first octet 0x01 for command and then vendor event 0xe4 with first octet 0x02 for event. I assume the second octet is then the vendor command code for these.
>>
>
> Yes, you're right.
>
>>> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] 10.861118
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.865763
>>> Reset (0x03|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: Read Local Supported Fe.. (0x04|0x0003) plen 0 [hci0] 10.865805
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.865965
>>> Read Local Supported Features (0x04|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x7b 0x87
>>> 3 slot packets
>>> 5 slot packets
>>> Encryption
>>> Slot offset
>>> Timing accuracy
>>> Role switch
>>> Sniff mode
>>> Power control requests
>>> Channel quality driven data rate (CQDDR)
>>> SCO link
>>> HV2 packets
>>> HV3 packets
>>> CVSD synchronous data
>>> Power control
>>> Transparent synchronous data
>>> Broadcast Encryption
>>> Enhanced Data Rate ACL 2 Mbps mode
>>> Enhanced Data Rate ACL 3 Mbps mode
>>> Enhanced inquiry scan
>>> Interlaced inquiry scan
>>> Interlaced page scan
>>> RSSI with inquiry results
>>> Extended SCO link (EV3 packets)
>>> EV4 packets
>>> EV5 packets
>>> AFH capable slave
>>> AFH classification slave
>>> LE Supported (Controller)
>>> 3-slot Enhanced Data Rate ACL packets
>>> 5-slot Enhanced Data Rate ACL packets
>>> Sniff subrating
>>> Pause encryption
>>> AFH capable master
>>> AFH classification master
>>> Enhanced Data Rate eSCO 2 Mbps mode
>>> Enhanced Data Rate eSCO 3 Mbps mode
>>> 3-slot Enhanced Data Rate eSCO packets
>>> Extended Inquiry Response
>>> Simultaneous LE and BR/EDR (Controller)
>>> Secure Simple Pairing
>>> Encapsulated PDU
>>> Erroneous Data Reporting
>>> Non-flushable Packet Boundary Flag
>>> Link Supervision Timeout Changed Event
>>> Inquiry TX Power Level
>>> Enhanced Power Control
>>> Extended features
>>> < HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0 [hci0] 10.865987
>>>> HCI Event: Vendor (0xff) plen 9 [hci0] 10.866259
>>> 29 19 09 17 20 48 07 11 00 )... H…
>>
>> Is this meant to happen here?
>>
>
> If event received is not expected as the specification defines, I think it's probably incorrect.
>
> But it requires more discussion with firmware people to make it clearer.
Please check and let them decode what this event means.
>
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.866372
>>> Read Local Version Information (0x04|0x0001) ncmd 1
>>> Status: Success (0x00)
>>> HCI version: Bluetooth 4.2 (0x08) - Revision 4359 (0x1107)
>>> LMP version: Bluetooth 4.2 (0x08) - Subversion 2329 (0x0919)
>>> Manufacturer: MediaTek, Inc. (70)
>>> < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 [hci0] 10.866391
>>>> HCI Event: Command Complete (0x0e) plen 10 [hci0] 10.866539
>>> Read BD ADDR (0x04|0x0009) ncmd 1
>>> Status: Success (0x00)
>>> Address: 00:00:46:76:22:01 (OLIVETTI NORTH AMERICA)
>>> < HCI Command: Read Buffer Size (0x04|0x0005) plen 0 [hci0] 10.866609
>>>> HCI Event: Command Complete (0x0e) plen 11 [hci0] 10.866754
>>> Read Buffer Size (0x04|0x0005) ncmd 1
>>> Status: Success (0x00)
>>> ACL MTU: 1021 ACL max packet: 8
>>> SCO MTU: 184 SCO max packet: 1
>>> < HCI Command: Read Class of Device (0x03|0x0023) plen 0 [hci0] 10.866775
>>>> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.866920
>>> Read Class of Device (0x03|0x0023) ncmd 1
>>> Status: Success (0x00)
>>> Class: 0x001f00
>>> Major class: Uncategorized, specific device code not specified
>>> Minor class: 0x00
>>> < HCI Command: Read Local Name (0x03|0x0014) plen 0 [hci0] 10.866939
>>>> HCI Event: Command Complete (0x0e) plen 252 [hci0] 10.867256
>>> Read Local Name (0x03|0x0014) ncmd 1
>>> Status: Success (0x00)
>>> Name: MTK MT7622 #1
>>> < HCI Command: Read Voice Setting (0x03|0x0025) plen 0 [hci0] 10.867308
>>>> HCI Event: Command Complete (0x0e) plen 6 [hci0] 10.867447
>>> Read Voice Setting (0x03|0x0025) ncmd 1
>>> Status: Success (0x00)
>>> Setting: 0x0060
>>> Input Coding: Linear
>>> Input Data Format: 2's complement
>>> Input Sample Size: 16-bit
>>> # of bits padding at MSB: 0
>>> Air Coding Format: CVSD
>>> < HCI Command: Read Number of Supporte.. (0x03|0x0038) plen 0 [hci0] 10.867474
>>>> HCI Event: Command Complete (0x0e) plen 5 [hci0] 10.867611
>>> Read Number of Supported IAC (0x03|0x0038) ncmd 1
>>> Status: Success (0x00)
>>> Number of IAC: 4
>>> < HCI Command: Read Current IAC LAP (0x03|0x0039) plen 0 [hci0] 10.867678
>>>> HCI Event: Command Complete (0x0e) plen 8 [hci0] 10.867865
>>> Read Current IAC LAP (0x03|0x0039) ncmd 1
>>> Status: Success (0x00)
>>> Number of IAC: 1
>>> Access code: 0x9e8b33 (General Inquiry)
>>> < HCI Command: Set Event Filter (0x03|0x0005) plen 1 [hci0] 10.867890
>>> Type: Clear All Filters (0x00)
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868033
>>> Set Event Filter (0x03|0x0005) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: Write Connection Accept.. (0x03|0x0016) plen 2 [hci0] 10.868054
>>> Timeout: 20000.000 msec (0x7d00)
>>>> HCI Event: Command Complete (0x0e) plen 4 [hci0] 10.868235
>>> Write Connection Accept Timeout (0x03|0x0016) ncmd 1
>>> Status: Success (0x00)
>>> < HCI Command: LE Read Buffer Size (0x08|0x0002) plen 0 [hci0] 10.868262
>>>> HCI Event: Command Complete (0x0e) plen 7 [hci0] 10.868392
>>> LE Read Buffer Size (0x08|0x0002) ncmd 1
>>> Status: Success (0x00)
>>> Data packet length: 251
>>> Num data packets: 8
>>> < HCI Command: LE Read Local Supported.. (0x08|0x0003) plen 0 [hci0] 10.868413
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868587
>>> LE Read Local Supported Features (0x08|0x0003) ncmd 1
>>> Status: Success (0x00)
>>> Features: 0xfd 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>>> LE Encryption
>>> Extended Reject Indication
>>> Slave-initiated Features Exchange
>>> LE Ping
>>> LE Data Packet Length Extension
>>> LL Privacy
>>> Extended Scanner Filter Policies
>>> < HCI Command: LE Read Supported States (0x08|0x001c) plen 0 [hci0] 10.868646
>>>> HCI Event: Command Complete (0x0e) plen 12 [hci0] 10.868787
>>> LE Read Supported States (0x08|0x001c) ncmd 1
>>> Status: Success (0x00)
>>> States: 0x000000001fffffff
>>> Non-connectable Advertising State
>>> Scannable Advertising State
>>> Connectable Advertising State
>>> High Duty Cycle Directed Advertising State
>>> Passive Scanning State
>>> Active Scanning State
>>> Initiating State
>>> and Connection State (Master Role)
>>> Connection State (Slave Role)
>>> Non-connectable Advertising State
>>> and Passive Scanning State
>>> Scannable Advertising State
>>> and Passive Scanning State
>>> Connectable Advertising State
>>> and Passive Scanning State
>>> High Duty Cycle Directed Advertising State
>>> and Passive Scanning State
>>> Non-connectable Advertising State
>>> and Active Scanning State
>>> Scannable Advertising State
>>> and Active Scanning State
>>> Connectable Advertising State
>>> and Active Scanning State
>>> High Duty Cycle Directed Advertising State
>>> and Active Scanning State
>>> Non-connectable Advertising State
>>> and Initiating State
>>> Scannable Advertising State
>>> and Initiating State
>>> Non-connectable Advertising State
>>> and Connection State (Master Role)
>>> Scannable Advertising State
>>> and Connection State (Master Role)
>>> Non-connectable Advertising State
>>> and Connection State (Slave Role)
>>> Scannable Advertising State
>>> and Connection State (Slave Role)
>>> Passive Scanning State
>>> and Initiating State
>>> Active Scanning State
>>> and Initiating State
>>> Passive Scanning State
>>> and Connection State (Master Role)
>>> Active Scanning State
>>> and Connection State (Master Role)
>>> Passive Scanning State
>>> and Connection State (Slave Role)
>>> Active Scanning State
>>> and Connection State (Slave Role)
>>> Initiating State
>>> and Connection State (Master Role)
>>> and Master Role & Master Role
>>> < HCI Command: Read Local Supported Co.. (0x04|0x0002) plen 0 [hci0] 10.868807
>>>> HCI Event: Command Complete (0x0e) plen 68 [hci0] 10.868985
>>> Read Local Supported Commands (0x04|0x0002) ncmd 1
>>> Status: Success (0x00)
>>> Commands: 176 entries
>>> Inquiry (Octet 0 - Bit 0)
>>> Inquiry Cancel (Octet 0 - Bit 1)
>>> Periodic Inquiry Mode (Octet 0 - Bit 2)
>>> Exit Periodic Inquiry Mode (Octet 0 - Bit 3)
>>> Create Connection (Octet 0 - Bit 4)
>>> Disconnect (Octet 0 - Bit 5)
>>> Add SCO Connection (Octet 0 - Bit 6)
>>> Create Connection Cancel (Octet 0 - Bit 7)
>>> Accept Connection Request (Octet 1 - Bit 0)
>>> Reject Connection Request (Octet 1 - Bit 1)
>>> Link Key Request Reply (Octet 1 - Bit 2)
>>> Link Key Request Negative Reply (Octet 1 - Bit 3)
>>> PIN Code Request Reply (Octet 1 - Bit 4)
>>> PIN Code Request Negative Reply (Octet 1 - Bit 5)
>>> Change Connection Packet Type (Octet 1 - Bit 6)
>>> Authentication Requested (Octet 1 - Bit 7)
>>> Set Connection Encryption (Octet 2 - Bit 0)
>>> Change Connection Link Key (Octet 2 - Bit 1)
>>> Master Link Key (Octet 2 - Bit 2)
>>> Remote Name Request (Octet 2 - Bit 3)
>>> Remote Name Request Cancel (Octet 2 - Bit 4)
>>> Read Remote Supported Features (Octet 2 - Bit 5)
>>> Read Remote Extended Features (Octet 2 - Bit 6)
>>> Read Remote Version Information (Octet 2 - Bit 7)
>>> Read Clock Offset (Octet 3 - Bit 0)
>>> Read LMP Handle (Octet 3 - Bit 1)
>>> Sniff Mode (Octet 4 - Bit 2)
>>> Exit Sniff Mode (Octet 4 - Bit 3)
>>> QoS Setup (Octet 4 - Bit 6)
>>> Role Discovery (Octet 4 - Bit 7)
>>> Switch Role (Octet 5 - Bit 0)
>>> Read Link Policy Settings (Octet 5 - Bit 1)
>>> Write Link Policy Settings (Octet 5 - Bit 2)
>>> Read Default Link Policy Settings (Octet 5 - Bit 3)
>>> Write Default Link Policy Settings (Octet 5 - Bit 4)
>>> Flow Specification (Octet 5 - Bit 5)
>>> Set Event Mask (Octet 5 - Bit 6)
>>> Reset (Octet 5 - Bit 7)
>>> Set Event Filter (Octet 6 - Bit 0)
>>> Flush (Octet 6 - Bit 1)
>>> Read PIN Type (Octet 6 - Bit 2)
>>> Write PIN Type (Octet 6 - Bit 3)
>>> Create New Unit Key (Octet 6 - Bit 4)
>>> Read Stored Link Key (Octet 6 - Bit 5)
>>> Write Stored Link Key (Octet 6 - Bit 6)
>>> Delete Stored Link Key (Octet 6 - Bit 7)
>>> Write Local Name (Octet 7 - Bit 0)
>>> Read Local Name (Octet 7 - Bit 1)
>>> Read Connection Accept Timeout (Octet 7 - Bit 2)
>>> Write Connection Accept Timeout (Octet 7 - Bit 3)
>>> Read Page Timeout (Octet 7 - Bit 4)
>>> Write Page Timeout (Octet 7 - Bit 5)
>>> Read Scan Enable (Octet 7 - Bit 6)
>>> Write Scan Enable (Octet 7 - Bit 7)
>>> Read Page Scan Activity (Octet 8 - Bit 0)
>>> Write Page Scan Activity (Octet 8 - Bit 1)
>>> Read Inquiry Scan Activity (Octet 8 - Bit 2)
>>> Write Inquiry Scan Activity (Octet 8 - Bit 3)
>>> Read Authentication Enable (Octet 8 - Bit 4)
>>> Write Authentication Enable (Octet 8 - Bit 5)
>>> Read Encryption Mode (Octet 8 - Bit 6)
>>> Write Encryption Mode (Octet 8 - Bit 7)
>>> Read Class of Device (Octet 9 - Bit 0)
>>> Write Class of Device (Octet 9 - Bit 1)
>>> Read Voice Setting (Octet 9 - Bit 2)
>>> Write Voice Setting (Octet 9 - Bit 3)
>>> Read Automatic Flush Timeout (Octet 9 - Bit 4)
>>> Write Automatic Flush Timeout (Octet 9 - Bit 5)
>>> Read Num Broadcast Retransmissions (Octet 9 - Bit 6)
>>> Write Num Broadcast Retransmissions (Octet 9 - Bit 7)
>>> Read Transmit Power Level (Octet 10 - Bit 2)
>>> Read Sync Flow Control Enable (Octet 10 - Bit 3)
>>> Write Sync Flow Control Enable (Octet 10 - Bit 4)
>>> Set Controller To Host Flow Control (Octet 10 - Bit 5)
>>> Host Buffer Size (Octet 10 - Bit 6)
>>> Host Number of Completed Packets (Octet 10 - Bit 7)
>>> Read Link Supervision Timeout (Octet 11 - Bit 0)
>>> Write Link Supervision Timeout (Octet 11 - Bit 1)
>>> Read Number of Supported IAC (Octet 11 - Bit 2)
>>> Read Current IAC LAP (Octet 11 - Bit 3)
>>> Write Current IAC LAP (Octet 11 - Bit 4)
>>> Read Page Scan Mode (Octet 11 - Bit 7)
>>> Write Page Scan Mode (Octet 12 - Bit 0)
>>> Set AFH Host Channel Classification (Octet 12 - Bit 1)
>>> Read Inquiry Scan Type (Octet 12 - Bit 4)
>>> Write Inquiry Scan Type (Octet 12 - Bit 5)
>>> Read Inquiry Mode (Octet 12 - Bit 6)
>>> Write Inquiry Mode (Octet 12 - Bit 7)
>>> Read Page Scan Type (Octet 13 - Bit 0)
>>> Write Page Scan Type (Octet 13 - Bit 1)
>>> Read AFH Channel Assessment Mode (Octet 13 - Bit 2)
>>> Write AFH Channel Assessment Mode (Octet 13 - Bit 3)
>>> Read Local Version Information (Octet 14 - Bit 3)
>>> Read Local Supported Features (Octet 14 - Bit 5)
>>> Read Local Extended Features (Octet 14 - Bit 6)
>>> Read Buffer Size (Octet 14 - Bit 7)
>>> Read Country Code (Octet 15 - Bit 0)
>>> Read BD ADDR (Octet 15 - Bit 1)
>>> Read Failed Contact Counter (Octet 15 - Bit 2)
>>> Reset Failed Contact Counter (Octet 15 - Bit 3)
>>> Read Link Quality (Octet 15 - Bit 4)
>>> Read RSSI (Octet 15 - Bit 5)
>>> Read AFH Channel Map (Octet 15 - Bit 6)
>>> Read Clock (Octet 15 - Bit 7)
>>> Read Loopback Mode (Octet 16 - Bit 0)
>>> Write Loopback Mode (Octet 16 - Bit 1)
>>> Enable Device Under Test Mode (Octet 16 - Bit 2)
>>> Setup Synchronous Connection (Octet 16 - Bit 3)
>>> Accept Synchronous Connection Request (Octet 16 - Bit 4)
>>> Reject Synchronous Connection Request (Octet 16 - Bit 5)
>>> Read Extended Inquiry Response (Octet 17 - Bit 0)
>>> Write Extended Inquiry Response (Octet 17 - Bit 1)
>>> Refresh Encryption Key (Octet 17 - Bit 2)
>>> Sniff Subrating (Octet 17 - Bit 4)
>>> Read Simple Pairing Mode (Octet 17 - Bit 5)
>>> Write Simple Pairing Mode (Octet 17 - Bit 6)
>>> Read Local OOB Data (Octet 17 - Bit 7)
>>> Read Inquiry Response TX Power Level (Octet 18 - Bit 0)
>>> Write Inquiry Transmit Power Level (Octet 18 - Bit 1)
>>> Read Default Erroneous Data Reporting (Octet 18 - Bit 2)
>>> Write Default Erroneous Data Reporting (Octet 18 - Bit 3)
>>> IO Capability Request Reply (Octet 18 - Bit 7)
>>> User Confirmation Request Reply (Octet 19 - Bit 0)
>>> User Confirmation Request Neg Reply (Octet 19 - Bit 1)
>>> User Passkey Request Reply (Octet 19 - Bit 2)
>>> User Passkey Request Negative Reply (Octet 19 - Bit 3)
>>> Remote OOB Data Request Reply (Octet 19 - Bit 4)
>>> Write Simple Pairing Debug Mode (Octet 19 - Bit 5)
>>> Enhanced Flush (Octet 19 - Bit 6)
>>> Remote OOB Data Request Neg Reply (Octet 19 - Bit 7)
>>> Send Keypress Notification (Octet 20 - Bit 2)
>>> IO Capability Request Negative Reply (Octet 20 - Bit 3)
>>> Read Encryption Key Size (Octet 20 - Bit 4)
>>> Set Event Mask Page 2 (Octet 22 - Bit 2)
>>> Read Enhanced Transmit Power Level (Octet 24 - Bit 0)
>>> Enhanced Setup Synchronous Connection (Octet 29 - Bit 3)
>>> Enhanced Accept Synchronous Connection Request (Octet 29 - Bit 4)
>>> Read Local Supported Codecs (Octet 29 - Bit 5)
>>> Set Triggered Clock Capture (Octet 30 - Bit 5)
>>> Truncated Page (Octet 30 - Bit 6)
>>> Truncated Page Cancel (Octet 30 - Bit 7)
>>> Set Connectionless Slave Broadcast (Octet 31 - Bit 0)
>>> Start Synchronization Train (Octet 31 - Bit 2)
>>> Set Reserved LT_ADDR (Octet 31 - Bit 4)
>>> Delete Reserved LT_ADDR (Octet 31 - Bit 5)
>>> Set Connectionless Slave Broadcast Data (Octet 31 - Bit 6)
>>> Read Synchronization Train Parameters (Octet 31 - Bit 7)
>>> Write Synchronization Train Parameters (Octet 32 - Bit 0)
>>> Remote OOB Extended Data Request Reply (Octet 32 - Bit 1)
>>> Read Authenticated Payload Timeout (Octet 32 - Bit 4)
>>> Write Authenticated Payload Timeout (Octet 32 - Bit 5)
>>> Read Local OOB Extended Data (Octet 32 - Bit 6)
>>> Write Secure Connections Test Mode (Octet 32 - Bit 7)
>>> Read Extended Page Timeout (Octet 33 - Bit 0)
>>> Write Extended Page Timeout (Octet 33 - Bit 1)
>>> Read Extended Inquiry Length (Octet 33 - Bit 2)
>>> Write Extended Inquiry Length (Octet 33 - Bit 3)
>>> LE Set Data Length (Octet 33 - Bit 6)
>>> LE Read Suggested Default Data Length (Octet 33 - Bit 7)
>>> LE Write Suggested Default Data Length (Octet 34 - Bit 0)
>>> LE Read Local P-256 Public Key (Octet 34 - Bit 1)
>>> LE Generate DHKey (Octet 34 - Bit 2)
>>> LE Add Device To Resolving List (Octet 34 - Bit 3)
>>> LE Remove Device From Resolving List (Octet 34 - Bit 4)
>>> LE Clear Resolving List (Octet 34 - Bit 5)
>>> LE Read Resolving List Size (Octet 34 - Bit 6)
>>> LE Read Peer Resolvable Address (Octet 34 - Bit 7)
>>> LE Read Local Resolvable Address (Octet 35 - Bit 0)
>>> LE Set Address Resolution Enable (Octet 35 - Bit 1)
>>> LE Set Resolvable Private Address Timeout (Octet 35 - Bit 2)
>>> LE Read Maximum Data Length (Octet 35 - Bit 3)
>>> Octet 35 - Bit 4
>>> Octet 35 - Bit 5
>>> Octet 35 - Bit 6
>>> Octet 35 - Bit 7
>>> Octet 36 - Bit 0
>>
>> So you support the PHY commands, but do not indicate support LE 2M or LE Coded? Also these are Bluetooth 5.0 commands.
>>
>
> To be honest. When I ported the device into Bluez core, a unexpected event for LE read local feature would cause a fail at Bluez core, so I made a hack on Bluez core
>
> to allow that I can keeping bring up the device without be blocked by the issue most probably from firmware.
>
> Below code snippet is the only thing I added to avoid a fail at Bluez core to bring up the device.
>
> @@ -927,6 +927,8 @@ static void hci_cc_le_read_local_features(struct hci_dev *hdev,
> return;
>
> memcpy(hdev->le_features, rp->features, 8);
> + hdev->le_features[0] = 0;
> + hdev->le_features[1] = 0;
> }
Send me the trace where you didn’t clear the feature bits and I check what is going on. I doubt that we have a bug, but maybe some of the commands are optional and we should add an appropriate check. Or you guys need to fix your firmware. A new btmon should decode all bits properly.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 01/13] dt-bindings: net: bluetooth: add support for Realtek Bluetooth chips
From: Marcel Holtmann @ 2018-05-30 6:42 UTC (permalink / raw)
To: Hans de Goede
Cc: Johan Hedberg, Martin Blumenstingl, Rob Herring, Jeremy Cline,
linux-bluetooth, linux-serial, linux-acpi, devicetree
In-Reply-To: <20180527190457.2632-2-hdegoede@redhat.com>
Hi Hans,
> This adds the documentation for Bluetooth functionality of the Realtek
> RTL8723BS and RTL8723DS.
> Both are SDIO wifi chips with an additional Bluetooth module which is
> connected via UART to the host.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Jeremy Cline <jeremy@jcline.org>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../bindings/net/realtek-bluetooth.txt | 41 +++++++++++++++++++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek-bluetooth.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek-bluetooth.txt b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> new file mode 100644
> index 000000000000..1491329c4cd1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek-bluetooth.txt
> @@ -0,0 +1,41 @@
> +Realtek Bluetooth Chips
> +-----------------------
> +
> +This documents the binding structure and common properties for serial
> +attached Realtek devices.
> +
> +Serial attached Realtek devices shall be a child node of the host UART
> +device the slave device is attached to. See ../serial/slave-device.txt
> +for more information
> +
> +Required properties:
> +- compatible: should contain one of the following:
> + * "realtek,rtl8723bs-bluetooth"
> + * "realtek,rtl8723ds-bluetooth"
> +
> +Optional properties:
> +- realtek,config-data: Bluetooth chipset configuration data which is
> + needed for communication (it typically contains
> + board specific settings like the baudrate and
> + whether flow-control is used).
> + This is an array of u8 values.
> +- enable-gpios: GPIO specifier, used to enable/disable the BT module
> +- reset-gpios: GPIO specifier, used to reset the BT module
> +
> +
> +Example:
> +
> +&uart {
> + ...
> +
> + bluetooth {
> + compatible = "realtek,rtl8723bs-bluetooth";
> + enable-gpios = <&gpio 20 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
> + realtek,config-data = /bits/ 8 <
> + 0x55 0xab 0x23 0x87 0x29 0x00 0xf4 0x00 0x01 0x01 0xf6 0x00
> + 0x02 0x81 0x00 0xfa 0x00 0x02 0x12 0x80 0x0c 0x00 0x10 0x02
> + 0x80 0x92 0x04 0x50 0xc5 0xea 0x19 0xe1 0x1b 0xfd 0xaf 0x5f
> + 0x01 0xa4 0x0b 0xd9 0x00 0x01 0x0f 0xe4 0x00 0x01 0x08>;
> + };
> +};
we actually need to agree on this config-data. As I wrote in an earlier email some time ago, the actual config-data files are just memory portions that will overload the default config area. I wrote tools/rtlfw.c to parse these.
So now I wonder if we can just read the current configuration and run with that when no extra blob is provided. That way it would always work and we might just give the config-data filename here. Mostly this is the for PCM and UART settings anyway.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v6 05/15] usb: typec: add API to get typec basic port power and data config
From: kbuild test robot @ 2018-05-30 6:43 UTC (permalink / raw)
To: Li Jun
Cc: kbuild-all, robh+dt, gregkh, heikki.krogerus, linux, cw00.choi,
a.hajda, shufan_lee, peter.chen, garsilva, gsomlo, linux-usb,
devicetree, linux-imx
In-Reply-To: <1527475967-15201-6-git-send-email-jun.li@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 4277 bytes --]
Hi Li,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.17-rc7 next-20180529]
[cannot apply to staging/staging-testing]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Li-Jun/staging-typec-tcpci-move-out-of-staging/20180530-110011
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
config: i386-randconfig-s1-201821 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
In file included from include/linux/linkage.h:7:0,
from include/linux/kernel.h:7,
from include/linux/list.h:9,
from include/linux/kobject.h:19,
from include/linux/device.h:16,
from drivers/usb//typec/class.c:9:
>> drivers/usb//typec/class.c:1274:19: error: 'typec_find_power_type' undeclared here (not in a function)
EXPORT_SYMBOL_GPL(typec_find_power_type);
^
include/linux/export.h:65:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
drivers/usb//typec/class.c:1274:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(typec_find_power_type);
^~~~~~~~~~~~~~~~~
>> drivers/usb//typec/class.c:1288:19: error: 'typec_find_preferred_role' undeclared here (not in a function)
EXPORT_SYMBOL_GPL(typec_find_preferred_role);
^
include/linux/export.h:65:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
drivers/usb//typec/class.c:1288:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(typec_find_preferred_role);
^~~~~~~~~~~~~~~~~
>> drivers/usb//typec/class.c:1303:19: error: 'typec_find_data_type' undeclared here (not in a function)
EXPORT_SYMBOL_GPL(typec_find_data_type);
^
include/linux/export.h:65:16: note: in definition of macro '___EXPORT_SYMBOL'
extern typeof(sym) sym; \
^~~
drivers/usb//typec/class.c:1303:1: note: in expansion of macro 'EXPORT_SYMBOL_GPL'
EXPORT_SYMBOL_GPL(typec_find_data_type);
^~~~~~~~~~~~~~~~~
vim +/typec_find_power_type +1274 drivers/usb//typec/class.c
1260
1261 /**
1262 * typec_find_port_power_role - Get the typec port power capability
1263 * @name: port power capability string
1264 *
1265 * This routine is used to find the typec_port_type by its string name.
1266 *
1267 * Returns typec_port_type if success, otherwise negative error code.
1268 */
1269 int typec_find_port_power_role(const char *name)
1270 {
1271 return match_string(typec_port_types, ARRAY_SIZE(typec_port_types),
1272 name);
1273 }
> 1274 EXPORT_SYMBOL_GPL(typec_find_power_type);
1275
1276 /**
1277 * typec_find_power_role - Find the typec one specific power role
1278 * @name: power role string
1279 *
1280 * This routine is used to find the typec_role by its string name.
1281 *
1282 * Returns typec_role if success, otherwise negative error code.
1283 */
1284 int typec_find_power_role(const char *name)
1285 {
1286 return match_string(typec_roles, ARRAY_SIZE(typec_roles), name);
1287 }
> 1288 EXPORT_SYMBOL_GPL(typec_find_preferred_role);
1289
1290 /**
1291 * typec_find_port_data_role - Get the typec port data capability
1292 * @name: port data capability string
1293 *
1294 * This routine is used to find the typec_port_data by its string name.
1295 *
1296 * Returns typec_port_data if success, otherwise negative error code.
1297 */
1298 int typec_find_port_data_role(const char *name)
1299 {
1300 return match_string(typec_data_caps, ARRAY_SIZE(typec_data_caps),
1301 name);
1302 }
> 1303 EXPORT_SYMBOL_GPL(typec_find_data_type);
1304
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26505 bytes --]
^ permalink raw reply
* Re: [PATCH 07/13] Bluetooth: hci_uart: Restore hci_dev->flush callback on open()
From: Marcel Holtmann @ 2018-05-30 6:47 UTC (permalink / raw)
To: Hans de Goede
Cc: Johan Hedberg, Martin Blumenstingl, robh, Jeremy Cline,
linux-bluetooth, linux-serial, linux-acpi, devicetree
In-Reply-To: <20180527190457.2632-8-hdegoede@redhat.com>
Hi Hans,
> For reasons explained in detail in commit 3611f4d2a5e0 ("hci_ldisc:
> fix null pointer deref") the hci_uart_close() functions sets
> hci_dev->flush to NULL.
>
> But the device may be re-opened after a close, this commit restores the
> hci_dev->flush callback on open().
>
> Note this commit also moves the nearly empty defition of hci_uart_open()
> a bit down in the file to avoid the need for forward declaring
> hci_uart_flush().
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/bluetooth/hci_ldisc.c | 20 +++++++++++---------
> drivers/bluetooth/hci_serdev.c | 19 +++++++++++--------
> 2 files changed, 22 insertions(+), 17 deletions(-)
this patch has been cherry-picked and applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 08/13] Bluetooth: hci_serdev: Move serdev_device_close/open into common hci_serdev code
From: Marcel Holtmann @ 2018-05-30 6:48 UTC (permalink / raw)
To: Hans de Goede
Cc: Johan Hedberg, Martin Blumenstingl, robh, Jeremy Cline,
linux-bluetooth, linux-serial, linux-acpi, devicetree
In-Reply-To: <20180527190457.2632-9-hdegoede@redhat.com>
Hi Hans,
> Make hci_uart_register_device() and hci_uart_unregister_device() call
> serdev_device_close()/open() themselves instead of relying on the various
> hci_uart drivers to do this for them.
>
> Besides reducing code complexity, this also ensures correct error checking
> of serdev_device_open(), which was missing in a few drivers.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/bluetooth/hci_bcm.c | 10 +---------
> drivers/bluetooth/hci_ll.c | 3 ---
> drivers/bluetooth/hci_nokia.c | 3 ---
> drivers/bluetooth/hci_serdev.c | 9 ++++++++-
> 4 files changed, 9 insertions(+), 16 deletions(-)
this patch has been cherry-picked and applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 09/13] Bluetooth: hci_serdev: Fix HCI_UART_INIT_PENDING not working
From: Marcel Holtmann @ 2018-05-30 6:49 UTC (permalink / raw)
To: Hans de Goede
Cc: Johan Hedberg, Martin Blumenstingl, robh, Jeremy Cline,
linux-bluetooth, linux-serial, linux-acpi, devicetree
In-Reply-To: <20180527190457.2632-10-hdegoede@redhat.com>
Hi Hans,
> Init hci_uart->init_ready so that hci_uart_init_ready() works properly.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/bluetooth/hci_ldisc.c | 2 +-
> drivers/bluetooth/hci_serdev.c | 1 +
> drivers/bluetooth/hci_uart.h | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
this patch has been cherry-picked and applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v3 4/5] clocksource: add driver for i.MX EPIT timer
From: Vladimir Zapolskiy @ 2018-05-30 6:56 UTC (permalink / raw)
To: Clément Péron, Colin Didier, linux-arm-kernel,
devicetree, linux-clk
Cc: Rob Herring, Sascha Hauer, Clément Peron, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <20180529170436.22711-5-peron.clem@gmail.com>
Hi Clément,
please find some more review comments.
On 05/29/2018 08:04 PM, Clément Péron wrote:
> From: Colin Didier <colin.didier@devialet.com>
>
> Add driver for NXP's EPIT timer used in i.MX 6 family of SoC.
>
> Signed-off-by: Colin Didier <colin.didier@devialet.com>
> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> ---
> drivers/clocksource/Kconfig | 12 ++
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/timer-imx-epit.c | 283 +++++++++++++++++++++++++++
> 3 files changed, 296 insertions(+)
> create mode 100644 drivers/clocksource/timer-imx-epit.c
>
> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index 8e8a09755d10..920a0874f3a4 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -576,6 +576,18 @@ config H8300_TPU
> This enables the clocksource for the H8300 platform with the
> H8S2678 cpu.
>
> +config CLKSRC_IMX_EPIT
> + bool "Clocksource using i.MX EPIT"
> + depends on ARM && CLKDEV_LOOKUP && OF && (ARCH_MXC || COMPILE_TEST)
Here 'depends on ARM' can be removed, because ARCH_MXC implies it.
Also ARCH_MXC implies ARCH_MULTIPLATFORM, which implies USE_OF in turn,
so I would say that the following line is correct, sorry about a previous
comment asking to add an explicit OF dependency:
depends on CLKDEV_LOOKUP && (ARCH_MXC || COMPILE_TEST)
However most of the clocksource drivers follow 'bool "..." if COMPILE_TEST'
pattern, and it might be preferable to maintainers.
> + select TIMER_OF
The driver does not have this dependency.
> + select CLKSRC_MMIO
> + help
> + This enables EPIT support available on some i.MX platforms.
> + Normally you don't have a reason to do so as the EPIT has
> + the same features and uses the same clocks as the GPT.
> + Anyway, on some systems the GPT may be in use for other
> + purposes.
> +
> config CLKSRC_IMX_GPT
> bool "Clocksource using i.MX GPT" if COMPILE_TEST
> depends on ARM && CLKDEV_LOOKUP
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index 00caf37e52f9..d9426f69ec69 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -69,6 +69,7 @@ obj-$(CONFIG_INTEGRATOR_AP_TIMER) += timer-integrator-ap.o
> obj-$(CONFIG_CLKSRC_VERSATILE) += versatile.o
> obj-$(CONFIG_CLKSRC_MIPS_GIC) += mips-gic-timer.o
> obj-$(CONFIG_CLKSRC_TANGO_XTAL) += tango_xtal.o
> +obj-$(CONFIG_CLKSRC_IMX_EPIT) += timer-imx-epit.o
> obj-$(CONFIG_CLKSRC_IMX_GPT) += timer-imx-gpt.o
> obj-$(CONFIG_CLKSRC_IMX_TPM) += timer-imx-tpm.o
> obj-$(CONFIG_ASM9260_TIMER) += asm9260_timer.o
> diff --git a/drivers/clocksource/timer-imx-epit.c b/drivers/clocksource/timer-imx-epit.c
> new file mode 100644
> index 000000000000..87025d5f3a97
> --- /dev/null
> +++ b/drivers/clocksource/timer-imx-epit.c
> @@ -0,0 +1,283 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX EPIT Timer
> + *
> + * Copyright (C) 2010 Sascha Hauer <s.hauer@pengutronix.de>
> + * Copyright (C) 2018 Colin Didier <colin.didier@devialet.com>
> + * Copyright (C) 2018 Clément Péron <clement.peron@devialet.com>
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/clockchips.h>
> +#include <linux/err.h>
The include above can be dropped.
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
The include above can be dropped.
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of.h>
The include above can be dropped.
> +#include <linux/sched_clock.h>
> +#include <linux/slab.h>
> +
> +#define EPITCR 0x00
> +#define EPITSR 0x04
> +#define EPITLR 0x08
> +#define EPITCMPR 0x0c
> +#define EPITCNR 0x10
> +
> +#define EPITCR_EN BIT(0)
> +#define EPITCR_ENMOD BIT(1)
> +#define EPITCR_OCIEN BIT(2)
> +#define EPITCR_RLD BIT(3)
> +#define EPITCR_PRESC(x) (((x) & 0xfff) << 4)
> +#define EPITCR_SWR BIT(16)
> +#define EPITCR_IOVW BIT(17)
> +#define EPITCR_DBGEN BIT(18)
> +#define EPITCR_WAITEN BIT(19)
> +#define EPITCR_RES BIT(20)
> +#define EPITCR_STOPEN BIT(21)
> +#define EPITCR_OM_DISCON (0 << 22)
> +#define EPITCR_OM_TOGGLE (1 << 22)
> +#define EPITCR_OM_CLEAR (2 << 22)
> +#define EPITCR_OM_SET (3 << 22)
> +#define EPITCR_CLKSRC_OFF (0 << 24)
> +#define EPITCR_CLKSRC_PERIPHERAL (1 << 24)
> +#define EPITCR_CLKSRC_REF_HIGH (2 << 24)
> +#define EPITCR_CLKSRC_REF_LOW (3 << 24)
> +
> +#define EPITSR_OCIF BIT(0)
> +
> +struct epit_timer {
> + void __iomem *base;
> + int irq;
> + struct clk *clk_per;
> + struct clock_event_device ced;
> + struct irqaction act;
> +};
> +
> +static void __iomem *sched_clock_reg;
> +
> +static inline struct epit_timer *to_epit_timer(struct clock_event_device *ced)
> +{
> + return container_of(ced, struct epit_timer, ced);
> +}
> +
> +static inline void epit_irq_disable(struct epit_timer *epittm)
> +{
> + u32 val;
> +
> + val = readl_relaxed(epittm->base + EPITCR);
> + writel_relaxed(val & ~EPITCR_OCIEN, epittm->base + EPITCR);
> +}
> +
> +static inline void epit_irq_enable(struct epit_timer *epittm)
> +{
> + u32 val;
> +
> + val = readl_relaxed(epittm->base + EPITCR);
> + writel_relaxed(val | EPITCR_OCIEN, epittm->base + EPITCR);
> +}
> +
> +static void epit_irq_acknowledge(struct epit_timer *epittm)
> +{
> + writel_relaxed(EPITSR_OCIF, epittm->base + EPITSR);
> +}
> +
> +static u64 notrace epit_read_sched_clock(void)
> +{
> + return ~readl_relaxed(sched_clock_reg);
> +}
> +
> +static int __init epit_clocksource_init(struct epit_timer *epittm)
> +{
> + unsigned int c = clk_get_rate(epittm->clk_per);
> +
> + sched_clock_reg = epittm->base + EPITCNR;
> + sched_clock_register(epit_read_sched_clock, 32, c);
> +
> + return clocksource_mmio_init(epittm->base + EPITCNR, "epit", c, 200, 32,
> + clocksource_mmio_readl_down);
> +}
> +
I would suggest to place epit_clocksource_init() function right before
epit_timer_init().
> +static int epit_set_next_event(unsigned long cycles,
> + struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long tcmp;
> +
> + tcmp = readl_relaxed(epittm->base + EPITCNR) - cycles;
> + writel_relaxed(tcmp, epittm->base + EPITCMPR);
> +
> + return 0;
> +}
> +
> +/* Left event sources disabled, no more interrupts appear */
> +static int epit_shutdown(struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long flags;
> +
> + /*
> + * The timer interrupt generation is disabled at least
> + * for enough time to call epit_set_next_event()
> + */
> + local_irq_save(flags);
> +
> + /* Disable interrupt in EPIT module */
> + epit_irq_disable(epittm);
> +
> + /* Clear pending interrupt */
> + epit_irq_acknowledge(epittm);
> +
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> +static int epit_set_oneshot(struct clock_event_device *ced)
> +{
> + struct epit_timer *epittm = to_epit_timer(ced);
> + unsigned long flags;
> +
> + /*
> + * The timer interrupt generation is disabled at least
> + * for enough time to call epit_set_next_event()
> + */
> + local_irq_save(flags);
> +
> + /* Disable interrupt in EPIT module */
> + epit_irq_disable(epittm);
> +
> + /* Clear pending interrupt, only while switching mode */
> + if (!clockevent_state_oneshot(ced))
> + epit_irq_acknowledge(epittm);
> +
> + /*
> + * Do not put overhead of interrupt enable/disable into
> + * epit_set_next_event(), the core has about 4 minutes
> + * to call epit_set_next_event() or shutdown clock after
> + * mode switching
> + */
> + epit_irq_enable(epittm);
> + local_irq_restore(flags);
> +
> + return 0;
> +}
> +
> +static irqreturn_t epit_timer_interrupt(int irq, void *dev_id)
> +{
> + struct clock_event_device *ced = dev_id;
> + struct epit_timer *epittm = to_epit_timer(ced);
> +
> + epit_irq_acknowledge(epittm);
> +
> + ced->event_handler(ced);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int __init epit_clockevent_init(struct epit_timer *epittm)
> +{
> + struct clock_event_device *ced = &epittm->ced;
> + struct irqaction *act = &epittm->act;
> +
> + ced->name = "epit";
> + ced->features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_DYNIRQ;
> + ced->set_state_shutdown = epit_shutdown;
> + ced->tick_resume = epit_shutdown;
> + ced->set_state_oneshot = epit_set_oneshot;
> + ced->set_next_event = epit_set_next_event;
> + ced->rating = 200;
> + ced->cpumask = cpumask_of(0);
> + ced->irq = epittm->irq;
> + clockevents_config_and_register(ced, clk_get_rate(epittm->clk_per),
> + 0xff, 0xfffffffe);
Please indent the wrapped line.
> +
> + act->name = "i.MX EPIT Timer Tick",
> + act->flags = IRQF_TIMER | IRQF_IRQPOLL;
> + act->handler = epit_timer_interrupt;
> + act->dev_id = ced;
> +
> + /* Make irqs happen */
> + return setup_irq(epittm->irq, act);
> +}
> +
> +static int __init epit_timer_init(struct device_node *np)
> +{
> + struct epit_timer *epittm;
> + struct clk *clk_ipg;
> + int ret;
> +
> + epittm = kzalloc(sizeof(*epittm), GFP_KERNEL);
> + if (!epittm)
> + return -ENOMEM;
> +
> + epittm->base = of_iomap(np, 0);
> + if (!epittm->base) {
> + ret = -ENXIO;
> + goto out_kfree;
> + }
> +
> + epittm->irq = irq_of_parse_and_map(np, 0);
> + if (!epittm->irq) {
> + ret = -EINVAL;
> + goto out_iounmap;
> + }
> +
> + clk_ipg = of_clk_get_by_name(np, "ipg");
> + if (IS_ERR(clk_ipg)) {
> + pr_err("i.MX EPIT: unable to get clk_ipg\n");
> + ret = PTR_ERR(clk_ipg);
> + goto out_iounmap;
> + }
> +
> + ret = clk_prepare_enable(clk_ipg);
> + if (ret) {
> + pr_err("i.MX EPIT: unable to prepare+enable clk_ipg\n");
> + goto out_clk_ipg_disable;
> + }
> +
> + epittm->clk_per = of_clk_get_by_name(np, "per");
> + if (IS_ERR(epittm->clk_per)) {
> + pr_err("i.MX EPIT: unable to get clk_per\n");
> + ret = PTR_ERR(epittm->clk_per);
> + goto out_clk_ipg_disable;
> + }
> +
> + ret = clk_prepare_enable(epittm->clk_per);
> + if (ret) {
> + pr_err("i.MX EPIT: unable to prepare+enable clk_per\n");
> + goto out_clk_ipg_disable;
> + }
> +
> + /* Initialise to a known state (all timers off, and timing reset) */
> + writel_relaxed(0x0, epittm->base + EPITCR);
> + writel_relaxed(0xffffffff, epittm->base + EPITLR);
> + writel_relaxed(EPITCR_EN | EPITCR_CLKSRC_REF_HIGH | EPITCR_WAITEN,
> + epittm->base + EPITCR);
> +
> + ret = epit_clocksource_init(epittm);
> + if(ret) {
Add a space before left parenthesis.
> + pr_err("i.MX EPIT: failed to init clocksource\n");
> + goto out_clk_per_disable;
> + }
> +
> + ret = epit_clockevent_init(epittm);
> + if(ret) {
Add a space before left parenthesis.
> + pr_err("i.MX EPIT: failed to init clockevent\n");
> + goto out_clk_per_disable;
> + }
> +
> + return 0;
> +
> +out_clk_per_disable:
> + clk_disable_unprepare(epittm->clk_per);
> +out_clk_ipg_disable:
> + clk_disable_unprepare(clk_ipg);
> +out_iounmap:
> + iounmap(epittm->base);
> +out_kfree:
> + kfree(epittm);
> +
> + return ret;
> +}
> +TIMER_OF_DECLARE(mx6q_timer, "fsl,imx6q-epit", epit_timer_init);
>
Here "fsl,imx31-epit" would be way better than "fsl,imx6q-epit", please
fix it in the documentation as well.
--
With best wishes,
Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 5/8] pinctrl: optionally stop deferring probe at end of initcalls
From: Linus Walleij @ 2018-05-30 7:00 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Ulf Hansson, boot-architecture-cunTk1MwBs8s++Sfvej+rw,
Frank Rowand, Kevin Hilman, Greg Kroah-Hartman, Joerg Roedel,
Rafael J. Wysocki, Alexander Graf, Bjorn Andersson, Mark Brown,
Linux ARM, Robin Murphy,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20180524175024.19874-6-robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Thu, May 24, 2018 at 7:50 PM, Rob Herring <robh@kernel.org> wrote:
> If the pinctrl node in DT indicates that pin setup is optional and the
> defaults can be used with the 'pinctrl-use-default', then only defer probe
> until initcalls are done. This gives platforms the option to work without
> their pinctrl driver being enabled.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
I trust that you know what you're doing so I guess
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
^ permalink raw reply
* Re: [PATCH 2/2] mmc: meson-gx: add device reset
From: Ulf Hansson @ 2018-05-30 7:27 UTC (permalink / raw)
To: Jerome Brunet
Cc: Carlo Caione, Kevin Hilman, devicetree,
open list:ARM/Amlogic Meson..., linux-mmc@vger.kernel.org,
Linux Kernel Mailing List
In-Reply-To: <20180515095748.6794-3-jbrunet@baylibre.com>
Jerome,
On 15 May 2018 at 11:57, Jerome Brunet <jbrunet@baylibre.com> wrote:
> Trigger the reset line of the mmc controller while probing, if available.
> The reset should be optional for now, at least until all related DT nodes
> have the reset property.
>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
I got a regression boot report from kernelci. The bisect doesn't point
to a certain commit, but I found $subject patch a possible cause. Is
it something you can have a look at and see if it's a valid problem?
https://kernelci.org/boot/id/5b0d68a859b514726179a899/
Kind regards
Uffe
> ---
> drivers/mmc/host/meson-gx-mmc.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
> index 4f972b879fe6..9bca359f7936 100644
> --- a/drivers/mmc/host/meson-gx-mmc.c
> +++ b/drivers/mmc/host/meson-gx-mmc.c
> @@ -35,6 +35,7 @@
> #include <linux/clk.h>
> #include <linux/clk-provider.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> #include <linux/interrupt.h>
> #include <linux/bitfield.h>
> #include <linux/pinctrl/consumer.h>
> @@ -1184,6 +1185,14 @@ static int meson_mmc_probe(struct platform_device *pdev)
> goto free_host;
> }
>
> + ret = device_reset_optional(&pdev->dev);
> + if (ret) {
> + if (ret != -EPROBE_DEFER)
> + dev_err(&pdev->dev, "device reset failed: %d\n", ret);
> +
> + return ret;
> + }
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->regs = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(host->regs)) {
> --
> 2.14.3
>
^ permalink raw reply
* Re: [PATCH v3 3/5] Documentation: DT: add i.MX EPIT timer binding
From: Vladimir Zapolskiy @ 2018-05-30 7:27 UTC (permalink / raw)
To: Clément Péron, Colin Didier, linux-arm-kernel,
devicetree, linux-clk
Cc: Rob Herring, Sascha Hauer, Clément Peron, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <20180529170436.22711-4-peron.clem@gmail.com>
Hi Clément,
On 05/29/2018 08:04 PM, Clément Péron wrote:
> From: Clément Peron <clement.peron@devialet.com>
>
> Add devicetree binding document for NXP's i.MX SoC specific
> EPIT timer driver.
>
> Signed-off-by: Clément Peron <clement.peron@devialet.com>
> ---
> .../devicetree/bindings/clock/imx6q,epit.txt | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/imx6q,epit.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/imx6q,epit.txt b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
> new file mode 100644
> index 000000000000..a84a60c6ae35
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
The file should be renamed to a more generic name like 'imx,epit.txt'
or 'imx31,epit.txt'.
Also note that the folder is incorrectly selected, it must be
Documentation/devicetree/bindings/timer/
> @@ -0,0 +1,24 @@
> +Binding for the i.MX6 EPIT timer
Let's change it to 'Binding for the i.MX EPIT timer'.
> +
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +Required properties:
> +- compatible: should be "fsl,imx6q-epit"
Compatible should be "fsl,imx31-epit", i.MX31 SoC seems to be the first
one in the series, which has the timer module.
There should be added more compatibles specific to later SoC versions.
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: Should contain EPIT controller interrupt
> +- clocks: list of clock specifiers, must contain an entry for each required
> + entry in clock-names
> +- clock-names : should include entries "ipg", "per"
> +
> +Example:
> + epit1: epit@20d0000 {
> + compatible = "fsl,imx6q-epit";
For i.MX6Q example a list of compatibles should be updated like
compatible = "fsl,imx6q-epit", "fsl,imx31-epit";
> + reg = <0x020d0000 0x4000>;
> + interrupts = <0 56 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_EPIT1>,
> + <&clks IMX6QDL_CLK_IPG_PER>;
> + clock-names = "ipg", "per";
It looks like "ipg" and "per" clocks are swapped, please double check it.
> + };
>
--
With best wishes,
Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/5] Documentation: DT: add i.MX EPIT timer binding
From: Vladimir Zapolskiy @ 2018-05-30 7:38 UTC (permalink / raw)
To: Clément Péron, Colin Didier, linux-arm-kernel,
devicetree, linux-clk
Cc: Rob Herring, Sascha Hauer, Clément Peron, NXP Linux Team,
Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <7f2f8b6b-b7f6-99c1-fc5f-a7628a751fdc@mentor.com>
On 05/30/2018 10:27 AM, Vladimir Zapolskiy wrote:
> Hi Clément,
>
> On 05/29/2018 08:04 PM, Clément Péron wrote:
>> From: Clément Peron <clement.peron@devialet.com>
>>
>> Add devicetree binding document for NXP's i.MX SoC specific
>> EPIT timer driver.
>>
>> Signed-off-by: Clément Peron <clement.peron@devialet.com>
>> ---
>> .../devicetree/bindings/clock/imx6q,epit.txt | 24 +++++++++++++++++++
>> 1 file changed, 24 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/imx6q,epit.txt
>>
>> diff --git a/Documentation/devicetree/bindings/clock/imx6q,epit.txt b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
>> new file mode 100644
>> index 000000000000..a84a60c6ae35
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/imx6q,epit.txt
>
> The file should be renamed to a more generic name like 'imx,epit.txt'
> or 'imx31,epit.txt'.
>
> Also note that the folder is incorrectly selected, it must be
> Documentation/devicetree/bindings/timer/
>
And linux-clk mailing list for publishing seems to be improper one,
instead please add Daniel Lezcano <daniel.lezcano@linaro.org> and
Thomas Gleixner <tglx@linutronix.de> to the list of addressees,
and the proper mailing list address is linux-kernel@vger.kernel.org
--
With best wishes,
Vladimir
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/13] Bluetooth: hci_h5: Add support for the RTL8723BS
From: kbuild test robot @ 2018-05-30 7:40 UTC (permalink / raw)
To: Hans de Goede
Cc: kbuild-all, Marcel Holtmann, Johan Hedberg, Martin Blumenstingl,
robh, Jeremy Cline, linux-bluetooth, linux-serial, linux-acpi,
devicetree
In-Reply-To: <20180527190457.2632-13-hdegoede@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
Hi Jeremy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bluetooth/master]
[also build test ERROR on v4.17-rc7 next-20180529]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Hans-de-Goede/Bluetooth-Add-RTL8723BS-support/20180530-141115
base: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git master
config: i386-randconfig-a1-05291352 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
>> ERROR: "serdev_device_set_parity" [drivers/bluetooth/hci_uart.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27967 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/6] clk: tegra20: init NDFLASH clock to sensible rate
From: Peter De Schrijver @ 2018-05-30 7:42 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Stefan Agner, boris.brezillon, dwmw2, computersforpeace,
marek.vasut, robh+dt, mark.rutland, thierry.reding, mturquette,
sboyd, dev, miquel.raynal, richard, marcel, krzk,
benjamin.lindqvist, jonathanh, pgaikwad, mirza.krak, linux-mtd,
linux-tegra, devicetree, linux-kernel, linux-clk
In-Reply-To: <04cdfdf5-33c5-b569-9cd7-dda1b9ea0baf@gmail.com>
On Tue, May 29, 2018 at 03:19:47PM +0300, Dmitry Osipenko wrote:
> On 29.05.2018 15:12, Stefan Agner wrote:
> > On 29.05.2018 09:48, Peter De Schrijver wrote:
> >> On Mon, May 28, 2018 at 05:53:08PM +0200, Stefan Agner wrote:
> >>> On 28.05.2018 09:55, Peter De Schrijver wrote:
> >>>> On Sun, May 27, 2018 at 11:54:40PM +0200, Stefan Agner wrote:
> >>>>> From: Lucas Stach <dev@lynxeye.de>
> >>>>>
> >>>>> Set up the NAND Flash controller clock to run at 150MHz
> >>>>> instead of the rate set by the bootloader. This is a
> >>>>> conservative rate which also yields good performance.
> >>>>>
> >>>>> Signed-off-by: Lucas Stach <dev@lynxeye.de>
> >>>>> Signed-off-by: Stefan Agner <stefan@agner.ch>
> >>>>> ---
> >>>>> drivers/clk/tegra/clk-tegra20.c | 1 +
> >>>>> 1 file changed, 1 insertion(+)
> >>>>>
> >>>>> diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
> >>>>> index 0ee56dd04cec..dff8c425cd28 100644
> >>>>> --- a/drivers/clk/tegra/clk-tegra20.c
> >>>>> +++ b/drivers/clk/tegra/clk-tegra20.c
> >>>>> @@ -1049,6 +1049,7 @@ static struct tegra_clk_init_table init_table[] __initdata = {
> >>>>> { TEGRA20_CLK_GR2D, TEGRA20_CLK_PLL_C, 300000000, 0 },
> >>>>> { TEGRA20_CLK_GR3D, TEGRA20_CLK_PLL_C, 300000000, 0 },
> >>>>> { TEGRA20_CLK_VDE, TEGRA20_CLK_CLK_MAX, 300000000, 0 },
> >>>>> + { TEGRA20_CLK_NDFLASH, TEGRA20_CLK_PLL_P, 150000000, 0 },
> >>>>> /* must be the last entry */
> >>>>> { TEGRA20_CLK_CLK_MAX, TEGRA20_CLK_CLK_MAX, 0, 0 },
> >>>>> };
> >>>>> --
> >>>>> 2.17.0
> >>>>>
> >>>>
> >>>> Maybe better to specify this in the Tegra20 dtsi? See
> >>>> "Assigned clock parents and rates" in
> >>>> Documentation/devicetree/bindings/clock/clock-bindings.txt
> >>>
> >>> assigned-clocks indeed works just fine for this case. Thanks for
> >>> bringing this up, will drop this patch and add the device tree
> >>> properties in v3.
> >>>
> >>> Hm, interesting that none of the Tegra device tree make use of the
> >>> feature so far. I guess there would be other cases where this would be
> >>> useful as well (the one just above, VDE?).
> >>>
> >>
> >> Yes, historically this feature wasn't available, so we used these init tables.
> >> Unfortunately it's not easy to get rid of them for parent and rate
> >> configuration, because new kernels should also work with existing DTBs, so we
> >> can't just add assigned-clock properties and remove the existing table
> >> entries. What we could do is use the CLK_IS_CRITICAL flag for all clocks which
> >> are only enabled by the init table. For not yet merged blocks, this is
> >> ofcourse not a concern.
> >
> > Sure I understand.
> >
> > Was just somewhat surprised that it isn't used at all yet (grep -r -e
> > assigned-clock arch/arm/boot/dts/tegra* returns nothing). After all,
> > assigned clocks bindings have been merged in 2014 :-)
> >
> > At least "clk: tegra: Specify VDE clock rate" merged earlier this year
> > would have been a candidate already.
>
> I wasn't even aware of existence of the assigned-clock properties, probably just
> like others.
This feature seems to be little used indeed. Not sure why.
Peter.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox