| Message ID | 20240703025850.2172008-1-quic_tengfan@quicinc.com |
|---|---|
| Headers | show |
| Series | arm64: qcom: dts: add QCS9100 support | expand |
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
Hello: This series was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Wed, 3 Jul 2024 10:58:03 +0800 you 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 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. > > [...] Here is the summary with links: - [01/47] dt-bindings: arm: qcom: Document QCS9100 SoC and RIDE board (no matching commit) - [02/47] arm64: dts: qcom: qcs9100: Introduce QCS9100 SoC dtsi (no matching commit) - [03/47] arm64: dts: qcom: qcs9100: Introduce QCS9100 PMIC dtsi https://git.kernel.org/netdev/net-next/c/df18948d331e - [04/47] arm64: dts: qcom: qcs9100: Add QCS9100 RIDE board dts (no matching commit) - [05/47] dt-bindings: firmware: qcom,scm: document SCM on QCS9100 SoC (no matching commit) - [06/47] dt-bindings: interconnect: qcom: document the interconnect compatibles for QCS9100 (no matching commit) - [07/47] dt-bindings: clock: document QCS9100 GCC compatible (no matching commit) - [08/47] dt-bindings: mailbox: qcom-ipcc: Document the QCS9100 IPCC (no matching commit) - [09/47] dt-bindings: phy: Add QMP UFS PHY comptible for QCS9100 (no matching commit) - [10/47] dt-bindings: crypto: ice: Document QCS9100 inline crypto engine (no matching commit) - [11/47] dt-bindings: crypto: qcom,prng: document QCS9100 (no matching commit) - [12/47] dt-bindings: phy: qcom,usb-snps-femto-v2: Add bindings for QCS9100 (no matching commit) - [13/47] dt-bindings: ufs: qcom: document QCS9100 UFS (no matching commit) - [14/47] dt-bindings: phy: qcom,qmp-usb: Add QCS9100 USB3 PHY (no matching commit) - [15/47] dt-bindings: usb: dwc3: Add QCS9100 compatible (no matching commit) - [16/47] dt-bindings: clock: qcom: describe the GPUCC clock for QCS9100 (no matching commit) - [17/47] dt-bindings: arm-smmu: Document QCS9100 GPU SMMU (no matching commit) - [18/47] dt-bindings: phy: describe the Qualcomm SGMII PHY for QCS9100 (no matching commit) - [19/47] dt-bindings: cache: qcom,llcc: Add QCS9100 description (no matching commit) - [20/47] dt-bindings: interrupt-controller: qcom,pdc: document pdc on QCS9100 (no matching commit) - [21/47] dt-bindings: thermal: qcom-tsens: document the QCS9100 Temperature Sensor (no matching commit) - [22/47] dt-bindings: soc: qcom,aoss-qmp: Document the QCS9100 AOSS channel (no matching commit) - [23/47] dt-bindings: pinctrl: add qcs9100-tlmm compatible (no matching commit) - [24/47] dt-bindings: soc: qcom: add qcom,qcs9100-imem compatible (no matching commit) - [25/47] dt-bindings: watchdog: qcom-wdt: document QCS9100 (no matching commit) - [26/47] dt-bindings: clock: qcom-rpmhcc: Add RPMHCC bindings for QCS9100 (no matching commit) - [27/47] dt-bindings: cpufreq: cpufreq-qcom-hw: Add QCS9100 compatibles (no matching commit) - [28/47] dt-bindings: power: qcom,rpmpd: document the QCS9100 RPMh Power Domains (no matching commit) - [29/47] dt-bindings: net: qcom,ethqos: add description for qcs9100 (no matching commit) - [30/47] dt-bindings: PCI: Document compatible for QCS9100 (no matching commit) - [31/47] dt-bindings: PCI: qcom-ep: Add support for QCS9100 SoC (no matching commit) - [32/47] dt-bindings: phy: qcom,qmp: Add qcs9100 QMP PCIe PHY (no matching commit) - [33/47] interconnect: qcom: add driver support for qcs9100 (no matching commit) - [34/47] clk: qcom: add the GCC driver support for QCS9100 (no matching commit) - [35/47] phy: qcom-qmp-ufs: Add QCS9100 support (no matching commit) - [36/47] phy: qcpm-qmp-usb: Add support for QCS9100 (no matching commit) - [37/47] clk: qcom: add the GPUCC driver support for QCS9100 (no matching commit) - [38/47] phy: qcom: add the SGMII SerDes PHY driver support (no matching commit) - [39/47] soc: qcom: llcc: Add llcc configuration support for the QCS9100 platform (no matching commit) - [40/47] pinctrl: qcom: add the tlmm driver support for qcs9100 platform (no matching commit) - [41/47] clk: qcom: rpmh: Add support for QCS9100 rpmh clocks (no matching commit) You are awesome, thank you!
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 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.
On 7/3/2024 12:45 PM, 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. I can split this patch series, there are two options for splitting: Option A: 1. Initial qcs9100.dtsi, qcs9100-pmics.dtsi, qcs9100-ride.dts renamed from sa8775p with existing compatible. 2. Each subsystem have single patch series to each limited driver maintainers. - About 15 series need to update related drivers, so each series will have 3 patches (bindings, drivers, the compatible names in subsystem-related parts of dtsi/dts). - About 14 series only need to add qcs9100 compatible in bindings., so each series will have 2 patches (bindings, the compatible names in subsystem-related parts of dtsi/dts). Option B: 1. Each subsystem have single patch series to each limited driver maintainers. Each patch series only update bindings, drivers, but no compatible names change in dts. - About 15 series in total and each series will have 2 patches (bindings, drivers). - About 14 series only need to add qcs9100 compatible in bindings, so each series will have 1 patches (bindings). 2. Squash current qcs9100.dtsi, qcs9100-pmics.dtsi, qcs9100-ride.dts with compatible changed to qcs9100 dt files. We tend to use Option A. Welcome to other ideas ideas for splitting the huge numbers of patches as well. Another, each splited series will also have cover letter contain the whole story like this cover letter. > > <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 > Previously, I've been using scripts/get_maintainers.pl to obtain a list of recipients and manually removing duplicate email addresses(although I noticed you have two different email addresses, so I included both). I'll follow your advice and use b4 to submit a new version patch series to upstream, confident that similar issues won't arise again.
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.
On Wed, 03 Jul 2024 04:20:29 +0000 patchwork-bot+netdevbpf@kernel.org wrote: > This series was applied to netdev/net-next.git (main) > by Jakub Kicinski <kuba@kernel.org>: > Here is the summary with links: > - [01/47] dt-bindings: arm: qcom: Document QCS9100 SoC and RIDE board > (no matching commit) > - [02/47] arm64: dts: qcom: qcs9100: Introduce QCS9100 SoC dtsi > (no matching commit) > - [03/47] arm64: dts: qcom: qcs9100: Introduce QCS9100 PMIC dtsi > https://git.kernel.org/netdev/net-next/c/df18948d331e 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.
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 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