Re: [Devel] [PATCH] Add support to parse RASF Table
by Moore, Robert
Sorry for the delay.
Yes, this looks like we can take this.
Bob
> -----Original Message-----
> From: Sajjan, Vikas C [mailto:vikas.cha.sajjan@hpe.com]
> Sent: Monday, May 30, 2016 9:57 PM
> To: Moore, Robert
> Cc: Lakshminarasimha, Sunil Vishwanathpur; rjw(a)rjwysocki.net;
> devel(a)acpica.org; linux-acpi(a)vger.kernel.org; K V, Nagendra; linaro-
> acpi(a)lists.linaro.org; linux-arm-kernel(a)lists.infradead.org
> Subject: RE: [PATCH] Add support to parse RASF Table
>
> Hi Bob,
>
> Any thoughts on this patch
>
> Regards
> Vikas Sajjan
>
> -----Original Message-----
> From: K V, Nagendra
> Sent: Monday, May 16, 2016 2:05 PM
> To: robert.moore(a)intel.com
> Cc: Sajjan, Vikas C <vikas.cha.sajjan(a)hpe.com>; Lakshminarasimha, Sunil
> Vishwanathpur <sunil.vl(a)hpe.com>; devel(a)acpica.org; linux-
> acpi(a)vger.kernel.org
> Subject: RE: [PATCH] Add support to parse RASF Table
>
> Bob,
>
> Did you get chance to look into this?
>
> Regards
> Nagendra
>
> -----Original Message-----
> From: K V, Nagendra
> Sent: Monday, May 09, 2016 5:48 PM
> To: robert.moore(a)intel.com
> Cc: Sajjan, Vikas C <vikas.cha.sajjan(a)hpe.com>; Lakshminarasimha, Sunil
> Vishwanathpur <sunil.vl(a)hpe.com>; devel(a)acpica.org; K V, Nagendra
> <nagendra.k-v(a)hpe.com>
> Subject: [PATCH] Add support to parse RASF Table
>
> This patch adds support to parse RASF table. Currently RASF table is not
> being recognized.
> ---
> source/common/ahtable.c | 1 +
> source/common/dmtable.c | 7 +++++++
> source/common/dmtbinfo.c | 13 +++++++++++++
> source/compiler/dtcompiler.h | 1 +
> source/compiler/dttemplate.h | 11 +++++++++++
> source/compiler/dtutils.c | 5 +++++
> source/include/acdisasm.h | 2 ++
> 7 files changed, 40 insertions(+)
>
> diff --git a/source/common/ahtable.c b/source/common/ahtable.c index
> 021ae33..59ddc83 100644
> --- a/source/common/ahtable.c
> +++ b/source/common/ahtable.c
> @@ -196,6 +196,7 @@ const AH_TABLE AcpiSupportedTables[] =
> {ACPI_SIG_NFIT, "NVDIMM Firmware Interface Table"},
> {ACPI_SIG_PCCT, "Platform Communications Channel Table"},
> {ACPI_SIG_PMTT, "Platform Memory Topology Table"},
> + {ACPI_SIG_RASF, "RAS Features Table"},
> {ACPI_RSDP_NAME,"Root System Description Pointer"},
> {ACPI_SIG_RSDT, "Root System Description Table"},
> {ACPI_SIG_S3PT, "S3 Performance Table"}, diff --git
> a/source/common/dmtable.c b/source/common/dmtable.c index 51d91f8..321407c
> 100644
> --- a/source/common/dmtable.c
> +++ b/source/common/dmtable.c
> @@ -430,6 +430,7 @@ const ACPI_DMTABLE_DATA AcpiDmTableData[] =
> {ACPI_SIG_NFIT, AcpiDmTableInfoNfit, AcpiDmDumpNfit,
> DtCompileNfit, TemplateNfit},
> {ACPI_SIG_PCCT, AcpiDmTableInfoPcct, AcpiDmDumpPcct,
> DtCompilePcct, TemplatePcct},
> {ACPI_SIG_PMTT, NULL, AcpiDmDumpPmtt,
> DtCompilePmtt, TemplatePmtt},
> + {ACPI_SIG_RASF, AcpiDmTableInfoRasf, NULL, NULL,
> TemplateRasf},
> {ACPI_SIG_RSDT, NULL, AcpiDmDumpRsdt,
> DtCompileRsdt, TemplateRsdt},
> {ACPI_SIG_S3PT, NULL, NULL, NULL,
> TemplateS3pt},
> {ACPI_SIG_SBST, AcpiDmTableInfoSbst, NULL, NULL,
> TemplateSbst},
> @@ -916,6 +917,11 @@ AcpiDmDumpTable (
> ByteLength = 10;
> break;
>
> + case ACPI_DMT_RASF:
> +
> + ByteLength = 12;
> + break;
> +
> case ACPI_DMT_BUF16:
> case ACPI_DMT_UUID:
>
> @@ -1048,6 +1054,7 @@ AcpiDmDumpTable (
>
> /* Integer Data Types */
>
> + case ACPI_DMT_RASF:
> case ACPI_DMT_UINT8:
> case ACPI_DMT_UINT16:
> case ACPI_DMT_UINT24:
> diff --git a/source/common/dmtbinfo.c b/source/common/dmtbinfo.c index
> 5520da2..3896b69 100644
> --- a/source/common/dmtbinfo.c
> +++ b/source/common/dmtbinfo.c
> @@ -178,6 +178,7 @@
> #define ACPI_NFIT_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_NFIT,f)
> #define ACPI_PCCT_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_PCCT,f)
> #define ACPI_PMTT_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_PMTT,f)
> +#define ACPI_RASF_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_RASF,f)
> #define ACPI_S3PT_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_S3PT,f)
> #define ACPI_SBST_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_SBST,f)
> #define ACPI_SLIT_OFFSET(f) (UINT16) ACPI_OFFSET
> (ACPI_TABLE_SLIT,f)
> @@ -2512,6 +2513,18 @@ ACPI_DMTABLE_INFO AcpiDmTableInfoPmtt2[]
> =
>
>
> /*************************************************************************
> ******
> *
> + * RASF - RAS Feature table
> + *
> + **********************************************************************
> + ********/
> +
> +ACPI_DMTABLE_INFO AcpiDmTableInfoRasf[] =
> +{
> + {ACPI_DMT_RASF, ACPI_RASF_OFFSET (ChannelId[0]),
> "Channel Identifier", 0},
> + ACPI_DMT_TERMINATOR
> +};
> +
> +/**********************************************************************
> +*********
> + *
> * S3PT - S3 Performance Table
> *
>
> **************************************************************************
> ****/
> diff --git a/source/compiler/dtcompiler.h b/source/compiler/dtcompiler.h
> index eb85ddc..1072f52 100644
> --- a/source/compiler/dtcompiler.h
> +++ b/source/compiler/dtcompiler.h
> @@ -681,6 +681,7 @@ extern const unsigned char TemplateMtmr[]; extern
> const unsigned char TemplateNfit[]; extern const unsigned char
> TemplatePcct[]; extern const unsigned char TemplatePmtt[];
> +extern const unsigned char TemplateRasf[];
> extern const unsigned char TemplateRsdt[]; extern const unsigned char
> TemplateS3pt[]; extern const unsigned char TemplateSbst[]; diff --git
> a/source/compiler/dttemplate.h b/source/compiler/dttemplate.h index
> e420ec4..d17b2af 100644
> --- a/source/compiler/dttemplate.h
> +++ b/source/compiler/dttemplate.h
> @@ -978,6 +978,17 @@ const unsigned char TemplatePmtt[] =
> 0x00,0x00,0x00,0x00 /* 000000B0 "...."
> */
> };
>
> +const unsigned char TemplateRasf[] =
> +{
> + 0x42,0x45,0x52,0x54,0x30,0x00,0x00,0x00, /* 00000000 "RASF0..."
> */
> + 0x01,0x15,0x49,0x4E,0x54,0x45,0x4C,0x20, /* 00000008 "..INTEL "
> */
> + 0x54,0x45,0x4D,0x50,0x4C,0x41,0x54,0x45, /* 00000010 "TEMPLATE"
> */
> + 0x01,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL"
> */
> + 0x28,0x05,0x10,0x20,0x00,0x00,0x00,0x00, /* 00000020 "(.. ...."
> */
> + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00, /* 00000028 "........"
> */
> + 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00 /* 00000030 "........"
> */
> +};
> +
> const unsigned char TemplateRsdp[] =
> {
> 0x52,0x53,0x44,0x20,0x50,0x54,0x52,0x20, /* 00000000 "RSD PTR "
> */
> diff --git a/source/compiler/dtutils.c b/source/compiler/dtutils.c index
> 6ca418c..774db8b 100644
> --- a/source/compiler/dtutils.c
> +++ b/source/compiler/dtutils.c
> @@ -688,6 +688,11 @@ DtGetFieldLength (
> ByteLength = 10;
> break;
>
> + case ACPI_DMT_RASF:
> +
> + ByteLength = 12;
> + break;
> +
> case ACPI_DMT_BUF16:
> case ACPI_DMT_UUID:
>
> diff --git a/source/include/acdisasm.h b/source/include/acdisasm.h index
> ba8f274..d59e4d9 100644
> --- a/source/include/acdisasm.h
> +++ b/source/include/acdisasm.h
> @@ -227,6 +227,7 @@ typedef enum
> ACPI_DMT_NFIT,
> ACPI_DMT_PCCT,
> ACPI_DMT_PMTT,
> + ACPI_DMT_RASF,
> ACPI_DMT_SLIC,
> ACPI_DMT_SRAT,
>
> @@ -458,6 +459,7 @@ extern ACPI_DMTABLE_INFO
> AcpiDmTableInfoPcctHdr[];
> extern ACPI_DMTABLE_INFO AcpiDmTableInfoPcct0[];
> extern ACPI_DMTABLE_INFO AcpiDmTableInfoPcct1[];
> extern ACPI_DMTABLE_INFO AcpiDmTableInfoPcct2[];
> +extern ACPI_DMTABLE_INFO AcpiDmTableInfoRasf[];
> extern ACPI_DMTABLE_INFO AcpiDmTableInfoRsdp1[];
> extern ACPI_DMTABLE_INFO AcpiDmTableInfoRsdp2[];
> extern ACPI_DMTABLE_INFO AcpiDmTableInfoS3pt[];
> --
> 2.5.0
>
6 years, 4 months
Re: [Devel] [PATCH v7 13/15] ACPI / processor: Add acpi_map_madt_entry().
by Hanjun Guo
On 2016/5/25 6:35, David Daney wrote:
> From: David Daney <david.daney(a)cavium.com>
>
> Follow-on arm64 ACPI/NUMA patches need to map MADT entries very early
> (before kmalloc is usable).
>
> Add acpi_map_madt_entry() which, indirectly, uses
> early_memremap()/early_memunmap() to access the table and parse out
> the mpidr. The existing implementation of map_madt_entry() is
> modified to take a pointer to the MADT as a parameter and the callers
> adjusted.
>
> Signed-off-by: David Daney <david.daney(a)cavium.com>
> ---
> drivers/acpi/processor_core.c | 26 ++++++++++++++++++++++----
> include/acpi/processor.h | 1 +
> 2 files changed, 23 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
> index 33a38d6..9125d7d 100644
> --- a/drivers/acpi/processor_core.c
> +++ b/drivers/acpi/processor_core.c
> @@ -108,13 +108,12 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
> return -EINVAL;
> }
>
> -static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> +static phys_cpuid_t map_madt_entry(struct acpi_table_madt *madt,
> + int type, u32 acpi_id)
> {
> unsigned long madt_end, entry;
> phys_cpuid_t phys_id = PHYS_CPUID_INVALID; /* CPU hardware ID */
> - struct acpi_table_madt *madt;
>
> - madt = get_madt_table();
> if (!madt)
> return phys_id;
>
> @@ -145,6 +144,25 @@ static phys_cpuid_t map_madt_entry(int type, u32 acpi_id)
> return phys_id;
> }
>
> +phys_cpuid_t __init acpi_map_madt_entry(u32 acpi_id)
> +{
> + struct acpi_table_madt *madt = NULL;
> + acpi_size tbl_size;
> + phys_cpuid_t rv;
> +
> + acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt,
> + &tbl_size);
> + if (!madt)
> + return PHYS_CPUID_INVALID;
> +
> + rv = map_madt_entry(madt, 1, acpi_id);
Just nit-pick, pass 1 here means we need to define an acpi processor
device object in DSDT (see function map_gicc_mpidr(),
device_declaration), it would be fine for x2apic and gic mode,
but not for lapic mode, since the function name is acpi_map_madt_entry
which is general for all architecture, it will confuse people I think.
How about rename acpi_map_madt_entry() to acpi_map_madt_gicc_entry()?
It's only used for AMR64 to get mpidrs from GICC entries using acpi_id,
other than that, it's good to me.
Thanks
Hanjun
6 years, 4 months
Re: [Devel] [PATCH v7 07/15] arm64, numa: Cleanup NUMA disabled messages.
by Hanjun Guo
On 2016/5/25 6:35, David Daney wrote:
> From: David Daney <david.daney(a)cavium.com>
>
> As noted by Dennis Chen, we don't want to print "No NUMA configuration
> found" if NUMA was forced off from the command line.
>
> Change the type of numa_off to bool, and clean up printing code.
> Print "NUMA disabled" if forced off on command line and "No NUMA
> configuration found" if there was no firmware NUMA information.
>
> Signed-off-by: David Daney <david.daney(a)cavium.com>
> Acked-by: Catalin Marinas <catalin.marinas(a)arm.com>
> ---
> arch/arm64/mm/numa.c | 11 +++++++----
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 6cb03f9..1def1de 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -29,7 +29,7 @@ static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
>
> static int numa_distance_cnt;
> static u8 *numa_distance;
> -static int numa_off;
> +static bool numa_off;
>
> static __init int numa_parse_early_param(char *opt)
> {
> @@ -37,7 +37,7 @@ static __init int numa_parse_early_param(char *opt)
> return -EINVAL;
> if (!strncmp(opt, "off", 3)) {
> pr_info("%s\n", "NUMA turned off");
> - numa_off = 1;
> + numa_off = true;
> }
> return 0;
> }
> @@ -362,7 +362,10 @@ static int __init dummy_numa_init(void)
> int ret;
> struct memblock_region *mblk;
>
> - pr_info("%s\n", "No NUMA configuration found");
> + if (numa_off)
> + pr_info("NUMA disabled\n"); /* Forced off on command line. */
> + else
> + pr_info("No NUMA configuration found\n");
> pr_info("NUMA: Faking a node at [mem %#018Lx-%#018Lx]\n",
> 0LLU, PFN_PHYS(max_pfn) - 1);
>
> @@ -375,7 +378,7 @@ static int __init dummy_numa_init(void)
> return ret;
> }
>
> - numa_off = 1;
> + numa_off = true;
> return 0;
> }
Reviewed-by: Hanjun Guo <hanjun.guo(a)linaro.org>
>
>
6 years, 4 months
ACPICA version 20160527
by Moore, Robert
27 May 2016. Summary of changes for version 20160527:
This release is available at https://acpica.org/downloads
1) ACPICA kernel-resident subsystem:
Temporarily reverted the new arbitrary bit length/alignment support in AcpiHwRead/AcpiHwWrite for the Generic Address Structure. There have been a number of regressions with the new code that need to be fully resolved and tested before this support can be finally integrated into ACPICA. Apologies for any inconveniences these issues may have caused.
The ACPI message macros are not configurable (ACPI_MSG_ERROR, ACPI_MSG_EXCEPTION, ACPI_MSG_WARNING, ACPI_MSG_INFO, ACPI_MSG_BIOS_ERROR, and ACPI_MSG_BIOS_WARNING). Lv Zheng.
Fixed a couple of GCC warnings associated with the use of the -Wcast-qual option. Adds a new return macro, return_STR. Junk-uk Kim.
Example Code and Data Size: These are the sizes for the OS-independent acpica.lib produced by the Microsoft Visual C++ 9.0 32-bit compiler. The debug version of the code includes the debug output trace mechanism and has a much larger code and data size.
Current Release:
Non-Debug Version: 136.8K Code, 51.6K Data, 188.4K Total
Debug Version: 201.5K Code, 82.2K Data, 283.7K Total
Previous Release:
Non-Debug Version: 137.4K Code, 52.6K Data, 190.0K Total
Debug Version: 200.9K Code, 82.2K Data, 283.1K Total
6 years, 4 months
Re: [Devel] [PATCH v6 13/14] arm64, acpi, numa: NUMA support based on SRAT and SLIT
by Hanjun Guo
On 2016/5/12 8:06, David Daney wrote:
> On 05/11/2016 03:39 AM, Catalin Marinas wrote:
>> On Wed, Apr 27, 2016 at 11:07:15AM -0700, David Daney wrote:
>>> +static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
>>> +{
>>> + unsigned long madt_end, entry;
>>> + struct acpi_table_madt *madt;
>>> + acpi_size tbl_size;
>>> +
>>> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
>>> + (struct acpi_table_header **)&madt, &tbl_size)))
>>> + return -ENODEV;
>>> +
>>> + entry = (unsigned long)madt;
>>> + madt_end = entry + madt->header.length;
>>> +
>>> + /* Parse all entries looking for a match. */
>>> + entry += sizeof(struct acpi_table_madt);
>>> + while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
>>> + struct acpi_subtable_header *header =
>>> + (struct acpi_subtable_header *)entry;
>>> +
>>> + if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
>>> + struct acpi_madt_generic_interrupt *gicc =
>>> + container_of(header,
>>> + struct acpi_madt_generic_interrupt, header);
>>> +
>>> + if ((gicc->flags & ACPI_MADT_ENABLED) &&
>>> + (gicc->uid == acpi_id)) {
>>> + *mpidr = gicc->arm_mpidr;
>>> + early_acpi_os_unmap_memory(madt, tbl_size);
>>> + return 0;
>>> + }
>>> + }
>>> + entry += header->length;
>>> + }
>>> +
>>> + early_acpi_os_unmap_memory(madt, tbl_size);
>>> + return -ENODEV;
>>> +}
>>> +
>>> +/* Callback for Proximity Domain -> ACPI processor UID mapping */
>>> +void __init acpi_numa_gicc_affinity_init(struct
>>> acpi_srat_gicc_affinity *pa)
>>> +{
>>> + int pxm, node;
>>> + u64 mpidr;
>>> +
>>> + if (srat_disabled())
>>> + return;
>>> +
>>> + if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
>>> + pr_err("SRAT: Invalid SRAT header length: %d\n",
>>> + pa->header.length);
>>> + bad_srat();
>>> + return;
>>> + }
>>> +
>>> + if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
>>> + return;
>>> +
>>> + if (cpus_in_srat >= NR_CPUS) {
>>> + pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may
>>> not be able to use all cpus\n",
>>> + NR_CPUS);
>>> + return;
>>> + }
>>> +
>>> + pxm = pa->proximity_domain;
>>> + node = acpi_map_pxm_to_node(pxm);
>>> +
>>> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
>>> + pr_err("SRAT: Too many proximity domains %d\n", pxm);
>>> + bad_srat();
>>> + return;
>>> + }
>>> +
>>> + if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
>>> + pr_err("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in
>>> MADT\n",
>>> + pxm, pa->acpi_processor_uid);
>>> + bad_srat();
>>> + return;
>>> + }
>>
>> I wonder whether you could replace the get_mpidr_in_madt() function with
>> something like acpi_get_phys_id(). It looks like get_mpidr_in_madt()
>> duplicates functionality already available elsewhere.
>>
>
> I just tried that, and it doesn't work.
>
> The problem is that this code is being run very early in the boot, and
> kmalloc cannot be used. acpi_get_phys_id() and its ilk can only be used
> once we have working kmalloc. We need to extract the NUMA information
> early like this precisely because it is needed to initializing the slab
> system
>
> Notice that we are using early_acpi_os_unmap_memory() et al. in
> get_mpidr_in_madt() explicitly for this reason.
I got the same conclusion when I was preparing this patch set.
Thanks
Hanjun
6 years, 4 months
New: Introduction to ACPI document
by Moore, Robert
A new document, "Introduction to ACPI" has been posted to the ACPICA website, available at:
https://acpica.org/documentation
It contains a very high-level overview of the ACPI architecture, and it will be integrated into the ACPI specification itself.
The document is open until the next version of the ACPI specification is released, so comments are welcome.
Thanks,
Bob Moore
Intel Corporation
6 years, 5 months