[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5592A2BA.7010604@codeaurora.org>
Date: Tue, 30 Jun 2015 09:07:54 -0500
From: Timur Tabi <timur@...eaurora.org>
To: Will Deacon <will.deacon@....com>
CC: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Shanker Donthineni <shankerd@...eaurora.org>,
"awallis@...eaurora.org" <awallis@...eaurora.org>,
"abhimany@...eaurora.org" <abhimany@...eaurora.org>,
"sboyd@...eaurora.org" <sboyd@...eaurora.org>,
Vipul Gandhi <vgandhi@...eaurora.org>
Subject: Re: [PATCH 1/3] hvc_dcc: bind driver to core0 for reads and writes
Will Deacon wrote:
>> >Selecting this option will enable code that serializes all console
>> >input and output to core 0. The DCC driver will create input and
>> >output FIFOs that all cores will use. Reads and writes from/to DCC
>> >are handled by a workqueue that runs only core 0.
> What happens if CPU0 is hotplugged off?
I guess the whole thing just breaks.
I don't know what to say. Trace32's DCC window is latched to CPU0. If
that CPU is hotplugged off, then I don't think there's a mechanism for
Trace32 to migrate to another CPU. It will broken no matter what.
That's why this feature is disabled by default. If you're working on an
SMP ARM system and using Trace32, you will need this patch. It might be
possible for Lauterbach to fix Trace32 to provide this feature
internally in some situations (e.g. SMP mode where there's one window
for all cores), but not in every situation.
I can add a "depends on !CPU_HOTPLUG" to the Kconfig, but I think that's
overkill. This is really a "use it if you need it" patch, and DCC is
used mostly for debugging.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists