* [PATCH v3 0/2] PPTT handle Handle architecturally unknown cache types @ 2018-09-28 2:57 Jeffrey Hugo 2018-09-28 2:57 ` [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for " Jeffrey Hugo 2018-09-28 2:57 ` [PATCH v3 2/2] ACPI/PPTT: Handle architecturally " Jeffrey Hugo 0 siblings, 2 replies; 9+ messages in thread From: Jeffrey Hugo @ 2018-09-28 2:57 UTC (permalink / raw) To: sudeep.holla, gregkh, rjw, linux-acpi, jeremy.linton Cc: linux-kernel, vkilari, Jeffrey Hugo The ARM Architecture Reference Manual allows for caches to be "invisible" and thus not specified in the system registers under some scenarios such as if the cache cannot be managed by set/way operations. However, such caches may be specified in the ACPI PPTT table for workload performance/scheduling optimizations. Currently such caches can cause an error in lscpu - lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such file or directory and result in no output, providing a poor user experience. lstopo is also affected as such caches are not included in the output. Address these issues by attempting to be a little more discerning about when cache information is provided to userspace, and also utilize all sources for cache information when possible. [v3] -removed valid flag in PPTT -Added Jeremy Linton's reviewed-by [v2] -Updated cacheinfo per Sudeep's suggestion -Integrated the PPTT fix into existing PPTT code per Sudeep's suggestion Jeffrey Hugo (2): drivers: base: cacheinfo: Do not populate sysfs for unknown cache types ACPI/PPTT: Handle architecturally unknown cache types drivers/acpi/pptt.c | 15 +++++++++++---- drivers/base/cacheinfo.c | 2 ++ 2 files changed, 13 insertions(+), 4 deletions(-) -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for unknown cache types 2018-09-28 2:57 [PATCH v3 0/2] PPTT handle Handle architecturally unknown cache types Jeffrey Hugo @ 2018-09-28 2:57 ` Jeffrey Hugo 2018-10-02 10:49 ` Sudeep Holla 2018-10-03 9:35 ` Rafael J. Wysocki 2018-09-28 2:57 ` [PATCH v3 2/2] ACPI/PPTT: Handle architecturally " Jeffrey Hugo 1 sibling, 2 replies; 9+ messages in thread From: Jeffrey Hugo @ 2018-09-28 2:57 UTC (permalink / raw) To: sudeep.holla, gregkh, rjw, linux-acpi, jeremy.linton Cc: linux-kernel, vkilari, Jeffrey Hugo If a cache has an unknown type because neither the hardware nor the firmware told us, an entry in the sysfs tree will be made, but the type file will not be present. lscpu depends on the type file being present for every entry, and will error out without printing system information if lscpu cannot open the type file. Presenting information about a cache without indicating its type is not useful, therefore if we hit a cache with an unknown type, stop populating sysfs so that userspace has the maximum amount of useful information. This addresses the following lscpu error, which prevents any output. lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such file or directory Suggested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> --- drivers/base/cacheinfo.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 5d5b598..cf78fa6 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -615,6 +615,8 @@ static int cache_add_dev(unsigned int cpu) this_leaf = this_cpu_ci->info_list + i; if (this_leaf->disable_sysfs) continue; + if (this_leaf->type == CACHE_TYPE_NOCACHE) + break; cache_groups = cache_get_attribute_groups(this_leaf); ci_dev = cpu_device_create(parent, this_leaf, cache_groups, "index%1u", i); -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for unknown cache types 2018-09-28 2:57 ` [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for " Jeffrey Hugo @ 2018-10-02 10:49 ` Sudeep Holla 2018-10-03 9:35 ` Rafael J. Wysocki 1 sibling, 0 replies; 9+ messages in thread From: Sudeep Holla @ 2018-10-02 10:49 UTC (permalink / raw) To: Jeffrey Hugo Cc: gregkh, rjw, linux-acpi, jeremy.linton, linux-kernel, vkilari On Thu, Sep 27, 2018 at 08:57:56PM -0600, Jeffrey Hugo wrote: > If a cache has an unknown type because neither the hardware nor the > firmware told us, an entry in the sysfs tree will be made, but the type > file will not be present. lscpu depends on the type file being present > for every entry, and will error out without printing system information > if lscpu cannot open the type file. > > Presenting information about a cache without indicating its type is not > useful, therefore if we hit a cache with an unknown type, stop populating > sysfs so that userspace has the maximum amount of useful information. > > This addresses the following lscpu error, which prevents any output. > lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such > file or directory > > Suggested-by: Sudeep Holla <sudeep.holla@arm.com> > Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> > Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> -- Regards, Sudeep ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for unknown cache types 2018-09-28 2:57 ` [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for " Jeffrey Hugo 2018-10-02 10:49 ` Sudeep Holla @ 2018-10-03 9:35 ` Rafael J. Wysocki 2018-10-03 13:47 ` Jeffrey Hugo 1 sibling, 1 reply; 9+ messages in thread From: Rafael J. Wysocki @ 2018-10-03 9:35 UTC (permalink / raw) To: Jeffrey Hugo Cc: sudeep.holla, gregkh, linux-acpi, jeremy.linton, linux-kernel, vkilari On Friday, September 28, 2018 4:57:56 AM CEST Jeffrey Hugo wrote: > If a cache has an unknown type because neither the hardware nor the > firmware told us, an entry in the sysfs tree will be made, but the type > file will not be present. lscpu depends on the type file being present > for every entry, and will error out without printing system information > if lscpu cannot open the type file. > > Presenting information about a cache without indicating its type is not > useful, therefore if we hit a cache with an unknown type, stop populating > sysfs so that userspace has the maximum amount of useful information. > > This addresses the following lscpu error, which prevents any output. > lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such > file or directory > > Suggested-by: Sudeep Holla <sudeep.holla@arm.com> > Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> > Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> > --- > drivers/base/cacheinfo.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c > index 5d5b598..cf78fa6 100644 > --- a/drivers/base/cacheinfo.c > +++ b/drivers/base/cacheinfo.c > @@ -615,6 +615,8 @@ static int cache_add_dev(unsigned int cpu) > this_leaf = this_cpu_ci->info_list + i; > if (this_leaf->disable_sysfs) > continue; > + if (this_leaf->type == CACHE_TYPE_NOCACHE) > + break; > cache_groups = cache_get_attribute_groups(this_leaf); > ci_dev = cpu_device_create(parent, this_leaf, cache_groups, > "index%1u", i); > Can you please resend this patch with all tags collected so far? Patchwork doesn't seem to have picked it up. Thanks, Rafael ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for unknown cache types 2018-10-03 9:35 ` Rafael J. Wysocki @ 2018-10-03 13:47 ` Jeffrey Hugo 0 siblings, 0 replies; 9+ messages in thread From: Jeffrey Hugo @ 2018-10-03 13:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: sudeep.holla, gregkh, linux-acpi, jeremy.linton, linux-kernel, vkilari On 10/3/2018 3:35 AM, Rafael J. Wysocki wrote: > On Friday, September 28, 2018 4:57:56 AM CEST Jeffrey Hugo wrote: >> If a cache has an unknown type because neither the hardware nor the >> firmware told us, an entry in the sysfs tree will be made, but the type >> file will not be present. lscpu depends on the type file being present >> for every entry, and will error out without printing system information >> if lscpu cannot open the type file. >> >> Presenting information about a cache without indicating its type is not >> useful, therefore if we hit a cache with an unknown type, stop populating >> sysfs so that userspace has the maximum amount of useful information. >> >> This addresses the following lscpu error, which prevents any output. >> lscpu: cannot open /sys/devices/system/cpu/cpu0/cache/index3/type: No such >> file or directory >> >> Suggested-by: Sudeep Holla <sudeep.holla@arm.com> >> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> >> Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> >> --- >> drivers/base/cacheinfo.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c >> index 5d5b598..cf78fa6 100644 >> --- a/drivers/base/cacheinfo.c >> +++ b/drivers/base/cacheinfo.c >> @@ -615,6 +615,8 @@ static int cache_add_dev(unsigned int cpu) >> this_leaf = this_cpu_ci->info_list + i; >> if (this_leaf->disable_sysfs) >> continue; >> + if (this_leaf->type == CACHE_TYPE_NOCACHE) >> + break; >> cache_groups = cache_get_attribute_groups(this_leaf); >> ci_dev = cpu_device_create(parent, this_leaf, cache_groups, >> "index%1u", i); >> > > Can you please resend this patch with all tags collected so far? Will do. -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v3 2/2] ACPI/PPTT: Handle architecturally unknown cache types 2018-09-28 2:57 [PATCH v3 0/2] PPTT handle Handle architecturally unknown cache types Jeffrey Hugo 2018-09-28 2:57 ` [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for " Jeffrey Hugo @ 2018-09-28 2:57 ` Jeffrey Hugo 2018-09-28 21:52 ` Jeremy Linton 2018-10-02 10:57 ` Sudeep Holla 1 sibling, 2 replies; 9+ messages in thread From: Jeffrey Hugo @ 2018-09-28 2:57 UTC (permalink / raw) To: sudeep.holla, gregkh, rjw, linux-acpi, jeremy.linton Cc: linux-kernel, vkilari, Jeffrey Hugo The type of a cache might not be specified by architectural mechanisms (ie system registers), but its type might be specified in the PPTT. In this case, we should populate the type of the cache, rather than leave it undefined. This fixes the issue where the cacheinfo driver will not populate sysfs for such caches, resulting in the information missing from utilities like lstopo and lscpu, thus degrading the user experience. Fixes: 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing) Reported-by: Vijaya Kumar K <vkilari@codeaurora.org> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> --- drivers/acpi/pptt.c | 30 +++++++++++++----------------- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index d1e26cb..38ac30e 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -357,25 +357,15 @@ static void update_cache_properties(struct cacheinfo *this_leaf, struct acpi_pptt_cache *found_cache, struct acpi_pptt_processor *cpu_node) { - int valid_flags = 0; - this_leaf->fw_token = cpu_node; - if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) { + if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) this_leaf->size = found_cache->size; - valid_flags++; - } - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) this_leaf->coherency_line_size = found_cache->line_size; - valid_flags++; - } - if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) { + if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) this_leaf->number_of_sets = found_cache->number_of_sets; - valid_flags++; - } - if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) { + if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) this_leaf->ways_of_associativity = found_cache->associativity; - valid_flags++; - } if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) { switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) { case ACPI_PPTT_CACHE_POLICY_WT: @@ -402,11 +392,17 @@ static void update_cache_properties(struct cacheinfo *this_leaf, } } /* - * If the above flags are valid, and the cache type is NOCACHE - * update the cache type as well. + * If cache type is NOCACHE, then the cache hasn't been specified + * via other mechanisms. Update the type if a cache type has been + * provided. + * + * Note, we assume such caches are unified based on conventional system + * design and known examples. Significant work is required elsewhere to + * fully support data/instruction only type caches which are only + * specified in PPTT. */ if (this_leaf->type == CACHE_TYPE_NOCACHE && - valid_flags == PPTT_CHECKED_ATTRIBUTES) + found_cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) this_leaf->type = CACHE_TYPE_UNIFIED; } -- Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v3 2/2] ACPI/PPTT: Handle architecturally unknown cache types 2018-09-28 2:57 ` [PATCH v3 2/2] ACPI/PPTT: Handle architecturally " Jeffrey Hugo @ 2018-09-28 21:52 ` Jeremy Linton 2018-10-02 10:57 ` Sudeep Holla 1 sibling, 0 replies; 9+ messages in thread From: Jeremy Linton @ 2018-09-28 21:52 UTC (permalink / raw) To: Jeffrey Hugo, sudeep.holla, gregkh, rjw, linux-acpi; +Cc: linux-kernel, vkilari Hi, On 09/27/2018 09:57 PM, Jeffrey Hugo wrote: > The type of a cache might not be specified by architectural mechanisms (ie > system registers), but its type might be specified in the PPTT. In this > case, we should populate the type of the cache, rather than leave it > undefined. > > This fixes the issue where the cacheinfo driver will not populate sysfs > for such caches, resulting in the information missing from utilities like > lstopo and lscpu, thus degrading the user experience. The code looks fine to me. Reviewed-by: Jeremy Linton <jeremy.linton@arm.com> Thanks! > > Fixes: 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing) > Reported-by: Vijaya Kumar K <vkilari@codeaurora.org> PS: Although, if you end up re-spinning this, I think its appropriate to add in the commit message that what this is really working around is firmware that has declined to fill out all the fields in the cache description. > Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> > --- > drivers/acpi/pptt.c | 30 +++++++++++++----------------- > 1 file changed, 13 insertions(+), 17 deletions(-) > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index d1e26cb..38ac30e 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > @@ -357,25 +357,15 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > struct acpi_pptt_cache *found_cache, > struct acpi_pptt_processor *cpu_node) > { > - int valid_flags = 0; > - > this_leaf->fw_token = cpu_node; > - if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) { > + if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) > this_leaf->size = found_cache->size; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { > + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) > this_leaf->coherency_line_size = found_cache->line_size; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) { > + if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) > this_leaf->number_of_sets = found_cache->number_of_sets; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) { > + if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) > this_leaf->ways_of_associativity = found_cache->associativity; > - valid_flags++; > - } > if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) { > switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) { > case ACPI_PPTT_CACHE_POLICY_WT: > @@ -402,11 +392,17 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > } > } > /* > - * If the above flags are valid, and the cache type is NOCACHE > - * update the cache type as well. > + * If cache type is NOCACHE, then the cache hasn't been specified > + * via other mechanisms. Update the type if a cache type has been > + * provided. > + * > + * Note, we assume such caches are unified based on conventional system > + * design and known examples. Significant work is required elsewhere to > + * fully support data/instruction only type caches which are only > + * specified in PPTT. > */ > if (this_leaf->type == CACHE_TYPE_NOCACHE && > - valid_flags == PPTT_CHECKED_ATTRIBUTES) > + found_cache->flags & ACPI_PPTT_CACHE_TYPE_VALID) > this_leaf->type = CACHE_TYPE_UNIFIED; > } > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 2/2] ACPI/PPTT: Handle architecturally unknown cache types 2018-09-28 2:57 ` [PATCH v3 2/2] ACPI/PPTT: Handle architecturally " Jeffrey Hugo 2018-09-28 21:52 ` Jeremy Linton @ 2018-10-02 10:57 ` Sudeep Holla 2018-10-02 15:30 ` Jeffrey Hugo 1 sibling, 1 reply; 9+ messages in thread From: Sudeep Holla @ 2018-10-02 10:57 UTC (permalink / raw) To: Jeffrey Hugo Cc: gregkh, rjw, linux-acpi, jeremy.linton, linux-kernel, vkilari, Sudeep Holla On Thu, Sep 27, 2018 at 08:57:57PM -0600, Jeffrey Hugo wrote: > The type of a cache might not be specified by architectural mechanisms (ie > system registers), but its type might be specified in the PPTT. In this > case, we should populate the type of the cache, rather than leave it > undefined. > > This fixes the issue where the cacheinfo driver will not populate sysfs > for such caches, resulting in the information missing from utilities like > lstopo and lscpu, thus degrading the user experience. > > Fixes: 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing) > Reported-by: Vijaya Kumar K <vkilari@codeaurora.org> > Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> > --- > drivers/acpi/pptt.c | 30 +++++++++++++----------------- > 1 file changed, 13 insertions(+), 17 deletions(-) > > diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c > index d1e26cb..38ac30e 100644 > --- a/drivers/acpi/pptt.c > +++ b/drivers/acpi/pptt.c > @@ -357,25 +357,15 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > struct acpi_pptt_cache *found_cache, > struct acpi_pptt_processor *cpu_node) > { > - int valid_flags = 0; > - > this_leaf->fw_token = cpu_node; > - if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) { > + if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) > this_leaf->size = found_cache->size; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { > + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) > this_leaf->coherency_line_size = found_cache->line_size; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) { > + if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) > this_leaf->number_of_sets = found_cache->number_of_sets; > - valid_flags++; > - } > - if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) { > + if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) > this_leaf->ways_of_associativity = found_cache->associativity; > - valid_flags++; > - } > if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) { > switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) { > case ACPI_PPTT_CACHE_POLICY_WT: > @@ -402,11 +392,17 @@ static void update_cache_properties(struct cacheinfo *this_leaf, > } > } > /* > - * If the above flags are valid, and the cache type is NOCACHE > - * update the cache type as well. > + * If cache type is NOCACHE, then the cache hasn't been specified > + * via other mechanisms. Update the type if a cache type has been > + * provided. > + * > + * Note, we assume such caches are unified based on conventional system > + * design and known examples. Significant work is required elsewhere to > + * fully support data/instruction only type caches which are only > + * specified in PPTT. > */ > if (this_leaf->type == CACHE_TYPE_NOCACHE && > - valid_flags == PPTT_CHECKED_ATTRIBUTES) I don't think we use PPTT_CHECKED_ATTRIBUTES elsewhere. If so, can we drop that ? Other than that: Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> -- Regards, Sudeep ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 2/2] ACPI/PPTT: Handle architecturally unknown cache types 2018-10-02 10:57 ` Sudeep Holla @ 2018-10-02 15:30 ` Jeffrey Hugo 0 siblings, 0 replies; 9+ messages in thread From: Jeffrey Hugo @ 2018-10-02 15:30 UTC (permalink / raw) To: Sudeep Holla Cc: gregkh, rjw, linux-acpi, jeremy.linton, linux-kernel, vkilari On 10/2/2018 4:57 AM, Sudeep Holla wrote: > On Thu, Sep 27, 2018 at 08:57:57PM -0600, Jeffrey Hugo wrote: >> The type of a cache might not be specified by architectural mechanisms (ie >> system registers), but its type might be specified in the PPTT. In this >> case, we should populate the type of the cache, rather than leave it >> undefined. >> >> This fixes the issue where the cacheinfo driver will not populate sysfs >> for such caches, resulting in the information missing from utilities like >> lstopo and lscpu, thus degrading the user experience. >> >> Fixes: 2bd00bcd73e5 (ACPI/PPTT: Add Processor Properties Topology Table parsing) >> Reported-by: Vijaya Kumar K <vkilari@codeaurora.org> >> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org> >> --- >> drivers/acpi/pptt.c | 30 +++++++++++++----------------- >> 1 file changed, 13 insertions(+), 17 deletions(-) >> >> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c >> index d1e26cb..38ac30e 100644 >> --- a/drivers/acpi/pptt.c >> +++ b/drivers/acpi/pptt.c >> @@ -357,25 +357,15 @@ static void update_cache_properties(struct cacheinfo *this_leaf, >> struct acpi_pptt_cache *found_cache, >> struct acpi_pptt_processor *cpu_node) >> { >> - int valid_flags = 0; >> - >> this_leaf->fw_token = cpu_node; >> - if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) { >> + if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) >> this_leaf->size = found_cache->size; >> - valid_flags++; >> - } >> - if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) { >> + if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) >> this_leaf->coherency_line_size = found_cache->line_size; >> - valid_flags++; >> - } >> - if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) { >> + if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) >> this_leaf->number_of_sets = found_cache->number_of_sets; >> - valid_flags++; >> - } >> - if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) { >> + if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) >> this_leaf->ways_of_associativity = found_cache->associativity; >> - valid_flags++; >> - } >> if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) { >> switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) { >> case ACPI_PPTT_CACHE_POLICY_WT: >> @@ -402,11 +392,17 @@ static void update_cache_properties(struct cacheinfo *this_leaf, >> } >> } >> /* >> - * If the above flags are valid, and the cache type is NOCACHE >> - * update the cache type as well. >> + * If cache type is NOCACHE, then the cache hasn't been specified >> + * via other mechanisms. Update the type if a cache type has been >> + * provided. >> + * >> + * Note, we assume such caches are unified based on conventional system >> + * design and known examples. Significant work is required elsewhere to >> + * fully support data/instruction only type caches which are only >> + * specified in PPTT. >> */ >> if (this_leaf->type == CACHE_TYPE_NOCACHE && >> - valid_flags == PPTT_CHECKED_ATTRIBUTES) > > I don't think we use PPTT_CHECKED_ATTRIBUTES elsewhere. > If so, can we drop that ? > > Other than that: > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Whoops, you are right. For some reason I thought that came from the standard ACPICA definitions. Let me drop that. -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-10-03 13:47 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-28 2:57 [PATCH v3 0/2] PPTT handle Handle architecturally unknown cache types Jeffrey Hugo 2018-09-28 2:57 ` [PATCH v3 1/2] drivers: base: cacheinfo: Do not populate sysfs for " Jeffrey Hugo 2018-10-02 10:49 ` Sudeep Holla 2018-10-03 9:35 ` Rafael J. Wysocki 2018-10-03 13:47 ` Jeffrey Hugo 2018-09-28 2:57 ` [PATCH v3 2/2] ACPI/PPTT: Handle architecturally " Jeffrey Hugo 2018-09-28 21:52 ` Jeremy Linton 2018-10-02 10:57 ` Sudeep Holla 2018-10-02 15:30 ` Jeffrey Hugo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).