From: Hanjun Guo <hanjun.guo@linaro.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Olof Johansson <olof@lixom.net>,
Linus Walleij <linus.walleij@linaro.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
Jon Masters <jonathan@jonmasters.org>,
"patches@linaro.org" <patches@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro>
Subject: Re: [RFC part3 PATCH 1/2] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer
Date: Wed, 04 Dec 2013 22:25:16 +0800 [thread overview]
Message-ID: <529F3B4C.1080400@linaro.org> (raw)
In-Reply-To: <20131203170407.GA16025@e106331-lin.cambridge.arm.com>
On 2013年12月04日 01:04, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:41:30PM +0000, Hanjun Guo wrote:
>> ACPI GTDT (Generic Timer Description Table) contains information for
>> arch timer initialization, this patch use this table to probe arm timer.
>>
>> GTDT table is used for ARM/ARM64 only, please refer to chapter 5.2.24
>> of ACPI 5.0 spec for detailed inforamtion
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 129 ++++++++++++++++++++++++++++++----
>> include/clocksource/arm_arch_timer.h | 7 +-
>> 2 files changed, 120 insertions(+), 16 deletions(-)
>
> [...]
>
>> +#ifdef CONFIG_ACPI
>> +void __init arch_timer_acpi_init(void)
>> +{
>> + struct acpi_table_gtdt *gtdt;
>> + acpi_size tbl_size;
>> + int trigger, polarity;
>> + void __iomem *base = NULL;
>> +
>> + if (acpi_disabled)
>> + return;
>> +
>> + if (arch_timers_present & ARCH_CP15_TIMER) {
>> + pr_warn("arch_timer: already initialized, skipping\n");
>> + return;
>> + }
>> +
>> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_GTDT, 0,
>> + (struct acpi_table_header **)>dt, &tbl_size))) {
>> + pr_err("arch_timer: GTDT table not defined\n");
>> + return;
>> + }
>> +
>> + arch_timers_present |= ARCH_CP15_TIMER;
>> +
>> + /*
>> + * Get the timer frequency. Since there is no frequency info
>> + * in the GTDT table, so we should read it from CNTFREG register
>> + * or hard code here to wait for the new ACPI spec available.
>> + */
> If the core's CNTFRQ register does not hold the correct value, that is a
> horrendous firmware bug. The clock-frequency property in the DT is a
> horrific workaround for buggy firmware.
>
> We should not duplicate it in ACPI; people should be strongly encouraged
> to fix their firmware to do what it is supposed to do.
>
> Rely on CNTFRQ only. If it is wrong, then bail out. Let's not create a
> fertile environment for buggy firmware.
Great, this can make things much simple, and the information which contains
in ACPI GTDT table can be sufficient for timer initialization.
>> + if (!gtdt->address) {
>> + arch_timer_rate = arch_timer_get_cntfrq();
>> + } else {
>> + base = ioremap(gtdt->address, CNTFRQ);
>> + if (!base) {
>> + pr_warn("arch_timer: unable to map arch timer base address\n");
>> + return;
>> + }
>> +
>> + arch_timer_rate = readl_relaxed(base + CNTFRQ);
>> + iounmap(base);
>> + }
>> +
>> + if (!arch_timer_rate) {
>> + /* Hard code here to set frequence ? */
>> + pr_warn("arch_timer: Could not get frequency from GTDT table or CNTFREG\n");
>> + }
>> +
>> + if (gtdt->secure_pl1_interrupt) {
>> + trigger = (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE) ?
>> + ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[0] = acpi_register_gsi(NULL,
>> + gtdt->secure_pl1_interrupt, trigger, polarity);
>> + }
> This pattern looks like it can be factored out. I don't see why the
> driver needs to have such intimate knowledge of the interrrupt.
>
>> + if (gtdt->non_secure_pl1_interrupt) {
>> + trigger =
>> + (gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[1] = acpi_register_gsi(NULL,
>> + gtdt->non_secure_pl1_interrupt, trigger, polarity);
>> + }
>> + if (gtdt->virtual_timer_interrupt) {
>> + trigger = (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[2] = acpi_register_gsi(NULL,
>> + gtdt->virtual_timer_interrupt, trigger, polarity);
>> + }
>> + if (gtdt->non_secure_pl2_interrupt) {
>> + trigger =
>> + (gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[3] = acpi_register_gsi(NULL,
>> + gtdt->non_secure_pl2_interrupt, trigger, polarity);
>> + }
> Please factor out the interrupt parsing.
Ok, will try to factor it out in next version.
Thanks for the comments.
Hanjun
--
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
WARNING: multiple messages have this Message-ID (diff)
From: hanjun.guo@linaro.org (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC part3 PATCH 1/2] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer
Date: Wed, 04 Dec 2013 22:25:16 +0800 [thread overview]
Message-ID: <529F3B4C.1080400@linaro.org> (raw)
In-Reply-To: <20131203170407.GA16025@e106331-lin.cambridge.arm.com>
On 2013?12?04? 01:04, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:41:30PM +0000, Hanjun Guo wrote:
>> ACPI GTDT (Generic Timer Description Table) contains information for
>> arch timer initialization, this patch use this table to probe arm timer.
>>
>> GTDT table is used for ARM/ARM64 only, please refer to chapter 5.2.24
>> of ACPI 5.0 spec for detailed inforamtion
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 129 ++++++++++++++++++++++++++++++----
>> include/clocksource/arm_arch_timer.h | 7 +-
>> 2 files changed, 120 insertions(+), 16 deletions(-)
>
> [...]
>
>> +#ifdef CONFIG_ACPI
>> +void __init arch_timer_acpi_init(void)
>> +{
>> + struct acpi_table_gtdt *gtdt;
>> + acpi_size tbl_size;
>> + int trigger, polarity;
>> + void __iomem *base = NULL;
>> +
>> + if (acpi_disabled)
>> + return;
>> +
>> + if (arch_timers_present & ARCH_CP15_TIMER) {
>> + pr_warn("arch_timer: already initialized, skipping\n");
>> + return;
>> + }
>> +
>> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_GTDT, 0,
>> + (struct acpi_table_header **)>dt, &tbl_size))) {
>> + pr_err("arch_timer: GTDT table not defined\n");
>> + return;
>> + }
>> +
>> + arch_timers_present |= ARCH_CP15_TIMER;
>> +
>> + /*
>> + * Get the timer frequency. Since there is no frequency info
>> + * in the GTDT table, so we should read it from CNTFREG register
>> + * or hard code here to wait for the new ACPI spec available.
>> + */
> If the core's CNTFRQ register does not hold the correct value, that is a
> horrendous firmware bug. The clock-frequency property in the DT is a
> horrific workaround for buggy firmware.
>
> We should not duplicate it in ACPI; people should be strongly encouraged
> to fix their firmware to do what it is supposed to do.
>
> Rely on CNTFRQ only. If it is wrong, then bail out. Let's not create a
> fertile environment for buggy firmware.
Great, this can make things much simple, and the information which contains
in ACPI GTDT table can be sufficient for timer initialization.
>> + if (!gtdt->address) {
>> + arch_timer_rate = arch_timer_get_cntfrq();
>> + } else {
>> + base = ioremap(gtdt->address, CNTFRQ);
>> + if (!base) {
>> + pr_warn("arch_timer: unable to map arch timer base address\n");
>> + return;
>> + }
>> +
>> + arch_timer_rate = readl_relaxed(base + CNTFRQ);
>> + iounmap(base);
>> + }
>> +
>> + if (!arch_timer_rate) {
>> + /* Hard code here to set frequence ? */
>> + pr_warn("arch_timer: Could not get frequency from GTDT table or CNTFREG\n");
>> + }
>> +
>> + if (gtdt->secure_pl1_interrupt) {
>> + trigger = (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE) ?
>> + ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[0] = acpi_register_gsi(NULL,
>> + gtdt->secure_pl1_interrupt, trigger, polarity);
>> + }
> This pattern looks like it can be factored out. I don't see why the
> driver needs to have such intimate knowledge of the interrrupt.
>
>> + if (gtdt->non_secure_pl1_interrupt) {
>> + trigger =
>> + (gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[1] = acpi_register_gsi(NULL,
>> + gtdt->non_secure_pl1_interrupt, trigger, polarity);
>> + }
>> + if (gtdt->virtual_timer_interrupt) {
>> + trigger = (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[2] = acpi_register_gsi(NULL,
>> + gtdt->virtual_timer_interrupt, trigger, polarity);
>> + }
>> + if (gtdt->non_secure_pl2_interrupt) {
>> + trigger =
>> + (gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[3] = acpi_register_gsi(NULL,
>> + gtdt->non_secure_pl2_interrupt, trigger, polarity);
>> + }
> Please factor out the interrupt parsing.
Ok, will try to factor it out in next version.
Thanks for the comments.
Hanjun
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <hanjun.guo@linaro.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Olof Johansson <olof@lixom.net>,
Linus Walleij <linus.walleij@linaro.org>,
Bjorn Helgaas <bhelgaas@google.com>,
"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
Jon Masters <jonathan@jonmasters.org>,
"patches@linaro.org" <patches@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-kernel@lists.linaro.org" <linaro-kernel@lists.linaro.org>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
Amit Daniel Kachhap <amit.daniel@samsung.com>
Subject: Re: [RFC part3 PATCH 1/2] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer
Date: Wed, 04 Dec 2013 22:25:16 +0800 [thread overview]
Message-ID: <529F3B4C.1080400@linaro.org> (raw)
In-Reply-To: <20131203170407.GA16025@e106331-lin.cambridge.arm.com>
On 2013年12月04日 01:04, Mark Rutland wrote:
> On Tue, Dec 03, 2013 at 04:41:30PM +0000, Hanjun Guo wrote:
>> ACPI GTDT (Generic Timer Description Table) contains information for
>> arch timer initialization, this patch use this table to probe arm timer.
>>
>> GTDT table is used for ARM/ARM64 only, please refer to chapter 5.2.24
>> of ACPI 5.0 spec for detailed inforamtion
>>
>> Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 129 ++++++++++++++++++++++++++++++----
>> include/clocksource/arm_arch_timer.h | 7 +-
>> 2 files changed, 120 insertions(+), 16 deletions(-)
>
> [...]
>
>> +#ifdef CONFIG_ACPI
>> +void __init arch_timer_acpi_init(void)
>> +{
>> + struct acpi_table_gtdt *gtdt;
>> + acpi_size tbl_size;
>> + int trigger, polarity;
>> + void __iomem *base = NULL;
>> +
>> + if (acpi_disabled)
>> + return;
>> +
>> + if (arch_timers_present & ARCH_CP15_TIMER) {
>> + pr_warn("arch_timer: already initialized, skipping\n");
>> + return;
>> + }
>> +
>> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_GTDT, 0,
>> + (struct acpi_table_header **)>dt, &tbl_size))) {
>> + pr_err("arch_timer: GTDT table not defined\n");
>> + return;
>> + }
>> +
>> + arch_timers_present |= ARCH_CP15_TIMER;
>> +
>> + /*
>> + * Get the timer frequency. Since there is no frequency info
>> + * in the GTDT table, so we should read it from CNTFREG register
>> + * or hard code here to wait for the new ACPI spec available.
>> + */
> If the core's CNTFRQ register does not hold the correct value, that is a
> horrendous firmware bug. The clock-frequency property in the DT is a
> horrific workaround for buggy firmware.
>
> We should not duplicate it in ACPI; people should be strongly encouraged
> to fix their firmware to do what it is supposed to do.
>
> Rely on CNTFRQ only. If it is wrong, then bail out. Let's not create a
> fertile environment for buggy firmware.
Great, this can make things much simple, and the information which contains
in ACPI GTDT table can be sufficient for timer initialization.
>> + if (!gtdt->address) {
>> + arch_timer_rate = arch_timer_get_cntfrq();
>> + } else {
>> + base = ioremap(gtdt->address, CNTFRQ);
>> + if (!base) {
>> + pr_warn("arch_timer: unable to map arch timer base address\n");
>> + return;
>> + }
>> +
>> + arch_timer_rate = readl_relaxed(base + CNTFRQ);
>> + iounmap(base);
>> + }
>> +
>> + if (!arch_timer_rate) {
>> + /* Hard code here to set frequence ? */
>> + pr_warn("arch_timer: Could not get frequency from GTDT table or CNTFREG\n");
>> + }
>> +
>> + if (gtdt->secure_pl1_interrupt) {
>> + trigger = (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE) ?
>> + ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[0] = acpi_register_gsi(NULL,
>> + gtdt->secure_pl1_interrupt, trigger, polarity);
>> + }
> This pattern looks like it can be factored out. I don't see why the
> driver needs to have such intimate knowledge of the interrrupt.
>
>> + if (gtdt->non_secure_pl1_interrupt) {
>> + trigger =
>> + (gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->non_secure_pl1_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[1] = acpi_register_gsi(NULL,
>> + gtdt->non_secure_pl1_interrupt, trigger, polarity);
>> + }
>> + if (gtdt->virtual_timer_interrupt) {
>> + trigger = (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->virtual_timer_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[2] = acpi_register_gsi(NULL,
>> + gtdt->virtual_timer_interrupt, trigger, polarity);
>> + }
>> + if (gtdt->non_secure_pl2_interrupt) {
>> + trigger =
>> + (gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_MODE)
>> + ? ACPI_EDGE_SENSITIVE : ACPI_LEVEL_SENSITIVE;
>> + polarity =
>> + (gtdt->non_secure_pl2_flags & ACPI_GTDT_INTERRUPT_POLARITY)
>> + ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>> + arch_timer_ppi[3] = acpi_register_gsi(NULL,
>> + gtdt->non_secure_pl2_interrupt, trigger, polarity);
>> + }
> Please factor out the interrupt parsing.
Ok, will try to factor it out in next version.
Thanks for the comments.
Hanjun
next prev parent reply other threads:[~2013-12-04 14:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-03 16:41 [RFC part3 PATCH 0/2] Using ACPI GTDT table to initialize arch timer Hanjun Guo
2013-12-03 16:41 ` Hanjun Guo
2013-12-03 16:41 ` [RFC part3 PATCH 1/2] clocksource / arch_timer: Use " Hanjun Guo
2013-12-03 16:41 ` Hanjun Guo
2013-12-03 17:04 ` Mark Rutland
2013-12-03 17:04 ` Mark Rutland
2013-12-03 17:04 ` Mark Rutland
2013-12-04 14:25 ` Hanjun Guo [this message]
2013-12-04 14:25 ` Hanjun Guo
2013-12-04 14:25 ` Hanjun Guo
2013-12-05 3:43 ` Arnd Bergmann
2013-12-05 3:43 ` Arnd Bergmann
2013-12-05 3:43 ` Arnd Bergmann
2013-12-05 13:52 ` Hanjun Guo
2013-12-05 13:52 ` Hanjun Guo
2013-12-05 13:52 ` Hanjun Guo
2013-12-03 16:41 ` [RFC part3 PATCH 2/2] ARM64 / clocksource: Use arch_timer_acpi_init() Hanjun Guo
2013-12-03 16:41 ` Hanjun Guo
2013-12-03 17:08 ` Mark Rutland
2013-12-03 17:08 ` Mark Rutland
2013-12-03 17:08 ` Mark Rutland
2013-12-04 14:27 ` Hanjun Guo
2013-12-04 14:27 ` Hanjun Guo
2013-12-04 14:27 ` Hanjun Guo
2013-12-04 15:07 ` Mark Rutland
2013-12-04 15:07 ` Mark Rutland
2013-12-04 15:07 ` Mark Rutland
2013-12-05 13:09 ` Hanjun Guo
2013-12-05 13:09 ` Hanjun Guo
2013-12-05 13:09 ` Hanjun Guo
[not found] <1386069328-22502-1-git-send-email-hanjun.guo@linaro.org>
[not found] ` <1386069328-22502-2-git-send-email-hanjun.guo@linaro.org>
2013-12-04 15:33 ` [RFC part3 PATCH 1/2] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer Rob Herring
2013-12-04 15:33 ` Rob Herring
2013-12-05 13:26 ` Hanjun Guo
2013-12-05 13:26 ` Hanjun Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=529F3B4C.1080400@linaro.org \
--to=hanjun.guo@linaro.org \
--cc=Catalin.Marinas@arm.com \
--cc=Will.Deacon@arm.com \
--cc=bhelgaas@google.com \
--cc=daniel.lezcano@linaro.org \
--cc=grant.likely@linaro.org \
--cc=jonathan@jonmasters.org \
--cc=linaro-acpi@lists.linaro \
--cc=linaro-kernel@lists.linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mjg59@srcf.ucam.org \
--cc=olof@lixom.net \
--cc=patches@linaro.org \
--cc=rjw@rjwysocki.net \
--cc=rob.herring@calxeda.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.