All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-10 19:52 ` nick.hawkins
  0 siblings, 0 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

The GXP is the HPE BMC SoC that is used in the majority
of HPE Generation 10 servers. Traditionally the asic will
last multiple generations of server before being replaced.
In gxp.c we reset the EHCI controller early to boot the asic.

Info about SoC:

HPE GXP is the name of the HPE Soc. This SoC is used to implement
many BMC features at HPE. It supports ARMv7 architecture based on
the Cortex A9 core. It is capable of using an AXI bus to which
a memory controller is attached. It has multiple SPI interfaces
to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC
for network connectivity. It has multiple i2c engines to drive
connectivity with a host infrastructure. The initial patches
enable the watchdog and timer enabling the host to be able to
boot.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 arch/arm/Kconfig           |  2 ++
 arch/arm/Makefile          |  1 +
 arch/arm/mach-hpe/Kconfig  | 20 +++++++++++++
 arch/arm/mach-hpe/Makefile |  1 +
 arch/arm/mach-hpe/gxp.c    | 61 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 85 insertions(+)
 create mode 100644 arch/arm/mach-hpe/Kconfig
 create mode 100644 arch/arm/mach-hpe/Makefile
 create mode 100644 arch/arm/mach-hpe/gxp.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c97cb40eebb..6998b5b5f59e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -618,6 +618,8 @@ source "arch/arm/mach-highbank/Kconfig"
 
 source "arch/arm/mach-hisi/Kconfig"
 
+source "arch/arm/mach-hpe/Kconfig"
+
 source "arch/arm/mach-imx/Kconfig"
 
 source "arch/arm/mach-integrator/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 77172d555c7e..1cc0523d0a0a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -178,6 +178,7 @@ machine-$(CONFIG_ARCH_FOOTBRIDGE)	+= footbridge
 machine-$(CONFIG_ARCH_GEMINI)		+= gemini
 machine-$(CONFIG_ARCH_HIGHBANK)		+= highbank
 machine-$(CONFIG_ARCH_HISI)		+= hisi
+machine-$(CONFIG_ARCH_HPE)		+= hpe
 machine-$(CONFIG_ARCH_INTEGRATOR)	+= integrator
 machine-$(CONFIG_ARCH_IOP32X)		+= iop32x
 machine-$(CONFIG_ARCH_IXP4XX)		+= ixp4xx
diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
new file mode 100644
index 000000000000..9b27f97c6536
--- /dev/null
+++ b/arch/arm/mach-hpe/Kconfig
@@ -0,0 +1,20 @@
+menuconfig ARCH_HPE
+	bool "HPE SoC support"
+	help
+	  This enables support for HPE ARM based SoC chips
+if ARCH_HPE
+
+config ARCH_HPE_GXP
+	bool "HPE GXP SoC"
+	select ARM_VIC
+	select PINCTRL
+	select IRQ_DOMAIN
+	select GENERIC_IRQ_CHIP
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+	select CLKSRC_MMIO
+	depends on ARCH_MULTI_V7
+	help
+	  Support for GXP SoCs
+
+endif
diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
new file mode 100644
index 000000000000..8b0a91234df4
--- /dev/null
+++ b/arch/arm/mach-hpe/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_HPE_GXP) += gxp.o
diff --git a/arch/arm/mach-hpe/gxp.c b/arch/arm/mach-hpe/gxp.c
new file mode 100644
index 000000000000..44f6d719a346
--- /dev/null
+++ b/arch/arm/mach-hpe/gxp.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.*/
+
+
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#define IOP_REGS_PHYS_BASE 0xc0000000
+#define IOP_REGS_VIRT_BASE 0xf0000000
+#define IOP_REGS_SIZE (240*SZ_1M)
+#define RESET_CMD 0x00080002
+
+static struct map_desc gxp_io_desc[] __initdata = {
+	{
+		.virtual	= (unsigned long)IOP_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(IOP_REGS_PHYS_BASE),
+		.length		= IOP_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+void __init gxp_map_io(void)
+{
+	iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
+}
+
+static void __init gxp_dt_init(void)
+{
+	void __iomem *gxp_init_regs;
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "hpe,gxp-cpu-init");
+	gxp_init_regs = of_iomap(np, 0);
+
+	/*it is necessary for our SOC to reset ECHI through this*/
+	/* register due to a hardware limitation*/
+	__raw_writel(RESET_CMD,
+		(gxp_init_regs));
+
+}
+
+static void gxp_restart(enum reboot_mode mode, const char *cmd)
+{
+	__raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
+}
+
+static const char * const gxp_board_dt_compat[] = {
+	"hpe,gxp",
+	NULL,
+};
+
+DT_MACHINE_START(GXP_DT, "HPE GXP")
+	.init_machine	= gxp_dt_init,
+	.map_io		= gxp_map_io,
+	.restart	= gxp_restart,
+	.dt_compat	= gxp_board_dt_compat,
+MACHINE_END
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-10 19:52 ` nick.hawkins
  0 siblings, 0 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

The GXP is the HPE BMC SoC that is used in the majority
of HPE Generation 10 servers. Traditionally the asic will
last multiple generations of server before being replaced.
In gxp.c we reset the EHCI controller early to boot the asic.

Info about SoC:

HPE GXP is the name of the HPE Soc. This SoC is used to implement
many BMC features at HPE. It supports ARMv7 architecture based on
the Cortex A9 core. It is capable of using an AXI bus to which
a memory controller is attached. It has multiple SPI interfaces
to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC
for network connectivity. It has multiple i2c engines to drive
connectivity with a host infrastructure. The initial patches
enable the watchdog and timer enabling the host to be able to
boot.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 arch/arm/Kconfig           |  2 ++
 arch/arm/Makefile          |  1 +
 arch/arm/mach-hpe/Kconfig  | 20 +++++++++++++
 arch/arm/mach-hpe/Makefile |  1 +
 arch/arm/mach-hpe/gxp.c    | 61 ++++++++++++++++++++++++++++++++++++++
 5 files changed, 85 insertions(+)
 create mode 100644 arch/arm/mach-hpe/Kconfig
 create mode 100644 arch/arm/mach-hpe/Makefile
 create mode 100644 arch/arm/mach-hpe/gxp.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c97cb40eebb..6998b5b5f59e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -618,6 +618,8 @@ source "arch/arm/mach-highbank/Kconfig"
 
 source "arch/arm/mach-hisi/Kconfig"
 
+source "arch/arm/mach-hpe/Kconfig"
+
 source "arch/arm/mach-imx/Kconfig"
 
 source "arch/arm/mach-integrator/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 77172d555c7e..1cc0523d0a0a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -178,6 +178,7 @@ machine-$(CONFIG_ARCH_FOOTBRIDGE)	+= footbridge
 machine-$(CONFIG_ARCH_GEMINI)		+= gemini
 machine-$(CONFIG_ARCH_HIGHBANK)		+= highbank
 machine-$(CONFIG_ARCH_HISI)		+= hisi
+machine-$(CONFIG_ARCH_HPE)		+= hpe
 machine-$(CONFIG_ARCH_INTEGRATOR)	+= integrator
 machine-$(CONFIG_ARCH_IOP32X)		+= iop32x
 machine-$(CONFIG_ARCH_IXP4XX)		+= ixp4xx
diff --git a/arch/arm/mach-hpe/Kconfig b/arch/arm/mach-hpe/Kconfig
new file mode 100644
index 000000000000..9b27f97c6536
--- /dev/null
+++ b/arch/arm/mach-hpe/Kconfig
@@ -0,0 +1,20 @@
+menuconfig ARCH_HPE
+	bool "HPE SoC support"
+	help
+	  This enables support for HPE ARM based SoC chips
+if ARCH_HPE
+
+config ARCH_HPE_GXP
+	bool "HPE GXP SoC"
+	select ARM_VIC
+	select PINCTRL
+	select IRQ_DOMAIN
+	select GENERIC_IRQ_CHIP
+	select MULTI_IRQ_HANDLER
+	select SPARSE_IRQ
+	select CLKSRC_MMIO
+	depends on ARCH_MULTI_V7
+	help
+	  Support for GXP SoCs
+
+endif
diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
new file mode 100644
index 000000000000..8b0a91234df4
--- /dev/null
+++ b/arch/arm/mach-hpe/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ARCH_HPE_GXP) += gxp.o
diff --git a/arch/arm/mach-hpe/gxp.c b/arch/arm/mach-hpe/gxp.c
new file mode 100644
index 000000000000..44f6d719a346
--- /dev/null
+++ b/arch/arm/mach-hpe/gxp.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.*/
+
+
+#include <linux/init.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+
+#define IOP_REGS_PHYS_BASE 0xc0000000
+#define IOP_REGS_VIRT_BASE 0xf0000000
+#define IOP_REGS_SIZE (240*SZ_1M)
+#define RESET_CMD 0x00080002
+
+static struct map_desc gxp_io_desc[] __initdata = {
+	{
+		.virtual	= (unsigned long)IOP_REGS_VIRT_BASE,
+		.pfn		= __phys_to_pfn(IOP_REGS_PHYS_BASE),
+		.length		= IOP_REGS_SIZE,
+		.type		= MT_DEVICE,
+	},
+};
+
+void __init gxp_map_io(void)
+{
+	iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
+}
+
+static void __init gxp_dt_init(void)
+{
+	void __iomem *gxp_init_regs;
+	struct device_node *np;
+
+	np = of_find_compatible_node(NULL, NULL, "hpe,gxp-cpu-init");
+	gxp_init_regs = of_iomap(np, 0);
+
+	/*it is necessary for our SOC to reset ECHI through this*/
+	/* register due to a hardware limitation*/
+	__raw_writel(RESET_CMD,
+		(gxp_init_regs));
+
+}
+
+static void gxp_restart(enum reboot_mode mode, const char *cmd)
+{
+	__raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
+}
+
+static const char * const gxp_board_dt_compat[] = {
+	"hpe,gxp",
+	NULL,
+};
+
+DT_MACHINE_START(GXP_DT, "HPE GXP")
+	.init_machine	= gxp_dt_init,
+	.map_io		= gxp_map_io,
+	.restart	= gxp_restart,
+	.dt_compat	= gxp_board_dt_compat,
+MACHINE_END
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 02/10] arch: arm: configs: multi_v7_defconfig
  2022-03-10 19:52 ` nick.hawkins
@ 2022-03-10 19:52   ` nick.hawkins
  -1 siblings, 0 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

Add support for the HPE GXP Processor by modifing the
multi_v7_defconfig instead. This adds basic HPE and GXP
architecture as well as enables the watchdog which is part
of this patch set.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8863fa969ede..b93d213b7e60 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1006,6 +1006,8 @@ CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_SMD_RPM=m
 CONFIG_QCOM_WCNSS_CTRL=m
 CONFIG_ARCH_EMEV2=y
+CONFIG_ARCH_HPE=y
+CONFIG_ARCH_HPE_GXP=y
 CONFIG_ARCH_R8A7794=y
 CONFIG_ARCH_R8A7779=y
 CONFIG_ARCH_R8A7790=y
@@ -1169,3 +1171,4 @@ CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
+CONFIG_GXP_WATCHDOG=y
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 02/10] arch: arm: configs: multi_v7_defconfig
@ 2022-03-10 19:52   ` nick.hawkins
  0 siblings, 0 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

Add support for the HPE GXP Processor by modifing the
multi_v7_defconfig instead. This adds basic HPE and GXP
architecture as well as enables the watchdog which is part
of this patch set.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 arch/arm/configs/multi_v7_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8863fa969ede..b93d213b7e60 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1006,6 +1006,8 @@ CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_SMD_RPM=m
 CONFIG_QCOM_WCNSS_CTRL=m
 CONFIG_ARCH_EMEV2=y
+CONFIG_ARCH_HPE=y
+CONFIG_ARCH_HPE_GXP=y
 CONFIG_ARCH_R8A7794=y
 CONFIG_ARCH_R8A7779=y
 CONFIG_ARCH_R8A7790=y
@@ -1169,3 +1171,4 @@ CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_PRINTK_TIME=y
 CONFIG_MAGIC_SYSRQ=y
 CONFIG_DEBUG_FS=y
+CONFIG_GXP_WATCHDOG=y
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog
  2022-03-10 19:52 ` nick.hawkins
  (?)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-04-04 14:28   ` Guenter Roeck
  -1 siblings, 1 reply; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun
  Cc: Nick Hawkins, Wim Van Sebroeck, Guenter Roeck, linux-kernel,
	linux-watchdog

From: Nick Hawkins <nick.hawkins@hpe.com>

Adding support for the HPE GXP Watchdog. It is new to the linux
community and this along with several other patches is the first
support for it. The GXP asic contains a full compliment of
timers one of which is the watchdog timer. The watchdog timer
is 16 bit and has 10ms resolution.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 drivers/watchdog/Kconfig   |   8 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/gxp-wdt.c | 191 +++++++++++++++++++++++++++++++++++++
 3 files changed, 200 insertions(+)
 create mode 100644 drivers/watchdog/gxp-wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c8fa79da23b3..cb210d2978d2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1820,6 +1820,14 @@ config RALINK_WDT
 	help
 	  Hardware driver for the Ralink SoC Watchdog Timer.
 
+config GXP_WATCHDOG
+	tristate "HPE GXP watchdog support"
+	depends on ARCH_HPE_GXP
+	select WATCHDOG_CORE
+	help
+	  Say Y here to include support for the watchdog timer
+	  in HPE GXP SoCs.
+
 config MT7621_WDT
 	tristate "Mediatek SoC watchdog"
 	select WATCHDOG_CORE
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index f7da867e8782..e2acf3a0d0fc 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
 obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
 obj-$(CONFIG_PM8916_WATCHDOG) += pm8916_wdt.o
 obj-$(CONFIG_ARM_SMC_WATCHDOG) += arm_smc_wdt.o
+obj-$(CONFIG_GXP_WATCHDOG) += gxp-wdt.o
 obj-$(CONFIG_VISCONTI_WATCHDOG) += visconti_wdt.o
 obj-$(CONFIG_MSC313E_WATCHDOG) += msc313e_wdt.o
 obj-$(CONFIG_APPLE_WATCHDOG) += apple_wdt.o
diff --git a/drivers/watchdog/gxp-wdt.c b/drivers/watchdog/gxp-wdt.c
new file mode 100644
index 000000000000..d2b489cb4774
--- /dev/null
+++ b/drivers/watchdog/gxp-wdt.c
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/types.h>
+#include <linux/watchdog.h>
+
+#define MASK_WDGCS_ENABLE	0x01
+#define MASK_WDGCS_RELOAD	0x04
+#define MASK_WDGCS_NMIEN	0x08
+#define MASK_WDGCS_WARN		0x80
+
+#define WDT_MAX_TIMEOUT_MS	655000
+#define WDT_DEFAULT_TIMEOUT	30
+#define SECS_TO_WDOG_TICKS(x) ((x) * 100)
+#define WDOG_TICKS_TO_SECS(x) ((x) / 100)
+
+struct gxp_wdt {
+	void __iomem	*counter;
+	void __iomem	*control;
+	struct watchdog_device	wdd;
+};
+
+static void gxp_wdt_enable_reload(struct gxp_wdt *drvdata)
+{
+	uint8_t val;
+
+	val = readb(drvdata->control);
+	val |= (MASK_WDGCS_ENABLE | MASK_WDGCS_RELOAD);
+	writeb(val, drvdata->control);
+}
+
+static int gxp_wdt_start(struct watchdog_device *wdd)
+{
+	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
+
+	writew((SECS_TO_WDOG_TICKS(wdd->timeout)), drvdata->counter);
+	gxp_wdt_enable_reload(drvdata);
+	return 0;
+}
+
+static int gxp_wdt_stop(struct watchdog_device *wdd)
+{
+	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
+	uint8_t val;
+
+	val = readb_relaxed(drvdata->control);
+	val &= ~MASK_WDGCS_ENABLE;
+	writeb(val, drvdata->control);
+	return 0;
+}
+
+static int gxp_wdt_set_timeout(struct watchdog_device *wdd,
+			       unsigned int timeout)
+{
+	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
+	uint32_t actual;
+
+	wdd->timeout = timeout;
+	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
+	writew((SECS_TO_WDOG_TICKS(actual)), drvdata->counter);
+
+	return 0;
+}
+
+static unsigned int gxp_wdt_get_timeleft(struct watchdog_device *wdd)
+{
+	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
+	uint32_t val = readw(drvdata->counter);
+
+	return WDOG_TICKS_TO_SECS(val);
+}
+
+static int gxp_wdt_ping(struct watchdog_device *wdd)
+{
+	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
+
+	gxp_wdt_enable_reload(drvdata);
+	return 0;
+}
+
+static int gxp_restart(struct watchdog_device *wdd, unsigned long action,
+		       void *data)
+{
+	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
+
+	writew(10, drvdata->counter);
+	gxp_wdt_enable_reload(drvdata);
+	mdelay(100);
+	return 0;
+}
+
+static const struct watchdog_ops gxp_wdt_ops = {
+	.owner =	THIS_MODULE,
+	.start =	gxp_wdt_start,
+	.stop =		gxp_wdt_stop,
+	.ping = gxp_wdt_ping,
+	.set_timeout	= gxp_wdt_set_timeout,
+	.get_timeleft =	gxp_wdt_get_timeleft,
+	.restart =	gxp_restart,
+};
+
+static const struct watchdog_info gxp_wdt_info = {
+	.options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
+	.identity = "HPE GXP Watchdog timer",
+};
+
+static int gxp_wdt_probe(struct platform_device *pdev)
+{
+	struct resource *res;
+	struct device *dev = &pdev->dev;
+	struct gxp_wdt *drvdata;
+	int err;
+	uint8_t val;
+
+	drvdata = devm_kzalloc(dev, sizeof(struct gxp_wdt), GFP_KERNEL);
+	if (!drvdata)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, drvdata);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	drvdata->counter = devm_ioremap_resource(dev, res);
+	if (IS_ERR(drvdata->counter))
+		return PTR_ERR(drvdata->counter);
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+	drvdata->control = devm_ioremap_resource(dev, res);
+	if (IS_ERR(drvdata->control))
+		return PTR_ERR(drvdata->control);
+
+	drvdata->wdd.info = &gxp_wdt_info;
+	drvdata->wdd.ops = &gxp_wdt_ops;
+	drvdata->wdd.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT_MS;
+	drvdata->wdd.parent = &pdev->dev;
+
+	watchdog_set_drvdata(&drvdata->wdd, drvdata);
+	watchdog_init_timeout(&drvdata->wdd, WDT_DEFAULT_TIMEOUT, dev);
+	watchdog_set_nowayout(&drvdata->wdd, WATCHDOG_NOWAYOUT);
+
+	val = readb(drvdata->control);
+	if (val & MASK_WDGCS_ENABLE)
+		set_bit(WDOG_HW_RUNNING, &drvdata->wdd.status);
+
+	watchdog_set_restart_priority(&drvdata->wdd, 128);
+
+	watchdog_stop_on_reboot(&drvdata->wdd);
+	err = devm_watchdog_register_device(dev, &drvdata->wdd);
+	if (err) {
+		dev_err(dev, "Failed to register watchdog device");
+		return err;
+	}
+
+	dev_info(dev, "HPE GXP watchdog timer");
+	return 0;
+}
+
+static int gxp_wdt_remove(struct platform_device *pdev)
+{
+	return 0;
+}
+
+static const struct of_device_id gxp_wdt_of_match[] = {
+	{ .compatible = "hpe,gxp-wdt", },
+	{},
+};
+MODULE_DEVICE_TABLE(of, gxp_wdt_of_match);
+
+static struct platform_driver gxp_wdt_driver = {
+	.probe		= gxp_wdt_probe,
+	.remove		= gxp_wdt_remove,
+	.driver = {
+		.name =		"gxp-wdt",
+		.of_match_table = gxp_wdt_of_match,
+	},
+};
+module_platform_driver(gxp_wdt_driver);
+
+MODULE_AUTHOR("Nick Hawkins <nick.hawkins@hpe.com>");
+MODULE_AUTHOR("Jean-Marie Verdun <verdun@hpe.com>");
+MODULE_DESCRIPTION("Driver for GXP watchdog timer");
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer
  2022-03-10 19:52 ` nick.hawkins
                   ` (2 preceding siblings ...)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-04-06 11:13   ` Daniel Lezcano
  -1 siblings, 1 reply; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Daniel Lezcano, Thomas Gleixner, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

Add support for the HPE GXP SOC timer. The GXP supports several
different kinds of timers but for the purpose of this driver there
is only support for the General Timer. The timer has a 1us
resolution and is 32 bits.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 drivers/clocksource/Kconfig     |   8 ++
 drivers/clocksource/Makefile    |   1 +
 drivers/clocksource/gxp-timer.c | 159 ++++++++++++++++++++++++++++++++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/clocksource/gxp-timer.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index cfb8ea0df3b1..5916dade7608 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -617,6 +617,14 @@ config CLKSRC_ST_LPC
 	  Enable this option to use the Low Power controller timer
 	  as clocksource.
 
+config GXP_TIMER
+	bool "GXP timer driver"
+	depends on ARCH_HPE
+	default y
+	help
+	  Provides a driver for the timer control found on HPE
+	  GXP SOCs. This is required for all GXP SOCs.
+
 config ATCPIT100_TIMER
 	bool "ATCPIT100 timer driver"
 	depends on NDS32 || COMPILE_TEST
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index fa5f624eadb6..dbfb8c56a8a0 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -89,3 +89,4 @@ obj-$(CONFIG_GX6605S_TIMER)		+= timer-gx6605s.o
 obj-$(CONFIG_HYPERV_TIMER)		+= hyperv_timer.o
 obj-$(CONFIG_MICROCHIP_PIT64B)		+= timer-microchip-pit64b.o
 obj-$(CONFIG_MSC313E_TIMER)		+= timer-msc313e.o
+obj-$(CONFIG_GXP_TIMER)			+= gxp-timer.o
diff --git a/drivers/clocksource/gxp-timer.c b/drivers/clocksource/gxp-timer.c
new file mode 100644
index 000000000000..a24cd1cc5c04
--- /dev/null
+++ b/drivers/clocksource/gxp-timer.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.*/
+
+#include <linux/bitops.h>
+#include <linux/clockchips.h>
+#include <linux/clocksource.h>
+#include <linux/interrupt.h>
+#include <linux/irqreturn.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sched_clock.h>
+
+#include <asm/irq.h>
+
+#define TIMER0_FREQ	1000000
+
+/*TCS Stands for Timer Control/Status: these are masks to be used in*/
+/* the Timer Count Registers */
+#define MASK_TCS_ENABLE	0x01
+#define MASK_TCS_PERIOD	0x02
+#define MASK_TCS_RELOAD	0x04
+#define MASK_TCS_TC	0x80
+
+struct gxp_timer {
+	void __iomem *counter;
+	void __iomem *control;
+	struct clock_event_device evt;
+};
+
+static void __iomem *system_clock __read_mostly;
+
+static inline struct gxp_timer *to_gxp_timer(struct clock_event_device *evt_dev)
+{
+	return container_of(evt_dev, struct gxp_timer, evt);
+}
+
+static u64 notrace gxp_sched_read(void)
+{
+	return readl_relaxed(system_clock);
+}
+
+static int gxp_time_set_next_event(unsigned long event,
+								struct clock_event_device *evt_dev)
+{
+	struct gxp_timer *timer = to_gxp_timer(evt_dev);
+	/* Stop counting and disable interrupt before updating */
+	writeb_relaxed(MASK_TCS_TC, timer->control);
+	writel_relaxed(event, timer->counter);
+	writeb_relaxed(MASK_TCS_TC | MASK_TCS_ENABLE, timer->control);
+
+	return 0;
+}
+
+static irqreturn_t gxp_time_interrupt(int irq, void *dev_id)
+{
+	struct gxp_timer *timer = dev_id;
+	void (*event_handler)(struct clock_event_device *timer);
+
+	if (!(readb_relaxed(timer->control) & MASK_TCS_TC))
+		return IRQ_NONE;
+
+	writeb_relaxed(MASK_TCS_TC, timer->control);
+
+	event_handler = READ_ONCE(timer->evt.event_handler);
+	event_handler(&timer->evt);
+
+	return IRQ_HANDLED;
+}
+
+static int __init gxp_timer_init(struct device_node *node)
+{
+	void __iomem *base_counter;
+	void __iomem *base_control;
+	u32 freq;
+	int ret, irq;
+	struct gxp_timer *gxp_timer;
+
+	base_counter = of_iomap(node, 0);
+	if (!base_counter) {
+		pr_err("Can't remap counter registers");
+		ret = -ENXIO;
+		return ret;
+	}
+
+	base_control = of_iomap(node, 1);
+	if (!base_control) {
+		pr_err("Can't remap control registers");
+		ret = -ENXIO;
+		goto err_iounmap;
+	}
+
+	system_clock = of_iomap(node, 2);
+	if (!system_clock) {
+		pr_err("Can't remap control registers");
+		ret = -ENXIO;
+		goto err_iounmap;
+	}
+
+	if (of_property_read_u32(node, "clock-frequency", &freq)) {
+		pr_err("Can't read clock-frequency\n");
+		ret = -EIO;
+		goto err_iounmap;
+	}
+
+	sched_clock_register(gxp_sched_read, 32, freq);
+	clocksource_mmio_init(system_clock, node->name, freq,
+				300, 32, clocksource_mmio_readl_up);
+
+	irq = irq_of_parse_and_map(node, 0);
+	if (irq <= 0) {
+		ret = -EINVAL;
+		pr_err("GXP Timer Can't parse IRQ %d", irq);
+		goto err_iounmap;
+	}
+
+	gxp_timer = kzalloc(sizeof(*gxp_timer), GFP_KERNEL);
+	if (!gxp_timer) {
+		ret = -ENOMEM;
+		goto err_iounmap;
+	}
+
+	gxp_timer->counter = base_counter;
+	gxp_timer->control = base_control;
+	gxp_timer->evt.name = node->name;
+	gxp_timer->evt.rating = 300;
+	gxp_timer->evt.features = CLOCK_EVT_FEAT_ONESHOT;
+	gxp_timer->evt.set_next_event = gxp_time_set_next_event;
+	gxp_timer->evt.cpumask = cpumask_of(0);
+
+	if (request_irq(irq, gxp_time_interrupt, IRQF_TIMER | IRQF_SHARED,
+			node->name, gxp_timer)) {
+		ret = -EIO;
+		pr_err("%s: request_irq() failed\n", "GXP Timer Tick");
+		goto err_timer_free;
+	}
+
+	clockevents_config_and_register(&gxp_timer->evt, TIMER0_FREQ,
+					0xf, 0xffffffff);
+
+	pr_info("gxp: system timer (irq = %d)\n", irq);
+	return 0;
+
+
+err_timer_free:
+	kfree(gxp_timer);
+
+err_iounmap:
+	iounmap(system_clock);
+	iounmap(base_control);
+	iounmap(base_counter);
+	return ret;
+}
+
+TIMER_OF_DECLARE(gxp, "hpe,gxp-timer", gxp_timer_init);
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding
  2022-03-10 19:52 ` nick.hawkins
                   ` (3 preceding siblings ...)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-03-11  9:32   ` Krzysztof Kozlowski
  2022-03-11 15:40   ` Rob Herring
  -1 siblings, 2 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun
  Cc: Nick Hawkins, Daniel Lezcano, Thomas Gleixner, Rob Herring,
	linux-kernel, devicetree

From: Nick Hawkins <nick.hawkins@hpe.com>

Creating binding for gxp timer in device tree hpe,gxp-timer
Although there are multiple times on the SoC we are only
enabling one at this time.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>

----

v2:
 *Removed maintainer change from patch
 *Verified there was no compilation errors
 *Added reference code in separate patch of patchset
---
 .../bindings/timer/hpe,gxp-timer.yaml         | 45 +++++++++++++++++++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml

diff --git a/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
new file mode 100644
index 000000000000..1f4e345c5fb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/hpe,gxp-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE GXP TIMER
+
+maintainers:
+  - Nick Hawkins <nick.hawkins@hpe.com>
+  - Jean-Marie Verdun <verdun@hpe.com>
+
+properties:
+  compatible:
+    const: hpe,gxp-timer
+
+  reg:
+    items:
+      - description: T0CNT register
+      - description: T0CS register
+      - description: TIMELO register
+
+  interrupts:
+    maxItems: 1
+
+  clock-frequency:
+    description: The frequency of the clock that drives the counter, in Hz.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clock-frequency
+
+additionalProperties: false
+
+examples:
+  - |
+    timer@10003000 {
+        compatible = "hpe,gxp-timer";
+        reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
+        interrupts = <0>;
+        interrupt-parent = <&vic0>;
+        clock-frequency = <400000000>;
+    };
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 06/10] dt-bindings: watchdog: Add HPE GXP Watchdog timer binding
  2022-03-10 19:52 ` nick.hawkins
                   ` (4 preceding siblings ...)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-03-11  9:34   ` Krzysztof Kozlowski
  -1 siblings, 1 reply; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun
  Cc: Nick Hawkins, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
	linux-watchdog, devicetree, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

Add the hpe gxp watchdog timer binding hpe,gxp-wdt.
This will enable support for the HPE GXP Watchdog

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 .../bindings/watchdog/hpe,gxp-wdt.yaml        | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml

diff --git a/Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml
new file mode 100644
index 000000000000..6044496b4968
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/hpe,gxp-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE GXP Controlled Watchdog
+
+allOf:
+  - $ref: "watchdog.yaml#"
+
+maintainers:
+  - Nick Hawkins <nick.hawkins@hpe.com>
+  - Jean-Marie Verdun <verdun@hpe.com>
+
+properties:
+  compatible:
+    const: hpe,gxp-wdt
+
+  reg:
+    items:
+      - description: WDGRST register
+      - description: WDGCS register
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    watchdog0:  watchdog@c0000090 {
+      compatible = "hpe,gxp-wdt";
+      reg = <0xc0000090 0x02>, <0xc0000096 0x01>;
+    };
+
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 07/10] dt-bindings: arm: Add HPE GXP Binding
  2022-03-10 19:52 ` nick.hawkins
                   ` (5 preceding siblings ...)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-03-11 10:20   ` Krzysztof Kozlowski
  -1 siblings, 1 reply; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Rob Herring, devicetree, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

This adds support for the hpe,gxp binding. The GXP is based on
the cortex a9 processor and supports arm7.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 .../devicetree/bindings/arm/gxp.yaml          | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/gxp.yaml

