All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"olof@lixom.net" <olof@lixom.net>,
	"gregory.clement@free-electrons.com"
	<gregory.clement@free-electrons.com>, "shawn.guo@linaro.org" <>
Subject: Re: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific arch_of_get_cpu_node
Date: Wed, 17 Jul 2013 15:16:54 +0100	[thread overview]
Message-ID: <51E6A756.1000300@arm.com> (raw)
In-Reply-To: <51E50C59.50900@arm.com>

On 16/07/13 10:03, Sudeep KarkadaNagesha wrote:
> On 15/07/13 20:10, Rob Herring wrote:
>> On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha@arm.com wrote:
>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>>
>>> CPU subsystem now provides architecture specific hook to retrieve the
>>> of_node. Most of the cpu DT node parsing and initialisation is contained
>>> in devtree.c. It's better to contain all CPU device node parsing there.
>>>
>>> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
>>> registered. This patch overrides the defination of the same. It can also
>>> act as the helper function in pre-SMP/early initialisation stages to
>>> retrieve CPU device node pointers in logical ordering.
>>>
>>> This mainly helps to avoid replication of the code doing CPU node parsing
>>> and physical(MPIDR) to logical mapping.
>>>
>>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>
>> [snip]
>>
>>> +struct device_node * __init arch_of_get_cpu_node(int cpu)
>>> +{
>>> +	struct device_node *cpun, *cpus;
>>> +	const u32 *cell;
>>> +	u64 hwid;
>>> +	int ac;
>>> +
>>> +	cpus = of_find_node_by_path("/cpus");
>>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
>>> +		return NULL;
>>> +
>>> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
>>> +		ac = of_n_addr_cells(cpus);
>>> +
>>> +	for_each_child_of_node(cpus, cpun) {
>>> +		if (of_node_cmp(cpun->type, "cpu"))
>>> +			continue;
>>> +		cell = of_get_property(cpun, "reg", NULL);
>>> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
>>> +			continue;
>>> +
>>> +		hwid = of_read_number(cell, ac);
>>> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
>>
>> Most of this function is not ARM specific, so it would be nice if we
>> could shrink the arch specific part down to just this match. A default
>> match of reg == logical cpu number might be useful.
>>
> I completely agree, in fact that was my initial idea too.
> 
> But when I had a look at powerpc implementation of "of_get_cpu_node" in
> arch/powerpc/kernel/prom.c, it looked like PPC is using some
> compatibles(e.g. ibm,ppc-interrupt-server#s) which are not specified in
> ePAPR. I am not sure is that's allowed or not, if allowed then we can't
> have generic of_get_cpu_node with just arch specific hwid matching function.

I meant property names not compatibles. Looks like PPC and SPARC seem to
use non-standard property names like "cpuid",
"ibm,ppc-interrupt-server#s" instead of single "reg" property for all
cpus/threads

Since the cpufreq driver doesn't depend on those properties, I moved
arch_of_get_cpu_node to OF/DT core in v2.

Regards,
Sudeep


WARNING: multiple messages have this Message-ID (diff)
From: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"olof@lixom.net" <olof@lixom.net>,
	"gregory.clement@free-electrons.com"
	<gregory.clement@free-electrons.com>,
	"shawn.guo@linaro.org" <shawn.guo@>
Subject: Re: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific arch_of_get_cpu_node
Date: Wed, 17 Jul 2013 15:16:54 +0100	[thread overview]
Message-ID: <51E6A756.1000300@arm.com> (raw)
In-Reply-To: <51E50C59.50900@arm.com>

On 16/07/13 10:03, Sudeep KarkadaNagesha wrote:
> On 15/07/13 20:10, Rob Herring wrote:
>> On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha@arm.com wrote:
>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>>
>>> CPU subsystem now provides architecture specific hook to retrieve the
>>> of_node. Most of the cpu DT node parsing and initialisation is contained
>>> in devtree.c. It's better to contain all CPU device node parsing there.
>>>
>>> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
>>> registered. This patch overrides the defination of the same. It can also
>>> act as the helper function in pre-SMP/early initialisation stages to
>>> retrieve CPU device node pointers in logical ordering.
>>>
>>> This mainly helps to avoid replication of the code doing CPU node parsing
>>> and physical(MPIDR) to logical mapping.
>>>
>>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>
>> [snip]
>>
>>> +struct device_node * __init arch_of_get_cpu_node(int cpu)
>>> +{
>>> +	struct device_node *cpun, *cpus;
>>> +	const u32 *cell;
>>> +	u64 hwid;
>>> +	int ac;
>>> +
>>> +	cpus = of_find_node_by_path("/cpus");
>>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
>>> +		return NULL;
>>> +
>>> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
>>> +		ac = of_n_addr_cells(cpus);
>>> +
>>> +	for_each_child_of_node(cpus, cpun) {
>>> +		if (of_node_cmp(cpun->type, "cpu"))
>>> +			continue;
>>> +		cell = of_get_property(cpun, "reg", NULL);
>>> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
>>> +			continue;
>>> +
>>> +		hwid = of_read_number(cell, ac);
>>> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
>>
>> Most of this function is not ARM specific, so it would be nice if we
>> could shrink the arch specific part down to just this match. A default
>> match of reg == logical cpu number might be useful.
>>
> I completely agree, in fact that was my initial idea too.
> 
> But when I had a look at powerpc implementation of "of_get_cpu_node" in
> arch/powerpc/kernel/prom.c, it looked like PPC is using some
> compatibles(e.g. ibm,ppc-interrupt-server#s) which are not specified in
> ePAPR. I am not sure is that's allowed or not, if allowed then we can't
> have generic of_get_cpu_node with just arch specific hwid matching function.

I meant property names not compatibles. Looks like PPC and SPARC seem to
use non-standard property names like "cpuid",
"ibm,ppc-interrupt-server#s" instead of single "reg" property for all
cpus/threads

Since the cpufreq driver doesn't depend on those properties, I moved
arch_of_get_cpu_node to OF/DT core in v2.

Regards,
Sudeep


WARNING: multiple messages have this Message-ID (diff)
From: Sudeep.KarkadaNagesha@arm.com (Sudeep KarkadaNagesha)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific arch_of_get_cpu_node
Date: Wed, 17 Jul 2013 15:16:54 +0100	[thread overview]
Message-ID: <51E6A756.1000300@arm.com> (raw)
In-Reply-To: <51E50C59.50900@arm.com>

On 16/07/13 10:03, Sudeep KarkadaNagesha wrote:
> On 15/07/13 20:10, Rob Herring wrote:
>> On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha at arm.com wrote:
>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>>
>>> CPU subsystem now provides architecture specific hook to retrieve the
>>> of_node. Most of the cpu DT node parsing and initialisation is contained
>>> in devtree.c. It's better to contain all CPU device node parsing there.
>>>
>>> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
>>> registered. This patch overrides the defination of the same. It can also
>>> act as the helper function in pre-SMP/early initialisation stages to
>>> retrieve CPU device node pointers in logical ordering.
>>>
>>> This mainly helps to avoid replication of the code doing CPU node parsing
>>> and physical(MPIDR) to logical mapping.
>>>
>>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>
>> [snip]
>>
>>> +struct device_node * __init arch_of_get_cpu_node(int cpu)
>>> +{
>>> +	struct device_node *cpun, *cpus;
>>> +	const u32 *cell;
>>> +	u64 hwid;
>>> +	int ac;
>>> +
>>> +	cpus = of_find_node_by_path("/cpus");
>>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
>>> +		return NULL;
>>> +
>>> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
>>> +		ac = of_n_addr_cells(cpus);
>>> +
>>> +	for_each_child_of_node(cpus, cpun) {
>>> +		if (of_node_cmp(cpun->type, "cpu"))
>>> +			continue;
>>> +		cell = of_get_property(cpun, "reg", NULL);
>>> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
>>> +			continue;
>>> +
>>> +		hwid = of_read_number(cell, ac);
>>> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
>>
>> Most of this function is not ARM specific, so it would be nice if we
>> could shrink the arch specific part down to just this match. A default
>> match of reg == logical cpu number might be useful.
>>
> I completely agree, in fact that was my initial idea too.
> 
> But when I had a look at powerpc implementation of "of_get_cpu_node" in
> arch/powerpc/kernel/prom.c, it looked like PPC is using some
> compatibles(e.g. ibm,ppc-interrupt-server#s) which are not specified in
> ePAPR. I am not sure is that's allowed or not, if allowed then we can't
> have generic of_get_cpu_node with just arch specific hwid matching function.

I meant property names not compatibles. Looks like PPC and SPARC seem to
use non-standard property names like "cpuid",
"ibm,ppc-interrupt-server#s" instead of single "reg" property for all
cpus/threads

Since the cpufreq driver doesn't depend on those properties, I moved
arch_of_get_cpu_node to OF/DT core in v2.

Regards,
Sudeep

WARNING: multiple messages have this Message-ID (diff)
From: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>
To: Rob Herring <robherring2@gmail.com>
Cc: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	"rjw@sisk.pl" <rjw@sisk.pl>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"cpufreq@vger.kernel.org" <cpufreq@vger.kernel.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"olof@lixom.net" <olof@lixom.net>,
	"gregory.clement@free-electrons.com" 
	<gregory.clement@free-electrons.com>,
	"shawn.guo@linaro.org" <shawn.guo@linaro.org>
Subject: Re: [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific arch_of_get_cpu_node
Date: Wed, 17 Jul 2013 15:16:54 +0100	[thread overview]
Message-ID: <51E6A756.1000300@arm.com> (raw)
In-Reply-To: <51E50C59.50900@arm.com>

On 16/07/13 10:03, Sudeep KarkadaNagesha wrote:
> On 15/07/13 20:10, Rob Herring wrote:
>> On 07/15/2013 05:22 AM, Sudeep.KarkadaNagesha@arm.com wrote:
>>> From: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>>
>>> CPU subsystem now provides architecture specific hook to retrieve the
>>> of_node. Most of the cpu DT node parsing and initialisation is contained
>>> in devtree.c. It's better to contain all CPU device node parsing there.
>>>
>>> arch_of_get_cpu_node is mainly used to assign cpu->of_node when CPUs get
>>> registered. This patch overrides the defination of the same. It can also
>>> act as the helper function in pre-SMP/early initialisation stages to
>>> retrieve CPU device node pointers in logical ordering.
>>>
>>> This mainly helps to avoid replication of the code doing CPU node parsing
>>> and physical(MPIDR) to logical mapping.
>>>
>>> Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com>
>>
>> [snip]
>>
>>> +struct device_node * __init arch_of_get_cpu_node(int cpu)
>>> +{
>>> +	struct device_node *cpun, *cpus;
>>> +	const u32 *cell;
>>> +	u64 hwid;
>>> +	int ac;
>>> +
>>> +	cpus = of_find_node_by_path("/cpus");
>>> +	if (WARN(!cpus, "Missing cpus node, bailing out\n"))
>>> +		return NULL;
>>> +
>>> +	if (WARN_ON(of_property_read_u32(cpus, "#address-cells", &ac)))
>>> +		ac = of_n_addr_cells(cpus);
>>> +
>>> +	for_each_child_of_node(cpus, cpun) {
>>> +		if (of_node_cmp(cpun->type, "cpu"))
>>> +			continue;
>>> +		cell = of_get_property(cpun, "reg", NULL);
>>> +		if (WARN(!cell, "%s: missing reg property\n", cpun->full_name))
>>> +			continue;
>>> +
>>> +		hwid = of_read_number(cell, ac);
>>> +		if ((hwid & MPIDR_HWID_BITMASK) == cpu_logical_map(cpu))
>>
>> Most of this function is not ARM specific, so it would be nice if we
>> could shrink the arch specific part down to just this match. A default
>> match of reg == logical cpu number might be useful.
>>
> I completely agree, in fact that was my initial idea too.
> 
> But when I had a look at powerpc implementation of "of_get_cpu_node" in
> arch/powerpc/kernel/prom.c, it looked like PPC is using some
> compatibles(e.g. ibm,ppc-interrupt-server#s) which are not specified in
> ePAPR. I am not sure is that's allowed or not, if allowed then we can't
> have generic of_get_cpu_node with just arch specific hwid matching function.

I meant property names not compatibles. Looks like PPC and SPARC seem to
use non-standard property names like "cpuid",
"ibm,ppc-interrupt-server#s" instead of single "reg" property for all
cpus/threads

Since the cpufreq driver doesn't depend on those properties, I moved
arch_of_get_cpu_node to OF/DT core in v2.

Regards,
Sudeep


  reply	other threads:[~2013-07-17 14:16 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-15 10:22 [RFC PATCH 00/11] ARM: DT: update cpu device of_node Sudeep.KarkadaNagesha
2013-07-15 10:22 ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 01/11] driver/core: cpu: initialize of_node in cpu's device struture Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-16  6:27   ` Viresh Kumar
2013-07-16  6:27     ` Viresh Kumar
2013-07-15 10:22 ` [RFC PATCH 02/11] ARM: DT/kernel: define ARM specific arch_of_get_cpu_node Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 19:10   ` Rob Herring
2013-07-15 19:10     ` Rob Herring
2013-07-16  6:29     ` Viresh Kumar
2013-07-16  6:29       ` Viresh Kumar
2013-07-16  9:03     ` Sudeep KarkadaNagesha
2013-07-16  9:03       ` Sudeep KarkadaNagesha
2013-07-16  9:03       ` Sudeep KarkadaNagesha
2013-07-16  9:03       ` Sudeep KarkadaNagesha
2013-07-17 14:16       ` Sudeep KarkadaNagesha [this message]
2013-07-17 14:16         ` Sudeep KarkadaNagesha
2013-07-17 14:16         ` Sudeep KarkadaNagesha
2013-07-17 14:16         ` Sudeep KarkadaNagesha
2013-07-15 10:22 ` [RFC PATCH 03/11] ARM: topology: remove hwid/MPIDR dependency from cpu_capacity Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 04/11] ARM: mvebu: remove device tree parsing for cpu nodes Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 05/11] drivers/bus: arm-cci: avoid parsing DT for cpu device nodes Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 06/11] cpufreq: imx6q-cpufreq: remove device tree parsing for cpu nodes Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-16  1:22   ` Shawn Guo
2013-07-16  1:22     ` Shawn Guo
2013-07-16  1:22     ` Shawn Guo
2013-07-15 10:22 ` [RFC PATCH 07/11] cpufreq: cpufreq-cpu0: " Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-16  1:26   ` Shawn Guo
2013-07-16  1:26     ` Shawn Guo
2013-07-16  1:26     ` Shawn Guo
2013-07-15 10:22 ` [RFC PATCH 08/11] cpufreq: highbank-cpufreq: " Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 09/11] cpufreq: spear-cpufreq: " Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 10/11] cpufreq: kirkwood-cpufreq: " Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-15 10:22 ` [RFC PATCH 11/11] cpufreq: arm_big_little: " Sudeep.KarkadaNagesha
2013-07-15 10:22   ` Sudeep.KarkadaNagesha at arm.com
2013-07-16  6:31 ` [RFC PATCH 00/11] ARM: DT: update cpu device of_node Viresh Kumar
2013-07-16  6:31   ` Viresh Kumar

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=51E6A756.1000300@arm.com \
    --to=sudeep.karkadanagesha@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=arnd@arndb.de \
    --cc=cpufreq@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=gregory.clement@free-electrons.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=olof@lixom.net \
    --cc=rjw@sisk.pl \
    --cc=rob.herring@calxeda.com \
    --cc=robherring2@gmail.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.