On 01/22/14 09:19, Hanjun Guo wrote:
Hi Sudeep,
On 2014-1-22 0:39, Sudeep Holla wrote:
Hi Hanjun,
On 21/01/14 14:53, Hanjun Guo wrote:
On 2014年01月21日 19:41, Tomasz Nowicki wrote:
GIC ID is unique for GIC instance (not for CPU) and reflect number of GIC instances system has.
Signed-off-by: Tomasz Nowicki tomasz.nowicki@linaro.org
platforms/rtsm_ve-aemv8a.acpi/apic.asl | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/platforms/rtsm_ve-aemv8a.acpi/apic.asl b/platforms/rtsm_ve-aemv8a.acpi/apic.asl index 81351c3..41e869f 100644 --- a/platforms/rtsm_ve-aemv8a.acpi/apic.asl +++ b/platforms/rtsm_ve-aemv8a.acpi/apic.asl @@ -36,7 +36,7 @@
[0004] Signature : "APIC" [0004] Table Length : 000000F6 -[0001] Revision : 03 +[0001] Revision : 04 [0001] Checksum : B0 [0006] Oem ID : "LINARO" [0008] Oem Table ID : "RTSMVEV8" @@ -51,8 +51,8 @@ [0001] Subtable Type : 0B [Generic Interrupt Controller] [0001] Length : 28 [0002] Reserved : 0000 -[0004] Local GIC Hardware ID : 00000000 /* Should be equal to FDT provided or CPU hardware ID */ -[0004] Processor UID : 00000000 +[0004] Local GIC Hardware ID : 00000000
The GIC ID is the same always, I think they should be unique in the system.
how about matching the bit index of the associated processor in the distributor’s GICD_ITARGETSR register?
Seeing this change and your change on linux-acpi list to support ACPI on ARM64, I am bit confused. What should "Local GIC Hardware ID" in MADT represent ?
- Is it the interrupt controller(GIC) ID ?
or 2. GIC CPU interface ID ?
Sorry for the confusions, "Local GIC Hardware ID" here should be GIC CPU interface ID, and should be unique and one to one mapping to processor ID (ACPI Processor UID).
ACPI processor UID can be MPIDRs as you said in the comments of my patches.
Sudeep, I have some questions for you, How can I get the GIC CPU interface ID? Can I get that from the bit index of the associated processor in the distributor’s GICD_ITARGETSR register? or any other register?
I let myself to add my 2 cents. GICD_ITARGETSR can return CPU ID up to 8 CPUs for now. GICv3 is going to support much more and that register seems to be reorganised accordingly. What do you think?
Tomasz
are they unique when there are multi physical CPUs in the system?
Thanks Hanjun