All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-29 18:15 ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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

-- 
2.5.5

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-29 18:15 ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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

-- 
2.5.5

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-29 18:15 ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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

-- 
2.5.5

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

* [PATCH v6 01/10] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 01/10] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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
-- 
2.5.5

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

* [PATCH v6 01/10] clocksource/drivers/arm_arch_timer: Move enums and defines to header file
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 02/10] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 02/10] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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
-- 
2.5.5

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

* [PATCH v6 02/10] clocksource/drivers/arm_arch_timer: Add a new enum for spi type
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code
  2016-06-29 18:15 ` fu.wei
@ 2016-06-29 18:15   ` fu.wei at linaro.org
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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;
 	}
 
-- 
2.5.5


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

* [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code
@ 2016-06-29 18:15   ` fu.wei at linaro.org
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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@%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;
 	}
 
-- 
2.5.5

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
  2016-06-29 18:15 ` fu.wei
@ 2016-06-29 18:15   ` fu.wei at linaro.org
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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;
+}
-- 
2.5.5

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-29 18:15   ` fu.wei at linaro.org
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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;
+}
-- 
2.5.5

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

* [PATCH v6 05/10] acpi: Add arch_timer support in GTDT table parse driver
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 05/10] acpi: Add arch_timer support in GTDT table parse driver
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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
-- 
2.5.5

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

* [PATCH v6 05/10] acpi: Add arch_timer support in GTDT table parse driver
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 06/10] acpi: Add GTDT driver to kernel build system
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 06/10] acpi: Add GTDT driver to kernel build system
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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
-- 
2.5.5

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

* [PATCH v6 06/10] acpi: Add GTDT driver to kernel build system
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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
-- 
2.5.5

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

* [PATCH v6 07/10] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
  2016-06-29 18:15 ` fu.wei
@ 2016-06-29 18:15   ` fu.wei at linaro.org
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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);
-- 
2.5.5

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

* [PATCH v6 07/10] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
@ 2016-06-29 18:15   ` fu.wei at linaro.org
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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);
-- 
2.5.5

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

* [PATCH v6 08/10] acpi: Add memory-mapped timer support in GTDT driver
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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 */
-- 
2.5.5

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

* [PATCH v6 08/10] acpi: Add memory-mapped timer support in GTDT driver
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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 */
-- 
2.5.5

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

* [PATCH v6 08/10] acpi: Add memory-mapped timer support in GTDT driver
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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 */
-- 
2.5.5

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

* [PATCH v6 09/10] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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 = &gt_block->timer[i];
+			arch_timer_mem_use_virtual = true;
+			break;
+		}
+
+		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
+			continue;
+
+		best_frame = &gt_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;
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

* [PATCH v6 09/10] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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 = &gt_block->timer[i];
+			arch_timer_mem_use_virtual = true;
+			break;
+		}
+
+		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
+			continue;
+
+		best_frame = &gt_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;
-- 
2.5.5

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

* [PATCH v6 09/10] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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 = &gt_block->timer[i];
+			arch_timer_mem_use_virtual = true;
+			break;
+		}
+
+		if (~cntacr & (CNTACR_RWPT | CNTACR_RPCT))
+			continue;
+
+		best_frame = &gt_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;
-- 
2.5.5

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

* [PATCH v6 10/10] acpi: Add SBSA Generic Watchdog support in GTDT driver
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 18:15   ` fu.wei
  -1 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: wei, harba, Fu Wei, al.stone, graeme.gregory, linaro-acpi, jcm,
	timur, will.deacon, rruigrok, linux-kernel, linux-acpi, wim,
	arnd, cov, Suravee.Suthikulpanit, catalin.marinas, leo.duran,
	linux-arm-kernel

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,
-- 
2.5.5


_______________________________________________
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] 124+ messages in thread

* [PATCH v6 10/10] acpi: Add SBSA Generic Watchdog support in GTDT driver
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei @ 2016-06-29 18:15 UTC (permalink / raw)
  To: rjw, lenb, daniel.lezcano, tglx, marc.zyngier, hanjun.guo
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran, Fu Wei

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,
-- 
2.5.5

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

* [PATCH v6 10/10] acpi: Add SBSA Generic Watchdog support in GTDT driver
@ 2016-06-29 18:15   ` fu.wei
  0 siblings, 0 replies; 124+ messages in thread
From: fu.wei at linaro.org @ 2016-06-29 18:15 UTC (permalink / raw)
  To: linux-arm-kernel

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,
-- 
2.5.5

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
  2016-06-29 18:15   ` fu.wei at linaro.org
  (?)
