Re: [patch] x86, acpi: add support for x2apic ACPI extensions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Len Brown <lenb@xxxxxxxxxx> wrote:

> 
> On Wed, 25 Mar 2009, Suresh Siddha wrote:
> 
> > All logical processors with APIC ID values of 255 and greater will have their
> > APIC reported through Processor X2APIC structure (type-9 entry type) and all
> > logical processors with APIC ID less than 255 will have their APIC reported
> > through legacy Processor Local APIC (type-0 entry type) only. This is the
> > same case even for NMI structure reporting.
> > 
> > The Processor X2APIC Affinity structure provides the association between the
> > X2APIC ID of a logical processor and the proximity domain to which the logical
> > processor belongs.
> > 
> > For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device()
> > objects in the ACPI namespace.
> > 
> > Add support for these x2apic ACPI extensions.
> > 
> > Signed-off-by: Suresh Siddha <suresh.b.siddha@xxxxxxxxx>
> > ---
> > 
> > Index: tip/arch/x86/kernel/acpi/boot.c
> > ===================================================================
> > --- tip.orig/arch/x86/kernel/acpi/boot.c
> > +++ tip/arch/x86/kernel/acpi/boot.c
> > @@ -230,6 +230,35 @@ static void __cpuinit acpi_register_lapi
> >  }
> >  
> >  static int __init
> > +acpi_parse_x2apic(struct acpi_subtable_header * header, const unsigned long end)
> > +{
> > +	struct acpi_madt_local_x2apic *processor = NULL;
> > +
> > +	processor = (struct acpi_madt_local_x2apic *)header;
> > +
> > +	if (BAD_MADT_ENTRY(processor, end))
> > +		return -EINVAL;
> > +
> > +	acpi_table_print_madt_entry(header);
> > +
> > +#ifdef CONFIG_X86_X2APIC
> > +	/*
> > +	 * We need to register disabled CPU as well to permit
> > +	 * counting disabled CPUs. This allows us to size
> > +	 * cpus_possible_map more accurately, to permit
> > +	 * to not preallocating memory for all NR_CPUS
> > +	 * when we use CPU hotplug.
> > +	 */
> > +	acpi_register_lapic(processor->local_apic_id,	/* APIC ID */
> > +			    processor->lapic_flags & ACPI_MADT_ENABLED);
> > +#else
> > +	printk(KERN_WARNING PREFIX "x2apic entry ignored\n");
> > +#endif
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init
> >  acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned long end)
> >  {
> >  	struct acpi_madt_local_apic *processor = NULL;
> > @@ -289,6 +318,24 @@ acpi_parse_lapic_addr_ovr(struct acpi_su
> >  }
> >  
> >  static int __init
> > +acpi_parse_x2apic_nmi(struct acpi_subtable_header * header, const unsigned long end)
> > +{
> > +	struct acpi_madt_local_x2apic_nmi *x2apic_nmi = NULL;
> > +
> > +	x2apic_nmi = (struct acpi_madt_local_x2apic_nmi *)header;
> > +
> > +	if (BAD_MADT_ENTRY(x2apic_nmi, end))
> > +		return -EINVAL;
> > +
> > +	acpi_table_print_madt_entry(header);
> > +
> > +	if (x2apic_nmi->lint != 1)
> > +		printk(KERN_WARNING PREFIX "NMI not connected to LINT 1!\n");
> > +
> > +	return 0;
> > +}
> > +
> > +static int __init
> >  acpi_parse_lapic_nmi(struct acpi_subtable_header * header, const unsigned long end)
> >  {
> >  	struct acpi_madt_local_apic_nmi *lapic_nmi = NULL;
> > @@ -816,9 +863,12 @@ static int __init acpi_parse_madt_lapic_
> >  	count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_SAPIC,
> >  				      acpi_parse_sapic, MAX_APICS);
> >  
> > -	if (!count)
> > +	if (!count) {
> > +		count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
> > +					      acpi_parse_x2apic, MAX_APICS);
> >  		count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
> >  					      acpi_parse_lapic, MAX_APICS);
> 
> I'm not fond of the idiom
> 
> count = a();
> count = b();
> 
> if (count)...
> 
> here and below.
> 
> if we really don't care if the x2apic parse routines return,
> and we always care what the traditional apic parse routines return,
> we should have
> 
> a();
> count = b();
> ...
> 
> Ingo, this one is probably more ACPI than it is x86 -- shall I handle it?

Sure, please do.

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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux