* [PATCH v2 1/5] arm64: dts: qcom: sc7280: Fix gmu unit address
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Akhil P Oommen, Andy Gross,
Rob Herring, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125224422.544381-1-dianders@chromium.org>
When processing sc7280 device trees, I can see:
Warning (simple_bus_reg): /soc@0/gmu@3d69000:
simple-bus unit address format error, expected "3d6a000"
There's a clear typo in the node name. Fix it.
Fixes: 96c471970b7b ("arm64: dts: qcom: sc7280: Add gpu support")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
(no changes since v1)
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 937c2e0e93eb..eab7a8505053 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -1790,7 +1790,7 @@ opp-550000000 {
};
};
- gmu: gmu@3d69000 {
+ gmu: gmu@3d6a000 {
compatible="qcom,adreno-gmu-635.0", "qcom,adreno-gmu";
reg = <0 0x03d6a000 0 0x34000>,
<0 0x3de0000 0 0x10000>,
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: qcom: sc7280: Move herobrine-r0 to its own dts
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Andy Gross, Rob Herring,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125224422.544381-1-dianders@chromium.org>
The upcoming herobrine-r1 board is really not very similar to
herobrine-r0. Let's get rid of the "herobrine.dtsi" file and stick all
the content in the -r0 dts file directly. We'll also rename the dts so
it's obvious that it's just for -r0.
While renaming, let's actually name the file so it's obvious that
"herobrine" is both the name of the board and the name of the
"baseboard". In other words "herobrine" is an actual board but also
often used as the name of a whole class of similar boards that forked
from a design. While "herobrine-herobrine" is a bit of mouthful it
makes it more obvious which things are part of an actual board rather
than the baseboard.
NOTE: herobrine-rev0's days are likely doomed and this device tree is
likely to be deleted in the future.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
(no changes since v1)
arch/arm64/boot/dts/qcom/Makefile | 2 +-
...rine.dtsi => sc7280-herobrine-herobrine-r0.dts} | 6 ++++++
arch/arm64/boot/dts/qcom/sc7280-herobrine.dts | 14 --------------
3 files changed, 7 insertions(+), 15 deletions(-)
rename arch/arm64/boot/dts/qcom/{sc7280-herobrine.dtsi => sc7280-herobrine-herobrine-r0.dts} (99%)
delete mode 100644 arch/arm64/boot/dts/qcom/sc7280-herobrine.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index f7232052d286..9db743826391 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -82,7 +82,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-pompom-r3.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-pompom-r3-lte.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-r1.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-r1-lte.dtb
-dtb-$(CONFIG_ARCH_QCOM) += sc7280-herobrine.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sc7280-herobrine-herobrine-r0.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-idp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-idp2.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-crd.dtb
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
similarity index 99%
rename from arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
rename to arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
index 4619fa9fcacd..8676c93590b5 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
@@ -22,6 +22,12 @@
#include "pm8350c.dtsi"
#include "pmk8350.dtsi"
+/ {
+ model = "Google Herobrine (rev0)";
+ compatible = "google,herobrine",
+ "qcom,sc7280";
+};
+
/*
* Reserved memory changes
*
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dts
deleted file mode 100644
index 7a92679a688b..000000000000
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dts
+++ /dev/null
@@ -1,14 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Google Herobrine board device tree source
- *
- * Copyright 2021 Google LLC.
- */
-
-#include "sc7280-herobrine.dtsi"
-
-/ {
- model = "Google Herobrine";
- compatible = "google,herobrine",
- "qcom,sc7280";
-};
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: qcom: sc7280: Factor out Chrome common fragment
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Andy Gross, Rob Herring,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125224422.544381-1-dianders@chromium.org>
This factors out a device tree fragment from some sc7280 device
trees. It represents the device tree bits that should be included for
"Chrome" based sc7280 boards. On these boards the bootloader (Coreboot
+ Depthcharge) configures things slightly different than the
bootloader that Qualcomm provides. The modem firmware on these boards
also works differently than on other Qulacomm products and thus the
reserved memory map needs to be adjusted.
NOTES:
- This is _not_ quite a no-op change. The "herobrine" and "idp"
fragments here were different and it looks like someone simply
forgot to update the herobrine version. This updates a few numbers
to match IDP. This will also cause the `pmk8350_pon` to be disabled
on idp/crd, which I belive is a correct change.
- At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs
will work (how much of the memory map they can reclaim) we may add
an extra fragment that will rejigger one way or the other.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v2:
- memory-region syntax change as per Stephen.
.../boot/dts/qcom/sc7280-chrome-common.dtsi | 97 +++++++++++++++++++
.../qcom/sc7280-herobrine-herobrine-r0.dts | 70 +------------
arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 75 +-------------
3 files changed, 101 insertions(+), 141 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
diff --git a/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
new file mode 100644
index 000000000000..9f4a9c263c35
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7280-chrome-common.dtsi
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * sc7280 fragment for devices with Chrome bootloader
+ *
+ * This file mainly tries to abstract out the memory protections put into
+ * place by the Chrome bootloader which are different than what's put into
+ * place by Qualcomm's typical bootloader. It also has a smattering of other
+ * things that will hold true for any conceivable Chrome design
+ *
+ * Copyright 2022 Google LLC.
+ */
+
+/*
+ * Reserved memory changes
+ *
+ * Delete all unused memory nodes and define the peripheral memory regions
+ * required by the setup for Chrome boards.
+ */
+
+/delete-node/ &hyp_mem;
+/delete-node/ &xbl_mem;
+/delete-node/ &reserved_xbl_uefi_log;
+/delete-node/ &sec_apps_mem;
+
+/ {
+ reserved-memory {
+ adsp_mem: memory@86700000 {
+ reg = <0x0 0x86700000 0x0 0x2800000>;
+ no-map;
+ };
+
+ camera_mem: memory@8ad00000 {
+ reg = <0x0 0x8ad00000 0x0 0x500000>;
+ no-map;
+ };
+
+ venus_mem: memory@8b200000 {
+ reg = <0x0 0x8b200000 0x0 0x500000>;
+ no-map;
+ };
+
+ mpss_mem: memory@8b800000 {
+ reg = <0x0 0x8b800000 0x0 0xf600000>;
+ no-map;
+ };
+
+ wpss_mem: memory@9ae00000 {
+ reg = <0x0 0x9ae00000 0x0 0x1900000>;
+ no-map;
+ };
+
+ mba_mem: memory@9c700000 {
+ reg = <0x0 0x9c700000 0x0 0x200000>;
+ no-map;
+ };
+ };
+};
+
+/* The PMIC PON code isn't compatible w/ how Chrome EC/BIOS handle things. */
+&pmk8350_pon {
+ status = "disabled";
+};
+
+/*
+ * Chrome designs always boot from SPI flash hooked up to the qspi.
+ *
+ * It's expected that all boards will support "dual SPI" at 37.5 MHz.
+ * If some boards need a different speed or have a package that allows
+ * Quad SPI together with WP then those boards can easily override.
+ */
+&qspi {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&qspi_clk>, <&qspi_cs0>, <&qspi_data01>;
+
+ spi_flash: flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+
+ spi-max-frequency = <37500000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+};
+
+/* Modem setup is different on Chrome setups than typical Qualcomm setup */
+&remoteproc_mpss {
+ status = "okay";
+ compatible = "qcom,sc7280-mss-pil";
+ iommus = <&apps_smmu 0x124 0x0>, <&apps_smmu 0x488 0x7>;
+ memory-region = <&mba_mem>, <&mpss_mem>;
+};
+
+/* Increase the size from 2.5MB to 8MB */
+&rmtfs_mem {
+ reg = <0x0 0x9c900000 0x0 0x800000>;
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
index 8676c93590b5..67680a13c234 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
@@ -22,62 +22,15 @@
#include "pm8350c.dtsi"
#include "pmk8350.dtsi"
+#include "sc7280-chrome-common.dtsi"
+
/ {
model = "Google Herobrine (rev0)";
compatible = "google,herobrine",
"qcom,sc7280";
};
-/*
- * Reserved memory changes
- *
- * Delete all unused memory nodes and define the peripheral memory regions
- * required by the board dts.
- *
- */
-
-/delete-node/ &hyp_mem;
-/delete-node/ &xbl_mem;
-/delete-node/ &sec_apps_mem;
-
-/* Increase the size from 2MB to 8MB */
-&rmtfs_mem {
- reg = <0x0 0x83600000 0x0 0x800000>;
-};
-
/ {
- reserved-memory {
- adsp_mem: memory@86700000 {
- reg = <0x0 0x86700000 0x0 0x2800000>;
- no-map;
- };
-
- camera_mem: memory@8ad00000 {
- reg = <0x0 0x8ad00000 0x0 0x500000>;
- no-map;
- };
-
- venus_mem: memory@8b200000 {
- reg = <0x0 0x8b200000 0x0 0x500000>;
- no-map;
- };
-
- mpss_mem: memory@8b800000 {
- reg = <0x0 0x8b800000 0x0 0xf600000>;
- no-map;
- };
-
- wpss_mem: memory@9ae00000 {
- reg = <0x0 0x9ae00000 0x0 0x1900000>;
- no-map;
- };
-
- mba_mem: memory@9c700000 {
- reg = <0x0 0x9c700000 0x0 0x200000>;
- no-map;
- };
- };
-
aliases {
serial0 = &uart5;
serial1 = &uart7;
@@ -691,10 +644,6 @@ &pmk8350_gpios {
status = "disabled"; /* No GPIOs are connected */
};
-&pmk8350_pon {
- status = "disabled";
-};
-
&pmk8350_rtc {
status = "disabled";
};
@@ -717,21 +666,6 @@ &qfprom {
vcc-supply = <&vdd_qfprom>;
};
-&qspi {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&qspi_clk>, <&qspi_cs0>, <&qspi_data01>;
-
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
-
- spi-max-frequency = <37500000>;
- spi-tx-bus-width = <2>;
- spi-rx-bus-width = <2>;
- };
-};
-
&qupv3_id_0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
index d623d71d8bd4..98c8f39ce459 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
@@ -13,6 +13,8 @@
#include "pm8350c.dtsi"
#include "pmk8350.dtsi"
+#include "sc7280-chrome-common.dtsi"
+
/ {
gpio-keys {
compatible = "gpio-keys";
@@ -45,58 +47,6 @@ nvme_3v3_regulator: nvme-3v3-regulator {
};
};
-/*
- * Reserved memory changes
- *
- * Delete all unused memory nodes and define the peripheral memory regions
- * required by the board dts.
- *
- */
-
-/delete-node/ &hyp_mem;
-/delete-node/ &xbl_mem;
-/delete-node/ &reserved_xbl_uefi_log;
-/delete-node/ &sec_apps_mem;
-
-/* Increase the size from 2.5MB to 8MB */
-&rmtfs_mem {
- reg = <0x0 0x9c900000 0x0 0x800000>;
-};
-
-/ {
- reserved-memory {
- adsp_mem: memory@86700000 {
- reg = <0x0 0x86700000 0x0 0x2800000>;
- no-map;
- };
-
- camera_mem: memory@8ad00000 {
- reg = <0x0 0x8ad00000 0x0 0x500000>;
- no-map;
- };
-
- venus_mem: memory@8b200000 {
- reg = <0x0 0x8b200000 0x0 0x500000>;
- no-map;
- };
-
- mpss_mem: memory@8b800000 {
- reg = <0x0 0x8b800000 0x0 0xf600000>;
- no-map;
- };
-
- wpss_mem: memory@9ae00000 {
- reg = <0x0 0x9ae00000 0x0 0x1900000>;
- no-map;
- };
-
- mba_mem: memory@9c700000 {
- reg = <0x0 0x9c700000 0x0 0x200000>;
- no-map;
- };
- };
-};
-
&apps_rsc {
pm7325-regulators {
compatible = "qcom,pm7325-rpmh-regulators";
@@ -313,20 +263,6 @@ &qfprom {
vcc-supply = <&vreg_l1c_1p8>;
};
-&qspi {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&qspi_clk>, <&qspi_cs0>, <&qspi_data01>;
-
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <37500000>;
- spi-tx-bus-width = <2>;
- spi-rx-bus-width = <2>;
- };
-};
-
&qupv3_id_0 {
status = "okay";
};
@@ -335,13 +271,6 @@ &qupv3_id_1 {
status = "okay";
};
-&remoteproc_mpss {
- status = "okay";
- compatible = "qcom,sc7280-mss-pil";
- iommus = <&apps_smmu 0x124 0x0>, <&apps_smmu 0x488 0x7>;
- memory-region = <&mba_mem &mpss_mem>;
-};
-
&sdhc_1 {
status = "okay";
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: qcom: sc7280: Factor gpio.h include to sc7280.dtsi
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Andy Gross, Rob Herring,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125224422.544381-1-dianders@chromium.org>
Though sc7280 itself doesn't need any of the defines in gpio.h, it's
highly likely that the actual boards will use them. Let's add the
include to the sc7280.dtsi file so that boards don't need to do it.
Suggested-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- ("Factor gpio.h include to sc7280.dtsi") new for v2
arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts | 1 -
arch/arm64/boot/dts/qcom/sc7280-idp.dtsi | 1 -
arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 +
3 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
index 67680a13c234..ad4fe288b53c 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
@@ -7,7 +7,6 @@
/dts-v1/;
-#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
#include <dt-bindings/iio/qcom,spmi-adc7-pmr735a.h>
#include <dt-bindings/input/gpio-keys.h>
diff --git a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
index 98c8f39ce459..ec9836f4019e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-idp.dtsi
@@ -5,7 +5,6 @@
* Copyright (c) 2021, The Linux Foundation. All rights reserved.
*/
-#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
#include <dt-bindings/input/linux-event-codes.h>
#include "sc7280.dtsi"
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index eab7a8505053..02aff23d025e 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -10,6 +10,7 @@
#include <dt-bindings/clock/qcom,gpucc-sc7280.h>
#include <dt-bindings/clock/qcom,rpmh.h>
#include <dt-bindings/clock/qcom,videocc-sc7280.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interconnect/qcom,sc7280.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/mailbox/qcom-ipcc.h>
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1
From: Douglas Anderson @ 2022-01-25 22:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: konrad.dybcio, swboyd, kgodara, mka, sibis, pmaliset,
quic_rjendra, Douglas Anderson, Andy Gross, Rob Herring,
devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125224422.544381-1-dianders@chromium.org>
Add the new herobrine-r1. Note that this is pretty much a re-design
compared to herobrine-r0 so we don't attempt any dtsi to share stuff
between them.
This patch attempts to define things at 3 levels:
1. The Qcard level. Herobrine includes a Qcard PCB and the Qcard PCB
is supposed to be the same (modulo stuffing options) across
multiple boards, so trying to define what's there hopefully makes
sense. NOTE that newer "CRD" boards from Qualcomm also use
Qcard. When support for CRD3 is added hopefully it can use the
Qcard include (and perhaps we should even evaluate it using
herobrine.dtsi?)
2. The herobrine "baseboard" level. Right now most stuff is here with
the exception of things that we _know_ will be different per
board. We know that not all boards will have the same set of eMMC,
nvme, and SD. We also know that the exact pin names are likely to
be different.
3. The actual "board" level, AKA herobrine-rev1.
NOTES:
- This boots to command prompt, but no eDP yet since eDP hasn't
been added to sc7280.dtsi yet.
- This assumes LTE for now. Once it's clear how WiFi-only SKUs will
work we expect some small changes.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
---
Changes in v2:
- Herobrine compatible on one line, not two
- Wording change in comments for components enabled per-board
- Always sort "bias" above "drive-strength" in pinctrl.
- Properly sort "hub_en" pinctrl.
- Two comments moved from multiline to single line.
- Space after "/delete-property/"
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../qcom/sc7280-herobrine-herobrine-r0.dts | 3 +-
.../qcom/sc7280-herobrine-herobrine-r1.dts | 313 +++++++
.../arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 778 ++++++++++++++++++
arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi | 553 +++++++++++++
5 files changed, 1646 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 9db743826391..54998e108092 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -83,6 +83,7 @@ dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-pompom-r3-lte.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-r1.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7180-trogdor-r1-lte.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-herobrine-herobrine-r0.dtb
+dtb-$(CONFIG_ARCH_QCOM) += sc7280-herobrine-herobrine-r1.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-idp.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-idp2.dtb
dtb-$(CONFIG_ARCH_QCOM) += sc7280-crd.dtb
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
index ad4fe288b53c..e19eea1cb69a 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dts
@@ -25,8 +25,7 @@
/ {
model = "Google Herobrine (rev0)";
- compatible = "google,herobrine",
- "qcom,sc7280";
+ compatible = "google,herobrine-rev0", "qcom,sc7280";
};
/ {
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
new file mode 100644
index 000000000000..f95273052da0
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
@@ -0,0 +1,313 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Herobrine board device tree source
+ *
+ * Copyright 2022 Google LLC.
+ */
+
+/dts-v1/;
+
+#include "sc7280-herobrine.dtsi"
+
+/ {
+ model = "Google Herobrine (rev1+)";
+ compatible = "google,herobrine", "qcom,sc7280";
+};
+
+/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
+
+&ap_spi_fp {
+ status = "okay";
+};
+
+/*
+ * Although the trackpad is really part of the herobrine baseboard, we'll
+ * put the actual definition in the board device tree since different boards
+ * might hook up different trackpads (or no i2c trackpad at all in the case
+ * of tablets / detachables).
+ */
+ap_tp_i2c: &i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ trackpad: trackpad@15 {
+ compatible = "elan,ekth3000";
+ reg = <0x15>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&tp_int_odl>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+
+ vcc-supply = <&pp3300_z1>;
+
+ wakeup-source;
+ };
+};
+
+/*
+ * The touchscreen connector might come off the Qcard, at least in the case of
+ * eDP. Like the trackpad, we'll put it in the board device tree file since
+ * different boards have different touchscreens.
+ */
+ts_i2c: &i2c13 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ ap_ts: touchscreen@5c {
+ compatible = "hid-over-i2c";
+ reg = <0x5c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_int_conn>, <&ts_rst_conn>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <55 IRQ_TYPE_LEVEL_LOW>;
+
+ post-power-on-delay-ms = <500>;
+ hid-descr-addr = <0x0000>;
+
+ vdd-supply = <&ts_avdd>;
+ };
+};
+
+/* For nvme */
+&pcie1 {
+ status = "okay";
+};
+
+/* For nvme */
+&pcie1_phy {
+ status = "okay";
+};
+
+/* For eMMC */
+&sdhc_1 {
+ status = "okay";
+};
+
+/* For SD Card */
+&sdhc_2 {
+ status = "okay";
+};
+
+/* PINCTRL - BOARD-SPECIFIC */
+
+/*
+ * Methodology for gpio-line-names:
+ * - If a pin goes to herobrine board and is named it gets that name.
+ * - If a pin goes to herobrine board and is not named, it gets no name.
+ * - If a pin is totally internal to Qcard then it gets Qcard name.
+ * - If a pin is not hooked up on Qcard, it gets no name.
+ */
+
+&pm8350c_gpios {
+ gpio-line-names = "FLASH_STROBE_1", /* 1 */
+ "AP_SUSPEND",
+ "PM8008_1_RST_N",
+ "",
+ "",
+ "",
+ "PMIC_EDP_BL_EN",
+ "PMIC_EDP_BL_PWM",
+ "";
+};
+
+&tlmm {
+ gpio-line-names = "AP_TP_I2C_SDA", /* 0 */
+ "AP_TP_I2C_SCL",
+ "SSD_RST_L",
+ "PE_WAKE_ODL",
+ "AP_SAR_SDA",
+ "AP_SAR_SCL",
+ "PRB_SC_GPIO_6",
+ "TP_INT_ODL",
+ "HP_I2C_SDA",
+ "HP_I2C_SCL",
+
+ "GNSS_L1_EN", /* 10 */
+ "GNSS_L5_EN",
+ "SPI_AP_MOSI",
+ "SPI_AP_MISO",
+ "SPI_AP_CLK",
+ "SPI_AP_CS0_L",
+ /*
+ * AP_FLASH_WP is crossystem ABI. Schematics
+ * call it BIOS_FLASH_WP_OD.
+ */
+ "AP_FLASH_WP",
+ "",
+ "AP_EC_INT_L",
+ "",
+
+ "UF_CAM_RST_L", /* 20 */
+ "WF_CAM_RST_L",
+ "UART_AP_TX_DBG_RX",
+ "UART_DBG_TX_AP_RX",
+ "",
+ "PM8008_IRQ_1",
+ "HOST2WLAN_SOL",
+ "WLAN2HOST_SOL",
+ "MOS_BT_UART_CTS",
+ "MOS_BT_UART_RFR",
+
+ "MOS_BT_UART_TX", /* 30 */
+ "MOS_BT_UART_RX",
+ "PRB_SC_GPIO_32",
+ "HUB_RST_L",
+ "",
+ "",
+ "AP_SPI_FP_MISO",
+ "AP_SPI_FP_MOSI",
+ "AP_SPI_FP_CLK",
+ "AP_SPI_FP_CS_L",
+
+ "AP_EC_SPI_MISO", /* 40 */
+ "AP_EC_SPI_MOSI",
+ "AP_EC_SPI_CLK",
+ "AP_EC_SPI_CS_L",
+ "LCM_RST_L",
+ "EARLY_EUD_N",
+ "",
+ "DP_HOT_PLUG_DET",
+ "IO_BRD_MLB_ID0",
+ "IO_BRD_MLB_ID1",
+
+ "IO_BRD_MLB_ID2", /* 50 */
+ "SSD_EN",
+ "TS_I2C_SDA_CONN",
+ "TS_I2C_CLK_CONN",
+ "TS_RST_CONN",
+ "TS_INT_CONN",
+ "AP_I2C_TPM_SDA",
+ "AP_I2C_TPM_SCL",
+ "PRB_SC_GPIO_58",
+ "PRB_SC_GPIO_59",
+
+ "EDP_HOT_PLUG_DET_N", /* 60 */
+ "FP_TO_AP_IRQ_L",
+ "",
+ "AMP_EN",
+ "CAM0_MCLK_GPIO_64",
+ "CAM1_MCLK_GPIO_65",
+ "WF_CAM_MCLK",
+ "PRB_SC_GPIO_67",
+ "FPMCU_BOOT0",
+ "UF_CAM_SDA",
+
+ "UF_CAM_SCL", /* 70 */
+ "",
+ "",
+ "WF_CAM_SDA",
+ "WF_CAM_SCL",
+ "",
+ "",
+ "EN_FP_RAILS",
+ "FP_RST_L",
+ "PCIE1_CLKREQ_ODL",
+
+ "EN_PP3300_DX_EDP", /* 80 */
+ "SC_GPIO_81",
+ "FORCED_USB_BOOT",
+ "WCD_RESET_N",
+ "MOS_WLAN_EN",
+ "MOS_BT_EN",
+ "MOS_SW_CTRL",
+ "MOS_PCIE0_RST",
+ "MOS_PCIE0_CLKREQ_N",
+ "MOS_PCIE0_WAKE_N",
+
+ "MOS_LAA_AS_EN", /* 90 */
+ "SD_CD_ODL",
+ "",
+ "",
+ "MOS_BT_WLAN_SLIMBUS_CLK",
+ "MOS_BT_WLAN_SLIMBUS_DAT0",
+ "HP_MCLK",
+ "HP_BCLK",
+ "HP_DOUT",
+ "HP_DIN",
+
+ "HP_LRCLK", /* 100 */
+ "HP_IRQ",
+ "",
+ "",
+ "GSC_AP_INT_ODL",
+ "EN_PP3300_CODEC",
+ "AMP_BCLK",
+ "AMP_DIN",
+ "AMP_LRCLK",
+ "UIM1_DATA_GPIO_109",
+
+ "UIM1_CLK_GPIO_110", /* 110 */
+ "UIM1_RESET_GPIO_111",
+ "PRB_SC_GPIO_112",
+ "UIM0_DATA",
+ "UIM0_CLK",
+ "UIM0_RST",
+ "UIM0_PRESENT_ODL",
+ "SDM_RFFE0_CLK",
+ "SDM_RFFE0_DATA",
+ "WF_CAM_EN",
+
+ "FASTBOOT_SEL_0", /* 120 */
+ "SC_GPIO_121",
+ "FASTBOOT_SEL_1",
+ "SC_GPIO_123",
+ "FASTBOOT_SEL_2",
+ "SM_RFFE4_CLK_GRFC_8",
+ "SM_RFFE4_DATA_GRFC_9",
+ "WLAN_COEX_UART1_RX",
+ "WLAN_COEX_UART1_TX",
+ "PRB_SC_GPIO_129",
+
+ "LCM_ID0", /* 130 */
+ "LCM_ID1",
+ "",
+ "SDR_QLINK_REQ",
+ "SDR_QLINK_EN",
+ "QLINK0_WMSS_RESET_N",
+ "SMR526_QLINK1_REQ",
+ "SMR526_QLINK1_EN",
+ "SMR526_QLINK1_WMSS_RESET_N",
+ "PRB_SC_GPIO_139",
+
+ "SAR1_IRQ_ODL", /* 140 */
+ "SAR0_IRQ_ODL",
+ "PRB_SC_GPIO_142",
+ "",
+ "WCD_SWR_TX_CLK",
+ "WCD_SWR_TX_DATA0",
+ "WCD_SWR_TX_DATA1",
+ "WCD_SWR_RX_CLK",
+ "WCD_SWR_RX_DATA0",
+ "WCD_SWR_RX_DATA1",
+
+ "DMIC01_CLK", /* 150 */
+ "DMIC01_DATA",
+ "DMIC23_CLK",
+ "DMIC23_DATA",
+ "",
+ "",
+ "EC_IN_RW_ODL",
+ "HUB_EN",
+ "WCD_SWR_TX_DATA2",
+ "",
+
+ "", /* 160 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+
+ "", /* 170 */
+ "MOS_BLE_UART_TX",
+ "MOS_BLE_UART_RX",
+ "",
+ "",
+ "";
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
new file mode 100644
index 000000000000..24c34ddebd18
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -0,0 +1,778 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Google Herobrine baseboard device tree source
+ *
+ * The set of things in this file is a bit loosely defined. It's roughly
+ * defined as the set of things that the child boards happen to have in
+ * common. Since all of the child boards started from the same original
+ * design this is hopefully a large set of things but as more derivatives
+ * appear things may "bubble down" out of this file. For things that are
+ * part of the reference design but might not exist on child nodes we will
+ * follow the lead of the SoC dtsi files and leave their status as "disabled".
+ *
+ * Copyright 2022 Google LLC.
+ */
+
+#include <dt-bindings/input/gpio-keys.h>
+#include <dt-bindings/input/input.h>
+
+#include "sc7280-qcard.dtsi"
+#include "sc7280-chrome-common.dtsi"
+
+/ {
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ /*
+ * FIXED REGULATORS
+ *
+ * Sort order:
+ * 1. parents above children.
+ * 2. higher voltage above lower voltage.
+ * 3. alphabetically by node name.
+ */
+
+ /* This is the top level supply and variable voltage */
+ ppvar_sys: ppvar-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "ppvar_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /* This divides ppvar_sys by 2, so voltage is variable */
+ src_vph_pwr: src-vph-pwr-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "src_vph_pwr";
+
+ /* EC turns on with switchcap_on; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ pp5000_s5: pp5000-s5-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp5000_s5";
+
+ /* EC turns on with en_pp5000_s5; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ pp3300_z1: pp3300-z1-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_z1";
+
+ /* EC turns on with en_pp3300_z1; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ vin-supply = <&ppvar_sys>;
+ };
+
+ pp3300_codec: pp3300-codec-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_codec";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 105 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&en_pp3300_codec>;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp3300_left_in_mlb: pp3300-left-in-mlb {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_left_in_mlb";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&en_pp3300_dx_edp>;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp3300_mcu_fp:
+ pp3300_fp_ls:
+ pp3300_fp_mcu: pp3300-fp-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_fp";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-boot-on;
+ regulator-always-on;
+
+ /*
+ * WARNING: it is intentional that GPIO 77 isn't listed here.
+ * The userspace script for updating the fingerprint firmware
+ * needs to control the FP regulators during a FW update,
+ * hence the signal can't be owned by the kernel regulator.
+ */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&en_fp_rails>;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp3300_hub: pp3300-hub-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_hub";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-boot-on;
+ regulator-always-on;
+
+ gpio = <&tlmm 157 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hub_en>;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp3300_tp: pp3300-tp-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_tp";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ /* AP turns on with PP1800_L18B_S0; always on for AP */
+ regulator-always-on;
+ regulator-boot-on;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp3300_ssd: pp3300-ssd {
+ compatible = "regulator-fixed";
+ regulator-name = "pp3300_ssd";
+
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ssd_en>;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp2850_vcm_wf_cam: pp2850-vcm-wf-cam {
+ compatible = "regulator-fixed";
+ regulator-name = "pp2850_vcm_wf_cam";
+
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+
+ gpio = <&tlmm 119 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wf_cam_en>;
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp2850_wf_cam: pp2850-wf-cam {
+ compatible = "regulator-fixed";
+ regulator-name = "pp2850_wf_cam";
+
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+
+ gpio = <&tlmm 119 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * The pinconf can only be referenced once so we put it on the
+ * first regulator and comment it out here.
+ *
+ * pinctrl-names = "default";
+ * pinctrl-0 = <&wf_cam_en>;
+ */
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ pp1800_fp: pp1800-fp-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1800_fp";
+
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-boot-on;
+ regulator-always-on;
+
+ /*
+ * WARNING: it is intentional that GPIO 77 isn't listed here.
+ * The userspace script for updating the fingerprint firmware
+ * needs to control the FP regulators during a FW update,
+ * hence the signal can't be owned by the kernel regulator.
+ */
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&en_fp_rails>;
+
+ vin-supply = <&pp1800_l18b_s0>;
+ status = "disabled";
+ };
+
+ pp1800_wf_cam: pp1800-wf-cam {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1800_wf_cam";
+
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ gpio = <&tlmm 119 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * The pinconf can only be referenced once so we put it on the
+ * first regulator and comment it out here.
+ *
+ * pinctrl-names = "default";
+ * pinctrl-0 = <&wf_cam_en>;
+ */
+
+ vin-supply = <&vreg_l19b_s0>;
+ };
+
+ pp1200_wf_cam: pp1200-wf-cam {
+ compatible = "regulator-fixed";
+ regulator-name = "pp1200_wf_cam";
+
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+
+ gpio = <&tlmm 119 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * The pinconf can only be referenced once so we put it on the
+ * first regulator and comment it out here.
+ *
+ * pinctrl-names = "default";
+ * pinctrl-0 = <&wf_cam_en>;
+ */
+
+ vin-supply = <&pp3300_z1>;
+ };
+
+ /* BOARD-SPECIFIC TOP LEVEL NODES */
+
+ pwmleds {
+ compatible = "pwm-leds";
+ status = "disabled";
+ keyboard_backlight: keyboard-backlight {
+ status = "disabled";
+ label = "cros_ec::kbd_backlight";
+ pwms = <&cros_ec_pwm 0>;
+ max-brightness = <1023>;
+ };
+ };
+};
+
+/*
+ * BOARD-LOCAL NAMES FOR REGULATORS THAT CONNECT TO QCARD
+ *
+ * Names are only listed here if regulators go somewhere other than a
+ * testpoint.
+ */
+
+/* From Qcard to our board; ordered by PMIC-ID / rail number */
+
+pp1256_s8b: &vreg_s8b_1p256 {};
+
+pp1800_l18b_s0: &vreg_l18b_1p8 {};
+pp1800_l18b: &vreg_l18b_1p8 {};
+
+vreg_l19b_s0: &vreg_l19b_1p8 {};
+
+pp1800_alc5682: &vreg_l2c_1p8 {};
+pp1800_l2c: &vreg_l2c_1p8 {};
+
+vreg_l4c: &vreg_l4c_1p8_3p0 {};
+
+ppvar_l6c: &vreg_l6c_2p96 {};
+
+pp3000_l7c: &vreg_l7c_3p0 {};
+
+pp1800_prox: &vreg_l8c_1p8 {};
+pp1800_l8c: &vreg_l8c_1p8 {};
+
+pp2950_l9c: &vreg_l9c_2p96 {};
+
+pp1800_lcm: &vreg_l12c_1p8 {};
+pp1800_mipi: &vreg_l12c_1p8 {};
+pp1800_l12c: &vreg_l12c_1p8 {};
+
+pp3300_lcm: &vreg_l13c_3p0 {};
+pp3300_mipi: &vreg_l13c_3p0 {};
+pp3300_l13c: &vreg_l13c_3p0 {};
+
+/* From our board to Qcard; ordered same as node definition above */
+
+vreg_edp_bl: &ppvar_sys {};
+
+ts_avdd: &pp3300_left_in_mlb {};
+vreg_edp_3p3: &pp3300_left_in_mlb {};
+
+/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
+
+ap_i2c_tpm: &i2c14 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ tpm@50 {
+ compatible = "google,cr50";
+ reg = <0x50>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&gsc_ap_int_odl>;
+
+ interrupt-parent = <&tlmm>;
+ interrupts = <104 IRQ_TYPE_EDGE_RISING>;
+ };
+};
+
+/* NVMe drive, enabled on a per-board basis */
+&pcie1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie1_clkreq_n>, <&ssd_rst_l>, <&pe_wake_odl>;
+
+ perst-gpio = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ vddpe-3v3-supply = <&pp3300_ssd>;
+};
+
+&pmk8350_rtc {
+ status = "disabled";
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+/* SD Card, enabled on a per-board basis */
+&sdhc_2 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&sdc2_on>;
+ pinctrl-1 = <&sdc2_off>;
+
+ vmmc-supply = <&pp2950_l9c>;
+ vqmmc-supply = <&ppvar_l6c>;
+
+ cd-gpios = <&tlmm 91 GPIO_ACTIVE_LOW>;
+};
+
+/* Fingerprint, enabled on a per-board basis */
+ap_spi_fp: &spi9 {
+ pinctrl-0 = <&qup_spi9_data_clk>, <&qup_spi9_cs_gpio_init_high>, <&qup_spi9_cs_gpio>;
+
+ cs-gpios = <&tlmm 39 GPIO_ACTIVE_LOW>;
+
+ cros_ec_fp: ec@0 {
+ compatible = "google,cros-ec-spi";
+ reg = <0>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <61 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fp_to_ap_irq_l>, <&fp_rst_l>, <&fpmcu_boot0>;
+ spi-max-frequency = <3000000>;
+ };
+};
+
+ap_ec_spi: &spi10 {
+ status = "okay";
+ pinctrl-0 = <&qup_spi10_data_clk>, <&qup_spi10_cs_gpio_init_high>, <&qup_spi10_cs_gpio>;
+
+ cs-gpios = <&tlmm 43 GPIO_ACTIVE_LOW>;
+
+ cros_ec: ec@0 {
+ compatible = "google,cros-ec-spi";
+ reg = <0>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <18 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ap_ec_int_l>;
+ spi-max-frequency = <3000000>;
+
+ cros_ec_pwm: ec-pwm {
+ compatible = "google,cros-ec-pwm";
+ #pwm-cells = <1>;
+ };
+
+ i2c_tunnel: i2c-tunnel {
+ compatible = "google,cros-ec-i2c-tunnel";
+ google,remote-bus = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ typec {
+ compatible = "google,cros-ec-typec";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb_c0: connector@0 {
+ compatible = "usb-c-connector";
+ reg = <0>;
+ label = "left";
+ power-role = "dual";
+ data-role = "host";
+ try-power-role = "source";
+ };
+
+ usb_c1: connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ label = "right";
+ power-role = "dual";
+ data-role = "host";
+ try-power-role = "source";
+ };
+ };
+ };
+};
+
+#include <arm/cros-ec-keyboard.dtsi>
+#include <arm/cros-ec-sbs.dtsi>
+
+&keyboard_controller {
+ function-row-physmap = <
+ MATRIX_KEY(0x00, 0x02, 0) /* T1 */
+ MATRIX_KEY(0x03, 0x02, 0) /* T2 */
+ MATRIX_KEY(0x02, 0x02, 0) /* T3 */
+ MATRIX_KEY(0x01, 0x02, 0) /* T4 */
+ MATRIX_KEY(0x03, 0x04, 0) /* T5 */
+ MATRIX_KEY(0x02, 0x04, 0) /* T6 */
+ MATRIX_KEY(0x01, 0x04, 0) /* T7 */
+ MATRIX_KEY(0x02, 0x09, 0) /* T8 */
+ MATRIX_KEY(0x01, 0x09, 0) /* T9 */
+ MATRIX_KEY(0x00, 0x04, 0) /* T10 */
+ >;
+ linux,keymap = <
+ MATRIX_KEY(0x00, 0x02, KEY_BACK)
+ MATRIX_KEY(0x03, 0x02, KEY_REFRESH)
+ MATRIX_KEY(0x02, 0x02, KEY_ZOOM)
+ MATRIX_KEY(0x01, 0x02, KEY_SCALE)
+ MATRIX_KEY(0x03, 0x04, KEY_SYSRQ)
+ MATRIX_KEY(0x02, 0x04, KEY_BRIGHTNESSDOWN)
+ MATRIX_KEY(0x01, 0x04, KEY_BRIGHTNESSUP)
+ MATRIX_KEY(0x02, 0x09, KEY_MUTE)
+ MATRIX_KEY(0x01, 0x09, KEY_VOLUMEDOWN)
+ MATRIX_KEY(0x00, 0x04, KEY_VOLUMEUP)
+
+ CROS_STD_MAIN_KEYMAP
+ >;
+};
+
+&usb_1 {
+ status = "okay";
+};
+
+&usb_1_dwc3 {
+ dr_mode = "host";
+};
+
+&usb_1_hsphy {
+ status = "okay";
+};
+
+&usb_1_qmpphy {
+ status = "okay";
+};
+
+&usb_2 {
+ status = "okay";
+};
+
+&usb_2_dwc3 {
+ dr_mode = "host";
+};
+
+&usb_2_hsphy {
+ status = "okay";
+};
+
+/* PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES */
+
+&qspi_cs0 {
+ bias-disable;
+ drive-strength = <8>;
+};
+
+&qspi_clk {
+ bias-disable;
+ drive-strength = <8>;
+};
+
+&qspi_data01 {
+ /* High-Z when no transfers; nice to park the lines */
+ bias-pull-up;
+ drive-strength = <8>;
+};
+
+/* For ap_tp_i2c */
+&qup_i2c0_data_clk {
+ /* Has external pull */
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For ap_i2c_tpm */
+&qup_i2c14_data_clk {
+ /* Has external pull */
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For ap_spi_fp */
+&qup_spi9_data_clk {
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For ap_spi_fp */
+&qup_spi9_cs_gpio {
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For ap_ec_spi */
+&qup_spi10_data_clk {
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For ap_ec_spi */
+&qup_spi10_cs_gpio {
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For uart_dbg */
+&qup_uart5_rx {
+ bias-pull-up;
+};
+
+/* For uart_dbg */
+&qup_uart5_tx {
+ bias-disable;
+ drive-strength = <2>;
+};
+
+&sdc2_on {
+ clk {
+ bias-disable;
+ drive-strength = <16>;
+ };
+
+ cmd {
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ data {
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ sd-cd {
+ pins = "gpio91";
+ bias-pull-up;
+ };
+};
+
+/* PINCTRL - board-specific pinctrl */
+
+&pm7325_gpios {
+ /*
+ * On a quick glance it might look like KYPD_VOL_UP_N is used, but
+ * that only passes through to a debug connector and not to the actual
+ * volume up key.
+ */
+ status = "disabled"; /* No GPIOs are connected */
+};
+
+&pmk8350_gpios {
+ status = "disabled"; /* No GPIOs are connected */
+};
+
+&tlmm {
+ /* pinctrl settings for pins that have no real owners. */
+ pinctrl-names = "default";
+ pinctrl-0 = <&bios_flash_wp_od>;
+
+ amp_en: amp-en {
+ pins = "gpio63";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ ap_ec_int_l: ap-ec-int-l {
+ pins = "gpio18";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ bios_flash_wp_od: bios-flash-wp-od {
+ pins = "gpio16";
+ function = "gpio";
+ /* Has external pull */
+ bias-disable;
+ };
+
+ en_fp_rails: en-fp-rails {
+ pins = "gpio77";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ output-high;
+ };
+
+ en_pp3300_codec: en-pp3300-codec {
+ pins = "gpio105";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ en_pp3300_dx_edp: en-pp3300-dx-edp {
+ pins = "gpio80";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ fp_rst_l: fp-rst-l {
+ pins = "gpio78";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ output-high;
+ };
+
+ fp_to_ap_irq_l: fp-to-ap-irq-l {
+ pins = "gpio61";
+ function = "gpio";
+ /* Has external pullup */
+ bias-disable;
+ };
+
+ fpmcu_boot0: fpmcu-boot0 {
+ pins = "gpio68";
+ function = "gpio";
+ bias-disable;
+ output-low;
+ };
+
+ gsc_ap_int_odl: gsc-ap-int-odl {
+ pins = "gpio104";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ hp_irq: hp-irq {
+ pins = "gpio101";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ hub_en: hub-en {
+ pins = "gpio157";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ pe_wake_odl: pe-wake-odl {
+ pins = "gpio3";
+ function = "gpio";
+ /* Has external pull */
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ /* For ap_spi_fp */
+ qup_spi9_cs_gpio_init_high: qup-spi9-cs-gpio-init-high {
+ pins = "gpio39";
+ function = "gpio";
+ output-high;
+ };
+
+ /* For ap_ec_spi */
+ qup_spi10_cs_gpio_init_high: qup-spi10-cs-gpio-init-high {
+ pins = "gpio43";
+ function = "gpio";
+ output-high;
+ };
+
+ sar0_irq_odl: sar0-irq-odl {
+ pins = "gpio141";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ sar1_irq_odl: sar0-irq-odl {
+ pins = "gpio140";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ ssd_en: ssd-en {
+ pins = "gpio51";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ };
+
+ ssd_rst_l: ssd-rst-l {
+ pins = "gpio2";
+ function = "gpio";
+ bias-disable;
+ drive-strength = <2>;
+ output-low;
+ };
+
+ tp_int_odl: tp-int-odl {
+ pins = "gpio7";
+ function = "gpio";
+ /* Has external pullup */
+ bias-disable;
+ };
+
+ wf_cam_en: wf-cam-en {
+ pins = "gpio119";
+ function = "gpio";
+ /* Has external pulldown */
+ bias-disable;
+ drive-strength = <2>;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi b/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi
new file mode 100644
index 000000000000..a9cd746c12c6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sc7280-qcard.dtsi
@@ -0,0 +1,553 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * sc7280 Qcard device tree source
+ *
+ * Qcard PCB has the processor, RAM, eMMC (if stuffed), and eDP connector (if
+ * stuffed) on it. This device tree tries to encapsulate all the things that
+ * all boards using Qcard will have in common. Given that there are stuffing
+ * options, some things may be left with status "disabled" and enabled in
+ * the actual board device tree files.
+ *
+ * Copyright 2022 Google LLC.
+ */
+
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pmr735a.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "sc7280.dtsi"
+
+/* PMICs depend on spmi_bus label and so must come after SoC */
+#include "pm7325.dtsi"
+#include "pm8350c.dtsi"
+#include "pmk8350.dtsi"
+
+/ {
+ aliases {
+ bluetooth0 = &bluetooth;
+ serial0 = &uart5;
+ serial1 = &uart7;
+ };
+};
+
+&apps_rsc {
+ /*
+ * Regulators are given labels corresponding to the various names
+ * they are referred to on schematics. They are also given labels
+ * corresponding to named voltage inputs on the SoC or components
+ * bundled with the SoC (like radio companion chips). We totally
+ * ignore it when one regulator is the input to another regulator.
+ * That's handled automatically by the initial config given to
+ * RPMH by the firmware.
+ *
+ * Regulators that the HLOS (High Level OS) doesn't touch at all
+ * are left out of here since they are managed elsewhere.
+ */
+
+ pm7325-regulators {
+ compatible = "qcom,pm7325-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd19_pmu_pcie_i:
+ vdd19_pmu_rfa_i:
+ vreg_s1b_1p856: smps1 {
+ regulator-min-microvolt = <1856000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ vdd_pmu_aon_i:
+ vdd09_pmu_rfa_i:
+ vdd095_mx_pmu:
+ vdd095_pmu:
+ vreg_s7b_0p952: smps7 {
+ regulator-min-microvolt = <535000>;
+ regulator-max-microvolt = <1120000>;
+ };
+
+ vdd13_pmu_rfa_i:
+ vdd13_pmu_pcie_i:
+ vreg_s8b_1p256: smps8 {
+ regulator-min-microvolt = <1256000>;
+ regulator-max-microvolt = <1500000>;
+ };
+
+ vdd_a_usbssdp_0_core:
+ vreg_l1b_0p912: ldo1 {
+ regulator-min-microvolt = <825000>;
+ regulator-max-microvolt = <925000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_usbhs_3p1:
+ vreg_l2b_3p072: ldo2 {
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_csi_0_1_1p2:
+ vdd_a_csi_2_3_1p2:
+ vdd_a_csi_4_1p2:
+ vdd_a_dsi_0_1p2:
+ vdd_a_edp_0_1p2:
+ vdd_a_qlink_0_1p2:
+ vdd_a_qlink_1_1p2:
+ vdd_a_pcie_0_1p2:
+ vdd_a_pcie_1_1p2:
+ vdd_a_ufs_0_1p2:
+ vdd_a_usbssdp_0_1p2:
+ vreg_l6b_1p2: ldo6 {
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ /*
+ * Despite the fact that this is named to be 2.5V on the
+ * schematic, it powers eMMC which doesn't accept 2.5V
+ */
+ vreg_l7b_2p5: ldo7 {
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_px_wcd9385:
+ vdd_txrx:
+ vddpx_0:
+ vddpx_3:
+ vddpx_7:
+ vreg_l18b_1p8: ldo18 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_1p8:
+ vdd_px_sdr735:
+ vdd_pxm:
+ vdd18_io:
+ vddio_px_1:
+ vddio_px_2:
+ vddio_px_3:
+ vddpx_ts:
+ vddpx_wl4otp:
+ vreg_l19b_1p8: ldo19 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ pm8350c-regulators {
+ compatible = "qcom,pm8350c-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd22_wlbtpa_ch0:
+ vdd22_wlbtpa_ch1:
+ vdd22_wlbtppa_ch0:
+ vdd22_wlbtppa_ch1:
+ vdd22_wlpa5g_ch0:
+ vdd22_wlpa5g_ch1:
+ vdd22_wlppa5g_ch0:
+ vdd22_wlppa5g_ch1:
+ vreg_s1c_2p2: smps1 {
+ regulator-min-microvolt = <2190000>;
+ regulator-max-microvolt = <2210000>;
+ };
+
+ lp4_vdd2_1p052:
+ vreg_s9c_0p676: smps9 {
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1170000>;
+ };
+
+ vdda_apc_cs_1p8:
+ vdda_gfx_cs_1p8:
+ vdda_turing_q6_cs_1p8:
+ vdd_a_cxo_1p8:
+ vdd_a_qrefs_1p8:
+ vdd_a_usbhs_1p8:
+ vdd_qfprom:
+ vreg_l1c_1p8: ldo1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c_1p8: ldo2 {
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3c_3p0: ldo3 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3540000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vddpx_5:
+ vreg_l4c_1p8_3p0: ldo4 {
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vddpx_6:
+ vreg_l5c_1p8_3p0: ldo5 {
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vddpx_2:
+ vreg_l6c_2p96: ldo6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_3p0: ldo7 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c_1p8: ldo8 {
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c_2p96: ldo9 {
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_a_csi_0_1_0p9:
+ vdd_a_csi_2_3_0p9:
+ vdd_a_csi_4_0p9:
+ vdd_a_dsi_0_0p9:
+ vdd_a_dsi_0_pll_0p9:
+ vdd_a_edp_0_0p9:
+ vdd_a_gnss_0p9:
+ vdd_a_pcie_0_core:
+ vdd_a_pcie_1_core:
+ vdd_a_qlink_0_0p9:
+ vdd_a_qlink_0_0p9_ck:
+ vdd_a_qlink_1_0p9:
+ vdd_a_qlink_1_0p9_ck:
+ vdd_a_qrefs_0p875_0:
+ vdd_a_qrefs_0p875_1:
+ vdd_a_qrefs_0p875_2:
+ vdd_a_qrefs_0p875_3:
+ vdd_a_qrefs_0p875_4_5:
+ vdd_a_qrefs_0p875_6:
+ vdd_a_qrefs_0p875_7:
+ vdd_a_qrefs_0p875_8:
+ vdd_a_qrefs_0p875_9:
+ vdd_a_ufs_0_core:
+ vdd_a_usbhs_core:
+ vreg_l10c_0p88: ldo10 {
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11c_2p8: ldo11 {
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12c_1p8: ldo12 {
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13c_3p0: ldo13 {
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vdd_flash:
+ vdd_iris_rgb:
+ vdd_mic_bias:
+ vreg_bob: bob {
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+ };
+};
+
+/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
+
+&ipa {
+ status = "okay";
+ modem-init;
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+};
+
+&pmk8350_vadc {
+ pmk8350-die-temp@3 {
+ reg = <PMK8350_ADC7_DIE_TEMP>;
+ label = "pmk8350_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+
+ pmr735a-die-temp@403 {
+ reg = <PMR735A_ADC7_DIE_TEMP>;
+ label = "pmr735a_die_temp";
+ qcom,pre-scaling = <1 1>;
+ };
+};
+
+&qfprom {
+ vcc-supply = <&vdd_qfprom>;
+};
+
+/* For eMMC. NOTE: not all Qcards have eMMC stuffed */
+&sdhc_1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&sdc1_on>;
+ pinctrl-1 = <&sdc1_off>;
+
+ vmmc-supply = <&vreg_l7b_2p5>;
+ vqmmc-supply = <&vreg_l19b_1p8>;
+
+ non-removable;
+ no-sd;
+ no-sdio;
+};
+
+uart_dbg: &uart5 {
+ compatible = "qcom,geni-debug-uart";
+ status = "okay";
+};
+
+mos_bt_uart: &uart7 {
+ status = "okay";
+
+ /delete-property/ interrupts;
+ interrupts-extended = <&intc GIC_SPI 608 IRQ_TYPE_LEVEL_HIGH>,
+ <&tlmm 31 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-1 = <&qup_uart7_sleep_cts>, <&qup_uart7_sleep_rts>, <&qup_uart7_sleep_tx>, <&qup_uart7_sleep_rx>;
+
+ bluetooth: bluetooth {
+ compatible = "qcom,wcn6750-bt";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mos_bt_en>;
+ enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>;
+ swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>;
+ vddaon-supply = <&vreg_s7b_0p952>;
+ vddbtcxmx-supply = <&vreg_s7b_0p952>;
+ vddrfacmn-supply = <&vreg_s7b_0p952>;
+ vddrfa0p8-supply = <&vreg_s7b_0p952>;
+ vddrfa1p7-supply = <&vdd19_pmu_rfa_i>;
+ vddrfa1p2-supply = <&vdd13_pmu_rfa_i>;
+ vddrfa2p2-supply = <&vreg_s1c_2p2>;
+ vddasd-supply = <&vreg_l11c_2p8>;
+ vddio-supply = <&vreg_l18b_1p8>;
+ max-speed = <3200000>;
+ };
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vdd_a_usbhs_core>;
+ vdda33-supply = <&vdd_a_usbhs_3p1>;
+ vdda18-supply = <&vdd_a_usbhs_1p8>;
+};
+
+&usb_1_qmpphy {
+ vdda-phy-supply = <&vdd_a_usbssdp_0_1p2>;
+ vdda-pll-supply = <&vdd_a_usbssdp_0_core>;
+};
+
+&usb_2_hsphy {
+ vdda-pll-supply = <&vdd_a_usbhs_core>;
+ vdda33-supply = <&vdd_a_usbhs_3p1>;
+ vdda18-supply = <&vdd_a_usbhs_1p8>;
+};
+
+/*
+ * PINCTRL - ADDITIONS TO NODES IN PARENT DEVICE TREE FILES
+ *
+ * NOTE: In general if pins leave the Qcard then the pinctrl goes in the
+ * baseboard or board device tree, not here.
+ */
+
+/*
+ * For ts_i2c
+ *
+ * Technically this i2c bus actually leaves the Qcard, but it leaves directly
+ * via the eDP connector (it doesn't hit the baseboard). The external pulls
+ * are on Qcard.
+ */
+&qup_i2c13_data_clk {
+ /* Has external pull */
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For mos_bt_uart */
+&qup_uart7_cts {
+ /* Configure a pull-down on CTS to match the pull of the Bluetooth module. */
+ bias-pull-down;
+};
+
+/* For mos_bt_uart */
+&qup_uart7_rts {
+ /* We'll drive RTS, so no pull */
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For mos_bt_uart */
+&qup_uart7_tx {
+ /* We'll drive TX, so no pull */
+ bias-disable;
+ drive-strength = <2>;
+};
+
+/* For mos_bt_uart */
+&qup_uart7_rx {
+ /*
+ * Configure a pull-up on RX. This is needed to avoid
+ * garbage data when the TX pin of the Bluetooth module is
+ * in tri-state (module powered off or not driving the
+ * signal yet).
+ */
+ bias-pull-up;
+};
+
+/* eMMC, if stuffed, is straight on the Qcard */
+&sdc1_on {
+ clk {
+ bias-disable;
+ drive-strength = <16>;
+ };
+
+ cmd {
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ data {
+ bias-pull-up;
+ drive-strength = <10>;
+ };
+
+ rclk {
+ bias-pull-down;
+ };
+};
+
+/*
+ * PINCTRL - QCARD
+ *
+ * This has entries that are defined by Qcard even if they go to the main
+ * board. In cases where the pulls may be board dependent we defer those
+ * settings to the board device tree. Drive strengths tend to be assinged here
+ * but could conceivably be overwridden by board device trees.
+ */
+
+&pm8350c_gpios {
+ pmic_edp_bl_en: pmic-edp-bl-en {
+ pins = "gpio7";
+ function = "normal";
+ bias-disable;
+ qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+
+ /* Force backlight to be disabled to match state at boot. */
+ output-low;
+ };
+
+ pmic_edp_bl_pwm: pmic-edp-bl-pwm {
+ pins = "gpio8";
+ function = "func1";
+ bias-disable;
+ qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+ output-low;
+ power-source = <0>;
+ };
+};
+
+&tlmm {
+ mos_bt_en: mos-bt-en {
+ pins = "gpio85";
+ function = "gpio";
+ drive-strength = <2>;
+ output-low;
+ };
+
+ /* For mos_bt_uart */
+ qup_uart7_sleep_cts: qup-uart7-sleep-cts {
+ pins = "gpio28";
+ function = "gpio";
+ /*
+ * Configure a pull-down on CTS to match the pull of
+ * the Bluetooth module.
+ */
+ bias-pull-down;
+ };
+
+ /* For mos_bt_uart */
+ qup_uart7_sleep_rts: qup-uart7-sleep-rts {
+ pins = "gpio29";
+ function = "gpio";
+ /*
+ * Configure pull-down on RTS. As RTS is active low
+ * signal, pull it low to indicate the BT SoC that it
+ * can wakeup the system anytime from suspend state by
+ * pulling RX low (by sending wakeup bytes).
+ */
+ bias-pull-down;
+ };
+
+ /* For mos_bt_uart */
+ qup_uart7_sleep_rx: qup-uart7-sleep-rx {
+ pins = "gpio31";
+ function = "gpio";
+ /*
+ * Configure a pull-up on RX. This is needed to avoid
+ * garbage data when the TX pin of the Bluetooth module
+ * is floating which may cause spurious wakeups.
+ */
+ bias-pull-up;
+ };
+
+ /* For mos_bt_uart */
+ qup_uart7_sleep_tx: qup-uart7-sleep-tx {
+ pins = "gpio30";
+ function = "gpio";
+ /*
+ * Configure pull-up on TX when it isn't actively driven
+ * to prevent BT SoC from receiving garbage during sleep.
+ */
+ bias-pull-up;
+ };
+
+ ts_int_conn: ts-int-conn {
+ pins = "gpio55";
+ function = "gpio";
+ bias-pull-up;
+ };
+
+ ts_rst_conn: ts-rst-conn {
+ pins = "gpio54";
+ function = "gpio";
+ bias-pull-up;
+ drive-strength = <2>;
+ };
+};
--
2.35.0.rc0.227.g00780c9af4-goog
^ permalink raw reply related
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
From: Andrew Lunn @ 2022-01-25 22:46 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski, Shawn Guo,
Stanislav Jakubek, Sam Ravnborg, Linus Walleij, Hao Fang,
Arnd Bergmann, Russell King (Oracle), Geert Uytterhoeven,
Mark Rutland, Ard Biesheuvel, Anshuman Khandual, Lukas Bulwahn,
Masahiro Yamada, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20220125194609.32314-1-nick.hawkins@hpe.com>
> + umac0: umac@c0004000 {
> + compatible = "hpe, gxp-umac";
> + reg = <0xc0004000 0x80>;
> + interrupts = <10>;
> + interrupt-parent = <&vic0>;
> + mac-address = [94 18 82 16 04 d8];
> + phy-handle = <&ext_phy0>;
> + int-phy-handle = <&int_phy0>;
> + };
I suggest you don't add any DT for drivers which have not been
accepted yet. When you MAC driver is posted to netdev, the DT binding
will get reviewed. And i expect int-phy-handle will be rejected.
Often the first dtsi and dts submission for a new SoC have just the
CPUs and the serial port, since none of the other drivers have been
reviewed yet, unless they reuse existing drivers. The additional nodes
are then added one by one as the drivers get accepted.
Andrew
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: qcom: sc7280: Factor gpio.h include to sc7280.dtsi
From: Stephen Boyd @ 2022-01-25 22:54 UTC (permalink / raw)
To: Bjorn Andersson, Douglas Anderson
Cc: konrad.dybcio, kgodara, mka, sibis, pmaliset, quic_rjendra,
Andy Gross, Rob Herring, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125144316.v2.4.I3194c8bdb2ad3212665286fa273710a3c4840e94@changeid>
Quoting Douglas Anderson (2022-01-25 14:44:21)
> Though sc7280 itself doesn't need any of the defines in gpio.h, it's
> highly likely that the actual boards will use them. Let's add the
> include to the sc7280.dtsi file so that boards don't need to do it.
>
> Suggested-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1
From: Stephen Boyd @ 2022-01-25 22:58 UTC (permalink / raw)
To: Bjorn Andersson, Douglas Anderson
Cc: konrad.dybcio, kgodara, mka, sibis, pmaliset, quic_rjendra,
Andy Gross, Rob Herring, devicetree, linux-arm-msm, linux-kernel
In-Reply-To: <20220125144316.v2.5.I5604b7af908e8bbe709ac037a6a8a6ba8a2bfa94@changeid>
Quoting Douglas Anderson (2022-01-25 14:44:22)
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> new file mode 100644
> index 000000000000..f95273052da0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> @@ -0,0 +1,313 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Herobrine board device tree source
> + *
> + * Copyright 2022 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include "sc7280-herobrine.dtsi"
> +
> +/ {
> + model = "Google Herobrine (rev1+)";
> + compatible = "google,herobrine", "qcom,sc7280";
Can we stop adding "qcom,sc7280" to the board compatible string? It
looks out of place. It's the compatible for the SoC and should really be
the compatible for the /soc node.
> +};
> +
> +/* ADDITIONS TO NODES DEFINED IN PARENT DEVICE TREE FILES */
> +
> +&ap_spi_fp {
> + status = "okay";
> +};
[...]
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> new file mode 100644
> index 000000000000..24c34ddebd18
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> @@ -0,0 +1,778 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Google Herobrine baseboard device tree source
> + *
[...]
> +
> + vin-supply = <&ppvar_sys>;
> + };
> +
> + pp3300_codec: pp3300-codec-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "pp3300_codec";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&tlmm 105 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + pinctrl-names = "default";
> + pinctrl-0 = <&en_pp3300_codec>;
> +
> + vin-supply = <&pp3300_z1>;
> + };
> +
> + pp3300_left_in_mlb: pp3300-left-in-mlb {
Sometimes '-regulator' is left out. Is that intentional? I suppose it
would be better if every node had regulator postfix, but it may be too
long of a node name?
> + compatible = "regulator-fixed";
> + regulator-name = "pp3300_left_in_mlb";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&tlmm 80 GPIO_ACTIVE_HIGH>;
^ permalink raw reply
* Re: [RFC PATCH 2/2] leds: Add PWM multicolor driver
From: Jacek Anaszewski @ 2022-01-25 23:01 UTC (permalink / raw)
To: sven, linux-leds, devicetree, linux-pwm
Cc: Sven Schwermer, pavel, robh+dt, thierry.reding, u.kleine-koenig,
lee.jones
In-Reply-To: <20220125092239.2006333-3-sven@svenschwermer.de>
Hi Sven,
Thanks for the patch. Few comments below.
On 1/25/22 10:22 AM, sven@svenschwermer.de wrote:
> From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
>
> By allowing to group multiple monochrome PWM LEDs into multicolor LEDs,
> all involved LEDs can be controlled in-sync. This enables using effects
> using triggers, etc.
>
> Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> ---
> drivers/leds/Kconfig | 8 ++
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-pwm-multicolor.c | 184 +++++++++++++++++++++++++++++
> 3 files changed, 193 insertions(+)
> create mode 100644 drivers/leds/leds-pwm-multicolor.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index b6742b4231bf..2e5058696fa6 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -586,6 +586,14 @@ config LEDS_PWM
> help
> This option enables support for pwm driven LEDs
>
> +config LEDS_PWM_MULTICOLOR
> + tristate "PWM driven multi-color LED Support"
> + depends on LEDS_CLASS_MULTICOLOR
> + depends on PWM
> + help
> + This option enables support for PWM driven monochrome LEDs that are
> + grouped into multicolor LEDs.
> +
> config LEDS_REGULATOR
> tristate "REGULATOR driven LED support"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 2a698df9da57..152f69374632 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -79,6 +79,7 @@ obj-$(CONFIG_LEDS_PCA963X) += leds-pca963x.o
> obj-$(CONFIG_LEDS_PM8058) += leds-pm8058.o
> obj-$(CONFIG_LEDS_POWERNV) += leds-powernv.o
> obj-$(CONFIG_LEDS_PWM) += leds-pwm.o
> +obj-$(CONFIG_LEDS_PWM_MULTICOLOR) += leds-pwm-multicolor.o
> obj-$(CONFIG_LEDS_REGULATOR) += leds-regulator.o
> obj-$(CONFIG_LEDS_S3C24XX) += leds-s3c24xx.o
> obj-$(CONFIG_LEDS_SC27XX_BLTC) += leds-sc27xx-bltc.o
> diff --git a/drivers/leds/leds-pwm-multicolor.c b/drivers/leds/leds-pwm-multicolor.c
> new file mode 100644
> index 000000000000..c54bed4536d3
> --- /dev/null
> +++ b/drivers/leds/leds-pwm-multicolor.c
> @@ -0,0 +1,184 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * PWM-based multi-color LED control
> + *
> + * Copyright 2022 Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/led-class-multicolor.h>
> +#include <linux/leds.h>
> +#include <linux/err.h>
> +#include <linux/pwm.h>
> +#include <linux/mutex.h>
> +
> +struct pwm_led {
> + struct pwm_device *pwm;
> + struct pwm_state pwmstate;
> +};
> +
> +struct pwm_mc_led {
> + struct led_classdev_mc mc_cdev;
> + struct mutex lock;
> + struct pwm_led leds[];
> +};
> +
> +static int led_pwm_mc_set(struct led_classdev *cdev,
> + enum led_brightness brightness)
> +{
> + int i;
> + unsigned long long duty;
> + int ret = 0;
> + struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(cdev);
> + struct pwm_mc_led *priv = container_of(mc_cdev, struct pwm_mc_led, mc_cdev);
> +
> + led_mc_calc_color_components(mc_cdev, brightness);
> +
> + mutex_lock(&priv->lock);
> +
> + for (i = 0; i < mc_cdev->num_colors; ++i) {
> + duty = priv->leds[i].pwmstate.period;
> + duty *= mc_cdev->subled_info[i].brightness;
> + do_div(duty, cdev->max_brightness);
> +
> + priv->leds[i].pwmstate.duty_cycle = duty;
> + priv->leds[i].pwmstate.enabled = duty > 0;
> + ret = pwm_apply_state(priv->leds[i].pwm,
> + &priv->leds[i].pwmstate);
> + if (ret)
> + break;
> + }
> +
> + mutex_unlock(&priv->lock);
> +
> + return ret;
> +}
> +
> +static int led_pwm_mc_probe(struct platform_device *pdev)
> +{
> + struct fwnode_handle *mcnode, *fwnode;
> + int count = 0;
> + struct pwm_mc_led *priv;
> + struct mc_subled *subled;
> + struct led_classdev *cdev;
> + struct pwm_led *pwmled;
> + u32 color;
> + int ret = 0;
> + struct led_init_data init_data = {};
> +
> + mcnode = device_get_named_child_node(&pdev->dev, "multi-led");
> + if (!mcnode) {
> + dev_err(&pdev->dev, "expected multi-led node\n");
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + /* count the nodes inside the multi-led node */
> + fwnode_for_each_child_node(mcnode, fwnode)
> + ++count;
> +
> + priv = devm_kzalloc(&pdev->dev, struct_size(priv, leds, count),
> + GFP_KERNEL);
> + if (!priv) {
> + ret = -ENOMEM;
> + goto out;
> + }
> + mutex_init(&priv->lock);
> +
> + subled = devm_kcalloc(&pdev->dev, count, sizeof(*subled), GFP_KERNEL);
> + if (!subled) {
> + ret = -ENOMEM;
> + goto destroy_mutex;
> + }
> + priv->mc_cdev.subled_info = subled;
> +
> + /* init the multicolor's LED class device */
> + cdev = &priv->mc_cdev.led_cdev;
> + fwnode_property_read_string(mcnode, "label", &cdev->name);
LED core has the support for parsing LED name, so you can skip it.
> + cdev->brightness = LED_OFF;
devm_kzalloc() handles that.
> + fwnode_property_read_u32(mcnode, "max-brightness",
> + &cdev->max_brightness);
> + cdev->flags = LED_CORE_SUSPENDRESUME;
> + cdev->brightness_set_blocking = led_pwm_mc_set;
> +
> + /* iterate over the nodes inside the multi-led node */
> + fwnode_for_each_child_node(mcnode, fwnode) {
> + pwmled = &priv->leds[priv->mc_cdev.num_colors];
> + pwmled->pwm = devm_fwnode_pwm_get(&pdev->dev, fwnode, NULL);
> + if (IS_ERR(pwmled->pwm)) {
> + ret = PTR_ERR(pwmled->pwm);
> + dev_err(&pdev->dev, "unable to request PWM: %d\n", ret);
> + goto destroy_mutex;
> + }
> + pwm_init_state(pwmled->pwm, &pwmled->pwmstate);
> +
> + ret = fwnode_property_read_u32(fwnode, "color", &color);
> + if (ret) {
> + dev_err(&pdev->dev, "cannot read color: %d\n", ret);
> + goto destroy_mutex;
> + }
> +
> + subled[priv->mc_cdev.num_colors].color_index = color;
> + subled[priv->mc_cdev.num_colors].channel =
> + priv->mc_cdev.num_colors;
channel property can be meaningful only for the LED controllers that can
control many LED outputs. In case of pwm controllers you're using LED id
to pwmstate mapping in led_pwm_mc_set().
> + ++priv->mc_cdev.num_colors;
> + }
> +
> + init_data.fwnode = mcnode;
> + ret = devm_led_classdev_multicolor_register_ext(&pdev->dev,
> + &priv->mc_cdev,
> + &init_data);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to register multicolor PWM led for %s: %d\n",
> + cdev->name, ret);
> + goto destroy_mutex;
> + }
> +
> + ret = led_pwm_mc_set(cdev, cdev->brightness);
> + if (ret) {
> + dev_err(&pdev->dev, "failed to set led PWM value for %s: %d",
> + cdev->name, ret);
> + goto destroy_mutex;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> + return 0;
> +
> +destroy_mutex:
> + mutex_destroy(&priv->lock);
> +out:
> + return ret;
> +}
> +
> +static int led_pwm_mc_remove(struct platform_device *pdev)
> +{
> + struct pwm_mc_led *priv = platform_get_drvdata(pdev);
> +
> + mutex_destroy(&priv->lock);
> + return 0;
> +}
> +
> +static const struct of_device_id of_pwm_leds_mc_match[] = {
> + { .compatible = "pwm-leds-multicolor", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, of_pwm_leds_mc_match);
> +
> +static struct platform_driver led_pwm_mc_driver = {
> + .probe = led_pwm_mc_probe,
> + .remove = led_pwm_mc_remove,
> + .driver = {
> + .name = "leds_pwm_multicolor",
> + .of_match_table = of_pwm_leds_mc_match,
> + },
> +};
> +
> +module_platform_driver(led_pwm_mc_driver);
> +
> +MODULE_AUTHOR("Sven Schwermer <sven.schwermer@disruptive-technologies.com>");
> +MODULE_DESCRIPTION("multi-color PWM LED driver");
> +MODULE_LICENSE("GPL v2");
> +MODULE_ALIAS("platform:leds-pwm-multicolor");
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1
From: Doug Anderson @ 2022-01-25 23:46 UTC (permalink / raw)
To: Stephen Boyd
Cc: Bjorn Andersson, Konrad Dybcio, kgodara, Matthias Kaehlcke,
Sibi Sankar, Prasad Malisetty, quic_rjendra, Andy Gross,
Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, LKML
In-Reply-To: <CAE-0n528Bxdj+DKhi2Lan4qR_=4KHD7A1Zkr15tmu+MchryJ1A@mail.gmail.com>
Hi,
On Tue, Jan 25, 2022 at 2:58 PM Stephen Boyd <swboyd@chromium.org> wrote:
>
> Quoting Douglas Anderson (2022-01-25 14:44:22)
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> > new file mode 100644
> > index 000000000000..f95273052da0
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> > @@ -0,0 +1,313 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Google Herobrine board device tree source
> > + *
> > + * Copyright 2022 Google LLC.
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "sc7280-herobrine.dtsi"
> > +
> > +/ {
> > + model = "Google Herobrine (rev1+)";
> > + compatible = "google,herobrine", "qcom,sc7280";
>
> Can we stop adding "qcom,sc7280" to the board compatible string? It
> looks out of place. It's the compatible for the SoC and should really be
> the compatible for the /soc node.
I don't have any objections, but I feel like this is the type of thing
I'd like Bjorn to have the final say on. What say you, Bjorn?
> > + pp3300_left_in_mlb: pp3300-left-in-mlb {
>
> Sometimes '-regulator' is left out. Is that intentional? I suppose it
> would be better if every node had regulator postfix, but it may be too
> long of a node name?
Huh, you're right. No, it's not intentional. It looks like it was that
way on herobrine-rev0 too... It also looks like it's missing on
"pp3300-hub" on trogdor.
Happy to add "-regulator" in the herobrine / trogdor nodes that need
it. I'll probably do it as a follow-on patch if that works OK? Then I
can just clean them all up at once...
-Doug
^ permalink raw reply
* [PATCH v7 2/4] usb: dwc3: xilinx: Fix error handling when getting USB3 PHY
From: Robert Hancock @ 2022-01-26 0:02 UTC (permalink / raw)
To: linux-usb
Cc: balbi, gregkh, michal.simek, manish.narani, sean.anderson,
robh+dt, devicetree, piyush.mehta, Robert Hancock
In-Reply-To: <20220126000253.1586760-1-robert.hancock@calian.com>
The code that looked up the USB3 PHY was ignoring all errors other than
EPROBE_DEFER in an attempt to handle the PHY not being present. Fix and
simplify the code by using devm_phy_optional_get and dev_err_probe so
that a missing PHY is not treated as an error and unexpected errors
are handled properly.
Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
drivers/usb/dwc3/dwc3-xilinx.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 06b591b14b09..e14ac15e24c3 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -102,12 +102,12 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
int ret;
u32 reg;
- usb3_phy = devm_phy_get(dev, "usb3-phy");
- if (PTR_ERR(usb3_phy) == -EPROBE_DEFER) {
- ret = -EPROBE_DEFER;
+ usb3_phy = devm_phy_optional_get(dev, "usb3-phy");
+ if (IS_ERR(usb3_phy)) {
+ ret = PTR_ERR(usb3_phy);
+ dev_err_probe(dev, ret,
+ "failed to get USB3 PHY\n");
goto err;
- } else if (IS_ERR(usb3_phy)) {
- usb3_phy = NULL;
}
/*
--
2.31.1
^ permalink raw reply related
* [PATCH v7 1/4] usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0 mode
From: Robert Hancock @ 2022-01-26 0:02 UTC (permalink / raw)
To: linux-usb
Cc: balbi, gregkh, michal.simek, manish.narani, sean.anderson,
robh+dt, devicetree, piyush.mehta, Robert Hancock
In-Reply-To: <20220126000253.1586760-1-robert.hancock@calian.com>
It appears that the PIPE clock should not be selected when only USB 2.0
is being used in the design and no USB 3.0 reference clock is used.
Also, the core resets are not required if a USB3 PHY is not in use, and
will break things if USB3 is actually used but the PHY entry is not
listed in the device tree.
Skip core resets and register settings that are only required for
USB3 mode when no USB3 PHY is specified in the device tree.
Fixes: 84770f028fab ("usb: dwc3: Add driver for Xilinx platforms")
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
drivers/usb/dwc3/dwc3-xilinx.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 9cc3ad701a29..06b591b14b09 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -110,6 +110,18 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
usb3_phy = NULL;
}
+ /*
+ * The following core resets are not required unless a USB3 PHY
+ * is used, and the subsequent register settings are not required
+ * unless a core reset is performed (they should be set properly
+ * by the first-stage boot loader, but may be reverted by a core
+ * reset). They may also break the configuration if USB3 is actually
+ * in use but the usb3-phy entry is missing from the device tree.
+ * Therefore, skip these operations in this case.
+ */
+ if (!usb3_phy)
+ goto skip_usb3_phy;
+
crst = devm_reset_control_get_exclusive(dev, "usb_crst");
if (IS_ERR(crst)) {
ret = PTR_ERR(crst);
@@ -188,6 +200,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
goto err;
}
+skip_usb3_phy:
/*
* This routes the USB DMA traffic to go through FPD path instead
* of reaching DDR directly. This traffic routing is needed to
--
2.31.1
^ permalink raw reply related
* [PATCH v7 3/4] dt-bindings: usb: dwc3-xilinx: Added reset-gpios
From: Robert Hancock @ 2022-01-26 0:02 UTC (permalink / raw)
To: linux-usb
Cc: balbi, gregkh, michal.simek, manish.narani, sean.anderson,
robh+dt, devicetree, piyush.mehta, Robert Hancock
In-Reply-To: <20220126000253.1586760-1-robert.hancock@calian.com>
Update DT binding to reflect new reset-gpios property.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
index f77c16e203d5..823ce731e95f 100644
--- a/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
+++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.yaml
@@ -59,6 +59,10 @@ properties:
- const: usb_hibrst
- const: usb_apbrst
+ reset-gpios:
+ description: Optional GPIO connected to ULPI PHY reset line.
+ maxItems: 1
+
phys:
minItems: 1
maxItems: 2
--
2.31.1
^ permalink raw reply related
* [PATCH v7 0/4] Xilinx ZynqMP USB fixes
From: Robert Hancock @ 2022-01-26 0:02 UTC (permalink / raw)
To: linux-usb
Cc: balbi, gregkh, michal.simek, manish.narani, sean.anderson,
robh+dt, devicetree, piyush.mehta, Robert Hancock
Some fixes related to the Xilinx ZynqMP DWC3 wrapper driver to allow
ZynqMP USB to work properly when the hardware is configured in USB
2.0-only mode.
Changes since v6:
-skip USB core resets and register settings which are not necessary
when USB3 PHY is not specified
-added patches to implement ULPI PHY reset in driver
Changes since v5:
-code formatting fixes, no functional change
Changes since v4:
-dropped DWC3 core patches as they are superseded by Sean Anderson's
patchset "usb: dwc3: Calculate REFCLKPER et. al. from reference clock",
ZynqMP-specific patches unchanged
Changes since v3:
-fixed DT schema dt-doc-validate error
Changes since v2:
-additional kerneldoc fixes
Changes since v1:
-added DT binding documentation for new attribute
-kerneldoc formatting and reworded comments
Robert Hancock (4):
usb: dwc3: xilinx: Skip resets and USB3 register settings for USB2.0
mode
usb: dwc3: xilinx: Fix error handling when getting USB3 PHY
dt-bindings: usb: dwc3-xilinx: Added reset-gpios
usb: dwc3: xilinx: Add ULPI PHY reset handling
.../devicetree/bindings/usb/dwc3-xilinx.yaml | 4 ++
drivers/usb/dwc3/dwc3-xilinx.c | 41 ++++++++++++++++---
2 files changed, 40 insertions(+), 5 deletions(-)
--
2.31.1
^ permalink raw reply
* [PATCH v7 4/4] usb: dwc3: xilinx: Add ULPI PHY reset handling
From: Robert Hancock @ 2022-01-26 0:02 UTC (permalink / raw)
To: linux-usb
Cc: balbi, gregkh, michal.simek, manish.narani, sean.anderson,
robh+dt, devicetree, piyush.mehta, Robert Hancock
In-Reply-To: <20220126000253.1586760-1-robert.hancock@calian.com>
Hook up an optional GPIO-based reset for the connected USB ULPI PHY
device. This is typically already done by the first-stage boot loader,
however it can be more robust to ensure this reset is done prior to
loading the driver in Linux.
Based on a patch "usb: dwc3: xilinx: Add gpio-reset support" in the
Xilinx kernel tree by Piyush Mehta <piyush.mehta@xilinx.com>.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
drivers/usb/dwc3/dwc3-xilinx.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index e14ac15e24c3..0778236509bf 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -11,6 +11,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/of.h>
+#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
#include <linux/of_platform.h>
@@ -101,6 +102,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
struct phy *usb3_phy;
int ret;
u32 reg;
+ struct gpio_desc *reset_gpio;
usb3_phy = devm_phy_optional_get(dev, "usb3-phy");
if (IS_ERR(usb3_phy)) {
@@ -201,6 +203,22 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
skip_usb3_phy:
+ /* ulpi reset via gpio-modepin or gpio-framework driver */
+ reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpio)) {
+ dev_err_probe(dev, PTR_ERR(reset_gpio),
+ "Failed to bind reset gpio\n");
+ goto err;
+ }
+
+ if (reset_gpio) {
+ /* Toggle ulpi to reset the phy. */
+ gpiod_set_value(reset_gpio, 0);
+ usleep_range(5000, 10000); /* delay */
+ gpiod_set_value(reset_gpio, 1);
+ usleep_range(5000, 10000); /* delay */
+ }
+
/*
* This routes the USB DMA traffic to go through FPD path instead
* of reaching DDR directly. This traffic routing is needed to
--
2.31.1
^ permalink raw reply related
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
From: Arnd Bergmann @ 2022-01-26 0:22 UTC (permalink / raw)
To: nick.hawkins
Cc: verdun, Rob Herring, Russell King, Krzysztof Kozlowski, Shawn Guo,
Stanislav Jakubek, Sam Ravnborg, Linus Walleij, Hao Fang,
Arnd Bergmann, Russell King (Oracle), Geert Uytterhoeven,
Mark Rutland, Ard Biesheuvel, Anshuman Khandual, Lukas Bulwahn,
Masahiro Yamada, DTML, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <20220125194609.32314-1-nick.hawkins@hpe.com>
'On Tue, Jan 25, 2022 at 8:46 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Hi Nick,
Thanks for your submission, it's always nice to see support for a new platform.
I assume that you have a number of other drivers that are required for
an initial
support, at least to get you booting into a shell. I recommend to keep
those together
as a series, and we can merge them through the soc tree initially, with an Ack
from the corresponding subsystem maintainers. For later updates to the drivers,
you should send them to the maintainers directly, same for any
non-essential drivers
Krzysztof already commented on most issues I see, here are a few more things
to consider:
>
> +GXP ARCHITECTURE
Make this "ARM/HPE GXP ARCHITECTURE", so it does not get mistaken
for a separate instruction set architecture, or something else with that three
letter acronym.
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
> + model = "GXP";
Make this the specific machine rather than the SoC, unless you can guarantee
that there won't ever be another board revision made from the same SoC (family).
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
> + };
The bootargs should be set by the bootloader. In particular there should be
not 'earlyprintk' by default, and the console should be selected using the
'stdout-path' property.
You seem to be missing CPU nodes.
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
Add a custom compatible string as a specialization in case you ever
need to work around some quirk on these devices.
> + spifi0: spifi@c0000200 {
> + compatible = "hpe,gxp-spifi";
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
The partitions should ideally be set by the bootloader as well, or
at least be in the .dts file separately from the soc .dtsi file.
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
Do you have a strong reason for needing a custom defconfig file?
Usually this should
work with the normal multi_v7_defconfig.
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
Most of the symbols you select are implied by ARCH_MULTI_V7, so you
can remove them here.
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
We don't normally do custom mappings any more, these should come from
the device tree and get mapped by the corresponding drivers.
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
> + __raw_writel(0x00080002,
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
This belongs into the bootloader, or the EHCI driver, see the comment about a
custom compatible value above ;-)
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
This should be a reset driver, see
drivers/power/reset/syscon-reboot.c either as an example, or something you
can use directly.
Arnd
^ permalink raw reply
* Re: [PATCH] Adding architectural support for HPE's GXP BMC. This is the first of a series of patches to support HPE's BMC with Linux Kernel.
From: Verdun, Jean-Marie @ 2022-01-26 1:49 UTC (permalink / raw)
To: Arnd Bergmann, Hawkins, Nick
Cc: Rob Herring, Russell King, Krzysztof Kozlowski, Shawn Guo,
Stanislav Jakubek, Sam Ravnborg, Linus Walleij, Hao Fang,
Russell King (Oracle), Geert Uytterhoeven, Mark Rutland,
Ard Biesheuvel, Anshuman Khandual, Lukas Bulwahn, Masahiro Yamada,
DTML, Linux Kernel Mailing List, Linux ARM
In-Reply-To: <CAK8P3a0ccoH_sNE9eWxQnWHEWNBPFL6k4k6mku=cHs_fRfnL-w@mail.gmail.com>
Hello Arnd,
I work with Nick on upstreaming the initial code for our GXP asic. Many thanks for your feedbacks.
We will update accordingly. I must admit that I am a little bit lost regarding the process we shall follow to introduce a new SoC. We took the path to send first the DT side and then the drivers through a set of patch per driver. Andrew, seems to guide us into a direction where we shall have a very small DT initially and we will expand it in a step by step manner when we will get drivers approved, this might lead us into a process which might be very sequential. What is the best recommendation to follow ? Either way is ok on our side, I am just looking at the easiest solution for the code Maintainers.
Most of this code is intended to be used with OpenBMC and u-boot. We didn't have yet upstream anything into the bootloader, and wanted to follow a step by step approach by initially publishing into the kernel (that explain why some init also are still hardcoded in the case the bootloader doesn't provide the data, that is still work in progress, but we can have end user testing the infrastructure). We have a very small user space environment to validate that the kernel boot properly by using u-root, before getting OpenBMC fully loaded. Last but not least, as this is a BMC code, which is new to our end users, it would be just great to have default fall back if the u-boot environment is not properly setup (roughly we could code the MAC address into the umac driver, or the DT to address such cases). We plan to update uboot in the next couple of days by the way.
We do not use dtsi at all for the moment, as we are generating a dtb out of the dts file and load it into our SPI image. Probably not the best approach, but this is the way it is implemented currently. The dtb is compiled outside the kernel tree for the moment using dtc compiler. We will add that step into the dts boot Makefile, it make sense. Does the dtsi is mandatory for every SoC ? I can build one if needed. But as this SoC is a BMC, the current dts is an example of what shall be configured. Many other datas related to the hardware target platform are defined into OpenBMC layers while we build for various ProLiant servers. We wanted our kernel code being readily testable that is why we have that generic dts. (GPIOS mapping is machine dependent)
vejmarie
On 1/25/22, 4:22 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
'On Tue, Jan 25, 2022 at 8:46 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
Hi Nick,
Thanks for your submission, it's always nice to see support for a new platform.
I assume that you have a number of other drivers that are required for
an initial
support, at least to get you booting into a shell. I recommend to keep
those together
as a series, and we can merge them through the soc tree initially, with an Ack
from the corresponding subsystem maintainers. For later updates to the drivers,
you should send them to the maintainers directly, same for any
non-essential drivers
Krzysztof already commented on most issues I see, here are a few more things
to consider:
>
> +GXP ARCHITECTURE
Make this "ARM/HPE GXP ARCHITECTURE", so it does not get mistaken
for a separate instruction set architecture, or something else with that three
letter acronym.
> +
> +/dts-v1/;
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "HPE,GXP";
> + model = "GXP";
Make this the specific machine rather than the SoC, unless you can guarantee
that there won't ever be another board revision made from the same SoC (family).
> + chosen {
> + bootargs = "earlyprintk console=ttyS0,115200 user_debug=31";
> + };
The bootargs should be set by the bootloader. In particular there should be
not 'earlyprintk' by default, and the console should be selected using the
'stdout-path' property.
You seem to be missing CPU nodes.
> +
> + usb0: ehci@cefe0000 {
> + compatible = "generic-ehci";
> + reg = <0xcefe0000 0x100>;
> + interrupts = <7>;
> + interrupt-parent = <&vic0>;
> + };
> +
> + usb1: ohci@cefe0100 {
> + compatible = "generic-ohci";
> + reg = <0xcefe0100 0x110>;
> + interrupts = <6>;
> + interrupt-parent = <&vic0>;
> + };
Add a custom compatible string as a specialization in case you ever
need to work around some quirk on these devices.
> + spifi0: spifi@c0000200 {
> + compatible = "hpe,gxp-spifi";
> + reg = <0xc0000200 0x80>, <0xc000c000 0x100>, <0xf8000000 0x8000000>;
> + interrupts = <20>;
> + interrupt-parent = <&vic0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bmc@0 {
> + label = "bmc";
> + reg = <0x0 0x2000000>;
> + };
> + u-boot@0 {
> + label = "u-boot";
> + reg = <0x0 0x60000>;
> + };
The partitions should ideally be set by the bootloader as well, or
at least be in the .dts file separately from the soc .dtsi file.
> diff --git a/arch/arm/configs/gxp_defconfig b/arch/arm/configs/gxp_defconfig
> new file mode 100644
> index 000000000000..f37c6630e06d
> --- /dev/null
> +++ b/arch/arm/configs/gxp_defconfig
Do you have a strong reason for needing a custom defconfig file?
Usually this should
work with the normal multi_v7_defconfig.
> diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
> new file mode 100644
> index 000000000000..9b27f97c6536
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Kconfig
> @@ -0,0 +1,20 @@
> +menuconfig ARCH_HPE
> + bool "HPE SoC support"
> + help
> + This enables support for HPE ARM based SoC chips
> +if ARCH_HPE
> +
> +config ARCH_HPE_GXP
> + bool "HPE GXP SoC"
> + select ARM_VIC
> + select PINCTRL
> + select IRQ_DOMAIN
> + select GENERIC_IRQ_CHIP
> + select MULTI_IRQ_HANDLER
> + select SPARSE_IRQ
> + select CLKSRC_MMIO
> + depends on ARCH_MULTI_V7
Most of the symbols you select are implied by ARCH_MULTI_V7, so you
can remove them here.
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
We don't normally do custom mappings any more, these should come from
the device tree and get mapped by the corresponding drivers.
> +#define IOP_EHCI_USBCMD 0x0efe0010
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> + {
> + .virtual = (unsigned long)IOP_REGS_VIRT_BASE,
> + .pfn = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> + .length = IOP_REGS_SIZE,
> + .type = MT_DEVICE,
> + },
> +};
> +
> +void __init gxp_map_io(void)
> +{
> + iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
> +}
> +
> +static void __init gxp_dt_init(void)
> +{
> + //reset EHCI host controller for clear start
> + __raw_writel(0x00080002,
> + (void __iomem *)(IOP_REGS_VIRT_BASE + IOP_EHCI_USBCMD));
This belongs into the bootloader, or the EHCI driver, see the comment about a
custom compatible value above ;-)
> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> + pr_info("gpx restart");
> + __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}
This should be a reset driver, see
drivers/power/reset/syscon-reboot.c either as an example, or something you
can use directly.
Arnd
^ permalink raw reply
* Re: [PATCH v1 4/4] ARM: dts: imx6dl: plym2m, prtvt7, victgo: make use of new resistive-adc-touch driver
From: Shawn Guo @ 2022-01-26 2:05 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Mark Rutland, Rob Herring, Sascha Hauer, Thierry Reding,
Sam Ravnborg, David Airlie, Daniel Vetter, devicetree,
Fabio Estevam, linux-arm-kernel, linux-kernel, NXP Linux Team,
Pengutronix Kernel Team, David Jander, Robin van der Gracht,
dri-devel, Jonathan Cameron
In-Reply-To: <20220105110434.GG303@pengutronix.de>
On Wed, Jan 05, 2022 at 12:04:34PM +0100, Oleksij Rempel wrote:
> Hi Shawn,
>
> sorry for the delay, I just came back to work.
>
> On Mon, Dec 06, 2021 at 09:06:28AM +0800, Shawn Guo wrote:
> > On Mon, Nov 22, 2021 at 01:43:10PM +0100, Oleksij Rempel wrote:
> > > The tsc2046 is an ADC used as touchscreen controller. To share as mach
> > > code as possible, we should use it as actual ADC + virtual tochscreen
> > > controller.
> > > With this patch we make use of the new kernel IIO and HID infrastructure.
> > >
> > > Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> >
> > One space is enough in subject "victgo: make".
>
> done.
>
> > > ---
> > > arch/arm/boot/dts/imx6dl-plym2m.dts | 55 ++++++++++++++++++++---------
> > > arch/arm/boot/dts/imx6dl-prtvt7.dts | 53 ++++++++++++++++++++-------
> > > arch/arm/boot/dts/imx6dl-victgo.dts | 55 +++++++++++++++++++++--------
> > > 3 files changed, 120 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/imx6dl-plym2m.dts b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > > index 60fe5f14666e..e2afedae85cb 100644
> > > --- a/arch/arm/boot/dts/imx6dl-plym2m.dts
> > > +++ b/arch/arm/boot/dts/imx6dl-plym2m.dts
> > > @@ -101,6 +101,17 @@ reg_12v0: regulator-12v0 {
> > > regulator-min-microvolt = <12000000>;
> > > regulator-max-microvolt = <12000000>;
> > > };
> > > +
> > > + touchscreen {
> > > + compatible = "resistive-adc-touch";
> > > + io-channels = <&adc 1>, <&adc 3>, <&adc 4>, <&adc 5>;
> > > + io-channel-names = "y", "z1", "z2", "x";
> > > + touchscreen-min-pressure = <64687>;
> > > + touchscreen-inverted-x;
> > > + touchscreen-inverted-y;
> > > + touchscreen-x-plate-ohms = <300>;
> > > + touchscreen-y-plate-ohms = <800>;
> > > + };
> > > };
> > >
> > > &can1 {
> > > @@ -129,26 +140,38 @@ &ecspi2 {
> > > pinctrl-0 = <&pinctrl_ecspi2>;
> > > status = "okay";
> > >
> > > - touchscreen@0 {
> > > - compatible = "ti,tsc2046";
> > > + adc: adc@0 {
> >
> > Isn't label name "adc" too generic?
>
> I do not have strong opinion about this. Currently we have no
> restrictions for the node names:
> Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml
> Documentation/devicetree/bindings/iio/adc/adc.yaml
>
> I can name it touchscreen-adc@0 or something like this. What are your
> preferences?
I wasn't talking about node name but label.
Shawn
^ permalink raw reply
* Re: [PATCH] kbuild: unify cmd_copy and cmd_shipped
From: Masahiro Yamada @ 2022-01-26 2:19 UTC (permalink / raw)
To: Gabriel Krisman Bertazi
Cc: Nick Desaulniers, Linux Kbuild mailing list, Michal Marek,
Michal Simek, Rob Herring, DTML, Linux FS-devel Mailing List,
Linux Kernel Mailing List
In-Reply-To: <87h79rsbxe.fsf@collabora.com>
On Wed, Jan 26, 2022 at 7:11 AM Gabriel Krisman Bertazi
<krisman@collabora.com> wrote:
>
> Nick Desaulniers <ndesaulniers@google.com> writes:
>
> > On Mon, Jan 24, 2022 at 10:41 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
> >>
> >> cmd_copy and cmd_shipped have similar functionality. The difference is
> >> that cmd_copy uses 'cp' while cmd_shipped 'cat'.
> >>
> >> Unify them into cmd_copy because this macro name is more intuitive.
> >>
> >> Going forward, cmd_copy will use 'cat' to avoid the permission issue.
> >> I also thought of 'cp --no-preserve=mode' but this option is not
> >> mentioned in the POSIX spec [1], so I am keeping the 'cat' command.
> >>
> >> [1]: https://pubs.opengroup.org/onlinepubs/009695299/utilities/cp.html
> >> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> >> ---
> >>
> >> arch/microblaze/boot/Makefile | 2 +-
> >> arch/microblaze/boot/dts/Makefile | 2 +-
> >> fs/unicode/Makefile | 2 +-
> >> scripts/Makefile.lib | 12 ++++--------
> >> usr/Makefile | 4 ++--
> >> 5 files changed, 9 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
> >> index cff570a71946..2b42c370d574 100644
> >> --- a/arch/microblaze/boot/Makefile
> >> +++ b/arch/microblaze/boot/Makefile
> >> @@ -29,7 +29,7 @@ $(obj)/simpleImage.$(DTB).ub: $(obj)/simpleImage.$(DTB) FORCE
> >> $(call if_changed,uimage)
> >>
> >> $(obj)/simpleImage.$(DTB).unstrip: vmlinux FORCE
> >> - $(call if_changed,shipped)
> >> + $(call if_changed,copy)
> >>
> >> $(obj)/simpleImage.$(DTB).strip: vmlinux FORCE
> >> $(call if_changed,strip)
> >> diff --git a/arch/microblaze/boot/dts/Makefile b/arch/microblaze/boot/dts/Makefile
> >> index ef00dd30d19a..b84e2cbb20ee 100644
> >> --- a/arch/microblaze/boot/dts/Makefile
> >> +++ b/arch/microblaze/boot/dts/Makefile
> >> @@ -12,7 +12,7 @@ $(obj)/linked_dtb.o: $(obj)/system.dtb
> >> # Generate system.dtb from $(DTB).dtb
> >> ifneq ($(DTB),system)
> >> $(obj)/system.dtb: $(obj)/$(DTB).dtb
> >> - $(call if_changed,shipped)
> >> + $(call if_changed,copy)
> >> endif
> >> endif
> >>
> >> diff --git a/fs/unicode/Makefile b/fs/unicode/Makefile
> >> index 2f9d9188852b..74ae80fc3a36 100644
> >> --- a/fs/unicode/Makefile
> >> +++ b/fs/unicode/Makefile
> >> @@ -31,7 +31,7 @@ $(obj)/utf8data.c: $(obj)/mkutf8data $(filter %.txt, $(cmd_utf8data)) FORCE
> >> else
> >>
> >> $(obj)/utf8data.c: $(src)/utf8data.c_shipped FORCE
> >
> > do we want to retitle the _shipped suffix for this file to _copy now, too?
> > fs/unicode/Makefile:11
> > fs/unicode/Makefile:33
> > fs/unicode/Makefile:34
>
> I think _copy doesn't convey the sense that this is distributed with the
> kernel tree, even though it is also generated from in-tree sources.
> Even if that is not the original sense of _shipped (is it?), it makes
> sense to me that way, but _copy doesn't.
>
> The patch looks good to me, though.
>
> Reviewed-by: Gabriel Krisman Bertazi <krisman@collabora.com>
>
>
> >
I only renamed the action part (cmd_shipped -> cmd_copy)
because I thought it was clearer.
Actually I do not get the sense of _shipped pretty much, but
I think we can keep the file suffix part (utf8data.c_shipped) as is.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH v3 6/6] RISC-V: Do not use cpumask data structure for hartid bitmap
From: Atish Patra @ 2022-01-26 2:21 UTC (permalink / raw)
To: Jessica Clarke, Geert Uytterhoeven
Cc: Atish Patra, Linux Kernel Mailing List, Anup Patel, Albert Ou,
Damien Le Moal, devicetree, Jisheng Zhang, Krzysztof Kozlowski,
linux-riscv, Palmer Dabbelt, Paul Walmsley, Rob Herring
In-Reply-To: <1AA3005C-E9C8-4E4B-900D-DD48B37CEA41@jrtc27.com>
On Tue, Jan 25, 2022 at 2:26 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> On 20 Jan 2022, at 09:09, Atish Patra <atishp@rivosinc.com> wrote:
> >
> > Currently, SBI APIs accept a hartmask that is generated from struct
> > cpumask. Cpumask data structure can hold upto NR_CPUs value. Thus, it
> > is not the correct data structure for hartids as it can be higher
> > than NR_CPUs for platforms with sparse or discontguous hartids.
> >
> > Remove all association between hartid mask and struct cpumask.
> >
> > Reviewed-by: Anup Patel <anup@brainfault.org> (For Linux RISC-V changes)
> > Acked-by: Anup Patel <anup@brainfault.org> (For KVM RISC-V changes)
> > Signed-off-by: Atish Patra <atishp@rivosinc.com>
> > ---
> > arch/riscv/include/asm/sbi.h | 19 +--
> > arch/riscv/include/asm/smp.h | 2 -
> > arch/riscv/kernel/sbi.c | 189 +++++++++++++++++-------------
> > arch/riscv/kernel/setup.c | 10 --
> > arch/riscv/kernel/smpboot.c | 2 +-
> > arch/riscv/kvm/mmu.c | 4 +-
> > arch/riscv/kvm/vcpu_sbi_replace.c | 11 +-
> > arch/riscv/kvm/vcpu_sbi_v01.c | 11 +-
> > arch/riscv/kvm/vmid.c | 4 +-
> > arch/riscv/mm/cacheflush.c | 5 +-
> > arch/riscv/mm/tlbflush.c | 9 +-
> > 11 files changed, 130 insertions(+), 136 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > index 26ba6f2d7a40..d1c37479d828 100644
> > --- a/arch/riscv/include/asm/sbi.h
> > +++ b/arch/riscv/include/asm/sbi.h
> > @@ -8,6 +8,7 @@
> > #define _ASM_RISCV_SBI_H
> >
> > #include <linux/types.h>
> > +#include <linux/cpumask.h>
> >
> > #ifdef CONFIG_RISCV_SBI
> > enum sbi_ext_id {
> > @@ -128,27 +129,27 @@ long sbi_get_mimpid(void);
> > void sbi_set_timer(uint64_t stime_value);
> > void sbi_shutdown(void);
> > void sbi_clear_ipi(void);
> > -int sbi_send_ipi(const unsigned long *hart_mask);
> > -int sbi_remote_fence_i(const unsigned long *hart_mask);
> > -int sbi_remote_sfence_vma(const unsigned long *hart_mask,
> > +int sbi_send_ipi(const struct cpumask *cpu_mask);
> > +int sbi_remote_fence_i(const struct cpumask *cpu_mask);
> > +int sbi_remote_sfence_vma(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size);
> >
> > -int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
> > +int sbi_remote_sfence_vma_asid(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size,
> > unsigned long asid);
> > -int sbi_remote_hfence_gvma(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_gvma(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size);
> > -int sbi_remote_hfence_gvma_vmid(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_gvma_vmid(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size,
> > unsigned long vmid);
> > -int sbi_remote_hfence_vvma(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_vvma(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size);
> > -int sbi_remote_hfence_vvma_asid(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_vvma_asid(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size,
> > unsigned long asid);
> > @@ -183,7 +184,7 @@ static inline unsigned long sbi_mk_version(unsigned long major,
> >
> > int sbi_err_map_linux_errno(int err);
> > #else /* CONFIG_RISCV_SBI */
> > -static inline int sbi_remote_fence_i(const unsigned long *hart_mask) { return -1; }
> > +static inline int sbi_remote_fence_i(const struct cpumask *cpu_mask) { return -1; }
> > static inline void sbi_init(void) {}
> > #endif /* CONFIG_RISCV_SBI */
> > #endif /* _ASM_RISCV_SBI_H */
> > diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> > index 6ad749f42807..23170c933d73 100644
> > --- a/arch/riscv/include/asm/smp.h
> > +++ b/arch/riscv/include/asm/smp.h
> > @@ -92,8 +92,6 @@ static inline void riscv_clear_ipi(void)
> >
> > #endif /* CONFIG_SMP */
> >
> > -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out);
> > -
> > #if defined(CONFIG_HOTPLUG_CPU) && (CONFIG_SMP)
> > bool cpu_has_hotplug(unsigned int cpu);
> > #else
> > diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
> > index 9a84f0cb5175..f72527fcb347 100644
> > --- a/arch/riscv/kernel/sbi.c
> > +++ b/arch/riscv/kernel/sbi.c
> > @@ -16,8 +16,8 @@ unsigned long sbi_spec_version __ro_after_init = SBI_SPEC_VERSION_DEFAULT;
> > EXPORT_SYMBOL(sbi_spec_version);
> >
> > static void (*__sbi_set_timer)(uint64_t stime) __ro_after_init;
> > -static int (*__sbi_send_ipi)(const unsigned long *hart_mask) __ro_after_init;
> > -static int (*__sbi_rfence)(int fid, const unsigned long *hart_mask,
> > +static int (*__sbi_send_ipi)(const struct cpumask *cpu_mask) __ro_after_init;
> > +static int (*__sbi_rfence)(int fid, const struct cpumask *cpu_mask,
> > unsigned long start, unsigned long size,
> > unsigned long arg4, unsigned long arg5) __ro_after_init;
> >
> > @@ -67,6 +67,30 @@ int sbi_err_map_linux_errno(int err)
> > EXPORT_SYMBOL(sbi_err_map_linux_errno);
> >
> > #ifdef CONFIG_RISCV_SBI_V01
> > +static unsigned long __sbi_v01_cpumask_to_hartmask(const struct cpumask *cpu_mask)
> > +{
> > + unsigned long cpuid, hartid;
> > + unsigned long hmask = 0;
> > +
> > + /*
> > + * There is no maximum hartid concept in RISC-V and NR_CPUS must not be
> > + * associated with hartid. As SBI v0.1 is only kept for backward compatibility
> > + * and will be removed in the future, there is no point in supporting hartid
> > + * greater than BITS_PER_LONG (32 for RV32 and 64 for RV64). Ideally, SBI v0.2
> > + * should be used for platforms with hartid greater than BITS_PER_LONG.
> > + */
> > + for_each_cpu(cpuid, cpu_mask) {
> > + hartid = cpuid_to_hartid_map(cpuid);
> > + if (hartid >= BITS_PER_LONG) {
> > + pr_warn("Unable to send any request to hartid > BITS_PER_LONG for SBI v0.1\n");
> > + break;
> > + }
> > + hmask |= 1 << hartid;
>
> This should be 1UL otherwise hartid 31 and up cause UB.
>
Yeah. Thanks for catching it.
> > + }
> > +
> > + return hmask;
> > +}
> > +
> > /**
> > * sbi_console_putchar() - Writes given character to the console device.
> > * @ch: The data to be written to the console.
> > @@ -132,33 +156,44 @@ static void __sbi_set_timer_v01(uint64_t stime_value)
> > #endif
> > }
> >
> > -static int __sbi_send_ipi_v01(const unsigned long *hart_mask)
> > +static int __sbi_send_ipi_v01(const struct cpumask *cpu_mask)
> > {
> > - sbi_ecall(SBI_EXT_0_1_SEND_IPI, 0, (unsigned long)hart_mask,
> > + unsigned long hart_mask;
> > +
> > + if (!cpu_mask)
> > + cpu_mask = cpu_online_mask;
> > + hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
> > +
> > + sbi_ecall(SBI_EXT_0_1_SEND_IPI, 0, (unsigned long)(&hart_mask),
> > 0, 0, 0, 0, 0);
> > return 0;
> > }
> >
> > -static int __sbi_rfence_v01(int fid, const unsigned long *hart_mask,
> > +static int __sbi_rfence_v01(int fid, const struct cpumask *cpu_mask,
> > unsigned long start, unsigned long size,
> > unsigned long arg4, unsigned long arg5)
> > {
> > int result = 0;
> > + unsigned long hart_mask;
> > +
> > + if (!cpu_mask)
> > + cpu_mask = cpu_online_mask;
> > + hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
> >
> > /* v0.2 function IDs are equivalent to v0.1 extension IDs */
> > switch (fid) {
> > case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> > sbi_ecall(SBI_EXT_0_1_REMOTE_FENCE_I, 0,
> > - (unsigned long)hart_mask, 0, 0, 0, 0, 0);
> > + (unsigned long)&hart_mask, 0, 0, 0, 0, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA:
> > sbi_ecall(SBI_EXT_0_1_REMOTE_SFENCE_VMA, 0,
> > - (unsigned long)hart_mask, start, size,
> > + (unsigned long)&hart_mask, start, size,
> > 0, 0, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID:
> > sbi_ecall(SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID, 0,
> > - (unsigned long)hart_mask, start, size,
> > + (unsigned long)&hart_mask, start, size,
> > arg4, 0, 0);
> > break;
> > default:
> > @@ -180,7 +215,7 @@ static void __sbi_set_timer_v01(uint64_t stime_value)
> > sbi_major_version(), sbi_minor_version());
> > }
> >
> > -static int __sbi_send_ipi_v01(const unsigned long *hart_mask)
> > +static int __sbi_send_ipi_v01(const struct cpumask *cpu_mask)
> > {
> > pr_warn("IPI extension is not available in SBI v%lu.%lu\n",
> > sbi_major_version(), sbi_minor_version());
> > @@ -188,7 +223,7 @@ static int __sbi_send_ipi_v01(const unsigned long *hart_mask)
> > return 0;
> > }
> >
> > -static int __sbi_rfence_v01(int fid, const unsigned long *hart_mask,
> > +static int __sbi_rfence_v01(int fid, const struct cpumask *cpu_mask,
> > unsigned long start, unsigned long size,
> > unsigned long arg4, unsigned long arg5)
> > {
> > @@ -212,37 +247,33 @@ static void __sbi_set_timer_v02(uint64_t stime_value)
> > #endif
> > }
> >
> > -static int __sbi_send_ipi_v02(const unsigned long *hart_mask)
> > +static int __sbi_send_ipi_v02(const struct cpumask *cpu_mask)
> > {
> > - unsigned long hartid, hmask_val, hbase;
> > - struct cpumask tmask;
> > + unsigned long hartid, cpuid, hmask = 0, hbase = 0;
> > struct sbiret ret = {0};
> > int result;
> >
> > - if (!hart_mask || !(*hart_mask)) {
> > - riscv_cpuid_to_hartid_mask(cpu_online_mask, &tmask);
> > - hart_mask = cpumask_bits(&tmask);
> > - }
> > + if (!cpu_mask)
> > + cpu_mask = cpu_online_mask;
>
> This is a change in behaviour. Are you sure nothing passes an empty mask?
>
The change in behavior is not intentional.
I am yet to reproduce it on my end.
@Geert Uytterhoeven: can you please try the below diff on your end.
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index f72527fcb347..ca1c617407b4 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -85,7 +85,7 @@ static unsigned long
__sbi_v01_cpumask_to_hartmask(const struct cpumask *cpu_mas
pr_warn("Unable to send any request to hartid
> BITS_PER_LONG for SBI v0.1\n");
break;
}
- hmask |= 1 << hartid;
+ hmask |= 1UL << hartid;
}
return hmask;
@@ -160,7 +160,7 @@ static int __sbi_send_ipi_v01(const struct cpumask
*cpu_mask)
{
unsigned long hart_mask;
- if (!cpu_mask)
+ if (!cpu_mask || cpumask_empty(cpu_mask))
cpu_mask = cpu_online_mask;
hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
@@ -176,7 +176,7 @@ static int __sbi_rfence_v01(int fid, const struct
cpumask *cpu_mask,
int result = 0;
unsigned long hart_mask;
- if (!cpu_mask)
+ if (!cpu_mask || cpumask_empty(cpu_mask))
cpu_mask = cpu_online_mask;
hart_mask = __sbi_v01_cpumask_to_hartmask(cpu_mask);
@@ -253,7 +253,7 @@ static int __sbi_send_ipi_v02(const struct cpumask
*cpu_mask)
struct sbiret ret = {0};
int result;
- if (!cpu_mask)
+ if (!cpu_mask || cpumask_empty(cpu_mask))
cpu_mask = cpu_online_mask;
for_each_cpu(cpuid, cpu_mask) {
@@ -347,7 +347,7 @@ static int __sbi_rfence_v02(int fid, const struct
cpumask *cpu_mask,
unsigned long hartid, cpuid, hmask = 0, hbase = 0;
int result;
- if (!cpu_mask)
+ if (!cpu_mask || cpumask_empty(cpu_mask))
cpu_mask = cpu_online_mask;
> > - hmask_val = 0;
> > - hbase = 0;
> > - for_each_set_bit(hartid, hart_mask, NR_CPUS) {
> > - if (hmask_val && ((hbase + BITS_PER_LONG) <= hartid)) {
> > + for_each_cpu(cpuid, cpu_mask) {
> > + hartid = cpuid_to_hartid_map(cpuid);
> > + if (hmask && ((hbase + BITS_PER_LONG) <= hartid)) {
> > ret = sbi_ecall(SBI_EXT_IPI, SBI_EXT_IPI_SEND_IPI,
> > - hmask_val, hbase, 0, 0, 0, 0);
> > + hmask, hbase, 0, 0, 0, 0);
> > if (ret.error)
> > goto ecall_failed;
> > - hmask_val = 0;
> > + hmask = 0;
> > hbase = 0;
> > }
> > - if (!hmask_val)
> > + if (!hmask)
> > hbase = hartid;
> > - hmask_val |= 1UL << (hartid - hbase);
> > + hmask |= 1UL << (hartid - hbase);
> > }
> >
> > - if (hmask_val) {
> > + if (hmask) {
> > ret = sbi_ecall(SBI_EXT_IPI, SBI_EXT_IPI_SEND_IPI,
> > - hmask_val, hbase, 0, 0, 0, 0);
> > + hmask, hbase, 0, 0, 0, 0);
> > if (ret.error)
> > goto ecall_failed;
> > }
> > @@ -252,11 +283,11 @@ static int __sbi_send_ipi_v02(const unsigned long *hart_mask)
> > ecall_failed:
> > result = sbi_err_map_linux_errno(ret.error);
> > pr_err("%s: hbase = [%lu] hmask = [0x%lx] failed (error [%d])\n",
> > - __func__, hbase, hmask_val, result);
> > + __func__, hbase, hmask, result);
> > return result;
> > }
> >
> > -static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask_val,
> > +static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask,
> > unsigned long hbase, unsigned long start,
> > unsigned long size, unsigned long arg4,
> > unsigned long arg5)
> > @@ -267,31 +298,31 @@ static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask_val,
> >
> > switch (fid) {
> > case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, 0, 0, 0, 0);
> > + ret = sbi_ecall(ext, fid, hmask, hbase, 0, 0, 0, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> > + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> > size, 0, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> > + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> > size, arg4, 0);
> > break;
> >
> > case SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> > + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> > size, 0, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> > + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> > size, arg4, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> > + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> > size, 0, 0);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID:
> > - ret = sbi_ecall(ext, fid, hmask_val, hbase, start,
> > + ret = sbi_ecall(ext, fid, hmask, hbase, start,
> > size, arg4, 0);
> > break;
> > default:
> > @@ -303,43 +334,39 @@ static int __sbi_rfence_v02_call(unsigned long fid, unsigned long hmask_val,
> > if (ret.error) {
> > result = sbi_err_map_linux_errno(ret.error);
> > pr_err("%s: hbase = [%lu] hmask = [0x%lx] failed (error [%d])\n",
> > - __func__, hbase, hmask_val, result);
> > + __func__, hbase, hmask, result);
> > }
> >
> > return result;
> > }
> >
> > -static int __sbi_rfence_v02(int fid, const unsigned long *hart_mask,
> > +static int __sbi_rfence_v02(int fid, const struct cpumask *cpu_mask,
> > unsigned long start, unsigned long size,
> > unsigned long arg4, unsigned long arg5)
> > {
> > - unsigned long hmask_val, hartid, hbase;
> > - struct cpumask tmask;
> > + unsigned long hartid, cpuid, hmask = 0, hbase = 0;
> > int result;
> >
> > - if (!hart_mask || !(*hart_mask)) {
> > - riscv_cpuid_to_hartid_mask(cpu_online_mask, &tmask);
> > - hart_mask = cpumask_bits(&tmask);
> > - }
> > + if (!cpu_mask)
> > + cpu_mask = cpu_online_mask;
>
> As with __sbi_send_ipi_v02.
>
> Jess
>
> > - hmask_val = 0;
> > - hbase = 0;
> > - for_each_set_bit(hartid, hart_mask, NR_CPUS) {
> > - if (hmask_val && ((hbase + BITS_PER_LONG) <= hartid)) {
> > - result = __sbi_rfence_v02_call(fid, hmask_val, hbase,
> > + for_each_cpu(cpuid, cpu_mask) {
> > + hartid = cpuid_to_hartid_map(cpuid);
> > + if (hmask && ((hbase + BITS_PER_LONG) <= hartid)) {
> > + result = __sbi_rfence_v02_call(fid, hmask, hbase,
> > start, size, arg4, arg5);
> > if (result)
> > return result;
> > - hmask_val = 0;
> > + hmask = 0;
> > hbase = 0;
> > }
> > - if (!hmask_val)
> > + if (!hmask)
> > hbase = hartid;
> > - hmask_val |= 1UL << (hartid - hbase);
> > + hmask |= 1UL << (hartid - hbase);
> > }
> >
> > - if (hmask_val) {
> > - result = __sbi_rfence_v02_call(fid, hmask_val, hbase,
> > + if (hmask) {
> > + result = __sbi_rfence_v02_call(fid, hmask, hbase,
> > start, size, arg4, arg5);
> > if (result)
> > return result;
> > @@ -361,44 +388,44 @@ void sbi_set_timer(uint64_t stime_value)
> >
> > /**
> > * sbi_send_ipi() - Send an IPI to any hart.
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > *
> > * Return: 0 on success, appropriate linux error code otherwise.
> > */
> > -int sbi_send_ipi(const unsigned long *hart_mask)
> > +int sbi_send_ipi(const struct cpumask *cpu_mask)
> > {
> > - return __sbi_send_ipi(hart_mask);
> > + return __sbi_send_ipi(cpu_mask);
> > }
> > EXPORT_SYMBOL(sbi_send_ipi);
> >
> > /**
> > * sbi_remote_fence_i() - Execute FENCE.I instruction on given remote harts.
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > *
> > * Return: 0 on success, appropriate linux error code otherwise.
> > */
> > -int sbi_remote_fence_i(const unsigned long *hart_mask)
> > +int sbi_remote_fence_i(const struct cpumask *cpu_mask)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
> > - hart_mask, 0, 0, 0, 0);
> > + cpu_mask, 0, 0, 0, 0);
> > }
> > EXPORT_SYMBOL(sbi_remote_fence_i);
> >
> > /**
> > * sbi_remote_sfence_vma() - Execute SFENCE.VMA instructions on given remote
> > * harts for the specified virtual address range.
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > * @start: Start of the virtual address
> > * @size: Total size of the virtual address range.
> > *
> > * Return: 0 on success, appropriate linux error code otherwise.
> > */
> > -int sbi_remote_sfence_vma(const unsigned long *hart_mask,
> > +int sbi_remote_sfence_vma(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> > - hart_mask, start, size, 0, 0);
> > + cpu_mask, start, size, 0, 0);
> > }
> > EXPORT_SYMBOL(sbi_remote_sfence_vma);
> >
> > @@ -406,38 +433,38 @@ EXPORT_SYMBOL(sbi_remote_sfence_vma);
> > * sbi_remote_sfence_vma_asid() - Execute SFENCE.VMA instructions on given
> > * remote harts for a virtual address range belonging to a specific ASID.
> > *
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > * @start: Start of the virtual address
> > * @size: Total size of the virtual address range.
> > * @asid: The value of address space identifier (ASID).
> > *
> > * Return: 0 on success, appropriate linux error code otherwise.
> > */
> > -int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
> > +int sbi_remote_sfence_vma_asid(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size,
> > unsigned long asid)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> > - hart_mask, start, size, asid, 0);
> > + cpu_mask, start, size, asid, 0);
> > }
> > EXPORT_SYMBOL(sbi_remote_sfence_vma_asid);
> >
> > /**
> > * sbi_remote_hfence_gvma() - Execute HFENCE.GVMA instructions on given remote
> > * harts for the specified guest physical address range.
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > * @start: Start of the guest physical address
> > * @size: Total size of the guest physical address range.
> > *
> > * Return: None
> > */
> > -int sbi_remote_hfence_gvma(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_gvma(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > - hart_mask, start, size, 0, 0);
> > + cpu_mask, start, size, 0, 0);
> > }
> > EXPORT_SYMBOL_GPL(sbi_remote_hfence_gvma);
> >
> > @@ -445,38 +472,38 @@ EXPORT_SYMBOL_GPL(sbi_remote_hfence_gvma);
> > * sbi_remote_hfence_gvma_vmid() - Execute HFENCE.GVMA instructions on given
> > * remote harts for a guest physical address range belonging to a specific VMID.
> > *
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > * @start: Start of the guest physical address
> > * @size: Total size of the guest physical address range.
> > * @vmid: The value of guest ID (VMID).
> > *
> > * Return: 0 if success, Error otherwise.
> > */
> > -int sbi_remote_hfence_gvma_vmid(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_gvma_vmid(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size,
> > unsigned long vmid)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> > - hart_mask, start, size, vmid, 0);
> > + cpu_mask, start, size, vmid, 0);
> > }
> > EXPORT_SYMBOL(sbi_remote_hfence_gvma_vmid);
> >
> > /**
> > * sbi_remote_hfence_vvma() - Execute HFENCE.VVMA instructions on given remote
> > * harts for the current guest virtual address range.
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > * @start: Start of the current guest virtual address
> > * @size: Total size of the current guest virtual address range.
> > *
> > * Return: None
> > */
> > -int sbi_remote_hfence_vvma(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_vvma(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > - hart_mask, start, size, 0, 0);
> > + cpu_mask, start, size, 0, 0);
> > }
> > EXPORT_SYMBOL(sbi_remote_hfence_vvma);
> >
> > @@ -485,20 +512,20 @@ EXPORT_SYMBOL(sbi_remote_hfence_vvma);
> > * remote harts for current guest virtual address range belonging to a specific
> > * ASID.
> > *
> > - * @hart_mask: A cpu mask containing all the target harts.
> > + * @cpu_mask: A cpu mask containing all the target harts.
> > * @start: Start of the current guest virtual address
> > * @size: Total size of the current guest virtual address range.
> > * @asid: The value of address space identifier (ASID).
> > *
> > * Return: None
> > */
> > -int sbi_remote_hfence_vvma_asid(const unsigned long *hart_mask,
> > +int sbi_remote_hfence_vvma_asid(const struct cpumask *cpu_mask,
> > unsigned long start,
> > unsigned long size,
> > unsigned long asid)
> > {
> > return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> > - hart_mask, start, size, asid, 0);
> > + cpu_mask, start, size, asid, 0);
> > }
> > EXPORT_SYMBOL(sbi_remote_hfence_vvma_asid);
> >
> > @@ -591,11 +618,7 @@ long sbi_get_mimpid(void)
> >
> > static void sbi_send_cpumask_ipi(const struct cpumask *target)
> > {
> > - struct cpumask hartid_mask;
> > -
> > - riscv_cpuid_to_hartid_mask(target, &hartid_mask);
> > -
> > - sbi_send_ipi(cpumask_bits(&hartid_mask));
> > + sbi_send_ipi(target);
> > }
> >
> > static const struct riscv_ipi_ops sbi_ipi_ops = {
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 63241abe84eb..b42bfdc67482 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -59,16 +59,6 @@ atomic_t hart_lottery __section(".sdata")
> > unsigned long boot_cpu_hartid;
> > static DEFINE_PER_CPU(struct cpu, cpu_devices);
> >
> > -void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask *out)
> > -{
> > - int cpu;
> > -
> > - cpumask_clear(out);
> > - for_each_cpu(cpu, in)
> > - cpumask_set_cpu(cpuid_to_hartid_map(cpu), out);
> > -}
> > -EXPORT_SYMBOL_GPL(riscv_cpuid_to_hartid_mask);
> > -
> > /*
> > * Place kernel memory regions on the resource tree so that
> > * kexec-tools can retrieve them from /proc/iomem. While there
> > diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> > index bd82375db51a..622f226454d5 100644
> > --- a/arch/riscv/kernel/smpboot.c
> > +++ b/arch/riscv/kernel/smpboot.c
> > @@ -96,7 +96,7 @@ void __init setup_smp(void)
> > if (cpuid >= NR_CPUS) {
> > pr_warn("Invalid cpuid [%d] for hartid [%d]\n",
> > cpuid, hart);
> > - break;
> > + continue;
> > }
> >
> > cpuid_to_hartid_map(cpuid) = hart;
> > diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c
> > index 9af67dbdc66a..f80a34fbf102 100644
> > --- a/arch/riscv/kvm/mmu.c
> > +++ b/arch/riscv/kvm/mmu.c
> > @@ -114,7 +114,6 @@ static bool stage2_get_leaf_entry(struct kvm *kvm, gpa_t addr,
> >
> > static void stage2_remote_tlb_flush(struct kvm *kvm, u32 level, gpa_t addr)
> > {
> > - struct cpumask hmask;
> > unsigned long size = PAGE_SIZE;
> > struct kvm_vmid *vmid = &kvm->arch.vmid;
> >
> > @@ -127,8 +126,7 @@ static void stage2_remote_tlb_flush(struct kvm *kvm, u32 level, gpa_t addr)
> > * where the Guest/VM is running.
> > */
> > preempt_disable();
> > - riscv_cpuid_to_hartid_mask(cpu_online_mask, &hmask);
> > - sbi_remote_hfence_gvma_vmid(cpumask_bits(&hmask), addr, size,
> > + sbi_remote_hfence_gvma_vmid(cpu_online_mask, addr, size,
> > READ_ONCE(vmid->vmid));
> > preempt_enable();
> > }
> > diff --git a/arch/riscv/kvm/vcpu_sbi_replace.c b/arch/riscv/kvm/vcpu_sbi_replace.c
> > index 00036b7f83b9..1bc0608a5bfd 100644
> > --- a/arch/riscv/kvm/vcpu_sbi_replace.c
> > +++ b/arch/riscv/kvm/vcpu_sbi_replace.c
> > @@ -82,7 +82,7 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run
> > {
> > int ret = 0;
> > unsigned long i;
> > - struct cpumask cm, hm;
> > + struct cpumask cm;
> > struct kvm_vcpu *tmp;
> > struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
> > unsigned long hmask = cp->a0;
> > @@ -90,7 +90,6 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run
> > unsigned long funcid = cp->a6;
> >
> > cpumask_clear(&cm);
> > - cpumask_clear(&hm);
> > kvm_for_each_vcpu(i, tmp, vcpu->kvm) {
> > if (hbase != -1UL) {
> > if (tmp->vcpu_id < hbase)
> > @@ -103,17 +102,15 @@ static int kvm_sbi_ext_rfence_handler(struct kvm_vcpu *vcpu, struct kvm_run *run
> > cpumask_set_cpu(tmp->cpu, &cm);
> > }
> >
> > - riscv_cpuid_to_hartid_mask(&cm, &hm);
> > -
> > switch (funcid) {
> > case SBI_EXT_RFENCE_REMOTE_FENCE_I:
> > - ret = sbi_remote_fence_i(cpumask_bits(&hm));
> > + ret = sbi_remote_fence_i(&cm);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA:
> > - ret = sbi_remote_hfence_vvma(cpumask_bits(&hm), cp->a2, cp->a3);
> > + ret = sbi_remote_hfence_vvma(&cm, cp->a2, cp->a3);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID:
> > - ret = sbi_remote_hfence_vvma_asid(cpumask_bits(&hm), cp->a2,
> > + ret = sbi_remote_hfence_vvma_asid(&cm, cp->a2,
> > cp->a3, cp->a4);
> > break;
> > case SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA:
> > diff --git a/arch/riscv/kvm/vcpu_sbi_v01.c b/arch/riscv/kvm/vcpu_sbi_v01.c
> > index 4c7e13ec9ccc..07e2de14433a 100644
> > --- a/arch/riscv/kvm/vcpu_sbi_v01.c
> > +++ b/arch/riscv/kvm/vcpu_sbi_v01.c
> > @@ -38,7 +38,7 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
> > int i, ret = 0;
> > u64 next_cycle;
> > struct kvm_vcpu *rvcpu;
> > - struct cpumask cm, hm;
> > + struct cpumask cm;
> > struct kvm *kvm = vcpu->kvm;
> > struct kvm_cpu_context *cp = &vcpu->arch.guest_context;
> >
> > @@ -101,15 +101,12 @@ static int kvm_sbi_ext_v01_handler(struct kvm_vcpu *vcpu, struct kvm_run *run,
> > continue;
> > cpumask_set_cpu(rvcpu->cpu, &cm);
> > }
> > - riscv_cpuid_to_hartid_mask(&cm, &hm);
> > if (cp->a7 == SBI_EXT_0_1_REMOTE_FENCE_I)
> > - ret = sbi_remote_fence_i(cpumask_bits(&hm));
> > + ret = sbi_remote_fence_i(&cm);
> > else if (cp->a7 == SBI_EXT_0_1_REMOTE_SFENCE_VMA)
> > - ret = sbi_remote_hfence_vvma(cpumask_bits(&hm),
> > - cp->a1, cp->a2);
> > + ret = sbi_remote_hfence_vvma(&cm, cp->a1, cp->a2);
> > else
> > - ret = sbi_remote_hfence_vvma_asid(cpumask_bits(&hm),
> > - cp->a1, cp->a2, cp->a3);
> > + ret = sbi_remote_hfence_vvma_asid(&cm, cp->a1, cp->a2, cp->a3);
> > break;
> > default:
> > ret = -EINVAL;
> > diff --git a/arch/riscv/kvm/vmid.c b/arch/riscv/kvm/vmid.c
> > index 807228f8f409..2fa4f7b1813d 100644
> > --- a/arch/riscv/kvm/vmid.c
> > +++ b/arch/riscv/kvm/vmid.c
> > @@ -67,7 +67,6 @@ void kvm_riscv_stage2_vmid_update(struct kvm_vcpu *vcpu)
> > {
> > unsigned long i;
> > struct kvm_vcpu *v;
> > - struct cpumask hmask;
> > struct kvm_vmid *vmid = &vcpu->kvm->arch.vmid;
> >
> > if (!kvm_riscv_stage2_vmid_ver_changed(vmid))
> > @@ -102,8 +101,7 @@ void kvm_riscv_stage2_vmid_update(struct kvm_vcpu *vcpu)
> > * running, we force VM exits on all host CPUs using IPI and
> > * flush all Guest TLBs.
> > */
> > - riscv_cpuid_to_hartid_mask(cpu_online_mask, &hmask);
> > - sbi_remote_hfence_gvma(cpumask_bits(&hmask), 0, 0);
> > + sbi_remote_hfence_gvma(cpu_online_mask, 0, 0);
> > }
> >
> > vmid->vmid = vmid_next;
> > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c
> > index 89f81067e09e..6cb7d96ad9c7 100644
> > --- a/arch/riscv/mm/cacheflush.c
> > +++ b/arch/riscv/mm/cacheflush.c
> > @@ -67,10 +67,7 @@ void flush_icache_mm(struct mm_struct *mm, bool local)
> > */
> > smp_mb();
> > } else if (IS_ENABLED(CONFIG_RISCV_SBI)) {
> > - cpumask_t hartid_mask;
> > -
> > - riscv_cpuid_to_hartid_mask(&others, &hartid_mask);
> > - sbi_remote_fence_i(cpumask_bits(&hartid_mask));
> > + sbi_remote_fence_i(&others);
> > } else {
> > on_each_cpu_mask(&others, ipi_remote_fence_i, NULL, 1);
> > }
> > diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
> > index 64f8201237c2..37ed760d007c 100644
> > --- a/arch/riscv/mm/tlbflush.c
> > +++ b/arch/riscv/mm/tlbflush.c
> > @@ -32,7 +32,6 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
> > unsigned long size, unsigned long stride)
> > {
> > struct cpumask *cmask = mm_cpumask(mm);
> > - struct cpumask hmask;
> > unsigned int cpuid;
> > bool broadcast;
> >
> > @@ -46,9 +45,7 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
> > unsigned long asid = atomic_long_read(&mm->context.id);
> >
> > if (broadcast) {
> > - riscv_cpuid_to_hartid_mask(cmask, &hmask);
> > - sbi_remote_sfence_vma_asid(cpumask_bits(&hmask),
> > - start, size, asid);
> > + sbi_remote_sfence_vma_asid(cmask, start, size, asid);
> > } else if (size <= stride) {
> > local_flush_tlb_page_asid(start, asid);
> > } else {
> > @@ -56,9 +53,7 @@ static void __sbi_tlb_flush_range(struct mm_struct *mm, unsigned long start,
> > }
> > } else {
> > if (broadcast) {
> > - riscv_cpuid_to_hartid_mask(cmask, &hmask);
> > - sbi_remote_sfence_vma(cpumask_bits(&hmask),
> > - start, size);
> > + sbi_remote_sfence_vma(cmask, start, size);
> > } else if (size <= stride) {
> > local_flush_tlb_page(start);
> > } else {
> > --
> > 2.30.2
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
--
Regards,
Atish
^ permalink raw reply related
* Re: [PATCH v7 4/8] arm64: dts: imx8mm: Add the pcie phy support
From: Shawn Guo @ 2022-01-26 2:25 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, bhelgaas, lorenzo.pieralisi, marcel.ziswiler, tharvey,
kishon, vkoul, robh, galak, linux-phy, devicetree, linux-pci,
linux-arm-kernel, linux-kernel, kernel, linux-imx
In-Reply-To: <1638432158-4119-5-git-send-email-hongxing.zhu@nxp.com>
On Thu, Dec 02, 2021 at 04:02:34PM +0800, Richard Zhu wrote:
> Add the PCIe PHY support on iMX8MM platforms.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Reviewed-by: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Tim Harvey <tharvey@gateworks.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v7 6/8] arm64: dts: imx8mm: Add the pcie support
From: Shawn Guo @ 2022-01-26 2:25 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, bhelgaas, lorenzo.pieralisi, marcel.ziswiler, tharvey,
kishon, vkoul, robh, galak, linux-phy, devicetree, linux-pci,
linux-arm-kernel, linux-kernel, kernel, linux-imx
In-Reply-To: <1638432158-4119-7-git-send-email-hongxing.zhu@nxp.com>
On Thu, Dec 02, 2021 at 04:02:36PM +0800, Richard Zhu wrote:
> Add the PCIe support on i.MX8MM platforms.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Reviewed-by: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Tim Harvey <tharvey@gateworks.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v7 7/8] arm64: dts: imx8mm-evk: Add the pcie support on imx8mm evk board
From: Shawn Guo @ 2022-01-26 2:26 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, bhelgaas, lorenzo.pieralisi, marcel.ziswiler, tharvey,
kishon, vkoul, robh, galak, linux-phy, devicetree, linux-pci,
linux-arm-kernel, linux-kernel, kernel, linux-imx
In-Reply-To: <1638432158-4119-8-git-send-email-hongxing.zhu@nxp.com>
On Thu, Dec 02, 2021 at 04:02:37PM +0800, Richard Zhu wrote:
> Add the PCIe support on iMX8MM EVK boards.
> And set the default reference clock mode.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
> Reviewed-by: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Tim Harvey <tharvey@gateworks.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 55 +++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> index e033d0257b5a..87a30daf0b3c 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi
> @@ -5,6 +5,7 @@
>
> /dts-v1/;
>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> #include <dt-bindings/usb/pd.h>
> #include "imx8mm.dtsi"
>
> @@ -30,6 +31,23 @@ status {
> };
> };
>
> + pcie0_refclk: pcie0-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
Incorrect indent. Fixed them up and applied.
Shawn
> + };
> +
> + reg_pcie0: regulator-pcie {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie0_reg>;
> + regulator-name = "MPCIE_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> reg_usdhc2_vmmc: regulator-usdhc2 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> @@ -289,6 +307,30 @@ pca6416: gpio@20 {
> };
> };
>
> +&pcie_phy {
> + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
> + fsl,tx-deemph-gen1 = <0x2d>;
> + fsl,tx-deemph-gen2 = <0xf>;
> + clocks = <&pcie0_refclk>;
> + status = "okay";
> +};
> +
> +&pcie0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie0>;
> + reset-gpio = <&gpio4 21 GPIO_ACTIVE_LOW>;
> + clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&clk IMX8MM_CLK_PCIE1_AUX>,
> + <&pcie0_refclk>;
> + clock-names = "pcie", "pcie_aux", "pcie_bus";
> + assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
> + <&clk IMX8MM_CLK_PCIE1_CTRL>;
> + assigned-clock-rates = <10000000>, <250000000>;
> + assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
> + <&clk IMX8MM_SYS_PLL2_250M>;
> + vpcie-supply = <®_pcie0>;
> + status = "okay";
> +};
> +
> &sai3 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_sai3>;
> @@ -406,6 +448,19 @@ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3
> >;
> };
>
> + pinctrl_pcie0: pcie0grp {
> + fsl,pins = <
> + MX8MM_IOMUXC_I2C4_SCL_PCIE1_CLKREQ_B 0x61
> + MX8MM_IOMUXC_SAI2_RXFS_GPIO4_IO21 0x41
> + >;
> + };
> +
> + pinctrl_pcie0_reg: pcie0reggrp {
> + fsl,pins = <
> + MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x41
> + >;
> + };
> +
> pinctrl_pmic: pmicirqgrp {
> fsl,pins = <
> MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x141
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: qcom: sc7280: Add herobrine-r1
From: Bjorn Andersson @ 2022-01-26 3:01 UTC (permalink / raw)
To: Doug Anderson
Cc: Stephen Boyd, Konrad Dybcio, kgodara, Matthias Kaehlcke,
Sibi Sankar, Prasad Malisetty, quic_rjendra, Andy Gross,
Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, LKML
In-Reply-To: <CAD=FV=UcpKaLQ31CGKUnaNnZcYnM4N_t8VC43FPGktoYDiMfsw@mail.gmail.com>
On Tue 25 Jan 15:46 PST 2022, Doug Anderson wrote:
> Hi,
>
> On Tue, Jan 25, 2022 at 2:58 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Douglas Anderson (2022-01-25 14:44:22)
> > > diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> > > new file mode 100644
> > > index 000000000000..f95273052da0
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r1.dts
> > > @@ -0,0 +1,313 @@
> > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > > +/*
> > > + * Google Herobrine board device tree source
> > > + *
> > > + * Copyright 2022 Google LLC.
> > > + */
> > > +
> > > +/dts-v1/;
> > > +
> > > +#include "sc7280-herobrine.dtsi"
> > > +
> > > +/ {
> > > + model = "Google Herobrine (rev1+)";
> > > + compatible = "google,herobrine", "qcom,sc7280";
> >
> > Can we stop adding "qcom,sc7280" to the board compatible string? It
> > looks out of place. It's the compatible for the SoC and should really be
> > the compatible for the /soc node.
>
> I don't have any objections, but I feel like this is the type of thing
> I'd like Bjorn to have the final say on. What say you, Bjorn?
>
One practical case I can think of right away, where this matters is in
cpufreq-dt-plat.c where we blocklist qcom,sc7280.
I don't know if we rely on this in any other places, but I'm not keen on
seeing a bunch of board-specific compatibles sprinkled throughout the
implementation - it's annoying enough having to add each platform to
these drivers.
Regards,
Bjorn
>
> > > + pp3300_left_in_mlb: pp3300-left-in-mlb {
> >
> > Sometimes '-regulator' is left out. Is that intentional? I suppose it
> > would be better if every node had regulator postfix, but it may be too
> > long of a node name?
>
> Huh, you're right. No, it's not intentional. It looks like it was that
> way on herobrine-rev0 too... It also looks like it's missing on
> "pp3300-hub" on trogdor.
>
> Happy to add "-regulator" in the herobrine / trogdor nodes that need
> it. I'll probably do it as a follow-on patch if that works OK? Then I
> can just clean them all up at once...
>
> -Doug
^ permalink raw reply
* [PATCH v2 0/2] Add support for Azoteq IQS7222A/B/C
From: Jeff LaBundy @ 2022-01-26 3:07 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt; +Cc: linux-input, devicetree, Jeff LaBundy
This series introduces support for the Azoteq IQS7222A, IQS7222B and
IQS7222C capacitive touch controllers. This new family of devices is
similar to the IQS269A, a key difference being the delineation between
conversion cycles and sensing channels.
A cycle represents the charge transfer mechanism shared by up to two
channels. Channels may represent keys or switches and have two levels
of detection (proximity and touch).
Each device has its own unique features including channel count, slider
or wheel support, and Hall-effect sensing. The driver is demonstrated
with each device in the following videos:
IQS7222A: https://youtu.be/SyHhe9pSr8c
IQS7222B: https://youtu.be/R9Yd8yFPmN8
IQS7222C: https://youtu.be/-ahg52Co5zo
Like the IQS269A and its close cousin IQS626A, the IQS7222A/B/C are
highly configurable and follow the same general structure in terms of
how their bindings are represented.
Jeff LaBundy (2):
dt-bindings: input: Add bindings for Azoteq IQS7222A/B/C
Input: add support for Azoteq IQS7222A/B/C
.../bindings/input/azoteq,iqs7222.yaml | 960 +++++++
drivers/input/misc/Kconfig | 10 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/iqs7222.c | 2444 +++++++++++++++++
4 files changed, 3415 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
create mode 100644 drivers/input/misc/iqs7222.c
--
2.25.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox