ipq807x: add Qualcomm Atheros IPQ807x target

Qualcomm Atheros IPQ807x is a modern WiSoC featuring:
* Quad Core ARMv8 Cortex A-53
	* @ 2.2 GHz (IPQ8072A/4A/6A/8A) Codename Hawkeye
	* @ 1.4 GHz (IPQ8070A/1A) Codename Acorn
* Dual Band simultaneaous IEEE 802.11ax
	* 5G: 8x8/80 or 4x4/160MHz (IPQ8074A/8A)
	* 5G: 4x4/80 or 2x2/160MHz (IPQ8071A/2A/6A)
	* 5G: 2x2/80MHz (IPQ8070A)
	* 2G: 4x4/40MHz (IPQ8072A/4A/6A/8A)
	* 2G: 2x2/40MHz (IPQ8070A/1A)
* 1x PSGMII via QCA8072/5 (Max 5x 1GbE ports)
* 2x SGMII/USXGMII (1/2.5/5/10 GbE) on Hawkeye
* 2x SGMII/USXGMII (1/2.5/5 GbE) on Acorn
* DDR3L/4 32/16 bit up to 2400MT/s
* SDIO 3.0/SD card 3.0/eMMC 5.1
* Dual USB 3.0
* One PCIe Gen2.1 and one PCIe Gen3.0 port (Single lane)
* Parallel NAND (ONFI)/LCD
* 6x QUP BLSP SPI/I2C/UART
* I2S, PCM, and TDMA
* HW PWM
* 1.8V configurable GPIO
* Companion PMP8074 PMIC via SPMI (GPIOS, RTC etc)

Note that only v2 SOC models aka the ones ending with A suffix are
supported, v1 models do not comply to the final 802.11ax and have
lower clocks, lack the Gen3 PCIe etc.

SoC itself has two UBI32 cores for the NSS offloading system, however
currently no offloading is supported.

Signed-off-by: Robert Marko <robimarko@gmail.com>

1 files changed, 54 insertions, 0 deletions

diff --git a/target/linux/ipq807x/patches-5.15/0048-v6.1-clk-qcom-reset-Allow-specifying-custom-reset-delay.patch b/target/linux/ipq807x/patches-5.15/0048-v6.1-clk-qcom-reset-Allow-specifying-custom-reset-delay.patch
new file mode 100644
index 0000000000..6a525f2c3e
--- /dev/null
+++ b/target/linux/ipq807x/patches-5.15/0048-v6.1-clk-qcom-reset-Allow-specifying-custom-reset-delay.patch
@@ -0,0 +1,54 @@
+From 72bc31aa621e21a7c36a7da8aa6f6a77bb234e0b Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+Date: Wed, 6 Jul 2022 15:41:29 +0200
+Subject: [PATCH] clk: qcom: reset: Allow specifying custom reset delay
+
+The amount of time required between asserting and deasserting the reset
+signal can vary depending on the involved hardware component. Sometimes
+1 us might not be enough and a larger delay is necessary to conform to
+the specifications.
+
+Usually this is worked around in the consuming drivers, by replacing
+reset_control_reset() with a sequence of reset_control_assert(), waiting
+for a custom delay, followed by reset_control_deassert().
+
+However, in some cases the driver making use of the reset is generic and
+can be used with different reset controllers. In this case the reset
+time requirement is better handled directly by the reset controller
+driver.
+
+Make this possible by adding an "udelay" field to the qcom_reset_map
+that allows setting a different reset delay (in microseconds).
+
+Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Link: https://lore.kernel.org/r/20220706134132.3623415-4-stephan.gerhold@kernkonzept.com
+---
+ drivers/clk/qcom/reset.c | 4 +++-
+ drivers/clk/qcom/reset.h | 1 +
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/clk/qcom/reset.c
++++ b/drivers/clk/qcom/reset.c
+@@ -13,8 +13,10 @@
+ 
+ static int qcom_reset(struct reset_controller_dev *rcdev, unsigned long id)
+ {
++	struct qcom_reset_controller *rst = to_qcom_reset_controller(rcdev);
++
+ 	rcdev->ops->assert(rcdev, id);
+-	udelay(1);
++	udelay(rst->reset_map[id].udelay ?: 1); /* use 1 us as default */
+ 	rcdev->ops->deassert(rcdev, id);
+ 	return 0;
+ }
+--- a/drivers/clk/qcom/reset.h
++++ b/drivers/clk/qcom/reset.h
+@@ -11,6 +11,7 @@
+ struct qcom_reset_map {
+ 	unsigned int reg;
+ 	u8 bit;
++	u8 udelay;
+ };
+ 
+ struct regmap;