* [PATCH 3/7] arm64: dts: qcom: sm8250-mtp: include pmic files
From: Dmitry Baryshkov @ 2020-06-04 0:43 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring
Cc: linux-arm-msm, devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-1-dmitry.baryshkov@linaro.org>
Include files describing used PMIC chips, GPIOs, power on, etc nodes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8250-mtp.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-mtp.dts b/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
index 0bc4b1e037c4..c20ae91d3026 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/sm8250-mtp.dts
@@ -7,6 +7,10 @@
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sm8250.dtsi"
+#include "pm8150.dtsi"
+#include "pm8150b.dtsi"
+#include "pm8150l.dtsi"
+#include "pm8009.dtsi"
/ {
model = "Qualcomm Technologies, Inc. SM8250 MTP";
--
2.26.2
^ permalink raw reply related
* [PATCH 2/7] arm64: dts: qcom: sm8250: change spmi node label
From: Dmitry Baryshkov @ 2020-06-04 0:43 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring
Cc: linux-arm-msm, devicetree, patches, linaro-kernel
In-Reply-To: <20200604004331.669936-1-dmitry.baryshkov@linaro.org>
PMIC dtsi files (pm8150*.dtsi) expect to have spmi_bus label, rather
than just spmi. Rename spmi label accordingly.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 1e2862bbfb11..9dd27aecdfda 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -991,7 +991,7 @@ pdc: interrupt-controller@b220000 {
interrupt-controller;
};
- spmi: qcom,spmi@c440000 {
+ spmi_bus: qcom,spmi@c440000 {
compatible = "qcom,spmi-pmic-arb";
reg = <0x0 0x0c440000 0x0 0x0001100>,
<0x0 0x0c600000 0x0 0x2000000>,
--
2.26.2
^ permalink raw reply related
* [PATCH 1/7] arm64: dts: qcom: pm8009: Add base dts file
From: Dmitry Baryshkov @ 2020-06-04 0:43 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring
Cc: linux-arm-msm, devicetree, patches, linaro-kernel
Add base DTS file for pm8009 along with GPIOs and power-on nodes.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
arch/arm64/boot/dts/qcom/pm8009.dtsi | 40 ++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/pm8009.dtsi
diff --git a/arch/arm64/boot/dts/qcom/pm8009.dtsi b/arch/arm64/boot/dts/qcom/pm8009.dtsi
new file mode 100644
index 000000000000..9f3e19b5bd00
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8009.dtsi
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2017-2019, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2019, Linaro Limited
+ */
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/spmi/spmi.h>
+#include <dt-bindings/iio/qcom,spmi-vadc.h>
+
+&spmi_bus {
+ pmic@a {
+ compatible = "qcom,pm8009", "qcom,spmi-pmic";
+ reg = <0xa SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-on@800 {
+ compatible = "qcom,pm8916-pon";
+ reg = <0x0800>;
+ };
+
+ pm8009_gpios: gpio@c000 {
+ compatible = "qcom,pm8005-gpio";
+ reg = <0xc000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ pmic@b {
+ compatible = "qcom,pm8009", "qcom,spmi-pmic";
+ reg = <0xb SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH 4/4] arm64: dts: ipq6018: Add support for apcs clk
From: kernel test robot @ 2020-06-04 0:19 UTC (permalink / raw)
To: Sivaprakash Murugesan, agross, bjorn.andersson, robh+dt,
jassisinghbrar, linux-arm-msm, devicetree, linux-kernel
Cc: kbuild-all, clang-built-linux, Sivaprakash Murugesan
In-Reply-To: <1590583092-24290-5-git-send-email-sivaprak@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
Hi Sivaprakash,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on linus/master v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Sivaprakash-Murugesan/Add-ipq6018-apcs-mailbox-driver/20200527-204025
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-randconfig-r016-20200603 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 16437992cac249f6fe1efd392d20e3469b47e39e)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: Input tree has errors, aborting (use -f to force output)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 35982 bytes --]
^ permalink raw reply
* Re: [v4] dt-bindings: msm: disp: add yaml schemas for DPU and DSI bindings
From: Rob Herring @ 2020-06-03 22:45 UTC (permalink / raw)
To: Krishna Manikandan
Cc: dri-devel, linux-arm-msm, freedreno, devicetree, linux-kernel,
robdclark, seanpaul, hoegsberg, kalyan_t, nganji, mka
In-Reply-To: <1589868421-30062-1-git-send-email-mkrishn@codeaurora.org>
On Tue, May 19, 2020 at 11:37:01AM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem (MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
>
> Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
>
> Changes in v2:
> - Changed dpu to DPU (Sam Ravnborg)
> - Fixed indentation issues (Sam Ravnborg)
> - Added empty line between different properties (Sam Ravnborg)
> - Replaced reference txt files with their corresponding
> yaml files (Sam Ravnborg)
> - Modified the file to use "|" only when it is
> necessary (Sam Ravnborg)
>
> Changes in v3:
> - Corrected the license used (Rob Herring)
> - Added maxItems for properties (Rob Herring)
> - Dropped generic descriptions (Rob Herring)
> - Added ranges property (Rob Herring)
> - Corrected the indendation (Rob Herring)
> - Added additionalProperties (Rob Herring)
> - Split dsi file into two, one for dsi controller
> and another one for dsi phy per target (Rob Herring)
> - Corrected description for pinctrl-names (Rob Herring)
> - Corrected the examples used in yaml file (Rob Herring)
> - Delete dsi.txt and dpu.txt (Rob Herring)
>
> Changes in v4:
> - Move schema up by one level (Rob Herring)
> - Add patternProperties for mdp node (Rob Herring)
> - Corrected description of some properties (Rob Herring)
> ---
> .../bindings/display/msm/dpu-sc7180.yaml | 243 ++++++++++++++++++++
> .../bindings/display/msm/dpu-sdm845.yaml | 220 ++++++++++++++++++
> .../devicetree/bindings/display/msm/dpu.txt | 141 ------------
> .../display/msm/dsi-controller-sc7180.yaml | 123 +++++++++++
> .../display/msm/dsi-controller-sdm845.yaml | 120 ++++++++++
> .../bindings/display/msm/dsi-controller.yaml | 151 +++++++++++++
> .../bindings/display/msm/dsi-phy-sc7180.yaml | 75 +++++++
> .../bindings/display/msm/dsi-phy-sdm845.yaml | 76 +++++++
> .../devicetree/bindings/display/msm/dsi-phy.yaml | 82 +++++++
> .../devicetree/bindings/display/msm/dsi.txt | 246 ---------------------
> 10 files changed, 1090 insertions(+), 387 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
> delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt
> create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
> create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
> create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller.yaml
> create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
> create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml
> create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy.yaml
> delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt
>
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> new file mode 100644
> index 0000000..b5607f9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
> @@ -0,0 +1,243 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DPU dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates
> + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
> + bindings of MDSS and DPU are mentioned for SC7180 target.
> +
> +properties:
> + compatible:
> + items:
> + - const: qcom,sc7180-mdss
blank line between properties.
> + reg:
> + maxItems: 1
> +
> + reg-names:
> + const: mdss
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + description: |
> + Device clock names in the same order as mentioned in clocks property.
> + The required clocks are mentioned below.
Not a useful description. Unless you have something specific about
*this* device, drop it.
> + items:
> + - const: iface
> + - const: ahb
> + - const: core
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 1
> +
> + iommus:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> + interconnects:
> + description: |
> + Interconnect path specifier for MDSS according to
> + Documentation/devicetree/bindings/interconnect/interconnect.txt.
> + An entry should contain 2 paths corresponding to 2 AXI ports representing
> + source and destination ports.
2 entries or...
> + maxItems: 1
1?
> +
> + interconnect-names:
> + description: |
> + MDSS will have 2 port names to differentiate between the
> + 2 interconnect paths defined with interconnect specifier.
> + maxItems: 1
Need to define the names.
> +
> + assigned-clocks:
> + description: |
> + Clock specifiers for clocks needing rate assignment (optional).
That's every 'assigned-clocks'. Think about that for all of your
'description' entries and drop them if nothing device specific.
> + maxItems: 1
> +
> + assigned-clock-rates:
> + description: |
> + Clock frequencies sorted in the same order as the
> + assigned-clocks property (optional).
> + maxItems: 1
> +
> +patternProperties:
> + "^mdp@[0-9a-f]+$":
> + type: object
> + description: Node containing the properties of DPU.
> +
> + properties:
> + compatible:
> + items:
> + - const: qcom,sc7180-dpu
> +
> + reg:
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: mdp
> + - const: vbif
> +
> + clocks:
> + maxItems: 6
> +
> + clock-names:
> + description: |
> + Device clock names, must be in same order as clocks property.
> + The following clocks are required. "bus" is an optional property
> + in sc7180 due to architecture change. "rot" and "lut" are optional
> + device clocks, needed for accessing LUT blocks.
The schema doesn't match this description. The schema only allows
the exact list below. You'll need an if/then schema to define the
different combinations. Or a 'oneOf' schema if there's different
possibilities for just the sc7180. There shouldn't be though. A given
chip either has a clock or it doesn't.
> + items:
> + - const: bus
> + - const: iface
> + - const: rot
> + - const: lut
> + - const: core
> + - const: vsync
> +
> + interrupts:
> + maxItems: 1
> +
> + ports:
> + type: object
> + description: |
> + Contains the list of output ports from DPU device. These ports
> + connect to interfaces that are external to the DPU hardware,
> + such as DSI, DP etc. Each output port contains an endpoint that
> + describes how it is connected to an external interface. These
> + are described by the standard properties documented in files
> + mentioned below.
> +
> + Documentation/devicetree/bindings/graph.txt
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> + properties:
> + port@0:
Wrong indentation.
> + type: object
> + description: DPU_INTF1 (DSI1)
> + port@1:
> + type: object
> + description: DPU_INTF2 (DSI2)
> +
> + assigned-clocks:
> + description: |
> + Clock specifiers for clocks needing rate assignment (optional).
> + maxItems: 4
> +
> + assigned-clock-rates:
> + description: |
> + Clock frequencies sorted in the same order as the
> + assigned-clocks property (optional).
> + maxItems: 4
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - power-domains
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-controller
> + - iommus
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,dispcc-sc7180.h>
> + #include <dt-bindings/clock/qcom,gcc-sc7180.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interconnect/qcom,sdm845.h>
> + mdss: mdss@ae00000 {
> + compatible = "qcom,sc7180-mdss";
> + reg = <0 0xae00000 0 0x1000>;
> + reg-names = "mdss";
> + power-domains = <&dispcc MDSS_GDSC>;
> +
> + clocks = <&gcc GCC_DISP_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_CLK>;
> +
> + clock-names = "iface", "ahb", "core";
> +
> + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
> + assigned-clock-rates = <300000000>;
> +
> + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>;
interconnects = <&mmss_noc MASTER_MDP0>, <&mc_virt SLAVE_EBI1>;
Which will fail with the above schema.
> +
> + interconnect-names = "mdp0-mem";
> +
> + iommus = <&apps_smmu 0x800 0x2>;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + mdp: mdp@ae01000 {
> + compatible = "qcom,sc7180-dpu";
> + reg = <0 0x0ae01000 0 0x8f000>,
> + <0 0x0aeb0000 0 0x2008>;
> +
> + reg-names = "mdp", "vbif";
> +
> + clocks = <&gcc GCC_DISP_HF_AXI_CLK>,
> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_ROT_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_CLK>,
> + <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
> + clock-names = "bus", "iface", "rot", "lut", "core",
> + "vsync";
> + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
> + <&dispcc DISP_CC_MDSS_VSYNC_CLK>,
> + <&dispcc DISP_CC_MDSS_ROT_CLK>,
> + <&dispcc DISP_CC_MDSS_ROT_CLK>;
> + assigned-clock-rates = <300000000>,
> + <19200000>,
> + <19200000>,
> + <19200000>;
> +
> + interrupt-parent = <&mdss>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dpu_intf1_out: endpoint {
> + remote-endpoint = <&dsi0_in>;
> + };
> + };
> + };
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
> new file mode 100644
> index 0000000..ed036fd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
> @@ -0,0 +1,220 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dpu-sdm845.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DPU dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates
> + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree
> + bindings of MDSS and DPU are mentioned for SDM845 target.
> +
> +properties:
> + compatible:
> + items:
> + - const: qcom,sdm845-mdss
> + reg:
> + maxItems: 1
> +
> + reg-names:
> + const: mdss
> +
> + power-domains:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 3
> +
> + clock-names:
> + description: |
> + Device clock names in the same order as mentioned in clocks property.
> + The required clocks are mentioned below.
> + items:
> + - const: iface
> + - const: bus
> + - const: core
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 1
> +
> + iommus:
> + maxItems: 2
Need to define what each one is:
items:
- description: ...
- description: ...
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> + assigned-clocks:
> + description: |
> + Clock specifiers for clocks needing rate assignment (optional).
> + maxItems: 1
> +
> + assigned-clock-rates:
> + description: |
> + Clock frequencies sorted in the same order as the
> + assigned-clocks property (optional).
> + maxItems: 1
> +
> +patternProperties:
> + "^mdp@[0-9a-f]+$":
> + type: object
> + description: Node containing the properties of DPU.
> +
> + properties:
> + compatible:
> + items:
> + - const: qcom,sdm845-dpu
> + reg:
> + maxItems: 2
> +
> + reg-names:
> + items:
> + - const: mdp
> + - const: vbif
> +
> + clocks:
> + maxItems: 4
> +
> + clock-names:
> + description: |
> + Device clock names, must be in same order as clocks property.
> + The following clocks are required.
> + items:
> + - const: iface
> + - const: bus
> + - const: core
> + - const: vsync
> +
> + interrupts:
> + maxItems: 1
> +
> + ports:
> + type: object
> + description: |
> + Contains the list of output ports from DPU device. These ports
> + connect to interfaces that are external to the DPU hardware,
> + such as DSI, DP etc. Each output port contains an endpoint that
> + describes how it is connected to an external interface. These
> + are described by the standard properties documented in files
> + mentioned below.
> +
> + Documentation/devicetree/bindings/graph.txt
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> + properties:
> + port@0:
> + type: object
> + description: DPU_INTF1 (DSI1)
> + port@1:
> + type: object
> + description: DPU_INTF2 (DSI2)
> +
> + assigned-clocks:
> + description: |
> + Clock specifiers for clocks needing rate assignment (optional).
> + maxItems: 2
> +
> + assigned-clock-rates:
> + description: |
> + Clock frequencies sorted in the same order as the
> + assigned-clocks property (optional).
> + maxItems: 2
> +
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - power-domains
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-controller
> + - iommus
> +
> +additionalProperties: false
> +
> +examples:
> +- |
> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
> + #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + mdss: mdss@ae00000 {
> + compatible = "qcom,sdm845-mdss";
> + reg = <0 0x0ae00000 0 0x1000>;
> + reg-names = "mdss";
> + power-domains = <&dispcc MDSS_GDSC>;
> +
> + clocks = <&gcc GCC_DISP_AHB_CLK>,
> + <&gcc GCC_DISP_AXI_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_CLK>;
> + clock-names = "iface", "bus", "core";
> +
> + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>;
> + assigned-clock-rates = <300000000>;
> +
> + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + iommus = <&apps_smmu 0x880 0x8>,
> + <&apps_smmu 0xc80 0x8>;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + mdss_mdp: mdp@ae01000 {
> + compatible = "qcom,sdm845-dpu";
> + reg = <0 0x0ae01000 0 0x8f000>,
> + <0 0x0aeb0000 0 0x2008>;
> + reg-names = "mdp", "vbif";
> +
> + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_AXI_CLK>,
> + <&dispcc DISP_CC_MDSS_MDP_CLK>,
> + <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
> + clock-names = "iface", "bus", "core", "vsync";
> +
> + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>,
> + <&dispcc DISP_CC_MDSS_VSYNC_CLK>;
> + assigned-clock-rates = <300000000>,
> + <19200000>;
> +
> + interrupt-parent = <&mdss>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dpu_intf1_out: endpoint {
> + remote-endpoint = <&dsi0_in>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dpu_intf2_out: endpoint {
> + remote-endpoint = <&dsi1_in>;
> + };
> + };
> + };
> + };
> + };
> +...
> diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt
> deleted file mode 100644
> index 551ae26..0000000
> --- a/Documentation/devicetree/bindings/display/msm/dpu.txt
> +++ /dev/null
> @@ -1,141 +0,0 @@
> -Qualcomm Technologies, Inc. DPU KMS
> -
> -Description:
> -
> -Device tree bindings for MSM Mobile Display Subsytem(MDSS) that encapsulates
> -sub-blocks like DPU display controller, DSI and DP interfaces etc.
> -The DPU display controller is found in SDM845 SoC.
> -
> -MDSS:
> -Required properties:
> -- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss"
> -- reg: physical base address and length of contoller's registers.
> -- reg-names: register region names. The following region is required:
> - * "mdss"
> -- power-domains: a power domain consumer specifier according to
> - Documentation/devicetree/bindings/power/power_domain.txt
> -- clocks: list of clock specifiers for clocks needed by the device.
> -- clock-names: device clock names, must be in same order as clocks property.
> - The following clocks are required:
> - * "iface"
> - * "bus"
> - * "core"
> -- interrupts: interrupt signal from MDSS.
> -- interrupt-controller: identifies the node as an interrupt controller.
> -- #interrupt-cells: specifies the number of cells needed to encode an interrupt
> - source, should be 1.
> -- iommus: phandle of iommu device node.
> -- #address-cells: number of address cells for the MDSS children. Should be 1.
> -- #size-cells: Should be 1.
> -- ranges: parent bus address space is the same as the child bus address space.
> -- interconnects : interconnect path specifier for MDSS according to
> - Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be
> - 2 paths corresponding to 2 AXI ports.
> -- interconnect-names : MDSS will have 2 port names to differentiate between the
> - 2 interconnect paths defined with interconnect specifier.
> -
> -Optional properties:
> -- assigned-clocks: list of clock specifiers for clocks needing rate assignment
> -- assigned-clock-rates: list of clock frequencies sorted in the same order as
> - the assigned-clocks property.
> -
> -MDP:
> -Required properties:
> -- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu"
> -- reg: physical base address and length of controller's registers.
> -- reg-names : register region names. The following region is required:
> - * "mdp"
> - * "vbif"
> -- clocks: list of clock specifiers for clocks needed by the device.
> -- clock-names: device clock names, must be in same order as clocks property.
> - The following clocks are required.
> - * "bus"
> - * "iface"
> - * "core"
> - * "vsync"
> -- interrupts: interrupt line from DPU to MDSS.
> -- ports: contains the list of output ports from DPU device. These ports connect
> - to interfaces that are external to the DPU hardware, such as DSI, DP etc.
> -
> - Each output port contains an endpoint that describes how it is connected to an
> - external interface. These are described by the standard properties documented
> - here:
> - Documentation/devicetree/bindings/graph.txt
> - Documentation/devicetree/bindings/media/video-interfaces.txt
> -
> - Port 0 -> DPU_INTF1 (DSI1)
> - Port 1 -> DPU_INTF2 (DSI2)
> -
> -Optional properties:
> -- assigned-clocks: list of clock specifiers for clocks needing rate assignment
> -- assigned-clock-rates: list of clock frequencies sorted in the same order as
> - the assigned-clocks property.
> -
> -Example:
> -
> - mdss: mdss@ae00000 {
> - compatible = "qcom,sdm845-mdss";
> - reg = <0xae00000 0x1000>;
> - reg-names = "mdss";
> -
> - power-domains = <&clock_dispcc 0>;
> -
> - clocks = <&gcc GCC_DISP_AHB_CLK>, <&gcc GCC_DISP_AXI_CLK>,
> - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>;
> - clock-names = "iface", "bus", "core";
> -
> - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>;
> - assigned-clock-rates = <300000000>;
> -
> - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-controller;
> - #interrupt-cells = <1>;
> -
> - interconnects = <&rsc_hlos MASTER_MDP0 &rsc_hlos SLAVE_EBI1>,
> - <&rsc_hlos MASTER_MDP1 &rsc_hlos SLAVE_EBI1>;
> -
> - interconnect-names = "mdp0-mem", "mdp1-mem";
> -
> - iommus = <&apps_iommu 0>;
> -
> - #address-cells = <2>;
> - #size-cells = <1>;
> - ranges = <0 0 0xae00000 0xb2008>;
> -
> - mdss_mdp: mdp@ae01000 {
> - compatible = "qcom,sdm845-dpu";
> - reg = <0 0x1000 0x8f000>, <0 0xb0000 0x2008>;
> - reg-names = "mdp", "vbif";
> -
> - clocks = <&clock_dispcc DISP_CC_MDSS_AHB_CLK>,
> - <&clock_dispcc DISP_CC_MDSS_AXI_CLK>,
> - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>,
> - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>;
> - clock-names = "iface", "bus", "core", "vsync";
> -
> - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>,
> - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>;
> - assigned-clock-rates = <0 0 300000000 19200000>;
> -
> - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - dpu_intf1_out: endpoint {
> - remote-endpoint = <&dsi0_in>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - dpu_intf2_out: endpoint {
> - remote-endpoint = <&dsi1_in>;
> - };
> - };
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
> new file mode 100644
> index 0000000..deb8272
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-sc7180.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dsi-controller-sc7180.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DSI controller dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Device tree bindings for DSI controller for SC7180 target.
> +
> +allOf:
> + - $ref: dsi-controller.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,mdss-dsi-ctrl
> +
> + reg:
> + maxItems: 1
> +
> + reg-names:
> + const: dsi_ctrl
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 6
> +
> + clock-names:
> + items:
> + - const: byte
> + - const: byte_intf
> + - const: pixel
> + - const: core
> + - const: iface
> + - const: bus
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + const: dsi
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
These 2 properties aren't needed here.
> +
> + ports: true
Need to define what 'port@0' and 'port@1' are.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupt-parent
> + - interrupts
> + - clocks
> + - clock-names
> + - phys
> + - phy-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,dispcc-sc7180.h>
> + #include <dt-bindings/clock/qcom,gcc-sc7180.h>
> +
> + dsi0: dsi@ae94000 {
> + compatible = "qcom,mdss-dsi-ctrl";
> + reg = <0 0x0ae94000 0 0x400>;
> + reg-names = "dsi_ctrl";
> +
> + interrupt-parent = <&mdss>;
> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
> + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
> + <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
> + <&dispcc DISP_CC_MDSS_ESC0_CLK>,
> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&gcc GCC_DISP_HF_AXI_CLK>;
> +
> + clock-names = "byte",
> + "byte_intf",
> + "pixel",
> + "core",
> + "iface",
> + "bus";
> +
> + phys = <&dsi_phy>;
> + phy-names = "dsi";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <&dpu_intf1_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi0_out: endpoint {
> + };
> + };
> + };
> + };
> +...
> +
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
> new file mode 100644
> index 0000000..264d7c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-sdm845.yaml
> @@ -0,0 +1,120 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dsi-controller-sdm845.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DSI controller dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Device tree bindings for DSI controller for SDM845 target.
> +
> +allOf:
> + - $ref: dsi-controller.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,mdss-dsi-ctrl
> +
> + reg:
> + maxItems: 1
> +
> + reg-names:
> + const: dsi_ctrl
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 6
> +
> + clock-names:
> + items:
> + - const: byte
> + - const: byte_intf
> + - const: pixel
> + - const: core
> + - const: iface
> + - const: bus
> +
> + phys:
> + maxItems: 1
> +
> + phy-names:
> + const: dsi
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + ports: true
Need to define each port.
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupt-parent
> + - interrupts
> + - clocks
> + - clock-names
> + - phys
> + - phy-names
> + - ports
> +
> +additionalProperties: false
unevaluatedProperties: false
Because DSI bus child nodes defined in dsi-controller.yaml should be
valid too.
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
> + #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> +
> + dsi0: dsi@ae94000 {
> + compatible = "qcom,mdss-dsi-ctrl";
> + reg = <0 0x0ae94000 0 0x400>;
> + reg-names = "dsi_ctrl";
> +
> + interrupt-parent = <&mdss>;
> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH>;
> +
> + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>,
> + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>,
> + <&dispcc DISP_CC_MDSS_PCLK0_CLK>,
> + <&dispcc DISP_CC_MDSS_ESC0_CLK>,
> + <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&dispcc DISP_CC_MDSS_AXI_CLK>;
> + clock-names = "byte",
> + "byte_intf",
> + "pixel",
> + "core",
> + "iface",
> + "bus";
> +
> + phys = <&dsi0_phy>;
> + phy-names = "dsi";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <&dpu_intf1_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi0_out: endpoint {
> + };
> + };
> + };
> + };
> +...
> +
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller.yaml
> new file mode 100644
> index 0000000..dbec55e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller.yaml
> @@ -0,0 +1,151 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dsi-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DSI controller dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Common Device tree bindings for DSI controller.
Not a correct description. We already have a common binding for DSI
controllers and should reference it (dsi-controller.yaml).
> +
> +properties:
> + compatible:
> + items:
> + - const: qcom,mdss-dsi-ctrl
> +
> + clocks:
> + maxItems: 6
> +
> + clock-names:
> + description: |
> + Device clock names in the same order as mentioned in clocks property.
> + For DSIv2, we need an additional clock "src" and for DSI6G v2.0
> + onwards we need "byte_intf" clock.
Need a schema list.
> +
> + assigned-clocks:
> + description: Parents of "byte" and "pixel" for the given platform.
How many?
> +
> + assigned-clock-parents:
> + description: |
> + The Byte clock and Pixel clock PLL outputs provided by a DSI PHY block.
> + Details on clock bindings are mentioned in
> + Documentation/devicetree/bindings/clock/clock-bindings.txt.
> +
> + vdd-supply:
> + description: Phandle to vdd regulator device node.
> +
> + vddio-supply:
> + description: Phandle to vdd-io regulator device node.
> +
> + vdda-supply:
> + description: Phandle to vdda regulator device node.
> +
> + phys:
> + description: Phandle to DSI PHY device node.
> +
> + phy-names:
> + description: Name of the corresponding PHY device.
> +
> + syscon-sfpb:
> + description: A phandle to mmss_sfpb syscon node (only for DSIv2).
Needs a type $ref.
> +
> + # Optional Properties for dsi controller
> + panel@0:
> + description: |
> + Node of panel connected to this DSI controller.
> + See files in Documentation/devicetree/bindings/display/panel/
> + for each supported panel.
Covered by the common binding. Could be a bridge instead BTW.
> +
> + qcom,mdss-mdp-transfer-time-us:
> + description: |
> + Specifies the DSI transfer time for command mode
> + panels in microseconds. Driver uses this number to adjust
> + the clock rate according to the expected transfer time.
> + Increasing this value would slow down the mdp processing
> + and can result in slower performance.
> + Decreasing this value can speed up the mdp processing,
> + but this can also impact power consumption.
> + As a rule this time should not be higher than the time
> + that would be expected with the processing at the
> + DSI link rate since anyways this would be the maximum
> + transfer time that could be achieved.
> + If ping pong split is enabled, this time should not be higher
> + than two times the DSI link rate time.
> + If the property is not specified, then the default value is
> + 14000 us. This is an optional property.
> +
> + qcom,dual-dsi-mode:
> + type: boolean
> + description: |
> + Boolean value indicating if the DSI controller is
> + driving a panel which needs 2 DSI links.
> +
> + qcom,master-dsi:
> + type: boolean
> + description: |
> + Boolean value indicating if the DSI controller is driving
> + the master link of the 2-DSI panel.
> +
> + qcom,sync-dual-dsi:
> + type: boolean
> + description: |
> + Boolean value indicating if the DSI controller is driving a
> + 2-DSI panel whose 2 links need receive command simultaneously.
Dependencies between these 3 properties? If so, use dependencies.
> +
> + pinctrl-names:
> + description: The pin control state names; may be "default" or "sleep".
Sounds like constraints.
> +
> + pinctrl-0:
> + description: The default pinctrl state (active)
> +
> + pinctrl-1:
> + description: The sleep pinctrl state (suspend)
No need to document these 2.
> +
> + ports:
> + type: object
> + description: |
> + Contains DSI controller input and output ports as children, each
> + containing one endpoint subnode as defined in
> + Documentation/devicetree/bindings/graph.txt and
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> + properties:
> + remote-endpoint:
Not a property in 'ports'
> + description: |
> + For port@0, set to phandle of the connected panel/bridge's
> + input endpoint. For port@1, set to the MDP interface output.
> + See Documentation/devicetree/bindings/graph.txt for
> + device graph info.
> +
> + data-lanes:
> + description: |
> + This describes how the physical DSI data lanes are mapped
> + to the logical lanes on the given platform. The value contained in
> + index n describes what physical lane is mapped to the logical lane n
> + (DATAn, where n lies between 0 and 3). The clock lane position is fixed
> + and can't be changed. Hence, they aren't a part of the DT bindings. See
> + Documentation/devicetree/bindings/media/video-interfaces.txt for
> + more info on the data-lanes property.
> +
> + For example:
> + data-lanes = <3 0 1 2>;
> +
> + The above mapping describes that the logical data lane DATA0 is mapped
> + to the physical data lane DATA3, logical DATA1 to physical DATA0,
> + logic DATA2 to phys DATA1 and logic DATA3 to phys DATA2. There are
> + only a limited number of physical to logical mappings possible.
> + oneOf:
> + - const: <0 1 2 3>
> + - const: <1 2 3 0>
> + - const: <2 3 0 1>
> + - const: <3 0 1 2>
> + - const: <0 3 2 1>
> + - const: <1 0 3 2>
> + - const: <2 1 0 3>
> + - const: <3 2 1 0>
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
> new file mode 100644
> index 0000000..316b3b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-sc7180.yaml
> @@ -0,0 +1,75 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dsi-phy-sc7180.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DSI PHY dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Device tree bindings for DSI PHY for SC7180 target.
> +
> +allOf:
> + - $ref: dsi-phy.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,dsi-phy-10nm
> +
> + reg:
> + maxItems: 3
> +
> + reg-names:
> + maxItems: 3
> +
> + clocks:
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: iface
> + - const: ref
> +
> + "#clock-cells":
> + const: 1
> +
> + "#phy-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,dispcc-sc7180.h>
> + #include <dt-bindings/clock/qcom,gcc-sc7180.h>
> + #include <dt-bindings/clock/qcom,rpmh.h>
> +
> + dsi_phy: dsi-phy@ae94400 {
> + compatible = "qcom,dsi-phy-10nm";
> + reg = <0 0x0ae94400 0 0x200>,
> + <0 0x0ae94600 0 0x280>,
> + <0 0x0ae94a00 0 0x1e0>;
> + reg-names = "dsi_phy",
> + "dsi_phy_lane",
> + "dsi_pll";
> +
> + #clock-cells = <1>;
> + #phy-cells = <0>;
> +
> + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "iface", "ref";
> + };
> +...
> +
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml
> new file mode 100644
> index 0000000..0c9d19a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-sdm845.yaml
> @@ -0,0 +1,76 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dsi-phy-sdm845.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DSI PHY dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Device tree bindings for DSI PHY for SDM845 target.
> +
> +allOf:
> + - $ref: dsi-phy.yaml#
> +
> +properties:
> + compatible:
> + const: qcom,dsi-phy-10nm
> +
> + reg:
> + maxItems: 3
> +
> + reg-names:
> + maxItems: 3
> +
> + clocks:
> + maxItems: 2
> +
> + clock-names:
> + items:
> + - const: iface
> + - const: ref
> +
> + "#clock-cells":
> + const: 1
> +
> + "#phy-cells":
> + const: 0
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h>
> + #include <dt-bindings/clock/qcom,gcc-sdm845.h>
> + #include <dt-bindings/clock/qcom,rpmh.h>
> +
> + dsi0_phy: dsi-phy@ae94400 {
> + compatible = "qcom,dsi-phy-10nm";
> + reg = <0 0x0ae94400 0 0x200>,
> + <0 0x0ae94600 0 0x280>,
> + <0 0x0ae94a00 0 0x1e0>;
> + reg-names = "dsi_phy",
> + "dsi_phy_lane",
> + "dsi_pll";
> +
> + #clock-cells = <1>;
> + #phy-cells = <0>;
> +
> + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> + <&rpmhcc RPMH_CXO_CLK>;
> + clock-names = "iface", "ref";
Where's vdds-supply you say is required?
> +
> + };
> +...
> +
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy.yaml
> new file mode 100644
> index 0000000..46ac96f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy.yaml
> @@ -0,0 +1,82 @@
> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/msm/dsi-phy.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Description of Qualcomm Display DSI PHY dt properties.
> +
> +maintainers:
> + - Krishna Manikandan <mkrishn@codeaurora.org>
> +
> +description: |
> + Common Device tree bindings for DSI PHY.
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: qcom,dsi-phy-28nm-hpm
> + - const: qcom,dsi-phy-28nm-lp
> + - const: qcom,dsi-phy-20nm
> + - const: qcom,dsi-phy-28nm-8960
> + - const: qcom,dsi-phy-14nm
> + - const: qcom,dsi-phy-10nm
> + - const: qcom,dsi-phy-10nm-8998
> +
> + reg-names:
> + description: Name of register regions.
> + oneOf:
> + - description: |
> + Following regions are required for DSI 28nm HPM/LP/8960 PHYs and
> + 20nm PHY.
> + items:
> + - const: dsi_pll
> + - const: dsi_phy
> + - const: dsi_phy_regulator
> +
> + - description: |
> + Following regions are required for DSI 14nm and 10nm PHYs:
> + items:
> + - const: dsi_phy
> + - const: dsi_phy_lane
> + - const: dsi_pll
> +
> + clock-cells:
> + description: |
> + The DSI PHY block acts as a clock provider, creating
> + 2 clocks: A byte clock (index 0), and a pixel clock (index 1).
> + const: 1
> +
> + power-domains:
> + description: Should be <&mmcc MDSS_GDSC>.
How many?
> +
> + clocks:
> + maxItems: 2
> +
> + clock-names:
> + description: |
> + The following clocks are required.
> + "iface"
> + "ref" (only required for new DTS files/entries)
Sounds like constraints.
> +
> + vddio-supply:
> + description: |
> + Phandle to vdd-io regulator device node. Required for 28nm HPM/LP,
> + 28nm 8960 PHYs and 20nm PHY.
I'm not sure a common file helps here with all these free form text
constraints. We can't validate whether having 'vddio-supply' is correct
or not.
> +
> + vcca-supply:
> + description: |
> + Phandle to vcca regulator device node. Required for 20nm PHY and
> + 10nm PHY.
> +
> + vdds-supply:
> + description: |
> + Phandle to vdds regulator device node. Required for 10nm PHY.
> +
> + qcom,dsi-phy-regulator-ldo-mode:
> + type: boolean
> + description: |
> + Boolean value indicating if the LDO mode PHY regulator is wanted (optional).
> +
> +...
> +
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
> deleted file mode 100644
> index af95586..0000000
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ /dev/null
> @@ -1,246 +0,0 @@
> -Qualcomm Technologies Inc. adreno/snapdragon DSI output
> -
> -DSI Controller:
> -Required properties:
> -- compatible:
> - * "qcom,mdss-dsi-ctrl"
> -- reg: Physical base address and length of the registers of controller
> -- reg-names: The names of register regions. The following regions are required:
> - * "dsi_ctrl"
> -- interrupts: The interrupt signal from the DSI block.
> -- power-domains: Should be <&mmcc MDSS_GDSC>.
> -- clocks: Phandles to device clocks.
> -- clock-names: the following clocks are required:
> - * "mdp_core"
> - * "iface"
> - * "bus"
> - * "core_mmss"
> - * "byte"
> - * "pixel"
> - * "core"
> - For DSIv2, we need an additional clock:
> - * "src"
> - For DSI6G v2.0 onwards, we need also need the clock:
> - * "byte_intf"
> -- assigned-clocks: Parents of "byte" and "pixel" for the given platform.
> -- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided
> - by a DSI PHY block. See [1] for details on clock bindings.
> -- vdd-supply: phandle to vdd regulator device node
> -- vddio-supply: phandle to vdd-io regulator device node
> -- vdda-supply: phandle to vdda regulator device node
> -- phys: phandle to DSI PHY device node
> -- phy-names: the name of the corresponding PHY device
> -- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
> -- ports: Contains 2 DSI controller ports as child nodes. Each port contains
> - an endpoint subnode as defined in [2] and [3].
> -
> -Optional properties:
> -- panel@0: Node of panel connected to this DSI controller.
> - See files in [4] for each supported panel.
> -- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
> - driving a panel which needs 2 DSI links.
> -- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
> - the master link of the 2-DSI panel.
> -- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is
> - driving a 2-DSI panel whose 2 links need receive command simultaneously.
> -- pinctrl-names: the pin control state names; should contain "default"
> -- pinctrl-0: the default pinctrl state (active)
> -- pinctrl-n: the "sleep" pinctrl state
> -- ports: contains DSI controller input and output ports as children, each
> - containing one endpoint subnode.
> -
> - DSI Endpoint properties:
> - - remote-endpoint: For port@0, set to phandle of the connected panel/bridge's
> - input endpoint. For port@1, set to the MDP interface output. See [2] for
> - device graph info.
> -
> - - data-lanes: this describes how the physical DSI data lanes are mapped
> - to the logical lanes on the given platform. The value contained in
> - index n describes what physical lane is mapped to the logical lane n
> - (DATAn, where n lies between 0 and 3). The clock lane position is fixed
> - and can't be changed. Hence, they aren't a part of the DT bindings. See
> - [3] for more info on the data-lanes property.
> -
> - For example:
> -
> - data-lanes = <3 0 1 2>;
> -
> - The above mapping describes that the logical data lane DATA0 is mapped to
> - the physical data lane DATA3, logical DATA1 to physical DATA0, logic DATA2
> - to phys DATA1 and logic DATA3 to phys DATA2.
> -
> - There are only a limited number of physical to logical mappings possible:
> - <0 1 2 3>
> - <1 2 3 0>
> - <2 3 0 1>
> - <3 0 1 2>
> - <0 3 2 1>
> - <1 0 3 2>
> - <2 1 0 3>
> - <3 2 1 0>
> -
> -DSI PHY:
> -Required properties:
> -- compatible: Could be the following
> - * "qcom,dsi-phy-28nm-hpm"
> - * "qcom,dsi-phy-28nm-lp"
> - * "qcom,dsi-phy-20nm"
> - * "qcom,dsi-phy-28nm-8960"
> - * "qcom,dsi-phy-14nm"
> - * "qcom,dsi-phy-10nm"
> - * "qcom,dsi-phy-10nm-8998"
> -- reg: Physical base address and length of the registers of PLL, PHY. Some
> - revisions require the PHY regulator base address, whereas others require the
> - PHY lane base address. See below for each PHY revision.
> -- reg-names: The names of register regions. The following regions are required:
> - For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY:
> - * "dsi_pll"
> - * "dsi_phy"
> - * "dsi_phy_regulator"
> - For DSI 14nm and 10nm PHYs:
> - * "dsi_pll"
> - * "dsi_phy"
> - * "dsi_phy_lane"
> -- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating
> - 2 clocks: A byte clock (index 0), and a pixel clock (index 1).
> -- power-domains: Should be <&mmcc MDSS_GDSC>.
> -- clocks: Phandles to device clocks. See [1] for details on clock bindings.
> -- clock-names: the following clocks are required:
> - * "iface"
> - * "ref" (only required for new DTS files/entries)
> - For 28nm HPM/LP, 28nm 8960 PHYs:
> -- vddio-supply: phandle to vdd-io regulator device node
> - For 20nm PHY:
> -- vddio-supply: phandle to vdd-io regulator device node
> -- vcca-supply: phandle to vcca regulator device node
> - For 14nm PHY:
> -- vcca-supply: phandle to vcca regulator device node
> - For 10nm PHY:
> -- vdds-supply: phandle to vdds regulator device node
> -
> -Optional properties:
> -- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
> - regulator is wanted.
> -- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode
> - panels in microseconds. Driver uses this number to adjust
> - the clock rate according to the expected transfer time.
> - Increasing this value would slow down the mdp processing
> - and can result in slower performance.
> - Decreasing this value can speed up the mdp processing,
> - but this can also impact power consumption.
> - As a rule this time should not be higher than the time
> - that would be expected with the processing at the
> - dsi link rate since anyways this would be the maximum
> - transfer time that could be achieved.
> - If ping pong split is enabled, this time should not be higher
> - than two times the dsi link rate time.
> - If the property is not specified, then the default value is 14000 us.
> -
> -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> -[2] Documentation/devicetree/bindings/graph.txt
> -[3] Documentation/devicetree/bindings/media/video-interfaces.txt
> -[4] Documentation/devicetree/bindings/display/panel/
> -
> -Example:
> - dsi0: dsi@fd922800 {
> - compatible = "qcom,mdss-dsi-ctrl";
> - qcom,dsi-host-index = <0>;
> - interrupt-parent = <&mdp>;
> - interrupts = <4 0>;
> - reg-names = "dsi_ctrl";
> - reg = <0xfd922800 0x200>;
> - power-domains = <&mmcc MDSS_GDSC>;
> - clock-names =
> - "bus",
> - "byte",
> - "core",
> - "core_mmss",
> - "iface",
> - "mdp_core",
> - "pixel";
> - clocks =
> - <&mmcc MDSS_AXI_CLK>,
> - <&mmcc MDSS_BYTE0_CLK>,
> - <&mmcc MDSS_ESC0_CLK>,
> - <&mmcc MMSS_MISC_AHB_CLK>,
> - <&mmcc MDSS_AHB_CLK>,
> - <&mmcc MDSS_MDP_CLK>,
> - <&mmcc MDSS_PCLK0_CLK>;
> -
> - assigned-clocks =
> - <&mmcc BYTE0_CLK_SRC>,
> - <&mmcc PCLK0_CLK_SRC>;
> - assigned-clock-parents =
> - <&dsi_phy0 0>,
> - <&dsi_phy0 1>;
> -
> - vdda-supply = <&pma8084_l2>;
> - vdd-supply = <&pma8084_l22>;
> - vddio-supply = <&pma8084_l12>;
> -
> - phys = <&dsi_phy0>;
> - phy-names ="dsi-phy";
> -
> - qcom,dual-dsi-mode;
> - qcom,master-dsi;
> - qcom,sync-dual-dsi;
> -
> - qcom,mdss-mdp-transfer-time-us = <12000>;
> -
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <&dsi_active>;
> - pinctrl-1 = <&dsi_suspend>;
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - dsi0_in: endpoint {
> - remote-endpoint = <&mdp_intf1_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - dsi0_out: endpoint {
> - remote-endpoint = <&panel_in>;
> - data-lanes = <0 1 2 3>;
> - };
> - };
> - };
> -
> - panel: panel@0 {
> - compatible = "sharp,lq101r1sx01";
> - reg = <0>;
> - link2 = <&secondary>;
> -
> - power-supply = <...>;
> - backlight = <...>;
> -
> - port {
> - panel_in: endpoint {
> - remote-endpoint = <&dsi0_out>;
> - };
> - };
> - };
> - };
> -
> - dsi_phy0: dsi-phy@fd922a00 {
> - compatible = "qcom,dsi-phy-28nm-hpm";
> - qcom,dsi-phy-index = <0>;
> - reg-names =
> - "dsi_pll",
> - "dsi_phy",
> - "dsi_phy_regulator";
> - reg = <0xfd922a00 0xd4>,
> - <0xfd922b00 0x2b0>,
> - <0xfd922d80 0x7b>;
> - clock-names = "iface";
> - clocks = <&mmcc MDSS_AHB_CLK>;
> - #clock-cells = <1>;
> - vddio-supply = <&pma8084_l12>;
> -
> - qcom,dsi-phy-regulator-ldo-mode;
> - };
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v10 06/20] dt-bindings: mtd: Document nand-ecc-engine
From: Rob Herring @ 2020-06-03 22:16 UTC (permalink / raw)
To: Miquel Raynal
Cc: Boris Brezillon, Tudor Ambarus, Thomas Petazzoni, linux-mtd,
Vignesh Raghavendra, Mason Yang, linux-arm-kernel,
Richard Weinberger, Julien Su, Mark Rutland, devicetree,
Rob Herring
In-Reply-To: <20200603175759.19948-7-miquel.raynal@bootlin.com>
On Wed, 03 Jun 2020 19:57:45 +0200, Miquel Raynal wrote:
> This property is needed to precisely point to the hardware ECC engine
> to use when there are several of them available. Here, hardware also
> refers to the on-die possibility.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> .../devicetree/bindings/mtd/nand-controller.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
Documentation/devicetree/bindings/mtd/nand-controller.yaml: while scanning for the next token
found character that cannot start any token
in "<unicode string>", line 62, column 1
Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/mtd/nand-controller.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/mtd/nand-controller.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/nand-controller.yaml: ignoring, error parsing file
warning: no schema found in file: ./Documentation/devicetree/bindings/mtd/nand-controller.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/mtd/nand-controller.yaml: ignoring, error parsing file
warning: no schema found in file: ./Documentation/devicetree/bindings/mtd/nand-controller.yaml
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1303116
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH v13 3/7] dt-bindings: clock: Add documentation for X1830 bindings.
From: Rob Herring @ 2020-06-03 21:58 UTC (permalink / raw)
To: Stephen Boyd
Cc: Zhou Yanjie, Michael Turquette, aric.pzqi, rick.tyliu, yanfei.li,
zhenwenjin, sernia.zhou, Paul Cercueil, dongsheng.qiu, devicetree,
linux-clk, linux-kernel@vger.kernel.org
In-Reply-To: <159078668338.69627.5841582436445900180@swboyd.mtv.corp.google.com>
On Fri, May 29, 2020 at 3:11 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Rob Herring (2020-05-29 12:14:31)
> >
> > Acked-by: Rob Herring <robh@kernel.org>
>
> Please apply to bindings tree Rob. The yaml conversion is in your tree.
Done.
Rob
^ permalink raw reply
* Re: [PATCH 22/28] dt-bindings: i2c: Convert i2c-pxa to json-schema
From: Wolfram Sang @ 2020-06-03 20:41 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Rob Herring, Linus Walleij, Bartosz Golaszewski, Thomas Gleixner,
Jason Cooper, Marc Zyngier, Mauro Carvalho Chehab, Ulf Hansson,
Kishon Vijay Abraham I, Alessandro Zummo, Alexandre Belloni,
Greg Kroah-Hartman, Mark Brown, Daniel Lezcano, Andrew Lunn,
Gregory Clement, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
devicetree, linux-kernel, linux-gpio, linux-i2c, linux-media,
linux-mmc, linux-rtc, linux-serial, linux-spi, linux-usb
In-Reply-To: <20200317093922.20785-23-lkundrak@v3.sk>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On Tue, Mar 17, 2020 at 10:39:16AM +0100, Lubomir Rintel wrote:
> A conversion of the i2c-pxa binding to DT schema format using json-schema.
>
> This also cleans ups some errors in the binding: The compatible string
> description suggested that "mmp" in "mrvl,mmp-twsi" is to be substituted
> with a processor model, which wouldn't be a right thing to do and indeed
> nobody seems to have been doing that. There also was "Recommended
> properties" section that included optional as well as mandatory
> properties. Missing mandatory properties were added to the example.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Waiting for an ack from someone with DT-YAML experience here.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v14 0/3] i2c: npcm7xx: add NPCM i2c controller driver
From: Wolfram Sang @ 2020-06-03 20:25 UTC (permalink / raw)
To: Tali Perry
Cc: ofery, brendanhiggins, avifishman70, tmaimon77, kfting, venture,
yuenn, benjaminfair, robh+dt, andriy.shevchenko, linux-arm-kernel,
linux-i2c, openbmc, devicetree, linux-kernel, kbuild test robot
In-Reply-To: <20200527200820.47359-1-tali.perry1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 876 bytes --]
On Wed, May 27, 2020 at 11:08:17PM +0300, Tali Perry wrote:
> This patch set adds i2c controller support
> for the Nuvoton NPCM Baseboard Management Controller (BMC).
>
> NPCM7xx includes 16 I2C controllers. This driver operates the controller.
> This module also includes a slave mode.
>
> ---
> v14 -> v13:
> - Fix yaml example: add missing include.
> - Replace all udelay to usleep_range, except one which is called from
> irq.
> - Fix compilation error (module_platfrom_init conflict).
> - debugfs counters always updated. Counting till max value,
> then stop counting.
> - Rename bus-frequency to clock-frequency.
> - Remove unused variables.
I don't have time for a deeper review, but from what I can tell this
driver is good to go and we can fix things incrementally from now on.
Applied to for-next (will go into 5.8), thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [RFC 4/4] regulator: lp87565: add LP87524-Q1 variant
From: Luca Ceresoli @ 2020-06-03 20:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Luca Ceresoli, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200603200319.16184-1-luca@lucaceresoli.net>
Add support for the LP87524B/J/P-Q1 Four 4-MHz Buck Converter. This is a
variant of the LP87565 having 4 single-phase outputs and up to 10 A of
total output current.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
drivers/mfd/lp87565.c | 4 ++++
include/linux/mfd/lp87565.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/mfd/lp87565.c b/drivers/mfd/lp87565.c
index 4a5c8ade4ae0..cc1072927f6d 100644
--- a/drivers/mfd/lp87565.c
+++ b/drivers/mfd/lp87565.c
@@ -26,6 +26,10 @@ static const struct mfd_cell lp87565_cells[] = {
static const struct of_device_id of_lp87565_match_table[] = {
{ .compatible = "ti,lp87565", },
+ {
+ .compatible = "ti,lp87524-q1",
+ .data = (void *)LP87565_DEVICE_TYPE_LP87524_Q1,
+ },
{
.compatible = "ti,lp87565-q1",
.data = (void *)LP87565_DEVICE_TYPE_LP87565_Q1,
diff --git a/include/linux/mfd/lp87565.h b/include/linux/mfd/lp87565.h
index ce965354bbad..ad240f2d0d3f 100644
--- a/include/linux/mfd/lp87565.h
+++ b/include/linux/mfd/lp87565.h
@@ -14,6 +14,7 @@
enum lp87565_device_type {
LP87565_DEVICE_TYPE_UNKNOWN = 0,
+ LP87565_DEVICE_TYPE_LP87524_Q1,
LP87565_DEVICE_TYPE_LP87561_Q1,
LP87565_DEVICE_TYPE_LP87565_Q1,
};
--
2.27.0
^ permalink raw reply related
* [RFC 0/4] regulator: lp87565: ignore ENx pins and add LP87524-Q1
From: Luca Ceresoli @ 2020-06-03 20:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Luca Ceresoli, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
Hi,
the first patch in this series is a small but significant variation in how
the lp87565 driver enables the output rails, allow the kernel to always
know when it is enabling an output. However it can change existing
behaviour (depending on the hardware setup) and thus it should be carefully
evaluated.
The following patches are a fairly straightforward addition of a new chip
variant along with some DT bindings cleanup.
Luca
Luca Ceresoli (4):
regulator: lp87565: enable voltage regardless of ENx pin
regulator: lp87565: dt: remove duplicated section
regulator: lp87565: dt: add LP87524-Q1 variant
regulator: lp87565: add LP87524-Q1 variant
.../devicetree/bindings/mfd/lp87565.txt | 66 ++++++++++++++-----
drivers/mfd/lp87565.c | 4 ++
drivers/regulator/lp87565-regulator.c | 21 +++++-
include/linux/mfd/lp87565.h | 1 +
4 files changed, 73 insertions(+), 19 deletions(-)
--
2.27.0
^ permalink raw reply
* [RFC 3/4] regulator: lp87565: dt: add LP87524-Q1 variant
From: Luca Ceresoli @ 2020-06-03 20:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Luca Ceresoli, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200603200319.16184-1-luca@lucaceresoli.net>
Add the LP87524-Q1 to the lp87565 bindings document along with an example.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
.../devicetree/bindings/mfd/lp87565.txt | 47 ++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt b/Documentation/devicetree/bindings/mfd/lp87565.txt
index b75ae23a1ef3..839eac6b75c2 100644
--- a/Documentation/devicetree/bindings/mfd/lp87565.txt
+++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
@@ -1,7 +1,8 @@
TI LP87565 PMIC MFD driver
Required properties:
- - compatible: one of "ti,lp87565", "ti,lp87565-q1", "ti,lp87561-q1"
+ - compatible: one of "ti,lp87565", "ti,lp87565-q1", "ti,lp87561-q1",
+ "ti,lp87524-q1"
- reg: I2C slave address.
- gpio-controller: Marks the device node as a GPIO Controller.
- #gpio-cells: Should be two. The first cell is the pin number and
@@ -64,3 +65,47 @@ lp87561_pmic: pmic@62 {
};
};
};
+
+Example for the TI LP87524-Q1 PMIC (four 1-phase output configuration):
+
+lp87524_pmic: pmic@60 {
+ compatible = "ti,lp87524-q1";
+ reg = <0x60>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ buck0-in-supply = <&vdd_5v0>;
+ buck1-in-supply = <&vdd_5v0>;
+ buck2-in-supply = <&vdd_5v0>;
+ buck3-in-supply = <&vdd_5v0>;
+
+ regulators {
+ buck0_reg: buck0 {
+ regulator-name = "buck0";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ buck1_reg: buck1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ };
+
+ buck2_reg: buck2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+ regulator-always-on;
+ };
+
+ buck3_reg: buck3 {
+ regulator-name = "buck3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+ };
+};
--
2.27.0
^ permalink raw reply related
* [RFC 1/4] regulator: lp87565: enable voltage regardless of ENx pin
From: Luca Ceresoli @ 2020-06-03 20:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Luca Ceresoli, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200603200319.16184-1-luca@lucaceresoli.net>
This driver enables outputs by setting bit EN_BUCKn in the BUCKn_CTRL1
register. However, if bit EN_PIN_CTRLn in the same register is set, the
output is actually enabled only if EN_BUCKn is set AND an enable pin is
active. Since the driver does not touch EN_PIN_CTRLn, the choice is left to
the hardware, which in turn gets this bit from OTP memory, and in absence
of OTP data it uses a default value that is documented in the datasheet for
LP8752x, but not for LP8756x.
Thus the driver doesn't really "know" whether it is actually enabling the
output or not.
In order to make sure activation is always driver-controlled, just clear
the EN_PIN_CTRLn bit. Now all activation solely depend on the EN_BUCKn bit.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
This is an RFC because there is a potential regression on existing
hardware. If there are boards where the enable pins _are_ used to toggle
power on/off in addition to I2C control, then this patch would make these
board ignore the enable pin as if it were always active.
Whether setups with ENx pins are used or not is hard to say. A Linux system
that needs to set a register _and_ to move a GPIO in order to enable a
regulatore output seems to me a bit weird, but there might be sound use
cases that I ignore.
I suspect the only solution that allows to configure the EN_PIN_CTRLn bits
correctly in all the possible hardware setups would be to tell in device
tree / board info whether each enable pin is connected or not (which is a
hardware _fact_) and which ENx pin should control which regulator output
(which is a policy). But it would make this simple driver considerably more
complex.
Any suggestion about the correct way to handle this situation would be
greatly appreciated.
---
drivers/regulator/lp87565-regulator.c | 21 +++++++++++++++++++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/regulator/lp87565-regulator.c b/drivers/regulator/lp87565-regulator.c
index 5d525dacf959..fbed6bc80c1a 100644
--- a/drivers/regulator/lp87565-regulator.c
+++ b/drivers/regulator/lp87565-regulator.c
@@ -11,8 +11,8 @@
#include <linux/mfd/lp87565.h>
-#define LP87565_REGULATOR(_name, _id, _of, _ops, _n, _vr, _vm, _er, _em, \
- _delay, _lr, _cr) \
+#define LP87565_REGULATOR(_name, _id, _of, _ops, _n, _vr, _vm, \
+ _er, _em, _ev, _delay, _lr, _cr) \
[_id] = { \
.desc = { \
.name = _name, \
@@ -28,6 +28,7 @@
.vsel_mask = _vm, \
.enable_reg = _er, \
.enable_mask = _em, \
+ .enable_val = _ev, \
.ramp_delay = _delay, \
.linear_ranges = _lr, \
.n_linear_ranges = ARRAY_SIZE(_lr), \
@@ -121,38 +122,54 @@ static const struct lp87565_regulator regulators[] = {
LP87565_REGULATOR("BUCK0", LP87565_BUCK_0, "buck0", lp87565_buck_ops,
256, LP87565_REG_BUCK0_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK0_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
LP87565_REGULATOR("BUCK1", LP87565_BUCK_1, "buck1", lp87565_buck_ops,
256, LP87565_REG_BUCK1_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK1_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK1_CTRL_2),
LP87565_REGULATOR("BUCK2", LP87565_BUCK_2, "buck2", lp87565_buck_ops,
256, LP87565_REG_BUCK2_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK2_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
LP87565_REGULATOR("BUCK3", LP87565_BUCK_3, "buck3", lp87565_buck_ops,
256, LP87565_REG_BUCK3_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK3_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK3_CTRL_2),
LP87565_REGULATOR("BUCK10", LP87565_BUCK_10, "buck10", lp87565_buck_ops,
256, LP87565_REG_BUCK0_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK0_CTRL_1,
LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL |
+ LP87565_BUCK_CTRL_1_FPWM_MP_0_2,
+ LP87565_BUCK_CTRL_1_EN |
LP87565_BUCK_CTRL_1_FPWM_MP_0_2, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
LP87565_REGULATOR("BUCK23", LP87565_BUCK_23, "buck23", lp87565_buck_ops,
256, LP87565_REG_BUCK2_VOUT, LP87565_BUCK_VSET,
LP87565_REG_BUCK2_CTRL_1,
+ LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL,
LP87565_BUCK_CTRL_1_EN, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK2_CTRL_2),
LP87565_REGULATOR("BUCK3210", LP87565_BUCK_3210, "buck3210",
lp87565_buck_ops, 256, LP87565_REG_BUCK0_VOUT,
LP87565_BUCK_VSET, LP87565_REG_BUCK0_CTRL_1,
LP87565_BUCK_CTRL_1_EN |
+ LP87565_BUCK_CTRL_1_EN_PIN_CTRL |
+ LP87565_BUCK_CTRL_1_FPWM_MP_0_2,
+ LP87565_BUCK_CTRL_1_EN |
LP87565_BUCK_CTRL_1_FPWM_MP_0_2, 3230,
buck0_1_2_3_ranges, LP87565_REG_BUCK0_CTRL_2),
};
--
2.27.0
^ permalink raw reply related
* [RFC 2/4] regulator: lp87565: dt: remove duplicated section
From: Luca Ceresoli @ 2020-06-03 20:03 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Luca Ceresoli, devicetree, linux-kernel, Lee Jones, Rob Herring,
Keerthy, Axel Lin
In-Reply-To: <20200603200319.16184-1-luca@lucaceresoli.net>
The "Required properties:" section is copied verbatim for each of the two
supported chips. In preparation to add a new chip variant make it a common
section and keep the two examples to differentiate between the two chips.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
.../devicetree/bindings/mfd/lp87565.txt | 21 ++++---------------
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/lp87565.txt b/Documentation/devicetree/bindings/mfd/lp87565.txt
index 41671e0dc26b..b75ae23a1ef3 100644
--- a/Documentation/devicetree/bindings/mfd/lp87565.txt
+++ b/Documentation/devicetree/bindings/mfd/lp87565.txt
@@ -1,7 +1,7 @@
TI LP87565 PMIC MFD driver
Required properties:
- - compatible: "ti,lp87565", "ti,lp87565-q1"
+ - compatible: one of "ti,lp87565", "ti,lp87565-q1", "ti,lp87561-q1"
- reg: I2C slave address.
- gpio-controller: Marks the device node as a GPIO Controller.
- #gpio-cells: Should be two. The first cell is the pin number and
@@ -10,7 +10,8 @@ Required properties:
- xxx-in-supply: Phandle to parent supply node of each regulator
populated under regulators node. xxx should match
the supply_name populated in driver.
-Example:
+
+Example for the TI LP87565-Q1 PMIC (dual 2-phase output configuration):
lp87565_pmic: pmic@60 {
compatible = "ti,lp87565-q1";
@@ -42,21 +43,7 @@ lp87565_pmic: pmic@60 {
};
};
-TI LP87561 PMIC:
-
-This is a single output 4-phase regulator configuration
-
-Required properties:
- - compatible: "ti,lp87561-q1"
- - reg: I2C slave address.
- - gpio-controller: Marks the device node as a GPIO Controller.
- - #gpio-cells: Should be two. The first cell is the pin number and
- the second cell is used to specify flags.
- See ../gpio/gpio.txt for more information.
- - xxx-in-supply: Phandle to parent supply node of each regulator
- populated under regulators node. xxx should match
- the supply_name populated in driver.
-Example:
+Example for the TI LP87561 PMIC (single 4-phase output configuration):
lp87561_pmic: pmic@62 {
compatible = "ti,lp87561-q1";
--
2.27.0
^ permalink raw reply related
* Re: [PATCH 2/2] drm/panel: simple: Add support for KOE TX26D202VM0BWA panel
From: Sam Ravnborg @ 2020-06-03 19:54 UTC (permalink / raw)
To: Emil Velikov
Cc: Liu Ying, devicetree, Thierry Reding, NXP Linux Team,
ML dri-devel
In-Reply-To: <CACvgo52fdrjp_-Q-mB1AYtNuKcQ722mvTOFsjWaXc139rjD58Q@mail.gmail.com>
Hi Emil.
> >
> > I expect to have some hours for linux work friday or saturday, but no
> > promises...
> >
> Don't worry - once the DT maintainers ack 1/2, I'll merge the series.
If it is in alphabetical order then we are good to go.
For such simple patches we do not need DT maintainer ack.
You can add my: r-b then you are fully covered.
Sam
>
> -Emil
^ permalink raw reply
* Re: [PATCH v8 0/5] support reserving crashkernel above 4G on arm64 kdump
From: Bhupesh Sharma @ 2020-06-03 19:47 UTC (permalink / raw)
To: John Donnelly
Cc: chenzhou, Simon Horman, Devicetree List, Arnd Bergmann,
Baoquan He, Linux Doc Mailing List, Catalin Marinas, guohanjun,
kexec mailing list, Linux Kernel Mailing List, Will Deacon,
Rob Herring, James Morse, nsaenzjulienne, Prabhakar Kushwaha,
Thomas Gleixner, Prabhakar Kushwaha, RuiRui Yang, Ingo Molnar,
linux-arm-kernel
In-Reply-To: <8E0D45DC-12BF-437D-A342-03E974D9C6D4@oracle.com>
Hi All,
On Wed, Jun 3, 2020 at 9:03 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
>
>
>
> > On Jun 3, 2020, at 8:20 AM, chenzhou <chenzhou10@huawei.com> wrote:
> >
> > Hi,
> >
> >
> > On 2020/6/3 19:47, Prabhakar Kushwaha wrote:
> >> Hi Chen,
> >>
> >> On Tue, Jun 2, 2020 at 8:12 PM John Donnelly <john.p.donnelly@oracle.com> wrote:
> >>>
> >>>
> >>>> On Jun 2, 2020, at 12:38 AM, Prabhakar Kushwaha <prabhakar.pkin@gmail.com> wrote:
> >>>>
> >>>> On Tue, Jun 2, 2020 at 3:29 AM John Donnelly <john.p.donnelly@oracle.com> wrote:
> >>>>> Hi . See below !
> >>>>>
> >>>>>> On Jun 1, 2020, at 4:02 PM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> >>>>>>
> >>>>>> Hi John,
> >>>>>>
> >>>>>> On Tue, Jun 2, 2020 at 1:01 AM John Donnelly <John.P.donnelly@oracle.com> wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>>
> >>>>>>> On 6/1/20 7:02 AM, Prabhakar Kushwaha wrote:
> >>>>>>>> Hi Chen,
> >>>>>>>>
> >>>>>>>> On Thu, May 21, 2020 at 3:05 PM Chen Zhou <chenzhou10@huawei.com> wrote:
> >>>>>>>>> This patch series enable reserving crashkernel above 4G in arm64.
> >>>>>>>>>
> >>>>>>>>> There are following issues in arm64 kdump:
> >>>>>>>>> 1. We use crashkernel=X to reserve crashkernel below 4G, which will fail
> >>>>>>>>> when there is no enough low memory.
> >>>>>>>>> 2. Currently, crashkernel=Y@X can be used to reserve crashkernel above 4G,
> >>>>>>>>> in this case, if swiotlb or DMA buffers are required, crash dump kernel
> >>>>>>>>> will boot failure because there is no low memory available for allocation.
> >>>>>>>>>
> >>>>>>>> We are getting "warn_alloc" [1] warning during boot of kdump kernel
> >>>>>>>> with bootargs as [2] of primary kernel.
> >>>>>>>> This error observed on ThunderX2 ARM64 platform.
> >>>>>>>>
> >>>>>>>> It is observed with latest upstream tag (v5.7-rc3) with this patch set
> >>>>>>>> and https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbiIAAlzu$
> >>>>>>>> Also **without** this patch-set
> >>>>>>>> "https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$"
> >>>>>>>>
> >>>>>>>> This issue comes whenever crashkernel memory is reserved after 0xc000_0000.
> >>>>>>>> More details discussed earlier in
> >>>>>>>> https://urldefense.com/v3/__https://www.spinics.net/lists/arm-kernel/msg806882.html__;!!GqivPVa7Brio!LnTSARkCt0V0FozR0KmqooaH5ADtdXvs3mPdP3KRVqALmvSK2VmCkIPIhsaxbjC6ujMA$ without any
> >>>>>>>> solution
> >>>>>>>>
> >>>>>>>> This patch-set is expected to solve similar kind of issue.
> >>>>>>>> i.e. low memory is only targeted for DMA, swiotlb; So above mentioned
> >>>>>>>> observation should be considered/fixed. .
> >>>>>>>>
> >>>>>>>> --pk
> >>>>>>>>
> >>>>>>>> [1]
> >>>>>>>> [ 30.366695] DMI: Cavium Inc. Saber/Saber, BIOS
> >>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>>>>>>> [ 30.367696] NET: Registered protocol family 16
> >>>>>>>> [ 30.369973] swapper/0: page allocation failure: order:6,
> >>>>>>>> mode:0x1(GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
> >>>>>>>> [ 30.369980] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc3+ #121
> >>>>>>>> [ 30.369981] Hardware name: Cavium Inc. Saber/Saber, BIOS
> >>>>>>>> TX2-FW-Release-3.1-build_01-2803-g74253a541a mm/dd/yyyy
> >>>>>>>> [ 30.369984] Call trace:
> >>>>>>>> [ 30.369989] dump_backtrace+0x0/0x1f8
> >>>>>>>> [ 30.369991] show_stack+0x20/0x30
> >>>>>>>> [ 30.369997] dump_stack+0xc0/0x10c
> >>>>>>>> [ 30.370001] warn_alloc+0x10c/0x178
> >>>>>>>> [ 30.370004] __alloc_pages_slowpath.constprop.111+0xb10/0xb50
> >>>>>>>> [ 30.370006] __alloc_pages_nodemask+0x2b4/0x300
> >>>>>>>> [ 30.370008] alloc_page_interleave+0x24/0x98
> >>>>>>>> [ 30.370011] alloc_pages_current+0xe4/0x108
> >>>>>>>> [ 30.370017] dma_atomic_pool_init+0x44/0x1a4
> >>>>>>>> [ 30.370020] do_one_initcall+0x54/0x228
> >>>>>>>> [ 30.370027] kernel_init_freeable+0x228/0x2cc
> >>>>>>>> [ 30.370031] kernel_init+0x1c/0x110
> >>>>>>>> [ 30.370034] ret_from_fork+0x10/0x18
> >>>>>>>> [ 30.370036] Mem-Info:
> >>>>>>>> [ 30.370064] active_anon:0 inactive_anon:0 isolated_anon:0
> >>>>>>>> [ 30.370064] active_file:0 inactive_file:0 isolated_file:0
> >>>>>>>> [ 30.370064] unevictable:0 dirty:0 writeback:0 unstable:0
> >>>>>>>> [ 30.370064] slab_reclaimable:34 slab_unreclaimable:4438
> >>>>>>>> [ 30.370064] mapped:0 shmem:0 pagetables:14 bounce:0
> >>>>>>>> [ 30.370064] free:1537719 free_pcp:219 free_cma:0
> >>>>>>>> [ 30.370070] Node 0 active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>>>>>>> unstable:0kB all_unreclaimable? no
> >>>>>>>> [ 30.370073] Node 1 active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
> >>>>>>>> isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB
> >>>>>>>> shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB
> >>>>>>>> unstable:0kB all_unreclaimable? no
> >>>>>>>> [ 30.370079] Node 0 DMA free:0kB min:0kB low:0kB high:0kB
> >>>>>>>> reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>>>>> present:128kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB
> >>>>>>>> bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>>>>>>> [ 30.370084] lowmem_reserve[]: 0 250 6063 6063
> >>>>>>>> [ 30.370090] Node 0 DMA32 free:256000kB min:408kB low:664kB
> >>>>>>>> high:920kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>>>>> present:269700kB managed:256000kB mlocked:0kB kernel_stack:0kB
> >>>>>>>> pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
> >>>>>>>> [ 30.370094] lowmem_reserve[]: 0 0 5813 5813
> >>>>>>>> [ 30.370100] Node 0 Normal free:5894876kB min:9552kB low:15504kB
> >>>>>>>> high:21456kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
> >>>>>>>> active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB
> >>>>>>>> present:8388608kB managed:5953112kB mlocked:0kB kernel_stack:21672kB
> >>>>>>>> pagetables:56kB bounce:0kB free_pcp:876kB local_pcp:176kB free_cma:0kB
> >>>>>>>> [ 30.370104] lowmem_reserve[]: 0 0 0 0
> >>>>>>>> [ 30.370107] Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>>>>>>> 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB
> >>>>>>>> [ 30.370113] Node 0 DMA32: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB
> >>>>>>>> 0*256kB 0*512kB 0*1024kB 1*2048kB (M) 62*4096kB (M) = 256000kB
> >>>>>>>> [ 30.370119] Node 0 Normal: 2*4kB (M) 3*8kB (ME) 2*16kB (UE) 3*32kB
> >>>>>>>> (UM) 1*64kB (U) 2*128kB (M) 2*256kB (ME) 3*512kB (ME) 3*1024kB (ME)
> >>>>>>>> 3*2048kB (UME) 1436*4096kB (M) = 5893600kB
> >>>>>>>> [ 30.370129] Node 0 hugepages_total=0 hugepages_free=0
> >>>>>>>> hugepages_surp=0 hugepages_size=1048576kB
> >>>>>>>> [ 30.370130] 0 total pagecache pages
> >>>>>>>> [ 30.370132] 0 pages in swap cache
> >>>>>>>> [ 30.370134] Swap cache stats: add 0, delete 0, find 0/0
> >>>>>>>> [ 30.370135] Free swap = 0kB
> >>>>>>>> [ 30.370136] Total swap = 0kB
> >>>>>>>> [ 30.370137] 2164609 pages RAM
> >>>>>>>> [ 30.370139] 0 pages HighMem/MovableOnly
> >>>>>>>> [ 30.370140] 612331 pages reserved
> >>>>>>>> [ 30.370141] 0 pages hwpoisoned
> >>>>>>>> [ 30.370143] DMA: failed to allocate 256 KiB pool for atomic
> >>>>>>>> coherent allocation
> >>>>>>>
> >>>>>>> During my testing I saw the same error and Chen's solution corrected it .
> >>>>>> Which combination you are using on your side? I am using Prabhakar's
> >>>>>> suggested environment and can reproduce the issue
> >>>>>> with or without Chen's crashkernel support above 4G patchset.
> >>>>>>
> >>>>>> I am also using a ThunderX2 platform with latest makedumpfile code and
> >>>>>> kexec-tools (with the suggested patch
> >>>>>> <https://urldefense.com/v3/__https://lists.infradead.org/pipermail/kexec/2020-May/025128.html__;!!GqivPVa7Brio!J6lUig58-Gw6TKZnEEYzEeSU36T-1SqlB1kImU00xtX_lss5Tx-JbUmLE9TJC3foXBLg$ >).
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Bhupesh
> >>>>>
> >>>>> I did this activity 5 months ago and I have moved on to other activities. My DMA failures were related to PCI devices that could not be enumerated because low-DMA space was not available when crashkernel was moved above 4G; I don’t recall the exact platform.
> >>>>>
> >>>>>
> >>>>>
> >>>>> For this failure ,
> >>>>>
> >>>>>>>> DMA: failed to allocate 256 KiB pool for atomic
> >>>>>>>> coherent allocation
> >>>>>
> >>>>> Is due to :
> >>>>>
> >>>>>
> >>>>> 3618082c
> >>>>> ("arm64 use both ZONE_DMA and ZONE_DMA32")
> >>>>>
> >>>>> With the introduction of ZONE_DMA to support the Raspberry DMA
> >>>>> region below 1G, the crashkernel is placed in the upper 4G
> >>>>> ZONE_DMA_32 region. Since the crashkernel does not have access
> >>>>> to the ZONE_DMA region, it prints out call trace during bootup.
> >>>>>
> >>>>> It is due to having this CONFIG item ON :
> >>>>>
> >>>>>
> >>>>> CONFIG_ZONE_DMA=y
> >>>>>
> >>>>> Turning off ZONE_DMA fixes a issue and Raspberry PI 4 will
> >>>>> use the device tree to specify memory below 1G.
> >>>>>
> >>>>>
> >>>> Disabling ZONE_DMA is temporary solution. We may need proper solution
> >>>
> >>> Perhaps the Raspberry platform configuration dependencies need separated from “server class” Arm equipment ? Or auto-configured on boot ? Consult an expert ;-)
> >>>
> >>>
> >>>
> >>>>> I would like to see Chen’s feature added , perhaps as EXPERIMENTAL, so we can get some configuration testing done on it. It corrects having a DMA zone in low memory while crash-kernel is above 4GB. This has been going on for a year now.
> >>>> I will also like this patch to be added in Linux as early as possible.
> >>>>
> >>>> Issue mentioned by me happens with or without this patch.
> >>>>
> >>>> This patch-set can consider fixing because it uses low memory for DMA
> >>>> & swiotlb only.
> >>>> We can consider restricting crashkernel within the required range like below
> >>>>
> >>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> >>>> index 7f9e5a6dc48c..bd67b90d35bd 100644
> >>>> --- a/kernel/crash_core.c
> >>>> +++ b/kernel/crash_core.c
> >>>> @@ -354,7 +354,7 @@ int __init reserve_crashkernel_low(void)
> >>>> return 0;
> >>>> }
> >>>>
> >>>> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> >>>> + low_base = memblock_find_in_range(0,0xc0000000, low_size, CRASH_ALIGN);
> >>>> if (!low_base) {
> >>>> pr_err("Cannot reserve %ldMB crashkernel low memory,
> >>>> please try smaller size.\n",
> >>>> (unsigned long)(low_size >> 20));
> >>>>
> >>>>
> >>> I suspect 0xc0000000 would need to be a CONFIG item and not hard-coded.
> >>>
> >> if you consider this as valid change, can you please incorporate as
> >> part of your patch-set.
> >
> > After commit 1a8e1cef7 ("arm64: use both ZONE_DMA and ZONE_DMA32")，the 0-4G memory is splited
> > to DMA [mem 0x0000000000000000-0x000000003fffffff] and DMA32 [mem 0x0000000040000000-0x00000000ffffffff] on arm64.
> >
> > From the above discussion, on your platform, the low crashkernel fall in DMA32 region, but your environment needs to access DMA
> > region, so there is the call trace.
> >
> > I have a question, why do you choose 0xc0000000 here?
> >
> > Besides, this is common code, we also need to consider about x86.
> >
>
> + nsaenzjulienne@suse.de
>
> Exactly . This is why it needs to be a CONFIG option for Raspberry .., or device tree option.
>
>
> We could revert 1a8e1cef7 since it broke Arm kdump too.
Well, unfortunately the patch for commit 1a8e1cef7603 ("arm64: use
both ZONE_DMA and ZONE_DMA32") was not Cc'ed to the kexec mailing
list, thus we couldn't get many eyes on it for a thorough review from
kexec/kdump p-o-v.
Also we historically never had distinction in common arch code on the
basis of the intended end use-case: embedded, server or automotive, so
I am not sure introducing a Raspberry specific CONFIG option would be
a good idea.
So, rather than reverting the patch, we can look at addressing the
same properly this time - especially from a kdump p-o-v.
This issue has been reported by some Red Hat arm64 partners with
upstream kernel also and as we have noticed in the past as well,
hardcoding the placement of the crashkernel base address (unless the
base address is specified by a crashkernel=X@Y like bootargs) is also
not a portable suggestion.
I am working on a possible fix and will have more updates on the same
in a day-or-two.
Thanks,
Bhupesh
^ permalink raw reply
* Re: [PATCH] arm: dts: vexpress: Move mcc node back into motherboard node
From: Guenter Roeck @ 2020-06-03 19:46 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Liviu Dudau, Sudeep Holla, Lorenzo Pieralisi,
devicetree, linux-arm-kernel
On Wed, Jun 03, 2020 at 05:22:37PM +0100, Andre Przywara wrote:
> Commit d9258898ad49 ("arm64: dts: arm: vexpress: Move fixed devices
> out of bus node") moved the "mcc" DT node into the root node, because
> it does not have any children using "reg" properties, so does violate
> some dtc checks about "simple-bus" nodes.
> However this broke the vexpress config-bus code, which walks up the
> device tree to find the first node with an "arm,vexpress,site" property.
> This gave the wrong result (matching the root node instead of the
> motherboard node), so broke the clocks and some other devices for
> VExpress boards.
>
> Move the whole node back into its original position. This re-introduces
> the dtc warning, but is conceptually the right thing to do. The dtc
> warning seems to be overzealous here, there are discussions on fixing or
> relaxing this check instead.
>
> Fixes: d9258898ad49 ("arm64: dts: arm: vexpress: Move fixed devices out of bus node")
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
> ---
> P.S. The broken commit has not reached mainline yet, but is already in
> arm-soc/arm/dt.
>
> arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 146 ++++++++++++------------
> 1 file changed, 73 insertions(+), 73 deletions(-)
>
> diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> index e6308fb76183..a88ee5294d35 100644
> --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi
> @@ -100,79 +100,6 @@
> };
> };
>
> - mcc {
> - compatible = "arm,vexpress,config-bus";
> - arm,vexpress,config-bridge = <&v2m_sysreg>;
> -
> - oscclk0 {
> - /* MCC static memory clock */
> - compatible = "arm,vexpress-osc";
> - arm,vexpress-sysreg,func = <1 0>;
> - freq-range = <25000000 60000000>;
> - #clock-cells = <0>;
> - clock-output-names = "v2m:oscclk0";
> - };
> -
> - v2m_oscclk1: oscclk1 {
> - /* CLCD clock */
> - compatible = "arm,vexpress-osc";
> - arm,vexpress-sysreg,func = <1 1>;
> - freq-range = <23750000 65000000>;
> - #clock-cells = <0>;
> - clock-output-names = "v2m:oscclk1";
> - };
> -
> - v2m_oscclk2: oscclk2 {
> - /* IO FPGA peripheral clock */
> - compatible = "arm,vexpress-osc";
> - arm,vexpress-sysreg,func = <1 2>;
> - freq-range = <24000000 24000000>;
> - #clock-cells = <0>;
> - clock-output-names = "v2m:oscclk2";
> - };
> -
> - volt-vio {
> - /* Logic level voltage */
> - compatible = "arm,vexpress-volt";
> - arm,vexpress-sysreg,func = <2 0>;
> - regulator-name = "VIO";
> - regulator-always-on;
> - label = "VIO";
> - };
> -
> - temp-mcc {
> - /* MCC internal operating temperature */
> - compatible = "arm,vexpress-temp";
> - arm,vexpress-sysreg,func = <4 0>;
> - label = "MCC";
> - };
> -
> - reset {
> - compatible = "arm,vexpress-reset";
> - arm,vexpress-sysreg,func = <5 0>;
> - };
> -
> - muxfpga {
> - compatible = "arm,vexpress-muxfpga";
> - arm,vexpress-sysreg,func = <7 0>;
> - };
> -
> - shutdown {
> - compatible = "arm,vexpress-shutdown";
> - arm,vexpress-sysreg,func = <8 0>;
> - };
> -
> - reboot {
> - compatible = "arm,vexpress-reboot";
> - arm,vexpress-sysreg,func = <9 0>;
> - };
> -
> - dvimode {
> - compatible = "arm,vexpress-dvimode";
> - arm,vexpress-sysreg,func = <11 0>;
> - };
> - };
> -
> bus@8000000 {
> motherboard-bus {
> model = "V2M-P1";
> @@ -435,6 +362,79 @@
> };
> };
> };
> +
> + mcc {
> + compatible = "arm,vexpress,config-bus";
> + arm,vexpress,config-bridge = <&v2m_sysreg>;
> +
> + oscclk0 {
> + /* MCC static memory clock */
> + compatible = "arm,vexpress-osc";
> + arm,vexpress-sysreg,func = <1 0>;
> + freq-range = <25000000 60000000>;
> + #clock-cells = <0>;
> + clock-output-names = "v2m:oscclk0";
> + };
> +
> + v2m_oscclk1: oscclk1 {
> + /* CLCD clock */
> + compatible = "arm,vexpress-osc";
> + arm,vexpress-sysreg,func = <1 1>;
> + freq-range = <23750000 65000000>;
> + #clock-cells = <0>;
> + clock-output-names = "v2m:oscclk1";
> + };
> +
> + v2m_oscclk2: oscclk2 {
> + /* IO FPGA peripheral clock */
> + compatible = "arm,vexpress-osc";
> + arm,vexpress-sysreg,func = <1 2>;
> + freq-range = <24000000 24000000>;
> + #clock-cells = <0>;
> + clock-output-names = "v2m:oscclk2";
> + };
> +
> + volt-vio {
> + /* Logic level voltage */
> + compatible = "arm,vexpress-volt";
> + arm,vexpress-sysreg,func = <2 0>;
> + regulator-name = "VIO";
> + regulator-always-on;
> + label = "VIO";
> + };
> +
> + temp-mcc {
> + /* MCC internal operating temperature */
> + compatible = "arm,vexpress-temp";
> + arm,vexpress-sysreg,func = <4 0>;
> + label = "MCC";
> + };
> +
> + reset {
> + compatible = "arm,vexpress-reset";
> + arm,vexpress-sysreg,func = <5 0>;
> + };
> +
> + muxfpga {
> + compatible = "arm,vexpress-muxfpga";
> + arm,vexpress-sysreg,func = <7 0>;
> + };
> +
> + shutdown {
> + compatible = "arm,vexpress-shutdown";
> + arm,vexpress-sysreg,func = <8 0>;
> + };
> +
> + reboot {
> + compatible = "arm,vexpress-reboot";
> + arm,vexpress-sysreg,func = <9 0>;
> + };
> +
> + dvimode {
> + compatible = "arm,vexpress-dvimode";
> + arm,vexpress-sysreg,func = <11 0>;
> + };
> + };
> };
> };
> };
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v3 00/13] PCI: brcmstb: enable PCIe for STB chips
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Alan Stern, Andy Shevchenko, Arnd Bergmann, Corey Minyard,
Dan Williams, open list:STAGING SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
open list:DRM DRIVERS FOR ALLWINNER A10, Florian Fainelli,
Greg Kroah-Hartman, Hans de Goede, H. Peter Anvin,
open list:IOMMU DRIVERS, Jens Axboe, Joerg Roedel, Julien Grall,
open list:ACPI FOR ARM64 (ACPI/arm64), moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list, open list:ALLWINNER A10 CSI DRIVER,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:SUPERH, open list:USB SUBSYSTEM, Mark Brown,
Oliver Neukum, Rafael J. Wysocki, Rob Herring, Robin Murphy,
Saravana Kannan, Srinivas Kandagatla, Stefano Stabellini,
Suzuki K Poulose, Ulf Hansson
v3:
Commit "device core: Introduce multiple dma pfn offsets"
Commit "arm: dma-mapping: Invoke dma offset func if needed"
-- The above two commits have been squashed. More importantly,
the code has been modified so that the functionality for
multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
In fact, dma_pfn_offset is removed and supplanted by
dma_pfn_offset_map, which is a pointer to an array. The
more common case of a uniform offset is now handled as
a map with a single entry, while cases requiring multiple
pfn offsets use a map with multiple entries. Code paths
that used to do this:
dev->dma_pfn_offset = mydrivers_pfn_offset;
have been changed to do this:
attach_uniform_dma_pfn_offset(dev, pfn_offset);
Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
-- Add if/then clause for required props: resets, reset-names (RobH)
-- Change compatible list from const to enum (RobH)
-- Change list of u32-tuples to u64 (RobH)
Commit "of: Include a dev param in of_dma_get_range()"
-- modify of/unittests.c to add NULL param in of_dma_get_range() call.
Commit "device core: Add ability to handle multiple dma offsets"
-- align comment in device.h (AndyS).
-- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
dma_pfn_offset_region (AndyS).
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
Jim Quinlan (13):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ata: ahci_brcm: Fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add bcm7278 reigister info
PCI: brcmstb: Add suspend and resume pm_ops
PCI: brcmstb: Add bcm7278 PERST support
PCI: brcmstb: Add control of rescal reset
of: Include a dev param in of_dma_get_range()
device core: Introduce multiple dma pfn offsets
PCI: brcmstb: Set internal memory viewport sizes
PCI: brcmstb: Accommodate MSI for older chips
PCI: brcmstb: Set bus max burst size by chip type
PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
.../bindings/pci/brcm,stb-pcie.yaml | 58 ++-
arch/arm/include/asm/dma-mapping.h | 9 +-
arch/arm/mach-keystone/keystone.c | 9 +-
arch/sh/drivers/pci/pcie-sh7786.c | 3 +-
arch/sh/kernel/dma-coherent.c | 17 +-
arch/x86/pci/sta2x11-fixup.c | 7 +-
drivers/acpi/arm64/iort.c | 5 +-
drivers/ata/ahci_brcm.c | 14 +-
drivers/gpu/drm/sun4i/sun4i_backend.c | 7 +-
drivers/iommu/io-pgtable-arm.c | 2 +-
.../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +-
.../platform/sunxi/sun6i-csi/sun6i_csi.c | 5 +-
drivers/of/address.c | 97 ++++-
drivers/of/device.c | 10 +-
drivers/of/of_private.h | 8 +-
drivers/of/unittest.c | 2 +-
drivers/pci/controller/Kconfig | 3 +-
drivers/pci/controller/pcie-brcmstb.c | 408 +++++++++++++++---
drivers/remoteproc/remoteproc_core.c | 2 +-
.../staging/media/sunxi/cedrus/cedrus_hw.c | 7 +-
drivers/usb/core/message.c | 4 +-
drivers/usb/core/usb.c | 2 +-
include/linux/device.h | 4 +-
include/linux/dma-direct.h | 16 +-
include/linux/dma-mapping.h | 45 ++
kernel/dma/coherent.c | 11 +-
26 files changed, 631 insertions(+), 129 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v3 03/13] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Florian Fainelli, Bjorn Helgaas, Rob Herring,
moderated list:BROADCOM BCM7XXX ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
From: Jim Quinlan <jquinlan@broadcom.com>
- Add compatible strings for three more Broadcom STB chips: 7278, 7216,
7211 (STB version of RPi4).
- add new property 'brcm,scb-sizes'
- add new property 'resets'
- add new property 'reset-names' for 7216 only
- allow 'ranges' and 'dma-ranges' to have more than one item and update
the example to show this.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
.../bindings/pci/brcm,stb-pcie.yaml | 58 ++++++++++++++++---
1 file changed, 51 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 8680a0f86c5a..4a012d77513f 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -9,12 +9,15 @@ title: Brcmstb PCIe Host Controller Device Tree Bindings
maintainers:
- Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
-allOf:
- - $ref: /schemas/pci/pci-bus.yaml#
-
properties:
compatible:
- const: brcm,bcm2711-pcie # The Raspberry Pi 4
+ items:
+ - enum:
+ - brcm,bcm2711-pcie # The Raspberry Pi 4
+ - brcm,bcm7211-pcie # Broadcom STB version of RPi4
+ - brcm,bcm7278-pcie # Broadcom 7278 Arm
+ - brcm,bcm7216-pcie # Broadcom 7216 Arm
+ - brcm,bcm7445-pcie # Broadcom 7445 Arm
reg:
maxItems: 1
@@ -34,10 +37,12 @@ properties:
- const: msi
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
dma-ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 6
clocks:
maxItems: 1
@@ -58,8 +63,33 @@ properties:
aspm-no-l0s: true
+ resets:
+ description: for "brcm,bcm7216-pcie", must be a valid reset
+ phandle pointing to the RESCAL reset controller provider node.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ reset-names:
+ items:
+ - const: rescal
+
+ brcm,scb-sizes:
+ description: u64 giving the 64bit PCIe memory
+ viewport size of a memory controller. There may be up to
+ three controllers, and each size must be a power of two
+ with a size greater or equal to the amount of memory the
+ controller supports. Note that each memory controller
+ may have two component regions -- base and extended -- so
+ this information cannot be deduced from the dma-ranges.
+
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint64-array
+ - items:
+ minItems: 1
+ maxItems: 3
+
required:
- reg
+ - ranges
- dma-ranges
- "#interrupt-cells"
- interrupts
@@ -68,6 +98,18 @@ required:
- interrupt-map
- msi-controller
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm7216-pcie
+ then:
+ required:
+ - resets
+ - reset-names
+
unevaluatedProperties: false
examples:
@@ -93,7 +135,9 @@ examples:
msi-parent = <&pcie0>;
msi-controller;
ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
- dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
+ dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
+ <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
brcm,enable-ssc;
+ brcm,scb-sizes = <0x0000000080000000 0x0000000080000000>;
};
};
--
2.17.1
^ permalink raw reply related
* [PATCH v3 08/13] of: Include a dev param in of_dma_get_range()
From: Jim Quinlan @ 2020-06-03 19:20 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
In-Reply-To: <20200603192058.35296-1-james.quinlan@broadcom.com>
Currently there is only one caller of of_dma_get_range(). A struct device
*dev param is needed For implementing multiple dma offsets. This function
will still work if dev == NULL.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 4 +++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 ++++----
drivers/of/unittest.c | 2 +-
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..96d8cfb14a60 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -920,6 +920,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
/**
* of_dma_get_range - Get DMA range info
+ * @dev: device pointer; only needed for a corner case.
* @np: device node to get DMA range info
* @dma_addr: pointer to store initial DMA address of DMA range
* @paddr: pointer to store initial CPU address of DMA range
@@ -935,7 +936,8 @@ EXPORT_SYMBOL(of_io_request_and_map);
* It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT.
*/
-int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
+ u64 *paddr, u64 *size)
{
struct device_node *node = of_node_get(np);
const __be32 *ranges = NULL;
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 27203bfd0b22..ef6a741f9f0b 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -95,7 +95,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
const struct iommu_ops *iommu;
u64 mask, end;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ ret = of_dma_get_range(dev, np, &dma_addr, &paddr, &size);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index edc682249c00..7a83d3a81ab6 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -158,11 +158,11 @@ extern int of_bus_n_addr_cells(struct device_node *np);
extern int of_bus_n_size_cells(struct device_node *np);
#ifdef CONFIG_OF_ADDRESS
-extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size);
+extern int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size);
#else
-static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size)
+static inline int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size)
{
return -ENODEV;
}
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 398de04fd19c..57a22517c428 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -881,7 +881,7 @@ static void __init of_unittest_dma_ranges_one(const char *path,
return;
}
- rc = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ rc = of_dma_get_range(NULL, np, &dma_addr, &paddr, &size);
unittest(!rc, "of_dma_get_range failed on node %pOF rc=%i\n", np, rc);
if (!rc) {
--
2.17.1
^ permalink raw reply related
* Re: [PATCHv1 00/19] Improve SBS battery support
From: Marek Szyprowski @ 2020-06-03 18:49 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Rob Herring, Greg Kroah-Hartman, Rafael J . Wysocki, linux-pm,
devicetree, linux-kernel, kernel, 'Linux Samsung SOC'
In-Reply-To: <20200602180119.52izs7kd72u3kmr4@earth.universe>
Hi Sebastian,
On 02.06.2020 20:01, Sebastian Reichel wrote:
> On Tue, Jun 02, 2020 at 09:17:09AM +0200, Marek Szyprowski wrote:
>> On 01.06.2020 19:05, Sebastian Reichel wrote:
>>> On Mon, Jun 01, 2020 at 12:40:27PM +0200, Marek Szyprowski wrote:
>>>> On 13.05.2020 20:55, Sebastian Reichel wrote:
>>>>> This patchset improves support for SBS compliant batteries. Due to
>>>>> the changes, the battery now exposes 32 power supply properties and
>>>>> (un)plugging it generates a backtrace containing the following message
>>>>> without the first patch in this series:
>>>>>
>>>>> ---------------------------
>>>>> WARNING: CPU: 0 PID: 20 at lib/kobject_uevent.c:659 add_uevent_var+0xd4/0x104
>>>>> add_uevent_var: too many keys
>>>>> ---------------------------
>>>>>
>>>>> For references this is what an SBS battery status looks like after
>>>>> the patch series has been applied:
>>>>>
>>>>> cat /sys/class/power_supply/sbs-0-000b/uevent
>>>>> POWER_SUPPLY_NAME=sbs-0-000b
>>>>> POWER_SUPPLY_TYPE=Battery
>>>>> POWER_SUPPLY_STATUS=Discharging
>>>>> POWER_SUPPLY_CAPACITY_LEVEL=Normal
>>>>> POWER_SUPPLY_HEALTH=Good
>>>>> POWER_SUPPLY_PRESENT=1
>>>>> POWER_SUPPLY_TECHNOLOGY=Li-ion
>>>>> POWER_SUPPLY_CYCLE_COUNT=12
>>>>> POWER_SUPPLY_VOLTAGE_NOW=11441000
>>>>> POWER_SUPPLY_CURRENT_NOW=-26000
>>>>> POWER_SUPPLY_CURRENT_AVG=-24000
>>>>> POWER_SUPPLY_CAPACITY=76
>>>>> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=1
>>>>> POWER_SUPPLY_TEMP=198
>>>>> POWER_SUPPLY_TIME_TO_EMPTY_AVG=438600
>>>>> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
>>>>> POWER_SUPPLY_SERIAL_NUMBER=0000
>>>>> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
>>>>> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=10800000
>>>>> POWER_SUPPLY_ENERGY_NOW=31090000
>>>>> POWER_SUPPLY_ENERGY_FULL=42450000
>>>>> POWER_SUPPLY_ENERGY_FULL_DESIGN=41040000
>>>>> POWER_SUPPLY_CHARGE_NOW=2924000
>>>>> POWER_SUPPLY_CHARGE_FULL=3898000
>>>>> POWER_SUPPLY_CHARGE_FULL_DESIGN=3800000
>>>>> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=3000000
>>>>> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=12300000
>>>>> POWER_SUPPLY_MANUFACTURE_YEAR=2017
>>>>> POWER_SUPPLY_MANUFACTURE_MONTH=7
>>>>> POWER_SUPPLY_MANUFACTURE_DAY=3
>>>>> POWER_SUPPLY_MANUFACTURER=UR18650A
>>>>> POWER_SUPPLY_MODEL_NAME=GEHC
>>>> This patch landed in linux-next dated 20200529. Sadly it causes a
>>>> regression on Samsung Exynos-based Chromebooks (Exynos5250 Snow,
>>>> Exynos5420 Peach-Pi and Exynos5800 Peach-Pit). System boots to
>>>> userspace, but then, when udev populates /dev, booting hangs:
>>>>
>>>> [ 4.435167] VFS: Mounted root (ext4 filesystem) readonly on device
>>>> 179:51.
>>>> [ 4.457477] devtmpfs: mounted
>>>> [ 4.460235] Freeing unused kernel memory: 1024K
>>>> [ 4.464022] Run /sbin/init as init process
>>>> INIT: version 2.88 booting
>>>> [info] Using makefile-style concurrent boot in runlevel S.
>>>> [ 5.102096] random: crng init done
>>>> [....] Starting the hotplug events dispatcher: systemd-udevdstarting
>>>> version 236
>>>> [ ok .
>>>> [....] Synthesizing the initial hotplug events...[ ok done.
>>>> [....] Waiting for /dev to be fully populated...[ 34.409914]
>>>> TPS65090_RAILSDCDC1: disabling
>>>> [ 34.412977] TPS65090_RAILSDCDC2: disabling
>>>> [ 34.417021] TPS65090_RAILSDCDC3: disabling
>>>> [ 34.423848] TPS65090_RAILSLDO1: disabling
>>>> [ 34.429068] TPS65090_RAILSLDO2: disabling
>>> :(
>>>
>>> log does not look useful either.
>>>
>>>> Bisect between v5.7-rc1 and next-20200529 pointed me to the first bad
>>>> commit: [c4b12a2f3f3de670f6be5e96092a2cab0b877f1a] power: supply:
>>>> sbs-battery: simplify read_read_string_data.
>>> ok. I tested this on an to-be-upstreamed i.MX6 based system
>>> and arch/arm/boot/dts/imx53-ppd.dts. I think the difference
>>> is, that i2c-exynos5 does not expose I2C_FUNC_SMBUS_READ_BLOCK_DATA.
>>> I hoped all systems using SBS battery support this, but now
>>> I see I2C_FUNC_SMBUS_EMUL only supports writing block data.
>>> Looks like I need to add another patch implementing that
>>> using the old code with added PEC support.
>>>
>>> In any case that should only return -ENODEV for the property
>>> (and uevent), but not break boot. So something fishy is going
>>> on.
>>>
>>>> However reverting it in linux-next doesn't fix the issue, so the
>>>> next commits are also relevant to this issue.
>>> The next patch, which adds PEC support depends on the simplification
>>> of sbs_read_string_data. The old, open coded variant will result in
>>> PEC failure for string properties (which should not stop boot either
>>> of course). Can you try reverting both?
>> Indeed, reverting both (and fixing the conflict) restores proper boot.
> Ok, I pushed out a revert of those two patches. They should land in
> tomorrows linux-next release. Please test it.
Today's linux-next (20200603) boots fine on the Samsung Exynos-based
Chromebooks. Let me know how if you need any help debugging the issues
to resurrect those patches.
>>> If that helps I will revert those two instead of dropping the whole
>>> series for this merge window.
>>>
>>>> Let me know how can I help debugging it.
>>> I suspect, that this is userspace endlessly retrying reading the
>>> battery uevent when an error is returned. Could you check this?
>>> Should be easy to see by adding some printfs.
>> I've added some debug messages in sbs_get_property() and it read the
>> same properties many times. However I've noticed that if I wait long
>> enough booting finally continues.
> So basically userspace slows down itself massively by trying to
> re-read uevent over and over when an error occurs. Does not seem
> like a sensible thing to do. I will have a look at this when I find
> some time.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-03 18:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: Viresh Kumar, Bjorn Andersson, Arnd Bergmann, Rob Herring,
Frank Rowand, Vincent Guittot, linux-arm-kernel, Devicetree List,
Linux Kernel Mailing List
In-Reply-To: <20200603183120.GE23722@bogus>
On Wed, Jun 3, 2020 at 1:31 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> > >
> > H/W is actually fine :) Its just that the driver is written to
> > _also_ support a platform (my original) that doesn't have shmem and
> > need to pass data via 32bit registers.
> > Frankly, I am not against the doorbell mode, I am against implementing
> > two modes in a driver. If it really helped (note the past tense) the
> > SCMI, we could implement the driver only in doorbell mode but
> > unfortunately SCMI would still be _broken_ for non-doorbell
> > controllers.
>
> Should be fine as the specification is designed to work with only shmem
> for any data transfer and mailbox is just a signal mechanism. I won't
> be too worried about that.
>
Please clarify how it will work on, say again, rockchip platform with shmem.
thanks.
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Jassi Brar @ 2020-06-03 18:32 UTC (permalink / raw)
To: Sudeep Holla
Cc: Viresh Kumar, Rob Herring, Arnd Bergmann, Frank Rowand,
Bjorn Andersson, Vincent Guittot, linux-arm-kernel,
Devicetree List, Linux Kernel Mailing List
In-Reply-To: <20200603180435.GB23722@bogus>
On Wed, Jun 3, 2020 at 1:04 PM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Fri, May 29, 2020 at 09:37:58AM +0530, Viresh Kumar wrote:
> > On 28-05-20, 13:20, Rob Herring wrote:
> > > Whether Linux
> > > requires serializing mailbox accesses is a separate issue. On that side,
> > > it seems silly to not allow driving the h/w in the most efficient way
> > > possible.
> >
> > That's exactly what we are trying to say. The hardware allows us to
> > write all 32 bits in parallel, without any hardware issues, why
> > shouldn't we do that ? The delay (which Sudeep will find out, he is
> > facing issues with hardware access because of lockdown right now)
>
> OK, I was able to access the setup today. I couldn't reach a point
> where I can do measurements as the system just became unusable with
> one physical channel instead of 2 virtual channels as in my patches.
>
> My test was simple. Switch to schedutil and read sensors periodically
> via sysfs.
>
> arm-scmi firmware:scmi: message for 1 is not expected!
>
This sounds like you are not serialising requests on a shared channel.
Can you please also share the patch?
Thanks.
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Sudeep Holla @ 2020-06-03 18:31 UTC (permalink / raw)
To: Jassi Brar
Cc: Viresh Kumar, Bjorn Andersson, Arnd Bergmann, Rob Herring,
Frank Rowand, Vincent Guittot, linux-arm-kernel, Devicetree List,
Sudeep Holla, Linux Kernel Mailing List
In-Reply-To: <CABb+yY30nmbBUzYG62xGEbrr7107h_Edyq3jKPheZAQ0Cvr9Yg@mail.gmail.com>
On Mon, May 18, 2020 at 11:05:03PM -0500, Jassi Brar wrote:
> On Mon, May 18, 2020 at 10:40 PM Viresh Kumar <viresh.kumar@linaro.org> wrote:
> >
> > On 18-05-20, 18:29, Bjorn Andersson wrote:
> > > On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote:
> > > > This stuff has been doing rounds on the mailing list since several years
> > > > now with no agreed conclusion by all the parties. And here is another
> > > > attempt to get some feedback from everyone involved to close this once
> > > > and for ever. Your comments will very much be appreciated.
> > > >
> > > > The ARM MHU is defined here in the TRM [1] for your reference, which
> > > > states following:
> > > >
> > > > "The MHU drives the signal using a 32-bit register, with all 32
> > > > bits logically ORed together. The MHU provides a set of
> > > > registers to enable software to set, clear, and check the status
> > > > of each of the bits of this register independently. The use of
> > > > 32 bits for each interrupt line enables software to provide more
> > > > information about the source of the interrupt. For example, each
> > > > bit of the register can be associated with a type of event that
> > > > can contribute to raising the interrupt."
> > > >
> > >
> > > Does this mean that there are 32 different signals and they are all ORed
> > > into the same interrupt line to trigger software action when something
> > > happens?
> > >
> > > Or does it mean that this register is used to pass multi-bit information
> > > and when any such information is passed an interrupt will be triggered?
> > > If so, what does that information mean? How is it tied into other Linux
> > > drivers/subsystems?
> >
> > I have started to believe the hardware is written badly at this point
> > :)
> >
> H/W is actually fine :) Its just that the driver is written to
> _also_ support a platform (my original) that doesn't have shmem and
> need to pass data via 32bit registers.
> Frankly, I am not against the doorbell mode, I am against implementing
> two modes in a driver. If it really helped (note the past tense) the
> SCMI, we could implement the driver only in doorbell mode but
> unfortunately SCMI would still be _broken_ for non-doorbell
> controllers.
Should be fine as the specification is designed to work with only shmem
for any data transfer and mailbox is just a signal mechanism. I won't
be too worried about that.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Sudeep Holla @ 2020-06-03 18:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Viresh Kumar, Jassi Brar, Arnd Bergmann, Rob Herring,
Frank Rowand, Vincent Guittot, Sudeep Holla, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20200519012927.GT2165@builder.lan>
Hi Bjorn,
Thanks for the details response.
On Mon, May 18, 2020 at 06:29:27PM -0700, Bjorn Andersson wrote:
> On Thu 14 May 22:17 PDT 2020, Viresh Kumar wrote:
>
[...]
I find this part nicely summarise your response.
> > - With serialization, if we use only one channel as today at every
> > priority, if there are 5 requests to send signal to the receiver and
> > the dvfs request is the last one in queue (which may be called from
> > scheduler's hot path with fast switching), it unnecessarily needs to
> > wait for the first four transfers to finish due to the software
> > locking imposed by the mailbox framework. This adds additional delay,
> > maybe of few ms only, which isn't required by the hardware but just by
> > the software and few ms can be important in scheduler's hotpath.
> >
>
> So these 5 requests, are they conveyed by the signals [1,2,3,4,5] or
> [BIT(0), BIT(1), BIT(2), BIT(3), BIT(4)]?
>
Latter in this case. IMO it is platform choice on how to use it. It is
equally possible to send 2^31 different signals. But the receiver must
also interpret it in the *exact* same way. In this case, the receiver
which is platform firmware interprets as individual bit signals.
> In the first case you have to serialize things given that e.g. signal 1
> immediately followed by 2 is indistinguishable from 3.
>
Agree and we are not proposing to break that use case. It exists in the
driver/binding today and will continue as is.
> If you signals are single-bit notifications then you don't need any
> serialization.
>
Indeed, we are making use of that.
--
Regards,
Sudeep
^ 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