@ 2016-06-29 21:24     ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-29 21:24 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee

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

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-29 21:24     ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-29 21:24 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-29 21:24     ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-29 21:24 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-29 18:15 ` fu.wei
  (?)
@ 2016-06-29 21:32   ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-29 21:32 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-29 21:32   ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-29 21:32 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-29 21:32   ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-29 21:32 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
  2016-06-29 21:24     ` Rafael J. Wysocki
  (?)
@ 2016-06-30  1:17       ` Fu Wei
  -1 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:17 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linaro-acpi, Catalin Marinas, Will Deacon, rruigrok,
	Wim Van Sebroeck, wei, Al Stone, Timur Tabi, Daniel Lezcano,
	ACPI Devel Maling List, Len Brown, harba, Arnd Bergmann,
	Marc Zyngier, Jon Masters, Christopher Covington,
	Thomas Gleixner, linux-arm-kernel, G Gregory, Rafael J. Wysocki,
	Linux Kernel Mailing List, Leo Duran, Hanjun Guo

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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  1:17       ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:17 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  1:17       ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:17 UTC (permalink / raw)
  To: linux-arm-kernel

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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
  2016-06-30  1:17       ` Fu Wei
  (?)
@ 2016-06-30  1:26         ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30  1:26 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Catalin Marinas, Will Deacon, rruigrok,
	Wim Van Sebroeck, wei, Al Stone, Timur Tabi, Daniel Lezcano,
	linaro-acpi, ACPI Devel Maling List, Len Brown, harba,
	Arnd Bergmann, Marc Zyngier, Jon Masters, Christopher Covington,
	Thomas Gleixner, linux-arm-kernel, G Gregory,
	Linux Kernel Mailing List, Leo Duran, Hanjun Guo

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

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  1:26         ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30  1:26 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  1:26         ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30  1:26 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-29 21:32   ` Rafael J. Wysocki
  (?)
@ 2016-06-30  1:29     ` Fu Wei
  -1 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee

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 timer
>
> GTDT 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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30  1:29     ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:29 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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 timer
>
> GTDT 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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30  1:29     ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:29 UTC (permalink / raw)
  To: linux-arm-kernel

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 timer
>
> GTDT 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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
  2016-06-30  1:26         ` Rafael J. Wysocki
  (?)
@ 2016-06-30  1:32           ` Fu Wei
  -1 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:32 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee

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
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  1:32           ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:32 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  1:32           ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-06-30  1:32 UTC (permalink / raw)
  To: linux-arm-kernel

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
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-30  1:29     ` Fu Wei
  (?)
@ 2016-06-30  1:37       ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30  1:37 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee

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 timer
> >
> > GTDT 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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30  1:37       ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30  1:37 UTC (permalink / raw)
  To: Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulanit, Leo Duran

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 timer
> >
> > GTDT 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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30  1:37       ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30  1:37 UTC (permalink / raw)
  To: linux-arm-kernel

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 timer
> >
> > GTDT 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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-30  1:37       ` Rafael J. Wysocki
  (?)
@ 2016-06-30  2:10         ` Hanjun Guo
  -1 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30  2:10 UTC (permalink / raw)
  To: Rafael J. Wysocki, Fu Wei, Catalin Marinas, Will Deacon
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran

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 timer
>>>
>>> GTDT 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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30  2:10         ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30  2:10 UTC (permalink / raw)
  To: Rafael J. Wysocki, Fu Wei, Catalin Marinas, Will Deacon
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran

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 timer
>>>
>>> GTDT 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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30  2:10         ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30  2:10 UTC (permalink / raw)
  To: linux-arm-kernel

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 timer
>>>
>>> GTDT 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

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

* Re: [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code
  2016-06-29 18:15   ` fu.wei at linaro.org
@ 2016-06-30  2:54     ` Hanjun Guo
  -1 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30  2:54 UTC (permalink / raw)
  To: fu.wei, rjw, lenb, daniel.lezcano, tglx, marc.zyngier
  Cc: linux-arm-kernel, linaro-acpi, linux-kernel, linux-acpi,
	rruigrok, harba, cov, timur, graeme.gregory, al.stone, jcm, wei,
	arnd, wim, catalin.marinas, will.deacon, Suravee.Suthikulpanit,
	leo.duran

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

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

* [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code
@ 2016-06-30  2:54     ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30  2:54 UTC (permalink / raw)
  To: linux-arm-kernel

On 2016/6/30 2:15, fu.wei at 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

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
  2016-06-30  1:26         ` Rafael J. Wysocki
  (?)
