[PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Jonathan Marek]

Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.

Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
few changes. Notably, the HDK865 dts has regulator config changed a bit based
on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).

Jonathan Marek (6):
  arm64: dts: qcom: sm8150: add apps_smmu node
  arm64: dts: qcom: sm8250: add apps_smmu node
  arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
  arm64: dts: qcom: sm8250: Add USB and PHY device nodes
  arm64: dts: qcom: add sm8150 hdk dts
  arm64: dts: qcom: add sm8250 hdk dts

 arch/arm64/boot/dts/qcom/Makefile       |   2 +
 arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
 arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
 arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
 5 files changed, 1384 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts

-- 
2.26.1

[PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Jonathan Marek]

Add the apps_smmu node for sm8150. Note that adding the iommus field for
UFS is required because initializing the iommu removes the bypass mapping
that created by the bootloader.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
 1 file changed, 91 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index a36512d1f6a1..acb839427b12 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
 			resets = <&gcc GCC_UFS_PHY_BCR>;
 			reset-names = "rst";
 
+			iommus = <&apps_smmu 0x300 0>;
+
 			clock-names =
 				"core_clk",
 				"bus_aggr_clk",
@@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
 				compatible = "snps,dwc3";
 				reg = <0 0x0a600000 0 0xcd00>;
 				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+				iommus = <&apps_smmu 0x140 0>;
 				snps,dis_u2_susphy_quirk;
 				snps,dis_enblslpm_quirk;
 				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
@@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
 			cell-index = <0>;
 		};
 
+		apps_smmu: iommu@15000000 {
+			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
+			reg = <0 0x15000000 0 0x100000>;
+			#iommu-cells = <2>;
+			#global-interrupts = <1>;
+			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		remoteproc_adsp: remoteproc@17300000 {
 			compatible = "qcom,sm8150-adsp-pas";
 			reg = <0x0 0x17300000 0x0 0x4040>;
-- 
2.26.1

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Sai Prakash Ranjan]

Hi Jonathan,

On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8150. Note that adding the iommus field 
> for
> UFS is required because initializing the iommu removes the bypass 
> mapping
> that created by the bootloader.
> 
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
>  arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> index a36512d1f6a1..acb839427b12 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
>  			resets = <&gcc GCC_UFS_PHY_BCR>;
>  			reset-names = "rst";
> 
> +			iommus = <&apps_smmu 0x300 0>;
> +
>  			clock-names =
>  				"core_clk",
>  				"bus_aggr_clk",
> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
>  				compatible = "snps,dwc3";
>  				reg = <0 0x0a600000 0 0xcd00>;
>  				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> +				iommus = <&apps_smmu 0x140 0>;
>  				snps,dis_u2_susphy_quirk;
>  				snps,dis_enblslpm_quirk;
>  				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
>  			cell-index = <0>;
>  		};
> 
> +		apps_smmu: iommu@15000000 {
> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";

This should be qcom,sm8150-smmu-500 and also you need to update the 
arm-smmu
binding with this compatible in a separate patch.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-05-25 15:07, Sai Prakash Ranjan wrote:
> Hi Jonathan,
> 
> On 2020-05-24 08:08, Jonathan Marek wrote:
>> Add the apps_smmu node for sm8150. Note that adding the iommus field 
>> for
>> UFS is required because initializing the iommu removes the bypass 
>> mapping
>> that created by the bootloader.
>> 
>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>>  arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 
>> ++++++++++++++++++++++++++++
>>  1 file changed, 91 insertions(+)
>> 
>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> index a36512d1f6a1..acb839427b12 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>  			resets = <&gcc GCC_UFS_PHY_BCR>;
>>  			reset-names = "rst";
>> 
>> +			iommus = <&apps_smmu 0x300 0>;
>> +
>>  			clock-names =
>>  				"core_clk",
>>  				"bus_aggr_clk",
>> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
>>  				compatible = "snps,dwc3";
>>  				reg = <0 0x0a600000 0 0xcd00>;
>>  				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>> +				iommus = <&apps_smmu 0x140 0>;
>>  				snps,dis_u2_susphy_quirk;
>>  				snps,dis_enblslpm_quirk;
>>  				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
>> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
>>  			cell-index = <0>;
>>  		};
>> 
>> +		apps_smmu: iommu@15000000 {
>> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> 
> This should be qcom,sm8150-smmu-500 and also you need to update the 
> arm-smmu
> binding with this compatible in a separate patch.
> 

I tested out this series with my coresight patches for enabling SMMU 
translation
for ETR on SM8150, it works fine. With this above comment addressed and 
with
Bjorn's comments on commit description addressed,

Reviewed-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Tested-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Bjorn Andersson]

On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:

> Add the apps_smmu node for sm8150. Note that adding the iommus field for
> UFS is required because initializing the iommu removes the bypass mapping
> that created by the bootloader.
> 

Unrelated to the patch itself; how do you disable the splash screen on
8150? "fastboot oem select-display-panel none" doesn't seem to work for
me on the MTP - and hence this would prevent my device from booting.

Thanks,
Bjorn

> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
>  arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
>  1 file changed, 91 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> index a36512d1f6a1..acb839427b12 100644
> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
>  			resets = <&gcc GCC_UFS_PHY_BCR>;
>  			reset-names = "rst";
>  
> +			iommus = <&apps_smmu 0x300 0>;
> +
>  			clock-names =
>  				"core_clk",
>  				"bus_aggr_clk",
> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
>  				compatible = "snps,dwc3";
>  				reg = <0 0x0a600000 0 0xcd00>;
>  				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> +				iommus = <&apps_smmu 0x140 0>;
>  				snps,dis_u2_susphy_quirk;
>  				snps,dis_enblslpm_quirk;
>  				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
>  			cell-index = <0>;
>  		};
>  
> +		apps_smmu: iommu@15000000 {
> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> +			reg = <0 0x15000000 0 0x100000>;
> +			#iommu-cells = <2>;
> +			#global-interrupts = <1>;
> +			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
> +				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
> +		};
> +
>  		remoteproc_adsp: remoteproc@17300000 {
>  			compatible = "qcom,sm8150-adsp-pas";
>  			reg = <0x0 0x17300000 0x0 0x4040>;
> -- 
> 2.26.1
> 

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Jonathan Marek]

On 5/28/20 10:52 PM, Bjorn Andersson wrote:
> On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> 
>> Add the apps_smmu node for sm8150. Note that adding the iommus field for
>> UFS is required because initializing the iommu removes the bypass mapping
>> that created by the bootloader.
>>
> 
> Unrelated to the patch itself; how do you disable the splash screen on
> 8150? "fastboot oem select-display-panel none" doesn't seem to work for
> me on the MTP - and hence this would prevent my device from booting.
> 
> Thanks,
> Bjorn
> 

