date:20210603

At present the AE350 SPL defconfig is using OF_PRIOR_STAGE. The
intention was to use gdb to load device tree before running U-Boot
SPL/proper from RAM. When we switch to OF_SEPARATE we will have to
use our own DT but without "u-boot,dm-spl" in several essential
nodes, SPL does not boot.

Let's add all the required "u-boot,dm-spl" for SPL config.

Signed-off-by: Bin Meng 
---

 arch/riscv/dts/ae350-u-boot.dtsi | 52 
 arch/riscv/dts/ae350_32.dts  |  1 +
 arch/riscv/dts/ae350_64.dts  |  1 +
 3 files changed, 54 insertions(+)
 create mode 100644 arch/riscv/dts/ae350-u-boot.dtsi

diff --git a/arch/riscv/dts/ae350-u-boot.dtsi b/arch/riscv/dts/ae350-u-boot.dtsi
new file mode 100644
index 00..0d4201cfae
--- /dev/null
+++ b/arch/riscv/dts/ae350-u-boot.dtsi
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/ {
+   cpus {
+   u-boot,dm-spl;
+   CPU0: cpu@0 {
+   u-boot,dm-spl;
+   CPU0_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+   CPU1: cpu@1 {
+   u-boot,dm-spl;
+   CPU1_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+   CPU2: cpu@2 {
+   u-boot,dm-spl;
+   CPU2_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+   CPU3: cpu@3 {
+   u-boot,dm-spl;
+   CPU3_intc: interrupt-controller {
+   u-boot,dm-spl;
+   };
+   };
+   };
+
+   memory@0 {
+   u-boot,dm-spl;
+   };
+
+   soc {
+   u-boot,dm-spl;
+
+   plic1: interrupt-controller@e640 {
+   u-boot,dm-spl;
+   };
+
+   plmt0@e600 {
+   u-boot,dm-spl;
+   };
+   };
+
+   serial0: serial@f030 {
+   u-boot,dm-spl;
+   };
+
+};
diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index 70576846f2..083f676333 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -3,6 +3,7 @@
 /dts-v1/;
 
 #include "binman.dtsi"
+#include "ae350-u-boot.dtsi"
 
 / {
#address-cells = <1>;
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index 564e94a1db..74cff9122d 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -3,6 +3,7 @@
 /dts-v1/;
 
 #include "binman.dtsi"
+#include "ae350-u-boot.dtsi"
 
 / {
#address-cells = <2>;
-- 
2.25.1

[PATCH 4/5] riscv: ae350: dts: Fix #interrupt-cells for plic0 in 32-bit

All the device nodes that refer to plic0 as their interrupt parent
have 2 cells encoded in their interrupts property, but plic0 only
provides 1 cell in #interrupt-cells which is incorrect.

Signed-off-by: Bin Meng 
---

 arch/riscv/dts/ae350_32.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index 0917b83108..70576846f2 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -135,7 +135,7 @@
 
plic0: interrupt-controller@e400 {
compatible = "riscv,plic0";
-   #interrupt-cells = <1>;
+   #interrupt-cells = <2>;
interrupt-controller;
reg = <0xe400 0x200>;
riscv,ndev=<71>;
-- 
2.25.1

[PATCH 3/5] riscv: ae350: dts: Remove the unnecessary #address-cells in plic nodes

PLIC nodes don't have child nodes, so #address-cells is not needed.

Signed-off-by: Bin Meng 
---

 arch/riscv/dts/ae350_32.dts | 2 --
 arch/riscv/dts/ae350_64.dts | 2 --
 2 files changed, 4 deletions(-)

diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index b90351e87b..0917b83108 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -135,7 +135,6 @@
 
plic0: interrupt-controller@e400 {
compatible = "riscv,plic0";
-   #address-cells = <1>;
#interrupt-cells = <1>;
interrupt-controller;
reg = <0xe400 0x200>;
@@ -148,7 +147,6 @@
 
plic1: interrupt-controller@e640 {
compatible = "riscv,plic1";
-   #address-cells = <1>;
#interrupt-cells = <1>;
interrupt-controller;
reg = <0xe640 0x40>;
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index 27ac21c716..564e94a1db 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -135,7 +135,6 @@
 
plic0: interrupt-controller@e400 {
compatible = "riscv,plic0";
-   #address-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x0 0xe400 0x0 0x200>;
@@ -148,7 +147,6 @@
 
plic1: interrupt-controller@e640 {
compatible = "riscv,plic1";
-   #address-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
reg = <0x0 0xe640 0x0 0x40>;
-- 
2.25.1

[PATCH 2/5] riscv: ae350: dts: Remove the unnecessary space in bootargs

There are two spaces before "debug' in bootargs. Drop one.

Signed-off-by: Bin Meng 
---

 arch/riscv/dts/ae350_32.dts | 2 +-
 arch/riscv/dts/ae350_64.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index ef110c54ae..b90351e87b 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -16,7 +16,7 @@
};
 
chosen {
-   bootargs = "console=ttyS0,38400n8  debug loglevel=7";
+   bootargs = "console=ttyS0,38400n8 debug loglevel=7";
stdout-path = "uart0:38400n8";
};
 
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index 6abf42e904..27ac21c716 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -16,7 +16,7 @@
};
 
chosen {
-   bootargs = "console=ttyS0,38400n8  debug loglevel=7";
+   bootargs = "console=ttyS0,38400n8 debug loglevel=7";
stdout-path = "uart0:38400n8";
};
 
-- 
2.25.1

[PATCH 1/5] riscv: ae350: dts: Add SPDX license header

The SPDX license header is currently missing. Add one.

Signed-off-by: Bin Meng 
---

 arch/riscv/dts/ae350_32.dts | 2 ++
 arch/riscv/dts/ae350_64.dts | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
index a0ab5e9be2..ef110c54ae 100644
--- a/arch/riscv/dts/ae350_32.dts
+++ b/arch/riscv/dts/ae350_32.dts
@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
 /dts-v1/;
 
 #include "binman.dtsi"
diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
index f654f4809a..6abf42e904 100644
--- a/arch/riscv/dts/ae350_64.dts
+++ b/arch/riscv/dts/ae350_64.dts
@@ -1,3 +1,5 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
 /dts-v1/;
 
 #include "binman.dtsi"
-- 
2.25.1

[PATCHv3 3/3] pci: pcie_dw_rockchip: Replace msleep occurences by udelay

2021-06-03 Thread Anand Moon

Replace msleep occurences by udelay.

drivers/pci/pcie_dw_rockchip.c:254:3: warning: implicit
 declaration of function 'msleep' [-Wimplicit-function-declaration]

Cc: Patrick Wildt 
Cc: Neil Armstrong 
Cc: Kever Yang 
Signed-off-by: Anand Moon 
---
V2: drop the msleep macro.
---
 drivers/pci/pcie_dw_rockchip.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
index 4e448c0a3d..039266a357 100644
--- a/drivers/pci/pcie_dw_rockchip.c
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -62,6 +62,7 @@ struct rk_pcie {
 
 /* Parameters for the waiting for #perst signal */
 #define PERST_WAIT_MS  1000
+#define MACRO_US   1000
 
 static int rk_pcie_read(void __iomem *addr, int size, u32 *val)
 {
@@ -249,7 +250,7 @@ static int rk_pcie_link_up(struct rk_pcie *priv, u32 
cap_speed)
 * some wired devices need much more, such as 600ms.
 * Add a enough delay to cover all cases.
 */
-   msleep(PERST_WAIT_MS);
+   udelay(PERST_WAIT_MS);
dm_gpio_set_value(>rst_gpio, 1);
}
 
@@ -271,12 +272,12 @@ static int rk_pcie_link_up(struct rk_pcie *priv, u32 
cap_speed)
dev_info(priv->dw.dev, "PCIe Linking... LTSSM is 0x%x\n",
 rk_pcie_readl_apb(priv, PCIE_CLIENT_LTSSM_STATUS));
rk_pcie_debug_dump(priv);
-   msleep(1000);
+   udelay(PERST_WAIT_MS * MACRO_US);
}
 
dev_err(priv->dw.dev, "PCIe-%d Link Fail\n", dev_seq(priv->dw.dev));
/* Link maybe in Gen switch recovery but we need to wait more 1s */
-   msleep(1000);
+   udelay(PERST_WAIT_MS * MACRO_US);
return -EIO;
 }
 
@@ -296,7 +297,7 @@ static int rockchip_pcie_init_port(struct udevice *dev)
}
}
 
-   msleep(1000);
+   udelay(PERST_WAIT_MS * MACRO_US);
 
ret = generic_phy_init(>phy);
if (ret) {
-- 
2.31.1

[PATCHv3 2/3] pci: pcie_dw_rockchip: Drop the unused variable warning

2021-06-03 Thread Anand Moon

Drop the unused variable warning below.

drivers/pci/pcie_dw_rockchip.c:161:6: warning: unused variable
'val' [-Wunused-variable]
  161 |  u32 val;
   |  ^~~
Cc: Patrick Wildt 
Cc: Neil Armstrong 
Cc: Kever Yang 
Reviewed-by: Neil Armstrong 
Signed-off-by: Anand Moon 
---
V1
V2: Added Neil review tags.
---
 drivers/pci/pcie_dw_rockchip.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
index 3ac2434b69..4e448c0a3d 100644
--- a/drivers/pci/pcie_dw_rockchip.c
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -158,8 +158,6 @@ static inline void rk_pcie_writel_apb(struct rk_pcie 
*rk_pcie, u32 reg,
  */
 static void rk_pcie_configure(struct rk_pcie *pci, u32 cap_speed)
 {
-   u32 val;
-
dw_pcie_dbi_write_enable(>dw, true);
 
clrsetbits_le32(pci->dw.dbi_base + PCIE_LINK_CAPABILITY,
-- 
2.31.1

[PATCHv3 1/3] pci: pcie_dw_rockchip: Fixed the below compilation error

2021-06-03 Thread Anand Moon

Use the generic error number instead of specific error number.
Changes fix the below error.

drivers/pci/pcie_dw_rockchip.c: In function 'rk_pcie_read':
drivers/pci/pcie_dw_rockchip.c:70:10: error: 'PCIBIOS_UNSUPPORTED'
undeclared (first use in this function)
   70 |   return PCIBIOS_UNSUPPORTED;
  |  ^~~
drivers/pci/pcie_dw_rockchip.c: In function 'rk_pcie_write':
drivers/pci/pcie_dw_rockchip.c:90:10: error: 'PCIBIOS_UNSUPPORTED'
undeclared (first use in this function)
   90 |   return PCIBIOS_UNSUPPORTED;
  |  ^~~

Cc: Patrick Wildt 
Cc: Neil Armstrong 
Cc: Kever Yang 
Reviewed-by: Neil Armstrong 
Signed-off-by: Anand Moon 
---
v1: Drop the PCI ERROR MACRO,
v2: added the Neil review tag.
---
---
 drivers/pci/pcie_dw_rockchip.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie_dw_rockchip.c b/drivers/pci/pcie_dw_rockchip.c
index bc22af4230..3ac2434b69 100644
--- a/drivers/pci/pcie_dw_rockchip.c
+++ b/drivers/pci/pcie_dw_rockchip.c
@@ -67,7 +67,7 @@ static int rk_pcie_read(void __iomem *addr, int size, u32 
*val)
 {
if ((uintptr_t)addr & (size - 1)) {
*val = 0;
-   return PCIBIOS_UNSUPPORTED;
+   return -EOPNOTSUPP;
}
 
if (size == 4) {
@@ -87,7 +87,7 @@ static int rk_pcie_read(void __iomem *addr, int size, u32 
*val)
 static int rk_pcie_write(void __iomem *addr, int size, u32 val)
 {
if ((uintptr_t)addr & (size - 1))
-   return PCIBIOS_UNSUPPORTED;
+   return -EOPNOTSUPP;
 
if (size == 4)
writel(val, addr);
-- 
2.31.1

[PATCH V5 2/2] riscv: board: Support OpenPiton SoC

2021-06-03 Thread Tianrui Wei

From: Tianrui Wei 
Date: Fri, 4 June 2021 12:45:29 +0800
Subject: [PATCH v5 2/2] riscv: board: Support OpenPiton SoC

This patch add board support for OpenPiton.

Changelog:

v5:
- major changes to device tree
- change defconfig to use OF_SEPARATE and other things
- change some documentation

Signed-off-by: Tianrui Wei 
Signed-off-by: Jonathan Balkind 
---

 arch/riscv/Kconfig  |   4 +
 arch/riscv/dts/Makefile |   1 +
 arch/riscv/dts/openpiton-riscv64.dts| 160 +
 board/openpiton/riscv/Kconfig   |  42 ++
 board/openpiton/riscv/MAINTAINERS   |   6 +
 board/openpiton/riscv/Makefile  |   5 +
 board/openpiton/riscv/openpiton-riscv.c |  41 ++
 configs/openpiton_riscv64_defconfig | 132 
 doc/board/index.rst |   1 +
 doc/board/openpiton/index.rst   |   9 +
 doc/board/openpiton/riscv64.rst | 885 
 include/configs/openpiton-riscv.h   |  58 ++
 12 files changed, 1344 insertions(+)
 create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
 create mode 100644 board/openpiton/riscv/Kconfig
 create mode 100644 board/openpiton/riscv/MAINTAINERS
 create mode 100644 board/openpiton/riscv/Makefile
 create mode 100644 board/openpiton/riscv/openpiton-riscv.c
 create mode 100644 configs/openpiton_riscv64_defconfig
 create mode 100644 doc/board/openpiton/index.rst
 create mode 100644 doc/board/openpiton/riscv64.rst
 create mode 100644 include/configs/openpiton-riscv.h

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 30b05408..9e7deb34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -23,6 +23,9 @@ config TARGET_SIFIVE_FU540
 config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
 
+config TARGET_OPENPITON_RISCV
+  bool "Support riscv cores on openpiton SoC"
+
 endchoice
 
 config SYS_ICACHE_OFF
@@ -55,6 +58,7 @@ config SPL_SYS_DCACHE_OFF
 source "board/AndesTech/ax25-ae350/Kconfig"
 source "board/emulation/qemu-riscv/Kconfig"
 source "board/microchip/mpfs_icicle/Kconfig"
+source "board/openpiton/riscv/Kconfig"
 source "board/sifive/fu540/Kconfig"
 source "board/sipeed/maix/Kconfig"
 
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 3a6f96c6..b511cd74 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -1,6 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
+dtb-$(CONFIG_TARGET_OPENPITON_RISCV) += openpiton-riscv64.dtb
 dtb-$(CONFIG_TARGET_SIFIVE_FU540) += hifive-unleashed-a00.dtb
 dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
 
diff --git a/arch/riscv/dts/openpiton-riscv64.dts 
b/arch/riscv/dts/openpiton-riscv64.dts
new file mode 100644
index ..3abeaff8
--- /dev/null
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2021 Tianrui Wei  */
+
+/*
+ * This dts is for a dual core instance of OpenPiton+Ariane built
+ * to run on a Digilent Genesys 2 FPGA at 66.67MHz. These files
+ * are automatically generated by the OpenPiton build system and
+ * this configuration may not be what you need if your configuration
+ * is different from the below.
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   u-boot,dm-spl;
+   compatible = "openpiton,riscv64";
+
+   chosen {
+  stdout-path = "uart0:115200";
+   };
+
+   aliases {
+   console = 
+   serial0 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   timebase-frequency = <520835>;
+
+   CPU0: cpu@0 {
+   clocks = <>;
+   u-boot,dm-spl;
+   device_type = "cpu";
+   reg = <0>;
+   status = "okay";
+   compatible = "openhwgroup,cva6", "riscv";
+   riscv,isa = "rv64imafdc";
+   mmu-type = "riscv,sv39";
+   tlb-split;
+   // HLIC - hart local interrupt controller
+   CPU0_intc: interrupt-controller {
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "riscv,cpu-intc";
+   };
+   };
+
+   CPU1: cpu@1 {
+   clocks = <>;
+   device_type = "cpu";
+   reg = <1>;
+   status = "okay";
+   compatible = "openhwgroup,cva6", "riscv";
+   riscv,isa = "rv64imafdc";
+   mmu-type = "riscv,sv39";
+   tlb-split;
+   // HLIC - hart local interrupt controller
+   CPU1_intc: interrupt-controller {
+   #interrupt-cells

[PATCH V5 1/2] mmc: add OpenPiton mmc support

2021-06-03 Thread Tianrui Wei

From: Tianrui Wei 
Date: Fri, 4 June 2021 12:45:29 +0800
Subject: [PATCH v5 1/2] mmc: add OpenPiton mmc support

This patch adds mmc support for OpenPiton board.

Changelog:

v5: move definitions around, changed some incompatible type information

Signed-off-by: Tianrui Wei 
Signed-off-by: Jonathan Balkind 
---

 drivers/mmc/Kconfig |   7 +
 drivers/mmc/Makefile|   1 +
 drivers/mmc/piton_mmc.c | 174 +
 3 files changed, 182 insertions(+)
 create mode 100644 drivers/mmc/piton_mmc.c

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 14d79139..1038800f 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -707,6 +707,13 @@ config MMC_SUNXI_HAS_MODE_SWITCH
bool
depends on MMC_SUNXI
 
+config MMC_PITON
+   bool "MMC support for openpiton SoC"
+  depends on DM_MMC && BLK
+   help
+This driver enables SD card support in U-Boot port for
+OpenPiton SoC
+
 config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 1c849cba..698dfe05 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
 obj-$(CONFIG_MMC_SDHCI_ZYNQ)   += zynq_sdhci.o
 
 obj-$(CONFIG_MMC_SUNXI)+= sunxi_mmc.o
+obj-$(CONFIG_MMC_PITON)+= piton_mmc.o
 obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
 obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
 obj-$(CONFIG_MMC_BCM2835)  += bcm2835_sdhost.o
diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
new file mode 100644
index ..2b2d5756
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang 
+ * Jaehoon Chung 
+ * Portions Copyright 2011-2019 NVIDIA Corporation
+ * Portions Copyright 2021 Tianrui Wei
+ * This file is adapted from tegra_mmc.c
+ * Tianrui Wei 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct piton_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
+struct piton_mmc_priv {
+   u64 piton_mmc_base_addr; /* peripheral id */
+};
+
+/*
+ * see mmc_read_blocks to see how it is used.
+ * start block is hidden at cmd->arg
+ * also, initialize the block size at init
+ */
+static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+   /* check first if this is a pure command */
+   if (!data)
+   return 0;
+
+   u64 byte_cnt, start_block, start_addr;
+
+   struct piton_mmc_priv *priv = dev_get_priv(dev);
+   unsigned long *buff = (unsigned long *)data->dest;
+
+   start_addr = priv->piton_mmc_base_addr + (start_block);
+   byte_cnt = data->blocks * data->blocksize;
+   start_block = cmd->cmdarg;
+
+   /* if there is a read */
+   if (data->flags & MMC_DATA_READ) {
+   for (u64 i = 0; i < byte_cnt; i += 4) {
+   *(buff) = readl((void *)(start_addr + i));
+   buff++;
+   }
+   } else {
+   /* else there is a write
+* we don't handle write, so error right away
+*/
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+   struct piton_mmc_priv *priv = dev_get_priv(dev);
+   struct piton_mmc_plat *plat = dev_get_platdata(dev);
+   struct mmc_config *cfg;
+   struct mmc *mmc;
+   /* fill in device description */
+   struct blk_desc *bdesc;
+
+   priv->piton_mmc_base_addr = dev_read_addr(dev);
+   cfg = >cfg;
+   cfg->name = "PITON MMC";
+   cfg->host_caps = MMC_MODE_8BIT;
+   cfg->f_max = 10;
+   cfg->f_min = 40;
+   cfg->voltages = MMC_VDD_21_22;
+
+   mmc = >mmc;
+   mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+   mmc->capacity_user = 0x1;
+   mmc->capacity_user *= mmc->read_bl_len;
+   mmc->capacity_boot = 0;
+   mmc->capacity_rpmb = 0;
+   for (int i = 0; i < 4; i++)
+   mmc->capacity_gp[i] = 0;
+   mmc->capacity = 0x20ULL;
+   mmc->has_init = 1;
+
+   bdesc = mmc_get_blk_desc(mmc);
+   bdesc->lun = 0;
+   bdesc->hwpart = 0;
+   bdesc->type = 0;
+   bdesc->blksz = mmc->read_bl_len;
+   bdesc->log2blksz = LOG2(bdesc->blksz);
+   bdesc->lba = lldiv(mmc->capacity, mmc->read_bl_len);
+
+   return 0;
+}
+
+/* test if piton has the micro mmc card present
+ * always return 1, which means present
+ */
+static int piton_mmc_getcd(struct udevice *dev)
+{
+   /*
+*

[PATCH V5 0/2] Add OpenPiton board support

2021-06-03 Thread Tianrui Wei

This patch set is to add OpenPiton board support. Patches are split into
several parts:

- [PATCH 1/2] add OpenPiton support to mmc driver
- [PATCH 2/2] add support for OpenPiton board

Description

- for mmc driver, it's settings are automatically configured at hardware level.
  We only need to expose the memory mapped interface through U-Boot driver model
- For OpenPiton, as we need to embed the device tree blob into the bitstream,
  there is currently no itb support

Tests checks

- Able to boot Debian Linux from SD card on Digilent Genesys 2
- Checkpatch is performed, with some warnings ignored

Changelogs
- V2
  . fix styles and typos in [1/2] and [2/2]
  . add board documentation in [2/2]
- V3
  . fix styles in [1/2]
- V4
  . fix checkpatch warnings in [1/2] except MAINTAINERS
- V5
  . major changes in device tree
  . changed to OF_SEPARATE
  . formatting update for mmc

 arch/riscv/Kconfig  |   4 +


 arch/riscv/dts/Makefile |   1 +


 arch/riscv/dts/openpiton-riscv64.dts| 160 +


 board/openpiton/riscv/Kconfig   |  42 ++   


 board/openpiton/riscv/MAINTAINERS   |   6 +


 board/openpiton/riscv/Makefile  |   5 +


 board/openpiton/riscv/openpiton-riscv.c |  41 ++   


 configs/openpiton_riscv64_defconfig | 132  


 doc/board/index.rst |   1 +


 doc/board/openpiton/index.rst   |   9 +


 doc/board/openpiton/riscv64.rst | 885  


 drivers/mmc/Kconfig |   7 +


 drivers/mmc/Makefile|   1 +


 drivers/mmc/piton_mmc.c | 174 +


 include/configs/openpiton-riscv.h   |  58 ++   


 15 files changed, 1526 insertions(+)   


 create mode 100644 arch/riscv/dts/openpiton-riscv64.dts


 create mode 100644 board/openpiton/riscv/Kconfig   


 create mode 100644 board/openpiton/riscv/MAINTAINERS   


 create mode 100644 board/openpiton/riscv/Makefile  


 create mode 100644 board/openpiton/riscv/openpiton-riscv.c 


 create mode

Re: [PATCH v2 00/11] clk: k210: Rewrite K210 clock without CCF


On 6/4/21 12:28 AM, Damien Le Moal wrote:

On 2021/06/04 12:58, Sean Anderson wrote:

This is something I've been meaning to do for a while but only just got around
to. The CCF has been quite unwieldy in a few ways:

* It is very rigid, and there are not easy ways to hook into it without
   rewriting many things. See e.g. things like the bypass clock and all the 
_half
   clocks which were created because CCF didn't support the dividers used on the
   k210. While preparing this series, I encountered several edge cases which I
   had initially overlooked (or which were not supported in the initial 
release).
   These would have been very difficult to fix with CCF, but were much easier to
   address because each funcion is implemented in one place.
* There is a lot of magic going on under the curtains because of all the CCF
   code which lives in many different files. Some things live in drivers, but
   many things live in e.g. clk-uclass.c. So many things live in so many files
   and it can be very difficult to get a handle on what exactly happens.
   Complicating this is that there is a conflation of struct clk as a handle and
   struct clk as a device. In this regard, refcounting is completely broken. IMO
   we should just do away with refcounts and only disable clocks when explicitly
   asked for.
* It is very dependent on runtime initialization. Typically, everything is
   initialized by calling into various register() functions, usually with 
several
   wrappers to avoid specifying all the arguments. This balloons the runtime
   memory usage since there are so many devices created. It also makes it hard 
to
   debug, since if you do it the "typical" way it is easy to accidentally assign
   a clock to the wrong register.
* It inflates code size by pulling in not just some dead code (e.g. this driver
   does not use divider tables but they are in clk-divider anyway) but also
   pulling in numerous imx-specific clocks. This could be fixed, but I don't 
want
   to due to the other reasons listed.

I am very happy to have completely excised it from my driver. IMO there should
be big warning signs on the CCF warning not to use it for new code. This would
hopefully dissuade those like myself who had no idea that CCF was *not* in fact
a good way to write a clock driver.

Overall there is a total savings of 12k from this series.
text   data bss dec hex filename
  292485  32672   12624  337781   52775 before/u-boot
  283125  29856   12624  325605   4f7e5 after/u-boot

This series depends on
https://patchwork.ozlabs.org/project/uboot/list/?series=238211

Changes in v2:
- Convert stage to enum
- Only force probe clocks pre-reloc
- Rebase on u-boot/master

Sean Anderson (11):
   clk: Allow force setting clock defaults before relocation
   clk: k210: Rewrite to remove CCF
   clk: k210: Move pll into the rest of the driver
   clk: k210: Implement soc_clk_dump
   clk: k210: Re-add support for setting rate
   clk: k210: Don't set PLL rates if we are already at the correct rate
   clk: k210: Remove bypass driver
   clk: k210: Move k210 clock out of its own subdirectory
   k210: dts: Set PLL1 to the same rate as PLL0
   k210: Don't imply CCF
   test: Add K210 PLL tests to sandbox defconfigs

  MAINTAINERS |4 +-
  arch/riscv/dts/k210.dtsi|2 +
  board/sipeed/maix/Kconfig   |2 -
  configs/sandbox64_defconfig |2 +
  configs/sandbox_defconfig   |2 +
  configs/sandbox_flattree_defconfig  |2 +
  configs/sipeed_maix_bitm_defconfig  |1 -
  drivers/clk/Kconfig |   14 +-
  drivers/clk/Makefile|2 +-
  drivers/clk/clk-uclass.c|   27 +-
  drivers/clk/clk_kendryte.c  | 1320 +++
  drivers/clk/kendryte/Kconfig|   12 -
  drivers/clk/kendryte/Makefile   |1 -
  drivers/clk/kendryte/bypass.c   |  273 -
  drivers/clk/kendryte/clk.c  |  668 
  drivers/clk/kendryte/pll.c  |  585 --
  drivers/clk/rockchip/clk_rk3308.c   |2 +-
  drivers/core/device.c   |2 +-
  drivers/net/gmac_rockchip.c |2 +-
  include/clk.h   |   30 +-
  include/dt-bindings/clock/k210-sysctl.h |   94 +-
  include/kendryte/bypass.h   |   31 -
  include/kendryte/clk.h  |   35 -
  include/kendryte/pll.h  |   34 -
  24 files changed, 1436 insertions(+), 1711 deletions(-)


Awesome cleanup !

I will try to revisit the clock rate setting in Linux and re-check where we 
diverge.


I don't believe there are any divergences other than the fix mentioned in 02/11.



FYI: I have a draft series adding K210 builds to buildroot here:

https://github.com/damien-lemoal/buildroot (k210-v2 branch)


Ok, I will try and check it out.

(you have a typo in

Re: [PATCH v2 05/11] clk: k210: Re-add support for setting rate


On 6/3/21 11:58 PM, Sean Anderson wrote:

This adds support for setting clock rates, which was left out of the
initial CCF expunging. There are several tricky bits here, mostly related
to the PLLS:

* The PLL's bypass is broken. If the PLL is reconfigured, any child clocks
   will be stopped.
* PLL0 is the parent of ACLK which is the CPU and SRAM's clock. To prevent
   stopping the CPU while we configure PLL0's rate, ACLK is reparented
   to IN0 while PLL0 is disabled.
* PLL1 is the parent of the AISRAM clock. This clock cannot be reparented,
   so we instead just disallow changing PLL1's rate after relocation (when
   we are using the AISRAM).

Signed-off-by: Sean Anderson 
---

Changes in v2:
- Only force probe clocks pre-reloc

  drivers/clk/kendryte/clk.c | 89 +++---
  1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index 203d5f741c..a1742eb856 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -17,6 +17,8 @@
  #include 
  #include 
  
+DECLARE_GLOBAL_DATA_PTR;

+
  /**
   * struct k210_clk_priv - K210 clock driver private data
   * @base: The base address of the sysctl device
@@ -1059,11 +1061,6 @@ static ulong k210_clk_get_rate(struct clk *clk)
return do_k210_clk_get_rate(dev_get_priv(clk->dev), clk->id);
  }
  
-static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)

-{
-   return -ENOSYS;
-}
-
  static int do_k210_clk_set_parent(struct k210_clk_priv *priv, int id, int new)
  {
int i;
@@ -1089,6 +1086,81 @@ static int k210_clk_set_parent(struct clk *clk, struct 
clk *parent)
  parent->id);
  }
  
+static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)

+{
+   int parent, ret, err;
+   ulong rate_in, val;
+   const struct k210_div_params *div;
+   struct k210_clk_priv *priv = dev_get_priv(clk->dev);
+
+   if (clk->id == K210_CLK_IN0)
+   return clk_set_rate(>in0, rate);
+
+   parent = k210_clk_get_parent(priv, clk->id);
+   rate_in = do_k210_clk_get_rate(priv, parent);
+
+   log_debug("id=%ld rate=%lu rate_in=%lu\n", clk->id, rate, rate_in);
+
+   if (clk->id == K210_CLK_PLL0) {
+   /* Bypass ACLK so the CPU keeps going */
+   ret = do_k210_clk_set_parent(priv, K210_CLK_ACLK, K210_CLK_IN0);
+   if (ret)
+   return ret;
+   } else if (clk->id == K210_CLK_PLL1 && gd->flags & GD_FLG_RELOC) {
+   /*
+* We can't bypass the AI clock like we can ACLK, and after
+* relocation we are using the AI ram.
+*/
+   return -EPERM;
+   }
+
+   if (k210_clks[clk->id].flags & K210_CLKF_PLL) {
+   ret = k210_pll_set_rate(priv, k210_clks[clk->id].pll, rate,
+   rate_in);
+   if (!IS_ERR_VALUE(ret) && clk->id == K210_CLK_PLL0) {
+   /*
+* This may have the side effect of reparenting ACLK,
+* but I don't really want to keep track of what the old
+* parent was.
+*/
+   err = do_k210_clk_set_parent(priv, K210_CLK_ACLK,
+K210_CLK_PLL0);
+   if (err)
+   return err;
+   }
+   return ret;
+   }
+
+   if (k210_clks[clk->id].div == K210_CLK_DIV_NONE)
+   return -ENOSYS;
+   div = _divs[k210_clks[clk->id].div];
+
+   switch (div->type) {
+   case K210_DIV_ONE:
+   val = DIV_ROUND_CLOSEST_ULL((u64)rate_in, rate);
+   val = val ? val - 1 : 0;
+   break;
+   case K210_DIV_EVEN:
+   val = DIV_ROUND_CLOSEST_ULL((u64)rate_in, 2 * rate);
+   break;
+   case K210_DIV_POWER:
+   /* This is ACLK, which has no divider on IN0 */
+   if (parent == K210_CLK_IN0)
+   return -ENOSYS;
+
+   DIV_ROUND_CLOSEST_ULL((u64)rate_in, rate);
+   val = __ffs(val);
+   break;
+   default:
+   assert(false);
+   return -EINVAL;
+   };
+
+   val = val ? val - 1 : 0;
+   k210_clk_writel(priv, div->off, div->shift, div->width, val);
+   return do_k210_clk_get_rate(priv, clk->id);
+}
+
  static int k210_clk_endisable(struct k210_clk_priv *priv, int id, bool enable)
  {
int parent = k210_clk_get_parent(priv, id);
@@ -1163,6 +1235,13 @@ static int k210_clk_probe(struct udevice *dev)
if (ret)
return ret;
  
+	/*

+* Force setting defaults, even before relocation. This is so we can
+* set the clock rate for PLL1 before we relocate into aisram.
+*/
+   if (gd->flags & GD_FLG_RELOC)

[PATCH v2 10/11] k210: Don't imply CCF

Now that the k210 clock driver does not depend on CCF, we should no longer
imply it (and probably should not have in the first place). We can also
reduce the pre-relocation malloc arena back to something sensible.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 board/sipeed/maix/Kconfig  | 2 --
 configs/sipeed_maix_bitm_defconfig | 1 -
 2 files changed, 3 deletions(-)

diff --git a/board/sipeed/maix/Kconfig b/board/sipeed/maix/Kconfig
index adf6abb572..b1d7a7ad93 100644
--- a/board/sipeed/maix/Kconfig
+++ b/board/sipeed/maix/Kconfig
@@ -37,8 +37,6 @@ config BOARD_SPECIFIC_OPTIONS
imply SIFIVE_CLINT
imply POWER_DOMAIN
imply SIMPLE_PM_BUS
-   imply CLK_CCF
-   imply CLK_COMPOSITE_CCF
imply CLK_K210
imply DM_RESET
imply RESET_SYSCON
diff --git a/configs/sipeed_maix_bitm_defconfig 
b/configs/sipeed_maix_bitm_defconfig
index bd877cd055..4903476961 100644
--- a/configs/sipeed_maix_bitm_defconfig
+++ b/configs/sipeed_maix_bitm_defconfig
@@ -1,5 +1,4 @@
 CONFIG_RISCV=y
-CONFIG_SYS_MALLOC_F_LEN=0x1
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0xfff000
 CONFIG_ENV_SECT_SIZE=0x1000
-- 
2.31.0

[PATCH v2 11/11] test: Add K210 PLL tests to sandbox defconfigs

This adds the unit test for the K210 PLL to the sandbox defconfigs.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

(no changes since v1)

 configs/sandbox64_defconfig| 2 ++
 configs/sandbox_defconfig  | 2 ++
 configs/sandbox_flattree_defconfig | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/configs/sandbox64_defconfig b/configs/sandbox64_defconfig
index 9a373bab6f..9cd746107d 100644
--- a/configs/sandbox64_defconfig
+++ b/configs/sandbox64_defconfig
@@ -107,6 +107,8 @@ CONFIG_AXI_SANDBOX=y
 CONFIG_BUTTON=y
 CONFIG_BUTTON_GPIO=y
 CONFIG_CLK=y
+CONFIG_CLK_K210=y
+CONFIG_CLK_K210_SET_RATE=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
 CONFIG_DM_DEMO_SIMPLE=y
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index bdbf714e2b..f9749dea61 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -130,6 +130,8 @@ CONFIG_BUTTON_GPIO=y
 CONFIG_CLK=y
 CONFIG_CLK_COMPOSITE_CCF=y
 CONFIG_CLK_SCMI=y
+CONFIG_CLK_K210=y
+CONFIG_CLK_K210_SET_RATE=y
 CONFIG_SANDBOX_CLK_CCF=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 853c9440ea..772230ce47 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -86,6 +86,8 @@ CONFIG_AXI=y
 CONFIG_AXI_SANDBOX=y
 CONFIG_CLK=y
 CONFIG_CLK_COMPOSITE_CCF=y
+CONFIG_CLK_K210=y
+CONFIG_CLK_K210_SET_RATE=y
 CONFIG_SANDBOX_CLK_CCF=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
-- 
2.31.0

[PATCH v2 07/11] clk: k210: Remove bypass driver

This driver no longer serves a purpose now that we have moved away from
CCF. Drop it.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/kendryte/Makefile |   2 +-
 drivers/clk/kendryte/bypass.c | 273 --
 include/kendryte/bypass.h |  31 
 3 files changed, 1 insertion(+), 305 deletions(-)
 delete mode 100644 drivers/clk/kendryte/bypass.c
 delete mode 100644 include/kendryte/bypass.h

diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
index 6710a1db72..0303c0b99c 100644
--- a/drivers/clk/kendryte/Makefile
+++ b/drivers/clk/kendryte/Makefile
@@ -1 +1 @@
-obj-y += bypass.o clk.o
+obj-y += clk.o
diff --git a/drivers/clk/kendryte/bypass.c b/drivers/clk/kendryte/bypass.c
deleted file mode 100644
index bbdbd9a10d..00
--- a/drivers/clk/kendryte/bypass.c
+++ /dev/null
@@ -1,273 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2020 Sean Anderson 
- */
-
-#define LOG_CATEGORY UCLASS_CLK
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define CLK_K210_BYPASS "k210_clk_bypass"
-
-/*
- * This is a small driver to do a software bypass of a clock if hardware bypass
- * is not working. I have tried to write this in a generic fashion, so that it
- * could be potentially broken out of the kendryte code at some future date.
- *
- * Say you have the following clock configuration
- *
- * +---+ +---+
- * |osc| |pll|
- * +---+ +---+
- * ^
- */|
- *   / |
- *  /  |
- * /   |
- */|
- * +---+ +---+
- * |clk| |clk|
- * +---+ +---+
- *
- * But the pll does not have a bypass, so when you configure the pll, the
- * configuration needs to change to look like
- *
- * +---+ +---+
- * |osc| |pll|
- * +---+ +---+
- *   ^
- *   |\
- *   | \
- *   |  \
- *   |   \
- *   |\
- * +---+ +---+
- * |clk| |clk|
- * +---+ +---+
- *
- * To set this up, create a bypass clock with bypassee=pll and alt=osc. When
- * creating the child clocks, set their parent to the bypass clock. After
- * creating all the children, call k210_bypass_setchildren().
- */
-
-static int k210_bypass_dobypass(struct k210_bypass *bypass)
-{
-   int ret, i;
-
-   /*
-* If we already have saved parents, then the children are already
-* bypassed
-*/
-   if (bypass->child_count && bypass->saved_parents[0])
-   return 0;
-
-   for (i = 0; i < bypass->child_count; i++) {
-   struct clk *child = bypass->children[i];
-   struct clk *parent = clk_get_parent(child);
-
-   if (IS_ERR(parent)) {
-   for (; i; i--)
-   bypass->saved_parents[i] = NULL;
-   return PTR_ERR(parent);
-   }
-   bypass->saved_parents[i] = parent;
-   }
-
-   for (i = 0; i < bypass->child_count; i++) {
-   struct clk *child = bypass->children[i];
-
-   ret = clk_set_parent(child, bypass->alt);
-   if (ret) {
-   for (; i; i--)
-   clk_set_parent(bypass->children[i],
-  bypass->saved_parents[i]);
-   for (i = 0; i < bypass->child_count; i++)
-   bypass->saved_parents[i] = NULL;
-   return ret;
-   }
-   }
-
-   return 0;
-}
-
-static int k210_bypass_unbypass(struct k210_bypass *bypass)
-{
-   int err, ret, i;
-
-   if (!bypass->child_count && !bypass->saved_parents[0]) {
-   log_warning("Cannot unbypass children; dobypass not called 
first\n");
-   return 0;
-   }
-
-   ret = 0;
-   for (i = 0; i < bypass->child_count; i++) {
-   err = clk_set_parent(bypass->children[i],
-bypass->saved_parents[i]);
-   if (err)
-   ret = err;
-   bypass->saved_parents[i] = NULL;
-   }
-   return ret;
-}
-
-static ulong k210_bypass_get_rate(struct clk *clk)
-{
-   struct k210_bypass *bypass = to_k210_bypass(clk);
-   const struct clk_ops *ops = bypass->bypassee_ops;
-
-   if (ops->get_rate)
-   return ops->get_rate(bypass->bypassee);
-   else
-   return clk_get_parent_rate(bypass->bypassee);
-}
-
-static ulong k210_bypass_set_rate(struct clk *clk, unsigned long rate)
-{
-   int ret;
-   struct k210_bypass *bypass = to_k210_bypass(clk);
-   const struct clk_ops *ops = bypass->bypassee_ops;
-
-   /* Don't bother bypassing if we aren't going to set the rate */
-   if (!ops->set_rate)
-   return k210_bypass_get_rate(clk);
-
-   ret = k210_bypass_dobypass(bypass);
-   if (ret)
-   return ret;
-
-   ret = ops->set_rate(bypass->bypassee, rate);
-   if (ret < 0)
-   return ret;
-
-   return

[PATCH v2 08/11] clk: k210: Move k210 clock out of its own subdirectory

Now that we have only one clock driver, we don't need to have our own
subdirectory. Move the driver back with the rest of the clock drivers.

The MAINTAINERS for kendryte pinctrl is also fixed since it has always been
wrong.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 MAINTAINERS|  4 ++--
 drivers/clk/Kconfig| 14 +-
 drivers/clk/Makefile   |  2 +-
 drivers/clk/{kendryte/clk.c => clk_kendryte.c} |  0
 drivers/clk/kendryte/Kconfig   | 12 
 drivers/clk/kendryte/Makefile  |  1 -
 6 files changed, 16 insertions(+), 17 deletions(-)
 rename drivers/clk/{kendryte/clk.c => clk_kendryte.c} (100%)
 delete mode 100644 drivers/clk/kendryte/Kconfig
 delete mode 100644 drivers/clk/kendryte/Makefile

diff --git a/MAINTAINERS b/MAINTAINERS
index 4d0441c1a2..8afb2ed61b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -999,8 +999,8 @@ M:  Sean Anderson 
 S: Maintained
 F: doc/device-tree-bindings/mfd/kendryte,k210-sysctl.txt
 F: doc/device-tree-bindings/pinctrl/kendryte,k210-fpioa.txt
-F: drivers/clk/kendryte/
-F: drivers/pinctrl/kendryte/
+F: drivers/clk/clk_kendryte.c
+F: drivers/pinctrl/pinctrl-kendryte.c
 F: include/kendryte/
 
 RNG
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 40a5a5dd88..4bc6680121 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -159,11 +159,23 @@ config CLK_SCMI
  by a SCMI agent based on SCMI clock protocol communication
  with a SCMI server.
 
+config CLK_K210
+   bool "Clock support for Kendryte K210"
+   depends on CLK
+   help
+ This enables support clock driver for Kendryte K210 platforms.
+
+config CLK_K210_SET_RATE
+   bool "Enable setting the Kendryte K210 PLL rate"
+   depends on CLK_K210
+   help
+ Add functionality to calculate new rates for K210 PLLs. Enabling this
+ feature adds around 1K to U-Boot's final size.
+
 source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 source "drivers/clk/imx/Kconfig"
-source "drivers/clk/kendryte/Kconfig"
 source "drivers/clk/meson/Kconfig"
 source "drivers/clk/microchip/Kconfig"
 source "drivers/clk/mvebu/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 645709b855..f06164bb49 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -28,7 +28,7 @@ obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
 obj-$(CONFIG_$(SPL_TPL_)CLK_INTEL) += intel/
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-cgu.o
-obj-$(CONFIG_CLK_K210) += kendryte/
+obj-$(CONFIG_CLK_K210) += clk_kendryte.o
 obj-$(CONFIG_CLK_MPC83XX) += mpc83xx_clk.o
 obj-$(CONFIG_CLK_MPFS) += microchip/
 obj-$(CONFIG_CLK_OCTEON) += clk_octeon.o
diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/clk_kendryte.c
similarity index 100%
rename from drivers/clk/kendryte/clk.c
rename to drivers/clk/clk_kendryte.c
diff --git a/drivers/clk/kendryte/Kconfig b/drivers/clk/kendryte/Kconfig
deleted file mode 100644
index 0dc8e3f889..00
--- a/drivers/clk/kendryte/Kconfig
+++ /dev/null
@@ -1,12 +0,0 @@
-config CLK_K210
-   bool "Clock support for Kendryte K210"
-   depends on CLK
-   help
- This enables support clock driver for Kendryte K210 platforms.
-
-config CLK_K210_SET_RATE
-   bool "Enable setting the Kendryte K210 PLL rate"
-   depends on CLK_K210
-   help
- Add functionality to calculate new rates for K210 PLLs. Enabling this
- feature adds around 1K to U-Boot's final size.
diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
deleted file mode 100644
index 0303c0b99c..00
--- a/drivers/clk/kendryte/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-y += clk.o
-- 
2.31.0

[PATCH v2 09/11] k210: dts: Set PLL1 to the same rate as PLL0

Linux has had some stability issues when using AISRAM with a different
frequency from SRAM. Mirror their change here now that we relocate into
AISRAM.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 arch/riscv/dts/k210.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
index 2492af8038..8bcd3cebde 100644
--- a/arch/riscv/dts/k210.dtsi
+++ b/arch/riscv/dts/k210.dtsi
@@ -501,6 +501,8 @@
#clock-cells = <1>;
compatible = "kendryte,k210-clk";
clocks = <>;
+   assigned-clocks = < 
K210_CLK_PLL1>;
+   assigned-clock-rates = <39000>;
u-boot,dm-pre-reloc;
};
 
-- 
2.31.0

[PATCH v2 06/11] clk: k210: Don't set PLL rates if we are already at the correct rate

This speeds up boot by preventing multiple reconfigurations of the PLLs.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/kendryte/clk.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index a1742eb856..bb6d4a1692 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -847,21 +847,22 @@ static ulong k210_pll_set_rate(struct k210_clk_priv 
*priv, int id, ulong rate,
const struct k210_pll_params *pll = _plls[id];
struct k210_pll_config config = {};
u32 reg;
+   ulong calc_rate;
 
if (rate_in < 0)
return rate_in;
 
-   log_debug("Calculating parameters with rate=%lu and rate_in=%lu\n",
- rate, rate_in);
err = k210_pll_calc_config(rate, rate_in, );
if (err)
return err;
log_debug("Got r=%u f=%u od=%u\n", config.r, config.f, config.od);
 
-   /*
-* Don't use clk_disable as it might not actually disable the pll due to
-* refcounting
-*/
+   /* Don't bother setting the rate if we're already at that rate */
+   calc_rate = DIV_ROUND_DOWN_ULL(((u64)rate_in) * config.f,
+  config.r * config.od);
+   if (calc_rate == k210_pll_get_rate(priv, id, rate))
+   return calc_rate;
+
k210_pll_disable(priv, id);
 
reg = readl(priv->base + pll->off);
@@ -875,7 +876,7 @@ static ulong k210_pll_set_rate(struct k210_clk_priv *priv, 
int id, ulong rate,
|  FIELD_PREP(K210_PLL_BWADJ, config.f - 1);
writel(reg, priv->base + pll->off);
 
-   err = k210_pll_enable(priv, id);
+   k210_pll_enable(priv, id);
 
serial_setbrg();
return k210_pll_get_rate(priv, id, rate);
-- 
2.31.0

[PATCH v2 03/11] clk: k210: Move pll into the rest of the driver

Now that there no separate PLL driver, we can no longer make the PLL
functions static. By moving the PLL driver in with the rest of the clock
code, we can make these functions static again. We still keep the pll
header for unit testing, but it is pretty reduced.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/kendryte/Makefile |   2 +-
 drivers/clk/kendryte/clk.c| 606 +-
 drivers/clk/kendryte/pll.c| 587 
 include/kendryte/clk.h|  35 --
 include/kendryte/pll.h|  34 --
 5 files changed, 601 insertions(+), 663 deletions(-)
 delete mode 100644 drivers/clk/kendryte/pll.c
 delete mode 100644 include/kendryte/clk.h

diff --git a/drivers/clk/kendryte/Makefile b/drivers/clk/kendryte/Makefile
index 6fb68253ae..6710a1db72 100644
--- a/drivers/clk/kendryte/Makefile
+++ b/drivers/clk/kendryte/Makefile
@@ -1 +1 @@
-obj-y += bypass.o clk.o pll.o
+obj-y += bypass.o clk.o
diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index 34e8e742a6..de9db84361 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -2,17 +2,30 @@
 /*
  * Copyright (C) 2019-20 Sean Anderson 
  */
-#include 
+#define LOG_CATEGORY UCLASS_CLK
 
 #include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+
+/**
+ * struct k210_clk_priv - K210 clock driver private data
+ * @base: The base address of the sysctl device
+ * @in0: The "in0" external oscillator
+ */
+struct k210_clk_priv {
+   void __iomem *base;
+   struct clk in0;
+};
 
 /*
  * All parameters for different sub-clocks are collected into parameter arrays.
@@ -248,6 +261,30 @@ static const struct k210_mux_params k210_muxes[] = {
 #undef MUX
 #undef MUX_LIST
 
+/**
+ * struct k210_pll_params - K210 PLL parameters
+ * @off: The offset of the PLL from the base sysctl address
+ * @shift: The offset of the LSB of the lock status
+ * @width: The number of bits in the lock status
+ */
+struct k210_pll_params {
+   u8 off;
+   u8 shift;
+   u8 width;
+};
+
+static const struct k210_pll_params k210_plls[] = {
+#define PLL(_off, _shift, _width) { \
+   .off = (_off), \
+   .shift = (_shift), \
+   .width = (_width), \
+}
+   [0] = PLL(K210_SYSCTL_PLL0,  0, 2),
+   [1] = PLL(K210_SYSCTL_PLL1,  8, 1),
+   [2] = PLL(K210_SYSCTL_PLL2, 16, 1),
+#undef PLL
+};
+
 /**
  * enum k210_clk_flags - The type of a K210 clock
  * @K210_CLKF_MUX: This clock has a mux and not a static parent
@@ -286,7 +323,6 @@ struct k210_clk_params {
};
 };
 
-
 static const struct k210_clk_params k210_clks[] = {
 #if CONFIG_IS_ENABLED(CMD_CLK)
 #define NAME(_name) .name = (_name),
@@ -382,6 +418,564 @@ static const struct k210_clk_params k210_clks[] = {
 #undef CLK_LIST
 };
 
+#define K210_PLL_CLKR  GENMASK(3, 0)
+#define K210_PLL_CLKF  GENMASK(9, 4)
+#define K210_PLL_CLKOD GENMASK(13, 10) /* Output Divider */
+#define K210_PLL_BWADJ GENMASK(19, 14) /* BandWidth Adjust */
+#define K210_PLL_RESET BIT(20)
+#define K210_PLL_PWRD  BIT(21) /* PoWeReD */
+#define K210_PLL_INTFB BIT(22) /* Internal FeedBack */
+#define K210_PLL_BYPASSBIT(23)
+#define K210_PLL_TEST  BIT(24)
+#define K210_PLL_ENBIT(25)
+#define K210_PLL_TEST_EN   BIT(26)
+
+#define K210_PLL_LOCK  0
+#define K210_PLL_CLEAR_SLIP2
+#define K210_PLL_TEST_OUT  3
+
+#ifdef CONFIG_CLK_K210_SET_RATE
+static int k210_pll_enable(struct k210_clk_priv *priv, int id);
+static int k210_pll_disable(struct k210_clk_priv *priv, int id);
+static ulong k210_pll_get_rate(struct k210_clk_priv *priv, int id, ulong 
rate_in);
+
+/*
+ * The PLL included with the Kendryte K210 appears to be a True Circuits, Inc.
+ * General-Purpose PLL. The logical layout of the PLL with internal feedback is
+ * approximately the following:
+ *
+ *  +---+
+ *  |reference clock|
+ *  +---+
+ *  |
+ *  v
+ *+--+
+ *|/r|
+ *+--+
+ *  |
+ *  v
+ *   +-+
+ *   |divided clock|
+ *   +-+
+ *  |
+ *  v
+ *  +--+
+ *  |phase detector|<---+
+ *  +--+|
+ *  |   |
+ *  v   +--+
+ *+---+ |feedback clock|
+ *|VCO| +--+
+ *+---+ ^
+ *  |+--+   |
+ *  +--->|/f|---+
+ *  |+--+
+ *  v
+ *+---+
+ *|/od|
+ *+---+
+ *  |
+ *  v
+ *   +--+
+ *   |output|
+ *   +--+
+ *
+ * The k210 PLLs have three factors: r, f, and od. Because of the feedback 
mode,
+ * the effect of the division by f is to multiply the input frequency. The
+ * equation for the output rate is
+ *   rate = (rate_in * f) / (r * od).
+ *

[PATCH v2 05/11] clk: k210: Re-add support for setting rate

This adds support for setting clock rates, which was left out of the
initial CCF expunging. There are several tricky bits here, mostly related
to the PLLS:

* The PLL's bypass is broken. If the PLL is reconfigured, any child clocks
  will be stopped.
* PLL0 is the parent of ACLK which is the CPU and SRAM's clock. To prevent
  stopping the CPU while we configure PLL0's rate, ACLK is reparented
  to IN0 while PLL0 is disabled.
* PLL1 is the parent of the AISRAM clock. This clock cannot be reparented,
  so we instead just disallow changing PLL1's rate after relocation (when
  we are using the AISRAM).

Signed-off-by: Sean Anderson 
---

Changes in v2:
- Only force probe clocks pre-reloc

 drivers/clk/kendryte/clk.c | 89 +++---
 1 file changed, 84 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index 203d5f741c..a1742eb856 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /**
  * struct k210_clk_priv - K210 clock driver private data
  * @base: The base address of the sysctl device
@@ -1059,11 +1061,6 @@ static ulong k210_clk_get_rate(struct clk *clk)
return do_k210_clk_get_rate(dev_get_priv(clk->dev), clk->id);
 }
 
-static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)
-{
-   return -ENOSYS;
-}
-
 static int do_k210_clk_set_parent(struct k210_clk_priv *priv, int id, int new)
 {
int i;
@@ -1089,6 +1086,81 @@ static int k210_clk_set_parent(struct clk *clk, struct 
clk *parent)
  parent->id);
 }
 
+static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)
+{
+   int parent, ret, err;
+   ulong rate_in, val;
+   const struct k210_div_params *div;
+   struct k210_clk_priv *priv = dev_get_priv(clk->dev);
+
+   if (clk->id == K210_CLK_IN0)
+   return clk_set_rate(>in0, rate);
+
+   parent = k210_clk_get_parent(priv, clk->id);
+   rate_in = do_k210_clk_get_rate(priv, parent);
+
+   log_debug("id=%ld rate=%lu rate_in=%lu\n", clk->id, rate, rate_in);
+
+   if (clk->id == K210_CLK_PLL0) {
+   /* Bypass ACLK so the CPU keeps going */
+   ret = do_k210_clk_set_parent(priv, K210_CLK_ACLK, K210_CLK_IN0);
+   if (ret)
+   return ret;
+   } else if (clk->id == K210_CLK_PLL1 && gd->flags & GD_FLG_RELOC) {
+   /*
+* We can't bypass the AI clock like we can ACLK, and after
+* relocation we are using the AI ram.
+*/
+   return -EPERM;
+   }
+
+   if (k210_clks[clk->id].flags & K210_CLKF_PLL) {
+   ret = k210_pll_set_rate(priv, k210_clks[clk->id].pll, rate,
+   rate_in);
+   if (!IS_ERR_VALUE(ret) && clk->id == K210_CLK_PLL0) {
+   /*
+* This may have the side effect of reparenting ACLK,
+* but I don't really want to keep track of what the old
+* parent was.
+*/
+   err = do_k210_clk_set_parent(priv, K210_CLK_ACLK,
+K210_CLK_PLL0);
+   if (err)
+   return err;
+   }
+   return ret;
+   }
+
+   if (k210_clks[clk->id].div == K210_CLK_DIV_NONE)
+   return -ENOSYS;
+   div = _divs[k210_clks[clk->id].div];
+
+   switch (div->type) {
+   case K210_DIV_ONE:
+   val = DIV_ROUND_CLOSEST_ULL((u64)rate_in, rate);
+   val = val ? val - 1 : 0;
+   break;
+   case K210_DIV_EVEN:
+   val = DIV_ROUND_CLOSEST_ULL((u64)rate_in, 2 * rate);
+   break;
+   case K210_DIV_POWER:
+   /* This is ACLK, which has no divider on IN0 */
+   if (parent == K210_CLK_IN0)
+   return -ENOSYS;
+
+   DIV_ROUND_CLOSEST_ULL((u64)rate_in, rate);
+   val = __ffs(val);
+   break;
+   default:
+   assert(false);
+   return -EINVAL;
+   };
+
+   val = val ? val - 1 : 0;
+   k210_clk_writel(priv, div->off, div->shift, div->width, val);
+   return do_k210_clk_get_rate(priv, clk->id);
+}
+
 static int k210_clk_endisable(struct k210_clk_priv *priv, int id, bool enable)
 {
int parent = k210_clk_get_parent(priv, id);
@@ -1163,6 +1235,13 @@ static int k210_clk_probe(struct udevice *dev)
if (ret)
return ret;
 
+   /*
+* Force setting defaults, even before relocation. This is so we can
+* set the clock rate for PLL1 before we relocate into aisram.
+*/
+   if (gd->flags & GD_FLG_RELOC)
+   clk_set_defaults(dev, CLK_DEFAULTS_POST_FORCE);

[PATCH v2 02/11] clk: k210: Rewrite to remove CCF

This is effectively a complete rewrite to remove all dependency on CCF.
The code is now smaller, and so is the binary (TODO: numbers). It also
takes up less memory at runtime (since we don't have to create 40
udevices). In general, I am much happier with this driver as much of the
complexity and late binding has been removed.

The k210_*_params structs which were previously used to initialize CCF
clocks are now used as the complete configuration. Since we can write our
own division logic, we can now do away with several "half" clocks which
only existed to provide constant factors of two.

The clock IDs have been renumbered to remove unused clocks. This may not be
the last time they are renumbered, since we have diverged with Linux. There
are also still a few clocks left out which may need to be added back in.

In general, I have tried to leave out behavioral changes. However, there is
a small bugfix regarding ACLK. According to the technical reference manual,
its mux comes *after* its divider (which is present only for PLL0). This
would have required yet another intermediate clock to fix with CCF, but
with the new driver it is just 2 lines of code :)

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/kendryte/Kconfig|   2 +-
 drivers/clk/kendryte/clk.c  | 848 +++-
 drivers/clk/kendryte/pll.c  | 114 ++--
 include/dt-bindings/clock/k210-sysctl.h |  94 ++-
 include/kendryte/pll.h  |  26 +-
 5 files changed, 499 insertions(+), 585 deletions(-)

diff --git a/drivers/clk/kendryte/Kconfig b/drivers/clk/kendryte/Kconfig
index 073fca0781..0dc8e3f889 100644
--- a/drivers/clk/kendryte/Kconfig
+++ b/drivers/clk/kendryte/Kconfig
@@ -1,6 +1,6 @@
 config CLK_K210
bool "Clock support for Kendryte K210"
-   depends on CLK && CLK_CCF && CLK_COMPOSITE_CCF
+   depends on CLK
help
  This enables support clock driver for Kendryte K210 platforms.
 
diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index 41c712e03f..34e8e742a6 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -4,7 +4,7 @@
  */
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -14,77 +14,6 @@
 #include 
 #include 
 
-/* All methods are delegated to CCF clocks */
-
-static ulong k210_clk_get_rate(struct clk *clk)
-{
-   struct clk *c;
-   int err = clk_get_by_id(clk->id, );
-
-   if (err)
-   return err;
-   return clk_get_rate(c);
-}
-
-static ulong k210_clk_set_rate(struct clk *clk, unsigned long rate)
-{
-   struct clk *c;
-   int err = clk_get_by_id(clk->id, );
-
-   if (err)
-   return err;
-   return clk_set_rate(c, rate);
-}
-
-static int k210_clk_set_parent(struct clk *clk, struct clk *parent)
-{
-   struct clk *c, *p;
-   int err = clk_get_by_id(clk->id, );
-
-   if (err)
-   return err;
-
-   err = clk_get_by_id(parent->id, );
-   if (err)
-   return err;
-
-   return clk_set_parent(c, p);
-}
-
-static int k210_clk_endisable(struct clk *clk, bool enable)
-{
-   struct clk *c;
-   int err = clk_get_by_id(clk->id, );
-
-   if (err)
-   return err;
-   return enable ? clk_enable(c) : clk_disable(c);
-}
-
-static int k210_clk_enable(struct clk *clk)
-{
-   return k210_clk_endisable(clk, true);
-}
-
-static int k210_clk_disable(struct clk *clk)
-{
-   return k210_clk_endisable(clk, false);
-}
-
-static const struct clk_ops k210_clk_ops = {
-   .set_rate = k210_clk_set_rate,
-   .get_rate = k210_clk_get_rate,
-   .set_parent = k210_clk_set_parent,
-   .enable = k210_clk_enable,
-   .disable = k210_clk_disable,
-};
-
-/* Parents for muxed clocks */
-static const char * const generic_sels[] = { "in0_half", "pll0_half" };
-/* The first clock is in0, which is filled in by k210_clk_probe */
-static const char *aclk_sels[] = { NULL, "pll0_half" };
-static const char *pll2_sels[] = { NULL, "pll0", "pll1" };
-
 /*
  * All parameters for different sub-clocks are collected into parameter arrays.
  * These parameters are then initialized by the clock which uses them during
@@ -97,68 +26,113 @@ static const char *pll2_sels[] = { NULL, "pll0", "pll1" };
  * easy to find bugs in the code.
  */
 
-#define DIV(id, off, shift, width) DIV_FLAGS(id, off, shift, width, 0)
+/**
+ * enum k210_clk_div_type - The type of divider
+ * @K210_DIV_ONE: freq = parent / (reg + 1)
+ * @K210_DIV_EVEN: freq = parent / 2 / (reg + 1)
+ * @K210_DIV_POWER: freq = parent / (2 << reg)
+ * @K210_DIV_FIXED: freq = parent / factor
+ */
+enum k210_clk_div_type {
+   K210_DIV_ONE,
+   K210_DIV_EVEN,
+   K210_DIV_POWER,
+   K210_DIV_FIXED,
+};
+
+/**
+ * struct k210_div_params - Parameters for dividing clocks
+ * @type: An  k210_clk_div_type specifying the dividing formula
+ * @off: The offset of the divider from the sysctl base address
+ *

[PATCH v2 04/11] clk: k210: Implement soc_clk_dump

Since we are no longer using CCF we cannot use the default soc_clk_dump.
Instead, implement our own.

Signed-off-by: Sean Anderson 
---

(no changes since v1)

 drivers/clk/kendryte/clk.c | 68 --
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/kendryte/clk.c b/drivers/clk/kendryte/clk.c
index de9db84361..203d5f741c 100644
--- a/drivers/clk/kendryte/clk.c
+++ b/drivers/clk/kendryte/clk.c
@@ -925,14 +925,19 @@ static void k210_pll_waitfor_lock(struct k210_clk_priv 
*priv, int id)
}
 }
 
+static bool k210_pll_enabled(u32 reg)
+{
+   return (reg & K210_PLL_PWRD) && (reg & K210_PLL_EN) &&
+   !(reg & K210_PLL_RESET);
+}
+
 /* Adapted from sysctl_pll_enable */
 static int k210_pll_enable(struct k210_clk_priv *priv, int id)
 {
const struct k210_pll_params *pll = _plls[id];
u32 reg = readl(priv->base + pll->off);
 
-   if ((reg & K210_PLL_PWRD) && (reg & K210_PLL_EN) &&
-   !(reg & K210_PLL_RESET))
+   if (k210_pll_enabled(reg))
return 0;
 
reg |= K210_PLL_PWRD;
@@ -1174,3 +1179,62 @@ U_BOOT_DRIVER(k210_clk) = {
.probe = k210_clk_probe,
.priv_auto = sizeof(struct k210_clk_priv),
 };
+
+#if CONFIG_IS_ENABLED(CMD_CLK)
+static char show_enabled(struct k210_clk_priv *priv, int id)
+{
+   bool enabled;
+
+   if (k210_clks[id].flags & K210_CLKF_PLL) {
+   const struct k210_pll_params *pll =
+   _plls[k210_clks[id].pll];
+
+   enabled = k210_pll_enabled(readl(priv->base + pll->off));
+   } else if (k210_clks[id].gate == K210_CLK_GATE_NONE) {
+   return '-';
+   } else {
+   const struct k210_gate_params *gate =
+   _gates[k210_clks[id].gate];
+
+   enabled = k210_clk_readl(priv, gate->off, gate->bit_idx, 1);
+   }
+
+   return enabled ? 'y' : 'n';
+}
+
+static void show_clks(struct k210_clk_priv *priv, int id, int depth)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(k210_clks); i++) {
+   if (k210_clk_get_parent(priv, i) != id)
+   continue;
+
+   printf(" %-9lu %-7c %*s%s\n", do_k210_clk_get_rate(priv, i),
+  show_enabled(priv, i), depth * 4, "",
+  k210_clks[i].name);
+
+   show_clks(priv, i, depth + 1);
+   }
+}
+
+int soc_clk_dump(void)
+{
+   int ret;
+   struct udevice *dev;
+   struct k210_clk_priv *priv;
+
+   ret = uclass_get_device_by_driver(UCLASS_CLK, DM_DRIVER_GET(k210_clk),
+ );
+   if (ret)
+   return ret;
+   priv = dev_get_priv(dev);
+
+   puts(" Rate  Enabled Name\n");
+   puts("\n");
+   printf(" %-9lu %-7c %*s%s\n", clk_get_rate(>in0), 'y', 0, "",
+  priv->in0.dev->name);
+   show_clks(priv, K210_CLK_IN0, 1);
+   return 0;
+}
+#endif
-- 
2.31.0

[PATCH v2 01/11] clk: Allow force setting clock defaults before relocation

Since 291da96b8e ("clk: Allow clock defaults to be set during re-reloc
state for SPL only") it has been impossible to set clock defaults before
relocation. This is annoying on boards without SPL, since there is no way
to set clock defaults before U-Boot proper. In particular, the aisram rate
must be changed before relocation on the K210, since U-Boot will hang if we
try and change the rate while we are using aisram.

To get around this, extend the stage parameter to allow force setting
defaults, even if they would be otherwise postponed for later. A device
tree property was decided against because of the concerns in the original
commit thread about the overhead of repeatedly parsing the device tree.

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass 
---

Changes in v2:
- Convert stage to enum

 drivers/clk/clk-uclass.c  | 27 +--
 drivers/clk/rockchip/clk_rk3308.c |  2 +-
 drivers/core/device.c |  2 +-
 drivers/net/gmac_rockchip.c   |  2 +-
 include/clk.h | 30 ++
 5 files changed, 46 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 53e7be764d..25b6a41855 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -207,7 +207,8 @@ static struct clk *clk_set_default_get_by_id(struct clk 
*clk)
return c;
 }
 
-static int clk_set_default_parents(struct udevice *dev, int stage)
+static int clk_set_default_parents(struct udevice *dev,
+  enum clk_defaults_stage stage)
 {
struct clk clk, parent_clk, *c, *p;
int index;
@@ -251,10 +252,10 @@ static int clk_set_default_parents(struct udevice *dev, 
int stage)
 * It cannot be done right now but need to wait after the
 * device is probed
 */
-   if (stage == 0 && clk.dev == dev)
+   if (stage == CLK_DEFAULTS_PRE && clk.dev == dev)
continue;
 
-   if (stage > 0 && clk.dev != dev)
+   if (stage != CLK_DEFAULTS_PRE && clk.dev != dev)
/* do not setup twice the parent clocks */
continue;
 
@@ -280,7 +281,8 @@ static int clk_set_default_parents(struct udevice *dev, int 
stage)
return 0;
 }
 
-static int clk_set_default_rates(struct udevice *dev, int stage)
+static int clk_set_default_rates(struct udevice *dev,
+enum clk_defaults_stage stage)
 {
struct clk clk, *c;
int index;
@@ -320,10 +322,10 @@ static int clk_set_default_rates(struct udevice *dev, int 
stage)
 * It cannot be done right now but need to wait after the
 * device is probed
 */
-   if (stage == 0 && clk.dev == dev)
+   if (stage == CLK_DEFAULTS_PRE && clk.dev == dev)
continue;
 
-   if (stage > 0 && clk.dev != dev)
+   if (stage != CLK_DEFAULTS_PRE && clk.dev != dev)
/* do not setup twice the parent clocks */
continue;
 
@@ -346,16 +348,21 @@ fail:
return ret;
 }
 
-int clk_set_defaults(struct udevice *dev, int stage)
+int clk_set_defaults(struct udevice *dev, enum clk_defaults_stage stage)
 {
int ret;
 
if (!dev_has_ofnode(dev))
return 0;
 
-   /* If this not in SPL and pre-reloc state, don't take any action. */
+   /*
+* To avoid setting defaults twice, don't set them before relocation.
+* However, still set them for SPL. And still set them if explicitly
+* asked.
+*/
if (!(IS_ENABLED(CONFIG_SPL_BUILD) || (gd->flags & GD_FLG_RELOC)))
-   return 0;
+   if (stage != CLK_DEFAULTS_POST_FORCE)
+   return 0;
 
debug("%s(%s)\n", __func__, dev_read_name(dev));
 
@@ -805,7 +812,7 @@ int clk_uclass_post_probe(struct udevice *dev)
 * where the DT is used to setup default parents and rates
 * using assigned-clocks
 */
-   clk_set_defaults(dev, 1);
+   clk_set_defaults(dev, CLK_DEFAULTS_POST);
 
return 0;
 }
diff --git a/drivers/clk/rockchip/clk_rk3308.c 
b/drivers/clk/rockchip/clk_rk3308.c
index 5a838b9e9a..5248e59685 100644
--- a/drivers/clk/rockchip/clk_rk3308.c
+++ b/drivers/clk/rockchip/clk_rk3308.c
@@ -1014,7 +1014,7 @@ static int rk3308_clk_probe(struct udevice *dev)
rk3308_clk_init(dev);
 
/* Process 'assigned-{clocks/clock-parents/clock-rates}' properties */
-   ret = clk_set_defaults(dev, 1);
+   ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
if (ret)
debug("%s clk_set_defaults failed %d\n", __func__, ret);
 
diff --git a/drivers/core/device.c b/drivers/core/device.c
index cb960f8ec4..9f1400768d 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -561,7 +561,7 @@ int

[PATCH v2 00/11] clk: k210: Rewrite K210 clock without CCF

This is something I've been meaning to do for a while but only just got around
to. The CCF has been quite unwieldy in a few ways:

* It is very rigid, and there are not easy ways to hook into it without
  rewriting many things. See e.g. things like the bypass clock and all the _half
  clocks which were created because CCF didn't support the dividers used on the
  k210. While preparing this series, I encountered several edge cases which I
  had initially overlooked (or which were not supported in the initial release).
  These would have been very difficult to fix with CCF, but were much easier to
  address because each funcion is implemented in one place.
* There is a lot of magic going on under the curtains because of all the CCF
  code which lives in many different files. Some things live in drivers, but
  many things live in e.g. clk-uclass.c. So many things live in so many files
  and it can be very difficult to get a handle on what exactly happens.
  Complicating this is that there is a conflation of struct clk as a handle and
  struct clk as a device. In this regard, refcounting is completely broken. IMO
  we should just do away with refcounts and only disable clocks when explicitly
  asked for.
* It is very dependent on runtime initialization. Typically, everything is
  initialized by calling into various register() functions, usually with several
  wrappers to avoid specifying all the arguments. This balloons the runtime
  memory usage since there are so many devices created. It also makes it hard to
  debug, since if you do it the "typical" way it is easy to accidentally assign
  a clock to the wrong register.
* It inflates code size by pulling in not just some dead code (e.g. this driver
  does not use divider tables but they are in clk-divider anyway) but also
  pulling in numerous imx-specific clocks. This could be fixed, but I don't want
  to due to the other reasons listed.

I am very happy to have completely excised it from my driver. IMO there should
be big warning signs on the CCF warning not to use it for new code. This would
hopefully dissuade those like myself who had no idea that CCF was *not* in fact
a good way to write a clock driver.

Overall there is a total savings of 12k from this series.
   textdata bss dec hex filename
 292485   32672   12624  337781   52775 before/u-boot
 283125   29856   12624  325605   4f7e5 after/u-boot

This series depends on
https://patchwork.ozlabs.org/project/uboot/list/?series=238211

Changes in v2:
- Convert stage to enum
- Only force probe clocks pre-reloc
- Rebase on u-boot/master

Sean Anderson (11):
  clk: Allow force setting clock defaults before relocation
  clk: k210: Rewrite to remove CCF
  clk: k210: Move pll into the rest of the driver
  clk: k210: Implement soc_clk_dump
  clk: k210: Re-add support for setting rate
  clk: k210: Don't set PLL rates if we are already at the correct rate
  clk: k210: Remove bypass driver
  clk: k210: Move k210 clock out of its own subdirectory
  k210: dts: Set PLL1 to the same rate as PLL0
  k210: Don't imply CCF
  test: Add K210 PLL tests to sandbox defconfigs

 MAINTAINERS |4 +-
 arch/riscv/dts/k210.dtsi|2 +
 board/sipeed/maix/Kconfig   |2 -
 configs/sandbox64_defconfig |2 +
 configs/sandbox_defconfig   |2 +
 configs/sandbox_flattree_defconfig  |2 +
 configs/sipeed_maix_bitm_defconfig  |1 -
 drivers/clk/Kconfig |   14 +-
 drivers/clk/Makefile|2 +-
 drivers/clk/clk-uclass.c|   27 +-
 drivers/clk/clk_kendryte.c  | 1320 +++
 drivers/clk/kendryte/Kconfig|   12 -
 drivers/clk/kendryte/Makefile   |1 -
 drivers/clk/kendryte/bypass.c   |  273 -
 drivers/clk/kendryte/clk.c  |  668 
 drivers/clk/kendryte/pll.c  |  585 --
 drivers/clk/rockchip/clk_rk3308.c   |2 +-
 drivers/core/device.c   |2 +-
 drivers/net/gmac_rockchip.c |2 +-
 include/clk.h   |   30 +-
 include/dt-bindings/clock/k210-sysctl.h |   94 +-
 include/kendryte/bypass.h   |   31 -
 include/kendryte/clk.h  |   35 -
 include/kendryte/pll.h  |   34 -
 24 files changed, 1436 insertions(+), 1711 deletions(-)
 create mode 100644 drivers/clk/clk_kendryte.c
 delete mode 100644 drivers/clk/kendryte/Kconfig
 delete mode 100644 drivers/clk/kendryte/Makefile
 delete mode 100644 drivers/clk/kendryte/bypass.c
 delete mode 100644 drivers/clk/kendryte/clk.c
 delete mode 100644 drivers/clk/kendryte/pll.c
 delete mode 100644 include/kendryte/bypass.h
 delete mode 100644 include/kendryte/clk.h

-- 
2.31.0

Re: [PATCH] sunxi-common: support loading compressed kernel images on ARMv8

2021-06-03 Thread Arnaud Ferraris

Hi Andre,

Le 17/04/2021 à 20:23, Andre Przywara a écrit :
> On Sat, 17 Apr 2021 12:47:23 -0500
> Samuel Holland  wrote:
> 
> Hi Samuel,
> 
>> On 3/31/21 10:39 AM, Andre Przywara wrote:
>>> On 20/02/2021 12:14, Nicolas Boulenguez wrote:
>>>
>>> Hi Arnaud,
>>>   
 From: Arnaud Ferraris   
>>>
>>> as mentioned before, this looks useful, so can you re-send this with a
>>> commit message and your Signed-off-by:?  
>>
>> It looks like you picked up this patch regardless?
> 
> Yes, I asked him twice, without any reply. At the end I figured that
> the danger of a copyright infringement is low given the nature of the
> change, and I didn't feel this should block this useful feature. The
> alternative would be to have sent it as a patch of mine, but I felt
> that I should preserve his authorship, so took the patch anyway.
> I got a reply from him on another patch, and it's not his first U-Boot
> patch, so I think it's just an oversight (from the sender of the patch?)

Thanks for picking up and reworking this patch, and my apologies for not
replying earlier: I had personal stuff to deal with for a few months,
and am only now able to fully process my emails backlog.

I should be more reactive from now on, and might have a few more patches
for you in the near future.

All the best,
Arnaud

> 
> Chen-Yu asked about the feature lately, so if you think that approach
> is dodgy, we can revert it and take another version of the patch.
> 
>>> Also I was wondering if you could increase the COMP_SIZE? The 64MB look
>>> rather arbitrary and maybe unnecessarily limiting. I think we could go
>>> up till 0xfa0, but maybe should stop at 0xf80, to leave some
>>> space for further extensions?  
>>
>> And you changed KERNEL_COMP_SIZE to 0xb00. How does that work when
>> U-Boot itself is at 0x4a00 (KERNEL_COMP_ADDR_R + 0x600)?
> 
> It's not anymore at this time, that's just the load address, and it
> relocates itself to the end of DRAM very early. So basically the whole
> memory except the very end is available.
> Btw, the reason we confine everything to below 0x5000 is just that
> we need to concatenate the base (0x4) with that offset, and cannot
> use arithmetic, because that doesn't work in the Makefiles.
> 
> Cheers,
> Andre
> 
 ---
  include/configs/sunxi-common.h | 15 +++
  1 file changed, 15 insertions(+)

 diff --git a/include/configs/sunxi-common.h 
 b/include/configs/sunxi-common.h
 index 5b0bec0561..227284cd29 100644
 --- a/include/configs/sunxi-common.h
 +++ b/include/configs/sunxi-common.h
 @@ -291,6 +291,8 @@ extern int soft_i2c_gpio_scl;
   */
  #define BOOTM_SIZE__stringify(0xa00)
  #define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(008))
 +#define KERNEL_COMP_ADDR_R__stringify(SDRAM_OFFSET(400))
 +#define KERNEL_COMP_SIZE  __stringify(0x400)
  #define FDT_ADDR_R__stringify(SDRAM_OFFSET(FA0))
  #define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(FC0))
  #define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(FD0))
 @@ -332,6 +334,18 @@ extern int soft_i2c_gpio_scl;
"pxefile_addr_r=" PXEFILE_ADDR_R "\0" \
"ramdisk_addr_r=" RAMDISK_ADDR_R "\0"
  
 +#ifdef CONFIG_ARM64
 +
 +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS \
 +  "kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \
 +  "kernel_comp_size=" KERNEL_COMP_SIZE "\0"
 +
 +#else
 +
 +#define MEM_LAYOUT_ENV_EXTRA_SETTINGS ""  
>>
>> This can be defined to nothing. No empty string is needed.
>>
 +
 +#endif
 +
  #define DFU_ALT_INFO_RAM \
"dfu_alt_info_ram=" \
"kernel ram " KERNEL_ADDR_R " 0x100;" \
 @@ -487,6 +501,7 @@ extern int soft_i2c_gpio_scl;
  #define CONFIG_EXTRA_ENV_SETTINGS \
CONSOLE_ENV_SETTINGS \
MEM_LAYOUT_ENV_SETTINGS \
 +  MEM_LAYOUT_ENV_EXTRA_SETTINGS \
DFU_ALT_INFO_RAM \
"fdtfile=" FDTFILE "\0" \
"console=ttyS0,115200\0" \
  
>>>   
>>
>

Re: [v3, 1/3] mmc: fsl_esdhc: convert to CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT

2021-06-03 Thread Jaehoon Chung

On 6/3/21 11:51 AM, Yangbo Lu wrote:
> For eSDHC, power supply is through peripheral circuit.
> Some eSDHC versions have value 0 of the bit but that
> does not reflect the truth. 3.3V is common for SD/MMC,
> and is supported for all boards with eSDHC in current
> u-boot. So, make 3.3V is supported in default in code.
> CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT can be enabled if
> future board does not support 3.3V.
> 
> This is also a fix-up for one previous patch, which converted
> to use IS_ENABLED() for CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
> that is not a Kconfig option.
> 
> Fixes: 52faec31827e ("mmc: fsl_esdhc: replace most #ifdefs by IS_ENABLED()")
> Signed-off-by: Yangbo Lu 

Reviewed-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

> ---
> Changes for v2:
>   - Updated copyright.
> Chagnes for v3:
>   - Fixed code logic.
> ---
>  drivers/mmc/Kconfig |  7 +++
>  drivers/mmc/fsl_esdhc.c | 17 ++---
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 8901456967..0909f502a1 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -798,6 +798,13 @@ config FSL_ESDHC_33V_IO_RELIABILITY_WORKAROUND
> This option assumes no hotplug, and u-boot has to make all the way to
> to linux to use 1.8v UHS-I speed mode if has card.
>  
> +config FSL_ESDHC_VS33_NOT_SUPPORT
> + bool "3.3V power supply not supported"
> + depends on FSL_ESDHC
> + help
> +   For eSDHC, power supply is through peripheral circuit. 3.3V support is
> +   common. Select this if 3.3V power supply not supported.
> +
>  config FSL_ESDHC_IMX
>   bool "Freescale/NXP i.MX eSDHC controller support"
>   help
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index 7501fdb71e..1d98fa65c4 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
> - * Copyright 2019-2020 NXP
> + * Copyright 2019-2021 NXP
>   * Andy Fleming
>   *
>   * Based vaguely on the pxa mmc code:
> @@ -795,10 +795,21 @@ static void fsl_esdhc_get_cfg_common(struct 
> fsl_esdhc_priv *priv,
>   u32 caps;
>  
>   caps = esdhc_read32(>hostcapblt);
> +
> + /*
> +  * For eSDHC, power supply is through peripheral circuit. Some eSDHC
> +  * versions have value 0 of the bit but that does not reflect the
> +  * truth. 3.3V is common for SD/MMC, and is supported for all boards
> +  * with eSDHC in current u-boot. So, make 3.3V is supported in
> +  * default in code. CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT can be enabled
> +  * if future board does not support 3.3V.
> +  */
> + caps |= HOSTCAPBLT_VS33;
> + if (IS_ENABLED(CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT))
> + caps &= ~HOSTCAPBLT_VS33;
> +
>   if (IS_ENABLED(CONFIG_SYS_FSL_ERRATUM_ESDHC135))
>   caps &= ~(HOSTCAPBLT_SRS | HOSTCAPBLT_VS18 | HOSTCAPBLT_VS30);
> - if (IS_ENABLED(CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33))
> - caps |= HOSTCAPBLT_VS33;
>   if (caps & HOSTCAPBLT_VS18)
>   cfg->voltages |= MMC_VDD_165_195;
>   if (caps & HOSTCAPBLT_VS30)
>

[PATCH] arm: iproc: Add higher speed configurations

2021-06-03 Thread Chris Packham

Add support for 1.3GHz, 1.35GHz and 1.4GHz parts. This is based on
equivalent code in Broadcom's LDK 5.0.6.

Signed-off-by: Chris Packham 

---
As Broadcom are currently migrating users to the BCM58525BB1KF14G part
I suspect others may want this. In our case because we wanted to still
run at 1.2GHz we also had to set CONFIG_ARMCLK to 1200.

 arch/arm/cpu/armv7/iproc-common/armpll.c | 29 +---
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/arch/arm/cpu/armv7/iproc-common/armpll.c 
b/arch/arm/cpu/armv7/iproc-common/armpll.c
index efa3d9e5a9bd..8c3a323f0654 100644
--- a/arch/arm/cpu/armv7/iproc-common/armpll.c
+++ b/arch/arm/cpu/armv7/iproc-common/armpll.c
@@ -19,19 +19,22 @@ struct armpll_parameters {
 };
 
 struct armpll_parameters armpll_clk_tab[] = {
-   {   25, 64,  1, 1, 0},
-   {  100, 64,  1, 1, 2},
-   {  400, 64,  1, 1, 6},
-   {  448, 71, 713050, 1, 6},
-   {  500, 80,  1, 1, 6},
-   {  560, 89, 629145, 1, 6},
-   {  600, 96,  1, 1, 6},
-   {  800, 64,  1, 1, 7},
-   {  896, 71, 713050, 1, 7},
-   { 1000, 80,  1, 1, 7},
-   { 1100, 88,  1, 1, 7},
-   { 1120, 89, 629145, 1, 7},
-   { 1200, 96,  1, 1, 7},
+   {   25,  64,  1, 1, 0},
+   {  100,  64,  1, 1, 2},
+   {  400,  64,  1, 1, 6},
+   {  448,  71, 713050, 1, 6},
+   {  500,  80,  1, 1, 6},
+   {  560,  89, 629145, 1, 6},
+   {  600,  96,  1, 1, 6},
+   {  800,  64,  1, 1, 7},
+   {  896,  71, 713050, 1, 7},
+   { 1000,  80,  1, 1, 7},
+   { 1100,  88,  1, 1, 7},
+   { 1120,  89, 629145, 1, 7},
+   { 1200,  96,  1, 1, 7},
+   { 1300, 104,  1, 1, 7},
+   { 1350, 108,  1, 1, 7},
+   { 1400, 112,  1, 1, 7},
 };
 
 uint32_t armpll_config(uint32_t clkmhz)
-- 
2.31.1

Re: [BUG] network is broken on Orange Pi PC


On 6/3/21 8:00 PM, Andreas Rehn wrote:



Am Do., 3. Juni 2021 um 18:58 Uhr schrieb Andre Przywara
mailto:andre.przyw...@arm.com>>:

On Thu, 3 Jun 2021 18:09:25 +0200
Heinrich Schuchardt mailto:xypron.g...@gmx.de>>
wrote:

Hi,

 > On 6/3/21 1:04 PM, Andre Przywara wrote:
 > > On Thu, 3 Jun 2021 12:20:34 +0200
 > > Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:
 > >
 > > Hi,
 > >
 > >> On 6/3/21 11:04 AM, Andre Przywara wrote:
 > >>> On Thu, 3 Jun 2021 09:46:48 +0200
 > >>> Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:
 > >>>
 > >>> Hi Heinrich,
 > >>>
 >  On 6/2/21 3:08 PM, Ramon Fried wrote:
 > > On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt
mailto:xypron.g...@gmx.de>> wrote:
 > >>
 > >> Dear all,
 > >>
 > >> network is broken in U-Boot on orangepi_pc_defconfig:
 > >>>
 > >>> Thanks for the report!
 > >>>
 > >>
 > >> U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 -
21:26:56 +)
 > >> Allwinner Technology
 > >> eth0: ethernet@1c3
 > >> => dhcp
 > >> sun8i_emac_eth_start: Timeout
 > >>
 > >> Best regards
 > >>
 > >> Heinrich
 > >>
 > > Hi Heinrich, I don't have OrangePi. can you bisect and tell
me when it broke ?
 > > Thanks.
 > > Ramon.
 > >
 > 
 >  Git bisect points to:
 > 
 >  commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
 >  Author: Andre Przywara mailto:andre.przyw...@arm.com>>
 >  Date:   Mon Jul 6 01:40:45 2020 +0100
 > 
 >         net: sun8i-emac: Lower MDIO frequency
 > 
 >  Reverting the patch solves the problem for the OrangePi PC.
 > 
 >  According to the commit message the change was only needed
for needed
 >  for external PHYs.
 > >>>
 > >>> The external PHY on the Pine64 (non-plus) was the trigger,
however
 > >>> both the manual and the Linux driver point to that we
definitely need a
 > >>> higher divider. From what I can see, AHB2 (the EMAC clock)
runs at 200
 > >>> MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16"
results in 12.5
 > >>> MHz MDIO frequency. Can you check whether any other divider
values fix
 > >>> this for you as well?
 > >>
 > >> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was
used
 > >> before your patch.
 > >>
 > >> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
 > >>    Waiting for PHY auto negotiation to complete. done
 > >> MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
 > >> MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
 > >> MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout
 > >>
 > >> What is wrong about the approach in
 > >>
 > >> [PATCH 1/1] net: sun8i-emac: fix MDIO frequency
 > >> https://lists.denx.de/pipermail/u-boot/2021-June/451305.html
 ?
 > >
 > > The MDIO spec says that the maximum frequency on the MDIO bus
should be
 > > 2.5 MHz. On the H3 with 200 MHz AHB and with a divider of 16
it's 12.5
 >
 > The dts says for the MDIO:
 >
 > int_mii_phy: ethernet-phy@1 {
 >       clocks = < CLK_BUS_EPHY>;

I think that is the clock to drive the PHY logic, not the MDIO bus.
It's a gate for AHB1, in this case, which seems to be 200 MHz as well
(because rate(AHB2)=rate(AHB1)/1).

 > "ahb" refers to CLK_BUS_SPI1:
 >
 > spi1: spi@1c69000 {
 >       clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
 >       clock-names = "ahb", "mod";
 >
 > Why are you mentioning AHB?

AHB stands for "Advanced High-performance Bus", which is a traditional
term for a (faster, data centric) bus interface in the ARM
bus world. I am not sure the exact term is actually correct anymore
with recent bus implementations, but the H3 manual refers to AHB
everywhere, in particular as the bus name for the EMAC IP (figure
4-1 System
Bus Tree). Apparently the bus clock is used as the clock source for the
MDIO bus as well - after dividing it.

 > > MHz. Apparently the internal H3 PHY can tolerate those high
 > > frequencies, but it's beyond the spec. And certainly it should
not fail
 > > with lower frequencies. And indeed it works for me on the H2+
(which I
 > > understand is just a binned version of the H3).
 > >
 > >> The Linux 5.10 driver runs fine no matter what value we choose
for the
 > >> divider in U-Boot.
 > >
 > > Because it programs the divider correctly:
 > >

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n316

Re: [BUG] network is broken on Orange Pi PC


On 6/3/21 6:57 PM, Andre Przywara wrote:

On Thu, 3 Jun 2021 18:09:25 +0200
Heinrich Schuchardt  wrote:

Hi,


On 6/3/21 1:04 PM, Andre Przywara wrote:

On Thu, 3 Jun 2021 12:20:34 +0200
Heinrich Schuchardt  wrote:

Hi,


On 6/3/21 11:04 AM, Andre Przywara wrote:

On Thu, 3 Jun 2021 09:46:48 +0200
Heinrich Schuchardt  wrote:

Hi Heinrich,


On 6/2/21 3:08 PM, Ramon Fried wrote:

On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt  wrote:


Dear all,

network is broken in U-Boot on orangepi_pc_defconfig:


Thanks for the report!



U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
Allwinner Technology
eth0: ethernet@1c3
=> dhcp
sun8i_emac_eth_start: Timeout

Best regards

Heinrich


Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it broke ?
Thanks.
Ramon.



Git bisect points to:

commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
Author: Andre Przywara 
Date:   Mon Jul 6 01:40:45 2020 +0100

net: sun8i-emac: Lower MDIO frequency

Reverting the patch solves the problem for the OrangePi PC.

According to the commit message the change was only needed for needed
for external PHYs.


The external PHY on the Pine64 (non-plus) was the trigger, however
both the manual and the Linux driver point to that we definitely need a
higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200
MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5
MHz MDIO frequency. Can you check whether any other divider values fix
this for you as well?


MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was used
before your patch.

MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
Waiting for PHY auto negotiation to complete. done
MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout

What is wrong about the approach in

[PATCH 1/1] net: sun8i-emac: fix MDIO frequency
https://lists.denx.de/pipermail/u-boot/2021-June/451305.html ?


The MDIO spec says that the maximum frequency on the MDIO bus should be
2.5 MHz. On the H3 with 200 MHz AHB and with a divider of 16 it's 12.5


The dts says for the MDIO:

int_mii_phy: ethernet-phy@1 {
clocks = < CLK_BUS_EPHY>;


I think that is the clock to drive the PHY logic, not the MDIO bus.
It's a gate for AHB1, in this case, which seems to be 200 MHz as well
(because rate(AHB2)=rate(AHB1)/1).


"ahb" refers to CLK_BUS_SPI1:

spi1: spi@1c69000 {
clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
clock-names = "ahb", "mod";

Why are you mentioning AHB?


AHB stands for "Advanced High-performance Bus", which is a traditional
term for a (faster, data centric) bus interface in the ARM
bus world. I am not sure the exact term is actually correct anymore
with recent bus implementations, but the H3 manual refers to AHB
everywhere, in particular as the bus name for the EMAC IP (figure 4-1 System
Bus Tree). Apparently the bus clock is used as the clock source for the
MDIO bus as well - after dividing it.


MHz. Apparently the internal H3 PHY can tolerate those high
frequencies, but it's beyond the spec. And certainly it should not fail
with lower frequencies. And indeed it works for me on the H2+ (which I
understand is just a binned version of the H3).


The Linux 5.10 driver runs fine no matter what value we choose for the
divider in U-Boot.


Because it programs the divider correctly:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n316
I take it you have no problems with Linux, so the divider being too
high cannot be the root cause of the problem.


Function stmmac_clk_csr_set() depends on the rate of the clock named
"stmmaceth":

ethernet@1c3 {
clocks = < CLK_BUS_EMAC>;
clock-names = "stmmaceth";

How do we get the frequency of this clock?


Have you checked /sys/kernel/debug/clk/clk_summary? You could also
insert some printk to be sure. Otherwise the definition of bus_emac_clk
and CLK_BUS_EMAC in drivers/clk/sunxi-ng/ccu-sun8i-h3.c tell you that
it's a gate for ahb2. All of those point to 200 MHz on my OPi Zero.


I have appended clk_summary.

stmmac_clk_csr_set():
dwmac-sun8i 1c3.ethernet: priv->plat->has_sun8i 1
dwmac-sun8i 1c3.ethernet: clk_rate 2
dwmac-sun8i 1c3.ethernet: priv->clk_csr 3

Best regards

Heinrich



Hope that helps!

Cheers,
Andre


Best regards

Heinrich



So I'd rather fix this problem properly and correctly, especially as it
seems to be more related to the EMAC soft reset (where your error
message comes from).


But I see a message:

dwmac-sun8i 1c3.ethernet:
Current syscon value is not the default 148000 (expect 58000)

@default_syscon_value:
The default value of the EMAC register in syscon
This value is used for disabling properly EMAC
and used as a good starting value in case of the
boot process(uboot) leave some stuff.


Yeah, I never got

[PATCH 1/1] test: NULL dereference in test-uclass

If a test-uclass device is probed outside a test, uts is not defined.
Avoid a NULL dereference in this case.

Signed-off-by: Heinrich Schuchardt 
---
 test/dm/test-uclass.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/test/dm/test-uclass.c b/test/dm/test-uclass.c
index 067701734a..d2d1e0f190 100644
--- a/test/dm/test-uclass.c
+++ b/test/dm/test-uclass.c
@@ -32,6 +32,9 @@ static int test_post_bind(struct udevice *dev)
struct unit_test_state *uts = test_get_state();
struct dm_test_perdev_uc_pdata *uc_pdata;

+   if (!uts)
+   return 0;
+
dm_testdrv_op_count[DM_TEST_OP_POST_BIND]++;
ut_assert(!device_active(dev));

@@ -57,6 +60,9 @@ static int test_pre_probe(struct udevice *dev)
test-uclass.cstruct dm_test_uclass_perdev_priv *priv = 
dev_get_uclass_priv(dev);
struct unit_test_state *uts = test_get_state();

+   if (!uts)
+   return 0;
+
dm_testdrv_op_count[DM_TEST_OP_PRE_PROBE]++;
ut_assert(priv);
ut_assert(device_active(dev));
@@ -70,6 +76,9 @@ static int test_post_probe(struct udevice *dev)
struct udevice *prev = list_entry(dev->uclass_node.prev,
struct udevice, uclass_node);

+   if (!uts)
+   return 0;
+
struct dm_test_uclass_perdev_priv *priv = dev_get_uclass_priv(dev);
struct uclass *uc = dev->uclass;

@@ -103,6 +112,9 @@ static int test_init(struct uclass *uc)
 {
struct unit_test_state *uts = test_get_state();

+   if (!uts)
+   return 0;
+
dm_testdrv_op_count[DM_TEST_OP_INIT]++;
ut_assert(uclass_get_priv(uc));

--
2.30.2

Re: [BUG] network is broken on Orange Pi PC

2021-06-03 Thread Andreas Rehn

Am Do., 3. Juni 2021 um 18:58 Uhr schrieb Andre Przywara <
andre.przyw...@arm.com>:

> On Thu, 3 Jun 2021 18:09:25 +0200
> Heinrich Schuchardt  wrote:
>
> Hi,
>
> > On 6/3/21 1:04 PM, Andre Przywara wrote:
> > > On Thu, 3 Jun 2021 12:20:34 +0200
> > > Heinrich Schuchardt  wrote:
> > >
> > > Hi,
> > >
> > >> On 6/3/21 11:04 AM, Andre Przywara wrote:
> > >>> On Thu, 3 Jun 2021 09:46:48 +0200
> > >>> Heinrich Schuchardt  wrote:
> > >>>
> > >>> Hi Heinrich,
> > >>>
> >  On 6/2/21 3:08 PM, Ramon Fried wrote:
> > > On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt <
> xypron.g...@gmx.de> wrote:
> > >>
> > >> Dear all,
> > >>
> > >> network is broken in U-Boot on orangepi_pc_defconfig:
> > >>>
> > >>> Thanks for the report!
> > >>>
> > >>
> > >> U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56
> +)
> > >> Allwinner Technology
> > >> eth0: ethernet@1c3
> > >> => dhcp
> > >> sun8i_emac_eth_start: Timeout
> > >>
> > >> Best regards
> > >>
> > >> Heinrich
> > >>
> > > Hi Heinrich, I don't have OrangePi. can you bisect and tell me
> when it broke ?
> > > Thanks.
> > > Ramon.
> > >
> > 
> >  Git bisect points to:
> > 
> >  commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
> >  Author: Andre Przywara 
> >  Date:   Mon Jul 6 01:40:45 2020 +0100
> > 
> > net: sun8i-emac: Lower MDIO frequency
> > 
> >  Reverting the patch solves the problem for the OrangePi PC.
> > 
> >  According to the commit message the change was only needed for
> needed
> >  for external PHYs.
> > >>>
> > >>> The external PHY on the Pine64 (non-plus) was the trigger, however
> > >>> both the manual and the Linux driver point to that we definitely
> need a
> > >>> higher divider. From what I can see, AHB2 (the EMAC clock) runs at
> 200
> > >>> MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in
> 12.5
> > >>> MHz MDIO frequency. Can you check whether any other divider values
> fix
> > >>> this for you as well?
> > >>
> > >> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was used
> > >> before your patch.
> > >>
> > >> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
> > >>Waiting for PHY auto negotiation to complete. done
> > >> MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
> > >> MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
> > >> MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout
> > >>
> > >> What is wrong about the approach in
> > >>
> > >> [PATCH 1/1] net: sun8i-emac: fix MDIO frequency
> > >> https://lists.denx.de/pipermail/u-boot/2021-June/451305.html ?
> > >
> > > The MDIO spec says that the maximum frequency on the MDIO bus should be
> > > 2.5 MHz. On the H3 with 200 MHz AHB and with a divider of 16 it's
> 12.5
> >
> > The dts says for the MDIO:
> >
> > int_mii_phy: ethernet-phy@1 {
> >   clocks = < CLK_BUS_EPHY>;
>
> I think that is the clock to drive the PHY logic, not the MDIO bus.
> It's a gate for AHB1, in this case, which seems to be 200 MHz as well
> (because rate(AHB2)=rate(AHB1)/1).
>
> > "ahb" refers to CLK_BUS_SPI1:
> >
> > spi1: spi@1c69000 {
> >   clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
> >   clock-names = "ahb", "mod";
> >
> > Why are you mentioning AHB?
>
> AHB stands for "Advanced High-performance Bus", which is a traditional
> term for a (faster, data centric) bus interface in the ARM
> bus world. I am not sure the exact term is actually correct anymore
> with recent bus implementations, but the H3 manual refers to AHB
> everywhere, in particular as the bus name for the EMAC IP (figure 4-1
> System
> Bus Tree). Apparently the bus clock is used as the clock source for the
> MDIO bus as well - after dividing it.
>
> > > MHz. Apparently the internal H3 PHY can tolerate those high
> > > frequencies, but it's beyond the spec. And certainly it should not fail
> > > with lower frequencies. And indeed it works for me on the H2+ (which I
> > > understand is just a binned version of the H3).
> > >
> > >> The Linux 5.10 driver runs fine no matter what value we choose for the
> > >> divider in U-Boot.
> > >
> > > Because it programs the divider correctly:
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n316
> > > I take it you have no problems with Linux, so the divider being too
> > > high cannot be the root cause of the problem.
> >
> > Function stmmac_clk_csr_set() depends on the rate of the clock named
> > "stmmaceth":
> >
> > ethernet@1c3 {
> >   clocks = < CLK_BUS_EMAC>;
> >   clock-names = "stmmaceth";
> >
> > How do we get the frequency of this clock?
>
> Have you checked /sys/kernel/debug/clk/clk_summary? You could also
> insert some printk to be sure. Otherwise the definition of bus_emac_clk
> and CLK_BUS_EMAC in drivers/clk/sunxi-ng/ccu-sun8i-h3.c tell you that
> it's a gate for ahb2. All of

Re: [BUG] network is broken on Orange Pi PC

On Thu, 3 Jun 2021 18:09:25 +0200
Heinrich Schuchardt  wrote:

Hi,

> On 6/3/21 1:04 PM, Andre Przywara wrote:
> > On Thu, 3 Jun 2021 12:20:34 +0200
> > Heinrich Schuchardt  wrote:
> >
> > Hi,
> >  
> >> On 6/3/21 11:04 AM, Andre Przywara wrote:  
> >>> On Thu, 3 Jun 2021 09:46:48 +0200
> >>> Heinrich Schuchardt  wrote:
> >>>
> >>> Hi Heinrich,
> >>>  
>  On 6/2/21 3:08 PM, Ramon Fried wrote:  
> > On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt 
> >  wrote:  
> >>
> >> Dear all,
> >>
> >> network is broken in U-Boot on orangepi_pc_defconfig:  
> >>>
> >>> Thanks for the report!
> >>>  
> >>
> >> U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
> >> Allwinner Technology
> >> eth0: ethernet@1c3  
> >> => dhcp  
> >> sun8i_emac_eth_start: Timeout
> >>
> >> Best regards
> >>
> >> Heinrich
> >>  
> > Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it 
> > broke ?
> > Thanks.
> > Ramon.
> >  
> 
>  Git bisect points to:
> 
>  commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
>  Author: Andre Przywara 
>  Date:   Mon Jul 6 01:40:45 2020 +0100
> 
> net: sun8i-emac: Lower MDIO frequency
> 
>  Reverting the patch solves the problem for the OrangePi PC.
> 
>  According to the commit message the change was only needed for needed
>  for external PHYs.  
> >>>
> >>> The external PHY on the Pine64 (non-plus) was the trigger, however
> >>> both the manual and the Linux driver point to that we definitely need a
> >>> higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200
> >>> MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5
> >>> MHz MDIO frequency. Can you check whether any other divider values fix
> >>> this for you as well?  
> >>
> >> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was used
> >> before your patch.
> >>
> >> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
> >>Waiting for PHY auto negotiation to complete. done
> >> MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
> >> MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
> >> MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout
> >>
> >> What is wrong about the approach in
> >>
> >> [PATCH 1/1] net: sun8i-emac: fix MDIO frequency
> >> https://lists.denx.de/pipermail/u-boot/2021-June/451305.html ?  
> >
> > The MDIO spec says that the maximum frequency on the MDIO bus should be
> > 2.5 MHz. On the H3 with 200 MHz AHB and with a divider of 16 it's 12.5  
> 
> The dts says for the MDIO:
> 
> int_mii_phy: ethernet-phy@1 {
>   clocks = < CLK_BUS_EPHY>;

I think that is the clock to drive the PHY logic, not the MDIO bus.
It's a gate for AHB1, in this case, which seems to be 200 MHz as well
(because rate(AHB2)=rate(AHB1)/1).

> "ahb" refers to CLK_BUS_SPI1:
> 
> spi1: spi@1c69000 {
>   clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
>   clock-names = "ahb", "mod";
> 
> Why are you mentioning AHB?

AHB stands for "Advanced High-performance Bus", which is a traditional
term for a (faster, data centric) bus interface in the ARM
bus world. I am not sure the exact term is actually correct anymore
with recent bus implementations, but the H3 manual refers to AHB
everywhere, in particular as the bus name for the EMAC IP (figure 4-1 System
Bus Tree). Apparently the bus clock is used as the clock source for the
MDIO bus as well - after dividing it.

> > MHz. Apparently the internal H3 PHY can tolerate those high
> > frequencies, but it's beyond the spec. And certainly it should not fail
> > with lower frequencies. And indeed it works for me on the H2+ (which I
> > understand is just a binned version of the H3).
> >  
> >> The Linux 5.10 driver runs fine no matter what value we choose for the
> >> divider in U-Boot.  
> >
> > Because it programs the divider correctly:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n316
> > I take it you have no problems with Linux, so the divider being too
> > high cannot be the root cause of the problem.  
> 
> Function stmmac_clk_csr_set() depends on the rate of the clock named
> "stmmaceth":
> 
> ethernet@1c3 {
>   clocks = < CLK_BUS_EMAC>;
>   clock-names = "stmmaceth";
> 
> How do we get the frequency of this clock?

Have you checked /sys/kernel/debug/clk/clk_summary? You could also
insert some printk to be sure. Otherwise the definition of bus_emac_clk
and CLK_BUS_EMAC in drivers/clk/sunxi-ng/ccu-sun8i-h3.c tell you that
it's a gate for ahb2. All of those point to 200 MHz on my OPi Zero.

Hope that helps!

Cheers,
Andre
> 
> Best regards
> 
> Heinrich
> 
> >
> > So I'd rather fix this problem properly and correctly, especially as it
> > seems to be more related to the EMAC soft reset (where your error
> > message comes from).
> >  
> >> But I see a message:
> >>
>

Re: [PATCH V2] clk: clk_versaclock: Add support for versaclock driver





On 6/3/21 8:28 AM, Adam Ford wrote:
> The driver is based on the Versaclock driver from the Linux code, but
> due to the differences in the clock API between U-Boot and Linux, some
> pieces had to be changed.
>
> This driver creates a mux, pfd, pll, and a series of fod ouputs.
>   Rate   Usecnt  Name
> --
>   2500 0`-- x304-clock
>   2500 0`-- clock-control...@6a.mux
>   2500 0|-- clock-control...@6a.pfd
>   28   0|   `-- clock-control...@6a.pll
>    0|   |-- clock-controller@6a.fod0
>    0|   |   `-- 
clock-controller@6a.out1
>    0|   |-- clock-controller@6a.fod1
>    0|   |   `-- 
clock-controller@6a.out2
>   5000 0|   |-- clock-controller@6a.fod2
>   5000 0|   |   `-- 
clock-controller@6a.out3
>   125000|   `-- clock-controller@6a.fod3
>   125000|   `-- 
clock-controller@6a.out4
>   2500 0`-- clock-controller@6a.out0_sel_i2cb
>
> A translation function is added so the references to < X> get 
routed
> to the corresponding clock-control...@6a.outx.
>
> Signed-off-by: Adam Ford 
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 40a5a5dd88..2a7507ea18 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -197,4 +197,13 @@ config SANDBOX_CLK_CCF
>  Enable this option if you want to test the Linux kernel's Common
>  Clock Framework [CCF] code in U-Boot's Sandbox clock driver.
>
> +config CLK_VERSACLOCK
> +  tristate "Enable VersaClock 5/6 devices"
> +  depends on CLK
> +  depends on CLK_CCF
> +  depends on OF_CONTROL
> +  help
> +This driver supports the IDT VersaClock 5 and VersaClock 6
> +programmable clock generators.
> +
>   endmenu
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 645709b855..6f5ddafd64 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
>   obj-$(CONFIG_STM32H7) += clk_stm32h7.o
>   obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
>   obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
> +obj-$(CONFIG_CLK_VERSACLOCK) += clk_versaclock.o
> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
> new file mode 100644
> index 00..ee5562978a
> --- /dev/null
> +++ b/drivers/clk/clk_versaclock.c
> @@ -0,0 +1,979 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Driver for IDT Versaclock 5/6
> + *
> + * Derived from code Copyright (C) 2017 Marek Vasut 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +/* Configuration register block */
> +#define VC5_PRIM_SRC_SHDN 0x10
> +#define VC5_PRIM_SRC_SHDN_EN_XTAL BIT(7)
> +#define VC5_PRIM_SRC_SHDN_EN_CLKINBIT(6)
> +#define VC5_XTAL_X1_LOAD_CAP  0x12
> +#define VC5_XTAL_X2_LOAD_CAP  0x13
> +#define VC5_REF_DIVIDER   0x15
> +#define VC5_REF_DIVIDER_SEL_PREDIV2   BIT(7)
> +#define VC5_REF_DIVIDER_REF_DIV(n)((n) & 0x3f)
> +#define VC5_VCO_CTRL_AND_PREDIV   0x16
> +#define VC5_VCO_CTRL_AND_PREDIV_BYPASS_PREDIV BIT(7)
> +#define VC5_FEEDBACK_INT_DIV  0x17
> +
> +/* Output divider control for divider 1,2,3,4 */
> +#define VC5_OUT_DIV_CONTROL(idx)  (0x21 + ((idx) * 0x10))
> +#define VC5_OUT_DIV_CONTROL_RESET BIT(7)
> +#define VC5_OUT_DIV_CONTROL_SELB_NORM BIT(3)
> +#define VC5_OUT_DIV_CONTROL_SEL_EXT   BIT(2)
> +#define VC5_OUT_DIV_CONTROL_EN_FODBIT(0)
> +#define VC5_OUT_DIV_FRAC(idx, n)  (0x22 + ((idx) * 0x10) + (n))
> +#define VC5_OUT_DIV_INT(idx, n)   (0x2d + ((idx) * 0x10) + (n))
> +
> +/* Clock control register for clock 1,2 */
> +#define VC5_CLK_OUTPUT_CFG(idx, n)(0x60 + ((idx) * 0x2) + (n))
> +#define VC5_CLK_OUTPUT_CFG0_CFG_SHIFT 5
> +#define VC5_CLK_OUTPUT_CFG0_CFG_MASK GENMASK(7, 
VC5_CLK_OUTPUT_CFG0_CFG_SHIFT)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_LVPECL(VC5_LVPECL)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_CMOS  (VC5_CMOS)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_HCSL33(VC5_HCSL33)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_LVDS  (VC5_LVDS)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_CMOS2 (VC5_CMOS2)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_CMOSD (VC5_CMOSD)
> +#define VC5_CLK_OUTPUT_CFG0_CFG_HCSL25(VC5_HCSL25)
> +#define VC5_CLK_OUTPUT_CFG0_PWR_SHIFT 3
> +#define VC5_CLK_OUTPUT_CFG0_PWR_MASK GENMASK(4,

Re: [PATCH] env: Leave invalid env for nowhere location

2021-06-03 Thread Kunihiko Hayashi


Hi Marek,
Sorry for rate reply.

On 2021/05/25 16:35, Marek Vasut wrote:

On 5/12/21 4:09 PM, Kunihiko Hayashi wrote:

When CONFIG_ENV_IS_NOWHERE is enabled, env_nowhere_init() sets ENV_INVALID
to gd->env_valid, and sets default_environment before relocation to
gd->env_addr. After that, env_init() switches gd->env_valid to ENV_VALID
by the previous fix.

If gd->env_valid is ENV_INVALID, env_get_char() returns relocated
default_environment, however, env_get_char() returns gd->env_addr before
relocation since gd->env_valid is ENV_VALID, and access to gd->env_addr
will cause a fault.

This leaves gd->env_valid as ENV_INVALID for "nowhere" location.


So do I understand this correctly that _after_ relocation, env_init() is
called and env_init() does not update gd->env_addr to the relocated one?


In my understandings, env_init() belongs to init_sequence_f[]
and env_init() is called before relocation.


I would expect that after relocation, if all you have is env_nowhere
driver, the env_nowhere_init() is called again from the first for() loop
of env_init() [1], which would set gd->env_valid to ENV_INVALID [1], and
that for() loop would exit with ret = -ENOENT [2], so then the last part
of env_init() would check for ret == -ENOENT and update gd->env_addr to
relocated default_environment [3].

324  int env_init(void)
325  {
326struct env_driver *drv;
327int ret = -ENOENT;
328int prio;
329
330for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio)); prio++) {
   /* Part [1] */
331  if (!drv->init || !(ret = drv->init()))
332env_set_inited(drv->location);
333  if (ret == -ENOENT)
334env_set_inited(drv->location);
335
336  debug("%s: Environment %s init done (ret=%d)\n", __func__,
337drv->name, ret);
338
   /* Part [2] */
339  if (gd->env_valid == ENV_INVALID)
340ret = -ENOENT;
341}
342
343if (!prio)
344  return -ENODEV;
345
 /* Part [3] */
346if (ret == -ENOENT) {
   /* This should be relocated default_environment address */
347  gd->env_addr = (ulong)_environment[0];
348  gd->env_valid = ENV_VALID;
349
350  return 0;
351}
352
353return ret;
354  }

Or am I missing something obvious ?


These are called before relocation, and update gd->env_addr to non-relocated
default_environment by [3].

After that, gd->env_addr is relocated in initr_reloc_global_data()
if CONFIG_SYS_RELOC_GD_ENV_ADDR is defined.

| #ifdef CONFIG_SYS_RELOC_GD_ENV_ADDR
|   /*
|* Relocate the early env_addr pointer unless we know it is not inside
|* the binary. Some systems need this and for the rest, it doesn't hurt.
|*/
|   gd->env_addr += gd->reloc_off;
| #endif


However, I misunderstood my situation.
gd->reloc_off doesn't have the proper value because CONFIG_SYS_TEXT_BASE
is zero due to CONFIG_POSITION_INDENENDENT=y.

gd->reloc_off is calculated with CONFIG_SYS_TEXT_BASE in setup_reloc().

|   gd->reloc_off = gd->relocaddr - CONFIG_SYS_TEXT_BASE;

gd->env_addr is added with gd->reloc_off (== gd->relocaddr - 0),
as a result, gd->env_addr has wrong address.

In this case, I think the proper solution is to undefine
CONFIG_SYS_RELOC_GD_ENV_ADDR.

My patch isn't necessary no longer and your patch also works with
"nowhere".

Thank you,

---
Best Regards
Kunihiko Hayashi

Re: [BUG] network is broken on Orange Pi PC


On 6/3/21 1:04 PM, Andre Przywara wrote:

On Thu, 3 Jun 2021 12:20:34 +0200
Heinrich Schuchardt  wrote:

Hi,


On 6/3/21 11:04 AM, Andre Przywara wrote:

On Thu, 3 Jun 2021 09:46:48 +0200
Heinrich Schuchardt  wrote:

Hi Heinrich,


On 6/2/21 3:08 PM, Ramon Fried wrote:

On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt  wrote:


Dear all,

network is broken in U-Boot on orangepi_pc_defconfig:


Thanks for the report!



U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
Allwinner Technology
eth0: ethernet@1c3
=> dhcp
sun8i_emac_eth_start: Timeout

Best regards

Heinrich


Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it broke ?
Thanks.
Ramon.



Git bisect points to:

commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
Author: Andre Przywara 
Date:   Mon Jul 6 01:40:45 2020 +0100

   net: sun8i-emac: Lower MDIO frequency

Reverting the patch solves the problem for the OrangePi PC.

According to the commit message the change was only needed for needed
for external PHYs.


The external PHY on the Pine64 (non-plus) was the trigger, however
both the manual and the Linux driver point to that we definitely need a
higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200
MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5
MHz MDIO frequency. Can you check whether any other divider values fix
this for you as well?


MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was used
before your patch.

MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
Waiting for PHY auto negotiation to complete. done
MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout

What is wrong about the approach in

[PATCH 1/1] net: sun8i-emac: fix MDIO frequency
https://lists.denx.de/pipermail/u-boot/2021-June/451305.html ?


The MDIO spec says that the maximum frequency on the MDIO bus should be
2.5 MHz. On the H3 with 200 MHz AHB and with a divider of 16 it's 12.5


The dts says for the MDIO:

int_mii_phy: ethernet-phy@1 {
clocks = < CLK_BUS_EPHY>;

"ahb" refers to CLK_BUS_SPI1:

spi1: spi@1c69000 {
clocks = < CLK_BUS_SPI1>, < CLK_SPI1>;
clock-names = "ahb", "mod";

Why are you mentioning AHB?


MHz. Apparently the internal H3 PHY can tolerate those high
frequencies, but it's beyond the spec. And certainly it should not fail
with lower frequencies. And indeed it works for me on the H2+ (which I
understand is just a binned version of the H3).


The Linux 5.10 driver runs fine no matter what value we choose for the
divider in U-Boot.


Because it programs the divider correctly:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n316
I take it you have no problems with Linux, so the divider being too
high cannot be the root cause of the problem.


Function stmmac_clk_csr_set() depends on the rate of the clock named
"stmmaceth":

ethernet@1c3 {
clocks = < CLK_BUS_EMAC>;
clock-names = "stmmaceth";

How do we get the frequency of this clock?

Best regards

Heinrich



So I'd rather fix this problem properly and correctly, especially as it
seems to be more related to the EMAC soft reset (where your error
message comes from).


But I see a message:

dwmac-sun8i 1c3.ethernet:
Current syscon value is not the default 148000 (expect 58000)

@default_syscon_value:
The default value of the EMAC register in syscon
This value is used for disabling properly EMAC
and used as a good starting value in case of the
boot process(uboot) leave some stuff.


Yeah, I never got the reason for this message. If Linux wants a
certain value, it should program that. Whatever was left by someone
else (be it U-Boot or some other software/OS) should not matter.

Cheers,
Andre



Best regards

Heinrich




Can't we let the change depend on priv->use_internal_phy?

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 5a1b38bf80..d7553fe163 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int
addr, int devad, int reg)
* The EMAC clock is either 200 or 300 MHz, so we need a divider
* of 128 to get the MDIO frequency below the required 2.5 MHz.
*/
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

   mii_cmd |= MDIO_CMD_MII_BUSY;

@@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int
addr, int devad, int reg,
* The EMAC clock is either 200 or 300 MHz, so we need a divider
* of 128 to get the MDIO frequency below the required 2.5 MHz.
*/
-   mii_cmd |=

Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver

2021-06-03 Thread Luca Ceresoli

Hi Adam,

On 03/06/21 14:06, Adam Ford wrote:
> On Thu, Jun 3, 2021 at 3:34 AM Luca Ceresoli  wrote:
>>
>> On 24/05/21 19:53, Adam Ford wrote:
>>> The driver is based on the Versaclock driver from the Linux code, but
>>> do differences in the clock API between them, some pieces had to change.
>>
>> s/do/due to/ ?
>> s/had to change/had to be changed/
> 
> I am usually more careful about grammar.  I must have been tired.  :-)
> 
>>
>>> This driver creates a mux, pfd, pll, and a series of fod ouputs.
>>>  Rate   Usecnt  Name
>>> --
>>>  2500 0`-- x304-clock
>>>  2500 0`-- clock-control...@6a.mux
>>>  2500 0|-- clock-control...@6a.pfd
>>>  28   0|   `-- clock-control...@6a.pll
>>>   0|   |-- clock-controller@6a.fod0
>>>   0|   |   `-- 
>>> clock-controller@6a.out1
>>>   0|   |-- clock-controller@6a.fod1
>>>   0|   |   `-- 
>>> clock-controller@6a.out2
>>>  5000 0|   |-- clock-controller@6a.fod2
>>>  5000 0|   |   `-- 
>>> clock-controller@6a.out3
>>>  125000|   `-- clock-controller@6a.fod3
>>>  125000|   `-- 
>>> clock-controller@6a.out4
>>>  2500 0`-- clock-controller@6a.out0_sel_i2cb
>>>
>>> A translation function is added so the references to < X> get 
>>> routed
>>> to the corresponding clock-control...@6a.outx.
>>>
>>> Signed-off-by: Adam Ford 
>>
>> I've been reviewing this patch and it looks mostly OK to me except for a
>> few notes below, mostly minor ones. However my knowledge of the U-Boot
>> driver model is minimal, thus I couldn't go in depth in the most
>> interesting and critical part of Adam's work, i.e. the adaptations for
>> the U-Boot codebase. I'm afraid I cannot do more.
>>
>>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>>> index 645709b855..2a9ebec860 100644
>>> --- a/drivers/clk/Makefile
>>> +++ b/drivers/clk/Makefile
>>> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
>>>  obj-$(CONFIG_STM32H7) += clk_stm32h7.o
>>>  obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
>>>  obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
>>> +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o
>>
>> Nit: space after '+='.
> 
> make sense.
> 
>>
>>> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
>>> new file mode 100644
>>> index 00..30e49fad31
>>> --- /dev/null
>>> +++ b/drivers/clk/clk_versaclock.c
>>> @@ -0,0 +1,1025 @@
>>> +// SPDX-License-Identifier: GPL-2.0-or-later
>>> +/*
>>> + * Driver for IDT Versaclock 5/6
>>> + *
>>> + * Derived from code Copyright (C) 2017 Marek Vasut 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include 
>>
>> Missing file?
> 
> This was included a while ago in order to allow the device trees to build.

Apologies, I was on an old commit and didn't realize.

-- 
Luca

Re: [PATCH 1/3] usb: ehci-mx6: move mode set/detect to probe

2021-06-03 Thread Tim Harvey

On Tue, Apr 27, 2021 at 6:59 PM Marek Vasut  wrote:
>
> On 4/28/21 3:51 AM, Tim Harvey wrote:
> > On Tue, Apr 27, 2021 at 10:45 AM Marek Vasut  wrote:
> >>
> >> On 4/27/21 7:08 PM, Tim Harvey wrote:
> >>> There is no need to set and/or detect mode in of_to_plat and
> >>> accessing phy registers at that point before device power domain and
> >>> clock are enabled will cause hangs on platforms such as IMX8M Mini.
> >>>
> >>> Move the mode set/detect from of_to_plat into the probe and remove
> >>> the unnecessary of_to_plat.
> >>>
> >>> Signed-off-by: Tim Harvey 
> >>> ---
> >>>drivers/usb/host/ehci-mx6.c | 42 ++---
> >>>1 file changed, 16 insertions(+), 26 deletions(-)
> >>>
> >>> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> >>> index 06be9deaaa..c2dfe49012 100644
> >>> --- a/drivers/usb/host/ehci-mx6.c
> >>> +++ b/drivers/usb/host/ehci-mx6.c
> >>> @@ -539,28 +539,6 @@ static int ehci_usb_phy_mode(struct udevice *dev)
> >>>return 0;
> >>>}
> >>>
> >>> -static int ehci_usb_of_to_plat(struct udevice *dev)
> >>> -{
> >>> - struct usb_plat *plat = dev_get_plat(dev);
> >>> - enum usb_dr_mode dr_mode;
> >>> -
> >>> - dr_mode = usb_get_dr_mode(dev_ofnode(dev));
> >>> -
> >>> - switch (dr_mode) {
> >>> - case USB_DR_MODE_HOST:
> >>> - plat->init_type = USB_INIT_HOST;
> >>> - break;
> >>> - case USB_DR_MODE_PERIPHERAL:
> >>> - plat->init_type = USB_INIT_DEVICE;
> >>> - break;
> >>> - case USB_DR_MODE_OTG:
> >>> - case USB_DR_MODE_UNKNOWN:
> >>> - return ehci_usb_phy_mode(dev);
> >>> - };
> >>> -
> >>> - return 0;
> >>> -}
> >>> -
> >>
> >> [...]
> >>
> >>> @@ -764,7 +755,6 @@ U_BOOT_DRIVER(usb_mx6) = {
> >>>.name   = "ehci_mx6",
> >>>.id = UCLASS_USB,
> >>>.of_match = mx6_usb_ids,
> >>> - .of_to_plat = ehci_usb_of_to_plat,
> >>
> >> I wonder why it was implemented in of_to_plat originally , maybe there
> >> is some reason for that ?
> >
> > Marek,
> >
> > Looking back the commit that added the ehci_usb_ofdata_to_platdata was:
> > cccbddc38c43 ("usb: ehci-mx6: implement ofdata_to_platdata")
> >
> > Before that there was a board-specific function that would set the
> > usb_plat->init_type.
> >
> > The only reason to set usb_plat->init_type in of_to_plat would be so
> > that drivers/usb/host/usb-uclass.c would have knowledge of it but I
> > only see that it is set there in usb_setup_ehci_gadget.
>
> So interaction with Gadget, that's what I was afraid of.
>
> > I added Peng, Stefano, and Simon to the thread to see if they see an
> > issue with doing away with of_to_plat setting the usb_plat->init_type
> > prior to probe.
>
> I added Lukasz too.

Marek,

Is there something you want me to change here?

I am happy to test gadget support as my board has an OTG connector.
Could you give me some pointers on how to configure a gadget in U-Boot
in order to test?

Best regards,

Tim

Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver

On Thu, Jun 3, 2021 at 9:52 AM Sean Anderson  wrote:
>
>
>
> On 6/3/21 4:34 AM, Luca Ceresoli wrote:
>  > On 24/05/21 19:53, Adam Ford wrote:
>  >> The driver is based on the Versaclock driver from the Linux code, but
>  >> do differences in the clock API between them, some pieces had to change.
>  >
>  > s/do/due to/ ?
>  > s/had to change/had to be changed/
>  >
>  >> This driver creates a mux, pfd, pll, and a series of fod ouputs.
>  >>   Rate   Usecnt  Name
>  >> --
>  >>   2500 0`-- x304-clock
>  >>   2500 0`-- clock-control...@6a.mux
>  >>   2500 0|-- clock-control...@6a.pfd
>  >>   28   0|   `-- clock-control...@6a.pll
>  >>    0|   |-- 
> clock-controller@6a.fod0
>  >>    0|   |   `-- 
> clock-controller@6a.out1
>  >>    0|   |-- 
> clock-controller@6a.fod1
>  >>    0|   |   `-- 
> clock-controller@6a.out2
>  >>   5000 0|   |-- 
> clock-controller@6a.fod2
>  >>   5000 0|   |   `-- 
> clock-controller@6a.out3
>  >>   125000|   `-- 
> clock-controller@6a.fod3
>  >>   125000|   `-- 
> clock-controller@6a.out4
>  >>   2500 0`-- 
> clock-controller@6a.out0_sel_i2cb
>  >>
>  >> A translation function is added so the references to < X> get 
> routed
>  >> to the corresponding clock-control...@6a.outx.
>  >>
>  >> Signed-off-by: Adam Ford 
>  >
>  > I've been reviewing this patch and it looks mostly OK to me except for a
>  > few notes below, mostly minor ones. However my knowledge of the U-Boot
>  > driver model is minimal, thus I couldn't go in depth in the most
>  > interesting and critical part of Adam's work, i.e. the adaptations for
>  > the U-Boot codebase. I'm afraid I cannot do more.
>  >
>  >> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>  >> index 645709b855..2a9ebec860 100644
>  >> --- a/drivers/clk/Makefile
>  >> +++ b/drivers/clk/Makefile
>  >> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
>  >>   obj-$(CONFIG_STM32H7) += clk_stm32h7.o
>  >>   obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
>  >>   obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
>  >> +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o
>  >
>  > Nit: space after '+='.
>  >
>  >> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
>  >> new file mode 100644
>  >> index 00..30e49fad31
>  >> --- /dev/null
>  >> +++ b/drivers/clk/clk_versaclock.c
>  >> @@ -0,0 +1,1025 @@
>  >> +// SPDX-License-Identifier: GPL-2.0-or-later
>  >> +/*
>  >> + * Driver for IDT Versaclock 5/6
>  >> + *
>  >> + * Derived from code Copyright (C) 2017 Marek Vasut 
> 
>  >> + */
>  >> +
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +#include 
>  >> +
>  >> +#include 
>  >
>  > Missing file?
>  >
>  >> +
>  >> +/* VersaClock5 registers */
>  >> +#define VC5_OTP_CONTROL0x00
>  >> +
>  >> +/* Factory-reserved register block */
>  >> +#define VC5_RSVD_DEVICE_ID 0x01
>  >> +#define VC5_RSVD_ADC_GAIN_7_0  0x02
>  >> +#define VC5_RSVD_ADC_GAIN_15_8 0x03
>  >> +#define VC5_RSVD_ADC_OFFSET_7_00x04
>  >> +#define VC5_RSVD_ADC_OFFSET_15_8   0x05
>  >> +#define VC5_RSVD_TEMPY 0x06
>  >> +#define VC5_RSVD_OFFSET_TBIN   0x07
>  >> +#define VC5_RSVD_GAIN  0x08
>  >> +#define VC5_RSVD_TEST_NP   0x09
>  >> +#define VC5_RSVD_UNUSED0x0a
>  >> +#define VC5_RSVD_BANDGAP_TRIM_UP   0x0b
>  >> +#define VC5_RSVD_BANDGAP_TRIM_DN   0x0c
>  >> +#define VC5_RSVD_CLK_R_12_CLK_AMP_40x0d
>  >> +#define VC5_RSVD_CLK_R_34_CLK_AMP_40x0e
>  >> +#define VC5_RSVD_CLK_AMP_123   0x0f
>  >
>  > I wonder whether it really makes sense to define so many registers that
>  > are not used in the driver. But it's done the same way in the Linux
>  > driver, and it doesn't hurt much, so I'll be fine with or without them.
>
> I would leave them in so the next person who works on this driver doesn't 
> have to add them.\

OK.  Disregard my V2, and I'll submit a V3 today or tomorrow with the
register definitions left intact.

adam
>
> --Sean
>
>  >
>  > [...]
>  >
>  >> +static const struct udevice_id versaclock_ids[] = {
>  >> +   { .compatible = "idt,5p49v5923", .data = (ulong)_5p49v5923_info },
>  >> +   { .compatible =

Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout

2021-06-03 Thread Andreas Rehn

Am Do., 3. Juni 2021 um 16:43 Uhr schrieb Heinrich Schuchardt <
xypron.g...@gmx.de>:

> On 6/3/21 3:56 PM, Andre Przywara wrote:
> > On Fri, 21 May 2021 22:14:00 +0200
> > Andreas Rehn  wrote:
> >
> > Hi,
> >
> >> sorry for the late response.
> >
> > same ;-)
> >
> >> I run some test runs and maybe there is something with the phy itself
> >> or something is missing on sun8i_emac_eth_stop/start?
> >>
> >> if you have any patches/ideas to test - let me know!
> >> maybe someone has an idea how I can try to force the Linux mainline
> driver
> >> in the same situation?
> >> just want to know if there is the same behavior.
> >
> > So... I think there are at least three different problems at play here:
> > 1) EMAC soft reset timeout:
> > as mentioned, I believe the timeout value itself is a red herring,
> > as it is an automatic operation (the bit flips back to 0 once the
> > reset is done). Waiting much longer sounds weird, the MAC should
> > reset immediately, since at this point it doesn't talk to anyone: it
> > just pushes the "reset switch" on its internal state. However there
> > might be more to it, see below.
>

I totally agree. Disabling the soft-reset results not in a timeout at 100
MB/s full-duplex
and the download starts immediately. For me, this looks like a wrong usage
of the softreset too.
Maybe this occurs only if the die supports an internal phy?


> > 2) TFTP timeout and resulting slow transfer speed:
> > This is a totally unrelated and somewhat normal behaviour: TFTP uses
> > UDP, so it's not connection oriented. UDP packets might get lost,
> > for instance due to collisions on the wire. TCP handles those loses
> > transparently and swiftly, that's why you don't notice them there.
> > What makes this so annoying is the long timeout value of 5 seconds,
> > which drastically reduces the overall transfer rate. You can tweak
> > this value by changing TIMEOUT at the beginning of net/tftp.c. If
> > you put 100 there, you will probably barely notice them anymore. The
> > 5 seconds seem to come from the TFTP RFC, so it's hard to argue
> > against it.
>

Agree, I just wanted to give you the exact behaviors/measurements.


> > 3) PHY autonegotiation timeout:
> > This is again independent from the others, especially the MAC soft
> > reset timeout. U-Boot's network stack tries to speak to the PHY via
> > the MDIO bus: PHY_ANEG_TIMEOUT is the macro putting a limit here.
> > There is currently the default 4 seconds fallback value in effect
> > for sunxi here: this might be too short for some situations. Grep
> > for that value to find much longer timeouts for some other
> > platforms. You can try to define this for the V3s in
> > include/configs/sunxi-common.h, and see if that improves things.
> > Happy to take a patch to that effect.


I didn't run into this after i disabled the soft-reset for 100 MB/s
full-duplex!
And yes, I expect a timeout if the cable is not connected but when you
connect the cable
until the timeout is reached, the link will be established.


> >

>
> > Regarding 1): Heinrich reported the same problem on a H3 board, and
> > bisected it down to some other patch. This again does not seem to be
> > related, and I start to wonder if we indeed handle the soft reset
> > wrongly, as mentioned in you v2 patch.
> > I will have a closer look later at when exactly we issue the soft
> > reset, maybe we do it too often? We probably should do it only once,
> > and not on every new network request. Or maybe we need some delay
> > after the soft reset returns, because it's doing so prematurely? But
> > just dropping it does not sound right, although it's interesting that
> > Linux doesn't need it.
>

I was also wondering about the linux driver but i didn't see any wrong
behaviors if i disable it on u-boot too.


>
> Applying
>
> net: sun8i-emac: v3s: fix soft reset timeout
>
> https://patchwork.ozlabs.org/project/uboot/patch/20210522232340.201471-1-rehn.andrea...@gmail.com/
>
> and
>
>  /* Soft reset MAC */
> -   if (!IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) {
> +   if (1 || !IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) {
>
> does not solve the problem I see on the OrangePi PC:
>
> => dhcp
> sun8i_emac_eth_start: Timeout
>
> So it seems we are talking about different issues.


> Applying "net: sun8i-emac: v3s: fix soft reset timeout" on top of
>
> "net: sun8i-emac: fix MDIO frequency"
>
> https://patchwork.ozlabs.org/project/uboot/patch/20210603075242.96527-1-xypron.g...@gmx.de/
>
> does not do any harm nor does it show any benefit for tFTP transfer on
> the OrangePi PC.
>
> Best regards
>
> Heinrich
>
> >
> >>
> >> test-scenario:
> >>  download 10 times zImage and dtb over tftp,
> >>  static ip, no reset, timeout = 1000
> >> 10 duplex half:
> >>  soft reset time 0us with 3 tftp timeouts and recover
> >>  lowest speed:   369.1 KiB/s
> >>  max speed:  779.3 KiB/s
> >> 10 duplex

Re: [PATCH u-boot-marvell 7/7] arm64: a37xx: dts: rename internal-regs node

2021-06-03 Thread Marek Behún

On Wed,  2 Jun 2021 19:10:01 +0200
Marek Behún  wrote:

> The node `internal-regs` is called `internal-regs@d000`
> in Linux' device tree. Rename this in U-Boot also.
> 
> No in-tree code depends on this name, so this should be safe.
> 
> Signed-off-by: Marek Behún 
> ---
>  arch/arm/dts/armada-37xx.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/armada-37xx.dtsi
> b/arch/arm/dts/armada-37xx.dtsi index a1052add0c..ad86bf5c1d 100644
> --- a/arch/arm/dts/armada-37xx.dtsi
> +++ b/arch/arm/dts/armada-37xx.dtsi
> @@ -93,7 +93,7 @@
>   #size-cells = <2>;
>   ranges;
>  
> - internal-regs {
> + internal-regs@d000 {
>   #address-cells = <1>;
>   #size-cells = <1>;
>   compatible = "simple-bus";

On second thought we can ignore this patch for now. We can update the
whole DTS to kernel's DTS once all drivers are updated to support
kernel bindings.

Re: [PATCH u-boot-marvell 2/7] arm: mvebu: turris_mox: add support for board rescue mode

2021-06-03 Thread Marek Behún

On Wed,  2 Jun 2021 19:09:56 +0200
Marek Behún  wrote:

> +#define TURRIS_MOX_BOOTCMD_RESCUE \
> + "setenv bootargs \"console=ttyMV0,115200 " \
> +   "earlycon=ar3700_uart,0xd0012000\" && " \
> + "sf probe && " \
> + "sf read ${kernel_addr_r} 0x19 && " \
> + "lzmadec ${kernel_addr_r} ${ramdisk_addr_r} && " \
> + "bootm ${ramdisk_addr_r}"

OMG, we should use constants for addresses here instead of
${kernel_addr_r} and ${ramdisk_addr_r}, in case user changes or removed
this variables.

I will update this in v2.

> +
>  #define CONFIG_EXTRA_ENV_SETTINGS\
>   "scriptaddr=0x4d0\0"\
>   "pxefile_addr_r=0x4e0\0"\
>   "fdt_addr_r=0x4f0\0"\
>   "kernel_addr_r=0x500\0" \
>   "ramdisk_addr_r=0x800\0"\
> + "bootcmd_rescue=" TURRIS_MOX_BOOTCMD_RESCUE "\0" \
>   BOOTENV
>  
>  #endif /* _CONFIG_TURRIS_MOX_H */

Re: [PATCH 3/4] socfpga64: Do not define CONFIG_SYS_MEM_RESERVE_SECURE to 0

On Thu, Jun 03, 2021 at 05:07:17PM +0200, Rasmus Villemoes wrote:
> On 03/06/2021 15.39, Tom Rini wrote:
> > Based on the comment in socfpga_soc64_common.h, the intention is for
> > CONFIG_SYS_MEM_RESERVE_SECURE to be unused.  However, in the code we do:
> > ...
> > 
> > and that will evaluate to true.  This leads to unwanted code being
> 
> Some cleanup made lines beginning with # disappear? I can _strongly_
> recommend setting commit.cleanup to scissors; I have lost count of the
> number of times I've had a commit message mangled and become practically
> useless because important lines got removed.
> 
> For example
> 
> became
> 

Bah!  Yes, thanks.  It should have said
#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
...
#endif

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] sunxi: clock: H6/H616: Fix PLL clock factor encodings

2021-06-03 Thread Jernej Škrabec

Hi!

Dne četrtek, 27. maj 2021 ob 01:49:48 CEST je Andre Przywara napisal(a):
> On Wed,  5 May 2021 13:53:05 +0100
> Andre Przywara  wrote:
> 
> Hi,
> 
> > Most clock factors and dividers in the H6 PLLs use a "+1 encoding",
> > which we were missing on two occasions.
> 
> can someone please confirm that I didn't mess this up?
> 
> Cheers,
> Andre
> 
> > This fixes the MMC clock setup on the H6, which could be slightly off due
> > to the wrong parent frequency:
> > mmc 2 set mod-clk req 5200 parent 117600 n 2 m 12 rate 4900
> > 
> > Also the CPU frequency was a tad too high before.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> > Changelog v1 .. v2:
> > - Also fix PLL5 factor calculation (video, currently unused)
> > - Also fix PLL1 factor calculation (CPU clock)
> > 
> >  arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 4 ++--
> >  arch/arm/mach-sunxi/clock_sun50i_h6.c | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h index
> > 62abfc4ef6b..2e076cf594d 100644
> > --- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > +++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
> > @@ -233,14 +233,14 @@ struct sunxi_ccm_reg {
> > 
> >  #define CCM_PLL1_OUT_ENBIT(27)
> >  #define CCM_PLL1_CLOCK_TIME_2  (2 << 24)
> >  #define CCM_PLL1_CTRL_P(p) ((p) << 16)
> > 
> > -#define CCM_PLL1_CTRL_N(n) ((n) << 8)
> > +#define CCM_PLL1_CTRL_N(n) (((n) - 1) << 8)
> > 
> >  /* pll5 bit field */
> >  #define CCM_PLL5_CTRL_EN   BIT(31)
> >  #define CCM_PLL5_LOCK_EN   BIT(29)
> >  #define CCM_PLL5_LOCK  BIT(28)
> >  #define CCM_PLL5_OUT_ENBIT(27)
> > 
> > -#define CCM_PLL5_CTRL_N(n) ((n) << 8)
> > +#define CCM_PLL5_CTRL_N(n) (((n) - 1) << 8)

H6 and H616 DRAM drivers actually consider this "- 1" in the code. Either drop 
this change or fix DRAM drivers.

With that:
Reviewed-by: Jernej Skrabec 

Best regards,
Jernej

> > 
> >  #define CCM_PLL5_CTRL_DIV1(div1)   ((div1) << 0)
> >  #define CCM_PLL5_CTRL_DIV2(div0)   ((div0) << 1)
> > 
> > diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > b/arch/arm/mach-sunxi/clock_sun50i_h6.c index 492fc4a3fca..a947463e0a5
> > 100644
> > --- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > +++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
> > @@ -94,7 +94,7 @@ unsigned int clock_get_pll6(void)
> > 
> > int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) ? 4 : 2;
> > 
> > uint32_t rval = readl(>pll6_cfg);
> > 
> > -   int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT);
> > +   int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 
1;
> > 
> > int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
> > 
> > CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
> > 
> > int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>

Re: [PATCH 3/4] socfpga64: Do not define CONFIG_SYS_MEM_RESERVE_SECURE to 0

2021-06-03 Thread Rasmus Villemoes

On 03/06/2021 15.39, Tom Rini wrote:
> Based on the comment in socfpga_soc64_common.h, the intention is for
> CONFIG_SYS_MEM_RESERVE_SECURE to be unused.  However, in the code we do:
> ...
> 
> and that will evaluate to true.  This leads to unwanted code being

Some cleanup made lines beginning with # disappear? I can _strongly_
recommend setting commit.cleanup to scissors; I have lost count of the
number of times I've had a commit message mangled and become practically
useless because important lines got removed.

For example

became

Rasmus

Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver





On 6/3/21 4:34 AM, Luca Ceresoli wrote:
> On 24/05/21 19:53, Adam Ford wrote:
>> The driver is based on the Versaclock driver from the Linux code, but
>> do differences in the clock API between them, some pieces had to change.
>
> s/do/due to/ ?
> s/had to change/had to be changed/
>
>> This driver creates a mux, pfd, pll, and a series of fod ouputs.
>>   Rate   Usecnt  Name
>> --
>>   2500 0`-- x304-clock
>>   2500 0`-- clock-control...@6a.mux
>>   2500 0|-- clock-control...@6a.pfd
>>   28   0|   `-- clock-control...@6a.pll
>>    0|   |-- clock-controller@6a.fod0
>>    0|   |   `-- 
clock-controller@6a.out1
>>    0|   |-- clock-controller@6a.fod1
>>    0|   |   `-- 
clock-controller@6a.out2
>>   5000 0|   |-- clock-controller@6a.fod2
>>   5000 0|   |   `-- 
clock-controller@6a.out3
>>   125000|   `-- clock-controller@6a.fod3
>>   125000|   `-- 
clock-controller@6a.out4
>>   2500 0`-- clock-controller@6a.out0_sel_i2cb
>>
>> A translation function is added so the references to < X> get 
routed
>> to the corresponding clock-control...@6a.outx.
>>
>> Signed-off-by: Adam Ford 
>
> I've been reviewing this patch and it looks mostly OK to me except for a
> few notes below, mostly minor ones. However my knowledge of the U-Boot
> driver model is minimal, thus I couldn't go in depth in the most
> interesting and critical part of Adam's work, i.e. the adaptations for
> the U-Boot codebase. I'm afraid I cannot do more.
>
>> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
>> index 645709b855..2a9ebec860 100644
>> --- a/drivers/clk/Makefile
>> +++ b/drivers/clk/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
>>   obj-$(CONFIG_STM32H7) += clk_stm32h7.o
>>   obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
>>   obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
>> +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o
>
> Nit: space after '+='.
>
>> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
>> new file mode 100644
>> index 00..30e49fad31
>> --- /dev/null
>> +++ b/drivers/clk/clk_versaclock.c
>> @@ -0,0 +1,1025 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Driver for IDT Versaclock 5/6
>> + *
>> + * Derived from code Copyright (C) 2017 Marek Vasut 
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>
> Missing file?
>
>> +
>> +/* VersaClock5 registers */
>> +#define VC5_OTP_CONTROL   0x00
>> +
>> +/* Factory-reserved register block */
>> +#define VC5_RSVD_DEVICE_ID0x01
>> +#define VC5_RSVD_ADC_GAIN_7_0 0x02
>> +#define VC5_RSVD_ADC_GAIN_15_80x03
>> +#define VC5_RSVD_ADC_OFFSET_7_0   0x04
>> +#define VC5_RSVD_ADC_OFFSET_15_8  0x05
>> +#define VC5_RSVD_TEMPY0x06
>> +#define VC5_RSVD_OFFSET_TBIN  0x07
>> +#define VC5_RSVD_GAIN 0x08
>> +#define VC5_RSVD_TEST_NP  0x09
>> +#define VC5_RSVD_UNUSED   0x0a
>> +#define VC5_RSVD_BANDGAP_TRIM_UP  0x0b
>> +#define VC5_RSVD_BANDGAP_TRIM_DN  0x0c
>> +#define VC5_RSVD_CLK_R_12_CLK_AMP_4   0x0d
>> +#define VC5_RSVD_CLK_R_34_CLK_AMP_4   0x0e
>> +#define VC5_RSVD_CLK_AMP_123  0x0f
>
> I wonder whether it really makes sense to define so many registers that
> are not used in the driver. But it's done the same way in the Linux
> driver, and it doesn't hurt much, so I'll be fine with or without them.

I would leave them in so the next person who works on this driver doesn't have 
to add them.\

--Sean

>
> [...]
>
>> +static const struct udevice_id versaclock_ids[] = {
>> +  { .compatible = "idt,5p49v5923", .data = (ulong)_5p49v5923_info },
>> +  { .compatible = "idt,5p49v5925", .data = (ulong)_5p49v5925_info },
>> +  { .compatible = "idt,5p49v5933", .data = (ulong)_5p49v5933_info },
>> +  { .compatible = "idt,5p49v5935", .data = (ulong)_5p49v5935_info },
>> +  { .compatible = "idt,5p49v6901", .data = (ulong)_5p49v6901_info },
>> +  { .compatible = "idt,5p49v6965", .data = (ulong)_5p49v6965_info },
>> +  {},
>> +};
>
> Why not putting this array below, right before the U_BOOT_DRIVER() call
> where it is used, similarly to the Linux driver?
>

Re: [PATCHv4,1/1] clk: zynq: Add clock wizard driver





On 6/2/21 9:56 AM, Zhengxun Li wrote:

Hi Sean,

Thanks for your reply.


This clock driver adds support for clock related settings for
Zynq platform.

+config COMMON_CLK_XLNX_CLKWZRD


Why not just CLK_XILNIX_WIZARD? Do we need "COMMON" in here?


Follow the linux patch "clk: clocking-wizard: Add the clockwizard to
clk directory".


Yes, but while they are using CCF, this driver is not.

--Sean



https://patchwork.kernel.org/project/linux-clk/patch/1617886723-27117-3-git-send-email-shubhrajyoti.da...@xilinx.com/


+bool "Xilinx Clocking Wizard"
+depends on CLK
+help
+  Support for the Xilinx Clocking Wizard IP core clock generator.
+  Adds support for clocking wizard and compatible.
+  This driver supports the Xilinx clocking wizard programmable clock
+  synthesizer.


This can all be one sentence. Please also add some basic information
about the clock wizard. What sorts of systems might one find this device
on? It looks like configuration is determined from registers within the
clock itself. Perhaps add a note about that.


Okay.


+
   config CLK_ZYNQMP
  bool "Enable clock driver support for ZynqMP"
  depends on ARCH_ZYNQMP
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 645709b855..f4ddbe831a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
   obj-$(CONFIG_CLK_VEXPRESS_OSC) += clk_vexpress_osc.o
   obj-$(CONFIG_CLK_ZYNQ) += clk_zynq.o
   obj-$(CONFIG_CLK_ZYNQMP) += clk_zynqmp.o
+obj-$(CONFIG_COMMON_CLK_XLNX_CLKWZRD) += clk-xlnx-clock-wizard.o
   obj-$(CONFIG_ICS8N3QV01) += ics8n3qv01.o
   obj-$(CONFIG_MACH_PIC32) += clk_pic32.o
   obj-$(CONFIG_SANDBOX) += clk_sandbox.o
diff --git a/drivers/clk/clk-xlnx-clock-wizard.c 
b/drivers/clk/clk-xlnx-clock-wizard.c
new file mode 100644
index 00..76c0eb27e6
--- /dev/null
+++ b/drivers/clk/clk-xlnx-clock-wizard.c
@@ -0,0 +1,177 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx 'Clocking Wizard' driver
+ *
+ * Copyright (c) 2021 Macronix Inc.
+ *
+ * Author: Zhengxun Li 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SRR 0x0
+
+#define SR  0x4
+#define SR_LOCKED   BIT(0)
+
+#define CCR(x)  (0x200 + ((x) * 4))
+
+#define FBOUT_CFG   CCR(0)
+#define FBOUT_DIV(x)(x)
+#define FBOUT_GET_DIV(x)((x) & GENMASK(7, 0))
+#define FBOUT_MUL(x)((x) << 8)
+#define FBOUT_GET_MUL(x)(((x) & GENMASK(15, 8)) >> 8)
+#define FBOUT_FRAC(x)   ((x) << 16)
+#define FBOUT_GET_FRAC(x)   (((x) & GENMASK(25, 16)) >> 16)
+#define FBOUT_FRAC_EN   BIT(26)
+
+#define FBOUT_PHASE CCR(1)
+
+#define OUT_CFG(x)  CCR(2 + ((x) * 3))
+#define OUT_DIV(x)  (x)
+#define OUT_GET_DIV(x)  ((x) & GENMASK(7, 0))


Please use FIELD_PREP and FIELD_GET. And please define the mask
separately.


Okay.


+#define OUT_FRAC(x) ((x) << 8)
+#define OUT_GET_FRAC(x) (((x) & GENMASK(17, 8)) >> 8)


ditto


+#define OUT_FRAC_EN BIT(18)
+
+#define OUT_PHASE(x)CCR(3 + ((x) * 3))
+#define OUT_DUTY(x) CCR(4 + ((x) * 3))
+
+#define CTRLCCR(23)
+#define CTRL_SENBIT(2)
+#define CTRL_SADDR  BIT(1)
+#define CTRL_LOAD   BIT(0)
+
+/**
+ * struct clkwzrd - Clock wizard private data structure
+ *
+ * @base:   memory base
+ * @vco_clk:voltage-controlled oscillator frequency
+ */
+struct clkwzd {
+void *base;
+u64 vco_clk;
+};
+
+struct clkwzd_plat {
+fdt_addr_t addr;
+};
+
+static int clk_wzrd_enable(struct clk *clk)
+{
+struct clkwzd *priv = dev_get_priv(clk->dev);
+int ret;
+u32 val;
+
+ret = readl_poll_sleep_timeout(priv->base + SR, val, val & SR_LOCKED,
+   1, 100);
+if (!ret) {
+writel(CTRL_SEN | CTRL_SADDR | CTRL_LOAD, priv->base + CTRL);
+writel(CTRL_SADDR, priv->base + CTRL);
+ret = readl_poll_sleep_timeout(priv->base + SR, val,
+   val & SR_LOCKED, 1, 100);
+}
+
+return ret;
+}
+
+static unsigned long clk_wzrd_set_rate(struct clk *clk, ulong rate)
+{
+struct clkwzd *priv = dev_get_priv(clk->dev);
+u64 div;
+u32 cfg;
+
+/* Get output clock divide value */
+div = DIV_ROUND_DOWN_ULL(priv->vco_clk * 1000, rate);
+if (div < 1000 || div > 255999)
+return -EINVAL;
+
+cfg = OUT_DIV((u32)div / 1000);
+
+writel(cfg, priv->base + OUT_CFG(clk->id));
+
+return 0;
+}
+
+static struct clk_ops clk_wzrd_ops = {
+.enable = clk_wzrd_enable,
+.set_rate = clk_wzrd_set_rate,
+};
+
+static int clk_wzrd_probe(struct udevice *dev)
+{
+struct clkwzd_plat *plat = dev_get_plat(dev);
+struct clkwzd *priv = dev_get_priv(dev);
+struct clk clk;
+u64 clock, vco_clk;
+

Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout

On 6/3/21 3:56 PM, Andre Przywara wrote:

On Fri, 21 May 2021 22:14:00 +0200
Andreas Rehn wrote:

Hi,

sorry for the late response.

same ;-)

I run some test runs and maybe there is something with the phy itself
or something is missing on sun8i_emac_eth_stop/start?

if you have any patches/ideas to test - let me know!
maybe someone has an idea how I can try to force the Linux mainline driver
in the same situation?
just want to know if there is the same behavior.

So... I think there are at least three different problems at play here:
1) EMAC soft reset timeout:
as mentioned, I believe the timeout value itself is a red herring,
as it is an automatic operation (the bit flips back to 0 once the
reset is done). Waiting much longer sounds weird, the MAC should
reset immediately, since at this point it doesn't talk to anyone: it
just pushes the "reset switch" on its internal state. However there
might be more to it, see below.
2) TFTP timeout and resulting slow transfer speed:
This is a totally unrelated and somewhat normal behaviour: TFTP uses
UDP, so it's not connection oriented. UDP packets might get lost,
for instance due to collisions on the wire. TCP handles those loses
transparently and swiftly, that's why you don't notice them there.
What makes this so annoying is the long timeout value of 5 seconds,
which drastically reduces the overall transfer rate. You can tweak
this value by changing TIMEOUT at the beginning of net/tftp.c. If
you put 100 there, you will probably barely notice them anymore. The
5 seconds seem to come from the TFTP RFC, so it's hard to argue
against it.
3) PHY autonegotiation timeout:
This is again independent from the others, especially the MAC soft
reset timeout. U-Boot's network stack tries to speak to the PHY via
the MDIO bus: PHY_ANEG_TIMEOUT is the macro putting a limit here.
There is currently the default 4 seconds fallback value in effect
for sunxi here: this might be too short for some situations. Grep
for that value to find much longer timeouts for some other
platforms. You can try to define this for the V3s in
include/configs/sunxi-common.h, and see if that improves things.
Happy to take a patch to that effect.

Regarding 1): Heinrich reported the same problem on a H3 board, and
bisected it down to some other patch. This again does not seem to be
related, and I start to wonder if we indeed handle the soft reset
wrongly, as mentioned in you v2 patch.
I will have a closer look later at when exactly we issue the soft
reset, maybe we do it too often? We probably should do it only once,
and not on every new network request. Or maybe we need some delay
after the soft reset returns, because it's doing so prematurely? But
just dropping it does not sound right, although it's interesting that
Linux doesn't need it.

Applying

net: sun8i-emac: v3s: fix soft reset timeout
https://patchwork.ozlabs.org/project/uboot/patch/20210522232340.201471-1-rehn.andrea...@gmail.com/

and

/* Soft reset MAC */
- if (!IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) {
+ if (1 || !IS_ENABLED(CONFIG_MACH_SUN8I_V3S)) {

does not solve the problem I see on the OrangePi PC:

=> dhcp
sun8i_emac_eth_start: Timeout

So it seems we are talking about different issues.

Applying "net: sun8i-emac: v3s: fix soft reset timeout" on top of

"net: sun8i-emac: fix MDIO frequency"
https://patchwork.ozlabs.org/project/uboot/patch/20210603075242.96527-1-xypron.g...@gmx.de/

does not do any harm nor does it show any benefit for tFTP transfer on
the OrangePi PC.

Best regards

Heinrich

test-scenario:
download 10 times zImage and dtb over tftp,
static ip, no reset, timeout = 1000
10 duplex half:
soft reset time 0us with 3 tftp timeouts and recover
lowest speed: 369.1 KiB/s
max speed: 779.3 KiB/s
10 duplex full:
soft reset time 0us with 0 tftp timeouts and recover
lowest speed: 656.3 KiB/s
max speed: 752.9 KiB/s
100 duplex half:
soft reset time 0us with 1 tftp timeout and recover
lowest speed: 1.6 MiB/s
max speed: 2.7 MiB/s

100 duplex full:

what are those values before and after the comma below?

Cheers,
Andre

try1: 0us, 63 us with 0 tftp timeout and recover
try2: 1001000 us sun8i_emac_eth_start: Timeout
-> 5 times
-> reconnect cable
try3: 382000us, 502000us with 0 tftp timeout and recover
try4: 33 us, 1001000 us sun8i_emac_eth_start: Timeout
-> 2 times
-> 192000 us
try5: power up with cable pluged in:
58000 us, 373000 us with 0 tftp timeout and recover
try6: 354000 us, 494000 us with 0 tftp timeout and recover
try7: 1001000 us sun8i_emac_eth_start: Timeout
-> 3 times
->

Re: [PATCH 6/6] net: sun8i-emac: v3s: fix soft reset timeout

On Fri, 21 May 2021 22:14:00 +0200
Andreas Rehn  wrote:

Hi,

> sorry for the late response.

same ;-)

> I run some test runs and maybe there is something with the phy itself
> or something is missing on sun8i_emac_eth_stop/start?
> 
> if you have any patches/ideas to test - let me know!
> maybe someone has an idea how I can try to force the Linux mainline driver
> in the same situation?
> just want to know if there is the same behavior.

So... I think there are at least three different problems at play here:
1) EMAC soft reset timeout:
   as mentioned, I believe the timeout value itself is a red herring,
   as it is an automatic operation (the bit flips back to 0 once the
   reset is done). Waiting much longer sounds weird, the MAC should
   reset immediately, since at this point it doesn't talk to anyone: it
   just pushes the "reset switch" on its internal state. However there
   might be more to it, see below.
2) TFTP timeout and resulting slow transfer speed:
   This is a totally unrelated and somewhat normal behaviour: TFTP uses
   UDP, so it's not connection oriented. UDP packets might get lost,
   for instance due to collisions on the wire. TCP handles those loses
   transparently and swiftly, that's why you don't notice them there.
   What makes this so annoying is the long timeout value of 5 seconds,
   which drastically reduces the overall transfer rate. You can tweak
   this value by changing TIMEOUT at the beginning of net/tftp.c. If
   you put 100 there, you will probably barely notice them anymore. The
   5 seconds seem to come from the TFTP RFC, so it's hard to argue
   against it.
3) PHY autonegotiation timeout:
   This is again independent from the others, especially the MAC soft
   reset timeout. U-Boot's network stack tries to speak to the PHY via
   the MDIO bus: PHY_ANEG_TIMEOUT is the macro putting a limit here.
   There is currently the default 4 seconds fallback value in effect
   for sunxi here: this might be too short for some situations. Grep
   for that value to find much longer timeouts for some other
   platforms. You can try to define this for the V3s in
   include/configs/sunxi-common.h, and see if that improves things.
   Happy to take a patch to that effect.

Regarding 1): Heinrich reported the same problem on a H3 board, and
bisected it down to some other patch. This again does not seem to be
related, and I start to wonder if we indeed handle the soft reset
wrongly, as mentioned in you v2 patch.
I will have a closer look later at when exactly we issue the soft
reset, maybe we do it too often? We probably should do it only once,
and not on every new network request. Or maybe we need some delay
after the soft reset returns, because it's doing so prematurely? But
just dropping it does not sound right, although it's interesting that
Linux doesn't need it.

> 
> test-scenario:
> download 10 times zImage and dtb over tftp,
> static ip, no reset, timeout = 1000
> 10 duplex half:
> soft reset time 0us with 3 tftp timeouts and recover
> lowest speed:   369.1 KiB/s
> max speed:  779.3 KiB/s
> 10 duplex full:
> soft reset time 0us with 0 tftp timeouts and recover
> lowest speed:   656.3 KiB/s
> max speed:  752.9 KiB/s
> 100 duplex half:
> soft reset time 0us with 1 tftp timeout and recover
> lowest speed:   1.6 MiB/s
> max speed:  2.7 MiB/s
> 
> 100 duplex full:

what are those values before and after the comma below?

Cheers,
Andre

> try1:   0us, 63 us with 0 tftp timeout and recover
> try2:   1001000 us sun8i_emac_eth_start: Timeout
> -> 5 times
> -> reconnect cable  
> try3:   382000us, 502000us with 0 tftp timeout and recover
> try4:   33 us, 1001000 us sun8i_emac_eth_start: Timeout
> -> 2 times
> -> 192000 us  
> try5:   power up with cable pluged in:
> 58000 us, 373000 us with 0 tftp timeout and recover
> try6:   354000 us, 494000 us with 0 tftp timeout and recover
> try7:   1001000 us sun8i_emac_eth_start: Timeout
> -> 3 times
> -> 1001000 us sun8i_emac_eth_start: Timeout, 626000 us  
> next tries with fresh startup
> try8:   845000 us, 594000 us
> try9:   903000 us, 479000 us
> try10:  638000 us, 50 us
> try11:  1001000 us sun8i_emac_eth_start: Timeout, 333000 us
> try12:  63000 us, 489000 us
> lowest speed:   1.6 MiB/s
> max speed:  2.7 MiB/s
> 
> when switching from 100 duplex half to full and try to run tftp download
> for zImage and dtb
>  try1:
> reset MAC done after: 0 us
> ethernet@1c3 Waiting for PHY auto negotiation to complete.
> TIMEOUT !
> reset MAC done after: 0 us
> ethernet@1c3 Waiting for PHY auto negotiation to complete.
> TIMEOUT !
>  try2:
>

[PATCH 4/4] global_data: Ensure we have when symbols are not in Kconfig yet

All symbols that are defined in Kconfig will always be defined (or not)
prior to preprocessing due to the -include directive while building.
However, symbols which are not yet migrated will only be defined (or
not) once the board config.h is included, via .  While the end
goal must be to migrate all symbols, today we have cases where the size
of gd will get mismatched within the build, based on include order.
Mitigate this by making sure that any  that uses
symbols not in Kconfig does start with .  Remove this when not
needed.

Cc: Alexey Brodkin 
Cc: Eugeniy Paltsev 
Cc: Huan Wang 
Cc: Angelo Dureghello 
Cc: Rick Chen 
Signed-off-by: Tom Rini 
---
 arch/arc/include/asm/global_data.h   | 2 --
 arch/arm/include/asm/global_data.h   | 2 ++
 arch/m68k/include/asm/global_data.h  | 2 ++
 arch/nds32/include/asm/global_data.h | 2 ++
 4 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arc/include/asm/global_data.h 
b/arch/arc/include/asm/global_data.h
index 8f9c83d3c28d..e35a26f1eb14 100644
--- a/arch/arc/include/asm/global_data.h
+++ b/arch/arc/include/asm/global_data.h
@@ -6,8 +6,6 @@
 #ifndef__ASM_ARC_GLOBAL_DATA_H
 #define __ASM_ARC_GLOBAL_DATA_H
 
-#include 
-
 #ifndef __ASSEMBLY__
 /* Architecture-specific global data */
 struct arch_global_data {
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 2aff1c467c14..79432f3bbd24 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -9,6 +9,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
+
 #include 
 #include 
 
diff --git a/arch/m68k/include/asm/global_data.h 
b/arch/m68k/include/asm/global_data.h
index 188055e9d314..273e843c4ae6 100644
--- a/arch/m68k/include/asm/global_data.h
+++ b/arch/m68k/include/asm/global_data.h
@@ -7,6 +7,8 @@
 #ifndef__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
+#include 
+
 /* Architecture-specific global data */
 struct arch_global_data {
 #ifdef CONFIG_SYS_I2C_FSL
diff --git a/arch/nds32/include/asm/global_data.h 
b/arch/nds32/include/asm/global_data.h
index be04a18857a1..297481beaaef 100644
--- a/arch/nds32/include/asm/global_data.h
+++ b/arch/nds32/include/asm/global_data.h
@@ -17,6 +17,8 @@
 #ifndef__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
+#include 
+
 /* Architecture-specific global data */
 struct arch_global_data {
 };
-- 
2.17.1

[PATCH 3/4] socfpga64: Do not define CONFIG_SYS_MEM_RESERVE_SECURE to 0

Based on the comment in socfpga_soc64_common.h, the intention is for
CONFIG_SYS_MEM_RESERVE_SECURE to be unused.  However, in the code we do:
...

and that will evaluate to true.  This leads to unwanted code being
compiled.  Further, as CONFIG_SYS_MEM_RESERVE_SECURE has not been
migrated to Kconfig, this leads to a mismatch in the size of gd
depending on if we have or have not also had  also
included yet.

Remove the define as it's not needed.

Cc: Siew Chin Lim 
Cc: Chee Hong Ang 
Cc: Dalon Westergreen 
Signed-off-by: Tom Rini 
---
 include/configs/socfpga_soc64_common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 5afdb104543e..38fd775b5b6e 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -21,7 +21,6 @@
 /* sysmgr.boot_scratch_cold4 & 5 (64bit) will be used for PSCI_CPU_ON call */
 #define CPU_RELEASE_ADDR   0xFFD12210
 #define CONFIG_SYS_CACHELINE_SIZE  64
-#define CONFIG_SYS_MEM_RESERVE_SECURE  0   /* using OCRAM, not DDR */
 
 /*
  * U-Boot console configurations
-- 
2.17.1

[PATCH 2/4] Revert "powerpc: fix regression in arch_initr_trap()"

With the changes in commit 588efcdd72fc ("powerpc: Don't use relative
include for config.h in global_data.h") fixing the root of the problem,
we no longer need this re-inclusion.

This reverts commit f6c0d365d3e8ee8e4fd3ebe2ed957c2bca9d3328.

Cc: Matt Merhar 
Signed-off-by: Tom Rini 
---
I will need to reword this to have the right commit ID when merging.
---
 arch/powerpc/lib/traps.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/lib/traps.c b/arch/powerpc/lib/traps.c
index ab8ca269a50c..c7bce82a44b3 100644
--- a/arch/powerpc/lib/traps.c
+++ b/arch/powerpc/lib/traps.c
@@ -4,7 +4,6 @@
  * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
  */
 
-#include 
 #include 
 #include 
 
-- 
2.17.1

[PATCH 1/4] powerpc: Don't use relative include for config.h in global_data.h

As there is an arch/powerpc/include/asm/config.h file using "" to get
config.h here can lead to using that rather than include/config.h.  This
in turn can lead to a mismatch in the size of gd.

Cc: Matt Merhar 
Signed-off-by: Tom Rini 
---
 arch/powerpc/include/asm/global_data.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/global_data.h 
b/arch/powerpc/include/asm/global_data.h
index 192a02d347e7..90bf5a2aea5d 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ -8,7 +8,7 @@
 #ifndef__ASM_GBL_DATA_H
 #define __ASM_GBL_DATA_H
 
-#include "config.h"
+#include 
 #include "asm/types.h"
 
 /* Architecture-specific global data */
-- 
2.17.1

[PATCH V2] ARM: rmobile: beacon-renesom: Enable QSPI NOR Flash

There is a QSPI NOR flash part on the board.  Because this chip isn't
yet supported in Linux, but it is supported in U-Boot, and the
face that the RPC_SPI compatible names are different in U-Boot and
Linux, the device tree updates are confined to -u-boot.dtsi files.

In order to use the QSPI, TF-A must leave RPC unlocked by compiling
TF-A with RZG_RPC_HYPERFLASH_LOCKED=0.

Signed-off-by: Adam Ford 
Reviewed-by: Biju Bas 
---
V2:  Add note to commit message about TF-A
 No functional changes

diff --git a/arch/arm/dts/r8a774a1-beacon-rzg2m-kit-u-boot.dtsi 
b/arch/arm/dts/r8a774a1-beacon-rzg2m-kit-u-boot.dtsi
index a0c0a7f35c..06271537b7 100644
--- a/arch/arm/dts/r8a774a1-beacon-rzg2m-kit-u-boot.dtsi
+++ b/arch/arm/dts/r8a774a1-beacon-rzg2m-kit-u-boot.dtsi
@@ -4,11 +4,19 @@
  */
 
 / {
+   aliases {
+   spi0 = 
+   };
+
soc {
u-boot,dm-pre-reloc;
};
 };
 
+ {
+   phy-mode = "rgmii-txid";
+};
+
  {
u-boot,dm-pre-reloc;
 };
@@ -25,6 +33,25 @@
u-boot,dm-pre-reloc;
 };
 
+ {
+   compatible = "renesas,rcar-gen3-rpc";
+   num-cs = <1>;
+   spi-max-frequency = <4000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   flash0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <4000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
+   };
+};
+
  {
/delete-property/ cd-gpios;
 };
diff --git a/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi 
b/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi
index a0c0a7f35c..be0ce54e55 100644
--- a/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi
+++ b/arch/arm/dts/r8a774b1-beacon-rzg2n-kit-u-boot.dtsi
@@ -4,6 +4,10 @@
  */
 
 / {
+   aliases {
+   spi0 = 
+   };
+
soc {
u-boot,dm-pre-reloc;
};
@@ -25,6 +29,25 @@
u-boot,dm-pre-reloc;
 };
 
+ {
+   compatible = "renesas,rcar-gen3-rpc";
+   num-cs = <1>;
+   spi-max-frequency = <4000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   flash0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <4000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
+   };
+};
+
  {
/delete-property/ cd-gpios;
 };
diff --git a/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi 
b/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi
index eef200af2d..228391e0df 100644
--- a/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi
+++ b/arch/arm/dts/r8a774e1-beacon-rzg2h-kit-u-boot.dtsi
@@ -4,6 +4,10 @@
  */
 
 / {
+   aliases {
+   spi0 = 
+   };
+
soc {
u-boot,dm-pre-reloc;
};
@@ -25,6 +29,25 @@
u-boot,dm-pre-reloc;
 };
 
+ {
+   compatible = "renesas,rcar-gen3-rpc";
+   num-cs = <1>;
+   spi-max-frequency = <4000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   flash0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0>;
+   compatible = "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <4000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
+   };
+};
+
  {
/delete-property/ cd-gpios;
sd-uhs-sdr12;
diff --git a/configs/r8a774a1_beacon_defconfig 
b/configs/r8a774a1_beacon_defconfig
index 4a87a9a31f..c115f548a3 100644
--- a/configs/r8a774a1_beacon_defconfig
+++ b/configs/r8a774a1_beacon_defconfig
@@ -18,7 +18,9 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
 CONFIG_CMD_PART=y
+CONFIG_CMD_SPI=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
@@ -47,6 +49,10 @@ CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
 CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MTD=y
+CONFIG_DM_MTD=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_BITBANGMII=y
 CONFIG_PHY_REALTEK=y
 CONFIG_DM_ETH=y
@@ -56,6 +62,9 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_SCIF_CONSOLE=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_RENESAS_RPC_SPI=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
diff --git a/configs/r8a774b1_beacon_defconfig 
b/configs/r8a774b1_beacon_defconfig
index 2c31222525..fe7bac048a 100644
--- a/configs/r8a774b1_beacon_defconfig
+++ b/configs/r8a774b1_beacon_defconfig
@@ -18,7 +18,9 @@ CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_MTD=y
 CONFIG_CMD_PART=y
+CONFIG_CMD_SPI=y

[PATCH] arm: dts: k3-j7200: ddr: Update to 0.5.0 version of DDR for LPDDR 2666MTs

2021-06-03 Thread praneeth

From: Kevin Scholz 

Update the ddr settings to use the DDR reg config tool rev 0.5.0.
This enables 2666MTs LPDDR configuration on J7200.

Signed-off-by: Kevin Scholz 
Signed-off-by: Praneeth Bajjuri 
Tested-by: Suman Anna 
---
 ...00.dtsi => k3-j7200-ddr-evm-lp4-2666.dtsi} | 437 +-
 .../arm/dts/k3-j7200-r5-common-proc-board.dts |   2 +-
 2 files changed, 220 insertions(+), 219 deletions(-)
 rename arch/arm/dts/{k3-j7200-ddr-evm-lp4-1600.dtsi => 
k3-j7200-ddr-evm-lp4-2666.dtsi} (90%)

diff --git a/arch/arm/dts/k3-j7200-ddr-evm-lp4-1600.dtsi 
b/arch/arm/dts/k3-j7200-ddr-evm-lp4-2666.dtsi
similarity index 90%
rename from arch/arm/dts/k3-j7200-ddr-evm-lp4-1600.dtsi
rename to arch/arm/dts/k3-j7200-ddr-evm-lp4-2666.dtsi
index 12ffd913d1..42ac8c5c89 100644
--- a/arch/arm/dts/k3-j7200-ddr-evm-lp4-1600.dtsi
+++ b/arch/arm/dts/k3-j7200-ddr-evm-lp4-2666.dtsi
@@ -1,13 +1,14 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * This file was generated by the AM752x_DRA82x_TDA4x_DDRSS_RegConfigTool, 
Revision: 0.3.0
- * This file was generated on 06/08/2020
- * Includes hand edits
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * This file was generated by the Jacinto7_DDRSS_RegConfigTool, Revision: 0.5.0
+ * This file was generated on 08/07/2020
+ * Includes hand-edits
  */
 
 #define DDRSS_PLL_FHS_CNT 10
-#define DDRSS_PLL_FREQUENCY_1 4
-#define DDRSS_PLL_FREQUENCY_2 4
+#define DDRSS_PLL_FREQUENCY_1 66650
+#define DDRSS_PLL_FREQUENCY_2 66650
 
 #define DDRSS_CTL_00_DATA 0x0B00
 #define DDRSS_CTL_01_DATA 0x
@@ -20,14 +21,14 @@
 #define DDRSS_CTL_08_DATA 0x000186A0
 #define DDRSS_CTL_09_DATA 0x0005
 #define DDRSS_CTL_10_DATA 0x0064
-#define DDRSS_CTL_11_DATA 0x00027100
-#define DDRSS_CTL_12_DATA 0x00186A00
+#define DDRSS_CTL_11_DATA 0x000411AB
+#define DDRSS_CTL_12_DATA 0x0028B0AB
 #define DDRSS_CTL_13_DATA 0x0005
-#define DDRSS_CTL_14_DATA 0x0640
-#define DDRSS_CTL_15_DATA 0x00027100
-#define DDRSS_CTL_16_DATA 0x00186A00
+#define DDRSS_CTL_14_DATA 0x0A6B
+#define DDRSS_CTL_15_DATA 0x000411AB
+#define DDRSS_CTL_16_DATA 0x0028B0AB
 #define DDRSS_CTL_17_DATA 0x0005
-#define DDRSS_CTL_18_DATA 0x0640
+#define DDRSS_CTL_18_DATA 0x0A6B
 #define DDRSS_CTL_19_DATA 0x0101
 #define DDRSS_CTL_20_DATA 0x02011001
 #define DDRSS_CTL_21_DATA 0x0201
@@ -37,66 +38,66 @@
 #define DDRSS_CTL_25_DATA 0x
 #define DDRSS_CTL_26_DATA 0x
 #define DDRSS_CTL_27_DATA 0x02020200
-#define DDRSS_CTL_28_DATA 0x2020
+#define DDRSS_CTL_28_DATA 0x3636
 #define DDRSS_CTL_29_DATA 0x0010
 #define DDRSS_CTL_30_DATA 0x
 #define DDRSS_CTL_31_DATA 0x
 #define DDRSS_CTL_32_DATA 0x
 #define DDRSS_CTL_33_DATA 0x
 #define DDRSS_CTL_34_DATA 0x040C
-#define DDRSS_CTL_35_DATA 0x081C081C
+#define DDRSS_CTL_35_DATA 0x0C300C30
 #define DDRSS_CTL_36_DATA 0x00050804
 #define DDRSS_CTL_37_DATA 0x09040008
-#define DDRSS_CTL_38_DATA 0x08000204
-#define DDRSS_CTL_39_DATA 0x0B240034
-#define DDRSS_CTL_40_DATA 0x08001910
-#define DDRSS_CTL_41_DATA 0x0B240034
-#define DDRSS_CTL_42_DATA 0x20001910
+#define DDRSS_CTL_38_DATA 0x0D000204
+#define DDRSS_CTL_39_DATA 0x113C0057
+#define DDRSS_CTL_40_DATA 0x0D00291B
+#define DDRSS_CTL_41_DATA 0x113C0057
+#define DDRSS_CTL_42_DATA 0x2000291B
 #define DDRSS_CTL_43_DATA 0x000A0A09
 #define DDRSS_CTL_44_DATA 0x040006DB
-#define DDRSS_CTL_45_DATA 0x0C0A0904
-#define DDRSS_CTL_46_DATA 0x06006DB0
-#define DDRSS_CTL_47_DATA 0x0C0A0906
-#define DDRSS_CTL_48_DATA 0x06006DB0
-#define DDRSS_CTL_49_DATA 0x02030406
-#define DDRSS_CTL_50_DATA 0x11040500
-#define DDRSS_CTL_51_DATA 0x08121112
+#define DDRSS_CTL_45_DATA 0x130E0B04
+#define DDRSS_CTL_46_DATA 0x0A00B6D0
+#define DDRSS_CTL_47_DATA 0x130E0B0A
+#define DDRSS_CTL_48_DATA 0x0A00B6D0
+#define DDRSS_CTL_49_DATA 0x0203040A
+#define DDRSS_CTL_50_DATA 0x1C040500
+#define DDRSS_CTL_51_DATA 0x081D1C1D
 #define DDRSS_CTL_52_DATA 0x14000D0A
 #define DDRSS_CTL_53_DATA 0x02010A0A
 #define DDRSS_CTL_54_DATA 0x01010002
-#define DDRSS_CTL_55_DATA 0x0408
-#define DDRSS_CTL_56_DATA 0x04131304
-#define DDRSS_CTL_57_DATA 0x1313
+#define DDRSS_CTL_55_DATA 0x04383808
+#define DDRSS_CTL_56_DATA 0x041F1F04
+#define DDRSS_CTL_57_DATA 0x1F1F
 #define DDRSS_CTL_58_DATA 0x00010100
 #define DDRSS_CTL_59_DATA 0x0301
 #define DDRSS_CTL_60_DATA 0x0E08
 #define DDRSS_CTL_61_DATA 0x00BB
-#define DDRSS_CTL_62_DATA 0x00E0
-#define DDRSS_CTL_63_DATA 0x0C28
-#define DDRSS_CTL_64_DATA 0x00E0
-#define DDRSS_CTL_65_DATA 0x0C28
+#define DDRSS_CTL_62_DATA 0x0176
+#define DDRSS_CTL_63_DATA 0x1448
+#define DDRSS_CTL_64_DATA 0x0176
+#define DDRSS_CTL_65_DATA 0x1448
 #define DDRSS_CTL_66_DATA 0x0005
 #define DDRSS_CTL_67_DATA 0x0003
-#define DDRSS_CTL_68_DATA 0x00380010
-#define DDRSS_CTL_69_DATA 0x0038017E
-#define DDRSS_CTL_70_DATA 0x0040017E
+#define DDRSS_CTL_68_DATA 0x005D0010
+#define

[PATCH V2] clk: clk_versaclock: Add support for versaclock driver

The driver is based on the Versaclock driver from the Linux code, but
due to the differences in the clock API between U-Boot and Linux, some
pieces had to be changed.

This driver creates a mux, pfd, pll, and a series of fod ouputs.
 Rate   Usecnt  Name
--
 2500 0`-- x304-clock
 2500 0`-- clock-control...@6a.mux
 2500 0|-- clock-control...@6a.pfd
 28   0|   `-- clock-control...@6a.pll
  0|   |-- clock-controller@6a.fod0
  0|   |   `-- clock-controller@6a.out1
  0|   |-- clock-controller@6a.fod1
  0|   |   `-- clock-controller@6a.out2
 5000 0|   |-- clock-controller@6a.fod2
 5000 0|   |   `-- clock-controller@6a.out3
 125000|   `-- clock-controller@6a.fod3
 125000|   `-- clock-controller@6a.out4
 2500 0`-- clock-controller@6a.out0_sel_i2cb

A translation function is added so the references to < X> get routed
to the corresponding clock-control...@6a.outx.

Signed-off-by: Adam Ford 

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 40a5a5dd88..2a7507ea18 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -197,4 +197,13 @@ config SANDBOX_CLK_CCF
  Enable this option if you want to test the Linux kernel's Common
  Clock Framework [CCF] code in U-Boot's Sandbox clock driver.
 
+config CLK_VERSACLOCK
+   tristate "Enable VersaClock 5/6 devices"
+   depends on CLK
+   depends on CLK_CCF
+   depends on OF_CONTROL
+   help
+ This driver supports the IDT VersaClock 5 and VersaClock 6
+ programmable clock generators.
+
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 645709b855..6f5ddafd64 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
 obj-$(CONFIG_STM32H7) += clk_stm32h7.o
 obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
 obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
+obj-$(CONFIG_CLK_VERSACLOCK) += clk_versaclock.o
diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
new file mode 100644
index 00..ee5562978a
--- /dev/null
+++ b/drivers/clk/clk_versaclock.c
@@ -0,0 +1,979 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Driver for IDT Versaclock 5/6
+ *
+ * Derived from code Copyright (C) 2017 Marek Vasut 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Configuration register block */
+#define VC5_PRIM_SRC_SHDN  0x10
+#define VC5_PRIM_SRC_SHDN_EN_XTAL  BIT(7)
+#define VC5_PRIM_SRC_SHDN_EN_CLKIN BIT(6)
+#define VC5_XTAL_X1_LOAD_CAP   0x12
+#define VC5_XTAL_X2_LOAD_CAP   0x13
+#define VC5_REF_DIVIDER0x15
+#define VC5_REF_DIVIDER_SEL_PREDIV2BIT(7)
+#define VC5_REF_DIVIDER_REF_DIV(n) ((n) & 0x3f)
+#define VC5_VCO_CTRL_AND_PREDIV0x16
+#define VC5_VCO_CTRL_AND_PREDIV_BYPASS_PREDIV  BIT(7)
+#define VC5_FEEDBACK_INT_DIV   0x17
+
+/* Output divider control for divider 1,2,3,4 */
+#define VC5_OUT_DIV_CONTROL(idx)   (0x21 + ((idx) * 0x10))
+#define VC5_OUT_DIV_CONTROL_RESET  BIT(7)
+#define VC5_OUT_DIV_CONTROL_SELB_NORM  BIT(3)
+#define VC5_OUT_DIV_CONTROL_SEL_EXTBIT(2)
+#define VC5_OUT_DIV_CONTROL_EN_FOD BIT(0)
+#define VC5_OUT_DIV_FRAC(idx, n)   (0x22 + ((idx) * 0x10) + (n))
+#define VC5_OUT_DIV_INT(idx, n)(0x2d + ((idx) * 0x10) + (n))
+
+/* Clock control register for clock 1,2 */
+#define VC5_CLK_OUTPUT_CFG(idx, n) (0x60 + ((idx) * 0x2) + (n))
+#define VC5_CLK_OUTPUT_CFG0_CFG_SHIFT  5
+#define VC5_CLK_OUTPUT_CFG0_CFG_MASK GENMASK(7, VC5_CLK_OUTPUT_CFG0_CFG_SHIFT)
+#define VC5_CLK_OUTPUT_CFG0_CFG_LVPECL (VC5_LVPECL)
+#define VC5_CLK_OUTPUT_CFG0_CFG_CMOS   (VC5_CMOS)
+#define VC5_CLK_OUTPUT_CFG0_CFG_HCSL33 (VC5_HCSL33)
+#define VC5_CLK_OUTPUT_CFG0_CFG_LVDS   (VC5_LVDS)
+#define VC5_CLK_OUTPUT_CFG0_CFG_CMOS2  (VC5_CMOS2)
+#define VC5_CLK_OUTPUT_CFG0_CFG_CMOSD  (VC5_CMOSD)
+#define VC5_CLK_OUTPUT_CFG0_CFG_HCSL25 (VC5_HCSL25)
+#define VC5_CLK_OUTPUT_CFG0_PWR_SHIFT  3
+#define VC5_CLK_OUTPUT_CFG0_PWR_MASK GENMASK(4, VC5_CLK_OUTPUT_CFG0_PWR_SHIFT)
+#define VC5_CLK_OUTPUT_CFG0_PWR_18 (0 << VC5_CLK_OUTPUT_CFG0_PWR_SHIFT)
+#define VC5_CLK_OUTPUT_CFG0_PWR_25 (2 << VC5_CLK_OUTPUT_CFG0_PWR_SHIFT)
+#define VC5_CLK_OUTPUT_CFG0_PWR_33 (3 << VC5_CLK_OUTPUT_CFG0_PWR_SHIFT)
+#define

Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver

On Thu, Jun 3, 2021 at 3:34 AM Luca Ceresoli  wrote:
>
> On 24/05/21 19:53, Adam Ford wrote:
> > The driver is based on the Versaclock driver from the Linux code, but
> > do differences in the clock API between them, some pieces had to change.
>
> s/do/due to/ ?
> s/had to change/had to be changed/

I am usually more careful about grammar.  I must have been tired.  :-)

>
> > This driver creates a mux, pfd, pll, and a series of fod ouputs.
> >  Rate   Usecnt  Name
> > --
> >  2500 0`-- x304-clock
> >  2500 0`-- clock-control...@6a.mux
> >  2500 0|-- clock-control...@6a.pfd
> >  28   0|   `-- clock-control...@6a.pll
> >   0|   |-- clock-controller@6a.fod0
> >   0|   |   `-- 
> > clock-controller@6a.out1
> >   0|   |-- clock-controller@6a.fod1
> >   0|   |   `-- 
> > clock-controller@6a.out2
> >  5000 0|   |-- clock-controller@6a.fod2
> >  5000 0|   |   `-- 
> > clock-controller@6a.out3
> >  125000|   `-- clock-controller@6a.fod3
> >  125000|   `-- 
> > clock-controller@6a.out4
> >  2500 0`-- clock-controller@6a.out0_sel_i2cb
> >
> > A translation function is added so the references to < X> get 
> > routed
> > to the corresponding clock-control...@6a.outx.
> >
> > Signed-off-by: Adam Ford 
>
> I've been reviewing this patch and it looks mostly OK to me except for a
> few notes below, mostly minor ones. However my knowledge of the U-Boot
> driver model is minimal, thus I couldn't go in depth in the most
> interesting and critical part of Adam's work, i.e. the adaptations for
> the U-Boot codebase. I'm afraid I cannot do more.
>
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index 645709b855..2a9ebec860 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
> >  obj-$(CONFIG_STM32H7) += clk_stm32h7.o
> >  obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
> >  obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
> > +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o
>
> Nit: space after '+='.

make sense.

>
> > diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
> > new file mode 100644
> > index 00..30e49fad31
> > --- /dev/null
> > +++ b/drivers/clk/clk_versaclock.c
> > @@ -0,0 +1,1025 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Driver for IDT Versaclock 5/6
> > + *
> > + * Derived from code Copyright (C) 2017 Marek Vasut 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
>
> Missing file?

This was included a while ago in order to allow the device trees to build.

>
> > +
> > +/* VersaClock5 registers */
> > +#define VC5_OTP_CONTROL  0x00
> > +
> > +/* Factory-reserved register block */
> > +#define VC5_RSVD_DEVICE_ID   0x01
> > +#define VC5_RSVD_ADC_GAIN_7_00x02
> > +#define VC5_RSVD_ADC_GAIN_15_8   0x03
> > +#define VC5_RSVD_ADC_OFFSET_7_0  0x04
> > +#define VC5_RSVD_ADC_OFFSET_15_8 0x05
> > +#define VC5_RSVD_TEMPY   0x06
> > +#define VC5_RSVD_OFFSET_TBIN 0x07
> > +#define VC5_RSVD_GAIN0x08
> > +#define VC5_RSVD_TEST_NP 0x09
> > +#define VC5_RSVD_UNUSED  0x0a
> > +#define VC5_RSVD_BANDGAP_TRIM_UP 0x0b
> > +#define VC5_RSVD_BANDGAP_TRIM_DN 0x0c
> > +#define VC5_RSVD_CLK_R_12_CLK_AMP_4  0x0d
> > +#define VC5_RSVD_CLK_R_34_CLK_AMP_4  0x0e
> > +#define VC5_RSVD_CLK_AMP_123 0x0f
>
> I wonder whether it really makes sense to define so many registers that
> are not used in the driver. But it's done the same way in the Linux
> driver, and it doesn't hurt much, so I'll be fine with or without them.

I thought about it.  Because it was a port from Linux, I thought it
might be nice to keep it consistent, but I can remove the unused
references for cleaner code.

>
> [...]
>
> > +static const struct udevice_id versaclock_ids[] = {
> > + { .compatible = "idt,5p49v5923", .data = (ulong)_5p49v5923_info },
> > + { .compatible = "idt,5p49v5925", .data = (ulong)_5p49v5925_info },
> > + { .compatible = "idt,5p49v5933", .data = (ulong)_5p49v5933_info },
> > + { .compatible = "idt,5p49v5935", .data = (ulong)_5p49v5935_info },
> > +

Re: [BUG] network is broken on Orange Pi PC

On Thu, 3 Jun 2021 12:20:34 +0200
Heinrich Schuchardt  wrote:

Hi,

> On 6/3/21 11:04 AM, Andre Przywara wrote:
> > On Thu, 3 Jun 2021 09:46:48 +0200
> > Heinrich Schuchardt  wrote:
> >
> > Hi Heinrich,
> >  
> >> On 6/2/21 3:08 PM, Ramon Fried wrote:  
> >>> On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt  
> >>> wrote:  
> 
>  Dear all,
> 
>  network is broken in U-Boot on orangepi_pc_defconfig:  
> >
> > Thanks for the report!
> >  
> 
>  U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
>  Allwinner Technology
>  eth0: ethernet@1c3  
>  => dhcp  
>  sun8i_emac_eth_start: Timeout
> 
>  Best regards
> 
>  Heinrich
>   
> >>> Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it 
> >>> broke ?
> >>> Thanks.
> >>> Ramon.
> >>>  
> >>
> >> Git bisect points to:
> >>
> >> commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
> >> Author: Andre Przywara 
> >> Date:   Mon Jul 6 01:40:45 2020 +0100
> >>
> >>   net: sun8i-emac: Lower MDIO frequency
> >>
> >> Reverting the patch solves the problem for the OrangePi PC.
> >>
> >> According to the commit message the change was only needed for needed
> >> for external PHYs.  
> >
> > The external PHY on the Pine64 (non-plus) was the trigger, however
> > both the manual and the Linux driver point to that we definitely need a
> > higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200
> > MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5
> > MHz MDIO frequency. Can you check whether any other divider values fix
> > this for you as well?  
> 
> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was used
> before your patch.
> 
> MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
>   Waiting for PHY auto negotiation to complete. done
> MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
> MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
> MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout
> 
> What is wrong about the approach in
> 
> [PATCH 1/1] net: sun8i-emac: fix MDIO frequency
> https://lists.denx.de/pipermail/u-boot/2021-June/451305.html ?

The MDIO spec says that the maximum frequency on the MDIO bus should be
2.5 MHz. On the H3 with 200 MHz AHB and with a divider of 16 it's 12.5
MHz. Apparently the internal H3 PHY can tolerate those high
frequencies, but it's beyond the spec. And certainly it should not fail
with lower frequencies. And indeed it works for me on the H2+ (which I
understand is just a binned version of the H3).

> The Linux 5.10 driver runs fine no matter what value we choose for the
> divider in U-Boot.

Because it programs the divider correctly:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c#n316
I take it you have no problems with Linux, so the divider being too
high cannot be the root cause of the problem.

So I'd rather fix this problem properly and correctly, especially as it
seems to be more related to the EMAC soft reset (where your error
message comes from).

> But I see a message:
> 
> dwmac-sun8i 1c3.ethernet:
> Current syscon value is not the default 148000 (expect 58000)
> 
> @default_syscon_value:
> The default value of the EMAC register in syscon
> This value is used for disabling properly EMAC
> and used as a good starting value in case of the
> boot process(uboot) leave some stuff.

Yeah, I never got the reason for this message. If Linux wants a
certain value, it should program that. Whatever was left by someone
else (be it U-Boot or some other software/OS) should not matter.

Cheers,
Andre
  
> 
> Best regards
> 
> Heinrich
> 
> >  
> >> Can't we let the change depend on priv->use_internal_phy?
> >>
> >> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> >> index 5a1b38bf80..d7553fe163 100644
> >> --- a/drivers/net/sun8i_emac.c
> >> +++ b/drivers/net/sun8i_emac.c
> >> @@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int
> >> addr, int devad, int reg)
> >>* The EMAC clock is either 200 or 300 MHz, so we need a divider
> >>* of 128 to get the MDIO frequency below the required 2.5 MHz.
> >>*/
> >> -   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> >> MDIO_CMD_MII_CLK_CSR_SHIFT;
> >> +   if (!priv->use_internal_phy)
> >> +   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> >> +  MDIO_CMD_MII_CLK_CSR_SHIFT;
> >>
> >>   mii_cmd |= MDIO_CMD_MII_BUSY;
> >>
> >> @@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int
> >> addr, int devad, int reg,
> >>* The EMAC clock is either 200 or 300 MHz, so we need a divider
> >>* of 128 to get the MDIO frequency below the required 2.5 MHz.
> >>*/
> >> -   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> >> MDIO_CMD_MII_CLK_CSR_SHIFT;
> >> +   if (!priv->use_internal_phy)
> >> +

[PATCHv5] drivers: tpm2: update reset gpio semantics

2021-06-03 Thread Jorge Ramirez-Ortiz

Use the more generic reset-gpios property name.

Signed-off-by: Jorge Ramirez-Ortiz 
Acked-by: Michal Simek 
---

 v5: added Acked-by: Michal Simek
 
 .../tpm2/tis-tpm2-spi.txt |  3 ++-
 drivers/tpm/tpm2_tis_spi.c| 23 ---
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
index 3a2ee4bd17..16f870225f 100644
--- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
+++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
@@ -6,7 +6,8 @@ Required properties:
 - reg  : SPI Chip select
 
 Optional properties:
-- gpio-reset   : Reset GPIO (if not connected to the SoC reset line)
+- reset-gpios  : Reset GPIO (if not connected to the SoC reset line)
+- gpio-reset   : Reset GPIO (deprecated, use reset-gpios instead)
 - spi-max-frequency: See spi-bus.txt
 
 Example:
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 4b33ac8fd3..1d24d32d86 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -589,18 +589,25 @@ static int tpm_tis_spi_probe(struct udevice *dev)
if (CONFIG_IS_ENABLED(DM_GPIO)) {
struct gpio_desc reset_gpio;
 
-   ret = gpio_request_by_name(dev, "gpio-reset", 0,
+   ret = gpio_request_by_name(dev, "reset-gpios", 0,
   _gpio, GPIOD_IS_OUT);
if (ret) {
-   log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
-   __func__);
-   } else {
-   dm_gpio_set_value(_gpio, 1);
-   mdelay(1);
-   dm_gpio_set_value(_gpio, 0);
+   /* legacy reset */
+   ret = gpio_request_by_name(dev, "gpio-reset", 0,
+  _gpio, GPIOD_IS_OUT);
+   if (ret) {
+   log(LOGC_NONE, LOGL_NOTICE,
+   "%s: missing reset GPIO\n", __func__);
+   goto init;
+   }
+   log(LOGC_NONE, LOGL_NOTICE,
+   "%s: gpio-reset is deprecated\n", __func__);
}
+   dm_gpio_set_value(_gpio, 1);
+   mdelay(1);
+   dm_gpio_set_value(_gpio, 0);
}
-
+init:
/* Ensure a minimum amount of time elapsed since reset of the TPM */
mdelay(drv_data->time_before_first_cmd_ms);
 
-- 
2.31.1

Re: [PATCHv4] drivers: tpm2: update reset gpio semantics




On 6/3/21 12:38 PM, Jorge Ramirez-Ortiz wrote:
> Use the more generic reset-gpios property name.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
> 
>  v4: s/will be deprecated/is deprecated
>  
>  .../tpm2/tis-tpm2-spi.txt |  3 ++-
>  drivers/tpm/tpm2_tis_spi.c| 23 ---
>  2 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
> b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> index 3a2ee4bd17..16f870225f 100644
> --- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> +++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> @@ -6,7 +6,8 @@ Required properties:
>  - reg: SPI Chip select
>  
>  Optional properties:
> -- gpio-reset : Reset GPIO (if not connected to the SoC reset line)
> +- reset-gpios: Reset GPIO (if not connected to the SoC reset 
> line)
> +- gpio-reset : Reset GPIO (deprecated, use reset-gpios instead)
>  - spi-max-frequency  : See spi-bus.txt
>  
>  Example:
> diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> index 4b33ac8fd3..1d24d32d86 100644
> --- a/drivers/tpm/tpm2_tis_spi.c
> +++ b/drivers/tpm/tpm2_tis_spi.c
> @@ -589,18 +589,25 @@ static int tpm_tis_spi_probe(struct udevice *dev)
>   if (CONFIG_IS_ENABLED(DM_GPIO)) {
>   struct gpio_desc reset_gpio;
>  
> - ret = gpio_request_by_name(dev, "gpio-reset", 0,
> + ret = gpio_request_by_name(dev, "reset-gpios", 0,
>  _gpio, GPIOD_IS_OUT);
>   if (ret) {
> - log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
> - __func__);
> - } else {
> - dm_gpio_set_value(_gpio, 1);
> - mdelay(1);
> - dm_gpio_set_value(_gpio, 0);
> + /* legacy reset */
> + ret = gpio_request_by_name(dev, "gpio-reset", 0,
> +_gpio, GPIOD_IS_OUT);
> + if (ret) {
> + log(LOGC_NONE, LOGL_NOTICE,
> + "%s: missing reset GPIO\n", __func__);
> + goto init;
> + }
> + log(LOGC_NONE, LOGL_NOTICE,
> + "%s: gpio-reset is deprecated\n", __func__);
>   }
> + dm_gpio_set_value(_gpio, 1);
> + mdelay(1);
> + dm_gpio_set_value(_gpio, 0);
>   }
> -
> +init:
>   /* Ensure a minimum amount of time elapsed since reset of the TPM */
>   mdelay(drv_data->time_before_first_cmd_ms);
>  
> 

Acked-by: Michal Simek 

Thanks,
Michal

[PATCHv4] drivers: tpm2: update reset gpio semantics

2021-06-03 Thread Jorge Ramirez-Ortiz

Use the more generic reset-gpios property name.

Signed-off-by: Jorge Ramirez-Ortiz 
---

 v4: s/will be deprecated/is deprecated
 
 .../tpm2/tis-tpm2-spi.txt |  3 ++-
 drivers/tpm/tpm2_tis_spi.c| 23 ---
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
index 3a2ee4bd17..16f870225f 100644
--- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
+++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
@@ -6,7 +6,8 @@ Required properties:
 - reg  : SPI Chip select
 
 Optional properties:
-- gpio-reset   : Reset GPIO (if not connected to the SoC reset line)
+- reset-gpios  : Reset GPIO (if not connected to the SoC reset line)
+- gpio-reset   : Reset GPIO (deprecated, use reset-gpios instead)
 - spi-max-frequency: See spi-bus.txt
 
 Example:
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 4b33ac8fd3..1d24d32d86 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -589,18 +589,25 @@ static int tpm_tis_spi_probe(struct udevice *dev)
if (CONFIG_IS_ENABLED(DM_GPIO)) {
struct gpio_desc reset_gpio;
 
-   ret = gpio_request_by_name(dev, "gpio-reset", 0,
+   ret = gpio_request_by_name(dev, "reset-gpios", 0,
   _gpio, GPIOD_IS_OUT);
if (ret) {
-   log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
-   __func__);
-   } else {
-   dm_gpio_set_value(_gpio, 1);
-   mdelay(1);
-   dm_gpio_set_value(_gpio, 0);
+   /* legacy reset */
+   ret = gpio_request_by_name(dev, "gpio-reset", 0,
+  _gpio, GPIOD_IS_OUT);
+   if (ret) {
+   log(LOGC_NONE, LOGL_NOTICE,
+   "%s: missing reset GPIO\n", __func__);
+   goto init;
+   }
+   log(LOGC_NONE, LOGL_NOTICE,
+   "%s: gpio-reset is deprecated\n", __func__);
}
+   dm_gpio_set_value(_gpio, 1);
+   mdelay(1);
+   dm_gpio_set_value(_gpio, 0);
}
-
+init:
/* Ensure a minimum amount of time elapsed since reset of the TPM */
mdelay(drv_data->time_before_first_cmd_ms);
 
-- 
2.31.1

Re: [BUG] network is broken on Orange Pi PC


On 6/3/21 11:04 AM, Andre Przywara wrote:

On Thu, 3 Jun 2021 09:46:48 +0200
Heinrich Schuchardt  wrote:

Hi Heinrich,


On 6/2/21 3:08 PM, Ramon Fried wrote:

On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt  wrote:


Dear all,

network is broken in U-Boot on orangepi_pc_defconfig:


Thanks for the report!



U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
Allwinner Technology
eth0: ethernet@1c3
=> dhcp
sun8i_emac_eth_start: Timeout

Best regards

Heinrich


Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it broke ?
Thanks.
Ramon.



Git bisect points to:

commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
Author: Andre Przywara 
Date:   Mon Jul 6 01:40:45 2020 +0100

  net: sun8i-emac: Lower MDIO frequency

Reverting the patch solves the problem for the OrangePi PC.

According to the commit message the change was only needed for needed
for external PHYs.


The external PHY on the Pine64 (non-plus) was the trigger, however
both the manual and the Linux driver point to that we definitely need a
higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200
MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5
MHz MDIO frequency. Can you check whether any other divider values fix
this for you as well?


MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 and this is the value that was used
before your patch.

MDIO_CMD_MII_CLK_CSR_DIV_16 = 0 =>
Waiting for PHY auto negotiation to complete. done
MDIO_CMD_MII_CLK_CSR_DIV_32 = 1 => sun8i_emac_eth_start: Timeout
MDIO_CMD_MII_CLK_CSR_DIV_64 = 2 => sun8i_emac_eth_start: Timeout
MDIO_CMD_MII_CLK_CSR_DIV_128 = 3 => sun8i_emac_eth_start: Timeout

What is wrong about the approach in

[PATCH 1/1] net: sun8i-emac: fix MDIO frequency
https://lists.denx.de/pipermail/u-boot/2021-June/451305.html ?

The Linux 5.10 driver runs fine no matter what value we choose for the
divider in U-Boot. But I see a message:

dwmac-sun8i 1c3.ethernet:
Current syscon value is not the default 148000 (expect 58000)

@default_syscon_value:
The default value of the EMAC register in syscon
This value is used for disabling properly EMAC
and used as a good starting value in case of the
boot process(uboot) leave some stuff.

Best regards

Heinrich




Can't we let the change depend on priv->use_internal_phy?

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 5a1b38bf80..d7553fe163 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int
addr, int devad, int reg)
   * The EMAC clock is either 200 or 300 MHz, so we need a divider
   * of 128 to get the MDIO frequency below the required 2.5 MHz.
   */
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

  mii_cmd |= MDIO_CMD_MII_BUSY;

@@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int
addr, int devad, int reg,
   * The EMAC clock is either 200 or 300 MHz, so we need a divider
   * of 128 to get the MDIO frequency below the required 2.5 MHz.
   */
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

  mii_cmd |= MDIO_CMD_MII_WRITE;
  mii_cmd |= MDIO_CMD_MII_BUSY;

Best regards

Heinrich

I would assume the problem hits all H3 boards.


And that's the confusing part: it does not. I tested this on my
OrangePi Zero (H2+ with internal PHY), both back then with the original
MDIO frequency patch and also now after your report. It always worked
reliably for me.
Also: I am still puzzled how one influences the other: The error you
get is from the *MAC* soft reset: I would think this is an independent
operation from any communication attempts with the PHY.

There is this thread here about the same symptom on a V3s:
https://lists.denx.de/pipermail/u-boot/2021-May/450315.html
v2 of this original patch (in the same thread) proposes some other
solution, which I am also not very happy with. But just to get some more
data points: can you check whether skipping the soft reset fixes this
for you? I will have a closer look tonight to check the order of soft
reset and PHY communication. Maybe we should only do the soft reset
*once* when the MAC probes, and not on every .start call?

Thanks,
Andre

Re: [PATCH v1 4/5] rockchip: Add rk3568 architecture core

2021-06-03 Thread Kever Yang


Hi Peter

On 2021/6/2 下午7:51, Peter Robinson wrote:

On Wed, Jun 2, 2021 at 12:47 PM Joseph Chen  wrote:

RK3568 is a high-performance and low power quad-core application
processor designed for personal mobile internet device and AIoT
equipments.

Signed-off-by: Joseph Chen 
---

  arch/arm/include/asm/arch-rk3568/boot0.h  |  11 +
  arch/arm/include/asm/arch-rk3568/gpio.h   |  11 +
  .../include/asm/arch-rockchip/grf_rk3568.h| 369 ++
  arch/arm/mach-rockchip/Kconfig|  17 +
  arch/arm/mach-rockchip/Makefile   |   1 +
  arch/arm/mach-rockchip/rk3568/Kconfig |  20 +
  arch/arm/mach-rockchip/rk3568/Makefile|   9 +

I wonder if this directory structure should be called rk35xx given
that at least the rk3566 shares a lot with the rk3568?



Yes, rk356x is an option, but I think it's OK to use 'rk3568' to name 
all the module compatible and soc basic


folder name, which we can sync from kernel directly. And for rk3566, we 
can know its relation with rk3568


from dtsi and defconfig file.


Thanks,
- Kever

Re: [PATCHv3] drivers: tpm2: update reset gpio semantics




On 6/3/21 11:21 AM, Jorge Ramirez-Ortiz wrote:
> Use the more generic reset-gpios property name.
> 
> Signed-off-by: Jorge Ramirez-Ortiz 
> ---
> 
>  v3: maintained the legacy property in the docs
> 
>  .../tpm2/tis-tpm2-spi.txt |  3 ++-
>  drivers/tpm/tpm2_tis_spi.c| 23 ---
>  2 files changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
> b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> index 3a2ee4bd17..521550bf67 100644
> --- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> +++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> @@ -6,7 +6,8 @@ Required properties:
>  - reg: SPI Chip select
>  
>  Optional properties:
> -- gpio-reset : Reset GPIO (if not connected to the SoC reset line)
> +- reset-gpios: Reset GPIO (if not connected to the SoC reset 
> line)
> +- gpio-reset : Reset GPIO (will be deprecated, use reset-gpios 
> instead)

nit: I would use "is deprecated"

>  - spi-max-frequency  : See spi-bus.txt
>  
>  Example:
> diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> index 4b33ac8fd3..73e7c342aa 100644
> --- a/drivers/tpm/tpm2_tis_spi.c
> +++ b/drivers/tpm/tpm2_tis_spi.c
> @@ -589,18 +589,25 @@ static int tpm_tis_spi_probe(struct udevice *dev)
>   if (CONFIG_IS_ENABLED(DM_GPIO)) {
>   struct gpio_desc reset_gpio;
>  
> - ret = gpio_request_by_name(dev, "gpio-reset", 0,
> + ret = gpio_request_by_name(dev, "reset-gpios", 0,
>  _gpio, GPIOD_IS_OUT);
>   if (ret) {
> - log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
> - __func__);
> - } else {
> - dm_gpio_set_value(_gpio, 1);
> - mdelay(1);
> - dm_gpio_set_value(_gpio, 0);
> + /* legacy reset */
> + ret = gpio_request_by_name(dev, "gpio-reset", 0,
> +_gpio, GPIOD_IS_OUT);
> + if (ret) {
> + log(LOGC_NONE, LOGL_NOTICE,
> + "%s: missing reset GPIO\n", __func__);
> + goto init;
> + }
> + log(LOGC_NONE, LOGL_NOTICE,
> + "%s: gpio-reset will be deprecated\n", __func__);

ditto.

>   }
> + dm_gpio_set_value(_gpio, 1);
> + mdelay(1);
> + dm_gpio_set_value(_gpio, 0);
>   }
> -
> +init:
>   /* Ensure a minimum amount of time elapsed since reset of the TPM */
>   mdelay(drv_data->time_before_first_cmd_ms);
>  
> 

With above changes
Acked-by: Michal Simek 

Thanks,
Michal

[PATCHv3] drivers: tpm2: update reset gpio semantics

2021-06-03 Thread Jorge Ramirez-Ortiz

Use the more generic reset-gpios property name.

Signed-off-by: Jorge Ramirez-Ortiz 
---

 v3: maintained the legacy property in the docs

 .../tpm2/tis-tpm2-spi.txt |  3 ++-
 drivers/tpm/tpm2_tis_spi.c| 23 ---
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
index 3a2ee4bd17..521550bf67 100644
--- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
+++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
@@ -6,7 +6,8 @@ Required properties:
 - reg  : SPI Chip select
 
 Optional properties:
-- gpio-reset   : Reset GPIO (if not connected to the SoC reset line)
+- reset-gpios  : Reset GPIO (if not connected to the SoC reset line)
+- gpio-reset   : Reset GPIO (will be deprecated, use reset-gpios 
instead)
 - spi-max-frequency: See spi-bus.txt
 
 Example:
diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 4b33ac8fd3..73e7c342aa 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -589,18 +589,25 @@ static int tpm_tis_spi_probe(struct udevice *dev)
if (CONFIG_IS_ENABLED(DM_GPIO)) {
struct gpio_desc reset_gpio;
 
-   ret = gpio_request_by_name(dev, "gpio-reset", 0,
+   ret = gpio_request_by_name(dev, "reset-gpios", 0,
   _gpio, GPIOD_IS_OUT);
if (ret) {
-   log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
-   __func__);
-   } else {
-   dm_gpio_set_value(_gpio, 1);
-   mdelay(1);
-   dm_gpio_set_value(_gpio, 0);
+   /* legacy reset */
+   ret = gpio_request_by_name(dev, "gpio-reset", 0,
+  _gpio, GPIOD_IS_OUT);
+   if (ret) {
+   log(LOGC_NONE, LOGL_NOTICE,
+   "%s: missing reset GPIO\n", __func__);
+   goto init;
+   }
+   log(LOGC_NONE, LOGL_NOTICE,
+   "%s: gpio-reset will be deprecated\n", __func__);
}
+   dm_gpio_set_value(_gpio, 1);
+   mdelay(1);
+   dm_gpio_set_value(_gpio, 0);
}
-
+init:
/* Ensure a minimum amount of time elapsed since reset of the TPM */
mdelay(drv_data->time_before_first_cmd_ms);
 
-- 
2.31.1

[PATCH 6/6] configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT library overlay

Enable config to support gpt command on AM642 evm/sk and enable config for
FDT library overlay support

Signed-off-by: Aswath Govindraju 
---
 configs/am64x_evm_a53_defconfig | 2 ++
 configs/am64x_evm_r5_defconfig  | 1 +
 2 files changed, 3 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index edce099f28b2..b19b58f795b0 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -120,6 +120,7 @@ CONFIG_OMAP_TIMER=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
 CONFIG_CMD_DFU=y
 CONFIG_CMD_DM=y
+CONFIG_CMD_GPT=y
 CONFIG_CMD_USB=y
 CONFIG_DFU=y
 CONFIG_DFU_OVER_USB=y
@@ -152,3 +153,4 @@ CONFIG_USB_GADGET_DUALSPEED=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_FUNCTION_MASS_STORAGE=y
 CONFIG_FAT_WRITE=y
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index df70852669d4..1f04b3683f87 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -58,6 +58,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_DFU=y
+CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_REMOTEPROC=y
 CONFIG_CMD_USB=y
-- 
2.17.1

[PATCH 5/6] configs: am64x_evm_a53_defconfig/am64x_evm_r5_defconfig: Enable configs to support eMMC boot

From: Kishon Vijay Abraham I 

Enable configs to support eMMC boot.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Aswath Govindraju 
---
 configs/am64x_evm_a53_defconfig | 1 +
 configs/am64x_evm_r5_defconfig  | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 34c527940cb6..edce099f28b2 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -81,6 +81,7 @@ CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_SPL_MMC_HS200_SUPPORT=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_SPL_MMC_HS400_SUPPORT=y
+CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_SPL_MMC_SDHCI_ADMA=y
diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index 57e0399ea0fa..df70852669d4 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -37,6 +37,8 @@ CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_EARLY_BSS=y
 CONFIG_SPL_BOARD_INIT=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
 CONFIG_SPL_ENV_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_DM_MAILBOX=y
-- 
2.17.1

[PATCH 4/6] configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to save env in eMMC and FAT write.

Kconfig symbols for SYS_MMC_ENV_DEV and SYS_MMC_ENV_PART have been added by
commit 7d080773347c1f6e0e896d9284134a2a411155d6. Therefore, move the
definitions of configs to corresponding board defconfig files and enable
configs to save env in eMMC.

Also enable config for FAT write in U-Boot.

Fixes: 33b7258947f4 ("board: ti: am64x: Add board support for am64x evm")
Signed-off-by: Aswath Govindraju 
---
 configs/am64x_evm_a53_defconfig | 10 +++---
 configs/am64x_evm_r5_defconfig  |  4 
 include/configs/am64x_evm.h |  6 --
 3 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 41eb43f191d6..34c527940cb6 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -8,6 +8,7 @@ CONFIG_SOC_K3_AM642=y
 CONFIG_K3_ATF_LOAD_ADDR=0x701a
 CONFIG_TARGET_AM642_A53_EVM=y
 CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x68
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
 CONFIG_SPL_DM_SPI=y
 CONFIG_SPL_TEXT_BASE=0x8008
@@ -29,6 +30,8 @@ CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
 CONFIG_SPL_DMA=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_ENV_SUPPORT=y
@@ -53,10 +56,10 @@ CONFIG_OF_LIST="k3-am642-evm k3-am642-sk"
 CONFIG_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
-CONFIG_ENV_IS_NOWHERE=y
-CONFIG_ENV_IS_IN_FAT=y
-CONFIG_ENV_FAT_DEVICE_AND_PART="1:1"
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_MMC_ENV_DEV=0
+CONFIG_SYS_MMC_ENV_PART=1
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
@@ -147,3 +150,4 @@ CONFIG_USB_GADGET_VBUS_DRAW=2
 CONFIG_USB_GADGET_DUALSPEED=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_FUNCTION_MASS_STORAGE=y
+CONFIG_FAT_WRITE=y
diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig
index 3e9b5650c60d..57e0399ea0fa 100644
--- a/configs/am64x_evm_r5_defconfig
+++ b/configs/am64x_evm_r5_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x8
 CONFIG_SOC_K3_AM642=y
 CONFIG_TARGET_AM642_R5_EVM=y
 CONFIG_ENV_SIZE=0x2
+CONFIG_ENV_OFFSET=0x68
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x8
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
@@ -22,6 +23,9 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEFAULT_DEVICE_TREE="k3-am642-r5-evm"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SYS_MMC_ENV_DEV=0
+CONFIG_SYS_MMC_ENV_PART=1
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
 # CONFIG_DISPLAY_CPUINFO is not set
diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index c2c2bf06777c..7c520f4395b5 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -115,10 +115,4 @@
 
 #define CONFIG_SYS_USB_FAT_BOOT_PARTITION 1
 
-/* MMC ENV related defines */
-#ifdef CONFIG_ENV_IS_IN_MMC
-#define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_SYS_MMC_ENV_PART1
-#endif
-
 #endif /* __CONFIG_AM642_EVM_H */
-- 
2.17.1

[PATCH 3/6] configs: am64x_evm_a53_defconfig: Enable configs to support HS200/HS400

From: Kishon Vijay Abraham I 

Enable configs to support HS200/HS400.

Signed-off-by: Kishon Vijay Abraham I 
Signed-off-by: Aswath Govindraju 
---
 configs/am64x_evm_a53_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index a3aab807c6e7..41eb43f191d6 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -73,6 +73,11 @@ CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_OMAP24XX=y
 CONFIG_DM_MAILBOX=y
 CONFIG_K3_SEC_PROXY=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_SPL_MMC_HS200_SUPPORT=y
+CONFIG_MMC_HS400_SUPPORT=y
+CONFIG_SPL_MMC_HS400_SUPPORT=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ADMA=y
 CONFIG_SPL_MMC_SDHCI_ADMA=y
-- 
2.17.1

[PATCH 2/6] arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias index 1 for main_sdhci1 node

A Wilink wireless device is connected to MMCSD0 subsystem and is not
supported in U-Boot. Therefore, disable main_sdhci0 device tree node in
U-Boot.

If main_sdhci0 device tree node is disabled then the the index of
main_sdhci1 node becomes 0 which leads to break in boot flow. Therefore,
add an alias to fix the index to 1.

Signed-off-by: Aswath Govindraju 
---
 arch/arm/dts/k3-am642-sk-u-boot.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi 
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 35b49df85106..efbcfb36e92a 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -8,6 +8,10 @@
stdout-path = "serial2:115200n8";
tick-timer = 
};
+
+   aliases {
+   mmc1 = 
+   };
 };
 
 _main{
@@ -79,6 +83,7 @@
 };
 
  {
+   status = "disabled";
u-boot,dm-spl;
 };
 
-- 
2.17.1

[PATCH 1/6] arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to spl_mmc_boot_mode()

Function spl_boot_mode() is called in common/spl/spl_mmc.c, to find the
boot mode for a given boot device. This function was renamed to
spl_mmc_boot_mode() by commit e97590654aea4c964f49bd915543a417d0c76996.

Therefore, rename spl_boot_mode to spl_mmc_boot_mode.

Fixes: 57dba04afbb7 ("arm: mach-k3: am642: Add support for boot device 
detection")
Signed-off-by: Aswath Govindraju 
---
 arch/arm/mach-k3/am642_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/am642_init.c b/arch/arm/mach-k3/am642_init.c
index 579dbacb7e48..8d8b07076a98 100644
--- a/arch/arm/mach-k3/am642_init.c
+++ b/arch/arm/mach-k3/am642_init.c
@@ -198,7 +198,7 @@ void board_init_f(ulong dummy)
 #endif
 }
 
-u32 spl_boot_mode(const u32 boot_device)
+u32 spl_mmc_boot_mode(const u32 boot_device)
 {
switch (boot_device) {
case BOOT_DEVICE_MMC1:
-- 
2.17.1

Re: [BUG] network is broken on Orange Pi PC

On Thu, 3 Jun 2021 09:46:48 +0200
Heinrich Schuchardt  wrote:

Hi Heinrich,

> On 6/2/21 3:08 PM, Ramon Fried wrote:
> > On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt  
> > wrote:  
> >>
> >> Dear all,
> >>
> >> network is broken in U-Boot on orangepi_pc_defconfig:

Thanks for the report!

> >>
> >> U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
> >> Allwinner Technology
> >> eth0: ethernet@1c3  
> >> => dhcp  
> >> sun8i_emac_eth_start: Timeout
> >>
> >> Best regards
> >>
> >> Heinrich
> >>  
> > Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it 
> > broke ?
> > Thanks.
> > Ramon.
> >  
> 
> Git bisect points to:
> 
> commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
> Author: Andre Przywara 
> Date:   Mon Jul 6 01:40:45 2020 +0100
> 
>  net: sun8i-emac: Lower MDIO frequency
> 
> Reverting the patch solves the problem for the OrangePi PC.
> 
> According to the commit message the change was only needed for needed
> for external PHYs.

The external PHY on the Pine64 (non-plus) was the trigger, however
both the manual and the Linux driver point to that we definitely need a
higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200
MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5
MHz MDIO frequency. Can you check whether any other divider values fix
this for you as well?

> Can't we let the change depend on priv->use_internal_phy?
> 
> diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
> index 5a1b38bf80..d7553fe163 100644
> --- a/drivers/net/sun8i_emac.c
> +++ b/drivers/net/sun8i_emac.c
> @@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int
> addr, int devad, int reg)
>   * The EMAC clock is either 200 or 300 MHz, so we need a divider
>   * of 128 to get the MDIO frequency below the required 2.5 MHz.
>   */
> -   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> MDIO_CMD_MII_CLK_CSR_SHIFT;
> +   if (!priv->use_internal_phy)
> +   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> +  MDIO_CMD_MII_CLK_CSR_SHIFT;
> 
>  mii_cmd |= MDIO_CMD_MII_BUSY;
> 
> @@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int
> addr, int devad, int reg,
>   * The EMAC clock is either 200 or 300 MHz, so we need a divider
>   * of 128 to get the MDIO frequency below the required 2.5 MHz.
>   */
> -   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> MDIO_CMD_MII_CLK_CSR_SHIFT;
> +   if (!priv->use_internal_phy)
> +   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
> +  MDIO_CMD_MII_CLK_CSR_SHIFT;
> 
>  mii_cmd |= MDIO_CMD_MII_WRITE;
>  mii_cmd |= MDIO_CMD_MII_BUSY;
> 
> Best regards
> 
> Heinrich
> 
> I would assume the problem hits all H3 boards.

And that's the confusing part: it does not. I tested this on my
OrangePi Zero (H2+ with internal PHY), both back then with the original
MDIO frequency patch and also now after your report. It always worked
reliably for me.
Also: I am still puzzled how one influences the other: The error you
get is from the *MAC* soft reset: I would think this is an independent
operation from any communication attempts with the PHY.

There is this thread here about the same symptom on a V3s:
https://lists.denx.de/pipermail/u-boot/2021-May/450315.html
v2 of this original patch (in the same thread) proposes some other
solution, which I am also not very happy with. But just to get some more
data points: can you check whether skipping the soft reset fixes this
for you? I will have a closer look tonight to check the order of soft
reset and PHY communication. Maybe we should only do the soft reset
*once* when the MAC probes, and not on every .start call?

Thanks,
Andre

[PATCH 0/6] AM64: Add support for higher speed modes and boot mode in eMMC

The following series of patches add support for,
- HS200/HS400 speed modes
- eMMC boot mode
- gpt and FDT library overlay

This series of patches,
- dependent on
  https://patchwork.ozlabs.org/project/uboot/list/?series=237442

- applies on top of,
  https://patchwork.ozlabs.org/project/uboot/list/?series=246976

Aswath Govindraju (4):
  arch: arm: mach-k3: am642_init: Correct the function name
spl_boot_mode() to spl_mmc_boot_mode()
  arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define
alias index 1 for main_sdhci1 node
  configs: am64x_evm: Move CONFIG_SYS_MMC_ENV_DEV and
CONFIG_SYS_MMC_ENV_PART to defconfig files and enable configs to
save env in eMMC and FAT write.
  configs: am64x_evm_*_defconfig: Enable config to support gpt and FDT
library overlay

Kishon Vijay Abraham I (2):
  configs: am64x_evm_a53_defconfig: Enable configs to support
HS200/HS400
  configs: am64x_evm_a53_defconfig/am64x_evm_r5_defconfig: Enable
configs to support eMMC boot

 arch/arm/dts/k3-am642-sk-u-boot.dtsi |  5 +
 arch/arm/mach-k3/am642_init.c|  2 +-
 configs/am64x_evm_a53_defconfig  | 18 +++---
 configs/am64x_evm_r5_defconfig   |  7 +++
 include/configs/am64x_evm.h  |  6 --
 5 files changed, 28 insertions(+), 10 deletions(-)

-- 
2.17.1

Re: [PATCHv2] drivers: tpm2: update reset gpio semantics

2021-06-03 Thread Jorge Ramirez-Ortiz, Foundries

On 01/06/21, Michal Simek wrote:
> 
> 
> On 6/1/21 9:35 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 01/06/21, Michal Simek wrote:
> >>
> >>
> >> On 6/1/21 8:09 AM, Jorge Ramirez-Ortiz wrote:
> >>> Use the more generic reset-gpios propery name.
> >>>
> >>> Signed-off-by: Jorge Ramirez-Ortiz 
> >>> ---
> >>>   v2: kept gpio-reset as legacy
> >>>
> >>>  .../tpm2/tis-tpm2-spi.txt |  2 +-
> >>>  drivers/tpm/tpm2_tis_spi.c| 21 ---
> >>>  2 files changed, 14 insertions(+), 9 deletions(-)
> >>>
> >>> diff --git a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt 
> >>> b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> >>> index 3a2ee4bd17..bbcd12950f 100644
> >>> --- a/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> >>> +++ b/doc/device-tree-bindings/tpm2/tis-tpm2-spi.txt
> >>> @@ -6,7 +6,7 @@ Required properties:
> >>>  - reg: SPI Chip select
> >>>  
> >>>  Optional properties:
> >>> -- gpio-reset : Reset GPIO (if not connected to the SoC reset 
> >>> line)
> >>
> >> As I said you shouldn't remove this. Just extend description that it is
> >> deprecated and reset-gpios should be used instead.
> > 
> > I dont really agree with that. IMO we should remove the documentation
> > since it is obsolete after this commit and anyone reading it should
> > not care about the gpio-reset property.
> 
> Run this on linux kernel and you will see that normal style is to keep
> it there.
> git grep deprecated Documentation/devicetree/bindings

um, ok then (although IMO it only makes sense when we have the tools
to parse such documents and apply them at build time)...if you have to
read the docs you might just as well change the property.

will post later today (I am also adding an additional test to tpm2 to
read the rng)

> 
> > 
> >>
> >>> +- reset-gpios: Reset GPIO (if not connected to the SoC reset 
> >>> line)
> >>>  - spi-max-frequency  : See spi-bus.txt
> >>>  
> >>>  Example:
> >>> diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
> >>> index 4b33ac8fd3..1f9f89f68f 100644
> >>> --- a/drivers/tpm/tpm2_tis_spi.c
> >>> +++ b/drivers/tpm/tpm2_tis_spi.c
> >>> @@ -589,18 +589,23 @@ static int tpm_tis_spi_probe(struct udevice *dev)
> >>>   if (CONFIG_IS_ENABLED(DM_GPIO)) {
> >>>   struct gpio_desc reset_gpio;
> >>>  
> >>> - ret = gpio_request_by_name(dev, "gpio-reset", 0,
> >>> + ret = gpio_request_by_name(dev, "reset-gpios", 0,
> >>>  _gpio, GPIOD_IS_OUT);
> >>>   if (ret) {
> >>> - log(LOGC_NONE, LOGL_NOTICE, "%s: missing reset GPIO\n",
> >>> - __func__);
> >>> - } else {
> >>> - dm_gpio_set_value(_gpio, 1);
> >>> - mdelay(1);
> >>> - dm_gpio_set_value(_gpio, 0);
> >>> + /* legacy reset */
> >>> + ret = gpio_request_by_name(dev, "gpio-reset", 0,
> >>> +_gpio, GPIOD_IS_OUT);
> >>> + if (ret) {
> >>> + log(LOGC_NONE, LOGL_NOTICE,
> >>> + "%s: missing reset GPIO\n",  __func__);
> >>> + goto init;
> >>> + }
> >>
> >> And here it is clear that gpio-reset is used which should deprecated
> >> that's why you should print message about it here.
> > 
> > yes, I can do that. makes sense
> > 
> >>
> >>
> >>>   }
> >>> + dm_gpio_set_value(_gpio, 1);
> >>> + mdelay(1);
> >>> + dm_gpio_set_value(_gpio, 0);
> >>>   }
> >>
> >> What about this to remove that goto?
> > 
> > um, what is the problem with the goto (IMO tidier than yet another
> > conditional); it is not as if this goto is making the code obscure.
> > 
> > with the change below you just removed previous functionality
> > (ie indicating that there is no GPIO reset provided, hence why at
> > first sight might look cleaner than a goto)
> 
> I tend to use goto unless there is no way around. But up2you.
> 
> M
>

Re: [PATCH] clk: clk_versaclock: Add support for versaclock driver

2021-06-03 Thread Luca Ceresoli

On 24/05/21 19:53, Adam Ford wrote:
> The driver is based on the Versaclock driver from the Linux code, but
> do differences in the clock API between them, some pieces had to change.

s/do/due to/ ?
s/had to change/had to be changed/

> This driver creates a mux, pfd, pll, and a series of fod ouputs.
>  Rate   Usecnt  Name
> --
>  2500 0`-- x304-clock
>  2500 0`-- clock-control...@6a.mux
>  2500 0|-- clock-control...@6a.pfd
>  28   0|   `-- clock-control...@6a.pll
>   0|   |-- clock-controller@6a.fod0
>   0|   |   `-- 
> clock-controller@6a.out1
>   0|   |-- clock-controller@6a.fod1
>   0|   |   `-- 
> clock-controller@6a.out2
>  5000 0|   |-- clock-controller@6a.fod2
>  5000 0|   |   `-- 
> clock-controller@6a.out3
>  125000|   `-- clock-controller@6a.fod3
>  125000|   `-- 
> clock-controller@6a.out4
>  2500 0`-- clock-controller@6a.out0_sel_i2cb
> 
> A translation function is added so the references to < X> get 
> routed
> to the corresponding clock-control...@6a.outx.
> 
> Signed-off-by: Adam Ford 

I've been reviewing this patch and it looks mostly OK to me except for a
few notes below, mostly minor ones. However my knowledge of the U-Boot
driver model is minimal, thus I couldn't go in depth in the most
interesting and critical part of Adam's work, i.e. the adaptations for
the U-Boot codebase. I'm afraid I cannot do more.

> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 645709b855..2a9ebec860 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
>  obj-$(CONFIG_STM32H7) += clk_stm32h7.o
>  obj-$(CONFIG_CLK_VERSAL) += clk_versal.o
>  obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o
> +obj-$(CONFIG_CLK_VERSACLOCK) +=clk_versaclock.o

Nit: space after '+='.

> diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c
> new file mode 100644
> index 00..30e49fad31
> --- /dev/null
> +++ b/drivers/clk/clk_versaclock.c
> @@ -0,0 +1,1025 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Driver for IDT Versaclock 5/6
> + *
> + * Derived from code Copyright (C) 2017 Marek Vasut 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

Missing file?

> +
> +/* VersaClock5 registers */
> +#define VC5_OTP_CONTROL  0x00
> +
> +/* Factory-reserved register block */
> +#define VC5_RSVD_DEVICE_ID   0x01
> +#define VC5_RSVD_ADC_GAIN_7_00x02
> +#define VC5_RSVD_ADC_GAIN_15_8   0x03
> +#define VC5_RSVD_ADC_OFFSET_7_0  0x04
> +#define VC5_RSVD_ADC_OFFSET_15_8 0x05
> +#define VC5_RSVD_TEMPY   0x06
> +#define VC5_RSVD_OFFSET_TBIN 0x07
> +#define VC5_RSVD_GAIN0x08
> +#define VC5_RSVD_TEST_NP 0x09
> +#define VC5_RSVD_UNUSED  0x0a
> +#define VC5_RSVD_BANDGAP_TRIM_UP 0x0b
> +#define VC5_RSVD_BANDGAP_TRIM_DN 0x0c
> +#define VC5_RSVD_CLK_R_12_CLK_AMP_4  0x0d
> +#define VC5_RSVD_CLK_R_34_CLK_AMP_4  0x0e
> +#define VC5_RSVD_CLK_AMP_123 0x0f

I wonder whether it really makes sense to define so many registers that
are not used in the driver. But it's done the same way in the Linux
driver, and it doesn't hurt much, so I'll be fine with or without them.

[...]

> +static const struct udevice_id versaclock_ids[] = {
> + { .compatible = "idt,5p49v5923", .data = (ulong)_5p49v5923_info },
> + { .compatible = "idt,5p49v5925", .data = (ulong)_5p49v5925_info },
> + { .compatible = "idt,5p49v5933", .data = (ulong)_5p49v5933_info },
> + { .compatible = "idt,5p49v5935", .data = (ulong)_5p49v5935_info },
> + { .compatible = "idt,5p49v6901", .data = (ulong)_5p49v6901_info },
> + { .compatible = "idt,5p49v6965", .data = (ulong)_5p49v6965_info },
> + {},
> +};

Why not putting this array below, right before the U_BOOT_DRIVER() call
where it is used, similarly to the Linux driver?

-- 
Luca

[PATCH 6/6] arm64: zynqmp: Sync psgtr location on zcu100/zcu106

psgtr node should be below pinctrl for easier comparion among dts files.
That's why move that nodes to different location.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zcu100-revC.dts | 14 +++---
 arch/arm/dts/zynqmp-zcu106-revA.dts | 14 +++---
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm/dts/zynqmp-zcu100-revC.dts 
b/arch/arm/dts/zynqmp-zcu100-revC.dts
index cad1a23e9539..45dd7da7179b 100644
--- a/arch/arm/dts/zynqmp-zcu100-revC.dts
+++ b/arch/arm/dts/zynqmp-zcu100-revC.dts
@@ -483,6 +483,13 @@
};
 };
 
+ {
+   status = "okay";
+   /* usb3, dp */
+   clocks = <_0>, <_1>;
+   clock-names = "ref0", "ref1";
+};
+
  {
status = "okay";
 };
@@ -518,13 +525,6 @@
};
 };
 
- {
-   status = "okay";
-   /* usb3, dp */
-   clocks = <_0>, <_1>;
-   clock-names = "ref0", "ref1";
-};
-
  { /* Low Speed connector */
status = "okay";
label = "LS-SPI0";
diff --git a/arch/arm/dts/zynqmp-zcu106-revA.dts 
b/arch/arm/dts/zynqmp-zcu106-revA.dts
index d7140fc950ee..2b1255dc5f32 100644
--- a/arch/arm/dts/zynqmp-zcu106-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu106-revA.dts
@@ -947,6 +947,13 @@
};
 };
 
+ {
+   status = "okay";
+   /* nc, sata, usb3, dp */
+   clocks = < 0 3>, < 0 2>, < 0 0>;
+   clock-names = "ref1", "ref2", "ref3";
+};
+
  {
status = "okay";
is-dual = <1>;
@@ -977,13 +984,6 @@
};
 };
 
- {
-   status = "okay";
-   /* nc, sata, usb3, dp */
-   clocks = < 0 3>, < 0 2>, < 0 0>;
-   clock-names = "ref1", "ref2", "ref3";
-};
-
  {
status = "okay";
 };
-- 
2.31.1

[PATCH 5/6] arm64: zynqmp: Sync dp port location on zc1751 dc4

Historically dpdma and dpsub are placed at the end of files. Move nodes
there for easier comparison among dts files.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts 
b/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
index aadda179c323..e7fbf1c4b70c 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts
@@ -115,14 +115,6 @@
status = "okay";
 };
 
-_dpsub {
-   status = "okay";
-};
-
-_dpdma {
-   status = "okay";
-};
-
  {
status = "okay";
phy-mode = "rgmii-id";
@@ -221,3 +213,11 @@
  {
status = "okay";
 };
+
+_dpdma {
+   status = "okay";
+};
+
+_dpsub {
+   status = "okay";
+};
-- 
2.31.1

[PATCH 4/6] arm64: zynqmp: Remove unused dp_aclk clock

dp_aclk is not used anywhere that's why remove it.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-clk-ccf.dtsi | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/arm/dts/zynqmp-clk-ccf.dtsi b/arch/arm/dts/zynqmp-clk-ccf.dtsi
index 987792e5c511..5ee7aa244552 100644
--- a/arch/arm/dts/zynqmp-clk-ccf.dtsi
+++ b/arch/arm/dts/zynqmp-clk-ccf.dtsi
@@ -67,13 +67,6 @@
#clock-cells = <0>;
clock-frequency = <2700>;
};
-
-   dp_aclk: dp_aclk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <1>;
-   clock-accuracy = <100>;
-   };
 };
 
 _firmware {
-- 
2.31.1

[PATCH 3/6] arm64: zynqmp: Remove addition newline from zc1751 dc1

Trivial patch.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts 
b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
index b0506c08418e..8f361e47bda1 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
@@ -443,4 +443,3 @@
 _dpsub {
status = "okay";
 };
-
-- 
2.31.1

[PATCH 2/6] arm64: zynqmp: Add maximum-speed property for dwc3 nodes

dwc3 can be used only for higher speeds than super-speed that's why
explicitly set it up.
This is also aligned with other ZynqMP dts files.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 1 +
 arch/arm/dts/zynqmp-zcu106-revA.dts  | 1 +
 arch/arm/dts/zynqmp-zcu111-revA.dts  | 1 +
 arch/arm/dts/zynqmp-zcu208-revA.dts  | 1 +
 arch/arm/dts/zynqmp-zcu216-revA.dts  | 1 +
 5 files changed, 5 insertions(+)

diff --git a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts 
b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
index 0c6a2a92dfe5..b0506c08418e 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts
@@ -433,6 +433,7 @@
snps,usb3_lpm_capable;
phy-names = "usb3-phy";
phys = < 2 PHY_TYPE_USB3 0 2>;
+   maximum-speed = "super-speed";
 };
 
 _dpdma {
diff --git a/arch/arm/dts/zynqmp-zcu106-revA.dts 
b/arch/arm/dts/zynqmp-zcu106-revA.dts
index 4da7a3edf548..d7140fc950ee 100644
--- a/arch/arm/dts/zynqmp-zcu106-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu106-revA.dts
@@ -1040,6 +1040,7 @@
snps,usb3_lpm_capable;
phy-names = "usb3-phy";
phys = < 2 PHY_TYPE_USB3 0 2>;
+   maximum-speed = "super-speed";
 };
 
  {
diff --git a/arch/arm/dts/zynqmp-zcu111-revA.dts 
b/arch/arm/dts/zynqmp-zcu111-revA.dts
index 85821065dd43..223bb8a61462 100644
--- a/arch/arm/dts/zynqmp-zcu111-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu111-revA.dts
@@ -861,6 +861,7 @@
snps,usb3_lpm_capable;
phy-names = "usb3-phy";
phys = < 2 PHY_TYPE_USB3 0 2>;
+   maximum-speed = "super-speed";
 };
 
 _dpdma {
diff --git a/arch/arm/dts/zynqmp-zcu208-revA.dts 
b/arch/arm/dts/zynqmp-zcu208-revA.dts
index 03c84ae21acb..7607098ac077 100644
--- a/arch/arm/dts/zynqmp-zcu208-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu208-revA.dts
@@ -701,4 +701,5 @@
snps,usb3_lpm_capable;
phy-names = "usb3-phy";
phys = < 2 PHY_TYPE_USB3 0 2>;
+   maximum-speed = "super-speed";
 };
diff --git a/arch/arm/dts/zynqmp-zcu216-revA.dts 
b/arch/arm/dts/zynqmp-zcu216-revA.dts
index fd1d9bfbd199..7ba60da131f1 100644
--- a/arch/arm/dts/zynqmp-zcu216-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu216-revA.dts
@@ -705,4 +705,5 @@
snps,usb3_lpm_capable;
phy-names = "usb3-phy";
phys = < 2 PHY_TYPE_USB3 0 2>;
+   maximum-speed = "super-speed";
 };
-- 
2.31.1

[PATCH 1/6] arm64: zynqmp: Remove additional header from zc1232 DT

Remove unused phy.h from zc1232 DTS.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zc1232-revA.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp-zc1232-revA.dts 
b/arch/arm/dts/zynqmp-zc1232-revA.dts
index 65dd4e1f3a5d..7543855c9fda 100644
--- a/arch/arm/dts/zynqmp-zc1232-revA.dts
+++ b/arch/arm/dts/zynqmp-zc1232-revA.dts
@@ -11,7 +11,6 @@
 
 #include "zynqmp.dtsi"
 #include "zynqmp-clk-ccf.dtsi"
-#include 
 
 / {
model = "ZynqMP ZC1232 RevA";
-- 
2.31.1

[PATCH 0/6] arm64: zynqmp: DT syncup patches

Hi,

this series is trying to clean and sync DTS files. At the end we want to
have all these files be in sync with the Linux kernel based on DT binding
available in the Linux kernel.

Thanks,
Michal


Michal Simek (6):
  arm64: zynqmp: Remove additional header from zc1232 DT
  arm64: zynqmp: Add maximum-speed property for dwc3 nodes
  arm64: zynqmp: Remove addition newline from zc1751 dc1
  arm64: zynqmp: Remove unused dp_aclk clock
  arm64: zynqmp: Sync dp port location on zc1751 dc4
  arm64: zynqmp: Sync psgtr location on zcu100/zcu106

 arch/arm/dts/zynqmp-clk-ccf.dtsi |  7 ---
 arch/arm/dts/zynqmp-zc1232-revA.dts  |  1 -
 arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts |  2 +-
 arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 16 
 arch/arm/dts/zynqmp-zcu100-revC.dts  | 14 +++---
 arch/arm/dts/zynqmp-zcu106-revA.dts  | 15 ---
 arch/arm/dts/zynqmp-zcu111-revA.dts  |  1 +
 arch/arm/dts/zynqmp-zcu208-revA.dts  |  1 +
 arch/arm/dts/zynqmp-zcu216-revA.dts  |  1 +
 9 files changed, 27 insertions(+), 31 deletions(-)

-- 
2.31.1

Re: [PATCH v1 4/5] rockchip: Add rk3568 architecture core

2021-06-03 Thread Peter Robinson

On Thu, Jun 3, 2021 at 2:43 AM 陈健洪  wrote:
>
> Hi, Peter:
>
> 在 2021/6/2 19:51, Peter Robinson 写道:
> > On Wed, Jun 2, 2021 at 12:47 PM Joseph Chen  wrote:
> >> RK3568 is a high-performance and low power quad-core application
> >> processor designed for personal mobile internet device and AIoT
> >> equipments.
> >>
> >> Signed-off-by: Joseph Chen 
> >> ---
> >>
> >>   arch/arm/include/asm/arch-rk3568/boot0.h  |  11 +
> >>   arch/arm/include/asm/arch-rk3568/gpio.h   |  11 +
> >>   .../include/asm/arch-rockchip/grf_rk3568.h| 369 ++
> >>   arch/arm/mach-rockchip/Kconfig|  17 +
> >>   arch/arm/mach-rockchip/Makefile   |   1 +
> >>   arch/arm/mach-rockchip/rk3568/Kconfig |  20 +
> >>   arch/arm/mach-rockchip/rk3568/Makefile|   9 +
> > I wonder if this directory structure should be called rk35xx given
> > that at least the rk3566 shares a lot with the rk3568?
>
> Rockchip doesn't plan to add rk3566 support to U-Boot and Kernel
> mainline, only rk3568 will be supported.

Why not? What happens if others do?

> >>   arch/arm/mach-rockchip/rk3568/clk_rk3568.c|  53 +++
> >>   arch/arm/mach-rockchip/rk3568/rk3568.c|  85 
> >>   arch/arm/mach-rockchip/rk3568/syscon_rk3568.c |  24 ++
> >>   include/configs/rk3568_common.h   |  43 ++
> >>   11 files changed, 643 insertions(+)
> >>   create mode 100644 arch/arm/include/asm/arch-rk3568/boot0.h
> >>   create mode 100644 arch/arm/include/asm/arch-rk3568/gpio.h
> >>   create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3568.h
> >>   create mode 100644 arch/arm/mach-rockchip/rk3568/Kconfig
> >>   create mode 100644 arch/arm/mach-rockchip/rk3568/Makefile
> >>   create mode 100644 arch/arm/mach-rockchip/rk3568/clk_rk3568.c
> >>   create mode 100644 arch/arm/mach-rockchip/rk3568/rk3568.c
> >>   create mode 100644 arch/arm/mach-rockchip/rk3568/syscon_rk3568.c
> >>   create mode 100644 include/configs/rk3568_common.h
> >>
> >> diff --git a/arch/arm/include/asm/arch-rk3568/boot0.h 
> >> b/arch/arm/include/asm/arch-rk3568/boot0.h
> >> new file mode 100644
> >> index 00..dea2b20252
> >> --- /dev/null
> >> +++ b/arch/arm/include/asm/arch-rk3568/boot0.h
> >> @@ -0,0 +1,11 @@
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >> +/*
> >> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> >> + */
> >> +
> >> +#ifndef __ASM_ARCH_BOOT0_H__
> >> +#define __ASM_ARCH_BOOT0_H__
> >> +
> >> +#include 
> >> +
> >> +#endif
> >> diff --git a/arch/arm/include/asm/arch-rk3568/gpio.h 
> >> b/arch/arm/include/asm/arch-rk3568/gpio.h
> >> new file mode 100644
> >> index 00..b48c0a5cf8
> >> --- /dev/null
> >> +++ b/arch/arm/include/asm/arch-rk3568/gpio.h
> >> @@ -0,0 +1,11 @@
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >> +/*
> >> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> >> + */
> >> +
> >> +#ifndef __ASM_ARCH_GPIO_H__
> >> +#define __ASM_ARCH_GPIO_H__
> >> +
> >> +#include 
> >> +
> >> +#endif
> >> diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3568.h 
> >> b/arch/arm/include/asm/arch-rockchip/grf_rk3568.h
> >> new file mode 100644
> >> index 00..d4e9b56292
> >> --- /dev/null
> >> +++ b/arch/arm/include/asm/arch-rockchip/grf_rk3568.h
> >> @@ -0,0 +1,369 @@
> >> +/* SPDX-License-Identifier: GPL-2.0+ */
> >> +/*
> >> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> >> + */
> >> +
> >> +#ifndef __SOC_ROCKCHIP_RK3568_GRF_H__
> >> +#define __SOC_ROCKCHIP_RK3568_GRF_H__
> >> +
> >> +struct rk3568_grf {
> >> +   unsigned int gpio1a_iomux_l;
> >> +   unsigned int gpio1a_iomux_h;
> >> +   unsigned int gpio1b_iomux_l;
> >> +   unsigned int gpio1b_iomux_h;
> >> +   unsigned int gpio1c_iomux_l;
> >> +   unsigned int gpio1c_iomux_h;
> >> +   unsigned int gpio1d_iomux_l;
> >> +   unsigned int gpio1d_iomux_h;
> >> +   unsigned int gpio2a_iomux_l;
> >> +   unsigned int gpio2a_iomux_h;
> >> +   unsigned int gpio2b_iomux_l;
> >> +   unsigned int gpio2b_iomux_h;
> >> +   unsigned int gpio2c_iomux_l;
> >> +   unsigned int gpio2c_iomux_h;
> >> +   unsigned int gpio2d_iomux_l;
> >> +   unsigned int gpio2d_iomux_h;
> >> +   unsigned int gpio3a_iomux_l;
> >> +   unsigned int gpio3a_iomux_h;
> >> +   unsigned int gpio3b_iomux_l;
> >> +   unsigned int gpio3b_iomux_h;
> >> +   unsigned int gpio3c_iomux_l;
> >> +   unsigned int gpio3c_iomux_h;
> >> +   unsigned int gpio3d_iomux_l;
> >> +   unsigned int gpio3d_iomux_h;
> >> +   unsigned int gpio4a_iomux_l;
> >> +   unsigned int gpio4a_iomux_h;
> >> +   unsigned int gpio4b_iomux_l;
> >> +   unsigned int gpio4b_iomux_h;
> >> +   unsigned int gpio4c_iomux_l;
> >> +   unsigned int gpio4c_iomux_h;
> >> +   unsigned int gpio4d_iomux_l;
> >> +   unsigned int reserved0[(0x0080 - 0x0078) / 4 - 1];
> >> +   unsigned int gpio1a_p;
> >> +   unsigned int gpio1b_p;
> >> +   unsigned int gpio1c_p;
>

[PATCH 1/1] net: sun8i-emac: fix MDIO frequency

Commit 4f0278dac56a ("net: sun8i-emac: Lower MDIO frequency") leads to
network failure on the OrangePi PC.

=> dhcp
sun8i_emac_eth_start: Timeout

According to the commit message the change of the MDIO frequency is only
required for external PHYs.

Fixes: 4f0278dac56a ("net: sun8i-emac: Lower MDIO frequency")
Signed-off-by: Heinrich Schuchardt 
---
 drivers/net/sun8i_emac.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 5a1b38bf80..d7553fe163 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int addr, 
int devad, int reg)
 * The EMAC clock is either 200 or 300 MHz, so we need a divider
 * of 128 to get the MDIO frequency below the required 2.5 MHz.
 */
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 << MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

mii_cmd |= MDIO_CMD_MII_BUSY;

@@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int addr, 
int devad, int reg,
 * The EMAC clock is either 200 or 300 MHz, so we need a divider
 * of 128 to get the MDIO frequency below the required 2.5 MHz.
 */
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 << MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

mii_cmd |= MDIO_CMD_MII_WRITE;
mii_cmd |= MDIO_CMD_MII_BUSY;
--
2.31.0

[PATCH] gpio: pca953x: Add missing i2c dependency

pca953x also depends on i2c that's why add dependency to Kconfig.
Where GPIO is enabled but I2C compilation error pops up.

Signed-off-by: Michal Simek 
---

 drivers/gpio/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d24884739bf2..de4dc51d4b48 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -396,7 +396,7 @@ config DM_74X164
 
 config DM_PCA953X
bool "PCA95[357]x, PCA9698, TCA64xx, and MAX7310 I/O ports"
-   depends on DM_GPIO
+   depends on DM_GPIO && DM_I2C
help
  Say yes here to provide access to several register-oriented
  SMBus I/O expanders, made mostly by NXP or TI.  Compatible
-- 
2.31.1

Re: [BUG] network is broken on Orange Pi PC


On 6/2/21 3:08 PM, Ramon Fried wrote:

On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt  wrote:


Dear all,

network is broken in U-Boot on orangepi_pc_defconfig:

U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +)
Allwinner Technology
eth0: ethernet@1c3
=> dhcp
sun8i_emac_eth_start: Timeout

Best regards

Heinrich


Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it broke ?
Thanks.
Ramon.



Git bisect points to:

commit 4f0278dac56a658ef1e0967fec0bb95372a875bd
Author: Andre Przywara 
Date:   Mon Jul 6 01:40:45 2020 +0100

net: sun8i-emac: Lower MDIO frequency

Reverting the patch solves the problem for the OrangePi PC.

According to the commit message the change was only needed for needed
for external PHYs. Can't we let the change depend on priv->use_internal_phy?

diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 5a1b38bf80..d7553fe163 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int
addr, int devad, int reg)
 * The EMAC clock is either 200 or 300 MHz, so we need a divider
 * of 128 to get the MDIO frequency below the required 2.5 MHz.
 */
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

mii_cmd |= MDIO_CMD_MII_BUSY;

@@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int
addr, int devad, int reg,
 * The EMAC clock is either 200 or 300 MHz, so we need a divider
 * of 128 to get the MDIO frequency below the required 2.5 MHz.
 */
-   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
MDIO_CMD_MII_CLK_CSR_SHIFT;
+   if (!priv->use_internal_phy)
+   mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 <<
+  MDIO_CMD_MII_CLK_CSR_SHIFT;

mii_cmd |= MDIO_CMD_MII_WRITE;
mii_cmd |= MDIO_CMD_MII_BUSY;

Best regards

Heinrich

I would assume the problem hits all H3 boards.

Best regards

Heinrich

Re: [v3, 3/3] armv8: layerscape: drop CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33

2021-06-03 Thread Michael Walle

Am 3. Juni 2021 04:51:19 MESZ schrieb Yangbo Lu :
>Drop CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33.
>CONFIG_FSL_ESDHC_VS33_NOT_SUPPORT
>is used instead.
>
>Signed-off-by: Yangbo Lu 

Acked-by: Michael Walle  [for kontron-sl28]

Re: [PATCH v2 5/5] arm: dts: stm32mp157c-odyssey-som: enable SDMMC2 in SPL

2021-06-03 Thread Patrice CHOTARD

Hi Grzegorz

On 6/2/21 7:09 PM, Grzegorz Szymaszek wrote:
> Enable the SDMMC2 device tree node, as well as the pins it uses, in
> U-Boot SPL.
> 
> Signed-off-by: Grzegorz Szymaszek 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
> Changes for v2:
>- rebased on current master
>- added a short commit message body
> 
>  .../dts/stm32mp157c-odyssey-som-u-boot.dtsi   | 21 +++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> index 6be728846e..4ff848350d 100644
> --- a/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
> @@ -123,3 +123,24 @@
>   u-boot,dm-pre-reloc;
>   };
>  };
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_b4_pins_a {
> + u-boot,dm-spl;
> + pins1 {
> + u-boot,dm-spl;
> + };
> + pins2 {
> + u-boot,dm-spl;
> + };
> +};
> +
> +_d47_pins_d {
> + u-boot,dm-spl;
> + pins {
> + u-boot,dm-spl;
> + };
> +};
> 
Reviewed-by: Patrice Chotard 
Thanks
Patrice

Re: [PATCH v2 4/5] arm: dts: stm32mp157c-odyssey-som: enable the SDMMC2 eMMC HS DDR mode

2021-06-03 Thread Patrice CHOTARD

Hi Grzegorz

On 6/2/21 7:09 PM, Grzegorz Szymaszek wrote:
> Enable the SDMMC2 eMMC high-speed DDR mode as it is done in the
> corresponding Linux kernel device tree.
> 
> Signed-off-by: Grzegorz Szymaszek 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> ---
> Changes for v2:
>- rebased on current master
>- added a short commit message body
> 
>  arch/arm/dts/stm32mp157c-odyssey-som.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/dts/stm32mp157c-odyssey-som.dtsi 
> b/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
> index 583812f137..1510a5b364 100644
> --- a/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
> +++ b/arch/arm/dts/stm32mp157c-odyssey-som.dtsi
> @@ -274,6 +274,7 @@
>   bus-width = <8>;
>   vmmc-supply = <>;
>   vqmmc-supply = <>;
> + mmc-ddr-3_3v;
>   status = "okay";
>  };
>  
> 

Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH] efi: Restrict the simple file system protocol to support only FAT

2021-06-03 Thread Masami Hiramatsu

Hi Heinrich,

2021年6月3日(木) 15:14 Heinrich Schuchardt :
[..]
>
> If a volume or file is read only the UEFI spec requires to report this
> in EFI_FILE_PROTOCOL.GetInfo().

Yes.

>
> On partition level we have the following deficiencies in U-Boot:
>
> * we cannot (re-)mount a partition read-only
> * we cannot determine if a partition is read-only

Hmm, but I think the filesystem driver itself defined it in fstype_info.
Thus we can check it as below.
fsinfo = fs_get_info(fs_get_type());
if (fsinfo->write == fs_write_unsupported)
  // then set the volume readonly

BTW, it seems fsinfo->opendir and readdir are also required for
EFI_FILE_PROTOCOL, unless it, UEFI application can not follow the
directory tree. Hmm.

> * we can neither read nor write the volume label
> * we cannot determine the free space.
>
> The current implementation of the FAT driver does not support reading
> attributes and dates. I have started looking into what is needed in the
> FAT driver.
> https://github.com/xypron/u-boot-patches/blob/bfe483ed97978678b124f8fe579682aab6e3e9d8/patch-efi-next.sh#L91
> But it is not ready for submission.

Ah, that's great! I would like to test it.

Thank you,


-- 
Masami Hiramatsu

Re: [PATCH] efi: Restrict the simple file system protocol to support only FAT

2021-06-03 Thread Ilias Apalodimas

On Thu, Jun 03, 2021 at 03:36:38PM +0900, Masami Hiramatsu wrote:
> Hi Ilias,
> 
> 2021年6月3日(木) 15:25 Ilias Apalodimas :
> >
> > [...]
> > > >
> > > > At least Debian and Ubuntu do not allow /boot to be on a FAT file 
> > > > system. If we want to boot Linux via the EFI stub without GRUB, we need 
> > > > ext4 support exposed to the EFI sub-system. See Ilias' recent 
> > > > contributions for the EFI_LOAD_FILE2_PROTOCOL for initrd and efidebug. 
> > > > This came in handy for booting via EFI on RISC-V where the initrd= 
> > > > command line parameter is not supported by Linux.
> > >
> > > IMHO, such dependency is out of UEFI spec. That means Debian/Ubuntu
> > > doesn't follow the UEFI spec. (but as far as I know, those install ESP
> > > on the disk and install GRUB efi application for boot)
> > > And yes, EFI_LOAD_FILE2_PROTOCOL needs to load initrd from somewhere
> > > (I'm usually put it on the ESP). But, if the EFI_LOAD_FILE2_PROTOCOL
> > > *requires* to access ext4 partition, I think that is not supported by
> > > UEFI spec.
> >
> > One of the advantages in using EFI_LOAD_FILE2_PROTOCOL is that you can load
> > it from *any* file system the firmware has access to. The only thing the
> > kernel does is provide a buffer big enough to fit in the initrd.  The
> > firmware is free to locate the file and copy it in that memory however it
> > sees fit.
> 
> Ah, I got it. Yes, EFI_LOAD_FILE2_PROTOCOL doesn't depend on the
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. Thus it should be able to load
> the file from where the U-Boot can access. However, since current 
> implementation
> depends on the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, my patch limits
> the ability...
> 

Yea that changed recently. On the first version, I was using u-boot
internal functions to locate and load the file.  When we decided to store a
device path on Boot options, in order to locate the initrd, we started
using the EFI APIs to load it. You can check commit 53f6a5aa8626 for more
details.

Cheers
/Ilias
> Thank you,
> 
> >
> > Cheers
> > /Ilias
> > >
> > > Anyway, I agree that denying access to non-FAT partitions is too
> > > restricted. What about my other ideas? If the volume is set to
> > > ReadOnly, that is good for both of the SCT and the
> > > EFI_LOAD_FILE2_PROTOCOL.
> > >
> > >
> > > Thank you,
> > >
> > > >
> > > > Best regards
> > > >
> > > > Heinrich
> > > >
> > > >
> 
> 
> 
> -- 
> Masami Hiramatsu

Re: [PATCH] efi: Restrict the simple file system protocol to support only FAT

2021-06-03 Thread Masami Hiramatsu

Hi Ilias,

2021年6月3日(木) 15:25 Ilias Apalodimas :
>
> [...]
> > >
> > > At least Debian and Ubuntu do not allow /boot to be on a FAT file system. 
> > > If we want to boot Linux via the EFI stub without GRUB, we need ext4 
> > > support exposed to the EFI sub-system. See Ilias' recent contributions 
> > > for the EFI_LOAD_FILE2_PROTOCOL for initrd and efidebug. This came in 
> > > handy for booting via EFI on RISC-V where the initrd= command line 
> > > parameter is not supported by Linux.
> >
> > IMHO, such dependency is out of UEFI spec. That means Debian/Ubuntu
> > doesn't follow the UEFI spec. (but as far as I know, those install ESP
> > on the disk and install GRUB efi application for boot)
> > And yes, EFI_LOAD_FILE2_PROTOCOL needs to load initrd from somewhere
> > (I'm usually put it on the ESP). But, if the EFI_LOAD_FILE2_PROTOCOL
> > *requires* to access ext4 partition, I think that is not supported by
> > UEFI spec.
>
> One of the advantages in using EFI_LOAD_FILE2_PROTOCOL is that you can load
> it from *any* file system the firmware has access to. The only thing the
> kernel does is provide a buffer big enough to fit in the initrd.  The
> firmware is free to locate the file and copy it in that memory however it
> sees fit.

Ah, I got it. Yes, EFI_LOAD_FILE2_PROTOCOL doesn't depend on the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. Thus it should be able to load
the file from where the U-Boot can access. However, since current implementation
depends on the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, my patch limits
the ability...

Thank you,

>
> Cheers
> /Ilias
> >
> > Anyway, I agree that denying access to non-FAT partitions is too
> > restricted. What about my other ideas? If the volume is set to
> > ReadOnly, that is good for both of the SCT and the
> > EFI_LOAD_FILE2_PROTOCOL.
> >
> >
> > Thank you,
> >
> > >
> > > Best regards
> > >
> > > Heinrich
> > >
> > >



-- 
Masami Hiramatsu

[PATCHv5 17/26] arm: mach-k3: Add platform data for j721e and j7200

From: Dave Gerlach 

Add platform clock and powerdomain data for J721e and J7200. This data
is used by the corresponding drivers to register all the required device
clocks and powerdomains.

Signed-off-by: Dave Gerlach 
Signed-off-by: Tero Kristo 
---
 arch/arm/mach-k3/Makefile |   2 +-
 arch/arm/mach-k3/j7200/Makefile   |   5 +
 arch/arm/mach-k3/j7200/clk-data.c | 547 +
 arch/arm/mach-k3/j7200/dev-data.c |  77 +++
 arch/arm/mach-k3/j721e/Makefile   |   5 +
 arch/arm/mach-k3/j721e/clk-data.c | 781 ++
 arch/arm/mach-k3/j721e/dev-data.c |  75 +++
 7 files changed, 1491 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-k3/j7200/Makefile
 create mode 100644 arch/arm/mach-k3/j7200/clk-data.c
 create mode 100644 arch/arm/mach-k3/j7200/dev-data.c
 create mode 100644 arch/arm/mach-k3/j721e/Makefile
 create mode 100644 arch/arm/mach-k3/j721e/clk-data.c
 create mode 100644 arch/arm/mach-k3/j721e/dev-data.c

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 890d1498d0..47cf7b6d17 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -4,7 +4,7 @@
 #  Lokesh Vutla 
 
 obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
-obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o
+obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o j721e/ j7200/
 obj-$(CONFIG_SOC_K3_AM642) += am642_init.o
 obj-$(CONFIG_ARM64) += arm64-mmu.o
 obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
diff --git a/arch/arm/mach-k3/j7200/Makefile b/arch/arm/mach-k3/j7200/Makefile
new file mode 100644
index 00..ff9abd78ea
--- /dev/null
+++ b/arch/arm/mach-k3/j7200/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/
+obj-y += clk-data.o
+obj-y += dev-data.o
diff --git a/arch/arm/mach-k3/j7200/clk-data.c 
b/arch/arm/mach-k3/j7200/clk-data.c
new file mode 100644
index 00..93c067079a
--- /dev/null
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -0,0 +1,547 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * J7200 specific clock platform data
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - http://www.ti.com/
+ */
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+   "osc_19_2_mhz",
+   "osc_20_mhz",
+   "osc_24_mhz",
+   "osc_25_mhz",
+   "osc_26_mhz",
+   "osc_27_mhz",
+};
+
+static const char * const mcu_ospi0_iclk_sel_out0_parents[] = {
+   "board_0_mcu_ospi0_dqs_out",
+   "fss_mcu_0_ospi_0_ospi_oclk_clk",
+};
+
+static const char * const wkup_fref_clksel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "j7vc_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const main_pll_hfosc_sel_out1_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const k3_pll_ctrl_wrap_wkup_0_sysclkout_clk_parents[] = {
+   "wkup_fref_clksel_out0",
+   "hsdiv1_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const mcu_ospi_ref_clk_sel_out0_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout4_clk",
+   "hsdiv4_16fft_mcu_2_hsdivout4_clk",
+};
+
+static const char * const mcuusart_clk_sel_out0_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+   "postdiv2_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const wkup_gpio0_clksel_out0_parents[] = {
+   "k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
+   "k3_pll_ctrl_wrap_wkup_0_chip_div1_clk_clk",
+   "j7vc_wakeup_16ff_wkup_0_wkup_rcosc_32k_clk",
+   "j7vc_wakeup_16ff_wkup_0_wkup_rcosc_12p5m_clk",
+};
+
+static const char * const wkup_i2c0_mcupll_bypass_clksel_out0_parents[] = {
+   "hsdiv4_16fft_mcu_1_hsdivout3_clk",
+   "gluelogic_hfosc0_clkout",
+};
+
+static const char * const main_pll_hfosc_sel_out0_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out12_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out14_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out2_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out3_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out4_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out7_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const main_pll_hfosc_sel_out8_parents[] = {
+   "gluelogic_hfosc0_clkout",
+   "board_0_hfosc1_clk_out",
+};
+
+static const char * const usb0_refclk_sel_out0_parents[] = {
+

[PATCHv5 25/26] board: ti: j72xx: README: update build instructions and image formats

From: Tero Kristo 

Update build instructions and image formats based on HSM rearch. A new
DM image is added into the build, which gets executed right after R5
SPL finishes its job.

Signed-off-by: Tero Kristo 
Signed-off-by: Tero Kristo 
---
 board/ti/j721e/README | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/board/ti/j721e/README b/board/ti/j721e/README
index c33afa496e..b1c9145c92 100644
--- a/board/ti/j721e/README
+++ b/board/ti/j721e/README
@@ -73,12 +73,12 @@ support. Below is the pictorial representation of boot flow:
 || | |   +-+ |   | 
  |
 || |<|---| Start A72   | |   | 
  |
 || | |   | and jump to | |   | 
  |
-|| | |   | next image  | |   | 
  |
+|| | |   | DM fw image | |   | 
  |
 || | |   +-+ |   | 
  |
 || | |   | +---+ | 
  |
 || |-|---|>| Reset rls | | 
  |
 || | |   | +---+ | 
  |
-||  DMSC   | |   |  :| 
  |
+||  TIFS   | |   |  :| 
  |
 ||Services | |   | +---+ | 
  |
 || |<|---|>|*ATF/OPTEE*| | 
  |
 || | |   | +---+ | 
  |
@@ -154,7 +154,7 @@ $ make CROSS_COMPILE=arm-linux-gnueabihf- O=/tmp/r5
 
 4.2. A72:
 $ make CROSS_COMPILE=aarch64-linux-gnu- j721e_evm_a72_defconfig O=/tmp/a72
-$ make CROSS_COMPILE=aarch64-linux-gnu- ATF=/build/k3/generic/release/bl31.bin TEE=/out/arm-plat-k3/core/tee-pager_v2.bin O=/tmp/a72
+$ make CROSS_COMPILE=aarch64-linux-gnu- ATF=/build/k3/generic/release/bl31.bin TEE=/out/arm-plat-k3/core/tee-pager_v2.bin DM= 
O=/tmp/a72
 
 Target Images
 --
@@ -197,6 +197,9 @@ Image formats:
 | | A72 OPTEE | |
 | +---+ |
 | |   | |
+| |  R5 DM FW | |
+| +---+ |
+| |   | |
 | |  A72 SPL  | |
 | +---+ |
 | |   | |
-- 
2.17.1

[PATCHv5 26/26] arm: dts: k3-j72xx: correct MCU timer1 frequency

MCU timer1 is used as the tick timer for MCU R5 SPL, and the
clock-frequency defined in DT appears to be incorrect at the moment.
Actual clock source for the timer is MCU_SYSCLK0 / 4 which is 250MHz.

Earlier setup of 25MHz went unnoticed, as there was a separate issue
with omap-timer, which caused an error to the clock by a factor of 8
with j7 devices. This problem surfaced once the omap-timer was fixed.

Signed-off-by: Tero Kristo 
---
 arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 2 +-
 arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index bd037be350..c3aae65b39 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -33,7 +33,7 @@
compatible = "ti,omap5430-timer";
reg = <0x0 0x4040 0x0 0x80>;
ti,timer-alwon;
-   clock-frequency = <2500>;
+   clock-frequency = <25000>;
u-boot,dm-spl;
};
 
diff --git a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi 
b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
index fe095a6153..951331831e 100644
--- a/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-common-proc-board-u-boot.dtsi
@@ -46,7 +46,7 @@
compatible = "ti,omap5430-timer";
reg = <0x0 0x4040 0x0 0x80>;
ti,timer-alwon;
-   clock-frequency = <2500>;
+   clock-frequency = <25000>;
u-boot,dm-spl;
};
 
