linuxppc-dev.lists.ozlabs.org archive mirror
 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: "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
> 
> 
> 

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

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5208E2D3.7060005@arm.com>
     [not found] ` <3356439.a21MloFP7n@vostro.rjw.lan>
2013-08-13 15:40   ` [GIT PULL] DT/core: cpu_ofnode updates for v3.12 Sudeep KarkadaNagesha
2013-08-13 18:29     ` Sudeep KarkadaNagesha
2013-08-13 21:07       ` Benjamin Herrenschmidt
2013-08-14 10:01         ` Sudeep KarkadaNagesha
2013-08-14 11:37           ` Benjamin Herrenschmidt
2013-08-14 13:21             ` Sudeep KarkadaNagesha
2013-08-14 22:57               ` Benjamin Herrenschmidt
2013-08-14 12:53           ` Rob Herring [this message]
2013-08-14 13:27             ` Sudeep KarkadaNagesha
2013-08-13 18:37     ` Michal Simek
2013-08-14  8:41       ` Sudeep KarkadaNagesha
2013-08-13 18:44     ` Rob Herring
2013-08-13 19:45       ` Rafael J. Wysocki
2013-08-13 21:09         ` Benjamin Herrenschmidt
2013-08-14  9:23         ` Sudeep KarkadaNagesha
2013-08-13 21:08       ` Benjamin Herrenschmidt
2013-08-13 21:03     ` Benjamin Herrenschmidt

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 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).