The SM6115 comes with UFS support, so add the related UFS and UFS PHY
nodes.
Signed-off-by: Iskren Chernev <[email protected]>
---
arch/arm64/boot/dts/qcom/sm6115.dtsi | 70 ++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
index cde963c56ac9..491fffff8aa1 100644
--- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
@@ -620,6 +620,76 @@ opp-202000000 {
};
};
+ ufs_mem_hc: ufshc@4804000 {
+ compatible = "qcom,sm6115-ufshc", "qcom,ufshc",
+ "jedec,ufs-2.0";
+ reg = <0x4804000 0x3000>, <0x4810000 0x8000>;
+ reg-names = "std", "ice";
+ interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&ufs_mem_phy_lanes>;
+ phy-names = "ufsphy";
+ lanes-per-direction = <1>;
+ #reset-cells = <1>;
+ resets = <&gcc GCC_UFS_PHY_BCR>;
+ reset-names = "rst";
+
+ power-domains = <&gcc GCC_UFS_PHY_GDSC>;
+ iommus = <&apps_smmu 0x100 0>;
+
+ clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_SYS_NOC_UFS_PHY_AXI_CLK>,
+ <&gcc GCC_UFS_PHY_AHB_CLK>,
+ <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
+ <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
+ <&rpmcc RPM_SMD_XO_CLK_SRC>,
+ <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
+ <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>;
+ clock-names = "core_clk",
+ "bus_aggr_clk",
+ "iface_clk",
+ "core_clk_unipro",
+ "core_clk_ice",
+ "ref_clk",
+ "tx_lane0_sync_clk",
+ "rx_lane0_sync_clk";
+
+ freq-table-hz = <50000000 200000000>,
+ <0 0>,
+ <0 0>,
+ <37500000 150000000>,
+ <75000000 300000000>,
+ <0 0>,
+ <0 0>,
+ <0 0>;
+
+ non-removable;
+ status = "disabled";
+ };
+
+ ufs_mem_phy: phy@4807000 {
+ compatible = "qcom,sm6115-qmp-ufs-phy";
+ reg = <0x4807000 0x1c4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ clocks = <&gcc GCC_UFS_CLKREF_CLK>,
+ <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
+ clock-names = "ref", "ref_aux";
+
+ resets = <&ufs_mem_hc 0>;
+ reset-names = "ufsphy";
+ status = "disabled";
+
+ ufs_mem_phy_lanes: lanes@4807400 {
+ reg = <0x4807400 0x098>,
+ <0x4807600 0x130>,
+ <0x4807c00 0x16c>;
+ #phy-cells = <0>;
+ };
+ };
+
+
usb3: usb@4ef8800 {
compatible = "qcom,sm6115-dwc3", "qcom,dwc3";
reg = <0x04ef8800 0x400>;
--
2.37.2
On 01/09/2022 10:24, Iskren Chernev wrote:
> The SM6115 comes with UFS support, so add the related UFS and UFS PHY
> nodes.
>
> Signed-off-by: Iskren Chernev <[email protected]>
> ---
> arch/arm64/boot/dts/qcom/sm6115.dtsi | 70 ++++++++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
> index cde963c56ac9..491fffff8aa1 100644
> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
> @@ -620,6 +620,76 @@ opp-202000000 {
> };
> };
>
> + ufs_mem_hc: ufshc@4804000 {
> + compatible = "qcom,sm6115-ufshc", "qcom,ufshc",
> + "jedec,ufs-2.0";
> + reg = <0x4804000 0x3000>, <0x4810000 0x8000>;
> + reg-names = "std", "ice";
I could imagine that testing DTS against existing bindings might miss a
lot, because we have still a lot of errors. But at least I would expect
you test your DTS against your own bindings, which you submit here (and
previously).
You just wrote that ice is not allowed.
> + interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&ufs_mem_phy_lanes>;
> + phy-names = "ufsphy";
> + lanes-per-direction = <1>;
> + #reset-cells = <1>;
> + resets = <&gcc GCC_UFS_PHY_BCR>;
> + reset-names = "rst";
> +
> + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
> + iommus = <&apps_smmu 0x100 0>;
> +
> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_SYS_NOC_UFS_PHY_AXI_CLK>,
> + <&gcc GCC_UFS_PHY_AHB_CLK>,
> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
> + <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
> + <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>;
> + clock-names = "core_clk",
> + "bus_aggr_clk",
> + "iface_clk",
> + "core_clk_unipro",
> + "core_clk_ice",
> + "ref_clk",
> + "tx_lane0_sync_clk",
> + "rx_lane0_sync_clk";
> +
> + freq-table-hz = <50000000 200000000>,
> + <0 0>,
> + <0 0>,
> + <37500000 150000000>,
> + <75000000 300000000>,
> + <0 0>,
> + <0 0>,
> + <0 0>;
> +
> + non-removable;
Is it allowed property?
> + status = "disabled";
> + };
> +
> + ufs_mem_phy: phy@4807000 {
> + compatible = "qcom,sm6115-qmp-ufs-phy";
> + reg = <0x4807000 0x1c4>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + clocks = <&gcc GCC_UFS_CLKREF_CLK>,
> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
> + clock-names = "ref", "ref_aux";
> +
> + resets = <&ufs_mem_hc 0>;
> + reset-names = "ufsphy";
> + status = "disabled";
> +
> + ufs_mem_phy_lanes: lanes@4807400 {
> + reg = <0x4807400 0x098>,
> + <0x4807600 0x130>,
> + <0x4807c00 0x16c>;
> + #phy-cells = <0>;
> + };
> + };
> +
> +
Just one blank line.
Best regards,
Krzysztof
On 9/1/22 19:13, Krzysztof Kozlowski wrote:
> On 01/09/2022 10:24, Iskren Chernev wrote:
>> The SM6115 comes with UFS support, so add the related UFS and UFS PHY
>> nodes.
>>
>> Signed-off-by: Iskren Chernev <[email protected]>
>> ---
>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 70 ++++++++++++++++++++++++++++
>> 1 file changed, 70 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
>> index cde963c56ac9..491fffff8aa1 100644
>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
>> @@ -620,6 +620,76 @@ opp-202000000 {
>> };
>> };
>>
>> + ufs_mem_hc: ufshc@4804000 {
>> + compatible = "qcom,sm6115-ufshc", "qcom,ufshc",
>> + "jedec,ufs-2.0";
>> + reg = <0x4804000 0x3000>, <0x4810000 0x8000>;
>> + reg-names = "std", "ice";
>
> I could imagine that testing DTS against existing bindings might miss a
> lot, because we have still a lot of errors. But at least I would expect
> you test your DTS against your own bindings, which you submit here (and
> previously).
>
> You just wrote that ice is not allowed.
OK, I'm an idiot. I didn't run the bindings checks, not against existing
bindings or my bindings or whatever. It's my fault.
Ice should be allowed, I fixed the bindings in v2.
For the record, running dtbs_checks is a PITA, not only because of the
thousands of warnings in unrelated code, but because it takes forever.
Maybe the docs should be updated with instructions on how to run it on a single
(or a small subset) of DTBs. I had to comment out a lot of Makefile lines to
focus it on mine. It would really help if the binding check works more like
a compiler, not some magic spell hidden in a bunch of Makefiles.
I'll list all remaining issues with description/explanation in v2. The fact
that some bindings break on all DTBs present doesn't help either.
>> + interrupts = <GIC_SPI 356 IRQ_TYPE_LEVEL_HIGH>;
>> + phys = <&ufs_mem_phy_lanes>;
>> + phy-names = "ufsphy";
>> + lanes-per-direction = <1>;
>> + #reset-cells = <1>;
>> + resets = <&gcc GCC_UFS_PHY_BCR>;
>> + reset-names = "rst";
>> +
>> + power-domains = <&gcc GCC_UFS_PHY_GDSC>;
>> + iommus = <&apps_smmu 0x100 0>;
>> +
>> + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>,
>> + <&gcc GCC_SYS_NOC_UFS_PHY_AXI_CLK>,
>> + <&gcc GCC_UFS_PHY_AHB_CLK>,
>> + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>,
>> + <&gcc GCC_UFS_PHY_ICE_CORE_CLK>,
>> + <&rpmcc RPM_SMD_XO_CLK_SRC>,
>> + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>,
>> + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>;
>> + clock-names = "core_clk",
>> + "bus_aggr_clk",
>> + "iface_clk",
>> + "core_clk_unipro",
>> + "core_clk_ice",
>> + "ref_clk",
>> + "tx_lane0_sync_clk",
>> + "rx_lane0_sync_clk";
>> +
>> + freq-table-hz = <50000000 200000000>,
>> + <0 0>,
>> + <0 0>,
>> + <37500000 150000000>,
>> + <75000000 300000000>,
>> + <0 0>,
>> + <0 0>,
>> + <0 0>;
>> +
>> + non-removable;
>
> Is it allowed property?
I dropped it.
>> + status = "disabled";
>> + };
>> +
>> + ufs_mem_phy: phy@4807000 {
>> + compatible = "qcom,sm6115-qmp-ufs-phy";
>> + reg = <0x4807000 0x1c4>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + clocks = <&gcc GCC_UFS_CLKREF_CLK>,
>> + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>;
>> + clock-names = "ref", "ref_aux";
>> +
>> + resets = <&ufs_mem_hc 0>;
>> + reset-names = "ufsphy";
>> + status = "disabled";
>> +
>> + ufs_mem_phy_lanes: lanes@4807400 {
>> + reg = <0x4807400 0x098>,
>> + <0x4807600 0x130>,
>> + <0x4807c00 0x16c>;
>> + #phy-cells = <0>;
>> + };
>> + };
>> +
>> +
>
> Just one blank line.
>
> Best regards,
> Krzysztof
On 03/09/2022 19:04, Iskren Chernev wrote:
>
>
> On 9/1/22 19:13, Krzysztof Kozlowski wrote:
>> On 01/09/2022 10:24, Iskren Chernev wrote:
>>> The SM6115 comes with UFS support, so add the related UFS and UFS PHY
>>> nodes.
>>>
>>> Signed-off-by: Iskren Chernev <[email protected]>
>>> ---
>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 70 ++++++++++++++++++++++++++++
>>> 1 file changed, 70 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
>>> index cde963c56ac9..491fffff8aa1 100644
>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
>>> @@ -620,6 +620,76 @@ opp-202000000 {
>>> };
>>> };
>>>
>>> + ufs_mem_hc: ufshc@4804000 {
>>> + compatible = "qcom,sm6115-ufshc", "qcom,ufshc",
>>> + "jedec,ufs-2.0";
>>> + reg = <0x4804000 0x3000>, <0x4810000 0x8000>;
>>> + reg-names = "std", "ice";
>>
>> I could imagine that testing DTS against existing bindings might miss a
>> lot, because we have still a lot of errors. But at least I would expect
>> you test your DTS against your own bindings, which you submit here (and
>> previously).
>>
>> You just wrote that ice is not allowed.
>
> OK, I'm an idiot. I didn't run the bindings checks, not against existing
> bindings or my bindings or whatever. It's my fault.
>
> Ice should be allowed, I fixed the bindings in v2.
>
> For the record, running dtbs_checks is a PITA, not only because of the
> thousands of warnings in unrelated code, but because it takes forever.
You can limit it per schema and/or limit it per target, which would
speed up things. Of course it depends on computer you have, but I don't
find it slow on my laptop and I run them a lot...
>
> Maybe the docs should be updated with instructions on how to run it on a single
> (or a small subset) of DTBs. I had to comment out a lot of Makefile lines to
> focus it on mine. It would really help if the binding check works more like
> a compiler, not some magic spell hidden in a bunch of Makefiles.
crosc.... make -j8 DT_SCHEMA_FILES=exynos-srom.yaml CHECK_DTBS=y
qcom/sm8450-hdk.dtb
>
> I'll list all remaining issues with description/explanation in v2. The fact
> that some bindings break on all DTBs present doesn't help either.
We're working on this... It's quite a lot of effort, especially when new
warnings are being added. :)
Best regards,
Krzysztof
On 9/5/22 13:02, Krzysztof Kozlowski wrote:
> On 03/09/2022 19:04, Iskren Chernev wrote:
>>
>>
>> On 9/1/22 19:13, Krzysztof Kozlowski wrote:
>>> On 01/09/2022 10:24, Iskren Chernev wrote:
>>>> The SM6115 comes with UFS support, so add the related UFS and UFS PHY
>>>> nodes.
>>>>
>>>> Signed-off-by: Iskren Chernev <[email protected]>
>>>> ---
>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 70 ++++++++++++++++++++++++++++
>>>> 1 file changed, 70 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi
>>>> index cde963c56ac9..491fffff8aa1 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi
>>>> @@ -620,6 +620,76 @@ opp-202000000 {
>>>> };
>>>> };
>>>>
>>>> + ufs_mem_hc: ufshc@4804000 {
>>>> + compatible = "qcom,sm6115-ufshc", "qcom,ufshc",
>>>> + "jedec,ufs-2.0";
>>>> + reg = <0x4804000 0x3000>, <0x4810000 0x8000>;
>>>> + reg-names = "std", "ice";
>>>
>>> I could imagine that testing DTS against existing bindings might miss a
>>> lot, because we have still a lot of errors. But at least I would expect
>>> you test your DTS against your own bindings, which you submit here (and
>>> previously).
>>>
>>> You just wrote that ice is not allowed.
>>
>> OK, I'm an idiot. I didn't run the bindings checks, not against existing
>> bindings or my bindings or whatever. It's my fault.
>>
>> Ice should be allowed, I fixed the bindings in v2.
>>
>> For the record, running dtbs_checks is a PITA, not only because of the
>> thousands of warnings in unrelated code, but because it takes forever.
>
> You can limit it per schema and/or limit it per target, which would
> speed up things. Of course it depends on computer you have, but I don't
> find it slow on my laptop and I run them a lot...
For one file it's great. For all files (i.e make dtbs_check) it takes more than
30mins on my 4c/8t intel laptop. About limiting by schema... not really
useful for me (except if I write the schema, but then I use it in one dtb, so
it's easier to limit by dtb).
>>
>> Maybe the docs should be updated with instructions on how to run it on a single
>> (or a small subset) of DTBs. I had to comment out a lot of Makefile lines to
>> focus it on mine. It would really help if the binding check works more like
>> a compiler, not some magic spell hidden in a bunch of Makefiles.
>
> crosc.... make -j8 DT_SCHEMA_FILES=exynos-srom.yaml CHECK_DTBS=y
> qcom/sm8450-hdk.dtb
Aaah, very nice! Thank you!
>>
>> I'll list all remaining issues with description/explanation in v2. The fact
>> that some bindings break on all DTBs present doesn't help either.
>
> We're working on this... It's quite a lot of effort, especially when new
> warnings are being added. :)
I understand. Is there an up-for-grabs list, or any schema fixes are welcome?
> Best regards,
> Krzysztof
On 05/09/2022 12:45, Iskren Chernev wrote:
>
>>>
>>> I'll list all remaining issues with description/explanation in v2. The fact
>>> that some bindings break on all DTBs present doesn't help either.
>>
>> We're working on this... It's quite a lot of effort, especially when new
>> warnings are being added. :)
>
> I understand. Is there an up-for-grabs list, or any schema fixes are welcome?
Any fixes are welcomed, but check if someone did not post it. For
bindings conversion, the easiest is with "dfn:old-schema.txt" on
https://lore.kernel.org/all/.
We have some Linaro internal tracking, but maybe it would be useful to
expose it to avoid duplication of work and to track better what is still
to do/fix.
+Cc Nicolas,
Are we interested in some public tracking not only upstream status but
also actual things to do (like DTS fixes, DT schema conversions)? It
might be quite a lot of effort for us, but if community is engaged, they
would offload us in task tracking system.
Best regards,
Krzysztof