-- 
2.17.1

[PATCHv5 24/26] configs: j7200_evm_r5: Enable raw access power management features

From: Dave Gerlach 

Sysfw is not going to provide access to power management features in the
new architecture, so SPL must implement these itself. Enable all the raw
register access based clock + power domain drivers.

Signed-off-by: Dave Gerlach 
Signed-off-by: Tero Kristo 
---
 configs/j7200_evm_r5_defconfig | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig
index 08fad3e04b..5c51bd5ae7 100644
--- a/configs/j7200_evm_r5_defconfig
+++ b/configs/j7200_evm_r5_defconfig
@@ -75,7 +75,7 @@ CONFIG_SPL_SYSCON=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
-CONFIG_CLK_TI_SCI=y
+# CONFIG_CLK_TI_SCI is not set
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
@@ -110,7 +110,7 @@ CONFIG_SPL_PINCTRL=y
 # CONFIG_SPL_PINCTRL_GENERIC is not set
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
-CONFIG_TI_SCI_POWER_DOMAIN=y
+# CONFIG_TI_SCI_POWER_DOMAIN is not set
 CONFIG_K3_SYSTEM_CONTROLLER=y
 CONFIG_REMOTEPROC_TI_K3_ARM64=y
 CONFIG_DM_RESET=y
