From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them.
(3)Simplify ACPI code for arm_arch_timer
(4)Add GTDT support for ARM memory-mapped timer
Changelog: v6: split the GTDT driver to 4 parts: basic, arch_timer, memory-mapped timer, and SBSA Generic Watchdog timer Improve driver by suggestions and example code from Daniel Lezcano
v5: https://lkml.org/lkml/2016/5/24/356 Sorting out all patches, simplify the API of GTDT driver: GTDT driver just fills the data struct for arm_arch_timer driver.
v4: https://lists.linaro.org/pipermail/linaro-acpi/2016-March/006667.html Delete the kvm relevant patches Separate two patches for sorting out the code for arm_arch_timer. Improve irq info export code to allow missing irq info in GTDT table.
v3: https://lkml.org/lkml/2016/2/1/658 Improve GTDT driver code: (1)improve pr_* by defining pr_fmt(fmt) (2)simplify gtdt_sbsa_gwdt_init (3)improve gtdt_arch_timer_data_init, if table is NULL, it will try to get GTDT table. Move enum ppi_nr to arm_arch_timer.h, and add enum spi_nr. Add arm_arch_timer get ppi from DT and GTDT support for kvm.
v2: https://lkml.org/lkml/2015/12/2/10 Rebase to latest kernel version(4.4-rc3). Fix the bug about the config problem, use CONFIG_ACPI_GTDT instead of CONFIG_ACPI in arm_arch_timer.c
v1: The first upstreaming version: https://lkml.org/lkml/2015/10/28/553
Fu Wei (10): clocksource/drivers/arm_arch_timer: Move enums and defines to header file clocksource/drivers/arm_arch_timer: Add a new enum for spi type clocksource/drivers/arm_arch_timer: Improve printk relevant code acpi: Add some basic struct and functions in GTDT driver acpi: Add arch_timer support in GTDT table parse driver acpi: Add GTDT driver to kernel build system clocksource/drivers/arm_arch_timer: Simplify ACPI support code. acpi: Add memory-mapped timer support in GTDT driver clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer acpi: Add SBSA Generic Watchdog support in GTDT driver
drivers/acpi/Kconfig | 9 + drivers/acpi/Makefile | 1 + drivers/acpi/acpi_gtdt.c | 326 +++++++++++++++++++++++++++++++++++ drivers/clocksource/Kconfig | 1 + drivers/clocksource/arm_arch_timer.c | 227 +++++++++++++++++------- drivers/watchdog/Kconfig | 1 + include/clocksource/arm_arch_timer.h | 32 ++++ include/linux/acpi.h | 7 + 8 files changed, 538 insertions(+), 66 deletions(-) create mode 100644 drivers/acpi/acpi_gtdt.c
From: Fu Wei fu.wei@linaro.org
To support the arm_arch_timer via ACPI we need to share defines and enums between the driver and the ACPI parser code.
Split out the relevant defines and enums into arm_arch_timer.h. No functional change.
Signed-off-by: Fu Wei fu.wei@linaro.org --- drivers/clocksource/arm_arch_timer.c | 11 ----------- include/clocksource/arm_arch_timer.h | 11 +++++++++++ 2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 4814446..5d7272e 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -48,8 +48,6 @@ #define CNTV_TVAL 0x38 #define CNTV_CTL 0x3c
-#define ARCH_CP15_TIMER BIT(0) -#define ARCH_MEM_TIMER BIT(1) static unsigned arch_timers_present __initdata;
static void __iomem *arch_counter_base; @@ -62,15 +60,6 @@ struct arch_timer { #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
static u32 arch_timer_rate; - -enum ppi_nr { - PHYS_SECURE_PPI, - PHYS_NONSECURE_PPI, - VIRT_PPI, - HYP_PPI, - MAX_TIMER_PPI -}; - static int arch_timer_ppi[MAX_TIMER_PPI];
static struct clock_event_device __percpu *arch_timer_evt; diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h index caedb74..6f06481 100644 --- a/include/clocksource/arm_arch_timer.h +++ b/include/clocksource/arm_arch_timer.h @@ -19,6 +19,9 @@ #include <linux/timecounter.h> #include <linux/types.h>
+#define ARCH_CP15_TIMER BIT(0) +#define ARCH_MEM_TIMER BIT(1) + #define ARCH_TIMER_CTRL_ENABLE (1 << 0) #define ARCH_TIMER_CTRL_IT_MASK (1 << 1) #define ARCH_TIMER_CTRL_IT_STAT (1 << 2) @@ -34,6 +37,14 @@ enum arch_timer_reg { ARCH_TIMER_REG_TVAL, };
+enum ppi_nr { + PHYS_SECURE_PPI, + PHYS_NONSECURE_PPI, + VIRT_PPI, + HYP_PPI, + MAX_TIMER_PPI +}; + #define ARCH_TIMER_PHYS_ACCESS 0 #define ARCH_TIMER_VIRT_ACCESS 1 #define ARCH_TIMER_MEM_PHYS_ACCESS 2
From: Fu Wei fu.wei@linaro.org
This patch add a new enum "spi_nr" and use it in the driver. Just for code's readability, no functional change.
Signed-off-by: Fu Wei fu.wei@linaro.org --- drivers/clocksource/arm_arch_timer.c | 4 ++-- include/clocksource/arm_arch_timer.h | 6 ++++++ 2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 5d7272e..966c574 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -826,9 +826,9 @@ static void __init arch_timer_mem_init(struct device_node *np) }
if (arch_timer_mem_use_virtual) - irq = irq_of_parse_and_map(best_frame, 1); + irq = irq_of_parse_and_map(best_frame, VIRT_SPI); else - irq = irq_of_parse_and_map(best_frame, 0); + irq = irq_of_parse_and_map(best_frame, PHYS_SPI);
if (!irq) { pr_err("arch_timer: Frame missing %s irq", diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h index 6f06481..16dcd10 100644 --- a/include/clocksource/arm_arch_timer.h +++ b/include/clocksource/arm_arch_timer.h @@ -45,6 +45,12 @@ enum ppi_nr { MAX_TIMER_PPI };
+enum spi_nr { + PHYS_SPI, + VIRT_SPI, + MAX_TIMER_SPI +}; + #define ARCH_TIMER_PHYS_ACCESS 0 #define ARCH_TIMER_VIRT_ACCESS 1 #define ARCH_TIMER_MEM_PHYS_ACCESS 2
From: Fu Wei fu.wei@linaro.org
This patch defines pr_fmt(fmt) for all pr_* functions, then the pr_* don't need to add "arch_timer:" everytime.
Also delete some Blank Spaces in arch_timer_banner, according to the suggestion from checkpatch.pl.
No functional change.
Signed-off-by: Fu Wei fu.wei@linaro.org --- drivers/clocksource/arm_arch_timer.c | 52 +++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 966c574..9540e9d 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -29,6 +29,9 @@
#include <clocksource/arm_arch_timer.h>
+#undef pr_fmt +#define pr_fmt(fmt) "arch_timer: " fmt + #define CNTTIDR 0x08 #define CNTTIDR_VIRT(n) (BIT(1) << ((n) * 4))
@@ -388,24 +391,24 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
/* Check the timer frequency. */ if (arch_timer_rate == 0) - pr_warn("Architected timer frequency not available\n"); + pr_warn("frequency not available\n"); }
static void arch_timer_banner(unsigned type) { - pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n", - type & ARCH_CP15_TIMER ? "cp15" : "", - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "", - type & ARCH_MEM_TIMER ? "mmio" : "", - (unsigned long)arch_timer_rate / 1000000, - (unsigned long)(arch_timer_rate / 10000) % 100, - type & ARCH_CP15_TIMER ? - (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" : - "", - type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "", - type & ARCH_MEM_TIMER ? - arch_timer_mem_use_virtual ? "virt" : "phys" : - ""); + pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n", + type & ARCH_CP15_TIMER ? "cp15" : "", + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "", + type & ARCH_MEM_TIMER ? "mmio" : "", + (unsigned long)arch_timer_rate / 1000000, + (unsigned long)(arch_timer_rate / 10000) % 100, + type & ARCH_CP15_TIMER ? + (arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" : + "", + type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "", + type & ARCH_MEM_TIMER ? + arch_timer_mem_use_virtual ? "virt" : "phys" : + ""); }
u32 arch_timer_get_rate(void) @@ -498,7 +501,7 @@ static void __init arch_counter_register(unsigned type)
static void arch_timer_stop(struct clock_event_device *clk) { - pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n", + pr_debug("teardown, disable IRQ%d cpu #%d\n", clk->irq, smp_processor_id());
disable_percpu_irq(arch_timer_ppi[arch_timer_uses_ppi]); @@ -597,8 +600,7 @@ static int __init arch_timer_register(void) }
if (err) { - pr_err("arch_timer: can't register interrupt %d (%d)\n", - ppi, err); + pr_err("can't register interrupt %d (%d)\n", ppi, err); goto out_free; }
@@ -650,7 +652,7 @@ static int __init arch_timer_mem_register(void __iomem *base, unsigned int irq)
ret = request_irq(irq, func, IRQF_TIMER, "arch_mem_timer", &t->evt); if (ret) { - pr_err("arch_timer: Failed to request mem timer irq\n"); + pr_err("Failed to request mem timer irq\n"); kfree(t); }
@@ -727,7 +729,7 @@ static void __init arch_timer_init(void) }
if (!has_ppi) { - pr_warn("arch_timer: No interrupt available, giving up\n"); + pr_warn("No interrupt available, giving up\n"); return; } } @@ -743,7 +745,7 @@ static void __init arch_timer_of_init(struct device_node *np) int i;
if (arch_timers_present & ARCH_CP15_TIMER) { - pr_warn("arch_timer: multiple nodes in dt, skipping\n"); + pr_warn("multiple nodes in dt, skipping\n"); return; }
@@ -778,7 +780,7 @@ static void __init arch_timer_mem_init(struct device_node *np) arch_timers_present |= ARCH_MEM_TIMER; cntctlbase = of_iomap(np, 0); if (!cntctlbase) { - pr_err("arch_timer: Can't find CNTCTLBase\n"); + pr_err("Can't find CNTCTLBase\n"); return; }
@@ -793,7 +795,7 @@ static void __init arch_timer_mem_init(struct device_node *np) u32 cntacr;
if (of_property_read_u32(frame, "frame-number", &n)) { - pr_err("arch_timer: Missing frame-number\n"); + pr_err("Missing frame-number\n"); of_node_put(frame); goto out; } @@ -821,7 +823,7 @@ static void __init arch_timer_mem_init(struct device_node *np)
base = arch_counter_base = of_iomap(best_frame, 0); if (!base) { - pr_err("arch_timer: Can't map frame's registers\n"); + pr_err("Can't map frame's registers\n"); goto out; }
@@ -831,7 +833,7 @@ static void __init arch_timer_mem_init(struct device_node *np) irq = irq_of_parse_and_map(best_frame, PHYS_SPI);
if (!irq) { - pr_err("arch_timer: Frame missing %s irq", + pr_err("Frame missing %s irq", arch_timer_mem_use_virtual ? "virt" : "phys"); goto out; } @@ -869,7 +871,7 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table) struct acpi_table_gtdt *gtdt;
if (arch_timers_present & ARCH_CP15_TIMER) { - pr_warn("arch_timer: already initialized, skipping\n"); + pr_warn("already initialized, skipping\n"); return -EINVAL; }
On 2016/6/30 2:15, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patch defines pr_fmt(fmt) for all pr_* functions, then the pr_* don't need to add "arch_timer:" everytime.
Also delete some Blank Spaces in arch_timer_banner, according to the suggestion from checkpatch.pl.
No functional change.
Signed-off-by: Fu Wei fu.wei@linaro.org
drivers/clocksource/arm_arch_timer.c | 52 +++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 966c574..9540e9d 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -29,6 +29,9 @@
#include <clocksource/arm_arch_timer.h>
+#undef pr_fmt +#define pr_fmt(fmt) "arch_timer: " fmt
#define CNTTIDR 0x08 #define CNTTIDR_VIRT(n) (BIT(1) << ((n) * 4))
@@ -388,24 +391,24 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
/* Check the timer frequency. */ if (arch_timer_rate == 0)
pr_warn("Architected timer frequency not available\n");
pr_warn("frequency not available\n");}
static void arch_timer_banner(unsigned type) {
- pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
type & ARCH_CP15_TIMER ? "cp15" : "",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",type & ARCH_MEM_TIMER ? "mmio" : "",(unsigned long)arch_timer_rate / 1000000,(unsigned long)(arch_timer_rate / 10000) % 100,type & ARCH_CP15_TIMER ?(arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :"",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",type & ARCH_MEM_TIMER ?arch_timer_mem_use_virtual ? "virt" : "phys" :"");
- pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",
type & ARCH_CP15_TIMER ? "cp15" : "",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " : "",type & ARCH_MEM_TIMER ? "mmio" : "",(unsigned long)arch_timer_rate / 1000000,(unsigned long)(arch_timer_rate / 10000) % 100,type & ARCH_CP15_TIMER ?(arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :"",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",type & ARCH_MEM_TIMER ?arch_timer_mem_use_virtual ? "virt" : "phys" :"");}
u32 arch_timer_get_rate(void) @@ -498,7 +501,7 @@ static void __init arch_counter_register(unsigned type)
static void arch_timer_stop(struct clock_event_device *clk) {
- pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
- pr_debug("teardown, disable IRQ%d cpu #%d\n",
Not a problem of this patch, but arch_timer_teardown is a function name? I can't find where it's defined...
I think we can leave arch_timer as it but update it to:
pr_debug("arch_timer_stop disable IRQ%d cpu #%d\n",
Others are look good to me.
Thanks Hanjun
Hi Hanjun
On 30 June 2016 at 10:54, Hanjun Guo hanjun.guo@linaro.org wrote:
On 2016/6/30 2:15, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patch defines pr_fmt(fmt) for all pr_* functions, then the pr_* don't need to add "arch_timer:" everytime.
Also delete some Blank Spaces in arch_timer_banner, according to the suggestion from checkpatch.pl.
No functional change.
Signed-off-by: Fu Wei fu.wei@linaro.org
drivers/clocksource/arm_arch_timer.c | 52 +++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 25 deletions(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 966c574..9540e9d 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -29,6 +29,9 @@
#include <clocksource/arm_arch_timer.h>
+#undef pr_fmt +#define pr_fmt(fmt) "arch_timer: " fmt
#define CNTTIDR 0x08 #define CNTTIDR_VIRT(n) (BIT(1) << ((n) * 4))
@@ -388,24 +391,24 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
/* Check the timer frequency. */ if (arch_timer_rate == 0)
pr_warn("Architected timer frequency not available\n");
pr_warn("frequency not available\n");}
static void arch_timer_banner(unsigned type) {
pr_info("Architected %s%s%s timer(s) running at %lu.%02luMHz(%s%s%s).\n",
type & ARCH_CP15_TIMER ? "cp15" : "",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and ": "",
type & ARCH_MEM_TIMER ? "mmio" : "",(unsigned long)arch_timer_rate / 1000000,(unsigned long)(arch_timer_rate / 10000) % 100,type & ARCH_CP15_TIMER ?(arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :"",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" :"",
type & ARCH_MEM_TIMER ?arch_timer_mem_use_virtual ? "virt" : "phys" :"");
pr_info("%s%s%s timer(s) running at %lu.%02luMHz (%s%s%s).\n",type & ARCH_CP15_TIMER ? "cp15" : "",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? " and " :"",
type & ARCH_MEM_TIMER ? "mmio" : "",(unsigned long)arch_timer_rate / 1000000,(unsigned long)(arch_timer_rate / 10000) % 100,type & ARCH_CP15_TIMER ?(arch_timer_uses_ppi == VIRT_PPI) ? "virt" : "phys" :"",type == (ARCH_CP15_TIMER | ARCH_MEM_TIMER) ? "/" : "",type & ARCH_MEM_TIMER ?arch_timer_mem_use_virtual ? "virt" : "phys" :"");}
u32 arch_timer_get_rate(void) @@ -498,7 +501,7 @@ static void __init arch_counter_register(unsigned type)
static void arch_timer_stop(struct clock_event_device *clk) {
pr_debug("arch_timer_teardown disable IRQ%d cpu #%d\n",
pr_debug("teardown, disable IRQ%d cpu #%d\n",Not a problem of this patch, but arch_timer_teardown is a function name? I can't find where it's defined...
I think we can leave arch_timer as it but update it to:
pr_debug("arch_timer_stop disable IRQ%d cpu #%d\n",
If so, you will see "arch_timer: arch_timer_stop disable IRQ%d cpu #%d\n "
I think we can do :
pr_debug(" disable IRQ%d cpu #%d\n",
Others are look good to me.
Thanks Hanjun
From: Fu Wei fu.wei@linaro.org
Signed-off-by: Fu Wei fu.wei@linaro.org --- drivers/acpi/acpi_gtdt.c | 85 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+)
diff --git a/drivers/acpi/acpi_gtdt.c b/drivers/acpi/acpi_gtdt.c new file mode 100644 index 0000000..54d7644e --- /dev/null +++ b/drivers/acpi/acpi_gtdt.c @@ -0,0 +1,85 @@ +/* + * ARM Specific GTDT table Support + * + * Copyright (C) 2015, Linaro Ltd. + * Author: Daniel Lezcano daniel.lezcano@linaro.org + * Fu Wei fu.wei@linaro.org + * Hanjun Guo hanjun.guo@linaro.org + * + * 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/acpi.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/module.h> + +#undef pr_fmt +#define pr_fmt(fmt) "GTDT: " fmt + +typedef struct { + struct acpi_table_gtdt *gtdt; + void *platform_timer_start; + void *gtdt_end; +} acpi_gtdt_desc_t; + +static acpi_gtdt_desc_t acpi_gtdt_desc __initdata; + +static inline void *gtdt_next(void *platform_timer, void *end, int type) +{ + struct acpi_gtdt_header *gh = platform_timer; + + while ((void *)(gh += gh->length) < end) + if (gh->type == type) + return (void *)gh; + return NULL; +} + +#define for_each_gtdt_type(_g, _t) \ + for (_g = acpi_gtdt_desc.platform_timer_start; _g; \ + _g = gtdt_next(_g, acpi_gtdt_desc.gtdt_end, _t)) + +#define for_each_gtdt_timer(_g) \ + for_each_gtdt_type(_g, ACPI_GTDT_TYPE_TIMER_BLOCK) + +#define for_each_gtdt_watchdog(_g) \ + for_each_gtdt_type(_g, ACPI_GTDT_TYPE_WATCHDOG) + +/* + * Get some basic info from GTDT table, and init the global variables above + * for all timers initialization of Generic Timer. + * This function does some validation on GTDT table. + */ +static int __init acpi_gtdt_desc_init(struct acpi_table_header *table) +{ + struct acpi_table_gtdt *gtdt = container_of(table, + struct acpi_table_gtdt, + header); + + acpi_gtdt_desc.gtdt = gtdt; + acpi_gtdt_desc.gtdt_end = (void *)table + table->length; + + if (table->revision < 2) { + pr_info("Revision:%d doesn't support Platform Timers.\n", + table->revision); + return 0; + } + + if (!gtdt->platform_timer_count) { + pr_info("No Platform Timer.\n"); + return 0; + } + + acpi_gtdt_desc.platform_timer_start = (void *)gtdt + + gtdt->platform_timer_offset; + if (acpi_gtdt_desc.platform_timer_start < + (void *)table + sizeof(struct acpi_table_gtdt)) { + pr_err(FW_BUG "Platform Timer pointer error.\n"); + acpi_gtdt_desc.platform_timer_start = NULL; + return -EINVAL; + } + + return gtdt->platform_timer_count; +}
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
No changelog?
Signed-off-by: Fu Wei fu.wei@linaro.org
Please combine this one with the [5-6/10]. Splitting them the way you did it is not very useful.
Thanks, Rafael
Hi Rafael,
Great thanks for your review :-)
On 30 June 2016 at 05:24, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
No changelog?
it's on [0/10]
Signed-off-by: Fu Wei fu.wei@linaro.org
Please combine this one with the [5-6/10]. Splitting them the way you did it is not very useful.
OK , NP, will do , thanks :-)
Thanks, Rafael
On Thursday, June 30, 2016 09:17:56 AM Fu Wei wrote:
Hi Rafael,
Great thanks for your review :-)
On 30 June 2016 at 05:24, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
No changelog?
it's on [0/10]
That's not enough. The [0/10] will not go into the git log, mind you.
Thanks, Rafael
Hi Rafael,
On 30 June 2016 at 09:26, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Thursday, June 30, 2016 09:17:56 AM Fu Wei wrote:
Hi Rafael,
Great thanks for your review :-)
On 30 June 2016 at 05:24, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
No changelog?
it's on [0/10]
That's not enough. The [0/10] will not go into the git log, mind you.
OK, thanks for your reminding, will add changelog for this driver in this patch[4+5+6].
Thanks, Rafael
Rafael J. Wysocki wrote:
That's not enough. The [0/10] will not go into the git log, mind you.
The changelog is placed under the "---", so it wouldn't go into the git log anyway.
From: Fu Wei fu.wei@linaro.org
This patch adds support for parsing arch timer in GTDT, provides some kernel APIs to parse all the PPIs and always-on info in GTDT and export them.
By this driver, we can simplify arm_arch_timer drivers, and separate the ACPI GTDT knowledge from it.
Signed-off-by: Fu Wei fu.wei@linaro.org Signed-off-by: Hanjun Guo hanjun.guo@linaro.org --- drivers/acpi/acpi_gtdt.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++ include/linux/acpi.h | 6 +++++ 2 files changed, 76 insertions(+)
diff --git a/drivers/acpi/acpi_gtdt.c b/drivers/acpi/acpi_gtdt.c index 54d7644e..edb5a8c 100644 --- a/drivers/acpi/acpi_gtdt.c +++ b/drivers/acpi/acpi_gtdt.c @@ -16,6 +16,8 @@ #include <linux/kernel.h> #include <linux/module.h>
+#include <clocksource/arm_arch_timer.h> + #undef pr_fmt #define pr_fmt(fmt) "GTDT: " fmt
@@ -83,3 +85,71 @@ static int __init acpi_gtdt_desc_init(struct acpi_table_header *table)
return gtdt->platform_timer_count; } + +static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags) +{ + int trigger, polarity; + + if (!interrupt) + return 0; + + trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE + : ACPI_LEVEL_SENSITIVE; + + polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW + : ACPI_ACTIVE_HIGH; + + return acpi_register_gsi(NULL, interrupt, trigger, polarity); +} + +/* + * Map the PPIs of per-cpu arch_timer. + * @type: the type of PPI + * Returns 0 if error. + */ +int __init acpi_gtdt_map_ppi(int type) +{ + struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt; + + switch (type) { + case PHYS_SECURE_PPI: + return map_generic_timer_interrupt(gtdt->secure_el1_interrupt, + gtdt->secure_el1_flags); + case PHYS_NONSECURE_PPI: + return map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt, + gtdt->non_secure_el1_flags); + case VIRT_PPI: + return map_generic_timer_interrupt(gtdt->virtual_timer_interrupt, + gtdt->virtual_timer_flags); + + case HYP_PPI: + return map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt, + gtdt->non_secure_el2_flags); + default: + pr_err("ppi type error.\n"); + } + + return 0; +} + +/* + * acpi_gtdt_c3stop - got c3stop info from GTDT + * + * Returns 1 if the timer is powered in deep idle state, 0 otherwise. + */ +int __init acpi_gtdt_c3stop(void) +{ + struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt; + + return !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON); +} + +int __init gtdt_arch_timer_init(struct acpi_table_header *table) +{ + if (table) + return acpi_gtdt_desc_init(table); + + pr_err("table pointer error.\n"); + + return -EINVAL; +} diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 288fac5..8439579 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -532,6 +532,12 @@ void acpi_walk_dep_device_list(acpi_handle handle); struct platform_device *acpi_create_platform_device(struct acpi_device *); #define ACPI_PTR(_ptr) (_ptr)
+#ifdef CONFIG_ACPI_GTDT +int __init gtdt_arch_timer_init(struct acpi_table_header *table); +int __init acpi_gtdt_map_ppi(int type); +int __init acpi_gtdt_c3stop(void); +#endif + #else /* !CONFIG_ACPI */
#define acpi_disabled 1
From: Fu Wei fu.wei@linaro.org
Signed-off-by: Fu Wei fu.wei@linaro.org --- drivers/acpi/Kconfig | 9 +++++++++ drivers/acpi/Makefile | 1 + 2 files changed, 10 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b7e2e77..27a5cf9 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -521,4 +521,13 @@ config XPOWER_PMIC_OPREGION
endif
+config ACPI_GTDT + bool "ACPI GTDT Support" + depends on ARM64 + help + GTDT (Generic Timer Description Table) provides information + for per-processor timers and Platform (memory-mapped) timers + for ARM platforms. Select this option to provide information + needed for the timers init. + endif # ACPI diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 251ce85..848aa8a 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -99,5 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o obj-$(CONFIG_PMIC_OPREGION) += pmic/intel_pmic.o obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o +obj-$(CONFIG_ACPI_GTDT) += acpi_gtdt.o
video-objs += acpi_video.o video_detect.o
From: Fu Wei fu.wei@linaro.org
The patch update arm_arch_timer driver to use the function provided by the new GTDT driver of ACPI. By this way, arm_arch_timer.c can be simplified, and separate all the ACPI GTDT knowledge from this timer driver.
Signed-off-by: Fu Wei fu.wei@linaro.org Signed-off-by: Hanjun Guo hanjun.guo@linaro.org --- drivers/clocksource/Kconfig | 1 + drivers/clocksource/arm_arch_timer.c | 49 +++++++++--------------------------- 2 files changed, 13 insertions(+), 37 deletions(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig index 47352d2..71d5b30 100644 --- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -8,6 +8,7 @@ config CLKSRC_OF config CLKSRC_ACPI bool select CLKSRC_PROBE + select ACPI_GTDT if ARM64
config CLKSRC_PROBE bool diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 9540e9d..1382a49 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -848,60 +848,35 @@ out: CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem", arch_timer_mem_init);
-#ifdef CONFIG_ACPI -static int __init map_generic_timer_interrupt(u32 interrupt, u32 flags) -{ - int trigger, polarity; - - if (!interrupt) - return 0; - - trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE - : ACPI_LEVEL_SENSITIVE; - - polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW - : ACPI_ACTIVE_HIGH; - - return acpi_register_gsi(NULL, interrupt, trigger, polarity); -} - +#ifdef CONFIG_ACPI_GTDT /* Initialize per-processor generic timer */ static int __init arch_timer_acpi_init(struct acpi_table_header *table) { - struct acpi_table_gtdt *gtdt; + int timer_count;
if (arch_timers_present & ARCH_CP15_TIMER) { pr_warn("already initialized, skipping\n"); return -EINVAL; }
- gtdt = container_of(table, struct acpi_table_gtdt, header); - arch_timers_present |= ARCH_CP15_TIMER;
- arch_timer_ppi[PHYS_SECURE_PPI] = - map_generic_timer_interrupt(gtdt->secure_el1_interrupt, - gtdt->secure_el1_flags); + timer_count = gtdt_arch_timer_init(table);
- arch_timer_ppi[PHYS_NONSECURE_PPI] = - map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt, - gtdt->non_secure_el1_flags); - - arch_timer_ppi[VIRT_PPI] = - map_generic_timer_interrupt(gtdt->virtual_timer_interrupt, - gtdt->virtual_timer_flags); + if (timer_count < 0) + return -EINVAL;
- arch_timer_ppi[HYP_PPI] = - map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt, - gtdt->non_secure_el2_flags); + arch_timer_ppi[PHYS_SECURE_PPI] = acpi_gtdt_map_ppi(PHYS_SECURE_PPI); + arch_timer_ppi[PHYS_NONSECURE_PPI] = acpi_gtdt_map_ppi(PHYS_NONSECURE_PPI); + arch_timer_ppi[VIRT_PPI] = acpi_gtdt_map_ppi(VIRT_PPI); + arch_timer_ppi[HYP_PPI] = acpi_gtdt_map_ppi(HYP_PPI); + /* Always-on capability */ + arch_timer_c3stop = acpi_gtdt_c3stop();
/* Get the frequency from CNTFRQ */ arch_timer_detect_rate(NULL, NULL); - - /* Always-on capability */ - arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON); - arch_timer_init(); + return 0; } CLOCKSOURCE_ACPI_DECLARE(arch_timer, ACPI_SIG_GTDT, arch_timer_acpi_init);
From: Fu Wei fu.wei@linaro.org
This driver adds support for parsing memory-mapped timer in GTDT: provide a kernel APIs to parse GT Block Structure in GTDT, export all the info by filling the struct which provided by parameter(pointer of the struct).
By this driver, we can add ACPI support for memory-mapped timer in arm_arch_timer drivers, and separate the ACPI GTDT knowledge from it.
Signed-off-by: Fu Wei fu.wei@linaro.org Signed-off-by: Hanjun Guo hanjun.guo@linaro.org --- drivers/acpi/acpi_gtdt.c | 89 ++++++++++++++++++++++++++++++++++++ include/clocksource/arm_arch_timer.h | 15 ++++++ include/linux/acpi.h | 1 + 3 files changed, 105 insertions(+)
diff --git a/drivers/acpi/acpi_gtdt.c b/drivers/acpi/acpi_gtdt.c index edb5a8c..4592dba 100644 --- a/drivers/acpi/acpi_gtdt.c +++ b/drivers/acpi/acpi_gtdt.c @@ -153,3 +153,92 @@ int __init gtdt_arch_timer_init(struct acpi_table_header *table)
return -EINVAL; } + +/* + * Helper function for getting the pointer of a timer frame in GT block. + */ +static void __init *gtdt_gt_timer_frame(struct acpi_gtdt_timer_block *gt_block, + int index) +{ + void *timer_frame = (void *)gt_block + gt_block->timer_offset + + sizeof(struct acpi_gtdt_timer_entry) * index; + + if (timer_frame <= (void *)gt_block + gt_block->header.length - + sizeof(struct acpi_gtdt_timer_entry)) + return timer_frame; + + return NULL; +} + +static int __init gtdt_parse_gt_block(void *platform_timer, int index, + void *data) +{ + struct acpi_gtdt_timer_block *block; + struct acpi_gtdt_timer_entry *frame; + struct gt_block_data *block_data; + int i, j; + + if (!platform_timer || !data) + return -EINVAL; + + block = platform_timer; + block_data = data + sizeof(struct gt_block_data) * index; + + if (!block->block_address || !block->timer_count) { + pr_err(FW_BUG "invalid GT Block data.\n"); + return -EINVAL; + } + block_data->cntctlbase_phy = (phys_addr_t)block->block_address; + block_data->timer_count = block->timer_count; + + /* + * Get the GT timer Frame data for every GT Block Timer + */ + for (i = 0, j = 0; i < block->timer_count; i++) { + frame = gtdt_gt_timer_frame(block, i); + if (!frame || !frame->base_address || !frame->timer_interrupt) { + pr_err(FW_BUG "invalid GT Block Timer data.\n"); + return -EINVAL; + } + block_data->timer[j].frame_nr = frame->frame_number; + block_data->timer[j].cntbase_phy = frame->base_address; + block_data->timer[j].irq = map_generic_timer_interrupt( + frame->timer_interrupt, + frame->timer_flags); + if (frame->virtual_timer_interrupt) + block_data->timer[j].virt_irq = + map_generic_timer_interrupt( + frame->virtual_timer_interrupt, + frame->virtual_timer_flags); + j++; + } + + if (j) + return 0; + + block_data->cntctlbase_phy = (phys_addr_t)NULL; + block_data->timer_count = 0; + + return -EINVAL; +} + +/* + * Get the GT block info for memory-mapped timer from GTDT table. + * Please make sure we have called gtdt_arch_timer_init, because it helps to + * init the global variables. + */ +int __init gtdt_arch_timer_mem_init(struct gt_block_data *data) +{ + void *platform_timer; + int index = 0; + + for_each_gtdt_timer(platform_timer) { + if (!gtdt_parse_gt_block(platform_timer, index, data)) + index++; + } + + if (index) + pr_info("found %d memory-mapped timer block.\n", index); + + return index; +} diff --git a/include/clocksource/arm_arch_timer.h b/include/clocksource/arm_arch_timer.h index 16dcd10..ece6b3b 100644 --- a/include/clocksource/arm_arch_timer.h +++ b/include/clocksource/arm_arch_timer.h @@ -56,6 +56,8 @@ enum spi_nr { #define ARCH_TIMER_MEM_PHYS_ACCESS 2 #define ARCH_TIMER_MEM_VIRT_ACCESS 3
+#define ARCH_TIMER_MEM_MAX_FRAME 8 + #define ARCH_TIMER_USR_PCT_ACCESS_EN (1 << 0) /* physical counter */ #define ARCH_TIMER_USR_VCT_ACCESS_EN (1 << 1) /* virtual counter */ #define ARCH_TIMER_VIRT_EVT_EN (1 << 2) @@ -71,6 +73,19 @@ struct arch_timer_kvm_info { int virtual_irq; };
+struct gt_timer_data { + int frame_nr; + phys_addr_t cntbase_phy; + int irq; + int virt_irq; +}; + +struct gt_block_data { + phys_addr_t cntctlbase_phy; + int timer_count; + struct gt_timer_data timer[ARCH_TIMER_MEM_MAX_FRAME]; +}; + #ifdef CONFIG_ARM_ARCH_TIMER
extern u32 arch_timer_get_rate(void); diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 8439579..b1cacbc 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -536,6 +536,7 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *); int __init gtdt_arch_timer_init(struct acpi_table_header *table); int __init acpi_gtdt_map_ppi(int type); int __init acpi_gtdt_c3stop(void); +int __init gtdt_arch_timer_mem_init(struct gt_block_data *data); #endif
#else /* !CONFIG_ACPI */
From: Fu Wei fu.wei@linaro.org
The patch add memory-mapped timer register support by using the information provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei fu.wei@linaro.org --- drivers/clocksource/arm_arch_timer.c | 131 ++++++++++++++++++++++++++++++++++- 1 file changed, 130 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c index 1382a49..683d691 100644 --- a/drivers/clocksource/arm_arch_timer.c +++ b/drivers/clocksource/arm_arch_timer.c @@ -849,7 +849,132 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem", arch_timer_mem_init);
#ifdef CONFIG_ACPI_GTDT -/* Initialize per-processor generic timer */ +static struct gt_timer_data __init *arch_timer_mem_get_timer( + struct gt_block_data *gt_blocks) +{ + struct gt_block_data *gt_block = gt_blocks; + struct gt_timer_data *best_frame = NULL; + void __iomem *cntctlbase; + u32 cnttidr; + int i; + + /* + * According to ARMv8 Architecture Reference Manual(ARM), + * the size of CNTCTLBase frame of memory-mapped timer + * is SZ_4K(Offset 0x000 – 0xFFF). + */ + cntctlbase = ioremap(gt_block->cntctlbase_phy, SZ_4K); + if (!cntctlbase) { + pr_err("Can't map CNTCTLBase\n"); + return NULL; + } + cnttidr = readl_relaxed(cntctlbase + CNTTIDR); + + /* + * Try to find a virtual capable frame. Otherwise fall back to a + * physical capable frame. + */ + for (i = 0; i < gt_block->timer_count; i++) { + int n; + u32 cntacr; + + n = gt_block->timer[i].frame_nr; + + /* Try enabling everything, and see what sticks */ + cntacr = CNTACR_RFRQ | CNTACR_RWPT | CNTACR_RPCT | + CNTACR_RWVT | CNTACR_RVOFF | CNTACR_RVCT; + writel_relaxed(cntacr, cntctlbase + CNTACR(n)); + cntacr = readl_relaxed(cntctlbase + CNTACR(n)); + + if ((cnttidr & CNTTIDR_VIRT(n)) && + !(~cntacr & (CNTACR_RWVT | CNTACR_RVCT))) { + best_frame = >_block->timer[i]; + arch_timer_mem_use_virtual = true; + break; + } + + if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT)) + continue; + + best_frame = >_block->timer[i]; + } + iounmap(cntctlbase); + + return best_frame; +} + +static int __init arch_timer_mem_acpi_init(u32 timer_count) +{ + struct gt_block_data *gt_blocks; + struct gt_timer_data *gt_timer; + void __iomem *timer_cntbase; + int ret = -EINVAL; + int timer_irq; + + /* + * If we have some Platform Timer Structures, + * try to find and register a memory-mapped timer. + * If not, just return. + */ + if (!timer_count) + return 0; + + if (arch_timers_present & ARCH_MEM_TIMER) { + pr_warn("memory-mapped timer already initialized, skipping\n"); + return 0; + } + arch_timers_present |= ARCH_MEM_TIMER; + /* + * before really check all the Platform Timer Structures, + * we assume they are GT block, and allocate memory for them. + * We will free these memory once we finish the initialization. + */ + gt_blocks = kcalloc(timer_count, sizeof(*gt_blocks), GFP_KERNEL); + if (!gt_blocks) + return -ENOMEM; + + if (gtdt_arch_timer_mem_init(gt_blocks)) { + gt_timer = arch_timer_mem_get_timer(gt_blocks); + if (!gt_timer) { + pr_err("Failed to get mem timer info.\n"); + goto error; + } + + if (arch_timer_mem_use_virtual) + timer_irq = gt_timer->virt_irq; + else + timer_irq = gt_timer->irq; + if (!timer_irq) { + pr_err("Frame missing %s irq", + arch_timer_mem_use_virtual ? "virt" : "phys"); + goto error; + } + + /* + * According to ARMv8 Architecture Reference Manual(ARM), + * the size of CNTBaseN frames of memory-mapped timer + * is SZ_4K(Offset 0x000 – 0xFFF). + */ + timer_cntbase = ioremap(gt_timer->cntbase_phy, SZ_4K); + if (!timer_cntbase) { + pr_err("Can't map CntBase.\n"); + goto error; + } + arch_counter_base = timer_cntbase; + ret = arch_timer_mem_register(timer_cntbase, timer_irq); + if (ret) { + iounmap(timer_cntbase); + arch_counter_base = NULL; + pr_err("Failed to register mem timer.\n"); + } + } + +error: + kfree(gt_blocks); + return ret; +} + +/* Initialize per-processor generic timer and memory-mapped timer(if present) */ static int __init arch_timer_acpi_init(struct acpi_table_header *table) { int timer_count; @@ -875,6 +1000,10 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
/* Get the frequency from CNTFRQ */ arch_timer_detect_rate(NULL, NULL); + + if (arch_timer_mem_acpi_init(timer_count)) + pr_err("Failed to initialize memory-mapped timer, skipping\n"); + arch_timer_init();
return 0;
From: Fu Wei fu.wei@linaro.org
This driver adds support for parsing SBSA Generic Watchdog timer in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT, and creating a platform device with that information.
This allows the operating system to obtain device data from the resource of platform device. The platform device named "sbsa-gwdt" can be used by the ARM SBSA Generic Watchdog driver.
Signed-off-by: Fu Wei fu.wei@linaro.org Signed-off-by: Hanjun Guo hanjun.guo@linaro.org --- drivers/acpi/acpi_gtdt.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++ drivers/watchdog/Kconfig | 1 + 2 files changed, 83 insertions(+)
diff --git a/drivers/acpi/acpi_gtdt.c b/drivers/acpi/acpi_gtdt.c index 4592dba..ab8a822 100644 --- a/drivers/acpi/acpi_gtdt.c +++ b/drivers/acpi/acpi_gtdt.c @@ -15,6 +15,7 @@ #include <linux/init.h> #include <linux/kernel.h> #include <linux/module.h> +#include <linux/platform_device.h>
#include <clocksource/arm_arch_timer.h>
@@ -242,3 +243,84 @@ int __init gtdt_arch_timer_mem_init(struct gt_block_data *data)
return index; } + +/* + * Initialize a SBSA generic Watchdog platform device info from GTDT + */ +static int __init gtdt_import_sbsa_gwdt(void *platform_timer, int index) +{ + struct platform_device *pdev; + struct acpi_gtdt_watchdog *wd = platform_timer; + int irq = map_generic_timer_interrupt(wd->timer_interrupt, + wd->timer_flags); + int no_irq = 1; + + /* + * According to SBSA specification the size of refresh and control + * frames of SBSA Generic Watchdog is SZ_4K(Offset 0x000 – 0xFFF). + */ + struct resource res[] = { + DEFINE_RES_MEM(wd->control_frame_address, SZ_4K), + DEFINE_RES_MEM(wd->refresh_frame_address, SZ_4K), + DEFINE_RES_IRQ(irq), + }; + + pr_debug("a Watchdog GT(0x%llx/0x%llx gsi:%u flags:0x%x).\n", + wd->refresh_frame_address, wd->control_frame_address, + wd->timer_interrupt, wd->timer_flags); + + if (!(wd->refresh_frame_address && wd->control_frame_address)) { + pr_err(FW_BUG "failed getting the Watchdog GT frame addr.\n"); + return -EINVAL; + } + + if (!wd->timer_interrupt) + pr_warn(FW_BUG "failed getting the Watchdog GT GSIV.\n"); + else if (irq <= 0) + pr_warn("failed to map the Watchdog GT GSIV.\n"); + else + no_irq = 0; + + /* + * Add a platform device named "sbsa-gwdt" to match the platform driver. + * "sbsa-gwdt": SBSA(Server Base System Architecture) Generic Watchdog + * The platform driver (like drivers/watchdog/sbsa_gwdt.c)can get device + * info below by matching this name. + */ + pdev = platform_device_register_simple("sbsa-gwdt", index, res, + ARRAY_SIZE(res) - no_irq); + if (IS_ERR(pdev)) { + acpi_unregister_gsi(wd->timer_interrupt); + return PTR_ERR(pdev); + } + + return 0; +} + +static int __init gtdt_sbsa_gwdt_init(void) +{ + struct acpi_table_header *table; + void *platform_timer; + int index = 0; + + if (acpi_disabled) + return 0; + + if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_GTDT, 0, &table))) + return -EINVAL; + + if (acpi_gtdt_desc_init(table) < 0) + return -EINVAL; + + for_each_gtdt_watchdog(platform_timer) { + if (!gtdt_import_sbsa_gwdt(platform_timer, index)) + index++; + } + + if (index) + pr_info("found %d SBSA generic Watchdog.\n", index); + + return 0; +} + +device_initcall(gtdt_sbsa_gwdt_init); diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index b4b3e25..105f059 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -207,6 +207,7 @@ config ARM_SBSA_WATCHDOG depends on ARM64 depends on ARM_ARCH_TIMER select WATCHDOG_CORE + select ACPI_GTDT if ACPI help ARM SBSA Generic Watchdog has two stage timeouts: the first signal (WS0) is for alerting the system by interrupt,
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timer
GTDT is ARM-specific AFAICS.
If so, why do we need that code to reside in drivers/acpi/ ?
Thanks, Rafael
Hi Rafael,
On 30 June 2016 at 05:32, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timerGTDT is ARM-specific AFAICS.
yes, you are right, it is.
If so, why do we need that code to reside in drivers/acpi/ ?
Although the GTDT is just for ARM64, but this driver is parsing one of ACPI table, I think that could be treated as ACPI driver. Do I miss something? :-)
Thanks, Rafael
On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
Hi Rafael,
On 30 June 2016 at 05:32, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timerGTDT is ARM-specific AFAICS.
yes, you are right, it is.
If so, why do we need that code to reside in drivers/acpi/ ?
Although the GTDT is just for ARM64, but this driver is parsing one of ACPI table, I think that could be treated as ACPI driver. Do I miss something? :-)
Yes, you are. Nobody except for ARM64 will ever need it.
Thanks, Rafael
Hi Rafael,
On 2016/6/30 9:37, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
Hi Rafael,
On 30 June 2016 at 05:32, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timerGTDT is ARM-specific AFAICS.
yes, you are right, it is.
If so, why do we need that code to reside in drivers/acpi/ ?
Although the GTDT is just for ARM64, but this driver is parsing one of ACPI table, I think that could be treated as ACPI driver. Do I miss something? :-)
Yes, you are. Nobody except for ARM64 will ever need it.
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
Thanks Hanjun
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
Hi Rafael,
On 2016/6/30 9:37, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
Hi Rafael,
On 30 June 2016 at 05:32, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timerGTDT is ARM-specific AFAICS.
yes, you are right, it is.
If so, why do we need that code to reside in drivers/acpi/ ?
Although the GTDT is just for ARM64, but this driver is parsing one of ACPI table, I think that could be treated as ACPI driver. Do I miss something? :-)
Yes, you are. Nobody except for ARM64 will ever need it.
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
Thanks, Rafael
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
Hi Rafael,
On 2016/6/30 9:37, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 09:29:59 AM Fu Wei wrote:
Hi Rafael,
On 30 June 2016 at 05:32, Rafael J. Wysocki rafael@kernel.org wrote:
On Wed, Jun 29, 2016 at 8:15 PM, fu.wei@linaro.org wrote:
From: Fu Wei fu.wei@linaro.org
This patchset: (1)Preparation for adding GTDT support in arm_arch_timer 1. Move some enums and marcos to header file 2. Add a new enum for spi type. 3. Improve printk relevant code
(2)Introduce ACPI GTDT parser: drivers/acpi/gtdt.c Parse all kinds of timer in GTDT table of ACPI:arch timer, memory-mapped timer and SBSA Generic Watchdog timer. This driver can help to simplify all the relevant timer drivers, and separate all the ACPI GTDT knowledge from them. (3)Simplify ACPI code for arm_arch_timer (4)Add GTDT support for ARM memory-mapped timerGTDT is ARM-specific AFAICS.
yes, you are right, it is.
If so, why do we need that code to reside in drivers/acpi/ ?
Although the GTDT is just for ARM64, but this driver is parsing one of ACPI table, I think that could be treated as ACPI driver. Do I miss something? :-)
Yes, you are. Nobody except for ARM64 will ever need it.
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
Thanks Hanjun
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
Will
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.
What gives?
Maybe it should go to the same place as the analogus DT code, then?
Thanks, Rafael
On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.
What gives?
Well, since there are things like acpi_lpss in there, my position here is kind of weak. :-)
That said I'm not particularly happy with having them in drivers/acpi/, so I definitely won't object against attempts to moving them somewhere else.
Maybe it should go to the same place as the analogus DT code, then?
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward, though. I also think it should be made clear that it is ARM64-only.
Thanks, Rafael
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote:
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.
What gives?
Well, since there are things like acpi_lpss in there, my position here is kind of weak. :-)
That said I'm not particularly happy with having them in drivers/acpi/, so I definitely won't object against attempts to moving them somewhere else.
Maybe it should go to the same place as the analogus DT code, then?
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward, though. I also think it should be made clear that it is ARM64-only.
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Graeme
On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory gg@slimlogic.co.uk wrote:
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
On 2016/6/30 21:27, Rafael J. Wysocki wrote:
On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote: >GTDT is part of ACPI spec, drivers/acpi/ is for driver code of >ACPI spec, I think it can stay in drivers/acpi/ from this point >of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.
What gives?
Well, since there are things like acpi_lpss in there, my position here is kind of weak. :-)
That said I'm not particularly happy with having them in drivers/acpi/, so I definitely won't object against attempts to moving them somewhere else.
Maybe it should go to the same place as the analogus DT code, then?
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward, though. I also think it should be made clear that it is ARM64-only.
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
That's one thing.
Another one is the question I asked a few messages ago: Why having the GTDT code in drivers/acpi/ is actually useful to anyone? It definitely would not be useful to me as the maintainer of drivers/acpi/, but maybe it would be useful to somebody for a specific practical reason. Or is it just "let's put this into drivers/acpi/ for the lack of a better place"?
I have not received a good answer to this one yet.
Thanks, Rafael
On 2016/7/6 8:00, Rafael J. Wysocki wrote:
On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory gg@slimlogic.co.uk wrote:
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote:
On 2016/6/30 21:27, Rafael J. Wysocki wrote: > On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote: >> GTDT is part of ACPI spec, drivers/acpi/ is for driver code of >> ACPI spec, I think it can stay in drivers/acpi/ from this point >> of view, am I right? > > The question is not "Can it?", but "Does it need to?". > > It is in the spec, but still there's only one architecture needing it. > > There is no way to test it on any other architecture and no reason to build it > for any other architecture, so why does it need to be located in drivers/acpi/ ?
I'm fine to move it to other places such as arch/arm64/kernel/, but I would like to ask ARM64 maintainer's suggestion for this.
Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.
What gives?
Well, since there are things like acpi_lpss in there, my position here is kind of weak. :-)
That said I'm not particularly happy with having them in drivers/acpi/, so I definitely won't object against attempts to moving them somewhere else.
Maybe it should go to the same place as the analogus DT code, then?
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward, though. I also think it should be made clear that it is ARM64-only.
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
I'm working on ACPI for years and upstreamed the ARM64 ACPI core support (with lots of people's help), I'm willing to maintain the ARM64 ACPI code under drivers/acpi/ if no objections.
That's one thing.
Another one is the question I asked a few messages ago: Why having the GTDT code in drivers/acpi/ is actually useful to anyone? It definitely would not be useful to me as the maintainer of drivers/acpi/, but maybe it would be useful to somebody for a specific practical reason. Or is it just "let's put this into drivers/acpi/ for the lack of a better place"?
Having GTDT code in drivers/acpi/ is useful as it is code that is used by two different subsystems, clocksource and watchdog,and where people look by default for utility ACPI code.
If the mostly concerned thing (maintainer ship) is settled down, the second question would be easily solved.
Thanks Hanjun
On Thursday, July 07, 2016 07:12:38 PM Hanjun Guo wrote:
On 2016/7/6 8:00, Rafael J. Wysocki wrote:
On Tue, Jul 5, 2016 at 4:18 PM, Graeme Gregory gg@slimlogic.co.uk wrote:
On Mon, Jul 04, 2016 at 02:53:20PM +0200, Rafael J. Wysocki wrote:
On Fri, Jul 1, 2016 at 11:04 PM, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Friday, July 01, 2016 04:23:40 PM Will Deacon wrote:
On Thu, Jun 30, 2016 at 09:48:02PM +0800, Hanjun Guo wrote: > On 2016/6/30 21:27, Rafael J. Wysocki wrote: >> On Thursday, June 30, 2016 10:10:02 AM Hanjun Guo wrote: >>> GTDT is part of ACPI spec, drivers/acpi/ is for driver code of >>> ACPI spec, I think it can stay in drivers/acpi/ from this point >>> of view, am I right? >> >> The question is not "Can it?", but "Does it need to?". >> >> It is in the spec, but still there's only one architecture needing it. >> >> There is no way to test it on any other architecture and no reason to build it >> for any other architecture, so why does it need to be located in drivers/acpi/ ? > > I'm fine to move it to other places such as arch/arm64/kernel/, but I > would like to ask ARM64 maintainer's suggestion for this. > > Will, Catalin, what's your opinion on this?
We don't have any device-tree code for the architected timer under arch/arm64, so I don't see why we should need anything for ACPI either.
And I don't see a reason for the GTDT code to be there in drivers/acpi/.
What gives?
Well, since there are things like acpi_lpss in there, my position here is kind of weak. :-)
That said I'm not particularly happy with having them in drivers/acpi/, so I definitely won't object against attempts to moving them somewhere else.
Maybe it should go to the same place as the analogus DT code, then?
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward, though. I also think it should be made clear that it is ARM64-only.
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
I'm working on ACPI for years and upstreamed the ARM64 ACPI core support (with lots of people's help), I'm willing to maintain the ARM64 ACPI code under drivers/acpi/ if no objections.
OK
Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
That's one thing.
Another one is the question I asked a few messages ago: Why having the GTDT code in drivers/acpi/ is actually useful to anyone? It definitely would not be useful to me as the maintainer of drivers/acpi/, but maybe it would be useful to somebody for a specific practical reason. Or is it just "let's put this into drivers/acpi/ for the lack of a better place"?
Having GTDT code in drivers/acpi/ is useful as it is code that is used by two different subsystems, clocksource and watchdog,and where people look by default for utility ACPI code.
If the mostly concerned thing (maintainer ship) is settled down, the second question would be easily solved.
Fair enough.
Thanks, Rafael
[+Sudeep]
On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
[...]
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
I'm working on ACPI for years and upstreamed the ARM64 ACPI core support (with lots of people's help), I'm willing to maintain the ARM64 ACPI code under drivers/acpi/ if no objections.
OK
I would ask you please to add Sudeep and myself for the ARM64 specific ACPI code maintainership too.
Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
It can, but I do not understand why x86 should not have a separate directory for all x86 specific stuff too then.
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
That's one thing.
Another one is the question I asked a few messages ago: Why having the GTDT code in drivers/acpi/ is actually useful to anyone? It definitely would not be useful to me as the maintainer of drivers/acpi/, but maybe it would be useful to somebody for a specific practical reason. Or is it just "let's put this into drivers/acpi/ for the lack of a better place"?
The same logic applies to eg ioapic.c but anyway, see above, if it can help having a separate subdirectory let's do it.
Having GTDT code in drivers/acpi/ is useful as it is code that is used by two different subsystems, clocksource and watchdog,and where people look by default for utility ACPI code.
If the mostly concerned thing (maintainer ship) is settled down, the second question would be easily solved.
See above.
Thanks, Lorenzo
On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
[+Sudeep]
On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
[...]
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
I'm working on ACPI for years and upstreamed the ARM64 ACPI core support (with lots of people's help), I'm willing to maintain the ARM64 ACPI code under drivers/acpi/ if no objections.
OK
I would ask you please to add Sudeep and myself for the ARM64 specific ACPI code maintainership too.
OK
Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
It can, but I do not understand why x86 should not have a separate directory for all x86 specific stuff too then.
It should. :-)
It doesn't have it ATM, but that doesn't mean it's all OK.
Well, some of the x86-specific stuff goes into arch/x86/kernel/acpi/, so it has something at least.
In any case, IMO, if some code is only used by one architecture, it should be clear that this is the case, and moving that code into a separate directory helps to achieve that.
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
To avoid confusion on who's going to push stuff to Linus, I can do that, but it must be clear whose ACKs are needed for that to happen. That may be one person or all of you, whatever you decide.
I can take pull requests too if that's more convenient.
Thanks, Rafael
Hi Rafael,
On 7 July 2016 at 21:58, Rafael J. Wysocki rjw@rjwysocki.net wrote:
On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
[+Sudeep]
On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
[...]
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
I'm working on ACPI for years and upstreamed the ARM64 ACPI core support (with lots of people's help), I'm willing to maintain the ARM64 ACPI code under drivers/acpi/ if no objections.
OK
I would ask you please to add Sudeep and myself for the ARM64 specific ACPI code maintainership too.
OK
For this, it seems we have a decision now, so I will post v7 tomorrow following this decision: drivers/acpi/arm64/acpi_gtdt.c
I think that is a very good idea, I also believe Hanjun can maintain it well.
Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
It can, but I do not understand why x86 should not have a separate directory for all x86 specific stuff too then.
It should. :-)
It doesn't have it ATM, but that doesn't mean it's all OK.
Well, some of the x86-specific stuff goes into arch/x86/kernel/acpi/, so it has something at least.
In any case, IMO, if some code is only used by one architecture, it should be clear that this is the case, and moving that code into a separate directory helps to achieve that.
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
To avoid confusion on who's going to push stuff to Linus, I can do that, but it must be clear whose ACKs are needed for that to happen. That may be one person or all of you, whatever you decide.
I can take pull requests too if that's more convenient.
Thanks, Rafael
On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:
[...]
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
To avoid confusion on who's going to push stuff to Linus, I can do that, but it must be clear whose ACKs are needed for that to happen. That may be one person or all of you, whatever you decide.
I think the reasoning is the same, to avoid confusion and avoid stepping on each other toes it is best to have a single gatekeeper (still multiple maintainer entries to keep patches reviewed correctly), if no one complains I will do that and a) provide ACKs (I will definitely require and request Hanjun and Sudeep ones too appropriately on a per patch basis) and b) send you pull requests.
Having a maintainer per file would be farcical, I really do not expect that amount of traffic for drivers/acpi/arm64 therefore I really doubt there is any risk of me slowing things down.
Does this sound reasonable ? Comments/complaints welcome, please manifest yourselves.
Thanks, Lorenzo
On 08/07/16 14:22, Lorenzo Pieralisi wrote:
On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:
[...]
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
To avoid confusion on who's going to push stuff to Linus, I can do that, but it must be clear whose ACKs are needed for that to happen. That may be one person or all of you, whatever you decide.
I think the reasoning is the same, to avoid confusion and avoid stepping on each other toes it is best to have a single gatekeeper (still multiple maintainer entries to keep patches reviewed correctly), if no one complains I will do that and a) provide ACKs (I will definitely require and request Hanjun and Sudeep ones too appropriately on a per patch basis) and b) send you pull requests.
Having a maintainer per file would be farcical, I really do not expect that amount of traffic for drivers/acpi/arm64 therefore
I agree.
I really doubt there is any risk of me slowing things down.
Does this sound reasonable ? Comments/complaints welcome, please manifest yourselves.
Yes sounds good to me.
On 2016/7/8 21:22, Lorenzo Pieralisi wrote:
On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:
[...]
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
To avoid confusion on who's going to push stuff to Linus, I can do that, but it must be clear whose ACKs are needed for that to happen. That may be one person or all of you, whatever you decide.
I think the reasoning is the same, to avoid confusion and avoid stepping on each other toes it is best to have a single gatekeeper (still multiple maintainer entries to keep patches reviewed correctly), if no one complains I will do that and a) provide ACKs (I will definitely require and request Hanjun and Sudeep ones too appropriately on a per patch basis) and b) send you pull requests.
Fine to me.
Having a maintainer per file would be farcical, I really do not
Agree, but having three of us in maintainer entries in MAINTAINERS file will help the patches be reviewed correctly with more eyes.
expect that amount of traffic for drivers/acpi/arm64 therefore I really doubt there is any risk of me slowing things down.
Does this sound reasonable ? Comments/complaints welcome, please manifest yourselves.
Fair enough. What I'm concern most is land ACPI on ARM64 soundly, let's do that :)
OK, let's back to this patch set, Fuwei already prepared a new version of patches [1] (moving acpi_gtdt.c to drivers/acpi/arm64/ and add a maintainer entries patch), shall we review and comment on this patch set for now, or just let Fuwei send out the new version?
[1]: https://git.linaro.org/people/fu.wei/linux.git/shortlog/refs/heads/topic-gtd...
Thanks Hanjun
On Saturday, July 09, 2016 11:44:47 AM Hanjun Guo wrote:
On 2016/7/8 21:22, Lorenzo Pieralisi wrote:
On Thu, Jul 07, 2016 at 03:58:04PM +0200, Rafael J. Wysocki wrote:
[...]
Anyway let's avoid these petty arguments, I agree there must be some sort of ARM64 ACPI maintainership for the reasons you mentioned above.
To avoid confusion on who's going to push stuff to Linus, I can do that, but it must be clear whose ACKs are needed for that to happen. That may be one person or all of you, whatever you decide.
I think the reasoning is the same, to avoid confusion and avoid stepping on each other toes it is best to have a single gatekeeper (still multiple maintainer entries to keep patches reviewed correctly), if no one complains I will do that and a) provide ACKs (I will definitely require and request Hanjun and Sudeep ones too appropriately on a per patch basis) and b) send you pull requests.
Fine to me.
Having a maintainer per file would be farcical, I really do not
Agree, but having three of us in maintainer entries in MAINTAINERS file will help the patches be reviewed correctly with more eyes.
expect that amount of traffic for drivers/acpi/arm64 therefore I really doubt there is any risk of me slowing things down.
Does this sound reasonable ? Comments/complaints welcome, please manifest yourselves.
Fair enough. What I'm concern most is land ACPI on ARM64 soundly, let's do that :)
OK, let's back to this patch set, Fuwei already prepared a new version of patches [1] (moving acpi_gtdt.c to drivers/acpi/arm64/ and add a maintainer entries patch), shall we review and comment on this patch set for now, or just let Fuwei send out the new version?
Frankly, I don't see a point in discussing the old version only if a new one is available already. Post it, please.
Thanks, Rafael
On 2016/7/7 21:58, Rafael J. Wysocki wrote:
On Thursday, July 07, 2016 02:40:23 PM Lorenzo Pieralisi wrote:
[+Sudeep]
On Thu, Jul 07, 2016 at 02:03:17PM +0200, Rafael J. Wysocki wrote:
[...]
So is this a documentation issue in which case Fu Wei can add that to the file to explain its limited to ARM64. Or we could even rename the file acpi_arm64_gtdt.c
It seems a pity as the comment on this series were minors to block things on a filename/location.
Let me repeat what I said above:
I'm mostly concerned about how (and by whom) that code is going to be maintained going forward.
This is not about documentation, it is about responsibility.
Honestly, I don't think I'm the right maintainer to apply the patch introducing this code and then handle bug reports regarding it and so on. That has to be done by somebody else.
I'm working on ACPI for years and upstreamed the ARM64 ACPI core support (with lots of people's help), I'm willing to maintain the ARM64 ACPI code under drivers/acpi/ if no objections.
OK
I would ask you please to add Sudeep and myself for the ARM64 specific ACPI code maintainership too.
OK
Can the ARM64-specific code go under drivers/acpi/arm64/ then, for clarity?
I'm fine with it as it helps for maintain.
Thanks Hanjun
On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
[ ... ]
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
Hi Rafael,
what is the problem of having it in drivers/acpi ?
There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.
clocksource-probe which is DT based with different drivers using it in drivers/clocksource with a pletore of different archs.
Cstate code which is only used by x86 is in drivers/acpi, it is only used by x86/ia64 and it isn't a problem. There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the comprehension of the code.
IMHO, having all ACPI code in the same directory will encourage the consolidation.
On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
[ ... ]
GTDT is part of ACPI spec, drivers/acpi/ is for driver code of ACPI spec, I think it can stay in drivers/acpi/ from this point of view, am I right?
The question is not "Can it?", but "Does it need to?".
It is in the spec, but still there's only one architecture needing it.
There is no way to test it on any other architecture and no reason to build it for any other architecture, so why does it need to be located in drivers/acpi/ ?
Hi Rafael,
what is the problem of having it in drivers/acpi ?
There's no reason for it to be there.
There are cpufreq-dt, speedstep*, tegra124-* in drivers/cpufreq.
Yes, they are, but for a reason. Having them in there makes it easier to rework and clean up the core.
clocksource-probe which is DT based with different drivers using it in drivers/clocksource with a pletore of different archs.
So maybe the GTDT code should be there too?
Cstate code which is only used by x86 is in drivers/acpi, it is only used by x86/ia64 and it isn't a problem.
It is a problem. drivers/acpi/ is not the right place for arch-specific code.
There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the comprehension of the code.
IMHO, having all ACPI code in the same directory will encourage the consolidation.
The consolidation of what exactly?
In particular, how does the GTDT code in drivers/acpi/ help to consolidate anything?
Thanks, Rafael
On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
[ ... ]
clocksource-probe which is DT based with different drivers using it in drivers/clocksource with a pletore of different archs.
So maybe the GTDT code should be there too?
*maybe*
Cstate code which is only used by x86 is in drivers/acpi, it is only used by x86/ia64 and it isn't a problem.
It is a problem.
Can you explain why it is a problem ?
drivers/acpi/ is not the right place for arch-specific code.
I do not understand this assertion regarding what happened during the last years with different subsystems where the drivers were moved from their arch specific directories to the drivers directory (cpufreq, cpuidle, clockevent, clk, etc ...) and resulted at the end to a code refactoring and consolidation.
Why ACPI should follow the opposite rule ?
There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the comprehension of the code.
IMHO, having all ACPI code in the same directory will encourage the consolidation.
The consolidation of what exactly?
The consolidation of the ACPI code in general which is the counter-example of self-contained code.
In particular, how does the GTDT code in drivers/acpi/ help to consolidate anything?
If I imagine we group all ACPI code under a common directory, the first example coming in my mind is the sharing of private headers, reducing the scope of exported functions and global variables (eg. acpi_disabled).
That say, I can understand grouping all the ACPI into a single directory will make it fall under a single umbrella's maintainer and that could be a nightmare to maintain as it covers a lot of different features. However, I believe that could be solved by clearly identifying who takes care of what.
On Mon, Jul 4, 2016 at 3:43 PM, Daniel Lezcano daniel.lezcano@linaro.org wrote:
On 07/01/2016 11:01 PM, Rafael J. Wysocki wrote:
On Friday, July 01, 2016 04:00:34 PM Daniel Lezcano wrote:
On 06/30/2016 03:27 PM, Rafael J. Wysocki wrote:
[ ... ]
clocksource-probe which is DT based with different drivers using it in drivers/clocksource with a pletore of different archs.
So maybe the GTDT code should be there too?
*maybe*
Cstate code which is only used by x86 is in drivers/acpi, it is only used by x86/ia64 and it isn't a problem.
It is a problem.
Can you explain why it is a problem ?
drivers/acpi/ is not the right place for arch-specific code.
I do not understand this assertion regarding what happened during the last years with different subsystems where the drivers were moved from their arch specific directories to the drivers directory (cpufreq, cpuidle, clockevent, clk, etc ...) and resulted at the end to a code refactoring and consolidation.
Why ACPI should follow the opposite rule ?
Because drivers/acpi/ is for common and generic ACPI code. Maybe it should not be located under drivers/, but that's a different matter.
There is a small chunk in arch/x86/kernel/acpi and it doesn't facilitate the comprehension of the code.
IMHO, having all ACPI code in the same directory will encourage the consolidation.
The consolidation of what exactly?
The consolidation of the ACPI code in general which is the counter-example of self-contained code.
Do you actually realize how much ACPI code is there in the kernel and that moving it all into one directory would be totally counter-productive?
You seem to be thinking that ACPI is something like cpufreq, where you have the core and the drivers and nothing but the drivers uses the core, but that's not the case.
In particular, how does the GTDT code in drivers/acpi/ help to consolidate anything?
If I imagine we group all ACPI code under a common directory, the first example coming in my mind is the sharing of private headers, reducing the scope of exported functions and global variables (eg. acpi_disabled).
That say, I can understand grouping all the ACPI into a single directory will make it fall under a single umbrella's maintainer and that could be a nightmare to maintain as it covers a lot of different features. However, I believe that could be solved by clearly identifying who takes care of what.
And one way of doing that is to put things in different places in the kernel source tree.
Thanks, Rafael
-
Daniel Lezcano -
Fu Wei -
fu.wei＠linaro.org
-
Graeme Gregory -
Hanjun Guo -
Lorenzo Pieralisi -
Rafael J. Wysocki -
Rafael J. Wysocki -
Sudeep Holla -
Timur Tabi -
Will Deacon