Add device tree support for QCS9075 Ride & Ride-r3 boards.
QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
subsystem which is available in QCS9100, and it affects thermal
management.
Also, between ride and ride-r3 ethernet phy is different.
Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
---
arch/arm64/boot/dts/qcom/Makefile | 2 +
arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
3 files changed, 94 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 78613a1bd34a..41cb2bbd3472 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
new file mode 100644
index 000000000000..d9a8956d3a76
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+/dts-v1/;
+
+#include "sa8775p-ride.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
+ compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
+};
+
+ðernet0 {
+ phy-mode = "2500base-x";
+};
+
+ðernet1 {
+ phy-mode = "2500base-x";
+};
+
+&mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sgmii_phy0: phy@8 {
+ compatible = "ethernet-phy-id31c3.1c33";
+ reg = <0x8>;
+ device_type = "ethernet-phy";
+ interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+
+ sgmii_phy1: phy@0 {
+ compatible = "ethernet-phy-id31c3.1c33";
+ reg = <0x0>;
+ device_type = "ethernet-phy";
+ interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
new file mode 100644
index 000000000000..3b524359a72d
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+/dts-v1/;
+
+#include "sa8775p-ride.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. QCS9075 Ride";
+ compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
+};
+
+ðernet0 {
+ phy-mode = "sgmii";
+};
+
+ðernet1 {
+ phy-mode = "sgmii";
+};
+
+&mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sgmii_phy0: phy@8 {
+ compatible = "ethernet-phy-id0141.0dd4";
+ reg = <0x8>;
+ device_type = "ethernet-phy";
+ interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+
+ sgmii_phy1: phy@a {
+ compatible = "ethernet-phy-id0141.0dd4";
+ reg = <0xa>;
+ device_type = "ethernet-phy";
+ interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <11000>;
+ reset-deassert-us = <70000>;
+ };
+};
--
2.47.0On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> Add device tree support for QCS9075 Ride & Ride-r3 boards.
>
> QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> subsystem which is available in QCS9100, and it affects thermal
> management.
>
> Also, between ride and ride-r3 ethernet phy is different.
> Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
>
This commit message is written under the assumption that the reader
first reads the patch, to determine what QCS9075 subtracts features
from.
Please describe what the QCS9075 Ride and Ride R3 are, if it's just a
variant of QCS9100 without SAIL, write that - and if that is all the
difference, then Dmitry's request makes total sense.
Also, subject prefix doesn't match upstream style. Prefix with the
subsystem/platform/device and avoid "for XYZ". See "git log" on a few
of the other files to see how it should look like.
Thanks,
Bjorn
> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> 3 files changed, 94 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 78613a1bd34a..41cb2bbd3472 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> new file mode 100644
> index 000000000000..d9a8956d3a76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +ðernet0 {
> + phy-mode = "2500base-x";
> +};
> +
> +ðernet1 {
> + phy-mode = "2500base-x";
> +};
> +
> +&mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sgmii_phy0: phy@8 {
> + compatible = "ethernet-phy-id31c3.1c33";
> + reg = <0x8>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +
> + sgmii_phy1: phy@0 {
> + compatible = "ethernet-phy-id31c3.1c33";
> + reg = <0x0>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> new file mode 100644
> index 000000000000..3b524359a72d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +ðernet0 {
> + phy-mode = "sgmii";
> +};
> +
> +ðernet1 {
> + phy-mode = "sgmii";
> +};
> +
> +&mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sgmii_phy0: phy@8 {
> + compatible = "ethernet-phy-id0141.0dd4";
> + reg = <0x8>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +
> + sgmii_phy1: phy@a {
> + compatible = "ethernet-phy-id0141.0dd4";
> + reg = <0xa>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +};
> --
> 2.47.0
>
On Mon, Jan 06, 2025 at 05:59:01PM -0600, Bjorn Andersson wrote:
> On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> >
> > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > subsystem which is available in QCS9100, and it affects thermal
> > management.
> >
> > Also, between ride and ride-r3 ethernet phy is different.
> > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> >
>
> This commit message is written under the assumption that the reader
> first reads the patch, to determine what QCS9075 subtracts features
> from.
>
> Please describe what the QCS9075 Ride and Ride R3 are, if it's just a
> variant of QCS9100 without SAIL, write that - and if that is all the
> difference, then Dmitry's request makes total sense.
>
9075 is not derived from 9100 but from 8775, though difference between
9075 & 9100 is only SAIL. And in commit message I have tried to add
details to differentiate between 9075 & 9100 and most importantly to
highlight why we need sperate DT for 9075.
Will add more details in commit message instead of adding it in
cover-letter.
Also, I am convinced to proceed with Dmitry's approach to structure the
DT.
>
> Also, subject prefix doesn't match upstream style. Prefix with the
> subsystem/platform/device and avoid "for XYZ". See "git log" on a few
> of the other files to see how it should look like.
Sure will change this accordingly.
>
> Thanks,
> Bjorn
>
> > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > 3 files changed, 94 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 78613a1bd34a..41cb2bbd3472 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > new file mode 100644
> > index 000000000000..d9a8956d3a76
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +ðernet0 {
> > + phy-mode = "2500base-x";
> > +};
> > +
> > +ðernet1 {
> > + phy-mode = "2500base-x";
> > +};
> > +
> > +&mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sgmii_phy0: phy@8 {
> > + compatible = "ethernet-phy-id31c3.1c33";
> > + reg = <0x8>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +
> > + sgmii_phy1: phy@0 {
> > + compatible = "ethernet-phy-id31c3.1c33";
> > + reg = <0x0>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > new file mode 100644
> > index 000000000000..3b524359a72d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +ðernet0 {
> > + phy-mode = "sgmii";
> > +};
> > +
> > +ðernet1 {
> > + phy-mode = "sgmii";
> > +};
> > +
> > +&mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sgmii_phy0: phy@8 {
> > + compatible = "ethernet-phy-id0141.0dd4";
> > + reg = <0x8>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +
> > + sgmii_phy1: phy@a {
> > + compatible = "ethernet-phy-id0141.0dd4";
> > + reg = <0xa>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +};
> > --
> > 2.47.0
> >
Thanks & Regards,
Wasim
On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> Add device tree support for QCS9075 Ride & Ride-r3 boards.
>
> QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> subsystem which is available in QCS9100, and it affects thermal
> management.
>
> Also, between ride and ride-r3 ethernet phy is different.
> Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
include corresponding SA8775P files.
This is not ideal for the following reasons:
- The approach is not uniform (between QCS9100 and QCS9075), which might
lead to mistakes.
- The approach ends up duplicating DT code unnecessarily, which can lead
to issues being patches in the one board file, but not in the other
file.
If there are any reasons why you want to follow this approach, they must
be a part of the commit message.
>
> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> 3 files changed, 94 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 78613a1bd34a..41cb2bbd3472 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> new file mode 100644
> index 000000000000..d9a8956d3a76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +ðernet0 {
> + phy-mode = "2500base-x";
> +};
> +
> +ðernet1 {
> + phy-mode = "2500base-x";
> +};
> +
> +&mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sgmii_phy0: phy@8 {
> + compatible = "ethernet-phy-id31c3.1c33";
> + reg = <0x8>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +
> + sgmii_phy1: phy@0 {
> + compatible = "ethernet-phy-id31c3.1c33";
> + reg = <0x0>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> new file mode 100644
> index 000000000000..3b524359a72d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +ðernet0 {
> + phy-mode = "sgmii";
> +};
> +
> +ðernet1 {
> + phy-mode = "sgmii";
> +};
> +
> +&mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sgmii_phy0: phy@8 {
> + compatible = "ethernet-phy-id0141.0dd4";
> + reg = <0x8>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +
> + sgmii_phy1: phy@a {
> + compatible = "ethernet-phy-id0141.0dd4";
> + reg = <0xa>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +};
> --
> 2.47.0
>
--
With best wishes
Dmitry
On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> >
> > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > subsystem which is available in QCS9100, and it affects thermal
> > management.
> >
> > Also, between ride and ride-r3 ethernet phy is different.
> > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
>
> Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> include corresponding SA8775P files.
>
> This is not ideal for the following reasons:
> - The approach is not uniform (between QCS9100 and QCS9075), which might
> lead to mistakes.
> - The approach ends up duplicating DT code unnecessarily, which can lead
> to issues being patches in the one board file, but not in the other
> file.
>
> If there are any reasons why you want to follow this approach, they must
> be a part of the commit message.
>
Hi Dmitry,
Initially, we included the DTS [1] file to avoid duplication. However,
based on Krzysztof's previous suggestion [2], we change to this format.
Please let us know how to proceed further on this.
[1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
[2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> >
> > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > ---
> > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > 3 files changed, 94 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> >
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 78613a1bd34a..41cb2bbd3472 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > new file mode 100644
> > index 000000000000..d9a8956d3a76
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +ðernet0 {
> > + phy-mode = "2500base-x";
> > +};
> > +
> > +ðernet1 {
> > + phy-mode = "2500base-x";
> > +};
> > +
> > +&mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sgmii_phy0: phy@8 {
> > + compatible = "ethernet-phy-id31c3.1c33";
> > + reg = <0x8>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +
> > + sgmii_phy1: phy@0 {
> > + compatible = "ethernet-phy-id31c3.1c33";
> > + reg = <0x0>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > new file mode 100644
> > index 000000000000..3b524359a72d
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > @@ -0,0 +1,46 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/*
> > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > + */
> > +/dts-v1/;
> > +
> > +#include "sa8775p-ride.dtsi"
> > +
> > +/ {
> > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > +};
> > +
> > +ðernet0 {
> > + phy-mode = "sgmii";
> > +};
> > +
> > +ðernet1 {
> > + phy-mode = "sgmii";
> > +};
> > +
> > +&mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sgmii_phy0: phy@8 {
> > + compatible = "ethernet-phy-id0141.0dd4";
> > + reg = <0x8>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +
> > + sgmii_phy1: phy@a {
> > + compatible = "ethernet-phy-id0141.0dd4";
> > + reg = <0xa>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +};
> > --
> > 2.47.0
> >
>
> --
> With best wishes
> Dmitry
Thanks & Regards,
Wasim
On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > >
> > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > subsystem which is available in QCS9100, and it affects thermal
> > > management.
> > >
> > > Also, between ride and ride-r3 ethernet phy is different.
> > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> >
> > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > include corresponding SA8775P files.
> >
> > This is not ideal for the following reasons:
> > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > lead to mistakes.
> > - The approach ends up duplicating DT code unnecessarily, which can lead
> > to issues being patches in the one board file, but not in the other
> > file.
> >
> > If there are any reasons why you want to follow this approach, they must
> > be a part of the commit message.
> >
>
> Hi Dmitry,
>
> Initially, we included the DTS [1] file to avoid duplication. However,
> based on Krzysztof's previous suggestion [2], we change to this format.
>
> Please let us know how to proceed further on this.
Krzysztof asked you to include DTSI files instead of including DTS
files. Hope this helps.
>
> [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
>
> > >
> > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > ---
> > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > > 3 files changed, 94 insertions(+)
> > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > index 78613a1bd34a..41cb2bbd3472 100644
> > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > new file mode 100644
> > > index 000000000000..d9a8956d3a76
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > @@ -0,0 +1,46 @@
> > > +// SPDX-License-Identifier: BSD-3-Clause
> > > +/*
> > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > + */
> > > +/dts-v1/;
> > > +
> > > +#include "sa8775p-ride.dtsi"
> > > +
> > > +/ {
> > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > +};
> > > +
> > > +ðernet0 {
> > > + phy-mode = "2500base-x";
> > > +};
> > > +
> > > +ðernet1 {
> > > + phy-mode = "2500base-x";
> > > +};
> > > +
> > > +&mdio {
> > > + compatible = "snps,dwmac-mdio";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + sgmii_phy0: phy@8 {
> > > + compatible = "ethernet-phy-id31c3.1c33";
> > > + reg = <0x8>;
> > > + device_type = "ethernet-phy";
> > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > + reset-assert-us = <11000>;
> > > + reset-deassert-us = <70000>;
> > > + };
> > > +
> > > + sgmii_phy1: phy@0 {
> > > + compatible = "ethernet-phy-id31c3.1c33";
> > > + reg = <0x0>;
> > > + device_type = "ethernet-phy";
> > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > + reset-assert-us = <11000>;
> > > + reset-deassert-us = <70000>;
> > > + };
> > > +};
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > new file mode 100644
> > > index 000000000000..3b524359a72d
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > @@ -0,0 +1,46 @@
> > > +// SPDX-License-Identifier: BSD-3-Clause
> > > +/*
> > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > + */
> > > +/dts-v1/;
> > > +
> > > +#include "sa8775p-ride.dtsi"
> > > +
> > > +/ {
> > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > +};
> > > +
> > > +ðernet0 {
> > > + phy-mode = "sgmii";
> > > +};
> > > +
> > > +ðernet1 {
> > > + phy-mode = "sgmii";
> > > +};
> > > +
> > > +&mdio {
> > > + compatible = "snps,dwmac-mdio";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + sgmii_phy0: phy@8 {
> > > + compatible = "ethernet-phy-id0141.0dd4";
> > > + reg = <0x8>;
> > > + device_type = "ethernet-phy";
> > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > + reset-assert-us = <11000>;
> > > + reset-deassert-us = <70000>;
> > > + };
> > > +
> > > + sgmii_phy1: phy@a {
> > > + compatible = "ethernet-phy-id0141.0dd4";
> > > + reg = <0xa>;
> > > + device_type = "ethernet-phy";
> > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > + reset-assert-us = <11000>;
> > > + reset-deassert-us = <70000>;
> > > + };
> > > +};
> > > --
> > > 2.47.0
> > >
> >
> > --
> > With best wishes
> > Dmitry
>
>
> Thanks & Regards,
> Wasim
--
With best wishes
Dmitry
On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > >
> > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > subsystem which is available in QCS9100, and it affects thermal
> > > > management.
> > > >
> > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > >
> > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > include corresponding SA8775P files.
> > >
> > > This is not ideal for the following reasons:
> > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > lead to mistakes.
> > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > to issues being patches in the one board file, but not in the other
> > > file.
> > >
> > > If there are any reasons why you want to follow this approach, they must
> > > be a part of the commit message.
> > >
> >
> > Hi Dmitry,
> >
> > Initially, we included the DTS [1] file to avoid duplication. However,
> > based on Krzysztof's previous suggestion [2], we change to this format.
> >
> > Please let us know how to proceed further on this.
>
> Krzysztof asked you to include DTSI files instead of including DTS
> files. Hope this helps.
Are you suggesting that we should also modify the 9100-ride files to
include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
However, this would result in the duplication of Ethernet nodes in all
the ride board files. Would that be acceptable?
>
> >
> > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> >
> > > >
> > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > > > 3 files changed, 94 insertions(+)
> > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > > > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > new file mode 100644
> > > > index 000000000000..d9a8956d3a76
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > @@ -0,0 +1,46 @@
> > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > +/*
> > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > + */
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sa8775p-ride.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > +};
> > > > +
> > > > +ðernet0 {
> > > > + phy-mode = "2500base-x";
> > > > +};
> > > > +
> > > > +ðernet1 {
> > > > + phy-mode = "2500base-x";
> > > > +};
> > > > +
> > > > +&mdio {
> > > > + compatible = "snps,dwmac-mdio";
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + sgmii_phy0: phy@8 {
> > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > + reg = <0x8>;
> > > > + device_type = "ethernet-phy";
> > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > + reset-assert-us = <11000>;
> > > > + reset-deassert-us = <70000>;
> > > > + };
> > > > +
> > > > + sgmii_phy1: phy@0 {
> > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > + reg = <0x0>;
> > > > + device_type = "ethernet-phy";
> > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > + reset-assert-us = <11000>;
> > > > + reset-deassert-us = <70000>;
> > > > + };
> > > > +};
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > new file mode 100644
> > > > index 000000000000..3b524359a72d
> > > > --- /dev/null
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > @@ -0,0 +1,46 @@
> > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > +/*
> > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > + */
> > > > +/dts-v1/;
> > > > +
> > > > +#include "sa8775p-ride.dtsi"
> > > > +
> > > > +/ {
> > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > +};
> > > > +
> > > > +ðernet0 {
> > > > + phy-mode = "sgmii";
> > > > +};
> > > > +
> > > > +ðernet1 {
> > > > + phy-mode = "sgmii";
> > > > +};
> > > > +
> > > > +&mdio {
> > > > + compatible = "snps,dwmac-mdio";
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + sgmii_phy0: phy@8 {
> > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > + reg = <0x8>;
> > > > + device_type = "ethernet-phy";
> > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > + reset-assert-us = <11000>;
> > > > + reset-deassert-us = <70000>;
> > > > + };
> > > > +
> > > > + sgmii_phy1: phy@a {
> > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > + reg = <0xa>;
> > > > + device_type = "ethernet-phy";
> > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > + reset-assert-us = <11000>;
> > > > + reset-deassert-us = <70000>;
> > > > + };
> > > > +};
> > > > --
> > > > 2.47.0
> > > >
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
> >
> > Thanks & Regards,
> > Wasim
>
> --
> With best wishes
> Dmitry
Thanks & Regards,
Wasim
On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > >
> > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > management.
> > > > >
> > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > >
> > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > include corresponding SA8775P files.
> > > >
> > > > This is not ideal for the following reasons:
> > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > lead to mistakes.
> > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > to issues being patches in the one board file, but not in the other
> > > > file.
> > > >
> > > > If there are any reasons why you want to follow this approach, they must
> > > > be a part of the commit message.
> > > >
> > >
> > > Hi Dmitry,
> > >
> > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > based on Krzysztof's previous suggestion [2], we change to this format.
> > >
> > > Please let us know how to proceed further on this.
> >
> > Krzysztof asked you to include DTSI files instead of including DTS
> > files. Hope this helps.
>
> Are you suggesting that we should also modify the 9100-ride files to
> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> However, this would result in the duplication of Ethernet nodes in all
> the ride board files. Would that be acceptable?
git mv foo.dts foo.dtsi
echo '#include "foo.dtsi"' > foo.dts
git add foo.dts
git commit
>
> >
> > >
> > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > >
> > > > >
> > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > > > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > > > > 3 files changed, 94 insertions(+)
> > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > > > > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > new file mode 100644
> > > > > index 000000000000..d9a8956d3a76
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > @@ -0,0 +1,46 @@
> > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > +/*
> > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > + */
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "sa8775p-ride.dtsi"
> > > > > +
> > > > > +/ {
> > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > +};
> > > > > +
> > > > > +ðernet0 {
> > > > > + phy-mode = "2500base-x";
> > > > > +};
> > > > > +
> > > > > +ðernet1 {
> > > > > + phy-mode = "2500base-x";
> > > > > +};
> > > > > +
> > > > > +&mdio {
> > > > > + compatible = "snps,dwmac-mdio";
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + sgmii_phy0: phy@8 {
> > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > + reg = <0x8>;
> > > > > + device_type = "ethernet-phy";
> > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > + reset-assert-us = <11000>;
> > > > > + reset-deassert-us = <70000>;
> > > > > + };
> > > > > +
> > > > > + sgmii_phy1: phy@0 {
> > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > + reg = <0x0>;
> > > > > + device_type = "ethernet-phy";
> > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > + reset-assert-us = <11000>;
> > > > > + reset-deassert-us = <70000>;
> > > > > + };
> > > > > +};
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > new file mode 100644
> > > > > index 000000000000..3b524359a72d
> > > > > --- /dev/null
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > @@ -0,0 +1,46 @@
> > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > +/*
> > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > + */
> > > > > +/dts-v1/;
> > > > > +
> > > > > +#include "sa8775p-ride.dtsi"
> > > > > +
> > > > > +/ {
> > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > +};
> > > > > +
> > > > > +ðernet0 {
> > > > > + phy-mode = "sgmii";
> > > > > +};
> > > > > +
> > > > > +ðernet1 {
> > > > > + phy-mode = "sgmii";
> > > > > +};
> > > > > +
> > > > > +&mdio {
> > > > > + compatible = "snps,dwmac-mdio";
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <0>;
> > > > > +
> > > > > + sgmii_phy0: phy@8 {
> > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > + reg = <0x8>;
> > > > > + device_type = "ethernet-phy";
> > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > + reset-assert-us = <11000>;
> > > > > + reset-deassert-us = <70000>;
> > > > > + };
> > > > > +
> > > > > + sgmii_phy1: phy@a {
> > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > + reg = <0xa>;
> > > > > + device_type = "ethernet-phy";
> > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > + reset-assert-us = <11000>;
> > > > > + reset-deassert-us = <70000>;
> > > > > + };
> > > > > +};
> > > > > --
> > > > > 2.47.0
> > > > >
> > > >
> > > > --
> > > > With best wishes
> > > > Dmitry
> > >
> > >
> > > Thanks & Regards,
> > > Wasim
> >
> > --
> > With best wishes
> > Dmitry
>
>
> Thanks & Regards,
> Wasim
--
With best wishes
Dmitry
On Fri, Jan 03, 2025 at 12:31:55PM +0200, Dmitry Baryshkov wrote:
> On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> > On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > >
> > > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > > management.
> > > > > >
> > > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > >
> > > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > > include corresponding SA8775P files.
> > > > >
> > > > > This is not ideal for the following reasons:
> > > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > > lead to mistakes.
> > > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > > to issues being patches in the one board file, but not in the other
> > > > > file.
> > > > >
> > > > > If there are any reasons why you want to follow this approach, they must
> > > > > be a part of the commit message.
> > > > >
> > > >
> > > > Hi Dmitry,
> > > >
> > > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > >
> > > > Please let us know how to proceed further on this.
> > >
> > > Krzysztof asked you to include DTSI files instead of including DTS
> > > files. Hope this helps.
> >
> > Are you suggesting that we should also modify the 9100-ride files to
> > include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > However, this would result in the duplication of Ethernet nodes in all
> > the ride board files. Would that be acceptable?
>
> git mv foo.dts foo.dtsi
> echo '#include "foo.dtsi"' > foo.dts
> git add foo.dts
> git commit
>
We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
they represent different platforms. In patch [1], we included these DTS
files to reuse the common hardware nodes.
Could you please advise on how we should proceed with the following
approaches?
a) Previous approach [1]:
Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
platform DTS, similar to the qcs9100-ride platform DTS. This approach
avoids duplicating Ethernet nodes and maintains uniformity. However, it
involves including the DTS file directly.
b) Current suggestion:
Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
modify the qcs9100-ride platform DTS files to maintain uniformity. This
approach results in duplicating Ethernet nodes.
Please let us know your recommendation to finalize the DT structure.
[1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> >
> > >
> > > >
> > > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > >
> > > > > >
> > > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > > ---
> > > > > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > > > > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > > > > > 3 files changed, 94 insertions(+)
> > > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > > > > > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > new file mode 100644
> > > > > > index 000000000000..d9a8956d3a76
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > @@ -0,0 +1,46 @@
> > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > +/*
> > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > + */
> > > > > > +/dts-v1/;
> > > > > > +
> > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > +};
> > > > > > +
> > > > > > +ðernet0 {
> > > > > > + phy-mode = "2500base-x";
> > > > > > +};
> > > > > > +
> > > > > > +ðernet1 {
> > > > > > + phy-mode = "2500base-x";
> > > > > > +};
> > > > > > +
> > > > > > +&mdio {
> > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + sgmii_phy0: phy@8 {
> > > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > > + reg = <0x8>;
> > > > > > + device_type = "ethernet-phy";
> > > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > + reset-assert-us = <11000>;
> > > > > > + reset-deassert-us = <70000>;
> > > > > > + };
> > > > > > +
> > > > > > + sgmii_phy1: phy@0 {
> > > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > > + reg = <0x0>;
> > > > > > + device_type = "ethernet-phy";
> > > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > + reset-assert-us = <11000>;
> > > > > > + reset-deassert-us = <70000>;
> > > > > > + };
> > > > > > +};
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > new file mode 100644
> > > > > > index 000000000000..3b524359a72d
> > > > > > --- /dev/null
> > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > @@ -0,0 +1,46 @@
> > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > +/*
> > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > + */
> > > > > > +/dts-v1/;
> > > > > > +
> > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > +};
> > > > > > +
> > > > > > +ðernet0 {
> > > > > > + phy-mode = "sgmii";
> > > > > > +};
> > > > > > +
> > > > > > +ðernet1 {
> > > > > > + phy-mode = "sgmii";
> > > > > > +};
> > > > > > +
> > > > > > +&mdio {
> > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > + #address-cells = <1>;
> > > > > > + #size-cells = <0>;
> > > > > > +
> > > > > > + sgmii_phy0: phy@8 {
> > > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > > + reg = <0x8>;
> > > > > > + device_type = "ethernet-phy";
> > > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > + reset-assert-us = <11000>;
> > > > > > + reset-deassert-us = <70000>;
> > > > > > + };
> > > > > > +
> > > > > > + sgmii_phy1: phy@a {
> > > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > > + reg = <0xa>;
> > > > > > + device_type = "ethernet-phy";
> > > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > + reset-assert-us = <11000>;
> > > > > > + reset-deassert-us = <70000>;
> > > > > > + };
> > > > > > +};
> > > > > > --
> > > > > > 2.47.0
> > > > > >
> > > > >
> > > > > --
> > > > > With best wishes
> > > > > Dmitry
> > > >
> > > >
> > > > Thanks & Regards,
> > > > Wasim
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
> >
> > Thanks & Regards,
> > Wasim
>
> --
> With best wishes
> Dmitry
Thanks & Regards,
Wasim
On Sat, Jan 04, 2025 at 12:29:07AM +0530, Wasim Nazir wrote:
> On Fri, Jan 03, 2025 at 12:31:55PM +0200, Dmitry Baryshkov wrote:
> > On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> > > On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > > > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > > >
> > > > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > > > management.
> > > > > > >
> > > > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > > >
> > > > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > > > include corresponding SA8775P files.
> > > > > >
> > > > > > This is not ideal for the following reasons:
> > > > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > > > lead to mistakes.
> > > > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > > > to issues being patches in the one board file, but not in the other
> > > > > > file.
> > > > > >
> > > > > > If there are any reasons why you want to follow this approach, they must
> > > > > > be a part of the commit message.
> > > > > >
> > > > >
> > > > > Hi Dmitry,
> > > > >
> > > > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > > >
> > > > > Please let us know how to proceed further on this.
> > > >
> > > > Krzysztof asked you to include DTSI files instead of including DTS
> > > > files. Hope this helps.
> > >
> > > Are you suggesting that we should also modify the 9100-ride files to
> > > include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > > However, this would result in the duplication of Ethernet nodes in all
> > > the ride board files. Would that be acceptable?
> >
> > git mv foo.dts foo.dtsi
> > echo '#include "foo.dtsi"' > foo.dts
> > git add foo.dts
> > git commit
> >
>
> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> they represent different platforms. In patch [1], we included these DTS
> files to reuse the common hardware nodes.
>
> Could you please advise on how we should proceed with the following
> approaches?
>
> a) Previous approach [1]:
> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> platform DTS, similar to the qcs9100-ride platform DTS. This approach
> avoids duplicating Ethernet nodes and maintains uniformity. However, it
> involves including the DTS file directly.
>
> b) Current suggestion:
> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> modify the qcs9100-ride platform DTS files to maintain uniformity. This
> approach results in duplicating Ethernet nodes.
>
> Please let us know your recommendation to finalize the DT structure.
sa8775p.dtsi
`__sa8775p-ride.dtsi
`__sa8775p-ride-r2.dtsi
`__sa8775p-ride.dts
`__qcs9100-ride.dts
`__qcs9075-ride.dts
`__sa8775p-ride-r3.dtsi
`__sa8775p-ride-r3.dts
`__qcs9100-ride-r3.dts
`__qcs9075-ride-r3.dts
>
> [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
>
> > >
> > > >
> > > > >
> > > > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > > >
> > > > > > >
> > > > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > > > ---
> > > > > > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > > > > > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > > > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > > > > > > 3 files changed, 94 insertions(+)
> > > > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > > > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > > > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..d9a8956d3a76
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > @@ -0,0 +1,46 @@
> > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > +/*
> > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > + */
> > > > > > > +/dts-v1/;
> > > > > > > +
> > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > +
> > > > > > > +/ {
> > > > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > > > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > +};
> > > > > > > +
> > > > > > > +ðernet0 {
> > > > > > > + phy-mode = "2500base-x";
> > > > > > > +};
> > > > > > > +
> > > > > > > +ðernet1 {
> > > > > > > + phy-mode = "2500base-x";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&mdio {
> > > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + sgmii_phy0: phy@8 {
> > > > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > + reg = <0x8>;
> > > > > > > + device_type = "ethernet-phy";
> > > > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > + reset-assert-us = <11000>;
> > > > > > > + reset-deassert-us = <70000>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + sgmii_phy1: phy@0 {
> > > > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > + reg = <0x0>;
> > > > > > > + device_type = "ethernet-phy";
> > > > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > + reset-assert-us = <11000>;
> > > > > > > + reset-deassert-us = <70000>;
> > > > > > > + };
> > > > > > > +};
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..3b524359a72d
> > > > > > > --- /dev/null
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > @@ -0,0 +1,46 @@
> > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > +/*
> > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > + */
> > > > > > > +/dts-v1/;
> > > > > > > +
> > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > +
> > > > > > > +/ {
> > > > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > > > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > +};
> > > > > > > +
> > > > > > > +ðernet0 {
> > > > > > > + phy-mode = "sgmii";
> > > > > > > +};
> > > > > > > +
> > > > > > > +ðernet1 {
> > > > > > > + phy-mode = "sgmii";
> > > > > > > +};
> > > > > > > +
> > > > > > > +&mdio {
> > > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > > + #address-cells = <1>;
> > > > > > > + #size-cells = <0>;
> > > > > > > +
> > > > > > > + sgmii_phy0: phy@8 {
> > > > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > + reg = <0x8>;
> > > > > > > + device_type = "ethernet-phy";
> > > > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > + reset-assert-us = <11000>;
> > > > > > > + reset-deassert-us = <70000>;
> > > > > > > + };
> > > > > > > +
> > > > > > > + sgmii_phy1: phy@a {
> > > > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > + reg = <0xa>;
> > > > > > > + device_type = "ethernet-phy";
> > > > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > + reset-assert-us = <11000>;
> > > > > > > + reset-deassert-us = <70000>;
> > > > > > > + };
> > > > > > > +};
> > > > > > > --
> > > > > > > 2.47.0
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > With best wishes
> > > > > > Dmitry
> > > > >
> > > > >
> > > > > Thanks & Regards,
> > > > > Wasim
> > > >
> > > > --
> > > > With best wishes
> > > > Dmitry
> > >
> > >
> > > Thanks & Regards,
> > > Wasim
> >
> > --
> > With best wishes
> > Dmitry
>
> Thanks & Regards,
> Wasim
--
With best wishes
Dmitry
On Fri, Jan 03, 2025 at 09:58:40PM +0200, Dmitry Baryshkov wrote:
> On Sat, Jan 04, 2025 at 12:29:07AM +0530, Wasim Nazir wrote:
> > On Fri, Jan 03, 2025 at 12:31:55PM +0200, Dmitry Baryshkov wrote:
> > > On Fri, Jan 03, 2025 at 12:37:50PM +0530, Wasim Nazir wrote:
> > > > On Fri, Jan 03, 2025 at 07:50:43AM +0200, Dmitry Baryshkov wrote:
> > > > > On Thu, Jan 02, 2025 at 02:37:39PM +0530, Wasim Nazir wrote:
> > > > > > On Mon, Dec 30, 2024 at 05:45:39PM +0200, Dmitry Baryshkov wrote:
> > > > > > > On Sun, Dec 29, 2024 at 08:53:31PM +0530, Wasim Nazir wrote:
> > > > > > > > Add device tree support for QCS9075 Ride & Ride-r3 boards.
> > > > > > > >
> > > > > > > > QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> > > > > > > > subsystem which is available in QCS9100, and it affects thermal
> > > > > > > > management.
> > > > > > > >
> > > > > > > > Also, between ride and ride-r3 ethernet phy is different.
> > > > > > > > Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
> > > > > > >
> > > > > > > Your board files duplicate sa8775p-ride-r3.dts and sa8775p-ride.dts, but
> > > > > > > include them. Existing qcs9100-ride-r3.dts and qcs9100-ride-r3.dts just
> > > > > > > include corresponding SA8775P files.
> > > > > > >
> > > > > > > This is not ideal for the following reasons:
> > > > > > > - The approach is not uniform (between QCS9100 and QCS9075), which might
> > > > > > > lead to mistakes.
> > > > > > > - The approach ends up duplicating DT code unnecessarily, which can lead
> > > > > > > to issues being patches in the one board file, but not in the other
> > > > > > > file.
> > > > > > >
> > > > > > > If there are any reasons why you want to follow this approach, they must
> > > > > > > be a part of the commit message.
> > > > > > >
> > > > > >
> > > > > > Hi Dmitry,
> > > > > >
> > > > > > Initially, we included the DTS [1] file to avoid duplication. However,
> > > > > > based on Krzysztof's previous suggestion [2], we change to this format.
> > > > > >
> > > > > > Please let us know how to proceed further on this.
> > > > >
> > > > > Krzysztof asked you to include DTSI files instead of including DTS
> > > > > files. Hope this helps.
> > > >
> > > > Are you suggesting that we should also modify the 9100-ride files to
> > > > include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> > > > However, this would result in the duplication of Ethernet nodes in all
> > > > the ride board files. Would that be acceptable?
> > >
> > > git mv foo.dts foo.dtsi
> > > echo '#include "foo.dtsi"' > foo.dts
> > > git add foo.dts
> > > git commit
> > >
> >
> > We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> > they represent different platforms. In patch [1], we included these DTS
> > files to reuse the common hardware nodes.
> >
> > Could you please advise on how we should proceed with the following
> > approaches?
> >
> > a) Previous approach [1]:
> > Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> > platform DTS, similar to the qcs9100-ride platform DTS. This approach
> > avoids duplicating Ethernet nodes and maintains uniformity. However, it
> > involves including the DTS file directly.
> >
> > b) Current suggestion:
> > Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> > modify the qcs9100-ride platform DTS files to maintain uniformity. This
> > approach results in duplicating Ethernet nodes.
> >
> > Please let us know your recommendation to finalize the DT structure.
>
> sa8775p.dtsi
> `__sa8775p-ride.dtsi
> `__sa8775p-ride-r2.dtsi
> `__sa8775p-ride.dts
> `__qcs9100-ride.dts
> `__qcs9075-ride.dts
> `__sa8775p-ride-r3.dtsi
> `__sa8775p-ride-r3.dts
> `__qcs9100-ride-r3.dts
> `__qcs9075-ride-r3.dts
Thanks Dmitry, we need slight modification to the above structure as
we don't have any ride-r2 boards, so we want to go ahead with this structure:
sa8775p.dtsi
`__sa8775p-ride-common.dtsi
`__sa8775p-ride.dtsi
`__sa8775p-ride.dts
`__qcs9100-ride.dts
`__qcs9075-ride.dts
`__sa8775p-ride-r3.dtsi
`__sa8775p-ride-r3.dts
`__qcs9100-ride-r3.dts
`__qcs9075-ride-r3.dts
>
> >
> > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> >
> > > >
> > > > >
> > > > > >
> > > > > > [1] https://lore.kernel.org/all/20241119174954.1219002-6-quic_wasimn@quicinc.com/
> > > > > > [2] https://lore.kernel.org/all/8cf9edc0-a0cb-4fd0-b10e-2138784dfba3@kernel.org/
> > > > > >
> > > > > > > >
> > > > > > > > Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> > > > > > > > ---
> > > > > > > > arch/arm64/boot/dts/qcom/Makefile | 2 +
> > > > > > > > arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> > > > > > > > arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> > > > > > > > 3 files changed, 94 insertions(+)
> > > > > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > > create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > >
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > > index 78613a1bd34a..41cb2bbd3472 100644
> > > > > > > > --- a/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > > > > > > > @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> > > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> > > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> > > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> > > > > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> > > > > > > > +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> > > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> > > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> > > > > > > > dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..d9a8956d3a76
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> > > > > > > > @@ -0,0 +1,46 @@
> > > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > +/*
> > > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > > + */
> > > > > > > > +/dts-v1/;
> > > > > > > > +
> > > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> > > > > > > > + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +ðernet0 {
> > > > > > > > + phy-mode = "2500base-x";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +ðernet1 {
> > > > > > > > + phy-mode = "2500base-x";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mdio {
> > > > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <0>;
> > > > > > > > +
> > > > > > > > + sgmii_phy0: phy@8 {
> > > > > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > > + reg = <0x8>;
> > > > > > > > + device_type = "ethernet-phy";
> > > > > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > > + reset-assert-us = <11000>;
> > > > > > > > + reset-deassert-us = <70000>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + sgmii_phy1: phy@0 {
> > > > > > > > + compatible = "ethernet-phy-id31c3.1c33";
> > > > > > > > + reg = <0x0>;
> > > > > > > > + device_type = "ethernet-phy";
> > > > > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > > + reset-assert-us = <11000>;
> > > > > > > > + reset-deassert-us = <70000>;
> > > > > > > > + };
> > > > > > > > +};
> > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > > new file mode 100644
> > > > > > > > index 000000000000..3b524359a72d
> > > > > > > > --- /dev/null
> > > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> > > > > > > > @@ -0,0 +1,46 @@
> > > > > > > > +// SPDX-License-Identifier: BSD-3-Clause
> > > > > > > > +/*
> > > > > > > > + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> > > > > > > > + */
> > > > > > > > +/dts-v1/;
> > > > > > > > +
> > > > > > > > +#include "sa8775p-ride.dtsi"
> > > > > > > > +
> > > > > > > > +/ {
> > > > > > > > + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> > > > > > > > + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +ðernet0 {
> > > > > > > > + phy-mode = "sgmii";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +ðernet1 {
> > > > > > > > + phy-mode = "sgmii";
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +&mdio {
> > > > > > > > + compatible = "snps,dwmac-mdio";
> > > > > > > > + #address-cells = <1>;
> > > > > > > > + #size-cells = <0>;
> > > > > > > > +
> > > > > > > > + sgmii_phy0: phy@8 {
> > > > > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > > + reg = <0x8>;
> > > > > > > > + device_type = "ethernet-phy";
> > > > > > > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > > > > > > + reset-assert-us = <11000>;
> > > > > > > > + reset-deassert-us = <70000>;
> > > > > > > > + };
> > > > > > > > +
> > > > > > > > + sgmii_phy1: phy@a {
> > > > > > > > + compatible = "ethernet-phy-id0141.0dd4";
> > > > > > > > + reg = <0xa>;
> > > > > > > > + device_type = "ethernet-phy";
> > > > > > > > + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> > > > > > > > + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> > > > > > > > + reset-assert-us = <11000>;
> > > > > > > > + reset-deassert-us = <70000>;
> > > > > > > > + };
> > > > > > > > +};
> > > > > > > > --
> > > > > > > > 2.47.0
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > With best wishes
> > > > > > > Dmitry
> > > > > >
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > Wasim
> > > > >
> > > > > --
> > > > > With best wishes
> > > > > Dmitry
> > > >
> > > >
> > > > Thanks & Regards,
> > > > Wasim
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
> > Thanks & Regards,
> > Wasim
>
> --
> With best wishes
> Dmitry
Thanks & Regards,
Wasim
On 03/01/2025 20:58, Dmitry Baryshkov wrote: >>>>>> Initially, we included the DTS [1] file to avoid duplication. However, >>>>>> based on Krzysztof's previous suggestion [2], we change to this format. >>>>>> >>>>>> Please let us know how to proceed further on this. >>>>> >>>>> Krzysztof asked you to include DTSI files instead of including DTS >>>>> files. Hope this helps. >>>> >>>> Are you suggesting that we should also modify the 9100-ride files to >>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075? >>>> However, this would result in the duplication of Ethernet nodes in all >>>> the ride board files. Would that be acceptable? >>> >>> git mv foo.dts foo.dtsi >>> echo '#include "foo.dtsi"' > foo.dts >>> git add foo.dts >>> git commit >>> >> >> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as >> they represent different platforms. In patch [1], we included these DTS >> files to reuse the common hardware nodes. >> >> Could you please advise on how we should proceed with the following >> approaches? >> >> a) Previous approach [1]: >> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride >> platform DTS, similar to the qcs9100-ride platform DTS. This approach >> avoids duplicating Ethernet nodes and maintains uniformity. However, it >> involves including the DTS file directly. >> >> b) Current suggestion: >> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also >> modify the qcs9100-ride platform DTS files to maintain uniformity. This >> approach results in duplicating Ethernet nodes. >> >> Please let us know your recommendation to finalize the DT structure. > > sa8775p.dtsi > `__sa8775p-ride.dtsi > `__sa8775p-ride-r2.dtsi > `__sa8775p-ride.dts > `__qcs9100-ride.dts > `__qcs9075-ride.dts > `__sa8775p-ride-r3.dtsi > `__sa8775p-ride-r3.dts > `__qcs9100-ride-r3.dts > `__qcs9075-ride-r3.dts > Wasim and all other copy-pasters of sa8775p-ride, Just to recap, qcs9100 contributions started this terrible pattern of board including a board. Unfortunately qcs9100 was merged, so that ship has sailed. This patchset was going the same way, because poor choices like to keep spreading, but at one of previous versions I noticed it and objected. This v5 however solves above problem by duplicating the nodes. Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the same board, but none of this was communicated. I checked all the commit msgs in this patchset and nothing explained about it. What annoys me is that you do not communicate your design forcing us to accept poor DTS or forcing us to guess and make poor judgments. Come with proper hardware description and split out shared parts, like motherboard. Look how other vendors are doing it, e.g. NXP or Renesas. But assuming there are shared parts because I am pretty sure you will pick my comments when it suits you without actually following them fully and without understanding and explaining to us your own hardware. Best regards, Krzysztof
On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote: > On 03/01/2025 20:58, Dmitry Baryshkov wrote: > >>>>>> Initially, we included the DTS [1] file to avoid duplication. However, > >>>>>> based on Krzysztof's previous suggestion [2], we change to this format. > >>>>>> > >>>>>> Please let us know how to proceed further on this. > >>>>> > >>>>> Krzysztof asked you to include DTSI files instead of including DTS > >>>>> files. Hope this helps. > >>>> > >>>> Are you suggesting that we should also modify the 9100-ride files to > >>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075? > >>>> However, this would result in the duplication of Ethernet nodes in all > >>>> the ride board files. Would that be acceptable? > >>> > >>> git mv foo.dts foo.dtsi > >>> echo '#include "foo.dtsi"' > foo.dts > >>> git add foo.dts > >>> git commit > >>> > >> > >> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as > >> they represent different platforms. In patch [1], we included these DTS > >> files to reuse the common hardware nodes. > >> > >> Could you please advise on how we should proceed with the following > >> approaches? > >> > >> a) Previous approach [1]: > >> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride > >> platform DTS, similar to the qcs9100-ride platform DTS. This approach > >> avoids duplicating Ethernet nodes and maintains uniformity. However, it > >> involves including the DTS file directly. > >> > >> b) Current suggestion: > >> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also > >> modify the qcs9100-ride platform DTS files to maintain uniformity. This > >> approach results in duplicating Ethernet nodes. > >> > >> Please let us know your recommendation to finalize the DT structure. > > > > sa8775p.dtsi > > `__sa8775p-ride.dtsi > > `__sa8775p-ride-r2.dtsi > > `__sa8775p-ride.dts > > `__qcs9100-ride.dts > > `__qcs9075-ride.dts > > `__sa8775p-ride-r3.dtsi > > `__sa8775p-ride-r3.dts > > `__qcs9100-ride-r3.dts > > `__qcs9075-ride-r3.dts > > > Wasim and all other copy-pasters of sa8775p-ride, > > Just to recap, qcs9100 contributions started this terrible pattern of > board including a board. Unfortunately qcs9100 was merged, so that ship > has sailed. > > This patchset was going the same way, because poor choices like to keep > spreading, but at one of previous versions I noticed it and objected. > > This v5 however solves above problem by duplicating the nodes. > > Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the > same board, but none of this was communicated. I checked all the commit > msgs in this patchset and nothing explained about it. What annoys me is > that you do not communicate your design forcing us to accept poor DTS or > forcing us to guess and make poor judgments. > > Come with proper hardware description and split out shared parts, like > motherboard. Look how other vendors are doing it, e.g. NXP or Renesas. > But assuming there are shared parts because I am pretty sure you will > pick my comments when it suits you without actually following them fully > and without understanding and explaining to us your own hardware. > Hi Krzysztof, Here is the pictorial flow showing how SoCs are derived and what all boards are supported. +---------------------------------------------------------------------+ | | | sa8775p | | | | | +-----------------------+-----------------------+ | | | | | | | v | v | | qcs9100 | qcs9075 | | | | | | | v v v | | (IOT) (AUTO) (IOT) | | qcs9100-ride.dts sa8775p-ride.dts qcs9075-ride.dts | | qcs9100-ride-r3.dts sa8775p-ride-r3.dts qcs9075-ride-r3.dts | | qcs9075-rb8.dts | | | +---------------------------------------------------------------------+ Although we included details about the QCS9075 and QCS9100 in the cover letter and commit message, explaining their differences and common origin from the SA8775P SOC, the new DT structure suggested by Dmitry should make things clearer. This structure properly splits common parts and enhances reusability. > Best regards, > Krzysztof Thanks & Regards, Wasim
On 09/01/2025 15:47, Wasim Nazir wrote: > On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote: >> On 03/01/2025 20:58, Dmitry Baryshkov wrote: >>>>>>>> Initially, we included the DTS [1] file to avoid duplication. However, >>>>>>>> based on Krzysztof's previous suggestion [2], we change to this format. >>>>>>>> >>>>>>>> Please let us know how to proceed further on this. >>>>>>> >>>>>>> Krzysztof asked you to include DTSI files instead of including DTS >>>>>>> files. Hope this helps. >>>>>> >>>>>> Are you suggesting that we should also modify the 9100-ride files to >>>>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075? >>>>>> However, this would result in the duplication of Ethernet nodes in all >>>>>> the ride board files. Would that be acceptable? >>>>> >>>>> git mv foo.dts foo.dtsi >>>>> echo '#include "foo.dtsi"' > foo.dts >>>>> git add foo.dts >>>>> git commit >>>>> >>>> >>>> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as >>>> they represent different platforms. In patch [1], we included these DTS >>>> files to reuse the common hardware nodes. >>>> >>>> Could you please advise on how we should proceed with the following >>>> approaches? >>>> >>>> a) Previous approach [1]: >>>> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride >>>> platform DTS, similar to the qcs9100-ride platform DTS. This approach >>>> avoids duplicating Ethernet nodes and maintains uniformity. However, it >>>> involves including the DTS file directly. >>>> >>>> b) Current suggestion: >>>> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also >>>> modify the qcs9100-ride platform DTS files to maintain uniformity. This >>>> approach results in duplicating Ethernet nodes. >>>> >>>> Please let us know your recommendation to finalize the DT structure. >>> >>> sa8775p.dtsi >>> `__sa8775p-ride.dtsi >>> `__sa8775p-ride-r2.dtsi >>> `__sa8775p-ride.dts >>> `__qcs9100-ride.dts >>> `__qcs9075-ride.dts >>> `__sa8775p-ride-r3.dtsi >>> `__sa8775p-ride-r3.dts >>> `__qcs9100-ride-r3.dts >>> `__qcs9075-ride-r3.dts >>> >> Wasim and all other copy-pasters of sa8775p-ride, >> >> Just to recap, qcs9100 contributions started this terrible pattern of >> board including a board. Unfortunately qcs9100 was merged, so that ship >> has sailed. >> >> This patchset was going the same way, because poor choices like to keep >> spreading, but at one of previous versions I noticed it and objected. >> >> This v5 however solves above problem by duplicating the nodes. >> >> Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the >> same board, but none of this was communicated. I checked all the commit >> msgs in this patchset and nothing explained about it. What annoys me is >> that you do not communicate your design forcing us to accept poor DTS or >> forcing us to guess and make poor judgments. >> >> Come with proper hardware description and split out shared parts, like >> motherboard. Look how other vendors are doing it, e.g. NXP or Renesas. >> But assuming there are shared parts because I am pretty sure you will >> pick my comments when it suits you without actually following them fully >> and without understanding and explaining to us your own hardware. >> > > Hi Krzysztof, > > Here is the pictorial flow showing how SoCs are derived and what all boards > are supported. > > +---------------------------------------------------------------------+ > | | > | sa8775p | > | | | > | +-----------------------+-----------------------+ | > | | | | | > | v | v | > | qcs9100 | qcs9075 | > | | | | | > | v v v | > | (IOT) (AUTO) (IOT) | > | qcs9100-ride.dts sa8775p-ride.dts qcs9075-ride.dts | > | qcs9100-ride-r3.dts sa8775p-ride-r3.dts qcs9075-ride-r3.dts | > | qcs9075-rb8.dts | > | | > +---------------------------------------------------------------------+ The the SoC, I am asking about the board. Why each of them is for example r3? So this is not sufficient explanation, nothing about the board, and again just look Renesas and NXP. Best regards, Krzysztof
On Thu, Jan 09, 2025 at 05:16:25PM +0100, Krzysztof Kozlowski wrote: > On 09/01/2025 15:47, Wasim Nazir wrote: > > On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote: > >> On 03/01/2025 20:58, Dmitry Baryshkov wrote: > >>>>>>>> Initially, we included the DTS [1] file to avoid duplication. However, > >>>>>>>> based on Krzysztof's previous suggestion [2], we change to this format. > >>>>>>>> > >>>>>>>> Please let us know how to proceed further on this. > >>>>>>> > >>>>>>> Krzysztof asked you to include DTSI files instead of including DTS > >>>>>>> files. Hope this helps. > >>>>>> > >>>>>> Are you suggesting that we should also modify the 9100-ride files to > >>>>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075? > >>>>>> However, this would result in the duplication of Ethernet nodes in all > >>>>>> the ride board files. Would that be acceptable? > >>>>> > >>>>> git mv foo.dts foo.dtsi > >>>>> echo '#include "foo.dtsi"' > foo.dts > >>>>> git add foo.dts > >>>>> git commit > >>>>> > >>>> > >>>> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as > >>>> they represent different platforms. In patch [1], we included these DTS > >>>> files to reuse the common hardware nodes. > >>>> > >>>> Could you please advise on how we should proceed with the following > >>>> approaches? > >>>> > >>>> a) Previous approach [1]: > >>>> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride > >>>> platform DTS, similar to the qcs9100-ride platform DTS. This approach > >>>> avoids duplicating Ethernet nodes and maintains uniformity. However, it > >>>> involves including the DTS file directly. > >>>> > >>>> b) Current suggestion: > >>>> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also > >>>> modify the qcs9100-ride platform DTS files to maintain uniformity. This > >>>> approach results in duplicating Ethernet nodes. > >>>> > >>>> Please let us know your recommendation to finalize the DT structure. > >>> > >>> sa8775p.dtsi > >>> `__sa8775p-ride.dtsi > >>> `__sa8775p-ride-r2.dtsi > >>> `__sa8775p-ride.dts > >>> `__qcs9100-ride.dts > >>> `__qcs9075-ride.dts > >>> `__sa8775p-ride-r3.dtsi > >>> `__sa8775p-ride-r3.dts > >>> `__qcs9100-ride-r3.dts > >>> `__qcs9075-ride-r3.dts > >>> > >> Wasim and all other copy-pasters of sa8775p-ride, > >> > >> Just to recap, qcs9100 contributions started this terrible pattern of > >> board including a board. Unfortunately qcs9100 was merged, so that ship > >> has sailed. > >> > >> This patchset was going the same way, because poor choices like to keep > >> spreading, but at one of previous versions I noticed it and objected. > >> > >> This v5 however solves above problem by duplicating the nodes. > >> > >> Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the > >> same board, but none of this was communicated. I checked all the commit > >> msgs in this patchset and nothing explained about it. What annoys me is > >> that you do not communicate your design forcing us to accept poor DTS or > >> forcing us to guess and make poor judgments. > >> > >> Come with proper hardware description and split out shared parts, like > >> motherboard. Look how other vendors are doing it, e.g. NXP or Renesas. > >> But assuming there are shared parts because I am pretty sure you will > >> pick my comments when it suits you without actually following them fully > >> and without understanding and explaining to us your own hardware. > >> > > > > Hi Krzysztof, > > > > Here is the pictorial flow showing how SoCs are derived and what all boards > > are supported. > > > > +---------------------------------------------------------------------+ > > | | > > | sa8775p | > > | | | > > | +-----------------------+-----------------------+ | > > | | | | | > > | v | v | > > | qcs9100 | qcs9075 | > > | | | | | > > | v v v | > > | (IOT) (AUTO) (IOT) | > > | qcs9100-ride.dts sa8775p-ride.dts qcs9075-ride.dts | > > | qcs9100-ride-r3.dts sa8775p-ride-r3.dts qcs9075-ride-r3.dts | > > | qcs9075-rb8.dts | > > | | > > +---------------------------------------------------------------------+ > > The the SoC, I am asking about the board. Why each of them is for > example r3? > > So this is not sufficient explanation, nothing about the board, and > again just look Renesas and NXP. > Hi Krzysztof, sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on safety capabilities and memory map, serving different purpose. Ride & Ride-r3 are different boards based on ethernet capabilities and are compatible with all the SoCs mentioned. With the combination of these 3 SoCs and 2 boards, we have 6 platforms, all of which we need. - sa8775p-ride.dts is auto grade Ride platform with safety feature. - qcs9100-ride.dts is IOT grade Ride platform with safety feature. - qcs9075-ride.dts is IOT grade Ride platform without safety feature. Since the Ride-r3 boards are essentially Ride boards with Ethernet modifications, we can convert the Ride-r3 DTS to overlays. Please let me know if this solution works for you. > > Best regards, > Krzysztof Thanks & Regards, Wasim
On 15/01/2025 06:48, Wasim Nazir wrote: >> The the SoC, I am asking about the board. Why each of them is for >> example r3? >> >> So this is not sufficient explanation, nothing about the board, and >> again just look Renesas and NXP. >> > > Hi Krzysztof, > > sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on > safety capabilities and memory map, serving different purpose. > Ride & Ride-r3 are different boards based on ethernet capabilities and > are compatible with all the SoCs mentioned. Compatible? What does it mean for a board? Third time: did you look how other vendors do it? > > With the combination of these 3 SoCs and 2 boards, we have 6 platforms, > all of which we need. > - sa8775p-ride.dts is auto grade Ride platform with safety feature. > - qcs9100-ride.dts is IOT grade Ride platform with safety feature. > - qcs9075-ride.dts is IOT grade Ride platform without safety feature. > > Since the Ride-r3 boards are essentially Ride boards with Ethernet > modifications, we can convert the Ride-r3 DTS to overlays. How one board can be with multiple SoCs? If it is soldered, it's close to impossible - that's just not the same board. If it is not soldered, why you are not explaining it? What is Ride board? What is there? What can go there? How it can be used in other SoCs? Or for which SoCs? Is there a datasheet available? You keep repeating my about SoC and I keep responding the same: don't care. Best regards, Krzysztof
On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote: > On 15/01/2025 06:48, Wasim Nazir wrote: > >> The the SoC, I am asking about the board. Why each of them is for > >> example r3? > >> > >> So this is not sufficient explanation, nothing about the board, and > >> again just look Renesas and NXP. > >> > > > > Hi Krzysztof, > > > > sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on > > safety capabilities and memory map, serving different purpose. > > Ride & Ride-r3 are different boards based on ethernet capabilities and > > are compatible with all the SoCs mentioned. > Hi Krzysztof, > Compatible? What does it mean for a board? > Ride board is based on multiple daughter cards (SOC-card, display, camera, ethernet, pcie, sensor, etc.). The SOC is not directly soldered to Ride board, instead SOC is soldered on SIP (System in Package) card which can be mounted on SOC-daughter card of Ride board. - SoC => SIP-card => SOC-daughter-card (Ride) Together with SIP cards and other daughter cards we are creating different <soc>-Ride Variants with differences in memory map & thermal mitigations. The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP cards, except an additional third party SIL-PMIC for SAIL, which is not present in QCS9075 Ride. Other daughter cards remains same for <soc>-Ride variants, except ethernet card which is different for <soc>-Ride rev3 variants. So the Ride board (combination of daughter cards) is same across the SIP, while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075. > Third time: did you look how other vendors do it? > Yes, we have reviewed other vendors. However, please feel free to share any specific reference you would like us to follow. Here are few reference files we found from other vendors where similar tasks are performed which includes code refactoring and HW modularity: - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi, px30-engicam-px30-core-ctouch2.dts In our case along with describing the HW, code refactoring is also done which might be causing confusion, but we are ready for any inputs for correction. Putting this pictorial diagram for updated DT structure depicting our HW. - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having SoC, PMICs, Memory-map updates. - qcom-ride-common.dtsi specifying ride daughter boards, here we are doing code refactoring also as this is common for all ride boards. - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which uses 2.5G phy and can be overlayed to ride boards to get ride-r3. By default ride uses 1G phy. - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product name. We will be changing this in next patch series. +-----------------------------------------------------------------------------------------------------------------------------------------------+ | | | sa8775p.dtsi | | | | | +-------------------------+-----------------------+ | | | | | | | v | v | | qcs9075-module.dtsi | qcs9100-module.dtsi | | | | | | | v v v | | (IOT) (AUTO) (IOT) | | | | | | | +----------------------+ | | | | | | | | | | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | | | | | | | | | | | v v v v v v v | | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | | | | | | | | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso | | | | | | | | | | v v v v v v | | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | | | +-----------------------------------------------------------------------------------------------------------------------------------------------+ > > > > With the combination of these 3 SoCs and 2 boards, we have 6 platforms, > > all of which we need. > > - sa8775p-ride.dts is auto grade Ride platform with safety feature. > > - qcs9100-ride.dts is IOT grade Ride platform with safety feature. > > - qcs9075-ride.dts is IOT grade Ride platform without safety feature. > > > > Since the Ride-r3 boards are essentially Ride boards with Ethernet > > modifications, we can convert the Ride-r3 DTS to overlays. > How one board can be with multiple SoCs? If it is soldered, it's close > to impossible - that's just not the same board. If it is not soldered, > why you are not explaining it? What is Ride board? What is there? What > can go there? How it can be used in other SoCs? Or for which SoCs? Is > there a datasheet available? > As our SoC is based on SIP card and SIP card is compatible with Ride board, we could able to use same Ride board (which is combination of multiple daughter cards) with multiple SIP cards. These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC. > You keep repeating my about SoC and I keep responding the same: don't care. > > Best regards, > Krzysztof Thanks & Regards, Wasim
On 27/02/2025 08:37, Wasim Nazir wrote: > On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote: >> On 15/01/2025 06:48, Wasim Nazir wrote: >>>> The the SoC, I am asking about the board. Why each of them is for >>>> example r3? >>>> >>>> So this is not sufficient explanation, nothing about the board, and >>>> again just look Renesas and NXP. >>>> >>> >>> Hi Krzysztof, >>> >>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on >>> safety capabilities and memory map, serving different purpose. >>> Ride & Ride-r3 are different boards based on ethernet capabilities and >>> are compatible with all the SoCs mentioned. >> > > Hi Krzysztof, > >> Compatible? What does it mean for a board? >> > > Ride board is based on multiple daughter cards (SOC-card, display, > camera, ethernet, pcie, sensor, etc.). > > The SOC is not directly soldered to Ride board, instead SOC is soldered > on SIP (System in Package) card which can be mounted on SOC-daughter card of > Ride board. > - SoC => SIP-card => SOC-daughter-card (Ride) So basically pretty like other designs using SoM. > > Together with SIP cards and other daughter cards we are creating different > <soc>-Ride Variants with differences in memory map & thermal mitigations. > > The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the > SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP > cards, except an additional third party SIL-PMIC for SAIL, which is not > present in QCS9075 Ride. Just like every SoM > > Other daughter cards remains same for <soc>-Ride variants, except > ethernet card which is different for <soc>-Ride rev3 variants. > > So the Ride board (combination of daughter cards) is same across the SIP, > while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075. > >> Third time: did you look how other vendors do it? >> > > Yes, we have reviewed other vendors. However, please feel free to share > any specific reference you would like us to follow. > > Here are few reference files we found from other vendors where similar > tasks are performed which includes code refactoring and HW modularity: > - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts That's an unexpected choice - I would rather look at dozen of SoMs for iMX platforms. > - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts > - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi, > px30-engicam-px30-core-ctouch2.dts > > In our case along with describing the HW, code refactoring is also done > which might be causing confusion, but we are ready for any inputs for > correction. I don't understand why this was not properly described since beginning. You had the hardware in your hands and went with incomplete or even incorrect hardware description. > > Putting this pictorial diagram for updated DT structure depicting our HW. > - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having > SoC, PMICs, Memory-map updates. > - qcom-ride-common.dtsi specifying ride daughter boards, here we are > doing code refactoring also as this is common for all ride boards. > - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which > uses 2.5G phy and can be overlayed to ride boards to get ride-r3. > By default ride uses 1G phy. > - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product > name. We will be changing this in next patch series. > > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > | | > | sa8775p.dtsi | > | | | > | +-------------------------+-----------------------+ | > | | | | | > | v | v | > | qcs9075-module.dtsi | qcs9100-module.dtsi | So this is the SoM? > | | | | | > | v v v | > | (IOT) (AUTO) (IOT) | > | | | | | > | +----------------------+ | | | > | | | | | | > | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | Which piece of actual hardware is represented in qcom-ride-common? > | | | | | | | | | > | v v v v v v v | > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > | | | | | > | | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso | > | | | | | | | | > | v v v v v v | > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | I think I gave already few times that answer: No. You cannot reference from a module.c another .c file. You cannot reference DTS from DTS. Strictly speaking you can, of course, but you must not. That's not how source code is done to be manageable and readable. > | | > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > >>> >>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms, >>> all of which we need. >>> - sa8775p-ride.dts is auto grade Ride platform with safety feature. >>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature. >>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature. >>> >>> Since the Ride-r3 boards are essentially Ride boards with Ethernet >>> modifications, we can convert the Ride-r3 DTS to overlays. >> How one board can be with multiple SoCs? If it is soldered, it's close >> to impossible - that's just not the same board. If it is not soldered, >> why you are not explaining it? What is Ride board? What is there? What >> can go there? How it can be used in other SoCs? Or for which SoCs? Is >> there a datasheet available? >> > > As our SoC is based on SIP card and SIP card is compatible with Ride > board, we could able to use same Ride board (which is combination of > multiple daughter cards) with multiple SIP cards. > These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC. Describe properly the hardware - if you have a module or SIP if you decide not to use industry-standard naming (but why...), then describe it in DTSI. Best regards, Krzysztof
On Mon, Mar 03, 2025 at 08:46:55AM +0100, Krzysztof Kozlowski wrote: > On 27/02/2025 08:37, Wasim Nazir wrote: > > On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote: > >> On 15/01/2025 06:48, Wasim Nazir wrote: > >>>> The the SoC, I am asking about the board. Why each of them is for > >>>> example r3? > >>>> > >>>> So this is not sufficient explanation, nothing about the board, and > >>>> again just look Renesas and NXP. > >>>> > >>> > >>> Hi Krzysztof, > >>> > >>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on > >>> safety capabilities and memory map, serving different purpose. > >>> Ride & Ride-r3 are different boards based on ethernet capabilities and > >>> are compatible with all the SoCs mentioned. > >> > > > > Hi Krzysztof, > > > >> Compatible? What does it mean for a board? > >> > > > > Ride board is based on multiple daughter cards (SOC-card, display, > > camera, ethernet, pcie, sensor, etc.). > > > > The SOC is not directly soldered to Ride board, instead SOC is soldered > > on SIP (System in Package) card which can be mounted on SOC-daughter card of > > Ride board. > > - SoC => SIP-card => SOC-daughter-card (Ride) > > > So basically pretty like other designs using SoM. > > > > > Together with SIP cards and other daughter cards we are creating different > > <soc>-Ride Variants with differences in memory map & thermal mitigations. > > > > The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the > > SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP > > cards, except an additional third party SIL-PMIC for SAIL, which is not > > present in QCS9075 Ride. > > Just like every SoM > > > > > Other daughter cards remains same for <soc>-Ride variants, except > > ethernet card which is different for <soc>-Ride rev3 variants. > > > > So the Ride board (combination of daughter cards) is same across the SIP, > > while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075. > > > >> Third time: did you look how other vendors do it? > >> > > > > Yes, we have reviewed other vendors. However, please feel free to share > > any specific reference you would like us to follow. > > > > Here are few reference files we found from other vendors where similar > > tasks are performed which includes code refactoring and HW modularity: > > - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts > > That's an unexpected choice - I would rather look at dozen of SoMs for > iMX platforms. > > > - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts > > - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi, > > px30-engicam-px30-core-ctouch2.dts > > > > In our case along with describing the HW, code refactoring is also done > > which might be causing confusion, but we are ready for any inputs for > > correction. > > I don't understand why this was not properly described since beginning. > You had the hardware in your hands and went with incomplete or even > incorrect hardware description. > > > > > Putting this pictorial diagram for updated DT structure depicting our HW. > > - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having > > SoC, PMICs, Memory-map updates. > > - qcom-ride-common.dtsi specifying ride daughter boards, here we are > > doing code refactoring also as this is common for all ride boards. > > - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which > > uses 2.5G phy and can be overlayed to ride boards to get ride-r3. > > By default ride uses 1G phy. > > - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product > > name. We will be changing this in next patch series. > > > > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > > | | > > | sa8775p.dtsi | > > | | | > > | +-------------------------+-----------------------+ | > > | | | | | > > | v | v | > > | qcs9075-module.dtsi | qcs9100-module.dtsi | > > So this is the SoM? Yes this is SoM. > > > | | | | | > > | v v v | > > | (IOT) (AUTO) (IOT) | > > | | | | | > > | +----------------------+ | | | > > | | | | | | > > | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | > > Which piece of actual hardware is represented in qcom-ride-common? > All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc. > > | | | | | | | | | > > | v v v v v v v | > > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > > | | | | | > > | | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso | > > | | | | | | | | > > | v v v v v v | > > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > > I think I gave already few times that answer: No. You cannot reference > from a module.c another .c file. You cannot reference DTS from DTS. > > Strictly speaking you can, of course, but you must not. That's not how > source code is done to be manageable and readable. Ah the arrow is leading to confusion. Actually we are not including dts here instead *.dtso file will be overlayed to *-ride.dts to generate *-ride-r3.dts. Below is the correct arrow sequence. | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | | | | | | | +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso | | | | | | | v v v | | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > > > | | > > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > > > >>> > >>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms, > >>> all of which we need. > >>> - sa8775p-ride.dts is auto grade Ride platform with safety feature. > >>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature. > >>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature. > >>> > >>> Since the Ride-r3 boards are essentially Ride boards with Ethernet > >>> modifications, we can convert the Ride-r3 DTS to overlays. > >> How one board can be with multiple SoCs? If it is soldered, it's close > >> to impossible - that's just not the same board. If it is not soldered, > >> why you are not explaining it? What is Ride board? What is there? What > >> can go there? How it can be used in other SoCs? Or for which SoCs? Is > >> there a datasheet available? > >> > > > > As our SoC is based on SIP card and SIP card is compatible with Ride > > board, we could able to use same Ride board (which is combination of > > multiple daughter cards) with multiple SIP cards. > > These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC. > > Describe properly the hardware - if you have a module or SIP if you > decide not to use industry-standard naming (but why...), then describe > it in DTSI. We refer to it as ‘module’ in our datasheet, so I use the same term here. Thanks for pointing it out; we can proceed with the SoM name. Below is the updated diagram: +-----------------------------------------------------------------------------------------------------------------------------------------------+ | | | sa8775p.dtsi | | | | | +-------------------------+-----------------------+ | | | | | | | v | v | | qcs9075-som.dtsi | qcs9100-som.dtsi | | | | | | | v v v | | (IOT) (AUTO) (IOT) | | | | | | | +----------------------+ | | | | | | | | | | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | | | | | | | | | | | v v v v v v v | | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | | | | | | | +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso | | | | | | | v v v | | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | | | +-----------------------------------------------------------------------------------------------------------------------------------------------+ > > Best regards, > Krzysztof Thanks & regards, Wasim
On 06/03/2025 09:17, Wasim Nazir wrote: > On Mon, Mar 03, 2025 at 08:46:55AM +0100, Krzysztof Kozlowski wrote: >> On 27/02/2025 08:37, Wasim Nazir wrote: >>> On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote: >>>> On 15/01/2025 06:48, Wasim Nazir wrote: >>>>>> The the SoC, I am asking about the board. Why each of them is for >>>>>> example r3? >>>>>> >>>>>> So this is not sufficient explanation, nothing about the board, and >>>>>> again just look Renesas and NXP. >>>>>> >>>>> >>>>> Hi Krzysztof, >>>>> >>>>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on >>>>> safety capabilities and memory map, serving different purpose. >>>>> Ride & Ride-r3 are different boards based on ethernet capabilities and >>>>> are compatible with all the SoCs mentioned. >>>> >>> >>> Hi Krzysztof, >>> >>>> Compatible? What does it mean for a board? >>>> >>> >>> Ride board is based on multiple daughter cards (SOC-card, display, >>> camera, ethernet, pcie, sensor, etc.). >>> >>> The SOC is not directly soldered to Ride board, instead SOC is soldered >>> on SIP (System in Package) card which can be mounted on SOC-daughter card of >>> Ride board. >>> - SoC => SIP-card => SOC-daughter-card (Ride) >> >> >> So basically pretty like other designs using SoM. >> >>> >>> Together with SIP cards and other daughter cards we are creating different >>> <soc>-Ride Variants with differences in memory map & thermal mitigations. >>> >>> The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the >>> SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP >>> cards, except an additional third party SIL-PMIC for SAIL, which is not >>> present in QCS9075 Ride. >> >> Just like every SoM >> >>> >>> Other daughter cards remains same for <soc>-Ride variants, except >>> ethernet card which is different for <soc>-Ride rev3 variants. >>> >>> So the Ride board (combination of daughter cards) is same across the SIP, >>> while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075. >>> >>>> Third time: did you look how other vendors do it? >>>> >>> >>> Yes, we have reviewed other vendors. However, please feel free to share >>> any specific reference you would like us to follow. >>> >>> Here are few reference files we found from other vendors where similar >>> tasks are performed which includes code refactoring and HW modularity: >>> - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts >> >> That's an unexpected choice - I would rather look at dozen of SoMs for >> iMX platforms. >> >>> - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts >>> - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi, >>> px30-engicam-px30-core-ctouch2.dts >>> >>> In our case along with describing the HW, code refactoring is also done >>> which might be causing confusion, but we are ready for any inputs for >>> correction. >> >> I don't understand why this was not properly described since beginning. >> You had the hardware in your hands and went with incomplete or even >> incorrect hardware description. >> >>> >>> Putting this pictorial diagram for updated DT structure depicting our HW. >>> - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having >>> SoC, PMICs, Memory-map updates. >>> - qcom-ride-common.dtsi specifying ride daughter boards, here we are >>> doing code refactoring also as this is common for all ride boards. >>> - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which >>> uses 2.5G phy and can be overlayed to ride boards to get ride-r3. >>> By default ride uses 1G phy. >>> - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product >>> name. We will be changing this in next patch series. >>> >>> +-----------------------------------------------------------------------------------------------------------------------------------------------+ >>> | | >>> | sa8775p.dtsi | >>> | | | >>> | +-------------------------+-----------------------+ | >>> | | | | | >>> | v | v | >>> | qcs9075-module.dtsi | qcs9100-module.dtsi | >> >> So this is the SoM? > > Yes this is SoM. > >> >>> | | | | | >>> | v v v | >>> | (IOT) (AUTO) (IOT) | >>> | | | | | >>> | +----------------------+ | | | >>> | | | | | | >>> | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | >> >> Which piece of actual hardware is represented in qcom-ride-common? >> > > All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc. No, I asked about the name of the hardware, datasheet, ID or picture. Common DTSI represents somoething, not just because you wanted to add something you had in downstream. > >>> | | | | | | | | | >>> | v v v v v v v | >>> | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | >>> | | | | | >>> | | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso | >>> | | | | | | | | >>> | v v v v v v | >>> | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | >> >> I think I gave already few times that answer: No. You cannot reference >> from a module.c another .c file. You cannot reference DTS from DTS. >> >> Strictly speaking you can, of course, but you must not. That's not how >> source code is done to be manageable and readable. > > Ah the arrow is leading to confusion. > > Actually we are not including dts here instead *.dtso file will be > overlayed to *-ride.dts to generate *-ride-r3.dts. > > Below is the correct arrow sequence. And the overlay represents what exactly? Different board? No, that's not how overlays should be used. You have different board, you have different DTS. > > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > | | | | | > | +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso | > | | | | | > | v v v | > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > >> >>> | | >>> +-----------------------------------------------------------------------------------------------------------------------------------------------+ >>> >>>>> >>>>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms, >>>>> all of which we need. >>>>> - sa8775p-ride.dts is auto grade Ride platform with safety feature. >>>>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature. >>>>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature. >>>>> >>>>> Since the Ride-r3 boards are essentially Ride boards with Ethernet >>>>> modifications, we can convert the Ride-r3 DTS to overlays. >>>> How one board can be with multiple SoCs? If it is soldered, it's close >>>> to impossible - that's just not the same board. If it is not soldered, >>>> why you are not explaining it? What is Ride board? What is there? What >>>> can go there? How it can be used in other SoCs? Or for which SoCs? Is >>>> there a datasheet available? >>>> >>> >>> As our SoC is based on SIP card and SIP card is compatible with Ride >>> board, we could able to use same Ride board (which is combination of >>> multiple daughter cards) with multiple SIP cards. >>> These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC. >> >> Describe properly the hardware - if you have a module or SIP if you >> decide not to use industry-standard naming (but why...), then describe >> it in DTSI. > > We refer to it as ‘module’ in our datasheet, so I use the same term > here. Thanks for pointing it out; we can proceed with the SoM name. > > Below is the updated diagram: > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > | | > | sa8775p.dtsi | > | | | > | +-------------------------+-----------------------+ | > | | | | | > | v | v | > | qcs9075-som.dtsi | qcs9100-som.dtsi | > | | | | | > | v v v | > | (IOT) (AUTO) (IOT) | > | | | | | > | +----------------------+ | | | > | | | | | | > | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | > | | | | | | | | | > | v v v v v v v | > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > | | | | | > | +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso | > | | | | | > | v v v | > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > | | > +-----------------------------------------------------------------------------------------------------------------------------------------------+ Several companies solved it - most of NXP vendors, many Renesas etc. I really do not get why this needs so much talk and you cannot learn from their architecture how SoM should be represented. Best regards, Krzysztof
On Thu, Mar 06, 2025 at 01:47:15PM +0530, Wasim Nazir wrote: > On Mon, Mar 03, 2025 at 08:46:55AM +0100, Krzysztof Kozlowski wrote: > > On 27/02/2025 08:37, Wasim Nazir wrote: > > > On Wed, Jan 15, 2025 at 09:35:34AM +0100, Krzysztof Kozlowski wrote: > > >> On 15/01/2025 06:48, Wasim Nazir wrote: > > >>>> The the SoC, I am asking about the board. Why each of them is for > > >>>> example r3? > > >>>> > > >>>> So this is not sufficient explanation, nothing about the board, and > > >>>> again just look Renesas and NXP. > > >>>> > > >>> > > >>> Hi Krzysztof, > > >>> > > >>> sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on > > >>> safety capabilities and memory map, serving different purpose. > > >>> Ride & Ride-r3 are different boards based on ethernet capabilities and > > >>> are compatible with all the SoCs mentioned. > > >> > > > > > > Hi Krzysztof, > > > > > >> Compatible? What does it mean for a board? > > >> > > > > > > Ride board is based on multiple daughter cards (SOC-card, display, > > > camera, ethernet, pcie, sensor, etc.). > > > > > > The SOC is not directly soldered to Ride board, instead SOC is soldered > > > on SIP (System in Package) card which can be mounted on SOC-daughter card of > > > Ride board. > > > - SoC => SIP-card => SOC-daughter-card (Ride) > > > > > > So basically pretty like other designs using SoM. > > > > > > > > Together with SIP cards and other daughter cards we are creating different > > > <soc>-Ride Variants with differences in memory map & thermal mitigations. > > > > > > The SIP card consists of SOC, PMIC & DDR and it is pin compatible to the > > > SOC daughter card of <soc>-Ride board. Only SOC is changing accross SIP > > > cards, except an additional third party SIL-PMIC for SAIL, which is not > > > present in QCS9075 Ride. > > > > Just like every SoM > > > > > > > > Other daughter cards remains same for <soc>-Ride variants, except > > > ethernet card which is different for <soc>-Ride rev3 variants. > > > > > > So the Ride board (combination of daughter cards) is same across the SIP, > > > while SOC on SIP card is changing which can be sa8775p, qcs9100 or qcs9075. > > > > > >> Third time: did you look how other vendors do it? > > >> > > > > > > Yes, we have reviewed other vendors. However, please feel free to share > > > any specific reference you would like us to follow. > > > > > > Here are few reference files we found from other vendors where similar > > > tasks are performed which includes code refactoring and HW modularity: > > > - Freescale: fsl-ls208xa.dtsi, fsl-ls2088a.dtsi, fsl-ls2081a-rdb.dts > > > > That's an unexpected choice - I would rather look at dozen of SoMs for > > iMX platforms. > > > > > - Renesas: white-hawk-common.dtsi, r8a779g0-white-hawk.dts > > > - Rockchip: px30-engicam-common.dtsi, px30-engicam-ctouch2.dtsi, > > > px30-engicam-px30-core-ctouch2.dts > > > > > > In our case along with describing the HW, code refactoring is also done > > > which might be causing confusion, but we are ready for any inputs for > > > correction. > > > > I don't understand why this was not properly described since beginning. > > You had the hardware in your hands and went with incomplete or even > > incorrect hardware description. > > > > > > > > Putting this pictorial diagram for updated DT structure depicting our HW. > > > - qcs9xxx-module.dtsi specifying QCS9xxx based SIP card/module having > > > SoC, PMICs, Memory-map updates. > > > - qcom-ride-common.dtsi specifying ride daughter boards, here we are > > > doing code refactoring also as this is common for all ride boards. > > > - qcom-ride-ethernet-aqr115c.dtso specifying ethernet overlay board which > > > uses 2.5G phy and can be overlayed to ride boards to get ride-r3. > > > By default ride uses 1G phy. > > > - qcs9075-iq-9075-evk.dts is the new name for RB8 as per new product > > > name. We will be changing this in next patch series. > > > > > > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > > > | | > > > | sa8775p.dtsi | > > > | | | > > > | +-------------------------+-----------------------+ | > > > | | | | | > > > | v | v | > > > | qcs9075-module.dtsi | qcs9100-module.dtsi | > > > > So this is the SoM? > > Yes this is SoM. > > > > > > | | | | | > > > | v v v | > > > | (IOT) (AUTO) (IOT) | > > > | | | | | > > > | +----------------------+ | | | > > > | | | | | | > > > | | | +-------------------------+-----------------------+-------------------< qcom-ride-common.dtsi | > > > > Which piece of actual hardware is represented in qcom-ride-common? > > > > All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc. > > > > | | | | | | | | | > > > | v v v v v v v | > > > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > > > | | | | | > > > | | +-------------------------+-----------------------+-------------------< qcom-ride-ethernet-aqr115c.dtso | > > > | | | | | | | | > > > | v v v v v v | > > > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > > > > I think I gave already few times that answer: No. You cannot reference > > from a module.c another .c file. You cannot reference DTS from DTS. > > > > Strictly speaking you can, of course, but you must not. That's not how > > source code is done to be manageable and readable. > > Ah the arrow is leading to confusion. > > Actually we are not including dts here instead *.dtso file will be > overlayed to *-ride.dts to generate *-ride-r3.dts. > > Below is the correct arrow sequence. > > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > | | | | | > | +-------------------------+-----------------------+---------------------< qcom-ride-ethernet-aqr115c.dtso | > | | | | | > | v v v | > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > > > > > > | | > > > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > > > > > >>> > > >>> With the combination of these 3 SoCs and 2 boards, we have 6 platforms, > > >>> all of which we need. > > >>> - sa8775p-ride.dts is auto grade Ride platform with safety feature. > > >>> - qcs9100-ride.dts is IOT grade Ride platform with safety feature. > > >>> - qcs9075-ride.dts is IOT grade Ride platform without safety feature. > > >>> > > >>> Since the Ride-r3 boards are essentially Ride boards with Ethernet > > >>> modifications, we can convert the Ride-r3 DTS to overlays. > > >> How one board can be with multiple SoCs? If it is soldered, it's close > > >> to impossible - that's just not the same board. If it is not soldered, > > >> why you are not explaining it? What is Ride board? What is there? What > > >> can go there? How it can be used in other SoCs? Or for which SoCs? Is > > >> there a datasheet available? > > >> > > > > > > As our SoC is based on SIP card and SIP card is compatible with Ride > > > board, we could able to use same Ride board (which is combination of > > > multiple daughter cards) with multiple SIP cards. > > > These SIP cards can be of sa8775p, qcs9100 or qcs9075 SOC. > > > > Describe properly the hardware - if you have a module or SIP if you > > decide not to use industry-standard naming (but why...), then describe > > it in DTSI. > > We refer to it as ‘module’ in our datasheet, so I use the same term > here. Thanks for pointing it out; we can proceed with the SoM name. > > Below is the updated diagram: > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > | | > | sa8775p.dtsi | > | | | > | +-------------------------+-----------------------+ | > | | | | | > | v | v | > | qcs9075-som.dtsi | qcs9100-som.dtsi | > | | | | | > | v v v | > | (IOT) (AUTO) (IOT) | > | | | | | > | +----------------------+ | | | > | | | | | | > | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi | > | | | | | | | | | > | v v v v v v v | > | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | > | | | | | > | +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso | > | | | | | > | v v v | > | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | > | | > +-----------------------------------------------------------------------------------------------------------------------------------------------+ > Updating typo: qcom-ride-* changed to sa8775p-ride-*. > > > > Best regards, > > Krzysztof > > Thanks & regards, > Wasim
On 06/03/2025 09:25, Wasim Nazir wrote: >> +-----------------------------------------------------------------------------------------------------------------------------------------------+ >> | | >> | sa8775p.dtsi | >> | | | >> | +-------------------------+-----------------------+ | >> | | | | | >> | v | v | >> | qcs9075-som.dtsi | qcs9100-som.dtsi | >> | | | | | >> | v v v | >> | (IOT) (AUTO) (IOT) | >> | | | | | >> | +----------------------+ | | | >> | | | | | | >> | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi | There is no ride-common hardware. If there is, send us any proof of its existence. all your statements here show you want to create some structure because you like it. I don't think you get my questions. You painted diagram of DTS, not hardware. We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here and show us the hardware. I have been asking it for two months now and it is just waste of time to keep talking the same. >> | | | | | | | | | >> | v v v v v v v | >> | qcs9075-iq-9075-evk.dts qcs9075-ride.dts sa8775p-ride.dts qcs9100-ride.dts | >> | | | | | >> | +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso | How does "sa8775p-ride-ethernet-aqr115c" hardware look like? >> | | | | | >> | v v v | >> | qcs9075-ride-r3.dts sa8775p-ride-r3.dts qcs9100-ride-r3.dts | >> | | >> +-----------------------------------------------------------------------------------------------------------------------------------------------+ >> > > Updating typo: qcom-ride-* changed to sa8775p-ride-*. > Best regards, Krzysztof
Hi Krzysztof,
> >>
> >> Which piece of actual hardware is represented in qcom-ride-common?
> >>
> >
> > All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
>
> No, I asked about the name of the hardware, datasheet, ID or picture.
> Common DTSI represents somoething, not just because you wanted to add
> something you had in downstream.
>
Currently we don't have any datasheet or document which is publicly
available, so I will try my best to describe our HW.
Ride is a modular hardware system with several smaller daughter cards
connected to single backplane board and each daughter card is stacked on
top of each other. I will try to explain each daughter card with HW
components and how it is connected to construct the ride-hw.
Backplane board:
- It contains an MCU (Aurix TC397), CAN/LIN transceiver,
Audio/GNSS/IMU-I2C signals, Fan header
- It holds & connects all the daughter cards.
SoC card:
- It contains:
- SoM:
- One of QCS9075M/QCS9100M/QAM8775p SoM.
- Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along
with DDR & PMICs.
- Each SoM can be mounted to same SoC-daughter card of ride-hw.
- In addition to SoM, it also has
- 4x UART, 2x USB 3.1 & 1x USB 2.0
- Memory: 1x OSPI, 2x UFS-3.1
- Debug: JTAG/QDSS header
- PCIe0, PCIe1 & Display signals
- Reset button
- It is connected to backplain board via B2B connector.
Display card:
- It contains:
- 4 eDP ports & 2 DSI-DP bridge
- I2C GPIO expander & I2C switch
- It is connected to SoC-card via B2B connector.
Camera card:
- It contains:
- 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs
- Total upto 16 Cameras ports are supported.
- It is connected to backplain board via B2B connector.
Ethernet card:
- There are two variants of ethernet card each with different
capabilities:
- [Ethernet-v1] card contains:
- 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently)
- Total 4 phy supported, only 2 phy are enabled and it is used in
ride.
- [Ethernet-v2] card contains:
- 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based
MAC+PHY controller
- Total 5 phy supported, only 2 phy are enabled and it is used in
ride-r3.
- Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board
via B2B connector.
PCIe card:
- It contains:
- PCIe connections to SoC-card
- NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) &
GNSS module
- It is connected to backplain board via B2B connector & PCIe signals are
connected to SoC card via flyover cables.
Sensor Card:
- It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which
are communicating via I2C
- It is connected to backplain board via B2B connector.
Front panel card:
- It does not contain any active circuitry, only ports are available
- Audio-in/out ports
- USB hub ports
- CAN/LIN ports
- 12V power off switch
- It is connected to backplain board via ribbon cable.
>
> >
> >> | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi |
>
>
> There is no ride-common hardware. If there is, send us any proof of its
> existence. all your statements here show you want to create some
> structure because you like it. I don't think you get my questions. You
> painted diagram of DTS, not hardware.
>
> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
> and show us the hardware.
>
Considering outlined h/w description, following are ride configuration
variation each platform supporting:
Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing;
And between ride & ride-r3 ethernet is changing.
Excluding these differences all other cards i.e SoC, display, camera, PCIe,
sensor, front & backplain are same and are refactored in ride-common.
If any variant of these cards comes up in future we need to refactor
ride-common accordingly. I will try to outline this as clearly as possible
in next commit log.
Considering current outlines of all daughter cards, following defines
ride/ride-r3 variant boards:
- sa8775p ride : QAM8775p SoM + [Ethernet-v1] + other daughter cards
- sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards
- qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards
- qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards
Since we don't have a document yet which formally describes
qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping
this particular variant in next patch series and re-send after complete
documentation is available.
> > Actually we are not including dts here instead *.dtso file will be
> > overlayed to *-ride.dts to generate *-ride-r3.dts.
> >
> > Below is the correct arrow sequence.
>
> And the overlay represents what exactly? Different board? No, that's not
> how overlays should be used.
>
> You have different board, you have different DTS.
>
No the overlay is not a different ride board. This overlay represents
[Ethernet-v2] card which is different than [Ethernet-v1] card.
We thought of using overlay as otherwise we have to create separate board
DTS to support [Ethernet-v2] cards.
>
> >
> >> | +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso |
>
> How does "sa8775p-ride-ethernet-aqr115c" hardware look like?
>
Here sa8775p-ride-ethernet-aqr115c.dtso is representing [Ethernet-v2] card.
>
> Several companies solved it - most of NXP vendors, many Renesas etc. I
> really do not get why this needs so much talk and you cannot learn from
> their architecture how SoM should be represented.
>
Our SoM is separate HW which is reusable in ride-hw. Can you share more
details on what we can improve here?
Thanks & regards,
Wasim
On 20/03/2025 12:45, Wasim Nazir wrote: > Hi Krzysztof, > >>>> >>>> Which piece of actual hardware is represented in qcom-ride-common? >>>> >>> >>> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc. >> >> No, I asked about the name of the hardware, datasheet, ID or picture. >> Common DTSI represents somoething, not just because you wanted to add >> something you had in downstream. >> > > Currently we don't have any datasheet or document which is publicly > available, so I will try my best to describe our HW. > > Ride is a modular hardware system with several smaller daughter cards > connected to single backplane board and each daughter card is stacked on > top of each other. I will try to explain each daughter card with HW > components and how it is connected to construct the ride-hw. > > Backplane board: > - It contains an MCU (Aurix TC397), CAN/LIN transceiver, > Audio/GNSS/IMU-I2C signals, Fan header > - It holds & connects all the daughter cards. > > SoC card: > - It contains: > - SoM: > - One of QCS9075M/QCS9100M/QAM8775p SoM. > - Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along > with DDR & PMICs. > - Each SoM can be mounted to same SoC-daughter card of ride-hw. > - In addition to SoM, it also has > - 4x UART, 2x USB 3.1 & 1x USB 2.0 > - Memory: 1x OSPI, 2x UFS-3.1 > - Debug: JTAG/QDSS header > - PCIe0, PCIe1 & Display signals > - Reset button > - It is connected to backplain board via B2B connector. > > Display card: > - It contains: > - 4 eDP ports & 2 DSI-DP bridge > - I2C GPIO expander & I2C switch > - It is connected to SoC-card via B2B connector. > > Camera card: > - It contains: > - 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs > - Total upto 16 Cameras ports are supported. > - It is connected to backplain board via B2B connector. > > Ethernet card: > - There are two variants of ethernet card each with different > capabilities: > - [Ethernet-v1] card contains: > - 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently) > - Total 4 phy supported, only 2 phy are enabled and it is used in > ride. > - [Ethernet-v2] card contains: > - 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based > MAC+PHY controller > - Total 5 phy supported, only 2 phy are enabled and it is used in > ride-r3. > - Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board > via B2B connector. > > PCIe card: > - It contains: > - PCIe connections to SoC-card > - NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) & > GNSS module > - It is connected to backplain board via B2B connector & PCIe signals are > connected to SoC card via flyover cables. > > Sensor Card: > - It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which > are communicating via I2C > - It is connected to backplain board via B2B connector. > > Front panel card: > - It does not contain any active circuitry, only ports are available > - Audio-in/out ports > - USB hub ports > - CAN/LIN ports > - 12V power off switch > - It is connected to backplain board via ribbon cable. > >> >>> > >>>> | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi | >> >> >> There is no ride-common hardware. If there is, send us any proof of its >> existence. all your statements here show you want to create some >> structure because you like it. I don't think you get my questions. You >> painted diagram of DTS, not hardware. >> >> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here >> and show us the hardware. >> > > Considering outlined h/w description, following are ride configuration > variation each platform supporting: > > Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing; Define these as SoMs then. > And between ride & ride-r3 ethernet is changing. Different ethernet cards can be also represented as cards - their own DTSI. But there is no soc-card with one or other ethernet, so do not create fake structure just because downstream had it. > Excluding these differences all other cards i.e SoC, display, camera, PCIe, > sensor, front & backplain are same and are refactored in ride-common. > If any variant of these cards comes up in future we need to refactor > ride-common accordingly. I will try to outline this as clearly as possible > in next commit log. > > Considering current outlines of all daughter cards, following defines > ride/ride-r3 variant boards: > - sa8775p ride : QAM8775p SoM + [Ethernet-v1] + other daughter cards > - sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards > - qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards > - qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards > > Since we don't have a document yet which formally describes > qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping > this particular variant in next patch series and re-send after complete > documentation is available. > >>> Actually we are not including dts here instead *.dtso file will be >>> overlayed to *-ride.dts to generate *-ride-r3.dts. >>> >>> Below is the correct arrow sequence. >> >> And the overlay represents what exactly? Different board? No, that's not >> how overlays should be used. >> >> You have different board, you have different DTS. >> > > No the overlay is not a different ride board. This overlay represents > [Ethernet-v2] card which is different than [Ethernet-v1] card. Different cards is not an overlay. Overlay is for added cards, but you replace here the card. Best regards, Krzysztof
On Sat, Mar 29, 2025 at 05:48:00AM +0100, Krzysztof Kozlowski wrote: > On 20/03/2025 12:45, Wasim Nazir wrote: > > Hi Krzysztof, > > > >>>> > >>>> Which piece of actual hardware is represented in qcom-ride-common? > >>>> > >>> > >>> All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc. > >> > >> No, I asked about the name of the hardware, datasheet, ID or picture. > >> Common DTSI represents somoething, not just because you wanted to add > >> something you had in downstream. > >> > > > > Currently we don't have any datasheet or document which is publicly > > available, so I will try my best to describe our HW. > > > > Ride is a modular hardware system with several smaller daughter cards > > connected to single backplane board and each daughter card is stacked on > > top of each other. I will try to explain each daughter card with HW > > components and how it is connected to construct the ride-hw. > > > > Backplane board: > > - It contains an MCU (Aurix TC397), CAN/LIN transceiver, > > Audio/GNSS/IMU-I2C signals, Fan header > > - It holds & connects all the daughter cards. > > > > SoC card: > > - It contains: > > - SoM: > > - One of QCS9075M/QCS9100M/QAM8775p SoM. > > - Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along > > with DDR & PMICs. > > - Each SoM can be mounted to same SoC-daughter card of ride-hw. > > - In addition to SoM, it also has > > - 4x UART, 2x USB 3.1 & 1x USB 2.0 > > - Memory: 1x OSPI, 2x UFS-3.1 > > - Debug: JTAG/QDSS header > > - PCIe0, PCIe1 & Display signals > > - Reset button > > - It is connected to backplain board via B2B connector. > > > > Display card: > > - It contains: > > - 4 eDP ports & 2 DSI-DP bridge > > - I2C GPIO expander & I2C switch > > - It is connected to SoC-card via B2B connector. > > > > Camera card: > > - It contains: > > - 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs > > - Total upto 16 Cameras ports are supported. > > - It is connected to backplain board via B2B connector. > > > > Ethernet card: > > - There are two variants of ethernet card each with different > > capabilities: > > - [Ethernet-v1] card contains: > > - 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently) > > - Total 4 phy supported, only 2 phy are enabled and it is used in > > ride. > > - [Ethernet-v2] card contains: > > - 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based > > MAC+PHY controller > > - Total 5 phy supported, only 2 phy are enabled and it is used in > > ride-r3. > > - Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board > > via B2B connector. > > > > PCIe card: > > - It contains: > > - PCIe connections to SoC-card > > - NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) & > > GNSS module > > - It is connected to backplain board via B2B connector & PCIe signals are > > connected to SoC card via flyover cables. > > > > Sensor Card: > > - It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which > > are communicating via I2C > > - It is connected to backplain board via B2B connector. > > > > Front panel card: > > - It does not contain any active circuitry, only ports are available > > - Audio-in/out ports > > - USB hub ports > > - CAN/LIN ports > > - 12V power off switch > > - It is connected to backplain board via ribbon cable. > > > >> > >>> > > > >>>> | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi | > >> > >> > >> There is no ride-common hardware. If there is, send us any proof of its > >> existence. all your statements here show you want to create some > >> structure because you like it. I don't think you get my questions. You > >> painted diagram of DTS, not hardware. > >> > >> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here > >> and show us the hardware. > >> > > > > Considering outlined h/w description, following are ride configuration > > variation each platform supporting: > > > > Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing; > > Define these as SoMs then. sure > > > And between ride & ride-r3 ethernet is changing. > > Different ethernet cards can be also represented as cards - their own > DTSI. But there is no soc-card with one or other ethernet, so do not > create fake structure just because downstream had it. > Ok, will proceed with dtsi for v1/v2 ethernet cards and use it for ride & ride-r3 respectively. > > > Excluding these differences all other cards i.e SoC, display, camera, PCIe, > > sensor, front & backplain are same and are refactored in ride-common. > > If any variant of these cards comes up in future we need to refactor > > ride-common accordingly. I will try to outline this as clearly as possible > > in next commit log. > > > > Considering current outlines of all daughter cards, following defines > > ride/ride-r3 variant boards: > > - sa8775p ride : QAM8775p SoM + [Ethernet-v1] + other daughter cards > > - sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards > > - qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards > > - qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards > > > > Since we don't have a document yet which formally describes > > qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping > > this particular variant in next patch series and re-send after complete > > documentation is available. > > > >>> Actually we are not including dts here instead *.dtso file will be > >>> overlayed to *-ride.dts to generate *-ride-r3.dts. > >>> > >>> Below is the correct arrow sequence. > >> > >> And the overlay represents what exactly? Different board? No, that's not > >> how overlays should be used. > >> > >> You have different board, you have different DTS. > >> > > > > No the overlay is not a different ride board. This overlay represents > > [Ethernet-v2] card which is different than [Ethernet-v1] card. > > Different cards is not an overlay. Overlay is for added cards, but you > replace here the card. > Understood, will proceed with dtsi way of adding ethernet cards for ride & ride-r3 boards. > > Based on current understanding, here is the final structure for the dts & dtsi, representing all variant of boards. Ethernet cards are represented using dtsi as: - [Ethernet-v1] card: sa8775p-ride-ethernet-88ea1512.dtsi - [Ethernet-v2] card: sa8775p-ride-ethernet-aqr115c.dtsi +-------------------------------------------------------------------------------------------------------------------------------------------------------+ | | | sa8775p.dtsi | | | | | +-------------------------+-----------------------+ | | | | | | | v | v | | qcs9075-som.dtsi qam8775p-som.dtsi qcs9100-som.dtsi | | | | | | | v v v | | (IOT) (AUTO) (IOT) | | | | | | | +-------------------------+ | | | | | | | | | | | | +-------------------------+-----------------------+---------------< sa8775p-ride-ethernet-88ea1512.dtsi | | | | | | | | | | | | | | +-------------------------+-----------------------+----------+--< sa8775p-ride-common.dtsi | | | | | | | | | | | | | | | | | | | +----------+ | | | | | | | | | | | | | | | | | | | | | | v v v v | v v v v v v | | | qcs9075-iq-9075-evk.dts qcs9075-ride.dts | sa8775p-ride.dts qcs9100-ride.dts | | | | | | | | +-----------------------------------------------+ | | | | | | | | +------------------------------------------------< sa8775p-ride-ethernet-aqr115c.dtsi | | | | | | | v v v | | sa8775p-ride-r3.dts | | | +-------------------------------------------------------------------------------------------------------------------------------------------------------+ Please let us know if we can proceed with the change. Thanks & regards, Wasim > Best regards, > Krzysztof
On Thu, Jan 09, 2025 at 08:17:54PM +0530, Wasim Nazir wrote: > On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote: > > On 03/01/2025 20:58, Dmitry Baryshkov wrote: > > >>>>>> Initially, we included the DTS [1] file to avoid duplication. However, > > >>>>>> based on Krzysztof's previous suggestion [2], we change to this format. > > >>>>>> > > >>>>>> Please let us know how to proceed further on this. > > >>>>> > > >>>>> Krzysztof asked you to include DTSI files instead of including DTS > > >>>>> files. Hope this helps. > > >>>> > > >>>> Are you suggesting that we should also modify the 9100-ride files to > > >>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075? > > >>>> However, this would result in the duplication of Ethernet nodes in all > > >>>> the ride board files. Would that be acceptable? > > >>> > > >>> git mv foo.dts foo.dtsi > > >>> echo '#include "foo.dtsi"' > foo.dts > > >>> git add foo.dts > > >>> git commit > > >>> > > >> > > >> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as > > >> they represent different platforms. In patch [1], we included these DTS > > >> files to reuse the common hardware nodes. > > >> > > >> Could you please advise on how we should proceed with the following > > >> approaches? > > >> > > >> a) Previous approach [1]: > > >> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride > > >> platform DTS, similar to the qcs9100-ride platform DTS. This approach > > >> avoids duplicating Ethernet nodes and maintains uniformity. However, it > > >> involves including the DTS file directly. > > >> > > >> b) Current suggestion: > > >> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also > > >> modify the qcs9100-ride platform DTS files to maintain uniformity. This > > >> approach results in duplicating Ethernet nodes. > > >> > > >> Please let us know your recommendation to finalize the DT structure. > > > > > > sa8775p.dtsi > > > `__sa8775p-ride.dtsi > > > `__sa8775p-ride-r2.dtsi > > > `__sa8775p-ride.dts > > > `__qcs9100-ride.dts > > > `__qcs9075-ride.dts > > > `__sa8775p-ride-r3.dtsi > > > `__sa8775p-ride-r3.dts > > > `__qcs9100-ride-r3.dts > > > `__qcs9075-ride-r3.dts > > > > > Wasim and all other copy-pasters of sa8775p-ride, > > > > Just to recap, qcs9100 contributions started this terrible pattern of > > board including a board. Unfortunately qcs9100 was merged, so that ship > > has sailed. > > > > This patchset was going the same way, because poor choices like to keep > > spreading, but at one of previous versions I noticed it and objected. > > > > This v5 however solves above problem by duplicating the nodes. > > > > Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the > > same board, but none of this was communicated. I checked all the commit > > msgs in this patchset and nothing explained about it. What annoys me is > > that you do not communicate your design forcing us to accept poor DTS or > > forcing us to guess and make poor judgments. > > > > Come with proper hardware description and split out shared parts, like > > motherboard. Look how other vendors are doing it, e.g. NXP or Renesas. > > But assuming there are shared parts because I am pretty sure you will > > pick my comments when it suits you without actually following them fully > > and without understanding and explaining to us your own hardware. > > > > Hi Krzysztof, > > Here is the pictorial flow showing how SoCs are derived and what all boards > are supported. > +-----------------------------------------------------------------------+ | | | sa8775p | | | | | +-----------------------+-----------------------+ | | | | | | | v | v | | qcs9100 | qcs9075 | | | | | | | v v v | | (IOT) (AUTO) (IOT) | | qcs9100-ride.dts sa8775p-ride.dts qcs9075-ride.dts | | qcs9100-ride-r3.dts sa8775p-ride-r3.dts qcs9075-ride-r3.dts | | qcs9075-rb8.dts | | | +-----------------------------------------------------------------------+ Updating it as previous one is messed up with whitespaces. > > Although we included details about the QCS9075 and QCS9100 in the cover > letter and commit message, explaining their differences and common > origin from the SA8775P SOC, the new DT structure suggested by Dmitry > should make things clearer. This structure properly splits common parts > and enhances reusability. > > > Best regards, > > Krzysztof > > Thanks & Regards, > Wasim
On 29.12.2024 4:23 PM, Wasim Nazir wrote:
> Add device tree support for QCS9075 Ride & Ride-r3 boards.
>
> QCS9075 lacks the safety monitoring features of Safety-Island (SAIL)
> subsystem which is available in QCS9100, and it affects thermal
> management.
>
> Also, between ride and ride-r3 ethernet phy is different.
> Ride uses 1G ethernet phy while ride-r3 uses 2.5G ethernet phy.
>
> Signed-off-by: Wasim Nazir <quic_wasimn@quicinc.com>
> ---
+ Andrew
IIUC we have a similar case to
https://lore.kernel.org/linux-arm-msm/cbd696c0-3b25-438b-a279-a4263308323a@lunn.ch/
here in the first file changed, please see below and let me know if
the rest makes sense for the networking part
Konrad
> arch/arm64/boot/dts/qcom/Makefile | 2 +
> arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts | 46 ++++++++++++++++++++
> arch/arm64/boot/dts/qcom/qcs9075-ride.dts | 46 ++++++++++++++++++++
> 3 files changed, 94 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-ride.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 78613a1bd34a..41cb2bbd3472 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -118,6 +118,8 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9075-rb8.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += qcs9075-ride-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
> dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> new file mode 100644
> index 000000000000..d9a8956d3a76
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride-r3.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS9075 Ride Rev3";
> + compatible = "qcom,qcs9075-ride-r3", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +ðernet0 {
> + phy-mode = "2500base-x";
> +};
> +
> +ðernet1 {
> + phy-mode = "2500base-x";
> +};
> +
> +&mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sgmii_phy0: phy@8 {
> + compatible = "ethernet-phy-id31c3.1c33";
> + reg = <0x8>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +
> + sgmii_phy1: phy@0 {
> + compatible = "ethernet-phy-id31c3.1c33";
> + reg = <0x0>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/qcs9075-ride.dts b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> new file mode 100644
> index 000000000000..3b524359a72d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs9075-ride.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +/dts-v1/;
> +
> +#include "sa8775p-ride.dtsi"
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. QCS9075 Ride";
> + compatible = "qcom,qcs9075-ride", "qcom,qcs9075", "qcom,sa8775p";
> +};
> +
> +ðernet0 {
> + phy-mode = "sgmii";
> +};
> +
> +ðernet1 {
> + phy-mode = "sgmii";
> +};
> +
> +&mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sgmii_phy0: phy@8 {
> + compatible = "ethernet-phy-id0141.0dd4";
> + reg = <0x8>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +
> + sgmii_phy1: phy@a {
> + compatible = "ethernet-phy-id0141.0dd4";
> + reg = <0xa>;
> + device_type = "ethernet-phy";
> + interrupts-extended = <&tlmm 26 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&pmm8654au_2_gpios 9 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <11000>;
> + reset-deassert-us = <70000>;
> + };
> +};
> --
> 2.47.0
>
> > +ðernet0 {
> > + phy-mode = "2500base-x";
> > +};
> > +
> > +ðernet1 {
> > + phy-mode = "2500base-x";
> > +};
> > +
> > +&mdio {
> > + compatible = "snps,dwmac-mdio";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + sgmii_phy0: phy@8 {
> > + compatible = "ethernet-phy-id31c3.1c33";
> > + reg = <0x8>;
> > + device_type = "ethernet-phy";
> > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <11000>;
> > + reset-deassert-us = <70000>;
> > + };
> > +
> > + sgmii_phy1: phy@0 {
SGMII is 10/100/1000. You have a phy-mode of 2500base-x, which is only
2500. So calling this sgmii_phy is wrong. Just call it phy1: phy@0.
Andrew
On Tue, Dec 31, 2024 at 06:10:15AM +0100, Andrew Lunn wrote:
> > > +ðernet0 {
> > > + phy-mode = "2500base-x";
> > > +};
> > > +
> > > +ðernet1 {
> > > + phy-mode = "2500base-x";
> > > +};
> > > +
> > > +&mdio {
> > > + compatible = "snps,dwmac-mdio";
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > +
> > > + sgmii_phy0: phy@8 {
> > > + compatible = "ethernet-phy-id31c3.1c33";
> > > + reg = <0x8>;
> > > + device_type = "ethernet-phy";
> > > + interrupts-extended = <&tlmm 7 IRQ_TYPE_EDGE_FALLING>;
> > > + reset-gpios = <&pmm8654au_2_gpios 8 GPIO_ACTIVE_LOW>;
> > > + reset-assert-us = <11000>;
> > > + reset-deassert-us = <70000>;
> > > + };
> > > +
> > > + sgmii_phy1: phy@0 {
>
> SGMII is 10/100/1000. You have a phy-mode of 2500base-x, which is only
> 2500. So calling this sgmii_phy is wrong. Just call it phy1: phy@0.
>
Thanks Konrad/Andrew will fix this in next patch.
Regards,
Wasim
© 2016 - 2025 Red Hat, Inc.