diff --git a/Documentation/devicetree/bindings/arm/gxp.yaml b/Documentation/devicetree/bindings/arm/gxp.yaml
new file mode 100644
index 000000000000..edfd331c493e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/gxp.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/gxp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HPE bmc GXP SoC driver
+
+maintainers:
+  - Nick Hawkins <nick.hawkins@hpe.com>
+  - Jean-Marie Verdun <verdun@hpe.com>
+
+properties:
+  compatible:
+    const: hpe,gxp
+
+  "#address-cells":
+    const: 1
+
+required:
+  - compatible
+
+additionalProperties: true
+
+examples:
+  - |
+      / {
+          model = "Hewlett Packard Enterprise GXP BMC";
+          compatible = "hpe,gxp";
+          #address-cells = <1>;
+          #size-cells = <1>;
+          cpus {
+              #address-cells = <1>;
+              #size-cells = <0>;
+
+              CPU0: cpu@0 {
+                  compatible = "arm,cortex-a9";
+                  device_type = "cpu";
+                  reg = <0>;
+              };
+          };
+
+          memory@40000000 {
+            device_type = "memory";
+            reg = <0x40000000 0x20000000>;
+          };
+
+          ahb {
+
+          };
+      };
+
+...
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init
  2022-03-10 19:52 ` nick.hawkins
                   ` (6 preceding siblings ...)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-03-11 10:22   ` Krzysztof Kozlowski
  -1 siblings, 1 reply; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, Rob Herring, devicetree, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

This adds support for the hpe,gxp-cpu-init binding.
With the HPE GXP initialization it is necessary to have access to this
register for it to boot.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 .../cpu-enable-method/hpe,gxp-cpu-init.yaml   | 31 +++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml

diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml b/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml
new file mode 100644
index 000000000000..a17c3fcc5421
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml
@@ -0,0 +1,31 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Initialize GXP CPU
+
+maintainers:
+  - Nick Hawkins <nick.hawkins@hpe.com>
+  - Jean-Marie Verdun <verdun@hpe.com>
+
+properties:
+  compatible:
+    const: hpe,gxp-cpu-init
+
+  reg:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    gxp-init@cefe0010 {
+      compatible = "hpe,gxp-cpu-init";
+      reg = <0xcefe0010 0x04>;
+    };
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-10 19:52 ` nick.hawkins
@ 2022-03-10 19:52   ` nick.hawkins
  -1 siblings, 0 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun
  Cc: Nick Hawkins, Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

The HPE SoC is new to linux. This patch
creates the basic device tree layout with minimum required
for linux to boot. This includes timer and watchdog
support.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 arch/arm/boot/dts/Makefile               |   2 +
 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
 arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
 3 files changed, 177 insertions(+)
 create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
 create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e41eca79c950..2823b359d373 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-vegman-n110.dtb \
 	aspeed-bmc-vegman-rx20.dtb \
 	aspeed-bmc-vegman-sx20.dtb
+dtb-$(CONFIG_ARCH_HPE_GXP) += \
+	hpe-bmc-dl360gen10.dtb
diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
new file mode 100644
index 000000000000..da5eac1213a8
--- /dev/null
+++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE DL360Gen10
+ */
+
+/include/ "hpe-gxp.dtsi"
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	compatible = "hpe,gxp";
+	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
+
+	chosen {
+		bootargs = "earlyprintk console=ttyS2,115200";
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x40000000 0x20000000>;
+	};
+
+	ahb {
+
+	};
+
+};
diff --git a/arch/arm/boot/dts/hpe-gxp.dtsi b/arch/arm/boot/dts/hpe-gxp.dtsi
new file mode 100644
index 000000000000..dfaf8df829fe
--- /dev/null
+++ b/arch/arm/boot/dts/hpe-gxp.dtsi
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE GXP
+ */
+
+/dts-v1/;
+/ {
+	model = "Hewlett Packard Enterprise GXP BMC";
+	compatible = "hpe,gxp";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	gxp-init@cefe0010 {
+		compatible = "hpe,gxp-cpu-init";
+		reg = <0xcefe0010 0x04>;
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x40000000 0x20000000>;
+	};
+
+	ahb {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		device_type = "soc";
+		ranges;
+
+		vic0: interrupt-controller@ceff0000 {
+			compatible = "arm,pl192-vic";
+			interrupt-controller;
+			reg = <0xceff0000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		vic1: interrupt-controller@80f00000 {
+			compatible = "arm,pl192-vic";
+			interrupt-controller;
+			reg = <0x80f00000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		timer0: timer@c0000080 {
+			compatible = "hpe,gxp-timer";
+			reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
+			interrupts = <0>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <400000000>;
+		};
+
+		uarta: serial@c00000e0 {
+			compatible = "ns16550a";
+			reg = <0xc00000e0 0x8>;
+			interrupts = <17>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <1846153>;
+			reg-shift = <0>;
+		};
+
+		uartb: serial@c00000e8 {
+			compatible = "ns16550a";
+			reg = <0xc00000e8 0x8>;
+			interrupts = <18>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <1846153>;
+			reg-shift = <0>;
+		};
+
+		uartc: serial@c00000f0 {
+			compatible = "ns16550a";
+			reg = <0xc00000f0 0x8>;
+			interrupts = <19>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <1846153>;
+			reg-shift = <0>;
+		};
+
+		usb0: usb@cefe0000 {
+			compatible = "generic-ehci";
+			reg = <0xcefe0000 0x100>;
+			interrupts = <7>;
+			interrupt-parent = <&vic0>;
+		};
+
+		usb1: usb@cefe0100 {
+			compatible = "generic-ohci";
+			reg = <0xcefe0100 0x110>;
+			interrupts = <6>;
+			interrupt-parent = <&vic0>;
+		};
+
+		vrom@58000000 {
+			compatible = "mtd-ram";
+			bank-width = <4>;
+			reg = <0x58000000 0x4000000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			partition@0 {
+				label = "vrom-prime";
+				reg = <0x0 0x2000000>;
+			};
+			partition@2000000 {
+				label = "vrom-second";
+				reg = <0x2000000 0x2000000>;
+			};
+		};
+
+		i2cg: syscon@c00000f8 {
+			compatible = "simple-mfd", "syscon";
+			reg = <0xc00000f8 0x08>;
+		};
+	};
+
+	clocks {
+		osc: osc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "osc";
+			clock-frequency = <33333333>;
+		};
+
+		iopclk: iopclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "iopclk";
+			clock-frequency = <400000000>;
+		};
+
+		memclk: memclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "memclk";
+			clock-frequency = <800000000>;
+		};
+	};
+};
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-10 19:52   ` nick.hawkins
  0 siblings, 0 replies; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun
  Cc: Nick Hawkins, Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

The HPE SoC is new to linux. This patch
creates the basic device tree layout with minimum required
for linux to boot. This includes timer and watchdog
support.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 arch/arm/boot/dts/Makefile               |   2 +
 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
 arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
 3 files changed, 177 insertions(+)
 create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
 create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e41eca79c950..2823b359d373 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-vegman-n110.dtb \
 	aspeed-bmc-vegman-rx20.dtb \
 	aspeed-bmc-vegman-sx20.dtb
+dtb-$(CONFIG_ARCH_HPE_GXP) += \
+	hpe-bmc-dl360gen10.dtb
diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
new file mode 100644
index 000000000000..da5eac1213a8
--- /dev/null
+++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE DL360Gen10
+ */
+
+/include/ "hpe-gxp.dtsi"
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	compatible = "hpe,gxp";
+	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
+
+	chosen {
+		bootargs = "earlyprintk console=ttyS2,115200";
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x40000000 0x20000000>;
+	};
+
+	ahb {
+
+	};
+
+};
diff --git a/arch/arm/boot/dts/hpe-gxp.dtsi b/arch/arm/boot/dts/hpe-gxp.dtsi
new file mode 100644
index 000000000000..dfaf8df829fe
--- /dev/null
+++ b/arch/arm/boot/dts/hpe-gxp.dtsi
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree file for HPE GXP
+ */
+
+/dts-v1/;
+/ {
+	model = "Hewlett Packard Enterprise GXP BMC";
+	compatible = "hpe,gxp";
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			compatible = "arm,cortex-a9";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	gxp-init@cefe0010 {
+		compatible = "hpe,gxp-cpu-init";
+		reg = <0xcefe0010 0x04>;
+	};
+
+	memory@40000000 {
+		device_type = "memory";
+		reg = <0x40000000 0x20000000>;
+	};
+
+	ahb {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		device_type = "soc";
+		ranges;
+
+		vic0: interrupt-controller@ceff0000 {
+			compatible = "arm,pl192-vic";
+			interrupt-controller;
+			reg = <0xceff0000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		vic1: interrupt-controller@80f00000 {
+			compatible = "arm,pl192-vic";
+			interrupt-controller;
+			reg = <0x80f00000 0x1000>;
+			#interrupt-cells = <1>;
+		};
+
+		timer0: timer@c0000080 {
+			compatible = "hpe,gxp-timer";
+			reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
+			interrupts = <0>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <400000000>;
+		};
+
+		uarta: serial@c00000e0 {
+			compatible = "ns16550a";
+			reg = <0xc00000e0 0x8>;
+			interrupts = <17>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <1846153>;
+			reg-shift = <0>;
+		};
+
+		uartb: serial@c00000e8 {
+			compatible = "ns16550a";
+			reg = <0xc00000e8 0x8>;
+			interrupts = <18>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <1846153>;
+			reg-shift = <0>;
+		};
+
+		uartc: serial@c00000f0 {
+			compatible = "ns16550a";
+			reg = <0xc00000f0 0x8>;
+			interrupts = <19>;
+			interrupt-parent = <&vic0>;
+			clock-frequency = <1846153>;
+			reg-shift = <0>;
+		};
+
+		usb0: usb@cefe0000 {
+			compatible = "generic-ehci";
+			reg = <0xcefe0000 0x100>;
+			interrupts = <7>;
+			interrupt-parent = <&vic0>;
+		};
+
+		usb1: usb@cefe0100 {
+			compatible = "generic-ohci";
+			reg = <0xcefe0100 0x110>;
+			interrupts = <6>;
+			interrupt-parent = <&vic0>;
+		};
+
+		vrom@58000000 {
+			compatible = "mtd-ram";
+			bank-width = <4>;
+			reg = <0x58000000 0x4000000>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			partition@0 {
+				label = "vrom-prime";
+				reg = <0x0 0x2000000>;
+			};
+			partition@2000000 {
+				label = "vrom-second";
+				reg = <0x2000000 0x2000000>;
+			};
+		};
+
+		i2cg: syscon@c00000f8 {
+			compatible = "simple-mfd", "syscon";
+			reg = <0xc00000f8 0x08>;
+		};
+	};
+
+	clocks {
+		osc: osc {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "osc";
+			clock-frequency = <33333333>;
+		};
+
+		iopclk: iopclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "iopclk";
+			clock-frequency = <400000000>;
+		};
+
+		memclk: memclk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-output-names = "memclk";
+			clock-frequency = <800000000>;
+		};
+	};
+};
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 80+ messages in thread

* [PATCH v3 10/10] maintainers: Introduce HPE GXP Architecture
  2022-03-10 19:52 ` nick.hawkins
                   ` (8 preceding siblings ...)
  (?)
@ 2022-03-10 19:52 ` nick.hawkins
  2022-03-11 10:33   ` Joe Perches
  -1 siblings, 1 reply; 80+ messages in thread
From: nick.hawkins @ 2022-03-10 19:52 UTC (permalink / raw)
  To: verdun; +Cc: Nick Hawkins, linux-kernel

From: Nick Hawkins <nick.hawkins@hpe.com>

Create a section in MAINTAINERS for the GXP HPE
architecture.

Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
 MAINTAINERS | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6db79f3b209e..f227d76ec43d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8791,6 +8791,20 @@ L:	platform-driver-x86@vger.kernel.org
 S:	Orphan
 F:	drivers/platform/x86/tc1100-wmi.c
 
+HPE GXP ARCHITECTURE
+M:	Jean-Marie Verdun <verdun@hpe.com>
+M:	Nick Hawkins <nick.hawkins@hpe.com>
+S:	MAINTAINED
+F:	Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml
+F:	Documentation/devicetree/bindings/arm/gxp.yaml
+F:	Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
+F:	Documentation/devicetree/bindings/wdt/hpe,gxp-wdt.yaml
+F:	arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
+F:	arch/arm/boot/dts/hpe-gxp.dtsi
+F:	arch/arm/mach-hpe/gxp.c
+F:	drivers/clocksource/gxp-timer.c
+F:	drivers/watchdog/gxp-wdt.c
+
 HPET:	High Precision Event Timers driver
 M:	Clemens Ladisch <clemens@ladisch.de>
 S:	Maintained
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
  2022-03-10 19:52 ` nick.hawkins
@ 2022-03-11  7:21   ` kernel test robot
  -1 siblings, 0 replies; 80+ messages in thread
From: kernel test robot @ 2022-03-11  7:21 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: llvm, kbuild-all, Nick Hawkins, Russell King, linux-arm-kernel,
	linux-kernel

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tip/timers/core]
[also build test WARNING on soc/for-next robh/for-next linus/master v5.17-rc7 next-20220310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 58dedf0a4782ce42b4d31f1f62e5ad80a1b73d72
config: arm-defconfig (https://download.01.org/0day-ci/archive/20220311/202203111516.oSsKrRqX-lkp@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 276ca87382b8f16a65bddac700202924228982f6)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/0day-ci/linux/commit/9fbfc32473a65e025764e0a1456c421b4706fe8e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
        git checkout 9fbfc32473a65e025764e0a1456c421b4706fe8e
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> arch/arm/mach-hpe/gxp.c:26:13: warning: no previous prototype for function 'gxp_map_io' [-Wmissing-prototypes]
   void __init gxp_map_io(void)
               ^
   arch/arm/mach-hpe/gxp.c:26:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __init gxp_map_io(void)
   ^
   static 
   1 warning generated.


vim +/gxp_map_io +26 arch/arm/mach-hpe/gxp.c

    25	
  > 26	void __init gxp_map_io(void)
    27	{
    28		iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
    29	}
    30	

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-11  7:21   ` kernel test robot
  0 siblings, 0 replies; 80+ messages in thread
From: kernel test robot @ 2022-03-11  7:21 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: llvm, kbuild-all, Nick Hawkins, Russell King, linux-arm-kernel,
	linux-kernel

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tip/timers/core]
[also build test WARNING on soc/for-next robh/for-next linus/master v5.17-rc7 next-20220310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 58dedf0a4782ce42b4d31f1f62e5ad80a1b73d72
config: arm-defconfig (https://download.01.org/0day-ci/archive/20220311/202203111516.oSsKrRqX-lkp@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 276ca87382b8f16a65bddac700202924228982f6)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install arm cross compiling tool for clang build
        # apt-get install binutils-arm-linux-gnueabi
        # https://github.com/0day-ci/linux/commit/9fbfc32473a65e025764e0a1456c421b4706fe8e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
        git checkout 9fbfc32473a65e025764e0a1456c421b4706fe8e
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> arch/arm/mach-hpe/gxp.c:26:13: warning: no previous prototype for function 'gxp_map_io' [-Wmissing-prototypes]
   void __init gxp_map_io(void)
               ^
   arch/arm/mach-hpe/gxp.c:26:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
   void __init gxp_map_io(void)
   ^
   static 
   1 warning generated.


vim +/gxp_map_io +26 arch/arm/mach-hpe/gxp.c

    25	
  > 26	void __init gxp_map_io(void)
    27	{
    28		iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
    29	}
    30	

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
  2022-03-10 19:52 ` nick.hawkins
@ 2022-03-11  8:06   ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-11  8:06 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Verdun, Jean-Marie, Russell King, Linux ARM, Linux Kernel Mailing List

On Thu, Mar 10, 2022 at 8:52 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> The GXP is the HPE BMC SoC that is used in the majority
> of HPE Generation 10 servers. Traditionally the asic will
> last multiple generations of server before being replaced.
> In gxp.c we reset the EHCI controller early to boot the asic.
>
> Info about SoC:
>
> HPE GXP is the name of the HPE Soc. This SoC is used to implement
> many BMC features at HPE. It supports ARMv7 architecture based on
> the Cortex A9 core. It is capable of using an AXI bus to which
> a memory controller is attached. It has multiple SPI interfaces
> to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC
> for network connectivity. It has multiple i2c engines to drive
> connectivity with a host infrastructure. The initial patches
> enable the watchdog and timer enabling the host to be able to
> boot.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>

Please add me to Cc for the entire series when resending.


> +config ARCH_HPE_GXP
> +       bool "HPE GXP SoC"
> +       select ARM_VIC
> +       select PINCTRL
> +       select IRQ_DOMAIN
> +       select GENERIC_IRQ_CHIP
> +       select MULTI_IRQ_HANDLER
> +       select SPARSE_IRQ
> +       select CLKSRC_MMIO
> +       depends on ARCH_MULTI_V7

By convention, the 'depends on' usually comes first here.

Please drop the 'select' statements for things that are already selected
by ARCH_MULTIPLATFORM or ARCH_MULTI_V7.


> +
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
> +#define RESET_CMD 0x00080002
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> +       {
> +               .virtual        = (unsigned long)IOP_REGS_VIRT_BASE,
> +               .pfn            = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> +               .length         = IOP_REGS_SIZE,
> +               .type           = MT_DEVICE,
> +       },
> +};

It looks like this is only used for the pxf_restart() function below.
In this case, you should get rid of the static mapping entirely and
use an ioremap() in the gxp_dt_init() function instead, ideally getting
the address from an appropriate device node rather than hardcoding
it here.

If there are other drivers using the static mapping, either explain
here why this is required, or try to change them to dynamic mappings as well.

> +static void __init gxp_dt_init(void)
> +{
> +       void __iomem *gxp_init_regs;
> +       struct device_node *np;
> +
> +       np = of_find_compatible_node(NULL, NULL, "hpe,gxp-cpu-init");
> +       gxp_init_regs = of_iomap(np, 0);
> +
> +       /*it is necessary for our SOC to reset ECHI through this*/
> +       /* register due to a hardware limitation*/
> +       __raw_writel(RESET_CMD,
> +               (gxp_init_regs));

My feeling is still that this should be done in the platform specific EHCI
driver front-end. I think I commented on this before but don't remember
getting an explanation why you can't have it there.

> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> +       __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}

With both of these, you should use writel() instead of __raw_write().
Using the __raw accessors breaks big-endian kernels (which you
probably don't need, but shouldn't break for no reason anyway), and
lacks serialization and atomicity of the access.

A better place for the restart logic may be a separate driver in
drivers/power/reset/, at least if this otherwise ends up being the only
platform specific code you need.

          Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-11  8:06   ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-11  8:06 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Verdun, Jean-Marie, Russell King, Linux ARM, Linux Kernel Mailing List

On Thu, Mar 10, 2022 at 8:52 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> The GXP is the HPE BMC SoC that is used in the majority
> of HPE Generation 10 servers. Traditionally the asic will
> last multiple generations of server before being replaced.
> In gxp.c we reset the EHCI controller early to boot the asic.
>
> Info about SoC:
>
> HPE GXP is the name of the HPE Soc. This SoC is used to implement
> many BMC features at HPE. It supports ARMv7 architecture based on
> the Cortex A9 core. It is capable of using an AXI bus to which
> a memory controller is attached. It has multiple SPI interfaces
> to connect boot flash and BIOS flash. It uses a 10/100/1000 MAC
> for network connectivity. It has multiple i2c engines to drive
> connectivity with a host infrastructure. The initial patches
> enable the watchdog and timer enabling the host to be able to
> boot.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>

Please add me to Cc for the entire series when resending.


> +config ARCH_HPE_GXP
> +       bool "HPE GXP SoC"
> +       select ARM_VIC
> +       select PINCTRL
> +       select IRQ_DOMAIN
> +       select GENERIC_IRQ_CHIP
> +       select MULTI_IRQ_HANDLER
> +       select SPARSE_IRQ
> +       select CLKSRC_MMIO
> +       depends on ARCH_MULTI_V7

By convention, the 'depends on' usually comes first here.

Please drop the 'select' statements for things that are already selected
by ARCH_MULTIPLATFORM or ARCH_MULTI_V7.


> +
> +#define IOP_REGS_PHYS_BASE 0xc0000000
> +#define IOP_REGS_VIRT_BASE 0xf0000000
> +#define IOP_REGS_SIZE (240*SZ_1M)
> +#define RESET_CMD 0x00080002
> +
> +static struct map_desc gxp_io_desc[] __initdata = {
> +       {
> +               .virtual        = (unsigned long)IOP_REGS_VIRT_BASE,
> +               .pfn            = __phys_to_pfn(IOP_REGS_PHYS_BASE),
> +               .length         = IOP_REGS_SIZE,
> +               .type           = MT_DEVICE,
> +       },
> +};

It looks like this is only used for the pxf_restart() function below.
In this case, you should get rid of the static mapping entirely and
use an ioremap() in the gxp_dt_init() function instead, ideally getting
the address from an appropriate device node rather than hardcoding
it here.

If there are other drivers using the static mapping, either explain
here why this is required, or try to change them to dynamic mappings as well.

> +static void __init gxp_dt_init(void)
> +{
> +       void __iomem *gxp_init_regs;
> +       struct device_node *np;
> +
> +       np = of_find_compatible_node(NULL, NULL, "hpe,gxp-cpu-init");
> +       gxp_init_regs = of_iomap(np, 0);
> +
> +       /*it is necessary for our SOC to reset ECHI through this*/
> +       /* register due to a hardware limitation*/
> +       __raw_writel(RESET_CMD,
> +               (gxp_init_regs));

My feeling is still that this should be done in the platform specific EHCI
driver front-end. I think I commented on this before but don't remember
getting an explanation why you can't have it there.

> +static void gxp_restart(enum reboot_mode mode, const char *cmd)
> +{
> +       __raw_writel(1, (void __iomem *) IOP_REGS_VIRT_BASE);
> +}

With both of these, you should use writel() instead of __raw_write().
Using the __raw accessors breaks big-endian kernels (which you
probably don't need, but shouldn't break for no reason anyway), and
lacks serialization and atomicity of the access.

A better place for the restart logic may be a separate driver in
drivers/power/reset/, at least if this otherwise ends up being the only
platform specific code you need.

          Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-10 19:52   ` nick.hawkins
@ 2022-03-11  8:17     ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-11  8:17 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Verdun, Jean-Marie, Arnd Bergmann, Olof Johansson, SoC Team,
	Rob Herring, Linux ARM, DTML, Linux Kernel Mailing List

On Thu, Mar 10, 2022 at 8:52 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> The HPE SoC is new to linux. This patch
> creates the basic device tree layout with minimum required
> for linux to boot. This includes timer and watchdog
> support.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> +/ {
> +       #address-cells = <1>;
> +       #size-cells = <1>;
> +       compatible = "hpe,gxp";
> +       model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
> +
> +       chosen {
> +               bootargs = "earlyprintk console=ttyS2,115200";
> +       };

Please drop the bootargs here, you definitely should not have 'earlyprintk'
in the bootargs because that is incompatible with cross-platform kernels.

Instead of passing the console in the bootargs, use the "stdout-path"
property.

The "compatible" property should be a list that contains at least the specific
SoC variant and an identifier for the board. "hpe,gxp" is way too generic
to be the only property here.
> +       gxp-init@cefe0010 {
> +               compatible = "hpe,gxp-cpu-init";
> +               reg = <0xcefe0010 0x04>;
> +       };
> +
> +       memory@40000000 {
> +               device_type = "memory";
> +               reg = <0x40000000 0x20000000>;
> +       };
> +
> +       ahb {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               device_type = "soc";
> +               ranges;
> +
> +               vic0: interrupt-controller@ceff0000 {
> +                       compatible = "arm,pl192-vic";
> +                       interrupt-controller;
> +                       reg = <0xceff0000 0x1000>;
> +                       #interrupt-cells = <1>;
> +               };

I don't think this represents the actual hierarchy of the devices:
the register range of the "vic0" and the "gxp-init" is very close
together, which usually indicates that they are also on the same
bus.



> +               vic1: interrupt-controller@80f00000 {
> +                       compatible = "arm,pl192-vic";
> +                       interrupt-controller;
> +                       reg = <0x80f00000 0x1000>;
> +                       #interrupt-cells = <1>;
> +               };
> +
> +               timer0: timer@c0000080 {
> +                       compatible = "hpe,gxp-timer";
> +                       reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
> +                       interrupts = <0>;
> +                       interrupt-parent = <&vic0>;
> +                       clock-frequency = <400000000>;
> +               };
> +
> +               uarta: serial@c00000e0 {
> +                       compatible = "ns16550a";
> +                       reg = <0xc00000e0 0x8>;
> +                       interrupts = <17>;
> +                       interrupt-parent = <&vic0>;
> +                       clock-frequency = <1846153>;
> +                       reg-shift = <0>;
> +               };

In turn, you seem to have a lot of other devices on low addresses
of the 0xc0000000 range, which would be an indication that these
are on a different bus from the others.

Please see if you can find an internal datasheet that describes the
actual device hierarchy, and then try to model this in the device tree.

Use non-empty "ranges" properties to describe the address ranges
and how they get translated between these buses, and add
"dma-ranges" for any high-speed buses that have DMA master
capable devices like USB on them.

> +               i2cg: syscon@c00000f8 {
> +                       compatible = "simple-mfd", "syscon";
> +                       reg = <0xc00000f8 0x08>;
> +               };
> +       };

It's odd to have a "syscon" device that only has 8 bytes worth of registers.

What are the contents of this? Is it possible to have a proper abstraction
for it as something that has a specific purpose rather than being a
random collection of individual bits?

       Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-11  8:17     ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-11  8:17 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Verdun, Jean-Marie, Arnd Bergmann, Olof Johansson, SoC Team,
	Rob Herring, Linux ARM, DTML, Linux Kernel Mailing List

On Thu, Mar 10, 2022 at 8:52 PM <nick.hawkins@hpe.com> wrote:
>
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> The HPE SoC is new to linux. This patch
> creates the basic device tree layout with minimum required
> for linux to boot. This includes timer and watchdog
> support.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> +/ {
> +       #address-cells = <1>;
> +       #size-cells = <1>;
> +       compatible = "hpe,gxp";
> +       model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
> +
> +       chosen {
> +               bootargs = "earlyprintk console=ttyS2,115200";
> +       };

Please drop the bootargs here, you definitely should not have 'earlyprintk'
in the bootargs because that is incompatible with cross-platform kernels.

Instead of passing the console in the bootargs, use the "stdout-path"
property.

The "compatible" property should be a list that contains at least the specific
SoC variant and an identifier for the board. "hpe,gxp" is way too generic
to be the only property here.
> +       gxp-init@cefe0010 {
> +               compatible = "hpe,gxp-cpu-init";
> +               reg = <0xcefe0010 0x04>;
> +       };
> +
> +       memory@40000000 {
> +               device_type = "memory";
> +               reg = <0x40000000 0x20000000>;
> +       };
> +
> +       ahb {
> +               compatible = "simple-bus";
> +               #address-cells = <1>;
> +               #size-cells = <1>;
> +               device_type = "soc";
> +               ranges;
> +
> +               vic0: interrupt-controller@ceff0000 {
> +                       compatible = "arm,pl192-vic";
> +                       interrupt-controller;
> +                       reg = <0xceff0000 0x1000>;
> +                       #interrupt-cells = <1>;
> +               };

I don't think this represents the actual hierarchy of the devices:
the register range of the "vic0" and the "gxp-init" is very close
together, which usually indicates that they are also on the same
bus.



> +               vic1: interrupt-controller@80f00000 {
> +                       compatible = "arm,pl192-vic";
> +                       interrupt-controller;
> +                       reg = <0x80f00000 0x1000>;
> +                       #interrupt-cells = <1>;
> +               };
> +
> +               timer0: timer@c0000080 {
> +                       compatible = "hpe,gxp-timer";
> +                       reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
> +                       interrupts = <0>;
> +                       interrupt-parent = <&vic0>;
> +                       clock-frequency = <400000000>;
> +               };
> +
> +               uarta: serial@c00000e0 {
> +                       compatible = "ns16550a";
> +                       reg = <0xc00000e0 0x8>;
> +                       interrupts = <17>;
> +                       interrupt-parent = <&vic0>;
> +                       clock-frequency = <1846153>;
> +                       reg-shift = <0>;
> +               };

In turn, you seem to have a lot of other devices on low addresses
of the 0xc0000000 range, which would be an indication that these
are on a different bus from the others.

Please see if you can find an internal datasheet that describes the
actual device hierarchy, and then try to model this in the device tree.

Use non-empty "ranges" properties to describe the address ranges
and how they get translated between these buses, and add
"dma-ranges" for any high-speed buses that have DMA master
capable devices like USB on them.

> +               i2cg: syscon@c00000f8 {
> +                       compatible = "simple-mfd", "syscon";
> +                       reg = <0xc00000f8 0x08>;
> +               };
> +       };

It's odd to have a "syscon" device that only has 8 bytes worth of registers.

What are the contents of this? Is it possible to have a proper abstraction
for it as something that has a specific purpose rather than being a
random collection of individual bits?

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding
  2022-03-10 19:52 ` [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding nick.hawkins
@ 2022-03-11  9:32   ` Krzysztof Kozlowski
  2022-03-11 15:40   ` Rob Herring
  1 sibling, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11  9:32 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, linux-kernel, devicetree

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> Creating binding for gxp timer in device tree hpe,gxp-timer
> Although there are multiple times on the SoC we are only
> enabling one at this time.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> 
> ----
> 
> v2:
>  *Removed maintainer change from patch
>  *Verified there was no compilation errors
>  *Added reference code in separate patch of patchset
> ---
>  .../bindings/timer/hpe,gxp-timer.yaml         | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
> 
> diff --git a/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
> new file mode 100644
> index 000000000000..1f4e345c5fb8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/timer/hpe,gxp-timer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HPE GXP TIMER
> +
> +maintainers:
> +  - Nick Hawkins <nick.hawkins@hpe.com>
> +  - Jean-Marie Verdun <verdun@hpe.com>
> +
> +properties:
> +  compatible:
> +    const: hpe,gxp-timer
> +
> +  reg:
> +    items:
> +      - description: T0CNT register
> +      - description: T0CS register
> +      - description: TIMELO register
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clock-frequency:
> +    description: The frequency of the clock that drives the counter, in Hz.

Which clock is it? Generated inside the timer? If outside, why driver
does not take the reference to it and uses clk_get_rate()?

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 06/10] dt-bindings: watchdog: Add HPE GXP Watchdog timer binding
  2022-03-10 19:52 ` [PATCH v3 06/10] dt-bindings: watchdog: Add HPE GXP Watchdog timer binding nick.hawkins
@ 2022-03-11  9:34   ` Krzysztof Kozlowski
  0 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11  9:34 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: Wim Van Sebroeck, Guenter Roeck, Rob Herring, linux-watchdog,
	devicetree, linux-kernel

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> Add the hpe gxp watchdog timer binding hpe,gxp-wdt.
> This will enable support for the HPE GXP Watchdog
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>  .../bindings/watchdog/hpe,gxp-wdt.yaml        | 37 +++++++++++++++++++
>  1 file changed, 37 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml
> new file mode 100644
> index 000000000000..6044496b4968
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/hpe,gxp-wdt.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/hpe,gxp-wdt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HPE GXP Controlled Watchdog
> +
> +allOf:
> +  - $ref: "watchdog.yaml#"
> +
> +maintainers:
> +  - Nick Hawkins <nick.hawkins@hpe.com>
> +  - Jean-Marie Verdun <verdun@hpe.com>
> +
> +properties:
> +  compatible:
> +    const: hpe,gxp-wdt
> +
> +  reg:
> +    items:
> +      - description: WDGRST register
> +      - description: WDGCS register

Why are you mapping each register instead of entire address space? It
won't scale if your new design comes with 10 registers...

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +    watchdog0:  watchdog@c0000090 {

Skip the label. You also have there double space between label and node
name.

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 07/10] dt-bindings: arm: Add HPE GXP Binding
  2022-03-10 19:52 ` [PATCH v3 07/10] dt-bindings: arm: Add HPE GXP Binding nick.hawkins
@ 2022-03-11 10:20   ` Krzysztof Kozlowski
  0 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11 10:20 UTC (permalink / raw)
  To: nick.hawkins, verdun; +Cc: Rob Herring, devicetree, linux-kernel

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> This adds support for the hpe,gxp binding. The GXP is based on
> the cortex a9 processor and supports arm7.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>  .../devicetree/bindings/arm/gxp.yaml          | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/gxp.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/gxp.yaml b/Documentation/devicetree/bindings/arm/gxp.yaml
> new file mode 100644
> index 000000000000..edfd331c493e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/gxp.yaml

Missing vendor prefix in file name, so "hpe,gxp.yaml"

> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/gxp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HPE bmc GXP SoC driver

Driver does not fit here. I think you are adding HPE GXP platforms? If yes

> +
> +maintainers:
> +  - Nick Hawkins <nick.hawkins@hpe.com>
> +  - Jean-Marie Verdun <verdun@hpe.com>
> +
> +properties:
> +  compatible:
> +    const: hpe,gxp

This is not proper SoC/boards description. Look at intel,keembay.yaml
for example.

You also miss here other compatibles - for board(s).

> +
> +  "#address-cells":
> +    const: 1
> +
> +required:
> +  - compatible
> +
> +additionalProperties: true
> +
> +examples:
> +  - |

Skip the example, platform bindings do not have them.

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init
  2022-03-10 19:52 ` [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init nick.hawkins
@ 2022-03-11 10:22   ` Krzysztof Kozlowski
  2022-03-16 21:33     ` Hawkins, Nick
  0 siblings, 1 reply; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11 10:22 UTC (permalink / raw)
  To: nick.hawkins, verdun; +Cc: Rob Herring, devicetree, linux-kernel

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> This adds support for the hpe,gxp-cpu-init binding.
> With the HPE GXP initialization it is necessary to have access to this
> register for it to boot.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>  .../cpu-enable-method/hpe,gxp-cpu-init.yaml   | 31 +++++++++++++++++++
>  1 file changed, 31 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml b/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml
> new file mode 100644
> index 000000000000..a17c3fcc5421
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/cpu-enable-method/hpe,gxp-cpu-init.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Initialize GXP CPU

Please explain what's this. The bindings describe the hardware and I
cannot get what is this here about. Is it a CPU enable method (like in
cpus.yaml)? Is it some power management block?


Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-10 19:52   ` nick.hawkins
@ 2022-03-11 10:29     ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11 10:29 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> The HPE SoC is new to linux. This patch
> creates the basic device tree layout with minimum required
> for linux to boot. This includes timer and watchdog
> support.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>  arch/arm/boot/dts/Makefile               |   2 +
>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>  3 files changed, 177 insertions(+)
>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e41eca79c950..2823b359d373 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>  	aspeed-bmc-vegman-n110.dtb \
>  	aspeed-bmc-vegman-rx20.dtb \
>  	aspeed-bmc-vegman-sx20.dtb
> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
> +	hpe-bmc-dl360gen10.dtb

Alphabetically, also in respect to other architectures, so before
CONFIG_ARCH_INTEGRATOR.

> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
> new file mode 100644
> index 000000000000..da5eac1213a8
> --- /dev/null
> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE DL360Gen10
> + */
> +
> +/include/ "hpe-gxp.dtsi"
> +
> +/ {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	compatible = "hpe,gxp";

Missing board compatible.

> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
> +
> +	chosen {
> +		bootargs = "earlyprintk console=ttyS2,115200";

I have impression we talked about it...

> +	};
> +
> +	memory@40000000 {
> +		device_type = "memory";
> +		reg = <0x40000000 0x20000000>;
> +	};
> +
> +	ahb {

Why do you need empty node?

> +
> +	};
> +
> +};
> diff --git a/arch/arm/boot/dts/hpe-gxp.dtsi b/arch/arm/boot/dts/hpe-gxp.dtsi
> new file mode 100644
> index 000000000000..dfaf8df829fe
> --- /dev/null
> +++ b/arch/arm/boot/dts/hpe-gxp.dtsi
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE GXP
> + */
> +
> +/dts-v1/;
> +/ {
> +	model = "Hewlett Packard Enterprise GXP BMC";
> +	compatible = "hpe,gxp";
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			compatible = "arm,cortex-a9";
> +			device_type = "cpu";
> +			reg = <0>;
> +		};
> +	};
> +
> +	gxp-init@cefe0010 {

Need a generic node name. gpx-init is specific.

> +		compatible = "hpe,gxp-cpu-init";
> +		reg = <0xcefe0010 0x04>;
> +	};
> +
> +	memory@40000000 {
> +		device_type = "memory";
> +		reg = <0x40000000 0x20000000>;
> +	};
> +
> +	ahb {

By convention we call it soc.

> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "soc";
> +		ranges;
> +
> +		vic0: interrupt-controller@ceff0000 {
> +			compatible = "arm,pl192-vic";
> +			interrupt-controller;
> +			reg = <0xceff0000 0x1000>;

Please put reg after compatible, everywhere.

> +			#interrupt-cells = <1>;
> +		};
> +
> +		vic1: interrupt-controller@80f00000 {
> +			compatible = "arm,pl192-vic";
> +			interrupt-controller;
> +			reg = <0x80f00000 0x1000>;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		timer0: timer@c0000080 {
> +			compatible = "hpe,gxp-timer";
> +			reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
> +			interrupts = <0>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <400000000>;
> +		};
> +
> +		uarta: serial@c00000e0 {
> +			compatible = "ns16550a";
> +			reg = <0xc00000e0 0x8>;
> +			interrupts = <17>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <1846153>;
> +			reg-shift = <0>;
> +		};
> +
> +		uartb: serial@c00000e8 {
> +			compatible = "ns16550a";
> +			reg = <0xc00000e8 0x8>;
> +			interrupts = <18>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <1846153>;
> +			reg-shift = <0>;
> +		};
> +
> +		uartc: serial@c00000f0 {
> +			compatible = "ns16550a";
> +			reg = <0xc00000f0 0x8>;
> +			interrupts = <19>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <1846153>;
> +			reg-shift = <0>;
> +		};
> +
> +		usb0: usb@cefe0000 {
> +			compatible = "generic-ehci";

I think one of previous comments was that you cannot have "generic-ehci"
only, right?

> +			reg = <0xcefe0000 0x100>;
> +			interrupts = <7>;
> +			interrupt-parent = <&vic0>;
> +		};
> +
> +		usb1: usb@cefe0100 {
> +			compatible = "generic-ohci";
> +			reg = <0xcefe0100 0x110>;
> +			interrupts = <6>;
> +			interrupt-parent = <&vic0>;
> +		};
> +
> +		vrom@58000000 {
> +			compatible = "mtd-ram";
> +			bank-width = <4>;
> +			reg = <0x58000000 0x4000000>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			partition@0 {
> +				label = "vrom-prime";
> +				reg = <0x0 0x2000000>;
> +			};
> +			partition@2000000 {
> +				label = "vrom-second";
> +				reg = <0x2000000 0x2000000>;
> +			};
> +		};
> +
> +		i2cg: syscon@c00000f8 {


> +			compatible = "simple-mfd", "syscon";
> +			reg = <0xc00000f8 0x08>;
> +		};
> +	};
> +
> +	clocks {
> +		osc: osc {

Keep node naming consistent, so just "clk"... but it's also very generic
comparing to others, so I wonder what is this clock?

> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-output-names = "osc";
> +			clock-frequency = <33333333>;
> +		};
> +
> +		iopclk: iopclk {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-output-names = "iopclk";
> +			clock-frequency = <400000000>;
> +		};
> +
> +		memclk: memclk {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-output-names = "memclk";
> +			clock-frequency = <800000000>;
> +		};

What are these clocks? If external to the SoC, then where are they? On
the board?

> +	};
> +};


Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-11 10:29     ` Krzysztof Kozlowski
  0 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11 10:29 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> The HPE SoC is new to linux. This patch
> creates the basic device tree layout with minimum required
> for linux to boot. This includes timer and watchdog
> support.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>  arch/arm/boot/dts/Makefile               |   2 +
>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>  3 files changed, 177 insertions(+)
>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e41eca79c950..2823b359d373 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>  	aspeed-bmc-vegman-n110.dtb \
>  	aspeed-bmc-vegman-rx20.dtb \
>  	aspeed-bmc-vegman-sx20.dtb
> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
> +	hpe-bmc-dl360gen10.dtb

Alphabetically, also in respect to other architectures, so before
CONFIG_ARCH_INTEGRATOR.

> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
> new file mode 100644
> index 000000000000..da5eac1213a8
> --- /dev/null
> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE DL360Gen10
> + */
> +
> +/include/ "hpe-gxp.dtsi"
> +
> +/ {
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +	compatible = "hpe,gxp";

Missing board compatible.

> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
> +
> +	chosen {
> +		bootargs = "earlyprintk console=ttyS2,115200";

I have impression we talked about it...

> +	};
> +
> +	memory@40000000 {
> +		device_type = "memory";
> +		reg = <0x40000000 0x20000000>;
> +	};
> +
> +	ahb {

Why do you need empty node?

> +
> +	};
> +
> +};
> diff --git a/arch/arm/boot/dts/hpe-gxp.dtsi b/arch/arm/boot/dts/hpe-gxp.dtsi
> new file mode 100644
> index 000000000000..dfaf8df829fe
> --- /dev/null
> +++ b/arch/arm/boot/dts/hpe-gxp.dtsi
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE GXP
> + */
> +
> +/dts-v1/;
> +/ {
> +	model = "Hewlett Packard Enterprise GXP BMC";
> +	compatible = "hpe,gxp";
> +	#address-cells = <1>;
> +	#size-cells = <1>;
> +
> +	cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		cpu@0 {
> +			compatible = "arm,cortex-a9";
> +			device_type = "cpu";
> +			reg = <0>;
> +		};
> +	};
> +
> +	gxp-init@cefe0010 {

Need a generic node name. gpx-init is specific.

> +		compatible = "hpe,gxp-cpu-init";
> +		reg = <0xcefe0010 0x04>;
> +	};
> +
> +	memory@40000000 {
> +		device_type = "memory";
> +		reg = <0x40000000 0x20000000>;
> +	};
> +
> +	ahb {

By convention we call it soc.

> +		compatible = "simple-bus";
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		device_type = "soc";
> +		ranges;
> +
> +		vic0: interrupt-controller@ceff0000 {
> +			compatible = "arm,pl192-vic";
> +			interrupt-controller;
> +			reg = <0xceff0000 0x1000>;

Please put reg after compatible, everywhere.

> +			#interrupt-cells = <1>;
> +		};
> +
> +		vic1: interrupt-controller@80f00000 {
> +			compatible = "arm,pl192-vic";
> +			interrupt-controller;
> +			reg = <0x80f00000 0x1000>;
> +			#interrupt-cells = <1>;
> +		};
> +
> +		timer0: timer@c0000080 {
> +			compatible = "hpe,gxp-timer";
> +			reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;
> +			interrupts = <0>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <400000000>;
> +		};
> +
> +		uarta: serial@c00000e0 {
> +			compatible = "ns16550a";
> +			reg = <0xc00000e0 0x8>;
> +			interrupts = <17>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <1846153>;
> +			reg-shift = <0>;
> +		};
> +
> +		uartb: serial@c00000e8 {
> +			compatible = "ns16550a";
> +			reg = <0xc00000e8 0x8>;
> +			interrupts = <18>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <1846153>;
> +			reg-shift = <0>;
> +		};
> +
> +		uartc: serial@c00000f0 {
> +			compatible = "ns16550a";
> +			reg = <0xc00000f0 0x8>;
> +			interrupts = <19>;
> +			interrupt-parent = <&vic0>;
> +			clock-frequency = <1846153>;
> +			reg-shift = <0>;
> +		};
> +
> +		usb0: usb@cefe0000 {
> +			compatible = "generic-ehci";

I think one of previous comments was that you cannot have "generic-ehci"
only, right?

> +			reg = <0xcefe0000 0x100>;
> +			interrupts = <7>;
> +			interrupt-parent = <&vic0>;
> +		};
> +
> +		usb1: usb@cefe0100 {
> +			compatible = "generic-ohci";
> +			reg = <0xcefe0100 0x110>;
> +			interrupts = <6>;
> +			interrupt-parent = <&vic0>;
> +		};
> +
> +		vrom@58000000 {
> +			compatible = "mtd-ram";
> +			bank-width = <4>;
> +			reg = <0x58000000 0x4000000>;
> +			#address-cells = <1>;
> +			#size-cells = <1>;
> +			partition@0 {
> +				label = "vrom-prime";
> +				reg = <0x0 0x2000000>;
> +			};
> +			partition@2000000 {
> +				label = "vrom-second";
> +				reg = <0x2000000 0x2000000>;
> +			};
> +		};
> +
> +		i2cg: syscon@c00000f8 {


> +			compatible = "simple-mfd", "syscon";
> +			reg = <0xc00000f8 0x08>;
> +		};
> +	};
> +
> +	clocks {
> +		osc: osc {

Keep node naming consistent, so just "clk"... but it's also very generic
comparing to others, so I wonder what is this clock?

> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-output-names = "osc";
> +			clock-frequency = <33333333>;
> +		};
> +
> +		iopclk: iopclk {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-output-names = "iopclk";
> +			clock-frequency = <400000000>;
> +		};
> +
> +		memclk: memclk {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-output-names = "memclk";
> +			clock-frequency = <800000000>;
> +		};

What are these clocks? If external to the SoC, then where are they? On
the board?

> +	};
> +};


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 10/10] maintainers: Introduce HPE GXP Architecture
  2022-03-10 19:52 ` [PATCH v3 10/10] maintainers: Introduce HPE GXP Architecture nick.hawkins
@ 2022-03-11 10:33   ` Joe Perches
  0 siblings, 0 replies; 80+ messages in thread
From: Joe Perches @ 2022-03-11 10:33 UTC (permalink / raw)
  To: nick.hawkins, verdun; +Cc: linux-kernel

On Thu, 2022-03-10 at 13:52 -0600, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> Create a section in MAINTAINERS for the GXP HPE
> architecture.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -8791,6 +8791,20 @@ L:	platform-driver-x86@vger.kernel.org
>  S:	Orphan
>  F:	drivers/platform/x86/tc1100-wmi.c
>  
> +HPE GXP ARCHITECTURE
> +M:	Jean-Marie Verdun <verdun@hpe.com>
> +M:	Nick Hawkins <nick.hawkins@hpe.com>
> +S:	MAINTAINED

Use the case sensitive version instead

S:	Maintained

$ git grep -h '^S:' MAINTAINERS | sort | uniq -c | sort -rn
   1682 S:	Maintained
    637 S:	Supported
     71 S:	Odd Fixes
     64 S:	Orphan
     19 S:	Odd fixes
      7 S:	Orphan / Obsolete
      2 S:	Obsolete
      1 S:	Buried alive in reporters



^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
  2022-03-10 19:52 ` nick.hawkins
@ 2022-03-11 12:40   ` kernel test robot
  -1 siblings, 0 replies; 80+ messages in thread
From: kernel test robot @ 2022-03-11 12:40 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: kbuild-all, Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tip/timers/core]
[also build test WARNING on soc/for-next robh/for-next linus/master v5.17-rc7 next-20220310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 58dedf0a4782ce42b4d31f1f62e5ad80a1b73d72
config: arm-defconfig (https://download.01.org/0day-ci/archive/20220311/202203112000.DIc9zr62-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/9fbfc32473a65e025764e0a1456c421b4706fe8e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
        git checkout 9fbfc32473a65e025764e0a1456c421b4706fe8e
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> arch/arm/mach-hpe/gxp.c:26:13: warning: no previous prototype for 'gxp_map_io' [-Wmissing-prototypes]
      26 | void __init gxp_map_io(void)
         |             ^~~~~~~~~~


vim +/gxp_map_io +26 arch/arm/mach-hpe/gxp.c

    25	
  > 26	void __init gxp_map_io(void)
    27	{
    28		iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
    29	}
    30	

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-11 12:40   ` kernel test robot
  0 siblings, 0 replies; 80+ messages in thread
From: kernel test robot @ 2022-03-11 12:40 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: kbuild-all, Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

Hi,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on tip/timers/core]
[also build test WARNING on soc/for-next robh/for-next linus/master v5.17-rc7 next-20220310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 58dedf0a4782ce42b4d31f1f62e5ad80a1b73d72
config: arm-defconfig (https://download.01.org/0day-ci/archive/20220311/202203112000.DIc9zr62-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/9fbfc32473a65e025764e0a1456c421b4706fe8e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
        git checkout 9fbfc32473a65e025764e0a1456c421b4706fe8e
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All warnings (new ones prefixed by >>):

>> arch/arm/mach-hpe/gxp.c:26:13: warning: no previous prototype for 'gxp_map_io' [-Wmissing-prototypes]
      26 | void __init gxp_map_io(void)
         |             ^~~~~~~~~~


vim +/gxp_map_io +26 arch/arm/mach-hpe/gxp.c

    25	
  > 26	void __init gxp_map_io(void)
    27	{
    28		iotable_init(gxp_io_desc, ARRAY_SIZE(gxp_io_desc));
    29	}
    30	

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding
  2022-03-10 19:52 ` [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding nick.hawkins
  2022-03-11  9:32   ` Krzysztof Kozlowski
@ 2022-03-11 15:40   ` Rob Herring
  2022-03-11 16:22     ` Hawkins, Nick
  1 sibling, 1 reply; 80+ messages in thread
From: Rob Herring @ 2022-03-11 15:40 UTC (permalink / raw)
  To: nick.hawkins
  Cc: verdun, Daniel Lezcano, Thomas Gleixner, linux-kernel, devicetree

On Thu, Mar 10, 2022 at 01:52:24PM -0600, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> Creating binding for gxp timer in device tree hpe,gxp-timer
> Although there are multiple times on the SoC we are only
> enabling one at this time.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> 
> ----
> 
> v2:
>  *Removed maintainer change from patch
>  *Verified there was no compilation errors
>  *Added reference code in separate patch of patchset
> ---
>  .../bindings/timer/hpe,gxp-timer.yaml         | 45 +++++++++++++++++++
>  1 file changed, 45 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
> 
> diff --git a/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
> new file mode 100644
> index 000000000000..1f4e345c5fb8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/timer/hpe,gxp-timer.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HPE GXP TIMER
> +
> +maintainers:
> +  - Nick Hawkins <nick.hawkins@hpe.com>
> +  - Jean-Marie Verdun <verdun@hpe.com>
> +
> +properties:
> +  compatible:
> +    const: hpe,gxp-timer
> +
> +  reg:
> +    items:
> +      - description: T0CNT register
> +      - description: T0CS register
> +      - description: TIMELO register

Is the spec public to know what T0CNT, T0CS, and TIMELO are?

> +
> +  interrupts:
> +    maxItems: 1
> +
> +  clock-frequency:
> +    description: The frequency of the clock that drives the counter, in Hz.
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clock-frequency
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    timer@10003000 {
> +        compatible = "hpe,gxp-timer";
> +        reg = <0xc0000080 0x1>, <0xc0000094 0x01>, <0xc0000088 0x08>;

Based on the driver these are 4 bytes, 1 byte, 4 bytes in size.

Are there other registers in 0x80-0x95 range or do these offsets change 
in other chips? If not, just 1 entry covering the whole thing would be 
better.

> +        interrupts = <0>;
> +        interrupt-parent = <&vic0>;
> +        clock-frequency = <400000000>;
> +    };
> -- 
> 2.17.1
> 
> 

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding
  2022-03-11 15:40   ` Rob Herring
@ 2022-03-11 16:22     ` Hawkins, Nick
  2022-03-11 17:13       ` Krzysztof Kozlowski
  0 siblings, 1 reply; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-11 16:22 UTC (permalink / raw)
  To: Rob Herring
  Cc: Verdun, Jean-Marie, Daniel Lezcano, Thomas Gleixner,
	linux-kernel, devicetree

On Thu, Mar 10, 2022 at 01:52:24PM -0600, nick.hawkins@hpe.com wrote:
>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>> 
>> Creating binding for gxp timer in device tree hpe,gxp-timer Although 
>> there are multiple times on the SoC we are only enabling one at this 
>> time.
>> 
>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>> 
>> ----
>> 
>> v2:
>>  *Removed maintainer change from patch  *Verified there was no 
>> compilation errors  *Added reference code in separate patch of 
>> patchset
>> ---
>>  .../bindings/timer/hpe,gxp-timer.yaml         | 45 +++++++++++++++++++
>>  1 file changed, 45 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml 
>> b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>> new file mode 100644
>> index 000000000000..1f4e345c5fb8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>> @@ -0,0 +1,45 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>> +---
>> +$id: 
>> +INVALID URI REMOVED
>> +xp-timer.yaml*__;Iw!!NpxR!yaItMPvjqEf3fKyp1xDQAzawRQDd8uDGTNKMlVPpn5Y
>> +56IUABMYbali7jonBl20K$
>> +$schema: 
>> +INVALID URI REMOVED
>> +aml*__;Iw!!NpxR!yaItMPvjqEf3fKyp1xDQAzawRQDd8uDGTNKMlVPpn5Y56IUABMYba
>> +li7jmX565-G$
>> +
>> +title: HPE GXP TIMER
>> +
>> +maintainers:
>> +  - Nick Hawkins <nick.hawkins@hpe.com>>
>> +  - Jean-Marie Verdun <verdun@hpe.com>>
>> +
>> +properties:
>> +  compatible:
>> +    const: hpe,gxp-timer
>> +
>> +  reg:
>> +    items:
>> +      - description: T0CNT register
>> +      - description: T0CS register
>> +      - description: TIMELO register

> Is the spec public to know what T0CNT, T0CS, and TIMELO are?
No it is not, should I not mention the register descriptions at all?

>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  clock-frequency:
>> +    description: The frequency of the clock that drives the counter, in Hz.
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - interrupts
>> +  - clock-frequency
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    timer@10003000 {
>> +        compatible = "hpe,gxp-timer";
>> +        reg = <0xc0000080 0x1>>, <0xc0000094 0x01>>, <0xc0000088 0x08>>;

> Based on the driver these are 4 bytes, 1 byte, 4 bytes in size.

> Are there other registers in 0x80-0x95 range or do these offsets change in other chips? If not, just 1 entry covering the whole thing would be better.
There are other registers in this range that cover different timers/clocks, for the most part between chip generations the offsets remain the same unless there is an architectural issue.
Can you provide a quick example of what one entry would be?

>> +        interrupts = <0>>;
>> +        interrupt-parent = <&vic0>>;
>> +        clock-frequency = <400000000>>;
>> +    };
>> --
>> 2.17.1
>> 
>> 

Regards,

Nick Hawkins 

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding
  2022-03-11 16:22     ` Hawkins, Nick
@ 2022-03-11 17:13       ` Krzysztof Kozlowski
  0 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-11 17:13 UTC (permalink / raw)
  To: Hawkins, Nick, Rob Herring
  Cc: Verdun, Jean-Marie, Daniel Lezcano, Thomas Gleixner,
	linux-kernel, devicetree

On 11/03/2022 17:22, Hawkins, Nick wrote:
> On Thu, Mar 10, 2022 at 01:52:24PM -0600, nick.hawkins@hpe.com wrote:
>>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>>>
>>> Creating binding for gxp timer in device tree hpe,gxp-timer Although 
>>> there are multiple times on the SoC we are only enabling one at this 
>>> time.
>>>
>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>>>
>>> ----
>>>
>>> v2:
>>>  *Removed maintainer change from patch  *Verified there was no 
>>> compilation errors  *Added reference code in separate patch of 
>>> patchset
>>> ---
>>>  .../bindings/timer/hpe,gxp-timer.yaml         | 45 +++++++++++++++++++
>>>  1 file changed, 45 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml 
>>> b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>>> new file mode 100644
>>> index 000000000000..1f4e345c5fb8
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
>>> @@ -0,0 +1,45 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>>> +---
>>> +$id: 
>>> +INVALID URI REMOVED
>>> +xp-timer.yaml*__;Iw!!NpxR!yaItMPvjqEf3fKyp1xDQAzawRQDd8uDGTNKMlVPpn5Y
>>> +56IUABMYbali7jonBl20K$
>>> +$schema: 
>>> +INVALID URI REMOVED
>>> +aml*__;Iw!!NpxR!yaItMPvjqEf3fKyp1xDQAzawRQDd8uDGTNKMlVPpn5Y56IUABMYba
>>> +li7jmX565-G$
>>> +
>>> +title: HPE GXP TIMER
>>> +
>>> +maintainers:
>>> +  - Nick Hawkins <nick.hawkins@hpe.com>>
>>> +  - Jean-Marie Verdun <verdun@hpe.com>>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    const: hpe,gxp-timer
>>> +
>>> +  reg:
>>> +    items:
>>> +      - description: T0CNT register
>>> +      - description: T0CS register
>>> +      - description: TIMELO register
> 
>> Is the spec public to know what T0CNT, T0CS, and TIMELO are?
> No it is not, should I not mention the register descriptions at all?
> 
>>> +
>>> +  interrupts:
>>> +    maxItems: 1
>>> +
>>> +  clock-frequency:
>>> +    description: The frequency of the clock that drives the counter, in Hz.
>>> +
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +  - interrupts
>>> +  - clock-frequency
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    timer@10003000 {
>>> +        compatible = "hpe,gxp-timer";
>>> +        reg = <0xc0000080 0x1>>, <0xc0000094 0x01>>, <0xc0000088 0x08>>;
> 
>> Based on the driver these are 4 bytes, 1 byte, 4 bytes in size.
> 
>> Are there other registers in 0x80-0x95 range or do these offsets change in other chips? If not, just 1 entry covering the whole thing would be better.
> There are other registers in this range that cover different timers/clocks, for the most part between chip generations the offsets remain the same unless there is an architectural issue.
> Can you provide a quick example of what one entry would be?

arch/arm/boot/dts/versatile-ab.dts

and actually 90% of DTS... it's rather a challange to find such
fine-grained iomap.

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
  2022-03-10 19:52 ` nick.hawkins
@ 2022-03-12 13:27   ` kernel test robot
  -1 siblings, 0 replies; 80+ messages in thread
From: kernel test robot @ 2022-03-12 13:27 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: kbuild-all, Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

Hi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/timers/core]
[also build test ERROR on soc/for-next robh/for-next linus/master v5.17-rc7 next-20220310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 58dedf0a4782ce42b4d31f1f62e5ad80a1b73d72
config: arm-randconfig-c002-20220312 (https://download.01.org/0day-ci/archive/20220312/202203122119.szjgiy49-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/9fbfc32473a65e025764e0a1456c421b4706fe8e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
        git checkout 9fbfc32473a65e025764e0a1456c421b4706fe8e
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   drivers/memstick/host/r592.c:47:13: warning: no previous prototype for 'memstick_debug_get_tpc_name' [-Wmissing-prototypes]
      47 | const char *memstick_debug_get_tpc_name(int tpc)
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   init/main.c:768:20: warning: no previous prototype for 'arch_post_acpi_subsys_init' [-Wmissing-prototypes]
     768 | void __init __weak arch_post_acpi_subsys_init(void) { }
         |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
   init/main.c:780:20: warning: no previous prototype for 'mem_encrypt_init' [-Wmissing-prototypes]
     780 | void __init __weak mem_encrypt_init(void) { }
         |                    ^~~~~~~~~~~~~~~~
   init/main.c:782:20: warning: no previous prototype for 'poking_init' [-Wmissing-prototypes]
     782 | void __init __weak poking_init(void) { }
         |                    ^~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   init/calibrate.c:261:37: warning: no previous prototype for 'calibrate_delay_is_known' [-Wmissing-prototypes]
     261 | unsigned long __attribute__((weak)) calibrate_delay_is_known(void)
         |                                     ^~~~~~~~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/ptrace.c:854:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes]
     854 | asmlinkage int syscall_trace_enter(struct pt_regs *regs)
         |                ^~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/ptrace.c:882:17: warning: no previous prototype for 'syscall_trace_exit' [-Wmissing-prototypes]
     882 | asmlinkage void syscall_trace_exit(struct pt_regs *regs)
         |                 ^~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/reboot.c:78:6: warning: no previous prototype for 'soft_restart' [-Wmissing-prototypes]
      78 | void soft_restart(unsigned long addr)
         |      ^~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/signal.c:186:16: warning: no previous prototype for 'sys_sigreturn' [-Wmissing-prototypes]
     186 | asmlinkage int sys_sigreturn(struct pt_regs *regs)
         |                ^~~~~~~~~~~~~
   arch/arm/kernel/signal.c:216:16: warning: no previous prototype for 'sys_rt_sigreturn' [-Wmissing-prototypes]
     216 | asmlinkage int sys_rt_sigreturn(struct pt_regs *regs)
         |                ^~~~~~~~~~~~~~~~
   arch/arm/kernel/signal.c:601:1: warning: no previous prototype for 'do_work_pending' [-Wmissing-prototypes]
     601 | do_work_pending(struct pt_regs *regs, unsigned int thread_flags, int syscall)
         | ^~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/sys_arm.c:32:17: warning: no previous prototype for 'sys_arm_fadvise64_64' [-Wmissing-prototypes]
      32 | asmlinkage long sys_arm_fadvise64_64(int fd, int advice,
         |                 ^~~~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/time.c:88:13: warning: no previous prototype for 'time_init' [-Wmissing-prototypes]
      88 | void __init time_init(void)
         |             ^~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/traps.c:84:6: warning: no previous prototype for 'dump_backtrace_stm' [-Wmissing-prototypes]
      84 | void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
         |      ^~~~~~~~~~~~~~~~~~
   arch/arm/kernel/traps.c:433:17: warning: no previous prototype for 'do_undefinstr' [-Wmissing-prototypes]
     433 | asmlinkage void do_undefinstr(struct pt_regs *regs)
         |                 ^~~~~~~~~~~~~
   arch/arm/kernel/traps.c:498:39: warning: no previous prototype for 'handle_fiq_as_nmi' [-Wmissing-prototypes]
     498 | asmlinkage void __exception_irq_entry handle_fiq_as_nmi(struct pt_regs *regs)
         |                                       ^~~~~~~~~~~~~~~~~
   arch/arm/kernel/traps.c:517:17: warning: no previous prototype for 'bad_mode' [-Wmissing-prototypes]
     517 | asmlinkage void bad_mode(struct pt_regs *regs, int reason)
         |                 ^~~~~~~~
   arch/arm/kernel/traps.c:590:16: warning: no previous prototype for 'arm_syscall' [-Wmissing-prototypes]
     590 | asmlinkage int arm_syscall(int no, struct pt_regs *regs)
         |                ^~~~~~~~~~~
   arch/arm/kernel/traps.c:716:1: warning: no previous prototype for 'baddataabort' [-Wmissing-prototypes]
     716 | baddataabort(int code, unsigned long instr, struct pt_regs *regs)
         | ^~~~~~~~~~~~
   arch/arm/kernel/traps.c:756:17: warning: no previous prototype for '__div0' [-Wmissing-prototypes]
     756 | asmlinkage void __div0(void)
         |                 ^~~~~~
   arch/arm/kernel/traps.c:763:6: warning: no previous prototype for 'abort' [-Wmissing-prototypes]
     763 | void abort(void)
         |      ^~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/suspend.c:75:6: warning: no previous prototype for '__cpu_suspend_save' [-Wmissing-prototypes]
      75 | void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
         |      ^~~~~~~~~~~~~~~~~~
..

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-12 13:27   ` kernel test robot
  0 siblings, 0 replies; 80+ messages in thread
From: kernel test robot @ 2022-03-12 13:27 UTC (permalink / raw)
  To: nick.hawkins, verdun
  Cc: kbuild-all, Nick Hawkins, Russell King, linux-arm-kernel, linux-kernel

Hi,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/timers/core]
[also build test ERROR on soc/for-next robh/for-next linus/master v5.17-rc7 next-20220310]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 58dedf0a4782ce42b4d31f1f62e5ad80a1b73d72
config: arm-randconfig-c002-20220312 (https://download.01.org/0day-ci/archive/20220312/202203122119.szjgiy49-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/9fbfc32473a65e025764e0a1456c421b4706fe8e
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review nick-hawkins-hpe-com/arch-arm-mach-hpe-Introduce-the-HPE-GXP-architecture/20220311-035513
        git checkout 9fbfc32473a65e025764e0a1456c421b4706fe8e
        # save the config file to linux build tree
        mkdir build_dir
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   drivers/memstick/host/r592.c:47:13: warning: no previous prototype for 'memstick_debug_get_tpc_name' [-Wmissing-prototypes]
      47 | const char *memstick_debug_get_tpc_name(int tpc)
         |             ^~~~~~~~~~~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   init/main.c:768:20: warning: no previous prototype for 'arch_post_acpi_subsys_init' [-Wmissing-prototypes]
     768 | void __init __weak arch_post_acpi_subsys_init(void) { }
         |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~
   init/main.c:780:20: warning: no previous prototype for 'mem_encrypt_init' [-Wmissing-prototypes]
     780 | void __init __weak mem_encrypt_init(void) { }
         |                    ^~~~~~~~~~~~~~~~
   init/main.c:782:20: warning: no previous prototype for 'poking_init' [-Wmissing-prototypes]
     782 | void __init __weak poking_init(void) { }
         |                    ^~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   init/calibrate.c:261:37: warning: no previous prototype for 'calibrate_delay_is_known' [-Wmissing-prototypes]
     261 | unsigned long __attribute__((weak)) calibrate_delay_is_known(void)
         |                                     ^~~~~~~~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/ptrace.c:854:16: warning: no previous prototype for 'syscall_trace_enter' [-Wmissing-prototypes]
     854 | asmlinkage int syscall_trace_enter(struct pt_regs *regs)
         |                ^~~~~~~~~~~~~~~~~~~
   arch/arm/kernel/ptrace.c:882:17: warning: no previous prototype for 'syscall_trace_exit' [-Wmissing-prototypes]
     882 | asmlinkage void syscall_trace_exit(struct pt_regs *regs)
         |                 ^~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/reboot.c:78:6: warning: no previous prototype for 'soft_restart' [-Wmissing-prototypes]
      78 | void soft_restart(unsigned long addr)
         |      ^~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/signal.c:186:16: warning: no previous prototype for 'sys_sigreturn' [-Wmissing-prototypes]
     186 | asmlinkage int sys_sigreturn(struct pt_regs *regs)
         |                ^~~~~~~~~~~~~
   arch/arm/kernel/signal.c:216:16: warning: no previous prototype for 'sys_rt_sigreturn' [-Wmissing-prototypes]
     216 | asmlinkage int sys_rt_sigreturn(struct pt_regs *regs)
         |                ^~~~~~~~~~~~~~~~
   arch/arm/kernel/signal.c:601:1: warning: no previous prototype for 'do_work_pending' [-Wmissing-prototypes]
     601 | do_work_pending(struct pt_regs *regs, unsigned int thread_flags, int syscall)
         | ^~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/sys_arm.c:32:17: warning: no previous prototype for 'sys_arm_fadvise64_64' [-Wmissing-prototypes]
      32 | asmlinkage long sys_arm_fadvise64_64(int fd, int advice,
         |                 ^~~~~~~~~~~~~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/time.c:88:13: warning: no previous prototype for 'time_init' [-Wmissing-prototypes]
      88 | void __init time_init(void)
         |             ^~~~~~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/traps.c:84:6: warning: no previous prototype for 'dump_backtrace_stm' [-Wmissing-prototypes]
      84 | void dump_backtrace_stm(u32 *stack, u32 instruction, const char *loglvl)
         |      ^~~~~~~~~~~~~~~~~~
   arch/arm/kernel/traps.c:433:17: warning: no previous prototype for 'do_undefinstr' [-Wmissing-prototypes]
     433 | asmlinkage void do_undefinstr(struct pt_regs *regs)
         |                 ^~~~~~~~~~~~~
   arch/arm/kernel/traps.c:498:39: warning: no previous prototype for 'handle_fiq_as_nmi' [-Wmissing-prototypes]
     498 | asmlinkage void __exception_irq_entry handle_fiq_as_nmi(struct pt_regs *regs)
         |                                       ^~~~~~~~~~~~~~~~~
   arch/arm/kernel/traps.c:517:17: warning: no previous prototype for 'bad_mode' [-Wmissing-prototypes]
     517 | asmlinkage void bad_mode(struct pt_regs *regs, int reason)
         |                 ^~~~~~~~
   arch/arm/kernel/traps.c:590:16: warning: no previous prototype for 'arm_syscall' [-Wmissing-prototypes]
     590 | asmlinkage int arm_syscall(int no, struct pt_regs *regs)
         |                ^~~~~~~~~~~
   arch/arm/kernel/traps.c:716:1: warning: no previous prototype for 'baddataabort' [-Wmissing-prototypes]
     716 | baddataabort(int code, unsigned long instr, struct pt_regs *regs)
         | ^~~~~~~~~~~~
   arch/arm/kernel/traps.c:756:17: warning: no previous prototype for '__div0' [-Wmissing-prototypes]
     756 | asmlinkage void __div0(void)
         |                 ^~~~~~
   arch/arm/kernel/traps.c:763:6: warning: no previous prototype for 'abort' [-Wmissing-prototypes]
     763 | void abort(void)
         |      ^~~~~
--
>> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]
   arch/arm/kernel/suspend.c:75:6: warning: no previous prototype for '__cpu_suspend_save' [-Wmissing-prototypes]
      75 | void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr)
         |      ^~~~~~~~~~~~~~~~~~
..

---
0-DAY CI Kernel Test Service
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
  2022-03-12 13:27   ` kernel test robot
  (?)
@ 2022-03-12 15:14     ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-12 15:14 UTC (permalink / raw)
  To: kernel test robot
  Cc: Hawkins, Nick, Verdun, Jean-Marie, kbuild-all, Russell King,
	Linux ARM, Linux Kernel Mailing List

On Sat, Mar 12, 2022 at 2:27 PM kernel test robot <lkp@intel.com> wrote:

>
> All error/warnings (new ones prefixed by >>):
>
> >> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]

You need to make CONFIG_ARCH_HPE depend on CONFIG_ARCH_MULTI_V7, otherwise
it becomes possible to select this for non-multiplatform configs that expect
an include directory below the platform.

       Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-12 15:14     ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-12 15:14 UTC (permalink / raw)
  To: kernel test robot
  Cc: Hawkins, Nick, Verdun, Jean-Marie, kbuild-all, Russell King,
	Linux ARM, Linux Kernel Mailing List

On Sat, Mar 12, 2022 at 2:27 PM kernel test robot <lkp@intel.com> wrote:

>
> All error/warnings (new ones prefixed by >>):
>
> >> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]

You need to make CONFIG_ARCH_HPE depend on CONFIG_ARCH_MULTI_V7, otherwise
it becomes possible to select this for non-multiplatform configs that expect
an include directory below the platform.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture
@ 2022-03-12 15:14     ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-12 15:14 UTC (permalink / raw)
  To: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 440 bytes --]

On Sat, Mar 12, 2022 at 2:27 PM kernel test robot <lkp@intel.com> wrote:

>
> All error/warnings (new ones prefixed by >>):
>
> >> cc1: warning: arch/arm/mach-hpe/include: No such file or directory [-Wmissing-include-dirs]

You need to make CONFIG_ARCH_HPE depend on CONFIG_ARCH_MULTI_V7, otherwise
it becomes possible to select this for non-multiplatform configs that expect
an include directory below the platform.

       Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-11 10:29     ` Krzysztof Kozlowski
@ 2022-03-16 15:41       ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-16 15:41 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

-----Original Message-----
From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
Sent: Friday, March 11, 2022 4:30 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>>; Verdun, Jean-Marie <verdun@hpe.com>>
Cc: Arnd Bergmann <arnd@arndb.de>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>> 
>> The HPE SoC is new to linux. This patch creates the basic device tree 
>> layout with minimum required for linux to boot. This includes timer 
>> and watchdog support.
>> 
>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>> ---
>>  arch/arm/boot/dts/Makefile               |   2 +
>>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>>  3 files changed, 177 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>> 
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>> index e41eca79c950..2823b359d373 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>  	aspeed-bmc-vegman-n110.dtb \
>>  	aspeed-bmc-vegman-rx20.dtb \
>>  	aspeed-bmc-vegman-sx20.dtb
>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>> +	hpe-bmc-dl360gen10.dtb

> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.

Done

>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>> new file mode 100644
>> index 000000000000..da5eac1213a8
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>> @@ -0,0 +1,27 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree file for HPE DL360Gen10  */
>> +
>> +/include/ "hpe-gxp.dtsi"
>> +
>> +/ {
>> +	#address-cells = <1>>;
>> +	#size-cells = <1>>;
>> +	compatible = "hpe,gxp";

> Missing board compatible.

Will become compatible =  "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.

>> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>> +
>> +	chosen {
>> +		bootargs = "earlyprintk console=ttyS2,115200";

> I have impression we talked about it...

Removed!

>> +	};
>> +
>> +	memory@40000000 {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0x20000000>>;
>> +	};
>> +
>> +	ahb {

> Why do you need empty node?

I do not, this was a placeholder for after the initial checkin where I would put all the board specific stuff. This has been removed.

>> +
>> +	};
>> +
>> +};
>> diff --git a/arch/arm/boot/dts/hpe-gxp.dtsi 
>> b/arch/arm/boot/dts/hpe-gxp.dtsi new file mode 100644 index 
>> 000000000000..dfaf8df829fe
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/hpe-gxp.dtsi
>> @@ -0,0 +1,148 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree file for HPE GXP
>> + */
>> +
>> +/dts-v1/;
>> +/ {
>> +	model = "Hewlett Packard Enterprise GXP BMC";
>> +	compatible = "hpe,gxp";
>> +	#address-cells = <1>>;
>> +	#size-cells = <1>>;
>> +
>> +	cpus {
>> +		#address-cells = <1>>;
>> +		#size-cells = <0>>;
>> +
>> +		cpu@0 {
>> +			compatible = "arm,cortex-a9";
>> +			device_type = "cpu";
>> +			reg = <0>>;
>> +		};
>> +	};
>> +
>> +	gxp-init@cefe0010 {

> Need a generic node name. gpx-init is specific.

Will do. But more than likely this is going to get removed as I try to push this option into the bootloader.

>> +		compatible = "hpe,gxp-cpu-init";
>> +		reg = <0xcefe0010 0x04>>;
>> +	};
>> +
>> +	memory@40000000 {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0x20000000>>;
>> +	};
>> +
>> +	ahb {

> By convention we call it soc.

>> +		compatible = "simple-bus";
>> +		#address-cells = <1>>;
>> +		#size-cells = <1>>;
>> +		device_type = "soc";
>> +		ranges;
>> +
>> +		vic0: interrupt-controller@ceff0000 {
>> +			compatible = "arm,pl192-vic";
>> +			interrupt-controller;
>> +			reg = <0xceff0000 0x1000>>;

> Please put reg after compatible, everywhere.

Done

>> +			#interrupt-cells = <1>>;
>> +		};
>> +
>> +		vic1: interrupt-controller@80f00000 {
>> +			compatible = "arm,pl192-vic";
>> +			interrupt-controller;
>> +			reg = <0x80f00000 0x1000>>;
>> +			#interrupt-cells = <1>>;
>> +		};
>> +
>> +		timer0: timer@c0000080 {
>> +			compatible = "hpe,gxp-timer";
>> +			reg = <0xc0000080 0x1>>, <0xc0000094 0x01>>, <0xc0000088 0x08>>;
>> +			interrupts = <0>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <400000000>>;
>> +		};
>> +
>> +		uarta: serial@c00000e0 {
>> +			compatible = "ns16550a";
>> +			reg = <0xc00000e0 0x8>>;
>> +			interrupts = <17>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <1846153>>;
>> +			reg-shift = <0>>;
>> +		};
>> +
>> +		uartb: serial@c00000e8 {
>> +			compatible = "ns16550a";
>> +			reg = <0xc00000e8 0x8>>;
>> +			interrupts = <18>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <1846153>>;
>> +			reg-shift = <0>>;
>> +		};
>> +
>> +		uartc: serial@c00000f0 {
>> +			compatible = "ns16550a";
>> +			reg = <0xc00000f0 0x8>>;
>> +			interrupts = <19>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <1846153>>;
>> +			reg-shift = <0>>;
>> +		};
>> +
>> +		usb0: usb@cefe0000 {
>> +			compatible = "generic-ehci";

> I think one of previous comments was that you cannot have "generic-ehci"
> only, right?

Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?

>> +			reg = <0xcefe0000 0x100>>;
>> +			interrupts = <7>>;
>> +			interrupt-parent = <&vic0>>;
>> +		};
>> +
>> +		usb1: usb@cefe0100 {
>> +			compatible = "generic-ohci";
>> +			reg = <0xcefe0100 0x110>>;
>> +			interrupts = <6>>;
>> +			interrupt-parent = <&vic0>>;
>> +		};
>> +
>> +		vrom@58000000 {
>> +			compatible = "mtd-ram";
>> +			bank-width = <4>>;
>> +			reg = <0x58000000 0x4000000>>;
>> +			#address-cells = <1>>;
>> +			#size-cells = <1>>;
>> +			partition@0 {
>> +				label = "vrom-prime";
>> +				reg = <0x0 0x2000000>>;
>> +			};
>> +			partition@2000000 {
>> +				label = "vrom-second";
>> +				reg = <0x2000000 0x2000000>>;
>> +			};
>> +		};
>> +
>> +		i2cg: syscon@c00000f8 {


>> +			compatible = "simple-mfd", "syscon";
>> +			reg = <0xc00000f8 0x08>>;
>> +		};
>> +	};
>> +
>> +	clocks {
>> +		osc: osc {

> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?

We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.

>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>>;
>> +			clock-output-names = "osc";
>> +			clock-frequency = <33333333>>;
>> +		};
>> +
>> +		iopclk: iopclk {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>>;
>> +			clock-output-names = "iopclk";
>> +			clock-frequency = <400000000>>;
>> +		};
>> +
>> +		memclk: memclk {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>>;
>> +			clock-output-names = "memclk";
>> +			clock-frequency = <800000000>>;
>> +		};

> What are these clocks? If external to the SoC, then where are they? On the board?

This was the internal iopclk and memclk they were both internal to the chip.
For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.

>> +	};
>> +};

Thanks,

-Nick

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-16 15:41       ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-16 15:41 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

-----Original Message-----
From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
Sent: Friday, March 11, 2022 4:30 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>>; Verdun, Jean-Marie <verdun@hpe.com>>
Cc: Arnd Bergmann <arnd@arndb.de>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>> 
>> The HPE SoC is new to linux. This patch creates the basic device tree 
>> layout with minimum required for linux to boot. This includes timer 
>> and watchdog support.
>> 
>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>> ---
>>  arch/arm/boot/dts/Makefile               |   2 +
>>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>>  3 files changed, 177 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>> 
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>> index e41eca79c950..2823b359d373 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>  	aspeed-bmc-vegman-n110.dtb \
>>  	aspeed-bmc-vegman-rx20.dtb \
>>  	aspeed-bmc-vegman-sx20.dtb
>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>> +	hpe-bmc-dl360gen10.dtb

> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.

Done

>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>> new file mode 100644
>> index 000000000000..da5eac1213a8
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>> @@ -0,0 +1,27 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree file for HPE DL360Gen10  */
>> +
>> +/include/ "hpe-gxp.dtsi"
>> +
>> +/ {
>> +	#address-cells = <1>>;
>> +	#size-cells = <1>>;
>> +	compatible = "hpe,gxp";

> Missing board compatible.

Will become compatible =  "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.

>> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>> +
>> +	chosen {
>> +		bootargs = "earlyprintk console=ttyS2,115200";

> I have impression we talked about it...

Removed!

>> +	};
>> +
>> +	memory@40000000 {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0x20000000>>;
>> +	};
>> +
>> +	ahb {

> Why do you need empty node?

I do not, this was a placeholder for after the initial checkin where I would put all the board specific stuff. This has been removed.

>> +
>> +	};
>> +
>> +};
>> diff --git a/arch/arm/boot/dts/hpe-gxp.dtsi 
>> b/arch/arm/boot/dts/hpe-gxp.dtsi new file mode 100644 index 
>> 000000000000..dfaf8df829fe
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/hpe-gxp.dtsi
>> @@ -0,0 +1,148 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree file for HPE GXP
>> + */
>> +
>> +/dts-v1/;
>> +/ {
>> +	model = "Hewlett Packard Enterprise GXP BMC";
>> +	compatible = "hpe,gxp";
>> +	#address-cells = <1>>;
>> +	#size-cells = <1>>;
>> +
>> +	cpus {
>> +		#address-cells = <1>>;
>> +		#size-cells = <0>>;
>> +
>> +		cpu@0 {
>> +			compatible = "arm,cortex-a9";
>> +			device_type = "cpu";
>> +			reg = <0>>;
>> +		};
>> +	};
>> +
>> +	gxp-init@cefe0010 {

> Need a generic node name. gpx-init is specific.

Will do. But more than likely this is going to get removed as I try to push this option into the bootloader.

>> +		compatible = "hpe,gxp-cpu-init";
>> +		reg = <0xcefe0010 0x04>>;
>> +	};
>> +
>> +	memory@40000000 {
>> +		device_type = "memory";
>> +		reg = <0x40000000 0x20000000>>;
>> +	};
>> +
>> +	ahb {

> By convention we call it soc.

>> +		compatible = "simple-bus";
>> +		#address-cells = <1>>;
>> +		#size-cells = <1>>;
>> +		device_type = "soc";
>> +		ranges;
>> +
>> +		vic0: interrupt-controller@ceff0000 {
>> +			compatible = "arm,pl192-vic";
>> +			interrupt-controller;
>> +			reg = <0xceff0000 0x1000>>;

> Please put reg after compatible, everywhere.

Done

>> +			#interrupt-cells = <1>>;
>> +		};
>> +
>> +		vic1: interrupt-controller@80f00000 {
>> +			compatible = "arm,pl192-vic";
>> +			interrupt-controller;
>> +			reg = <0x80f00000 0x1000>>;
>> +			#interrupt-cells = <1>>;
>> +		};
>> +
>> +		timer0: timer@c0000080 {
>> +			compatible = "hpe,gxp-timer";
>> +			reg = <0xc0000080 0x1>>, <0xc0000094 0x01>>, <0xc0000088 0x08>>;
>> +			interrupts = <0>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <400000000>>;
>> +		};
>> +
>> +		uarta: serial@c00000e0 {
>> +			compatible = "ns16550a";
>> +			reg = <0xc00000e0 0x8>>;
>> +			interrupts = <17>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <1846153>>;
>> +			reg-shift = <0>>;
>> +		};
>> +
>> +		uartb: serial@c00000e8 {
>> +			compatible = "ns16550a";
>> +			reg = <0xc00000e8 0x8>>;
>> +			interrupts = <18>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <1846153>>;
>> +			reg-shift = <0>>;
>> +		};
>> +
>> +		uartc: serial@c00000f0 {
>> +			compatible = "ns16550a";
>> +			reg = <0xc00000f0 0x8>>;
>> +			interrupts = <19>>;
>> +			interrupt-parent = <&vic0>>;
>> +			clock-frequency = <1846153>>;
>> +			reg-shift = <0>>;
>> +		};
>> +
>> +		usb0: usb@cefe0000 {
>> +			compatible = "generic-ehci";

> I think one of previous comments was that you cannot have "generic-ehci"
> only, right?

Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?

>> +			reg = <0xcefe0000 0x100>>;
>> +			interrupts = <7>>;
>> +			interrupt-parent = <&vic0>>;
>> +		};
>> +
>> +		usb1: usb@cefe0100 {
>> +			compatible = "generic-ohci";
>> +			reg = <0xcefe0100 0x110>>;
>> +			interrupts = <6>>;
>> +			interrupt-parent = <&vic0>>;
>> +		};
>> +
>> +		vrom@58000000 {
>> +			compatible = "mtd-ram";
>> +			bank-width = <4>>;
>> +			reg = <0x58000000 0x4000000>>;
>> +			#address-cells = <1>>;
>> +			#size-cells = <1>>;
>> +			partition@0 {
>> +				label = "vrom-prime";
>> +				reg = <0x0 0x2000000>>;
>> +			};
>> +			partition@2000000 {
>> +				label = "vrom-second";
>> +				reg = <0x2000000 0x2000000>>;
>> +			};
>> +		};
>> +
>> +		i2cg: syscon@c00000f8 {


>> +			compatible = "simple-mfd", "syscon";
>> +			reg = <0xc00000f8 0x08>>;
>> +		};
>> +	};
>> +
>> +	clocks {
>> +		osc: osc {

> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?

We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.

>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>>;
>> +			clock-output-names = "osc";
>> +			clock-frequency = <33333333>>;
>> +		};
>> +
>> +		iopclk: iopclk {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>>;
>> +			clock-output-names = "iopclk";
>> +			clock-frequency = <400000000>>;
>> +		};
>> +
>> +		memclk: memclk {
>> +			compatible = "fixed-clock";
>> +			#clock-cells = <0>>;
>> +			clock-output-names = "memclk";
>> +			clock-frequency = <800000000>>;
>> +		};

> What are these clocks? If external to the SoC, then where are they? On the board?

This was the internal iopclk and memclk they were both internal to the chip.
For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.

>> +	};
>> +};

Thanks,

-Nick
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-16 15:41       ` Hawkins, Nick
@ 2022-03-16 15:50         ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-16 15:50 UTC (permalink / raw)
  To: Hawkins, Nick, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

On 16/03/2022 16:41, Hawkins, Nick wrote:
> -----Original Message-----
> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
> Sent: Friday, March 11, 2022 4:30 AM
> To: Hawkins, Nick <nick.hawkins@hpe.com>>; Verdun, Jean-Marie <verdun@hpe.com>>
> Cc: Arnd Bergmann <arnd@arndb.de>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
> 
> On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>>>
>>> The HPE SoC is new to linux. This patch creates the basic device tree 
>>> layout with minimum required for linux to boot. This includes timer 
>>> and watchdog support.
>>>
>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>>> ---
>>>  arch/arm/boot/dts/Makefile               |   2 +
>>>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>>>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>>>  3 files changed, 177 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>>> index e41eca79c950..2823b359d373 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>>  	aspeed-bmc-vegman-n110.dtb \
>>>  	aspeed-bmc-vegman-rx20.dtb \
>>>  	aspeed-bmc-vegman-sx20.dtb
>>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>>> +	hpe-bmc-dl360gen10.dtb
> 
>> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.
> 
> Done
> 
>>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> new file mode 100644
>>> index 000000000000..da5eac1213a8
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> @@ -0,0 +1,27 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree file for HPE DL360Gen10  */
>>> +
>>> +/include/ "hpe-gxp.dtsi"
>>> +
>>> +/ {
>>> +	#address-cells = <1>>;
>>> +	#size-cells = <1>>;
>>> +	compatible = "hpe,gxp";
> 
>> Missing board compatible.
> 
> Will become compatible =  "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.

Yes, except hpe,gxp goes at the end.

> 
>>> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>>> +

(...)

>>> +
>>> +		usb0: usb@cefe0000 {
>>> +			compatible = "generic-ehci";
> 
>> I think one of previous comments was that you cannot have "generic-ehci"
>> only, right?
> 
> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?

Yes,, see other cases in generic-ehci.yaml bindings. Your current choice
would be pointed out by dtbs_check, that it's invalid according to
current bindings.

> 
>>> +			reg = <0xcefe0000 0x100>>;
>>> +			interrupts = <7>>;
>>> +			interrupt-parent = <&vic0>>;
>>> +		};
>>> +
>>> +		usb1: usb@cefe0100 {
>>> +			compatible = "generic-ohci";
>>> +			reg = <0xcefe0100 0x110>>;
>>> +			interrupts = <6>>;
>>> +			interrupt-parent = <&vic0>>;
>>> +		};
>>> +
>>> +		vrom@58000000 {
>>> +			compatible = "mtd-ram";
>>> +			bank-width = <4>>;
>>> +			reg = <0x58000000 0x4000000>>;
>>> +			#address-cells = <1>>;
>>> +			#size-cells = <1>>;
>>> +			partition@0 {
>>> +				label = "vrom-prime";
>>> +				reg = <0x0 0x2000000>>;
>>> +			};
>>> +			partition@2000000 {
>>> +				label = "vrom-second";
>>> +				reg = <0x2000000 0x2000000>>;
>>> +			};
>>> +		};
>>> +
>>> +		i2cg: syscon@c00000f8 {
> 
> 
>>> +			compatible = "simple-mfd", "syscon";
>>> +			reg = <0xc00000f8 0x08>>;
>>> +		};
>>> +	};
>>> +
>>> +	clocks {
>>> +		osc: osc {
> 
>> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?
> 
> We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.
> 
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>>;
>>> +			clock-output-names = "osc";
>>> +			clock-frequency = <33333333>>;
>>> +		};
>>> +
>>> +		iopclk: iopclk {
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>>;
>>> +			clock-output-names = "iopclk";
>>> +			clock-frequency = <400000000>>;
>>> +		};
>>> +
>>> +		memclk: memclk {
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>>;
>>> +			clock-output-names = "memclk";
>>> +			clock-frequency = <800000000>>;
>>> +		};
> 
>> What are these clocks? If external to the SoC, then where are they? On the board?
> 
> This was the internal iopclk and memclk they were both internal to the chip.
> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.

You should rather have a clock controller driver which defines this (and
many others). They can stay as a temporary work-around, if you really
need them for some other nodes.

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-16 15:50         ` Krzysztof Kozlowski
  0 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-16 15:50 UTC (permalink / raw)
  To: Hawkins, Nick, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

On 16/03/2022 16:41, Hawkins, Nick wrote:
> -----Original Message-----
> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
> Sent: Friday, March 11, 2022 4:30 AM
> To: Hawkins, Nick <nick.hawkins@hpe.com>>; Verdun, Jean-Marie <verdun@hpe.com>>
> Cc: Arnd Bergmann <arnd@arndb.de>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
> 
> On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>>>
>>> The HPE SoC is new to linux. This patch creates the basic device tree 
>>> layout with minimum required for linux to boot. This includes timer 
>>> and watchdog support.
>>>
>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>>> ---
>>>  arch/arm/boot/dts/Makefile               |   2 +
>>>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>>>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>>>  3 files changed, 177 insertions(+)
>>>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>>> index e41eca79c950..2823b359d373 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>>  	aspeed-bmc-vegman-n110.dtb \
>>>  	aspeed-bmc-vegman-rx20.dtb \
>>>  	aspeed-bmc-vegman-sx20.dtb
>>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>>> +	hpe-bmc-dl360gen10.dtb
> 
>> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.
> 
> Done
> 
>>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> new file mode 100644
>>> index 000000000000..da5eac1213a8
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>> @@ -0,0 +1,27 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/*
>>> + * Device Tree file for HPE DL360Gen10  */
>>> +
>>> +/include/ "hpe-gxp.dtsi"
>>> +
>>> +/ {
>>> +	#address-cells = <1>>;
>>> +	#size-cells = <1>>;
>>> +	compatible = "hpe,gxp";
> 
>> Missing board compatible.
> 
> Will become compatible =  "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.

Yes, except hpe,gxp goes at the end.

> 
>>> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>>> +

(...)

>>> +
>>> +		usb0: usb@cefe0000 {
>>> +			compatible = "generic-ehci";
> 
>> I think one of previous comments was that you cannot have "generic-ehci"
>> only, right?
> 
> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?

Yes,, see other cases in generic-ehci.yaml bindings. Your current choice
would be pointed out by dtbs_check, that it's invalid according to
current bindings.

> 
>>> +			reg = <0xcefe0000 0x100>>;
>>> +			interrupts = <7>>;
>>> +			interrupt-parent = <&vic0>>;
>>> +		};
>>> +
>>> +		usb1: usb@cefe0100 {
>>> +			compatible = "generic-ohci";
>>> +			reg = <0xcefe0100 0x110>>;
>>> +			interrupts = <6>>;
>>> +			interrupt-parent = <&vic0>>;
>>> +		};
>>> +
>>> +		vrom@58000000 {
>>> +			compatible = "mtd-ram";
>>> +			bank-width = <4>>;
>>> +			reg = <0x58000000 0x4000000>>;
>>> +			#address-cells = <1>>;
>>> +			#size-cells = <1>>;
>>> +			partition@0 {
>>> +				label = "vrom-prime";
>>> +				reg = <0x0 0x2000000>>;
>>> +			};
>>> +			partition@2000000 {
>>> +				label = "vrom-second";
>>> +				reg = <0x2000000 0x2000000>>;
>>> +			};
>>> +		};
>>> +
>>> +		i2cg: syscon@c00000f8 {
> 
> 
>>> +			compatible = "simple-mfd", "syscon";
>>> +			reg = <0xc00000f8 0x08>>;
>>> +		};
>>> +	};
>>> +
>>> +	clocks {
>>> +		osc: osc {
> 
>> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?
> 
> We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.
> 
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>>;
>>> +			clock-output-names = "osc";
>>> +			clock-frequency = <33333333>>;
>>> +		};
>>> +
>>> +		iopclk: iopclk {
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>>;
>>> +			clock-output-names = "iopclk";
>>> +			clock-frequency = <400000000>>;
>>> +		};
>>> +
>>> +		memclk: memclk {
>>> +			compatible = "fixed-clock";
>>> +			#clock-cells = <0>>;
>>> +			clock-output-names = "memclk";
>>> +			clock-frequency = <800000000>>;
>>> +		};
> 
>> What are these clocks? If external to the SoC, then where are they? On the board?
> 
> This was the internal iopclk and memclk they were both internal to the chip.
> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.

You should rather have a clock controller driver which defines this (and
many others). They can stay as a temporary work-around, if you really
need them for some other nodes.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-16 15:50         ` Krzysztof Kozlowski
@ 2022-03-16 20:10           ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-16 20:10 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>> Sent: Friday, March 11, 2022 4:30 AM
>> To: Hawkins, Nick <nick.hawkins@hpe.com>>>>; Verdun, Jean-Marie 
>> <verdun@hpe.com>>>>
>> Cc: Arnd Bergmann <arnd@arndb.de>>>>; Olof Johansson <olof@lixom.net>>>>; 
>> soc@kernel.org; Rob Herring <robh+dt@kernel.org>>>>; 
>> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; 
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP 
>> Device tree
>> 
>> On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>>>>>> From: Nick Hawkins <nick.hawkins@hpe.com>>>>
>>>>>>
>>>>>> The HPE SoC is new to linux. This patch creates the basic device 
>>>>>> tree layout with minimum required for linux to boot. This includes 
>>>>>> timer and watchdog support.
>>>>>>
>>>>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>>>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/Makefile               |   2 +
>>>>>>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>>>>>>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>>>>>>  3 files changed, 177 insertions(+)
>>>>>>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>>>>>> index e41eca79c950..2823b359d373 100644
>>>>>> --- a/arch/arm/boot/dts/Makefile
>>>>>> +++ b/arch/arm/boot/dts/Makefile
>>>>>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>>>>>  	aspeed-bmc-vegman-n110.dtb \
>>>>>>  	aspeed-bmc-vegman-rx20.dtb \
>>>>>>  	aspeed-bmc-vegman-sx20.dtb
>>>>>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>>>>>> +	hpe-bmc-dl360gen10.dtb
>> 
>>>> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.
>> 
>> Done
>> 
>>>>>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>> new file mode 100644
>>>>>> index 000000000000..da5eac1213a8
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>> @@ -0,0 +1,27 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * Device Tree file for HPE DL360Gen10  */
>>>>>> +
>>>>>> +/include/ "hpe-gxp.dtsi"
>>>>>> +
>>>>>> +/ {
>>>>>> +	#address-cells = <1>>>>;
>>>>>> +	#size-cells = <1>>>>;
>>>>>> +	compatible = "hpe,gxp";
>> 
>>>> Missing board compatible.
>> 
>> Will become compatible =  "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.

> Yes, except hpe,gxp goes at the end.

Done

>> 
>>>>>> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>>>>>> +

(...)

>>>>>> +
>>>>>> +		usb0: usb@cefe0000 {
>>>>>> +			compatible = "generic-ehci";
>> 
>>>> I think one of previous comments was that you cannot have "generic-ehci"
>>>> only, right?
>> 
>> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?

> Yes,, see other cases in generic-ehci.yaml bindings. Your current choice would be pointed out by dtbs_check, that it's invalid according to current bindings.

For some reason when I compile I am not seeing a warning for that file. I have been using "make dtbs_check" and "make dtbs W=1". Perhaps I am missing an important flag?

In the case of creating a hpe,gxp-ehci binding would I need to add that to the generic-ehci.yaml?


>> 
>>>>>> +			reg = <0xcefe0000 0x100>>>>;
>>>>>> +			interrupts = <7>>>>;
>>>>>> +			interrupt-parent = <&vic0>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		usb1: usb@cefe0100 {
>>>>>> +			compatible = "generic-ohci";
>>>>>> +			reg = <0xcefe0100 0x110>>>>;
>>>>>> +			interrupts = <6>>>>;
>>>>>> +			interrupt-parent = <&vic0>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		vrom@58000000 {
>>>>>> +			compatible = "mtd-ram";
>>>>>> +			bank-width = <4>>>>;
>>>>>> +			reg = <0x58000000 0x4000000>>>>;
>>>>>> +			#address-cells = <1>>>>;
>>>>>> +			#size-cells = <1>>>>;
>>>>>> +			partition@0 {
>>>>>> +				label = "vrom-prime";
>>>>>> +				reg = <0x0 0x2000000>>>>;
>>>>>> +			};
>>>>>> +			partition@2000000 {
>>>>>> +				label = "vrom-second";
>>>>>> +				reg = <0x2000000 0x2000000>>>>;
>>>>>> +			};
>>>>>> +		};
>>>>>> +
>>>>>> +		i2cg: syscon@c00000f8 {
>> 
>> 
>>>>>> +			compatible = "simple-mfd", "syscon";
>>>>>> +			reg = <0xc00000f8 0x08>>>>;
>>>>>> +		};
>>>>>> +	};
>>>>>> +
>>>>>> +	clocks {
>>>>>> +		osc: osc {
>> 
>>>> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?
>> 
>> We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.
>> 
>>>>>> +			compatible = "fixed-clock";
>>>>>> +			#clock-cells = <0>>>>;
>>>>>> +			clock-output-names = "osc";
>>>>>> +			clock-frequency = <33333333>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		iopclk: iopclk {
>>>>>> +			compatible = "fixed-clock";
>>>>>> +			#clock-cells = <0>>>>;
>>>>>> +			clock-output-names = "iopclk";
>>>>>> +			clock-frequency = <400000000>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		memclk: memclk {
>>>>>> +			compatible = "fixed-clock";
>>>>>> +			#clock-cells = <0>>>>;
>>>>>> +			clock-output-names = "memclk";
>>>>>> +			clock-frequency = <800000000>>>>;
>>>>>> +		};
>> 
>>>> What are these clocks? If external to the SoC, then where are they? On the board?
>> 
>> This was the internal iopclk and memclk they were both internal to the chip.
>> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.

> You should rather have a clock controller driver which defines this (and many others). They can stay as a temporary work-around, if you really need them for some other nodes.

I am trying to picture what you are saying but I am unsure, I know that on a separate review you mentioned that the gxp-timer needed to have clocks, and clock-names inside the node. Would it be improper for the gxp-timer to reference iopclk?

Thanks!

-Nick Hawkins

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-16 20:10           ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-16 20:10 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

>> -----Original Message-----
>> From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com]
>> Sent: Friday, March 11, 2022 4:30 AM
>> To: Hawkins, Nick <nick.hawkins@hpe.com>>>>; Verdun, Jean-Marie 
>> <verdun@hpe.com>>>>
>> Cc: Arnd Bergmann <arnd@arndb.de>>>>; Olof Johansson <olof@lixom.net>>>>; 
>> soc@kernel.org; Rob Herring <robh+dt@kernel.org>>>>; 
>> linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; 
>> linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP 
>> Device tree
>> 
>> On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>>>>>> From: Nick Hawkins <nick.hawkins@hpe.com>>>>
>>>>>>
>>>>>> The HPE SoC is new to linux. This patch creates the basic device 
>>>>>> tree layout with minimum required for linux to boot. This includes 
>>>>>> timer and watchdog support.
>>>>>>
>>>>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>>>
>>>>>> ---
>>>>>>  arch/arm/boot/dts/Makefile               |   2 +
>>>>>>  arch/arm/boot/dts/hpe-bmc-dl360gen10.dts |  27 +++++
>>>>>>  arch/arm/boot/dts/hpe-gxp.dtsi           | 148 +++++++++++++++++++++++
>>>>>>  3 files changed, 177 insertions(+)
>>>>>>  create mode 100644 arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>>  create mode 100644 arch/arm/boot/dts/hpe-gxp.dtsi
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile 
>>>>>> index e41eca79c950..2823b359d373 100644
>>>>>> --- a/arch/arm/boot/dts/Makefile
>>>>>> +++ b/arch/arm/boot/dts/Makefile
>>>>>> @@ -1550,3 +1550,5 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>>>>>>  	aspeed-bmc-vegman-n110.dtb \
>>>>>>  	aspeed-bmc-vegman-rx20.dtb \
>>>>>>  	aspeed-bmc-vegman-sx20.dtb
>>>>>> +dtb-$(CONFIG_ARCH_HPE_GXP) += \
>>>>>> +	hpe-bmc-dl360gen10.dtb
>> 
>>>> Alphabetically, also in respect to other architectures, so before CONFIG_ARCH_INTEGRATOR.
>> 
>> Done
>> 
>>>>>> diff --git a/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>> b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>> new file mode 100644
>>>>>> index 000000000000..da5eac1213a8
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/boot/dts/hpe-bmc-dl360gen10.dts
>>>>>> @@ -0,0 +1,27 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * Device Tree file for HPE DL360Gen10  */
>>>>>> +
>>>>>> +/include/ "hpe-gxp.dtsi"
>>>>>> +
>>>>>> +/ {
>>>>>> +	#address-cells = <1>>>>;
>>>>>> +	#size-cells = <1>>>>;
>>>>>> +	compatible = "hpe,gxp";
>> 
>>>> Missing board compatible.
>> 
>> Will become compatible =  "hpe,gxp","hpe,bmc-dl360gen10"; If that seems okay to you.

> Yes, except hpe,gxp goes at the end.

Done

>> 
>>>>>> +	model = "Hewlett Packard Enterprise ProLiant dl360 Gen10";
>>>>>> +

(...)

>>>>>> +
>>>>>> +		usb0: usb@cefe0000 {
>>>>>> +			compatible = "generic-ehci";
>> 
>>>> I think one of previous comments was that you cannot have "generic-ehci"
>>>> only, right?
>> 
>> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?

> Yes,, see other cases in generic-ehci.yaml bindings. Your current choice would be pointed out by dtbs_check, that it's invalid according to current bindings.

For some reason when I compile I am not seeing a warning for that file. I have been using "make dtbs_check" and "make dtbs W=1". Perhaps I am missing an important flag?

In the case of creating a hpe,gxp-ehci binding would I need to add that to the generic-ehci.yaml?


>> 
>>>>>> +			reg = <0xcefe0000 0x100>>>>;
>>>>>> +			interrupts = <7>>>>;
>>>>>> +			interrupt-parent = <&vic0>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		usb1: usb@cefe0100 {
>>>>>> +			compatible = "generic-ohci";
>>>>>> +			reg = <0xcefe0100 0x110>>>>;
>>>>>> +			interrupts = <6>>>>;
>>>>>> +			interrupt-parent = <&vic0>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		vrom@58000000 {
>>>>>> +			compatible = "mtd-ram";
>>>>>> +			bank-width = <4>>>>;
>>>>>> +			reg = <0x58000000 0x4000000>>>>;
>>>>>> +			#address-cells = <1>>>>;
>>>>>> +			#size-cells = <1>>>>;
>>>>>> +			partition@0 {
>>>>>> +				label = "vrom-prime";
>>>>>> +				reg = <0x0 0x2000000>>>>;
>>>>>> +			};
>>>>>> +			partition@2000000 {
>>>>>> +				label = "vrom-second";
>>>>>> +				reg = <0x2000000 0x2000000>>>>;
>>>>>> +			};
>>>>>> +		};
>>>>>> +
>>>>>> +		i2cg: syscon@c00000f8 {
>> 
>> 
>>>>>> +			compatible = "simple-mfd", "syscon";
>>>>>> +			reg = <0xc00000f8 0x08>>>>;
>>>>>> +		};
>>>>>> +	};
>>>>>> +
>>>>>> +	clocks {
>>>>>> +		osc: osc {
>> 
>>>> Keep node naming consistent, so just "clk"... but it's also very generic comparing to others, so I wonder what is this clock?
>> 
>> We are in the process of redoing the clocks. This was the oscillator but no longer needed for the minimum boot config.
>> 
>>>>>> +			compatible = "fixed-clock";
>>>>>> +			#clock-cells = <0>>>>;
>>>>>> +			clock-output-names = "osc";
>>>>>> +			clock-frequency = <33333333>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		iopclk: iopclk {
>>>>>> +			compatible = "fixed-clock";
>>>>>> +			#clock-cells = <0>>>>;
>>>>>> +			clock-output-names = "iopclk";
>>>>>> +			clock-frequency = <400000000>>>>;
>>>>>> +		};
>>>>>> +
>>>>>> +		memclk: memclk {
>>>>>> +			compatible = "fixed-clock";
>>>>>> +			#clock-cells = <0>>>>;
>>>>>> +			clock-output-names = "memclk";
>>>>>> +			clock-frequency = <800000000>>>>;
>>>>>> +		};
>> 
>>>> What are these clocks? If external to the SoC, then where are they? On the board?
>> 
>> This was the internal iopclk and memclk they were both internal to the chip.
>> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.

> You should rather have a clock controller driver which defines this (and many others). They can stay as a temporary work-around, if you really need them for some other nodes.

I am trying to picture what you are saying but I am unsure, I know that on a separate review you mentioned that the gxp-timer needed to have clocks, and clock-names inside the node. Would it be improper for the gxp-timer to reference iopclk?

Thanks!

-Nick Hawkins
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init
  2022-03-11 10:22   ` Krzysztof Kozlowski
@ 2022-03-16 21:33     ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-16 21:33 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Rob Herring, devicetree, linux-kernel



-----Original Message-----
From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com] 
Sent: Friday, March 11, 2022 4:22 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>>; Verdun, Jean-Marie <verdun@hpe.com>>
Cc: Rob Herring <robh+dt@kernel.org>>; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
>> From: Nick Hawkins <nick.hawkins@hpe.com>>
>> 
>> This adds support for the hpe,gxp-cpu-init binding.
>> With the HPE GXP initialization it is necessary to have access to this 
>> register for it to boot.
>> 
>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>>
>> ---
>>  .../cpu-enable-method/hpe,gxp-cpu-init.yaml   | 31 +++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-in
>> it.yaml
>> 
>> diff --git 
>> a/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-
>> init.yaml 
>> b/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-cpu-
>> init.yaml
>> new file mode 100644
>> index 000000000000..a17c3fcc5421
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/hpe,gxp-
>> +++ cpu-init.yaml
>> @@ -0,0 +1,31 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>> +---
>> +$id: 
>> +INVALID URI REMOVED
>> +ble-method/hpe,gxp-cpu-init.yaml*__;Iw!!NpxR!110gfGDYqJKEHiiJCXcAxkJJ
>> +uv62JykkON1xXN-Gdv6p4hn6fm7y8WHCy6w2GSFt$
>> +$schema: 
>> +INVALID URI REMOVED
>> +aml*__;Iw!!NpxR!110gfGDYqJKEHiiJCXcAxkJJuv62JykkON1xXN-Gdv6p4hn6fm7y8
>> +WHCy25gpjJ0$
>> +
>> +title: Initialize GXP CPU

> Please explain what's this. The bindings describe the hardware and I cannot get what is this here about. Is it a CPU enable method (like in cpus.yaml)? Is it some power management block?

This was intended to be a binding that would provide the necessary register to boot the asic. I have now moved this functionality into our bootloader. Thus this binding is no longer needed and will be removed from subsequent versions of this patch series.

Thanks,

-Nick

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-16 20:10           ` Hawkins, Nick
@ 2022-03-17  8:36             ` Krzysztof Kozlowski
  -1 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-17  8:36 UTC (permalink / raw)
  To: Hawkins, Nick, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

On 16/03/2022 21:10, Hawkins, Nick wrote:

(...)

>>>>> I think one of previous comments was that you cannot have "generic-ehci"
>>>>> only, right?
>>>
>>> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?
> 
>> Yes,, see other cases in generic-ehci.yaml bindings. Your current choice would be pointed out by dtbs_check, that it's invalid according to current bindings.
> 
> For some reason when I compile I am not seeing a warning for that file. I have been using "make dtbs_check" and "make dtbs W=1". Perhaps I am missing an important flag?

My bad, I misread the generic-ehci binding, so your compatible is
actually correct from bindings point of view. Still common practice is
to add own compatible which allows later customization.

> In the case of creating a hpe,gxp-ehci binding would I need to add that to the generic-ehci.yaml?

Yes, add your compatible to that big enum with list of many implementations.

(...)

>>>>>>> +
>>>>>>> +		memclk: memclk {
>>>>>>> +			compatible = "fixed-clock";
>>>>>>> +			#clock-cells = <0>>>>;
>>>>>>> +			clock-output-names = "memclk";
>>>>>>> +			clock-frequency = <800000000>>>>;
>>>>>>> +		};
>>>
>>>>> What are these clocks? If external to the SoC, then where are they? On the board?
>>>
>>> This was the internal iopclk and memclk they were both internal to the chip.
>>> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.
> 
>> You should rather have a clock controller driver which defines this (and many others). They can stay as a temporary work-around, if you really need them for some other nodes.
> 
> I am trying to picture what you are saying but I am unsure, I know that on a separate review you mentioned that the gxp-timer needed to have clocks, and clock-names inside the node. Would it be improper for the gxp-timer to reference iopclk?

It all depends on the architecture of your SoC. I could imagine such one:
1. Few external (from SoC point of view) oscillators, usually provided
on the board. It could be 24 MHz, could be 32767 Hz for Bluetooth etc.

2. One or several clock controllers inside the SoC which take as input
these external clocks. The clock controller provides clocks for several
other components/blocks. Allows also gating clocks, reparenting and
changing dividers (rate).

3. Other blocks within your SoC, e.g. gxp-timer, use these clocks.

The true question is where is that memclk or iopclk generated? Is it
controllable (gate/mux/rate)? Even some fixed-frequency clocks, coming
out of that clock controller (point 2.), are defined in the clock
controller because that's the logical place for them.


Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-17  8:36             ` Krzysztof Kozlowski
  0 siblings, 0 replies; 80+ messages in thread
From: Krzysztof Kozlowski @ 2022-03-17  8:36 UTC (permalink / raw)
  To: Hawkins, Nick, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

On 16/03/2022 21:10, Hawkins, Nick wrote:

(...)

>>>>> I think one of previous comments was that you cannot have "generic-ehci"
>>>>> only, right?
>>>
>>> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?
> 
>> Yes,, see other cases in generic-ehci.yaml bindings. Your current choice would be pointed out by dtbs_check, that it's invalid according to current bindings.
> 
> For some reason when I compile I am not seeing a warning for that file. I have been using "make dtbs_check" and "make dtbs W=1". Perhaps I am missing an important flag?

My bad, I misread the generic-ehci binding, so your compatible is
actually correct from bindings point of view. Still common practice is
to add own compatible which allows later customization.

> In the case of creating a hpe,gxp-ehci binding would I need to add that to the generic-ehci.yaml?

Yes, add your compatible to that big enum with list of many implementations.

(...)

>>>>>>> +
>>>>>>> +		memclk: memclk {
>>>>>>> +			compatible = "fixed-clock";
>>>>>>> +			#clock-cells = <0>>>>;
>>>>>>> +			clock-output-names = "memclk";
>>>>>>> +			clock-frequency = <800000000>>>>;
>>>>>>> +		};
>>>
>>>>> What are these clocks? If external to the SoC, then where are they? On the board?
>>>
>>> This was the internal iopclk and memclk they were both internal to the chip.
>>> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.
> 
>> You should rather have a clock controller driver which defines this (and many others). They can stay as a temporary work-around, if you really need them for some other nodes.
> 
> I am trying to picture what you are saying but I am unsure, I know that on a separate review you mentioned that the gxp-timer needed to have clocks, and clock-names inside the node. Would it be improper for the gxp-timer to reference iopclk?

It all depends on the architecture of your SoC. I could imagine such one:
1. Few external (from SoC point of view) oscillators, usually provided
on the board. It could be 24 MHz, could be 32767 Hz for Bluetooth etc.

2. One or several clock controllers inside the SoC which take as input
these external clocks. The clock controller provides clocks for several
other components/blocks. Allows also gating clocks, reparenting and
changing dividers (rate).

3. Other blocks within your SoC, e.g. gxp-timer, use these clocks.

The true question is where is that memclk or iopclk generated? Is it
controllable (gate/mux/rate)? Even some fixed-frequency clocks, coming
out of that clock controller (point 2.), are defined in the clock
controller because that's the logical place for them.


Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-17  8:36             ` Krzysztof Kozlowski
@ 2022-03-29 19:38               ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-29 19:38 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

-----Original Message-----
From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com] 
Sent: Thursday, March 17, 2022 3:37 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>; Verdun, Jean-Marie <verdun@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On 16/03/2022 21:10, Hawkins, Nick wrote:

(...)

>>>>>> I think one of previous comments was that you cannot have "generic-ehci"
>>>>>> only, right?
>>>
>>>> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?
>> 
>>> Yes,, see other cases in generic-ehci.yaml bindings. Your current choice would be pointed out by dtbs_check, that it's invalid according to current bindings.
>> 
>> For some reason when I compile I am not seeing a warning for that file. I have been using "make dtbs_check" and "make dtbs W=1". Perhaps I am missing an important flag?

> My bad, I misread the generic-ehci binding, so your compatible is actually correct from bindings point of view. Still common practice is to add own compatible which allows later customization.

>> In the case of creating a hpe,gxp-ehci binding would I need to add that to the generic-ehci.yaml?

> Yes, add your compatible to that big enum with list of many implementations.

Done.

> (...)

>>>>>>>> +
>>>>>>>> +		memclk: memclk {
>>>>>>>> +			compatible = "fixed-clock";
>>>>>>>> +			#clock-cells = <0>>>>;
>>>>>>>> +			clock-output-names = "memclk";
>>>>>>>> +			clock-frequency = <800000000>>>>;
>>>>>>>> +		};
>>>
>>>>>> What are these clocks? If external to the SoC, then where are they? On the board?
>>>
>>>> This was the internal iopclk and memclk they were both internal to the chip.
>>>> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.
>> 
>>> You should rather have a clock controller driver which defines this (and many others). They can stay as a temporary work-around, if you really need them for some other nodes.
>> 
>> I am trying to picture what you are saying but I am unsure, I know that on a separate review you mentioned that the gxp-timer needed to have clocks, and clock-names inside the node. Would it be improper for the gxp-timer to reference iopclk?

