Date: Thu, 6 Aug 2015 12:32:21 +0800
From: Chenhui Zhao <chenhui.zhao@freescale.com>
Subject: Re: [PATCH 3/3] PowerPC/mpc85xx: Add hotplug support on E6500 cores
To: Scott Wood <scottwood@freescale.com>
CC: <b29983@freescale.com>, <b07421@freescale.com>,
        <linux-kernel@vger.kernel.org>,
        Tang Yuantian <Yuantian.Tang@freescale.com>,
        "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Message-ID: <1438835541.23384.1@remotesmtp.freescale.net>
In-Reply-To: <1438831004.2097.146.camel@freescale.com>
References: <1438334444-31919-1-git-send-email-b29983@freescale.com>
	<1438334444-31919-3-git-send-email-b29983@freescale.com>
	<1438388531.19345.88.camel@freescale.com>
	<1438772906.21522.2@remotesmtp.freescale.net>
	<1438831004.2097.146.camel@freescale.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2015 04:32:23.6661
 (UTC)
X-MS-Exchange-CrossTenant-Id: 710a03f5-10f6-4d38-9ff4-a80b81da590d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=710a03f5-10f6-4d38-9ff4-a80b81da590d;Ip=[192.88.158.2];Helo=[az84smr01.freescale.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB563
X-Microsoft-Exchange-Diagnostics: 1;BL2PR03MB145;2:PV52jr+NF29zQUSw77ZAZlk044ZgQfqOa1IfQ9Aso/lNAld7YQJK1bnTtzLbVVwfcldd5XljDdEGkyCstDB1Q3xpNDFpOrKX1gl0Xy8A4qNWSKJ57qYQrqZ5IFGH77o925z1txXTfhiVNb0Sx3zQFB6Nl+1792iYexEGdaIUhMI=;3:ohcF9t4VdFQMeL9Oy8dL4/FTcckS030CHlEvx6aXacHESuGpW1K5PI09PULzG5bpT/2Wo04bIcEWdDU83zu7xlYKiOZDR/FZLT2L+HcuRi989C826UDjsMNYI9y6XyXtiysIIvJPZp1EAJ56xJw6acvtOFgFqf187UhvkcRzpfyNjbAeAXqQNCSZ4O/xnd6/EUh3BdBSr4RU1n4hiFNvZi24oJAYyqNKdjAj1xRJP9Q=;25:854eJnSzk6frloT/s7x+Rm6hQEIrduGtTCEtEyI+rbvfSjbOTs6eQjF6drH2mcYFztcohNgWJmGFOXifKqD7alVG3WjxR99HPjW1pxIgT3Hon5qwUI8xoPBt+RD1jIZeXJMBE7tRj/Lcg3mAD5SDqLoMs/prEBI8vFbwPNDSYCjv0U1h2NdthzNavSieMrdjR/ZP6cfJXbUCMue16lbf5Z7APfkHZmHkZZqcxGtz5WJNiqodhayFNxG9BGC3QDkEb+ZKHHSEu4l28AKlzV50zA==;23:Qez2eX6jBk2gewClZje8An1yrrPboItIgPDjwp1Et6ykABZhacZS42l5+R3Ygg3o8axdEy9NWnZpPOZzg4VvsAKN8ifqJRFXKhSpAVWixlXN+UkLmhi5LhaiA4LxKL2rYPODdSfLqNCufciKH91dYrIOVSkHlfA5MP4/LVdxJeCWwXW0JaK1fpw1Dvd7qFW0EBwrokjO1n8R59KCflAum/peWyN/a2a7D0ZB7adudWuEa/7Mz4RWVOGabc6WqxSl
X-OriginatorOrg: freescale.com
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2399
Lines: 71


On Thu, Aug 6, 2015 at 11:16 AM, Scott Wood <scottwood@freescale.com> 
wrote:
> On Wed, 2015-08-05 at 19:08 +0800, Chenhui Zhao wrote:
>>  On Sat, Aug 1, 2015 at 8:22 AM, Scott Wood <scottwood@freescale.com>
>>  wrote:
>>  > On Fri, 2015-07-31 at 17:20 +0800,  b29983@freescale.comwrote:
>>  > >  +             /*
>>  > >  +              * If both threads are offline, reset core to 
>> start.
>>  > >  +              * When core is up, Thread 0 always gets up 
>> first,
>>  > >  +              * so bind the current logical cpu with Thread 0.
>>  > >  +              */
>>  > >  +             if (hw_cpu != cpu_first_thread_sibling(hw_cpu)) {
>>  > >  +                     int hw_cpu1, hw_cpu2;
>>  > >  +
>>  > >  +                     hw_cpu1 = 
>> get_hard_smp_processor_id(primary);
>>  > >  +                     hw_cpu2 = 
>> get_hard_smp_processor_id(primary +
>>  > > 1);
>>  > >  +                     set_hard_smp_processor_id(primary, 
>> hw_cpu2);
>>  > >  +                     set_hard_smp_processor_id(primary + 1,
>>  > > hw_cpu1);
>>  > >  +                     /* get new physical cpu id */
>>  > >  +                     hw_cpu = get_hard_smp_processor_id(nr);
>>  >
>>  > NACK as discussed in http://patchwork.ozlabs.org/patch/454944/
>>  >
>>  > -Scott
>> 
>>  You said,
>> 
>>      There's no need for this. I have booting from a thread1, and 
>> having
>>  it
>>      kick its thread0, working locally without messing with the 
>> hwid/cpu
>>      mapping.
>> 
>>  I still have questions here. After a core reset, how can you boot
>>  Thread1
>>  of the core first. As I know, Thread0 boots up first by default.
> 
> So the issue isn't that thread1 comes up first, but that you *want* 
> thread1
> to come up first and it won't.  I don't think this remapping is an 
> acceptable
> answer, though.  Instead, if you need only thread1 to come up, start 
> the
> core, have thread0 start thread1, and then send thread0 into whatever 
> waiting
> state it would be in if thread1 had never been offlined.
> 
> -Scott

Remapping is a concise solution. what's the harm of it?
Keeping things simple is good in my opinion.

-Chenhui


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/