- Linaro-acpi - lists.linaro.org

[PATCH 0/3] updates to linaro-image-lamp for better ACPI testing

by Graeme Gregory

Hi, Just a small series to enable better testing of ACPI in LAVA without having to fetch and built test suites with git. Thanks Graeme

10 years, 7 months

1
3
0 0

[PATCH 1/3] ACPI / processor: Update the comments in processor.h

by Hanjun Guo

In commit 46ba51e (ACPI / processor: Introduce ARCH_MIGHT_HAVE_ACPI_PDC), acpi_processor_set_pdc() was moved to processor_pdc.c, so update the comments accordingly. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- include/acpi/processor.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/acpi/processor.h b/include/acpi/processor.h index 9b9b6f2..cbb6cd3 100644 --- a/include/acpi/processor.h +++ b/include/acpi/processor.h @@ -313,11 +313,13 @@ static inline int acpi_processor_get_bios_limit(int cpu, unsigned int *limit) #endif /* CONFIG_CPU_FREQ */ /* in processor_core.c */ -void acpi_processor_set_pdc(acpi_handle handle); int acpi_get_apicid(acpi_handle, int type, u32 acpi_id); int acpi_map_cpuid(int apic_id, u32 acpi_id); int acpi_get_cpuid(acpi_handle, int type, u32 acpi_id); +/* in processor_pdc.c */ +void acpi_processor_set_pdc(acpi_handle handle); + /* in processor_throttling.c */ int acpi_processor_tstate_has_changed(struct acpi_processor *pr); int acpi_processor_get_throttling_info(struct acpi_processor *pr); -- 1.7.9.5

10 years, 7 months

3
9
0 0

leg-kernel tag leg-20141118.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401118.0 This is based on mainline kernel v3.18-rc5 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/380ad5d8817a03204e6a92… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea… 2) This release merges the Mustang support from Redhat/APM https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-mus… 3) This release disables STRICT_DEVMEM in distribution.conf, this is needed to work on FWTS for the short term and should not be considered a production change.

10 years, 7 months

1
0
0 0

[RFC PATCH 0/4] MMCFG refactoring + PCI ACPI probing for ARM64

by Tomasz Nowicki

The patch set can be break down into two logic parts: 1. patch 1,2 - MMCONFIG code refacoring. MMCFG ACPI table has no arch dependencies so it can be used across other architectures. 2. patch 3,4 aim for PCI ACPI probing on ARM64 Patches tested on Cavium ThunderX simulator with the latest ACPI ARM64 core set: http://www.serverphorums.com/read.php?12,997228 Tomasz Nowicki (4): x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/ directory. x86, acpi, pci: Isolate new PCI mmconfig entry insertion. arm64, acpi, pci: Add arch specific functions for mmconfig driver. arm64, acpi, pci: Provide arch-specific calls for PCI host bridge dirver (PNP0A03). arch/arm64/Kconfig | 3 + arch/arm64/include/asm/pci.h | 8 + arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/mmconfig.c | 69 +++++++ arch/arm64/kernel/pci.c | 401 +++++++++++++++++++++++++++++++++++++++-- arch/x86/include/asm/pci_x86.h | 29 --- arch/x86/pci/acpi.c | 1 + arch/x86/pci/init.c | 1 + arch/x86/pci/mmconfig-shared.c | 176 +----------------- arch/x86/pci/mmconfig_32.c | 1 + arch/x86/pci/mmconfig_64.c | 1 + drivers/acpi/Makefile | 1 + drivers/acpi/bus.c | 1 + drivers/acpi/mmconfig.c | 204 +++++++++++++++++++++ include/linux/mmconfig.h | 57 ++++++ include/linux/pci.h | 8 - 16 files changed, 738 insertions(+), 224 deletions(-) create mode 100644 arch/arm64/kernel/mmconfig.c create mode 100644 drivers/acpi/mmconfig.c create mode 100644 include/linux/mmconfig.h -- 1.9.1

10 years, 7 months

3
16
0 0

[PATCH] acpi: ignore FACS table missing, if HW_REDUCED_ACPI is set.

by Fu Wei

acpi: ignore FACS table missing, if HW_REDUCED_ACPI is set. (ACPI Revision 5.1 Errata A) Signed-off-by: Fu Wei <fu.wei(a)linaro.org> --- src/lib/include/fwts_acpi.h | 1 + src/lib/src/fwts_acpi_tables.c | 13 ++++++++++--- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/src/lib/include/fwts_acpi.h b/src/lib/include/fwts_acpi.h index 24ebc84..73a3461 100644 --- a/src/lib/include/fwts_acpi.h +++ b/src/lib/include/fwts_acpi.h @@ -46,6 +46,7 @@ extern const char *fwts_acpi_fadt_preferred_pm_profile[]; #define FWTS_ACPI_FADT_PREFERRED_PM_PROFILE(x) \ ((x) > 8) ? "Reserved" : fwts_acpi_fadt_preferred_pm_profile[x] +#define FWTS_ACPI_FADT_FLAGS_HW_REDUCED_ACPI (1<<20) /* 5.2.3.1 Generic Address Structure */ typedef struct { diff --git a/src/lib/src/fwts_acpi_tables.c b/src/lib/src/fwts_acpi_tables.c index 56498e0..41cf6ea 100644 --- a/src/lib/src/fwts_acpi_tables.c +++ b/src/lib/src/fwts_acpi_tables.c @@ -311,7 +311,7 @@ static int fwts_acpi_handle_fadt_tables( } /* Is it sane? */ if (addr == 0) { - fwts_log_error(fw, "Failed to load %s: Cannot determine " + fwts_log_warning(fw, "Failed to load %s: Cannot determine " "address of %s from FADT, fields %s and %s are zero.", name, name, name_addr32, name_addr64); return FWTS_ERROR; @@ -320,7 +320,7 @@ static int fwts_acpi_handle_fadt_tables( addr = (off_t)*addr32; /* Is it sane? */ if (addr == 0) { - fwts_log_error(fw, "Failed to load %s: Cannot determine " + fwts_log_warning(fw, "Failed to load %s: Cannot determine " "address of %s from FADT, field %s is zero.", name, name, name_addr32); return FWTS_ERROR; @@ -375,12 +375,19 @@ static int fwts_acpi_handle_fadt( "FACS", "FIRMWARE_CTRL", "X_FIRMWARE_CTRL", &fadt->firmware_control, &fadt->x_firmware_ctrl, provenance) != FWTS_OK) { - return FWTS_ERROR; + if (fadt->flags && FWTS_ACPI_FADT_FLAGS_HW_REDUCED_ACPI) { + fwts_log_info(fw, "IGNORE the missing FACS " + "in Hardware-reduced ACPI"); + } else { + fwts_log_error(fw, "Missing FACS!"); + return FWTS_ERROR; + } } /* Determine DSDT addr and load it */ if (fwts_acpi_handle_fadt_tables(fw, fadt, "DSDT", "DSTD", "X_DSDT", &fadt->dsdt, &fadt->x_dsdt, provenance) != FWTS_OK) { + fwts_log_error(fw, "Failed to load DSDT!"); return FWTS_ERROR; } return FWTS_OK; -- 1.9.1

10 years, 7 months

1
1
0 0

[PATCH v10 0/1] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V9: - Default to PCC subspace headers as defined in ACPI v5.1 Changes since V8: - Removed unncessary header files. - Added kerneldoc comments. - Added intro about PCC in pcc.c Changes since V7: - Added timeout to tx method in case the remote dies. - Restructured usage of acpi_status. Had inverted logic previously. Changes since V6: - Cosmetic changes based on Lv's suggestions Changes since V5: - Optimize loop that matches channel request. - Use platform_create_bundle. - Replace ioread/writes. - Remove redundant code and headers. - Restructure common mailbox macros. - Reformat PCC cmd parsing. Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (1): Mailbox: Add support for Platform Communication Channel drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 +- drivers/mailbox/mailbox.h | 16 ++ drivers/mailbox/pcc.c | 367 ++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 398 insertions(+), 3 deletions(-) create mode 100644 drivers/mailbox/mailbox.h create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 7 months

5
41
0 0

A new fwts test result (using the latest leg kernel)

by Fu Wei

Hi our dear ACPI experts, I ran my ci job yesterday night. then I run a test on my new leg Image, because I recompiled the FWTS in the test , so the test took a long time. https://validation.linaro.org/scheduler/job/198839/log_file The result.log is attached. UPDATE: (1)disabling STATIC_DEVMEM is working, it's not a blocker for FWTS in short term. (2)we test the latest kernel, so the result should be better Please let me know what are the rest problem we need to fix , according to the test log. Great thanks for your time! -- Best regards, Fu Wei Software Engineer From Red Hat LEG Team Linaro.org | Open source software for ARM SoCs Ph: +86 186 2020 4684 (mobile) IRC: fuwei Skype: tekkamanninja Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021

10 years, 7 months

1
0
0 0

leg-kernel tag leg-20141111.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401111.0 This is based on mainline kernel v3.18-rc4 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/1a315a2d7b69d1b9c9c49… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea… 2) This release merges the Mustang support from Redhat/APM https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-mus… 3) This release disables STRICT_DEVMEM in distribution.conf, this is needed to work on FWTS for the short term and should not be considered a production change.

10 years, 7 months

1
0
0 0

[PATCH] mailbox: enable non-DT/ACPI clients to use the api

by Jassi Brar

The Mailbox API so far discounted controllers and clients that may not have a DT based channel mapping capability, as in ACPI. Allow such mailbox clients to ask for a mailbox channel by simply specifying a token. The token would be globally unique among channels provided by such controllers... which shouldn't be a problem because practically non-DT means ACPI and ACPI specifies just one controller instance called the Platform Communications Channel (PCC) that could have max 256 subspaces (channels or mailboxes). So this is simply going to be the value from 'Signature' field (first 4bytes) of the SharedMemory Region corresponding to the subspace/channel the client is interested in. Signed-off-by: Jassi Brar <jaswinder.singh(a)linaro.org> --- drivers/mailbox/mailbox.c | 50 +++++++++++++++++++++----------------- include/linux/mailbox_controller.h | 7 ++++++ 2 files changed, 35 insertions(+), 22 deletions(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index afcb430..8260451 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -296,36 +296,42 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index) { struct device *dev = cl->dev; struct mbox_controller *mbox; - struct of_phandle_args spec; - struct mbox_chan *chan; + struct mbox_chan *chan = NULL; unsigned long flags; int ret; - if (!dev || !dev->of_node) { - pr_debug("%s: No owner device node\n", __func__); - return ERR_PTR(-ENODEV); - } - mutex_lock(&con_mutex); - if (of_parse_phandle_with_args(dev->of_node, "mboxes", - "#mbox-cells", index, &spec)) { - dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", __func__); - mutex_unlock(&con_mutex); - return ERR_PTR(-ENODEV); - } - - chan = NULL; - list_for_each_entry(mbox, &mbox_cons, node) - if (mbox->dev->of_node == spec.np) { - chan = mbox->of_xlate(mbox, &spec); - break; + if (!dev || !dev->of_node) { /* If it's an ACPI client */ + list_for_each_entry(mbox, &mbox_cons, node) { + if (!mbox->global_xlate) + continue; + chan = mbox->global_xlate(mbox, index); + if (chan && !chan->cl) + break; + } + } else { + struct of_phandle_args spec; + + if (of_parse_phandle_with_args(dev->of_node, "mboxes", + "#mbox-cells", index, &spec)) { + dev_dbg(dev, "%s: can't parse \"mboxes\" property\n", + __func__); + mutex_unlock(&con_mutex); + return ERR_PTR(-ENODEV); } - of_node_put(spec.np); + list_for_each_entry(mbox, &mbox_cons, node) + if (mbox->dev->of_node == spec.np) { + chan = mbox->of_xlate(mbox, &spec); + break; + } + + of_node_put(spec.np); + } if (!chan || chan->cl || !try_module_get(mbox->dev->driver->owner)) { - dev_dbg(dev, "%s: mailbox not free\n", __func__); + pr_err("%s: mailbox not available\n", __func__); mutex_unlock(&con_mutex); return ERR_PTR(-EBUSY); } @@ -344,7 +350,7 @@ struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index) ret = chan->mbox->ops->startup(chan); if (ret) { - dev_err(dev, "Unable to startup the chan (%d)\n", ret); + pr_err("Unable to startup the chan (%d)\n", ret); mbox_free_channel(chan); chan = ERR_PTR(ret); } diff --git a/include/linux/mailbox_controller.h b/include/linux/mailbox_controller.h index d4cf96f..76871b2 100644 --- a/include/linux/mailbox_controller.h +++ b/include/linux/mailbox_controller.h @@ -67,6 +67,11 @@ struct mbox_chan_ops { * @txpoll_period: If 'txdone_poll' is in effect, the API polls for * last TX's status after these many millisecs * @of_xlate: Controller driver specific mapping of channel via DT + * @global_xlate: Controller driver specific mapping of channel for + * non-DT based clients (like ACPI). The 'global_id' + * argument is a token to uniquely identify the mbox_chan + * fromm those provided by more than one such controllers. + * 'of_xlate' takes precedence for DT based clients. * @poll: API private. Used to poll for TXDONE on all channels. * @node: API private. To hook into list of controllers. */ @@ -80,6 +85,8 @@ struct mbox_controller { unsigned txpoll_period; struct mbox_chan *(*of_xlate)(struct mbox_controller *mbox, const struct of_phandle_args *sp); + struct mbox_chan *(*global_xlate)(struct mbox_controller *mbox, + int global_id); /* Internal to API */ struct timer_list poll; struct list_head node; -- 1.8.1.2

10 years, 7 months

1
0
0 0

leg-kernel tag leg-20141107.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401107.0 This is based on mainline kernel v3.18-rc3 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/0aab83c05d7f2dc467d76… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea… 2) This release disables STRICT_DEVMEM in distribution.conf, this is needed to work on FWTS for the short term and should not be considered a production change.

10 years, 7 months

1
0
0 0

leg-kernel tag leg-20141106.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401106.0 This is based on mainline kernel v3.18-rc3 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/91d55a0bbfc3548e3a09e… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea…

10 years, 7 months

1
0
0 0

[PATCH v9] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V8: - Removed unncessary header files. - Added kerneldoc comments. - Added intro about PCC in pcc.c Changes since V7: - Added timeout to tx method in case the remote dies. - Restructured usage of acpi_status. Had inverted logic previously. Changes since V6: - Cosmetic changes based on Lv's suggestions Changes since V5: - Optimize loop that matches channel request. - Use platform_create_bundle. - Replace ioread/writes. - Remove redundant code and headers. - Restructure common mailbox macros. - Reformat PCC cmd parsing. Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (1): Mailbox: Add support for Platform Communication Channel drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 +- drivers/mailbox/mailbox.h | 16 ++ drivers/mailbox/pcc.c | 369 ++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 400 insertions(+), 3 deletions(-) create mode 100644 drivers/mailbox/mailbox.h create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 7 months

1
3
0 0

leg-kernel tag leg-20141105.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401105.0 This is based on mainline kernel v3.18-rc3 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/664f66862558283aab860… Notes :-

10 years, 7 months

1
0
0 0

[RFC PATCH 3/7] hw/arm/virt-acpi: Generate RSDP and XSDT, add helper functions

by Alexander Spyridakis

RSDP points to XSDT which in turn points to other tables. In the case of RSDP things are straightforward as we can point to XSDT just by adding the binary blob base address plus the size of RSDP. For XSDT we traverse the table array and point every other table by calculating their size (exception being FACS and DSDT which are pointed from FADT). Finally implement a common header and checksum helper functions for usage in all generated ACPI tables. Signed-off-by: Alexander Spyridakis <a.spyridakis(a)virtualopensystems.com> Signed-off-by: Alvise Rigo <a.rigo(a)virtualopensystems.com> --- hw/arm/virt-acpi.c | 93 +++++++++++++++++++++++++++++++++++++++++++-- include/hw/acpi/acpi-defs.h | 9 +++++ include/hw/arm/virt-acpi.h | 6 +++ 3 files changed, 104 insertions(+), 4 deletions(-) diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c index 5c8df45..0d7bb99 100644 --- a/hw/arm/virt-acpi.c +++ b/hw/arm/virt-acpi.c @@ -21,16 +21,101 @@ static void *acpi_table[NUM_ACPI_TABLES]; static int acpi_size[NUM_ACPI_TABLES]; +/* + * Many of the ACPI tables use the same header structure + * This is a common function to fill such information. + */ +static void acpi_fill_common_header_data(void *table, const char *signature, + uint8_t revision, int length) +{ + AcpiTableHeader *h = (AcpiTableHeader *)table; + + memcpy(&h->signature, signature, sizeof(h->signature)); + memcpy(h->oem_id, ACPI_VIRT_QEMU_STR_4, sizeof(h->oem_id)); + memcpy(h->oem_table_id, ACPI_VIRT_MACH_STR_8, sizeof(h->oem_table_id)); + h->revision = revision; + h->length = cpu_to_le32(length); +} + +/* + * Called at the very end of an ACPI table. + * Adding all the data bytes, plus the checksum should equal to zero. + */ +static void acpi_do_checksum(void *table, uint32_t length, uint8_t *checksum) +{ + uint8_t sum, *ptr; + + sum = 0; + ptr = table; + + *checksum = 0; + while (length--) { + sum = (uint8_t)(sum + (*ptr++)); + } + + ptr = table; + *checksum = (uint8_t) (0xff - sum + 1); +} + static void acpi_create_rsdp(void) { - acpi_table[RSDP] = NULL; - acpi_size[RSDP] = 0; + AcpiRsdpDescriptor *rsdp; + + rsdp = g_malloc0(sizeof(*rsdp)); + + /* Set table header information */ + memcpy(&rsdp->signature, "RSD PTR ", sizeof(rsdp->signature)); + memcpy(rsdp->oem_id, ACPI_VIRT_QEMU_STR_6, sizeof(rsdp->oem_id)); + rsdp->length = cpu_to_le32(sizeof(*rsdp)); + rsdp->revision = 0x02; + + /* Point to XSDT */ + rsdp->xsdt_physical_address = cpu_to_le64(ACPI_BASE_ADDRESS + rsdp->length); + + /* Calculate normal and extended checksum */ + acpi_do_checksum(rsdp, + offsetof(AcpiRsdpDescriptor, length), &rsdp->checksum); + acpi_do_checksum(rsdp, rsdp->length, &rsdp->extended_checksum); + + acpi_table[RSDP] = (void *)rsdp; + acpi_size[RSDP] = rsdp->length; } static void acpi_create_xsdt(void) { - acpi_table[XSDT] = NULL; - acpi_size[XSDT] = 0; + AcpiXsdtDescriptor *xsdt; + int i, xsdt_size; + + /* + * The final size of XSDT is the table size plus the number + * of pointed tables multiplied by the table_offset_entry size. + * + * The initial xsdt table size already includes one pointed table and + * assuming that FADT is the last pointed table we can calculate the + * total based on that. + */ + xsdt_size = sizeof(*xsdt) + + ((FADT - (XSDT + 1)) * sizeof(xsdt->table_offset_entry)); + xsdt = g_malloc0(xsdt_size); + + /* Set table header information */ + acpi_fill_common_header_data(xsdt, "XSDT", 1, xsdt_size); + + /* Point first table included by default in the xsdt structure */ + xsdt->table_offset_entry[0] = cpu_to_le64( + ACPI_BASE_ADDRESS + acpi_size[RSDP] + xsdt->length); + + /* Point all other tables (excluding FACS and DSDT) */ + for (i = XSDT; i < FADT - 1; i++) { + xsdt->table_offset_entry[i] = + xsdt->table_offset_entry[i - 1] + acpi_size[i + 1]; + } + + /* Calculate checksum */ + acpi_do_checksum(xsdt, xsdt->length, &xsdt->checksum); + + acpi_table[XSDT] = (void *)xsdt; + acpi_size[XSDT] = xsdt->length; } static void acpi_create_madt(uint32_t smp_cpus, diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h index c4468f8..779f872 100644 --- a/include/hw/acpi/acpi-defs.h +++ b/include/hw/acpi/acpi-defs.h @@ -88,6 +88,15 @@ struct AcpiTableHeader /* ACPI common table header */ typedef struct AcpiTableHeader AcpiTableHeader; /* + * Extended System Description Table (XSDT) + */ +struct AcpiXsdtDescriptor { + ACPI_TABLE_HEADER_DEF + uint64_t table_offset_entry[1]; /* Array of pointers to ACPI tables */ +} QEMU_PACKED; +typedef struct AcpiXsdtDescriptor AcpiXsdtDescriptor; + +/* * ACPI 1.0 Fixed ACPI Description Table (FADT) */ struct AcpiFadtDescriptorRev1 diff --git a/include/hw/arm/virt-acpi.h b/include/hw/arm/virt-acpi.h index 5098118..66a73eb 100644 --- a/include/hw/arm/virt-acpi.h +++ b/include/hw/arm/virt-acpi.h @@ -23,6 +23,12 @@ #define NUM_ACPI_TABLES 7 +#define ACPI_VIRT_QEMU_STR_4 "QEMU" +#define ACPI_VIRT_QEMU_STR_6 "QEMU " +#define ACPI_VIRT_MACH_STR_8 "MACHVIRT" + +#define ACPI_BASE_ADDRESS 0x47000000 + enum { RSDP, XSDT, -- 1.9.1

10 years, 8 months

1
0
0 0

[RFC PATCH 5/7] hw/arm/virt-acpi: GIC and Arch Timer definitions in MADT and GTDT

by Alexander Spyridakis

ACPI v5.1 defines GTDT for ARM devices as a place to describe timer related information in the system. MADT is also updated with a number of relevant subtables that can describe GIC enabled ARM platforms. For GTDT the Arch Timer interrupts must be provided, in the case of MADT the GICC and GICD subtables are used to define the GIC regions. Signed-off-by: Alexander Spyridakis <a.spyridakis(a)virtualopensystems.com> --- hw/arm/virt-acpi.c | 65 +++++++++++++++++++++++++++++++++++++--- include/hw/acpi/acpi-defs.h | 73 ++++++++++++++++++++++++++++++++++++++++++++- include/hw/arm/virt-acpi.h | 6 ++++ 3 files changed, 139 insertions(+), 5 deletions(-) diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c index aca0434..a53a620 100644 --- a/hw/arm/virt-acpi.c +++ b/hw/arm/virt-acpi.c @@ -121,14 +121,71 @@ static void acpi_create_xsdt(void) static void acpi_create_madt(uint32_t smp_cpus, const struct acpi_madt_info *info) { - acpi_table[MADT] = NULL; - acpi_size[MADT] = 0; + AcpiMultipleApicTable *madt; + AcpiMadtGenericInterrupt *gicc; + AcpiMadtGenericDistributor *gicd; + int i, madt_size; + + madt_size = sizeof(*madt) + (smp_cpus * sizeof(*gicc) + sizeof(*gicd)); + madt = g_malloc0(madt_size); + + acpi_fill_common_header_data(madt, "APIC", 1, madt_size); + + madt->local_apic_address = *info->gic_cpu_base_addr; + + /* Point at the end of the madt structure */ + gicc = (AcpiMadtGenericInterrupt *)(madt + 1); + + /* GICC subtable, one for each cpu in the guest*/ + for (i = 0; i < smp_cpus; i++) { + gicc->type = ACPI_APIC_GENERIC_INTERRUPT; + gicc->length = sizeof(*gicc); + + gicc->base_address = *info->gic_cpu_base_addr; + gicc->cpu_interface_number = i; + gicc->arm_mpidr = i; + gicc->uid = i; + gicc->flags = 0x01; + + gicc++; + } + + /* GIC Distributor subtable */ + gicd = (AcpiMadtGenericDistributor *)(gicc); + gicd->type = ACPI_APIC_GENERIC_DISTRIBUTOR; + gicd->length = sizeof(*gicd); + gicd->base_address = *info->gic_dist_base_addr; + + acpi_do_checksum(madt, madt->length, &madt->checksum); + + acpi_table[MADT] = (void *)madt; + acpi_size[MADT] = madt->length; } static void acpi_create_gtdt(const struct acpi_gtdt_info *irqs) { - acpi_table[GTDT] = NULL; - acpi_size[GTDT] = 0; + AcpiGenericTimerTable *gtdt; + + gtdt = g_malloc0(sizeof(*gtdt)); + acpi_fill_common_header_data(gtdt, "GTDT", 1, sizeof(*gtdt)); + + /* The interrupt values are the same with the device tree when adding 16 */ + gtdt->secure_el1_interrupt = irqs->timer_s_el1; + gtdt->secure_el1_flags = ACPI_EDGE_SENSITIVE; + + gtdt->non_secure_el1_interrupt = irqs->timer_ns_el1; + gtdt->non_secure_el1_flags = ACPI_EDGE_SENSITIVE; + + gtdt->virtual_timer_interrupt = irqs->timer_virt; + gtdt->virtual_timer_flags = ACPI_EDGE_SENSITIVE; + + gtdt->non_secure_el2_interrupt = irqs->timer_ns_el2; + gtdt->non_secure_el2_flags = ACPI_EDGE_SENSITIVE; + + acpi_do_checksum(gtdt, gtdt->length, &gtdt->checksum); + + acpi_table[GTDT] = (void *)gtdt; + acpi_size[GTDT] = gtdt->length; } static void acpi_create_fadt(void) diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h index ebbd2d0..f5e5222 100644 --- a/include/hw/acpi/acpi-defs.h +++ b/include/hw/acpi/acpi-defs.h @@ -257,7 +257,13 @@ typedef struct AcpiMultipleApicTable AcpiMultipleApicTable; #define ACPI_APIC_IO_SAPIC 6 #define ACPI_APIC_LOCAL_SAPIC 7 #define ACPI_APIC_XRUPT_SOURCE 8 -#define ACPI_APIC_RESERVED 9 /* 9 and greater are reserved */ +#define ACPI_APIC_LOCAL_X2APIC 9 +#define ACPI_APIC_LOCAL_X2APIC_NMI 10 +#define ACPI_APIC_GENERIC_INTERRUPT 11 +#define ACPI_APIC_GENERIC_DISTRIBUTOR 12 +#define ACPI_APIC_GENERIC_MSI_FRAME 13 +#define ACPI_APIC_GENERIC_REDISTRIBUTOR 14 +#define ACPI_APIC_RESERVED 15 /* 15 and greater are reserved */ /* * MADT sub-structures (Follow MULTIPLE_APIC_DESCRIPTION_TABLE) @@ -305,6 +311,71 @@ struct AcpiMadtLocalNmi { } QEMU_PACKED; typedef struct AcpiMadtLocalNmi AcpiMadtLocalNmi; +struct AcpiMadtGenericInterrupt { + ACPI_SUB_HEADER_DEF + uint16_t reserved; + uint32_t cpu_interface_number; + uint32_t uid; + uint32_t flags; + uint32_t parking_version; + uint32_t performance_interrupt; + uint64_t parked_address; + uint64_t base_address; + uint64_t gicv_base_address; + uint64_t gich_base_address; + uint32_t vgic_interrupt; + uint64_t gicr_base_address; + uint64_t arm_mpidr; +} QEMU_PACKED; +typedef struct AcpiMadtGenericInterrupt AcpiMadtGenericInterrupt; + +struct AcpiMadtGenericDistributor { + ACPI_SUB_HEADER_DEF + uint16_t reserved; + uint32_t gic_id; + uint64_t base_address; + uint32_t global_irq_base; + uint32_t reserved2; +} QEMU_PACKED; +typedef struct AcpiMadtGenericDistributor AcpiMadtGenericDistributor; + +/* + * Generic Timer Description Table (GTDT) + */ + +#define ACPI_GTDT_INTERRUPT_MODE (1) +#define ACPI_GTDT_INTERRUPT_POLARITY (1<<1) +#define ACPI_GTDT_ALWAYS_ON (1<<2) + +/* Triggering */ + +#define ACPI_LEVEL_SENSITIVE (uint8_t) 0x00 +#define ACPI_EDGE_SENSITIVE (uint8_t) 0x01 + +/* Polarity */ + +#define ACPI_ACTIVE_HIGH (uint8_t) 0x00 +#define ACPI_ACTIVE_LOW (uint8_t) 0x01 +#define ACPI_ACTIVE_BOTH (uint8_t) 0x02 + +struct AcpiGenericTimerTable { + ACPI_TABLE_HEADER_DEF + uint64_t counter_block_addresss; + uint32_t reserved; + uint32_t secure_el1_interrupt; + uint32_t secure_el1_flags; + uint32_t non_secure_el1_interrupt; + uint32_t non_secure_el1_flags; + uint32_t virtual_timer_interrupt; + uint32_t virtual_timer_flags; + uint32_t non_secure_el2_interrupt; + uint32_t non_secure_el2_flags; + uint64_t counter_read_block_address; + uint32_t platform_timer_count; + uint32_t platform_timer_offset; +} QEMU_PACKED; +typedef struct AcpiGenericTimerTable AcpiGenericTimerTable; + /* * HPET Description Table */ diff --git a/include/hw/arm/virt-acpi.h b/include/hw/arm/virt-acpi.h index 66a73eb..216a3a2 100644 --- a/include/hw/arm/virt-acpi.h +++ b/include/hw/arm/virt-acpi.h @@ -41,9 +41,15 @@ enum { }; struct acpi_gtdt_info { + uint32_t timer_virt; + uint32_t timer_s_el1; + uint32_t timer_ns_el1; + uint32_t timer_ns_el2; }; struct acpi_madt_info { + const hwaddr *gic_cpu_base_addr; + const hwaddr *gic_dist_base_addr; }; struct acpi_dsdt_info { -- 1.9.1

10 years, 8 months

1
0
0 0

[RFC PATCH 6/7] hw/arm/virt-acpi: Generation of DSDT including virt devices

by Alexander Spyridakis

DSDT consists of the usual common table header plus a definition block in AML encoding which describes all devices in the platform. After initializing DSDT with header information the namespace is created which is followed by the device encodings. The devices are described using the Resource Template for the 32-Bit Fixed Memory Range and the Extended Interrupt Descriptors. Additional helper functions are implemented to add devices with the Resource Template and calculating their multiple size fields which are not fixed. The following devices are included in the DSDT: - CPUs - UART - RTC - NAND Flash - virtio-mmio Signed-off-by: Alexander Spyridakis <a.spyridakis(a)virtualopensystems.com> --- hw/arm/virt-acpi.c | 284 +++++++++++++++++++++++++++++++++++++++++++- include/hw/acpi/acpi-defs.h | 34 ++++++ include/hw/arm/virt-acpi.h | 9 ++ 3 files changed, 325 insertions(+), 2 deletions(-) diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c index a53a620..be490e7 100644 --- a/hw/arm/virt-acpi.c +++ b/hw/arm/virt-acpi.c @@ -22,6 +22,258 @@ static void *acpi_table[NUM_ACPI_TABLES]; static int acpi_size[NUM_ACPI_TABLES]; /* + * Package length encoding: + * The package length can range from 1 to 4 bytes. For a package size less than + * 64, only 1 byte is needed, bits 0 - 5 represent the size and the rest should + * be zero. In case of larger package sizes, for the first byte (Package Lead + * Byte), bits 0 - 3 hold the least significant nibble of the size value, bits + * 4 - 5 are reserved and must be zero, bits 6 - 7 signify how many size bytes + * are following. + */ +static void *acpi_calc_size(uint8_t *buf, uint8_t *end, bool resource) +{ + uint8_t *ret, *ptr = buf; + unsigned int size = end - buf; + unsigned int i, shift, byte_num = 1; + + if (size < (1 << 6)) { + byte_num = 1; + } else if (size < (1 << 12)) { + byte_num = 2; + } else if (size < (1 << 20)) { + byte_num = 3; + } else if (size < (1 << 28)) { + byte_num = 4; + } + + if (resource) { + memmove(ptr + (byte_num * 2) + 1, buf, size); + size += (byte_num * 2) + 1; + } else { + memmove(ptr + byte_num, buf, size); + size += byte_num; + } + + *ptr++ = byte_num == 1 ? size : (size & 0x0F) | ((byte_num - 1) << 6); + + shift = 4; + for (i = 1; i < byte_num; i++) { + *ptr++ = size >> shift; + shift += 8; + } + + /* In the case of a resource template we have to add another size + * value just after the package size. This field needs to be + * prefixed by a byte signifying how many bytes the size is. */ + if (resource) { + switch (byte_num) { + case 1: + *ptr++ = ACPI_AML_BYTE_PREFIX; + break; + case 2: + *ptr++ = ACPI_AML_WORD_PREFIX; + break; + case 3: + *ptr++ = ACPI_AML_DWORD_PREFIX; + break; + case 4: + *ptr++ = ACPI_AML_QWORD_PREFIX; + break; + } + + shift = 0; + for (i = 0; i < byte_num; i++) { + *ptr++ = (size - byte_num - 2) >> shift; + shift += 8; + } + } + + ret = buf + size; + return ret; +} + +static void *acpi_dsdt_init_device(uint8_t *buf, const char *name, + const char *hid, int uid) +{ + uint8_t *ptr = buf; + + /* DeviceOp */ + *ptr++ = ACPI_AML_DEVICE_OP; + *ptr++ = ACPI_AML_OP_PREFIX; + + /* Device name */ + ptr = mempcpy(ptr, name, 4); + *ptr++ = ACPI_AML_NAME_OP; + + /* Hardware ID */ + ptr = mempcpy(ptr, "_HID", 4); + *ptr++ = ACPI_AML_STRING_PREFIX; + ptr = mempcpy(ptr, hid, 9); + *ptr++ = ACPI_AML_NAME_OP; + + /* Unique ID - Values greater than one need the byte prefix */ + ptr = mempcpy(ptr, "_UID", 4); + if (uid > 1) { + *ptr++ = ACPI_AML_BYTE_PREFIX; + } + *ptr++ = uid; + + return ptr; +} + +static void *acpi_add_res_memory32(uint8_t *buf, hwaddr addr, + hwaddr size, uint8_t rw_flag) +{ + AcpiAmlResourceFixedMemory32 *memory = (AcpiAmlResourceFixedMemory32 *)buf; + + memory->descriptor_type = ACPI_AML_RESOURCE_MEMORY32; + memory->resource_length = sizeof(*memory) - 3; + + memory->flags = rw_flag; + memory->address = addr; + memory->address_length = size; + + return (void *)memory + sizeof(*memory); +} + +static void *acpi_add_res_extended_irq(uint8_t *buf, uint8_t irq_flags, int irq) +{ + AcpiAmlResourceExtendedIrq *ext_irq = (AcpiAmlResourceExtendedIrq *)buf; + + ext_irq->descriptor_type = ACPI_AML_RESOURCE_EXTENDED_IRQ; + ext_irq->resource_length = sizeof(*ext_irq) - 3; + + ext_irq->flags = irq_flags; + ext_irq->interrupt_count = 0x01; + ext_irq->interrupts[0] = irq; + + return (void *)ext_irq + sizeof(*ext_irq); +} + +/* + * Create a device definition based on the ACPI ResourceTemplate: + * First the name, hardware and unique ID segments are created, + * then the resource template regions are added to define the + * address, size and interrupts of the device. + * Finally, the End Tag is used to signify the end of the device, + * and the total length is calculated. + */ +static void *acpi_dsdt_add_simple_resource(uint8_t *buf, const char *name, + const char *hid, int uid, + hwaddr base, hwaddr size, + int irq, uint8_t irq_flags) +{ + uint8_t *res_len, *ptr = buf; + + ptr = acpi_dsdt_init_device(ptr, name, hid, uid); + + /* Skip the creation of a resource template if it is not provided */ + if (!size && !irq) { + goto ret; + } + + /* Resource template */ + *ptr++ = ACPI_AML_NAME_OP; + ptr = mempcpy(ptr, "_CRS", 4); + *ptr++ = ACPI_AML_BUFFER_PREFIX; + + /* Point to resource size for later */ + res_len = ptr; + + /* Add resource template regions */ + if (size) { + ptr = acpi_add_res_memory32(ptr, base, size, 0x01); + } + if (irq) { + ptr = acpi_add_res_extended_irq(ptr, irq_flags, irq); + } + + /* End the resource template */ + *ptr++ = ACPI_AML_END_TAG; + *ptr++ = 0x00; + + /* Update resource size */ + ptr = acpi_calc_size(res_len, ptr, 1); + +ret: + /* Calculate total device size */ + ptr = acpi_calc_size(buf + 2, ptr, 0); + + return ptr; +} + +static void *acpi_dsdt_add_cpus(uint8_t *buf, int cpus) +{ + int i; + char name[5]; + uint8_t *ptr = buf; + + /* In the case of CPUs there is no need for a resource template */ + for (i = 0; i < cpus; i++) { + snprintf(name, 5, "CPU%u", i); + ptr = acpi_dsdt_add_simple_resource(ptr, name, "ACPI0007", + i, 0, 0, 0, 0); + } + + return ptr; +} + +static void *acpi_dsdt_add_uart(uint8_t *buf, const hwaddr *uart_addr, + const int *uart_irq) +{ + uint8_t *ptr = buf; + + ptr = acpi_dsdt_add_simple_resource(ptr, "COM0", "ARMH0011", 0, + uart_addr[0], uart_addr[1], *uart_irq + 32, 0x01); + return ptr; +} + +static void *acpi_dsdt_add_rtc(uint8_t *buf, const hwaddr *rtc_addrs, + const int *rtc_irq) +{ + uint8_t *ptr = buf; + int irq = *rtc_irq + 32; + + ptr = acpi_dsdt_add_simple_resource(ptr, "RTC0", "LNRO0013", 0, + rtc_addrs[0], rtc_addrs[1], irq, 0x01); + + return ptr; +} + +static void *acpi_dsdt_add_flash(uint8_t *buf, const hwaddr *flash_addrs) +{ + uint8_t *ptr = buf; + hwaddr base = flash_addrs[0]; + hwaddr size = flash_addrs[1]; + + ptr = acpi_dsdt_add_simple_resource(ptr, "FLS0", "LNRO0015", + 0, base, size, 0, 0); + ptr = acpi_dsdt_add_simple_resource(ptr, "FLS1", "LNRO0015", + 1, base + size, size, 0, 0); + return ptr; +} + +static void *acpi_dsdt_add_virtio(uint8_t *buf, const hwaddr *mmio_addrs, + const int *mmio_irq, int num) +{ + int i; + char name[5]; + uint8_t *ptr = buf; + hwaddr base = mmio_addrs[0]; + hwaddr size = mmio_addrs[1]; + int irq = *mmio_irq + 32; + + for (i = 0; i < num; i++) { + snprintf(name, 5, "VR%02u", i); + ptr = acpi_dsdt_add_simple_resource(ptr, name, "LNRO0005", + i, base, size, irq + i, 0x01); + base += size; + } + + return ptr; +} + +/* * Many of the ACPI tables use the same header structure * This is a common function to fill such information. */ @@ -235,8 +487,36 @@ static void acpi_create_facs(void) static void acpi_create_dsdt(int smp_cpus, const struct acpi_dsdt_info *info) { - acpi_table[DSDT] = NULL; - acpi_size[DSDT] = 0; + uint8_t *ptr; + AcpiTableHeader *header; + + /* As we don't know the size of DSDT beforehand, allocate a chunk of + * memory and pass this to all other calls that add device definitions */ + acpi_table[DSDT] = g_malloc0(ACPI_DSDT_MAX_SIZE); + ptr = acpi_table[DSDT]; + header = (AcpiTableHeader *)acpi_table[DSDT]; + + acpi_fill_common_header_data(ptr, "DSDT", 1, sizeof(AcpiTableHeader)); + ptr = acpi_table[DSDT] + sizeof(AcpiTableHeader); + + /* Scope and namespace, length will be filled at the end */ + *ptr++ = ACPI_AML_SCOPE_OP; + ptr = mempcpy(ptr, "_SB_", 4); + + /* Add device definitions */ + ptr = acpi_dsdt_add_cpus(ptr, smp_cpus); + ptr = acpi_dsdt_add_uart(ptr, info->uart_addr, info->uart_irq); + ptr = acpi_dsdt_add_rtc(ptr, info->rtc_addr, info->rtc_irq); + ptr = acpi_dsdt_add_flash(ptr, info->flash_addr); + ptr = acpi_dsdt_add_virtio(ptr, info->virtio_mmio_addr, + info->virtio_mmio_irq, info->virtio_mmio_num); + + /* Table and namespace size calculation */ + ptr = acpi_calc_size(acpi_table[DSDT] + sizeof(*header) + 1, ptr, 0); + acpi_size[DSDT] = (void *)ptr - acpi_table[DSDT]; + header->length = acpi_size[DSDT]; + + acpi_do_checksum(acpi_table[DSDT], acpi_size[DSDT], &header->checksum); } void acpi_build_tables(int smp_cpus, diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h index f5e5222..dc4ae46 100644 --- a/include/hw/acpi/acpi-defs.h +++ b/include/hw/acpi/acpi-defs.h @@ -227,6 +227,40 @@ typedef struct AcpiFacsDescriptorRev5_1 AcpiFacsDescriptorRev5_1; * Differentiated System Description Table (DSDT) */ +#define ACPI_AML_SCOPE_OP 0x10 +#define ACPI_AML_DEVICE_OP 0x5B +#define ACPI_AML_NAME_OP 0x08 +#define ACPI_AML_OP_PREFIX 0x82 +#define ACPI_AML_BYTE_PREFIX 0x0A +#define ACPI_AML_WORD_PREFIX 0x0B +#define ACPI_AML_DWORD_PREFIX 0x0C +#define ACPI_AML_QWORD_PREFIX 0x0E +#define ACPI_AML_STRING_PREFIX 0x0D +#define ACPI_AML_BUFFER_PREFIX 0x11 +#define ACPI_AML_END_TAG 0x79 +#define ACPI_AML_RESOURCE_MEMORY32 0x86 +#define ACPI_AML_RESOURCE_EXTENDED_IRQ 0x89 + +#define AML_RESOURCE_LARGE_HEADER_COMMON \ + uint8_t descriptor_type;\ + uint16_t resource_length; + +struct AcpiAmlResourceFixedMemory32 { + AML_RESOURCE_LARGE_HEADER_COMMON + uint8_t flags; + uint32_t address; + uint32_t address_length; +} QEMU_PACKED; +typedef struct AcpiAmlResourceFixedMemory32 AcpiAmlResourceFixedMemory32; + +struct AcpiAmlResourceExtendedIrq { + AML_RESOURCE_LARGE_HEADER_COMMON + uint8_t flags; + uint8_t interrupt_count; + uint32_t interrupts[1]; +} QEMU_PACKED; +typedef struct AcpiAmlResourceExtendedIrq AcpiAmlResourceExtendedIrq; + /* * MADT values and structures */ diff --git a/include/hw/arm/virt-acpi.h b/include/hw/arm/virt-acpi.h index 216a3a2..39bb14d 100644 --- a/include/hw/arm/virt-acpi.h +++ b/include/hw/arm/virt-acpi.h @@ -28,6 +28,7 @@ #define ACPI_VIRT_MACH_STR_8 "MACHVIRT" #define ACPI_BASE_ADDRESS 0x47000000 +#define ACPI_DSDT_MAX_SIZE 0x4000 enum { RSDP, @@ -53,6 +54,14 @@ struct acpi_madt_info { }; struct acpi_dsdt_info { + const hwaddr *uart_addr; + const int *uart_irq; + const hwaddr *virtio_mmio_addr; + const int *virtio_mmio_irq; + int virtio_mmio_num; + const hwaddr *rtc_addr; + const int *rtc_irq; + const hwaddr *flash_addr; }; void acpi_build_tables(int smp_cpus, -- 1.9.1

10 years, 8 months

1
0
0 0

[RFC PATCH 7/7] hw/arm/virt: Enable dynamic generation of ACPI v5.1 tables

by Alexander Spyridakis

Expose the needed device information to the table generation insfrastructure and assemble the final compacted ACPI binary blob in the guest memory. Signed-off-by: Alvise Rigo <a.rigo(a)virtualopensystems.com> --- hw/arm/boot.c | 26 +++++++++++++++++++++++++ hw/arm/virt-acpi.c | 18 +++++++++++++++++- hw/arm/virt.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++---- include/hw/arm/arm.h | 2 ++ 4 files changed, 95 insertions(+), 5 deletions(-) diff --git a/hw/arm/boot.c b/hw/arm/boot.c index bffbea5..74c8eb5 100644 --- a/hw/arm/boot.c +++ b/hw/arm/boot.c @@ -179,6 +179,11 @@ static inline bool have_dtb(const struct arm_boot_info *info) return info->dtb_filename || info->get_dtb; } +static inline bool have_acpi(const struct arm_boot_info *info) +{ + return info->get_acpi; +} + #define WRITE_WORD(p, value) do { \ stl_phys_notdirty(&address_space_memory, p, value); \ p += 4; \ @@ -438,6 +443,20 @@ fail: return -1; } +static int load_acpi(hwaddr addr, const struct arm_boot_info *binfo, + hwaddr addr_limit) +{ + void *acpi_blob = NULL; + int acpi_size; + + acpi_blob = binfo->get_acpi(binfo, &acpi_size); + rom_add_blob_fixed("acpi", acpi_blob, acpi_size, binfo->acpi_base_addr); + g_free(acpi_blob); + /* TODO: check to not write outside memory boundaries */ + + return 0; +} + static void do_cpu_reset(void *opaque) { ARMCPU *cpu = opaque; @@ -497,6 +516,13 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info *info) qemu_register_reset(do_cpu_reset, ARM_CPU(cs)); } + /* load ACPI blob */ + if (have_acpi(info)) { + if (load_acpi(info->acpi_base_addr, info, 0) < 0) { + exit(1); + } + } + /* Load the kernel. */ if (!info->kernel_filename) { diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c index be490e7..19e6779 100644 --- a/hw/arm/virt-acpi.c +++ b/hw/arm/virt-acpi.c @@ -535,5 +535,21 @@ void acpi_build_tables(int smp_cpus, uint32_t acpi_make_blob(void **blob_ptr) { - return 0; + uint8_t *acpi_blob_ptr = NULL; + uint32_t blob_size, n; + + for (n = RSDP, blob_size = 0; n <= DSDT; n++) { + blob_size += acpi_size[n]; + } + + *blob_ptr = (void *)g_malloc0(blob_size); + acpi_blob_ptr = *blob_ptr; + + for (n = RSDP; n <= DSDT; n++) { + memcpy(acpi_blob_ptr, acpi_table[n], acpi_size[n]); + acpi_blob_ptr += acpi_size[n]; + g_free(acpi_table[n]); + } + + return blob_size; } diff --git a/hw/arm/virt.c b/hw/arm/virt.c index 78f618d..5b40292 100644 --- a/hw/arm/virt.c +++ b/hw/arm/virt.c @@ -42,6 +42,8 @@ #include "exec/address-spaces.h" #include "qemu/bitops.h" #include "qemu/error-report.h" +#include "hw/acpi/acpi-defs.h" +#include "hw/arm/virt-acpi.h" #define NUM_VIRTIO_TRANSPORTS 32 @@ -59,6 +61,11 @@ #define GIC_FDT_IRQ_PPI_CPU_START 8 #define GIC_FDT_IRQ_PPI_CPU_WIDTH 8 +#define ARCH_TIMER_VIRT_IRQ 11 +#define ARCH_TIMER_S_EL1_IRQ 13 +#define ARCH_TIMER_NS_EL1_IRQ 14 +#define ARCH_TIMER_NS_EL2_IRQ 10 + enum { VIRT_FLASH, VIRT_MEM, @@ -83,6 +90,8 @@ typedef struct VirtBoardInfo { int smp_cpus; void *fdt; int fdt_size; + void *acpi; + int acpi_size; uint32_t clock_phandle; } VirtBoardInfo; @@ -119,6 +128,29 @@ static const int a15irqmap[] = { [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */ }; +static const struct acpi_madt_info madt_info = { + &a15memmap[VIRT_GIC_CPU].base, + &a15memmap[VIRT_GIC_DIST].base +}; + +static const struct acpi_dsdt_info dsdt_info = { + .uart_addr = &a15memmap[VIRT_UART].base, + .uart_irq = &a15irqmap[VIRT_UART], + .virtio_mmio_addr = &a15memmap[VIRT_MMIO].base, + .virtio_mmio_irq = &a15irqmap[VIRT_MMIO], + .virtio_mmio_num = NUM_VIRTIO_TRANSPORTS, + .rtc_addr = &a15memmap[VIRT_RTC].base, + .rtc_irq = &a15irqmap[VIRT_RTC], + .flash_addr = &a15memmap[VIRT_FLASH].base, +}; + +static const struct acpi_gtdt_info gtdt_info = { + ARCH_TIMER_VIRT_IRQ + 16, + ARCH_TIMER_S_EL1_IRQ + 16, + ARCH_TIMER_NS_EL1_IRQ + 16, + ARCH_TIMER_NS_EL2_IRQ + 16 +}; + static VirtBoardInfo machines[] = { { .cpu_model = "cortex-a15", @@ -259,10 +291,10 @@ static void fdt_add_timer_nodes(const VirtBoardInfo *vbi) "arm,armv7-timer"); } qemu_fdt_setprop_cells(vbi->fdt, "/timer", "interrupts", - GIC_FDT_IRQ_TYPE_PPI, 13, irqflags, - GIC_FDT_IRQ_TYPE_PPI, 14, irqflags, - GIC_FDT_IRQ_TYPE_PPI, 11, irqflags, - GIC_FDT_IRQ_TYPE_PPI, 10, irqflags); + GIC_FDT_IRQ_TYPE_PPI, ARCH_TIMER_S_EL1_IRQ, irqflags, + GIC_FDT_IRQ_TYPE_PPI, ARCH_TIMER_NS_EL1_IRQ, irqflags, + GIC_FDT_IRQ_TYPE_PPI, ARCH_TIMER_VIRT_IRQ, irqflags, + GIC_FDT_IRQ_TYPE_PPI, ARCH_TIMER_NS_EL2_IRQ, irqflags); } static void fdt_add_cpu_nodes(const VirtBoardInfo *vbi) @@ -527,6 +559,14 @@ static void *machvirt_dtb(const struct arm_boot_info *binfo, int *fdt_size) return board->fdt; } +static void *machvirt_acpi(const struct arm_boot_info *binfo, int *acpi_size) +{ + const VirtBoardInfo *board = (const VirtBoardInfo *)binfo; + + *acpi_size = board->acpi_size; + return board->acpi; +} + static void machvirt_init(MachineState *machine) { qemu_irq pic[NUM_IRQS]; @@ -604,6 +644,10 @@ static void machvirt_init(MachineState *machine) */ create_virtio_devices(vbi, pic); + /* Build ACPI tables and form the binary blob */ + acpi_build_tables(vbi->smp_cpus, &gtdt_info, &madt_info, &dsdt_info); + vbi->acpi_size = acpi_make_blob(&vbi->acpi); + vbi->bootinfo.ram_size = machine->ram_size; vbi->bootinfo.kernel_filename = machine->kernel_filename; vbi->bootinfo.kernel_cmdline = machine->kernel_cmdline; @@ -612,6 +656,8 @@ static void machvirt_init(MachineState *machine) vbi->bootinfo.board_id = -1; vbi->bootinfo.loader_start = vbi->memmap[VIRT_MEM].base; vbi->bootinfo.get_dtb = machvirt_dtb; + vbi->bootinfo.acpi_base_addr = ACPI_BASE_ADDRESS; + vbi->bootinfo.get_acpi = machvirt_acpi; arm_load_kernel(ARM_CPU(first_cpu), &vbi->bootinfo); } diff --git a/include/hw/arm/arm.h b/include/hw/arm/arm.h index cefc9e6..806faaf 100644 --- a/include/hw/arm/arm.h +++ b/include/hw/arm/arm.h @@ -27,6 +27,7 @@ struct arm_boot_info { const char *initrd_filename; const char *dtb_filename; hwaddr loader_start; + hwaddr acpi_base_addr; /* multicore boards that use the default secondary core boot functions * need to put the address of the secondary boot code, the boot reg, * and the GIC address in the next 3 values, respectively. boards that @@ -61,6 +62,7 @@ struct arm_boot_info { * the user it should implement this hook. */ void (*modify_dtb)(const struct arm_boot_info *info, void *fdt); + void *(*get_acpi)(const struct arm_boot_info *info, int *size); /* Used internally by arm_boot.c */ int is_linux; hwaddr initrd_start; -- 1.9.1

10 years, 8 months

1
0
0 0

[RFC PATCH 4/7] hw/arm/virt-acpi: Generate FACS and FADT, update ACPI headers

by Alexander Spyridakis

FADT points to FACS and DSDT and additionally, in the case of mach virt, it is also used to set the Hardware Reduced bit and enable PSCI SMP booting through HVC. For FACS the table is created as a mockup, as with the Hardware Reduced bit set it will not be used. Update the header definitions for FADT and FACS taking into account the new additions of ACPI v5.1 in `include/hw/acpi/acpi-defs.h` Signed-off-by: Alexander Spyridakis <a.spyridakis(a)virtualopensystems.com> Signed-off-by: Alvise Rigo <a.rigo(a)virtualopensystems.com> --- hw/arm/virt-acpi.c | 41 +++++++++++-- include/hw/acpi/acpi-defs.h | 141 ++++++++++++++++++++++++++++++-------------- 2 files changed, 134 insertions(+), 48 deletions(-) diff --git a/hw/arm/virt-acpi.c b/hw/arm/virt-acpi.c index 0d7bb99..aca0434 100644 --- a/hw/arm/virt-acpi.c +++ b/hw/arm/virt-acpi.c @@ -133,14 +133,47 @@ static void acpi_create_gtdt(const struct acpi_gtdt_info *irqs) static void acpi_create_fadt(void) { - acpi_table[FADT] = NULL; - acpi_size[FADT] = 0; + AcpiFacpDescriptorRev5_1 *fadt; + hwaddr facs_offset; + int i; + + fadt = g_malloc0(sizeof(*fadt)); + acpi_fill_common_header_data(fadt, "FACP", 5, sizeof(*fadt)); + + /* Hardware Reduced = 1 and use PSCI 0.2+ and with HVC */ + fadt->flags = cpu_to_le32(1 << ACPI_FADT_F_HW_REDUCED_ACPI); + fadt->arm_boot_flags = cpu_to_le16((1 << ACPI_FADT_ARM_USE_PSCI_G_0_2) | + (1 << ACPI_FADT_ARM_PSCI_USE_HVC)); + + /* ACPI v5.1 (fadt->revision.fadt->minor_revision) */ + fadt->minor_revision = 0x1; + + acpi_size[FADT] = fadt->length; + + /* Calculate FACS and DSDT table offsets */ + for (i = RSDP, facs_offset = 0; i < FACS; ++i) { + facs_offset += acpi_size[i]; + } + fadt->Xfacs = cpu_to_le64(ACPI_BASE_ADDRESS + facs_offset); + fadt->Xdsdt = cpu_to_le64(fadt->Xfacs + acpi_size[FACS]); + + acpi_do_checksum(fadt, fadt->length, &fadt->checksum); + + acpi_table[FADT] = (void *)fadt; } static void acpi_create_facs(void) { - acpi_table[FACS] = NULL; - acpi_size[FACS] = 0; + AcpiFacsDescriptorRev5_1 *facs; + + facs = g_malloc0(sizeof(*facs)); + + memcpy(&facs->signature, "FACS", sizeof(facs->signature)); + facs->length = cpu_to_le32(sizeof(*facs)); + facs->version = 0x02; + + acpi_table[FACS] = (void *)facs; + acpi_size[FACS] = facs->length; } static void acpi_create_dsdt(int smp_cpus, const struct acpi_dsdt_info *info) diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h index 779f872..ebbd2d0 100644 --- a/include/hw/acpi/acpi-defs.h +++ b/include/hw/acpi/acpi-defs.h @@ -97,46 +97,49 @@ struct AcpiXsdtDescriptor { typedef struct AcpiXsdtDescriptor AcpiXsdtDescriptor; /* - * ACPI 1.0 Fixed ACPI Description Table (FADT) + * ACPI Fixed ACPI Description Table (FADT) */ +#define ACPI_FADT_COMMON_DEF /* FADT common definition */ \ + ACPI_TABLE_HEADER_DEF /* ACPI common table header */ \ + uint32_t firmware_ctrl; /* Physical address of FACS */ \ + uint32_t dsdt; /* Physical address of DSDT */ \ + uint8_t model; /* System Interrupt Model */ \ + uint8_t reserved1; /* Reserved */ \ + uint16_t sci_int; /* System vector of SCI interrupt */ \ + uint32_t smi_cmd; /* Port address of SMI command port */ \ + uint8_t acpi_enable; /* Value to write to smi_cmd to enable ACPI */ \ + uint8_t acpi_disable; /* Value to write to smi_cmd to disable ACPI */ \ + uint8_t S4bios_req; /* Value to write to SMI CMD to enter S4BIOS state */ \ + uint8_t reserved2; /* Reserved - must be zero */ \ + uint32_t pm1a_evt_blk; /* Port address of Power Mgt 1a acpi_event Reg Blk */ \ + uint32_t pm1b_evt_blk; /* Port address of Power Mgt 1b acpi_event Reg Blk */ \ + uint32_t pm1a_cnt_blk; /* Port address of Power Mgt 1a Control Reg Blk */ \ + uint32_t pm1b_cnt_blk; /* Port address of Power Mgt 1b Control Reg Blk */ \ + uint32_t pm2_cnt_blk; /* Port address of Power Mgt 2 Control Reg Blk */ \ + uint32_t pm_tmr_blk; /* Port address of Power Mgt Timer Ctrl Reg Blk */ \ + uint32_t gpe0_blk; /* Port addr of General Purpose acpi_event 0 Reg Blk */ \ + uint32_t gpe1_blk; /* Port addr of General Purpose acpi_event 1 Reg Blk */ \ + uint8_t pm1_evt_len; /* Byte length of ports at pm1_x_evt_blk */ \ + uint8_t pm1_cnt_len; /* Byte length of ports at pm1_x_cnt_blk */ \ + uint8_t pm2_cnt_len; /* Byte Length of ports at pm2_cnt_blk */ \ + uint8_t pm_tmr_len; /* Byte Length of ports at pm_tm_blk */ \ + uint8_t gpe0_blk_len; /* Byte Length of ports at gpe0_blk */ \ + uint8_t gpe1_blk_len; /* Byte Length of ports at gpe1_blk */ \ + uint8_t gpe1_base; /* Offset in gpe model where gpe1 events start */ \ + uint8_t reserved3; /* Reserved */ \ + uint16_t plvl2_lat; /* Worst case HW latency to enter/exit C2 state */ \ + uint16_t plvl3_lat; /* Worst case HW latency to enter/exit C3 state */ \ + uint16_t flush_size; /* Size of area read to flush caches */ \ + uint16_t flush_stride; /* Stride used in flushing caches */ \ + uint8_t duty_offset; /* Bit location of duty cycle field in p_cnt reg */ \ + uint8_t duty_width; /* Bit width of duty cycle field in p_cnt reg */ \ + uint8_t day_alrm; /* Index to day-of-month alarm in RTC CMOS RAM */ \ + uint8_t mon_alrm; /* Index to month-of-year alarm in RTC CMOS RAM */ \ + uint8_t century; /* Index to century in RTC CMOS RAM */ + struct AcpiFadtDescriptorRev1 { - ACPI_TABLE_HEADER_DEF /* ACPI common table header */ - uint32_t firmware_ctrl; /* Physical address of FACS */ - uint32_t dsdt; /* Physical address of DSDT */ - uint8_t model; /* System Interrupt Model */ - uint8_t reserved1; /* Reserved */ - uint16_t sci_int; /* System vector of SCI interrupt */ - uint32_t smi_cmd; /* Port address of SMI command port */ - uint8_t acpi_enable; /* Value to write to smi_cmd to enable ACPI */ - uint8_t acpi_disable; /* Value to write to smi_cmd to disable ACPI */ - uint8_t S4bios_req; /* Value to write to SMI CMD to enter S4BIOS state */ - uint8_t reserved2; /* Reserved - must be zero */ - uint32_t pm1a_evt_blk; /* Port address of Power Mgt 1a acpi_event Reg Blk */ - uint32_t pm1b_evt_blk; /* Port address of Power Mgt 1b acpi_event Reg Blk */ - uint32_t pm1a_cnt_blk; /* Port address of Power Mgt 1a Control Reg Blk */ - uint32_t pm1b_cnt_blk; /* Port address of Power Mgt 1b Control Reg Blk */ - uint32_t pm2_cnt_blk; /* Port address of Power Mgt 2 Control Reg Blk */ - uint32_t pm_tmr_blk; /* Port address of Power Mgt Timer Ctrl Reg Blk */ - uint32_t gpe0_blk; /* Port addr of General Purpose acpi_event 0 Reg Blk */ - uint32_t gpe1_blk; /* Port addr of General Purpose acpi_event 1 Reg Blk */ - uint8_t pm1_evt_len; /* Byte length of ports at pm1_x_evt_blk */ - uint8_t pm1_cnt_len; /* Byte length of ports at pm1_x_cnt_blk */ - uint8_t pm2_cnt_len; /* Byte Length of ports at pm2_cnt_blk */ - uint8_t pm_tmr_len; /* Byte Length of ports at pm_tm_blk */ - uint8_t gpe0_blk_len; /* Byte Length of ports at gpe0_blk */ - uint8_t gpe1_blk_len; /* Byte Length of ports at gpe1_blk */ - uint8_t gpe1_base; /* Offset in gpe model where gpe1 events start */ - uint8_t reserved3; /* Reserved */ - uint16_t plvl2_lat; /* Worst case HW latency to enter/exit C2 state */ - uint16_t plvl3_lat; /* Worst case HW latency to enter/exit C3 state */ - uint16_t flush_size; /* Size of area read to flush caches */ - uint16_t flush_stride; /* Stride used in flushing caches */ - uint8_t duty_offset; /* Bit location of duty cycle field in p_cnt reg */ - uint8_t duty_width; /* Bit width of duty cycle field in p_cnt reg */ - uint8_t day_alrm; /* Index to day-of-month alarm in RTC CMOS RAM */ - uint8_t mon_alrm; /* Index to month-of-year alarm in RTC CMOS RAM */ - uint8_t century; /* Index to century in RTC CMOS RAM */ + ACPI_FADT_COMMON_DEF uint8_t reserved4; /* Reserved */ uint8_t reserved4a; /* Reserved */ uint8_t reserved4b; /* Reserved */ @@ -144,6 +147,43 @@ struct AcpiFadtDescriptorRev1 } QEMU_PACKED; typedef struct AcpiFadtDescriptorRev1 AcpiFadtDescriptorRev1; +struct acpi_generic_address { + uint8_t space_id; /* Address space where struct or register exists */ + uint8_t bit_width; /* Size in bits of given register */ + uint8_t bit_offset; /* Bit offset within the register */ + uint8_t access_width; /* Minimum Access size (ACPI 3.0) */ + uint64_t address; /* 64-bit address of struct or register */ +} QEMU_PACKED; + +struct AcpiFacpDescriptorRev5_1 { + ACPI_FADT_COMMON_DEF + uint16_t boot_flags; /* IA-PC Boot Architecture Flags (see below for individual flags) */ + uint8_t reserved; /* Reserved, must be zero */ + uint32_t flags; /* Miscellaneous flag bits (see below for individual flags) */ + struct acpi_generic_address reset_register; /* 64-bit address of the Reset register */ + uint8_t reset_value; /* Value to write to the reset_register port to reset the system */ + uint16_t arm_boot_flags; /* ARM-Specific Boot Flags (see below for individual flags) (ACPI 5.1) */ + uint8_t minor_revision; /* FADT Minor Revision (ACPI 5.1) */ + uint64_t Xfacs; /* 64-bit physical address of FACS */ + uint64_t Xdsdt; /* 64-bit physical address of DSDT */ + struct acpi_generic_address xpm1a_event_block; /* 64-bit Extended Power Mgt 1a Event Reg Blk address */ + struct acpi_generic_address xpm1b_event_block; /* 64-bit Extended Power Mgt 1b Event Reg Blk address */ + struct acpi_generic_address xpm1a_control_block; /* 64-bit Extended Power Mgt 1a Control Reg Blk address */ + struct acpi_generic_address xpm1b_control_block; /* 64-bit Extended Power Mgt 1b Control Reg Blk address */ + struct acpi_generic_address xpm2_control_block; /* 64-bit Extended Power Mgt 2 Control Reg Blk address */ + struct acpi_generic_address xpm_timer_block; /* 64-bit Extended Power Mgt Timer Ctrl Reg Blk address */ + struct acpi_generic_address xgpe0_block; /* 64-bit Extended General Purpose Event 0 Reg Blk address */ + struct acpi_generic_address xgpe1_block; /* 64-bit Extended General Purpose Event 1 Reg Blk address */ + struct acpi_generic_address sleep_control; /* 64-bit Sleep Control register (ACPI 5.0) */ + struct acpi_generic_address sleep_status; /* 64-bit Sleep Status register (ACPI 5.0) */ +} QEMU_PACKED; +typedef struct AcpiFacpDescriptorRev5_1 AcpiFacpDescriptorRev5_1; + +enum { + ACPI_FADT_ARM_USE_PSCI_G_0_2, + ACPI_FADT_ARM_PSCI_USE_HVC, +}; + /* * ACPI 1.0 Root System Description Table (RSDT) */ @@ -156,20 +196,33 @@ struct AcpiRsdtDescriptorRev1 typedef struct AcpiRsdtDescriptorRev1 AcpiRsdtDescriptorRev1; /* - * ACPI 1.0 Firmware ACPI Control Structure (FACS) + * ACPI Firmware ACPI Control Structure (FACS) */ +#define ACPI_FACS_COMMON_DEF /* FACS common definition */ \ + uint32_t signature; /* ACPI Signature */ \ + uint32_t length; /* Length of structure, in bytes */ \ + uint32_t hardware_signature; /* Hardware configuration signature */ \ + uint32_t firmware_waking_vector; /* ACPI OS waking vector */ \ + uint32_t global_lock; /* Global Lock */ \ + uint32_t flags; + struct AcpiFacsDescriptorRev1 { - uint32_t signature; /* ACPI Signature */ - uint32_t length; /* Length of structure, in bytes */ - uint32_t hardware_signature; /* Hardware configuration signature */ - uint32_t firmware_waking_vector; /* ACPI OS waking vector */ - uint32_t global_lock; /* Global Lock */ - uint32_t flags; + ACPI_FACS_COMMON_DEF uint8_t resverved3 [40]; /* Reserved - must be zero */ } QEMU_PACKED; typedef struct AcpiFacsDescriptorRev1 AcpiFacsDescriptorRev1; +struct AcpiFacsDescriptorRev5_1 { + ACPI_FACS_COMMON_DEF + uint64_t xfirmware_waking_vector; /* 64-bit version of the Firmware Waking Vector (ACPI 2.0+) */ + uint8_t version; /* Version of this table (ACPI 2.0+) */ + uint8_t reserved [3]; /* Reserved, must be zero */ + uint32_t ospm_flags; /* Flags to be set by OSPM (ACPI 4.0) */ + uint8_t reserved1 [24]; /* Reserved, must be zero */ +} QEMU_PACKED; +typedef struct AcpiFacsDescriptorRev5_1 AcpiFacsDescriptorRev5_1; + /* * Differentiated System Description Table (DSDT) */ -- 1.9.1

10 years, 8 months

1
0
0 0

[RFC PATCH v2 0/3] CPPC as PID backend

by Ashwin Chaugule

This patchset introduces CPPC(Collaborative Processor Performance Control) as a backend to the PID governor. The PID governor from intel_pstate.c maps cleanly onto some CPPC interfaces. e.g. The CPU performance requests are made on a continuous scale as against discrete pstate levels. The CPU performance feedback over an interval is gauged using platform specific counters which are also described by CPPC. Although CPPC describes several other registers to provide more hints to the platform, Linux as of today does not have the infrastructure to make use of those registers. Some of the CPPC specific information could be made available from the scheduler as part of the CPUfreq and Scheduler intergration work. Until then PID can be used as the front end for CPPC. This implementation was tested using a Thinkpad X240 Laptop which seemed to have CPPC and PCC tables in its ACPI firmware. However, it seems as though some addresses pointed to by the tables do not exist. This patchset also shows the hacks that were made in order to work around those limitations and test the control flow. This patchset builds on top of the PCC driver which is being reviewed separately[3]. Changes since V1: - Create a new driver based on Dirks suggestion. - Fold in CPPC backend hooks into main driver. Changes since V0: [1] - Split intel_pstate.c into a generic PID governor and platform specific backend. - Add CPPC accessors as PID backend. CPPC: ==== CPPC (Collaborative Processor Performance Control) is a new way to control CPU performance using an abstract continous scale as against a discretized P-state scale which is tied to CPU frequency only. It is defined in the ACPI 5.0+ spec. In brief, the basic operation involves: - OS makes a CPU performance request. (Can provide min and max tolerable bounds) - Platform (such as BMC) is free to optimize request within requested bounds depending on power/thermal budgets etc. - Platform conveys its decision back to OS The communication between OS and platform occurs through another medium called (PCC) Platform communication Channel. This is a generic mailbox like mechanism which includes doorbell semantics to indicate register updates. The PCC driver is being discussed in a separate patchset [3] and is not included here, since CPPC is only one client of PCC. Finer details about the PCC and CPPC spec are available in the latest ACPI 5.1 specification.[2] [1] - http://lwn.net/Articles/608715/ [2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf [3] - http://comments.gmane.org/gmane.linux.acpi.devel/71171 Ashwin Chaugule (3): PCC HACKS: Update PCC comm region with MSR data CPPC as a PID controller backend CPPC HACKS drivers/cpufreq/Kconfig | 12 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/acpi_pid.c | 1085 ++++++++++++++++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 125 ++++- 4 files changed, 1207 insertions(+), 16 deletions(-) create mode 100644 drivers/cpufreq/acpi_pid.c -- 1.9.1

10 years, 8 months

2
8
0 0

leg-kernel tag leg-20141013.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401013.0 This is based on mainline kernel v3.17 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/a0f69f9cba4d2fa5007b08… Notes :-

10 years, 8 months

1
0
0 0

[PATCH v8 0/2] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V7: - Added timeout to tx method in case the remote dies. - Restructured usage of acpi_status. Had inverted logic previously. Changes since V6: - Cosmetic changes based on Lv's suggestions Changes since V5: - Optimize loop that matches channel request. - Use platform_create_bundle. - Replace ioread/writes. - Remove redundant code and headers. - Restructure common mailbox macros. - Reformat PCC cmd parsing. Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (2): Mailbox: Add support for Platform Communication Channel PCC test drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 +- drivers/mailbox/mailbox.h | 16 +++ drivers/mailbox/pcc-test.c | 204 +++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 292 +++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 527 insertions(+), 3 deletions(-) create mode 100644 drivers/mailbox/mailbox.h create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 8 months

3
6
0 0

[RFC 0/2] Enable KVM on ARM when booting with ACPI

by Alexander Spyridakis

KVM on ARM relies on device tree information, which is not available when booting with ACPI. In the case of VGIC we need to extract the relevant data from the MADT table and probe it accordingly. For the architected timer, we need to expose the correct interrupt line to KVM from the GTDT table. This series has been tested on the Foundation Model 0.8 build 5206 and is based on the "Introduce ACPI for ARM64 based on ACPI 5.1" patch series from Hanjun Guo. Alexander Spyridakis (2): ARM64 / ACPI: VGIC probe support with ACPI ARM64 / ACPI: Point KVM to the virtual timer interrupt when booting with ACPI include/kvm/arm_vgic.h | 6 ++++ virt/kvm/arm/arch_timer.c | 48 ++++++++++++++++++------- virt/kvm/arm/vgic-v2.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++ virt/kvm/arm/vgic.c | 27 ++++++++------ 4 files changed, 150 insertions(+), 22 deletions(-) -- 1.9.1

10 years, 8 months

5
12
0 0

leg-kernel tag leg-20141002.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401002.0 This is based on mainline kernel v3.17-rc7 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/0ff59633762361c2dcc93… Notes :-

10 years, 9 months

1
0
0 0

[PATCH v7 0/2] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V6: - Cosmetic changes based on Lv's suggestions Changes since V5: - Optimize loop that matches channel request. - Use platform_create_bundle. - Replace ioread/writes. - Remove redundant code and headers. - Restructure common mailbox macros. - Reformat PCC cmd parsing. Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (2): Mailbox: Add support for Platform Communication Channel PCC test drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 +- drivers/mailbox/mailbox.h | 16 +++ drivers/mailbox/pcc-test.c | 203 ++++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 282 +++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 516 insertions(+), 3 deletions(-) create mode 100644 drivers/mailbox/mailbox.h create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 9 months

3
13
0 0

[PATCH v4 00/18] Introduce ACPI for ARM64 based on ACPI 5.1

by Hanjun Guo

ACPI 5.1 has been released and now be freely available for download [1]. It fixed some major gaps to run ACPI on ARM, this patch just follow the ACPI 5.1 spec and prepare the code to run ACPI on ARM64. ACPI 5.1 has some major changes for the following tables and method which are essential for ARM platforms: 1) MADT table updates. 2) FADT updates for PSCI 3) GTDT This patch set is the ARM64 ACPI core patches covered MADT, FADT and GTDT, platform board specific drivers are not covered by this patch set, but we provided drivers for Juno to boot with ACPI only for review purpose. We first introduce acpi.c and its related head file which are needed by ACPI core, and then get RSDP to extract all the ACPI boot-time tables. When all the boot-time tables (FADT, MADT, GTDT) are ready, then parse them to init the sytem when booted. Specifically, a) we use FADT to init PSCI and use PSCI to boot SMP; b) Use MADT for GIC init and SMP init; c) GTDT for arch timer init. This patch set is based on 3.17-rc4 and was tested by Graeme on Juno and FVP base model boot with ACPI only OK, if you want to test them, you can pull from acpi-5.1-v4 branch in leg/acpi repo: git://git.linaro.org/leg/acpi/acpi.git Updates since v3: - Compile out sleep.c on ARM64 when ACPI enabled - refactor the GIC init code to address the comments from Marc and Arnd - refactor the SMP init code to fix some logic problem when PSCI is not present, also address some of Grant and Lorenzo's comments - reorder the patch series and move ACPI table changes to the front of patch set - rebase on top of 3.17-rc4 Updates since v2: - Refactor the code to make SMP/PSCI init with less sperated init path by Tomasz - make ACPI depend on EXPERT - Address lots of comments from Catalin, Sudeep, Geoff - Add Juno device ACPI driver patches for review Updates since v1: - Set ACPI default off on ARM64 suggested by Olof; - Rebase the patch set on top of linux-next branch/linux-pm tree which includes the ACPICA for full ACPI 5.1 support. - Update the document as suggested; - Adress lots of comments from Mark, Sudeep, Randy, Naresh, Olof, Geoff and more... [1]: http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf Al Stone (3): ARM64 / ACPI: Get RSDP and ACPI boot-time tables ARM64 / ACPI: Introduce early_param for "acpi" ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Ashwin Chaugule (1): ACPI / table: Add new function to get table entries Graeme Gregory (4): ARM64 / ACPI: Introduce sleep-arm.c ARM64 / ACPI: If we chose to boot from acpi then disable FDT ARM64 / ACPI: Enable ARM64 in Kconfig Documentation: ACPI for ARM64 Hanjun Guo (8): ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() ARM64 / ACPI: Make PCI optional for ACPI on ARM64 ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init ACPI / table: Print GIC information when MADT is parsed ARM64 / ACPI: Parse MADT for SMP initialization ACPI / processor: Make it possible to get CPU hardware ID via GICC ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi ARM64 / ACPI: Parse GTDT to initialize arch timer Tomasz Nowicki (2): ACPI / table: Count matched and successfully parsed entries without specifying max entries ARM64 / ACPI: Add GICv2 specific ACPI boot support Documentation/arm64/arm-acpi.txt | 218 +++++++++++++++++++++ Documentation/kernel-parameters.txt | 3 +- arch/arm64/Kconfig | 3 + arch/arm64/include/asm/acenv.h | 18 ++ arch/arm64/include/asm/acpi.h | 96 ++++++++++ arch/arm64/include/asm/cpu_ops.h | 1 + arch/arm64/include/asm/pci.h | 11 ++ arch/arm64/include/asm/psci.h | 3 +- arch/arm64/include/asm/smp.h | 5 +- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/acpi.c | 351 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/cpu_ops.c | 4 +- arch/arm64/kernel/psci.c | 78 +++++--- arch/arm64/kernel/setup.c | 23 ++- arch/arm64/kernel/smp.c | 2 +- arch/arm64/kernel/time.c | 7 + drivers/acpi/Kconfig | 6 +- drivers/acpi/Makefile | 6 +- drivers/acpi/bus.c | 3 + drivers/acpi/internal.h | 5 + drivers/acpi/processor_core.c | 37 ++++ drivers/acpi/sleep-arm.c | 28 +++ drivers/acpi/tables.c | 115 +++++++++-- drivers/clocksource/arm_arch_timer.c | 117 ++++++++++-- drivers/irqchip/irq-gic.c | 106 ++++++++++ drivers/irqchip/irqchip.c | 3 + include/linux/acpi.h | 5 + include/linux/clocksource.h | 6 + include/linux/irqchip/arm-gic-acpi.h | 31 +++ include/linux/pci.h | 37 +++- 30 files changed, 1238 insertions(+), 91 deletions(-) create mode 100644 Documentation/arm64/arm-acpi.txt create mode 100644 arch/arm64/include/asm/acenv.h create mode 100644 arch/arm64/include/asm/acpi.h create mode 100644 arch/arm64/include/asm/pci.h create mode 100644 arch/arm64/kernel/acpi.c create mode 100644 drivers/acpi/sleep-arm.c create mode 100644 include/linux/irqchip/arm-gic-acpi.h -- 1.7.9.5

