From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props Date: Mon, 08 Sep 2014 15:18:18 +0200 Message-ID: <5220736.Vp1uzqqDMY@wuerfel> References: <1410176286-32533-1-git-send-email-linus.walleij@linaro.org> <65434961.9Ji0STQpff@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from mout.kundenserver.de ([212.227.126.130]:57904 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753047AbaIHNS3 (ORCPT ); Mon, 8 Sep 2014 09:18:29 -0400 In-Reply-To: Sender: linux-leds-owner@vger.kernel.org List-Id: linux-leds@vger.kernel.org To: Linus Walleij Cc: "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "linux-leds@vger.kernel.org" , "linux-pm@vger.kernel.org" , Pawel Moll , Mark Rutland , Marc Zyngier , Will Deacon , Rob Herring On Monday 08 September 2014 14:43:55 Linus Walleij wrote: > > > > > and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e. > > the fundamental unit of cache management as seen from the CPU, independent > > of how it is physically organized. > > Yeah. Well, actually that means the variable in cache-l2x0.c should > be renamed from CACHE_LINE_SIZE to CACHE_BLOCK_SIZE > if we go with that terminology, right? That is the real change that > is needed to make terminology consistent then. Not sure if it's worth it. It may be a case of IBM terminology being at odds with ARM terminology. ;-) Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 08 Sep 2014 15:18:18 +0200 Subject: [PATCH 6/7 v6] ARM: l2x0: calculate associativity from ePAPR cache props In-Reply-To: References: <1410176286-32533-1-git-send-email-linus.walleij@linaro.org> <65434961.9Ji0STQpff@wuerfel> Message-ID: <5220736.Vp1uzqqDMY@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Monday 08 September 2014 14:43:55 Linus Walleij wrote: > > > > > and CACHE_LINE_SIZE seems to be what ePAPR calls cache-block-size, i.e. > > the fundamental unit of cache management as seen from the CPU, independent > > of how it is physically organized. > > Yeah. Well, actually that means the variable in cache-l2x0.c should > be renamed from CACHE_LINE_SIZE to CACHE_BLOCK_SIZE > if we go with that terminology, right? That is the real change that > is needed to make terminology consistent then. Not sure if it's worth it. It may be a case of IBM terminology being at odds with ARM terminology. ;-) Arnd