linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hanjun.guo@linaro.org (Hanjun Guo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 09/20] ARM64 / ACPI: Implement core functions for parsing MADT table
Date: Fri, 24 Jan 2014 23:34:06 +0800	[thread overview]
Message-ID: <52E287EE.70407@linaro.org> (raw)
In-Reply-To: <52E15756.4060705@arm.com>

Hi Marc,

On 2014?01?24? 01:54, Marc Zyngier wrote:
> Hi Hanjun,
>
> On 17/01/14 12:25, Hanjun Guo wrote:
>> Implement core functions for parsing MADT table to get the information
>> about GIC cpu interface and GIC distributor to prepare for SMP and GIC
>> initialization.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |    3 +
>>   drivers/acpi/plat/arm-core.c  |  139 ++++++++++++++++++++++++++++++++++++++++-
>>   drivers/acpi/tables.c         |   21 +++++++
>>   3 files changed, 162 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index e108d9c..c335c6d 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -83,6 +83,9 @@ void arch_fix_phys_package_id(int num, u32 slot);
>>   extern int (*acpi_suspend_lowlevel)(void);
>>   #define acpi_wakeup_address (0)
>>   
>> +#define MAX_GIC_CPU_INTERFACE 256
> I'll bite. Where on Earth is this value coming from?

I just thought 256 is big enough for now :(
Yes, should be a larger number for GICv3.

> If that's for
> GICv2, 8 is the maximum. For GICv3+, that's incredibly low, and should
> be probed probed at runtime anyway.

I would prefer to do that, but this value is used to
probe CPUs in MADT :)

>
>> +#define MAX_GIC_DISTRIBUTOR   1		/* should be the same as MAX_GIC_NR */
> No support for cascaded GICs?

Yes, no cascade GICs in ACPI at now.

>
>> +
>>   #else	/* !CONFIG_ACPI */
>>   #define acpi_disabled 1		/* ACPI sometimes enabled on ARM */
>>   #define acpi_noirq 1		/* ACPI sometimes enabled on ARM */
>> diff --git a/drivers/acpi/plat/arm-core.c b/drivers/acpi/plat/arm-core.c
>> index 1835b21..8ba3e6f 100644
>> --- a/drivers/acpi/plat/arm-core.c
>> +++ b/drivers/acpi/plat/arm-core.c
>> @@ -46,6 +46,16 @@ EXPORT_SYMBOL(acpi_disabled);
>>   int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>>   EXPORT_SYMBOL(acpi_pci_disabled);
>>   
>> +/*
>> + * Local interrupt controller address,
>> + * GIC cpu interface base address on ARM/ARM64
>> + */
>> +static u64 acpi_lapic_addr __initdata;
> If that's a GIC address, why not call it as such?

thanks for the suggesting, I will update.

