linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	sudeep.holla@arm.com, hanjun.guo@linaro.org, rjw@rjwysocki.net,
	will.deacon@arm.com, catalin.marinas@arm.com,
	gregkh@linuxfoundation.org, viresh.kumar@linaro.org,
	mark.rutland@arm.com, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, jhugo@codeaurora.org,
	wangxiongfeng2@huawei.com, Jonathan.Zhang@cavium.com,
	ahs3@redhat.com, Jayachandran.Nair@cavium.com,
	austinwc@codeaurora.org
Subject: Re: [PATCH v3 3/7] drivers: base: cacheinfo: arm64: Add support for ACPI based firmware tables
Date: Thu, 19 Oct 2017 10:52:32 -0500	[thread overview]
Message-ID: <0d4872d9-580b-091d-82cf-671f40cea02a@arm.com> (raw)
In-Reply-To: <20171019152012.GB18883@red-moon>

Hi,


On 10/19/2017 10:20 AM, Lorenzo Pieralisi wrote:
> On Thu, Oct 12, 2017 at 02:48:52PM -0500, Jeremy Linton wrote:
>> The /sys cache entries should support ACPI/PPTT generated cache
>> topology information. Lets detect ACPI systems and call
>> an arch specific cache_setup_acpi() routine to update the hardware
>> probed cache topology.
>>
>> For arm64, if ACPI is enabled, determine the max number of cache
>> levels and populate them using a PPTT table if one is available.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>>   arch/arm64/kernel/cacheinfo.c | 23 ++++++++++++++++++-----
>>   drivers/acpi/pptt.c           |  1 +
>>   drivers/base/cacheinfo.c      | 17 +++++++++++------
>>   include/linux/cacheinfo.h     | 11 +++++++++--
>>   4 files changed, 39 insertions(+), 13 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
>> index 380f2e2fbed5..2e2cf0d312ba 100644
>> --- a/arch/arm64/kernel/cacheinfo.c
>> +++ b/arch/arm64/kernel/cacheinfo.c
>> @@ -17,6 +17,7 @@
>>    * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>    */
>>   
>> +#include <linux/acpi.h>
>>   #include <linux/cacheinfo.h>
>>   #include <linux/of.h>
>>   
>> @@ -44,9 +45,17 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
>>   	this_leaf->type = type;
>>   }
>>   
>> +#ifndef CONFIG_ACPI
>> +int acpi_find_last_cache_level(unsigned int cpu)
>> +{
>> +	/*ACPI kernels should be built with PPTT support*/
>> +	return 0;
>> +}
>> +#endif
>> +
>>   static int __init_cache_level(unsigned int cpu)
>>   {
>> -	unsigned int ctype, level, leaves, of_level;
>> +	unsigned int ctype, level, leaves, fw_level;
>>   	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>>   
>>   	for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
>> @@ -59,15 +68,19 @@ static int __init_cache_level(unsigned int cpu)
>>   		leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
>>   	}
>>   
>> -	of_level = of_find_last_cache_level(cpu);
>> -	if (level < of_level) {
>> +	if (acpi_disabled)
>> +		fw_level = of_find_last_cache_level(cpu);
>> +	else
>> +		fw_level = acpi_find_last_cache_level(cpu);
>> +
>> +	if (level < fw_level) {
>>   		/*
>>   		 * some external caches not specified in CLIDR_EL1
>>   		 * the information may be available in the device tree
>>   		 * only unified external caches are considered here
>>   		 */
>> -		leaves += (of_level - level);
>> -		level = of_level;
>> +		leaves += (fw_level - level);
>> +		level = fw_level;
>>   	}
>>   
>>   	this_cpu_ci->num_levels = level;
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> index c86715fed4a7..b5c6de37e328 100644
>> --- a/drivers/acpi/pptt.c
>> +++ b/drivers/acpi/pptt.c
>> @@ -355,6 +355,7 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
>>   				    struct acpi_pptt_cache *found_cache,
>>   				    struct acpi_pptt_processor *cpu_node)
>>   {
>> +	this_leaf->firmware_node = cpu_node;
> 
> This pointer comes from an ACPI static table mapping that happens
> to be permanent so it should be safe given that the mapping is carried
> out at device_initcall (ie cache_setup_acpi()) but it is not that
> obvious. More to it below.
> 
>>   	if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID)
>>   		this_leaf->size = found_cache->size;
>>   	if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID)
>> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
>> index eb3af2739537..8eca279e50d1 100644
>> --- a/drivers/base/cacheinfo.c
>> +++ b/drivers/base/cacheinfo.c
>> @@ -86,7 +86,7 @@ static int cache_setup_of_node(unsigned int cpu)
>>   static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>   					   struct cacheinfo *sib_leaf)
>>   {
>> -	return sib_leaf->of_node == this_leaf->of_node;
>> +	return sib_leaf->firmware_node == this_leaf->firmware_node;
>>   }
>>   
>>   /* OF properties to query for a given cache type */
>> @@ -215,6 +215,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
>>   }
>>   #endif
>>   
>> +int __weak cache_setup_acpi(unsigned int cpu)
>> +{
>> +	return -ENOTSUPP;
>> +}
>> +
>>   static int cache_shared_cpu_map_setup(unsigned int cpu)
>>   {
>>   	struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
>> @@ -225,11 +230,11 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
>>   	if (this_cpu_ci->cpu_map_populated)
>>   		return 0;
>>   
>> -	if (of_have_populated_dt())
>> +	if (!acpi_disabled)
>> +		ret = cache_setup_acpi(cpu);
>> +	else if (of_have_populated_dt())
>>   		ret = cache_setup_of_node(cpu);
>> -	else if (!acpi_disabled)
>> -		/* No cache property/hierarchy support yet in ACPI */
>> -		ret = -ENOTSUPP;
>> +
>>   	if (ret)
>>   		return ret;
>>   
>> @@ -286,7 +291,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
>>   
>>   static void cache_override_properties(unsigned int cpu)
>>   {
>> -	if (of_have_populated_dt())
>> +	if (acpi_disabled && of_have_populated_dt())
>>   		return cache_of_override_properties(cpu);
>>   }
>>   
>> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
>> index 6a524bf6a06d..d1e9b8e01981 100644
>> --- a/include/linux/cacheinfo.h
>> +++ b/include/linux/cacheinfo.h
>> @@ -36,6 +36,9 @@ enum cache_type {
>>    * @of_node: if devicetree is used, this represents either the cpu node in
>>    *	case there's no explicit cache node or the cache node itself in the
>>    *	device tree
>> + * @firmware_node: Shared with of_node. When not using DT, this may contain
>> + *	pointers to other firmware based values. Particularly ACPI/PPTT
>> + *	unique values.
>>    * @disable_sysfs: indicates whether this node is visible to the user via
>>    *	sysfs or not
>>    * @priv: pointer to any private data structure specific to particular
>> @@ -64,8 +67,10 @@ struct cacheinfo {
>>   #define CACHE_ALLOCATE_POLICY_MASK	\
>>   	(CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
>>   #define CACHE_ID		BIT(4)
>> -
>> -	struct device_node *of_node;
>> +	union {
>> +		struct device_node *of_node;
>> +		void *firmware_node;
>> +	};
> 
> How about turning of_node into a struct fwnode_handle* (and allocate
> one for each PPTT cache node - acpi_static_fwnode - to have the
> ACPI counterpart) ?

As pointed out internally (with a patch), I converted this whole module 
into fwnode, but the ACPI side is still a mess because it doesn't map 
cleanly to what ends up being an relative acpi pointer, mostly because 
fwnode is really designed more for parsing DT and the ACPI DSDT/etc. So 
you end up with fwnode routines that simply don't have mappings to PPTT, 
with IMHO is going to just create far more confusion than any assumed 
cleanliness that might result.

> 
> It will make more churn given that that pointer is just used to
> carry out a pointer comparison but it's also a bit more elegant.

Except for the huge api surface that takes a fwnode which won't work.

> 
> Lorenzo
> 
>>   	bool disable_sysfs;
>>   	void *priv;
>>   };
>> @@ -98,6 +103,8 @@ int func(unsigned int cpu)					\
>>   struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
>>   int init_cache_level(unsigned int cpu);
>>   int populate_cache_leaves(unsigned int cpu);
>> +int cache_setup_acpi(unsigned int cpu);
>> +int acpi_find_last_cache_level(unsigned int cpu);
>>   
>>   const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
>>   
>> -- 
>> 2.13.5
>>

  reply	other threads:[~2017-10-19 15:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-12 19:48 [PATCH v3 0/7] Support PPTT for ARM64 Jeremy Linton
2017-10-12 19:48 ` [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing Jeremy Linton
2017-10-13  9:56   ` Julien Thierry
2017-10-13 22:41     ` Jeremy Linton
2017-10-13 14:23   ` tn
2017-10-13 19:58     ` Jeremy Linton
2017-10-16 14:24   ` John Garry
2017-10-17 13:25   ` Tomasz Nowicki
2017-10-17 15:22     ` Jeremy Linton
2017-10-18  1:10       ` Xiongfeng Wang
2017-10-18  5:39       ` Tomasz Nowicki
2017-10-18 10:24         ` Tomasz Nowicki
2017-10-18 17:30           ` Jeremy Linton
2017-10-19  5:18             ` Tomasz Nowicki
2017-10-19 10:25               ` John Garry
2017-10-27  5:21                 ` Tomasz Nowicki
2017-10-19 14:24               ` Jeremy Linton
2017-10-19 10:22   ` Lorenzo Pieralisi
2017-10-19 15:43     ` Jeremy Linton
2017-10-20 10:15       ` Lorenzo Pieralisi
2017-10-20 19:53   ` Christ, Austin
2017-10-23 21:14     ` Jeremy Linton
2017-10-12 19:48 ` [PATCH v3 2/7] ACPI: Enable PPTT support on ARM64 Jeremy Linton
2017-10-13  9:53   ` Hanjun Guo
2017-10-13 17:51     ` Jeremy Linton
2017-10-18 16:47   ` Lorenzo Pieralisi
2017-10-18 17:38     ` Jeremy Linton
2017-10-19  9:12       ` Lorenzo Pieralisi
2017-10-12 19:48 ` [PATCH v3 3/7] drivers: base: cacheinfo: arm64: Add support for ACPI based firmware tables Jeremy Linton
2017-10-19 15:20   ` Lorenzo Pieralisi
2017-10-19 15:52     ` Jeremy Linton [this message]
2017-10-12 19:48 ` [PATCH v3 4/7] Topology: Add cluster on die macros and arm64 decoding Jeremy Linton
2017-10-12 19:48 ` [PATCH v3 5/7] arm64: Fixup users of topology_physical_package_id Jeremy Linton
2017-10-12 19:48 ` [PATCH v3 6/7] arm64: topology: Enable ACPI/PPTT based CPU topology Jeremy Linton
2017-10-19 15:56   ` Lorenzo Pieralisi
2017-10-19 16:13     ` Jeremy Linton
2017-10-20  9:14       ` Lorenzo Pieralisi
2017-10-20 16:14         ` Jeremy Linton
2017-10-20 16:42           ` Sudeep Holla
2017-10-20 19:55           ` Jeffrey Hugo
2017-10-23 21:26             ` Jeremy Linton
2017-10-19 16:54     ` Jeremy Linton
2017-10-20  9:22       ` Lorenzo Pieralisi
2017-11-01 20:29         ` Al Stone
2017-11-02 10:48           ` Lorenzo Pieralisi
2017-10-12 19:48 ` [PATCH v3 7/7] ACPI: Add PPTT to injectable table list Jeremy Linton
2017-10-13 11:08 ` [PATCH v3 0/7] Support PPTT for ARM64 John Garry
2017-10-13 19:34   ` Jeremy Linton
2017-10-31 12:46 ` Jon Masters

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d4872d9-580b-091d-82cf-671f40cea02a@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=Jayachandran.Nair@cavium.com \
    --cc=Jonathan.Zhang@cavium.com \
    --cc=ahs3@redhat.com \
    --cc=austinwc@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanjun.guo@linaro.org \
    --cc=jhugo@codeaurora.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=viresh.kumar@linaro.org \
    --cc=wangxiongfeng2@huawei.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).