10 years, 9 months

14
82
0 0

[PATCH v3 00/17] Introduce ACPI for ARM64 based on ACPI 5.1

by Hanjun Guo

ACPI 5.1 has been released and now be freely available for download [1]. It fixed some major gaps to run ACPI on ARM, this patch just follow the ACPI 5.1 spec and prepare the code to run ACPI on ARM64. ACPI 5.1 has some major changes for the following tables and method which are essential for ARM platforms: 1) MADT table updates. 2) FADT updates for PSCI 3) GTDT This patch set is the ARM64 ACPI core patches covered MADT, FADT and GTDT, platform board specific drivers are not covered by this patch set, but we provide drivers for Juno to boot with ACPI only in the follwing patch set for review purpose. We first introduce acpi.c and its related head file which are needed by ACPI core, and then get RSDP to extract all the ACPI boot-time tables. When all the boot-time tables (FADT, MADT, GTDT) are ready, then parse them to init the sytem when booted. Specifically, a) we use FADT to init PSCI and use PSCI to boot SMP; b) Use MADT for GIC init and SMP init; c) GTDT for arch timer init. This patch set is based on 3.17-rc2 and was tested by Graeme on Juno and FVP base model boot with ACPI only OK, if you want to test them, you can pull from acpi-5.1-v3 branch in leg/acpi repo: git://git.linaro.org/leg/acpi/acpi.git Updates since v2: - Refactor the code to make SMP/PSCI init with less sperated init path by Tomasz - make ACPI depend on EXPERT - Address lots of comments from Catalin, Sudeep, Geoff - Add Juno device ACPI driver patches for review Updates since v1: - Set ACPI default off on ARM64 suggested by Olof; - Rebase the patch set on top of linux-next branch/linux-pm tree which includes the ACPICA for full ACPI 5.1 support. - Update the document as suggested; - Adress lots of comments from Mark, Sudeep, Randy, Naresh, Olof, Geoff and more... [1]: http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf Al Stone (3): ARM64 / ACPI: Get RSDP and ACPI boot-time tables ARM64 / ACPI: Introduce early_param for "acpi" ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Ashwin Chaugule (1): ACPI / table: Add new function to get table entries Graeme Gregory (4): ARM64 / ACPI: Introduce lowlevel suspend function ARM64 / ACPI: If we chose to boot from acpi then disable FDT ARM64 / ACPI: Enable ARM64 in Kconfig Documentation: ACPI for ARM64 Hanjun Guo (8): ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() ARM64 / ACPI: Make PCI optional for ACPI on ARM64 ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init ACPI / table: Print GIC information when MADT is parsed ARM64 / ACPI: Parse MADT for SMP initialization ACPI / processor: Make it possible to get CPU hardware ID via GICC ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi ARM64 / ACPI: Parse GTDT to initialize arch timer Tomasz Nowicki (1): ARM64 / ACPI: Add GICv2 specific ACPI boot support Documentation/arm64/arm-acpi.txt | 218 +++++++++++++++++++++ Documentation/kernel-parameters.txt | 3 +- arch/arm64/Kconfig | 3 + arch/arm64/include/asm/acenv.h | 18 ++ arch/arm64/include/asm/acpi.h | 108 ++++++++++ arch/arm64/include/asm/cpu_ops.h | 1 + arch/arm64/include/asm/pci.h | 11 ++ arch/arm64/include/asm/psci.h | 3 +- arch/arm64/include/asm/smp.h | 5 +- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/acpi.c | 359 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/cpu_ops.c | 4 +- arch/arm64/kernel/irq.c | 5 + arch/arm64/kernel/psci.c | 78 +++++--- arch/arm64/kernel/setup.c | 23 ++- arch/arm64/kernel/smp.c | 2 +- arch/arm64/kernel/time.c | 7 + drivers/acpi/Kconfig | 6 +- drivers/acpi/Makefile | 2 +- drivers/acpi/bus.c | 3 + drivers/acpi/internal.h | 5 + drivers/acpi/processor_core.c | 37 ++++ drivers/acpi/tables.c | 113 +++++++++-- drivers/clocksource/arm_arch_timer.c | 117 +++++++++-- drivers/irqchip/irq-gic.c | 114 +++++++++++ include/linux/acpi.h | 5 + include/linux/clocksource.h | 6 + include/linux/irqchip/arm-gic-acpi.h | 33 ++++ include/linux/pci.h | 37 +++- 29 files changed, 1237 insertions(+), 90 deletions(-) create mode 100644 Documentation/arm64/arm-acpi.txt create mode 100644 arch/arm64/include/asm/acenv.h create mode 100644 arch/arm64/include/asm/acpi.h create mode 100644 arch/arm64/include/asm/pci.h create mode 100644 arch/arm64/kernel/acpi.c create mode 100644 include/linux/irqchip/arm-gic-acpi.h -- 1.7.9.5

