| Message ID | 20220901072414.1923075-1-iskren.chernev@gmail.com |
|---|---|
| Headers | show |
| Series | Add support for sm6115,4250 and OnePlus Nord N100 | expand |
On 01-09-22, 10:24, Iskren Chernev wrote: > Kryo240 is found in SM4250, the slower sibling of the SM6115. Reviewed-by: Vinod Koul <vkoul@kernel.org>
On 01/09/2022 10:24, Iskren Chernev wrote: > Add support for the main clock bundle on the SM6115. > > Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> > --- > arch/arm64/boot/dts/qcom/sm6115.dtsi | 11 +++++++++++ > 1 file changed, 11 insertions(+) This needs squashing, because one patchset per device node on first submission does not make sense. Please squash all your 1-7, 8-10 patches. Best regards, Krzysztof
On 1.09.2022 18:20, Krzysztof Kozlowski wrote: > On 01/09/2022 10:24, Iskren Chernev wrote: >> Add initial support for OnePlus Nord N100, based on SM4250. Currently >> working: >> - boots >> - usb >> - buildin flash storage (UFS) >> - SD card reader >> >> Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> >> --- >> .../boot/dts/qcom/sm4250-oneplus-billie2.dts | 240 ++++++++++++++++++ >> 1 file changed, 240 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dts >> >> diff --git a/arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dts b/arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dts >> new file mode 100644 >> index 000000000000..c1cf0288aa5f >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dts >> @@ -0,0 +1,240 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (c) 2021, Iskren Chernev <iskren.chernev@gmail.com> >> + */ >> + >> +/dts-v1/; >> + >> +#include "sm4250.dtsi" >> + >> +/ { >> + model = "OnePlus Nord N100"; >> + compatible = "oneplus,billie2", "qcom,sm4250"; >> + >> + /* required for bootloader to select correct board */ >> + qcom,msm-id = <0x1a1 0x10000 0x1bc 0x10000>; >> + qcom,board-id = <0x1000b 0x00>; >> + >> + aliases { >> + }; >> + >> + chosen { >> + bootargs = "earlycon=tty0 console=tty0 clk_ignore_unused pd_ignore_unused"; > > No bootargs. They are not suitable for wide-use. Agreed, the problem here is probably the framebuffer dying after our clock controllers probe. One can solve that by adding the relevant clocks/PDs under the framebuffer node like I did in sm8[123]50 Xperia DTs. Konrad
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 <iskren.chernev@gmail.com> >> --- >> 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 <iskren.chernev@gmail.com> >>> --- >>> 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 <iskren.chernev@gmail.com> >>>> --- >>>> 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