@ 2016-06-30  4:13           ` Timur Tabi
  -1 siblings, 0 replies; 124+ messages in thread
From: Timur Tabi @ 2016-06-30  4:13 UTC (permalink / raw)
  To: Rafael J. Wysocki, Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, G Gregory, Al Stone, Jon Masters,
	wei, Arnd Bergmann, Wim Van Sebroeck, Catalin Marinas,
	Will Deacon, Suravee Suthikulanit

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.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

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

* Re: [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  4:13           ` Timur Tabi
  0 siblings, 0 replies; 124+ messages in thread
From: Timur Tabi @ 2016-06-30  4:13 UTC (permalink / raw)
  To: Rafael J. Wysocki, Fu Wei
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, Hanjun Guo, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, G Gregory, Al Stone, Jon Masters,
	wei, Arnd Bergmann, Wim Van Sebroeck, Catalin Marinas,
	Will Deacon, Suravee Suthikulanit, Leo Duran

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.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

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

* [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver
@ 2016-06-30  4:13           ` Timur Tabi
  0 siblings, 0 replies; 124+ messages in thread
From: Timur Tabi @ 2016-06-30  4:13 UTC (permalink / raw)
  To: linux-arm-kernel

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.

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-30  2:10         ` Hanjun Guo
  (?)
@ 2016-06-30 13:27           ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30 13:27 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Fu Wei, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
	Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee

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 timer
> >>>
> >>> GTDT 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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30 13:27           ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30 13:27 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Fu Wei, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
	Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran

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 timer
> >>>
> >>> GTDT 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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30 13:27           ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-06-30 13:27 UTC (permalink / raw)
  To: linux-arm-kernel

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 timer
> >>>
> >>> GTDT 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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-30 13:27           ` Rafael J. Wysocki
  (?)
@ 2016-06-30 13:48             ` Hanjun Guo
  -1 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30 13:48 UTC (permalink / raw)
  To: Rafael J. Wysocki, Catalin Marinas, Will Deacon
  Cc: Rafael J. Wysocki, rruigrok, Wim Van Sebroeck, Fu Wei, wei,
	Al Stone, Timur Tabi, Daniel Lezcano, linaro-acpi,
	ACPI Devel Maling List, Len Brown, harba, Arnd Bergmann,
	Marc Zyngier, Jon Masters, Christopher Covington,
	Thomas Gleixner, linux-arm-kernel, G Gregory,
	Linux Kernel Mailing List, Leo Duran, Suravee Suthikulanit

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 timer
>>>>>
>>>>> GTDT 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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30 13:48             ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30 13:48 UTC (permalink / raw)
  To: Rafael J. Wysocki, Catalin Marinas, Will Deacon
  Cc: Fu Wei, Rafael J. Wysocki, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran

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 timer
>>>>>
>>>>> GTDT 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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-06-30 13:48             ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-06-30 13:48 UTC (permalink / raw)
  To: linux-arm-kernel

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 timer
>>>>>
>>>>> GTDT 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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-30 13:27           ` Rafael J. Wysocki
  (?)
@ 2016-07-01 14:00             ` Daniel Lezcano
  -1 siblings, 0 replies; 124+ messages in thread
From: Daniel Lezcano @ 2016-07-01 14:00 UTC (permalink / raw)
  To: Rafael J. Wysocki, Hanjun Guo
  Cc: Fu Wei, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
	Len Brown, Thomas Gleixner, Marc Zyngier, linux-arm-kernel,
	linaro-acpi, Linux Kernel Mailing List, ACPI Devel Maling List,
	rruigrok, harba, Christopher Covington, Timur Tabi, G Gregory,
	Al Stone, Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo

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.



-- 
  <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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 14:00             ` Daniel Lezcano
  0 siblings, 0 replies; 124+ messages in thread
From: Daniel Lezcano @ 2016-07-01 14:00 UTC (permalink / raw)
  To: Rafael J. Wysocki, Hanjun Guo
  Cc: Fu Wei, Catalin Marinas, Will Deacon, Rafael J. Wysocki,
	Len Brown, Thomas Gleixner, Marc Zyngier, linux-arm-kernel,
	linaro-acpi, Linux Kernel Mailing List, ACPI Devel Maling List,
	rruigrok, harba, Christopher Covington, Timur Tabi, G Gregory,
	Al Stone, Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran

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.



-- 
  <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] 124+ messages in thread

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 14:00             ` Daniel Lezcano
  0 siblings, 0 replies; 124+ messages in thread
From: Daniel Lezcano @ 2016-07-01 14:00 UTC (permalink / raw)
  To: linux-arm-kernel

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.



-- 
  <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] 124+ messages in thread

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-06-30 13:48             ` Hanjun Guo
  (?)
@ 2016-07-01 15:23               ` Will Deacon
  -1 siblings, 0 replies; 124+ messages in thread
From: Will Deacon @ 2016-07-01 15:23 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Rafael J. Wysocki, Catalin Marinas, Fu Wei, Rafael J. Wysocki,
	Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 15:23               ` Will Deacon
  0 siblings, 0 replies; 124+ messages in thread
From: Will Deacon @ 2016-07-01 15:23 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Rafael J. Wysocki, Catalin Marinas, Fu Wei, Rafael J. Wysocki,
	Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 15:23               ` Will Deacon
  0 siblings, 0 replies; 124+ messages in thread
From: Will Deacon @ 2016-07-01 15:23 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-01 14:00             ` Daniel Lezcano
  (?)
@ 2016-07-01 21:01               ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-01 21:01 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Hanjun Guo, Fu Wei, Catalin Marinas, Will Deacon,
	Rafael J. Wysocki, Len Brown, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit

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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 21:01               ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-01 21:01 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Hanjun Guo, Fu Wei, Catalin Marinas, Will Deacon,
	Rafael J. Wysocki, Len Brown, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 21:01               ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-01 21:01 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-01 15:23               ` Will Deacon
  (?)
@ 2016-07-01 21:04                 ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-01 21:04 UTC (permalink / raw)
  To: Will Deacon
  Cc: Hanjun Guo, Catalin Marinas, Fu Wei, Rafael J. Wysocki,
	Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee

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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 21:04                 ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-01 21:04 UTC (permalink / raw)
  To: Will Deacon
  Cc: Hanjun Guo, Catalin Marinas, Fu Wei, Rafael J. Wysocki,
	Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-01 21:04                 ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-01 21:04 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-01 21:04                 ` Rafael J. Wysocki
  (?)
@ 2016-07-04 12:53                   ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-04 12:53 UTC (permalink / raw)
  To: Will Deacon, Hanjun Guo
  Cc: Catalin Marinas, Fu Wei, Rafael J. Wysocki, Len Brown,
	Daniel Lezcano, Thomas Gleixner, Marc Zyngier, linux-arm-kernel,
	linaro-acpi, Linux Kernel Mailing List, ACPI Devel Maling List,
	rruigrok, harba, Christopher Covington, Timur Tabi, G Gregory,
	Al Stone, Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-04 12:53                   ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-04 12:53 UTC (permalink / raw)
  To: Will Deacon, Hanjun Guo
  Cc: Catalin Marinas, Fu Wei, Rafael J. Wysocki, Len Brown,
	Daniel Lezcano, Thomas Gleixner, Marc Zyngier, linux-arm-kernel,
	linaro-acpi, Linux Kernel Mailing List, ACPI Devel Maling List,
	rruigrok, harba, Christopher Covington, Timur Tabi, G Gregory,
	Al Stone, Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-04 12:53                   ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-04 12:53 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-01 21:01               ` Rafael J. Wysocki
  (?)
@ 2016-07-04 13:43                 ` Daniel Lezcano
  -1 siblings, 0 replies; 124+ messages in thread
From: Daniel Lezcano @ 2016-07-04 13:43 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Hanjun Guo, Fu Wei, Catalin Marinas, Will Deacon,
	Rafael J. Wysocki, Len Brown, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit

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.



-- 
 <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] 124+ messages in thread

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-04 13:43                 ` Daniel Lezcano
  0 siblings, 0 replies; 124+ messages in thread
From: Daniel Lezcano @ 2016-07-04 13:43 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Hanjun Guo, Fu Wei, Catalin Marinas, Will Deacon,
	Rafael J. Wysocki, Len Brown, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran

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.



-- 
 <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] 124+ messages in thread

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-04 13:43                 ` Daniel Lezcano
  0 siblings, 0 replies; 124+ messages in thread
From: Daniel Lezcano @ 2016-07-04 13:43 UTC (permalink / raw)
  To: linux-arm-kernel

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.



-- 
 <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] 124+ messages in thread

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-04 13:43                 ` Daniel Lezcano
  (?)