10 years, 9 months

17
86
0 0

[RFC PATCH for Juno 0/2] Drivers for Juno to boot from ACPI

by Hanjun Guo

This patch set is example of the sort of driver changes needed to boot Juno using ACPI tables, which using the ACPI tables devloped for MS Windows and published by ARM [1]. For the smsc911x driver, it is based on the following ASL fragment which is part of DSDT for Juno: // LAN9118 Ethernet // Device(ETH0) { Name(_HID, "ARMH9118") Name(_UID, Zero) Name(_CRS, ResourceTemplate() { Memory32Fixed(ReadWrite, 0x1A000000, 0x1000) Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 } }) } UART driver is just for review purpose, ARM is working on a more functional UART driver that does not poll to transmit. But it shows how to initialise SBSA compatible UART without clock definitions in DSDT. You also can refer to the boot log from [2]. [1]: https://github.com/ARM-software/edk2/tree/juno-acpi/ArmPlatformPkg/ArmJunoP… [2]: http://www.xora.org.uk/2014/08/29/juno-booting-from-acpi-tables/ Graeme Gregory (2): net: smsc911x add support for probing from ACPI tty: SBSA compatible UART drivers/net/ethernet/smsc/smsc911x.c | 38 ++++ drivers/tty/Kconfig | 6 + drivers/tty/Makefile | 1 + drivers/tty/sbsauart.c | 328 ++++++++++++++++++++++++++++++++++ 4 files changed, 373 insertions(+) create mode 100644 drivers/tty/sbsauart.c -- 1.7.9.5

10 years, 9 months

11
31
0 0

[RFC v1 0/6] CPPC as a PID backend

by Ashwin Chaugule

This patchset introduces CPPC(Collaborative Processor Performance Control) as a backend to the PID governor. The PID governor from intel_pstate.c maps cleanly onto some CPPC interfaces. e.g. The CPU performance requests are made on a continuous scale as against discrete pstate levels. The CPU performance feedback over an interval is gauged using platform specific counters which are also described by CPPC. Although CPPC describes several other registers to provide more hints to the platform, Linux as of today does not have the infrastructure to make use of those registers. Some of the CPPC specific information could be made available from the scheduler as part of the CPUfreq and Scheduler intergration work. Until then PID can be used as the front end for CPPC. Beyond code restructuring and renaming, this patchset does not change the logic from the intel_pstate.c driver. Kernel compilation times were compared with the original intel_pstate.c, intel backend(intel_pid_ctrl.c) and the CPPC backend and no significant overheads were noticed. Testing was performed on a Thinkpad X240 laptop. PID_CTRL + INTEL_PSTATE: ======================= real 5m37.742s user 18m42.575s sys 1m0.521s PID_CTRL + CPPC_PID_CTRL: ======================== real 5m48.321s user 18m24.487s sys 0m59.327s ORIGINAL INTEL_PSTATE: ====================== real 5m40.642s user 18m37.411s sys 1m0.185s The complete patchset including the PCC hacks used for testing is available in [4]. Changes since V0: [1] - Split intel_pstate.c into a generic PID governor and platform specific backend. - Add CPPC accessors as PID backend. CPPC: ==== CPPC (Collaborative Processor Performance Control) is a new way to control CPU performance using an abstract continous scale as against a discretized P-state scale which is tied to CPU frequency only. It is defined in the ACPI 5.0+ spec. In brief, the basic operation involves: - OS makes a CPU performance request. (Can provide min and max tolerable bounds) - Platform (such as BMC) is free to optimize request within requested bounds depending on power/thermal budgets etc. - Platform conveys its decision back to OS The communication between OS and platform occurs through another medium called (PCC) Platform communication Channel. This is a generic mailbox like mechanism which includes doorbell semantics to indicate register updates. The PCC driver is being discussed in a separate patchset [3] and is not included here, since CPPC is only one client of PCC. Finer details about the PCC and CPPC spec are available in the latest ACPI 5.1 specification.[2] [1] - http://lwn.net/Articles/608715/ [2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf [3] - http://comments.gmane.org/gmane.linux.acpi.devel/70299 [4] - http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/shortlog/refs/h… Ashwin Chaugule (6): PID Controller governor PID: Move Turbo detection into backend driver PID: Move Baytrail specific accessors into backend driver PID: Add new function pointers to read multiple registers PID: Rename counters to make them more generic PID: Add CPPC (Collaborative Processor Performance) backend driver Documentation/cpu-freq/intel-pstate.txt | 43 -- Documentation/cpu-freq/pid_ctrl.txt | 41 ++ drivers/cpufreq/Kconfig | 19 + drivers/cpufreq/Kconfig.x86 | 2 +- drivers/cpufreq/Makefile | 4 +- drivers/cpufreq/cppc_pid_ctrl.c | 406 +++++++++++++ drivers/cpufreq/intel_pid_ctrl.c | 408 +++++++++++++ drivers/cpufreq/intel_pstate.c | 1012 ------------------------------- drivers/cpufreq/pid_ctrl.c | 615 +++++++++++++++++++ drivers/cpufreq/pid_ctrl.h | 113 ++++ 10 files changed, 1606 insertions(+), 1057 deletions(-) delete mode 100644 Documentation/cpu-freq/intel-pstate.txt create mode 100644 Documentation/cpu-freq/pid_ctrl.txt create mode 100644 drivers/cpufreq/cppc_pid_ctrl.c create mode 100644 drivers/cpufreq/intel_pid_ctrl.c delete mode 100644 drivers/cpufreq/intel_pstate.c create mode 100644 drivers/cpufreq/pid_ctrl.c create mode 100644 drivers/cpufreq/pid_ctrl.h -- 1.9.1