@@ -142,3 +142,13 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6164
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_FS_EXT4=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_TI_POWER_DOMAIN=y
+CONFIG_SPL_CLK_CCF=y
+CONFIG_LIB_RATIONAL=y
+CONFIG_SPL_LIB_RATIONAL=y
+CONFIG_SPL_CLK_K3_PLL=y
+CONFIG_SPL_CLK_K3=y
+CONFIG_K3_DM_FW=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
-- 
2.17.1

[PATCHv5 22/26] arm: mach-k3: j721e_init: Force early probe of clk-k3 driver

From: Dave Gerlach 

Force the clk-k3 driver to probe early during R5 SPL boot to ensure the
default system clock configuration is completed. Many other drivers
assume a default state of the clock tree and it is currently possible
for them to probe before clk-k3 depending on the exact system
configuration.

Signed-off-by: Dave Gerlach 
Reported-by: Keerthy 
Tested-by: Keerthy 
Signed-off-by: Tero Kristo 
---
 arch/arm/mach-k3/j721e_init.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index 76a04a9035..833568d4b8 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -180,6 +180,18 @@ void board_init_f(ulong dummy)
k3_sysfw_loader(is_rom_loaded_sysfw(),
k3_mmc_stop_clock, k3_mmc_restart_clock);
 
+#ifdef CONFIG_SPL_CLK_K3
+   /*
+* Force probe of clk_k3 driver here to ensure basic default clock
+* configuration is always done.
+*/
+   ret = uclass_get_device_by_driver(UCLASS_CLK,
+ DM_DRIVER_GET(ti_clk),
+ );
+   if (ret)
+   panic("Failed to initialize clk-k3!\n");
+#endif
+
/* Prepare console output */
preloader_console_init();
 
-- 
2.17.1

[PATCHv5 23/26] configs: j721e_evm_r5: Enable raw access power management features

From: Tero Kristo 

Sysfw is not going to provide access to power management features in the
new architecture, so SPL must implement these itself. Enable all the raw
register access based clock + power domain drivers.

Signed-off-by: Tero Kristo 
Signed-off-by: Tero Kristo 
---
 configs/j721e_evm_r5_defconfig | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index 8ebbe7348f..8a9b20141b 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -72,7 +72,7 @@ CONFIG_SPL_REGMAP=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
-CONFIG_CLK_TI_SCI=y
+# CONFIG_CLK_TI_SCI is not set
 CONFIG_DMA_CHANNELS=y
 CONFIG_TI_K3_NAVSS_UDMA=y
 CONFIG_TI_SCI_PROTOCOL=y
