[PATCH v1 0/5] arm64: dts: qcom: initial Inforce IFC6560 board support

[PATCH v1 0/5] arm64: dts: qcom: initial Inforce IFC6560 board support

[Dmitry Baryshkov]

This work is largely based on the previous work by Bjorn Andersson ([1])

Changes since Bjorn's v2:
- Disable dsi1, dsi1 phy, GPU by default in sdm660.dtsi/sdm630.dtsi
- Fix qusb2phy ref clock
- Added USB2 host support to sdm630.dtsi
- Renamed DTS to follow SoC-vendor-board pattern
- Fixed vph_pwr voltage
- Removed extra/unrelated comments
- Added keys, USB2, USB3,
- Added configuration for the attached HDMI bridge
- Enabled MDP, MDSS and DSI0/DSI0 PHY devices
- Removed uart pinctrl and /reserved-mem nodes (present in main dtsi
  file)
- Added card detection for the SDCC2
- Disabled BLSP BAM DMA devices, they make the board reset during boot

[1] https://lore.kernel.org/linux-arm-msm/20210825221110.1498718-1-bjorn.andersson@linaro.org/#t

Dmitry Baryshkov (5):
  arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default
  arm64: dts: qcom: sdm630: disable GPU by default
  arm64: dts: qcom: sdm630: fix the qusb2phy ref clock
  arm64: dts: qcom: sdm630: add second (HS) USB host support
  arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
 arch/arm64/boot/dts/qcom/sdm630.dtsi          |  59 ++-
 arch/arm64/boot/dts/qcom/sdm660.dtsi          |   3 +
 4 files changed, 517 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts

-- 
2.35.1

[PATCH v1 1/5] arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default

[Dmitry Baryshkov]

Follow the typical practice and keep DSI1/DSI1 PHY disabled by default.
They should be enabled in the board DT files. No existing boards use
them at this moment.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
index eccf6fde16b4..023b0ac4118c 100644
--- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
@@ -192,6 +192,8 @@ dsi1: dsi@c996000 {
 		phys = <&dsi1_phy>;
 		phy-names = "dsi";
 
+		status = "disabled";
+
 		ports {
 			#address-cells = <1>;
 			#size-cells = <0>;
@@ -225,6 +227,7 @@ dsi1_phy: dsi-phy@c996400 {
 
 		clocks = <&mmcc MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
 		clock-names = "iface", "ref";
+		status = "disabled";
 	};
 };
 
-- 
2.35.1

Re: [PATCH v1 1/5] arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default

[Marijn Suijten]

On 2022-05-04 01:09:23, Dmitry Baryshkov wrote:
> Follow the typical practice and keep DSI1/DSI1 PHY disabled by default.
> They should be enabled in the board DT files. No existing boards use
> them at this moment.

This practice also seems to be applied to dsi0/dsi0_phy across other
boards.  Should this also be applied to sdm630.dtsi's dsi0/dsi0_phy
nodes, and them subsequently re-enabled in sdm630-sony-xperia-nile.dtsi?

> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>

- Marijn
> ---
>  arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> index eccf6fde16b4..023b0ac4118c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> @@ -192,6 +192,8 @@ dsi1: dsi@c996000 {
>  		phys = <&dsi1_phy>;
>  		phy-names = "dsi";
>  
> +		status = "disabled";
> +
>  		ports {
>  			#address-cells = <1>;
>  			#size-cells = <0>;
> @@ -225,6 +227,7 @@ dsi1_phy: dsi-phy@c996400 {
>  
>  		clocks = <&mmcc MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
>  		clock-names = "iface", "ref";
> +		status = "disabled";
>  	};
>  };
>  
> -- 
> 2.35.1
> 

Re: [PATCH v1 1/5] arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default

[Dmitry Baryshkov]

On 04/05/2022 11:11, Marijn Suijten wrote:
> On 2022-05-04 01:09:23, Dmitry Baryshkov wrote:
>> Follow the typical practice and keep DSI1/DSI1 PHY disabled by default.
>> They should be enabled in the board DT files. No existing boards use
>> them at this moment.
> 
> This practice also seems to be applied to dsi0/dsi0_phy across other
> boards.  Should this also be applied to sdm630.dtsi's dsi0/dsi0_phy
> nodes, and them subsequently re-enabled in sdm630-sony-xperia-nile.dtsi?

I will apply corresponding changes to sdm630.dtsi. However enabling them 
in sdm630-sony-xperia-nile.dtsi doens't make sense at this moment, since 
neither of nile platforms properly describes the mdss/mdp/panel 
configuration. I'm looking forward to seeing the updates for these 
devices trees though.

> 
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> 
> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
> 
> - Marijn
>> ---
>>   arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> index eccf6fde16b4..023b0ac4118c 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
>> @@ -192,6 +192,8 @@ dsi1: dsi@c996000 {
>>   		phys = <&dsi1_phy>;
>>   		phy-names = "dsi";
>>   
>> +		status = "disabled";
>> +
>>   		ports {
>>   			#address-cells = <1>;
>>   			#size-cells = <0>;
>> @@ -225,6 +227,7 @@ dsi1_phy: dsi-phy@c996400 {
>>   
>>   		clocks = <&mmcc MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
>>   		clock-names = "iface", "ref";
>> +		status = "disabled";
>>   	};
>>   };
>>   
>> -- 
>> 2.35.1
>>


-- 
With best wishes
Dmitry

Re: [PATCH v1 1/5] arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default

[Marijn Suijten]

On 2022-05-13 00:58:32, Dmitry Baryshkov wrote:
> On 04/05/2022 11:11, Marijn Suijten wrote:
> > On 2022-05-04 01:09:23, Dmitry Baryshkov wrote:
> >> Follow the typical practice and keep DSI1/DSI1 PHY disabled by default.
> >> They should be enabled in the board DT files. No existing boards use
> >> them at this moment.
> > 
> > This practice also seems to be applied to dsi0/dsi0_phy across other
> > boards.  Should this also be applied to sdm630.dtsi's dsi0/dsi0_phy
> > nodes, and them subsequently re-enabled in sdm630-sony-xperia-nile.dtsi?
> 
> I will apply corresponding changes to sdm630.dtsi. However enabling them 
> in sdm630-sony-xperia-nile.dtsi doens't make sense at this moment, since 
> neither of nile platforms properly describes the mdss/mdp/panel 
> configuration. I'm looking forward to seeing the updates for these 
> devices trees though.

Thanks, I'll rebase your patches into my public Nile branch and fix this
up on my end, as to not forget this when hopefully sending more
enablement for this platform at "some point...".

- Marijn

> > 
> >> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > 
> > Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
> > 
> > - Marijn
> >> ---
> >>   arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> >> index eccf6fde16b4..023b0ac4118c 100644
> >> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> >> @@ -192,6 +192,8 @@ dsi1: dsi@c996000 {
> >>   		phys = <&dsi1_phy>;
> >>   		phy-names = "dsi";
> >>   
> >> +		status = "disabled";
> >> +
> >>   		ports {
> >>   			#address-cells = <1>;
> >>   			#size-cells = <0>;
> >> @@ -225,6 +227,7 @@ dsi1_phy: dsi-phy@c996400 {
> >>   
> >>   		clocks = <&mmcc MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
> >>   		clock-names = "iface", "ref";
> >> +		status = "disabled";
> >>   	};
> >>   };
> >>   
> >> -- 
> >> 2.35.1
> >>
> 
> 
> -- 
> With best wishes
> Dmitry

Re: [PATCH v1 1/5] arm64: dts: qcom: sdm660: disable dsi1/dsi1_phy by default

[Konrad Dybcio]

On 04/05/2022 00:09, Dmitry Baryshkov wrote:
> Follow the typical practice and keep DSI1/DSI1 PHY disabled by default.
> They should be enabled in the board DT files. No existing boards use
> them at this moment.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>


>   arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 +++
>   1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm660.dtsi b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> index eccf6fde16b4..023b0ac4118c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm660.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm660.dtsi
> @@ -192,6 +192,8 @@ dsi1: dsi@c996000 {
>   		phys = <&dsi1_phy>;
>   		phy-names = "dsi";
>   
> +		status = "disabled";
> +
>   		ports {
>   			#address-cells = <1>;
>   			#size-cells = <0>;
> @@ -225,6 +227,7 @@ dsi1_phy: dsi-phy@c996400 {
>   
>   		clocks = <&mmcc MDSS_AHB_CLK>, <&rpmcc RPM_SMD_XO_CLK_SRC>;
>   		clock-names = "iface", "ref";
> +		status = "disabled";
>   	};
>   };
>   
>

[PATCH v1 2/5] arm64: dts: qcom: sdm630: disable GPU by default

[Dmitry Baryshkov]

The SoC's device tree file disables gpucc and adreno's SMMU by default.
So let's disable the GPU too. Moreover it looks like SMMU might be not
usable without additional patches (which means that GPU is unusable
too). No board uses GPU at this moment.

Fixes: 5cf69dcbec8b ("arm64: dts: qcom: sdm630: Add Adreno 508 GPU configuration")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 240293592ef9..45eaaa6a4a74 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1050,6 +1050,8 @@ adreno_gpu: gpu@5000000 {
 
 			operating-points-v2 = <&gpu_sdm630_opp_table>;
 
+			status = "disabled";
+
 			gpu_sdm630_opp_table: opp-table {
 				compatible  = "operating-points-v2";
 				opp-775000000 {
-- 
2.35.1

Re: [PATCH v1 2/5] arm64: dts: qcom: sdm630: disable GPU by default

[Konrad Dybcio]

On 04/05/2022 00:09, Dmitry Baryshkov wrote:
> The SoC's device tree file disables gpucc and adreno's SMMU by default.
This should not be the case, but
> So let's disable the GPU too. Moreover it looks like SMMU might be not
> usable without additional patches (which means that GPU is unusable
> too).

it will only be fixed after iommu changes (hopefully) land one day..


> No board uses GPU at this moment.
>
> Fixes: 5cf69dcbec8b ("arm64: dts: qcom: sdm630: Add Adreno 508 GPU configuration")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>


>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index 240293592ef9..45eaaa6a4a74 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -1050,6 +1050,8 @@ adreno_gpu: gpu@5000000 {
>   
>   			operating-points-v2 = <&gpu_sdm630_opp_table>;
>   
> +			status = "disabled";
> +
>   			gpu_sdm630_opp_table: opp-table {
>   				compatible  = "operating-points-v2";
>   				opp-775000000 {
>

[PATCH v1 3/5] arm64: dts: qcom: sdm630: fix the qusb2phy ref clock

[Dmitry Baryshkov]

According to the downstram DT file, the qusb2phy ref clock should be
GCC_RX0_USB2_CLKREF_CLK, not GCC_RX1_USB2_CLKREF_CLK.

Fixes: c65a4ed2ea8b ("arm64: dts: qcom: sdm630: Add USB configuration")
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index 45eaaa6a4a74..d8c3d2569340 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1262,7 +1262,7 @@ qusb2phy: phy@c012000 {
 			#phy-cells = <0>;
 
 			clocks = <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
-				<&gcc GCC_RX1_USB2_CLKREF_CLK>;
+				<&gcc GCC_RX0_USB2_CLKREF_CLK>;
 			clock-names = "cfg_ahb", "ref";
 
 			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
-- 
2.35.1

Re: [PATCH v1 3/5] arm64: dts: qcom: sdm630: fix the qusb2phy ref clock

[Konrad Dybcio]

On 04/05/2022 00:09, Dmitry Baryshkov wrote:
> According to the downstram DT file, the qusb2phy ref clock should be
> GCC_RX0_USB2_CLKREF_CLK, not GCC_RX1_USB2_CLKREF_CLK.
>
> Fixes: c65a4ed2ea8b ("arm64: dts: qcom: sdm630: Add USB configuration")
> Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---

So it always worked by miracle, as bootloader left it on. Nice catch.


Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>

>   arch/arm64/boot/dts/qcom/sdm630.dtsi | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> index 45eaaa6a4a74..d8c3d2569340 100644
> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> @@ -1262,7 +1262,7 @@ qusb2phy: phy@c012000 {
>   			#phy-cells = <0>;
>   
>   			clocks = <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
> -				<&gcc GCC_RX1_USB2_CLKREF_CLK>;
> +				<&gcc GCC_RX0_USB2_CLKREF_CLK>;
>   			clock-names = "cfg_ahb", "ref";
>   
>   			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
>

[PATCH v1 4/5] arm64: dts: qcom: sdm630: add second (HS) USB host support

[Dmitry Baryshkov]

Add DT entries for the second DWC3 USB host, which is limited to the
USB2.0 (HighSpeed), and the corresponding QUSB PHY.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 arch/arm64/boot/dts/qcom/sdm630.dtsi | 55 ++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
index d8c3d2569340..57b874650c90 100644
--- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
@@ -1270,6 +1270,20 @@ qusb2phy: phy@c012000 {
 			status = "disabled";
 		};
 
+		qusb2phy1: phy@c014000 {
+			compatible = "qcom,sdm660-qusb2-phy";
+			reg = <0x0c014000 0x180>;
+			#phy-cells = <0>;
+
+			clocks = <&gcc GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+				<&gcc GCC_RX1_USB2_CLKREF_CLK>;
+			clock-names = "cfg_ahb", "ref";
+
+			resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
+			nvmem-cells = <&qusb2_hstx_trim>;
+			status = "disabled";
+		};
+
 		sdhc_2: sdhci@c084000 {
 			compatible = "qcom,sdm630-sdhci", "qcom,sdhci-msm-v5";
 			reg = <0x0c084000 0x1000>;
@@ -1375,6 +1389,47 @@ opp-384000000 {
 			};
 		};
 
+		usb2: usb@c2f8800 {
+			compatible = "qcom,sdm660-dwc3", "qcom,dwc3";
+			reg = <0x0c2f8800 0x400>;
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			clocks = <&gcc GCC_CFG_NOC_USB2_AXI_CLK>,
+				 <&gcc GCC_USB20_MASTER_CLK>,
+				 <&gcc GCC_USB20_MOCK_UTMI_CLK>,
+				 <&gcc GCC_USB20_SLEEP_CLK>;
+			clock-names = "cfg_noc", "core",
+				      "mock_utmi", "sleep";
+
+			assigned-clocks = <&gcc GCC_USB20_MOCK_UTMI_CLK>,
+					  <&gcc GCC_USB20_MASTER_CLK>;
+			assigned-clock-rates = <19200000>, <60000000>;
+
+			interrupts = <GIC_SPI 348 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hs_phy_irq";
+
+			qcom,select-utmi-as-pipe-clk;
+
+			resets = <&gcc GCC_USB_20_BCR>;
+
+			usb2_dwc3: usb@c200000 {
+				compatible = "snps,dwc3";
+				reg = <0x0c200000 0xc8d0>;
+				interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
+				snps,dis_u2_susphy_quirk;
+				snps,dis_enblslpm_quirk;
+
+				/* This is the HS-only host */
+				maximum-speed = "high-speed";
+				phys = <&qusb2phy1>;
+				phy-names = "usb2-phy";
+				snps,hird-threshold = /bits/ 8 <0>;
+			};
+		};
+
 		mmcc: clock-controller@c8c0000 {
 			compatible = "qcom,mmcc-sdm630";
 			reg = <0x0c8c0000 0x40000>;
-- 
2.35.1

[PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Dmitry Baryshkov]

The IFC6560 is a board from Inforce Computing, built around the SDA660
SoC. This patch describes core clocks, some regulators from the two
PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.

The regulator settings are inherited from prior work by Konrad Dybcio
and AngeloGioacchino Del Regno.

Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
 2 files changed, 456 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index f9e6343acd03..5f717fe0e8d0 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-herobrine-herobrine-r1.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-idp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-idp2.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-crd.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sda660-inforce-ifc6560.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-ganges-kirin.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-discovery.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-pioneer.dtb
diff --git a/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts b/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
new file mode 100644
index 000000000000..bb5cbd20379e
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
@@ -0,0 +1,455 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2021, Linaro Ltd.
+ * Copyright (c) 2020, Konrad Dybcio <konrad.dybcio@somainline.org>
+ * Copyright (c) 2020, AngeloGioacchino Del Regno
+ *                     <angelogioacchino.delregno@somainline.org>
+ */
+
+/dts-v1/;
+
+#include "sdm660.dtsi"
+#include "pm660.dtsi"
+#include "pm660l.dtsi"
+
+/ {
+	model = "Inforce 6560 Single Board Computer";
+	compatible = "inforce,ifc6560", "qcom,sdm660";
+
+	aliases {
+		serial0 = &blsp1_uart2;
+		serial1 = &blsp2_uart1;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		volup {
+			label = "Volume Up";
+			gpios = <&pm660l_gpios 7 GPIO_ACTIVE_LOW>;
+			linux,code = <KEY_VOLUMEUP>;
+			debounce-interval = <15>;
+		};
+	};
+
+	/*
+	 * Until we hook up type-c detection, we
+	 * have to stick with this. But it works.
+	 */
+	extcon_usb: extcon-usb {
+		compatible = "linux,extcon-usb-gpio";
+		id-gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
+	};
+
+	hdmi-out {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con: endpoint {
+				remote-endpoint = <&adv7533_out>;
+			};
+		};
+	};
+
+	vph_pwr: vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3800000>;
+		regulator-max-microvolt = <3800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	v3p3_bck_bst: v3p3-bck-bst-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "v3p3_bck_bst";
+
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		vin-supply = <&vph_pwr>;
+	};
+
+	v1p2_ldo: v1p2-ldo-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "v1p2_ldo";
+
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1200000>;
+
+		vin-supply = <&vph_pwr>;
+	};
+
+	v5p0_boost: v5p0-boost-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "v5p0_boost";
+
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+
+		vin-supply = <&vph_pwr>;
+	};
+};
+
+&adsp_pil {
+	firmware-name = "qcom/inforce/ifc6560/adsp.mbn";
+};
+
+&blsp_i2c6 {
+	status = "okay";
+
+	/* BAM DMA doesn't seem to work on the board */
+	/delete-property/ dmas;
+	/delete-property/ dma-names;
+
+	adv7533: hdmi@39 {
+		compatible = "adi,adv7535";
+
+		reg = <0x39>, <0x66>;
+		reg-names = "main", "edid";
+
+		interrupt-parent = <&pm660l_gpios>;
+		interrupts = <11 2>;
+
+		clocks = <&rpmcc 12>;
+		clock-names = "cec";
+		adi,dsi-lanes = <3>;
+		avdd-supply = <&vreg_l13a_1p8>;
+		dvdd-supply = <&vreg_l13a_1p8>;
+		pvdd-supply = <&vreg_l13a_1p8>;
+		a2vdd-supply = <&vreg_l13a_1p8>;
+		v3p3-supply = <&v3p3_bck_bst>;
+
+		ports {
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			port@0 {
+				reg = <0>;
+
+				adv7533_in: endpoint {
+					remote-endpoint = <&dsi0_out>;
+				};
+			};
+
+			port@1 {
+				reg = <1>;
+
+				adv7533_out: endpoint {
+					remote-endpoint = <&hdmi_con>;
+				};
+			};
+		};
+	};
+};
+
+/* BAM DMA doesn't seem to work on the board */
+&blsp1_dma {
+	status = "disabled";
+};
+
+&blsp1_uart2 {
+	status = "okay";
+};
+
+/* BAM DMA doesn't seem to work on the board */
+&blsp2_dma {
+	status = "disabled";
+};
+
+&blsp2_uart1 {
+	status = "okay";
+
+	bluetooth {
+		compatible = "qcom,wcn3990-bt";
+
+		vddio-supply = <&vreg_l13a_1p8>;
+		vddxo-supply = <&vreg_l9a_1p8>;
+		vddrf-supply = <&vreg_l6a_1p3>;
+		vddch0-supply = <&vreg_l19a_3p3>;
+		max-speed = <3200000>;
+	};
+};
+
+&dsi0 {
+	status = "okay";
+	vdda-supply = <&vreg_l1a_1p225>;
+};
+
+&dsi0_out {
+	remote-endpoint = <&adv7533_in>;
+	data-lanes = <0 1 2>;
+};
+
+&dsi0_phy {
+	status = "okay";
+	vcca-supply = <&vreg_l1b_0p925>;
+};
+
+&mdp {
+	status = "okay";
+};
+
+&mdss {
+	status = "okay";
+};
+
+&mmss_smmu {
+	status = "okay";
+};
+
+&pon_pwrkey {
+	status = "okay";
+};
+
+&pon_resin {
+	status = "okay";
+
+	linux,code = <115>;
+};
+
+&qusb2phy {
+	status = "okay";
+
+	vdd-supply = <&vreg_l1b_0p925>;
+
+	vdda-phy-dpdm-supply = <&vreg_l7b_3p125>;
+};
+
+&qusb2phy1 {
+	status = "okay";
+
+	vdd-supply = <&vreg_l1b_0p925>;
+
+	vdda-phy-dpdm-supply = <&vreg_l7b_3p125>;
+};
+
+&rpm_requests {
+	pm660-regulators {
+		compatible = "qcom,rpm-pm660-regulators";
+
+		vdd_s1-supply = <&vph_pwr>;
+		vdd_s2-supply = <&vph_pwr>;
+		vdd_s3-supply = <&vph_pwr>;
+		vdd_s4-supply = <&vph_pwr>;
+		vdd_s5-supply = <&vph_pwr>;
+		vdd_s6-supply = <&vph_pwr>;
+
+		vdd_l1_l6_l7-supply = <&vreg_s5a_1p35>;
+		vdd_l2_l3-supply = <&vreg_s2b_1p05>;
+		vdd_l5-supply = <&vreg_s2b_1p05>;
+		vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>;
+		vdd_l15_l16_l17_l18_l19-supply = <&vreg_bob>;
+
+		vreg_s4a_2p04: s4 {
+			regulator-min-microvolt = <1805000>;
+			regulator-max-microvolt = <2040000>;
+			regulator-enable-ramp-delay = <200>;
+			regulator-ramp-delay = <0>;
+			regulator-always-on;
+		};
+
+		vreg_s5a_1p35: s5 {
+			regulator-min-microvolt = <1224000>;
+			regulator-max-microvolt = <1350000>;
+			regulator-enable-ramp-delay = <200>;
+			regulator-ramp-delay = <0>;
+		};
+
+		vreg_l1a_1p225: l1 {
+			regulator-min-microvolt = <1150000>;
+			regulator-max-microvolt = <1250000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-allow-set-load;
+		};
+
+		vreg_l6a_1p3: l6 {
+			regulator-min-microvolt = <1304000>;
+			regulator-max-microvolt = <1368000>;
+			regulator-allow-set-load;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+		};
+
+		vreg_l8a_1p8: l8 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+			regulator-system-load = <325000>;
+			regulator-allow-set-load;
+		};
+
+		vreg_l9a_1p8: l9 {
+			regulator-min-microvolt = <1804000>;
+			regulator-max-microvolt = <1896000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+			regulator-allow-set-load;
+		};
+
+		vreg_l13a_1p8: l13 {
+			/* This gives power to the LPDDR4: never turn it off! */
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1944000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+			regulator-boot-on;
+			regulator-always-on;
+		};
+
+		vreg_l19a_3p3: l19 {
+			regulator-min-microvolt = <3312000>;
+			regulator-max-microvolt = <3400000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+			regulator-allow-set-load;
+		};
+	};
+
+	pm660l-regulators {
+		compatible = "qcom,rpm-pm660l-regulators";
+
+		vdd_s1-supply = <&vph_pwr>;
+		vdd_s2-supply = <&vph_pwr>;
+		vdd_s3_s4-supply = <&vph_pwr>;
+		vdd_s5-supply = <&vph_pwr>;
+		vdd_s6-supply = <&vph_pwr>;
+
+		vdd_l1_l9_l10-supply = <&vreg_s2b_1p05>;
+		vdd_l2-supply = <&vreg_bob>;
+		vdd_l3_l5_l7_l8-supply = <&vreg_bob>;
+		vdd_l4_l6-supply = <&vreg_bob>;
+		vdd_bob-supply = <&vph_pwr>;
+
+		vreg_s2b_1p05: s2 {
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-enable-ramp-delay = <200>;
+			regulator-ramp-delay = <0>;
+		};
+
+		vreg_l1b_0p925: l1 {
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <925000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-allow-set-load;
+		};
+
+		vreg_l2b_2p95: l2 {
+			regulator-min-microvolt = <1648000>;
+			regulator-max-microvolt = <3100000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+			regulator-allow-set-load;
+		};
+
+		vreg_l4b_2p95: l4 {
+			regulator-min-microvolt = <2944000>;
+			regulator-max-microvolt = <2952000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+
+			regulator-min-microamp = <200>;
+			regulator-max-microamp = <600000>;
+			regulator-system-load = <570000>;
+			regulator-allow-set-load;
+		};
+
+		/*
+		 * Downstream specifies a range of 1721-3600mV,
+		 * but the only assigned consumers are SDHCI2 VMMC
+		 * and Coresight QPDI that both request pinned 2.95V.
+		 * Tighten the range to 1.8-3.328 (closest to 3.3) to
+		 * make the mmc driver happy.
+		 */
+		vreg_l5b_2p95: l5 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <3328000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+			regulator-allow-set-load;
+			regulator-system-load = <800000>;
+		};
+
+		vreg_l7b_3p125: l7 {
+			regulator-min-microvolt = <2700000>;
+			regulator-max-microvolt = <3125000>;
+			regulator-enable-ramp-delay = <250>;
+		};
+
+		vreg_l8b_3p3: l8 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3400000>;
+			regulator-enable-ramp-delay = <250>;
+			regulator-ramp-delay = <0>;
+		};
+
+		vreg_bob: bob {
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3624000>;
+			regulator-enable-ramp-delay = <500>;
+			regulator-ramp-delay = <0>;
+		};
+	};
+};
+
+&sdhc_1 {
+	status = "okay";
+	supports-cqe;
+
+	mmc-ddr-1_8v;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+
+	vmmc-supply = <&vreg_l4b_2p95>;
+	vqmmc-supply = <&vreg_l8a_1p8>;
+};
+
+&sdhc_2 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdc2_state_on &sdc2_card_det_n>;
+	pinctrl1 = <&sdc2_state_off &sdc2_card_det_n>;
+
+	vmmc-supply = <&vreg_l5b_2p95>;
+	vqmmc-supply = <&vreg_l2b_2p95>;
+
+	cd-gpios = <&tlmm 54 1>;
+	no-sdio;
+	no-emmc;
+};
+
+&tlmm {
+	gpio-reserved-ranges = <0 4>, <8 4>;
+
+	sdc2_card_det_n: sd-card-det-n {
+		pins = "gpio54";
+		function = "gpio";
+		bias-pull-up;
+	};
+};
+
+&usb2 {
+	status = "okay";
+};
+
+&usb2_dwc3 {
+	dr_mode = "host";
+};
+
+&usb3 {
+	status = "okay";
+};
+
+&usb3_dwc3 {
+	dr_mode = "peripheral";
+	extcon = <&extcon_usb>;
+};
-- 
2.35.1

Re: [PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Konrad Dybcio]

On 04/05/2022 00:09, Dmitry Baryshkov wrote:
> The IFC6560 is a board from Inforce Computing, built around the SDA660
> SoC. This patch describes core clocks, some regulators from the two
> PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.
>
> The regulator settings are inherited from prior work by Konrad Dybcio
> and AngeloGioacchino Del Regno.
>
> Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>   arch/arm64/boot/dts/qcom/Makefile             |   1 +
>   .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
>   2 files changed, 456 insertions(+)
>   create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index f9e6343acd03..5f717fe0e8d0 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-herobrine-herobrine-r1.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-idp.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-idp2.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= sc7280-crd.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= sda660-inforce-ifc6560.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-ganges-kirin.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-discovery.dtb
>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-pioneer.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts b/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
> new file mode 100644
> index 000000000000..bb5cbd20379e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
> @@ -0,0 +1,455 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2021, Linaro Ltd.
> + * Copyright (c) 2020, Konrad Dybcio <konrad.dybcio@somainline.org>
> + * Copyright (c) 2020, AngeloGioacchino Del Regno
> + *                     <angelogioacchino.delregno@somainline.org>
> + */
> +
> +/dts-v1/;
> +
> +#include "sdm660.dtsi"
> +#include "pm660.dtsi"
> +#include "pm660l.dtsi"
> +
> +/ {
> +	model = "Inforce 6560 Single Board Computer";
> +	compatible = "inforce,ifc6560", "qcom,sdm660";

qcom,sda660?

I know it's very picky and opens another room for error (for OF platform 
matching in case some more weird quirks are ever necessary), but:


a) it is more precise, as these two are *technically* separate SoCs

b) it gives us one more differentiating factor if there ever (although 
it's unlikely) turns out that there's a very specific quirk for the SDA 
but not SDM or vice versa


Also, you're missing a chassis-type property.

> +
> +	aliases {
> +		serial0 = &blsp1_uart2;
> +		serial1 = &blsp2_uart1;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	gpio-keys {
> +		compatible = "gpio-keys";
> +
> +		volup {
> +			label = "Volume Up";
> +			gpios = <&pm660l_gpios 7 GPIO_ACTIVE_LOW>;
> +			linux,code = <KEY_VOLUMEUP>;
> +			debounce-interval = <15>;
> +		};
> +	};
> +
> +	/*
> +	 * Until we hook up type-c detection, we
> +	 * have to stick with this. But it works.
> +	 */
> +	extcon_usb: extcon-usb {
> +		compatible = "linux,extcon-usb-gpio";
> +		id-gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
> +	};
> +
> +	hdmi-out {
> +		compatible = "hdmi-connector";
> +		type = "a";
> +
> +		port {
> +			hdmi_con: endpoint {
> +				remote-endpoint = <&adv7533_out>;
> +			};
> +		};
> +	};
> +
> +	vph_pwr: vph-pwr-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vph_pwr";
> +		regulator-min-microvolt = <3800000>;
> +		regulator-max-microvolt = <3800000>;
> +
> +		regulator-always-on;
> +		regulator-boot-on;
> +	};
> +
> +	v3p3_bck_bst: v3p3-bck-bst-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "v3p3_bck_bst";
> +
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +
> +		vin-supply = <&vph_pwr>;
> +	};
> +
> +	v1p2_ldo: v1p2-ldo-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "v1p2_ldo";
> +
> +		regulator-min-microvolt = <1200000>;
> +		regulator-max-microvolt = <1200000>;
> +
> +		vin-supply = <&vph_pwr>;
> +	};
> +
> +	v5p0_boost: v5p0-boost-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "v5p0_boost";
> +
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +
> +		vin-supply = <&vph_pwr>;
> +	};
> +};
> +
> +&adsp_pil {
> +	firmware-name = "qcom/inforce/ifc6560/adsp.mbn";
> +};
> +
> +&blsp_i2c6 {
> +	status = "okay";
> +
> +	/* BAM DMA doesn't seem to work on the board */
> +	/delete-property/ dmas;
> +	/delete-property/ dma-names;
> +
> +	adv7533: hdmi@39 {
> +		compatible = "adi,adv7535";
> +

Weird newline


> +		reg = <0x39>, <0x66>;
> +		reg-names = "main", "edid";
> +
> +		interrupt-parent = <&pm660l_gpios>;
> +		interrupts = <11 2>;

Please use the correct #define


> +
> +		clocks = <&rpmcc 12>;
Ditto


> +		clock-names = "cec";
> +		adi,dsi-lanes = <3>;
> +		avdd-supply = <&vreg_l13a_1p8>;
> +		dvdd-supply = <&vreg_l13a_1p8>;
> +		pvdd-supply = <&vreg_l13a_1p8>;
> +		a2vdd-supply = <&vreg_l13a_1p8>;
> +		v3p3-supply = <&v3p3_bck_bst>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port@0 {
> +				reg = <0>;
> +
> +				adv7533_in: endpoint {
> +					remote-endpoint = <&dsi0_out>;
> +				};
> +			};
> +
> +			port@1 {
> +				reg = <1>;
> +
> +				adv7533_out: endpoint {
> +					remote-endpoint = <&hdmi_con>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +/* BAM DMA doesn't seem to work on the board */
I wonder if these are configured differently on your firmware.. what if 
you remove the `qcom,controlled-remotely` property, or in case that 
doesn't work, swap out the BAM clock for a fake one, like xo_board?
> +&blsp1_dma {
> +	status = "disabled";
> +};

This reference should come before blsp1_i2c6 alphabetically


> +
> +&blsp1_uart2 {
> +	status = "okay";
> +};
> +
> +/* BAM DMA doesn't seem to work on the board */
> +&blsp2_dma {
> +	status = "disabled";
> +};
> +
> +&blsp2_uart1 {
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "qcom,wcn3990-bt";
> +
> +		vddio-supply = <&vreg_l13a_1p8>;
> +		vddxo-supply = <&vreg_l9a_1p8>;
> +		vddrf-supply = <&vreg_l6a_1p3>;
> +		vddch0-supply = <&vreg_l19a_3p3>;
> +		max-speed = <3200000>;
> +	};
> +};
> +
> +&dsi0 {
> +	status = "okay";
> +	vdda-supply = <&vreg_l1a_1p225>;
> +};
> +
> +&dsi0_out {
> +	remote-endpoint = <&adv7533_in>;
> +	data-lanes = <0 1 2>;

Only 3 out of 4 lines? (note: this might be correct, I have no idea)


> +};
> +
> +&dsi0_phy {
> +	status = "okay";
> +	vcca-supply = <&vreg_l1b_0p925>;
> +};
> +
> +&mdp {
> +	status = "okay";
> +};

MDP should be always enabled in SoC DTSI instead, as MDSS is borderline 
useless without it..


> +
> +&mdss {
> +	status = "okay";
> +};
> +
> +&mmss_smmu {
> +	status = "okay";
> +};

..and same goes for all the SMMUs (but that's a nit for the future, as I 
mentioned in one of the previous emails)


> +
> +&pon_pwrkey {
> +	status = "okay";
> +};
> +
> +&pon_resin {
> +	status = "okay";
> +
> +	linux,code = <115>;

linux,code = <KEY_VOLUMEUP>;


> +};
> +
> +&qusb2phy {
> +	status = "okay";
> +
> +	vdd-supply = <&vreg_l1b_0p925>;
> +

Weird newline


> +	vdda-phy-dpdm-supply = <&vreg_l7b_3p125>;
> +};
> +
> +&qusb2phy1 {
> +	status = "okay";
> +
> +	vdd-supply = <&vreg_l1b_0p925>;
> +

Ditto


> +	vdda-phy-dpdm-supply = <&vreg_l7b_3p125>;
> +};
> +
> +&rpm_requests {
> +	pm660-regulators {
> +		compatible = "qcom,rpm-pm660-regulators";
> +
> +		vdd_s1-supply = <&vph_pwr>;
> +		vdd_s2-supply = <&vph_pwr>;
> +		vdd_s3-supply = <&vph_pwr>;
> +		vdd_s4-supply = <&vph_pwr>;
> +		vdd_s5-supply = <&vph_pwr>;
> +		vdd_s6-supply = <&vph_pwr>;
> +
> +		vdd_l1_l6_l7-supply = <&vreg_s5a_1p35>;
> +		vdd_l2_l3-supply = <&vreg_s2b_1p05>;
> +		vdd_l5-supply = <&vreg_s2b_1p05>;
> +		vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>;
> +		vdd_l15_l16_l17_l18_l19-supply = <&vreg_bob>;
> +
> +		vreg_s4a_2p04: s4 {
> +			regulator-min-microvolt = <1805000>;
> +			regulator-max-microvolt = <2040000>;
> +			regulator-enable-ramp-delay = <200>;
> +			regulator-ramp-delay = <0>;
> +			regulator-always-on;
> +		};
> +
> +		vreg_s5a_1p35: s5 {
> +			regulator-min-microvolt = <1224000>;
> +			regulator-max-microvolt = <1350000>;
> +			regulator-enable-ramp-delay = <200>;
> +			regulator-ramp-delay = <0>;
> +		};
> +
> +		vreg_l1a_1p225: l1 {
> +			regulator-min-microvolt = <1150000>;
> +			regulator-max-microvolt = <1250000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-allow-set-load;
> +		};
> +
> +		vreg_l6a_1p3: l6 {
> +			regulator-min-microvolt = <1304000>;
> +			regulator-max-microvolt = <1368000>;
> +			regulator-allow-set-load;

Please move the always-on prop to the bottom


> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +		};
> +
> +		vreg_l8a_1p8: l8 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1800000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +			regulator-system-load = <325000>;
> +			regulator-allow-set-load;
> +		};
> +
> +		vreg_l9a_1p8: l9 {
> +			regulator-min-microvolt = <1804000>;
> +			regulator-max-microvolt = <1896000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +			regulator-allow-set-load;
> +		};
> +
> +		vreg_l13a_1p8: l13 {
> +			/* This gives power to the LPDDR4: never turn it off! */
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <1944000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +			regulator-boot-on;
> +			regulator-always-on;

I don't know if it's formalized anywhere, but I tend to go

always-on

boot-on


as it looks cleaner (imo) when the consequent properties are shorter, 
but it might be just my craziness..

> +		};
> +
> +		vreg_l19a_3p3: l19 {
> +			regulator-min-microvolt = <3312000>;
> +			regulator-max-microvolt = <3400000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +			regulator-allow-set-load;
> +		};
> +	};
> +
> +	pm660l-regulators {
> +		compatible = "qcom,rpm-pm660l-regulators";
> +
> +		vdd_s1-supply = <&vph_pwr>;
> +		vdd_s2-supply = <&vph_pwr>;
> +		vdd_s3_s4-supply = <&vph_pwr>;
> +		vdd_s5-supply = <&vph_pwr>;
> +		vdd_s6-supply = <&vph_pwr>;
> +
> +		vdd_l1_l9_l10-supply = <&vreg_s2b_1p05>;
> +		vdd_l2-supply = <&vreg_bob>;
> +		vdd_l3_l5_l7_l8-supply = <&vreg_bob>;
> +		vdd_l4_l6-supply = <&vreg_bob>;
> +		vdd_bob-supply = <&vph_pwr>;
> +
> +		vreg_s2b_1p05: s2 {
> +			regulator-min-microvolt = <1050000>;
> +			regulator-max-microvolt = <1050000>;
> +			regulator-enable-ramp-delay = <200>;
> +			regulator-ramp-delay = <0>;
> +		};
> +
> +		vreg_l1b_0p925: l1 {
> +			regulator-min-microvolt = <800000>;
> +			regulator-max-microvolt = <925000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-allow-set-load;
> +		};
> +
> +		vreg_l2b_2p95: l2 {
> +			regulator-min-microvolt = <1648000>;
> +			regulator-max-microvolt = <3100000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +			regulator-allow-set-load;
> +		};
> +
> +		vreg_l4b_2p95: l4 {
> +			regulator-min-microvolt = <2944000>;
> +			regulator-max-microvolt = <2952000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +
> +			regulator-min-microamp = <200>;
> +			regulator-max-microamp = <600000>;
> +			regulator-system-load = <570000>;
> +			regulator-allow-set-load;
> +		};
> +
> +		/*
> +		 * Downstream specifies a range of 1721-3600mV,
> +		 * but the only assigned consumers are SDHCI2 VMMC
> +		 * and Coresight QPDI that both request pinned 2.95V.
> +		 * Tighten the range to 1.8-3.328 (closest to 3.3) to
> +		 * make the mmc driver happy.
> +		 */
> +		vreg_l5b_2p95: l5 {
> +			regulator-min-microvolt = <1800000>;
> +			regulator-max-microvolt = <3328000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +			regulator-allow-set-load;
> +			regulator-system-load = <800000>;

Same comment about shorter-properties-going-lower, but keep in mind I 
don't know if it's formalized / valid



> +		};
> +
> +		vreg_l7b_3p125: l7 {
> +			regulator-min-microvolt = <2700000>;
> +			regulator-max-microvolt = <3125000>;
> +			regulator-enable-ramp-delay = <250>;
> +		};
> +
> +		vreg_l8b_3p3: l8 {
> +			regulator-min-microvolt = <2800000>;
> +			regulator-max-microvolt = <3400000>;
> +			regulator-enable-ramp-delay = <250>;
> +			regulator-ramp-delay = <0>;
> +		};
> +
> +		vreg_bob: bob {
> +			regulator-min-microvolt = <3300000>;
> +			regulator-max-microvolt = <3624000>;
> +			regulator-enable-ramp-delay = <500>;
> +			regulator-ramp-delay = <0>;
> +		};
> +	};
> +};
> +
> +&sdhc_1 {
> +	status = "okay";
> +	supports-cqe;
> +
> +	mmc-ddr-1_8v;
> +	mmc-hs400-1_8v;
> +	mmc-hs400-enhanced-strobe;
> +
> +	vmmc-supply = <&vreg_l4b_2p95>;
> +	vqmmc-supply = <&vreg_l8a_1p8>;

Please move regulators above boolean properties to keep it coherent with 
the node below


> +};
> +
> +&sdhc_2 {
> +	status = "okay";
> +
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdc2_state_on &sdc2_card_det_n>;
> +	pinctrl1 = <&sdc2_state_off &sdc2_card_det_n>;
> +
> +	vmmc-supply = <&vreg_l5b_2p95>;
> +	vqmmc-supply = <&vreg_l2b_2p95>;
> +
> +	cd-gpios = <&tlmm 54 1>;

GPIO_ACTIVE_LOW


> +	no-sdio;
> +	no-emmc;
> +};
> +
> +&tlmm {
> +	gpio-reserved-ranges = <0 4>, <8 4>;
> +
> +	sdc2_card_det_n: sd-card-det-n {
> +		pins = "gpio54";
> +		function = "gpio";
> +		bias-pull-up;
> +	};
> +};
> +
> +&usb2 {
> +	status = "okay";
> +};
> +
> +&usb2_dwc3 {
> +	dr_mode = "host";
> +};
> +
> +&usb3 {
> +	status = "okay";
> +};
> +
> +&usb3_dwc3 {
> +	dr_mode = "peripheral";
> +	extcon = <&extcon_usb>;
> +};
>
Konrad

Re: [PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Dmitry Baryshkov]

On 04/05/2022 19:17, Konrad Dybcio wrote:
> 
> On 04/05/2022 00:09, Dmitry Baryshkov wrote:
>> The IFC6560 is a board from Inforce Computing, built around the SDA660
>> SoC. This patch describes core clocks, some regulators from the two
>> PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.
>>
>> The regulator settings are inherited from prior work by Konrad Dybcio
>> and AngeloGioacchino Del Regno.
>>
>> Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile             |   1 +
>>   .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
>>   2 files changed, 456 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
>> b/arch/arm64/boot/dts/qcom/Makefile
>> index f9e6343acd03..5f717fe0e8d0 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)    += 
>> sc7280-herobrine-herobrine-r1.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)    += sc7280-idp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)    += sc7280-idp2.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)    += sc7280-crd.dtb
>> +dtb-$(CONFIG_ARCH_QCOM)    += sda660-inforce-ifc6560.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)    += sdm630-sony-xperia-ganges-kirin.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)    += sdm630-sony-xperia-nile-discovery.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)    += sdm630-sony-xperia-nile-pioneer.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts 
>> b/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>> new file mode 100644
>> index 000000000000..bb5cbd20379e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>> @@ -0,0 +1,455 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2021, Linaro Ltd.
>> + * Copyright (c) 2020, Konrad Dybcio <konrad.dybcio@somainline.org>
>> + * Copyright (c) 2020, AngeloGioacchino Del Regno
>> + *                     <angelogioacchino.delregno@somainline.org>
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sdm660.dtsi"
>> +#include "pm660.dtsi"
>> +#include "pm660l.dtsi"
>> +
>> +/ {
>> +    model = "Inforce 6560 Single Board Computer";
>> +    compatible = "inforce,ifc6560", "qcom,sdm660";
> 
> qcom,sda660?
> 
> I know it's very picky and opens another room for error (for OF platform 
> matching in case some more weird quirks are ever necessary), but:
> 
> 
> a) it is more precise, as these two are *technically* separate SoCs
> 
> b) it gives us one more differentiating factor if there ever (although 
> it's unlikely) turns out that there's a very specific quirk for the SDA 
> but not SDM or vice versa
> 
> 
> Also, you're missing a chassis-type property.
> 
>> +
>> +    aliases {
>> +        serial0 = &blsp1_uart2;
>> +        serial1 = &blsp2_uart1;
>> +    };
>> +
>> +    chosen {
>> +        stdout-path = "serial0:115200n8";
>> +    };
>> +
>> +    gpio-keys {
>> +        compatible = "gpio-keys";
>> +
>> +        volup {
>> +            label = "Volume Up";
>> +            gpios = <&pm660l_gpios 7 GPIO_ACTIVE_LOW>;
>> +            linux,code = <KEY_VOLUMEUP>;
>> +            debounce-interval = <15>;
>> +        };
>> +    };
>> +
>> +    /*
>> +     * Until we hook up type-c detection, we
>> +     * have to stick with this. But it works.
>> +     */
>> +    extcon_usb: extcon-usb {
>> +        compatible = "linux,extcon-usb-gpio";
>> +        id-gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
>> +    };
>> +
>> +    hdmi-out {
>> +        compatible = "hdmi-connector";
>> +        type = "a";
>> +
>> +        port {
>> +            hdmi_con: endpoint {
>> +                remote-endpoint = <&adv7533_out>;
>> +            };
>> +        };
>> +    };
>> +
>> +    vph_pwr: vph-pwr-regulator {
>> +        compatible = "regulator-fixed";
>> +        regulator-name = "vph_pwr";
>> +        regulator-min-microvolt = <3800000>;
>> +        regulator-max-microvolt = <3800000>;
>> +
>> +        regulator-always-on;
>> +        regulator-boot-on;
>> +    };
>> +
>> +    v3p3_bck_bst: v3p3-bck-bst-regulator {
>> +        compatible = "regulator-fixed";
>> +        regulator-name = "v3p3_bck_bst";
>> +
>> +        regulator-min-microvolt = <3300000>;
>> +        regulator-max-microvolt = <3300000>;
>> +
>> +        vin-supply = <&vph_pwr>;
>> +    };
>> +
>> +    v1p2_ldo: v1p2-ldo-regulator {
>> +        compatible = "regulator-fixed";
>> +        regulator-name = "v1p2_ldo";
>> +
>> +        regulator-min-microvolt = <1200000>;
>> +        regulator-max-microvolt = <1200000>;
>> +
>> +        vin-supply = <&vph_pwr>;
>> +    };
>> +
>> +    v5p0_boost: v5p0-boost-regulator {
>> +        compatible = "regulator-fixed";
>> +        regulator-name = "v5p0_boost";
>> +
>> +        regulator-min-microvolt = <5000000>;
>> +        regulator-max-microvolt = <5000000>;
>> +
>> +        vin-supply = <&vph_pwr>;
>> +    };
>> +};
>> +
>> +&adsp_pil {
>> +    firmware-name = "qcom/inforce/ifc6560/adsp.mbn";
>> +};
>> +
>> +&blsp_i2c6 {
>> +    status = "okay";
>> +
>> +    /* BAM DMA doesn't seem to work on the board */
>> +    /delete-property/ dmas;
>> +    /delete-property/ dma-names;
>> +
>> +    adv7533: hdmi@39 {
>> +        compatible = "adi,adv7535";
>> +
> 
> Weird newline
> 
> 
>> +        reg = <0x39>, <0x66>;
>> +        reg-names = "main", "edid";
>> +
>> +        interrupt-parent = <&pm660l_gpios>;
>> +        interrupts = <11 2>;
> 
> Please use the correct #define
> 
> 
>> +
>> +        clocks = <&rpmcc 12>;
> Ditto
> 
> 
>> +        clock-names = "cec";
>> +        adi,dsi-lanes = <3>;
>> +        avdd-supply = <&vreg_l13a_1p8>;
>> +        dvdd-supply = <&vreg_l13a_1p8>;
>> +        pvdd-supply = <&vreg_l13a_1p8>;
>> +        a2vdd-supply = <&vreg_l13a_1p8>;
>> +        v3p3-supply = <&v3p3_bck_bst>;
>> +
>> +        ports {
>> +            #address-cells = <1>;
>> +            #size-cells = <0>;
>> +
>> +            port@0 {
>> +                reg = <0>;
>> +
>> +                adv7533_in: endpoint {
>> +                    remote-endpoint = <&dsi0_out>;
>> +                };
>> +            };
>> +
>> +            port@1 {
>> +                reg = <1>;
>> +
>> +                adv7533_out: endpoint {
>> +                    remote-endpoint = <&hdmi_con>;
>> +                };
>> +            };
>> +        };
>> +    };
>> +};
>> +
>> +/* BAM DMA doesn't seem to work on the board */
> I wonder if these are configured differently on your firmware.. what if 
> you remove the `qcom,controlled-remotely` property, or in case that 
> doesn't work, swap out the BAM clock for a fake one, like xo_board?
>> +&blsp1_dma {
>> +    status = "disabled";
>> +};
> 
> This reference should come before blsp1_i2c6 alphabetically
> 
> 
>> +
>> +&blsp1_uart2 {
>> +    status = "okay";
>> +};
>> +
>> +/* BAM DMA doesn't seem to work on the board */
>> +&blsp2_dma {
>> +    status = "disabled";
>> +};
>> +
>> +&blsp2_uart1 {
>> +    status = "okay";
>> +
>> +    bluetooth {
>> +        compatible = "qcom,wcn3990-bt";
>> +
>> +        vddio-supply = <&vreg_l13a_1p8>;
>> +        vddxo-supply = <&vreg_l9a_1p8>;
>> +        vddrf-supply = <&vreg_l6a_1p3>;
>> +        vddch0-supply = <&vreg_l19a_3p3>;
>> +        max-speed = <3200000>;
>> +    };
>> +};
>> +
>> +&dsi0 {
>> +    status = "okay";
>> +    vdda-supply = <&vreg_l1a_1p225>;
>> +};
>> +
>> +&dsi0_out {
>> +    remote-endpoint = <&adv7533_in>;
>> +    data-lanes = <0 1 2>;
> 
> Only 3 out of 4 lines? (note: this might be correct, I have no idea)

Yes. Otherwise adv7535 would try playing wild games of detaching from 
DSI host on the fly, which our host obviously doesn't like.

I'll review other comments as the time permits and will post v2.

> 
> 
>> +};
>> +
>> +&dsi0_phy {
>> +    status = "okay";
>> +    vcca-supply = <&vreg_l1b_0p925>;
>> +};
>> +
>> +&mdp {
>> +    status = "okay";
>> +};
> 
> MDP should be always enabled in SoC DTSI instead, as MDSS is borderline 
> useless without it..
> 
> 
>> +
>> +&mdss {
>> +    status = "okay";
>> +};
>> +
>> +&mmss_smmu {
>> +    status = "okay";
>> +};
> 
> ..and same goes for all the SMMUs (but that's a nit for the future, as I 
> mentioned in one of the previous emails)
> 
> 
>> +
>> +&pon_pwrkey {
>> +    status = "okay";
>> +};
>> +
>> +&pon_resin {
>> +    status = "okay";
>> +
>> +    linux,code = <115>;
> 
> linux,code = <KEY_VOLUMEUP>;
> 
> 
>> +};
>> +
>> +&qusb2phy {
>> +    status = "okay";
>> +
>> +    vdd-supply = <&vreg_l1b_0p925>;
>> +
> 
> Weird newline
> 
> 
>> +    vdda-phy-dpdm-supply = <&vreg_l7b_3p125>;
>> +};
>> +
>> +&qusb2phy1 {
>> +    status = "okay";
>> +
>> +    vdd-supply = <&vreg_l1b_0p925>;
>> +
> 
> Ditto
> 
> 
>> +    vdda-phy-dpdm-supply = <&vreg_l7b_3p125>;
>> +};
>> +
>> +&rpm_requests {
>> +    pm660-regulators {
>> +        compatible = "qcom,rpm-pm660-regulators";
>> +
>> +        vdd_s1-supply = <&vph_pwr>;
>> +        vdd_s2-supply = <&vph_pwr>;
>> +        vdd_s3-supply = <&vph_pwr>;
>> +        vdd_s4-supply = <&vph_pwr>;
>> +        vdd_s5-supply = <&vph_pwr>;
>> +        vdd_s6-supply = <&vph_pwr>;
>> +
>> +        vdd_l1_l6_l7-supply = <&vreg_s5a_1p35>;
>> +        vdd_l2_l3-supply = <&vreg_s2b_1p05>;
>> +        vdd_l5-supply = <&vreg_s2b_1p05>;
>> +        vdd_l8_l9_l10_l11_l12_l13_l14-supply = <&vreg_s4a_2p04>;
>> +        vdd_l15_l16_l17_l18_l19-supply = <&vreg_bob>;
>> +
>> +        vreg_s4a_2p04: s4 {
>> +            regulator-min-microvolt = <1805000>;
>> +            regulator-max-microvolt = <2040000>;
>> +            regulator-enable-ramp-delay = <200>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-always-on;
>> +        };
>> +
>> +        vreg_s5a_1p35: s5 {
>> +            regulator-min-microvolt = <1224000>;
>> +            regulator-max-microvolt = <1350000>;
>> +            regulator-enable-ramp-delay = <200>;
>> +            regulator-ramp-delay = <0>;
>> +        };
>> +
>> +        vreg_l1a_1p225: l1 {
>> +            regulator-min-microvolt = <1150000>;
>> +            regulator-max-microvolt = <1250000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-allow-set-load;
>> +        };
>> +
>> +        vreg_l6a_1p3: l6 {
>> +            regulator-min-microvolt = <1304000>;
>> +            regulator-max-microvolt = <1368000>;
>> +            regulator-allow-set-load;
> 
> Please move the always-on prop to the bottom
> 
> 
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +        };
>> +
>> +        vreg_l8a_1p8: l8 {
>> +            regulator-min-microvolt = <1800000>;
>> +            regulator-max-microvolt = <1800000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-system-load = <325000>;
>> +            regulator-allow-set-load;
>> +        };
>> +
>> +        vreg_l9a_1p8: l9 {
>> +            regulator-min-microvolt = <1804000>;
>> +            regulator-max-microvolt = <1896000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-allow-set-load;
>> +        };
>> +
>> +        vreg_l13a_1p8: l13 {
>> +            /* This gives power to the LPDDR4: never turn it off! */
>> +            regulator-min-microvolt = <1800000>;
>> +            regulator-max-microvolt = <1944000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-boot-on;
>> +            regulator-always-on;
> 
> I don't know if it's formalized anywhere, but I tend to go
> 
> always-on
> 
> boot-on
> 
> 
> as it looks cleaner (imo) when the consequent properties are shorter, 
> but it might be just my craziness..
> 
>> +        };
>> +
>> +        vreg_l19a_3p3: l19 {
>> +            regulator-min-microvolt = <3312000>;
>> +            regulator-max-microvolt = <3400000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-allow-set-load;
>> +        };
>> +    };
>> +
>> +    pm660l-regulators {
>> +        compatible = "qcom,rpm-pm660l-regulators";
>> +
>> +        vdd_s1-supply = <&vph_pwr>;
>> +        vdd_s2-supply = <&vph_pwr>;
>> +        vdd_s3_s4-supply = <&vph_pwr>;
>> +        vdd_s5-supply = <&vph_pwr>;
>> +        vdd_s6-supply = <&vph_pwr>;
>> +
>> +        vdd_l1_l9_l10-supply = <&vreg_s2b_1p05>;
>> +        vdd_l2-supply = <&vreg_bob>;
>> +        vdd_l3_l5_l7_l8-supply = <&vreg_bob>;
>> +        vdd_l4_l6-supply = <&vreg_bob>;
>> +        vdd_bob-supply = <&vph_pwr>;
>> +
>> +        vreg_s2b_1p05: s2 {
>> +            regulator-min-microvolt = <1050000>;
>> +            regulator-max-microvolt = <1050000>;
>> +            regulator-enable-ramp-delay = <200>;
>> +            regulator-ramp-delay = <0>;
>> +        };
>> +
>> +        vreg_l1b_0p925: l1 {
>> +            regulator-min-microvolt = <800000>;
>> +            regulator-max-microvolt = <925000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-allow-set-load;
>> +        };
>> +
>> +        vreg_l2b_2p95: l2 {
>> +            regulator-min-microvolt = <1648000>;
>> +            regulator-max-microvolt = <3100000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-allow-set-load;
>> +        };
>> +
>> +        vreg_l4b_2p95: l4 {
>> +            regulator-min-microvolt = <2944000>;
>> +            regulator-max-microvolt = <2952000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +
>> +            regulator-min-microamp = <200>;
>> +            regulator-max-microamp = <600000>;
>> +            regulator-system-load = <570000>;
>> +            regulator-allow-set-load;
>> +        };
>> +
>> +        /*
>> +         * Downstream specifies a range of 1721-3600mV,
>> +         * but the only assigned consumers are SDHCI2 VMMC
>> +         * and Coresight QPDI that both request pinned 2.95V.
>> +         * Tighten the range to 1.8-3.328 (closest to 3.3) to
>> +         * make the mmc driver happy.
>> +         */
>> +        vreg_l5b_2p95: l5 {
>> +            regulator-min-microvolt = <1800000>;
>> +            regulator-max-microvolt = <3328000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +            regulator-allow-set-load;
>> +            regulator-system-load = <800000>;
> 
> Same comment about shorter-properties-going-lower, but keep in mind I 
> don't know if it's formalized / valid
> 
> 
> 
>> +        };
>> +
>> +        vreg_l7b_3p125: l7 {
>> +            regulator-min-microvolt = <2700000>;
>> +            regulator-max-microvolt = <3125000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +        };
>> +
>> +        vreg_l8b_3p3: l8 {
>> +            regulator-min-microvolt = <2800000>;
>> +            regulator-max-microvolt = <3400000>;
>> +            regulator-enable-ramp-delay = <250>;
>> +            regulator-ramp-delay = <0>;
>> +        };
>> +
>> +        vreg_bob: bob {
>> +            regulator-min-microvolt = <3300000>;
>> +            regulator-max-microvolt = <3624000>;
>> +            regulator-enable-ramp-delay = <500>;
>> +            regulator-ramp-delay = <0>;
>> +        };
>> +    };
>> +};
>> +
>> +&sdhc_1 {
>> +    status = "okay";
>> +    supports-cqe;
>> +
>> +    mmc-ddr-1_8v;
>> +    mmc-hs400-1_8v;
>> +    mmc-hs400-enhanced-strobe;
>> +
>> +    vmmc-supply = <&vreg_l4b_2p95>;
>> +    vqmmc-supply = <&vreg_l8a_1p8>;
> 
> Please move regulators above boolean properties to keep it coherent with 
> the node below
> 
> 
>> +};
>> +
>> +&sdhc_2 {
>> +    status = "okay";
>> +
>> +    pinctrl-names = "default";
>> +    pinctrl-0 = <&sdc2_state_on &sdc2_card_det_n>;
>> +    pinctrl1 = <&sdc2_state_off &sdc2_card_det_n>;
>> +
>> +    vmmc-supply = <&vreg_l5b_2p95>;
>> +    vqmmc-supply = <&vreg_l2b_2p95>;
>> +
>> +    cd-gpios = <&tlmm 54 1>;
> 
> GPIO_ACTIVE_LOW
> 
> 
>> +    no-sdio;
>> +    no-emmc;
>> +};
>> +
>> +&tlmm {
>> +    gpio-reserved-ranges = <0 4>, <8 4>;
>> +
>> +    sdc2_card_det_n: sd-card-det-n {
>> +        pins = "gpio54";
>> +        function = "gpio";
>> +        bias-pull-up;
>> +    };
>> +};
>> +
>> +&usb2 {
>> +    status = "okay";
>> +};
>> +
>> +&usb2_dwc3 {
>> +    dr_mode = "host";
>> +};
>> +
>> +&usb3 {
>> +    status = "okay";
>> +};
>> +
>> +&usb3_dwc3 {
>> +    dr_mode = "peripheral";
>> +    extcon = <&extcon_usb>;
>> +};
>>
> Konrad


-- 
With best wishes
Dmitry

Re: [PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Dmitry Baryshkov]

On 04/05/2022 19:17, Konrad Dybcio wrote:
> 
> On 04/05/2022 00:09, Dmitry Baryshkov wrote:
>> The IFC6560 is a board from Inforce Computing, built around the SDA660
>> SoC. This patch describes core clocks, some regulators from the two
>> PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.
>>
>> The regulator settings are inherited from prior work by Konrad Dybcio
>> and AngeloGioacchino Del Regno.
>>
>> Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile             |   1 +
>>   .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
>>   2 files changed, 456 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
>> b/arch/arm64/boot/dts/qcom/Makefile
>> index f9e6343acd03..5f717fe0e8d0 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)    += 

[skipped]

>> +
>> +/* BAM DMA doesn't seem to work on the board */
> I wonder if these are configured differently on your firmware.. what if 
> you remove the `qcom,controlled-remotely` property, or in case that 
> doesn't work, swap out the BAM clock for a fake one, like xo_board?

You know, replacing BAM clock with xo_board makes the devices probe and 
work. So does adding interconnects property (together with Bhupeshe's 
patches which didn't land for some reason). I think I will override just 
the clocks for now and update the core dtsi once the [1] gets merged.

[1] 
https://lore.kernel.org/linux-arm-msm/20211110105922.217895-14-bhupesh.sharma@linaro.org/

>> +&blsp1_dma {
>> +    status = "disabled";
>> +};
> 
> This reference should come before blsp1_i2c6 alphabetically
> 
> 

[skipped]


>> +
>> +&mdp {
>> +    status = "okay";
>> +};
> 
> MDP should be always enabled in SoC DTSI instead, as MDSS is borderline 
> useless without it..

I see your point. sdm845 doesn't disable it, but later platforms 
(sc7180/sc7280/sm8250) disable mdp and require enabling it explicitly in 
the board files. I'd tend to follow the example of the later platforms. 
Not to mention that sdm630.dtsi already contains 'status="disabled"' for 
this device.

>> +
>> +&mdss {
>> +    status = "okay";
>> +};
>> +
>> +&mmss_smmu {
>> +    status = "okay";
>> +};
> 
> ..and same goes for all the SMMUs (but that's a nit for the future, as I 
> mentioned in one of the previous emails)

Yes.

[skipped]


-- 
With best wishes
Dmitry

Re: [PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Konrad Dybcio]

On 13.05.2022 00:58, Dmitry Baryshkov wrote:
> On 04/05/2022 19:17, Konrad Dybcio wrote:
>>
>> On 04/05/2022 00:09, Dmitry Baryshkov wrote:
>>> The IFC6560 is a board from Inforce Computing, built around the SDA660
>>> SoC. This patch describes core clocks, some regulators from the two
>>> PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.
>>>
>>> The regulator settings are inherited from prior work by Konrad Dybcio
>>> and AngeloGioacchino Del Regno.
>>>
>>> Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> ---
>>>   arch/arm64/boot/dts/qcom/Makefile             |   1 +
>>>   .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
>>>   2 files changed, 456 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>>> index f9e6343acd03..5f717fe0e8d0 100644
>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>> @@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)    += 
> 
> [skipped]
> 
>>> +
>>> +/* BAM DMA doesn't seem to work on the board */
>> I wonder if these are configured differently on your firmware.. what if you remove the `qcom,controlled-remotely` property, or in case that doesn't work, swap out the BAM clock for a fake one, like xo_board?
> 
> You know, replacing BAM clock with xo_board makes the devices probe and work. So does adding interconnects property (together with Bhupeshe's patches which didn't land for some reason). I think I will override just the clocks for now and update the core dtsi once the [1] gets merged.
Hm, perhaps that clock should be marked as protected on this board then, since interactions with it can cause the board to hang.. Can you read the rate in, for example, debugfs without it going crazy?

> 
> [1] https://lore.kernel.org/linux-arm-msm/20211110105922.217895-14-bhupesh.sharma@linaro.org/
> 
>>> +&blsp1_dma {
>>> +    status = "disabled";
>>> +};
>>
>> This reference should come before blsp1_i2c6 alphabetically
>>
>>
> 
> [skipped]
> 
> 
>>> +
>>> +&mdp {
>>> +    status = "okay";
>>> +};
>>
>> MDP should be always enabled in SoC DTSI instead, as MDSS is borderline useless without it..
> 
> I see your point. sdm845 doesn't disable it, but later platforms (sc7180/sc7280/sm8250) disable mdp and require enabling it explicitly in the board files. I'd tend to follow the example of the later platforms. Not to mention that sdm630.dtsi already contains 'status="disabled"' for this device.
845 and 8250 do not, I changed that myself some time ago :P As for sc7x80, I just haven't gotten to play with these just yet..

Konrad
> 
>>> +
>>> +&mdss {
>>> +    status = "okay";
>>> +};
>>> +
>>> +&mmss_smmu {
>>> +    status = "okay";
>>> +};
>>
>> ..and same goes for all the SMMUs (but that's a nit for the future, as I mentioned in one of the previous emails)
> 
> Yes.
> 
> [skipped]
> 
> 

Re: [PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Dmitry Baryshkov]

On 13/05/2022 22:18, Konrad Dybcio wrote:
> 
> 
> On 13.05.2022 00:58, Dmitry Baryshkov wrote:
>> On 04/05/2022 19:17, Konrad Dybcio wrote:
>>>
>>> On 04/05/2022 00:09, Dmitry Baryshkov wrote:
>>>> The IFC6560 is a board from Inforce Computing, built around the SDA660
>>>> SoC. This patch describes core clocks, some regulators from the two
>>>> PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.
>>>>
>>>> The regulator settings are inherited from prior work by Konrad Dybcio
>>>> and AngeloGioacchino Del Regno.
>>>>
>>>> Co-developed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/Makefile             |   1 +
>>>>    .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
>>>>    2 files changed, 456 insertions(+)
>>>>    create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>>>> index f9e6343acd03..5f717fe0e8d0 100644
>>>> --- a/arch/arm64/boot/dts/qcom/Makefile
>>>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>>>> @@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)    +=
>>
>> [skipped]
>>
>>>> +
>>>> +/* BAM DMA doesn't seem to work on the board */
>>> I wonder if these are configured differently on your firmware.. what if you remove the `qcom,controlled-remotely` property, or in case that doesn't work, swap out the BAM clock for a fake one, like xo_board?
>>
>> You know, replacing BAM clock with xo_board makes the devices probe and work. So does adding interconnects property (together with Bhupeshe's patches which didn't land for some reason). I think I will override just the clocks for now and update the core dtsi once the [1] gets merged.
> Hm, perhaps that clock should be marked as protected on this board then, since interactions with it can cause the board to hang.. Can you read the rate in, for example, debugfs without it going crazy?

No, didn't try that. I'll check it next time I boot the board (might 
take a few days).

> 
>>
>> [1] https://lore.kernel.org/linux-arm-msm/20211110105922.217895-14-bhupesh.sharma@linaro.org/
>>
>>>> +&blsp1_dma {
>>>> +    status = "disabled";
>>>> +};
>>>
>>> This reference should come before blsp1_i2c6 alphabetically
>>>
>>>
>>
>> [skipped]
>>
>>
>>>> +
>>>> +&mdp {
>>>> +    status = "okay";
>>>> +};
>>>
>>> MDP should be always enabled in SoC DTSI instead, as MDSS is borderline useless without it..
>>
>> I see your point. sdm845 doesn't disable it, but later platforms (sc7180/sc7280/sm8250) disable mdp and require enabling it explicitly in the board files. I'd tend to follow the example of the later platforms. Not to mention that sdm630.dtsi already contains 'status="disabled"' for this device.
> 845 and 8250 do not, I changed that myself some time ago :P As for sc7x80, I just haven't gotten to play with these just yet..

ok. Then we should probably cleanup board files which still manually 
enable mdp nodes.

> 
> Konrad
>>
>>>> +
>>>> +&mdss {
>>>> +    status = "okay";
>>>> +};
>>>> +
>>>> +&mmss_smmu {
>>>> +    status = "okay";
>>>> +};
>>>
>>> ..and same goes for all the SMMUs (but that's a nit for the future, as I mentioned in one of the previous emails)
>>
>> Yes.
>>
>> [skipped]
>>
>>


-- 
With best wishes
Dmitry