10 years, 9 months

2
10
0 0

leg-kernel tag leg-20140908.0 released

by G Gregory

The leg-kernel release has been made and tagged as leg-20140908.0 This is based on mainline kernel v3.17-rc4 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/99fe5441d3aec97594381… Notes :-

10 years, 9 months

1
0
0 0

[PATCH v6 0/2] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V5: - Optimize loop that matches channel request. - Use platform_create_bundle. - Replace ioread/writes. - Remove redundant code and headers. - Restructure common mailbox macros. - Reformat PCC cmd parsing. Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (2): Mailbox: Add support for Platform Communication Channel PCC test drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 +- drivers/mailbox/mailbox.h | 16 +++ drivers/mailbox/pcc-test.c | 203 +++++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 279 +++++++++++++++++++++++++++++++++++++++++++++ 6 files changed, 513 insertions(+), 3 deletions(-) create mode 100644 drivers/mailbox/mailbox.h create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 9 months

2
7
0 0

[PATCH v5 0/2] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (2): Mailbox: Add support for Platform Communication Channel PCC test drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 - drivers/mailbox/pcc-test.c | 207 ++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 297 +++++++++++++++++++++++++++++++++++++ include/linux/mailbox_controller.h | 4 + 6 files changed, 522 insertions(+), 4 deletions(-) create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 10 months

4
12
0 0

[PATCH v4 0/4] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (4): Mailbox: Prepare to add PCC Mailbox support Mailbox: Add PCC Mailbox Helper functions Mailbox: Add support for Platform Communication Channel PCC test drivers/mailbox/Kconfig | 19 +++ drivers/mailbox/Makefile | 4 + drivers/mailbox/mailbox.c | 10 +- drivers/mailbox/pcc-test.c | 208 +++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 245 +++++++++++++++++++++++++++++++++++++ drivers/mailbox/pcc_mailbox.c | 136 ++++++++++++++++++++ include/linux/mailbox_controller.h | 4 + 7 files changed, 619 insertions(+), 7 deletions(-) create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c create mode 100644 drivers/mailbox/pcc_mailbox.c -- 1.9.1

10 years, 10 months

2
6
0 0

[PATCH v4 0/4] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (4): Mailbox: Prepare to add PCC Mailbox support Mailbox: Add PCC Mailbox Helper functions Mailbox: Add support for Platform Communication Channel PCC test drivers/mailbox/Kconfig | 19 +++ drivers/mailbox/Makefile | 4 + drivers/mailbox/mailbox.c | 10 +- drivers/mailbox/pcc-test.c | 208 +++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 245 +++++++++++++++++++++++++++++++++++++ drivers/mailbox/pcc_mailbox.c | 136 ++++++++++++++++++++ include/linux/mailbox_controller.h | 4 + 7 files changed, 619 insertions(+), 7 deletions(-) create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c create mode 100644 drivers/mailbox/pcc_mailbox.c -- 1.9.1

10 years, 10 months

1
0
0 0

[PATCH v3 0/3] PCC: Platform Communication Channel

by Ashwin Chaugule

This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: -Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 Ashwin Chaugule (3): Mailbox: Add support for PCC mailbox and channels Add support for Platform Communication Channel PCC-test: Test driver to trigger PCC commands drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 118 +++++++++++++++++-- drivers/mailbox/pcc-test.c | 208 +++++++++++++++++++++++++++++++++ drivers/mailbox/pcc.c | 228 +++++++++++++++++++++++++++++++++++++ include/linux/mailbox_client.h | 6 + include/linux/mailbox_controller.h | 1 + 7 files changed, 568 insertions(+), 7 deletions(-) create mode 100644 drivers/mailbox/pcc-test.c create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 10 months

3
28
0 0

leg-kernel tag leg-20140901.0 released

by G Gregory

The leg-kernel release has been made and tagged as leg-20140901.0 This is based on mainline kernel v3.17-rc2 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/cb30fb9031ff08b9586245… Notes :-

10 years, 10 months

1
0
0 0

[PATCH] ACPI: Add GPIO-signaled event emulator.

by Tomasz Nowicki

GPIO-signaled events is quite new thing in Linux kernel. There are not many board which can take advantage of it. However, GPIO events are very useful feature during work on ACPI subsystems. This commit emulates GPIO h/w behaviour and consists on write operation to debugfs file. GPIO device instance is still required in DSDT table along with _AEI resources and event methods. Please, see Kconfig help and driver head section for more details regarding tool usage. Signed-off-by: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> --- drivers/acpi/Kconfig | 10 ++ drivers/acpi/Makefile | 1 + drivers/acpi/gpio-acpi-evt-emu.c | 195 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 206 insertions(+) create mode 100644 drivers/acpi/gpio-acpi-evt-emu.c diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index fd54a74..8b9b74d 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -122,6 +122,16 @@ config ACPI_BUTTON To compile this driver as a module, choose M here: the module will be called button. +config ACPI_GPIO_EVT_EMULATE + bool "ACPI GPIO-signaled Events Emulation Support" + depends on DEBUG_FS + default n + help + This will enable your system to emulate GPIO-signaled event through + proc file system. User needs to trigger event method by + echo 1 > /sys/kernel/debug/acpi/events/<GPIO DEVICE>/<PIN> + (where, GPIO DEVICE is a GPIO device name and PIN is a pin number). + config ACPI_VIDEO tristate "Video" depends on X86 && BACKLIGHT_CLASS_DEVICE diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 9fa20ff..24f9d8f 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -55,6 +55,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o ifdef CONFIG_ACPI_VIDEO acpi-y += video_detect.o endif +acpi-$(CONFIG_ACPI_GPIO_EVT_EMULATE) += gpio-acpi-evt-emu.o # These are (potentially) separate modules diff --git a/drivers/acpi/gpio-acpi-evt-emu.c b/drivers/acpi/gpio-acpi-evt-emu.c new file mode 100644 index 0000000..c39f501 --- /dev/null +++ b/drivers/acpi/gpio-acpi-evt-emu.c @@ -0,0 +1,195 @@ +/* + * Code to emulate GPIO-signaled events. + * + * The sole purpose of this module is to help with GPIO event triggering. + * Usage: + * 1. See the list of available GPIO devices and associated pins under: + * /sys/kernel/debug/acpi/events/<GPIO DEVICE>/<PIN>. Only pins which are to + * be used as GPIO-signaled events will be listed (_AEI resources). + * + * 2. Trigger method corresponding to device pin number: + * $ echo 1 > /sys/kernel/debug/acpi/events/<GPIO DEVICE>/<PIN> + */ + +/* + * Copyright (C) 2014, Linaro Ltd. + * Author: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <linux/module.h> +#include <linux/uaccess.h> +#include <linux/debugfs.h> +#include <linux/acpi.h> + +#include "acpica/accommon.h" +#include "acpica/acnamesp.h" + +#include "internal.h" + +#define _COMPONENT ACPI_SYSTEM_COMPONENT +ACPI_MODULE_NAME("gpio_acpi_evt_emu"); + +struct gpio_pin_parent_data { + acpi_handle handle; + struct dentry *debugfs_dir; + char *name; + unsigned int evt_count; +}; + +struct gpio_pin_data { + struct list_head list; + acpi_handle handle; + unsigned int pin; +}; + +static struct dentry *acpi_evt_debugfs_dir; +static LIST_HEAD(pin_data_list); + +static int gpio_evt_trigger(void *data, u64 val) +{ + struct gpio_pin_data *pin_data = (struct gpio_pin_data *)data; + int pin = pin_data->pin; + + if (ACPI_FAILURE(acpi_execute_simple_method(pin_data->handle, NULL, + pin <= 255 ? 0 : pin))) + pr_err(PREFIX "evaluating event method failed\n"); + + return 0; +} + +DEFINE_SIMPLE_ATTRIBUTE(gpio_evt_emu_fops, NULL, gpio_evt_trigger, "%llu\n"); + +static acpi_status gpio_list_resource(struct acpi_resource *ares, void *context) +{ + struct acpi_resource_gpio *agpio = &ares->data.gpio; + struct gpio_pin_parent_data *parent_data = context; + struct dentry *pin_debugfs_dir; + struct gpio_pin_data *pin_data; + acpi_handle evt_handle; + acpi_status status; + char str_pin[5]; + char ev_name[5]; + int pin; + + if (ares->type != ACPI_RESOURCE_TYPE_GPIO) + return AE_OK; + + if (agpio->connection_type != ACPI_RESOURCE_GPIO_TYPE_INT) + return AE_OK; + + pin_data = kmalloc(sizeof(*pin_data), GFP_KERNEL); + if (!pin_data) + return AE_NO_MEMORY; + + pin = agpio->pin_table[0]; + snprintf(str_pin, 5, "%d", pin); + pin_debugfs_dir = debugfs_create_file(str_pin, S_IWUSR, + parent_data->debugfs_dir, + pin_data, + &gpio_evt_emu_fops); + if (!pin_debugfs_dir) { + status = AE_NULL_ENTRY; + goto fail; + } + + if (pin <= 255) + sprintf(ev_name, "_%c%02X", + agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L', + pin); + else + sprintf(ev_name, "_EVT"); + + status = acpi_get_handle(parent_data->handle, ev_name, &evt_handle); + if (ACPI_FAILURE(status)) { + pr_err(PREFIX "getting handle to <%s> of <%s> failed, there is no method related to 0x%02X pin\n", + ev_name, parent_data->name, pin); + goto fail; + } + + pin_data->handle = evt_handle; + pin_data->pin = pin; + list_add_tail(&pin_data->list, &pin_data_list); + + parent_data->evt_count++; + + return AE_OK; +fail: + kfree(pin_data); + return status; +} + +static acpi_status gpio_find_resource(acpi_handle handle, u32 lvl, + void *context, void **rv) +{ + struct acpi_namespace_node *node; + struct dentry *gpio_debugfs_dir; + struct gpio_pin_parent_data parent_data; + char gpio_name[5]; + + node = acpi_ns_validate_handle(handle); + if (!node) { + pr_err(PREFIX "Mapping GPIO handle to node failed\n"); + return AE_BAD_PARAMETER; + } + + snprintf(gpio_name, 5, "%s", node->name.ascii); + gpio_debugfs_dir = debugfs_create_dir(gpio_name, acpi_evt_debugfs_dir); + if (gpio_debugfs_dir == NULL) + return AE_OK; + + parent_data.debugfs_dir = gpio_debugfs_dir; + parent_data.handle = handle; + parent_data.name = gpio_name; + parent_data.evt_count = 0; + + acpi_walk_resources(handle, METHOD_NAME__AEI, gpio_list_resource, + &parent_data); + + if (!parent_data.evt_count) + debugfs_remove(gpio_debugfs_dir); + + return AE_OK; +} + +static int __init gpio_evt_emu_init(void) +{ + if (acpi_debugfs_dir == NULL) + return -ENOENT; + + acpi_evt_debugfs_dir = debugfs_create_dir("events", acpi_debugfs_dir); + if (acpi_evt_debugfs_dir == NULL) + return -ENOENT; + + acpi_get_devices(NULL, gpio_find_resource, NULL, NULL); + + return 0; +} + +static void __exit gpio_evt_emu_deinit(void) +{ + struct gpio_pin_data *pin_data, *temp; + + list_for_each_entry_safe(pin_data, temp, &pin_data_list, list) + kfree(pin_data); + + debugfs_remove_recursive(acpi_evt_debugfs_dir); +} + +module_init(gpio_evt_emu_init); +module_exit(gpio_evt_emu_deinit); + +MODULE_DESCRIPTION("GPIO-signaled events emulator"); +MODULE_LICENSE("GPL"); -- 1.9.1

10 years, 10 months

3
7
0 0

[PATCH v2 00/18] Introduce ACPI for ARM64 based on ACPI 5.1

by Hanjun Guo

ACPI 5.1 has been released and now be freely available for download [1]. It fixed some major gaps to run ACPI on ARM, this patch just follow the ACPI 5.1 spec and prepare the code to run ACPI on ARM64. ACPI 5.1 has some major changes for the following tables and method which are essential for ARM platforms: 1) MADT table updates. New fields were introduced to cover MPIDR and virtualization in GICC, and introduce GICR and GIC MSI frame structure to cover GICv3 and GICv2m (this patch set only cover GICv2). 2) FADT updates for PSCI New fields were introduced to cover PSCI and ACPI can use psci to boot SMP and other PSCI related functions. 3) GTDT GTDT was updated to support arch timer, memory-mapped tiemr, SBSA watchdog timer, in this patch, only arch timer tested on Juno board, so only arch timer init is available. 4) _DSD _DSD (Device Specific Data) will provide some key values which presented by FDT before, it makes possible that some devices can be emumerated in ACPI way, please refer to the document provided in this patch set for detail. This patch set is the ARM64 ACPI core patches covered MADT, FADT and GTDT, _DSD is not covered in this patch set. We first introduce acpi.c and its related head file which are needed by ACPI core, and then get RSDP to extract all the ACPI boot-time tables. When all the boot-time tables (FADT, MADT, GTDT) are ready, then parse them to init the sytem when booted. Specifically, a) we use FADT to init PSCI and use PSCI to boot SMP; b) Use MADT for GIC init and SMP init; c) GTDT for arch timer init. This patch set is based on Rafael's linux-pm tree/linux-next branch, and I already compiled it OK with: a) each patch applied on ARM64 with CONFIG_ACPI=y; b) CONFIG_ACPI=n on ARM64; c) CONFIG_ACPI=y on x86. Updates since v1: - Set ACPI default off on ARM64 suggested by Olof; - Rebase the patch set on top of linux-next branch/linux-pm tree which includes the ACPICA for full ACPI 5.1 support. - Update the document as suggested; - Adress lots of comments from Mark, Sudeep, Randy, Naresh, Olof, Geoff and more... [1] http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf Al Stone (3): ARM64 / ACPI: Get RSDP and ACPI boot-time tables ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 ARM64 / ACPI: Introduce early_param for "acpi" and set ACPI default off Ashwin Chaugule (1): ACPI / table: Add new function to get table entries Graeme Gregory (4): ARM64 / ACPI: Introduce lowlevel suspend function ARM64 / ACPI: If we chose to boot from acpi then disable FDT ARM64 / ACPI: Enable ARM64 in Kconfig Documentation: ACPI for ARM64 Hanjun Guo (9): ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() ARM64 / ACPI: Make PCI optional for ACPI on ARM64 ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map ACPI / table: Print GIC information when MADT is parsed ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way ACPI / processor: Make it possible to get CPU hardware ID via GICC ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi ARM64 / ACPI: Parse GTDT to initialize arch timer Tomasz Nowicki (1): ARM64 / ACPI: Add GICv2 specific ACPI boot support Documentation/arm64/arm-acpi.txt | 215 +++++++++++++++++++ Documentation/kernel-parameters.txt | 5 +- arch/arm64/Kconfig | 3 + arch/arm64/include/asm/acenv.h | 18 ++ arch/arm64/include/asm/acpi.h | 113 ++++++++++ arch/arm64/include/asm/cpu.h | 11 + arch/arm64/include/asm/pci.h | 11 + arch/arm64/include/asm/smp.h | 3 +- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/acpi.c | 380 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/cpu_ops.c | 62 +++++- arch/arm64/kernel/irq.c | 5 + arch/arm64/kernel/psci.c | 89 ++++++-- arch/arm64/kernel/setup.c | 13 +- arch/arm64/kernel/smp.c | 37 +++- arch/arm64/kernel/time.c | 7 + drivers/acpi/Kconfig | 6 +- drivers/acpi/Makefile | 2 +- drivers/acpi/bus.c | 3 + drivers/acpi/internal.h | 5 + drivers/acpi/processor_core.c | 37 ++++ drivers/acpi/tables.c | 109 ++++++++-- drivers/clocksource/arm_arch_timer.c | 117 +++++++++-- drivers/irqchip/irq-gic.c | 114 ++++++++++ include/linux/acpi.h | 5 + include/linux/clocksource.h | 6 + include/linux/irqchip/arm-gic-acpi.h | 36 ++++ include/linux/pci.h | 37 +++- 28 files changed, 1359 insertions(+), 91 deletions(-) create mode 100644 Documentation/arm64/arm-acpi.txt create mode 100644 arch/arm64/include/asm/acenv.h create mode 100644 arch/arm64/include/asm/acpi.h create mode 100644 arch/arm64/include/asm/cpu.h create mode 100644 arch/arm64/include/asm/pci.h create mode 100644 arch/arm64/kernel/acpi.c create mode 100644 include/linux/irqchip/arm-gic-acpi.h -- 1.7.9.5