@@ -102,7 +102,7 @@ CONFIG_SPL_PINCTRL=y
 # CONFIG_SPL_PINCTRL_GENERIC is not set
 CONFIG_PINCTRL_SINGLE=y
 CONFIG_POWER_DOMAIN=y
-CONFIG_TI_SCI_POWER_DOMAIN=y
+# CONFIG_TI_SCI_POWER_DOMAIN is not set
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_TPS65941=y
 CONFIG_DM_REGULATOR=y
@@ -140,3 +140,11 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0x6163
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_FS_EXT4=y
 CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_TI_POWER_DOMAIN=y
+CONFIG_SPL_CLK_CCF=y
+CONFIG_LIB_RATIONAL=y
+CONFIG_SPL_LIB_RATIONAL=y
+CONFIG_SPL_CLK_K3_PLL=y
+CONFIG_SPL_CLK_K3=y
+CONFIG_K3_DM_FW=y
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
-- 
2.17.1

[PATCHv5 21/26] arm: mach-k3: sysfw-loader: pass boardcfg to sciserver

From: Tero Kristo 

Copy the contents of the board config loaded from sysfw.itb into an
EXTBOOT shared memory buffer that gets passed to sciserver. This only
needs to be done if EXTBOOT area has not been populated by ROM code yet.

