All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Olof Johansson <olof@lixom.net>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [GIT PULL] DT/core: cpu_ofnode updates for v3.12
Date: Wed, 14 Aug 2013 07:53:02 -0500	[thread overview]
Message-ID: <520B7DAE.3060501@gmail.com> (raw)
In-Reply-To: <520B5584.7030608@arm.com>

On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote:
> On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
>> On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
>>> I don't understand completely the use of ibm,ppc-interrupt-server#s and
>>> its implications on generic of_get_cpu_node implementation.
>>> I see the PPC specific definition of of_get_cpu_node uses thread id only
>>> in 2 instances. Based on that, I have tried to move all the other
>>> instances to use generic definition.
>>>
>>> Let me know if the idea is correct.
>>
>> No. The device-tree historically only represents cores, not HW threads, so
>> it makes sense to retrieve also the thread number corresponding to the CPU.
>>
> Ok
> 
>> However, the mechanism to represent HW threads in the device-tree is currently
>> somewhat platform specific (the ibm,ppc-interrupt-server#s).
> I see most of the callers pass NULL to thread id argument except 2
> instances in entire tree. If that's the case why can't we move to use
> generic of_get_cpu_node in most of those cases and have PPC specific
> implementation for the ones using thread id.
> 
>>
>> So what you could do for now is:
>>
>>  - Have a generic version that always returns 0 as the thread, which is weak
> I would prefer to move to generic of_get_cpu_node where ever possible
> and rename the function that takes thread id rather than making generic
> one weak.
> 
>>
>>  - powerpc keeps its own implementation
> How about only in cases where it needs thread_id.
> 
>>
>>  - Start a discussion on the bindings (if not already there) to define threads
>> in a better way at which point the generic function can be updated.
>>
> I am not sure if we need to define any new bindings. Excerpts from ePAPR
> (v1.1):
> "3.7.1 General Properties of CPU nodes
> The value of "reg" is a <prop-encoded-array> that defines a unique
> CPU/thread id for the CPU/threads represented by the CPU node.
> If a CPU supports more than one thread (i.e. multiple streams of
> execution) the reg property is an array with 1 element per thread. The
> #address-cells on the /cpus node specifies how many cells each element
> of the array takes. Software can determine the number of threads by
> dividing the size of reg by the parent node's #address-cells."
> 
> And this is exactly in agreement to what's implemented in the generic
> of_get_cpu_node:
> 
> for_each_child_of_node(cpus, cpun) {
>         if (of_node_cmp(cpun->type, "cpu"))
>                 continue;
>         cell = of_get_property(cpun, "reg", &prop_len);
>         if (!cell) {
>                 pr_warn("%s: missing reg property\n", cpun->full_name);
>                 continue;
>         }
>         prop_len /= sizeof(*cell);
>         while (prop_len) {
>                 hwid = of_read_number(cell, ac);
>                 prop_len -= ac;
>                 if (arch_match_cpu_phys_id(cpu, hwid))
>                         return cpun;
>         }
> }

How about something like this:

for_each_child_of_node(cpus, cpun) {
        if (of_node_cmp(cpun->type, "cpu"))
                continue;

	if (arch_of_get_cpu_node(cpun, thread))
		return cpun;

        cell = of_get_property(cpun, "reg", &prop_len);
        if (!cell) {
                pr_warn("%s: missing reg property\n", cpun->full_name);
                continue;
        }
        prop_len /= sizeof(*cell);
        while (prop_len) {
                hwid = of_read_number(cell, ac);
                prop_len -= ac;
                if (arch_match_cpu_phys_id(cpu, hwid))
       	                return cpun;
        }
}

For PPC:

arch_of_get_cpu_node()
{
        const u32 *intserv;
        unsigned int plen, t;

        /* Check for ibm,ppc-interrupt-server#s. */
        intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
                                &plen);
        if (!intserv)
		return false;

	hardid = get_hard_smp_processor_id(cpu);

        plen /= sizeof(u32);
        for (t = 0; t < plen; t++) {
                 if (hardid == intserv[t]) {
                         if (thread)
                                  *thread = t;
                         return true;
                 }
        }
	return false;
}

> 
> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for
> which we can have PPC specific wrapper above the generic one i.e. get
> the cpu node and then parse for thread id under custom property.
> 
> Let me know your thoughts.
> 
> Regards,
> Sudeep
> 
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2@gmail.com>
To: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Olof Johansson <olof@lixom.net>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [GIT PULL] DT/core: cpu_ofnode updates for v3.12
Date: Wed, 14 Aug 2013 07:53:02 -0500	[thread overview]
Message-ID: <520B7DAE.3060501@gmail.com> (raw)
In-Reply-To: <520B5584.7030608@arm.com>

On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote:
> On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
>> On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
>>> I don't understand completely the use of ibm,ppc-interrupt-server#s and
>>> its implications on generic of_get_cpu_node implementation.
>>> I see the PPC specific definition of of_get_cpu_node uses thread id only
>>> in 2 instances. Based on that, I have tried to move all the other
>>> instances to use generic definition.
>>>
>>> Let me know if the idea is correct.
>>
>> No. The device-tree historically only represents cores, not HW threads, so
>> it makes sense to retrieve also the thread number corresponding to the CPU.
>>
> Ok
> 
>> However, the mechanism to represent HW threads in the device-tree is currently
>> somewhat platform specific (the ibm,ppc-interrupt-server#s).
> I see most of the callers pass NULL to thread id argument except 2
> instances in entire tree. If that's the case why can't we move to use
> generic of_get_cpu_node in most of those cases and have PPC specific
> implementation for the ones using thread id.
> 
>>
>> So what you could do for now is:
>>
>>  - Have a generic version that always returns 0 as the thread, which is weak
> I would prefer to move to generic of_get_cpu_node where ever possible
> and rename the function that takes thread id rather than making generic
> one weak.
> 
>>
>>  - powerpc keeps its own implementation
> How about only in cases where it needs thread_id.
> 
>>
>>  - Start a discussion on the bindings (if not already there) to define threads
>> in a better way at which point the generic function can be updated.
>>
> I am not sure if we need to define any new bindings. Excerpts from ePAPR
> (v1.1):
> "3.7.1 General Properties of CPU nodes
> The value of "reg" is a <prop-encoded-array> that defines a unique
> CPU/thread id for the CPU/threads represented by the CPU node.
> If a CPU supports more than one thread (i.e. multiple streams of
> execution) the reg property is an array with 1 element per thread. The
> #address-cells on the /cpus node specifies how many cells each element
> of the array takes. Software can determine the number of threads by
> dividing the size of reg by the parent node's #address-cells."
> 
> And this is exactly in agreement to what's implemented in the generic
> of_get_cpu_node:
> 
> for_each_child_of_node(cpus, cpun) {
>         if (of_node_cmp(cpun->type, "cpu"))
>                 continue;
>         cell = of_get_property(cpun, "reg", &prop_len);
>         if (!cell) {
>                 pr_warn("%s: missing reg property\n", cpun->full_name);
>                 continue;
>         }
>         prop_len /= sizeof(*cell);
>         while (prop_len) {
>                 hwid = of_read_number(cell, ac);
>                 prop_len -= ac;
>                 if (arch_match_cpu_phys_id(cpu, hwid))
>                         return cpun;
>         }
> }

How about something like this:

for_each_child_of_node(cpus, cpun) {
        if (of_node_cmp(cpun->type, "cpu"))
                continue;

	if (arch_of_get_cpu_node(cpun, thread))
		return cpun;

        cell = of_get_property(cpun, "reg", &prop_len);
        if (!cell) {
                pr_warn("%s: missing reg property\n", cpun->full_name);
                continue;
        }
        prop_len /= sizeof(*cell);
        while (prop_len) {
                hwid = of_read_number(cell, ac);
                prop_len -= ac;
                if (arch_match_cpu_phys_id(cpu, hwid))
       	                return cpun;
        }
}

For PPC:

arch_of_get_cpu_node()
{
        const u32 *intserv;
        unsigned int plen, t;

        /* Check for ibm,ppc-interrupt-server#s. */
        intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
                                &plen);
        if (!intserv)
		return false;

	hardid = get_hard_smp_processor_id(cpu);

        plen /= sizeof(u32);
        for (t = 0; t < plen; t++) {
                 if (hardid == intserv[t]) {
                         if (thread)
                                  *thread = t;
                         return true;
                 }
        }
	return false;
}

> 
> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for
> which we can have PPC specific wrapper above the generic one i.e. get
> the cpu node and then parse for thread id under custom property.
> 
> Let me know your thoughts.
> 
> Regards,
> Sudeep
> 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] DT/core: cpu_ofnode updates for v3.12
Date: Wed, 14 Aug 2013 07:53:02 -0500	[thread overview]
Message-ID: <520B7DAE.3060501@gmail.com> (raw)
In-Reply-To: <520B5584.7030608@arm.com>