10 years, 10 months

11
66
0 0

[RFC 0/3] Experimental patchset for CPPC

by Ashwin Chaugule

Hello, Apologies in advance for a lengthy cover letter. Hopefully it has all the required information so you dont need to read the ACPI spec. ;) This patchset introduces the ideas behind CPPC (Collaborative Processor Performance Control) and implements support for controlling CPU performance using the existing PID (Proportional-Integral-Derivative) controller (from intel_pstate.c) and some CPPC semantics. The patchwork is not a final proposal of the CPPC implementation. I've had to hack some sections due to lack of hardware, details of which are in the Testing section. There are several bits of information which are needed in order to make CPPC work great on Linux based platforms and I'm hoping to start a wider discussion on how to address the missing bits. The following sections briefly introduce CPPC and later highlight the information which is missing. More importantly, I'm also looking for ideas on how to support CPPC in the short term, given that we will soon be seeing products based on ARM64 and X86 which support CPPC.[1] Although we may not have all the information, we could make it work with existing governors in a way this patchset demonstrates. Hopefully, this approach is acceptable for mainline inclusion in the short term. Finer details about the CPPC spec are available in the latest ACPI 5.1 specification.[2] If these issues are being discussed on some other thread or elsewhere, or if someone is already working on it, please let me know. Also, please correct me if I have misunderstood anything. What is CPPC: ============= CPPC is the new interface for CPU performance control between the OS and the platform defined in ACPI 5.0+. The interface is built on an abstract representation of CPU performance rather than raw frequency. Basic operation consists of: * Platform enumerates supported performance range to OS * OS requests desired performance level over some time window along with min and max instantaneous limits * Platform is free to optimize power/performance within bounds provided by OS * Platform provides telemetry back to OS on delivered performance Communication with the OS is abstracted via another ACPI construct called Platform Communication Channel (PCC) which is essentially a generic shared memory channel with doorbell interrupts going back and forth. This abstraction allows the “platform” for CPPC to be a variety of different entities – driver, firmware, BMC, etc. CPPC describes the following registers: * HighestPerformance: (read from platform) Indicates the highest level of performance the processor is theoretically capable of achieving, given ideal operating conditions. * Nominal Performance: (read from platform) Indicates the highest sustained performance level of the processor. This is the highest operating performance level the CPU is expected to deliver continuously. * LowestNonlinearPerformance: (read from platform) Indicates the lowest performance level of the processor with non- linear power savings. * LowestPerformance: (read from platform) Indicates the lowest performance level of the processor. * GuaranteedPerformanceRegister: (read from platform) Optional. If supported, contains register to read the current guaranteed performance from. This is current max sustained performance of the CPU taking into account all budgeting constraints. This can change at runtime and is notified to the OS via ACPI notification mechanisms. * DesiredPerformanceRegister: (write to platform) Register to write desired performance level from the OS. * MinimumPerformanceRegister: (write to platform) Optional. This is the min allowable performance as requested by the OS. * MaximumPerformanceRegister: (write to platform) Optional. This is the max allowable performance as requested by the OS. * PerformanceReductionToleranceRegister (write to platform) Optional. This is the deviation below the desired perf value as requested by the OS. If the Time window register(below) is supported, then this value is the min performance on average over the time window that the OS desires. * TimeWindowRegister: (write to platform) Optional. The OS requests desired performance over this time window. * CounterWraparoundTime: (read from platform) Optional. Min time before the performance counters wrap around. * ReferencePerformanceCounterRegister: (read from platform) A counter that increments proportionally to the reference performance of the processor. * DeliveredPerformanceCounterRegister: (read from platform) Delivered perf = reference perf * delta(delivered perf ctr)/delta(ref perf ctr) * PerformanceLimitedRegister: (read from platform) This is set by the platform in the event that it has to limit available performance due to thermal or budgeting constraints. * CPPCEnableRegister: (read/write from platform) Enable/disable CPPC * AutonomousSelectionEnable: Platform decides CPU performance level w/o OS assist. * AutonomousActivityWindowRegister: This influences the increase or decrease in cpu performance of the platforms autonomous selection policy. * EnergyPerformancePreferenceRegister: Provides a energy or perf bias hint to the platform when in autonomous mode. * Reference Performance: (read from platform) Indicates the rate at which the reference counter increments. Whats missing in CPPC: ===================== Currently CPPC makes no mention of power. However, this could be added in future versions of the spec. e.g. although CPPC works off of a continuous range of CPU perf levels, we could discretize the scale such that we only extract points where the power level changes substantially between CPU perf levels and export this information to the scheduler. Whats missing in the kernel: ============================ We may have some of this information in the scheduler, but I couldn't see a good way to extract it for CPPC yet. (1) An intelligent way to provide a min/max bound and a desired value for CPU performance. (2) A timing window for the platform to deliver requested performance within bounds. This could be a kind of sampling interval between consecutive reads of delivered cpu performance. (3) Centralized decision making by any CPU in a freq domain for all its siblings. The last point needs some elaboration: I see that the CPUfreq layer allows defining "related CPUs" and that we can have the same policy for CPUs in the same freq domain and one governor per policy. However, from what I could tell, there are at least 2 baked in assumptions in this layer which break things at least for platforms like ARM (Please correct me if I'm wrong!) (a) All CPUs run at the exact same max, min and cur freq. (b) Any CPU always gets exactly the freq it asked for. So, although the CPUFreq layer is capable of making somewhat centralized cpufreq decisions for CPUs under the same policy, it seems to be deciding things under the wrong/inapplicable assumptions. Moreover only one CPU is in charge of policy handling at a time and the policy handling is shifted to another CPU in the domain, only if the former CPU is hotplugged out. Not having a proper centralized decision maker adversely affects power saving possibilities in platforms that can't distinguish when a CPU requests a specific freq and then goes to sleep. This potentially has the effect of keeping other CPUs in the domain running at a much higher frequency than required, while the initial requester is deep asleep. So, for point (3), I'm not sure which path we should take among the following: (I) Fix cpufreq layer and add CPPC support as a cpufreq_driver. (a) Change every call to get freq to make it read h/w registers and then snap value back to freq table. This way, cpufreq can keep its idea of freq current. However, this may end up waking CPUs to read counters, unless they are mem mapped. (b) Allow any CPU in the "related_cpus" mask to make policy decisions on behalf of siblings. So the policy maker switching is not tied to hotplug. (II) Not touch CPUfreq and use the PID algorithm instead, but change the busyness calculation to accumulate busyness values from all CPUs in common domain. Requires implementation of domain awareness. (III) Address these issues in the upcoming CPUfreq/CPUidle integration layer(?) (IV) Handle it in the platform or lose out. I understand this has some potential for adding latency to cpu freq requests so it may not be possible for all platforms. (V) ..? For points (1) and (2), the long term solution IMHO is to work it out along with the scheduler CPUFreq/CPUidle integration. But its not clear to me what would be the best short term approach. I'd greatly appreciate any suggestions/comments. If anyone is already working on these issues, please CC me as well. Test setup: ========== For the sake of experiments, I used the Thinkpad x240 laptop, which advertises CPPC tables in its ACPI firmware. The PCC and CPPC drivers included in this patchset are able to parse the tables and get all the required addresses. However, it seems that this laptop doesn't implement PCC doorbell and the firmware side of CPPC. The PCC doorbell calls would just wait forever. Not sure whats going on there. So, I had to hack it and emulate what the platform would've done to some extent. I extracted the PID algo from intel_pstate.c and modified it with CPPC function wrappers. It shouldn't be hard to replace PID with anything else we think is suitable. In the long term, I hope we can make CPPC calls directly from the scheduler. There are two versions of the low level CPPC accessors. The one included in the patchset is how I'd imagine it would work with platforms that completely implement CPPC in firmware. The other version is here [5]. This should help with DT or platforms with broken firmware, enablement purposes etc. I ran a simple kernel compilation with intel_pstate.c and the CPPC modified version as the governors and saw no real difference in compile times. So no new overheads added. I verified that CPU freq requests were taken by reading out the PERF_STATUS register. [1] - See the HWP section 14.4 http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-3… [2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf [3] - https://plus.google.com/+TheodoreTso/posts/2vEekAsG2QT [4] - https://plus.google.com/+ArjanvandeVen/posts/dLn9T4ehywL [5] - http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/blob/236d901d31… Ashwin Chaugule (3): ACPI: Add support for Platform Communication Channel CPPC: Add support for Collaborative Processor Performance Control CPPC: Add ACPI accessors to CPC registers drivers/acpi/Kconfig | 10 + drivers/acpi/Makefile | 1 + drivers/acpi/pcc.c | 301 +++++++++++++++ drivers/cpufreq/Kconfig | 19 + drivers/cpufreq/Makefile | 2 + drivers/cpufreq/cppc.c | 874 ++++++++++++++++++++++++++++++++++++++++++++ drivers/cpufreq/cppc.h | 181 +++++++++ drivers/cpufreq/cppc_acpi.c | 80 ++++ 8 files changed, 1468 insertions(+) create mode 100644 drivers/acpi/pcc.c create mode 100644 drivers/cpufreq/cppc.c create mode 100644 drivers/cpufreq/cppc.h create mode 100644 drivers/cpufreq/cppc_acpi.c -- 1.9.1

10 years, 10 months

4
24
0 0

[RFC] ACPI: Add GPIO-signaled event simulator.

by Tomasz Nowicki

GPIO signaled events is quite new thing in Linux kernel. AFAIK, there are not many board which can take advantage of it. However, GPIO events are very useful feature during work on ACPI subsystems. This commit emulates GPIO h/w behaviour and consists on read/write operation to debugfs file. GPIO device instance is still required in DSDT table along with _AEI resources and event methods. Reading from file provides pin to GPIO device map e.g. : $ cat /sys/kernel/debug/acpi/gpio_event GPIO device name: /__SB.GPI0 Available GPIO pin map: /__SB.GPI0 <-> pin 0x100 Based on that, user can trigger method corresponding to device pin number: $ echo "/__SB.GPI0 0x100" > /sys/kernel/debug/acpi/gpio_event Please, see Kconfig help and driver head section for more details regarding tool usage. Signed-off-by: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> --- drivers/acpi/Kconfig | 11 +++ drivers/acpi/Makefile | 1 + drivers/acpi/gpio_evt_emu.c | 207 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 219 insertions(+) create mode 100644 drivers/acpi/gpio_evt_emu.c diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index fd54a74..59e4c67 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -122,6 +122,17 @@ config ACPI_BUTTON To compile this driver as a module, choose M here: the module will be called button. +config ACPI_GPIO_EVT_EMULATE + bool "ACPI GPIO-signaled Events Emulation Support" + depends on DEBUG_FS + default n + help + This will enable your system to emulate GPIO-signaled event through + proc file system /sys/kernel/debug/acpi/gpio_event. User needs to print + available GPIO devices and pin map (cat path_to_proc_file) so that he + knows how to trigger given event by echo "XXX YYY" > path_to_proc_file + (where, XXX is a path to GPIO device and YYY is a pin number). + config ACPI_VIDEO tristate "Video" depends on X86 && BACKLIGHT_CLASS_DEVICE diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 9fa20ff..fb3c335 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -55,6 +55,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o ifdef CONFIG_ACPI_VIDEO acpi-y += video_detect.o endif +acpi-$(CONFIG_ACPI_GPIO_EVT_EMULATE) += gpio_evt_emu.o # These are (potentially) separate modules diff --git a/drivers/acpi/gpio_evt_emu.c b/drivers/acpi/gpio_evt_emu.c new file mode 100644 index 0000000..a2f762c --- /dev/null +++ b/drivers/acpi/gpio_evt_emu.c @@ -0,0 +1,207 @@ +/* + * Code to emulate GPIO-signaled events. + * + * The sole purpose of this module is to help with GPIO event triggering. + * Suggested way of using: + * 1. Perform walk of the namespac device tree looking for GPIO devices + * with associated _AEI resources e.g.: + * $ cat /sys/kernel/debug/acpi/gpio_event + * GPIO device name: /__SB.GPI0 + * Available GPIO pin map: + * /__SB.GPI0 <-> pin 0x100 + * + * 2. Trigger method corresponding to device pin number: + * $ echo "/__SB.GPI0 0x100" > /sys/kernel/debug/acpi/gpio_event + */ + +/* + * Copyright (C) 2014, Linaro Ltd. + * Author: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <linux/module.h> +#include <linux/uaccess.h> +#include <linux/debugfs.h> +#include <linux/acpi.h> + +#include "acpica/accommon.h" +#include "acpica/acnamesp.h" + +#include "internal.h" + +static struct dentry *gpio_evt_dentry; + +static void gpio_trigger_event(char *gpio_path, u32 pin) +{ + acpi_handle gpio_handle, evt_handle; + char ev_name[5]; + + if (ACPI_FAILURE(acpi_get_handle(NULL, gpio_path, &gpio_handle))) { + pr_err(PREFIX "getting handle to <%s> failed\n", gpio_path); + return; + } + + if (pin <= 255) + sprintf(ev_name, "_L%02X", pin); + else + sprintf(ev_name, "_EVT"); + + + if (ACPI_FAILURE(acpi_get_handle(gpio_handle, ev_name, &evt_handle))) { + pr_err(PREFIX "getting handle to <%s.%s> failed, there is no method related to 0x%02X pin\n", + gpio_path, ev_name, pin); + return; + } + + if (ACPI_FAILURE(acpi_execute_simple_method(evt_handle, NULL, + pin <= 255 ? 0 : pin))) + pr_err(PREFIX "evaluating <%s._EVT for pin %d> failed\n", + gpio_path, pin); + + return; +} + +static ssize_t gpio_evt_write(struct file *file, const char __user *user_buf, + size_t count, loff_t *ppos) +{ + u32 pin_number; + char *gpio_path = NULL; + char *pin_str = NULL; + const char *delim = " "; + char *temp_buf = NULL; + char *temp_buf_addr = NULL; + + temp_buf = kmalloc(count+1, GFP_ATOMIC); + if (!temp_buf) { + pr_warn(PREFIX "%s: Memory allocation failed\n", __func__); + return count; + } + temp_buf[count] = '\0'; + temp_buf_addr = temp_buf; + if (copy_from_user(temp_buf, user_buf, count)) + goto out; + + gpio_path = strsep(&temp_buf, delim); + pin_str = strsep(&temp_buf, delim); + + if (gpio_path && pin_str) { + ssize_t ret; + unsigned long val; + + ret = kstrtoul(pin_str, 10, &val); + if (ret) { + pr_warn(PREFIX "unknown event\n"); + goto out; + } + + pin_number = (u32)val; + } else { + pr_warn(PREFIX "unknown device\n"); + goto out; + } + + pr_info(PREFIX "ACPI device name is <%s>, pin number is <%d>\n", + gpio_path, pin_number); + + gpio_trigger_event(gpio_path, pin_number); + +out: + kfree(temp_buf_addr); + return count; +} + +static acpi_status gpio_list_resource(struct acpi_resource *ares, + void *context) +{ + struct acpi_resource_gpio *agpio; + struct seq_file *m = context; + int pin; + + if (!m) + return AE_OK; + + if (ares->type != ACPI_RESOURCE_TYPE_GPIO) + return AE_OK; + + agpio = &ares->data.gpio; + if (agpio->connection_type != ACPI_RESOURCE_GPIO_TYPE_INT) + return AE_OK; + + pin = agpio->pin_table[0]; + seq_printf(m, "%s <-> pin %d\n", agpio->resource_source.string_ptr, + pin); + + return AE_OK; +} + +static acpi_status gpio_find_resource(acpi_handle handle, u32 lvl, + void *context, void **rv) +{ + struct acpi_namespace_node *node; + struct seq_file *m = context; + + if (ACPI_FAILURE(acpi_walk_resources(handle, METHOD_NAME__AEI, + gpio_list_resource, NULL))) + return AE_OK; + + node = acpi_ns_validate_handle(handle); + if (!node) { + pr_err(PREFIX "Mapping GPIO handle to node failed\n"); + return AE_OK; + } + + seq_printf(m, "GPIO device name: %4.4s\nAvailable GPIO pin map:\n", + ACPI_CAST_PTR(char, &node->name)); + acpi_walk_resources(handle, METHOD_NAME__AEI, gpio_list_resource, + context); + return AE_OK; +} + +static int gpio_evt_show(struct seq_file *m, void *v) +{ + acpi_get_devices(NULL, gpio_find_resource, m, NULL); + return 0; +} + +static int gpio_evt_open(struct inode *inode, struct file *file) +{ + return single_open(file, gpio_evt_show, NULL); +} + +static const struct file_operations gpio_evt_emu_fops = { + .open = gpio_evt_open, + .write = gpio_evt_write, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static int __init gpio_evt_emu_init(void) +{ + if (acpi_debugfs_dir == NULL) + return -ENOENT; + + gpio_evt_dentry = debugfs_create_file("gpio_event", S_IWUSR, + acpi_debugfs_dir, NULL, &gpio_evt_emu_fops); + if (gpio_evt_dentry == NULL) + return -ENODEV; + + return 0; +} + +device_initcall(gpio_evt_emu_init); +ACPI_MODULE_NAME("acpi_evt_emu"); +MODULE_LICENSE("GPL"); -- 1.9.1

10 years, 10 months

4
8
0 0

[PATCH 1/2] ACPI 5.1: Add missing flag definitions for GTDT

by Hanjun Guo

The flag definitions of TimerFlags and VirtualTimerFlags in struct acpi_gtdt_timer_entry is missing, fix it. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- Those two patches are for ACPICA, I will send them to Bob and Lv. --- source/include/actbl3.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/source/include/actbl3.h b/source/include/actbl3.h index b30e80f..1e59241 100644 --- a/source/include/actbl3.h +++ b/source/include/actbl3.h @@ -432,6 +432,10 @@ typedef struct acpi_gtdt_timer_entry } ACPI_GTDT_TIMER_ENTRY; +/* Flag Definitions: TimerFlags and VirtualTimerFlags above */ + +#define ACPI_GTDT_GT_INTERRUPT_TRIGGER_MODE (1) +#define ACPI_GTDT_GT_INTERRUPT_POLARITY (1<<1) /* Flag Definitions: CommonFlags above */ -- 1.7.9.5

10 years, 10 months

1
1
0 0

leg-kernel tag leg-20140730.0 released

by G Gregory

The leg-kernel release has been made and tagged as leg-20140730.0 This is based on mainline kernel v3.16-rc7 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/2189d8891fd5ae91eeaa56… Notes :- 1) This is the first version of leg-kernel to be based on ACPI 5.1 release.