Signed-off-by: Tero Kristo 
Signed-off-by: Tero Kristo 
---
 arch/arm/mach-k3/sysfw-loader.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/arch/arm/mach-k3/sysfw-loader.c b/arch/arm/mach-k3/sysfw-loader.c
index c6af205163..ac719cd46f 100644
--- a/arch/arm/mach-k3/sysfw-loader.c
+++ b/arch/arm/mach-k3/sysfw-loader.c
@@ -40,6 +40,46 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 #define K3_SYSTEM_CONTROLLER_RPROC_ID  0
 
+#define COMMON_HEADER_ADDRESS  0x41cffb00
+#define BOARDCFG_ADDRESS   0x41c8
+
+#define COMP_TYPE_SBL_DATA 0x11
+#define DESC_TYPE_BOARDCFG_PM_INDEX0x2
+#define DESC_TYPE_BOARDCFG_RM_INDEX0x3
+
+#define BOARD_CONFIG_RM_DESC_TYPE  0x000c
+#define BOARD_CONFIG_PM_DESC_TYPE  0x000e
+
+struct extboot_comp {
+   u32 comp_type;
+   u32 boot_core;
+   u32 comp_opts;
+   u64 dest_addr;
+   u32 comp_size;
+};
+
+struct extboot_header {
+   u8 magic[8];
+   u32 num_comps;
+   struct extboot_comp comps[5];
+   u32 reserved;
+};
+
+struct bcfg_desc {
+   u16 type;
+   u16 offset;
+   u16 size;
+   u8 devgrp;
+   u8 reserved;
+} __packed;
+
+struct bcfg_header {
+   u8 num_elems;
+   u8 sw_rev;
+   struct bcfg_desc descs[4];
+   u16 reserved;
+} __packed;
+
 static bool sysfw_loaded;
 static void *sysfw_load_address;
 
@@ -131,6 +171,15 @@ static void k3_sysfw_configure_using_fit(void *fit,
const void *cfg_fragment_addr;
size_t cfg_fragment_size;
int ret;
+#ifdef CONFIG_K3_DM_FW
+   u8 *buf;
+   struct extboot_header *common_header;
+   struct bcfg_header *bcfg_header;
+   struct extboot_comp *comp;
+   struct bcfg_desc *desc;
+   u32 addr;
+   bool copy_bcfg = false;
+#endif
 
/* Find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
@@ -165,6 +214,46 @@ static void k3_sysfw_configure_using_fit(void *fit,
 (u32)cfg_fragment_size);
if (ret)
panic("Failed to set board PM configuration (%d)\n", ret);
+#else
+   /* Initialize shared memory boardconfig buffer */
+   buf = (u8 *)COMMON_HEADER_ADDRESS;
+   common_header = (struct extboot_header *)buf;
+
+   /* Check if we have a struct populated by ROM in memory already */
+   if (strcmp((char *)common_header->magic, "EXTBOOT"))
+   copy_bcfg = true;
+
+   if (copy_bcfg) {
+   strcpy((char *)common_header->magic, "EXTBOOT");
+   common_header->num_comps = 1;
+
+   comp = _header->comps[0];
+
+   comp->comp_type = COMP_TYPE_SBL_DATA;
+   comp->boot_core = 0x10;
+   comp->comp_opts = 0;
+   addr = (u32)BOARDCFG_ADDRESS;
+   comp->dest_addr = addr;
+   comp->comp_size = sizeof(*bcfg_header);
+
+   bcfg_header = (struct bcfg_header *)addr;
+
+   bcfg_header->num_elems = 2;
+   bcfg_header->sw_rev = 0;
+
+   desc = _header->descs[0];
+
+   desc->type = BOARD_CONFIG_PM_DESC_TYPE;
+   desc->offset = sizeof(*bcfg_header);
+   desc->size = cfg_fragment_size;
+   comp->comp_size += desc->size;
+   desc->devgrp = 0;
+   desc->reserved = 0;
+   memcpy((u8 *)bcfg_header + desc->offset, cfg_fragment_addr,
+  cfg_fragment_size);
+
+   bcfg_header->descs[1].offset = desc->offset + desc->size;
+   }
 #endif
 
/* Extract resource management (RM) specific configuration from FIT */
@@ -174,6 +263,20 @@ static void k3_sysfw_configure_using_fit(void *fit,
panic("Error accessing %s node in FIT (%d)\n", SYSFW_CFG_RM,
  ret);
 
+#ifdef CONFIG_K3_DM_FW
+   if (copy_bcfg) {
+   desc = _header->descs[1];
+
+   desc->type = BOARD_CONFIG_RM_DESC_TYPE;
+   desc->size = cfg_fragment_size;
+   comp->comp_size += desc->size;
+   desc->devgrp = 0;
+   desc->reserved = 0;
+   memcpy((u8 *)bcfg_header + desc->offset, cfg_fragment_addr,
+  cfg_fragment_size);
+   }
+#endif
+
/* Apply resource management (RM) configuration to SYSFW */
ret = board_ops->board_config_rm(ti_sci,
 (u64)(u32)cfg_fragment_addr,
-- 
2.17.1

[PATCHv5 19/26] arm: mach-k3: do board config for PM only if supported