> It all depends on the architecture of your SoC. I could imagine such one:
> 1. Few external (from SoC point of view) oscillators, usually provided on the board. It could be 24 MHz, could be 32767 Hz for Bluetooth etc.

> 2. One or several clock controllers inside the SoC which take as input these external clocks. The clock controller provides clocks for several other components/blocks. Allows also gating clocks, reparenting and changing dividers (rate).

> 3. Other blocks within your SoC, e.g. gxp-timer, use these clocks.

> The true question is where is that memclk or iopclk generated? Is it controllable (gate/mux/rate)? Even some fixed-frequency clocks, coming out of that clock controller (point 2.), are defined in the clock controller because that's the logical place for >them.

From the perspective of our SoC there is a PPUCLK that generates the clk signals for our watchdog and timer. This happens inside the SoC. I am trying to represent this below.

axi {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;
		dma-ranges;

		ahb@c0000000 {
			compatible = "simple-bus";
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0x0 0xc0000000 0x30000000>;

			...

			timer0: timer@80 {
				compatible = "hpe,gxp-timer";
				reg = <0x80 0x1>, <0x94 0x01>, <0x88 0x08>;
				interrupts = <0>;
				interrupt-parent = <&vic0>;
				clocks = <&ppuclk>;
				clock-names = "ppuclk";
				clock-frequency = <400000000>;
			};

			watchdog0: watchdog@90 {
				compatible = "hpe,gxp-wdt";
				reg = <0x90 0x02>, <0x96 0x01>;
			};

			...
	};

	clocks {
		ppuclk: ppuclk {
			compatible = "fixed-clock";
			#clock-cells = <0>;
			clock-output-names = "ppuclk";
			clock-frequency = <400000000>;
		};
	};

I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.

For instance with our watchdog controls we have:

@90 the countdown value
@96 the configuration

And for our timer we have:
@80 the countdown value
@94 the configuration
@88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.

What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers. 

 Thanks,

-Nick Hawkins


^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-29 19:38               ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-29 19:38 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Verdun, Jean-Marie
  Cc: Arnd Bergmann, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel

-----Original Message-----
From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@canonical.com] 
Sent: Thursday, March 17, 2022 3:37 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>; Verdun, Jean-Marie <verdun@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On 16/03/2022 21:10, Hawkins, Nick wrote:

(...)

>>>>>> I think one of previous comments was that you cannot have "generic-ehci"
>>>>>> only, right?
>>>
>>>> Yes there was, I removed the usb0: ehci@cefe0000. I see now that this is in reference to the compatible. This is our ehci controller. What would be a more appropriate compatible? Do we need hpe,gxp-ehci perhaps?
>> 
>>> Yes,, see other cases in generic-ehci.yaml bindings. Your current choice would be pointed out by dtbs_check, that it's invalid according to current bindings.
>> 
>> For some reason when I compile I am not seeing a warning for that file. I have been using "make dtbs_check" and "make dtbs W=1". Perhaps I am missing an important flag?

> My bad, I misread the generic-ehci binding, so your compatible is actually correct from bindings point of view. Still common practice is to add own compatible which allows later customization.

>> In the case of creating a hpe,gxp-ehci binding would I need to add that to the generic-ehci.yaml?

> Yes, add your compatible to that big enum with list of many implementations.

Done.

> (...)

>>>>>>>> +
>>>>>>>> +		memclk: memclk {
>>>>>>>> +			compatible = "fixed-clock";
>>>>>>>> +			#clock-cells = <0>>>>;
>>>>>>>> +			clock-output-names = "memclk";
>>>>>>>> +			clock-frequency = <800000000>>>>;
>>>>>>>> +		};
>>>
>>>>>> What are these clocks? If external to the SoC, then where are they? On the board?
>>>
>>>> This was the internal iopclk and memclk they were both internal to the chip.
>>>> For now I am removing osc and memclk and will just have an iopclk that Gxp-timer will refer to.
>> 
>>> You should rather have a clock controller driver which defines this (and many others). They can stay as a temporary work-around, if you really need them for some other nodes.
>> 
>> I am trying to picture what you are saying but I am unsure, I know that on a separate review you mentioned that the gxp-timer needed to have clocks, and clock-names inside the node. Would it be improper for the gxp-timer to reference iopclk?

> It all depends on the architecture of your SoC. I could imagine such one:
> 1. Few external (from SoC point of view) oscillators, usually provided on the board. It could be 24 MHz, could be 32767 Hz for Bluetooth etc.

> 2. One or several clock controllers inside the SoC which take as input these external clocks. The clock controller provides clocks for several other components/blocks. Allows also gating clocks, reparenting and changing dividers (rate).

> 3. Other blocks within your SoC, e.g. gxp-timer, use these clocks.

> The true question is where is that memclk or iopclk generated? Is it controllable (gate/mux/rate)? Even some fixed-frequency clocks, coming out of that clock controller (point 2.), are defined in the clock controller because that's the logical place for >them.

From the perspective of our SoC there is a PPUCLK that generates the clk signals for our watchdog and timer. This happens inside the SoC. I am trying to represent this below.

axi {
		compatible = "simple-bus";
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;
		dma-ranges;

		ahb@c0000000 {
			compatible = "simple-bus";
			#address-cells = <1>;
			#size-cells = <1>;
			ranges = <0x0 0xc0000000 0x30000000>;

			...

			timer0: timer@80 {
				compatible = "hpe,gxp-timer";
				reg = <0x80 0x1>, <0x94 0x01>, <0x88 0x08>;
				interrupts = <0>;
				interrupt-parent = <&vic0>;
				clocks = <&ppuclk>;
				clock-names = "ppuclk";
				clock-frequency = <400000000>;
			};

			watchdog0: watchdog@90 {
				compatible = "hpe,gxp-wdt";
				reg = <0x90 0x02>, <0x96 0x01>;
			};

			...
	};

	clocks {
		ppuclk: ppuclk {
			compatible = "fixed-clock";
			#clock-cells = <0>;
			clock-output-names = "ppuclk";
			clock-frequency = <400000000>;
		};
	};

I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.

For instance with our watchdog controls we have:

@90 the countdown value
@96 the configuration

And for our timer we have:
@80 the countdown value
@94 the configuration
@88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.

What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers. 

 Thanks,

-Nick Hawkins

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-29 19:38               ` Hawkins, Nick
@ 2022-03-29 21:13                 ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-29 21:13 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Krzysztof Kozlowski, Verdun, Jean-Marie, Arnd Bergmann,
	Olof Johansson, soc, Rob Herring, linux-arm-kernel, devicetree,
	linux-kernel

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:

> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
> For instance with our watchdog controls we have:
>
> @90 the countdown value
> @96 the configuration
>
> And for our timer we have:
> @80 the countdown value
> @94 the configuration
> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

I think this is most commonly done using a 'syscon' node, have a look at the
files listed by


$ git grep syscon drivers/watchdog/ drivers/clocksource/

You may also want to look at those drivers to find if any of them can
be directly reused,
this is perhaps a licensed IP block that others are using as well.

        Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-29 21:13                 ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-29 21:13 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Krzysztof Kozlowski, Verdun, Jean-Marie, Arnd Bergmann,
	Olof Johansson, soc, Rob Herring, linux-arm-kernel, devicetree,
	linux-kernel

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:

> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
> For instance with our watchdog controls we have:
>
> @90 the countdown value
> @96 the configuration
>
> And for our timer we have:
> @80 the countdown value
> @94 the configuration
> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

I think this is most commonly done using a 'syscon' node, have a look at the
files listed by


$ git grep syscon drivers/watchdog/ drivers/clocksource/

You may also want to look at those drivers to find if any of them can
be directly reused,
this is perhaps a licensed IP block that others are using as well.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-29 21:13                 ` Arnd Bergmann
@ 2022-03-29 21:45                   ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-29 21:45 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Krzysztof Kozlowski, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Tuesday, March 29, 2022 4:13 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Verdun, Jean-Marie <verdun@hpe.com>; Arnd Bergmann <arnd@arndb.de>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:

>> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
>> For instance with our watchdog controls we have:
>
>> @90 the countdown value
>> @96 the configuration
>
>> And for our timer we have:
>> @80 the countdown value
>> @94 the configuration
>> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
>> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

> I think this is most commonly done using a 'syscon' node, have a look at the files listed by


> $ git grep syscon drivers/watchdog/ drivers/clocksource/

Is this a good example of what you were thinking of? I found this in arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi

sysctrl@61840000 {
                        compatible = "socionext,uniphier-ld11-sysctrl",
                                     "simple-mfd", "syscon";
                        reg = <0x61840000 0x10000>;

                        sys_clk: clock {
                                compatible = "socionext,uniphier-ld11-clock";
                                #clock-cells = <1>;
                        };

                        sys_rst: reset {
                                compatible = "socionext,uniphier-ld11-reset";
                                #reset-cells = <1>;
                        };

                        watchdog {
                                compatible = "socionext,uniphier-wdt";
                        };
 };

If that is the case..

timectrl@80 {
	compatible = "hpe,gxp-timectrl","syscon";
	reg = <0x80 0x16>;

	watchdog0: watchdog {
		compatible = "hpe,gxp-wdt";
	}

	timer0: timer {
		compatible = "hpe,gxp-timer";
	}
}
	

> You may also want to look at those drivers to find if any of them can be directly reused, this is perhaps a licensed IP block that others are using as well.

I will look and see if any of them have the same register sets and functionality.

Thanks,

-Nick Hawkins

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-29 21:45                   ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-29 21:45 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Krzysztof Kozlowski, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Tuesday, March 29, 2022 4:13 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Verdun, Jean-Marie <verdun@hpe.com>; Arnd Bergmann <arnd@arndb.de>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:

>> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
>> For instance with our watchdog controls we have:
>
>> @90 the countdown value
>> @96 the configuration
>
>> And for our timer we have:
>> @80 the countdown value
>> @94 the configuration
>> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
>> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

> I think this is most commonly done using a 'syscon' node, have a look at the files listed by


> $ git grep syscon drivers/watchdog/ drivers/clocksource/

Is this a good example of what you were thinking of? I found this in arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi

sysctrl@61840000 {
                        compatible = "socionext,uniphier-ld11-sysctrl",
                                     "simple-mfd", "syscon";
                        reg = <0x61840000 0x10000>;

                        sys_clk: clock {
                                compatible = "socionext,uniphier-ld11-clock";
                                #clock-cells = <1>;
                        };

                        sys_rst: reset {
                                compatible = "socionext,uniphier-ld11-reset";
                                #reset-cells = <1>;
                        };

                        watchdog {
                                compatible = "socionext,uniphier-wdt";
                        };
 };

If that is the case..

timectrl@80 {
	compatible = "hpe,gxp-timectrl","syscon";
	reg = <0x80 0x16>;

	watchdog0: watchdog {
		compatible = "hpe,gxp-wdt";
	}

	timer0: timer {
		compatible = "hpe,gxp-timer";
	}
}
	

> You may also want to look at those drivers to find if any of them can be directly reused, this is perhaps a licensed IP block that others are using as well.

I will look and see if any of them have the same register sets and functionality.

Thanks,

-Nick Hawkins
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-29 21:45                   ` Hawkins, Nick
@ 2022-03-30 22:27                     ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-30 22:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Tuesday, March 29, 2022 4:13 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Verdun, Jean-Marie <verdun@hpe.com>; Arnd Bergmann <arnd@arndb.de>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:

>> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
>> For instance with our watchdog controls we have:
>
>> @90 the countdown value
>> @96 the configuration
>
>> And for our timer we have:
>> @80 the countdown value
>> @94 the configuration
>> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
>> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

> I think this is most commonly done using a 'syscon' node, have a look at the files listed by

I found an example and copied it although I have a couple questions when it comes to actually coding it. Can that be here or should I post these questions in the patch that actually concern the file?

st: timer@80 {
	compatible = "hpe,gxp-timer","syscon","simple-mfd";
	reg = <0x80 0x16>;
	interrupts = <0>;
	interrupt-parent = <&vic0>;
	clocks = <&ppuclk>;
	clock-names = "ppuclk";
	clock-frequency = <400000000>;

	watchdog {
		compatible = "hpe,gxp-wdt";
	};
 };

Thanks,

-Nick Hawkins

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-30 22:27                     ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-30 22:27 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Tuesday, March 29, 2022 4:13 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>; Verdun, Jean-Marie <verdun@hpe.com>; Arnd Bergmann <arnd@arndb.de>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:

>> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
>
>> For instance with our watchdog controls we have:
>
>> @90 the countdown value
>> @96 the configuration
>
>> And for our timer we have:
>> @80 the countdown value
>> @94 the configuration
>> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
>
>> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.

> I think this is most commonly done using a 'syscon' node, have a look at the files listed by

I found an example and copied it although I have a couple questions when it comes to actually coding it. Can that be here or should I post these questions in the patch that actually concern the file?

st: timer@80 {
	compatible = "hpe,gxp-timer","syscon","simple-mfd";
	reg = <0x80 0x16>;
	interrupts = <0>;
	interrupt-parent = <&vic0>;
	clocks = <&ppuclk>;
	clock-names = "ppuclk";
	clock-frequency = <400000000>;

	watchdog {
		compatible = "hpe,gxp-wdt";
	};
 };

Thanks,

-Nick Hawkins
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-30 22:27                     ` Hawkins, Nick
@ 2022-03-31  9:30                       ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-31  9:30 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Thu, Mar 31, 2022 at 12:27 AM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
>
> >> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
> >
> >> For instance with our watchdog controls we have:
> >
> >> @90 the countdown value
> >> @96 the configuration
> >
> >> And for our timer we have:
> >> @80 the countdown value
> >> @94 the configuration
> >> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
> >
> >> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.
>
> > I think this is most commonly done using a 'syscon' node, have a look at the files listed by
>
> I found an example and copied it although I have a couple questions when it comes to actually coding it. Can that be here or should I post these questions in the patch that actually concern the file?
>
> st: timer@80 {
>         compatible = "hpe,gxp-timer","syscon","simple-mfd";
>         reg = <0x80 0x16>;
>         interrupts = <0>;
>         interrupt-parent = <&vic0>;
>         clocks = <&ppuclk>;
>         clock-names = "ppuclk";
>         clock-frequency = <400000000>;
>
>         watchdog {
>                 compatible = "hpe,gxp-wdt";
>         };
>  };

I'd have to study the other examples myself to see what is most common.

My feeling would be that it's better to either have a "hpe,gxp-timer" parent
device with a watchdog child but no syscon, or to have a syscon/simple-mfd
parent with both the timer and the watchdog as children.

       Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-31  9:30                       ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-31  9:30 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Thu, Mar 31, 2022 at 12:27 AM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
>
> >> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
> >
> >> For instance with our watchdog controls we have:
> >
> >> @90 the countdown value
> >> @96 the configuration
> >
> >> And for our timer we have:
> >> @80 the countdown value
> >> @94 the configuration
> >> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
> >
> >> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.
>
> > I think this is most commonly done using a 'syscon' node, have a look at the files listed by
>
> I found an example and copied it although I have a couple questions when it comes to actually coding it. Can that be here or should I post these questions in the patch that actually concern the file?
>
> st: timer@80 {
>         compatible = "hpe,gxp-timer","syscon","simple-mfd";
>         reg = <0x80 0x16>;
>         interrupts = <0>;
>         interrupt-parent = <&vic0>;
>         clocks = <&ppuclk>;
>         clock-names = "ppuclk";
>         clock-frequency = <400000000>;
>
>         watchdog {
>                 compatible = "hpe,gxp-wdt";
>         };
>  };

I'd have to study the other examples myself to see what is most common.

My feeling would be that it's better to either have a "hpe,gxp-timer" parent
device with a watchdog child but no syscon, or to have a syscon/simple-mfd
parent with both the timer and the watchdog as children.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-31  9:30                       ` Arnd Bergmann
@ 2022-03-31 21:09                         ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-31 21:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Thursday, March 31, 2022 4:30 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Thu, Mar 31, 2022 at 12:27 AM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
>
> >> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
> >
> >> For instance with our watchdog controls we have:
> >
> >> @90 the countdown value
> >> @96 the configuration
> >
> >> And for our timer we have:
> >> @80 the countdown value
> >> @94 the configuration
> >> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
> >
> >> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.
>>
> > I think this is most commonly done using a 'syscon' node, have a 
> > look at the files listed by
>>
>> I found an example and copied it although I have a couple questions when it comes to actually coding it. Can that be here or should I post these questions in the patch that actually concern the file?
>>
>> st: timer@80 {
>>         compatible = "hpe,gxp-timer","syscon","simple-mfd";
>>         reg = <0x80 0x16>;
>>         interrupts = <0>;
>>         interrupt-parent = <&vic0>;
>>         clocks = <&ppuclk>;
>>         clock-names = "ppuclk";
>>         clock-frequency = <400000000>;
>>
>>         watchdog {
>>                 compatible = "hpe,gxp-wdt";
>>         };
>>  };

> I'd have to study the other examples myself to see what is most common.

> My feeling would be that it's better to either have a "hpe,gxp-timer" parent device with a watchdog child but no syscon, or to have a syscon/simple-mfd parent with both the timer and the watchdog as children.

Arnd, thanks for the feedback. I am trying to use the approach you recommend where you have a syscon/simple-mfd parent with watchdog and timer as children.

st: chip-controller@80 {
                                compatible = "hpe,gxp-ctrl-st","syscon","simple-mfd";
                                reg = <0x80 0x16>;

                                timer0: timer {
                                        compatible = "hpe,gxp-timer";
                                        interrupts = <0>;
                                        interrupt-parent = <&vic0>;
                                        clocks = <&ppuclk>;
                                        clock-names = "ppuclk";
                                };

                                watchdog {
                                        compatible = "hpe,gxp-wdt";
                                };
};

This compiles without any errors but I do have some questions about accessing the regmap in both drivers, specifically the timer code. How do you use a regmap with clocksource_mmio_init? I tried searching through the codebase and could not find the answer. I assume I am missing some vital step.

Thanks,

-Nick





^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-31 21:09                         ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-03-31 21:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Thursday, March 31, 2022 4:30 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Thu, Mar 31, 2022 at 12:27 AM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
>
> >> I am in the process of rewriting the timer driver for Linux but have hit a dilemma and I am looking for some direction. The registers that represent the watchdog timer, and timer all lay in the same register region and they are spread out to the point where there are other controls  in the same area.
> >
> >> For instance with our watchdog controls we have:
> >
> >> @90 the countdown value
> >> @96 the configuration
> >
> >> And for our timer we have:
> >> @80 the countdown value
> >> @94 the configuration
> >> @88 this is actually our timestamp register but is being included in with the timer driver currently to call clocksource_mmio_init.
> >
> >> What would be your recommendation for this? I was considering creating a gxp-clock that specifically points at the timestamp register but I still have the issue with gxp-timer and gxp-wdt being spread across the same area of registers.
>>
> > I think this is most commonly done using a 'syscon' node, have a 
> > look at the files listed by
>>
>> I found an example and copied it although I have a couple questions when it comes to actually coding it. Can that be here or should I post these questions in the patch that actually concern the file?
>>
>> st: timer@80 {
>>         compatible = "hpe,gxp-timer","syscon","simple-mfd";
>>         reg = <0x80 0x16>;
>>         interrupts = <0>;
>>         interrupt-parent = <&vic0>;
>>         clocks = <&ppuclk>;
>>         clock-names = "ppuclk";
>>         clock-frequency = <400000000>;
>>
>>         watchdog {
>>                 compatible = "hpe,gxp-wdt";
>>         };
>>  };

> I'd have to study the other examples myself to see what is most common.

> My feeling would be that it's better to either have a "hpe,gxp-timer" parent device with a watchdog child but no syscon, or to have a syscon/simple-mfd parent with both the timer and the watchdog as children.

Arnd, thanks for the feedback. I am trying to use the approach you recommend where you have a syscon/simple-mfd parent with watchdog and timer as children.

st: chip-controller@80 {
                                compatible = "hpe,gxp-ctrl-st","syscon","simple-mfd";
                                reg = <0x80 0x16>;

                                timer0: timer {
                                        compatible = "hpe,gxp-timer";
                                        interrupts = <0>;
                                        interrupt-parent = <&vic0>;
                                        clocks = <&ppuclk>;
                                        clock-names = "ppuclk";
                                };

                                watchdog {
                                        compatible = "hpe,gxp-wdt";
                                };
};

This compiles without any errors but I do have some questions about accessing the regmap in both drivers, specifically the timer code. How do you use a regmap with clocksource_mmio_init? I tried searching through the codebase and could not find the answer. I assume I am missing some vital step.

Thanks,

-Nick




_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-31 21:09                         ` Hawkins, Nick
@ 2022-03-31 21:52                           ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-31 21:52 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Thu, Mar 31, 2022 at 11:09 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> On Thu, Mar 31, 2022 at 12:27 AM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
> > I'd have to study the other examples myself to see what is most common.
>
> > My feeling would be that it's better to either have a "hpe,gxp-timer" parent device with a watchdog child but no syscon, or to have a syscon/simple-mfd parent with both the timer and the watchdog as children.
>
> Arnd, thanks for the feedback. I am trying to use the approach you recommend where you have a syscon/simple-mfd parent with watchdog and timer as children.
>
> st: chip-controller@80 {
>                                 compatible = "hpe,gxp-ctrl-st","syscon","simple-mfd";
>                                 reg = <0x80 0x16>;
>
>                                 timer0: timer {
>                                         compatible = "hpe,gxp-timer";
>                                         interrupts = <0>;
>                                         interrupt-parent = <&vic0>;
>                                         clocks = <&ppuclk>;
>                                         clock-names = "ppuclk";
>                                 };
>
>                                 watchdog {
>                                         compatible = "hpe,gxp-wdt";
>                                 };
> };
>
> This compiles without any errors but I do have some questions about accessing the regmap in both drivers, specifically the timer code. How do you use a regmap with clocksource_mmio_init? I tried searching through the codebase and could not find the answer. I assume I am missing some vital step.

I don't think you can do this, if you are using the syscon regmap, you
go through the
regmap indirection rather than accessing the mmio register by virtual address,
and this may result in some extra code in your driver, and a little
runtime overhead.

If you prefer to avoid that, you can go back to having the timer node as the
parent, but without being a syscon. In this case, the watchdog would be handled
in one of these ways:

a) a child device gets created from the clocksource driver and bound to the
    watchdog driver, which then uses a private interface between the clocksource
    and the watchdog to access the registers

b) the clocksource driver itself registers as a watchdog driver, without
    having a separate driver module

One thing to consider is whether the register range here contains any
registers that may be used in another driver, e.g. a second timer,
a PWM, or a clk controller. If not, you are fairly free to pick any of these
approaches.

        Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-03-31 21:52                           ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-03-31 21:52 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Thu, Mar 31, 2022 at 11:09 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> On Thu, Mar 31, 2022 at 12:27 AM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > On Tue, Mar 29, 2022 at 9:38 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
> > I'd have to study the other examples myself to see what is most common.
>
> > My feeling would be that it's better to either have a "hpe,gxp-timer" parent device with a watchdog child but no syscon, or to have a syscon/simple-mfd parent with both the timer and the watchdog as children.
>
> Arnd, thanks for the feedback. I am trying to use the approach you recommend where you have a syscon/simple-mfd parent with watchdog and timer as children.
>
> st: chip-controller@80 {
>                                 compatible = "hpe,gxp-ctrl-st","syscon","simple-mfd";
>                                 reg = <0x80 0x16>;
>
>                                 timer0: timer {
>                                         compatible = "hpe,gxp-timer";
>                                         interrupts = <0>;
>                                         interrupt-parent = <&vic0>;
>                                         clocks = <&ppuclk>;
>                                         clock-names = "ppuclk";
>                                 };
>
>                                 watchdog {
>                                         compatible = "hpe,gxp-wdt";
>                                 };
> };
>
> This compiles without any errors but I do have some questions about accessing the regmap in both drivers, specifically the timer code. How do you use a regmap with clocksource_mmio_init? I tried searching through the codebase and could not find the answer. I assume I am missing some vital step.

I don't think you can do this, if you are using the syscon regmap, you
go through the
regmap indirection rather than accessing the mmio register by virtual address,
and this may result in some extra code in your driver, and a little
runtime overhead.

If you prefer to avoid that, you can go back to having the timer node as the
parent, but without being a syscon. In this case, the watchdog would be handled
in one of these ways:

a) a child device gets created from the clocksource driver and bound to the
    watchdog driver, which then uses a private interface between the clocksource
    and the watchdog to access the registers

b) the clocksource driver itself registers as a watchdog driver, without
    having a separate driver module

One thing to consider is whether the register range here contains any
registers that may be used in another driver, e.g. a second timer,
a PWM, or a clk controller. If not, you are fairly free to pick any of these
approaches.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-03-31 21:52                           ` Arnd Bergmann
@ 2022-04-01 16:05                             ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-01 16:05 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Thursday, March 31, 2022 4:53 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree


> I don't think you can do this, if you are using the syscon regmap, you go through the regmap indirection rather than accessing the mmio register by virtual address, and this may result in some extra code in your driver, and a little runtime overhead.

> If you prefer to avoid that, you can go back to having the timer node as the parent, but without being a syscon. In this case, the watchdog would be handled in one of these ways:

> a) a child device gets created from the clocksource driver and bound to the
    watchdog driver, which then uses a private interface between the clocksource
    and the watchdog to access the registers

> b) the clocksource driver itself registers as a watchdog driver, without
    having a separate driver module

> One thing to consider is whether the register range here contains any registers that may be used in another driver, e.g. a second timer, a PWM, or a clk controller. If not, you are fairly free to pick any of these approaches.

I will try to use the b) approach everything in that range is timer or watchdog related. There is a second timer however there are no plans on using that. Should the combined code still live inside the driver/timer directory or should it be moved to mfd?

Thanks,

-Nick

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-01 16:05                             ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-01 16:05 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Thursday, March 31, 2022 4:53 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree


> I don't think you can do this, if you are using the syscon regmap, you go through the regmap indirection rather than accessing the mmio register by virtual address, and this may result in some extra code in your driver, and a little runtime overhead.

> If you prefer to avoid that, you can go back to having the timer node as the parent, but without being a syscon. In this case, the watchdog would be handled in one of these ways:

> a) a child device gets created from the clocksource driver and bound to the
    watchdog driver, which then uses a private interface between the clocksource
    and the watchdog to access the registers

> b) the clocksource driver itself registers as a watchdog driver, without
    having a separate driver module

> One thing to consider is whether the register range here contains any registers that may be used in another driver, e.g. a second timer, a PWM, or a clk controller. If not, you are fairly free to pick any of these approaches.

I will try to use the b) approach everything in that range is timer or watchdog related. There is a second timer however there are no plans on using that. Should the combined code still live inside the driver/timer directory or should it be moved to mfd?

Thanks,

-Nick
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-01 16:05                             ` Hawkins, Nick
@ 2022-04-01 16:30                               ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-01 16:30 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Fri, Apr 1, 2022 at 6:05 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > I don't think you can do this, if you are using the syscon regmap, you go through the regmap indirection rather than accessing the mmio register by virtual address, and this may result in some extra code in your driver, and a little runtime overhead.
>
> > If you prefer to avoid that, you can go back to having the timer node as the parent, but without being a syscon. In this case, the watchdog would be handled in one of these ways:
>
> > a) a child device gets created from the clocksource driver and bound to the
>     watchdog driver, which then uses a private interface between the clocksource
>     and the watchdog to access the registers
>
> > b) the clocksource driver itself registers as a watchdog driver, without
>     having a separate driver module
>
> > One thing to consider is whether the register range here contains any registers that may be used in another driver, e.g. a second timer, a PWM, or a clk controller. If not, you are fairly free to pick any of these approaches.
>
> I will try to use the b) approach everything in that range is timer or watchdog related. There is a second timer however there are no plans on using that. Should the combined code still live inside the driver/timer directory or should it be moved to mfd?

I would put it into drivers/clocksource/, I don't think drivers/mtd
would be any better,
but there is a chance that the clocksource maintainers don't want to
have the watchdog
code in their tree.

        Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-01 16:30                               ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-01 16:30 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Fri, Apr 1, 2022 at 6:05 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > I don't think you can do this, if you are using the syscon regmap, you go through the regmap indirection rather than accessing the mmio register by virtual address, and this may result in some extra code in your driver, and a little runtime overhead.
>
> > If you prefer to avoid that, you can go back to having the timer node as the parent, but without being a syscon. In this case, the watchdog would be handled in one of these ways:
>
> > a) a child device gets created from the clocksource driver and bound to the
>     watchdog driver, which then uses a private interface between the clocksource
>     and the watchdog to access the registers
>
> > b) the clocksource driver itself registers as a watchdog driver, without
>     having a separate driver module
>
> > One thing to consider is whether the register range here contains any registers that may be used in another driver, e.g. a second timer, a PWM, or a clk controller. If not, you are fairly free to pick any of these approaches.
>
> I will try to use the b) approach everything in that range is timer or watchdog related. There is a second timer however there are no plans on using that. Should the combined code still live inside the driver/timer directory or should it be moved to mfd?

I would put it into drivers/clocksource/, I don't think drivers/mtd
would be any better,
but there is a chance that the clocksource maintainers don't want to
have the watchdog
code in their tree.

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog
  2022-03-10 19:52 ` [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog nick.hawkins
@ 2022-04-04 14:28   ` Guenter Roeck
  2022-04-04 16:25     ` Hawkins, Nick
  0 siblings, 1 reply; 80+ messages in thread
From: Guenter Roeck @ 2022-04-04 14:28 UTC (permalink / raw)
  To: nick.hawkins; +Cc: verdun, Wim Van Sebroeck, linux-kernel, linux-watchdog

On Thu, Mar 10, 2022 at 01:52:22PM -0600, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> Adding support for the HPE GXP Watchdog. It is new to the linux
> community and this along with several other patches is the first
> support for it. The GXP asic contains a full compliment of
> timers one of which is the watchdog timer. The watchdog timer
> is 16 bit and has 10ms resolution.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>  drivers/watchdog/Kconfig   |   8 ++
>  drivers/watchdog/Makefile  |   1 +
>  drivers/watchdog/gxp-wdt.c | 191 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 200 insertions(+)
>  create mode 100644 drivers/watchdog/gxp-wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index c8fa79da23b3..cb210d2978d2 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1820,6 +1820,14 @@ config RALINK_WDT
>  	help
>  	  Hardware driver for the Ralink SoC Watchdog Timer.
>  
> +config GXP_WATCHDOG
> +	tristate "HPE GXP watchdog support"
> +	depends on ARCH_HPE_GXP
> +	select WATCHDOG_CORE
> +	help
> +	  Say Y here to include support for the watchdog timer
> +	  in HPE GXP SoCs.
> +
>  config MT7621_WDT
>  	tristate "Mediatek SoC watchdog"
>  	select WATCHDOG_CORE
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f7da867e8782..e2acf3a0d0fc 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -92,6 +92,7 @@ obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
>  obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
>  obj-$(CONFIG_PM8916_WATCHDOG) += pm8916_wdt.o
>  obj-$(CONFIG_ARM_SMC_WATCHDOG) += arm_smc_wdt.o
> +obj-$(CONFIG_GXP_WATCHDOG) += gxp-wdt.o
>  obj-$(CONFIG_VISCONTI_WATCHDOG) += visconti_wdt.o
>  obj-$(CONFIG_MSC313E_WATCHDOG) += msc313e_wdt.o
>  obj-$(CONFIG_APPLE_WATCHDOG) += apple_wdt.o
> diff --git a/drivers/watchdog/gxp-wdt.c b/drivers/watchdog/gxp-wdt.c
> new file mode 100644
> index 000000000000..d2b489cb4774
> --- /dev/null
> +++ b/drivers/watchdog/gxp-wdt.c
> @@ -0,0 +1,191 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
> + *
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/types.h>
> +#include <linux/watchdog.h>
> +
> +#define MASK_WDGCS_ENABLE	0x01
> +#define MASK_WDGCS_RELOAD	0x04
> +#define MASK_WDGCS_NMIEN	0x08
> +#define MASK_WDGCS_WARN		0x80
> +
> +#define WDT_MAX_TIMEOUT_MS	655000
> +#define WDT_DEFAULT_TIMEOUT	30
> +#define SECS_TO_WDOG_TICKS(x) ((x) * 100)
> +#define WDOG_TICKS_TO_SECS(x) ((x) / 100)
> +
> +struct gxp_wdt {
> +	void __iomem	*counter;
> +	void __iomem	*control;
> +	struct watchdog_device	wdd;

Odd variable alignment. Might as well just use spaces before the
variable names.

> +};
> +
> +static void gxp_wdt_enable_reload(struct gxp_wdt *drvdata)
> +{
> +	uint8_t val;
> +
> +	val = readb(drvdata->control);
> +	val |= (MASK_WDGCS_ENABLE | MASK_WDGCS_RELOAD);
> +	writeb(val, drvdata->control);
> +}
> +
> +static int gxp_wdt_start(struct watchdog_device *wdd)
> +{
> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
> +
> +	writew((SECS_TO_WDOG_TICKS(wdd->timeout)), drvdata->counter);

Unnecessary iand confusing () around SECS_TO_WDOG_TICKS().

> +	gxp_wdt_enable_reload(drvdata);
> +	return 0;
> +}
> +
> +static int gxp_wdt_stop(struct watchdog_device *wdd)
> +{
> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
> +	uint8_t val;
> +
> +	val = readb_relaxed(drvdata->control);
> +	val &= ~MASK_WDGCS_ENABLE;
> +	writeb(val, drvdata->control);
> +	return 0;
> +}
> +
> +static int gxp_wdt_set_timeout(struct watchdog_device *wdd,
> +			       unsigned int timeout)
> +{
> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
> +	uint32_t actual;

Please use u32 as suggested by checkpatch. Same everywhere.

> +
> +	wdd->timeout = timeout;
> +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
> +	writew((SECS_TO_WDOG_TICKS(actual)), drvdata->counter);

Unnecessary ()

> +
> +	return 0;
> +}
> +
> +static unsigned int gxp_wdt_get_timeleft(struct watchdog_device *wdd)
> +{
> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
> +	uint32_t val = readw(drvdata->counter);
> +
> +	return WDOG_TICKS_TO_SECS(val);
> +}
> +
> +static int gxp_wdt_ping(struct watchdog_device *wdd)
> +{
> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
> +
> +	gxp_wdt_enable_reload(drvdata);
> +	return 0;
> +}
> +
> +static int gxp_restart(struct watchdog_device *wdd, unsigned long action,
> +		       void *data)
> +{
> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
> +
> +	writew(10, drvdata->counter);
> +	gxp_wdt_enable_reload(drvdata);
> +	mdelay(100);
> +	return 0;
> +}
> +
> +static const struct watchdog_ops gxp_wdt_ops = {
> +	.owner =	THIS_MODULE,
> +	.start =	gxp_wdt_start,
> +	.stop =		gxp_wdt_stop,
> +	.ping = gxp_wdt_ping,
> +	.set_timeout	= gxp_wdt_set_timeout,
> +	.get_timeleft =	gxp_wdt_get_timeleft,
> +	.restart =	gxp_restart,

Please be consistent with alignments.

> +};
> +
> +static const struct watchdog_info gxp_wdt_info = {
> +	.options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
> +	.identity = "HPE GXP Watchdog timer",
> +};
> +
> +static int gxp_wdt_probe(struct platform_device *pdev)
> +{
> +	struct resource *res;
> +	struct device *dev = &pdev->dev;
> +	struct gxp_wdt *drvdata;
> +	int err;
> +	uint8_t val;

Please use u8.

> +
> +	drvdata = devm_kzalloc(dev, sizeof(struct gxp_wdt), GFP_KERNEL);
> +	if (!drvdata)
> +		return -ENOMEM;
> +	platform_set_drvdata(pdev, drvdata);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	drvdata->counter = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(drvdata->counter))
> +		return PTR_ERR(drvdata->counter);
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> +	drvdata->control = devm_ioremap_resource(dev, res);
> +	if (IS_ERR(drvdata->control))
> +		return PTR_ERR(drvdata->control);

Please use a single resource and offsets, or explain in a comment
why that does not work for this driver.

> +
> +	drvdata->wdd.info = &gxp_wdt_info;
> +	drvdata->wdd.ops = &gxp_wdt_ops;
> +	drvdata->wdd.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT_MS;
> +	drvdata->wdd.parent = &pdev->dev;
> +
> +	watchdog_set_drvdata(&drvdata->wdd, drvdata);
> +	watchdog_init_timeout(&drvdata->wdd, WDT_DEFAULT_TIMEOUT, dev);

That disables setting the watchdog timeout through devicetree, and is thus
mostly pointless. It is better to set the default timeout via variable
assignment above if you don't want to use devicetree to set the timeout,
or pass a timeout value of 0 to get the timeout from devicetree (if
configured).

> +	watchdog_set_nowayout(&drvdata->wdd, WATCHDOG_NOWAYOUT);
> +
> +	val = readb(drvdata->control);
> +	if (val & MASK_WDGCS_ENABLE)
> +		set_bit(WDOG_HW_RUNNING, &drvdata->wdd.status);
> +
> +	watchdog_set_restart_priority(&drvdata->wdd, 128);
> +
> +	watchdog_stop_on_reboot(&drvdata->wdd);
> +	err = devm_watchdog_register_device(dev, &drvdata->wdd);
> +	if (err) {
> +		dev_err(dev, "Failed to register watchdog device");
> +		return err;
> +	}
> +
> +	dev_info(dev, "HPE GXP watchdog timer");
> +	return 0;
> +}
> +
> +static int gxp_wdt_remove(struct platform_device *pdev)
> +{
> +	return 0;
> +}

Pointless remove function.

> +
> +static const struct of_device_id gxp_wdt_of_match[] = {
> +	{ .compatible = "hpe,gxp-wdt", },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, gxp_wdt_of_match);
> +
> +static struct platform_driver gxp_wdt_driver = {
> +	.probe		= gxp_wdt_probe,
> +	.remove		= gxp_wdt_remove,
> +	.driver = {
> +		.name =		"gxp-wdt",
> +		.of_match_table = gxp_wdt_of_match,
> +	},
> +};
> +module_platform_driver(gxp_wdt_driver);
> +
> +MODULE_AUTHOR("Nick Hawkins <nick.hawkins@hpe.com>");
> +MODULE_AUTHOR("Jean-Marie Verdun <verdun@hpe.com>");
> +MODULE_DESCRIPTION("Driver for GXP watchdog timer");

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog
  2022-04-04 14:28   ` Guenter Roeck
@ 2022-04-04 16:25     ` Hawkins, Nick
  2022-04-04 16:41       ` Guenter Roeck
  0 siblings, 1 reply; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-04 16:25 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Verdun, Jean-Marie, Wim Van Sebroeck, linux-kernel, linux-watchdog



-----Original Message-----
From: Guenter Roeck [mailto:linux@roeck-us.net] 
Sent: Monday, April 4, 2022 9:29 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Verdun, Jean-Marie <verdun@hpe.com>; Wim Van Sebroeck <wim@linux-watchdog.org>; linux-kernel@vger.kernel.org; linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog

On Thu, Mar 10, 2022 at 01:52:22PM -0600, nick.hawkins@hpe.com wrote:
>> From: Nick Hawkins <nick.hawkins@hpe.com>
>> 
>> Adding support for the HPE GXP Watchdog. It is new to the linux 
>> community and this along with several other patches is the first 
>> support for it. The GXP asic contains a full compliment of timers one 
>> of which is the watchdog timer. The watchdog timer is 16 bit and has 
>> 10ms resolution.
>> 
>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
>> ---
>>  drivers/watchdog/Kconfig   |   8 ++
>>  drivers/watchdog/Makefile  |   1 +
>>  drivers/watchdog/gxp-wdt.c | 191 
>> +++++++++++++++++++++++++++++++++++++
>>  3 files changed, 200 insertions(+)
>>  create mode 100644 drivers/watchdog/gxp-wdt.c
>> 
>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 
>> c8fa79da23b3..cb210d2978d2 100644
>> --- a/drivers/watchdog/Kconfig
>> +++ b/drivers/watchdog/Kconfig
>> @@ -1820,6 +1820,14 @@ config RALINK_WDT
>>  	help
>>  	  Hardware driver for the Ralink SoC Watchdog Timer.
>>  
>> +config GXP_WATCHDOG
>> +	tristate "HPE GXP watchdog support"
>> +	depends on ARCH_HPE_GXP
>> +	select WATCHDOG_CORE
>> +	help
>> +	  Say Y here to include support for the watchdog timer
>> +	  in HPE GXP SoCs.
>> +
>>  config MT7621_WDT
>>  	tristate "Mediatek SoC watchdog"
>>  	select WATCHDOG_CORE
>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile 
>> index f7da867e8782..e2acf3a0d0fc 100644
>> --- a/drivers/watchdog/Makefile
>> +++ b/drivers/watchdog/Makefile
>> @@ -92,6 +92,7 @@ obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
>>  obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
>>  obj-$(CONFIG_PM8916_WATCHDOG) += pm8916_wdt.o
>>  obj-$(CONFIG_ARM_SMC_WATCHDOG) += arm_smc_wdt.o
>> +obj-$(CONFIG_GXP_WATCHDOG) += gxp-wdt.o
>>  obj-$(CONFIG_VISCONTI_WATCHDOG) += visconti_wdt.o
>>  obj-$(CONFIG_MSC313E_WATCHDOG) += msc313e_wdt.o
>>  obj-$(CONFIG_APPLE_WATCHDOG) += apple_wdt.o diff --git 
>> a/drivers/watchdog/gxp-wdt.c b/drivers/watchdog/gxp-wdt.c new file 
>> mode 100644 index 000000000000..d2b489cb4774
>> --- /dev/null
>> +++ b/drivers/watchdog/gxp-wdt.c
>> @@ -0,0 +1,191 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
>> + *
>> + *
>> + * This program is free software; you can redistribute it and/or 
>> +modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/types.h>
>> +#include <linux/watchdog.h>
>> +
>> +#define MASK_WDGCS_ENABLE	0x01
>> +#define MASK_WDGCS_RELOAD	0x04
>> +#define MASK_WDGCS_NMIEN	0x08
>> +#define MASK_WDGCS_WARN		0x80
>> +
>> +#define WDT_MAX_TIMEOUT_MS	655000
>> +#define WDT_DEFAULT_TIMEOUT	30
>> +#define SECS_TO_WDOG_TICKS(x) ((x) * 100) #define 
>> +WDOG_TICKS_TO_SECS(x) ((x) / 100)
>> +
>> +struct gxp_wdt {
>> +	void __iomem	*counter;
>> +	void __iomem	*control;
>> +	struct watchdog_device	wdd;

> Odd variable alignment. Might as well just use spaces before the variable names.

Fixed

>> +};
>> +
>> +static void gxp_wdt_enable_reload(struct gxp_wdt *drvdata) {
>> +	uint8_t val;
>> +
>> +	val = readb(drvdata->control);
>> +	val |= (MASK_WDGCS_ENABLE | MASK_WDGCS_RELOAD);
>> +	writeb(val, drvdata->control);
>> +}
>> +
>> +static int gxp_wdt_start(struct watchdog_device *wdd) {
>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>> +
>> +	writew((SECS_TO_WDOG_TICKS(wdd->timeout)), drvdata->counter);

> Unnecessary iand confusing () around SECS_TO_WDOG_TICKS().

Fixed

>> +	gxp_wdt_enable_reload(drvdata);
>> +	return 0;
>> +}
>> +
>> +static int gxp_wdt_stop(struct watchdog_device *wdd) {
>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>> +	uint8_t val;
>> +
>> +	val = readb_relaxed(drvdata->control);
>> +	val &= ~MASK_WDGCS_ENABLE;
>> +	writeb(val, drvdata->control);
>> +	return 0;
>> +}
>> +
>> +static int gxp_wdt_set_timeout(struct watchdog_device *wdd,
>> +			       unsigned int timeout)
>> +{
>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>> +	uint32_t actual;

> Please use u32 as suggested by checkpatch. Same everywhere.

Fixed, checkpatch did not flag this, is there an option I should be using with checkpatch.pl?
>> +
>> +	wdd->timeout = timeout;
>> +	actual = min(timeout, wdd->max_hw_heartbeat_ms / 1000);
>> +	writew((SECS_TO_WDOG_TICKS(actual)), drvdata->counter);

> Unnecessary ()

Fixed

>> +
>> +	return 0;
>> +}
>> +
>> +static unsigned int gxp_wdt_get_timeleft(struct watchdog_device *wdd) 
>> +{
>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>> +	uint32_t val = readw(drvdata->counter);
>> +
>> +	return WDOG_TICKS_TO_SECS(val);
>> +}
>> +
>> +static int gxp_wdt_ping(struct watchdog_device *wdd) {
>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>> +
>> +	gxp_wdt_enable_reload(drvdata);
>> +	return 0;
>> +}
>> +
>> +static int gxp_restart(struct watchdog_device *wdd, unsigned long action,
>> +		       void *data)
>> +{
>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>> +
>> +	writew(10, drvdata->counter);
>> +	gxp_wdt_enable_reload(drvdata);
>> +	mdelay(100);
>> +	return 0;
>> +}
>> +
>> +static const struct watchdog_ops gxp_wdt_ops = {
>> +	.owner =	THIS_MODULE,
>> +	.start =	gxp_wdt_start,
>> +	.stop =		gxp_wdt_stop,
>> +	.ping = gxp_wdt_ping,
>> +	.set_timeout	= gxp_wdt_set_timeout,
>> +	.get_timeleft =	gxp_wdt_get_timeleft,
>> +	.restart =	gxp_restart,

> Please be consistent with alignments.

Fixed.

>> +};
>> +
>> +static const struct watchdog_info gxp_wdt_info = {
>> +	.options = WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING,
>> +	.identity = "HPE GXP Watchdog timer", };
>> +
>> +static int gxp_wdt_probe(struct platform_device *pdev) {
>> +	struct resource *res;
>> +	struct device *dev = &pdev->dev;
>> +	struct gxp_wdt *drvdata;
>> +	int err;
>> +	uint8_t val;

> Please use u8.

Fixed.

>> +
>> +	drvdata = devm_kzalloc(dev, sizeof(struct gxp_wdt), GFP_KERNEL);
>> +	if (!drvdata)
>> +		return -ENOMEM;
>> +	platform_set_drvdata(pdev, drvdata);
>> +
>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +	drvdata->counter = devm_ioremap_resource(dev, res);
>> +	if (IS_ERR(drvdata->counter))
>> +		return PTR_ERR(drvdata->counter);
>> +
>> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>> +	drvdata->control = devm_ioremap_resource(dev, res);
>> +	if (IS_ERR(drvdata->control))
>> +		return PTR_ERR(drvdata->control);

> Please use a single resource and offsets, or explain in a comment why that does not work for this driver.

I actually was flagged for this on our separate device tree review and have trying to determine a better solution for it. The primary issue is that there are many controls in the register region. The current suggestion I am pursuing is having the timer be the parent and watchdog be the child all in the same driver. I need to get feedback from the clocksource owners on this. For reference here is the discussion: https://lore.kernel.org/all/CAK8P3a1Cc+2oY9djdp11PuOW+TBQ0zf+p8QaDY3aerk1QqaG-g@mail.gmail.com/  Any input on this is welcome.

>> +
>> +	drvdata->wdd.info = &gxp_wdt_info;
>> +	drvdata->wdd.ops = &gxp_wdt_ops;
>> +	drvdata->wdd.max_hw_heartbeat_ms = WDT_MAX_TIMEOUT_MS;
>> +	drvdata->wdd.parent = &pdev->dev;
>> +
>> +	watchdog_set_drvdata(&drvdata->wdd, drvdata);
>> +	watchdog_init_timeout(&drvdata->wdd, WDT_DEFAULT_TIMEOUT, dev);

> That disables setting the watchdog timeout through devicetree, and is thus mostly pointless. It is better to set the default timeout via variable assignment above if you don't want to use devicetree to set the timeout, or pass a timeout value of 0 to get the timeout from devicetree (if configured).

Thank you.

>> +	watchdog_set_nowayout(&drvdata->wdd, WATCHDOG_NOWAYOUT);
>> +
>> +	val = readb(drvdata->control);
>> +	if (val & MASK_WDGCS_ENABLE)
>> +		set_bit(WDOG_HW_RUNNING, &drvdata->wdd.status);
>> +
>> +	watchdog_set_restart_priority(&drvdata->wdd, 128);
>> +
>> +	watchdog_stop_on_reboot(&drvdata->wdd);
>> +	err = devm_watchdog_register_device(dev, &drvdata->wdd);
>> +	if (err) {
>> +		dev_err(dev, "Failed to register watchdog device");
>> +		return err;
>> +	}
>> +
>> +	dev_info(dev, "HPE GXP watchdog timer");
>> +	return 0;
>> +}
>> +
>> +static int gxp_wdt_remove(struct platform_device *pdev) {
>> +	return 0;
>> +}

> Pointless remove function.

Fixed.

>> +
>> +static const struct of_device_id gxp_wdt_of_match[] = {
>> +	{ .compatible = "hpe,gxp-wdt", },
>> +	{},
>> +};
>> +MODULE_DEVICE_TABLE(of, gxp_wdt_of_match);
>> +
>> +static struct platform_driver gxp_wdt_driver = {
>> +	.probe		= gxp_wdt_probe,
>> +	.remove		= gxp_wdt_remove,
>> +	.driver = {
>> +		.name =		"gxp-wdt",
>> +		.of_match_table = gxp_wdt_of_match,
>> +	},
>> +};
>> +module_platform_driver(gxp_wdt_driver);
>> +
>> +MODULE_AUTHOR("Nick Hawkins <nick.hawkins@hpe.com>"); 
>> +MODULE_AUTHOR("Jean-Marie Verdun <verdun@hpe.com>"); 
>> +MODULE_DESCRIPTION("Driver for GXP watchdog timer");

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog
  2022-04-04 16:25     ` Hawkins, Nick
@ 2022-04-04 16:41       ` Guenter Roeck
  0 siblings, 0 replies; 80+ messages in thread
From: Guenter Roeck @ 2022-04-04 16:41 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Verdun, Jean-Marie, Wim Van Sebroeck, linux-kernel, linux-watchdog

On 4/4/22 09:25, Hawkins, Nick wrote:
> 
> 
> -----Original Message-----
> From: Guenter Roeck [mailto:linux@roeck-us.net]
> Sent: Monday, April 4, 2022 9:29 AM
> To: Hawkins, Nick <nick.hawkins@hpe.com>
> Cc: Verdun, Jean-Marie <verdun@hpe.com>; Wim Van Sebroeck <wim@linux-watchdog.org>; linux-kernel@vger.kernel.org; linux-watchdog@vger.kernel.org
> Subject: Re: [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog
> 
> On Thu, Mar 10, 2022 at 01:52:22PM -0600, nick.hawkins@hpe.com wrote:
>>> From: Nick Hawkins <nick.hawkins@hpe.com>
>>>
>>> Adding support for the HPE GXP Watchdog. It is new to the linux
>>> community and this along with several other patches is the first
>>> support for it. The GXP asic contains a full compliment of timers one
>>> of which is the watchdog timer. The watchdog timer is 16 bit and has
>>> 10ms resolution.
>>>
>>> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
>>> ---
>>>   drivers/watchdog/Kconfig   |   8 ++
>>>   drivers/watchdog/Makefile  |   1 +
>>>   drivers/watchdog/gxp-wdt.c | 191
>>> +++++++++++++++++++++++++++++++++++++
>>>   3 files changed, 200 insertions(+)
>>>   create mode 100644 drivers/watchdog/gxp-wdt.c
>>>
>>> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
>>> c8fa79da23b3..cb210d2978d2 100644
>>> --- a/drivers/watchdog/Kconfig
>>> +++ b/drivers/watchdog/Kconfig
>>> @@ -1820,6 +1820,14 @@ config RALINK_WDT
>>>   	help
>>>   	  Hardware driver for the Ralink SoC Watchdog Timer.
>>>   
>>> +config GXP_WATCHDOG
>>> +	tristate "HPE GXP watchdog support"
>>> +	depends on ARCH_HPE_GXP
>>> +	select WATCHDOG_CORE
>>> +	help
>>> +	  Say Y here to include support for the watchdog timer
>>> +	  in HPE GXP SoCs.
>>> +
>>>   config MT7621_WDT
>>>   	tristate "Mediatek SoC watchdog"
>>>   	select WATCHDOG_CORE
>>> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
>>> index f7da867e8782..e2acf3a0d0fc 100644
>>> --- a/drivers/watchdog/Makefile
>>> +++ b/drivers/watchdog/Makefile
>>> @@ -92,6 +92,7 @@ obj-$(CONFIG_RTD119X_WATCHDOG) += rtd119x_wdt.o
>>>   obj-$(CONFIG_SPRD_WATCHDOG) += sprd_wdt.o
>>>   obj-$(CONFIG_PM8916_WATCHDOG) += pm8916_wdt.o
>>>   obj-$(CONFIG_ARM_SMC_WATCHDOG) += arm_smc_wdt.o
>>> +obj-$(CONFIG_GXP_WATCHDOG) += gxp-wdt.o
>>>   obj-$(CONFIG_VISCONTI_WATCHDOG) += visconti_wdt.o
>>>   obj-$(CONFIG_MSC313E_WATCHDOG) += msc313e_wdt.o
>>>   obj-$(CONFIG_APPLE_WATCHDOG) += apple_wdt.o diff --git
>>> a/drivers/watchdog/gxp-wdt.c b/drivers/watchdog/gxp-wdt.c new file
>>> mode 100644 index 000000000000..d2b489cb4774
>>> --- /dev/null
>>> +++ b/drivers/watchdog/gxp-wdt.c
>>> @@ -0,0 +1,191 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.
>>> + *
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> +modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include <linux/delay.h>
>>> +#include <linux/io.h>
>>> +#include <linux/module.h>
>>> +#include <linux/platform_device.h>
>>> +#include <linux/of_address.h>
>>> +#include <linux/of_platform.h>
>>> +#include <linux/types.h>
>>> +#include <linux/watchdog.h>
>>> +
>>> +#define MASK_WDGCS_ENABLE	0x01
>>> +#define MASK_WDGCS_RELOAD	0x04
>>> +#define MASK_WDGCS_NMIEN	0x08
>>> +#define MASK_WDGCS_WARN		0x80
>>> +
>>> +#define WDT_MAX_TIMEOUT_MS	655000
>>> +#define WDT_DEFAULT_TIMEOUT	30
>>> +#define SECS_TO_WDOG_TICKS(x) ((x) * 100) #define
>>> +WDOG_TICKS_TO_SECS(x) ((x) / 100)
>>> +
>>> +struct gxp_wdt {
>>> +	void __iomem	*counter;
>>> +	void __iomem	*control;
>>> +	struct watchdog_device	wdd;
> 
>> Odd variable alignment. Might as well just use spaces before the variable names.
> 
> Fixed
> 
>>> +};
>>> +
>>> +static void gxp_wdt_enable_reload(struct gxp_wdt *drvdata) {
>>> +	uint8_t val;
>>> +
>>> +	val = readb(drvdata->control);
>>> +	val |= (MASK_WDGCS_ENABLE | MASK_WDGCS_RELOAD);
>>> +	writeb(val, drvdata->control);
>>> +}
>>> +
>>> +static int gxp_wdt_start(struct watchdog_device *wdd) {
>>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>>> +
>>> +	writew((SECS_TO_WDOG_TICKS(wdd->timeout)), drvdata->counter);
> 
>> Unnecessary iand confusing () around SECS_TO_WDOG_TICKS().
> 
> Fixed
> 
>>> +	gxp_wdt_enable_reload(drvdata);
>>> +	return 0;
>>> +}
>>> +
>>> +static int gxp_wdt_stop(struct watchdog_device *wdd) {
>>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>>> +	uint8_t val;
>>> +
>>> +	val = readb_relaxed(drvdata->control);
>>> +	val &= ~MASK_WDGCS_ENABLE;
>>> +	writeb(val, drvdata->control);
>>> +	return 0;
>>> +}
>>> +
>>> +static int gxp_wdt_set_timeout(struct watchdog_device *wdd,
>>> +			       unsigned int timeout)
>>> +{
>>> +	struct gxp_wdt *drvdata = watchdog_get_drvdata(wdd);
>>> +	uint32_t actual;
> 
>> Please use u32 as suggested by checkpatch. Same everywhere.
> 
> Fixed, checkpatch did not flag this, is there an option I should be using with checkpatch.pl?

--strict

Guenter

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-01 16:30                               ` Arnd Bergmann
@ 2022-04-04 20:22                                 ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-04 20:22 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Friday, April 1, 2022 11:30 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Fri, Apr 1, 2022 at 6:05 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > > I don't think you can do this, if you are using the syscon regmap, you go through the regmap indirection rather than accessing the mmio register by virtual address, and this may result in some extra code in your driver, and a little runtime overhead.
> >
> > > If you prefer to avoid that, you can go back to having the timer node as the parent, but without being a syscon. In this case, the watchdog would be handled in one of these ways:
> >
> > > a) a child device gets created from the clocksource driver and bound 
> > > to the
> >     watchdog driver, which then uses a private interface between the clocksource
> >     and the watchdog to access the registers
> >
> > > b) the clocksource driver itself registers as a watchdog driver, 
> > > without
> >     having a separate driver module
> >
> > > One thing to consider is whether the register range here contains any registers that may be used in another driver, e.g. a second timer, a PWM, or a clk controller. If not, you are fairly free to pick any of these approaches.
> >
> > I will try to use the b) approach everything in that range is timer or watchdog related. There is a second timer however there are no plans on using that. Should the combined code still live inside the driver/timer directory or should it be moved to mfd?

> > I would put it into drivers/clocksource/, I don't think drivers/mtd would be any better, but there is a chance that the clocksource maintainers don't want to have the watchdog code in their tree.

While trying to discover how to creating two devices in one driver I ran across an interesting .dtsi and I was wondering if this would be a valid approach for my situation as well. The pertinent files are:
1) drivers/clocksource/timer-digicolor.c
2) arch/arm/boot/dts/cx92755.dtsi
3) drivers/watchdog/digicolor_wdt.c

Here they are just sharing the same register area:

timer@f0000fc0 {
	compatible = "cnxt,cx92755-timer";
	reg = <0xf0000fc0 0x40>;
	interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
	clocks = <&main_clk>;
};

rtc@f0000c30 {
	compatible = "cnxt,cx92755-rtc";
	reg = <0xf0000c30 0x18>;
	interrupts = <25>;
};

watchdog@f0000fc0 {
	compatible = "cnxt,cx92755-wdt";
	reg = <0xf0000fc0 0x8>;
	clocks = <&main_clk>;
	timeout-sec = <15>;
};

Thanks,

-Nick Hawkins

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-04 20:22                                 ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-04 20:22 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Friday, April 1, 2022 11:30 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Fri, Apr 1, 2022 at 6:05 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > > I don't think you can do this, if you are using the syscon regmap, you go through the regmap indirection rather than accessing the mmio register by virtual address, and this may result in some extra code in your driver, and a little runtime overhead.
> >
> > > If you prefer to avoid that, you can go back to having the timer node as the parent, but without being a syscon. In this case, the watchdog would be handled in one of these ways:
> >
> > > a) a child device gets created from the clocksource driver and bound 
> > > to the
> >     watchdog driver, which then uses a private interface between the clocksource
> >     and the watchdog to access the registers
> >
> > > b) the clocksource driver itself registers as a watchdog driver, 
> > > without
> >     having a separate driver module
> >
> > > One thing to consider is whether the register range here contains any registers that may be used in another driver, e.g. a second timer, a PWM, or a clk controller. If not, you are fairly free to pick any of these approaches.
> >
> > I will try to use the b) approach everything in that range is timer or watchdog related. There is a second timer however there are no plans on using that. Should the combined code still live inside the driver/timer directory or should it be moved to mfd?

> > I would put it into drivers/clocksource/, I don't think drivers/mtd would be any better, but there is a chance that the clocksource maintainers don't want to have the watchdog code in their tree.

While trying to discover how to creating two devices in one driver I ran across an interesting .dtsi and I was wondering if this would be a valid approach for my situation as well. The pertinent files are:
1) drivers/clocksource/timer-digicolor.c
2) arch/arm/boot/dts/cx92755.dtsi
3) drivers/watchdog/digicolor_wdt.c

Here they are just sharing the same register area:

timer@f0000fc0 {
	compatible = "cnxt,cx92755-timer";
	reg = <0xf0000fc0 0x40>;
	interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
	clocks = <&main_clk>;
};

rtc@f0000c30 {
	compatible = "cnxt,cx92755-rtc";
	reg = <0xf0000c30 0x18>;
	interrupts = <25>;
};

watchdog@f0000fc0 {
	compatible = "cnxt,cx92755-wdt";
	reg = <0xf0000fc0 0x8>;
	clocks = <&main_clk>;
	timeout-sec = <15>;
};

Thanks,

-Nick Hawkins
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-04 20:22                                 ` Hawkins, Nick
@ 2022-04-04 22:02                                   ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-04 22:02 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Mon, Apr 4, 2022 at 10:22 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > > I would put it into drivers/clocksource/, I don't think drivers/mtd would be any better, but there is a chance that the clocksource maintainers don't want to have the watchdog code in their tree.
>
> While trying to discover how to creating two devices in one driver I ran across an interesting .dtsi and I was wondering if this would be a valid approach for my situation as well. The pertinent files are:
> 1) drivers/clocksource/timer-digicolor.c
> 2) arch/arm/boot/dts/cx92755.dtsi
> 3) drivers/watchdog/digicolor_wdt.c
>
> Here they are just sharing the same register area:
>
> timer@f0000fc0 {
>         compatible = "cnxt,cx92755-timer";
>         reg = <0xf0000fc0 0x40>;
>         interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
>         clocks = <&main_clk>;
> };
>
> rtc@f0000c30 {
>         compatible = "cnxt,cx92755-rtc";
>         reg = <0xf0000c30 0x18>;
>         interrupts = <25>;
> };
>
> watchdog@f0000fc0 {
>         compatible = "cnxt,cx92755-wdt";
>         reg = <0xf0000fc0 0x8>;
>         clocks = <&main_clk>;
>         timeout-sec = <15>;
> };

Right, it is possible to make this work, but it's not recommended, and you have
to work around the sanity checks in the code that try to keep you from doing it
wrong, as well as any tooling that tries to check for these in the DT.

         Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-04 22:02                                   ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-04 22:02 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Mon, Apr 4, 2022 at 10:22 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > > I would put it into drivers/clocksource/, I don't think drivers/mtd would be any better, but there is a chance that the clocksource maintainers don't want to have the watchdog code in their tree.
>
> While trying to discover how to creating two devices in one driver I ran across an interesting .dtsi and I was wondering if this would be a valid approach for my situation as well. The pertinent files are:
> 1) drivers/clocksource/timer-digicolor.c
> 2) arch/arm/boot/dts/cx92755.dtsi
> 3) drivers/watchdog/digicolor_wdt.c
>
> Here they are just sharing the same register area:
>
> timer@f0000fc0 {
>         compatible = "cnxt,cx92755-timer";
>         reg = <0xf0000fc0 0x40>;
>         interrupts = <19>, <31>, <34>, <35>, <52>, <53>, <54>, <55>;
>         clocks = <&main_clk>;
> };
>
> rtc@f0000c30 {
>         compatible = "cnxt,cx92755-rtc";
>         reg = <0xf0000c30 0x18>;
>         interrupts = <25>;
> };
>
> watchdog@f0000fc0 {
>         compatible = "cnxt,cx92755-wdt";
>         reg = <0xf0000fc0 0x8>;
>         clocks = <&main_clk>;
>         timeout-sec = <15>;
> };

Right, it is possible to make this work, but it's not recommended, and you have
to work around the sanity checks in the code that try to keep you from doing it
wrong, as well as any tooling that tries to check for these in the DT.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-04 22:02                                   ` Arnd Bergmann
@ 2022-04-05 21:21                                     ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-05 21:21 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Monday, April 4, 2022 5:02 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>>
Cc: Arnd Bergmann <arnd@arndb.de>>; Verdun, Jean-Marie <verdun@hpe.com>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Mon, Apr 4, 2022 at 10:22 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
>>>> I would put it into drivers/clocksource/, I don't think drivers/mtd would be any better, but there is a chance that the clocksource maintainers don't want to have the watchdog code in their tree.
>>
>> While trying to discover how to creating two devices in one driver I ran across an interesting .dtsi and I was wondering if this would be a valid approach for my situation as well. The pertinent files are:
>> 1) drivers/clocksource/timer-digicolor.c
>> 2) arch/arm/boot/dts/cx92755.dtsi
>> 3) drivers/watchdog/digicolor_wdt.c
>>
>> Here they are just sharing the same register area:
>>
>> timer@f0000fc0 {
>>         compatible = "cnxt,cx92755-timer";
>>         reg = <0xf0000fc0 0x40>>;
>>         interrupts = <19>>, <31>>, <34>>, <35>>, <52>>, <53>>, <54>>, <55>>;
>>         clocks = <&main_clk>>;
>> };
>>
>> rtc@f0000c30 {
>>         compatible = "cnxt,cx92755-rtc";
>>         reg = <0xf0000c30 0x18>>;
>>         interrupts = <25>>;
>> };
>>
>> watchdog@f0000fc0 {
>>         compatible = "cnxt,cx92755-wdt";
>>         reg = <0xf0000fc0 0x8>>;
>>         clocks = <&main_clk>>;
>>         timeout-sec = <15>>;
>> };

> Right, it is possible to make this work, but it's not recommended, and you have to work around the sanity checks in the code that try to keep you from doing it wrong, as well as any tooling that tries to check for these in the DT.

I found an example in the kernel where the timer creates a child watchdog device and passes it the base address when creating it. I used this to model the gxp-timer and gxp-wdt. The following files were what I have referenced:
drivers/watchdog/ixp4xx_wdt.c
drivers/clocksource/timer-ixp4xx.c

This seems very similar to what you suggested previously except I do not see a private interface in there between the parent and the child device. Is it mandatory to have the private interface between the two? If it is, what would you recommend that interface be? So far without the private interface I am not seeing any issues accessing the registers.

Thanks,

-Nick


^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-05 21:21                                     ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-05 21:21 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Monday, April 4, 2022 5:02 PM
To: Hawkins, Nick <nick.hawkins@hpe.com>>
Cc: Arnd Bergmann <arnd@arndb.de>>; Verdun, Jean-Marie <verdun@hpe.com>>; Olof Johansson <olof@lixom.net>>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

On Mon, Apr 4, 2022 at 10:22 PM Hawkins, Nick <nick.hawkins@hpe.com>> wrote:
>>>> I would put it into drivers/clocksource/, I don't think drivers/mtd would be any better, but there is a chance that the clocksource maintainers don't want to have the watchdog code in their tree.
>>
>> While trying to discover how to creating two devices in one driver I ran across an interesting .dtsi and I was wondering if this would be a valid approach for my situation as well. The pertinent files are:
>> 1) drivers/clocksource/timer-digicolor.c
>> 2) arch/arm/boot/dts/cx92755.dtsi
>> 3) drivers/watchdog/digicolor_wdt.c
>>
>> Here they are just sharing the same register area:
>>
>> timer@f0000fc0 {
>>         compatible = "cnxt,cx92755-timer";
>>         reg = <0xf0000fc0 0x40>>;
>>         interrupts = <19>>, <31>>, <34>>, <35>>, <52>>, <53>>, <54>>, <55>>;
>>         clocks = <&main_clk>>;
>> };
>>
>> rtc@f0000c30 {
>>         compatible = "cnxt,cx92755-rtc";
>>         reg = <0xf0000c30 0x18>>;
>>         interrupts = <25>>;
>> };
>>
>> watchdog@f0000fc0 {
>>         compatible = "cnxt,cx92755-wdt";
>>         reg = <0xf0000fc0 0x8>>;
>>         clocks = <&main_clk>>;
>>         timeout-sec = <15>>;
>> };

> Right, it is possible to make this work, but it's not recommended, and you have to work around the sanity checks in the code that try to keep you from doing it wrong, as well as any tooling that tries to check for these in the DT.

I found an example in the kernel where the timer creates a child watchdog device and passes it the base address when creating it. I used this to model the gxp-timer and gxp-wdt. The following files were what I have referenced:
drivers/watchdog/ixp4xx_wdt.c
drivers/clocksource/timer-ixp4xx.c

This seems very similar to what you suggested previously except I do not see a private interface in there between the parent and the child device. Is it mandatory to have the private interface between the two? If it is, what would you recommend that interface be? So far without the private interface I am not seeing any issues accessing the registers.

Thanks,

-Nick

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-05 21:21                                     ` Hawkins, Nick
@ 2022-04-06  7:24                                       ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-06  7:24 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Tue, Apr 5, 2022 at 11:21 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
>
> > Right, it is possible to make this work, but it's not recommended, and you have to work around the sanity checks in the code that try to keep you from doing it wrong, as well as any tooling that tries to check for these in the DT.
>
> I found an example in the kernel where the timer creates a child watchdog device and passes it the base address when creating it. I used this to model the gxp-timer and gxp-wdt. The following files were what I have referenced:
> drivers/watchdog/ixp4xx_wdt.c
> drivers/clocksource/timer-ixp4xx.c

Yes, I think that is a good example.

> This seems very similar to what you suggested previously except I do not see a private interface in there between the parent and the child device. Is it mandatory to have the private interface between the two? If it is, what would you recommend that interface be? So far without the private interface I am not seeing any issues accessing the registers.

I would count passing a register address to the child device as a
private interface.
It's a minimalistic one, but that is not a bad thing here.

         Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-06  7:24                                       ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-06  7:24 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Tue, Apr 5, 2022 at 11:21 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
>
> > Right, it is possible to make this work, but it's not recommended, and you have to work around the sanity checks in the code that try to keep you from doing it wrong, as well as any tooling that tries to check for these in the DT.
>
> I found an example in the kernel where the timer creates a child watchdog device and passes it the base address when creating it. I used this to model the gxp-timer and gxp-wdt. The following files were what I have referenced:
> drivers/watchdog/ixp4xx_wdt.c
> drivers/clocksource/timer-ixp4xx.c

Yes, I think that is a good example.

> This seems very similar to what you suggested previously except I do not see a private interface in there between the parent and the child device. Is it mandatory to have the private interface between the two? If it is, what would you recommend that interface be? So far without the private interface I am not seeing any issues accessing the registers.

I would count passing a register address to the child device as a
private interface.
It's a minimalistic one, but that is not a bad thing here.

         Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer
  2022-03-10 19:52 ` [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer nick.hawkins
@ 2022-04-06 11:13   ` Daniel Lezcano
  2022-04-06 22:02     ` Hawkins, Nick
  0 siblings, 1 reply; 80+ messages in thread
From: Daniel Lezcano @ 2022-04-06 11:13 UTC (permalink / raw)
  To: nick.hawkins, verdun; +Cc: Thomas Gleixner, linux-kernel

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
> 
> Add support for the HPE GXP SOC timer. The GXP supports several
> different kinds of timers but for the purpose of this driver there
> is only support for the General Timer. The timer has a 1us
> resolution and is 32 bits.
> 
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
>   drivers/clocksource/Kconfig     |   8 ++
>   drivers/clocksource/Makefile    |   1 +
>   drivers/clocksource/gxp-timer.c | 159 ++++++++++++++++++++++++++++++++
>   3 files changed, 168 insertions(+)
>   create mode 100644 drivers/clocksource/gxp-timer.c

Please for the sake of consistency, rename the timer to timer-qxp.c


> diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> index cfb8ea0df3b1..5916dade7608 100644
> --- a/drivers/clocksource/Kconfig
> +++ b/drivers/clocksource/Kconfig
> @@ -617,6 +617,14 @@ config CLKSRC_ST_LPC
>   	  Enable this option to use the Low Power controller timer
>   	  as clocksource.
>   
> +config GXP_TIMER
> +	bool "GXP timer driver"
> +	depends on ARCH_HPE
> +	default y
> +	help
> +	  Provides a driver for the timer control found on HPE
> +	  GXP SOCs. This is required for all GXP SOCs.

Regarding the silent option:

  https://www.spinics.net/lists/arm-kernel/msg936976.html

>   config ATCPIT100_TIMER
>   	bool "ATCPIT100 timer driver"
>   	depends on NDS32 || COMPILE_TEST
> diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> index fa5f624eadb6..dbfb8c56a8a0 100644
> --- a/drivers/clocksource/Makefile
> +++ b/drivers/clocksource/Makefile
> @@ -89,3 +89,4 @@ obj-$(CONFIG_GX6605S_TIMER)		+= timer-gx6605s.o
>   obj-$(CONFIG_HYPERV_TIMER)		+= hyperv_timer.o
>   obj-$(CONFIG_MICROCHIP_PIT64B)		+= timer-microchip-pit64b.o
>   obj-$(CONFIG_MSC313E_TIMER)		+= timer-msc313e.o
> +obj-$(CONFIG_GXP_TIMER)			+= gxp-timer.o
> diff --git a/drivers/clocksource/gxp-timer.c b/drivers/clocksource/gxp-timer.c
> new file mode 100644
> index 000000000000..a24cd1cc5c04
> --- /dev/null
> +++ b/drivers/clocksource/gxp-timer.c
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, L.P.*/
> +
> +#include <linux/bitops.h>
> +#include <linux/clockchips.h>
> +#include <linux/clocksource.h>
> +#include <linux/interrupt.h>
> +#include <linux/irqreturn.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
This header is not needed.

> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_platform.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/sched_clock.h>
> +
> +#include <asm/irq.h>

This header is not needed AFAICT.

Please double check the headers above are all needed.

> +#define TIMER0_FREQ	1000000
> +
> +/*TCS Stands for Timer Control/Status: these are masks to be used in*/
> +/* the Timer Count Registers */
> +#define MASK_TCS_ENABLE	0x01
> +#define MASK_TCS_PERIOD	0x02
> +#define MASK_TCS_RELOAD	0x04
> +#define MASK_TCS_TC	0x80
> +
> +struct gxp_timer {
> +	void __iomem *counter;
> +	void __iomem *control;
> +	struct clock_event_device evt;
> +};
> +
> +static void __iomem *system_clock __read_mostly;
> +
> +static inline struct gxp_timer *to_gxp_timer(struct clock_event_device *evt_dev)
> +{
> +	return container_of(evt_dev, struct gxp_timer, evt);
> +}
> +
> +static u64 notrace gxp_sched_read(void)
> +{
> +	return readl_relaxed(system_clock);
> +}
> +
> +static int gxp_time_set_next_event(unsigned long event,
> +								struct clock_event_device *evt_dev)
> +{
> +	struct gxp_timer *timer = to_gxp_timer(evt_dev);

nit: add a line to separate the declaration and the code below.

> +	/* Stop counting and disable interrupt before updating */
> +	writeb_relaxed(MASK_TCS_TC, timer->control);
> +	writel_relaxed(event, timer->counter);
> +	writeb_relaxed(MASK_TCS_TC | MASK_TCS_ENABLE, timer->control);
> +
> +	return 0;
> +}
> +
> +static irqreturn_t gxp_time_interrupt(int irq, void *dev_id)

	s/gxp_time/gxp_timer/

> +{
> +	struct gxp_timer *timer = dev_id;
> +	void (*event_handler)(struct clock_event_device *timer);
> +
> +	if (!(readb_relaxed(timer->control) & MASK_TCS_TC))
> +		return IRQ_NONE;
> +
> +	writeb_relaxed(MASK_TCS_TC, timer->control);
> +
> +	event_handler = READ_ONCE(timer->evt.event_handler);
> +	event_handler(&timer->evt);

Why READ_ONCE ?

Do timer->evt.event_handler();

Or alternatively pass the request_irq() &timer->evt and use to_gxp_timer()

> +	return IRQ_HANDLED;
> +}
> +
> +static int __init gxp_timer_init(struct device_node *node)
> +{
> +	void __iomem *base_counter;
> +	void __iomem *base_control;
> +	u32 freq;
> +	int ret, irq;
> +	struct gxp_timer *gxp_timer;
> +
> +	base_counter = of_iomap(node, 0);
> +	if (!base_counter) {
> +		pr_err("Can't remap counter registers");
> +		ret = -ENXIO;
> +		return ret;

		return -ENXIO;

> +	}
> +
> +	base_control = of_iomap(node, 1);
> +	if (!base_control) {
> +		pr_err("Can't remap control registers");
> +		ret = -ENXIO;
> +		goto err_iounmap;



> +	}
> +
> +	system_clock = of_iomap(node, 2);
> +	if (!system_clock) {
> +		pr_err("Can't remap control registers");
> +		ret = -ENXIO;
> +		goto err_iounmap;
> +	}
> +
> +	if (of_property_read_u32(node, "clock-frequency", &freq)) {
> +		pr_err("Can't read clock-frequency\n");
> +		ret = -EIO;
> +		goto err_iounmap;
> +	}
> +
> +	sched_clock_register(gxp_sched_read, 32, freq);
> +	clocksource_mmio_init(system_clock, node->name, freq,
> +				300, 32, clocksource_mmio_readl_up);
> +
> +	irq = irq_of_parse_and_map(node, 0);
> +	if (irq <= 0) {
> +		ret = -EINVAL;
> +		pr_err("GXP Timer Can't parse IRQ %d", irq);
> +		goto err_iounmap;
> +	}
> +
> +	gxp_timer = kzalloc(sizeof(*gxp_timer), GFP_KERNEL);
> +	if (!gxp_timer) {
> +		ret = -ENOMEM;
> +		goto err_iounmap;
> +	}
> +
> +	gxp_timer->counter = base_counter;
> +	gxp_timer->control = base_control;
> +	gxp_timer->evt.name = node->name; > +	gxp_timer->evt.rating = 300;
> +	gxp_timer->evt.features = CLOCK_EVT_FEAT_ONESHOT;
> +	gxp_timer->evt.set_next_event = gxp_time_set_next_event;
> +	gxp_timer->evt.cpumask = cpumask_of(0);
> +

	ret = request_irq();

> +	if (request_irq(irq, gxp_time_interrupt, IRQF_TIMER | IRQF_SHARED,
> +			node->name, gxp_timer)) {
> +		ret = -EIO;

		Remove above ret = -EIO;

> +		pr_err("%s: request_irq() failed\n", "GXP Timer Tick");
> +		goto err_timer_free;
> +	}
> +
> +	clockevents_config_and_register(&gxp_timer->evt, TIMER0_FREQ,
> +					0xf, 0xffffffff);
> +
> +	pr_info("gxp: system timer (irq = %d)\n", irq);

	s/pr_info/pr_debug/

> +	return 0;
> +
> +
> +err_timer_free:
> +	kfree(gxp_timer);
> +
> +err_iounmap:
> +	iounmap(system_clock);
> +	iounmap(base_control);
> +	iounmap(base_counter);
> +	return ret;
> +}
> +
> +TIMER_OF_DECLARE(gxp, "hpe,gxp-timer", gxp_timer_init);


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer
  2022-04-06 11:13   ` Daniel Lezcano
@ 2022-04-06 22:02     ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-06 22:02 UTC (permalink / raw)
  To: Daniel Lezcano, Verdun, Jean-Marie; +Cc: Thomas Gleixner, linux-kernel



-----Original Message-----
From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org] 
Sent: Wednesday, April 6, 2022 6:13 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>; Verdun, Jean-Marie <verdun@hpe.com>
Cc: Thomas Gleixner <tglx@linutronix.de>; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer

On 10/03/2022 20:52, nick.hawkins@hpe.com wrote:
> > From: Nick Hawkins <nick.hawkins@hpe.com> >
> > 
> > Add support for the HPE GXP SOC timer. The GXP supports several 
> > different kinds of timers but for the purpose of this driver there is 
> > only support for the General Timer. The timer has a 1us resolution and 
> > is 32 bits.
> > 
> > Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com> >
> > ---
> >   drivers/clocksource/Kconfig     |   8 ++
> >   drivers/clocksource/Makefile    |   1 +
> >   drivers/clocksource/gxp-timer.c | 159 ++++++++++++++++++++++++++++++++
> >   3 files changed, 168 insertions(+)
> >   create mode 100644 drivers/clocksource/gxp-timer.c

> Please for the sake of consistency, rename the timer to timer-qxp.c

Fixed.


> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig 
> > index cfb8ea0df3b1..5916dade7608 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -617,6 +617,14 @@ config CLKSRC_ST_LPC
> >   	  Enable this option to use the Low Power controller timer
> >   	  as clocksource.
> >   
> > +config GXP_TIMER
> > +	bool "GXP timer driver"
> > +	depends on ARCH_HPE
> > +	default y
> > +	help
> > +	  Provides a driver for the timer control found on HPE
> > +	  GXP SOCs. This is required for all GXP SOCs.

> Regarding the silent option:

 >  https://www.spinics.net/lists/arm-kernel/msg936976.html 

What I have understood from that is we need  ---> bool "GXP timer driver" if COMPILE_TEST

This is the modification I have made.

One a side note: The next submission will have several implementation differences due to requirements from the dtsi review.
1) The timer will get its frequency from the ppuclk
2) The timer will spawn a watchdog timer child and pass the base register to it. See: https://lore.kernel.org/all/CAK8P3a3jr-FkyxLff2cK4=X-4AShnKkeYMRKsvUg=2W0bTviiQ@mail.gmail.com/

> >   config ATCPIT100_TIMER
> >   	bool "ATCPIT100 timer driver"
> >   	depends on NDS32 || COMPILE_TEST
> > diff --git a/drivers/clocksource/Makefile 
> > b/drivers/clocksource/Makefile index fa5f624eadb6..dbfb8c56a8a0 100644
> > --- a/drivers/clocksource/Makefile
> > +++ b/drivers/clocksource/Makefile
> > @@ -89,3 +89,4 @@ obj-$(CONFIG_GX6605S_TIMER)		+= timer-gx6605s.o
> >   obj-$(CONFIG_HYPERV_TIMER)		+= hyperv_timer.o
> >   obj-$(CONFIG_MICROCHIP_PIT64B)		+= timer-microchip-pit64b.o
> >   obj-$(CONFIG_MSC313E_TIMER)		+= timer-msc313e.o
> > +obj-$(CONFIG_GXP_TIMER)			+= gxp-timer.o
> > diff --git a/drivers/clocksource/gxp-timer.c 
> > b/drivers/clocksource/gxp-timer.c new file mode 100644 index 
> > 000000000000..a24cd1cc5c04
> > --- /dev/null
> > +++ b/drivers/clocksource/gxp-timer.c
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/* Copyright (C) 2022 Hewlett-Packard Enterprise Development Company, 
> > +L.P.*/
> > +
> > +#include <linux/bitops.h> >
> > +#include <linux/clockchips.h> >
> > +#include <linux/clocksource.h> >
> > +#include <linux/interrupt.h> >
> > +#include <linux/irqreturn.h> >
> > +#include <linux/kernel.h> >
> > +#include <linux/module.h> >
> This header is not needed.

> > +#include <linux/of_address.h> >
> > +#include <linux/of_irq.h> >
> > +#include <linux/of_platform.h> >
> > +#include <linux/slab.h> >
> > +#include <linux/string.h> >
> > +#include <linux/sched_clock.h> >
> > +
> > +#include <asm/irq.h> >

> This header is not needed AFAICT.

> Please double check the headers above are all needed.

Done ended up removing irq, string, slab, bitops, irqreturn

> > +#define TIMER0_FREQ	1000000
> > +
> > +/*TCS Stands for Timer Control/Status: these are masks to be used 
> > +in*/
> > +/* the Timer Count Registers */
> > +#define MASK_TCS_ENABLE	0x01
> > +#define MASK_TCS_PERIOD	0x02
> > +#define MASK_TCS_RELOAD	0x04
> > +#define MASK_TCS_TC	0x80
> > +
> > +struct gxp_timer {
> > +	void __iomem *counter;
> > +	void __iomem *control;
> > +	struct clock_event_device evt;
> > +};
> > +
> > +static void __iomem *system_clock __read_mostly;
> > +
> > +static inline struct gxp_timer *to_gxp_timer(struct 
> > +clock_event_device *evt_dev) {
> > +	return container_of(evt_dev, struct gxp_timer, evt); }
> > +
> > +static u64 notrace gxp_sched_read(void) {
> > +	return readl_relaxed(system_clock);
> > +}
> > +
> > +static int gxp_time_set_next_event(unsigned long event,
> > +								struct clock_event_device *evt_dev) {
> > +	struct gxp_timer *timer = to_gxp_timer(evt_dev);

> nit: add a line to separate the declaration and the code below.

Done

> > +	/* Stop counting and disable interrupt before updating */
> > +	writeb_relaxed(MASK_TCS_TC, timer-> >control);
> > +	writel_relaxed(event, timer-> >counter);
> > +	writeb_relaxed(MASK_TCS_TC | MASK_TCS_ENABLE, timer-> >control);
> > +
> > +	return 0;
> > +}
> > +
> > +static irqreturn_t gxp_time_interrupt(int irq, void *dev_id)

>	s/gxp_time/gxp_timer/

Done

> > +{
> > +	struct gxp_timer *timer = dev_id;
> > +	void (*event_handler)(struct clock_event_device *timer);
> > +
> > +	if (!(readb_relaxed(timer-> >control) & MASK_TCS_TC))
> > +		return IRQ_NONE;
> > +
> > +	writeb_relaxed(MASK_TCS_TC, timer-> >control);
> > +
> > +	event_handler = READ_ONCE(timer-> >evt.event_handler);
> > +	event_handler(&timer-> >evt);

> Why READ_ONCE ?

> Do timer-> >evt.event_handler();
> Or alternatively pass the request_irq() &timer-> >evt and use to_gxp_timer()
Fixed
> > +	return IRQ_HANDLED;
> > +}
> > +
> > +static int __init gxp_timer_init(struct device_node *node) {
> > +	void __iomem *base_counter;
> > +	void __iomem *base_control;
> > +	u32 freq;
> > +	int ret, irq;
> > +	struct gxp_timer *gxp_timer;
> > +
> > +	base_counter = of_iomap(node, 0);
> > +	if (!base_counter) {
> > +		pr_err("Can't remap counter registers");
> > +		ret = -ENXIO;
> > +		return ret;

>		return -ENXIO;

Done

> > +	}
> > +
> > +	base_control = of_iomap(node, 1);
> > +	if (!base_control) {
> > +		pr_err("Can't remap control registers");
> > +		ret = -ENXIO;
> > +		goto err_iounmap;



> > +	}
> > +
> > +	system_clock = of_iomap(node, 2);
> > +	if (!system_clock) {
> > +		pr_err("Can't remap control registers");
> > +		ret = -ENXIO;
> > +		goto err_iounmap;
> > +	}
> > +
> > +	if (of_property_read_u32(node, "clock-frequency", &freq)) {
> > +		pr_err("Can't read clock-frequency\n");
> > +		ret = -EIO;
> > +		goto err_iounmap;
> > +	}
> > +
> > +	sched_clock_register(gxp_sched_read, 32, freq);
> > +	clocksource_mmio_init(system_clock, node-> >name, freq,
> > +				300, 32, clocksource_mmio_readl_up);
> > +
> > +	irq = irq_of_parse_and_map(node, 0);
> > +	if (irq <= 0) {
> > +		ret = -EINVAL;
> > +		pr_err("GXP Timer Can't parse IRQ %d", irq);
> > +		goto err_iounmap;
> > +	}
> > +
> > +	gxp_timer = kzalloc(sizeof(*gxp_timer), GFP_KERNEL);
> > +	if (!gxp_timer) {
> > +		ret = -ENOMEM;
> > +		goto err_iounmap;
> > +	}
> > +
> > +	gxp_timer-> >counter = base_counter;
> > +	gxp_timer-> >control = base_control;
> > +	gxp_timer-> >evt.name = node-> >name; > > +	gxp_timer-> >evt.rating = 300;
> > +	gxp_timer-> >evt.features = CLOCK_EVT_FEAT_ONESHOT;
> > +	gxp_timer-> >evt.set_next_event = gxp_time_set_next_event;
> > +	gxp_timer-> >evt.cpumask = cpumask_of(0);
> > +

>	ret = request_irq();

Done

> > +	if (request_irq(irq, gxp_time_interrupt, IRQF_TIMER | IRQF_SHARED,
> > +			node-> >name, gxp_timer)) {
> > +		ret = -EIO;

>		Remove above ret = -EIO;

Done

> > +		pr_err("%s: request_irq() failed\n", "GXP Timer Tick");
> > +		goto err_timer_free;
> > +	}
> > +
> > +	clockevents_config_and_register(&gxp_timer-> >evt, TIMER0_FREQ,
> > +					0xf, 0xffffffff);
> > +
> > +	pr_info("gxp: system timer (irq = %d)\n", irq);

>	s/pr_info/pr_debug/

Done

> > +	return 0;
> > +
> > +
> > +err_timer_free:
> > +	kfree(gxp_timer);
> > +
> > +err_iounmap:
> > +	iounmap(system_clock);
> > +	iounmap(base_control);
> > +	iounmap(base_counter);
> > +	return ret;
> > +}
> > +
> > +TIMER_OF_DECLARE(gxp, "hpe,gxp-timer", gxp_timer_init);


Thanks,

-Nick Hawkins

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-06  7:24                                       ` Arnd Bergmann
@ 2022-04-13 16:48                                         ` Hawkins, Nick
  -1 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-13 16:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Wednesday, April 6, 2022 2:25 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

> I would count passing a register address to the child device as a private interface.
> It's a minimalistic one, but that is not a bad thing here.

Thank you. Now that the parent/child issue with timer/watchdog is resolved I am now having an issue trying to access "iopclk" from "gxp-timer". I have tried use of of_clk_get_by_name and of_clk_get which both fail to find the clock.
Is it because clocks is outside of the axi -> ahb hierarchy?

        clocks {
                pll: pll {
                        compatible = "fixed-clock";
                        #clock-cells = <0>;
                        clock-frequency = <1600000000>;
                };

                iopclk: iopclk {
                        compatible = "fixed-factor-clock";
                        #clock-cells = <0>;
                        clock-div = <4>;
                        clock-mult = <4>;
                        clocks = <&pll>;
                };
        };

        axi {
                compatible = "simple-bus";
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;
                dma-ranges;

                ahb@c0000000 {
                        compatible = "simple-bus";
                        #address-cells = <1>;
                        #size-cells = <1>;
                        ranges = <0x0 0xc0000000 0x30000000>;

                        ...

                        st: timer@80 {
                                compatible = "hpe,gxp-timer","simple-mfd";
                                reg = <0x80 0x16>;
                                interrupts = <0>;
                                interrupt-parent = <&vic0>;
                                clocks = <&iopclk>;
                                clock-names = "iopclk";

                                watchdog {
                                        compatible = "hpe,gxp-wdt";
                                };
                        };
                };
        };

Thanks,

-Nick Hawkins

^ permalink raw reply	[flat|nested] 80+ messages in thread

* RE: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-13 16:48                                         ` Hawkins, Nick
  0 siblings, 0 replies; 80+ messages in thread
From: Hawkins, Nick @ 2022-04-13 16:48 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Verdun, Jean-Marie, Olof Johansson, soc, Rob Herring,
	linux-arm-kernel, devicetree, linux-kernel



-----Original Message-----
From: Arnd Bergmann [mailto:arnd@arndb.de] 
Sent: Wednesday, April 6, 2022 2:25 AM
To: Hawkins, Nick <nick.hawkins@hpe.com>
Cc: Arnd Bergmann <arnd@arndb.de>; Verdun, Jean-Marie <verdun@hpe.com>; Olof Johansson <olof@lixom.net>; soc@kernel.org; Rob Herring <robh+dt@kernel.org>; linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree

> I would count passing a register address to the child device as a private interface.
> It's a minimalistic one, but that is not a bad thing here.

Thank you. Now that the parent/child issue with timer/watchdog is resolved I am now having an issue trying to access "iopclk" from "gxp-timer". I have tried use of of_clk_get_by_name and of_clk_get which both fail to find the clock.
Is it because clocks is outside of the axi -> ahb hierarchy?

        clocks {
                pll: pll {
                        compatible = "fixed-clock";
                        #clock-cells = <0>;
                        clock-frequency = <1600000000>;
                };

                iopclk: iopclk {
                        compatible = "fixed-factor-clock";
                        #clock-cells = <0>;
                        clock-div = <4>;
                        clock-mult = <4>;
                        clocks = <&pll>;
                };
        };

        axi {
                compatible = "simple-bus";
                #address-cells = <1>;
                #size-cells = <1>;
                ranges;
                dma-ranges;

                ahb@c0000000 {
                        compatible = "simple-bus";
                        #address-cells = <1>;
                        #size-cells = <1>;
                        ranges = <0x0 0xc0000000 0x30000000>;

                        ...

                        st: timer@80 {
                                compatible = "hpe,gxp-timer","simple-mfd";
                                reg = <0x80 0x16>;
                                interrupts = <0>;
                                interrupt-parent = <&vic0>;
                                clocks = <&iopclk>;
                                clock-names = "iopclk";

                                watchdog {
                                        compatible = "hpe,gxp-wdt";
                                };
                        };
                };
        };

Thanks,

-Nick Hawkins
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
  2022-04-13 16:48                                         ` Hawkins, Nick
@ 2022-04-13 17:42                                           ` Arnd Bergmann
  -1 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-13 17:42 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Wed, Apr 13, 2022 at 6:48 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > I would count passing a register address to the child device as a private interface.
> > It's a minimalistic one, but that is not a bad thing here.
>
> Thank you. Now that the parent/child issue with timer/watchdog is resolved I am now
> having an issue trying to access "iopclk" from "gxp-timer". I have tried use of
>  of_clk_get_by_name and of_clk_get which both fail to find the clock.
> Is it because clocks is outside of the axi -> ahb hierarchy?

No, that should work, but you have to pass the right device node, which would
correspond to the parent device. You should also be able to pass the parent
device pointer (i.e. linux device, not device_node) and use clk_get().

        Arnd

^ permalink raw reply	[flat|nested] 80+ messages in thread

* Re: [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree
@ 2022-04-13 17:42                                           ` Arnd Bergmann
  0 siblings, 0 replies; 80+ messages in thread
From: Arnd Bergmann @ 2022-04-13 17:42 UTC (permalink / raw)
  To: Hawkins, Nick
  Cc: Arnd Bergmann, Verdun, Jean-Marie, Olof Johansson, soc,
	Rob Herring, linux-arm-kernel, devicetree, linux-kernel

On Wed, Apr 13, 2022 at 6:48 PM Hawkins, Nick <nick.hawkins@hpe.com> wrote:
> > I would count passing a register address to the child device as a private interface.
> > It's a minimalistic one, but that is not a bad thing here.
>
> Thank you. Now that the parent/child issue with timer/watchdog is resolved I am now
> having an issue trying to access "iopclk" from "gxp-timer". I have tried use of
>  of_clk_get_by_name and of_clk_get which both fail to find the clock.
> Is it because clocks is outside of the axi -> ahb hierarchy?

No, that should work, but you have to pass the right device node, which would
correspond to the parent device. You should also be able to pass the parent
device pointer (i.e. linux device, not device_node) and use clk_get().

        Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 80+ messages in thread

end of thread, other threads:[~2022-04-13 17:44 UTC | newest]

Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-10 19:52 [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture nick.hawkins
2022-03-10 19:52 ` nick.hawkins
2022-03-10 19:52 ` [PATCH v3 02/10] arch: arm: configs: multi_v7_defconfig nick.hawkins
2022-03-10 19:52   ` nick.hawkins
2022-03-10 19:52 ` [PATCH v3 03/10] drivers: wdt: Introduce HPE GXP SoC Watchdog nick.hawkins
2022-04-04 14:28   ` Guenter Roeck
2022-04-04 16:25     ` Hawkins, Nick
2022-04-04 16:41       ` Guenter Roeck
2022-03-10 19:52 ` [PATCH v3 04/10] clocksource/drivers: Add HPE GXP timer nick.hawkins
2022-04-06 11:13   ` Daniel Lezcano
2022-04-06 22:02     ` Hawkins, Nick
2022-03-10 19:52 ` [PATCH v3 05/10] dt-bindings: timer: Add HPE GXP Timer Binding nick.hawkins
2022-03-11  9:32   ` Krzysztof Kozlowski
2022-03-11 15:40   ` Rob Herring
2022-03-11 16:22     ` Hawkins, Nick
2022-03-11 17:13       ` Krzysztof Kozlowski
2022-03-10 19:52 ` [PATCH v3 06/10] dt-bindings: watchdog: Add HPE GXP Watchdog timer binding nick.hawkins
2022-03-11  9:34   ` Krzysztof Kozlowski
2022-03-10 19:52 ` [PATCH v3 07/10] dt-bindings: arm: Add HPE GXP Binding nick.hawkins
2022-03-11 10:20   ` Krzysztof Kozlowski
2022-03-10 19:52 ` [PATCH v3 08/10] dt-bindings: arm: Add HPE GXP CPU Init nick.hawkins
2022-03-11 10:22   ` Krzysztof Kozlowski
2022-03-16 21:33     ` Hawkins, Nick
2022-03-10 19:52 ` [PATCH v3 09/10] arch: arm: boot: dts: Introduce HPE GXP Device tree nick.hawkins
2022-03-10 19:52   ` nick.hawkins
2022-03-11  8:17   ` Arnd Bergmann
2022-03-11  8:17     ` Arnd Bergmann
2022-03-11 10:29   ` Krzysztof Kozlowski
2022-03-11 10:29     ` Krzysztof Kozlowski
2022-03-16 15:41     ` Hawkins, Nick
2022-03-16 15:41       ` Hawkins, Nick
2022-03-16 15:50       ` Krzysztof Kozlowski
2022-03-16 15:50         ` Krzysztof Kozlowski
2022-03-16 20:10         ` Hawkins, Nick
2022-03-16 20:10           ` Hawkins, Nick
2022-03-17  8:36           ` Krzysztof Kozlowski
2022-03-17  8:36             ` Krzysztof Kozlowski
2022-03-29 19:38             ` Hawkins, Nick
2022-03-29 19:38               ` Hawkins, Nick
2022-03-29 21:13               ` Arnd Bergmann
2022-03-29 21:13                 ` Arnd Bergmann
2022-03-29 21:45                 ` Hawkins, Nick
2022-03-29 21:45                   ` Hawkins, Nick
2022-03-30 22:27                   ` Hawkins, Nick
2022-03-30 22:27                     ` Hawkins, Nick
2022-03-31  9:30                     ` Arnd Bergmann
2022-03-31  9:30                       ` Arnd Bergmann
2022-03-31 21:09                       ` Hawkins, Nick
2022-03-31 21:09                         ` Hawkins, Nick
2022-03-31 21:52                         ` Arnd Bergmann
2022-03-31 21:52                           ` Arnd Bergmann
2022-04-01 16:05                           ` Hawkins, Nick
2022-04-01 16:05                             ` Hawkins, Nick
2022-04-01 16:30                             ` Arnd Bergmann
2022-04-01 16:30                               ` Arnd Bergmann
2022-04-04 20:22                               ` Hawkins, Nick
2022-04-04 20:22                                 ` Hawkins, Nick
2022-04-04 22:02                                 ` Arnd Bergmann
2022-04-04 22:02                                   ` Arnd Bergmann
2022-04-05 21:21                                   ` Hawkins, Nick
2022-04-05 21:21                                     ` Hawkins, Nick
2022-04-06  7:24                                     ` Arnd Bergmann
2022-04-06  7:24                                       ` Arnd Bergmann
2022-04-13 16:48                                       ` Hawkins, Nick
2022-04-13 16:48                                         ` Hawkins, Nick
2022-04-13 17:42                                         ` Arnd Bergmann
2022-04-13 17:42                                           ` Arnd Bergmann
2022-03-10 19:52 ` [PATCH v3 10/10] maintainers: Introduce HPE GXP Architecture nick.hawkins
2022-03-11 10:33   ` Joe Perches
2022-03-11  7:21 ` [PATCH v3 01/10] arch: arm: mach-hpe: Introduce the HPE GXP architecture kernel test robot
2022-03-11  7:21   ` kernel test robot
2022-03-11  8:06 ` Arnd Bergmann
2022-03-11  8:06   ` Arnd Bergmann
2022-03-11 12:40 ` kernel test robot
2022-03-11 12:40   ` kernel test robot
2022-03-12 13:27 ` kernel test robot
2022-03-12 13:27   ` kernel test robot
2022-03-12 15:14   ` Arnd Bergmann
2022-03-12 15:14     ` Arnd Bergmann
2022-03-12 15:14     ` Arnd Bergmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.