All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Covington <cov@codeaurora.org>
To: Fu Wei <fu.wei@linaro.org>, Mark Rutland <mark.rutland@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	Linaro ACPI Mailman List <linaro-acpi@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	rruigrok@codeaurora.org, "Abdulhamid,
	Harb" <harba@codeaurora.org>, Timur Tabi <timur@codeaurora.org>,
	G Gregory <graeme.gregory@linaro.org>,
	Al Stone <al.stone@linaro.org>, Jon Masters <jcm@redhat.com>,
	Wei Huang <wei@redhat.com>, Arnd Bergmann <arnd@a>
Subject: Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Date: Wed, 25 Jan 2017 10:38:01 -0500	[thread overview]
Message-ID: <e62c6f73-16e0-2764-126f-b8ed6adc3489@codeaurora.org> (raw)
In-Reply-To: <CADyBb7sU6DVMk6px0963r8by--U-3k_XjESd88zZMkj7xbywgA@mail.gmail.com>

Hi Fu,

On 01/25/2017 01:46 AM, Fu Wei wrote:
> Hi Mark,
> 
> On 25 January 2017 at 01:24, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu.wei@linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> The counter frequency detection call(arch_timer_detect_rate) combines two
>>> ways to get counter frequency: system coprocessor register and MMIO timer.
>>> But in a specific timer init code, we only need one way to try:
>>> getting frequency from MMIO timer register will be needed only when we
>>> init MMIO timer; getting frequency from system coprocessor register will
>>> be needed only when we init arch timer.
>>
>> When I mentioned this splitting before, I had mean that we'd completely
>> separate the two, with separate mmio_rate and sysreg_rate variables.
> 
> sorry for misunderstanding.
> 
> Are you saying :
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 663a57a..eec92f6 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -65,7 +65,8 @@ struct arch_timer {
> 
>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
> 
> -static u32 arch_timer_rate;
> +static u32 arch_timer_sysreg_rate ;
> +static u32 arch_timer_mmio_rate;
>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
> 
>  static struct clock_event_device __percpu *arch_timer_evt;
> 
> 
> But what have I learned From ARMv8 ARM is
> AArch64 System register CNTFRQ_EL0 is provided so that software can
> discover the frequency of the system counter.
> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
> discover the frequency of the system counter.
> The bit assignments of the registers are identical in the System
> register interface and in the memory-mapped system level interface.
> So I think they both contain the same value : the frequency of the
> system counter, just in different view, and can be accessed in
> different ways.
> 
> So do we really need to separate mmio_rate and sysreg_rate variables?
> 
> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
> Linux kernel (EL1),
> Because ARMv8 ARM says:
> In a system that implements both Secure and Non-secure states, this
> register is only accessible by Secure accesses.
> That means we still need to get the frequency of the system counter
> from CNTFRQ_EL0 in MMIO timer code.
> This have been proved when I tested this driver on foundation model, I
> got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)

That sounds like a firmware problem. Firmware in EL3 is supposed to write
the value into CNTFRQ. If you're not currently using any firmware, I'd
recommend the bootwrapper on models/simulators/emulators.

http://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/arch/aarch64/boot.S#n48

Cheers,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.

WARNING: multiple messages have this Message-ID (diff)
From: Christopher Covington <cov@codeaurora.org>
To: Fu Wei <fu.wei@linaro.org>, Mark Rutland <mark.rutland@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	Linaro ACPI Mailman List <linaro-acpi@lists.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	rruigrok@codeaurora.org, "Abdulhamid,
	Harb" <harba@codeaurora.org>, Timur Tabi <timur@codeaurora.org>,
	G Gregory <graeme.gregory@linaro.org>,
	Al Stone <al.stone@linaro.org>, Jon Masters <jcm@redhat.com>,
	Wei Huang <wei@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
	Leo Duran <leo.duran@amd.com>, Wim Van Sebroeck <wim@iguana.be>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-watchdog@vger.kernel.org, Tomasz Nowicki <tn@semihalf.com>,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Julien Grall <julien.grall@arm.com>
Subject: Re: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Date: Wed, 25 Jan 2017 10:38:01 -0500	[thread overview]
Message-ID: <e62c6f73-16e0-2764-126f-b8ed6adc3489@codeaurora.org> (raw)
In-Reply-To: <CADyBb7sU6DVMk6px0963r8by--U-3k_XjESd88zZMkj7xbywgA@mail.gmail.com>

Hi Fu,

On 01/25/2017 01:46 AM, Fu Wei wrote:
> Hi Mark,
> 
> On 25 January 2017 at 01:24, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu.wei@linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> The counter frequency detection call(arch_timer_detect_rate) combines two
>>> ways to get counter frequency: system coprocessor register and MMIO timer.
>>> But in a specific timer init code, we only need one way to try:
>>> getting frequency from MMIO timer register will be needed only when we
>>> init MMIO timer; getting frequency from system coprocessor register will
>>> be needed only when we init arch timer.
>>
>> When I mentioned this splitting before, I had mean that we'd completely
>> separate the two, with separate mmio_rate and sysreg_rate variables.
> 
> sorry for misunderstanding.
> 
> Are you saying :
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 663a57a..eec92f6 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -65,7 +65,8 @@ struct arch_timer {
> 
>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
> 
> -static u32 arch_timer_rate;
> +static u32 arch_timer_sysreg_rate ;
> +static u32 arch_timer_mmio_rate;
>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
> 
>  static struct clock_event_device __percpu *arch_timer_evt;
> 
> 
> But what have I learned From ARMv8 ARM is
> AArch64 System register CNTFRQ_EL0 is provided so that software can
> discover the frequency of the system counter.
> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
> discover the frequency of the system counter.
> The bit assignments of the registers are identical in the System
> register interface and in the memory-mapped system level interface.
> So I think they both contain the same value : the frequency of the
> system counter, just in different view, and can be accessed in
> different ways.
> 
> So do we really need to separate mmio_rate and sysreg_rate variables?
> 
> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
> Linux kernel (EL1),
> Because ARMv8 ARM says:
> In a system that implements both Secure and Non-secure states, this
> register is only accessible by Secure accesses.
> That means we still need to get the frequency of the system counter
> from CNTFRQ_EL0 in MMIO timer code.
> This have been proved when I tested this driver on foundation model, I
> got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)

That sounds like a firmware problem. Firmware in EL3 is supposed to write
the value into CNTFRQ. If you're not currently using any firmware, I'd
recommend the bootwrapper on models/simulators/emulators.

http://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/arch/aarch64/boot.S#n48

Cheers,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.

WARNING: multiple messages have this Message-ID (diff)
From: cov@codeaurora.org (Christopher Covington)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection.
Date: Wed, 25 Jan 2017 10:38:01 -0500	[thread overview]
Message-ID: <e62c6f73-16e0-2764-126f-b8ed6adc3489@codeaurora.org> (raw)
In-Reply-To: <CADyBb7sU6DVMk6px0963r8by--U-3k_XjESd88zZMkj7xbywgA@mail.gmail.com>

Hi Fu,

On 01/25/2017 01:46 AM, Fu Wei wrote:
> Hi Mark,
> 
> On 25 January 2017 at 01:24, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Jan 18, 2017 at 09:25:32PM +0800, fu.wei at linaro.org wrote:
>>> From: Fu Wei <fu.wei@linaro.org>
>>>
>>> The counter frequency detection call(arch_timer_detect_rate) combines two
>>> ways to get counter frequency: system coprocessor register and MMIO timer.
>>> But in a specific timer init code, we only need one way to try:
>>> getting frequency from MMIO timer register will be needed only when we
>>> init MMIO timer; getting frequency from system coprocessor register will
>>> be needed only when we init arch timer.
>>
>> When I mentioned this splitting before, I had mean that we'd completely
>> separate the two, with separate mmio_rate and sysreg_rate variables.
> 
> sorry for misunderstanding.
> 
> Are you saying :
> 
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 663a57a..eec92f6 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -65,7 +65,8 @@ struct arch_timer {
> 
>  #define to_arch_timer(e) container_of(e, struct arch_timer, evt)
> 
> -static u32 arch_timer_rate;
> +static u32 arch_timer_sysreg_rate ;
> +static u32 arch_timer_mmio_rate;
>  static int arch_timer_ppi[ARCH_TIMER_MAX_TIMER_PPI];
> 
>  static struct clock_event_device __percpu *arch_timer_evt;
> 
> 
> But what have I learned From ARMv8 ARM is
> AArch64 System register CNTFRQ_EL0 is provided so that software can
> discover the frequency of the system counter.
> CNTFRQ(in CNTCTLBase and CNTBaseN) is provided so that software can
> discover the frequency of the system counter.
> The bit assignments of the registers are identical in the System
> register interface and in the memory-mapped system level interface.
> So I think they both contain the same value : the frequency of the
> system counter, just in different view, and can be accessed in
> different ways.
> 
> So do we really need to separate mmio_rate and sysreg_rate variables?
> 
> And for CNTFRQ(in CNTCTLBase and CNTBaseN) , we can NOT access it in
> Linux kernel (EL1),
> Because ARMv8 ARM says:
> In a system that implements both Secure and Non-secure states, this
> register is only accessible by Secure accesses.
> That means we still need to get the frequency of the system counter
> from CNTFRQ_EL0 in MMIO timer code.
> This have been proved when I tested this driver on foundation model, I
> got "0" when I access CNTFRQ from Linux kernel (Non-secure EL1)

That sounds like a firmware problem. Firmware in EL3 is supposed to write
the value into CNTFRQ. If you're not currently using any firmware, I'd
recommend the bootwrapper on models/simulators/emulators.

http://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/arch/aarch64/boot.S#n48

Cheers,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.

  parent reply	other threads:[~2017-01-25 15:38 UTC|newest]

Thread overview: 134+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-18 13:25 [PATCH v20 00/17] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei
2017-01-18 13:25 ` fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 01/17] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 02/17] clocksource/drivers/arm_arch_timer: Rename the timer type macros fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 03/17] clocksource/drivers/arm_arch_timer: Rename the PPI enum and its values fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25 ` [PATCH v20 04/17] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 05/17] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 06/17] clocksource/drivers/arm_arch_timer: rework PPI determination fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 07/17] clocksource/drivers/arm_arch_timer: Separate out device-tree code from arch_timer_detect_rate fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 08/17] clocksource/drivers/arm_arch_timer: Rework counter frequency detection fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
     [not found]   ` <20170118132541.8989-9-fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-01-19  8:02     ` Hanjun Guo
2017-01-19  8:02       ` Hanjun Guo
2017-01-19  8:02       ` Hanjun Guo
     [not found]       ` <cafa8c7a-9c7c-51ba-5566-0cfe1fe6f764-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-01-19  9:44         ` Fu Wei
2017-01-19  9:44           ` Fu Wei
2017-01-19  9:44           ` Fu Wei
2017-01-19 12:41           ` Hanjun Guo
2017-01-19 12:41             ` Hanjun Guo
2017-01-19 12:41             ` Hanjun Guo
2017-01-19 12:41             ` Hanjun Guo
2017-01-24 17:24   ` Mark Rutland
2017-01-24 17:24     ` Mark Rutland
2017-01-25  6:46     ` Fu Wei
2017-01-25  6:46       ` Fu Wei
2017-01-25  6:46       ` Fu Wei
2017-01-25  7:23       ` Fu Wei
2017-01-25  7:23         ` Fu Wei
2017-01-25  7:23         ` Fu Wei
2017-01-25 15:38       ` Christopher Covington [this message]
2017-01-25 15:38         ` Christopher Covington
2017-01-25 15:38         ` Christopher Covington
2017-01-25 17:36         ` Mark Rutland
2017-01-25 17:36           ` Mark Rutland
2017-01-25 17:36           ` Mark Rutland
2017-01-26  5:55           ` Fu Wei
2017-01-26  5:55             ` Fu Wei
2017-01-26  5:55             ` Fu Wei
2017-01-25 17:25       ` Mark Rutland
2017-01-25 17:25         ` Mark Rutland
2017-01-25 17:25         ` Mark Rutland
2017-01-26  5:49         ` Fu Wei
2017-01-26  5:49           ` Fu Wei
2017-01-26  5:49           ` Fu Wei
2017-01-30 17:49           ` Mark Rutland
2017-01-30 17:49             ` Mark Rutland
2017-01-30 17:49             ` Mark Rutland
2017-01-31 11:42             ` Mark Rutland
2017-01-31 11:42               ` Mark Rutland
2017-01-31 11:42               ` Mark Rutland
2017-01-31 18:43             ` Fu Wei
2017-01-31 18:43               ` Fu Wei
2017-01-31 18:43               ` Fu Wei
2017-01-31 18:49               ` Mark Rutland
2017-01-31 18:49                 ` Mark Rutland
2017-01-31 18:49                 ` Mark Rutland
2017-01-31 19:07                 ` Fu Wei
2017-01-31 19:07                   ` Fu Wei
2017-01-31 19:07                   ` Fu Wei
2017-01-18 13:25 ` [PATCH v20 09/17] clocksource/drivers/arm_arch_timer: Refactor arch_timer_needs_probing fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 10/17] clocksource/drivers/arm_arch_timer: Move arch_timer_needs_of_probing into DT init call fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 11/17] clocksource/drivers/arm_arch_timer: Introduce some new structs to prepare for GTDT fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-19  8:28   ` Hanjun Guo
2017-01-19  8:28     ` Hanjun Guo
2017-01-19  9:47     ` Fu Wei
2017-01-19  9:47       ` Fu Wei
2017-01-19  9:47       ` Fu Wei
2017-01-18 13:25 ` [PATCH v20 12/17] clocksource/drivers/arm_arch_timer: Refactor MMIO timer probing fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 13/17] acpi/arm64: Add GTDT table parse driver fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-19  9:11   ` Hanjun Guo
2017-01-19  9:11     ` Hanjun Guo
     [not found]     ` <e69d80d1-0954-b1be-817e-c0be6fc24b77-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-01-19 10:32       ` Fu Wei
2017-01-19 10:32         ` Fu Wei
2017-01-19 10:32         ` Fu Wei
2017-01-19 11:16         ` Mark Rutland
2017-01-19 11:16           ` Mark Rutland
2017-01-19 11:16           ` Mark Rutland
2017-01-19 12:28           ` Fu Wei
2017-01-19 12:28             ` Fu Wei
2017-01-19 12:28             ` Fu Wei
2017-01-18 13:25 ` [PATCH v20 14/17] clocksource/drivers/arm_arch_timer: Simplify ACPI support code fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 15/17] acpi/arm64: Add memory-mapped timer support in GTDT driver fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25 ` [PATCH v20 16/17] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
     [not found]   ` <20170118132541.8989-17-fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2017-01-19  9:16     ` Hanjun Guo
2017-01-19  9:16       ` Hanjun Guo
2017-01-19  9:16       ` Hanjun Guo
2017-01-19 10:02       ` Fu Wei
2017-01-19 10:02         ` Fu Wei
2017-01-19 10:02         ` Fu Wei
2017-01-19 12:42         ` Hanjun Guo
2017-01-19 12:42           ` Hanjun Guo
2017-01-19 12:42           ` Hanjun Guo
2017-01-18 13:25 ` [PATCH v20 17/17] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver fu.wei
2017-01-18 13:25   ` fu.wei at linaro.org
2017-01-18 13:25   ` fu.wei
2017-01-18 13:25   ` fu.wei
2017-01-19  9:20 ` [PATCH v20 00/17] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer Hanjun Guo
2017-01-19  9:20   ` Hanjun Guo
2017-01-19  9:20   ` Hanjun Guo
2017-01-19 11:06   ` Fu Wei
2017-01-19 11:06     ` Fu Wei
2017-01-19 11:06     ` Fu Wei
2017-01-23 18:54 ` Mark Rutland
2017-01-23 18:54   ` Mark Rutland
2017-01-24  5:11   ` Fu Wei
2017-01-24  5:11     ` Fu Wei
2017-01-24  5:11     ` Fu Wei

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=e62c6f73-16e0-2764-126f-b8ed6adc3489@codeaurora.org \
    --to=cov@codeaurora.org \
    --cc=al.stone@linaro.org \
    --cc=arnd@a \
    --cc=daniel.lezcano@linaro.org \
    --cc=fu.wei@linaro.org \
    --cc=graeme.gregory@linaro.org \
    --cc=hanjun.guo@linaro.org \
    --cc=harba@codeaurora.org \
    --cc=jcm@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=rruigrok@codeaurora.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=timur@codeaurora.org \
    --cc=wei@redhat.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.