@ 2016-07-04 14:19                   ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-04 14:19 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Rafael J. Wysocki, Hanjun Guo, Fu Wei, Catalin Marinas,
	Will Deacon, Rafael J. Wysocki, Len Brown, Thomas Gleixner,
	Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-04 14:19                   ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-04 14:19 UTC (permalink / raw)
  To: Daniel Lezcano
  Cc: Rafael J. Wysocki, Hanjun Guo, Fu Wei, Catalin Marinas,
	Will Deacon, Rafael J. Wysocki, Len Brown, Thomas Gleixner,
	Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-04 14:19                   ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-04 14:19 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-04 12:53                   ` Rafael J. Wysocki
  (?)
@ 2016-07-05 14:18                     ` Graeme Gregory
  -1 siblings, 0 replies; 124+ messages in thread
From: Graeme Gregory @ 2016-07-05 14:18 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Will Deacon, Hanjun Guo, Catalin Marinas, Fu Wei, Len Brown,
	Daniel Lezcano, Thomas Gleixner, Marc Zyngier, linux-arm-kernel,
	linaro-acpi, Linux Kernel Mailing List, ACPI Devel Maling List,
	rruigrok, harba, Christopher Covington, Timur Tabi, G Gregory,
	Al Stone, Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit

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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-05 14:18                     ` Graeme Gregory
  0 siblings, 0 replies; 124+ messages in thread
From: Graeme Gregory @ 2016-07-05 14:18 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Will Deacon, Hanjun Guo, Catalin Marinas, Fu Wei, Len Brown,
	Daniel Lezcano, Thomas Gleixner, Marc Zyngier, linux-arm-kernel,
	linaro-acpi, Linux Kernel Mailing List, ACPI Devel Maling List,
	rruigrok, harba, Christopher Covington, Timur Tabi, G Gregory,
	Al Stone, Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, steve.capper, leif.lindholm

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-05 14:18                     ` Graeme Gregory
  0 siblings, 0 replies; 124+ messages in thread
From: Graeme Gregory @ 2016-07-05 14:18 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-05 14:18                     ` Graeme Gregory
  (?)
@ 2016-07-06  0:00                       ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-06  0:00 UTC (permalink / raw)
  To: Graeme Gregory
  Cc: Rafael J. Wysocki, Will Deacon, Hanjun Guo, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-06  0:00                       ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-06  0:00 UTC (permalink / raw)
  To: Graeme Gregory
  Cc: Rafael J. Wysocki, Will Deacon, Hanjun Guo, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran, Steve Capper,
	Leif Lindholm

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-06  0:00                       ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-06  0:00 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-06  0:00                       ` Rafael J. Wysocki
  (?)
@ 2016-07-07 11:12                         ` Hanjun Guo
  -1 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-07 11:12 UTC (permalink / raw)
  To: Rafael J. Wysocki, Graeme Gregory
  Cc: Will Deacon, Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 11:12                         ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-07 11:12 UTC (permalink / raw)
  To: Rafael J. Wysocki, Graeme Gregory
  Cc: Will Deacon, Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 11:12                         ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-07 11:12 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-07 11:12                         ` Hanjun Guo
  (?)
@ 2016-07-07 12:03                           ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-07 12:03 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Rafael J. Wysocki, Graeme Gregory, Will Deacon, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim

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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 12:03                           ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-07 12:03 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Rafael J. Wysocki, Graeme Gregory, Will Deacon, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran, Steve Capper,
	Leif Lindholm

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 12:03                           ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-07 12:03 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-07 12:03                           ` Rafael J. Wysocki
  (?)
@ 2016-07-07 13:40                             ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 124+ messages in thread
From: Lorenzo Pieralisi @ 2016-07-07 13:40 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Hanjun Guo, Rafael J. Wysocki, Graeme Gregory, Will Deacon,
	Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd

[+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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 13:40                             ` Lorenzo Pieralisi
  0 siblings, 0 replies; 124+ messages in thread
From: Lorenzo Pieralisi @ 2016-07-07 13:40 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Hanjun Guo, Rafael J. Wysocki, Graeme Gregory, Will Deacon,
	Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm,
	sudeep.holla

[+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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 13:40                             ` Lorenzo Pieralisi
  0 siblings, 0 replies; 124+ messages in thread
From: Lorenzo Pieralisi @ 2016-07-07 13:40 UTC (permalink / raw)
  To: linux-arm-kernel

[+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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-07 13:40                             ` Lorenzo Pieralisi
  (?)
@ 2016-07-07 13:58                               ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-07 13:58 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Hanjun Guo, Rafael J. Wysocki, Graeme Gregory, Will Deacon,
	Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd

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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 13:58                               ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-07 13:58 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Hanjun Guo, Rafael J. Wysocki, Graeme Gregory, Will Deacon,
	Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm,
	sudeep.holla

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 13:58                               ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-07 13:58 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-07 13:58                               ` Rafael J. Wysocki
  (?)
@ 2016-07-07 15:21                                 ` Fu Wei
  -1 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-07-07 15:21 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Graeme Gregory,
	Will Deacon, Catalin Marinas, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei

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
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 15:21                                 ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-07-07 15:21 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Graeme Gregory,
	Will Deacon, Catalin Marinas, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm,
	sudeep.holla

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
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-07 15:21                                 ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-07-07 15:21 UTC (permalink / raw)
  To: linux-arm-kernel

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
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code
  2016-06-30  2:54     ` Hanjun Guo
@ 2016-07-07 16:12       ` Fu Wei
  -1 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-07-07 16:12 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Rafael J. Wysocki, Len Brown, Daniel Lezcano, Thomas Gleixner,
	Marc Zyngier, linux-arm-kernel, Linaro ACPI Mailman List,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Catalin Marinas, Will Deacon, Suravee Suthikulpanit, Leo Duran

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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code
@ 2016-07-07 16:12       ` Fu Wei
  0 siblings, 0 replies; 124+ messages in thread
From: Fu Wei @ 2016-07-07 16:12 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Hanjun

On 30 June 2016 at 10:54, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> On 2016/6/30 2:15, fu.wei at 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



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-07 13:58                               ` Rafael J. Wysocki
  (?)
@ 2016-07-08 13:22                                 ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 124+ messages in thread
From: Lorenzo Pieralisi @ 2016-07-08 13:22 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Hanjun Guo, Rafael J. Wysocki, Graeme Gregory, Will Deacon,
	Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-08 13:22                                 ` Lorenzo Pieralisi
  0 siblings, 0 replies; 124+ messages in thread
From: Lorenzo Pieralisi @ 2016-07-08 13:22 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Hanjun Guo, Rafael J. Wysocki, Graeme Gregory, Will Deacon,
	Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm,
	sudeep.holla

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-08 13:22                                 ` Lorenzo Pieralisi
  0 siblings, 0 replies; 124+ messages in thread
From: Lorenzo Pieralisi @ 2016-07-08 13:22 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-08 13:22                                 ` Lorenzo Pieralisi
  (?)
@ 2016-07-08 13:50                                   ` Sudeep Holla
  -1 siblings, 0 replies; 124+ messages in thread
From: Sudeep Holla @ 2016-07-08 13:50 UTC (permalink / raw)
  To: Lorenzo Pieralisi, Rafael J. Wysocki
  Cc: Sudeep Holla, Hanjun Guo, Rafael J. Wysocki, Graeme Gregory,
	Will Deacon, Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters



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.

-- 
Regards,
Sudeep

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-08 13:50                                   ` Sudeep Holla
  0 siblings, 0 replies; 124+ messages in thread
From: Sudeep Holla @ 2016-07-08 13:50 UTC (permalink / raw)
  To: Lorenzo Pieralisi, Rafael J. Wysocki
  Cc: Sudeep Holla, Hanjun Guo, Rafael J. Wysocki, Graeme Gregory,
	Will Deacon, Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm



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.

-- 
Regards,
Sudeep

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-08 13:50                                   ` Sudeep Holla
  0 siblings, 0 replies; 124+ messages in thread
From: Sudeep Holla @ 2016-07-08 13:50 UTC (permalink / raw)
  To: linux-arm-kernel



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.

-- 
Regards,
Sudeep

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-07 13:58                               ` Rafael J. Wysocki
  (?)
@ 2016-07-09  3:00                                 ` Hanjun Guo
  -1 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-09  3:00 UTC (permalink / raw)
  To: Rafael J. Wysocki, Lorenzo Pieralisi
  Cc: Rafael J. Wysocki, Graeme Gregory, Will Deacon, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-09  3:00                                 ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-09  3:00 UTC (permalink / raw)
  To: Rafael J. Wysocki, Lorenzo Pieralisi
  Cc: Rafael J. Wysocki, Graeme Gregory, Will Deacon, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran, Steve Capper,
	Leif Lindholm, sudeep.holla

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-09  3:00                                 ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-09  3:00 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-08 13:22                                 ` Lorenzo Pieralisi
  (?)
@ 2016-07-09  3:44                                   ` Hanjun Guo
  -1 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-09  3:44 UTC (permalink / raw)
  To: Lorenzo Pieralisi, Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Graeme Gregory, Will Deacon, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim

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-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-09  3:44                                   ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-09  3:44 UTC (permalink / raw)
  To: Lorenzo Pieralisi, Rafael J. Wysocki
  Cc: Rafael J. Wysocki, Graeme Gregory, Will Deacon, Catalin Marinas,
	Fu Wei, Len Brown, Daniel Lezcano, Thomas Gleixner, Marc Zyngier,
	linux-arm-kernel, linaro-acpi, Linux Kernel Mailing List,
	ACPI Devel Maling List, rruigrok, harba, Christopher Covington,
	Timur Tabi, G Gregory, Al Stone, Jon Masters, wei, Arnd Bergmann,
	Wim Van Sebroeck, Suravee Suthikulanit, Leo Duran, Steve Capper,
	Leif Lindholm, sudeep.holla

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-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-09  3:44                                   ` Hanjun Guo
  0 siblings, 0 replies; 124+ messages in thread
From: Hanjun Guo @ 2016-07-09  3:44 UTC (permalink / raw)
  To: linux-arm-kernel

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-gtdt-wakeup-timer_upstream_v7_devel

Thanks
Hanjun

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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
  2016-07-09  3:44                                   ` Hanjun Guo
  (?)
@ 2016-07-10  1:26                                     ` Rafael J. Wysocki
  -1 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-10  1:26 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Lorenzo Pieralisi, Rafael J. Wysocki, Graeme Gregory,
	Will Deacon, Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei

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


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

* Re: [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-10  1:26                                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-10  1:26 UTC (permalink / raw)
  To: Hanjun Guo
  Cc: Lorenzo Pieralisi, Rafael J. Wysocki, Graeme Gregory,
	Will Deacon, Catalin Marinas, Fu Wei, Len Brown, Daniel Lezcano,
	Thomas Gleixner, Marc Zyngier, linux-arm-kernel, linaro-acpi,
	Linux Kernel Mailing List, ACPI Devel Maling List, rruigrok,
	harba, Christopher Covington, Timur Tabi, G Gregory, Al Stone,
	Jon Masters, wei, Arnd Bergmann, Wim Van Sebroeck,
	Suravee Suthikulanit, Leo Duran, Steve Capper, Leif Lindholm,
	sudeep.holla

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

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

* [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer
@ 2016-07-10  1:26                                     ` Rafael J. Wysocki
  0 siblings, 0 replies; 124+ messages in thread
From: Rafael J. Wysocki @ 2016-07-10  1:26 UTC (permalink / raw)
  To: linux-arm-kernel

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

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

end of thread, other threads:[~2016-07-10  1:26 UTC | newest]

Thread overview: 124+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-29 18:15 [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei
2016-06-29 18:15 ` fu.wei at linaro.org
2016-06-29 18:15 ` fu.wei
2016-06-29 18:15 ` [PATCH v6 01/10] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 18:15 ` [PATCH v6 02/10] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 18:15 ` [PATCH v6 03/10] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-30  2:54   ` Hanjun Guo
2016-06-30  2:54     ` Hanjun Guo
2016-07-07 16:12     ` Fu Wei
2016-07-07 16:12       ` Fu Wei
2016-06-29 18:15 ` [PATCH v6 04/10] acpi: Add some basic struct and functions in GTDT driver fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 21:24   ` Rafael J. Wysocki
2016-06-29 21:24     ` Rafael J. Wysocki
2016-06-29 21:24     ` Rafael J. Wysocki
2016-06-30  1:17     ` Fu Wei
2016-06-30  1:17       ` Fu Wei
2016-06-30  1:17       ` Fu Wei
2016-06-30  1:26       ` Rafael J. Wysocki
2016-06-30  1:26         ` Rafael J. Wysocki
2016-06-30  1:26         ` Rafael J. Wysocki
2016-06-30  1:32         ` Fu Wei
2016-06-30  1:32           ` Fu Wei
2016-06-30  1:32           ` Fu Wei
2016-06-30  4:13         ` Timur Tabi
2016-06-30  4:13           ` Timur Tabi
2016-06-30  4:13           ` Timur Tabi
2016-06-29 18:15 ` [PATCH v6 05/10] acpi: Add arch_timer support in GTDT table parse driver fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 18:15 ` [PATCH v6 06/10] acpi: Add GTDT driver to kernel build system fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 18:15 ` [PATCH v6 07/10] clocksource/drivers/arm_arch_timer: Simplify ACPI support code fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15 ` [PATCH v6 08/10] acpi: Add memory-mapped timer support in GTDT driver fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 18:15 ` [PATCH v6 09/10] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 18:15 ` [PATCH v6 10/10] acpi: Add SBSA Generic Watchdog support in GTDT driver fu.wei
2016-06-29 18:15   ` fu.wei at linaro.org
2016-06-29 18:15   ` fu.wei
2016-06-29 21:32 ` [PATCH v6 00/10] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer Rafael J. Wysocki
2016-06-29 21:32   ` Rafael J. Wysocki
2016-06-29 21:32   ` Rafael J. Wysocki
2016-06-30  1:29   ` Fu Wei
2016-06-30  1:29     ` Fu Wei
2016-06-30  1:29     ` Fu Wei
2016-06-30  1:37     ` Rafael J. Wysocki
2016-06-30  1:37       ` Rafael J. Wysocki
2016-06-30  1:37       ` Rafael J. Wysocki
2016-06-30  2:10       ` Hanjun Guo
2016-06-30  2:10         ` Hanjun Guo
2016-06-30  2:10         ` Hanjun Guo
2016-06-30 13:27         ` Rafael J. Wysocki
2016-06-30 13:27           ` Rafael J. Wysocki
2016-06-30 13:27           ` Rafael J. Wysocki
2016-06-30 13:48           ` Hanjun Guo
2016-06-30 13:48             ` Hanjun Guo
2016-06-30 13:48             ` Hanjun Guo
2016-07-01 15:23             ` Will Deacon
2016-07-01 15:23               ` Will Deacon
2016-07-01 15:23               ` Will Deacon
2016-07-01 21:04               ` Rafael J. Wysocki
2016-07-01 21:04                 ` Rafael J. Wysocki
2016-07-01 21:04                 ` Rafael J. Wysocki
2016-07-04 12:53                 ` Rafael J. Wysocki
2016-07-04 12:53                   ` Rafael J. Wysocki
2016-07-04 12:53                   ` Rafael J. Wysocki
2016-07-05 14:18                   ` Graeme Gregory
2016-07-05 14:18                     ` Graeme Gregory
2016-07-05 14:18                     ` Graeme Gregory
2016-07-06  0:00                     ` Rafael J. Wysocki
2016-07-06  0:00                       ` Rafael J. Wysocki
2016-07-06  0:00                       ` Rafael J. Wysocki
2016-07-07 11:12                       ` Hanjun Guo
2016-07-07 11:12                         ` Hanjun Guo
2016-07-07 11:12                         ` Hanjun Guo
2016-07-07 12:03                         ` Rafael J. Wysocki
2016-07-07 12:03                           ` Rafael J. Wysocki
2016-07-07 12:03                           ` Rafael J. Wysocki
2016-07-07 13:40                           ` Lorenzo Pieralisi
2016-07-07 13:40                             ` Lorenzo Pieralisi
2016-07-07 13:40                             ` Lorenzo Pieralisi
2016-07-07 13:58                             ` Rafael J. Wysocki
2016-07-07 13:58                               ` Rafael J. Wysocki
2016-07-07 13:58                               ` Rafael J. Wysocki
2016-07-07 15:21                               ` Fu Wei
2016-07-07 15:21                                 ` Fu Wei
2016-07-07 15:21                                 ` Fu Wei
2016-07-08 13:22                               ` Lorenzo Pieralisi
2016-07-08 13:22                                 ` Lorenzo Pieralisi
2016-07-08 13:22                                 ` Lorenzo Pieralisi
2016-07-08 13:50                                 ` Sudeep Holla
2016-07-08 13:50                                   ` Sudeep Holla
2016-07-08 13:50                                   ` Sudeep Holla
2016-07-09  3:44                                 ` Hanjun Guo
2016-07-09  3:44                                   ` Hanjun Guo
2016-07-09  3:44                                   ` Hanjun Guo
2016-07-10  1:26                                   ` Rafael J. Wysocki
2016-07-10  1:26                                     ` Rafael J. Wysocki
2016-07-10  1:26                                     ` Rafael J. Wysocki
2016-07-09  3:00                               ` Hanjun Guo
2016-07-09  3:00                                 ` Hanjun Guo
2016-07-09  3:00                                 ` Hanjun Guo
2016-07-01 14:00           ` Daniel Lezcano
2016-07-01 14:00             ` Daniel Lezcano
2016-07-01 14:00             ` Daniel Lezcano
2016-07-01 21:01             ` Rafael J. Wysocki
2016-07-01 21:01               ` Rafael J. Wysocki
2016-07-01 21:01               ` Rafael J. Wysocki
2016-07-04 13:43               ` Daniel Lezcano
2016-07-04 13:43                 ` Daniel Lezcano
2016-07-04 13:43                 ` Daniel Lezcano
2016-07-04 14:19                 ` Rafael J. Wysocki
2016-07-04 14:19                   ` Rafael J. Wysocki
2016-07-04 14:19                   ` Rafael J. Wysocki

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.