>
>> +#define BAD_MADT_ENTRY(entry, end) (					\
>> +	(!entry) || (unsigned long)entry + sizeof(*entry) > end ||	\
>> +	((struct acpi_subtable_header *)entry)->length < sizeof(*entry))
>> +
>>   #define PREFIX			"ACPI: "
> Just do:
> #define pr_fmt(fmt)	"ACPI: " fmt
>
> and remove all the occurrences of PREFIX.
>
>>   /* FIXME: this function should be moved to topology.c when it is ready */
>> @@ -92,6 +102,115 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>   	return;
>>   }
>>   
>> +static int __init acpi_parse_madt(struct acpi_table_header *table)
>> +{
>> +	struct acpi_table_madt *madt = NULL;
> No need to initialize this to NULL, you're doing an assignment at the
> next line...
>
>> +
>> +	madt = (struct acpi_table_madt *)table;
>> +	if (!madt) {
>> +		pr_warn(PREFIX "Unable to map MADT\n");
> There is no mapping here, please fix the message accordingly.

Ok, I will address your comments above in next version.
>
>> +		return -ENODEV;
>> +	}
>> +
>> +	if (madt->address) {
>> +		acpi_lapic_addr = (u64) madt->address;
> So you're updating this static variable, for the distributor and each
> CPU interface? /me puzzled...

Good catch. So I have a question: do we really have some SoCs
without banked registers on ARM64? if not , I think we can use
a single static variable is ok.

>
>> +		pr_info(PREFIX "Local APIC address 0x%08x\n", madt->address);
> Away with this APIC madness. GICC and GICD are the concepts we're all
> familiar with here, and using the proper terminology would certainly
> help reviewing these patches...

That make sense to me too, will update.

>
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * GIC structures on ARM are somthing like Local APIC structures on x86,
>> + * which means GIC cpu interfaces for GICv2/v3. Every GIC structure in
>> + * MADT table represents a cpu in the system.
> And what do you do when your GICv3 doesn't have a memory-mapped
> interface, but only uses system registers?
>
>> + * GIC distributor structures are somthing like IOAPIC on x86. GIC can
>> + * be initialized with information in this structure.
>> + *
>> + * Please refer to chapter5.2.12.14/15 of ACPI 5.0
> A pointer to that documentation?

Please refer to http://www.acpi.info/

>
>> + */
>> +
>> +static int __init
>> +acpi_parse_gic(struct acpi_subtable_header *header, const unsigned long end)
>> +{
>> +	struct acpi_madt_generic_interrupt *processor = NULL;
>> +
>> +	processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> +	if (BAD_MADT_ENTRY(processor, end))
>> +		return -EINVAL;
>> +
>> +	acpi_table_print_madt_entry(header);
>> +
>> +	return 0;
>> +}
>> +
>> +static int __init
>> +acpi_parse_gic_distributor(struct acpi_subtable_header *header,
>> +				const unsigned long end)
>> +{
>> +	struct acpi_madt_generic_distributor *distributor = NULL;
>> +
>> +	distributor = (struct acpi_madt_generic_distributor *)header;
>> +
>> +	if (BAD_MADT_ENTRY(distributor, end))
>> +		return -EINVAL;
>> +
>> +	acpi_table_print_madt_entry(header);
>> +
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC cpu interface related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_entries(void)
>> +{
>> +	int count;
>> +
>> +	/*
>> +	 * do a partial walk of MADT to determine how many CPUs
>> +	 * we have including disabled CPUs
>> +	 */
>> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
>> +				acpi_parse_gic, MAX_GIC_CPU_INTERFACE);
>> +
>> +	if (!count) {
>> +		pr_err(PREFIX "No GIC entries present\n");
>> +		return -ENODEV;
>> +	} else if (count < 0) {
>> +		pr_err(PREFIX "Error parsing GIC entry\n");
>> +		return count;
>> +	}
> So you do a lot of parsing to count stuff, and then discard the number
> of counted objects... You might as well check that there is at least one
> valid object and stop there.
>
>> +	return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC distributor related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_distributor_entries(void)
>> +{
>> +	int count;
>> +
>> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
>> +			acpi_parse_gic_distributor, MAX_GIC_DISTRIBUTOR);
>> +
>> +	if (!count) {
>> +		pr_err(PREFIX "No GIC distributor entries present\n");
>> +		return -ENODEV;
>> +	} else if (count < 0) {
>> +		pr_err(PREFIX "Error parsing GIC distributor entry\n");
>> +		return count;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>>   int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
>>   {
>>   	*irq = gsi_to_irq(gsi);
>> @@ -141,11 +260,29 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>   
>>   static void __init early_acpi_process_madt(void)
>>   {
>> -	return;
>> +	acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt);
>>   }
>>   
>>   static void __init acpi_process_madt(void)
>>   {
>> +	int error;
>> +
>> +	if (!acpi_table_parse(ACPI_SIG_MADT, acpi_parse_madt)) {
> How many times are you going to parse the same table? Surely you can
> stash whatever information you need and be done with it?

good catch, we already addressed this problem, and will
update in next version.

>
>> +		/*
>> +		 * Parse MADT GIC cpu interface entries
>> +		 */
>> +		error = acpi_parse_madt_gic_entries();
>> +		if (!error) {
>> +			/*
>> +			 * Parse MADT GIC distributor entries
>> +			 */
>> +			acpi_parse_madt_gic_distributor_entries();
>> +		}
>> +	}
>> +
>> +	pr_info("Using ACPI for processor (GIC) configuration information\n");
>> +
>>   	return;
>>   }
>>   
>> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>> index d67a1fe..b3e4615 100644
>> --- a/drivers/acpi/tables.c
>> +++ b/drivers/acpi/tables.c
>> @@ -191,6 +191,27 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>>   		}
>>   		break;
>>   
>> +	case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
>> +		{
>> +			struct acpi_madt_generic_interrupt *p =
>> +				(struct acpi_madt_generic_interrupt *)header;
>> +			printk(KERN_INFO PREFIX
> Use pr_info

this function use printk always, should change all of them?

>
>> +			       "GIC (acpi_id[0x%04x] gic_id[0x%04x] %s)\n",
>> +			       p->uid, p->gic_id,
>> +			       (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
>> +		}
>> +		break;
>> +
>> +	case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
>> +		{
>> +			struct acpi_madt_generic_distributor *p =
>> +				(struct acpi_madt_generic_distributor *)header;
>> +			printk(KERN_INFO PREFIX
>> +			       "GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
>> +			       p->gic_id, p->base_address, p->global_irq_base);
>> +		}
>> +		break;
>> +
>>   	default:
>>   		printk(KERN_WARNING PREFIX
>>   		       "Found unsupported MADT entry (type = 0x%x)\n",
>>
> Most of that code seems to be repeatedly parsing and printing stuff, and
> I fail to see what it actually does.

yes, just print some information when booting.

Thank you very much for the comments.

Hanjun

  reply	other threads:[~2014-01-24 15:34 UTC|newest]

Thread overview: 86+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-17 12:24 [PATCH 00/20] Make ACPI core running on ARM64 Hanjun Guo
2014-01-17 12:24 ` [PATCH 01/20] ARM64 / ACPI: Make PCI optional for ACPI " Hanjun Guo
2014-01-17 16:00   ` Bjorn Helgaas
2014-01-20  9:33     ` Hanjun Guo
2014-01-17 12:24 ` [PATCH 02/20] ARM64 : Add dummy asm/cpu.h Hanjun Guo
2014-01-17 14:22   ` Sudeep Holla
2014-01-20  8:58     ` Hanjun Guo
2014-01-23 16:15   ` Catalin Marinas
2014-01-24 14:41     ` Hanjun Guo
2014-01-17 12:24 ` [PATCH 03/20] ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64 Hanjun Guo
2014-01-17 14:25   ` Sudeep Holla
2014-01-20  9:20     ` Hanjun Guo
2014-01-23 16:19       ` Catalin Marinas
2014-01-24 14:43         ` Hanjun Guo
2014-01-23 18:03   ` Catalin Marinas
2014-01-24 15:35     ` Hanjun Guo
2014-01-17 12:24 ` [PATCH 04/20] ARM64 / ACPI: Introduce arm_core.c and its related head file Hanjun Guo
2014-01-17 14:12   ` Will Deacon
2014-01-18  4:05     ` Hanjun Guo
2014-01-17 16:56   ` Sudeep Holla
2014-01-20 12:26     ` Hanjun Guo
2014-01-22 11:54   ` Lorenzo Pieralisi
2014-01-23 15:56     ` [Linaro-acpi] " Tomasz Nowicki
2014-01-24  9:09       ` Hanjun Guo
2014-01-24 12:53         ` Lorenzo Pieralisi
2014-01-24 16:44           ` Tomasz Nowicki
2014-01-17 12:24 ` [PATCH 05/20] ARM64 / ACPI: Introduce lowlevel suspend function Hanjun Guo
2014-01-17 12:25 ` [PATCH 06/20] ARM64 / ACPI: Introduce some PCI functions when PCI is enabled Hanjun Guo
2014-01-17 14:04   ` Arnd Bergmann
2014-01-20  8:08     ` Hanjun Guo
2014-01-20  8:20       ` Arnd Bergmann
2014-01-20 14:13         ` Hanjun Guo
2014-01-20 18:39           ` Arnd Bergmann
2014-01-21  3:40             ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 07/20] ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo
2014-01-17 14:34   ` Sudeep Holla
2014-01-20  9:30     ` Hanjun Guo
2014-01-23 16:39   ` Catalin Marinas
2014-01-24 14:45     ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 08/20] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Hanjun Guo
2014-01-17 12:25 ` [PATCH 09/20] ARM64 / ACPI: Implement core functions for parsing MADT table Hanjun Guo
2014-01-17 14:12   ` Arnd Bergmann
2014-01-20  8:49     ` Hanjun Guo
2014-01-23 17:54   ` Marc Zyngier
2014-01-24 15:34     ` Hanjun Guo [this message]
2014-01-24 20:57       ` Arnd Bergmann
2014-01-17 12:25 ` [PATCH 10/20] ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id Hanjun Guo
2014-01-17 17:37   ` Sudeep Holla
2014-01-20 14:00     ` Hanjun Guo
2014-01-22 15:53   ` Lorenzo Pieralisi
2014-01-24 14:37     ` Hanjun Guo
2014-01-24 15:35       ` Lorenzo Pieralisi
2014-01-24 16:02         ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 11/20] ARM64 / ACPI: Get the enable method for SMP initialization Hanjun Guo
2014-01-23 17:50   ` Catalin Marinas
2014-01-24 14:57     ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 12/20] ARM64 / ACPI: Use Parked Address in GIC structure for spin table SMP initialisation Hanjun Guo
2014-01-17 14:15   ` Arnd Bergmann
2014-01-17 14:35     ` Tomasz Nowicki
2014-01-17 12:25 ` [PATCH 13/20] ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm Hanjun Guo
2014-01-17 12:25 ` [PATCH 14/20] Irqchip / gic: Set as default domain so we can access from ACPI Hanjun Guo
2014-01-17 12:25 ` [PATCH 15/20] ACPI / ARM64: Update acpi_register_gsi to register with the core IRQ subsystem Hanjun Guo
2014-01-17 12:25 ` [PATCH 17/20] clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer Hanjun Guo
2014-01-27 11:26   ` Mark Rutland
2014-01-17 12:25 ` [PATCH 18/20] clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE Hanjun Guo
2014-01-17 14:21   ` Arnd Bergmann
2014-01-20  9:08     ` Hanjun Guo
2014-01-22 11:46       ` Mark Rutland
2014-01-22 14:56         ` Arnd Bergmann
2014-01-22 15:17           ` Mark Rutland
2014-01-22 15:47             ` Arnd Bergmann
2014-01-24  9:19           ` Hanjun Guo
2014-01-24  0:46         ` Hanjun Guo
2014-01-22  8:26   ` Linus Walleij
2014-01-22 11:45     ` Mark Rutland
2014-01-22 14:38       ` Linus Walleij
2014-01-24  0:20       ` Hanjun Guo
2014-01-24 12:08         ` Mark Rutland
2014-01-24 15:15           ` Catalin Marinas
2014-01-24 15:44             ` Mark Rutland
2014-01-24 15:53             ` Hanjun Guo
2014-01-24  0:12     ` Hanjun Guo
2014-01-24 12:32       ` Mark Rutland
2014-01-24 15:45         ` Hanjun Guo
2014-01-17 12:25 ` [PATCH 19/20] clocksource / ACPI: Introduce clocksource_acpi_init() using CLOCKSOURCE_ACPI_DECLARE Hanjun Guo
2014-01-17 12:25 ` [PATCH 20/20] ARM64 / clocksource: Use clocksource_acpi_init() 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=52E287EE.70407@linaro.org \
    --to=hanjun.guo@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).