| Message ID | 20240703025850.2172008-1-quic_tengfan@quicinc.com |
|---|---|
| Headers | show |
| Series | arm64: qcom: dts: add QCS9100 support | expand |
On 03/07/2024 05:56, Tengfei Fan wrote: > Introduce support for the QCS9100 SoC device tree (DTSI) and the > QCS9100 RIDE board DTS. The QCS9100 is a variant of the SA8775p. > While the QCS9100 platform is still in the early design stage, the > QCS9100 RIDE board is identical to the SA8775p RIDE board, except it > mounts the QCS9100 SoC instead of the SA8775p SoC. The same huge patchset, to huge number of recipients was sent twice. First, sorry, this is way too big. Second, it has way too many recipients, but this is partially a result of first point. Only partially because you put here dozen of totally unrelated emails. Sorry, that does not make even sense. See form letter at the end how this works. Third, sending it to everyone twice is a way to annoy them off twice... Fourth, Please split your work and do not cc dozen of unrelated folks. <form letter> Please use scripts/get_maintainers.pl to get a list of necessary people and lists to CC (and consider --no-git-fallback argument). It might happen, that command when run on an older kernel, gives you outdated entries. Therefore please be sure you base your patches on recent Linux kernel. Tools like b4 or scripts/get_maintainer.pl provide you proper list of people, so fix your workflow. Tools might also fail if you work on some ancient tree (don't, instead use mainline), work on fork of kernel (don't, instead use mainline) or you ignore some maintainers (really don't). Just use b4 and everything should be fine, although remember about `b4 prep --auto-to-cc` if you added new patches to the patchset. </form letter> Best regards, Krzysztof
On 7/3/2024 9:27 AM, Tengfei Fan wrote:
> + - qcom,qcs9100-cpufreq-epss
This is not required as we already have sa8775p bindings.
On 7/3/2024 12:40 PM, Krzysztof Kozlowski wrote: > On 03/07/2024 04:58, Tengfei Fan wrote: >> Introduce QCS9100 SoC dtsi, QCS9100 is mainly used in IoT products. >> QCS9100 is drived from SA8775p. >> The current QCS9100 SoC dtsi is directly renamed from the SA8775p SoC >> dtsi. >> The QCS9100 platform is currently in the early design stage. Currently, >> Both the QCS9100 platform and SA8775p platform use non-SCMI resources, >> In the future, the SA8775p platform will transition to using SCMI >> resources and it will have new sa8775p-related device tree. >> This QCS9100 SoC dtsi remains consistent with the current SA8775p SoC >> dtsi, except for updating the following sa8775p-related compatible names >> to the qcs9100-related compatible name: >> - qcom,sa8775p-clk-virt >> - qcom,sa8775p-mc-virt >> - qcom,sa8775p-adsp-pas >> - qcom,sa8775p-cdsp-pas >> - qcom,sa8775p-cdsp1-pas >> - qcom,sa8775p-gpdsp0-pas >> - qcom,sa8775p-gpdsp1-pas >> - qcom,sa8775p-gcc >> - qcom,sa8775p-ipcc >> - qcom,sa8775p-config-noc >> - qcom,sa8775p-system-noc >> - qcom,sa8775p-aggre1-noc >> - qcom,sa8775p-aggre2-noc >> - qcom,sa8775p-pcie-anoc >> - qcom,sa8775p-gpdsp-anoc >> - qcom,sa8775p-mmss-noc >> - qcom,sa8775p-trng >> - qcom,sa8775p-ufshc >> - qcom,sa8775p-qmp-ufs-phy >> - qcom,sa8775p-qce >> - qcom,sa8775p-lpass-ag-noc >> - qcom,sa8775p-usb-hs-phy >> - qcom,sa8775p-dc-noc >> - qcom,sa8775p-gem-noc >> - qcom,sa8775p-dwc3 >> - qcom,sa8775p-qmp-usb3-uni-phy >> - qcom,sa8775p-gpucc >> - qcom,sa8775p-smmu-500 >> - qcom,sa8775p-dwmac-sgmii-phy >> - qcom,sa8775p-llcc-bwmon >> - qcom,sa8775p-cpu-bwmon >> - qcom,sa8775p-llcc >> - qcom,sa8775p-videocc >> - qcom,sa8775p-camcc >> - qcom,sa8775p-dispcc0 >> - qcom,sa8775p-pdc >> - qcom,sa8775p-aoss-qmp >> - qcom,sa8775p-tlmm >> - qcom,sa8775p-imem >> - qcom,sa8775p-smmu-500 >> - qcom,sa8775p-rpmh-clk >> - qcom,sa8775p-rpmhpd >> - qcom,sa8775p-cpufreq-epss >> - qcom,sa8775p-dispcc1 >> - qcom,sa8775p-ethqos >> - qcom,sa8775p-nspa-noc >> - qcom,sa8775p-nspb-noc >> - qcom,sa8775p-qmp-gen4x2-pcie-phy >> - qcom,sa8775p-qmp-gen4x4-pcie-phy >> >> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> >> --- >> .../dts/qcom/{sa8775p.dtsi => qcs9100.dtsi} | 112 +++++++++--------- >> 1 file changed, 56 insertions(+), 56 deletions(-) >> rename arch/arm64/boot/dts/qcom/{sa8775p.dtsi => qcs9100.dtsi} (97%) >> > > How do any things compile at this point? Please squash the patches. Your > patchset must be bisectable at build level (dtschema validation does not > have to). > > Best regards, > Krzysztof > The compilation issue indeed arises when applying only this single patch. In the new version patch series, I plan to consolidate the three patches that rename sa8775p.dtsi to qcs9100.dtsi, sa8775p-pmics.dtsi to qcs9100-pmics.dtsi, and sa87750-ride.dts to qcs9100-ride.dts into a single patch.
On 03/07/2024 11:21, Tengfei Fan wrote: >>> - items: >>> - enum: >>> + - qcom,qcs9100-ride >>> - qcom,sa8775p-ride >>> + - const: qcom,qcs9100 >> >> This changes existing compatible for sa8775p without any explanation in >> commit msg. >> >> Best regards, >> Krzysztof >> > > In the next verion patch series, I will provide relevant explanatory > information in this patch commit message. TBH, I cannot think of any reasonable explanation for this, especially considering rest of the patchset which does not fix resulting dtbs_check warning. Best regards, Krzysztof
On 7/3/2024 5:33 PM, Krzysztof Kozlowski wrote: > On 03/07/2024 11:21, Tengfei Fan wrote: >>>> - items: >>>> - enum: >>>> + - qcom,qcs9100-ride >>>> - qcom,sa8775p-ride >>>> + - const: qcom,qcs9100 >>> >>> This changes existing compatible for sa8775p without any explanation in >>> commit msg. >>> >>> Best regards, >>> Krzysztof >>> >> >> In the next verion patch series, I will provide relevant explanatory >> information in this patch commit message. > > TBH, I cannot think of any reasonable explanation for this, especially > considering rest of the patchset which does not fix resulting dtbs_check > warning. > > Best regards, > Krzysztof > This patch may need to be updated based on the results of dtbs_check. In the new version patch series, I will revise the commit message according to the patch updates made.
On 7/3/2024 1:35 PM, Taniya Das wrote: > > > On 7/3/2024 9:27 AM, Tengfei Fan wrote: >> + - qcom,qcs9100-cpufreq-epss > > This is not required as we already have sa8775p bindings. This is necessary. The reason is same as my reply in patch 41/47. >
On 7/3/2024 6:33 PM, Dmitry Baryshkov wrote: > On Wed, Jul 03, 2024 at 11:56:48AM GMT, Tengfei Fan wrote: >> Introduce support for the QCS9100 SoC device tree (DTSI) and the >> QCS9100 RIDE board DTS. The QCS9100 is a variant of the SA8775p. >> While the QCS9100 platform is still in the early design stage, the >> QCS9100 RIDE board is identical to the SA8775p RIDE board, except it >> mounts the QCS9100 SoC instead of the SA8775p SoC. > > Your patch series includes a second copy of your patches, wich have > different Message-IDs: > > 20240703035735.2182165-1-quic_tengfan@quicinc.com vs > 20240703025850.2172008-1-quic_tengfan@quicinc.com > > Please consider switching to the b4 tool or just > checking what is being sent. > This is because I encountered a "Connection timed out" error while sending this patch series using "git send-email". I wanted to add "--in-reply-to=" git paramater to resend the patches that haven't been pushed yet, which resulted in this second copy error result. I'll following your suggestion and use the b4 tool when sending the new version patch series to avoid similar error.
On 7/4/2024 2:49 AM, Jakub Kicinski wrote: > This is some bug / false positive in the bot, to be clear. > Commit df18948d331e is ("Merge branch 'device-memory-tcp'"). > No idea how it got from that to DTS. This issue may be due to the patch series being too large. In the future, I plan to split the patch series by different subsystem, which should prevent similar issue.
On 7/3/2024 11:09 PM, Andrew Halaney wrote: > On Wed, Jul 03, 2024 at 10:58:32AM GMT, Tengfei Fan wrote: >> Add the compatible for the MAC controller on qcs9100 platforms. This MAC >> works with a single interrupt so add minItems to the interrupts property. >> The fourth clock's name is different here so change it. Enable relevant >> PHY properties. Add the relevant compatibles to the binding document for >> snps,dwmac as well. > > This description doesn't match what was done in this patch, its what > Bart did when he made changes to add the sa8775 changes. Please consider > using a blurb indicating that this is the same SoC as sa8775p, just with > different firmware strategies or something along those lines? I will update this commit message as you suggested. > >> >> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> >> --- >> Documentation/devicetree/bindings/net/qcom,ethqos.yaml | 1 + >> Documentation/devicetree/bindings/net/snps,dwmac.yaml | 3 +++ >> 2 files changed, 4 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml >> index 6672327358bc..8ab11e00668c 100644 >> --- a/Documentation/devicetree/bindings/net/qcom,ethqos.yaml >> +++ b/Documentation/devicetree/bindings/net/qcom,ethqos.yaml >> @@ -20,6 +20,7 @@ properties: >> compatible: >> enum: >> - qcom,qcs404-ethqos >> + - qcom,qcs9100-ethqos >> - qcom,sa8775p-ethqos >> - qcom,sc8280xp-ethqos >> - qcom,sm8150-ethqos >> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml >> index 3bab4e1f3fbf..269c21779396 100644 >> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml >> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml >> @@ -67,6 +67,7 @@ properties: >> - loongson,ls2k-dwmac >> - loongson,ls7a-dwmac >> - qcom,qcs404-ethqos >> + - qcom,qcs9100-ethqos >> - qcom,sa8775p-ethqos >> - qcom,sc8280xp-ethqos >> - qcom,sm8150-ethqos >> @@ -582,6 +583,7 @@ allOf: >> - ingenic,x1600-mac >> - ingenic,x1830-mac >> - ingenic,x2000-mac >> + - qcom,qcs9100-ethqos >> - qcom,sa8775p-ethqos >> - qcom,sc8280xp-ethqos >> - snps,dwmac-3.50a >> @@ -639,6 +641,7 @@ allOf: >> - ingenic,x1830-mac >> - ingenic,x2000-mac >> - qcom,qcs404-ethqos >> + - qcom,qcs9100-ethqos >> - qcom,sa8775p-ethqos >> - qcom,sc8280xp-ethqos >> - qcom,sm8150-ethqos >> -- >> 2.25.1 >> >
On Thu, Jul 04, 2024 at 09:13:59AM +0800, Tengfei Fan wrote: > > > On 7/3/2024 11:09 PM, Andrew Halaney wrote: > > On Wed, Jul 03, 2024 at 10:58:32AM GMT, Tengfei Fan wrote: > > > Add the compatible for the MAC controller on qcs9100 platforms. This MAC > > > works with a single interrupt so add minItems to the interrupts property. > > > The fourth clock's name is different here so change it. Enable relevant > > > PHY properties. Add the relevant compatibles to the binding document for > > > snps,dwmac as well. > > > > This description doesn't match what was done in this patch, its what > > Bart did when he made changes to add the sa8775 changes. Please consider > > using a blurb indicating that this is the same SoC as sa8775p, just with > > different firmware strategies or something along those lines? > > I will update this commit message as you suggested. Hi Andrew, Tengfei Please trim emails when replying to just the needed context. Thanks Andrew
On Thu, Jul 04, 2024 at 06:03:14PM GMT, Andrew Lunn wrote: > On Thu, Jul 04, 2024 at 09:13:59AM +0800, Tengfei Fan wrote: > > > > > > On 7/3/2024 11:09 PM, Andrew Halaney wrote: > > > On Wed, Jul 03, 2024 at 10:58:32AM GMT, Tengfei Fan wrote: > > > > Add the compatible for the MAC controller on qcs9100 platforms. This MAC > > > > works with a single interrupt so add minItems to the interrupts property. > > > > The fourth clock's name is different here so change it. Enable relevant > > > > PHY properties. Add the relevant compatibles to the binding document for > > > > snps,dwmac as well. > > > > > > This description doesn't match what was done in this patch, its what > > > Bart did when he made changes to add the sa8775 changes. Please consider > > > using a blurb indicating that this is the same SoC as sa8775p, just with > > > different firmware strategies or something along those lines? > > > > I will update this commit message as you suggested. > > Hi Andrew, Tengfei > > Please trim emails when replying to just the needed context. > Sorry, I'm always a little guilty of this. In this case I didn't trim since the patch was small and trimming the diff out would then make it tough to see how my comment about the description relates to the body of the patch. But I'll try and trim when appropriate. Just replying here to explain myself as this isn't the first time I've been suggested to trim more aggressively and I don't want folks to think I'm completely ignoring them. Thanks, Andrew
On 7/3/2024 5:33 PM, Krzysztof Kozlowski wrote: > On 03/07/2024 11:21, Tengfei Fan wrote: >>>> - items: >>>> - enum: >>>> + - qcom,qcs9100-ride >>>> - qcom,sa8775p-ride >>>> + - const: qcom,qcs9100 >>> >>> This changes existing compatible for sa8775p without any explanation in >>> commit msg. >>> >>> Best regards, >>> Krzysztof >>> >> >> In the next verion patch series, I will provide relevant explanatory >> information in this patch commit message. > > TBH, I cannot think of any reasonable explanation for this, especially > considering rest of the patchset which does not fix resulting dtbs_check > warning. The existing compatible "sa8775p" warning can only be addressed When @Nikunj's "sa8775p" changes merged. Let me know if you have other suggestions for this. > > Best regards, > Krzysztof >
On 08/07/2024 06:45, Aiqun Yu (Maria) wrote: > > > On 7/3/2024 5:33 PM, Krzysztof Kozlowski wrote: >> On 03/07/2024 11:21, Tengfei Fan wrote: >>>>> - items: >>>>> - enum: >>>>> + - qcom,qcs9100-ride >>>>> - qcom,sa8775p-ride >>>>> + - const: qcom,qcs9100 >>>> >>>> This changes existing compatible for sa8775p without any explanation in >>>> commit msg. >>>> >>>> Best regards, >>>> Krzysztof >>>> >>> >>> In the next verion patch series, I will provide relevant explanatory >>> information in this patch commit message. >> >> TBH, I cannot think of any reasonable explanation for this, especially >> considering rest of the patchset which does not fix resulting dtbs_check >> warning. > > The existing compatible "sa8775p" warning can only be addressed When > @Nikunj's "sa8775p" changes merged. > > Let me know if you have other suggestions for this. I don't have, because I don't understand why do you want/need to change existing board compatible. Best regards, Krzysztof
On 7/8/2024 2:07 PM, Krzysztof Kozlowski wrote: > On 08/07/2024 06:45, Aiqun Yu (Maria) wrote: >> >> >> On 7/3/2024 5:33 PM, Krzysztof Kozlowski wrote: >>> On 03/07/2024 11:21, Tengfei Fan wrote: >>>>>> - items: >>>>>> - enum: >>>>>> + - qcom,qcs9100-ride >>>>>> - qcom,sa8775p-ride >>>>>> + - const: qcom,qcs9100 >>>>> >>>>> This changes existing compatible for sa8775p without any explanation in >>>>> commit msg. >>>>> >>>>> Best regards, >>>>> Krzysztof >>>>> >>>> >>>> In the next verion patch series, I will provide relevant explanatory >>>> information in this patch commit message. >>> >>> TBH, I cannot think of any reasonable explanation for this, especially >>> considering rest of the patchset which does not fix resulting dtbs_check >>> warning. >> >> The existing compatible "sa8775p" warning can only be addressed When >> @Nikunj's "sa8775p" changes merged. >> >> Let me know if you have other suggestions for this. > > I don't have, because I don't understand why do you want/need to change > existing board compatible. We can left the current existing sa8775p board compatible as it is. And have a brand new qcs9100 and qcs9100-board item for current non-scmi resources compatible. Will that be more reasonable from your end? > > Best regards, > Krzysztof >
On 08/07/2024 09:13, Aiqun Yu (Maria) wrote: > > > On 7/8/2024 2:07 PM, Krzysztof Kozlowski wrote: >> On 08/07/2024 06:45, Aiqun Yu (Maria) wrote: >>> >>> >>> On 7/3/2024 5:33 PM, Krzysztof Kozlowski wrote: >>>> On 03/07/2024 11:21, Tengfei Fan wrote: >>>>>>> - items: >>>>>>> - enum: >>>>>>> + - qcom,qcs9100-ride >>>>>>> - qcom,sa8775p-ride >>>>>>> + - const: qcom,qcs9100 >>>>>> >>>>>> This changes existing compatible for sa8775p without any explanation in >>>>>> commit msg. >>>>>> >>>>>> Best regards, >>>>>> Krzysztof >>>>>> >>>>> >>>>> In the next verion patch series, I will provide relevant explanatory >>>>> information in this patch commit message. >>>> >>>> TBH, I cannot think of any reasonable explanation for this, especially >>>> considering rest of the patchset which does not fix resulting dtbs_check >>>> warning. >>> >>> The existing compatible "sa8775p" warning can only be addressed When >>> @Nikunj's "sa8775p" changes merged. >>> >>> Let me know if you have other suggestions for this. >> >> I don't have, because I don't understand why do you want/need to change >> existing board compatible. > > We can left the current existing sa8775p board compatible as it is. And > have a brand new qcs9100 and qcs9100-board item for current non-scmi > resources compatible. > > Will that be more reasonable from your end? Yes, this is what I would expect. If you choose any other way - just like I wrote - you need to explain why you are doing this. Best regards, Krzysztof
On 7/5/2024 12:03 AM, Andrew Lunn wrote: > On Thu, Jul 04, 2024 at 09:13:59AM +0800, Tengfei Fan wrote: >> >> >> On 7/3/2024 11:09 PM, Andrew Halaney wrote: >>> On Wed, Jul 03, 2024 at 10:58:32AM GMT, Tengfei Fan wrote: >>>> Add the compatible for the MAC controller on qcs9100 platforms. This MAC >>>> works with a single interrupt so add minItems to the interrupts property. >>>> The fourth clock's name is different here so change it. Enable relevant >>>> PHY properties. Add the relevant compatibles to the binding document for >>>> snps,dwmac as well. >>> >>> This description doesn't match what was done in this patch, its what >>> Bart did when he made changes to add the sa8775 changes. Please consider >>> using a blurb indicating that this is the same SoC as sa8775p, just with >>> different firmware strategies or something along those lines? >> >> I will update this commit message as you suggested. > > Hi Andrew, Tengfei > > Please trim emails when replying to just the needed context. > > Thanks > Andrew Thank you for pointing out this. In the future, I will pay attention to trimming emails when I reply.
On 7/3/2024 2:28 PM, Conor Dooley wrote: > On Wed, Jul 03, 2024 at 06:45:00AM +0200, Krzysztof Kozlowski wrote: >> On 03/07/2024 05:56, Tengfei Fan wrote: >>> Introduce support for the QCS9100 SoC device tree (DTSI) and the >>> QCS9100 RIDE board DTS. The QCS9100 is a variant of the SA8775p. >>> While the QCS9100 platform is still in the early design stage, the >>> QCS9100 RIDE board is identical to the SA8775p RIDE board, except it >>> mounts the QCS9100 SoC instead of the SA8775p SoC. >> >> The same huge patchset, to huge number of recipients was sent twice. >> First, sorry, this is way too big. Second, it has way too many >> recipients, but this is partially a result of first point. Only >> partially because you put here dozen of totally unrelated emails. Sorry, >> that does not make even sense. See form letter at the end how this >> works. Third, sending it to everyone twice is a way to annoy them off >> twice... Fourth, >> >> Please split your work and do not cc dozen of unrelated folks. > > One of the extra recipients is cos that of that patch I sent adding the > cache bindings to the cache entry, forgetting that that would CC the > riscv list on all cache bindings. I modified that patch to drop the riscv > list from the entry. > > Cheers, > Conor. Thank you, Conor!
Introduce support for the QCS9100 SoC device tree (DTSI) and the QCS9100 RIDE board DTS. The QCS9100 is a variant of the SA8775p. While the QCS9100 platform is still in the early design stage, the QCS9100 RIDE board is identical to the SA8775p RIDE board, except it mounts the QCS9100 SoC instead of the SA8775p SoC. The QCS9100 SoC DTSI was directly renamed from the SA8775p SoC DTSI. In the upcoming weeks, Nikunj Kela will develop a new device tree related to SA8775p, specifically supporting the SCMI resource firmware solution for the SA8775p platform. If you're already familiar with the background, feel free to skip part[2], which provides a detailed explanation. All compatible strings have been updated from “SA8775P” to “QCS9100.” If you’re already aware of the context, feel free to skip part[3], which provides a detailed explanation of various other options. Here’s the reason and background: Bjorn Andersson, Nikunj Kela, Srinivas Kandagatla, and other Qualcomm engineers contributed to the current design, and we’ve finalized this series for broader audience review. *This patch series aligns with upstream efforts toward a new design solution: “Using logical performance and power domains to achieve resource abstraction over SCMI.” For more details, refer to [1]: [1]https://resources.linaro.org/en/resource/wfnfEwBhRjLV1PEAJoDDte *The SA8775p-RIDE will transition to using SCMI resources. This involves migrating to SCMI power and performance protocols for requesting and configuring peripheral resources such as clocks, regulators, interconnects, and PHYs. Consequently, most devices in the SA8775p-RIDE will require updates to drivers, bindings, and device trees. *The QCS9100-RIDE project will continue using the existing resources. It will rely on the current kernel infrastructure for clocks, regulators, interconnects, PHYs, and APIs. [2] The reason of qcs9100.dtsi renamed from sa8775.dtsi: The proposal is to maintain two separate platform.dtsi files. qcs9100.dtsi for non-scmi resources and sa8775p.dtsi for SCMI resources. Currently, the upstream sa8775p.dtsi contains 176 nodes with specified “compatible” strings. Among these, 142 nodes require distinct properties for SCMI and non-SCMI. As the IoT target is being upstreamed, both node counts are expected to increase for the IoT/QCS platform. If we do not implement platform separation, any modifications to the base sa8775p.dtsi-whether for automotive or IoT purposes-must consider the other platform. Each node(e.g., remoteproc, multimedia) added should be countered with an overlay that disables it in the automotive context. Care must be taken to avoid introducing changes that inferfere with the automotive system design, This structure poses challenges for human reasioning, leading to issues during development, code review, and maintenance. Furthermore, we are addressing the complexity of resuing marketing names accross both the IoT(QCS9100) and automotive(SA8775p) platforms. This decision has significations throughout DeviceTree and the kernel. Consequently, renameing the QCS9100 device tree files from the SA8775p device files is our definitive choice. [3] The reason of All Compatible Strings Changed from “SA8775P” to “QCS9100”: During discussions, three options were considered. Ultimately, Option B was chosen as the best approach for separating QCS projects from SA projects. This decision simplifies the reviewer’s task by focusing on each platform independently. Developers only need to verify the affected platform. *Option A: “And” (qcs9100+sa8775): Add all qcs9100-compatible strings alongside the current sa8775p-compatible strings in each binding file. For example: aggre1_noc: interconnect-aggre1-noc { - compatible = "qcom,sa8775p-aggre1-noc"; + compatible = "qcom,qcs9100-aggre1-noc", "qcom,sa8775p-aggre1-noc"; #interconnect-cells = <2>; qcom,bcm-voters = <&apps_bcm_voter>; }; Some device tree (DT) nodes may share common compatibles. For instance: firmware { scm { - compatible = "qcom,scm-sa8775p", "qcom,scm"; + compatible = "qcom,scm-qcs9100", "qcom,scm"; }; }; Approximately 50+ sa8775p-related compatible names need to be changed to qcs9100-compatible names in the binding files and DT nodes. When the SCMI resource driver owner adds SCMI support, they need to update both the qcs9100 DT (non-SCMI resource) and the sa8775 DT (SCMI resource) simultaneously. For this option: DT and binding changes are needed. No driver C file changes are required at this time. Technical driver owners must handle both the qcs DT and sa DT. *Option B: “Or” (qcs9100 or sa8775): Replace all qcs9100-compatible strings with the current sa8775p-compatible strings in the qcs9100 DT. For example: aggre1_noc: interconnect-aggre1-noc { - compatible = "qcom,sa8775p-aggre1-noc"; + compatible = "qcom,qcs9100-aggre1-noc"; #interconnect-cells = <2>; qcom,bcm-voters = <&apps_bcm_voter>; }; Add the necessary “qcs9100” compatible strings to the C driver. In drivers/interconnect/qcom/sa8775p.c: static const struct of_device_id qnoc_of_match[] = { { .compatible = "qcom,sa8775p-aggre1-noc", .data = &sa8775p_aggre1_noc }, + { .compatible = "qcom,qcs9100-aggre1-noc", .data = &sa8775p_aggre1_noc }, { .compatible = "qcom,sa8775p-aggre2-noc", .data = &sa8775p_aggre2_noc }, + { .compatible = "qcom,qcs9100-aggre2-noc", .data = &sa8775p_aggre2_noc }, // ... }; Some DT nodes may share common compatibles, similar to the example above. Approximately 50+ sa8775p-related compatible names need to be changed to qcs9100-compatible names in the binding files and DT nodes. When the SCMI resource driver owner adds SCMI support, they only need to update the sa8775 DT (SCMI resource). For this option: DT, binding, and C driver changes are needed. Technical driver owners only need to handle the sa DT. *Option C: “Depends” (sa8775 in qcs9100, depends on driver to change necessary driver + DT later): This option depends on the SCMI resource solution and requires minimal driver changes. Change common compatibles to “qcs9100,” as shown in the example: firmware { scm { - compatible = "qcom,scm-sa8775p", "qcom,scm"; + compatible = "qcom,scm-qcs9100", "qcom,scm"; }; }; Approximately 30+ sa8775p-related compatible names need to be changed to qcs9100-compatible names in the binding files and DT nodes. When the SCMI resource driver owner adds SCMI support, they must update both the qcs9100 DT and the sa8775 DT (SCMI resource) simultaneously. For example: { .compatible = "qcom,sa8775p-aggre1-noc", .data = &sa8775p_aggre1_noc }, + { .compatible = "qcom,qcs9100-aggre1-noc", .data = &qcs9100_aggre1_noc + }, { .compatible = "qcom,sa8775p-aggre2-noc", .data = &sa8775p_aggre2_noc }, + { .compatible = "qcom,qcs9100-aggre2-noc", .data = &qcs9100_aggre2_noc + }, // ... For this option: DT changes are needed. Technical driver owners are responsible for making the final different driver changes and ensuring the exact binding of qcs9100 and sa8775 with different compatibles. In summary, the current solution primarily targets SCMI-based resource transactions. However, both the qcs project and the SA project, which are in the development stage, require independent development processes. Co-developed-by: Maria Yu <quic_aiquny@quicinc.com> Signed-off-by: Maria Yu <quic_aiquny@quicinc.com> Signed-off-by: Tengfei Fan <quic_tengfan@quicinc.com> --- Tengfei Fan (47): dt-bindings: arm: qcom: Document QCS9100 SoC and RIDE board arm64: dts: qcom: qcs9100: Introduce QCS9100 SoC dtsi arm64: dts: qcom: qcs9100: Introduce QCS9100 PMIC dtsi arm64: dts: qcom: qcs9100: Add QCS9100 RIDE board dts dt-bindings: firmware: qcom,scm: document SCM on QCS9100 SoC dt-bindings: interconnect: qcom: document the interconnect compatibles for QCS9100 dt-bindings: clock: document QCS9100 GCC compatible dt-bindings: mailbox: qcom-ipcc: Document the QCS9100 IPCC dt-bindings: phy: Add QMP UFS PHY comptible for QCS9100 dt-bindings: crypto: ice: Document QCS9100 inline crypto engine dt-bindings: crypto: qcom,prng: document QCS9100 dt-bindings: phy: qcom,usb-snps-femto-v2: Add bindings for QCS9100 dt-bindings: ufs: qcom: document QCS9100 UFS dt-bindings: phy: qcom,qmp-usb: Add QCS9100 USB3 PHY dt-bindings: usb: dwc3: Add QCS9100 compatible dt-bindings: clock: qcom: describe the GPUCC clock for QCS9100 dt-bindings: arm-smmu: Document QCS9100 GPU SMMU dt-bindings: phy: describe the Qualcomm SGMII PHY for QCS9100 dt-bindings: cache: qcom,llcc: Add QCS9100 description dt-bindings: interrupt-controller: qcom,pdc: document pdc on QCS9100 dt-bindings: thermal: qcom-tsens: document the QCS9100 Temperature Sensor dt-bindings: soc: qcom,aoss-qmp: Document the QCS9100 AOSS channel dt-bindings: pinctrl: add qcs9100-tlmm compatible dt-bindings: soc: qcom: add qcom,qcs9100-imem compatible dt-bindings: watchdog: qcom-wdt: document QCS9100 dt-bindings: clock: qcom-rpmhcc: Add RPMHCC bindings for QCS9100 dt-bindings: cpufreq: cpufreq-qcom-hw: Add QCS9100 compatibles dt-bindings: power: qcom,rpmpd: document the QCS9100 RPMh Power Domains dt-bindings: net: qcom,ethqos: add description for qcs9100 dt-bindings: PCI: Document compatible for QCS9100 dt-bindings: PCI: qcom-ep: Add support for QCS9100 SoC dt-bindings: phy: qcom,qmp: Add qcs9100 QMP PCIe PHY interconnect: qcom: add driver support for qcs9100 clk: qcom: add the GCC driver support for QCS9100 phy: qcom-qmp-ufs: Add QCS9100 support phy: qcpm-qmp-usb: Add support for QCS9100 clk: qcom: add the GPUCC driver support for QCS9100 phy: qcom: add the SGMII SerDes PHY driver support soc: qcom: llcc: Add llcc configuration support for the QCS9100 platform pinctrl: qcom: add the tlmm driver support for qcs9100 platform clk: qcom: rpmh: Add support for QCS9100 rpmh clocks soc: qcom: rmphpd: add power domains for QCS9100 net: stmmac: dwmac-qcom-ethqos: add support for emac4 on qcs9100 platforms PCI: qcom: Add support for QCS9100 SoC PCI: qcom-ep: Add HDMA support for QCS9100 SoC cpufreq: qcom-nvmem: add support for QCS9100 phy: qcom-qmp-pcie: add x4 lane EP support for QCS9100 .../devicetree/bindings/arm/qcom.yaml | 3 + .../devicetree/bindings/cache/qcom,llcc.yaml | 2 + .../devicetree/bindings/clock/qcom,gpucc.yaml | 1 + .../bindings/clock/qcom,rpmhcc.yaml | 1 + .../bindings/clock/qcom,sa8775p-gcc.yaml | 5 +- .../bindings/cpufreq/cpufreq-qcom-hw.yaml | 1 + .../crypto/qcom,inline-crypto-engine.yaml | 1 + .../devicetree/bindings/crypto/qcom,prng.yaml | 1 + .../bindings/firmware/qcom,scm.yaml | 1 + .../interconnect/qcom,sa8775p-rpmh.yaml | 14 +++ .../interrupt-controller/qcom,pdc.yaml | 1 + .../devicetree/bindings/iommu/arm,smmu.yaml | 3 + .../bindings/mailbox/qcom-ipcc.yaml | 1 + .../devicetree/bindings/net/qcom,ethqos.yaml | 1 + .../devicetree/bindings/net/snps,dwmac.yaml | 3 + .../devicetree/bindings/pci/qcom,pcie-ep.yaml | 2 + .../bindings/pci/qcom,pcie-sa8775p.yaml | 5 +- .../phy/qcom,sa8775p-dwmac-sgmii-phy.yaml | 5 +- .../phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 4 + .../phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 + .../phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml | 3 + .../bindings/phy/qcom,usb-snps-femto-v2.yaml | 1 + .../bindings/pinctrl/qcom,sa8775p-tlmm.yaml | 5 +- .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 + .../bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 + .../devicetree/bindings/sram/qcom,imem.yaml | 1 + .../bindings/thermal/qcom-tsens.yaml | 1 + .../devicetree/bindings/ufs/qcom,ufs.yaml | 2 + .../devicetree/bindings/usb/qcom,dwc3.yaml | 3 + .../bindings/watchdog/qcom-wdt.yaml | 1 + arch/arm64/boot/dts/qcom/Makefile | 2 +- ...{sa8775p-pmics.dtsi => qcs9100-pmics.dtsi} | 0 .../{sa8775p-ride.dts => qcs9100-ride.dts} | 8 +- .../dts/qcom/{sa8775p.dtsi => qcs9100.dtsi} | 112 +++++++++--------- drivers/clk/qcom/clk-rpmh.c | 1 + drivers/clk/qcom/gcc-sa8775p.c | 1 + drivers/clk/qcom/gpucc-sa8775p.c | 1 + drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/interconnect/qcom/sa8775p.c | 14 +++ .../stmicro/stmmac/dwmac-qcom-ethqos.c | 1 + drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 + drivers/pci/controller/dwc/pcie-qcom.c | 1 + drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 6 + drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 3 + drivers/phy/qualcomm/phy-qcom-qmp-usb.c | 3 + drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 1 + drivers/pinctrl/qcom/pinctrl-sa8775p.c | 1 + drivers/pmdomain/qcom/rpmhpd.c | 1 + drivers/soc/qcom/llcc-qcom.c | 1 + 49 files changed, 170 insertions(+), 65 deletions(-) rename arch/arm64/boot/dts/qcom/{sa8775p-pmics.dtsi => qcs9100-pmics.dtsi} (100%) rename arch/arm64/boot/dts/qcom/{sa8775p-ride.dts => qcs9100-ride.dts} (99%) rename arch/arm64/boot/dts/qcom/{sa8775p.dtsi => qcs9100.dtsi} (97%) base-commit: 82e4255305c554b0bb18b7ccf2db86041b4c8b6e