From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id B975C1007D1 for ; Fri, 11 Nov 2011 03:42:36 +1100 (EST) Subject: Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Kumar Gala In-Reply-To: <20111110163100.GA11983@schlenkerla.am.freescale.net> Date: Thu, 10 Nov 2011 10:42:25 -0600 Message-Id: References: <4E42AB6F.1050900@freescale.com> <1320883635-17194-9-git-send-email-Kyle.D.Moffett@boeing.com> <3937191C-A735-4668-8E80-9FB4B35E2F63@kernel.crashing.org> <20111110163100.GA11983@schlenkerla.am.freescale.net> To: Scott Wood Cc: Baruch Siach , Timur Tabi , linux-kernel@vger.kernel.org, Paul Gortmaker , Paul Mackerras , Kyle Moffett , linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Nov 10, 2011, at 10:31 AM, Scott Wood wrote: > On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote: >>=20 >> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote: >>=20 >>> As FreeScale e500 systems have different cacheline sizes from = e500mc, it >>> is basically impossible for the kernel to support both in a single >>> system image at present. >>>=20 >>> Given that one is SPE-float and the other is classic-float, they are = not >>> generally userspace-compatible either. >>>=20 >>> This patch updates the conditional to depend on whether the system = is >>> actually targetting an "e500" or "e500mc" core and entirely removes = the >>> unused sync-to-lwsync-replacement on e500v1/e500v2 systems. >>>=20 >>> Signed-off-by: Kyle Moffett >>> --- >>> arch/powerpc/include/asm/synch.h | 16 ++++------------ >>> 1 files changed, 4 insertions(+), 12 deletions(-) >>=20 >> Nak, we can run an e500mc in a mode that is compatible with = e500v1/v2. I see no reason to change the support we have there. >=20 > What "mode" do you mean? DCBZ32? We don't support using that = currently, > and I'd imagine the performance implication would be such that you'd > never want to do it unless it's the only way to make some piece of = legacy > software work. Correct, DCBZ32, we've had customers that go down this path. >> I see no reason to change the support we have there. >=20 > No reason to remove complexity that is not needed, and is not planned = to > be needed? I'd rather wait for at least 2 years for e500mc devices to have further = deployment before we'd remove this. - k=