10 years, 11 months

1
0
0 0

[PATCH] ACPI:GPIO: Add GPIO description on JUNO

by Yi Li

Add the general description for GPIO on JUNO board. Define pin number 256 as power button function (for demo) in this patch. However,JUNO has no GPIO controller in hardware, Using GPIO event emulation which can trigger the GPIO action, then test the GPIO-signal event model for ACPI. Signed-off-by: Yi Li <yi.li(a)linaro.org> --- ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl | 42 ++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl index 5bfd521..e4e9cad 100644 --- a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl +++ b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl @@ -58,6 +58,48 @@ DefinitionBlock ( } } + //GPIO controller description + Device (GPO0) + { + Name (_HID, "LNRO0009") + Name (_ADR, 0) + Name (_UID, 0) + + Name (_CRS, ResourceTemplate () { + //GPIO Register Interface(demo,need to modify by the real h/w setting) + Memory32Fixed (ReadWrite, 0x1c010000, 0x1000) + + //Interrupt vector 0x80 for GPIO controller(demo,need to modify by the real h/w setting) + Interrupt (ResourceConsumer, Edge, ActiveLow, Exclusive) {0x80} + }) + + Name (_AEI,ResourceTemplate () { + //Assume GPIO256 as PowerButton + GpioInt(Edge, ActiveLow, ExclusiveAndWake, PullUp, , " \\_SB.GPO0") {0x100} + }) + + //Handle all ACPI Events signaled by GPIO Controller GPO0 + Method (_EVT, 0x1, Serialized) + { + //Arg0 - EventNumber. An Integer indicating the event number. + //(Controller-relative zero-based GPIO pin number) of the current event. + //Must be in the range 0x0000 - 0xffff. + Switch (ToInteger(Arg0)) + { + //Pin number 256 + Case (0x100) + { + //Notify OSPM the power button is pressed + Notify (PWRB, 0x80) + } + Default + { + + } + } + } + } + //Power button device description Device (PWRB) { -- 1.7.9.5

10 years, 11 months

1
0
0 0

[PATCH] ACPI:PB: Add the power button device on JUNO

by Yi Li

Add the power button description on juno board, notify power button with 0x80 value, the OS will detect the power button is pressed, how to deal with the event which depends on OS's policy. Usually the acpid deamon will call the specific script to let OS shutdown. Signed-off-by: Yi Li <yi.li(a)linaro.org> --- ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl index bdee349..5bfd521 100644 --- a/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl +++ b/ArmPlatformPkg/ArmJunoPkg/AcpiTables/juno/dsdt.asl @@ -58,6 +58,19 @@ DefinitionBlock ( } } + //Power button device description + Device (PWRB) + { + Name (_HID, EISAID("PNP0C0C")) + Name (_ADR, 0) + Name (_UID, 0) + + Method (_STA, 0x0, Notserialized) + { + Return (0x0F) + } + } + // apb_pclk Device (CLK0) { Name (_HID, "LNRO0008") -- 1.7.9.5

10 years, 11 months

1
0
0 0

[PATCH 0/3] Update APM XGene tables to ACPI 5.1

by al.stone＠linaro.org

From: Al Stone <al.stone(a)linaro.org> These patches are my best guess at initial ACPI tables for XGene, in accordance with the new ACPI 5.1 specification. These have not been fully tested yet but that process has been started. Al Stone (3): APM / XGene: Minor cleanup of some of the basics APM / XGene: Update core tables to replace ACPI 5.1 changes APM / XGene: Add in empty SSDT for future use in developing complete tables platforms/APMXGene.acpi/APMXGene.manifest | 1 + platforms/APMXGene.acpi/Apic.asl | 262 ++-- platforms/APMXGene.acpi/Dsdt.asl | 2215 ++++++++++++++++------------- platforms/APMXGene.acpi/Facp.asl | 57 +- platforms/APMXGene.acpi/Gtdt.asl | 87 +- platforms/APMXGene.acpi/Rsdp.asl | 2 +- platforms/APMXGene.acpi/Ssdt.asl | 21 + platforms/APMXGene.acpi/Xsdt.asl | 10 +- 8 files changed, 1508 insertions(+), 1147 deletions(-) create mode 100644 platforms/APMXGene.acpi/Ssdt.asl -- 1.9.3

10 years, 11 months

3
6
0 0

libacpica for aarch64 - package/source?

by Claudio Fontana

Hello, what is the current state of libacpica for aarch64? Are packages available from Linaro (static libs and includes would be best)? Is it available on which linaro trees? Is anything already in upstream libacpica? Thank you, Claudio

10 years, 11 months

2
1
0 0

[PATCH v5 0/3] APEI: Make APEI architecture independent.

by Tomasz Nowicki

APEI is currently implemented so that it depends on x86 hardware. The primary dependency is that GHES uses the x86 NMI for hardware error notification and MCE for memory error handling. These patches remove that dependency. Other APEI features such as error reporting via external IRQ, error serialization, or error injection, do not require changes to use them on non-x86 architectures. The following patch set eliminates the APEI Kconfig x86 dependency by making these changes: - treat NMI notification as GHES architecture - HAVE_ACPI_APEI_NMI - group and wrap around #ifdef CONFIG_HAVE_ACPI_APEI_NMI code which is used only for NMI path - identify architectural boxes and abstract it accordingly (tlb flush and MCE) - rework ioremap for both IRQ and NMI context NMI code is kept in ghes.c file since NMI and IRQ context are tightly coupled. Note, these patches introduce no functional changes for x86. The NMI notification feature is hard selected for x86. Architectures that want to use this feature should also provide NMI code infrastructure. V1->V2 - address Borislav's comment - abstract arch-specific calls instead of wrapping into the #ifdef V2->V3 - address Robert's comment - disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig - rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI V3->V4 - do not abstract NMI calls for archs which do not support it - merge some of patches to make review process easier V4->V5 - markers for preprocessor statements (#else, #endif) around long code block Tomasz Nowicki (3): apei, mce: Factor out APEI architecture specific MCE calls. acpi, apei, ghes: Make NMI error notification to be GHES architecture extension. acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context. arch/x86/Kconfig | 2 + arch/x86/kernel/acpi/Makefile | 1 + arch/x86/kernel/acpi/apei.c | 62 +++++++++++++++ drivers/acpi/apei/Kconfig | 8 +- drivers/acpi/apei/apei-base.c | 13 ++++ drivers/acpi/apei/ghes.c | 173 +++++++++++++++++++++++++++--------------- drivers/acpi/apei/hest.c | 29 +------ include/acpi/apei.h | 4 + include/linux/nmi.h | 4 + 9 files changed, 204 insertions(+), 92 deletions(-) create mode 100644 arch/x86/kernel/acpi/apei.c -- 1.9.1

10 years, 11 months

3
6
0 0

[PATCH v3 0/3] Clean up ACPI core to prepare for running ACPI on ARM64

by Hanjun Guo

This patch set have no function change for x86 and ia64 and just do some clean up to prepare for running ACPI on ARM64. This patch set is splited out from the patch set [1] "[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig" and hope it can be merged first before ARM64 ACPI core patches. [1]: https://lkml.org/lkml/2014/6/26/627 update from v2: Don not select ACPI_LEGACY_TABLES_LOOKUP on IA64 which is catched by Peter. update from v1: 1. Drop "Make EC debugfs depend on X86 || IA64 in Kconfig"; 2. Rename ACPI_SCAN_BIOS_NOT_EFI to ACPI_LEGACY_TABLES_LOOKUP suggested by Rafael; 3. Rename ARCH_HAS_ACPI_PDC to ARCH_MIGHT_HAVE_ACPI_PDC suggested by Rafael; 4. Remove the help for ARCH_MIGHT_HAVE_ACPI_PDC because it can't be selected; 5. Rename acpi_arch_is_smp() to acpi_has_cpu_in_madt() to be more explicit and easy understanding. Graeme Gregory (2): ACPI: ARM64 does not have a BIOS add config for BIOS table scan. ACPI: Don't use acpi_lapic in ACPI core code Hanjun Guo (1): ACPI / processor: Introduce ARCH_HAS_ACPI_PDC arch/ia64/Kconfig | 1 + arch/ia64/include/asm/acpi.h | 5 + arch/x86/Kconfig | 2 + arch/x86/include/asm/acpi.h | 5 + drivers/acpi/Kconfig | 6 ++ drivers/acpi/Makefile | 1 + drivers/acpi/acpi_processor.c | 2 +- drivers/acpi/internal.h | 5 + drivers/acpi/osl.c | 4 +- drivers/acpi/processor_core.c | 198 --------------------------------------- drivers/acpi/processor_pdc.c | 206 +++++++++++++++++++++++++++++++++++++++++ 11 files changed, 235 insertions(+), 200 deletions(-) create mode 100644 drivers/acpi/processor_pdc.c -- 1.7.9.5

10 years, 11 months

2
4
0 0

[PATCH v2 0/3] Clean up ACPI core to prepare for running ACPI on ARM64

by Hanjun Guo

This patch set have no function change for x86 and ia64 and just do some clean up to prepare for running ACPI on ARM64. This patch set is splited out from the patch set [1] "[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig" and hope it can be merged first before ARM64 ACPI core patches. [1]: https://lkml.org/lkml/2014/6/26/627 update from v1: 1. Drop "Make EC debugfs depend on X86 || IA64 in Kconfig"; 2. Rename ACPI_SCAN_BIOS_NOT_EFI to ACPI_LEGACY_TABLES_LOOKUP suggested by Rafael; 3. Rename ARCH_HAS_ACPI_PDC to ARCH_MIGHT_HAVE_ACPI_PDC suggested by Rafael; 4. Remove the help for ARCH_MIGHT_HAVE_ACPI_PDC because it can't be selected; 5. Rename acpi_arch_is_smp() to acpi_has_cpu_in_madt() to be more explicit and easy understanding. Graeme Gregory (2): ACPI: ARM64 does not have a BIOS add config for BIOS table scan. ACPI: Don't use acpi_lapic in ACPI core code Hanjun Guo (1): ACPI / processor: Introduce ARCH_HAS_ACPI_PDC arch/ia64/Kconfig | 2 + arch/ia64/include/asm/acpi.h | 5 + arch/x86/Kconfig | 2 + arch/x86/include/asm/acpi.h | 5 + drivers/acpi/Kconfig | 6 ++ drivers/acpi/Makefile | 1 + drivers/acpi/acpi_processor.c | 2 +- drivers/acpi/internal.h | 5 + drivers/acpi/osl.c | 4 +- drivers/acpi/processor_core.c | 198 --------------------------------------- drivers/acpi/processor_pdc.c | 206 +++++++++++++++++++++++++++++++++++++++++ 11 files changed, 236 insertions(+), 200 deletions(-) create mode 100644 drivers/acpi/processor_pdc.c -- 1.7.9.5

10 years, 11 months

4
12
0 0

[PATCH 0/4] Clean up ACPI core to prepare for running ACPI on ARM64

by Hanjun Guo

This patch set have no function change for x86 and ia64 and just do some clean up to prepare for running ACPI on ARM64. This patch set is splited out from the patch set [1] "[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig" and hope it can be merged first before ARM64 ACPI core patches. [1]: https://lkml.org/lkml/2014/6/26/627 Graeme Gregory (2): ACPI: ARM64 does not have a BIOS add config for BIOS table scan. ACPI: Don't use acpi_lapic in ACPI core code Hanjun Guo (2): ACPI / processor: Introduce ARCH_HAS_ACPI_PDC ACPI: Make EC debugfs depend on X86 || IA64 in Kconfig arch/ia64/Kconfig | 2 + arch/ia64/include/asm/acpi.h | 5 + arch/x86/Kconfig | 2 + arch/x86/include/asm/acpi.h | 5 + drivers/acpi/Kconfig | 14 +++ drivers/acpi/Makefile | 1 + drivers/acpi/acpi_processor.c | 2 +- drivers/acpi/internal.h | 5 + drivers/acpi/osl.c | 4 +- drivers/acpi/processor_core.c | 198 --------------------------------------- drivers/acpi/processor_pdc.c | 206 +++++++++++++++++++++++++++++++++++++++++ 11 files changed, 244 insertions(+), 200 deletions(-) create mode 100644 drivers/acpi/processor_pdc.c -- 1.7.9.5

10 years, 12 months

2
12
0 0

[PATCH v4 0/3] APEI: Make APEI architecture independent.

by Tomasz Nowicki

APEI is currently implemented so that it depends on x86 hardware. The primary dependency is that GHES uses the x86 NMI for hardware error notification and MCE for memory error handling. These patches remove that dependency. Other APEI features such as error reporting via external IRQ, error serialization, or error injection, do not require changes to use them on non-x86 architectures. The following patch set eliminates the APEI Kconfig x86 dependency by making these changes: - treat NMI notification as GHES architecture - HAVE_ACPI_APEI_NMI - group and wrap around #ifdef CONFIG_HAVE_ACPI_APEI_NMI code which is used only for NMI path - identify architectural boxes and abstract it accordingly (tlb flush and MCE) - rework ioremap for both IRQ and NMI context NMI code is kept in ghes.c file since NMI and IRQ context are tightly coupled. Note, these patches introduce no functional changes for x86. The NMI notification feature is hard selected for x86. Architectures that want to use this feature should also provide NMI code infrastructure. V1->V2 - address Borislav's comment - abstract arch-specific calls instead of wrapping into the #ifdef V2->V3 - address Robert's comment - disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig - rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI V3->V4 - do not abstract NMI calls for archs which do not support it - merge some of patches to make review process easier Tomasz Nowicki (3): apei, mce: Factor out APEI architecture specific MCE calls. acpi, apei, ghes: Make NMI error notification to be GHES architecture extension. acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context. arch/x86/Kconfig | 2 + arch/x86/kernel/acpi/Makefile | 1 + arch/x86/kernel/acpi/apei.c | 62 +++++++++++++++ drivers/acpi/apei/Kconfig | 8 +- drivers/acpi/apei/apei-base.c | 13 ++++ drivers/acpi/apei/ghes.c | 173 ++++++++++++++++++++++++++--------------- drivers/acpi/apei/hest.c | 29 +------ include/acpi/apei.h | 4 + include/linux/nmi.h | 4 + 9 files changed, 204 insertions(+), 92 deletions(-) create mode 100644 arch/x86/kernel/acpi/apei.c -- 1.7.9.5

10 years, 12 months

2
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi