From: Hanjun Guo <hanjun.guo@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>, Sudeep Holla <Sudeep.Holla@arm.com>
Cc: Tomasz Nowicki <tomasz.nowicki@linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Mark Rutland <Mark.Rutland@arm.com>,
Olof Johansson <olof@lixom.net>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"graeme.gregory@linaro.org" <graeme.gregory@linaro.org>,
Arnd Bergmann <arnd@arndb.de>, Will Deacon <Will.Deacon@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
Bjorn Helgaas <bhelgaas@google.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
Robert Richter <rric@kernel.org>, Lv Zheng <lv.zheng@intel.com>,
Robert Moore <robert.moore@intel.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Randy Dunlap <rdunlap@infradead.org>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vg>
Subject: Re: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
Date: Thu, 04 Sep 2014 22:03:38 +0800 [thread overview]
Message-ID: <5408713A.3020600@linaro.org> (raw)
In-Reply-To: <5406F8BC.7000503@linaro.org>
On 2014年09月03日 19:17, Hanjun Guo wrote:
>>>>>>> +
>>>>>>> +#ifdef CONFIG_ACPI
>>>>>>> +#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
>>>>>> With GICv2? I doubt it.
>>>>> I will create macro for each GIC driver:
>>>>> #define ACPI_MAX_GICV2_CPU_INTERFACE_ENTRIES 8
>>>>> #define ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES 65535
>>>> Where do you get this value (ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES) from?
>>> This value is for max processors entries in MADT, and we will use it to scan MADT
>>> for SMP/GIC Init, I just make it big enough for GICv3/4. since ACPI core will stop
>>> scan MADT if the real numbers of processors entries are reached no matter
>>> how big ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES is, I think we can just
>>> define a number big enough then it will work (x86 and ia64 did the same thing).
>> Also, with GICv3++, there is no such thing as a memory-mapped CPU
>> interface anymore. What you get is a bunch of redistributors (one per
>> CPU). I assume what you have here actually describe the redistributors,
>> and its name should reflect that.
> As Sudeep said, it is not to link to GIC architecture, so I think we can keep
> it stick with ACPI spec, in ACPI spec, it called "GICC structure" (section 5.2.12.14
> in ACPI 5.1), so we can name it as ACPI_MAX_GICC_STRUCTURE_ENTRIES no matter
> GICv2 or GICv3/4 (with GICv2, it may have more than 8 entries with some disabled
> ones, will no more than 8 enabled entries).
>
> What do you think?
After more consideration on this, we think that we can remove those macros which
introduce confusions, and just pass 0 to ACPI core for the max entries of GICC structure
or GICR structure, ACPI core will continue scan all the entries in MADT with 0 passed.
With that, we can avoid such name confusions for all GIC related structures in MADT
no matter GICv2 or GICv3/4.
Thanks
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: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
Date: Thu, 04 Sep 2014 22:03:38 +0800 [thread overview]
Message-ID: <5408713A.3020600@linaro.org> (raw)
In-Reply-To: <5406F8BC.7000503@linaro.org>
On 2014?09?03? 19:17, Hanjun Guo wrote:
>>>>>>> +
>>>>>>> +#ifdef CONFIG_ACPI
>>>>>>> +#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
>>>>>> With GICv2? I doubt it.
>>>>> I will create macro for each GIC driver:
>>>>> #define ACPI_MAX_GICV2_CPU_INTERFACE_ENTRIES 8
>>>>> #define ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES 65535
>>>> Where do you get this value (ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES) from?
>>> This value is for max processors entries in MADT, and we will use it to scan MADT
>>> for SMP/GIC Init, I just make it big enough for GICv3/4. since ACPI core will stop
>>> scan MADT if the real numbers of processors entries are reached no matter
>>> how big ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES is, I think we can just
>>> define a number big enough then it will work (x86 and ia64 did the same thing).
>> Also, with GICv3++, there is no such thing as a memory-mapped CPU
>> interface anymore. What you get is a bunch of redistributors (one per
>> CPU). I assume what you have here actually describe the redistributors,
>> and its name should reflect that.
> As Sudeep said, it is not to link to GIC architecture, so I think we can keep
> it stick with ACPI spec, in ACPI spec, it called "GICC structure" (section 5.2.12.14
> in ACPI 5.1), so we can name it as ACPI_MAX_GICC_STRUCTURE_ENTRIES no matter
> GICv2 or GICv3/4 (with GICv2, it may have more than 8 entries with some disabled
> ones, will no more than 8 enabled entries).
>
> What do you think?
After more consideration on this, we think that we can remove those macros which
introduce confusions, and just pass 0 to ACPI core for the max entries of GICC structure
or GICR structure, ACPI core will continue scan all the entries in MADT with 0 passed.
With that, we can avoid such name confusions for all GIC related structures in MADT
no matter GICv2 or GICv3/4.
Thanks
Hanjun
WARNING: multiple messages have this Message-ID (diff)
From: Hanjun Guo <hanjun.guo@linaro.org>
To: Marc Zyngier <marc.zyngier@arm.com>, Sudeep Holla <Sudeep.Holla@arm.com>
Cc: Tomasz Nowicki <tomasz.nowicki@linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Mark Rutland <Mark.Rutland@arm.com>,
Olof Johansson <olof@lixom.net>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"graeme.gregory@linaro.org" <graeme.gregory@linaro.org>,
Arnd Bergmann <arnd@arndb.de>, Will Deacon <Will.Deacon@arm.com>,
Jason Cooper <jason@lakedaemon.net>,
Bjorn Helgaas <bhelgaas@google.com>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
Robert Richter <rric@kernel.org>, Lv Zheng <lv.zheng@intel.com>,
Robert Moore <robert.moore@intel.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Randy Dunlap <rdunlap@infradead.org>,
Charles Garcia-Tobin <Charles.Garcia-Tobin@arm.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>
Subject: Re: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
Date: Thu, 04 Sep 2014 22:03:38 +0800 [thread overview]
Message-ID: <5408713A.3020600@linaro.org> (raw)
In-Reply-To: <5406F8BC.7000503@linaro.org>
On 2014年09月03日 19:17, Hanjun Guo wrote:
>>>>>>> +
>>>>>>> +#ifdef CONFIG_ACPI
>>>>>>> +#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
>>>>>> With GICv2? I doubt it.
>>>>> I will create macro for each GIC driver:
>>>>> #define ACPI_MAX_GICV2_CPU_INTERFACE_ENTRIES 8
>>>>> #define ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES 65535
>>>> Where do you get this value (ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES) from?
>>> This value is for max processors entries in MADT, and we will use it to scan MADT
>>> for SMP/GIC Init, I just make it big enough for GICv3/4. since ACPI core will stop
>>> scan MADT if the real numbers of processors entries are reached no matter
>>> how big ACPI_MAX_GICV3_CPU_INTERFACE_ENTRIES is, I think we can just
>>> define a number big enough then it will work (x86 and ia64 did the same thing).
>> Also, with GICv3++, there is no such thing as a memory-mapped CPU
>> interface anymore. What you get is a bunch of redistributors (one per
>> CPU). I assume what you have here actually describe the redistributors,
>> and its name should reflect that.
> As Sudeep said, it is not to link to GIC architecture, so I think we can keep
> it stick with ACPI spec, in ACPI spec, it called "GICC structure" (section 5.2.12.14
> in ACPI 5.1), so we can name it as ACPI_MAX_GICC_STRUCTURE_ENTRIES no matter
> GICv2 or GICv3/4 (with GICv2, it may have more than 8 entries with some disabled
> ones, will no more than 8 enabled entries).
>
> What do you think?
After more consideration on this, we think that we can remove those macros which
introduce confusions, and just pass 0 to ACPI core for the max entries of GICC structure
or GICR structure, ACPI core will continue scan all the entries in MADT with 0 passed.
With that, we can avoid such name confusions for all GIC related structures in MADT
no matter GICv2 or GICv3/4.
Thanks
Hanjun
next prev parent reply other threads:[~2014-09-04 14:04 UTC|newest]
Thread overview: 332+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-01 14:57 [PATCH v3 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 01/17] ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 02/17] ARM64 / ACPI: Get RSDP and ACPI boot-time tables Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-09 16:26 ` Catalin Marinas
2014-09-09 16:26 ` Catalin Marinas
2014-09-09 16:26 ` Catalin Marinas
2014-09-09 16:41 ` Jon Masters
2014-09-09 16:41 ` Jon Masters
2014-09-09 16:41 ` Jon Masters
2014-09-09 16:44 ` Jon Masters
2014-09-09 16:44 ` Jon Masters
2014-09-09 17:15 ` Mark Rutland
2014-09-09 17:15 ` Mark Rutland
2014-09-09 17:15 ` Mark Rutland
2014-09-09 17:33 ` Jon Masters
2014-09-09 17:33 ` Jon Masters
2014-09-09 17:33 ` Jon Masters
2014-09-09 17:50 ` Lorenzo Pieralisi
2014-09-09 17:50 ` Lorenzo Pieralisi
2014-09-09 17:50 ` Lorenzo Pieralisi
2014-09-09 18:05 ` Sudeep Holla
2014-09-09 18:05 ` Sudeep Holla
2014-09-09 18:05 ` Sudeep Holla
2014-09-09 19:06 ` Jon Masters
2014-09-09 19:06 ` Jon Masters
2014-09-09 19:06 ` Jon Masters
2014-09-10 11:13 ` Hanjun Guo
2014-09-10 11:13 ` Hanjun Guo
2014-09-10 11:13 ` Hanjun Guo
2014-09-10 12:33 ` Catalin Marinas
2014-09-10 12:33 ` Catalin Marinas
2014-09-10 12:33 ` Catalin Marinas
2014-09-10 21:51 ` Grant Likely
2014-09-10 21:51 ` Grant Likely
2014-09-10 21:51 ` Grant Likely
2014-09-11 11:01 ` Catalin Marinas
2014-09-11 11:01 ` Catalin Marinas
2014-09-11 11:01 ` Catalin Marinas
2014-09-14 15:40 ` Grant Likely
2014-09-14 15:40 ` Grant Likely
2014-09-14 15:40 ` Grant Likely
2014-09-14 21:59 ` Catalin Marinas
2014-09-14 21:59 ` Catalin Marinas
2014-09-14 21:59 ` Catalin Marinas
2014-09-15 3:53 ` Grant Likely
2014-09-15 3:53 ` Grant Likely
2014-09-15 3:53 ` Grant Likely
2014-09-16 5:29 ` Zheng, Lv
2014-09-16 5:29 ` Zheng, Lv
2014-09-16 5:29 ` Zheng, Lv
2014-09-10 21:41 ` Grant Likely
2014-09-10 21:41 ` Grant Likely
2014-09-10 21:41 ` Grant Likely
2014-09-09 16:54 ` Mark Rutland
2014-09-09 16:54 ` Mark Rutland
2014-09-09 16:54 ` Mark Rutland
2014-09-10 7:30 ` Hanjun Guo
2014-09-10 7:30 ` Hanjun Guo
2014-09-10 7:30 ` Hanjun Guo
2014-09-10 21:37 ` Grant Likely
2014-09-10 21:37 ` Grant Likely
2014-09-10 21:37 ` Grant Likely
2014-09-01 14:57 ` [PATCH v3 03/17] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-09 16:35 ` Catalin Marinas
2014-09-09 16:35 ` Catalin Marinas
2014-09-09 16:35 ` Catalin Marinas
2014-09-09 22:04 ` Graeme Gregory
2014-09-09 22:04 ` Graeme Gregory
2014-09-09 22:04 ` Graeme Gregory
2014-09-01 14:57 ` [PATCH v3 04/17] ARM64 / ACPI: Introduce early_param for "acpi" Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-09 16:37 ` Catalin Marinas
2014-09-09 16:37 ` Catalin Marinas
2014-09-09 16:37 ` Catalin Marinas
2014-09-09 17:17 ` Bjorn Helgaas
2014-09-09 17:17 ` Bjorn Helgaas
2014-09-09 17:17 ` Bjorn Helgaas
2014-09-09 22:14 ` Jon Masters
2014-09-09 22:14 ` Jon Masters
2014-09-09 22:14 ` Jon Masters
2014-09-10 13:04 ` Will Deacon
2014-09-10 13:04 ` Will Deacon
2014-09-10 13:04 ` Will Deacon
2014-09-10 13:21 ` Bjorn Helgaas
2014-09-10 13:21 ` Bjorn Helgaas
2014-09-10 13:21 ` Bjorn Helgaas
2014-09-10 18:30 ` Will Deacon
2014-09-10 18:30 ` Will Deacon
2014-09-10 18:30 ` Will Deacon
2014-09-10 21:58 ` Grant Likely
2014-09-10 21:58 ` Grant Likely
2014-09-10 21:58 ` Grant Likely
2014-09-01 14:57 ` [PATCH v3 05/17] ARM64 / ACPI: If we chose to boot from acpi then disable FDT Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 06/17] ARM64 / ACPI: Make PCI optional for ACPI on ARM64 Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 07/17] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 08/17] ACPI / table: Print GIC information when MADT is parsed Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 09/17] ARM64 / ACPI: Parse MADT for SMP initialization Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-03 17:21 ` Lorenzo Pieralisi
2014-09-03 17:21 ` Lorenzo Pieralisi
2014-09-03 17:21 ` Lorenzo Pieralisi
2014-09-04 15:29 ` Hanjun Guo
2014-09-04 15:29 ` Hanjun Guo
2014-09-04 15:29 ` Hanjun Guo
2014-09-09 3:55 ` Jon Masters
2014-09-09 10:22 ` Mark Rutland
2014-09-09 10:46 ` Graeme Gregory
2014-09-11 10:32 ` Grant Likely
2014-09-09 4:29 ` Jon Masters
2014-09-09 4:29 ` Jon Masters
2014-09-09 4:29 ` Jon Masters
2014-09-09 5:11 ` Hanjun Guo
2014-09-09 5:11 ` Hanjun Guo
2014-09-09 5:11 ` Hanjun Guo
2014-09-09 5:34 ` Jon Masters
2014-09-09 5:34 ` Jon Masters
2014-09-09 5:34 ` Jon Masters
2014-09-09 16:52 ` Lorenzo Pieralisi
2014-09-09 16:52 ` Lorenzo Pieralisi
2014-09-09 16:52 ` Lorenzo Pieralisi
2014-09-09 17:00 ` Jon Masters
2014-09-09 17:00 ` Jon Masters
2014-09-09 17:00 ` Jon Masters
2014-09-09 17:02 ` Jon Masters
2014-09-09 17:02 ` Jon Masters
2014-09-09 17:02 ` Jon Masters
2014-09-09 4:23 ` Jon Masters
2014-09-09 4:23 ` Jon Masters
2014-09-09 4:23 ` Jon Masters
2014-09-09 4:57 ` Hanjun Guo
2014-09-09 4:57 ` Hanjun Guo
2014-09-09 4:57 ` Hanjun Guo
2014-09-09 5:44 ` Jon Masters
2014-09-09 5:44 ` Jon Masters
2014-09-09 5:44 ` Jon Masters
2014-09-09 16:00 ` Hanjun Guo
2014-09-09 16:00 ` Hanjun Guo
2014-09-09 16:00 ` Hanjun Guo
2014-09-09 16:04 ` Jon Masters
2014-09-09 16:04 ` Jon Masters
2014-09-09 16:04 ` Jon Masters
2014-09-09 16:14 ` Hanjun Guo
2014-09-09 16:14 ` Hanjun Guo
2014-09-09 16:14 ` Hanjun Guo
2014-09-11 14:15 ` Will Deacon
2014-09-11 14:15 ` Will Deacon
2014-09-11 14:15 ` Will Deacon
2014-09-12 21:30 ` Jon Masters
2014-09-12 21:30 ` Jon Masters
2014-09-12 21:30 ` Jon Masters
2014-09-11 10:24 ` Grant Likely
2014-09-11 10:24 ` Grant Likely
2014-09-11 10:24 ` Grant Likely
2014-09-01 14:57 ` [PATCH v3 10/17] ACPI / processor: Make it possible to get CPU hardware ID via GICC Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-03 16:27 ` Lorenzo Pieralisi
2014-09-03 16:27 ` Lorenzo Pieralisi
2014-09-03 16:27 ` Lorenzo Pieralisi
2014-09-08 13:10 ` Hanjun Guo
2014-09-08 13:10 ` Hanjun Guo
2014-09-08 13:10 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 11/17] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-11 11:08 ` Grant Likely
2014-09-11 11:08 ` Grant Likely
2014-09-11 11:08 ` Grant Likely
2014-09-11 11:34 ` Grant Likely
2014-09-11 11:34 ` Grant Likely
2014-09-12 9:42 ` Hanjun Guo
2014-09-12 9:42 ` Hanjun Guo
2014-09-12 9:42 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 12/17] ACPI / table: Add new function to get table entries Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 17:35 ` Marc Zyngier
2014-09-01 17:35 ` Marc Zyngier
2014-09-01 17:35 ` Marc Zyngier
2014-09-02 8:28 ` [Linaro-acpi] " Alexander Spyridakis
2014-09-02 8:28 ` Alexander Spyridakis
2014-09-02 11:48 ` Tomasz Nowicki
2014-09-02 11:48 ` Tomasz Nowicki
2014-09-02 11:48 ` Tomasz Nowicki
2014-09-02 13:02 ` Marc Zyngier
2014-09-02 13:02 ` Marc Zyngier
2014-09-02 13:02 ` Marc Zyngier
2014-09-02 15:45 ` Hanjun Guo
2014-09-02 15:45 ` Hanjun Guo
2014-09-02 15:45 ` Hanjun Guo
2014-09-02 15:59 ` Marc Zyngier
2014-09-02 15:59 ` Marc Zyngier
2014-09-02 15:59 ` Marc Zyngier
2014-09-02 16:11 ` Sudeep Holla
2014-09-02 16:11 ` Sudeep Holla
2014-09-02 16:11 ` Sudeep Holla
2014-09-03 10:30 ` Marc Zyngier
2014-09-03 10:30 ` Marc Zyngier
2014-09-03 10:30 ` Marc Zyngier
2014-09-03 11:17 ` Hanjun Guo
2014-09-03 11:17 ` Hanjun Guo
2014-09-03 11:17 ` Hanjun Guo
2014-09-04 14:03 ` Hanjun Guo [this message]
2014-09-04 14:03 ` Hanjun Guo
2014-09-04 14:03 ` Hanjun Guo
2014-09-09 6:21 ` Jon Masters
2014-09-09 6:21 ` Jon Masters
2014-09-09 6:21 ` Jon Masters
2014-09-03 9:26 ` Tomasz Nowicki
2014-09-03 9:26 ` Tomasz Nowicki
2014-09-03 9:26 ` Tomasz Nowicki
2014-09-03 14:57 ` Arnd Bergmann
2014-09-03 14:57 ` Arnd Bergmann
2014-09-03 14:57 ` Arnd Bergmann
2014-09-05 8:52 ` Tomasz Nowicki
2014-09-05 8:52 ` Tomasz Nowicki
2014-09-05 8:52 ` Tomasz Nowicki
2014-09-05 9:47 ` Marc Zyngier
2014-09-05 9:47 ` Marc Zyngier
2014-09-05 9:47 ` Marc Zyngier
2014-09-05 10:13 ` [Linaro-acpi] " Arnd Bergmann
2014-09-05 10:13 ` Arnd Bergmann
2014-09-05 10:36 ` Tomasz Nowicki
2014-09-05 10:36 ` Tomasz Nowicki
2014-09-05 10:39 ` Marc Zyngier
2014-09-05 10:39 ` Marc Zyngier
2014-09-05 10:49 ` Tomasz Nowicki
2014-09-05 10:49 ` Tomasz Nowicki
2014-09-09 6:27 ` Jon Masters
2014-09-09 6:27 ` Jon Masters
2014-09-09 6:27 ` Jon Masters
2014-09-11 13:43 ` Grant Likely
2014-09-11 13:43 ` Grant Likely
2014-09-11 13:43 ` Grant Likely
2014-09-02 16:34 ` Catalin Marinas
2014-09-02 16:34 ` Catalin Marinas
2014-09-02 16:34 ` Catalin Marinas
2014-09-11 11:48 ` Grant Likely
2014-09-11 11:48 ` Grant Likely
2014-09-11 11:48 ` Grant Likely
2014-09-11 12:01 ` Marc Zyngier
2014-09-11 12:01 ` Marc Zyngier
2014-09-11 12:01 ` Marc Zyngier
2014-09-09 6:14 ` Jon Masters
2014-09-09 6:14 ` Jon Masters
2014-09-09 6:14 ` Jon Masters
2014-09-03 18:42 ` Arnd Bergmann
2014-09-03 18:42 ` Arnd Bergmann
2014-09-03 18:42 ` Arnd Bergmann
2014-09-04 10:10 ` Tomasz Nowicki
2014-09-04 10:10 ` Tomasz Nowicki
2014-09-04 10:14 ` Arnd Bergmann
2014-09-04 10:14 ` Arnd Bergmann
2014-09-04 10:39 ` Tomasz Nowicki
2014-09-04 10:39 ` Tomasz Nowicki
2014-09-09 6:35 ` Jon Masters
2014-09-09 6:35 ` Jon Masters
2014-09-09 6:35 ` Jon Masters
2014-09-01 14:57 ` [PATCH v3 14/17] ARM64 / ACPI: Parse GTDT to initialize arch timer Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 15/17] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-01 14:57 ` [PATCH v3 16/17] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-11 15:18 ` Lorenzo Pieralisi
2014-09-11 15:18 ` Lorenzo Pieralisi
2014-09-11 15:18 ` Lorenzo Pieralisi
2014-09-01 14:57 ` [PATCH v3 17/17] Documentation: ACPI for ARM64 Hanjun Guo
2014-09-01 14:57 ` Hanjun Guo
2014-09-11 13:29 ` [PATCH v3 00/17] Introduce ACPI for ARM64 based on ACPI 5.1 Grant Likely
2014-09-11 13:29 ` Grant Likely
2014-09-11 13:29 ` Grant Likely
2014-09-11 13:49 ` Will Deacon
2014-09-11 13:49 ` Will Deacon
2014-09-11 13:49 ` Will Deacon
2014-09-12 21:38 ` Jon Masters
2014-09-12 21:38 ` Jon Masters
2014-09-12 21:38 ` Jon Masters
2014-09-12 21:43 ` Jon Masters
2014-09-12 21:43 ` Jon Masters
2014-09-12 21:43 ` Jon Masters
2014-09-15 4:21 ` Grant Likely
2014-09-15 4:21 ` Grant Likely
2014-09-15 4:21 ` Grant Likely
2014-09-11 14:23 ` Rafael J. Wysocki
2014-09-11 14:23 ` Rafael J. Wysocki
2014-09-11 14:23 ` Rafael J. Wysocki
2014-09-11 14:04 ` Grant Likely
2014-09-11 14:04 ` Grant Likely
2014-09-11 14:04 ` Grant Likely
2014-09-11 15:37 ` Catalin Marinas
2014-09-11 15:37 ` Catalin Marinas
2014-09-11 15:37 ` Catalin Marinas
2014-09-11 15:57 ` Sudeep Holla
2014-09-11 15:57 ` Sudeep Holla
2014-09-11 15:57 ` Sudeep Holla
2014-09-11 16:06 ` Graeme Gregory
2014-09-11 16:06 ` Graeme Gregory
2014-09-11 16:06 ` Graeme Gregory
2014-09-11 16:14 ` Sudeep Holla
2014-09-11 16:14 ` Sudeep Holla
2014-09-11 16:14 ` Sudeep Holla
2014-09-15 4:31 ` Grant Likely
2014-09-15 4:31 ` Grant Likely
2014-09-15 4:31 ` Grant Likely
2014-09-15 9:15 ` Catalin Marinas
2014-09-15 9:15 ` Catalin Marinas
2014-09-15 9:15 ` Catalin Marinas
2014-09-15 22:48 ` Grant Likely
2014-09-15 22:48 ` Grant Likely
2014-09-15 22:48 ` Grant Likely
2014-09-16 10:12 ` Catalin Marinas
2014-09-16 10:12 ` Catalin Marinas
2014-09-16 10:12 ` Catalin Marinas
2014-09-11 16:05 ` Olof Johansson
2014-09-11 16:05 ` Olof Johansson
2014-09-11 16:05 ` Olof Johansson
2014-09-15 4:37 ` Grant Likely
2014-09-15 4:37 ` Grant Likely
2014-09-15 4:37 ` Grant Likely
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=5408713A.3020600@linaro.org \
--to=hanjun.guo@linaro.org \
--cc=Catalin.Marinas@arm.com \
--cc=Charles.Garcia-Tobin@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Sudeep.Holla@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=broonie@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=graeme.gregory@linaro.org \
--cc=grant.likely@linaro.org \
--cc=jason@lakedaemon.net \
--cc=linux-acpi@vg \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=olof@lixom.net \
--cc=rdunlap@infradead.org \
--cc=rjw@rjwysocki.net \
--cc=robert.moore@intel.com \
--cc=robh@kernel.org \
--cc=rric@kernel.org \
--cc=tomasz.nowicki@linaro.org \
/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.