On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote:
> On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
>> On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
>>> I don't understand completely the use of ibm,ppc-interrupt-server#s and
>>> its implications on generic of_get_cpu_node implementation.
>>> I see the PPC specific definition of of_get_cpu_node uses thread id only
>>> in 2 instances. Based on that, I have tried to move all the other
>>> instances to use generic definition.
>>>
>>> Let me know if the idea is correct.
>>
>> No. The device-tree historically only represents cores, not HW threads, so
>> it makes sense to retrieve also the thread number corresponding to the CPU.
>>
> Ok
> 
>> However, the mechanism to represent HW threads in the device-tree is currently
>> somewhat platform specific (the ibm,ppc-interrupt-server#s).
> I see most of the callers pass NULL to thread id argument except 2
> instances in entire tree. If that's the case why can't we move to use
> generic of_get_cpu_node in most of those cases and have PPC specific
> implementation for the ones using thread id.
> 
>>
>> So what you could do for now is:
>>
>>  - Have a generic version that always returns 0 as the thread, which is weak
> I would prefer to move to generic of_get_cpu_node where ever possible
> and rename the function that takes thread id rather than making generic
> one weak.
> 
>>
>>  - powerpc keeps its own implementation
> How about only in cases where it needs thread_id.
> 
>>
>>  - Start a discussion on the bindings (if not already there) to define threads
>> in a better way at which point the generic function can be updated.
>>
> I am not sure if we need to define any new bindings. Excerpts from ePAPR
> (v1.1):
> "3.7.1 General Properties of CPU nodes
> The value of "reg" is a <prop-encoded-array> that defines a unique
> CPU/thread id for the CPU/threads represented by the CPU node.
> If a CPU supports more than one thread (i.e. multiple streams of
> execution) the reg property is an array with 1 element per thread. The
> #address-cells on the /cpus node specifies how many cells each element
> of the array takes. Software can determine the number of threads by
> dividing the size of reg by the parent node's #address-cells."
> 
> And this is exactly in agreement to what's implemented in the generic
> of_get_cpu_node:
> 
> for_each_child_of_node(cpus, cpun) {
>         if (of_node_cmp(cpun->type, "cpu"))
>                 continue;
>         cell = of_get_property(cpun, "reg", &prop_len);
>         if (!cell) {
>                 pr_warn("%s: missing reg property\n", cpun->full_name);
>                 continue;
>         }
>         prop_len /= sizeof(*cell);
>         while (prop_len) {
>                 hwid = of_read_number(cell, ac);
>                 prop_len -= ac;
>                 if (arch_match_cpu_phys_id(cpu, hwid))
>                         return cpun;
>         }
> }

How about something like this:

for_each_child_of_node(cpus, cpun) {
        if (of_node_cmp(cpun->type, "cpu"))
                continue;

	if (arch_of_get_cpu_node(cpun, thread))
		return cpun;

        cell = of_get_property(cpun, "reg", &prop_len);
        if (!cell) {
                pr_warn("%s: missing reg property\n", cpun->full_name);
                continue;
        }
        prop_len /= sizeof(*cell);
        while (prop_len) {
                hwid = of_read_number(cell, ac);
                prop_len -= ac;
                if (arch_match_cpu_phys_id(cpu, hwid))
       	                return cpun;
        }
}

For PPC:

arch_of_get_cpu_node()
{
        const u32 *intserv;
        unsigned int plen, t;

        /* Check for ibm,ppc-interrupt-server#s. */
        intserv = of_get_property(np, "ibm,ppc-interrupt-server#s",
                                &plen);
        if (!intserv)
		return false;

	hardid = get_hard_smp_processor_id(cpu);

        plen /= sizeof(u32);
        for (t = 0; t < plen; t++) {
                 if (hardid == intserv[t]) {
                         if (thread)
                                  *thread = t;
                         return true;
                 }
        }
	return false;
}

> 
> Yes this doesn't cover the historical "ibm,ppc-interrupt-server#s", for
> which we can have PPC specific wrapper above the generic one i.e. get
> the cpu node and then parse for thread id under custom property.
> 
> Let me know your thoughts.
> 
> Regards,
> Sudeep
> 
> 
> 

  parent reply	other threads:[~2013-08-14 12:53 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12 13:27 [GIT PULL] DT/core: cpu_ofnode updates for v3.12 Sudeep KarkadaNagesha
2013-08-12 13:27 ` Sudeep KarkadaNagesha
2013-08-12 13:27 ` Sudeep KarkadaNagesha
2013-08-13 13:00 ` Rafael J. Wysocki
2013-08-13 13:00   ` Rafael J. Wysocki
2013-08-13 13:00   ` Rafael J. Wysocki
2013-08-13 15:40   ` Sudeep KarkadaNagesha
2013-08-13 15:40     ` Sudeep KarkadaNagesha
2013-08-13 15:40     ` Sudeep KarkadaNagesha
2013-08-13 15:40     ` Sudeep KarkadaNagesha
2013-08-13 18:29     ` Sudeep KarkadaNagesha
2013-08-13 18:29       ` Sudeep KarkadaNagesha
2013-08-13 18:29       ` Sudeep KarkadaNagesha
2013-08-13 18:29       ` Sudeep KarkadaNagesha
2013-08-13 21:07       ` Benjamin Herrenschmidt
2013-08-13 21:07         ` Benjamin Herrenschmidt
2013-08-13 21:07         ` Benjamin Herrenschmidt
2013-08-14 10:01         ` Sudeep KarkadaNagesha
2013-08-14 10:01           ` Sudeep KarkadaNagesha
2013-08-14 10:01           ` Sudeep KarkadaNagesha
2013-08-14 10:01           ` Sudeep KarkadaNagesha
2013-08-14 11:37           ` Benjamin Herrenschmidt
2013-08-14 11:37             ` Benjamin Herrenschmidt
2013-08-14 11:37             ` Benjamin Herrenschmidt
2013-08-14 13:21             ` Sudeep KarkadaNagesha
2013-08-14 13:21               ` Sudeep KarkadaNagesha
2013-08-14 13:21               ` Sudeep KarkadaNagesha
2013-08-14 13:21               ` Sudeep KarkadaNagesha
2013-08-14 22:57               ` Benjamin Herrenschmidt
2013-08-14 22:57                 ` Benjamin Herrenschmidt
2013-08-14 22:57                 ` Benjamin Herrenschmidt
2013-08-14 12:53           ` Rob Herring [this message]
2013-08-14 12:53             ` Rob Herring
2013-08-14 12:53             ` Rob Herring
2013-08-14 12:53             ` Rob Herring
2013-08-14 13:27             ` Sudeep KarkadaNagesha
2013-08-14 13:27               ` Sudeep KarkadaNagesha
2013-08-14 13:27               ` Sudeep KarkadaNagesha
2013-08-14 13:27               ` Sudeep KarkadaNagesha
2013-08-13 18:37     ` Michal Simek
2013-08-13 18:37       ` Michal Simek
2013-08-13 18:37       ` Michal Simek
2013-08-13 18:37       ` Michal Simek
2013-08-14  8:41       ` Sudeep KarkadaNagesha
2013-08-14  8:41         ` Sudeep KarkadaNagesha
2013-08-14  8:41         ` Sudeep KarkadaNagesha
2013-08-14  8:41         ` Sudeep KarkadaNagesha
2013-08-13 18:44     ` Rob Herring
2013-08-13 18:44       ` Rob Herring
2013-08-13 18:44       ` Rob Herring
2013-08-13 18:44       ` Rob Herring
2013-08-13 19:45       ` Rafael J. Wysocki
2013-08-13 19:45         ` Rafael J. Wysocki
2013-08-13 19:45         ` Rafael J. Wysocki
2013-08-13 19:45         ` Rafael J. Wysocki
2013-08-13 21:09         ` Benjamin Herrenschmidt
2013-08-13 21:09           ` Benjamin Herrenschmidt
2013-08-13 21:09           ` Benjamin Herrenschmidt
2013-08-13 21:09           ` Benjamin Herrenschmidt
2013-08-14  9:23         ` Sudeep KarkadaNagesha
2013-08-14  9:23           ` Sudeep KarkadaNagesha
2013-08-14  9:23           ` Sudeep KarkadaNagesha
2013-08-14  9:23           ` Sudeep KarkadaNagesha
2013-08-13 21:08       ` Benjamin Herrenschmidt
2013-08-13 21:08         ` Benjamin Herrenschmidt
2013-08-13 21:08         ` Benjamin Herrenschmidt
2013-08-13 21:03     ` Benjamin Herrenschmidt
2013-08-13 21:03       ` Benjamin Herrenschmidt
2013-08-13 21:03       ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2013-08-06 16:11 Sudeep KarkadaNagesha
2013-08-08 14:43 ` Sudeep KarkadaNagesha
2013-08-08 15:27   ` Rob Herring
2013-08-08 15:49     ` Sudeep KarkadaNagesha
2013-08-12  8:54       ` Sudeep KarkadaNagesha
2013-08-12  9:03         ` Viresh Kumar
2013-08-12 11:51           ` Rafael J. Wysocki
2013-08-12 12:41             ` Sudeep KarkadaNagesha
2013-08-12 13:13               ` Rafael J. Wysocki
2013-08-12 13:06                 ` Sudeep KarkadaNagesha

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=520B7DAE.3060501@gmail.com \
    --to=robherring2@gmail.com \
    --cc=Sudeep.KarkadaNagesha@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=olof@lixom.net \
    --cc=rjw@sisk.pl \
    --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.