I don't have a MTP, but on HDK855, "fastboot oem select-display-panel 
none" combined with setting the physical switch to HDMI mode (which 
switches off the 1440x2560 panel) gets it to not setup the display at 
all (just the fastboot command isn't enough).

With HDK865 though that doesn't work and I have a hack to work around it 
(writing 0 to INTF_TIMING_ENGINE_EN early on in boot will stop video 
mode scanout and it won't crash).

>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>>   arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
>>   1 file changed, 91 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> index a36512d1f6a1..acb839427b12 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>   			resets = <&gcc GCC_UFS_PHY_BCR>;
>>   			reset-names = "rst";
>>   
>> +			iommus = <&apps_smmu 0x300 0>;
>> +
>>   			clock-names =
>>   				"core_clk",
>>   				"bus_aggr_clk",
>> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
>>   				compatible = "snps,dwc3";
>>   				reg = <0 0x0a600000 0 0xcd00>;
>>   				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>> +				iommus = <&apps_smmu 0x140 0>;
>>   				snps,dis_u2_susphy_quirk;
>>   				snps,dis_enblslpm_quirk;
>>   				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
>> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
>>   			cell-index = <0>;
>>   		};
>>   
>> +		apps_smmu: iommu@15000000 {
>> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
>> +			reg = <0 0x15000000 0 0x100000>;
>> +			#iommu-cells = <2>;
>> +			#global-interrupts = <1>;
>> +			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
>> +				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
>> +		};
>> +
>>   		remoteproc_adsp: remoteproc@17300000 {
>>   			compatible = "qcom,sm8150-adsp-pas";
>>   			reg = <0x0 0x17300000 0x0 0x4040>;
>> -- 
>> 2.26.1
>>

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Bjorn Andersson]

On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:

> 
> 
> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> > 
> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
> > > UFS is required because initializing the iommu removes the bypass mapping
> > > that created by the bootloader.
> > > 
> > 
> > Unrelated to the patch itself; how do you disable the splash screen on
> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
> > me on the MTP - and hence this would prevent my device from booting.
> > 
> > Thanks,
> > Bjorn
> > 
> 
> I don't have a MTP, but on HDK855, "fastboot oem select-display-panel none"
> combined with setting the physical switch to HDMI mode (which switches off
> the 1440x2560 panel) gets it to not setup the display at all (just the
> fastboot command isn't enough).
> 

Okay, I don't think we have anything equivalent on the MTP, but good to
know.

> With HDK865 though that doesn't work and I have a hack to work around it
> (writing 0 to INTF_TIMING_ENGINE_EN early on in boot will stop video mode
> scanout and it won't crash).
> 

Then we need to sort this out in the arm-smmu driver before we can
enable the apps_smmu node on 8250. I did receive some guidance from Will
on the subject and have started looking into this.

Thanks,
Bjorn

> > > Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> > > ---
> > >   arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
> > >   1 file changed, 91 insertions(+)
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> > > index a36512d1f6a1..acb839427b12 100644
> > > --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> > > @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
> > >   			resets = <&gcc GCC_UFS_PHY_BCR>;
> > >   			reset-names = "rst";
> > > +			iommus = <&apps_smmu 0x300 0>;
> > > +
> > >   			clock-names =
> > >   				"core_clk",
> > >   				"bus_aggr_clk",
> > > @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
> > >   				compatible = "snps,dwc3";
> > >   				reg = <0 0x0a600000 0 0xcd00>;
> > >   				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> > > +				iommus = <&apps_smmu 0x140 0>;
> > >   				snps,dis_u2_susphy_quirk;
> > >   				snps,dis_enblslpm_quirk;
> > >   				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
> > > @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
> > >   			cell-index = <0>;
> > >   		};
> > > +		apps_smmu: iommu@15000000 {
> > > +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> > > +			reg = <0 0x15000000 0 0x100000>;
> > > +			#iommu-cells = <2>;
> > > +			#global-interrupts = <1>;
> > > +			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
> > > +				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
> > > +		};
> > > +
> > >   		remoteproc_adsp: remoteproc@17300000 {
> > >   			compatible = "qcom,sm8150-adsp-pas";
> > >   			reg = <0x0 0x17300000 0x0 0x4040>;
> > > -- 
> > > 2.26.1
> > > 

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Jonathan Marek]

On 5/28/20 11:15 PM, Bjorn Andersson wrote:
> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
> 
>>
>>
>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>>> On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>>>
>>>> Add the apps_smmu node for sm8150. Note that adding the iommus field for
>>>> UFS is required because initializing the iommu removes the bypass mapping
>>>> that created by the bootloader.
>>>>
>>>
>>> Unrelated to the patch itself; how do you disable the splash screen on
>>> 8150? "fastboot oem select-display-panel none" doesn't seem to work for
>>> me on the MTP - and hence this would prevent my device from booting.
>>>
>>> Thanks,
>>> Bjorn
>>>
>>
>> I don't have a MTP, but on HDK855, "fastboot oem select-display-panel none"
>> combined with setting the physical switch to HDMI mode (which switches off
>> the 1440x2560 panel) gets it to not setup the display at all (just the
>> fastboot command isn't enough).
>>
> 
> Okay, I don't think we have anything equivalent on the MTP, but good to
> know.
> 
>> With HDK865 though that doesn't work and I have a hack to work around it
>> (writing 0 to INTF_TIMING_ENGINE_EN early on in boot will stop video mode
>> scanout and it won't crash).
>>
> 
> Then we need to sort this out in the arm-smmu driver before we can
> enable the apps_smmu node on 8250. I did receive some guidance from Will
> on the subject and have started looking into this.
> 

That's annoying because a lot depends on apps_mmu. GPU is an exception 
with its own MMU but pretty much everything else uses apps_smmu (does it 
make sense to add USB nodes if it won't work without apps_smmu?) Is this 
something that will get resolved soon?

FWIW, I have another sm8250 board which does not need the workaround 
(its bootloader does not set up the display). AFAIK modifying the 
bootloader to not set up any display is a trivial modification (assuming 
that's an option).

> Thanks,
> Bjorn
> 
>>>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>>>> ---
>>>>    arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
>>>>    1 file changed, 91 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>>> index a36512d1f6a1..acb839427b12 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>>> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>>>    			resets = <&gcc GCC_UFS_PHY_BCR>;
>>>>    			reset-names = "rst";
>>>> +			iommus = <&apps_smmu 0x300 0>;
>>>> +
>>>>    			clock-names =
>>>>    				"core_clk",
>>>>    				"bus_aggr_clk",
>>>> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
>>>>    				compatible = "snps,dwc3";
>>>>    				reg = <0 0x0a600000 0 0xcd00>;
>>>>    				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>>>> +				iommus = <&apps_smmu 0x140 0>;
>>>>    				snps,dis_u2_susphy_quirk;
>>>>    				snps,dis_enblslpm_quirk;
>>>>    				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
>>>> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
>>>>    			cell-index = <0>;
>>>>    		};
>>>> +		apps_smmu: iommu@15000000 {
>>>> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
>>>> +			reg = <0 0x15000000 0 0x100000>;
>>>> +			#iommu-cells = <2>;
>>>> +			#global-interrupts = <1>;
>>>> +			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
>>>> +				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
>>>> +		};
>>>> +
>>>>    		remoteproc_adsp: remoteproc@17300000 {
>>>>    			compatible = "qcom,sm8150-adsp-pas";
>>>>    			reg = <0x0 0x17300000 0x0 0x4040>;
>>>> -- 
>>>> 2.26.1
>>>>

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Bjorn Andersson]

On Thu 28 May 20:34 PDT 2020, Jonathan Marek wrote:

> On 5/28/20 11:15 PM, Bjorn Andersson wrote:
> > On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
> > 
> > > 
> > > 
> > > On 5/28/20 10:52 PM, Bjorn Andersson wrote:
> > > > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> > > > 
> > > > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
> > > > > UFS is required because initializing the iommu removes the bypass mapping
> > > > > that created by the bootloader.
> > > > > 
> > > > 
> > > > Unrelated to the patch itself; how do you disable the splash screen on
> > > > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
> > > > me on the MTP - and hence this would prevent my device from booting.
> > > > 
> > > > Thanks,
> > > > Bjorn
> > > > 
> > > 
> > > I don't have a MTP, but on HDK855, "fastboot oem select-display-panel none"
> > > combined with setting the physical switch to HDMI mode (which switches off
> > > the 1440x2560 panel) gets it to not setup the display at all (just the
> > > fastboot command isn't enough).
> > > 
> > 
> > Okay, I don't think we have anything equivalent on the MTP, but good to
> > know.
> > 
> > > With HDK865 though that doesn't work and I have a hack to work around it
> > > (writing 0 to INTF_TIMING_ENGINE_EN early on in boot will stop video mode
> > > scanout and it won't crash).
> > > 
> > 
> > Then we need to sort this out in the arm-smmu driver before we can
> > enable the apps_smmu node on 8250. I did receive some guidance from Will
> > on the subject and have started looking into this.
> > 
> 
> That's annoying because a lot depends on apps_mmu. GPU is an exception with
> its own MMU but pretty much everything else uses apps_smmu (does it make
> sense to add USB nodes if it won't work without apps_smmu?) Is this
> something that will get resolved soon?
> 

We have a number of boards where this is becoming a critical issue, so
we better find an acceptable solution to this very soon.

Regards,
Bjorn

> FWIW, I have another sm8250 board which does not need the workaround (its
> bootloader does not set up the display). AFAIK modifying the bootloader to
> not set up any display is a trivial modification (assuming that's an
> option).
> 
> > Thanks,
> > Bjorn
> > 
> > > > > Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> > > > > ---
> > > > >    arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
> > > > >    1 file changed, 91 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> > > > > index a36512d1f6a1..acb839427b12 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
> > > > > +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
> > > > > @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
> > > > >    			resets = <&gcc GCC_UFS_PHY_BCR>;
> > > > >    			reset-names = "rst";
> > > > > +			iommus = <&apps_smmu 0x300 0>;
> > > > > +
> > > > >    			clock-names =
> > > > >    				"core_clk",
> > > > >    				"bus_aggr_clk",
> > > > > @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
> > > > >    				compatible = "snps,dwc3";
> > > > >    				reg = <0 0x0a600000 0 0xcd00>;
> > > > >    				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> > > > > +				iommus = <&apps_smmu 0x140 0>;
> > > > >    				snps,dis_u2_susphy_quirk;
> > > > >    				snps,dis_enblslpm_quirk;
> > > > >    				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
> > > > > @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
> > > > >    			cell-index = <0>;
> > > > >    		};
> > > > > +		apps_smmu: iommu@15000000 {
> > > > > +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> > > > > +			reg = <0 0x15000000 0 0x100000>;
> > > > > +			#iommu-cells = <2>;
> > > > > +			#global-interrupts = <1>;
> > > > > +			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
> > > > > +				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
> > > > > +		};
> > > > > +
> > > > >    		remoteproc_adsp: remoteproc@17300000 {
> > > > >    			compatible = "qcom,sm8150-adsp-pas";
> > > > >    			reg = <0x0 0x17300000 0x0 0x4040>;
> > > > > -- 
> > > > > 2.26.1
> > > > > 

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Jonathan Marek]

On 5/28/20 11:42 PM, Bjorn Andersson wrote:
> On Thu 28 May 20:34 PDT 2020, Jonathan Marek wrote:
> 
>> On 5/28/20 11:15 PM, Bjorn Andersson wrote:
>>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
>>>
>>>>
>>>>
>>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>>>>> On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>>>>>
>>>>>> Add the apps_smmu node for sm8150. Note that adding the iommus field for
>>>>>> UFS is required because initializing the iommu removes the bypass mapping
>>>>>> that created by the bootloader.
>>>>>>
>>>>>
>>>>> Unrelated to the patch itself; how do you disable the splash screen on
>>>>> 8150? "fastboot oem select-display-panel none" doesn't seem to work for
>>>>> me on the MTP - and hence this would prevent my device from booting.
>>>>>
>>>>> Thanks,
>>>>> Bjorn
>>>>>
>>>>
>>>> I don't have a MTP, but on HDK855, "fastboot oem select-display-panel none"
>>>> combined with setting the physical switch to HDMI mode (which switches off
>>>> the 1440x2560 panel) gets it to not setup the display at all (just the
>>>> fastboot command isn't enough).
>>>>
>>>
>>> Okay, I don't think we have anything equivalent on the MTP, but good to
>>> know.
>>>
>>>> With HDK865 though that doesn't work and I have a hack to work around it
>>>> (writing 0 to INTF_TIMING_ENGINE_EN early on in boot will stop video mode
>>>> scanout and it won't crash).
>>>>
>>>
>>> Then we need to sort this out in the arm-smmu driver before we can
>>> enable the apps_smmu node on 8250. I did receive some guidance from Will
>>> on the subject and have started looking into this.
>>>
>>
>> That's annoying because a lot depends on apps_mmu. GPU is an exception with
>> its own MMU but pretty much everything else uses apps_smmu (does it make
>> sense to add USB nodes if it won't work without apps_smmu?) Is this
>> something that will get resolved soon?
>>
> 
> We have a number of boards where this is becoming a critical issue, so
> we better find an acceptable solution to this very soon.
> 

I kept the sm8250 apps_smmu patch in V2:

I am now using a modified xbl with my HDK865, with a hack to make it use 
"none" for the display override string, and that allows me to use these 
patches without any kernel hack.

The "fastboot oem select-display-panel none" not working to disable 
bootloader enabled display definitely seems like a bug (I have not tried 
to debug it, but everything I've seen indicates that it should be 
disabling it). I don't think we should be holding this back based on a 
bootloader bug.

> Regards,
> Bjorn
> 
>> FWIW, I have another sm8250 board which does not need the workaround (its
>> bootloader does not set up the display). AFAIK modifying the bootloader to
>> not set up any display is a trivial modification (assuming that's an
>> option).
>>
>>> Thanks,
>>> Bjorn
>>>
>>>>>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>>>>>> ---
>>>>>>     arch/arm64/boot/dts/qcom/sm8150.dtsi | 91 ++++++++++++++++++++++++++++
>>>>>>     1 file changed, 91 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>>>>> index a36512d1f6a1..acb839427b12 100644
>>>>>> --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
>>>>>> @@ -442,6 +442,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>>>>>     			resets = <&gcc GCC_UFS_PHY_BCR>;
>>>>>>     			reset-names = "rst";
>>>>>> +			iommus = <&apps_smmu 0x300 0>;
>>>>>> +
>>>>>>     			clock-names =
>>>>>>     				"core_clk",
>>>>>>     				"bus_aggr_clk",
>>>>>> @@ -706,6 +708,7 @@ usb_1_dwc3: dwc3@a600000 {
>>>>>>     				compatible = "snps,dwc3";
>>>>>>     				reg = <0 0x0a600000 0 0xcd00>;
>>>>>>     				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> +				iommus = <&apps_smmu 0x140 0>;
>>>>>>     				snps,dis_u2_susphy_quirk;
>>>>>>     				snps,dis_enblslpm_quirk;
>>>>>>     				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
>>>>>> @@ -742,6 +745,94 @@ spmi_bus: spmi@c440000 {
>>>>>>     			cell-index = <0>;
>>>>>>     		};
>>>>>> +		apps_smmu: iommu@15000000 {
>>>>>> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
>>>>>> +			reg = <0 0x15000000 0 0x100000>;
>>>>>> +			#iommu-cells = <2>;
>>>>>> +			#global-interrupts = <1>;
>>>>>> +			interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
>>>>>> +				     <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
>>>>>> +		};
>>>>>> +
>>>>>>     		remoteproc_adsp: remoteproc@17300000 {
>>>>>>     			compatible = "qcom,sm8150-adsp-pas";
>>>>>>     			reg = <0x0 0x17300000 0x0 0x4040>;
>>>>>> -- 
>>>>>> 2.26.1
>>>>>>

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-05-29 08:45, Bjorn Andersson wrote:
> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
> 
>> 
>> 
>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>> >
>> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
>> > > UFS is required because initializing the iommu removes the bypass mapping
>> > > that created by the bootloader.
>> > >
>> >
>> > Unrelated to the patch itself; how do you disable the splash screen on
>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
>> > me on the MTP - and hence this would prevent my device from booting.
>> >
>> > Thanks,
>> > Bjorn
>> >
>> 
>> I don't have a MTP, but on HDK855, "fastboot oem select-display-panel 
>> none"
>> combined with setting the physical switch to HDMI mode (which switches 
>> off
>> the 1440x2560 panel) gets it to not setup the display at all (just the
>> fastboot command isn't enough).
>> 
> 
> Okay, I don't think we have anything equivalent on the MTP, but good to
> know.
> 

Actually I tried out this in SM8150 MTP and it works fine for me,

"fastboot set_active a; fastboot set_active b; fastboot set_active a; 
fastboot oem select-display-panel none; fastboot reboot bootloader; 
fastboot boot boot-sm8150.img"

Also I need to switch slots everytime like above, otherwise I always see 
some error
while loading the boot image.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Jonathan Marek]

On 6/5/20 10:03 AM, Sai Prakash Ranjan wrote:
> On 2020-05-29 08:45, Bjorn Andersson wrote:
>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
>>
>>>
>>>
>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>>> >
>>> > > Add the apps_smmu node for sm8150. Note that adding the iommus 
>>> field for
>>> > > UFS is required because initializing the iommu removes the bypass 
>>> mapping
>>> > > that created by the bootloader.
>>> > >
>>> >
>>> > Unrelated to the patch itself; how do you disable the splash screen on
>>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work 
>>> for
>>> > me on the MTP - and hence this would prevent my device from booting.
>>> >
>>> > Thanks,
>>> > Bjorn
>>> >
>>>
>>> I don't have a MTP, but on HDK855, "fastboot oem select-display-panel 
>>> none"
>>> combined with setting the physical switch to HDMI mode (which 
>>> switches off
>>> the 1440x2560 panel) gets it to not setup the display at all (just the
>>> fastboot command isn't enough).
>>>
>>
>> Okay, I don't think we have anything equivalent on the MTP, but good to
>> know.
>>
> 
> Actually I tried out this in SM8150 MTP and it works fine for me,
> 
> "fastboot set_active a; fastboot set_active b; fastboot set_active a; 
> fastboot oem select-display-panel none; fastboot reboot bootloader; 
> fastboot boot boot-sm8150.img"
> 
> Also I need to switch slots everytime like above, otherwise I always see 
> some error
> while loading the boot image.
> 

What is the error? If it is "FAILED (remote: Failed to load/authenticate 
boot image: Load Error)" then flashing/erasing boot_a will make it go 
away ("fastboot erase boot_a") for the next 6 or so "failed" boots.

> Thanks,
> Sai
> 

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-06-05 19:40, Jonathan Marek wrote:
> On 6/5/20 10:03 AM, Sai Prakash Ranjan wrote:
>> On 2020-05-29 08:45, Bjorn Andersson wrote:
>>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
>>> 
>>>> 
>>>> 
>>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>>>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>>>> >
>>>> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
>>>> > > UFS is required because initializing the iommu removes the bypass mapping
>>>> > > that created by the bootloader.
>>>> > >
>>>> >
>>>> > Unrelated to the patch itself; how do you disable the splash screen on
>>>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
>>>> > me on the MTP - and hence this would prevent my device from booting.
>>>> >
>>>> > Thanks,
>>>> > Bjorn
>>>> >
>>>> 
>>>> I don't have a MTP, but on HDK855, "fastboot oem 
>>>> select-display-panel none"
>>>> combined with setting the physical switch to HDMI mode (which 
>>>> switches off
>>>> the 1440x2560 panel) gets it to not setup the display at all (just 
>>>> the
>>>> fastboot command isn't enough).
>>>> 
>>> 
>>> Okay, I don't think we have anything equivalent on the MTP, but good 
>>> to
>>> know.
>>> 
>> 
>> Actually I tried out this in SM8150 MTP and it works fine for me,
>> 
>> "fastboot set_active a; fastboot set_active b; fastboot set_active a; 
>> fastboot oem select-display-panel none; fastboot reboot bootloader; 
>> fastboot boot boot-sm8150.img"
>> 
>> Also I need to switch slots everytime like above, otherwise I always 
>> see some error
>> while loading the boot image.
>> 
> 
> What is the error? If it is "FAILED (remote: Failed to
> load/authenticate boot image: Load Error)" then flashing/erasing
> boot_a will make it go away ("fastboot erase boot_a") for the next 6
> or so "failed" boots.
> 

Yes this exact error.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Nicolas Dechesne]

On Fri, Jun 5, 2020 at 4:14 PM Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> On 2020-06-05 19:40, Jonathan Marek wrote:
> > On 6/5/20 10:03 AM, Sai Prakash Ranjan wrote:
> >> On 2020-05-29 08:45, Bjorn Andersson wrote:
> >>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
> >>>
> >>>>
> >>>>
> >>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
> >>>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> >>>> >
> >>>> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
> >>>> > > UFS is required because initializing the iommu removes the bypass mapping
> >>>> > > that created by the bootloader.
> >>>> > >
> >>>> >
> >>>> > Unrelated to the patch itself; how do you disable the splash screen on
> >>>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
> >>>> > me on the MTP - and hence this would prevent my device from booting.
> >>>> >
> >>>> > Thanks,
> >>>> > Bjorn
> >>>> >
> >>>>
> >>>> I don't have a MTP, but on HDK855, "fastboot oem
> >>>> select-display-panel none"
> >>>> combined with setting the physical switch to HDMI mode (which
> >>>> switches off
> >>>> the 1440x2560 panel) gets it to not setup the display at all (just
> >>>> the
> >>>> fastboot command isn't enough).
> >>>>
> >>>
> >>> Okay, I don't think we have anything equivalent on the MTP, but good
> >>> to
> >>> know.
> >>>
> >>
> >> Actually I tried out this in SM8150 MTP and it works fine for me,
> >>
> >> "fastboot set_active a; fastboot set_active b; fastboot set_active a;
> >> fastboot oem select-display-panel none; fastboot reboot bootloader;
> >> fastboot boot boot-sm8150.img"
> >>
> >> Also I need to switch slots everytime like above, otherwise I always
> >> see some error
> >> while loading the boot image.
> >>
> >
> > What is the error? If it is "FAILED (remote: Failed to
> > load/authenticate boot image: Load Error)" then flashing/erasing
> > boot_a will make it go away ("fastboot erase boot_a") for the next 6
> > or so "failed" boots.
> >
>
> Yes this exact error.

The bootloader maintains a 'boot status' in one of the partition
attributes. After a certain amount of 'failed' boot , it will switch
to the other boot partition. It's the same thing on RB3/DB845c. In our
release for DB845c, we are patching the bootloader so that this
behavior is bypassed. On typical 'product' there is a user space
application that will come and set the partition attribute to indicate
the boot was successful.

For the record, this is the patch we use on 845c:
https://git.linaro.org/landing-teams/working/qualcomm/abl.git/commit/?h=release/LE.UM.2.3.7-09200-sda845.0&id=e3dc60213234ed626161a568ba587ddac63c5158

rebuilding EDK2/ABL requires access to signing tools.. so it might not
be possible for everyone. but in case you can, it should be
straightforward to reuse this patch.

>
>
> -Sai
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Sai Prakash Ranjan]

Hi Nico,

On 2020-06-05 20:01, Nicolas Dechesne wrote:
> On Fri, Jun 5, 2020 at 4:14 PM Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>> 
>> On 2020-06-05 19:40, Jonathan Marek wrote:
>> > On 6/5/20 10:03 AM, Sai Prakash Ranjan wrote:
>> >> On 2020-05-29 08:45, Bjorn Andersson wrote:
>> >>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
>> >>>
>> >>>>
>> >>>>
>> >>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>> >>>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>> >>>> >
>> >>>> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
>> >>>> > > UFS is required because initializing the iommu removes the bypass mapping
>> >>>> > > that created by the bootloader.
>> >>>> > >
>> >>>> >
>> >>>> > Unrelated to the patch itself; how do you disable the splash screen on
>> >>>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
>> >>>> > me on the MTP - and hence this would prevent my device from booting.
>> >>>> >
>> >>>> > Thanks,
>> >>>> > Bjorn
>> >>>> >
>> >>>>
>> >>>> I don't have a MTP, but on HDK855, "fastboot oem
>> >>>> select-display-panel none"
>> >>>> combined with setting the physical switch to HDMI mode (which
>> >>>> switches off
>> >>>> the 1440x2560 panel) gets it to not setup the display at all (just
>> >>>> the
>> >>>> fastboot command isn't enough).
>> >>>>
>> >>>
>> >>> Okay, I don't think we have anything equivalent on the MTP, but good
>> >>> to
>> >>> know.
>> >>>
>> >>
>> >> Actually I tried out this in SM8150 MTP and it works fine for me,
>> >>
>> >> "fastboot set_active a; fastboot set_active b; fastboot set_active a;
>> >> fastboot oem select-display-panel none; fastboot reboot bootloader;
>> >> fastboot boot boot-sm8150.img"
>> >>
>> >> Also I need to switch slots everytime like above, otherwise I always
>> >> see some error
>> >> while loading the boot image.
>> >>
>> >
>> > What is the error? If it is "FAILED (remote: Failed to
>> > load/authenticate boot image: Load Error)" then flashing/erasing
>> > boot_a will make it go away ("fastboot erase boot_a") for the next 6
>> > or so "failed" boots.
>> >
>> 
>> Yes this exact error.
> 
> The bootloader maintains a 'boot status' in one of the partition
> attributes. After a certain amount of 'failed' boot , it will switch
> to the other boot partition. It's the same thing on RB3/DB845c. In our
> release for DB845c, we are patching the bootloader so that this
> behavior is bypassed. On typical 'product' there is a user space
> application that will come and set the partition attribute to indicate
> the boot was successful.
> 
> For the record, this is the patch we use on 845c:
> https://git.linaro.org/landing-teams/working/qualcomm/abl.git/commit/?h=release/LE.UM.2.3.7-09200-sda845.0&id=e3dc60213234ed626161a568ba587ddac63c5158
> 
> rebuilding EDK2/ABL requires access to signing tools.. so it might not
> be possible for everyone. but in case you can, it should be
> straightforward to reuse this patch.
> 

Thank you for these details and the patch, it's very useful.
I do have access to ABL code and the signing tools and can build one.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Nicolas Dechesne]

On Fri, Jun 5, 2020 at 4:39 PM Sai Prakash Ranjan
<saiprakash.ranjan@codeaurora.org> wrote:
>
> Hi Nico,
>
> On 2020-06-05 20:01, Nicolas Dechesne wrote:
> > On Fri, Jun 5, 2020 at 4:14 PM Sai Prakash Ranjan
> > <saiprakash.ranjan@codeaurora.org> wrote:
> >>
> >> On 2020-06-05 19:40, Jonathan Marek wrote:
> >> > On 6/5/20 10:03 AM, Sai Prakash Ranjan wrote:
> >> >> On 2020-05-29 08:45, Bjorn Andersson wrote:
> >> >>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
> >> >>>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> >> >>>> >
> >> >>>> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
> >> >>>> > > UFS is required because initializing the iommu removes the bypass mapping
> >> >>>> > > that created by the bootloader.
> >> >>>> > >
> >> >>>> >
> >> >>>> > Unrelated to the patch itself; how do you disable the splash screen on
> >> >>>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
> >> >>>> > me on the MTP - and hence this would prevent my device from booting.
> >> >>>> >
> >> >>>> > Thanks,
> >> >>>> > Bjorn
> >> >>>> >
> >> >>>>
> >> >>>> I don't have a MTP, but on HDK855, "fastboot oem
> >> >>>> select-display-panel none"
> >> >>>> combined with setting the physical switch to HDMI mode (which
> >> >>>> switches off
> >> >>>> the 1440x2560 panel) gets it to not setup the display at all (just
> >> >>>> the
> >> >>>> fastboot command isn't enough).
> >> >>>>
> >> >>>
> >> >>> Okay, I don't think we have anything equivalent on the MTP, but good
> >> >>> to
> >> >>> know.
> >> >>>
> >> >>
> >> >> Actually I tried out this in SM8150 MTP and it works fine for me,
> >> >>
> >> >> "fastboot set_active a; fastboot set_active b; fastboot set_active a;
> >> >> fastboot oem select-display-panel none; fastboot reboot bootloader;
> >> >> fastboot boot boot-sm8150.img"
> >> >>
> >> >> Also I need to switch slots everytime like above, otherwise I always
> >> >> see some error
> >> >> while loading the boot image.
> >> >>
> >> >
> >> > What is the error? If it is "FAILED (remote: Failed to
> >> > load/authenticate boot image: Load Error)" then flashing/erasing
> >> > boot_a will make it go away ("fastboot erase boot_a") for the next 6
> >> > or so "failed" boots.
> >> >
> >>
> >> Yes this exact error.
> >
> > The bootloader maintains a 'boot status' in one of the partition
> > attributes. After a certain amount of 'failed' boot , it will switch
> > to the other boot partition. It's the same thing on RB3/DB845c. In our
> > release for DB845c, we are patching the bootloader so that this
> > behavior is bypassed. On typical 'product' there is a user space
> > application that will come and set the partition attribute to indicate
> > the boot was successful.
> >
> > For the record, this is the patch we use on 845c:
> > https://git.linaro.org/landing-teams/working/qualcomm/abl.git/commit/?h=release/LE.UM.2.3.7-09200-sda845.0&id=e3dc60213234ed626161a568ba587ddac63c5158
> >
> > rebuilding EDK2/ABL requires access to signing tools.. so it might not
> > be possible for everyone. but in case you can, it should be
> > straightforward to reuse this patch.
> >
>
> Thank you for these details and the patch, it's very useful.
> I do have access to ABL code and the signing tools and can build one.

Good. Then the next problem you will likely face is that building QCOM
ABL is far from being straightforward. Why would it be? ;)
That's the script we use to build it ourselves:
https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader/dragonboard845c/builders.sh#n61

It has a reference to sectools which we have (internally) access to,
but you have it too, and you should be able to leverage most of the
script.

>
> Thanks,
> Sai
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member
> of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-06-05 20:21, Nicolas Dechesne wrote:
> On Fri, Jun 5, 2020 at 4:39 PM Sai Prakash Ranjan
> <saiprakash.ranjan@codeaurora.org> wrote:
>> 
>> Hi Nico,
>> 
>> On 2020-06-05 20:01, Nicolas Dechesne wrote:
>> > On Fri, Jun 5, 2020 at 4:14 PM Sai Prakash Ranjan
>> > <saiprakash.ranjan@codeaurora.org> wrote:
>> >>
>> >> On 2020-06-05 19:40, Jonathan Marek wrote:
>> >> > On 6/5/20 10:03 AM, Sai Prakash Ranjan wrote:
>> >> >> On 2020-05-29 08:45, Bjorn Andersson wrote:
>> >> >>> On Thu 28 May 20:02 PDT 2020, Jonathan Marek wrote:
>> >> >>>
>> >> >>>>
>> >> >>>>
>> >> >>>> On 5/28/20 10:52 PM, Bjorn Andersson wrote:
>> >> >>>> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
>> >> >>>> >
>> >> >>>> > > Add the apps_smmu node for sm8150. Note that adding the iommus field for
>> >> >>>> > > UFS is required because initializing the iommu removes the bypass mapping
>> >> >>>> > > that created by the bootloader.
>> >> >>>> > >
>> >> >>>> >
>> >> >>>> > Unrelated to the patch itself; how do you disable the splash screen on
>> >> >>>> > 8150? "fastboot oem select-display-panel none" doesn't seem to work for
>> >> >>>> > me on the MTP - and hence this would prevent my device from booting.
>> >> >>>> >
>> >> >>>> > Thanks,
>> >> >>>> > Bjorn
>> >> >>>> >
>> >> >>>>
>> >> >>>> I don't have a MTP, but on HDK855, "fastboot oem
>> >> >>>> select-display-panel none"
>> >> >>>> combined with setting the physical switch to HDMI mode (which
>> >> >>>> switches off
>> >> >>>> the 1440x2560 panel) gets it to not setup the display at all (just
>> >> >>>> the
>> >> >>>> fastboot command isn't enough).
>> >> >>>>
>> >> >>>
>> >> >>> Okay, I don't think we have anything equivalent on the MTP, but good
>> >> >>> to
>> >> >>> know.
>> >> >>>
>> >> >>
>> >> >> Actually I tried out this in SM8150 MTP and it works fine for me,
>> >> >>
>> >> >> "fastboot set_active a; fastboot set_active b; fastboot set_active a;
>> >> >> fastboot oem select-display-panel none; fastboot reboot bootloader;
>> >> >> fastboot boot boot-sm8150.img"
>> >> >>
>> >> >> Also I need to switch slots everytime like above, otherwise I always
>> >> >> see some error
>> >> >> while loading the boot image.
>> >> >>
>> >> >
>> >> > What is the error? If it is "FAILED (remote: Failed to
>> >> > load/authenticate boot image: Load Error)" then flashing/erasing
>> >> > boot_a will make it go away ("fastboot erase boot_a") for the next 6
>> >> > or so "failed" boots.
>> >> >
>> >>
>> >> Yes this exact error.
>> >
>> > The bootloader maintains a 'boot status' in one of the partition
>> > attributes. After a certain amount of 'failed' boot , it will switch
>> > to the other boot partition. It's the same thing on RB3/DB845c. In our
>> > release for DB845c, we are patching the bootloader so that this
>> > behavior is bypassed. On typical 'product' there is a user space
>> > application that will come and set the partition attribute to indicate
>> > the boot was successful.
>> >
>> > For the record, this is the patch we use on 845c:
>> > https://git.linaro.org/landing-teams/working/qualcomm/abl.git/commit/?h=release/LE.UM.2.3.7-09200-sda845.0&id=e3dc60213234ed626161a568ba587ddac63c5158
>> >
>> > rebuilding EDK2/ABL requires access to signing tools.. so it might not
>> > be possible for everyone. but in case you can, it should be
>> > straightforward to reuse this patch.
>> >
>> 
>> Thank you for these details and the patch, it's very useful.
>> I do have access to ABL code and the signing tools and can build one.
> 
> Good. Then the next problem you will likely face is that building QCOM
> ABL is far from being straightforward. Why would it be? ;)
> That's the script we use to build it ourselves:
> https://git.linaro.org/ci/job/configs.git/tree/lt-qcom-bootloader/dragonboard845c/builders.sh#n61
> 
> It has a reference to sectools which we have (internally) access to,
> but you have it too, and you should be able to leverage most of the
> script.

Looks like a cool tool, will definitely try it out :) Also internally we 
have another
tool to build ABL(if you are aware of kdev then you will know what this 
is called, guess ;))
which takes care of cloning and building and signing all the things 
required
(although very weirdly it clones sectools everytime which should be 
fixed, I just comment
that part out when I build) and all it takes is one command "make" :)

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Jonathan Marek]

Add the apps_smmu node for sm8250. Note that adding the iommus field for
UFS is required because initializing the iommu removes the bypass mapping
that created by the bootloader.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 2f99c350c287..43c5e48c15e2 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
 
 			power-domains = <&gcc UFS_PHY_GDSC>;
 
+			iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
+
 			clock-names =
 				"core_clk",
 				"bus_aggr_clk",
@@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
 			wakeup-parent = <&pdc>;
 		};
 
+		apps_smmu: iommu@15000000 {
+			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
+			reg = <0 0x15000000 0 0x100000>;
+			#iommu-cells = <2>;
+			#global-interrupts = <2>;
+			interrupts =    <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 319 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 320 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 321 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 322 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 325 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 326 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 328 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 330 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 332 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 333 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 334 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 335 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 336 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 337 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 338 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 339 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 340 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 344 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 345 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 405 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 406 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 407 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 408 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 412 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 418 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 419 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 421 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 423 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 690 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 691 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 692 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 693 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 694 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 695 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 696 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 707 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
 		intc: interrupt-controller@17a00000 {
 			compatible = "arm,gic-v3";
 			#interrupt-cells = <3>;
-- 
2.26.1

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Sai Prakash Ranjan]

Hi Jonathan,

On 2020-05-24 08:08, Jonathan Marek wrote:
> Add the apps_smmu node for sm8250. Note that adding the iommus field 
> for
> UFS is required because initializing the iommu removes the bypass 
> mapping
> that created by the bootloader.
> 

This statement doesn't seem right, you can just say since the bypass is 
disabled
by default now, we need to add this property to enable translation and 
avoid global faults.

> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
>  arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
>  1 file changed, 107 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> index 2f99c350c287..43c5e48c15e2 100644
> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
> 
>  			power-domains = <&gcc UFS_PHY_GDSC>;
> 
> +			iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
> +
>  			clock-names =
>  				"core_clk",
>  				"bus_aggr_clk",
> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
>  			wakeup-parent = <&pdc>;
>  		};
> 
> +		apps_smmu: iommu@15000000 {
> +			compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";

This should be qcom,sm8250-smmu-500 and also you need to update the 
arm-smmu
binding with this compatible in a separate patch.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Jonathan Marek]

Hi,

On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
> Hi Jonathan,
> 
> On 2020-05-24 08:08, Jonathan Marek wrote:
>> Add the apps_smmu node for sm8250. Note that adding the iommus field for
>> UFS is required because initializing the iommu removes the bypass mapping
>> that created by the bootloader.
>>
> 
> This statement doesn't seem right, you can just say since the bypass is 
> disabled
> by default now, we need to add this property to enable translation and 
> avoid global faults.
> 

If I use this patch [1] then the UFS iommu property isn't needed. In 
downstream, the identity (bypass?) stream mapping is inherited from the 
bootloader, and UFS is used without any iommu property. Setting 
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own 
(without the UFS iommu property), so there's more to it than just 
"bypass is disabled by default now".

https://patchwork.kernel.org/patch/11310757/

>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>>  arch/arm64/boot/dts/qcom/sm8250.dtsi | 107 +++++++++++++++++++++++++++
>>  1 file changed, 107 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> index 2f99c350c287..43c5e48c15e2 100644
>> --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> @@ -323,6 +323,8 @@ ufs_mem_hc: ufshc@1d84000 {
>>
>>              power-domains = <&gcc UFS_PHY_GDSC>;
>>
>> +            iommus = <&apps_smmu 0x0e0 0>, <&apps_smmu 0x4e0 0>;
>> +
>>              clock-names =
>>                  "core_clk",
>>                  "bus_aggr_clk",
>> @@ -428,6 +430,111 @@ tlmm: pinctrl@f100000 {
>>              wakeup-parent = <&pdc>;
>>          };
>>
>> +        apps_smmu: iommu@15000000 {
>> +            compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
> 
> This should be qcom,sm8250-smmu-500 and also you need to update the 
> arm-smmu
> binding with this compatible in a separate patch.
> 
> -Sai
> 

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-05-25 15:39, Jonathan Marek wrote:
> Hi,
> 
> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>> Hi Jonathan,
>> 
>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>> Add the apps_smmu node for sm8250. Note that adding the iommus field 
>>> for
>>> UFS is required because initializing the iommu removes the bypass 
>>> mapping
>>> that created by the bootloader.
>>> 
>> 
>> This statement doesn't seem right, you can just say since the bypass 
>> is disabled
>> by default now, we need to add this property to enable translation and 
>> avoid global faults.
>> 
> 
> If I use this patch [1] then the UFS iommu property isn't needed. In
> downstream, the identity (bypass?) stream mapping is inherited from
> the bootloader, and UFS is used without any iommu property. Setting
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
> (without the UFS iommu property), so there's more to it than just
> "bypass is disabled by default now".
> 
> https://patchwork.kernel.org/patch/11310757/
> 

"iommus" property is not about inheriting stream mapping from 
bootloader,
it is used to enable SMMU address translation for the corresponding
master when specified. So when you have disabled bypass, i.e.,
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
"arm-smmu.disable_bypass=1"
and iommus property with SID and mask is not specified, then it will 
result
in SMMU global faults.

Downstream has bypass enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so 
you
won't see any global faults if you do not have iommus property.

Patch in your link is for display because of the usecase for splash 
screen
on android and some other devices where the bootloader will configure 
SMMU,
it has not yet merged and not likely to get merged in the current state.

So yes "there is *not* much more to it than bypass is disabled by 
default now"
and you have to specify "iommus" for the master devices or you should 
enable bypass,
i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or arm-smmu.disable_bypass=n

Try without the patch in the link and without iommus for UFS and
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.

-Sai
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Jonathan Marek]

On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
> On 2020-05-25 15:39, Jonathan Marek wrote:
>> Hi,
>>
>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>> Hi Jonathan,
>>>
>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>> Add the apps_smmu node for sm8250. Note that adding the iommus field 
>>>> for
>>>> UFS is required because initializing the iommu removes the bypass 
>>>> mapping
>>>> that created by the bootloader.
>>>>
>>>
>>> This statement doesn't seem right, you can just say since the bypass 
>>> is disabled
>>> by default now, we need to add this property to enable translation 
>>> and avoid global faults.
>>>
>>
>> If I use this patch [1] then the UFS iommu property isn't needed. In
>> downstream, the identity (bypass?) stream mapping is inherited from
>> the bootloader, and UFS is used without any iommu property. Setting
>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
>> (without the UFS iommu property), so there's more to it than just
>> "bypass is disabled by default now".
>>
>> https://patchwork.kernel.org/patch/11310757/
>>
> 
> "iommus" property is not about inheriting stream mapping from bootloader,
> it is used to enable SMMU address translation for the corresponding
> master when specified. So when you have disabled bypass, i.e.,
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
> "arm-smmu.disable_bypass=1"
> and iommus property with SID and mask is not specified, then it will result
> in SMMU global faults.
> 
> Downstream has bypass enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
> won't see any global faults if you do not have iommus property.
> 
> Patch in your link is for display because of the usecase for splash screen
> on android and some other devices where the bootloader will configure SMMU,
> it has not yet merged and not likely to get merged in the current state.
> 
> So yes "there is *not* much more to it than bypass is disabled by 
> default now"
> and you have to specify "iommus" for the master devices or you should 
> enable bypass,
> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or arm-smmu.disable_bypass=n
> 
> Try without the patch in the link and without iommus for UFS and
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
> 
> -Sai

I know that the "iommus" property is not about inheriting stream 
mapping. Probing the iommu removes the stream mapping created by the 
bootloader, the iommus property is added so that new mappings are 
created to replace what was removed.

You seem to be under the impression that the SM8150/SM8250 bootloader 
does not configure SMMU. It does, for both UFS and SDHC, just like it 
does for display/splash screen on some devices.

With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not 
work without the iommus property.

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Sai Prakash Ranjan]

Hi,

On 2020-05-25 16:38, Jonathan Marek wrote:
> On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
>> On 2020-05-25 15:39, Jonathan Marek wrote:
>>> Hi,
>>> 
>>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>>> Hi Jonathan,
>>>> 
>>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>>> Add the apps_smmu node for sm8250. Note that adding the iommus 
>>>>> field for
>>>>> UFS is required because initializing the iommu removes the bypass 
>>>>> mapping
>>>>> that created by the bootloader.
>>>>> 
>>>> 
>>>> This statement doesn't seem right, you can just say since the bypass 
>>>> is disabled
>>>> by default now, we need to add this property to enable translation 
>>>> and avoid global faults.
>>>> 
>>> 
>>> If I use this patch [1] then the UFS iommu property isn't needed. In
>>> downstream, the identity (bypass?) stream mapping is inherited from
>>> the bootloader, and UFS is used without any iommu property. Setting
>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
>>> (without the UFS iommu property), so there's more to it than just
>>> "bypass is disabled by default now".
>>> 
>>> https://patchwork.kernel.org/patch/11310757/
>>> 
>> 
>> "iommus" property is not about inheriting stream mapping from 
>> bootloader,
>> it is used to enable SMMU address translation for the corresponding
>> master when specified. So when you have disabled bypass, i.e.,
>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
>> "arm-smmu.disable_bypass=1"
>> and iommus property with SID and mask is not specified, then it will 
>> result
>> in SMMU global faults.
>> 
>> Downstream has bypass enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so 
>> you
>> won't see any global faults if you do not have iommus property.
>> 
>> Patch in your link is for display because of the usecase for splash 
>> screen
>> on android and some other devices where the bootloader will configure 
>> SMMU,
>> it has not yet merged and not likely to get merged in the current 
>> state.
>> 
>> So yes "there is *not* much more to it than bypass is disabled by 
>> default now"
>> and you have to specify "iommus" for the master devices or you should 
>> enable bypass,
>> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or 
>> arm-smmu.disable_bypass=n
>> 
>> Try without the patch in the link and without iommus for UFS and
>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>> 
>> -Sai
> 
> I know that the "iommus" property is not about inheriting stream
> mapping. Probing the iommu removes the stream mapping created by the
> bootloader, the iommus property is added so that new mappings are
> created to replace what was removed.
> 
> You seem to be under the impression that the SM8150/SM8250 bootloader
> does not configure SMMU. It does, for both UFS and SDHC, just like it
> does for display/splash screen on some devices.
> 

It could be that bootloader does configure SMMU for UFS and SDHC, but 
the
upstream SMMU driver doesnt allow to inherit stream mapping from the 
bootloader
yet, so adding iommus property based on the assumption that it is 
inherited seems
wrong.

> With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not
> work without the iommus property.

I'm pretty sure that if you have ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n 
and
without iommus, it should work.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Jonathan Marek]

On 5/25/20 7:17 AM, Sai Prakash Ranjan wrote:
> Hi,
> 
> On 2020-05-25 16:38, Jonathan Marek wrote:
>> On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
>>> On 2020-05-25 15:39, Jonathan Marek wrote:
>>>> Hi,
>>>>
>>>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>>>> Add the apps_smmu node for sm8250. Note that adding the iommus 
>>>>>> field for
>>>>>> UFS is required because initializing the iommu removes the bypass 
>>>>>> mapping
>>>>>> that created by the bootloader.
>>>>>>
>>>>>
>>>>> This statement doesn't seem right, you can just say since the 
>>>>> bypass is disabled
>>>>> by default now, we need to add this property to enable translation 
>>>>> and avoid global faults.
>>>>>
>>>>
>>>> If I use this patch [1] then the UFS iommu property isn't needed. In
>>>> downstream, the identity (bypass?) stream mapping is inherited from
>>>> the bootloader, and UFS is used without any iommu property. Setting
>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
>>>> (without the UFS iommu property), so there's more to it than just
>>>> "bypass is disabled by default now".
>>>>
>>>> https://patchwork.kernel.org/patch/11310757/
>>>>
>>>
>>> "iommus" property is not about inheriting stream mapping from 
>>> bootloader,
>>> it is used to enable SMMU address translation for the corresponding
>>> master when specified. So when you have disabled bypass, i.e.,
>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
>>> "arm-smmu.disable_bypass=1"
>>> and iommus property with SID and mask is not specified, then it will 
>>> result
>>> in SMMU global faults.
>>>
>>> Downstream has bypass 
>>> enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
>>> won't see any global faults if you do not have iommus property.
>>>
>>> Patch in your link is for display because of the usecase for splash 
>>> screen
>>> on android and some other devices where the bootloader will configure 
>>> SMMU,
>>> it has not yet merged and not likely to get merged in the current state.
>>>
>>> So yes "there is *not* much more to it than bypass is disabled by 
>>> default now"
>>> and you have to specify "iommus" for the master devices or you should 
>>> enable bypass,
>>> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or arm-smmu.disable_bypass=n
>>>
>>> Try without the patch in the link and without iommus for UFS and
>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>>>
>>> -Sai
>>
>> I know that the "iommus" property is not about inheriting stream
>> mapping. Probing the iommu removes the stream mapping created by the
>> bootloader, the iommus property is added so that new mappings are
>> created to replace what was removed.
>>
>> You seem to be under the impression that the SM8150/SM8250 bootloader
>> does not configure SMMU. It does, for both UFS and SDHC, just like it
>> does for display/splash screen on some devices.
>>
> 
> It could be that bootloader does configure SMMU for UFS and SDHC, but the
> upstream SMMU driver doesnt allow to inherit stream mapping from the 
> bootloader
> yet, so adding iommus property based on the assumption that it is 
> inherited seems
> wrong.
> 

I never said adding the iommus property is for inheriting stream 
mapping. I mentioned inheriting to say UFS works without the iommus 
property on downstream (it inherits a identity/bypass mapping).

>> With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not
>> work without the iommus property.
> 
> I'm pretty sure that if you have ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n and
> without iommus, it should work.
> 

It doesn't work, with either ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or 
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y.

> -Sai
> 

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-05-25 16:57, Jonathan Marek wrote:
> On 5/25/20 7:17 AM, Sai Prakash Ranjan wrote:
>> Hi,
>> 
>> On 2020-05-25 16:38, Jonathan Marek wrote:
>>> On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
>>>> On 2020-05-25 15:39, Jonathan Marek wrote:
>>>>> Hi,
>>>>> 
>>>>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>>>>> Hi Jonathan,
>>>>>> 
>>>>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>>>>> Add the apps_smmu node for sm8250. Note that adding the iommus 
>>>>>>> field for
>>>>>>> UFS is required because initializing the iommu removes the bypass 
>>>>>>> mapping
>>>>>>> that created by the bootloader.
>>>>>>> 
>>>>>> 
>>>>>> This statement doesn't seem right, you can just say since the 
>>>>>> bypass is disabled
>>>>>> by default now, we need to add this property to enable translation 
>>>>>> and avoid global faults.
>>>>>> 
>>>>> 
>>>>> If I use this patch [1] then the UFS iommu property isn't needed. 
>>>>> In
>>>>> downstream, the identity (bypass?) stream mapping is inherited from
>>>>> the bootloader, and UFS is used without any iommu property. Setting
>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its 
>>>>> own
>>>>> (without the UFS iommu property), so there's more to it than just
>>>>> "bypass is disabled by default now".
>>>>> 
>>>>> https://patchwork.kernel.org/patch/11310757/
>>>>> 
>>>> 
>>>> "iommus" property is not about inheriting stream mapping from 
>>>> bootloader,
>>>> it is used to enable SMMU address translation for the corresponding
>>>> master when specified. So when you have disabled bypass, i.e.,
>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
>>>> "arm-smmu.disable_bypass=1"
>>>> and iommus property with SID and mask is not specified, then it will 
>>>> result
>>>> in SMMU global faults.
>>>> 
>>>> Downstream has bypass 
>>>> enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
>>>> won't see any global faults if you do not have iommus property.
>>>> 
>>>> Patch in your link is for display because of the usecase for splash 
>>>> screen
>>>> on android and some other devices where the bootloader will 
>>>> configure SMMU,
>>>> it has not yet merged and not likely to get merged in the current 
>>>> state.
>>>> 
>>>> So yes "there is *not* much more to it than bypass is disabled by 
>>>> default now"
>>>> and you have to specify "iommus" for the master devices or you 
>>>> should enable bypass,
>>>> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or 
>>>> arm-smmu.disable_bypass=n
>>>> 
>>>> Try without the patch in the link and without iommus for UFS and
>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>>>> 
>>>> -Sai
>>> 
>>> I know that the "iommus" property is not about inheriting stream
>>> mapping. Probing the iommu removes the stream mapping created by the
>>> bootloader, the iommus property is added so that new mappings are
>>> created to replace what was removed.
>>> 
>>> You seem to be under the impression that the SM8150/SM8250 bootloader
>>> does not configure SMMU. It does, for both UFS and SDHC, just like it
>>> does for display/splash screen on some devices.
>>> 
>> 
>> It could be that bootloader does configure SMMU for UFS and SDHC, but 
>> the
>> upstream SMMU driver doesnt allow to inherit stream mapping from the 
>> bootloader
>> yet, so adding iommus property based on the assumption that it is 
>> inherited seems
>> wrong.
>> 
> 
> I never said adding the iommus property is for inheriting stream
> mapping. I mentioned inheriting to say UFS works without the iommus
> property on downstream (it inherits a identity/bypass mapping).
> 

Your commit description says "adding the iommus field for UFS is 
required
because initializing the iommu removes the bypass mapping that created 
by the
bootloader". So here it would mean like iommus property for UFS is not 
for
enabling address translation by SMMU for UFS but to avoid removing 
mappings
created by the bootloader which is not exactly what iommus property is 
for.

>>> With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not
>>> work without the iommus property.
>> 
>> I'm pretty sure that if you have ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n 
>> and
>> without iommus, it should work.
>> 
> 
> It doesn't work, with either ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or
> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y.
> 

Ok since you are very sure about this, I will try with your patches on
SM8150 MTP tomorrow since I do not have access to one now.
Also just to make sure, please remove all the extra SMMU patches you 
have
in your tree which are not yet merged or from downstream kernel.

-Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Jonathan Marek]

On 5/25/20 7:40 AM, Sai Prakash Ranjan wrote:
> On 2020-05-25 16:57, Jonathan Marek wrote:
>> On 5/25/20 7:17 AM, Sai Prakash Ranjan wrote:
>>> Hi,
>>>
>>> On 2020-05-25 16:38, Jonathan Marek wrote:
>>>> On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
>>>>> On 2020-05-25 15:39, Jonathan Marek wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>>>>>> Hi Jonathan,
>>>>>>>
>>>>>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>>>>>> Add the apps_smmu node for sm8250. Note that adding the iommus 
>>>>>>>> field for
>>>>>>>> UFS is required because initializing the iommu removes the 
>>>>>>>> bypass mapping
>>>>>>>> that created by the bootloader.
>>>>>>>>
>>>>>>>
>>>>>>> This statement doesn't seem right, you can just say since the 
>>>>>>> bypass is disabled
>>>>>>> by default now, we need to add this property to enable 
>>>>>>> translation and avoid global faults.
>>>>>>>
>>>>>>
>>>>>> If I use this patch [1] then the UFS iommu property isn't needed. In
>>>>>> downstream, the identity (bypass?) stream mapping is inherited from
>>>>>> the bootloader, and UFS is used without any iommu property. Setting
>>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
>>>>>> (without the UFS iommu property), so there's more to it than just
>>>>>> "bypass is disabled by default now".
>>>>>>
>>>>>> https://patchwork.kernel.org/patch/11310757/
>>>>>>
>>>>>
>>>>> "iommus" property is not about inheriting stream mapping from 
>>>>> bootloader,
>>>>> it is used to enable SMMU address translation for the corresponding
>>>>> master when specified. So when you have disabled bypass, i.e.,
>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
>>>>> "arm-smmu.disable_bypass=1"
>>>>> and iommus property with SID and mask is not specified, then it 
>>>>> will result
>>>>> in SMMU global faults.
>>>>>
>>>>> Downstream has bypass 
>>>>> enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
>>>>> won't see any global faults if you do not have iommus property.
>>>>>
>>>>> Patch in your link is for display because of the usecase for splash 
>>>>> screen
>>>>> on android and some other devices where the bootloader will 
>>>>> configure SMMU,
>>>>> it has not yet merged and not likely to get merged in the current 
>>>>> state.
>>>>>
>>>>> So yes "there is *not* much more to it than bypass is disabled by 
>>>>> default now"
>>>>> and you have to specify "iommus" for the master devices or you 
>>>>> should enable bypass,
>>>>> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or 
>>>>> arm-smmu.disable_bypass=n
>>>>>
>>>>> Try without the patch in the link and without iommus for UFS and
>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>>>>>
>>>>> -Sai
>>>>
>>>> I know that the "iommus" property is not about inheriting stream
>>>> mapping. Probing the iommu removes the stream mapping created by the
>>>> bootloader, the iommus property is added so that new mappings are
>>>> created to replace what was removed.
>>>>
>>>> You seem to be under the impression that the SM8150/SM8250 bootloader
>>>> does not configure SMMU. It does, for both UFS and SDHC, just like it
>>>> does for display/splash screen on some devices.
>>>>
>>>
>>> It could be that bootloader does configure SMMU for UFS and SDHC, but 
>>> the
>>> upstream SMMU driver doesnt allow to inherit stream mapping from the 
>>> bootloader
>>> yet, so adding iommus property based on the assumption that it is 
>>> inherited seems
>>> wrong.
>>>
>>
>> I never said adding the iommus property is for inheriting stream
>> mapping. I mentioned inheriting to say UFS works without the iommus
>> property on downstream (it inherits a identity/bypass mapping).
>>
> 
> Your commit description says "adding the iommus field for UFS is required
> because initializing the iommu removes the bypass mapping that created 
> by the
> bootloader". So here it would mean like iommus property for UFS is not for
> enabling address translation by SMMU for UFS but to avoid removing mappings
> created by the bootloader which is not exactly what iommus property is for.
> 

I guess the commit message is ambiguous, that's not what I meant. Is 
"Now that the kernel initializes the iommu, the bypass mappings set by 
the bootloader are cleared. Adding the iommus property is required so 
that new mappings are created for UFS." better?

>>>> With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not
>>>> work without the iommus property.
>>>
>>> I'm pretty sure that if you have ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n 
>>> and
>>> without iommus, it should work.
>>>
>>
>> It doesn't work, with either ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or
>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y.
>>
> 
> Ok since you are very sure about this, I will try with your patches on
> SM8150 MTP tomorrow since I do not have access to one now.
> Also just to make sure, please remove all the extra SMMU patches you have
> in your tree which are not yet merged or from downstream kernel.
> 

FYI, I have a branch [1] integrating patches for upstream. All the 
patches up to 34fff8a519cc075933 ("arm64: dts: qcom: add sm8250 GPU 
nodes") have been submitted (and the patches after that are unnecessary 
for testing on sm8150).

[1] https://github.com/flto/linux/commits/sm8x50-upstream

> -Sai
> 

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Sai Prakash Ranjan]

On 2020-05-25 17:23, Jonathan Marek wrote:
> On 5/25/20 7:40 AM, Sai Prakash Ranjan wrote:
>> On 2020-05-25 16:57, Jonathan Marek wrote:
>>> On 5/25/20 7:17 AM, Sai Prakash Ranjan wrote:
>>>> Hi,
>>>> 
>>>> On 2020-05-25 16:38, Jonathan Marek wrote:
>>>>> On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
>>>>>> On 2020-05-25 15:39, Jonathan Marek wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>>>>>>> Hi Jonathan,
>>>>>>>> 
>>>>>>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>>>>>>> Add the apps_smmu node for sm8250. Note that adding the iommus 
>>>>>>>>> field for
>>>>>>>>> UFS is required because initializing the iommu removes the 
>>>>>>>>> bypass mapping
>>>>>>>>> that created by the bootloader.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> This statement doesn't seem right, you can just say since the 
>>>>>>>> bypass is disabled
>>>>>>>> by default now, we need to add this property to enable 
>>>>>>>> translation and avoid global faults.
>>>>>>>> 
>>>>>>> 
>>>>>>> If I use this patch [1] then the UFS iommu property isn't needed. 
>>>>>>> In
>>>>>>> downstream, the identity (bypass?) stream mapping is inherited 
>>>>>>> from
>>>>>>> the bootloader, and UFS is used without any iommu property. 
>>>>>>> Setting
>>>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its 
>>>>>>> own
>>>>>>> (without the UFS iommu property), so there's more to it than just
>>>>>>> "bypass is disabled by default now".
>>>>>>> 
>>>>>>> https://patchwork.kernel.org/patch/11310757/
>>>>>>> 
>>>>>> 
>>>>>> "iommus" property is not about inheriting stream mapping from 
>>>>>> bootloader,
>>>>>> it is used to enable SMMU address translation for the 
>>>>>> corresponding
>>>>>> master when specified. So when you have disabled bypass, i.e.,
>>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline 
>>>>>> "arm-smmu.disable_bypass=1"
>>>>>> and iommus property with SID and mask is not specified, then it 
>>>>>> will result
>>>>>> in SMMU global faults.
>>>>>> 
>>>>>> Downstream has bypass 
>>>>>> enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
>>>>>> won't see any global faults if you do not have iommus property.
>>>>>> 
>>>>>> Patch in your link is for display because of the usecase for 
>>>>>> splash screen
>>>>>> on android and some other devices where the bootloader will 
>>>>>> configure SMMU,
>>>>>> it has not yet merged and not likely to get merged in the current 
>>>>>> state.
>>>>>> 
>>>>>> So yes "there is *not* much more to it than bypass is disabled by 
>>>>>> default now"
>>>>>> and you have to specify "iommus" for the master devices or you 
>>>>>> should enable bypass,
>>>>>> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or 
>>>>>> arm-smmu.disable_bypass=n
>>>>>> 
>>>>>> Try without the patch in the link and without iommus for UFS and
>>>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>>>>>> 
>>>>>> -Sai
>>>>> 
>>>>> I know that the "iommus" property is not about inheriting stream
>>>>> mapping. Probing the iommu removes the stream mapping created by 
>>>>> the
>>>>> bootloader, the iommus property is added so that new mappings are
>>>>> created to replace what was removed.
>>>>> 
>>>>> You seem to be under the impression that the SM8150/SM8250 
>>>>> bootloader
>>>>> does not configure SMMU. It does, for both UFS and SDHC, just like 
>>>>> it
>>>>> does for display/splash screen on some devices.
>>>>> 
>>>> 
>>>> It could be that bootloader does configure SMMU for UFS and SDHC, 
>>>> but the
>>>> upstream SMMU driver doesnt allow to inherit stream mapping from the 
>>>> bootloader
>>>> yet, so adding iommus property based on the assumption that it is 
>>>> inherited seems
>>>> wrong.
>>>> 
>>> 
>>> I never said adding the iommus property is for inheriting stream
>>> mapping. I mentioned inheriting to say UFS works without the iommus
>>> property on downstream (it inherits a identity/bypass mapping).
>>> 
>> 
>> Your commit description says "adding the iommus field for UFS is 
>> required
>> because initializing the iommu removes the bypass mapping that created 
>> by the
>> bootloader". So here it would mean like iommus property for UFS is not 
>> for
>> enabling address translation by SMMU for UFS but to avoid removing 
>> mappings
>> created by the bootloader which is not exactly what iommus property is 
>> for.
>> 
> 
> I guess the commit message is ambiguous, that's not what I meant. Is
> "Now that the kernel initializes the iommu, the bypass mappings set by
> the bootloader are cleared. Adding the iommus property is required so
> that new mappings are created for UFS." better?
> 

Yes looks good.

>>>>> With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will 
>>>>> not
>>>>> work without the iommus property.
>>>> 
>>>> I'm pretty sure that if you have 
>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n and
>>>> without iommus, it should work.
>>>> 
>>> 
>>> It doesn't work, with either ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or
>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y.
>>> 
>> 
>> Ok since you are very sure about this, I will try with your patches on
>> SM8150 MTP tomorrow since I do not have access to one now.
>> Also just to make sure, please remove all the extra SMMU patches you 
>> have
>> in your tree which are not yet merged or from downstream kernel.
>> 
> 
> FYI, I have a branch [1] integrating patches for upstream. All the
> patches up to 34fff8a519cc075933 ("arm64: dts: qcom: add sm8250 GPU
> nodes") have been submitted (and the patches after that are
> unnecessary for testing on sm8150).
> 
> [1] https://github.com/flto/linux/commits/sm8x50-upstream
> 

Thanks, I will test this out.

-Sai
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node

[Bjorn Andersson]

On Mon 25 May 04:53 PDT 2020, Jonathan Marek wrote:
[..]
> I guess the commit message is ambiguous, that's not what I meant. Is "Now
> that the kernel initializes the iommu, the bypass mappings set by the
> bootloader are cleared. Adding the iommus property is required so that new
> mappings are created for UFS." better?
> 

This looks better, but it's actually not a bypass mapping that we
inherit from the bootloader, it's the stream mapping pointing to a
disabled (~ARM_SMMU_SCTLR_M) context bank. So when we wipe the stream
mappings we will fault on the unmatched stream - which secure world
"handles" for us...

As such, I think you should replace "bypass" with "stream".

Regards,
Bjorn

[PATCH 3/6] arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes

[Jonathan Marek]

Add dts nodes for the secondary USB controller and related PHY nodes.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 89 ++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index acb839427b12..903514fc299f 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -636,6 +636,19 @@ usb_1_hsphy: phy@88e2000 {
 			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
 		};
 
+		usb_2_hsphy: phy@88e3000 {
+			compatible = "qcom,sm8150-usb-hs-phy",
+				     "qcom,usb-snps-hs-7nm-phy";
+			reg = <0 0x088e3000 0 0x400>;
+			status = "disabled";
+			#phy-cells = <0>;
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "ref";
+
+			resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
+		};
+
 		usb_1_qmpphy: phy@88e9000 {
 			compatible = "qcom,sm8150-qmp-usb3-phy";
 			reg = <0 0x088e9000 0 0x18c>,
@@ -671,6 +684,37 @@ usb_1_ssphy: lanes@88e9200 {
 			};
 		};
 
+		usb_2_qmpphy: phy@88eb000 {
+			compatible = "qcom,sm8150-qmp-usb3-uni-phy";
+			reg = <0 0x088eb000 0 0x200>;
+			status = "disabled";
+			#clock-cells = <1>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			clocks = <&gcc GCC_USB3_SEC_PHY_AUX_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>,
+				 <&gcc GCC_USB3_SEC_CLKREF_CLK>,
+				 <&gcc GCC_USB3_SEC_PHY_COM_AUX_CLK>;
+			clock-names = "aux", "ref_clk_src", "ref", "com_aux";
+
+			resets = <&gcc GCC_USB3PHY_PHY_SEC_BCR>,
+				 <&gcc GCC_USB3_PHY_SEC_BCR>;
+			reset-names = "phy", "common";
+
+			usb_2_ssphy: lane@88eb200 {
+				reg = <0 0x088eb200 0 0x200>,
+				      <0 0x088eb400 0 0x200>,
+				      <0 0x088eb800 0 0x800>,
+				      <0 0x088eb600 0 0x200>;
+				#phy-cells = <0>;
+				clocks = <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>;
+				clock-names = "pipe0";
+				clock-output-names = "usb3_uni_phy_pipe_clk_src";
+			};
+		};
+
 		usb_1: usb@a6f8800 {
 			compatible = "qcom,sm8150-dwc3", "qcom,dwc3";
 			reg = <0 0x0a6f8800 0 0x400>;
@@ -716,6 +760,51 @@ usb_1_dwc3: dwc3@a600000 {
 			};
 		};
 
+		usb_2: usb@a8f8800 {
+			compatible = "qcom,sm8150-dwc3", "qcom,dwc3";
+			reg = <0 0x0a8f8800 0 0x400>;
+			status = "disabled";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+			dma-ranges;
+
+			clocks = <&gcc GCC_CFG_NOC_USB3_SEC_AXI_CLK>,
+				 <&gcc GCC_USB30_SEC_MASTER_CLK>,
+				 <&gcc GCC_AGGRE_USB3_SEC_AXI_CLK>,
+				 <&gcc GCC_USB30_SEC_MOCK_UTMI_CLK>,
+				 <&gcc GCC_USB30_SEC_SLEEP_CLK>,
+				 <&gcc GCC_USB3_SEC_CLKREF_CLK>;
+			clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+				      "sleep", "xo";
+
+			assigned-clocks = <&gcc GCC_USB30_SEC_MOCK_UTMI_CLK>,
+					  <&gcc GCC_USB30_SEC_MASTER_CLK>;
+			assigned-clock-rates = <19200000>, <200000000>;
+
+			interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 487 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 490 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 491 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hs_phy_irq", "ss_phy_irq",
+					  "dm_hs_phy_irq", "dp_hs_phy_irq";
+
+			power-domains = <&gcc USB30_SEC_GDSC>;
+
+			resets = <&gcc GCC_USB30_SEC_BCR>;
+
+			usb_2_dwc3: dwc3@a800000 {
+				compatible = "snps,dwc3";
+				reg = <0 0x0a800000 0 0xcd00>;
+				interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+				iommus = <&apps_smmu 0x160 0>;
+				snps,dis_u2_susphy_quirk;
+				snps,dis_enblslpm_quirk;
+				phys = <&usb_2_hsphy>, <&usb_2_ssphy>;
+				phy-names = "usb2-phy", "usb3-phy";
+			};
+		};
+
 		aoss_qmp: power-controller@c300000 {
 			compatible = "qcom,sm8150-aoss-qmp";
 			reg = <0x0 0x0c300000 0x0 0x100000>;
-- 
2.26.1

[PATCH 4/6] arm64: dts: qcom: sm8250: Add USB and PHY device nodes

[Jonathan Marek]

Add device nodes for the USB3 controller, QMP SS PHY and
SNPS HS PHY.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
 arch/arm64/boot/dts/qcom/sm8250.dtsi | 180 +++++++++++++++++++++++++++
 1 file changed, 180 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 43c5e48c15e2..3bdce658c08a 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -387,6 +387,186 @@ tcsr_mutex: hwlock@1f40000 {
 			#hwlock-cells = <1>;
 		};
 
+		usb_1_hsphy: phy@88e3000 {
+			compatible = "qcom,sm8250-usb-hs-phy",
+				     "qcom,usb-snps-hs-7nm-phy";
+			reg = <0 0x088e3000 0 0x400>;
+			status = "disabled";
+			#phy-cells = <0>;
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "ref";
+
+			resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+		};
+
+		usb_2_hsphy: phy@88e4000 {
+			compatible = "qcom,sm8250-usb-hs-phy",
+				     "qcom,usb-snps-hs-7nm-phy";
+			reg = <0 0x088e4000 0 0x400>;
+			status = "disabled";
+			#phy-cells = <0>;
+
+			clocks = <&rpmhcc RPMH_CXO_CLK>;
+			clock-names = "ref";
+
+			resets = <&gcc GCC_QUSB2PHY_SEC_BCR>;
+		};
+
+		usb_1_qmpphy: phy@88e9000 {
+			compatible = "qcom,sm8250-qmp-usb3-phy";
+			reg = <0 0x088e9000 0 0x200>,
+			      <0 0x088e8000 0 0x20>;
+			reg-names = "reg-base", "dp_com";
+			status = "disabled";
+			#clock-cells = <1>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>,
+				 <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>;
+			clock-names = "aux", "ref_clk_src", "com_aux";
+
+			resets = <&gcc GCC_USB3_DP_PHY_PRIM_BCR>,
+				 <&gcc GCC_USB3_PHY_PRIM_BCR>;
+			reset-names = "phy", "common";
+
+			usb_1_ssphy: lanes@88e9200 {
+				reg = <0 0x088e9200 0 0x200>,
+				      <0 0x088e9400 0 0x200>,
+				      <0 0x088e9c00 0 0x400>,
+				      <0 0x088e9600 0 0x200>,
+				      <0 0x088e9800 0 0x200>,
+				      <0 0x088e9a00 0 0x100>;
+				#phy-cells = <0>;
+				clocks = <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+				clock-names = "pipe0";
+				clock-output-names = "usb3_phy_pipe_clk_src";
+			};
+		};
+
+		usb_2_qmpphy: phy@88eb000 {
+			compatible = "qcom,sm8250-qmp-usb3-uni-phy";
+			reg = <0 0x088eb000 0 0x200>;
+			status = "disabled";
+			#clock-cells = <1>;
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			clocks = <&gcc GCC_USB3_SEC_PHY_AUX_CLK>,
+				 <&rpmhcc RPMH_CXO_CLK>,
+				 <&gcc GCC_USB3_SEC_CLKREF_EN>,
+				 <&gcc GCC_USB3_SEC_PHY_COM_AUX_CLK>;
+			clock-names = "aux", "ref_clk_src", "ref", "com_aux";
+
+			resets = <&gcc GCC_USB3PHY_PHY_SEC_BCR>,
+				 <&gcc GCC_USB3_PHY_SEC_BCR>;
+			reset-names = "phy", "common";
+
+			usb_2_ssphy: lane@88eb200 {
+				reg = <0 0x088eb200 0 0x200>,
+				      <0 0x088eb400 0 0x200>,
+				      <0 0x088eb800 0 0x800>;
+				#phy-cells = <0>;
+				clocks = <&gcc GCC_USB3_SEC_PHY_PIPE_CLK>;
+				clock-names = "pipe0";
+				clock-output-names = "usb3_uni_phy_pipe_clk_src";
+			};
+		};
+
+		usb_1: usb@a6f8800 {
+			compatible = "qcom,sm8250-dwc3", "qcom,dwc3";
+			reg = <0 0x0a6f8800 0 0x400>;
+			status = "disabled";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+			dma-ranges;
+
+			clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+				 <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+				 <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+				 <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+				 <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
+				 <&gcc GCC_USB3_SEC_CLKREF_EN>;
+			clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+				      "sleep", "xo";
+
+			assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+					  <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+			assigned-clock-rates = <19200000>, <200000000>;
+
+			interrupts-extended = <&intc GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+					      <&pdc 14 IRQ_TYPE_EDGE_BOTH>,
+					      <&pdc 15 IRQ_TYPE_EDGE_BOTH>,
+					      <&pdc 17 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hs_phy_irq", "dp_hs_phy_irq",
+					  "dm_hs_phy_irq", "ss_phy_irq";
+
+			power-domains = <&gcc USB30_PRIM_GDSC>;
+
+			resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+			usb_1_dwc3: dwc3@a600000 {
+				compatible = "snps,dwc3";
+				reg = <0 0x0a600000 0 0xcd00>;
+				interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+				iommus = <&apps_smmu 0x0 0x0>;
+				snps,dis_u2_susphy_quirk;
+				snps,dis_enblslpm_quirk;
+				phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
+				phy-names = "usb2-phy", "usb3-phy";
+			};
+		};
+
+		usb_2: usb@a8f8800 {
+			compatible = "qcom,sm8250-dwc3", "qcom,dwc3";
+			reg = <0 0x0a8f8800 0 0x400>;
+			status = "disabled";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+			dma-ranges;
+
+			clocks = <&gcc GCC_CFG_NOC_USB3_SEC_AXI_CLK>,
+				 <&gcc GCC_USB30_SEC_MASTER_CLK>,
+				 <&gcc GCC_AGGRE_USB3_SEC_AXI_CLK>,
+				 <&gcc GCC_USB30_SEC_MOCK_UTMI_CLK>,
+				 <&gcc GCC_USB30_SEC_SLEEP_CLK>,
+				 <&gcc GCC_USB3_SEC_CLKREF_EN>;
+			clock-names = "cfg_noc", "core", "iface", "mock_utmi",
+				      "sleep", "xo";
+
+			assigned-clocks = <&gcc GCC_USB30_SEC_MOCK_UTMI_CLK>,
+					  <&gcc GCC_USB30_SEC_MASTER_CLK>;
+			assigned-clock-rates = <19200000>, <200000000>;
+
+			interrupts-extended = <&intc GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+					      <&pdc 12 IRQ_TYPE_EDGE_BOTH>,
+					      <&pdc 13 IRQ_TYPE_EDGE_BOTH>,
+					      <&pdc 16 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hs_phy_irq", "dp_hs_phy_irq",
+					  "dm_hs_phy_irq", "ss_phy_irq";
+
+			power-domains = <&gcc USB30_SEC_GDSC>;
+
+			resets = <&gcc GCC_USB30_SEC_BCR>;
+
+			usb_2_dwc3: dwc3@a800000 {
+				compatible = "snps,dwc3";
+				reg = <0 0x0a800000 0 0xcd00>;
+				interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+				iommus = <&apps_smmu 0x20 0>;
+				snps,dis_u2_susphy_quirk;
+				snps,dis_enblslpm_quirk;
+				phys = <&usb_2_hsphy>, <&usb_2_ssphy>;
+				phy-names = "usb2-phy", "usb3-phy";
+			};
+		};
+
 		pdc: interrupt-controller@b220000 {
 			compatible = "qcom,sm8250-pdc", "qcom,pdc";
 			reg = <0 0x0b220000 0 0x30000>, <0 0x17c000f0 0 0x60>;
-- 
2.26.1

[PATCH 5/6] arm64: dts: qcom: add sm8150 hdk dts

[Jonathan Marek]

Add initial HDK855 dts, based on sm8150-mtp, with a few changes.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
 arch/arm64/boot/dts/qcom/Makefile       |   1 +
 arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
 2 files changed, 462 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index cc103f7020fd..e5dbd8b63951 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-db845c.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm850-lenovo-yoga-c630.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-hdk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
new file mode 100644
index 000000000000..95b54fa8254a
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "sm8150.dtsi"
+#include "pm8150.dtsi"
+#include "pm8150b.dtsi"
+#include "pm8150l.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. SM8150 HDK";
+	compatible = "qcom,sm8150-hdk";
+
+	aliases {
+		serial0 = &uart2;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	vph_pwr: vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+	};
+
+	/*
+	 * Apparently RPMh does not provide support for PM8150 S4 because it
+	 * is always-on; model it as a fixed regulator.
+	 */
+	vreg_s4a_1p8: pm8150-s4 {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_s4a_1p8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vph_pwr>;
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+
+		vol-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&pm8150_gpios 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+&apps_rsc {
+	pm8150-rpmh-regulators {
+		compatible = "qcom,pm8150-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		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-s7-supply = <&vph_pwr>;
+		vdd-s8-supply = <&vph_pwr>;
+		vdd-s9-supply = <&vph_pwr>;
+		vdd-s10-supply = <&vph_pwr>;
+
+		vdd-l1-l8-l11-supply = <&vreg_s6a_0p9>;
+		vdd-l2-l10-supply = <&vreg_bob>;
+		vdd-l3-l4-l5-l18-supply = <&vreg_s6a_0p9>;
+		vdd-l6-l9-supply = <&vreg_s8c_1p3>;
+		vdd-l7-l12-l14-l15-supply = <&vreg_s5a_2p0>;
+		vdd-l13-l16-l17-supply = <&vreg_bob>;
+
+		vreg_s5a_2p0: smps5 {
+			regulator-min-microvolt = <1904000>;
+			regulator-max-microvolt = <2000000>;
+		};
+
+		vreg_s6a_0p9: smps6 {
+			regulator-min-microvolt = <920000>;
+			regulator-max-microvolt = <1128000>;
+		};
+
+		vdda_wcss_pll:
+		vreg_l1a_0p75: ldo1 {
+			regulator-min-microvolt = <752000>;
+			regulator-max-microvolt = <752000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_pdphy:
+		vdda_usb_hs_3p1:
+		vreg_l2a_3p1: ldo2 {
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3a_0p8: ldo3 {
+			regulator-min-microvolt = <480000>;
+			regulator-max-microvolt = <932000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_usb_hs_core:
+		vdda_csi_0_0p9:
+		vdda_csi_1_0p9:
+		vdda_csi_2_0p9:
+		vdda_csi_3_0p9:
+		vdda_dsi_0_0p9:
+		vdda_dsi_1_0p9:
+		vdda_dsi_0_pll_0p9:
+		vdda_dsi_1_pll_0p9:
+		vdda_pcie_1ln_core:
+		vdda_pcie_2ln_core:
+		vdda_pll_hv_cc_ebi01:
+		vdda_pll_hv_cc_ebi23:
+		vdda_qrefs_0p875_5:
+		vdda_sp_sensor:
+		vdda_ufs_2ln_core_1:
+		vdda_ufs_2ln_core_2:
+		vdda_usb_ss_dp_core_1:
+		vdda_usb_ss_dp_core_2:
+		vdda_qlink_lv:
+		vdda_qlink_lv_ck:
+		vreg_l5a_0p875: ldo5 {
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6a_1p2: ldo6 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7a_1p8: ldo7 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_10:
+		vreg_l9a_1p2: ldo9 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10a_2p5: ldo10 {
+			regulator-min-microvolt = <2504000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11a_0p8: ldo11 {
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdd_qfprom:
+		vdd_qfprom_sp:
+		vdda_apc_cs_1p8:
+		vdda_gfx_cs_1p8:
+		vdda_usb_hs_1p8:
+		vdda_qrefs_vref_1p8:
+		vddpx_10_a:
+		vreg_l12a_1p8: ldo12 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13a_2p7: ldo13 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2704000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14a_1p8: ldo14 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15a_1p7: ldo15 {
+			regulator-min-microvolt = <1704000>;
+			regulator-max-microvolt = <1704000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l16a_2p7: ldo16 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17a_3p0: ldo17 {
+			regulator-min-microvolt = <2856000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	pm8150l-rpmh-regulators {
+		compatible = "qcom,pm8150l-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		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-s7-supply = <&vph_pwr>;
+		vdd-s8-supply = <&vph_pwr>;
+
+		vdd-l1-l8-supply = <&vreg_s4a_1p8>;
+		vdd-l2-l3-supply = <&vreg_s8c_1p3>;
+		vdd-l4-l5-l6-supply = <&vreg_bob>;
+		vdd-l7-l11-supply = <&vreg_bob>;
+		vdd-l9-l10-supply = <&vreg_bob>;
+
+		vdd-bob-supply = <&vph_pwr>;
+		vdd-flash-supply = <&vreg_bob>;
+		vdd-rgb-supply = <&vreg_bob>;
+
+		vreg_bob: bob {
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <4000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+			regulator-allow-bypass;
+		};
+
+		vreg_s8c_1p3: smps8 {
+			regulator-min-microvolt = <1352000>;
+			regulator-max-microvolt = <1352000>;
+		};
+
+		vreg_l1c_1p8: ldo1 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdda_wcss_adcdac_1:
+		vdda_wcss_adcdac_22:
+		vreg_l2c_1p3: ldo2 {
+			regulator-min-microvolt = <1304000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vdda_hv_ebi0:
+		vdda_hv_ebi1:
+		vdda_hv_ebi2:
+		vdda_hv_ebi3:
+		vdda_hv_refgen0:
+		vdda_qlink_hv_ck:
+		vreg_l3c_1p2: ldo3 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_5:
+		vreg_l4c_1p8: ldo4 {
+			regulator-min-microvolt = <1704000>;
+			regulator-max-microvolt = <2928000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_6:
+		vreg_l5c_1p8: ldo5 {
+			regulator-min-microvolt = <1704000>;
+			regulator-max-microvolt = <2928000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vddpx_2:
+		vreg_l6c_2p9: ldo6 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7c_3p0: ldo7 {
+			regulator-min-microvolt = <2856000>;
+			regulator-max-microvolt = <3104000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8c_1p8: ldo8 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9c_2p9: ldo9 {
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10c_3p3: ldo10 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11c_3p3: ldo11 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	pm8009-rpmh-regulators {
+		compatible = "qcom,pm8009-rpmh-regulators";
+		qcom,pmic-id = "f";
+
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vreg_bob>;
+
+		vdd-l2-supply = <&vreg_s8c_1p3>;
+		vdd-l5-l6-supply = <&vreg_bob>;
+
+		vreg_l2f_1p2: ldo2 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5f_2p85: ldo5 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <2800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6f_2p85: ldo6 {
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+			regulator-min-microvolt = <2856000>;
+			regulator-max-microvolt = <2856000>;
+		};
+	};
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&pon {
+	pwrkey {
+		status = "okay";
+	};
+
+	resin {
+		compatible = "qcom,pm8941-resin";
+		interrupts = <0x0 0x8 0x1 IRQ_TYPE_EDGE_BOTH>;
+		debounce = <15625>;
+		bias-pull-up;
+		linux,code = <KEY_VOLUMEDOWN>;
+	};
+};
+
+&remoteproc_adsp {
+	status = "okay";
+};
+
+&remoteproc_cdsp {
+	status = "okay";
+};
+
+&remoteproc_slpi {
+	status = "okay";
+};
+
+&tlmm {
+	gpio-reserved-ranges = <0 4>, <126 4>;
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&ufs_mem_hc {
+	status = "okay";
+
+	reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
+
+	vcc-supply = <&vreg_l10a_2p5>;
+	vcc-max-microamp = <750000>;
+	vccq-supply = <&vreg_l9a_1p2>;
+	vccq-max-microamp = <700000>;
+	vccq2-supply = <&vreg_s4a_1p8>;
+	vccq2-max-microamp = <750000>;
+};
+
+&ufs_mem_phy {
+	status = "okay";
+
+	vdda-phy-supply = <&vdda_ufs_2ln_core_1>;
+	vdda-max-microamp = <90200>;
+	vdda-pll-supply = <&vreg_l3c_1p2>;
+	vdda-pll-max-microamp = <19000>;
+};
+
+&usb_1_hsphy {
+	status = "okay";
+	vdda-pll-supply = <&vdd_usb_hs_core>;
+	vdda33-supply = <&vdda_usb_hs_3p1>;
+	vdda18-supply = <&vdda_usb_hs_1p8>;
+};
+
+&usb_2_hsphy {
+	status = "okay";
+	vdda-pll-supply = <&vdd_usb_hs_core>;
+	vdda33-supply = <&vdda_usb_hs_3p1>;
+	vdda18-supply = <&vdda_usb_hs_1p8>;
+};
+
+&usb_1_qmpphy {
+	status = "okay";
+	vdda-phy-supply = <&vreg_l3c_1p2>;
+	vdda-pll-supply = <&vdda_usb_ss_dp_core_1>;
+};
+
+&usb_2_qmpphy {
+	status = "okay";
+	vdda-phy-supply = <&vreg_l3c_1p2>;
+	vdda-pll-supply = <&vdda_usb_ss_dp_core_1>;
+};
+
+&usb_1 {
+	status = "okay";
+};
+
+&usb_2 {
+	status = "okay";
+};
+
+&usb_1_dwc3 {
+	dr_mode = "peripheral";
+};
+
+&usb_2_dwc3 {
+	dr_mode = "host";
+};
-- 
2.26.1

Re: [PATCH 5/6] arm64: dts: qcom: add sm8150 hdk dts

[Bjorn Andersson]

On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:

> Add initial HDK855 dts, based on sm8150-mtp, with a few changes.
> 

Happy to see this on the list Jonathan, just some minor things on the
remoteproc nodes below.

> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
>  arch/arm64/boot/dts/qcom/Makefile       |   1 +
>  arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>  2 files changed, 462 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index cc103f7020fd..e5dbd8b63951 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-db845c.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sdm850-lenovo-yoga-c630.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-hdk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
[..]
> +/ {
> +	model = "Qualcomm Technologies, Inc. SM8150 HDK";
> +	compatible = "qcom,sm8150-hdk";
> +
> +	aliases {
> +		serial0 = &uart2;
> +	};
> +
> +	chosen {
> +		stdout-path = "serial0:115200n8";
> +	};
> +
> +	vph_pwr: vph-pwr-regulator {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vph_pwr";
> +		regulator-min-microvolt = <3700000>;
> +		regulator-max-microvolt = <3700000>;
> +	};
> +
> +	/*
> +	 * Apparently RPMh does not provide support for PM8150 S4 because it
> +	 * is always-on; model it as a fixed regulator.
> +	 */

One day we should stop being surprised by this and drop the "Apparently"
from this comment ;)

> +	vreg_s4a_1p8: pm8150-s4 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vreg_s4a_1p8";
> +
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +
> +		regulator-always-on;
> +		regulator-boot-on;
> +
> +		vin-supply = <&vph_pwr>;
> +	};
[..]
> +&remoteproc_adsp {
> +	status = "okay";

It would be nice to see a
	firmware-name = "qcom/sm8150/adsp.mbn";

here. Because if we ever end up pushing firmware to linux-firmware this
DTB would continue to work.

Use https://github.com/andersson/pil-squasher to get mbn files out of
the mdt+bXX files for your testing (or just rename/symlink the mdt to
mbn for now).

> +};
> +
> +&remoteproc_cdsp {
> +	status = "okay";

	firmware-name = "qcom/sm8150/cdsp.mbn";

> +};
> +
> +&remoteproc_slpi {
> +	status = "okay";

	firmware-name = "qcom/sm8150/slpi.mbn";

Regards,
Bjorn

> +};
> +
> +&tlmm {
> +	gpio-reserved-ranges = <0 4>, <126 4>;
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&ufs_mem_hc {
> +	status = "okay";
> +
> +	reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
> +
> +	vcc-supply = <&vreg_l10a_2p5>;
> +	vcc-max-microamp = <750000>;
> +	vccq-supply = <&vreg_l9a_1p2>;
> +	vccq-max-microamp = <700000>;
> +	vccq2-supply = <&vreg_s4a_1p8>;
> +	vccq2-max-microamp = <750000>;
> +};
> +
> +&ufs_mem_phy {
> +	status = "okay";
> +
> +	vdda-phy-supply = <&vdda_ufs_2ln_core_1>;
> +	vdda-max-microamp = <90200>;
> +	vdda-pll-supply = <&vreg_l3c_1p2>;
> +	vdda-pll-max-microamp = <19000>;
> +};
> +
> +&usb_1_hsphy {
> +	status = "okay";
> +	vdda-pll-supply = <&vdd_usb_hs_core>;
> +	vdda33-supply = <&vdda_usb_hs_3p1>;
> +	vdda18-supply = <&vdda_usb_hs_1p8>;
> +};
> +
> +&usb_2_hsphy {
> +	status = "okay";
> +	vdda-pll-supply = <&vdd_usb_hs_core>;
> +	vdda33-supply = <&vdda_usb_hs_3p1>;
> +	vdda18-supply = <&vdda_usb_hs_1p8>;
> +};
> +
> +&usb_1_qmpphy {
> +	status = "okay";
> +	vdda-phy-supply = <&vreg_l3c_1p2>;
> +	vdda-pll-supply = <&vdda_usb_ss_dp_core_1>;
> +};
> +
> +&usb_2_qmpphy {
> +	status = "okay";
> +	vdda-phy-supply = <&vreg_l3c_1p2>;
> +	vdda-pll-supply = <&vdda_usb_ss_dp_core_1>;
> +};
> +
> +&usb_1 {
> +	status = "okay";
> +};
> +
> +&usb_2 {
> +	status = "okay";
> +};
> +
> +&usb_1_dwc3 {
> +	dr_mode = "peripheral";
> +};
> +
> +&usb_2_dwc3 {
> +	dr_mode = "host";
> +};
> -- 
> 2.26.1
> 

Re: [PATCH 5/6] arm64: dts: qcom: add sm8150 hdk dts

[Jonathan Marek]

On 5/28/20 11:01 PM, Bjorn Andersson wrote:
> On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> 
>> Add initial HDK855 dts, based on sm8150-mtp, with a few changes.
>>
> 
> Happy to see this on the list Jonathan, just some minor things on the
> remoteproc nodes below.
> 
>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile       |   1 +
>>   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>>   2 files changed, 462 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>> index cc103f7020fd..e5dbd8b63951 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -22,6 +22,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r3.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-db845c.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm850-lenovo-yoga-c630.dtb
>> +dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-hdk.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-mtp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-mtp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/sm8150-hdk.dts b/arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> [..]
>> +/ {
>> +	model = "Qualcomm Technologies, Inc. SM8150 HDK";
>> +	compatible = "qcom,sm8150-hdk";
>> +
>> +	aliases {
>> +		serial0 = &uart2;
>> +	};
>> +
>> +	chosen {
>> +		stdout-path = "serial0:115200n8";
>> +	};
>> +
>> +	vph_pwr: vph-pwr-regulator {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vph_pwr";
>> +		regulator-min-microvolt = <3700000>;
>> +		regulator-max-microvolt = <3700000>;
>> +	};
>> +
>> +	/*
>> +	 * Apparently RPMh does not provide support for PM8150 S4 because it
>> +	 * is always-on; model it as a fixed regulator.
>> +	 */
> 
> One day we should stop being surprised by this and drop the "Apparently"
> from this comment ;)
> 

Had this copied from sm8150-mtp, dropped the comment entirely (to match 
sm8250-mtp dts).

>> +	vreg_s4a_1p8: pm8150-s4 {
>> +		compatible = "regulator-fixed";
>> +		regulator-name = "vreg_s4a_1p8";
>> +
>> +		regulator-min-microvolt = <1800000>;
>> +		regulator-max-microvolt = <1800000>;
>> +
>> +		regulator-always-on;
>> +		regulator-boot-on;
>> +
>> +		vin-supply = <&vph_pwr>;
>> +	};
> [..]
>> +&remoteproc_adsp {
>> +	status = "okay";
> 
> It would be nice to see a
> 	firmware-name = "qcom/sm8150/adsp.mbn";
> 
> here. Because if we ever end up pushing firmware to linux-firmware this
> DTB would continue to work.
> 
> Use https://github.com/andersson/pil-squasher to get mbn files out of
> the mdt+bXX files for your testing (or just rename/symlink the mdt to
> mbn for now).
> 

Added the firmware-name fields as you suggested. One thing to note (it 
shouldn't matter for HDK), these firmwares can be modified by the device 
maker, so not all sm8150 will have the same adsp/cdsp/slpi firmware.

>> +};
>> +
>> +&remoteproc_cdsp {
>> +	status = "okay";
> 
> 	firmware-name = "qcom/sm8150/cdsp.mbn";
> 
>> +};
>> +
>> +&remoteproc_slpi {
>> +	status = "okay";
> 
> 	firmware-name = "qcom/sm8150/slpi.mbn";
> 
> Regards,
> Bjorn
> 
>> +};
>> +
>> +&tlmm {
>> +	gpio-reserved-ranges = <0 4>, <126 4>;
>> +};
>> +
>> +&uart2 {
>> +	status = "okay";
>> +};
>> +
>> +&ufs_mem_hc {
>> +	status = "okay";
>> +
>> +	reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
>> +
>> +	vcc-supply = <&vreg_l10a_2p5>;
>> +	vcc-max-microamp = <750000>;
>> +	vccq-supply = <&vreg_l9a_1p2>;
>> +	vccq-max-microamp = <700000>;
>> +	vccq2-supply = <&vreg_s4a_1p8>;
>> +	vccq2-max-microamp = <750000>;
>> +};
>> +
>> +&ufs_mem_phy {
>> +	status = "okay";
>> +
>> +	vdda-phy-supply = <&vdda_ufs_2ln_core_1>;
>> +	vdda-max-microamp = <90200>;
>> +	vdda-pll-supply = <&vreg_l3c_1p2>;
>> +	vdda-pll-max-microamp = <19000>;
>> +};
>> +
>> +&usb_1_hsphy {
>> +	status = "okay";
>> +	vdda-pll-supply = <&vdd_usb_hs_core>;
>> +	vdda33-supply = <&vdda_usb_hs_3p1>;
>> +	vdda18-supply = <&vdda_usb_hs_1p8>;
>> +};
>> +
>> +&usb_2_hsphy {
>> +	status = "okay";
>> +	vdda-pll-supply = <&vdd_usb_hs_core>;
>> +	vdda33-supply = <&vdda_usb_hs_3p1>;
>> +	vdda18-supply = <&vdda_usb_hs_1p8>;
>> +};
>> +
>> +&usb_1_qmpphy {
>> +	status = "okay";
>> +	vdda-phy-supply = <&vreg_l3c_1p2>;
>> +	vdda-pll-supply = <&vdda_usb_ss_dp_core_1>;
>> +};
>> +
>> +&usb_2_qmpphy {
>> +	status = "okay";
>> +	vdda-phy-supply = <&vreg_l3c_1p2>;
>> +	vdda-pll-supply = <&vdda_usb_ss_dp_core_1>;
>> +};
>> +
>> +&usb_1 {
>> +	status = "okay";
>> +};
>> +
>> +&usb_2 {
>> +	status = "okay";
>> +};
>> +
>> +&usb_1_dwc3 {
>> +	dr_mode = "peripheral";
>> +};
>> +
>> +&usb_2_dwc3 {
>> +	dr_mode = "host";
>> +};
>> -- 
>> 2.26.1
>>

[PATCH 6/6] arm64: dts: qcom: add sm8250 hdk dts

[Jonathan Marek]

Add initial HDK865 dts, based on sm8250-mtp, with a few changes.
Notably, regulator configs are changed a bit.

Signed-off-by: Jonathan Marek <jonathan@marek.ca>
---
 arch/arm64/boot/dts/qcom/Makefile       |   1 +
 arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 ++++++++++++++++++++++++
 2 files changed, 455 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index e5dbd8b63951..4649e8bc5034 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -24,6 +24,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm850-lenovo-yoga-c630.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-hdk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-mtp.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-hdk.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-mtp.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
diff --git a/arch/arm64/boot/dts/qcom/sm8250-hdk.dts b/arch/arm64/boot/dts/qcom/sm8250-hdk.dts
new file mode 100644
index 000000000000..d35014bf4f81
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sm8250-hdk.dts
@@ -0,0 +1,454 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/gpio/gpio.h>
+#include "sm8250.dtsi"
+#include "pm8150.dtsi"
+#include "pm8150b.dtsi"
+#include "pm8150l.dtsi"
+
+/ {
+	model = "Qualcomm Technologies, Inc. SM8250 HDK";
+	compatible = "qcom,sm8250-hdk";
+
+	aliases {
+		serial0 = &uart2;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	vph_pwr: vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-min-microvolt = <3700000>;
+		regulator-max-microvolt = <3700000>;
+	};
+
+	vreg_s4a_1p8: pm8150-s4 {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_s4a_1p8";
+
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+
+		regulator-always-on;
+		regulator-boot-on;
+
+		vin-supply = <&vph_pwr>;
+	};
+
+	vreg_s6c_0p88: smpc6-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vreg_s6c_0p88";
+
+		regulator-min-microvolt = <880000>;
+		regulator-max-microvolt = <880000>;
+		regulator-always-on;
+		vin-supply = <&vph_pwr>;
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+
+		vol-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&pm8150_gpios 6 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+&apps_rsc {
+	pm8150-rpmh-regulators {
+		compatible = "qcom,pm8150-rpmh-regulators";
+		qcom,pmic-id = "a";
+
+		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-s7-supply = <&vph_pwr>;
+		vdd-s8-supply = <&vph_pwr>;
+		vdd-s9-supply = <&vph_pwr>;
+		vdd-s10-supply = <&vph_pwr>;
+		vdd-l1-l8-l11-supply = <&vreg_s6c_0p88>;
+		vdd-l2-l10-supply = <&vreg_bob>;
+		vdd-l3-l4-l5-l18-supply = <&vreg_s6a_0p95>;
+		vdd-l6-l9-supply = <&vreg_s8c_1p3>;
+		vdd-l7-l12-l14-l15-supply = <&vreg_s5a_1p9>;
+		vdd-l13-l16-l17-supply = <&vreg_bob>;
+
+		vreg_s5a_1p9: smps5 {
+			regulator-name = "vreg_s5a_1p9";
+			regulator-min-microvolt = <1824000>;
+			regulator-max-microvolt = <2000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_s6a_0p95: smps6 {
+			regulator-name = "vreg_s6a_0p95";
+			regulator-min-microvolt = <600000>;
+			regulator-max-microvolt = <1128000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2a_3p1: ldo2 {
+			regulator-name = "vreg_l2a_3p1";
+			regulator-min-microvolt = <3072000>;
+			regulator-max-microvolt = <3072000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3a_0p9: ldo3 {
+			regulator-name = "vreg_l3a_0p9";
+			regulator-min-microvolt = <928000>;
+			regulator-max-microvolt = <932000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5a_0p88: ldo5 {
+			regulator-name = "vreg_l5a_0p88";
+			regulator-min-microvolt = <880000>;
+			regulator-max-microvolt = <880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6a_1p2: ldo6 {
+			regulator-name = "vreg_l6a_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7a_1p7: ldo7 {
+			regulator-name = "vreg_l7a_1p7";
+			regulator-min-microvolt = <1704000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9a_1p2: ldo9 {
+			regulator-name = "vreg_l9a_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10a_1p8: ldo10 {
+			regulator-name = "vreg_l10a_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l12a_1p8: ldo12 {
+			regulator-name = "vreg_l12a_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l13a_ts_3p0: ldo13 {
+			regulator-name = "vreg_l13a_ts_3p0";
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l14a_1p8: ldo14 {
+			regulator-name = "vreg_l14a_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1880000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l15a_1p8: ldo15 {
+			regulator-name = "vreg_l15a_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l16a_3p3: ldo16 {
+			regulator-name = "vreg_l16a_3p3";
+			regulator-min-microvolt = <3024000>;
+			regulator-max-microvolt = <3304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l17a_2p96: ldo17 {
+			regulator-name = "vreg_l17a_2p96";
+			regulator-min-microvolt = <2496000>;
+			regulator-max-microvolt = <3008000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l18a_0p92: ldo18 {
+			regulator-name = "vreg_l18a_0p92";
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <920000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	pm8150l-rpmh-regulators {
+		compatible = "qcom,pm8150l-rpmh-regulators";
+		qcom,pmic-id = "c";
+
+		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-s7-supply = <&vph_pwr>;
+		vdd-s8-supply = <&vph_pwr>;
+		vdd-l1-l8-supply = <&vreg_s4a_1p8>;
+		vdd-l2-l3-supply = <&vreg_s8c_1p3>;
+		vdd-l4-l5-l6-supply = <&vreg_bob>;
+		vdd-l7-l11-supply = <&vreg_bob>;
+		vdd-l9-l10-supply = <&vreg_bob>;
+		vdd-bob-supply = <&vph_pwr>;
+
+		vreg_bob: bob {
+			regulator-name = "vreg_bob";
+			regulator-min-microvolt = <3008000>;
+			regulator-max-microvolt = <3960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+		};
+
+		vreg_s8c_1p3: smps8 {
+			regulator-name = "vreg_s8c_1p3";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1400000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l1c_1p8: ldo1 {
+			regulator-name = "vreg_l1c_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2c_1p2: ldo2 {
+			regulator-name = "vreg_l2c_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1304000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3c_0p8: ldo3 {
+			regulator-name = "vreg_l3c_0p8";
+			regulator-min-microvolt = <800000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l4c_1p8: ldo4 {
+			regulator-name = "vreg_l4c_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5c_1p8: ldo5 {
+			regulator-name = "vreg_l5c_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6c_2p96: ldo6 {
+			regulator-name = "vreg_l6c_2p96";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7c_cam_vcm0_2p85: ldo7 {
+			regulator-name = "vreg_l7c_cam_vcm0_2p85";
+			regulator-min-microvolt = <2856000>;
+			regulator-max-microvolt = <3104000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l8c_1p8: ldo8 {
+			regulator-name = "vreg_l8c_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l9c_2p96: ldo9 {
+			regulator-name = "vreg_l9c_2p96";
+			regulator-min-microvolt = <2704000>;
+			regulator-max-microvolt = <2960000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l10c_3p0: ldo10 {
+			regulator-name = "vreg_l10c_3p0";
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l11c_3p3: ldo11 {
+			regulator-name = "vreg_l11c_3p3";
+			regulator-min-microvolt = <3104000>;
+			regulator-max-microvolt = <3312000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+
+	pm8009-rpmh-regulators {
+		compatible = "qcom,pm8009-rpmh-regulators";
+		qcom,pmic-id = "f";
+
+		vdd-s1-supply = <&vph_pwr>;
+		vdd-s2-supply = <&vreg_bob>;
+		vdd-l2-supply = <&vreg_s8c_1p3>;
+		vdd-l5-l6-supply = <&vreg_bob>;
+		vdd-l7-supply = <&vreg_s4a_1p8>;
+
+		vreg_l1f_cam_dvdd1_1p1: ldo1 {
+			regulator-name = "vreg_l1f_cam_dvdd1_1p1";
+			regulator-min-microvolt = <1104000>;
+			regulator-max-microvolt = <1104000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l2f_cam_dvdd0_1p2: ldo2 {
+			regulator-name = "vreg_l2f_cam_dvdd0_1p2";
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l3f_cam_dvdd2_1p05: ldo3 {
+			regulator-name = "vreg_l3f_cam_dvdd2_1p05";
+			regulator-min-microvolt = <1056000>;
+			regulator-max-microvolt = <1056000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l5f_cam_avdd0_2p85: ldo5 {
+			regulator-name = "vreg_l5f_cam_avdd0_2p85";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l6f_cam_avdd1_2p8: ldo6 {
+			regulator-name = "vreg_l6f_cam_avdd1_2p8";
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3000000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+
+		vreg_l7f_1p8: ldo7 {
+			regulator-name = "vreg_l7f_1p8";
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+		};
+	};
+};
+
+&qupv3_id_1 {
+	status = "okay";
+};
+
+&pon {
+	pwrkey {
+		status = "okay";
+	};
+
+	resin {
+		compatible = "qcom,pm8941-resin";
+		interrupts = <0x0 0x8 0x1 IRQ_TYPE_EDGE_BOTH>;
+		debounce = <15625>;
+		bias-pull-up;
+		linux,code = <KEY_VOLUMEDOWN>;
+	};
+};
+
+&tlmm {
+	gpio-reserved-ranges = <28 4>, <40 4>;
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&ufs_mem_hc {
+	status = "okay";
+
+	vcc-supply = <&vreg_l17a_2p96>;
+	vcc-max-microamp = <800000>;
+	vccq-supply = <&vreg_l6a_1p2>;
+	vccq-max-microamp = <800000>;
+	vccq2-supply = <&vreg_s4a_1p8>;
+	vccq2-max-microamp = <800000>;
+};
+
+&ufs_mem_phy {
+	status = "okay";
+
+	vdda-phy-supply = <&vreg_l5a_0p88>;
+	vdda-max-microamp = <89900>;
+	vdda-pll-supply = <&vreg_l9a_1p2>;
+	vdda-pll-max-microamp = <18800>;
+};
+
+&usb_1_hsphy {
+	status = "okay";
+	vdda-pll-supply = <&vreg_l5a_0p88>;
+	vdda33-supply = <&vreg_l2a_3p1>;
+	vdda18-supply = <&vreg_l12a_1p8>;
+};
+
+&usb_2_hsphy {
+	status = "okay";
+	vdda-pll-supply = <&vreg_l5a_0p88>;
+	vdda33-supply = <&vreg_l2a_3p1>;
+	vdda18-supply = <&vreg_l12a_1p8>;
+};
+
+&usb_1_qmpphy {
+	status = "okay";
+	vdda-phy-supply = <&vreg_l9a_1p2>;
+	vdda-pll-supply = <&vreg_l18a_0p92>;
+};
+
+&usb_2_qmpphy {
+	status = "okay";
+	vdda-phy-supply = <&vreg_l9a_1p2>;
+	vdda-pll-supply = <&vreg_l18a_0p92>;
+};
+
+&usb_1 {
+	status = "okay";
+};
+
+&usb_2 {
+	status = "okay";
+};
+
+&usb_1_dwc3 {
+	dr_mode = "peripheral";
+};
+
+&usb_2_dwc3 {
+	dr_mode = "host";
+};
-- 
2.26.1

Re: [PATCH 6/6] arm64: dts: qcom: add sm8250 hdk dts

[Bjorn Andersson]

On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:

> Add initial HDK865 dts, based on sm8250-mtp, with a few changes.
> Notably, regulator configs are changed a bit.
> 
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
>  arch/arm64/boot/dts/qcom/Makefile       |   1 +
>  arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 ++++++++++++++++++++++++
>  2 files changed, 455 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index e5dbd8b63951..4649e8bc5034 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -24,6 +24,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sdm850-lenovo-yoga-c630.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-hdk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-hdk.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-mtp.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sm8250-hdk.dts b/arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> new file mode 100644
> index 000000000000..d35014bf4f81
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> @@ -0,0 +1,454 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include "sm8250.dtsi"
> +#include "pm8150.dtsi"
> +#include "pm8150b.dtsi"
> +#include "pm8150l.dtsi"
> +
> +/ {
> +	model = "Qualcomm Technologies, Inc. SM8250 HDK";
> +	compatible = "qcom,sm8250-hdk";

	compatible = "qcom,sm8250-hdk", "qcom,sm8250";

Apart from that this looks good!

Thanks,
Bjorn

Re: [PATCH 6/6] arm64: dts: qcom: add sm8250 hdk dts

[Jonathan Marek]

On 5/28/20 11:03 PM, Bjorn Andersson wrote:
> On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> 
>> Add initial HDK865 dts, based on sm8250-mtp, with a few changes.
>> Notably, regulator configs are changed a bit.
>>
>> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
>> ---
>>   arch/arm64/boot/dts/qcom/Makefile       |   1 +
>>   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 ++++++++++++++++++++++++
>>   2 files changed, 455 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>>
>> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
>> index e5dbd8b63951..4649e8bc5034 100644
>> --- a/arch/arm64/boot/dts/qcom/Makefile
>> +++ b/arch/arm64/boot/dts/qcom/Makefile
>> @@ -24,6 +24,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-mtp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sdm850-lenovo-yoga-c630.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-hdk.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sm8150-mtp.dtb
>> +dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-hdk.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= sm8250-mtp.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-1000.dtb
>>   dtb-$(CONFIG_ARCH_QCOM)	+= qcs404-evb-4000.dtb
>> diff --git a/arch/arm64/boot/dts/qcom/sm8250-hdk.dts b/arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>> new file mode 100644
>> index 000000000000..d35014bf4f81
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>> @@ -0,0 +1,454 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include "sm8250.dtsi"
>> +#include "pm8150.dtsi"
>> +#include "pm8150b.dtsi"
>> +#include "pm8150l.dtsi"
>> +
>> +/ {
>> +	model = "Qualcomm Technologies, Inc. SM8250 HDK";
>> +	compatible = "qcom,sm8250-hdk";
> 
> 	compatible = "qcom,sm8250-hdk", "qcom,sm8250";
> 
> Apart from that this looks good!
> 

Made this change for both HDK dts, but FYI the mtp dts do not have this.

> Thanks,
> Bjorn
> 

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Bjorn Andersson]

On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:

> Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> 
> Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> few changes. Notably, the HDK865 dts has regulator config changed a bit based
> on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).

Can you please elaborate on this discrepancy? I do remember seeing
something odd when looking at this, but it seems like I didn't document
it anywhere...

Thanks,
Bjorn

> 
> Jonathan Marek (6):
>   arm64: dts: qcom: sm8150: add apps_smmu node
>   arm64: dts: qcom: sm8250: add apps_smmu node
>   arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
>   arm64: dts: qcom: sm8250: Add USB and PHY device nodes
>   arm64: dts: qcom: add sm8150 hdk dts
>   arm64: dts: qcom: add sm8250 hdk dts
> 
>  arch/arm64/boot/dts/qcom/Makefile       |   2 +
>  arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
>  arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
>  5 files changed, 1384 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> 
> -- 
> 2.26.1
> 

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Jonathan Marek]

On 5/28/20 11:05 PM, Bjorn Andersson wrote:
> On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> 
>> Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
>>
>> Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
>> few changes. Notably, the HDK865 dts has regulator config changed a bit based
>> on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> 
> Can you please elaborate on this discrepancy? I do remember seeing
> something odd when looking at this, but it seems like I didn't document
> it anywhere...
> 
> Thanks,
> Bjorn
> 

Mainly there's a few regulators with different min/max voltage values. 
For example with l16a, downstream has min/max 3024000/3304000 but 
upstream sm8250-mtp has 2704000/2960000. I also added l18a.

>>
>> Jonathan Marek (6):
>>    arm64: dts: qcom: sm8150: add apps_smmu node
>>    arm64: dts: qcom: sm8250: add apps_smmu node
>>    arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
>>    arm64: dts: qcom: sm8250: Add USB and PHY device nodes
>>    arm64: dts: qcom: add sm8150 hdk dts
>>    arm64: dts: qcom: add sm8250 hdk dts
>>
>>   arch/arm64/boot/dts/qcom/Makefile       |   2 +
>>   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
>>   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
>>   5 files changed, 1384 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>>
>> -- 
>> 2.26.1
>>

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Bjorn Andersson]

On Thu 28 May 20:15 PDT 2020, Jonathan Marek wrote:

> On 5/28/20 11:05 PM, Bjorn Andersson wrote:
> > On Sat 23 May 19:38 PDT 2020, Jonathan Marek wrote:
> > 
> > > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > > 
> > > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > > few changes. Notably, the HDK865 dts has regulator config changed a bit based
> > > on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> > 
> > Can you please elaborate on this discrepancy? I do remember seeing
> > something odd when looking at this, but it seems like I didn't document
> > it anywhere...
> > 
> > Thanks,
> > Bjorn
> > 
> 
> Mainly there's a few regulators with different min/max voltage values. For
> example with l16a, downstream has min/max 3024000/3304000 but upstream
> sm8250-mtp has 2704000/2960000. I also added l18a.
> 

Thanks, we'll double check these.

Regards,
Bjorn

> > > 
> > > Jonathan Marek (6):
> > >    arm64: dts: qcom: sm8150: add apps_smmu node
> > >    arm64: dts: qcom: sm8250: add apps_smmu node
> > >    arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> > >    arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> > >    arm64: dts: qcom: add sm8150 hdk dts
> > >    arm64: dts: qcom: add sm8250 hdk dts
> > > 
> > >   arch/arm64/boot/dts/qcom/Makefile       |   2 +
> > >   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
> > >   arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
> > >   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
> > >   arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
> > >   5 files changed, 1384 insertions(+)
> > >   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> > >   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> > > 
> > > -- 
> > > 2.26.1
> > > 

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Manivannan Sadhasivam]

Hi,

On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
> Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> 

I've tested this series on an SM8250 based board and able to get Type C (USB0)
working. There are also couple of Type A ports (USB1) on that board behind a
USB hub. It is probing fine but I don't see any activity while connecting a
USB device. Will continue to debug and once I get them working, I'll add my
Tested-by tag.

Thanks,
Mani

> Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> few changes. Notably, the HDK865 dts has regulator config changed a bit based
> on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> 
> Jonathan Marek (6):
>   arm64: dts: qcom: sm8150: add apps_smmu node
>   arm64: dts: qcom: sm8250: add apps_smmu node
>   arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
>   arm64: dts: qcom: sm8250: Add USB and PHY device nodes
>   arm64: dts: qcom: add sm8150 hdk dts
>   arm64: dts: qcom: add sm8250 hdk dts
> 
>  arch/arm64/boot/dts/qcom/Makefile       |   2 +
>  arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
>  arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
>  arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
>  5 files changed, 1384 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>  create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> 
> -- 
> 2.26.1
> 

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Jonathan Marek]

On 6/4/20 9:52 AM, Manivannan Sadhasivam wrote:
> Hi,
> 
> On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
>> Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
>>
> 
> I've tested this series on an SM8250 based board and able to get Type C (USB0)
> working. There are also couple of Type A ports (USB1) on that board behind a
> USB hub. It is probing fine but I don't see any activity while connecting a
> USB device. Will continue to debug and once I get them working, I'll add my
> Tested-by tag.
> 

HDK865 also has a couple Type A ports, I am using them with devices 
already plugged in during boot and I haven't hit a problem like that, 
but I think I've seen the same issue when hotplugging. IIRC the behavior 
was a bit weird, like plugging a device in the Type A port (USB1) 
nothing would happen, but unplugging/replugging the type C port (USB0) 
would cause the Type A port device to start working..

Have you tried with the devices already plugged in before booting?

> Thanks,
> Mani
> 
>> Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
>> few changes. Notably, the HDK865 dts has regulator config changed a bit based
>> on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
>>
>> Jonathan Marek (6):
>>    arm64: dts: qcom: sm8150: add apps_smmu node
>>    arm64: dts: qcom: sm8250: add apps_smmu node
>>    arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
>>    arm64: dts: qcom: sm8250: Add USB and PHY device nodes
>>    arm64: dts: qcom: add sm8150 hdk dts
>>    arm64: dts: qcom: add sm8250 hdk dts
>>
>>   arch/arm64/boot/dts/qcom/Makefile       |   2 +
>>   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
>>   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
>>   arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
>>   5 files changed, 1384 insertions(+)
>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>>
>> -- 
>> 2.26.1
>>

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Manivannan Sadhasivam]

On Thu, Jun 04, 2020 at 10:06:19AM -0400, Jonathan Marek wrote:
> On 6/4/20 9:52 AM, Manivannan Sadhasivam wrote:
> > Hi,
> > 
> > On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
> > > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > > 
> > 
> > I've tested this series on an SM8250 based board and able to get Type C (USB0)
> > working. There are also couple of Type A ports (USB1) on that board behind a
> > USB hub. It is probing fine but I don't see any activity while connecting a
> > USB device. Will continue to debug and once I get them working, I'll add my
> > Tested-by tag.
> > 
> 
> HDK865 also has a couple Type A ports, I am using them with devices already
> plugged in during boot and I haven't hit a problem like that, but I think
> I've seen the same issue when hotplugging. IIRC the behavior was a bit
> weird, like plugging a device in the Type A port (USB1) nothing would
> happen, but unplugging/replugging the type C port (USB0) would cause the
> Type A port device to start working..
> 
> Have you tried with the devices already plugged in before booting?
> 

Tried it but no luck :/ Also plugging and removing Type C doesn't make any
difference.

Thanks,
Mani

> > Thanks,
> > Mani
> > 
> > > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > > few changes. Notably, the HDK865 dts has regulator config changed a bit based
> > > on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> > > 
> > > Jonathan Marek (6):
> > >    arm64: dts: qcom: sm8150: add apps_smmu node
> > >    arm64: dts: qcom: sm8250: add apps_smmu node
> > >    arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> > >    arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> > >    arm64: dts: qcom: add sm8150 hdk dts
> > >    arm64: dts: qcom: add sm8250 hdk dts
> > > 
> > >   arch/arm64/boot/dts/qcom/Makefile       |   2 +
> > >   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
> > >   arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
> > >   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
> > >   arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
> > >   5 files changed, 1384 insertions(+)
> > >   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> > >   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> > > 
> > > -- 
> > > 2.26.1
> > > 

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Jonathan Marek]

On 6/4/20 11:58 AM, Manivannan Sadhasivam wrote:
> On Thu, Jun 04, 2020 at 10:06:19AM -0400, Jonathan Marek wrote:
>> On 6/4/20 9:52 AM, Manivannan Sadhasivam wrote:
>>> Hi,
>>>
>>> On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
>>>> Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
>>>>
>>>
>>> I've tested this series on an SM8250 based board and able to get Type C (USB0)
>>> working. There are also couple of Type A ports (USB1) on that board behind a
>>> USB hub. It is probing fine but I don't see any activity while connecting a
>>> USB device. Will continue to debug and once I get them working, I'll add my
>>> Tested-by tag.
>>>
>>
>> HDK865 also has a couple Type A ports, I am using them with devices already
>> plugged in during boot and I haven't hit a problem like that, but I think
>> I've seen the same issue when hotplugging. IIRC the behavior was a bit
>> weird, like plugging a device in the Type A port (USB1) nothing would
>> happen, but unplugging/replugging the type C port (USB0) would cause the
>> Type A port device to start working..
>>
>> Have you tried with the devices already plugged in before booting?
>>
> 
> Tried it but no luck :/ Also plugging and removing Type C doesn't make any
> difference.
> 

This one might be obvious, but do you have 5V power coming out of the 
type A ports?

> Thanks,
> Mani
> 
>>> Thanks,
>>> Mani
>>>
>>>> Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
>>>> few changes. Notably, the HDK865 dts has regulator config changed a bit based
>>>> on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
>>>>
>>>> Jonathan Marek (6):
>>>>     arm64: dts: qcom: sm8150: add apps_smmu node
>>>>     arm64: dts: qcom: sm8250: add apps_smmu node
>>>>     arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
>>>>     arm64: dts: qcom: sm8250: Add USB and PHY device nodes
>>>>     arm64: dts: qcom: add sm8150 hdk dts
>>>>     arm64: dts: qcom: add sm8250 hdk dts
>>>>
>>>>    arch/arm64/boot/dts/qcom/Makefile       |   2 +
>>>>    arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>>>>    arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
>>>>    arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
>>>>    arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
>>>>    5 files changed, 1384 insertions(+)
>>>>    create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>>>>    create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>>>>
>>>> -- 
>>>> 2.26.1
>>>>

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Manivannan Sadhasivam]

On Thu, Jun 04, 2020 at 07:22:21PM +0530, Manivannan Sadhasivam wrote:
> Hi,
> 
> On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
> > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > 
> 
> I've tested this series on an SM8250 based board and able to get Type C (USB0)
> working. There are also couple of Type A ports (USB1) on that board behind a
> USB hub. It is probing fine but I don't see any activity while connecting a
> USB device. Will continue to debug and once I get them working, I'll add my
> Tested-by tag.
> 

So it turned out that I forgot to enable one regulator which kept the USB hub
powered down. After enabling that, both Type A ports are working. Hence,

Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Thanks,
Mani

> Thanks,
> Mani
> 
> > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > few changes. Notably, the HDK865 dts has regulator config changed a bit based
> > on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> > 
> > Jonathan Marek (6):
> >   arm64: dts: qcom: sm8150: add apps_smmu node
> >   arm64: dts: qcom: sm8250: add apps_smmu node
> >   arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> >   arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> >   arm64: dts: qcom: add sm8150 hdk dts
> >   arm64: dts: qcom: add sm8250 hdk dts
> > 
> >  arch/arm64/boot/dts/qcom/Makefile       |   2 +
> >  arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
> >  arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
> >  arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
> >  arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
> >  5 files changed, 1384 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> >  create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> > 
> > -- 
> > 2.26.1
> > 

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Jonathan Marek]

On 6/11/20 2:05 PM, Manivannan Sadhasivam wrote:
> On Thu, Jun 04, 2020 at 07:22:21PM +0530, Manivannan Sadhasivam wrote:
>> Hi,
>>
>> On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
>>> Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
>>>
>>
>> I've tested this series on an SM8250 based board and able to get Type C (USB0)
>> working. There are also couple of Type A ports (USB1) on that board behind a
>> USB hub. It is probing fine but I don't see any activity while connecting a
>> USB device. Will continue to debug and once I get them working, I'll add my
>> Tested-by tag.
>>
> 
> So it turned out that I forgot to enable one regulator which kept the USB hub
> powered down. After enabling that, both Type A ports are working. Hence,
> 
> Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> 
> Thanks,
> Mani
> 

Thanks for testing it. Your Tested-by only applies to the relevant 
patches (patches 2 and 4 in this version) right? And can I also add your 
Tested-by tag to my other series 
(https://patchwork.kernel.org/cover/11567095/) which this depends on?

>> Thanks,
>> Mani
>>
>>> Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
>>> few changes. Notably, the HDK865 dts has regulator config changed a bit based
>>> on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
>>>
>>> Jonathan Marek (6):
>>>    arm64: dts: qcom: sm8150: add apps_smmu node
>>>    arm64: dts: qcom: sm8250: add apps_smmu node
>>>    arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
>>>    arm64: dts: qcom: sm8250: Add USB and PHY device nodes
>>>    arm64: dts: qcom: add sm8150 hdk dts
>>>    arm64: dts: qcom: add sm8250 hdk dts
>>>
>>>   arch/arm64/boot/dts/qcom/Makefile       |   2 +
>>>   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
>>>   arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
>>>   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
>>>   arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
>>>   5 files changed, 1384 insertions(+)
>>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
>>>   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
>>>
>>> -- 
>>> 2.26.1
>>>

Re: [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Manivannan Sadhasivam]

On Thu, Jun 11, 2020 at 02:14:43PM -0400, Jonathan Marek wrote:
> On 6/11/20 2:05 PM, Manivannan Sadhasivam wrote:
> > On Thu, Jun 04, 2020 at 07:22:21PM +0530, Manivannan Sadhasivam wrote:
> > > Hi,
> > > 
> > > On Sat, May 23, 2020 at 10:38:06PM -0400, Jonathan Marek wrote:
> > > > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > > > 
> > > 
> > > I've tested this series on an SM8250 based board and able to get Type C (USB0)
> > > working. There are also couple of Type A ports (USB1) on that board behind a
> > > USB hub. It is probing fine but I don't see any activity while connecting a
> > > USB device. Will continue to debug and once I get them working, I'll add my
> > > Tested-by tag.
> > > 
> > 
> > So it turned out that I forgot to enable one regulator which kept the USB hub
> > powered down. After enabling that, both Type A ports are working. Hence,
> > 
> > Tested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > 
> > Thanks,
> > Mani
> > 
> 
> Thanks for testing it. Your Tested-by only applies to the relevant patches
> (patches 2 and 4 in this version) right? And can I also add your Tested-by
> tag to my other series (https://patchwork.kernel.org/cover/11567095/) which
> this depends on?
> 

Sure. You can add it for all SM8250 USB patches.

Thanks,
Mani

> > > Thanks,
> > > Mani
> > > 
> > > > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > > > few changes. Notably, the HDK865 dts has regulator config changed a bit based
> > > > on downstream (I think sm8250-mtp.dts is wrong and copied too much from sm8150).
> > > > 
> > > > Jonathan Marek (6):
> > > >    arm64: dts: qcom: sm8150: add apps_smmu node
> > > >    arm64: dts: qcom: sm8250: add apps_smmu node
> > > >    arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> > > >    arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> > > >    arm64: dts: qcom: add sm8150 hdk dts
> > > >    arm64: dts: qcom: add sm8250 hdk dts
> > > > 
> > > >   arch/arm64/boot/dts/qcom/Makefile       |   2 +
> > > >   arch/arm64/boot/dts/qcom/sm8150-hdk.dts | 461 ++++++++++++++++++++++++
> > > >   arch/arm64/boot/dts/qcom/sm8150.dtsi    | 180 +++++++++
> > > >   arch/arm64/boot/dts/qcom/sm8250-hdk.dts | 454 +++++++++++++++++++++++
> > > >   arch/arm64/boot/dts/qcom/sm8250.dtsi    | 287 +++++++++++++++
> > > >   5 files changed, 1384 insertions(+)
> > > >   create mode 100644 arch/arm64/boot/dts/qcom/sm8150-hdk.dts
> > > >   create mode 100644 arch/arm64/boot/dts/qcom/sm8250-hdk.dts
> > > > 
> > > > -- 
> > > > 2.26.1
> > > >