From patchwork Tue Dec 8 18:50:38 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dirk Behme X-Patchwork-Id: 7801371 X-Patchwork-Delegate: horms@verge.net.au Return-Path: X-Original-To: patchwork-linux-sh@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 685549F1C2 for ; Tue, 8 Dec 2015 18:50:51 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8E58220396 for ; Tue, 8 Dec 2015 18:50:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7F8120398 for ; Tue, 8 Dec 2015 18:50:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbbLHSut (ORCPT ); Tue, 8 Dec 2015 13:50:49 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35291 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbbLHSus (ORCPT ); Tue, 8 Dec 2015 13:50:48 -0500 Received: by wmeo63 with SMTP id o63so7356131wme.2; Tue, 08 Dec 2015 10:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=gzXW1w+5DVYD8NFEhlCkFctg8Wdt1IhgGjDX/S3mZmk=; b=Y2L9a6rZOHCBU7Hef+dbXpZwOr8MaOKSLwCSyvH/qyWQ/Fb2ybU5V/oyo/M3NrDjh8 286csvbGhkKvoul1xjtmls7bqIGcEpOIoETV3zmItuo7tmQEUGoMXuN30fMU7+OQ58Vs 6AKDsDWB5+VfQ2Xc20oS5WMVcUyOA/xJK3K/zah5Q+p+kQYO/aW/BqYdBGDdPGHFTcVh OekI/lov8DnkmpToOZgdn6GLstRAY1hwfJ/kslkYTYsWslgZt4gB7buIiNM9P+0vc8rB VIprUOOzSuEV4oFvCbi4X0b6pT0/gXPJTYuzfhgdN96QCGzl9ASAlYy22Q8JEG84xt5x xegA== X-Received: by 10.28.97.10 with SMTP id v10mr30709973wmb.66.1449600646527; Tue, 08 Dec 2015 10:50:46 -0800 (PST) Received: from [192.168.178.36] (p4FEE0C93.dip0.t-ipconnect.de. [79.238.12.147]) by smtp.gmail.com with ESMTPSA id u17sm4658454wmd.8.2015.12.08.10.50.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2015 10:50:45 -0800 (PST) Subject: Re: [PATCH v2 6/6] arm64: renesas: r8a7795: Add L2 cache-controller nodes To: Mark Rutland , Sudeep Holla References: <1449512659-16688-1-git-send-email-geert+renesas@glider.be> <1449512659-16688-7-git-send-email-geert+renesas@glider.be> <5665D4C7.1050705@arm.com> <20151207190355.GE28024@leverpostej> Cc: Geert Uytterhoeven , Simon Horman , Magnus Damm , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , Catalin Marinas , Will Deacon , Lina Iyer , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-sh@vger.kernel.org, linux-pm@vger.kernel.org From: Dirk Behme Message-ID: <5667267E.2080601@gmail.com> Date: Tue, 8 Dec 2015 19:50:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20151207190355.GE28024@leverpostej> Sender: linux-sh-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 07.12.2015 20:03, Mark Rutland wrote: > On Mon, Dec 07, 2015 at 06:49:43PM +0000, Sudeep Holla wrote: >> >> On 07/12/15 18:24, Geert Uytterhoeven wrote: >>> + L2_CA57: cache-controller@0 { >>> + compatible = "cache"; >>> + arm,data-latency = <4 4 1>; >>> + arm,tag-latency = <3 3 3>; >> >> Interesting, only PL2xx/3xx cache controller driver reads this from the >> DT and configures the controller. The integrated L2 found in >> A15/A7/A57/A53 needs doesn't make use of these values from the DT. > > These properties seem to be from l2cc.txt, which really only corresponds > to PL210/PL220/PL310 (and variants) and isn't as generic as it sounds. > > I don't see that these are necessary at all. What's about a documentation patch like [1], then? For what is the arm64 dts entry cpu@0 { ... next-level-cache = <&L2_0>; }; L2_0: l2-cache0 { compatible = "cache"; }; good for at all, then? Best regards Dirk [1] +preconfigured by early secure boot code. + +The ARM L2 cache representation for 32-bit cores in the device tree should be done +as follows: Required properties: --- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt index 06c88a4..f687aed 100644 --- a/Documentation/devicetree/bindings/arm/l2cc.txt +++ b/Documentation/devicetree/bindings/arm/l2cc.txt @@ -1,12 +1,18 @@ * ARM L2 Cache Controller -ARM cores often have a separate level 2 cache controller. There are various +ARM 32-bit cores often have a separate level 2 cache controller. There are various implementations of the L2 cache controller with compatible programming models. Some of the properties that are just prefixed "cache-*" are taken from section 3.7.3 of the ePAPR v1.1 specification which can be found at: https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf -The ARM L2 cache representation in the device tree should be done as follows: +ARM 64-bit cores (e.g. A15/A7/A57/A53) have an integrated level 2 cache which +doesn't make use of any values from the kernel device tree. There is no +L2 cache configuration done in the kernel. The L2 cache is assumed to be